AI写代码快了，工程债更多了

张涛翻开上个月的研发报表，表情从期待变成困惑。

团队三个月前全面启用了AI编程助手，人均代码提交量涨了将近四成，PR数量翻了一倍。可需求交付周期只缩短了不到5%，而生产事故环比增加了近两成。更让他坐立不安的是，高级工程师每天花在代码审查和返工上的时间，从两小时涨到了四小时。

"代码明明越写越快，为什么交付反而更累了？" 他在管理层会议上抛出这个问题，会议室里一片沉默。

这不是张涛一个人的困境。2026年8月，Mo Shehu 发布了一份对12500多位软件工程领导者的调研总结，提炼出82条AI工程落地经验。报告开篇就点破真相："AI让代码变便宜了，但规格、审查、QA和责任没有跟上。" 更快写代码往往只是把工作量挪到了别处。如果你只度量生成速度，就会像张涛一样，被漂亮的提交曲线麻痹，直到返工和事故敲响警钟。

代码便宜了，验证变贵了

AI把"把想法变成可运行代码"这一步的成本压到了接近零。过去写一个CRUD接口可能要半天，现在几分钟就能出初稿。但成本不会凭空消失，它只是转移了：从"写"转移到"读、审、改、验"。

New Relic 在2026年6月对美国200位技术决策者的调研显示，74%的受访者表示至少四分之一的AI生成代码需要大幅返工，86%的团队发现高级工程师修复代码的时间增加了，78%的团队经历了更多生产事故。这组数据描绘的正是张涛的处境：代码产出的前端被AI打通，但验证、集成、运维的后端开始拥堵。

管理者容易掉进一个度量陷阱：把"AI采纳率""人均提交次数""代码生成量"当成效率指标。这些数字好看，却和真实交付价值无关。Waydev 在2026年第二季度的报告里说得直接："AI采用时代已经结束，AI问责时代开始。" 代码输出在涨，工具支出在涨，但开发者体验在降，质量信号参差，创新产出几乎持平。

决策分析到这里，关键问题变成：省下来的时间去了哪里？

答案通常有三处。第一，审查时间。AI生成的PR更大、更碎、更依赖上下文理解，人类审查者被迫从"看代码对不对"变成"看代码是不是该这么写"。第二，返工时间。AI擅长模仿常见模式，却对业务边界、历史约束、隐性契约缺乏感知，很多代码"看起来对"，上线后才发现踩了坑。第三，对齐时间。需求描述稍不清晰，AI就会按自己的理解补齐，团队花更多精力在PR评论区解释"这里不是这个意思"。

经验总结：把AI当成单纯的"代码加速器"，等于在高速公路上只扩建入口不扩建出口。管理者必须接受一个事实——代码生成成本下降的同时，验证成本正在上升。预算和人力要跟着这个转移重新配置。

不是所有任务都适合交给AI

82条经验里有一条很扎心："任务类型决定AI成败。"  delegation 在边界清晰、上下文完整、验收明确的任务上表现出色：修一个已知bug、补一段样板代码、改一个依赖版本、加一个常见功能。但在开放式产品探索、架构重构、跨团队协调、未回答关键问题的需求上，AI只会把模糊放大成灾难。

可很多团队的做法是一刀切：给所有人开会员，鼓励"能用AI就用AI"。结果是，工程师把本属于判断和沟通的工作也丢给模型，模型给出看似合理的方案，团队再花双倍时间把它扳回正轨。

更聪明的团队会先做任务分类。把研发工作分成三类：人类辅助型（AI生成，人做最终判断）、人类引导型（人定方向，AI补细节）、无人值守型（触发条件清晰，失败可回滚，可自动执行）。不同的类别对应不同的 harness、不同的审查深度、不同的责任归属。

方案对比很清晰。方案A是"全面放开"，好处是短期数据好看，代价是质量债务和高级工程师 burnout。方案B是"任务分层"，前期投入时间做分类和模板，但能长期把AI用在刀刃上。大多数尝到甜头的团队，都是从方案B开始的。

