我用了三年 AI 辅助写代码，方式换了三次：最早是编辑器里的补全，后来是开着对话框一问一答，现在是让 Agent 直接改文件、跑命令、看结果。位置一直在变，但有一条经验越来越确定——AI 负责把「从 0 到 0.8」的时间压到几分钟，我负责判断这 0.8 是不是我们要的东西。
一、我的固定流程
接到一个需求，比如「给后台加一个导出 CSV 的接口」，我现在的顺序是：
- 先自己写三行规格：哪个接口、什么参数、返回什么、边界是什么（空数据怎么办、几万行怎么办、字段里带逗号怎么办）。这三行不交给 AI——它不知道我们的业务约束。
- 把规格 + 相关文件丢给 AI，让它先给方案（不写代码）：改哪几个文件、加哪几个函数、有没有更简单的做法。
- 挑一个方案，让它按小步实现：一次只改一处，改完告诉我改了什么、怎么验证。
- 我自己跑：本地起服务、打一次真实请求、看日志和返回。没跑过的代码我不合并。
- 让它写测试或补文档，我读一遍再收。
这套流程跑下来，一个普通接口从「打开编辑器」到「提交」大概十分钟，其中我真正写代码的时间可能只有两分钟。
二、它最值钱的两个时刻
第一，读陌生代码。 接手别人的项目，我会让 AI 先解释「这个请求从入口到落库经过了哪些函数」，再让它列「改这个字段会影响哪些地方」。它偶尔会说错，但比我自己顺着目录翻要快一个数量级，而且错的地方往往能被我一眼看出来。
第二，写一次性的东西。 正则、awk、一次性数据清洗脚本、CI 里那段只有三行的 yaml——这类东西的特点是「写完就不看了」，AI 的产出质量足够，省下的是我翻文档的时间。
三、我绝不让它碰的四件事
- 数据库迁移与删除类操作：任何 DROP、DELETE、ALTER 我都自己写、先在从库验证；
- 密钥与账号相关代码：让它写「读取环境变量」可以，让它决定密钥怎么存、往哪写不行；
- 架构决策：它会给我三个都挺合理的方案，但选哪个取决于团队、历史包袱和未来半年的方向，这些它不知道；
- 没验证过的配置：nginx、supervisor、systemd 这类「写错就起不来」的配置，它给的是草稿，我必须逐行对照文档。
四、三个具体的坑
- 它会自信地编 API。 有次它给我一个库的函数签名，我直接用了，编译不过——那个参数在新版本里才存在。现在我的习惯是：凡是它给的第三方 API，先点开文档确认一眼。
- 它会顺着我的错误思路往下写。 我说「用 Redis 缓存这个列表」，它会认真帮我实现，而不是问「这个列表一分钟变几次，需要缓存吗」。所以现在我习惯加一句：「如果我的思路有问题，先反驳我」。
- 上下文一长就开始忘。 一个任务聊了太久，它会忘记前面定的约束。对策是把约束写成一段固定的「规格」放在每次对话开头，或者干脆开新对话，把规格和当前代码重新贴一遍。
五、给刚开始用的人的建议
- 从「让它解释代码」开始，比「让它写代码」安全得多，收益也很直接；
- 提需求时把验收标准一起说，比如「改完这个接口应该能用 curl 拿到 200 和一段 CSV」——有验收标准，它的产出质量会明显不一样；
- 保留自己的判断权：它产出的是候选答案，不是结论。
一句话总结：AI 让我写代码更快了，但没有让我少想问题——它把「想清楚」这件事的重要性反而放大了。