开发者总结20条AI编程协作规则，覆盖全流程提效避坑

我花了一个下午，把自己的 AI 编程习惯整理成了 20 条规则，供你和你的智能体共同学习。

**简报**

1. 不要口述实现细节，描述你想要的结果。现在的模型已经足够强大，所以要把目标定高，不要担心它做不到。
2. 给你的智能体提供背景和目标：为什么重要、为谁而做、什么是优秀。然后放手，不要纠结技术细节。
3. 使用可用的最佳模型。较弱的模型只会意味着更多的来回沟通、浪费的时间和挫败感。
4. 在添加功能、设置或开关之前，让智能体先与你确认。不要让它添加没人会用的功能、开关或文案，并让它在过程中写下你的产品规则。
5. 大胆思考，但让它以最小可用的步骤构建，并随时可以回来沟通。

**规则**

6. 教它你的说话方式：“查看”或“分析”意味着阅读并报告，“修复”或“更改”意味着编辑。提交、发布和删除始终需要你的批准。
7. 在 AGENTS.md 或 CLAUDE.md 中，只写它无法从代码库中学到的内容。永远不要将密钥或令牌粘贴到聊天中。如果你这样做了，将其视为已泄露并轮换它们。
8. 仅靠提示词无法维持硬性规则。用脚本、测试和 CI 强制执行它们，这样检查才能真正通过。

**编码**

9. 在编写代码之前，让它解释将要更改的内容以及会影响什么，这样你就有了做出决定的背景。
10. 让它为项目构建一个验证脚本，在每次更改时运行它，并查看结果。随着时间的推移，这将成为你智能体的测试套件。
11. 并行智能体各自拥有自己的工作树，并且只提交自己的更改。合并所有内容后，运行完整的测试套件。

**调试**

12. 在修复之前找到原因。如果两次修复失败，添加日志并停止猜测。
13. 如果三次失败，清除上下文，带着问题、目标和你已经尝试过的方法重新开始。

**审查**

14. 让编写代码的智能体与审查代码的智能体分开，以保持诚实。
15. 将审查限制在 3 轮以内。从第二轮开始，只审查新内容。
16. 更改风险越高，检查越深入。删除、支付和权限是后门，因此请亲自检查并点击查看真实结果。

**发布**

17. 每次提交都说明更改了什么、如何验证以及如何回滚。你的 git 历史将成为下一个智能体的绝佳背景。
18. 先自己使用或交给早期测试者。添加一个 beta 更新，这样就不会影响到所有人。

**回顾**

19. 每个生产环境错误和用户报告都会得到一个在每次发布前运行的测试用例。每当你切换模型时，重新运行它们，看看新模型是否能胜任。
20. 当修复一个问题时，让它找到并修复代码库中其他地方的相同问题。然后让它进行最后的安全检查、错误处理和视觉润色。