经验总结：AI不是替代工程师做判断，而是替代工程师做重复执行。管理者要做的第一件事，不是采购更贵的模型，而是和团队一起划定：哪些工作可以无人值守，哪些必须 human-on-the-loop，哪些必须 human-in-the-loop。边界越清晰，AI越安全；边界模糊，AI就是高级随机数生成器。

审查产能才是新瓶颈

2026年8月15日，CodeRabbit 发布了一组AI辅助代码变更管理功能，核心是两个能力：Triage 和 Change Stack。Triage 用AI给PR做优先级排序和风险分级，Change Stack 则把变更对契约、依赖、下游系统的影响可视化。发布当天，多位分析师的评论指向同一个痛点：AI生成PR的速度已经远超人类审查能力的上限。

这不是工具问题，是结构性瓶颈。

以前一个工程师一天产出一个PR，审查者可以仔细看逻辑、测边界、问业务。现在AI让一个人一天产出三个PR，审查者的时间没有同比例增加，于是审查开始降级：只看语法、只看测试是否通过、只扫一眼就点approve。82条经验里警告说："如果一个agent在人类产出一个PR的时间里产出三个PR，那么原本就承压的审查流程现在要吸收三倍负载。"

解决这个问题不能靠"让审查者更努力"。人的注意力是有限的，每天能深度审查的代码量有上限。管理者要从流程设计上释放审查产能。

常见做法有三层。第一层，让AI先审AI生成的代码：跑静态分析、安全扫描、重复检测、测试覆盖检查，把低级问题拦截在人工审查之前。第二层，按风险分层审查：低风险变更走自动化门禁，中风险走常规审查，高风险必须双人审查或架构师介入。第三层，也是最容易被忽略的：控制并发在途PR数量。AI提速后，WIP（在制品）会自然膨胀，而WIP膨胀会直接压垮审查质量和交付节奏。

经验总结：审查不是成本中心，而是AI时代最重要的质量阀门。把审查产能当稀缺资源来管理，比单纯追求代码产出速度更能决定团队交付健康度。

度量端到端，而非生成速度

82条经验反复强调一句话："你无法知道AI是否真的提升了效率，除非你度量从想法到生产的完整路径。" 很多团队度量的是生成一行代码用了几秒，却忽略了需求澄清、审查、测试、部署、线上验证加起来的总时间。

更隐蔽的问题是指标扭曲。PR数量、提交频率、代码行数这些虚荣指标，在AI加持下会大幅上涨，但它们掩盖了真实质量。BizStack 在2026年提出用"复杂度调整吞吐量"（CAT）替代简单计数：简单任务1分、中等任务3分、复杂任务8分，避免AI大量生成样板代码把仪表盘刷漂亮。同时引入"代码周转率"，看一段新代码在30天或90天后是否还在、是否被重写、是否被回滚。

好的度量体系应该同时回答两个问题：我们交付得更快了吗？我们交付得更稳了吗？

DORA 指标和 SPACE 框架依然有效，但需要补充AI时代的信号。建议从五个层次建一张小仪表盘：业务结果（功能采用率、可靠性）、交付效率（前置时间、部署频率）、质量（变更失败率、线上缺陷）、流程摩擦（审查周期、返工率、在制品）、AI使用（采纳率、单次成功变更成本、agent使用分布）。最后一层只是诊断信号，不是生产力本身。

方案对比上，A方案是"只看AI采纳率和代码产出"，会被短期数据误导；B方案是"建立端到端基线，锁定几个变量做纵向对比"，能真实反映变化。82条经验里那唯一能证明收益的案例，靠的不是最先进的模型，而是多年积累的 workflow history：任务类型、估算vs实际耗时、延迟归因、供应商账单。没有基线，就只能在猜测中做决策。

经验总结：AI时代，度量的对象要从"人写了多少代码"转向"系统交付了多少可靠价值"。把git指标当诊断信号，而非绩效判断；把端到端人力当核心指标，而非生成速度。

写在最后

AI没有让工程变简单，它只是把工程的复杂形状改变了。过去瓶颈在"写"，现在瓶颈在"想清楚、审明白、负责任"。

给技术管理者的建议只有一句：先别问团队"AI用得够不够多"，先问"我们的规格、审查、QA和责任机制，能不能接住AI产出的代码"。接不住的提速，不是效率，是债务。