Tw93 是个有 12 年经验的程序员，最近他花了一个下午，把自己用 AI 写代码的习惯整理成了 20 条规则。我看完觉得挺实在的，给大家捋一捋。

先说怎么给 AI 布置任务。别告诉 AI 具体怎么实现，你只说你想要什么结果就行。现在的模型够强，目标可以定高一点。背景要交代清楚：做什么的、给谁用的、什么样算好，技术细节让 AI 自己想。模型挑最好的用，差的来回折腾浪费时间。别让 AI 随便加功能，加之前要跟你确认。想法可以大胆，但要拆成最小步骤一步步做。

然后是跟 AI 配合的规矩。教 AI 听懂你的话，“看一下”是让它读，“改一下”才是让它动手，提交代码和删东西必须经过你同意。配置文件里只写 AI 自己学不到的东西，比如你排除过的方案。重要的规则别光靠提示词，要用脚本卡住，确保检查真的跑过了。

写代码的时候，让 AI 先说清楚它要改什么、会影响到哪里，你点头了再让它动手。给项目建一个验证脚本，每次写完都跑一遍看结果，时间长了就变成你的测试套件。多个 AI 同时干活的话，各管各的目录，只提交自己的改动，合并之后再跑一次完整测试。

调试方面，先找到原因再动手修。修了两次没好就加日志去看，别猜。连修三次都不行，就清掉上下文重新来，把问题、目标、之前试过的方法都告诉 AI，从头开始。

审查代码的时候，写代码和查代码要分开，别让同一个 AI 自己查自己。审查最多三轮，从第二轮开始只看新改的就行。越有风险的改动查得越细，涉及删除数据、支付这类功能的，你得亲自上手点一遍真实页面。

上线发布的时候，每一次提交都写清楚改了什么、怎么验证的、出了问题怎么回滚。这些 git 记录就是下一次 AI 工作的好素材。先自己用或者给少数测试用户试试，加个灰度机制，别一下推给所有人。

最后是复盘。线上出的每一个 bug、用户反馈的每一个问题，都写成测试用例，每次发版前跑一遍。换模型的时候也跑一次，看新模型扛不扛得住。修一个问题的时候，让 AI 全项目搜一遍有没有同样的毛病，一起修掉。

评论区一个干了 15 年的工程师说，他以前总替 AI 操心，觉得这个它做不了、那个它会搞砸，后来换了个方式，什么都不管直接提要求，反而效果好了很多。Tw93 回复他说自己也一样，从写代码的思维转成了做产品的思维。

#科技先锋官##How I AI#