用了一年AI编程，我发现效率曲线是个倒U型
用了一年AI编程，我发现效率曲线是个倒U型
上周掘金有个帖子炸了——「重度AI编程用户的一天」。评论区直接裂成两半：一边说”AI写代码让我效率翻了10倍”，另一边说”AI写的代码让我加班到凌晨三点擦屁股”。两边都没说谎，只是他们站在效率曲线的不同位置上。
我用AI编程工具写代码已经快两年了。从最早的Copilot补全，到现在每天在Claude Code、Cursor、Codex之间来回切换，踩过的坑比写过的Prompt还多。今天不做工具评测，不搞参数对比——我把自己一整天的真实工作流摊开给你看。
早上9点：脚手架时间，AI的甜蜜区
每天早上我会花半小时做一件事：把当天要做的功能拆成最小可交付单元。不是拆给自己看的，是拆给AI看的。
这一步决定了你一整天的效率天花板。
拆得好，AI就是你的施工队，你画图纸它砌墙，效率确实能翻好几倍。拆得烂，AI就是个热心但没脑子的实习生，噼里啪啦写了500行代码，你还得花两小时搞明白它到底写了些什么。
9:30-11:00是我的黄金生产时段。 这个时间段我主要用Claude Code干一类事：脚手架搭建。新建一个API模块、写CRUD接口、生成数据模型和校验逻辑——这些有明确模式可循的活儿，AI干得又快又好。
举个具体例子：上周我要给后台加一套用户权限管理系统。我在Claude Code里写了一段任务描述——角色定义、权限模型、中间件设计，大概200字。15分钟后，它交出了完整的RBAC骨架：数据模型、路由、中间件、基础测试用例，一共1200多行代码。
如果我自己从零写，这活儿至少要大半天。
但有个前提：你得知道”正确答案”长什么样。 AI擅长的是把你脑子里已经成型的方案翻译成代码。它是一台超级打字机，不是一个架构师。
中午的切换：从生成模式到审查模式
11点之后，效率曲线开始拐弯了。
脚手架搭完，接下来是业务逻辑填充。这时候问题就来了——AI开始”合理地犯错”。它生成的代码看起来对，跑起来也对，但藏着一些只有你理解业务才能发现的地雷。
我有一次让AI写一个订单状态机。它生成的代码逻辑清晰、命名优雅、测试全绿。上线后发现一个问题：它把”已退款”和”已取消”当成了终态，但我们的业务里，已退款的订单还可以重新激活。AI不知道这个业务规则，它按照”常识”做了一个看起来无比正确的错误实现。
这就是AI编程的泥潭区：它犯的错不是语法错误，是语义错误。 而语义错误的debug成本远高于语法错误——因为你得先意识到它错了。
所以从11点开始，我的工作模式从”生成”切换到”审查”。这时候我会打开Cursor，因为它在代码审查场景下有个优势：你可以选中一段代码，直接问”这段逻辑在并发场景下有没有问题”，它会基于上下文给出分析。
我中午的工作流基本是这样的：
- 对着AI生成的代码写测试——不是让AI写测试，是自己写。因为测试本身就是在表达”我期望的行为是什么”，这个思考过程不能外包。
- 跑测试，找到AI的假设偏差——通常每100行AI代码里会有2-3个业务假设错误。
- 手动修正，然后让AI根据修正重新生成相关代码。
这个阶段效率大概是纯手写的1.5倍。注意，不是10倍，是1.5倍。甜蜜区的红利被审查成本吃掉了大半。
下午的债务清理：和AI生成的代码”对账”
下午两点，进入每天最不性感但最有价值的环节——技术债务清理。
AI生成代码有个通病：每次生成都是”从零开始思考”。它不记得上午生成的模块用了什么设计模式，下午再生成一个类似模块时，可能换了一套完全不同的写法。你的代码库里会出现三种风格的错误处理、两套日志格式、四种命名规范。
AI写的代码就像外包团队的交付物——单个模块质量不差，但拼在一起就是一个弗兰肯斯坦。
我每天下午会花一到两个小时做”代码对账”：
- 统一风格：把AI用的不同模式收敛成项目规范。这活儿反过来让AI帮忙——”按照这个模块的风格，重构那个模块”，它干得不错。
- 消除重复：AI特别爱造轮子。明明项目里已经有一个日期处理工具函数了，它偏要重新写一个。我会定期搜索重复代码，合并抽象。
- 补充边界处理：AI对happy path的覆盖堪称完美，但边界case经常缺失。空值、超时、并发竞争——这些得你自己补。
这个阶段我会用Codex跑一些批量重构任务。比如”把所有API响应格式统一成{code, data, message}结构”，这种全局一致性修改是Codex的舒适区。
工具链不是选择题，是排列组合
聊到这里，你可能发现了：我不是只用一个工具，而是在不同阶段用不同工具。这不是因为我喜欢折腾，是因为每个工具确实有自己的舒适区和崩溃区。
我把自己试过的搭配总结成三个段位：
青铜局：单工具走天下。 只用Copilot或只用Cursor，把AI当高级自动补全用。效率提升大概20-30%，但很快会撞上天花板。适合刚入门的同学，先把手感练出来。
白银局：双工具组合。 一个生成（Claude Code / Cursor），一个审查（Cursor的inline chat / CodeRabbit）。生成和审查分开，效率提升50-80%。大部分团队停在这个阶段就够用了。
王者局：全链路AI工作流。 任务拆解用AI辅助（把需求文档喂给Claude拆成子任务），代码生成用Claude Code，局部修改用Cursor，批量重构用Codex，Code Review用AI辅助但人工拍板，测试生成让AI起草但手动补边界case。效率提升可以到200-300%——但前提是你得花两三周打磨这套工作流。
一条被忽略的效率曲线
回头看这一天的时间分布：
- 早上脚手架阶段：AI贡献了大约70%的代码量，你只需要提供方向和框架。
- 中午业务逻辑阶段：AI贡献50%的代码量，但你要花同样多的时间审查和修正。
- 下午债务清理阶段：AI帮你执行重构，但判断”什么该改、往哪个方向改”完全靠你。
这条效率曲线不是很多人以为的一路飙升，而是一个倒U型。 任务复杂度越高，AI的净贡献越低。在脚手架区，AI像个10倍速的队友；在架构区，AI更像个需要全程盯着的新人。
这也是为什么那个掘金帖子的评论区会两极分化——乐观派大概率在脚手架区体验了心流，悲观派大概率在泥潭区挣扎了一整天。
你的新角色：代码的产品经理
说回开头那个争论。AI编程到底让效率提升了多少？我的真实体感是：如果工作流设计得当，综合效率提升大约在80-120%之间。没有10倍，但也绝不是负收益。
不过比效率数字更有意思的是角色转变。
以前写代码，你是施工队——自己搬砖、自己砌墙、自己刷漆。现在有了AI编程工具，你的角色更像一个产品经理：定义需求、拆解任务、审查交付、把控质量。你写的”代码”越来越少，写的Prompt和Review Comment越来越多。
这个转变有人欢喜有人忧。喜欢写代码的纯粹感的人会觉得失去了什么；但如果你享受的是”把事情做成”的感觉——那AI编程工具给了你一个杠杆，让你一个人能撬动以前需要三五个人才能推动的项目。
掘金那个帖子底下有条评论我印象很深：”AI不会替代程序员，但会用AI的程序员会替代不会用的。”这话说了一半。完整版应该是：会用AI且知道什么时候不该用AI的程序员，才是真正拿到杠杆的人。
工具从来不是重点，知道什么时候放下工具才是。