我花了一个下午的时间，将我的AI编码习惯总结成20条规则，你和你的智能体可以一起学习这些规则。 简报 1. 不要事事都管着实现方式。描述你想要的结果。现在的模型已经足够好了，所以要设定远大的目标，不要担心它无法实现。 2. 向你的智能体说明背景和目标：为什么它很重要，它的目标用户是谁，以及它应该达到怎样的优秀水平。然后，不要纠结于技术细节。 3. 使用最佳模型。较弱的模型只会带来更多的反复沟通、时间浪费和挫败感。 4. 在添加任何功能、设置或开关之前，务必让智能体先征求你的意见。不要让它添加没人会用到的功能、开关或复制内容，并让它在开发过程中记录你的产品规则。 5. 设想宏大的目标，但要让它以最小的可用步骤逐步构建，并随时反馈。 规则 6. 教它像你说话一样：“查看”或“分析”意味着阅读并报告，“修复”或“更改”意味着编辑。提交、发布和删除操作都需要你的许可。 7. 在 AGENTS.md 或 CLAUDE.md 文件中，只写入它无法从已排除的选项中学习到的内容。切勿将密钥或令牌粘贴到聊天记录中。如果粘贴了，请将其视为泄露并轮换使用。 8. 仅靠提示无法有效执行规则。使用脚本强制执行，并确保检查能够通过。 编码 9. 在编写代码之前，让它解释它将更改什么以及这将影响什么，以便你了解上下文并做出判断。 10. 让它为项目构建一个验证脚本，并在结果出来后运行它。随着时间的推移，这将成为你的代理的测试套件。 11. 并行代理各自拥有自己的工作树，并且只提交自己的更改。所有内容合并后，运行完整的测试套件。 调试 12. 修复前先找出原因。如果两次修复都失败，请添加日志并进行调试。 13. 如果三次都失败，请清除上下文，重新审视问题、目标以及已尝试过的方法。 评审 14. 将编写代码的代理与评审代理分开。 15. 评审轮数限制为 3 轮。从第二轮开始，只评审新增内容。 16. 变更风险越大，检查就越深入。例如删除操作、支付系统变更等，都需要亲自检查并确认实际结果。 发布 17. 每次提交都应说明变更内容、验证方式以及回滚方法。您的 Git 历史记录将成为后续代理的重要参考信息。 18. 自己先使用，或先提供给早期测试人员。添加 beta 更新不会影响到所有人。 回顾 19. 每个生产环境错误和用户报告都应生成一个测试用例，并在每次发布前运行。每次切换模型后都要重新运行测试，以检查新模型是否有效。 20. 修复一个问题时，也要检查并修复功能和视觉效果方面的相同问题。