LotusDecoder
RT @HiTw93: 假如把我的 AI Coding 经验沉淀成一些最佳实践规则，可以给到大伙复用，会是怎么样的，于是乎，今天一下午我就在琢磨这个事情，手写反复调整后给到大伙，可以让你和你的 Agent 一起去学习。
需求
1. 从技术实现细节编程转变成许愿式编程，现在模型能力已经住足够强大，你只需要大胆把自己想法说出来，给它提足够高的要求和任务，不要担心 AI 实现不了。
2. 多给你的 Agent 讲做这件事情的背景和目标，少替他考虑技术细节，告诉它为什么要做，是给谁用的，做成什么样子你认为是最好的，具体的技术细节让它自己去判断，学会放手。
3. 优先用业界最好的模型，用差模型浪费的时候，一来回让你很不高兴的干活，二来也浪费了很多时间。
4. 要不要做一个新功能以及加一个新配置、开关的时候，让 Agent 来先问你找你确定，没有人用的功能、开关、文案都不要让他去加，慢慢把这一套你的产品规范让他沉淀起来。
5. 你的想法可以很大，但是让 Agent 干活的时候，尽量让他每次拆分成最小的可用功能版本，不要一次写非常多的代码，即使提交，这样出问题了你可以随时撤回。
规则
6. 让你的 Agent 了解你的说话风格，比如说看看、分析一下这个问题的时候，它只需要去读代码分析问题不要去改代码，你说修复、修改的时候才去动手，每次提交、发布和删除的时候都找你确定。
7. Agent md、CLAUDE md 里面除去重点的项目型要求外，只写代码里面看不出来的那种规则，以及之前被否决过的方案也可以分流进去。对你而言密钥和 token 不要贴给 Agent，贴了就当已经泄露了，立马去更换一个。
8. 对于Agent必须遵守的规则不要完全信 prompt，可能会拦不住，一定要用规则脚本去限制，让它真实跑一遍通过后才算完成了。
编码
9. 开始写代码之前，先让 Agent 讲清楚要改什么地方，会影响到什么功能和效果，这样是为了补充你的上下文，方便后面更好判断决策做什么。
10. 一定要让 Agent 基于项目补充一个能够让自己验证各种结果的脚本，每次特定的时候需要去跑一下验证效果，完成功能后需要检查，让他输出结果给你看，并基于此逐步沉淀你的项目 Agent 测试功能集。
11. 假如有多个 Agent 同时干活的时候，让他们各自用一份独立的 worktree 代码目录，同时提交的时候只提交自己改的代码，不要碰他人的代码，等到各自改完合到一起，再完整跑一遍测试。
排查
12. 修 Bug 的时候先找到原因再去动手，假如两次都没有修好，就去加一些日志看真实的数据以及运行效果，不要盲目去猜问题在哪儿。
13. 假如尝试修复了3次还不对，直接清空上下文重新写清楚你的问题、诉求，以及尝试过的解法让 Agent 重新开始。
审查
14. 让写代码的 Agent 和 Review 审查代码的 Agent 分开，保持解耦，这样一方不会被另一方带偏。
15. Review 代码的时候最多让 Agent 跑 3轮，防止跑着停不下来，第二轮开始只看新改动的地方，不要再把之前 Review 的再看一遍。
16. 对于你和 Agent 判断危险的改动，越危险让他查得越深，特别对于删除、付费、发布这种单向门改动你都需要自己去看一遍，点一下，看实际效果。
发布
17. 每次提交的时候，让Agent 写清楚做了什么，怎么去验证这个改动，除了问题怎么来回滚，用于给到后面开发过程中 git 记录本身就是 Agent 的一个非常好的上下文。
18. 需要对外的功能，可以先给自己用，或者给一批愿意尝鲜的用户使用，不要一上来就全量，可以在你的软件里面假如 beta 更新的开关，防止全量有问题，也是对用户负责。
18. 先给自己和愿意尝鲜的人用，没问题再发给所有人。
复盘
19. Agent 需要对每一个线上 Bug 和用户反馈的问题都留一个测试案例，每次上线前都来跑一遍，防止继续踩坑，包括你换模型的时候也可以把这些旧问题全部都跑一遍，看看模型是否还行。
20. 修复问题的时候，让 Agent 学会举一反三，把同类的问题一起修复掉。优化功能的功能，完善视觉的时候也是一样，防止只改一个地方，忘记了其他的地方。
0116017
