2026 年，我的 21 条 AI Coding 最佳实践 - Tw93

假如把我的 AI Coding 经验沉淀成一些最佳实践规则，可以给到大伙复用，会是怎么样的，于是乎，昨天一下午我就在琢磨这个事情，手写反复调整后给到大伙，可以让你和你的 Agent 一起去学习。

需求

1. 从技术实现细节编程转变成许愿式编程，现在模型能力已经足够强大，你只需要大胆把自己想法说出来，给它提足够高的要求和任务，不要担心 AI 实现不了。
2. 多给你的 Agent 讲做这件事情的背景和目标，少替它考虑技术细节，告诉它为什么要做，是给谁用的，做成什么样子你认为是最好的，具体的技术细节让它自己去判断，学会放手。
3. 优先用业界最好的模型，用差模型的时候，一来会让你很不高兴地干活，二来也浪费了很多时间。
4. 要不要做一个新功能以及加一个新配置、开关的时候，让 Agent 先来找你确定，没有人用的功能、开关、文案都不要让它去加，慢慢把这一套你的产品规范让它沉淀起来。
5. 你的想法可以很大，但是让 Agent 干活的时候，尽量让它每次拆分成最小的可用功能版本，不要一次写非常多的代码，及时提交，这样出问题了你可以随时撤回。

规则

6. 让你的 Agent 了解你的说话风格，比如说看看、分析一下这个问题的时候，它只需要去读代码分析问题不要去改代码，你说修复、修改的时候才去动手，每次提交、发布和删除的时候都找你确定。
7. AGENTS.md、CLAUDE.md 里面除去重点的项目型要求外，只写代码里面看不出来的那种规则，以及之前被否决过的方案也可以分流进去。对你而言密钥和 token 不要贴给 Agent，贴了就当已经泄露了，立马去更换一个。
8. 对于 Agent 必须遵守的规则不要完全信 prompt，可能会拦不住，一定要用规则脚本去限制，让它真实跑一遍通过后才算完成了。
9. 维护公司那种庞大项目的时候，适合让 Agent 慢慢沉淀技能、工具、索引和文档，构建一套专属当前项目的 harness，我开源的 Waza 其实就是这样沉淀下来的经验。

编码

10. 开始写代码之前，先让 Agent 讲清楚要改什么地方，会影响到什么功能和效果，这样是为了补充你的上下文，方便后面更好判断决策做什么。
11. 一定要让 Agent 基于项目补充一个能够让自己验证各种结果的脚本，每次特定的时候需要去跑一下验证效果，完成功能后需要检查，让它输出结果给你看，并基于此逐步沉淀你的项目 Agent 测试功能集。
12. 假如有多个 Agent 同时干活的时候，让它们各自用一份独立的 worktree 代码目录，同时提交的时候只提交自己改的代码，不要碰他人的代码，等到各自改完合到一起，再完整跑一遍测试。

排查

13. 修 Bug 的时候先找到原因再去动手，假如两次都没有修好，就去加一些日志看真实的数据以及运行效果，不要盲目去猜问题在哪儿。
14. 假如尝试修复了 3 次还不对，直接清空上下文重新写清楚你的问题、诉求，以及尝试过的解法让 Agent 重新开始。

审查

15. 让写代码的 Agent 和 Review 审查代码的 Agent 分开，保持解耦，这样一方不会被另一方带偏。
16. Review 代码的时候最多让 Agent 跑 3 轮，防止跑着停不下来，第二轮开始只看新改动的地方，不要再把之前 Review 的再看一遍。
17. 对于你和 Agent 判断危险的改动，越危险让它查得越深，特别对于删除、付费、发布这种单向门改动你都需要自己去看一遍，点一下，看实际效果。

发布

18. 每次提交的时候，让 Agent 写清楚做了什么，怎么去验证这个改动，出了问题怎么来回滚，后面开发过程中 git 记录本身就是 Agent 的一个非常好的上下文。
19. 需要对外的功能，可以先给自己用，或者给一批愿意尝鲜的用户使用，不要一上来就全量，可以在你的软件里面加入 beta 更新的开关，防止全量有问题，也是对用户负责。

复盘

20. Agent 需要对每一个线上 Bug 和用户反馈的问题都留一个测试案例，每次上线前都来跑一遍，防止继续踩坑，包括你换模型的时候也可以把这些旧问题全部都跑一遍，看看模型是否还行。
21. 修复问题的时候，让 Agent 学会举一反三，把同类的问题一起修复掉。优化功能的时候，完善视觉的时候也是一样，防止只改一个地方，忘记了其他的地方。