开篇
这两周，我们已经做了不少事情：
- 盘点自己的开发工作流。
- 搭建 AI 编程工作台。
- 学习如何写高质量 Prompt。
- 让 AI 补全需求、拆解任务和先写方案。
- 用 AI 导览陌生项目。
- 审查 AI 生成的代码。
看起来，我们已经掌握了很多技巧。
但技巧越多，越容易出现一个新的问题：
我到底应该把 AI 当成什么？
有人把 AI 当作一个“高级搜索框”。
遇到问题就问一句，得到答案就结束。
有人把 AI 当作“自动写代码工具”。
需求粘贴进去，代码复制出来，出了问题再继续修补。
还有人把 AI 当作一名“不会犯错的高级工程师”。
只要模型给出了完整方案，就默认它已经理解了项目和业务。
我更愿意把这几种使用方式概括成两个比喻：
把 AI 当实习生
VS
把 AI 当工程搭档
这两个比喻不是为了给 AI 分级，而是为了帮助我们看清自己的协作方式。
如果你把 AI 当实习生，重点是：
给任务
↓
给上下文
↓
检查结果
↓
指出问题
↓
让它继续修改
如果你把 AI 当工程搭档，重点则会进一步升级：
共同澄清目标
↓
共同拆解问题
↓
共同比较方案
↓
共同验证结果
↓
共同沉淀知识
今天做一次阶段复盘，看看这两种方式到底有什么区别，以及中级开发者应该怎样逐步建立更成熟的 AI 协作模式。
本文不会讨论什么
本文不是要给 AI 赋予人格，也不是要把开发者和模型放在完全平等的位置上。
本文不会：
- 认为 AI 可以替代开发者承担最终责任。
- 建议把所有任务都交给 AI 处理。
- 认为只要 Prompt 足够好，就不需要测试和评审。
- 把“工程搭档”理解成无条件相信 AI 的输出。
- 讨论某个具体模型的排名或工具选择。
本文只讨论一个工程问题：
我们应该如何组织和管理与 AI 的协作，才能让它从一次性工具变成稳定的生产力系统？
一、把 AI 当实习生，通常是什么样
“实习生”这个比喻不代表能力低，而是强调：
- 它需要明确任务。
- 它缺少完整上下文。
- 它可能误解隐含规则。
- 它的结果必须经过检查。
- 它需要根据反馈迭代。
很多 AI 编程场景，其实都适合先采用这种工作方式。
1. 任务必须足够具体
不要只说：
帮我实现用户管理。
可以改成：
请在现有用户模块中新增“修改手机号”能力。
范围：
- 只允许当前用户修改自己的手机号。
- 修改前需要验证旧手机号。
- 修改成功后记录安全日志。
不在范围内：
- 不修改登录流程。
- 不修改找回密码流程。
- 不新增短信供应商。
请先输出实现方案和待确认问题，暂时不要写代码。
任务越清楚，AI 越容易产出可检查的结果。
2. 上下文不能只靠猜
实习生不知道项目约定时，需要我们主动提供信息：
项目使用 Java + Spring Boot。
业务异常统一使用 DomainException。
用户数据由 UserService 管理。
手机号修改需要经过 AuthService 验证。
修改后需要补充 Service 层单元测试。
如果上下文不完整，就应该允许 AI 先提问，而不是要求它直接补全。
3. 结果必须有验收标准
一个好的任务交付，不是“代码看起来完整”，而是能够回答：
- 哪些场景应该成功？
- 哪些场景应该失败？
- 失败后数据是否保持不变？
- 是否需要日志、通知或审计？
- 如何通过测试证明实现正确？
把这些标准写清楚，AI 才知道什么叫完成。
二、把 AI 当实习生的优点和局限
优点：边界清晰，风险可控
在这种模式下，开发者始终掌握：
- 任务范围。
- 技术方案。
- 修改权限。
- 验收标准。
- 最终合并决定。
适合以下场景：
- 第一次接触 AI 编程。
- 修改生产代码。
- 处理高风险业务。
- 项目上下文还没有整理好。
- 团队需要逐步建立信任。
局限：容易陷入“你写我改”
如果每轮协作都只是：
你写代码
↓
我发现问题
↓
你再修代码
↓
我继续发现问题
AI 就会变成一个被动执行器。
它可能完成很多局部动作，但无法帮助你发现更高层次的问题：
- 当前任务是否值得做？
- 有没有更小的修改范围？
- 方案是否会增加未来维护成本？
- 这个问题是不是应该通过流程或数据约束解决？
所以，“实习生模式”适合控制风险，但不应该是协作的终点。
三、把 AI 当工程搭档，意味着什么
工程搭档不是“让 AI 自己做决定”。
它意味着我们把 AI 提前放进工程思考过程，而不是只在最后让它生成代码。
1. 从交付任务升级为共同理解问题
可以先这样开始：
这是当前需求和项目上下文。
请先不要给实现代码。
请帮助我确认：
1. 这个问题真正要解决的是什么？
2. 当前描述中有哪些隐含假设？
3. 可能影响哪些模块和用户行为？
4. 有哪些不做的事情？
5. 怎样定义本次任务完成？
这一步不是让 AI 替我们做产品决策，而是借助它扩大问题观察范围。
2. 从“给出答案”升级为“比较选择”
当任务存在多个方案时，不要直接问：
哪个方案最好？
可以要求它展示取舍：
请比较以下三个方案：
1. 在现有 Service 中增加逻辑。
2. 新增独立领域服务。
3. 通过异步事件处理。
请从以下角度分析：
- 实现复杂度
- 对现有代码的影响
- 数据一致性
- 性能
- 测试难度
- 后续扩展成本
最后给出推荐方案，但说明推荐依赖哪些前提。
工程判断的价值不只是选择一个答案，而是知道这个答案在什么前提下成立。
3. 从“写完代码”升级为“共同验证”
搭档关系必须包含反馈闭环：
方案
↓
实现
↓
测试
↓
运行结果
↓
问题反馈
↓
修复和复盘
没有真实测试、日志和运行结果，AI 只能根据静态上下文推测。
因此可以把结果反馈给它：
这是测试输出和运行日志。
请不要直接修改代码。
请先判断：
1. 失败发生在哪个阶段？
2. 当前现象与预期有什么差异？
3. 哪些原因可以从日志直接确认？
4. 哪些只是可能原因？
5. 下一步最小验证动作是什么？
这比直接说“帮我修复这个报错”更接近工程排障。
四、两种模式的核心区别
| 对比维度 | AI 实习生 | AI 工程搭档 |
|---|---|---|
| 参与时间 | 需求明确后 | 需求澄清阶段就参与 |
| 主要任务 | 执行具体工作 | 共同分析和执行 |
| 上下文方式 | 开发者主动提供 | AI 协助发现上下文缺口 |
| 输出重点 | 代码和局部结果 | 方案、取舍、代码和验证 |
| 反馈方式 | 指出错误并修改 | 用证据共同定位问题 |
| 风险控制 | 依靠人工检查 | 依靠流程、证据和检查 |
| 知识沉淀 | 结果用完即丢 | 形成 Prompt、文档和检查卡 |
| 最终责任 | 开发者承担 | 仍由开发者承担 |
需要特别强调：
工程搭档模式不是减少人工审查，而是把人工判断前移，并且让 AI 参与更多有价值的思考环节。
五、中级开发者最适合采用的协作分层
我不建议一开始就把所有决策交给 AI。
更稳妥的方式，是根据任务风险分层。
第一层：执行型任务
AI 可以直接协助完成：
- 生成样板代码。
- 补充字段映射。
- 编写简单查询。
- 生成基础测试。
- 整理注释和文档。
- 做格式化和局部重命名。
这类任务的共同特点是：
- 规则明确。
- 修改范围小。
- 结果容易验证。
- 失败成本较低。
第二层：分析型任务
AI 可以参与：
- 需求拆解。
- 代码库导览。
- 调用链分析。
- 方案比较。
- 风险识别。
- 测试矩阵设计。
但输出必须经过开发者确认。
第三层：决策型任务
以下事项不应该直接交给 AI 决定：
- 核心业务规则。
- 权限模型。
- 数据迁移策略。
- 资金和支付流程。
- 安全边界。
- 生产事故处置。
- 跨团队架构取舍。
AI 可以提供选项和风险分析，但最终决策需要由有业务和系统上下文的人完成。
可以用这张表快速判断：
| 任务类型 | AI 可以做什么 | 开发者必须负责什么 |
|---|---|---|
| 执行型 | 生成和修改 | 验证范围和结果 |
| 分析型 | 提问、归纳和比较 | 确认事实和取舍 |
| 决策型 | 提供备选方案和风险 | 做最终判断和承担责任 |
六、真正高效的 AI 协作，不是少说话
很多人以为 AI 提效就是减少输入。
实际上，真正高效的协作往往需要更多高质量交流：
说明目标
↓
补充上下文
↓
确认理解
↓
限定范围
↓
请求最小实现
↓
执行验证
↓
反馈证据
表面上看，Prompt 变长了。
但总耗时通常会下降，因为它减少了：
- 反复返工。
- 错误方向的代码。
- 跨模块误修改。
- 测试阶段才发现的需求遗漏。
- 线上才暴露的边界问题。
可以把一次任务的总成本理解为：
总成本
=
前期澄清成本
+
实现成本
+
返工成本
+
验证成本
+
事故成本
适当增加前期澄清，往往可以降低后面的返工和事故成本。
七、我会固定保留的 7 条 AI 协作原则
原则 1：先让 AI 复述，再让它实现
如果目标都没有对齐，代码越多，返工越多。
原则 2：先给最小上下文，再按需补充
不要一开始把整个仓库丢给 AI，也不要只给一句需求。
原则 3：事实、推测和建议必须分开
AI 的“应该”“通常”“可能”都需要进一步验证。
原则 4：复杂任务先要方案，简单任务至少要范围
不是所有修改都需要完整设计，但所有修改都应该有边界。
原则 5：让 AI 提前暴露风险，而不是等报错后再修
边界、权限、并发、异常和测试都应该在代码生成前被讨论。
原则 6：用测试和运行结果反馈，不用情绪描述反馈
“还是不对”不如提供输入、日志、堆栈和实际结果。
原则 7：把有效对话沉淀成团队资产
好的 Prompt、检查清单、调用链和排障流程，不应该只停留在一次聊天里。
八、从“会用 AI”升级到“会管理 AI 协作”
前 14 天的学习重点，不是记住多少 Prompt，而是建立一套稳定的协作节奏。
我会把它整理成 5 个步骤：
第一步：定义目标
这次任务要改变什么？
用户能观察到什么结果？
哪些事情明确不做？
第二步：准备上下文
相关代码在哪里？
项目约定是什么？
已有测试和限制是什么？
第三步：设计交互
这次需要 AI 执行、分析，还是比较方案？
需要一次完成，还是分阶段完成？
第四步：建立验证
什么现象说明完成？
哪些边界和风险必须覆盖？
用什么测试、日志或运行结果证明？
第五步：沉淀资产
这次协作中，哪些 Prompt、检查项和结论可以复用？
当这 5 步逐渐固定下来，AI 才真正进入你的开发系统。
九、一个可以直接复用的协作启动 Prompt
以后接到一个中等复杂度的开发任务，我会先使用下面这段 Prompt：
请作为我的工程协作助手，协助我完成下面的开发任务。
任务：
<填写需求>
项目上下文：
<填写技术栈、相关模块、已有约定和限制>
请先不要写代码，先完成以下工作：
1. 用自己的话复述任务目标。
2. 列出本次范围和明确不在范围内的内容。
3. 区分已知事实、推测和待确认项。
4. 指出需要阅读的文件和项目上下文。
5. 列出可能的边界、异常、安全和并发风险。
6. 给出可选实现方案及取舍。
7. 设计验收标准和测试矩阵。
输出要求：
- 不确定的内容单独列出。
- 不要把通用最佳实践冒充项目事实。
- 没有得到确认前，不生成完整代码。
- 最后给出进入实现阶段前的最小确认清单。
这段 Prompt 的作用不是让 AI 直接完成全部工作，而是建立一次有边界的工程协作。
十、我的第二周复盘检查卡
[ ] 我没有把 AI 当成无条件正确的高级工程师
[ ] 我能明确告诉 AI 当前任务的目标和范围
[ ] 我会主动提供项目约定和验收标准
[ ] 我允许 AI 先提问，而不是强迫它立即写代码
[ ] 我能区分执行型、分析型和决策型任务
[ ] 我会要求 AI 说明依据、风险和触发条件
[ ] 我使用测试、日志和运行结果进行反馈
[ ] 我没有把最终责任交给 AI
[ ] 我把有效 Prompt 和检查清单保存下来
[ ] 我正在形成一套可重复的 AI 协作流程
如果只能做到“让 AI 写代码”，说明还停留在工具使用阶段。
如果已经能够让 AI 参与澄清、分析、验证和复盘，才开始进入工程协作阶段。
十一、总结
把 AI 当实习生，强调的是：
明确任务
提供上下文
检查结果
持续反馈
把 AI 当工程搭档，强调的是：
共同澄清问题
共同分析方案
共同识别风险
共同验证结果
共同沉淀方法
对于中级开发者来说，最稳妥的选择不是二选一，而是根据任务复杂度进行切换：
- 简单、局部、易验证的任务，可以让 AI 承担更多执行工作。
- 中等复杂度任务，让 AI 参与分析、方案和测试设计。
- 高风险和决策型任务，让 AI 提供辅助判断，但由开发者掌握最终决定。
请记住：
AI 编程的进阶，不是让 AI 替你做更多决定，而是让你更有能力管理目标、上下文、风险和验证。
下一篇文章，我们进入一个更贴近真实生产环境的场景：
用 AI 调试一个线上问题：从报错到根因定位。
如果这篇文章对你有帮助，欢迎点赞、收藏、关注专栏。
也欢迎在评论区留言：你现在更常把 AI 当实习生，还是已经开始把它当工程搭档？
✍坚持原创，求关注，点赞，收藏
