1. 代码产出量为什么是个伪指标
1.1 从一次团队复盘说起
去年年底我们做了一次内部复盘，统计了团队引入 AI 编程工具之后三个月的代码提交量。数据很漂亮：整体代码行数涨了大概四成，单个需求的平均交付周期从五天压到了三天半。会议室里有人已经开始鼓掌了，但我心里清楚，这个数字经不起推敲。
因为同一时间，我们的代码评审时长涨了将近一倍，线上回滚次数从每月两次变成了五次。换句话说，代码是写得更快了，但把代码真正变成可用的、稳定的功能，这个环节反而变慢了。这就是我后来一直跟团队强调的观点：AI 编程有没有提效，不能只看生成了多少代码。代码行数是一个极其容易注水的指标，AI 恰恰是最擅长注水的工具。
这篇文章我想聊的不是某个具体工具怎么用，而是怎么建立一套真正能衡量 AI 编程价值的判断框架。适合已经在团队里推 AI 编程、或者自己深度使用 AI 辅助编码但感觉"好像快了又好像没快"的人。如果你还在纠结要不要用 AI 写代码，那这篇可能对你来说有点超前，但看完你会少走很多弯路。
1.2 代码行数这个指标是怎么失效的
在没有 AI 的时代，代码行数就已经是个烂指标了，只不过那时候它烂得比较慢。一个熟练工程师一天写两百行有效代码，一个新手可能写五百行但一半是重复逻辑。大家心里都有数，行数只能当参考。
AI 进来之后，这个指标彻底崩了。原因很简单：AI 生成代码的边际成本几乎为零。你让它写一个工具类，它一口气给你生成三百行，里面可能有两百行是你根本用不上的防御性代码、过度封装的抽象层、还有一堆"以防万一"的边界处理。这些代码不是错的，但它们增加了阅读负担、增加了维护面积、增加了潜在的 bug 面。
我做过一个粗略的统计，在我们团队引入 AI 的前两个月里，AI 生成的代码中真正被保留到最终合并版本的，大概只有百分之五十五左右。也就是说，将近一半的生成内容是废稿。如果你只看"生成了多少"，你会觉得效率翻倍；但如果你看"最终有效产出"，提升可能只有百分之二三十。
提示：判断 AI 提效时，一定要区分"生成量"和"采纳量"。生成量是 AI 的产出，采纳量才是你的真实收益。两者之间的差距，就是你需要优化的空间。
1.3 真正该盯住的几个信号
那不看代码量看什么？我总结了几个在我们团队实际用下来比较靠谱的信号，它们不一定适用于所有场景，但方向是对的。
第一个是从需求到可运行的时间。注意不是从需求到代码写完，而是到"能跑起来、能点、能验证"的时间。AI 最大的价值往往不在写业务逻辑，而在于帮你快速搭起一个能跑的骨架，让你能尽早验证想法。
第二个是返工率。AI 生成的代码有多少需要你回头大改？这个比例如果很高，说明你的提示方式或者任务拆分方式有问题，提效是假的。
第三个是认知负荷。这个比较主观，但很重要。用 AI 之后，你是觉得脑子更轻松了，还是更累了？如果每天要花大量精力去审查 AI 生成的代码、去理解它为什么这么写，那这种"提效"是在透支你的注意力。
第四个是调试时间占比。AI 生成的代码往往有一个特点：看起来对，跑起来错，而且错得很隐蔽。如果调试时间不降反升，那说明 AI 帮你省下的打字时间，又被调试吃回去了。
2. Agent 和 Harness：两个被混用的概念
2.1 Agent 到底在做什么
要理解 AI 编程的真实效率，得先搞清楚现在这些工具是怎么工作的。市面上大部分所谓的 AI 编程工具，底层都是一个 Agent 架构。Agent 这个词现在被用得很泛，但它的核心其实就三件事：感知当前状态、决定下一步动作、执行动作并观察结果。
放到编程场景里，Agent 感知的是你的代码库、报错信息、终端输出；它决定的是"我该读哪个文件""我该改哪一行""我该跑什么命令"；它执行的是文件读写、命令调用、搜索等操作。一个完整的编程 Agent，本质上是在一个循环里不断重复这三步，直到任务完成或者它自己判断搞不定了。
这里有个关键点很多人忽略：Agent 的能力上限，很大程度上不取决于模型本身，而取决于它能看到什么、能操作什么。一个只能读当前文件的 Agent，和一个能读整个仓库、能跑测试、能看日志的 Agent，完全是两个物种。这就是为什么同样是接一个大模型，不同的工具效果差那么多。
2.2 Harness 是 Agent 的"外骨骼"
Harness 这个词最近在圈子里出现得越来越多，但很多人把它和 Agent 混着用。我的理解是：Agent 是决策核心，Harness 是让这个决策核心能真正干活的整套支撑系统。
打个比方，Agent 是驾驶员，Harness 是车。驾驶员再厉害，给他一辆方向盘失灵、刹车不灵的车，他也开不好。Harness 包含的东西很杂：工具调用的接口定义、上下文的管理和裁剪、权限控制、错误重试机制、状态持久化、和外部系统的对接等等。
为什么这个概念重要？因为当你觉得"AI 编程不好用"的时候，问题往往不在模型，而在 Harness。模型可能已经足够聪明了，但 Harness 没给它提供足够的上下文，或者工具调用老是失败，或者上下文窗口管理得一塌糊涂，导致它干到一半就忘了前面在干嘛。
我见过太多团队，花大价钱换更强的模型，效果提升却很有限。后来发现问题出在 Harness 层：他们的工具调用经常超时，上下文裁剪策略很粗暴，Agent 跑到第五步就丢失了最初的目标。把 Harness 修好之后，用同样的模型，效果立竿见影。
2.3 为什么这个区分对衡量提效很关键
搞清楚 Agent 和 Harness 的区别，直接影响到你怎么定位效率瓶颈。
如果你的瓶颈在 Agent 层，那可能是任务拆分不合理、提示词写得不好、或者模型选型不对。这些是"怎么用"的问题。
如果你的瓶颈在 Harness 层，那可能是工具集成不完善、上下文管理有缺陷、权限配置太紧或太松。这些是"基础设施"的问题，换模型解决不了。
我自己的经验是，大部分团队在 Harness 层的欠账，远多于在 Agent 层的欠账。大家热衷于研究提示词技巧、研究哪个模型更强，却很少有人认真去搭一套靠谱的 Harness。结果就是模型能力被浪费，然后得出"AI 编程也就那样"的结论。
3. Token 消耗与真实成本的核算
3.1 Token 用量不等于价值产出
现在用 AI 编程，绕不开 Token 这个计量单位。很多工具会显示你消耗了多少 Token，有些还按 Token 计费。于是很自然地，有人开始用 Token 消耗量来衡量"用了多少 AI"。
这个逻辑和用代码行数衡量效率一样有问题。Token 消耗高，可能是任务复杂，也可能是 Harness 在疯狂浪费上下文。我见过一个极端案例：一个简单的改字段名的任务，因为 Harness 每次都把整个仓库的文件列表塞进上下文，硬生生消耗了几万 Token。这不是 AI 在干活，这是 Harness 在烧钱。
真正该关注的是单位有效产出的 Token 成本。同样是完成一个功能，A 方案花了五万 Token，B 方案花了两万，那 B 方案在成本效率上就是更优的。但这个比较要建立在任务难度相当、产出质量相当的前提下，否则没有意义。
3.2 上下文管理才是省钱的关键
Token 消耗的大头永远是上下文。模型每回答一次，都要把之前的对话历史、读过的文件内容、工具调用结果重新过一遍。上下文越长，单次调用的成本越高，而且模型注意力被稀释，效果还会下降。
所以一个成熟的 Harness，核心能力之一就是上下文管理。什么时候该把旧内容压缩成摘要，什么时候该丢弃无关信息，什么时候该重新检索相关文件，这些策略直接决定了 Token 效率。
我自己的做法是给不同类型的任务设定不同的上下文策略。比如改 bug 这种局部任务，只保留相关文件和最近的报错信息；做架构调整这种全局任务，才需要加载更大范围的上下文。一刀切地把所有东西都塞进去，是最偷懒也最费钱的做法。
3.3 一个粗略的成本核算框架
如果你想认真算一算 AI 编程到底划不划算，我建议用这个框架：
| 成本项 | 说明 | 容易被忽略的点 |
|---|---|---|
| Token 费用 | 直接调用成本 | 上下文浪费导致的隐性翻倍 |
| 审查时间 | 人工检查 AI 代码 | 往往比写代码本身还耗时 |
| 调试时间 | 修复 AI 引入的问题 | 隐蔽 bug 排查成本极高 |
| 返工成本 | 推翻重写的部分 | 前期看不出来，后期集中爆发 |
| 学习成本 | 团队适应新工具 | 通常被严重低估 |
把这几项加起来，再和你省下的打字时间对比，才是真实的账。我算过我们团队的情况，如果只算 Token 费用，AI 编程确实便宜；但把审查和调试时间折算进去，净收益大概在百分之二十到三十之间，远没有宣传的那么夸张。
注意：不要被"AI 帮我省了一半时间"这种说法忽悠。省下的时间如果又被审查和调试吃回去，那等于没省。真实的提效，是端到端交付周期的缩短，不是某个环节的加速。
4. 多 AI 协作场景下的效率陷阱
4.1 协作听起来很美，实际很乱
现在流行一个说法叫"多 AI 协作"，让几个 Agent 分工干活，一个写代码、一个审查、一个测试。听起来很美好，像是组建了一个 AI 团队。但实际用下来，坑非常多。
最大的问题是状态同步。两个 Agent 如果各自维护一份对代码库的理解，很容易出现冲突。A 改了文件，B 不知道，还在基于旧版本干活，最后合并的时候一团糟。这和多人协作的 Git 冲突是一个道理，但 AI 不会像人一样主动沟通，冲突往往到很晚才暴露。
第二个问题是责任边界模糊。当多个 Agent 参与同一个任务，出了问题很难定位是谁的锅。是写代码的 Agent 理解错了需求，还是审查的 Agent 漏掉了问题，还是测试的 Agent 用例设计得不对？排查成本很高。
4.2 什么情况下多 Agent 才真的有用
不是说多 Agent 协作没价值，而是要用对场景。我总结下来，以下几种情况多 Agent 是划算的：
- 任务可以清晰切分且互不依赖：比如同时给五个独立的模块写单元测试，各写各的，最后汇总。
- 需要不同视角交叉验证：一个 Agent 写实现，另一个专门找边界条件和反例，这种对抗式协作确实能提高质量。
- 任务规模大到单个 Agent 的上下文装不下：这时候分而治之是必要的，但要有一个协调层来管理状态。
反过来，如果一个任务本身是高度耦合的、需要频繁来回修改的，那多 Agent 只会增加混乱。这种时候老老实实用一个 Agent 从头做到尾，反而更稳。
4.3 协作的隐性成本
多 Agent 协作还有一个隐性成本：协调开销。你需要设计它们之间怎么传递信息、怎么处理冲突、怎么汇总结果。这套协调机制本身就是一套系统，需要开发和维护。
我见过一个团队，为了做多 Agent 协作，专门写了一套消息队列和状态管理，结果这套基础设施的复杂度，比他们原本要解决的问题还高。这就是典型的为了协作而协作，本末倒置了。
我的建议是：先用单 Agent 把流程跑通，确认瓶颈确实在"单个 Agent 忙不过来"上，再考虑多 Agent。大部分场景下，单 Agent 配合好的 Harness，已经足够应付了。
5. 建立自己的 AI 编程提效评估方法
5.1 从记录开始，别凭感觉
说了这么多，最后落到实操上。想搞清楚 AI 到底有没有帮你提效，第一步是记录。别凭感觉，感觉是最不靠谱的。
我自己的做法是维护一个简单的表格，每完成一个任务就记几笔：任务类型、用了什么工具、大概花了多少时间、AI 生成的代码有多少被采纳、有没有返工、返工的原因是什么。坚持记一个月，你就能看出规律。
比如你可能会发现，AI 在写样板代码、写测试、写文档这类任务上提效明显，但在涉及复杂业务逻辑、需要深度理解现有代码的任务上，反而拖后腿。有了这个认知，你就能有针对性地分配任务，把 AI 用在刀刃上。
5.2 分任务类型看提效
不同类型的任务，AI 的提效差异极大。我大致分了几类：
| 任务类型 | AI 提效程度 | 主要原因 |
|---|---|---|
| 样板代码生成 | 高 | 模式固定，AI 擅长 |
| 单元测试编写 | 高 | 有明确输入输出，易验证 |
| 文档和注释 | 高 | 语言任务，AI 强项 |
| 局部 bug 修复 | 中 | 依赖上下文理解，时好时坏 |
| 新功能开发 | 中低 | 需求理解容易偏差 |
| 架构重构 | 低 | 需要全局视野和权衡 |
| 性能调优 | 低 | 依赖实测数据，AI 猜不准 |
这张表不是绝对的，但方向大致如此。把 AI 用在它擅长的地方，比指望它什么都能干要现实得多。
5.3 团队层面的推广经验
如果你是要在团队里推 AI 编程，我分享几条踩过坑之后的经验。
第一，别一上来就全员铺开。先找两三个愿意折腾的人试点，把流程和工具链跑顺，形成可复制的经验，再推广。一上来全员上，出了问题没人能兜底。
第二，建立代码审查的额外规范。AI 生成的代码有一些典型问题，比如过度防御、隐藏的副作用、不一致的风格。审查的时候要特别留意这些点，最好整理成一份检查清单。
第三，别用代码量考核。这一条我在开头就说了，但还是要再强调一遍。一旦你用代码量考核，大家就会用 AI 疯狂生成代码来凑数，质量必然崩盘。考核要看交付的功能、看线上稳定性、看返工率。
第四，给团队留出学习时间。AI 编程不是装个插件就完事，怎么提问、怎么拆任务、怎么审查，都是需要练的。指望大家无师自通，不现实。
5.4 我个人的几条心得
最后分享几条我自己用下来觉得最有用的心得。
把 AI 当成一个需要明确指令的实习生，而不是一个懂你的老搭档。你给它的信息越具体、边界越清晰，它的产出越靠谱。含糊的需求，它只会给你含糊的结果。
重要的不是它生成了什么，而是你采纳了什么。每次 AI 生成一堆代码，先别急着用，花点时间判断哪些是真需要的，哪些是噪音。这个筛选能力，是 AI 时代程序员的核心竞争力之一。
定期回顾你的 AI 使用方式。工具在变，模型在变，你的用法也应该变。我每隔一两个月就会重新审视一下自己的流程，看看有没有可以优化的地方。很多时候，提效的空间不在工具本身，而在你怎么用它。
别追求全自动。现在很多人幻想 AI 能全自动完成开发，你只需要提需求。这个方向也许有一天会实现，但现在还差得远。把 AI 当成一个强力助手，而不是一个替代者，你的心态会稳很多，效果也会好很多。
真正衡量 AI 编程价值的，从来不是它生成了多少行代码，而是它有没有让你更快地把想法变成可用的东西，同时没有把维护成本推高。这个标准听起来朴素，但能守住它的人不多。
