# AI 编码的下一阶段，是重造研发系统 - Date: 2026-10-11 - Author: ByF - URL: https://blog.baifan.site/agent-native-sdlc/ - Description: 写代码变快并没有让交付变快。实测数据显示交付稳定性持续承压，研发瓶颈已从敲键盘转移到评审排队与集成验证。单纯给开发者配 AI 工具收益见顶，下一阶段的重心在于重构流水线：验收条件测试化、评审分层自动化、安全防护下让业务人员直接改动，并由工程师守住架构底线。 --- 团队里每个人敲代码的速度翻了几倍，最终交付却没有变快。敲键盘提速产生的代码洪峰，直接把下游的评审队列和集成流水线冲垮了。瓶颈没有消失，只是从编辑器转移到了代码审查和上线验证。 ## 编码提速，交付没有 AI 没有让软件研发整体变快，行业实测数据至今都不支持提速的判断。 DORA 报告是工程效能领域样本量最大的长期研究。2024 年版（[报告发布文](https://cloud.google.com/blog/products/devops-sre/announcing-the-2024-dora-report)）的回归分析显示：AI 采纳率每提高 25%，交付吞吐量估计下降 1.5%，交付稳定性估计下降 7.2%。2025 年版（[报告发布文](https://cloud.google.com/blog/products/ai-machine-learning/announcing-the-2025-dora-report)）样本扩大到近 5,000 名开发者，吞吐量转为微弱正相关，但稳定性依然保持负相关。报告指出了根本原因：AI 加速了代码编写，但如果下游缺乏自动测试、健壮的版本控制和快速反馈机制，激增的变更量就会直接引发线上故障。 这是横断面问卷研究，吞吐量的相关方向在两年间出现过波动，应该看重发展趋势而非某单一年的点估计。然而两个年份、两组独立样本在交付稳定性上给出了完全一致的负相关结果。 这个现象完全符合约束理论（Goldratt，《The Goal》，1984）的基本规律：流水线的整体产出永远取决于最窄的那个瓶颈环节。给非瓶颈环节盲目加速，不仅不能增加产出，反而在瓶颈前堆满积压的半成品代码。过去敲代码是团队中最慢的环节，AI 把敲键盘的速度提上去了，流水线的堵点顺理成章地移到了代码评审、合并冲突处理与集成验证。代码写得越快，在下游排队等待的时间就越长。 代码库层面的数据同样证实了这种恶化。GitClear 2025 年的[年度报告](https://www.gitclear.com/ai_assistant_code_quality_2025_research)分析了 2.11 亿行代码变更：2024 年是复制粘贴代码占比首次超过重构代码的年份。重构代码占比从 2020 年的 24.1% 跌至 2024 年的 9.5%，而直接复制粘贴的代码占比同期从 8.3% 涨到 12.3%。2026 年的[新报告](https://www.gitclear.com/the_ai_code_quality_maintainability_gap)显示：2026 年上半年重构代码占比只剩 3.8%，跨文件函数调用自 2023 年下降 35%，开发者选择复制粘贴而非重构提取公共函数的概率变成了五倍。按 GitClear 的检测口径，包含 5 行以上重复代码的提交占比在两年内暴涨了约十倍。AI 让复制代码零成本，开发者遇到相似逻辑直接让 AI 吐一段贴进去，每多复制一段，未来修改逻辑时就多了一处需要同步排查的暗坑。 个人的体感同样不可靠。METR 在 2025 年 7 月完成的[随机对照实验](https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/)中，16 位资深开源开发者在自己最熟悉的仓库里处理 246 个真实 issue。允许使用 AI 的组实际慢了 19%。然而这些开发者在测试前预测自己能快 24%，任务完成后依然主观认为自己快了 20%。看着 AI 在编辑器里飞速吐出代码的主观快感，与真实交付速度毫无关系。花在排查 AI 逻辑漏洞、调试边缘情况上的时间，吃掉了省下的打字工时。 打字速度提高不会自动转化为交付提速。审查与验证体系如果不重构，多写出来的代码只会变成更长的审查队列。 ## 给 AI 派活，得先把边界和测试钉死 AI 能力越强，开工前把需求和验收标准写清楚的要求就越高。 METR 的归因分析揭示了核心原因：除了对 AI 能力的盲目乐观，另一个主要拖慢速度的因素是代码库里的未成文知识。AI 就像刚入职的新员工，并不清楚仓库里长年积累的潜规则：哪层抽象绝不能绕过、哪个遗留模块不可并发访问、测试覆盖到什么程度才允许合入。人类工程师需要数年摸索建立的分寸，AI 完全无法感知。给 AI 的需求越模糊，AI 就只能靠概率去猜，猜错的代价全部落在后续的调试与人工排查上。任务越复杂，AI 触碰到的未成文规则就越多，失误的概率随之增加。 前期需求设计的目的只有一个：把未成文的规则变成明确的约束。把意图写清楚、划定明确的代码修改边界、给出可自动执行的测试用例。Claude Code 官方工作流划分了探索、规划、实现、提交四个阶段（方法论详见[Plan Mode 的拆解]({{< ref "posts/2026-06-29-claude-code-plan-mode" >}})），核心原则是给 AI 提供能够明确判定成功或失败的检查点。 给 AI 派发任务时，禁止使用“优化”、“分析”、“重构”等含义模糊的方法论动词。如果只要求“优化查询性能”，AI 会开始天马行空地改写业务逻辑；必须明确说明四项要素：最终目标、系统背景、绝对不可破坏的约束条件，以及交付物的具体形态。这个规则来自于一次报废的对照实验，完整复盘记录在[那篇 Skill 评测文]({{< ref "posts/2026-10-08-evaluating-agent-skills-first-principles" >}})。 前期给出的测试与边界越清晰，AI 的执行就越稳定可控。 ## 代码评审必须由自动化系统接管第一道关卡 代码生成量翻倍之后，传统的人工审查机制必然陷入两难：要么严格审查导致合并请求大量积压，要么敷衍审查导致线上故障频发。 开发者的态度数据体现了这种信任危机：[Stack Overflow 2025 年调查](https://survey.stackoverflow.co/2025/ai)显示，46% 的受访者不信任 AI 工具的准确性，75% 的人因为不信任 AI 答案而必须向真人求助。面对每天涌入的数千行生成代码，单纯依靠增加审查人手或加班无法解决问题。唯一的工程出路是建立分层的自动化流水线，把审查从依赖个人经验的工作变成可扩展的自动化流程： 1. 确定性机器检查：代码规范、静态检查、类型校验、单元测试与集成测试构建。凡是能够由脚本执行并给出明确退出码（0 或非 0）的检查项，全部交给流水线处理。检查失败直接打回，不占用人工审查的精力。 2. 规则过滤与机器初筛：将团队中反复提出的人工审查意见固化为静态分析规则或 linter 插件；利用专门的审查工具优先过滤掉低级语法错误、未处理的空指针和明显的逻辑死循环。 3. 人类保留最终裁决：人类工程师只审阅机器无法判断的核心部分——系统架构是否合理、业务领域逻辑是否正确、高风险分支是否有未知影响。 工业界已经提供了完整的实践样本。Atlassian 在 2026 年 4 月公布了[内部 AI 审查系统的实测数据](https://www.atlassian.com/blog/ai-at-work/developer-productivity-improved-with-rovo-dev)：覆盖 1,900 多个代码库、运行一年以上，通过分层质量门过滤，合并请求中位周期缩短 30.8%，人类编写的审查评论减少 35.6%。报告同时给出了一个实测数据：AI 审查评论的采纳率为 38.7%，仍低于人类评论的 44.45%。机器审查并没有超越人类，但它把人类从第一道机械筛查工作中解放了出来。 ## 业务人员改代码的前提，是系统有防弹衣 审查实现分层自动化之后，另一项协作模式变得可行：允许非工程师直接修改代码。 在实际业务中，产品经理最清楚按钮应当放在哪个页面，交互设计师最清楚用户在哪一步流失，业务运营最清楚报表里哪个字段不再需要。过去修改两行文案或微调一个界面，需要经历提需求、排期、开发、审查与发版，流程长达数周。 配合 AI 工具，业务人员直接修改前端代码或配置文件能够大幅缩短响应时间。但这绝不意味着可以放任非技术人员随意向主干分支提交代码。这种模式得以成立，前提是系统提供了完善的安全防线： - 修改范围严格隔离：限制操作权限，只允许业务人员修改特定的展示模板、样式表或文案字典，严禁触碰底层核心业务与数据库逻辑。 - 自动部署与沙盒验证：变更提交后，流水线自动在独立沙盒环境中部署预览，并自动跑完回归测试。 - 一键秒级回滚：一旦线上表现异常，系统支持在几秒内无损回滚。 非工程师借助 AI 生成的代码普遍停留在“能够运行的原型代码”层面：主干逻辑可以跑通，但往往忽略了并发冲突、边缘异常和长期维护性。这种模式改变的是日常微调的协作链路，不代表软件工程的门槛消失了。完整的团队分工逻辑在[团队分工的思考]({{< ref "posts/2026-08-03-team-roles-evolution-ai-era" >}})中有过讨论。底层的系统架构与健壮性，依然需要资深工程师来构筑。 ## 出现生产事故，背锅的永远是人 AI 的能力清单在不断拉长：编写代码、运行测试、排查错误、提供重构建议。但责任清单始终没有改变：线上出事故时必须由具体的人来承担。 多份权威资料明确阐述了这一点。Atlassian 的评估报告强调，合并建议的最终批准权始终属于人类审查员；Anthropic 在 [Agent 构建指南](https://www.anthropic.com/engineering/building-effective-agents)中将人工审查列为方案对齐系统级要求的必要环节；DORA 2025 的核心观点极为明确：AI 不会修复糟糕的团队流程，只会放大团队已有的问题。混乱的流程引入 AI 之后只会崩溃得更快。 发生严重生产故障时，AI 不会被问责，不会承担业务经济损失，也不会在故障复盘会上解释当时为何做出这种修改。责任始终在人类的组织结构中流转：业务目标是否合理、系统架构是否稳健、高风险变更是否经过充分评估，责任始终由签字上线的工程师与技术管理者承担。 即便在度量人机协同这件事上，传统的评估体系也已经开始失灵。METR 在 2026 年 2 月宣布放弃其开发者效能测试（[官方说明](https://metr.org/blog/2026-02-24-uplift-update/)），因为在第二轮测试中，30% 到 50% 的开发者承认故意隐瞒了“没有 AI 就不想做”的任务，导致样本数据严重失真。度量体系需要重新设计，研发系统的建设更不能简单沿用过去的思维。 ## 研发系统的重心，从写代码转向验证与边界 开发工具的第一轮普及已经基本完成。DORA 2025 调查显示九成从业者在日常工作中使用 AI；[GitHub Octoverse 2025](https://github.blog/news-insights/octoverse/octoverse-a-new-developer-joins-github-every-second-as-ai-leads-typescript-to-1/) 统计到超过 113 万个公开代码仓库接入了语言模型接口，同比增长 178%。单纯给程序员配装 AI 助手带来的速度红利已经见顶。 软件研发的核心重心正在发生转移：从敲代码本身，转向重构整套支撑人机协同的研发流水线： 1. 需求向机器可执行的验收测试靠拢：业务需求不再停留在含糊的口头描述或长篇文档，而是直接转化为自动化的验收测试。测试用例是给 AI 执行结果做判定的唯一标尺。 2. 自动化审查承担首道防线：建立严格的自动化过滤流水线，把关代码质量与规范，人类工程师集中精力进行最终的业务与架构决策。 3. 验证体系成为研发基石：自动化测试与环境隔离不再是可有可无的辅助环节，它们是保障 AI 闭环运行并自动纠错的基础设施。 在人机协同的新流水线中，分工界限非常清晰：人类工程师负责定义需求意图、把控系统架构与核心决策；AI 负责推进具体代码实现与自动化测试闭环。 历史上编译器的出现重塑了程序员的工作定义，CI/CD 流水线重塑了团队的交付拓扑。当前的演化遵循同样的逻辑——演进路径在[从 Copilot 到 Autonomous Agent]({{< ref "posts/2026-07-03-ai-coding-tools-future-copilot-to-agent" >}})中讨论过。接下来的重点，是把这套体系具体落实到工程实践中。 ## 尚未解决的工程难题 在实际落地过程中，依然存在三项没有标准答案的工程挑战： 第一，团队效能的度量难题。在个人层面通过对照实验度量效率尚且极为艰难，在团队层面评估 AI 采纳对整体软件质量与交付效率的净影响，行业至今缺乏严谨的因果推断数据。 第二，自动化审查的误报成本。过滤规则过于严苛会导致大量误报，反复打扰工程师并引发报警麻木；过滤规则过于宽松则会让隐蔽缺陷溜进主干代码。维护一套高效且低误报的自动化审查流水线，本身需要持续投入工程资源。 第三，瓶颈向上游需求扩散。当代码实现变得极其廉价之后，研发流水线的拥堵点不可避免地向上游转移。如果产品和业务方无法明确自身需求与边界，快速生成的代码只会加速技术债务的积累。