用 AI 写代码：哪些能交给它，哪些必须自己把关
AI 辅助编程用久了会形成一种直觉：哪些活交给它省心，哪些活交给它会埋雷。我把自己的经验整理成下面这张"分工表"。
可以放心交给它的三类
- 样板代码：增删改查、表单校验、配置文件、单元测试骨架。这类代码结构固定、出错容易发现，交给它写能省下大量打字时间。
- 不熟的语言／库的一小段示例：比如"用 Python 的 requests 怎么设超时重试"，它给的片段通常比翻文档快，但记得自己验证一遍。
- 解释与翻译：看不懂的报错、别人写的一段逻辑、把 A 框架写法改成 B 框架。解释类任务是它的强项。
必须自己把关的三类
- 业务规则：涉及金额计算、权限判断、审批流的东西，它不知道你们公司的规矩，写出来的往往是"看起来合理的通用做法"，恰恰是最危险的。
- 性能与并发：它容易写出能跑但跑不快的代码，比如循环里查数据库、忘了加索引。这类问题在小数据量下完全看不出来。
- 安全相关：拼接 SQL、跳过校验、暴露敏感字段——AI 生成的代码安全性取决于训练数据里的平均水平，而平均水平并不高。
几条实用的工作方式
- 先让它讲思路，再让它写代码。思路错了，代码再漂亮也是白搭，而且思路阶段纠偏的成本低得多。
- 把报错原文整段贴给它，不要自己转述。转述会丢掉关键信息，而报错堆栈本身信息量很足。
- 一次只改一处。让它同时改三个地方，出问题时你分不清是哪一处引入的。
- 生成的代码一律自己读一遍。不是为了检查语法（语法它很少错），而是检查"它是不是理解错了我的意思"。
一个真实教训
有次我让它给一个接口加缓存，它写出来的逻辑在缓存失效时会导致所有请求同时打到数据库。代码本身没有语法错误、单测也过，直到压测才暴露。从那以后我给自己定了条规矩：凡是涉及"多个请求同时发生"的代码，一律自己写。
小结
把 AI 当成一个打字飞快、但对你业务一无所知的初级工程师——这个定位最准确。样板活尽管派给它，判断活留给自己，代码始终要过自己的眼睛。