文章目录
- 开篇
- 本文不会讨论什么
- 一、为什么第一周结束后要做一次复盘
- 二、这一周的 7 条 AI 编程原则
- 原则 1：让 AI 参与开发，但不要把判断交出去
- 原则 2：项目上下文比角色设定更重要
- 原则 3：需求不清时，先让 AI 补问题，不要让它补代码
- 原则 4：复杂任务先要方案，再要代码
- 原则 5：把 AI 输出当作草稿，必须回到代码和测试中验证
- 原则 6：工具应该服务于工作流，而不是反过来改变工作目标
- 原则 7：把一次有效协作沉淀成下一次可以复用的资产
- 三、把 7 条原则压缩成一张检查卡
- 四、第一周复盘：哪些方法值得继续保留
- 五、下一周的实践方向
- 六、总结
✍创作者：全栈弄潮儿²⁰²⁶
🏡 个人主页：全栈弄潮儿²⁰²⁶
📙 专栏地址：AI 编程进阶实战
开篇
这是《AI 编程进阶实战》的第 7 篇，也是第一周的复盘文章。
过去 6 篇，我们没有急着比较工具，也没有直接讨论如何让 AI 一次生成完整项目，而是沿着一条研发主线逐步展开：
认识 AI 编程的边界 ↓ 识别常见使用陷阱 ↓ 盘点自己的开发工作流 ↓ 搭建 AI 编程工作台 ↓ 写出更完整的编程 Prompt ↓ 把模糊需求拆成开发任务如果只看单篇文章，你可能会记住几个 Prompt、几个流程或几个案例。
但真正值得保存的，是这些内容背后的原则。
因为工具会变化，模型会变化，项目也会变化。
而好的原则可以帮助你在换工具、换团队、换技术栈之后，仍然保持稳定的判断方式。
这一篇不再展开新的工具和案例。
我们只做一件事：
把这一周最值得长期保存的 7 条 AI 编程原则提炼出来。
本文不会讨论什么
为了让复盘真正有价值，本文不会：
- 重新复述前 6 篇的全部内容。
- 给出所谓“最强模型”或“万能工具”的结论。
- 把 AI 编程原则写成必须机械执行的流程。
- 用生成代码数量衡量这一周的效率。
- 把 AI 的建议包装成不需要验证的答案。
复盘的重点不是证明我们已经掌握了多少工具，而是确认：
哪些方法已经可以变成下一周继续使用的工作习惯？
一、为什么第一周结束后要做一次复盘
AI 编程很容易带来即时反馈。
一段代码很快生成，一个报错很快得到解释，一份需求很快变成任务列表。
但即时反馈不等于长期能力。
如果没有复盘，你可能只会留下这些模糊印象：
- 这次 AI 好像帮了不少忙。
- 某个 Prompt 看起来挺好用。
- 某个工具的体验不错。
- 下次遇到类似问题再试试。
这些印象很快会消失。
一次有效的复盘，至少要回答三个问题：
- AI 具体在哪个环节帮到了我？
- 哪些地方的输出需要我重新判断和验证？
- 下次遇到类似任务，我能复用什么？
可以把复盘结果分成三类资产：
| 资产类型 | 具体内容 |
|---|---|
| 判断原则 | 什么时候应该问问题，什么时候可以让 AI 写代码 |
| 工作模板 | Prompt、任务卡、测试清单和复盘表 |
| 验证习惯 | 如何检查代码、日志、测试和改动范围 |
本周的 7 条原则，正是从这三类资产中提炼出来的。
二、这一周的 7 条 AI 编程原则
原则 1：让 AI 参与开发，但不要把判断交出去
AI 可以参与需求分析、代码阅读、方案设计、代码生成、测试和排障。
但它不能替开发者承担最终判断：
- 需求是否真的理解正确。
- 方案是否适合当前系统。
- 代码是否符合团队规范。
- 异常、权限和安全边界是否完整。
- 这个改动是否值得进入生产环境。
第一周最重要的定位是：
AI 是工程协作伙伴，不是最终决策者。
可以用下面这条边界提醒自己：
AI 提供候选答案 ↓ 开发者确认事实和规则 ↓ 代码与测试验证结果 ↓ 开发者承担最终交付责任如果一次任务结束后，你无法解释为什么接受这段代码、为什么采用这个方案，那么这次协作还没有真正完成。
原则 2：项目上下文比角色设定更重要
“你是一名资深工程师”可以帮助 AI 进入某种回答风格。
但它不能代替真实项目上下文。
决定代码能否落地的，通常是这些信息：
- 当前使用什么技术栈。
- 相关模块如何分层。
- 已有接口和数据结构是什么。
- 项目如何处理异常、日志和权限。
- 测试和验证命令是什么。
- 本次修改范围和禁止修改范围是什么。
因此，一条高质量 Prompt 不应该只写：
你是一名资深后端工程师，请帮我实现这个功能。更应该写：
项目使用什么技术栈； 当前代码位于什么模块； 哪些规则已经确认； 哪些文件允许修改； 如何判断实现完成。没有上下文的“资深角色”，只能产生更流畅的猜测。
原则 3：需求不清时，先让 AI 补问题，不要让它补代码
当需求只有一句话时，最危险的动作是直接要求 AI 生成完整实现。
因为代码一旦生成，很多未经确认的假设就会被藏进实现细节里。
更稳妥的顺序是：
原始需求 ↓ 待确认问题 ↓ 业务规则 ↓ 接口和数据约束 ↓ 开发任务 ↓ 代码实现可以让 AI 先回答：
请先不要写代码。 请从业务规则、权限、数据、接口、异常、并发和验收标准几个方面， 列出这条需求中仍然需要确认的问题。 请区分： 1. 已知事实。 2. 可以暂时假设的内容。 3. 必须由产品或开发者确认的内容。AI 在这里的价值，不是替你决定业务，而是帮助你发现那些原本容易被忽略的问题。
原则 4：复杂任务先要方案，再要代码
涉及以下内容时，不建议第一轮就要求完整代码：
- 状态流转。
- 权限和角色。
- 金额和库存。
- 数据库事务。
- 并发和幂等。
- 跨模块或跨服务调用。
- 可能影响已有功能的重构。
更可靠的协作方式是分轮次进行：
第一轮：复述需求、列出假设和风险 第二轮：比较方案、确认模块边界和测试点 第三轮：生成最小实现 第四轮：补充测试并审查改动这并不会降低 AI 的效率。
相反，它能避免 AI 在错误的前提下生成大量代码，减少后续返工。
原则 5：把 AI 输出当作草稿，必须回到代码和测试中验证
AI 的输出可能很完整，也可能很有说服力。
但“完整”和“正确”是两回事。
至少要检查：
[ ] 是否符合项目现有分层和规范？ [ ] 是否修改了不应该修改的文件？ [ ] 是否处理了空值、异常和边界输入？ [ ] 是否遗漏权限、数据安全或并发问题？ [ ] 是否补充了正常、边界和异常测试？ [ ] 是否实际运行过测试、静态检查或接口验证？对于代码改动，还应查看差异：
查看修改文件 ↓ 查看具体 diff ↓ 运行格式化和静态检查 ↓ 运行单元测试 ↓ 验证关键业务场景没有验证的 AI 输出，只能叫建议，不能叫交付。
原则 6：工具应该服务于工作流，而不是反过来改变工作目标
第一周我们把 AI 工作台拆成了几层：
| 工作层 | 更适合做什么 |
|---|---|
| 对话层 | 需求澄清、方案比较、排障假设 |
| IDE 层 | 阅读当前代码、小范围修改和即时反馈 |
| 终端层 | 执行命令、运行测试、批量处理和验证 |
| 模型层 | 根据任务复杂度选择快速、主力或深度模型 |
| 上下文层 | 保存项目结构、规范、测试和安全边界 |
工具选择应该从工作流出发：
我现在处于哪个研发环节？ ↓ 这个环节需要什么输入和输出？ ↓ 结果如何验证？ ↓ 哪个工具最适合完成这一步？不要因为某个工具有自动修改功能，就把不适合自动化的任务交给它。
也不要因为某个模型很强，就用它处理所有简单问题。
原则 7：把一次有效协作沉淀成下一次可以复用的资产
如果每次使用 AI 都从空白对话开始，你会不断重复说明相同的项目背景和工作要求。
建议至少保存下面 4 类内容：
- 有效 Prompt。
- 已确认业务规则。
- 测试和验收清单。
- AI 遗漏问题与人工修正记录。
可以把每次任务结束后的复盘写成这样：
本次任务： [填写] AI 参与的环节： [需求 / 代码阅读 / 方案 / 实现 / 测试 / 排障] 最有效的上下文： [填写] AI 漏掉的问题： [填写] 最终验证方式： [测试 / 日志 / 联调 / 代码审查] 下次可以复用： [Prompt / 清单 / 模板 / 代码片段]真正属于你的 AI 编程能力，不是记住某一句 Prompt，而是不断积累这些经过验证的资产。
三、把 7 条原则压缩成一张检查卡
如果不想每次阅读完整文章，可以保存下面这张检查卡：
AI 编程 7 条原则 1. AI 参与开发，但不替我做最终判断。 2. 项目上下文比角色设定更重要。 3. 需求不清时，先补问题，不补代码。 4. 复杂任务先要方案，再要实现。 5. AI 输出只是草稿，必须回到代码和测试中验证。 6. 工具服务于工作流，不让工具牵着任务走。 7. 把有效协作沉淀成 Prompt、规则和检查清单。这张卡可以放进你的项目文档、个人知识库或工作台配置中。
四、第一周复盘：哪些方法值得继续保留
建议在周末用 10 分钟回答下面的问题：
1. 本周哪个任务使用 AI 后真正减少了返工？ 2. AI 在哪个环节最容易产生错误假设？ 3. 我是否提供了足够的项目上下文？ 4. 我是否在生成代码前确认了需求和规则？ 5. 我是否实际检查了 AI 修改的文件和测试结果？ 6. 哪一条 Prompt 可以沉淀为模板？ 7. 下周准备把 AI 引入哪个新的研发环节？也可以用表格记录：
| 复盘项目 | 本周记录 |
|---|---|
| 最有效的 AI 使用场景 | 需求澄清、代码阅读、测试或其他 |
| 最大的错误假设 | AI 漏掉了什么 |
| 最值得保存的 Prompt | 粘贴或链接 |
| 最需要补充的项目上下文 | 目录、规范、接口或测试 |
| 下周实验目标 | 只选一个具体环节 |
复盘时不要只统计“生成了多少代码”。
更值得关注的是：
- 是否减少了重复沟通。
- 是否更早发现了边界问题。
- 是否更快理解了陌生代码。
- 是否提高了测试和验证的完整度。
- 是否留下了下一次可以复用的资产。
五、下一周的实践方向
第一周我们主要建立了方法和工作台。
接下来可以进入更贴近真实项目的代码理解与开发场景：
- 用 AI 快速读懂陌生项目。
- 让 AI 梳理目录、入口和调用链。
- 让 AI 协助定位一个真实 Bug。
- 用 AI 生成测试矩阵并补齐边界。
- 让 AI 参与代码审查和重构评估。
下一阶段仍然不追求“让 AI 自动完成所有工作”。
我们更关注：
如何让 AI 在真实代码库中工作，同时让开发者保持对上下文、改动和风险的控制。
六、总结
这一周最值得保存的 7 条 AI 编程原则是：
- 让 AI 参与开发，但不要把判断交出去。
- 项目上下文比角色设定更重要。
- 需求不清时，先让 AI 补全问题，而不是瞎写代码。
- 复杂任务先要方案，再要代码。
- 把 AI 输出当作草稿，必须回到代码和测试中验证。
- 工具应该服务于工作流，而不是反过来改变工作目标。
- 把一次有效协作沉淀成下一次可以复用的工程资产。
如果只能记住一句话，可以记住：
AI 编程的核心不是让 AI 写更多代码，而是让每一次输出都经过上下文、约束和验证。
下一篇文章，我们用一个真实场景实践本周的方法：
用 AI 拆一个真实需求：从模糊描述到开发任务清单。
如果这篇文章对你有帮助，欢迎点赞、收藏、关注专栏。
也欢迎在评论区留言：这 7 条原则中，你最想先实践哪一条？
✍坚持原创，求关注，点赞，收藏