2026 年，我的 21 条 AI Coding 最佳实践
内容提要
作者提出21条AI编程最佳实践，核心是“许愿式编程”：向Agent讲清背景与目标，少管技术细节，优先使用最强模型。规则方面，让Agent了解说话风格，用脚本约束硬性规则，密钥不要贴给Agent。编码前先说明改动影响，让Agent自建验证脚本，多Agent使用独立worktree。修Bug先找原因，两次未果加日志，三次失败清空上下文重来。写码与审查Agent分离，Review最多三轮。危险改动亲自验证。提交需写清验证与回滚方式，新功能先小范围试用，并为线上问题留存测试案例、举一反三。
延伸解读
从写代码到“许愿”：角色转变的关键
文章强调把技术实现细节交给 Agent，人只负责讲清背景、目标和验收标准。这并非偷懒，而是要求开发者把精力前移到需求定义和结果判断上。配套做法是优先用最强模型、每次只拆最小可用版本并及时提交，让“放手”建立在可回滚、可验证的基础上，而不是盲目信任。
规则不能只靠提示词，要靠脚本兜底
作者指出，Agent 必须遵守的硬性规则不能完全依赖 prompt，因为模型可能拦不住，需要用规则脚本去限制并真实跑通才算完成。同时，密钥和 token 不要贴给 Agent，贴了就当已泄露并立即更换。这提醒读者：把 AI 编程纳入工程流程时，约束和权限边界要比口头约定更可靠。
修 Bug 与 Review 的止损机制
排查问题时先找原因再动手，两次没修好就加日志看真实数据，三次失败则清空上下文重新描述问题与已试解法。审查环节让写码和 Review 的 Agent 分离，最多跑三轮，第二轮只看新改动。这些规则的价值在于给 Agent 的反复尝试设定明确上限，避免在错误方向上消耗时间。
发布与复盘：把每次事故变成测试资产
提交时要求写清做了什么、如何验证、出问题怎么回滚，git 记录本身也成为 Agent 的上下文。对外功能先小范围试用，用 beta 开关防止全量风险。线上 Bug 和用户反馈都要留测试案例，上线前跑一遍，换模型时也跑旧问题。这套做法把一次性修复转化为可复用的质量防线。
Q&A
什么是许愿式编程？
许愿式编程是指从关注技术实现细节转向大胆向 AI 表达想法，提出足够高的要求和任务，不必担心 AI 实现不了，因为当前模型能力已经足够强大。
如何给 AI Agent 提需求更有效？
多讲背景和目标，少替它考虑技术细节；告诉它为什么做、给谁用、做成什么样最好，具体技术细节让它自己判断。同时优先使用业界最好的模型，避免用差模型导致效率低下。
使用 AI 编程时有哪些必须遵守的规则？
让 Agent 了解你的说话风格（如“看看”只分析不改代码，“修复”才动手）；AGENTS.md 等文件只写代码中看不出的规则和被否决的方案；密钥和 token 不要贴给 Agent，贴了就当泄露立即更换；必须遵守的规则要用脚本限制，不能只靠 prompt。
多个 Agent 同时工作要注意什么？
让每个 Agent 使用独立的 worktree 代码目录，提交时只提交自己改的代码，不碰他人代码；各自改完后合并，再完整跑一遍测试。
修 Bug 时 Agent 反复修不好怎么办？
先找到原因再动手；如果两次没修好，就加日志看真实数据和运行效果，不要盲目猜；如果尝试 3 次还不对，直接清空上下文，重新写清楚问题、诉求和尝试过的解法让 Agent 重新开始。
如何安排代码审查（Review）更合理？
让写代码的 Agent 和 Review 的 Agent 分开，保持解耦；Review 最多跑 3 轮，从第二轮开始只看新改动的地方；对于删除、付费、发布等危险改动，要亲自查看实际效果。
提交和发布代码时有哪些最佳实践？
每次提交让 Agent 写清楚做了什么、如何验证、出问题如何回滚；对外功能先给自己或尝鲜用户使用，不要一上来就全量，可在软件中加入 beta 更新开关。
如何利用线上问题来改进 AI 编程流程？
对每个线上 Bug 和用户反馈留一个测试案例，每次上线前跑一遍；换模型时也跑旧问题看模型是否还行；修复问题时让 Agent 举一反三，把同类问题一起修复。
