ARTICLE · 1157105
AI 提效剪刀差:当执行越来越快,软件工程真的更高效了吗?
Coding Agent 已经不满足于补全几行代码。它能够阅读代码库、制定计划、调用工具、创建 Subagent、运行测试，甚至在没有人持续盯守的情况下推进一整条任务链。Personal Agent 则试图把同一套能力延伸到邮件、日程、文档和跨系统协作，成为持续存在的执行主体。
一个自然的预期是：机器承担越多工作，人就越轻松，系统就越高效。
但这里有一个容易被忽视的变量：生成结果的成本下降，不代表判断结果是否值得采用的成本也同比下降。当执行吞吐量迅速增加，而验证、协调与治理能力没有同步扩张，自动化可能创造新的瓶颈。这并不是对 AI 能力的否定，而是对“提效”这一概念的重新审视。
01｜软件工程的进步，不能只用完成任务的速度衡量
AI 确实产生了可观的局部生产率收益。2025 年一项覆盖 4,867 名开发者、来自三家企业的随机对照研究发现，获得 AI 代码补全工具的开发者，完成任务数量平均提高约 26.08% [1]。但在另一项针对成熟开源代码库的实验中，METR 观察到：16 名熟悉项目的开发者使用 2025 年初的 AI 工具后，实际完成任务的时间反而增加约 19%，尽管参与者主观上认为自己更快了 [2]。
看似矛盾的两组结果，并不需要二选一。它们研究的工具、样本、任务与衡量口径不同；尤其不能拿早期工具的表现推断今天全部 Agent 的效率。METR 在 2026 年的更新中也指出，新工具可能已带来更多加速，但后续实验受到样本选择偏差影响，尚不能可靠估计幅度 [3]。
真正重要的是区分四种容易被混为一谈的指标：代码生成速度、任务完成效率、系统交付能力，以及长期工程价值。前两者的提升，不会自动传导至后两者。
例如，Agent 可以迅速完成一项数据权限改造：增加关联表、拼接过滤条件、补齐接口与单元测试。就当前需求而言，它可能交付得非常完整。但若数据库包含大量历史数据、不同表缺少统一归属字段、查询路径高度复杂，原本“最容易实现”的方案，也可能成为未来的性能瓶颈。
问题不在于 AI 不会写正确代码，而在于：把一个方案正确实现，与证明这个方案值得实现，是两种不同的能力。人类工程师也会犯同样的错误；AI 带来的新风险，是让局部看似合理的设计以更高速度被复制、固化和扩散。
02｜从局部最优到全局最优：Harness 解决了什么，又遗漏了什么？
Harness Engineering 的价值是真实的。上下文文件、工具边界、执行规则、测试反馈、检查点与 Subagent 分工，可以显著改善 Agent 的执行纪律，使复杂任务具备更好的可重复性和可追踪性。
但一个执行系统越可靠，并不意味着它的目标函数越合理。
如果 Harness 以“任务通过测试、符合需求、完成提交”为主要终点，那么它就会倾向于优化这些可观察指标。重复写一段新逻辑，往往比梳理旧模块的设计意图更容易；新增一个适配层，往往比统一底层抽象更快；让测试变绿，也不等于理解了生产环境中的边界条件。
这可以概括为两种优化问题：
任务级优化：在给定要求下，以尽可能低的成本完成眼前交付。
系统级优化：在性能、可靠性、合规、可演进性等约束下，降低全生命周期总成本。
两者既可能一致，也可能冲突。某个方案短期代码量最少，长期却增加耦合；某次“快速修复”通过全部现有测试，却让未来每次变更都必须理解更多额外抽象。
当然，“最佳实现”并不是一个客观且永久不变的答案。需求会变化，业务权衡会变化，今天多做一次抽象也未必比明天局部修改更划算。真正需要 Agent 学会的不是永远追求最复杂的架构，而是识别当前方案依赖了哪些假设、还存在哪些可行替代方案、未来可能在哪些条件下失效。
即便模型的上下文窗口足够容纳整个代码库，它也不会自动获得代码之外的业务意图、组织约束和风险偏好。上下文容量解决的是“能看到多少”，不直接解决“应该优化什么”。
03｜提效剪刀差：机器产出扩张，人类验证成为稀缺资源
Agentic AI 正在改变知识劳动的分工：机器负责快速生成大量候选成果，人负责判断哪些成果可以安全地进入真实系统。
当生成能力加速、审阅能力增长缓慢时，产出与验证之间就会出现一条“提效剪刀差”。这也解释了为什么管理仪表盘上显示任务越来越快，但项目内部可能同时积累更多待审阅 PR、跨模块冲突和设计争议。
不妨看一个纯粹的示意：假设某团队每天能严肃审查并合入 5 项复杂变更。引入多 Agent 后，候选变更从每天 6 项增长到 18 项，而审查能力仍是 5 项。此时，新增候选并不意味着已验证交付同步增长；若不控制在制品数量，待审阅队列反而会扩大，等待时间也会增加。这里的数字是机制演示，不是任何团队的实测数据。
更微妙的是，审阅并不是生成的镜像工作。检查“程序是否运行”通常比较容易；判断“设计是否值得长期维护”“测试遗漏了什么”“修改是否改变了隐含业务规则”，则需要恢复上下文、反事实推理与跨系统判断。
因此，AI 节省的执行时间，可能重新流向四类成本：审阅、返工、协调，以及未来维护。2026 年 DORA 关于 AI 使用张力的分析也指出，创建阶段节省的时间往往转移到审计与验证，AI 使用增加与交付吞吐量提升相关联，同时也可能伴随更高的交付不稳定性 [4]。
这不是说验证一定比生成更昂贵。对于具有形式化规格、强测试预言机、明确边界的任务，自动验证可以非常便宜。真正棘手的是开放式设计问题：需求不完备，测试覆盖不了所有场景，失败后果又可能跨越多个系统。
如果组织只计算“机器完成了多少”，却忽略“最终有多少结果无需额外人工补救便可安全使用”，提效就容易退化为将执行成本转嫁为验证负担。
04｜系统的“熵增”：问题不是代码多，而是理解系统越来越贵
这里所说的“熵”，是对工程复杂性及治理负担的比喻，不是可以直接套用热力学公式的物理量。它至少有三种表现。
第一种是结构负担：重复代码、临时适配层、跨模块不一致、隐式耦合不断累积。GitClear 对 2023—2026 年代码变更的观察发现，重复代码块等维护风险信号上升；其中一项重复指标相对 2023 年增长约 81% [5]。但这属于观察性证据，不能将整个趋势直接归因为 AI，也不能仅凭重复率就判断系统质量。
第二种是认知负担：代码可以被快速创建，设计理由却散落在对话、提示词、Agent 日志和 PR 评论中。下一次修改时，维护者可能看到完整实现，却难以恢复当初的取舍逻辑。
第三种是治理负担：跨 Agent 的任务交接、临时授权、工具访问、审批例外与审计记录不断增加。每增加一个独立执行主体，就多了一份状态同步、权限撤销与责任归属的工作。
一个 Harness 可以要求代码符合规范，也可以用自动测试拦截部分缺陷；但若主要优化目标仍是“尽快关闭任务”，它就可能稳定地产生一种难以长期维护的局部解。自动化并不会天然制造技术债，它只是可能放大既有评价体系对短期结果的偏好。
因此，下一代 Harness 的关键不只是更会编排 Agent，而是能否建立一套独立于生成过程的评价机制：比较候选方案、检查架构约束、追踪代码复用、记录设计理由，并在真实使用反馈中更新判断。
AI成本可能不是减少，而是转移了
我建议把 Agent 的实际净收益定义为：
这里先用时间等价成本表示，实际研究中还应计入运行费用与风险损失。
我们以前主要计算 \(T_{\text{saved}}\)，也就是减少了多少写代码、写文档、整理资料的时间。
但对你这样的 PM 而言，剩余四项可能逐渐占据大量精力。
特别是一个不直观的问题：AI 帮你生成一个复杂方案，可能只需要几分钟；但你要判断这个方案是否真正合理，可能需要几小时。
因为验证不是重新读一遍答案。
真正的架构审阅必须检查隐含假设、比较替代方案、考虑异常与边界，并对未来可能发生的情况进行推断。
这比验证一道数学题或检查一个简单函数困难得多。
05｜自主权的悖论：为什么更多审批，未必意味着更多控制？
问题在 Personal Agent 身上更加突出。传统 Coding Agent 多围绕一个代码库或任务运行；长期存在的 Agent 还可能管理邮件、日程、文档、云端资源乃至跨组织流程。它的状态、目标和权限将跨越多次任务，授权不再是一个短暂的确认窗口。
最直观的治理办法是提高审批频率：读文件要问，运行命令要问，修改文件也要问。但逐步审批会打断执行链，人也容易在大量低风险确认中形成“机械点击同意”的习惯。另一端的极端是全面自动放行，连续性确实改善，却使错误决策有机会沿调用链持续扩散。
矛盾的根源，在于以工具动作作为审批单位，却以业务后果作为风险单位。
执行一条命令本身未必危险；真正需要评估的是它会接触什么数据、改变哪些外部状态、影响多大范围、能否可靠回滚。反过来，“只读”并不天然低风险：读取并外传敏感资料，可能比修改一份隔离环境中的测试文件严重得多。
更可行的模式，是从逐次的 Tool Permission 走向有边界的持续授权：先批准目标、资源范围、时间窗口、操作预算与不可逾越的约束，让 Agent 在隔离环境内自主完成可逆任务；当它触及关键架构、权限模型、生产数据、外部发送或真实系统发布等边界，再触发更高等级的审批。
这并不等于把判断权全部交给 Agent。关键条件有四个：边界必须由外部系统强制执行，重要证据必须能够独立验证，授权必须随时间或状态变化失效，所有关键行为必须可追溯。单靠提示词里的“请谨慎”或让同一个模型审计自己，都不足以构成可靠治理。
更进一步，审批不应只有“允许/拒绝”两个选项，还应能决定“允许到什么程度”：可以提出方案但不能修改；可以在沙箱修改但不能合入；可以准备发布但不能让生产生效。这使人类从低价值的逐步确认，转向真正重要的边界判断。
我会用四个维度来评估一次行动能否自动执行：
其中：
I：Impact，潜在影响程度。
B：Blast Radius，影响范围。
U：Irreversibility，操作不可逆程度。
E：Evidence，当前验证证据的充分程度。
前三项越高，风险通常越大；证据越充分，部分不确定性可以降低。这里是概念模型，实际研究不能简单假设四者线性可加。
控制力并不与审批次数成正比。控制力来自可执行的边界、可信的证据，以及在必要时撤销行动能力的机制。
06｜重写效率公式：从产出吞吐量转向净工程价值
评价 Agent 是否带来工程进步，需要把时间尺度从“这一轮执行”拉长到“整个系统生命周期”。至少应该同时观察三本账。
第一本是交付账：需求前置时间、变更交付周期、真实业务结果，而不是单纯的代码行数、Token 消耗或任务关闭数量。
第二本是验证账：每项成果需要多少人工审阅时间、多少次上下文恢复、多少返工、多少次异常升级；这些成本是否随 Agent 数量增加而线性甚至超线性上涨。
第三本是系统账：缺陷逃逸、事故恢复时间、架构复杂度、重复实现、修改影响范围、未来维护与合规审计成本。
如果要用一个简化关系表达：净工程价值 = 被验证的业务收益 − 执行成本 − 审阅协调成本 − 返工维护成本 − 风险调整成本。这不是一个可以跨企业直接套用的统一财务公式，而是一种提醒：不能把被机器节省的时间，计算为没有代价的净收益。
相应地，实验设计也需要变化。同类任务可以比较“人工执行”“Agent 执行且逐步审批”“边界内自动执行并风险触发审批”三种模式；短期记录任务时间与人类介入，长期跟踪变更质量、返工与维护。只有这样，才能判断自主权扩大后，是减少了不必要的人类劳动，还是把成本延期了。
现在很多人谈 AI 软件开发效率，默认指标仍然是：
单位时间完成多少任务。
多少代码由 AI 生成。
PR 合并速度。
自动化测试通过率。
Agent 能够独立工作多长时间。
这些指标有价值，但不充分。
假设一个团队使用 AI 后，开发效率提高 40%，但一年后系统的修改成本提高 30%，开发者需要更多时间审阅和修复，关键人员也更疲惫。
你很难仅用短期的任务完成速度判断 AI 到底有没有带来真正的生产率提升。
我更建议将软件工程的评价目标扩展为：
不是说这个公式能直接计算出所有系统的最优解，而是提醒我们：
真正的工程进步，必须体现为系统在长期内更容易正确演进，而不仅是更容易被快速创建。
尤其在你所在的高监管保险 IT 环境中，可靠性、审计性、业务规则可追溯性和长期维护成本，有时比上线速度更加重要。
我认为下一代真正有价值的 Harness，应该进一步承担三个功能：
Design Evaluation： 不直接接受第一个可实现方案，而是比较候选设计的性能、复杂度、迁移与维护代价。
Evidence-Based Verification： 要求每项重要变更提供可复现的验证证据，而非 Agent 自述“已经完成”。
Risk-Adaptive Autonomy： 根据任务风险、验证证据和历史可靠性决定自主权，而非简单按工具类型授权。
这也自然引出三个值得继续研究的方向：Agentic Software Engineering 的净生产率悖论、验证负担与动态自主权的关系，以及从 Task Completion 转向 Architecture Sustainability 的评价方法。它们并非三项独立的热门概念，而是同一个系统问题的不同切面。
最后｜真正稀缺的不是生成能力，而是可靠的判断能力
从 Coding Agent、Multi-Agent Harness 到 Personal Agent，技术正在持续降低行动门槛：更多任务可以被启动，更多方案可以被尝试，更多系统状态可以被自动改变。
这是实质性的进步。低成本试错、自动迁移、测试生成、跨系统协作，都会扩大软件工程的能力边界。但当行动的边际成本接近于零，决定生产率上限的可能不再是“还能生成多少”，而是有多少结果能被可靠验证、有效吸收并长期维护。
如果执行规模可以靠算力迅速扩张，而人的注意力、组织的决策能力和系统的承载能力仍然有限，那么无限增加 Agent 并不会自动带来无限收益。它可能只是让人的角色从执行者，变成更繁忙的审核者、协调者和最终责任承担者。
下一阶段值得追求的，不是让 Agent 永远不需要人，而是让人只在值得介入的时刻介入；不是让软件更快被创造，而是让系统更低成本地持续演进。
衡量 AI 工程价值的核心问题，或许应当从“机器完成了多少工作”，变成“在质量与风险可控的前提下，它消除了多少不必要的人类工作”。
参考资料
[1] Cui, Z. K., et al. (2025). *The Effects of Generative AI on High-Skilled Work: Evidence from Three Field Experiments with Software Developers*. Microsoft Research. https://www.microsoft.com/en-us/research/publication/the-effects-of-generative-ai-on-high-skilled-work-evidence-from-three-field-experiments-with-software-developers/
[2] METR (2025). *Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity*. https://metr.org/Early_2025_AI_Experienced_OS_Devs_Study-paper.pdf
[3] METR (2026). *We are Changing our Developer Productivity Experiment Design*. https://metr.org/blog/2026-02-24-uplift-update/
[4] Google DORA (2026). *Balancing AI Tensions: Moving from AI Adoption to Effective SDLC Use*. https://dora.dev/insights/balancing-ai-tensions/
[5] GitClear (2026). *The Maintainability Gap: AI Code Quality in 2026*. https://www.gitclear.com/the_ai_code_quality_maintainability_gap
延伸：Google DORA (2025). *State of AI-assisted Software Development*. https://dora.dev/research/2025/dora-report/
说明：文中的“提效剪刀差”“熵增”和净工程价值框架为概念性分析，不是已有统一定义的学术测量指标；所有示意均不代表特定企业的实测结果。