本文是 AI 编程反思系列第 5 篇。
用 AI 编程几个月之后，我对“人和 AI 怎么协作”这件事有了很大变化。
一开始，我以为最好的方式是尽量把任务交给 AI，让它自由发挥。后来我发现，这种方式在小任务里很爽，但在复杂项目里很容易失控。
现在我更相信一种新的工作流：
人做判断，AI 做执行，Harness 做约束。
这句话基本就是我现在理解 AI 编程的核心。
一、人不能把判断权完全交出去
AI 很擅长给答案，也很擅长把答案说得很完整。但产品开发中最重要的事情，往往不是“有没有答案”，而是“该选哪个答案”。
做不做这个功能？先做哪个版本？是重构还是打补丁？是追求灵活还是保持简单？是优化体验还是先补稳定性？这些问题都需要人来判断。
如果把判断权完全交给 AI，项目很容易变成“AI 觉得都可以”。
它可以给你三套方案，每套都讲得有道理；它可以告诉你这个架构不错，那个架构也不错；它可以顺着你的每一个新想法继续扩展。
但真正的产品需要取舍。取舍意味着你要知道什么更重要，什么可以先不做，什么即使看起来高级也要放弃。
所以我现在会把判断权牢牢留在人这里。
- 产品方向由人定。
- 功能优先级由人定。
- 架构边界由人定。
- 质量标准由人定。
- 上线节奏由人定。
AI 可以参与讨论，但不能替我承担最终判断。
二、AI 最适合做明确任务的执行者
当判断清楚之后，AI 的执行力非常强。
它可以快速生成代码、整理文档、补测试、解释错误、重构小模块、生成脚本、分析日志、写检查清单。
关键是任务要足够明确。
我现在很少再对 AI 说：“帮我做一个系统。”这种话太大，边界太模糊，AI 很容易凭感觉扩展。
我更倾向于这样描述任务：
- 先阅读现有结构，不要直接改代码。
- 说明你准备改哪些文件，为什么。
- 只实现这个功能，不引入额外功能。
- 保持现有接口兼容。
- 补充错误处理和验证方式。
- 完成后输出变更摘要和测试清单。
当任务变小、边界变清楚，AI 的价值就会明显提升。
它不再是一个乱冲的“万能工程师”，而更像一个执行力极强的协作者。
三、Harness 是让 AI 不乱来的轨道
只靠 Prompt 还不够。因为复杂项目不是一次提示词能解决的。
你需要一套围绕 AI 的约束系统，我把它理解为 Harness。它包括上下文、工具、规则、流程、检查、测试、审计和反馈闭环。
Prompt 是你怎么跟 AI 说话，Harness 是你怎么让 AI 在正确轨道里工作。
比如一个比较稳的 AI 编程流程，不应该是：
“帮我写功能” → 复制代码 → 运行 → 报错再修。
而应该是：
- 先明确需求和不做什么。
- 让 AI 阅读现有代码和约束。
- 让 AI 给出修改计划。
- 人确认方向是否正确。
- AI 小步实现。
- 运行测试或检查清单。
- AI 输出变更说明。
- 人做最终 review。
- 记录关键决策和后续风险。
这套流程看起来慢一点，但对复杂项目来说，它是在保护项目。
四、上下文管理比单次 Prompt 更重要
AI 编程里一个很常见的问题，是上下文漂移。
一开始它理解你的项目，聊着聊着就忘了边界；一开始它按架构来，后面为了修 bug 开始绕路；一开始它知道不做某个功能，后面又把它加回来了。
所以你需要管理上下文。
我现在会尽量把关键上下文沉淀成文档，而不是每次靠临时聊天重复说明。比如：
- 产品定位文档。
- 当前版本范围。
- 模块职责说明。
- 接口约定。
- 数据库设计说明。
- 代码风格和禁止事项。
- 发布检查清单。
这些东西就是 AI 的“护栏”。
没有护栏，AI 只能根据当前对话猜；有了护栏，AI 才能更稳定地协作。
五、把 AI 当成团队，而不是神
我觉得很多人用 AI 编程会出问题，是因为对它的定位错了。
要么把它当神，觉得它什么都能替你完成；要么一遇到错误就完全否定，觉得 AI 不靠谱。
我现在更愿意把 AI 当成一个团队成员。
一个团队成员可以很强，但仍然需要任务、边界、review、测试和管理。你不会让一个新同事不看需求、不看代码、不做 review 就直接改核心系统；同样，也不应该让 AI 这样做。
当你用管理团队的方式管理 AI，很多问题就变得清楚了：
- 需求不清，不要开工。
- 方案不清，不要改代码。
- 影响范围不清，不要合并。
- 没有验证，不要说完成。
- 没有记录，不要继续堆功能。
AI 很强，但它也需要被管理。
六、一个更适合独立开发者的 AI 工作流
结合这几个月的体会，我现在更推荐独立开发者用这样一套流程：
1. 人先写产品卡片
用几句话写清楚：用户是谁，场景是什么，痛点是什么，这一版只解决什么，不解决什么。
2. AI 帮忙拆任务
让 AI 基于产品卡片拆出模块、页面、接口、数据结构和风险点，但不要立刻写代码。
3. 人确认优先级
判断哪些是核心闭环，哪些只是锦上添花。先做最小可用闭环。
4. AI 小步实现
每次只做一个小任务，每次都要求输出修改范围、验证方式和潜在风险。
5. Harness 做检查
用测试、日志、代码检查、发布前校验、发布后回读等方式约束结果。
6. 人做 review 和取舍
最后由人判断是否合并、是否上线、是否继续扩展。
这套流程的重点不是让 AI 更自由，而是让 AI 更稳定。
七、结语：AI 编程不是无人驾驶，而是增强驾驶
我现在不再把 AI 编程理解成“无人驾驶”。
它更像是“增强驾驶”：AI 可以帮你看路、加速、提醒、执行很多动作，但方向盘不能完全丢掉。
个人开发者真正要建立的，不只是提示词技巧，而是一套稳定的人机协作系统。
人负责判断方向，AI 负责提高执行速度，Harness 负责把风险关进笼子里。
这样，AI 才不是一个把项目越堆越乱的工具，而是一个真正能放大个人开发者能力的系统。
评论