我用 AI 提效了多少：真有用的和纯自嗨的

关于 AI 编程，两种说法都很流行：

“效率提升好几倍，程序员要失业了。” “生成的全是错的，根本不能用。”

两种都不太准确。真实的体感是：提效非常不均匀。 有些活快到我愿意一直用，有些活它帮了倒忙，还有一类活交给它等于给自己挖坑。

这篇不讲工具对比，只讲怎么分这三类。

一个判断标准，能筛掉大部分错配

在决定要不要把一件事交给 AI 之前，问两个问题：

1. 能不能用一句话说清验收条件？
2. 它做错了，我能不能立刻发现？

两个都是“能”，交给它。有一个“不能”，别交。

这个标准解释了很多现象。比如“写一个把 CSV 里 A 列按 B 列分组求和的脚本”—— 验收条件一句话，跑一次就知道对不对，属于典型的该交。

而“帮我设计这个模块的边界” —— 说不清验收条件，错了也不会立刻发现，属于典型的别交。

真有用的三类

1. 知道要什么、但懒得写的代码

正则、日期格式转换、SQL 拼接、一次性脚本、格式转换。这类活的特点是：你完全清楚正确结果长什么样，只是不想一个字一个字敲。

这类收益是最实在的。以前写一个数据清洗脚本要二十分钟，现在五分钟。省下的不是“能力”，是纯粹的机械时间。

2. 样板代码

增删改查、配置骨架、接口定义、测试用例的分支铺陈。这类代码的规律性极强，写完也不含判断 —— 它的价值不在写得漂亮，在于别写错。

这一类的收益还体现在心理上：样板代码最消耗耐心，交给它之后，人的注意力能留在真正需要思考的地方。

3. 解释报错和不熟的东西

贴一段看不懂的报错、一个陌生的配置项、一段别人写的代码，让它先讲一遍。

这里要加一句限制：它的解释是“起点”，不是“结论”。 它的作用是让你知道该往哪查、该搜什么关键词，而不是替代你去确认。真正要改的东西，仍然要回到文档和源码。

鸡肋的三类

1. 需要理解你项目隐性约束的活

每个项目都有一堆没写进文档的约定：这个字段为什么不能改、那个接口为什么必须传某个参数、这段逻辑为什么绕了一圈。

它看不到这些约束，所以会给你一个“在你描述的需求上正确，但在你的项目里不能用”的答案。改它的产出，有时比自己写还慢。

2. 跨文件的大改动

改动越分散、涉及的文件越多，它的产出越难验证 —— 而验证成本正是这类任务的主要成本。你花在检查“它是不是顺手改坏了别的地方”上的时间，往往超过自己动手。

3. 需要权衡的决策

选型、拆分粒度、要不要引入某个依赖、这块逻辑该放哪一层。

它会给建议，而且看起来都有道理 —— 但它不知道你的团队规模、上线时间、以后的维护方式。决策的质量取决于约束条件，而约束条件在你脑子里，不在提示词里。

有害的三类（这一类要格外小心）

1. 不看就合并

最危险的一种。产出的代码看起来结构完整、命名规范、注释齐全 —— “看起来对”正是它最难防的地方。 你自己写错的地方通常一眼能看出来，但别人的代码读起来是顺的，顺就容易过。

处理方式：把它当成一个“打字很快但不了解项目的新人”的产出。新人交的东西要看，它交的东西同样要看。

我自己踩过一个很典型的：让它给一个后台加一个“批量导出”的接口。产出跑得通、命名规范、注释齐全，我读了一遍觉得没问题就上了。

问题出在验收方式上 —— 我用管理员账号测的，一切正常。上线几天后才发现：这个接口只在前端按角色隐藏了入口，服务端本身没有做权限校验。换一个低权限账号直接调接口，能导出全部数据。

代码没错，逻辑也没错，它只是“按我说的做了” —— 而我没说过权限。这类坑的共同特征是：不报错、测试也通过，问题只在你没想到要问的那一点上。

2. 靠它生成业务规则

这一条比代码错误更隐蔽。

业务规则（什么情况打折、什么情况不允许取消、状态怎么流转）如果你自己没想清楚，它会给你一个看起来很合理的版本 —— 格式规范、逻辑通顺，然后你把它接进系统，错了也不会报错，只是按错的规则跑了半年。

比起代码报错，这种错误的发现成本高一个数量级。业务规则不该由它来定，只能由你从业务里问出来，再让它照着实现。

3. 让它“顺手”做额外的改动

不在任务范围内的重构、格式化、依赖升级，看起来是免费的 —— 但它会把一次小改动变成一次需要完整回归的改动，而且真正改了什么，你未必看得全。

划清范围：这一轮的产出只允许包含任务描述里的改动。

我现在的实际用法

一句话概括：把它当一个打字极快、但不了解你项目、也不承担后果的同事。

具体到工作方式：

• 把任务切小到“能一句话验收”的粒度再交出去；产出必须自己读一遍，重点是范围外的东西有没有被动过
• 当前行补全留给编辑器自带的 AI 补全 —— 人还在掌控里，它只负责少敲几个字
• 样板代码、一次性脚本（正则、格式转换、SQL 拼接、数据清洗）交给对话式模型，写完看一眼就行
• 跨文件改动、技术方案调研交给终端里的编码代理 —— 它能读整个仓库、能跑命令、能自己验证结果
• 决策、业务规则、涉及生产环境的改动留给自己，不交给任何工具

工具名字半年就会换一轮，不必纠结选哪个 —— 真正决定收益的是这条划分线，不是型号。

怎么判断一段产出能不能进仓库，我现在走四步，比“读一遍”更省事也更快：

1. 看 diff，不看它的自我描述 —— 它说“我已经处理了边界情况”没用，看它实际改了哪几行、有没有碰任务范围外的文件
2. 跑一遍它没跑的东西 —— 它测试通过的那条路径，往往是你写的那条；换个输入、换个账号、换个权限再点一遍
3. 对一遍项目里那些“没写进文档的约定” —— 它看不到的隐性约束（哪个字段不能改、哪个接口必须带某参数），逐条核
4. 合入前想一次“这个功能在低权限 / 异常数据下会怎样” —— 上面那个没做权限校验的坑，就是在第四步被问出来的

这四步不追求快，追求的是别把范围外的问题带进生产。前两步防“写错了”，后两步防“它对、但在我项目里不能这么用”。

还有一条不太像规则，但更重要：它给的结论当作“线索”，验证仍然自己做。

一个反直觉的观察：用得越久，交给它的任务反而越小。 一开始想让它做整块功能，后来发现最划算的是那些“我知道答案、只是懒得敲”的部分。这不是它变差了，是你摸清它的边界了。

小结

AI 编程的提效不是一条平均线，是分层的：

• 机械的、可验证的活 → 明显提效，值得多用
• 需要项目上下文和权衡的活 → 鸡肋，省下的时间会被验证成本吃掉
• 决策、业务规则、不看就合并 → 负收益，要主动挡住

所以真正值得花时间的不是“换哪个工具”，而是每次动手前先判一下这是哪一类活。