代码秒出，验证排队？AI Coding 的隐性账单

开发者公众号专属群聊

扫码加入获取更多一手教程、科技前沿报告

进入 2026 年，用 AI 辅助开发已是许多研发团队的日常，我们团队也不例外。代码确实写得更快了，但在实际交付中，我们和不少团队一样，都遇到了一个问题：“代码写得更快了，为什么交付效率的提升没有那么明显？”围绕这个问题，我们做了一些实践和探索，也开始重新思考：编码省下的时间去了哪里？要让整个交付过程更快，除了用好 AI，还需要改变什么？本文就是对这些实践和思考的一次整理，尝试借助信息论的视角理解其中的原因，也讨论团队协作和研发平台可以怎样改进。把这些想法写出来，希望能和有类似经历的朋友一起探讨、交流。

 摘要

Vibe coding 显著提高了代码的开发速度，但不会自动带来同等幅度的需求交付效率。一份需求通常只说明要解决什么问题，真正开始实现时，还要确认业务规则、现有系统限制、异常处理方式和验收标准等。这些内容需要通过需求梳理、功能设计、技术方案评审等环节逐步补齐。如果开发者没有在上下文中告诉 AI，也没有让 AI 从现有代码中查到，模型就只能按照常见做法作出猜测，并把猜测写进代码。

开发者通过 chat 向 AI 说明需求时，或者需求从产品、架构、开发传到测试时，一些依赖经验和具体场景的细节也容易被省略。随着 AI 生成的代码越来越多，人的检查能力、系统集成速度和运行反馈会逐渐跟不上，返工、维护负担和代码腐化也会随之增加。因此，AI coding 能带来多大收益，取决于任务本身。规格明确、容易验收的日抛型应用，更容易把生成速度转化为交付速度；规则复杂、系统关联多、需要长期维护的应用，则收益提升有限。

此外，当需求在不同岗位之间反复转述，就容易遗漏背景和关键约束。为减少这种损耗，AI Native 组织可以围绕完整交付组建由超级个体和小团队构成的交付单元，让同一批人基于 AI 贯通需求、实现、验证与运行反馈。但个人和团队负责的范围不能随代码生成能力同步扩大，仍然受验证能力、专业知识和上线后的运行保障能力限制，组织统一的研发平台与专业人员支持。

研发平台也不能只把多个 coding agent 与 CI/CD 流程串联起来，而应保存每次变更依据的事实和执行记录，提供独立验证，并把上线结果带回需求判断，再根据这些证据逐步扩大自动执行范围。模型能力的提升会让 agent 更好地完成需求，但不会自动补齐缺失的业务信息，也不会替代独立验证。

最后，衡量研发是否提效，应看能否在质量要求不变的前提下，更快、更稳定地把需求转化为可靠的能力。只有需求信息更容易获得和传递，生成结果更容易验证，运行反馈也能及时返回，编码提速才会转化为稳定的交付提效。

01

 1.1 编码提速与交付提效之间的信息缺口

AI 加快了代码生成，vibe coding 也让自然语言驱动的开发更容易启动。然而，编码速度提高以后，软件研发生命周期（SDLC）的整体效率未必同步提高。信息论提供了一个分析视角：沿着真实约束的形成、传递和确认过程，寻找代码生成之外的交付瓶颈。

代码是需求的一种完全指定表述。在给定语言语义、依赖和运行环境后，代码必须把原本未决的选择固定为具体行为，但这些选择未必符合真实需求。

需求文档省略的细节，通常由开发者根据领域知识、系统现状和历史经验补齐。AI 能快速生成常规代码，却未必掌握这些依据，因此可能把猜测固化为实现。真正影响结果的是还有哪些关键选择没有确定，以及这些选择是否有真实依据；prompt 的文本长度不能代替这些信息。

本文所说的纯 vibe coding，是指主要依靠自然语言让 AI 生成代码，再根据局部运行效果反复修改，却缺少系统理解、明确约束和独立验证的开发方式。生成速度提高后，未经确认的假设也会更快进入代码，并在后续修改中不断累积。

本文将用一个假设的电商需求贯穿讨论：“用户取消已付款、未发货的订单后自动退款，减少联系客服的等待。”

 1.2 需求信息的来源与 AI 实现的边界

业务需求的依据来自用户行为与诉求、业务流程限制、运行环境和已有系统约束等。

需求并不是一开始就完整存在、只待向下传递的一组信息。用户知道痛点，未必知道功能应该怎样设计；系统存在限制，团队也未必已经发现；“速度更快”和“结果完全一致”之间还可能需要取舍。这些信息需要通过访谈、观察、实验和工程调查逐步形成，并根据测试与运行反馈持续修正。

以退款需求为例，退款是否到账，需要查询支付渠道和账务证据；取消与发货能否同时发生，需要确认业务规则。这些信息不会随着“自动退款”几个字自动进入模型。即使模型生成了接口调用和状态更新，也无法仅凭这句需求确定重试规则和成功判据。缺少实际流程与渠道约定时，这些实现仍然只是待确认的假设。

从信息论看，可以把 SDLC 类比为一条将业务意图转化为实现的有噪信道。真实目标和约束是有效信号，遗漏会造成信号损失，误解和无依据的补全则会引入噪声。各研发环节承担的信息处理工作如下：

这一类比需要区分信息尚未形成、传递中遗漏和实现未遵守已有约束三种情况，不能把研发理解为只传递固定消息的过程。沿着这条信息路径进入代码的内容，可以按形成方式作如下分类：

结构冗余主要来自语言语法、框架要求和项目惯例。只要环境和规则明确，AI 通常能快速生成这些常规代码。隐性决策则取决于项目的真实情况：接口约定、异常处理、性能目标、旧系统限制、团队要求和历史故障。AI 熟悉常见写法，却不知道当前项目应该采用哪一种选择。

大模型会根据训练形成的先验和当前上下文生成候选实现。上下文缺少事实时，模型可能作出合理推断，但“很可能如此”不能证明它符合当前系统。语法正确、语义合理、与真实约束错位，可以同时发生。

例如，模型可能先查询订单是否“未发货”，再执行取消和退款。代码语法正确，单次测试也能通过；但如果发货流程在查询后、取消前推进，系统就可能同时发货和退款。实现能否成立，取决于当前系统如何保证取消与发货不能同时成功，这项约束无法依靠常见写法猜出来。

因此，AI 编码的收益取决于代码的信息构成。结构冗余多、隐性决策少时，生成收益更容易兑现；隐性决策密集时，收益则取决于获取上下文和核对结果需要付出多少成本。这种关系只能判断收益趋势，不能直接换算成固定的加速倍数。

 1.3 Chat 中的上下文抽取与信息损耗

隐性决策需要真实依据。通过 chat 提供上下文时，开发者需要从掌握的领域规则、历史经验和系统细节中筛选与任务有关的内容，再组织成文字。chat 承载的是这些信息经过筛选后的表达，不能假设某个 prompt 已经包含实现所需的全部约束。

尚未发现的约束无从写入，已经掌握的知识也可能在筛选和表达时丢失。对于上下文丰富的研发任务，把已有知识转成 chat 文字通常是一次有损压缩：没有被选中、难以表达或被简化的信息，无法仅靠这段文字可靠恢复。

信息损失在模型接收之前就已经发生。开发者可能知道退款重试“需要按老办法处理”，却没有写出老办法中的去重条件；模型收到“失败后重试”后，只能在缺少约束的地方选择一种常见实现。它能补全表达，却无法保证补回被省略的事实。

把脑中的知识整理成文字，再核对生成结果是否符合要求，本身就需要时间。说明太少，容易遗漏关键约束并增加返工；说明得更充分，又会增加准备和检查成本。

传统编码中，开发者可以直接用已有经验作出实现判断。例如，他知道退款接口需要防重，就会把约束直接落实到状态变化中。委托 AI 后，这份知识必须先被开发者说出来或写下来，模型才能使用。“说清楚比自己写还累”，说明代码实现成本下降后，知识交付成本仍可能上升。

多轮 chat 可以逐步补齐遗漏，但前提是人先发现问题。对话更长，只能说明传输了更多文字，不能保证重要约束已经完整表达，也不能保证前后说明一致。只要人还没有意识到某项约束，重传就不会发生。

这里所说的有损压缩，是指任务相关信息无法从 chat 内容中完整重建，并不表示自然语言必然丢失关键要求。有限而明确的约束可以完整表达；困难在于，有些约束只有遇到具体问题才显得重要。例如，退款超时以后，团队才可能意识到：没有收到成功响应，不代表退款没有发生，直接重试可能造成重复退款。

减少损耗，需要改变信息进入模型的方式。模型应直接查阅当前契约、历史故障测试和运行证据，chat 主要说明本次新增的要求和未决取舍。团队还要筛选这些资料、标明适用版本并更新过时规则，使人不必每次凭记忆重新讲述。契约和领域知识应与代码同步更新，并采用同库、同版本管理。

 1.4 生成与验证的带宽不对称，验证成为新的效率瓶颈

开发者通过 chat 交代需求和上下文，AI 据此生成代码。代码生成以后，还要检查它是否符合需求、遵守系统约束。这里的“验证带宽”，是指单位时间内能够可靠检查多少代码。AI 可以快速生成大量代码，但生成能力扩大，并不意味着可靠验证能力同步扩大。

当新变更进入的速度超过验证速度，待检查的代码就会积压。坚持完整检查，交付就要排队；放宽检查，问题可能进入集成或运行阶段，随后引发缺陷和返工。生成阶段节省的时间，会被下游的等待和修复成本抵消。

多轮 chat 可以形成“发现错误—反馈—修正”的循环，类似 ARQ（自动重传请求）。然而，纠错必须从发现错误开始。验收由人主导时，人没有发现的问题就不会触发修正。自动测试可以分担检查工作，前提是已经存在明确、有效的判据，能够识别违反约束的行为。因此，真正限制这个循环速度的，仍是负责验收的人能否及时发现错误。

本文把确认 AI 产出所增加的人力称为验证税，并将它与原本就需要的评审和测试区分。计算交付的净收益时，要从生成节省中扣除新增的上下文整理、核验、修正和返工成本。只要关键约束仍留在人脑中，人的识别和判断能力就仍是验证瓶颈。

chat 遗漏的知识需要人重新补充，再据此确认实现。自动化工具可以检查已经明确的规则，却无法保证找回被遗漏的规则。要提高可靠验证能力，还要把隐性知识转成可复用的契约和检查，逐步减少对个人记忆与反复核验的依赖。

公开研究也观察到了这种下游负担。Faros AI 在 2025 年研究了逾 10,000 名开发者和 1,255 个团队，并比较各团队的低、高 AI 采纳期：PR 数量增加、单次变更变大，评审时长也随之上升（图 3）。Sonar 2026 年的调查中，38% 的受访者认为，评审 AI 代码比评审同事编写的代码更费力。

评审时长不等于新增人工工时。两项研究覆盖 AI 辅助开发，分别是观察研究和自报调查，不能据此认定纯 vibe coding 的因果效果。

 1.5 纯 Vibe Coding 的代码为何会快速腐化

代码腐化往往从缺失的约束被默认实现替代开始。在退款案例中，模型不知道重试必须保持为业务上的同一次退款，于是生成了普通的再次调用。一次演示成功后，这个未经确认的选择就成为后续代码的依赖；暂时没有出问题，也让假设看起来像已经确认的事实。

随后，开发工作开始围绕局部症状推进。退款重复了，就在接口外增加一个判断；页面状态不对，就在前端补一份退款逻辑；回调延迟了，再增加一条状态更新路径。每个补丁都可能暂时解决眼前的问题，但如果没有回到领域规则和系统不变量，代码就会不断堆积，缺少统一的抽象和管理，不同逻辑之间还可能相互冲突。

代码生成成本降低后，团队也更容易继续增加实现，而不是理解并合并已有逻辑。新增功能比删除不必要的状态更容易展示进展。同一个业务概念出现多个版本后，一次规则变化就要同步修改多个位置，维护者却未必知道这些逻辑分布在哪里、彼此怎样依赖。

这个过程还会自我强化。未经证实的假设进入代码库后，后续生成又把现有代码当作上下文，早期误判便可能被继承为项目惯例。模型依据局部代码继续生成时，会进一步巩固全局的不一致；每次局部修复，又会扩大以后需要理解和验证的范围。

这里会积累三类技术债：尚未确认的实现假设、缺少来源的设计决策，以及本应复用却被反复复制的结构。它们不是技术债的全部，却都会增加下一次修改时的理解和验证成本。最终，代码越来越多，团队却越来越难判断修改哪里才安全。

因此，代码腐化不能简单等同于“代码熵增”。当代码持续增加，而信息缺口、验证积压和代码冗余没有得到治理时，腐化就会加快。手写代码也可能进入这条路径，但 AI 降低了继续生成和打补丁的成本，从而放大了这个过程。

 1.6 编码提速后的瓶颈迁移与下游负担

即使不考虑代码腐化，只提高编码效率也存在结构上限。在工作量固定、其他阶段耗时不变的串行模型中，可以用阿姆达尔定律表示这一上限：

p是编码占原始总耗时的比例，k是编码加速倍数，S是端到端加速比。即使编码接近瞬间完成，也只能省去原来用于编码的时间。真实项目还有并行、依赖和排队，不能直接把个人活动时间占比当作项目的日历周期占比。

下表假设需求范围不变，并用相对耗时展示下游成本如何抵消编码阶段的局部收益。

注：示意性结构，非某团队实测值。

阿姆达尔定律解释了未被加速的工作如何限制整体收益；表中增加的评审与修复成本，则是在这个上限之外进一步抵消收益。两者不能混为一谈。

代码生成增加后，下游负担还会继续扩大。更大的 diff 要求评审者同时理解更多选择，更多变更会触及更多回归关系，更频繁的发布也需要更可靠的发布和恢复能力。这些额外工作由变更数量和规模增加引起，却往往由评审、测试和运维人员承担。

验证失败后，工作还会返回上游：补充需求、修改设计、重写代码，然后再次进入检查。返工会继续占用有限的需求和验证资源。生成越快、错误发现得越晚，返工就越容易与新需求争夺同一批人员。故障和返工增加可能由这一机制引起，但不能仅凭 AI 生成代码的采纳率上升，就认定两者存在因果关系。

 1.7 杠杆在信道两端：知识显式化与信任重建

在 vibe coding 场景中，AI 承担了更多代码生成工作，研发人员的投入随之向 SDLC 两端移动：向左参与需求、约束和规格的形成，向右承担实现审查、系统验证和持续运行。编码工作减少了，知识显式化和正确性确认却需要投入更多精力。

向左移动，需要把原本直接参与个人编码判断的知识，提前转化为 AI 可以使用的信息，也就是知识显式化。接口约定、功能演进和业务例外都要整理成上下文、契约和验收条件，已经知道的未决问题也要明确标出。过去可以边理解边实现，现在还要为表达、维护和传递这些知识投入时间。只有当这些信息能够反复复用，并减少后续猜测与返工时，显式化成本才会逐步摊薄。

向右移动的成本，来自信任建立方式的变化。传统开发中，开发者在编写代码的过程中逐步理解决策理由、依赖关系和边界处理。AI 生成代码时，开发者没有经历这个过程，只能通过代码审查、测试和运行结果重新建立理解，并确认 AI 是否正确处理了业务规则和异常情况。生成的代码越多，需要重新理解和检查的内容通常也越多，建立可靠信心所需的时间也会增加。

对 AI 生成的代码，应按照默认不信任的原则验收。退款接口调用成功，只能证明本次请求路径能够运行，不能证明超时重试不会造成重复退款，也不能证明取消与发货的竞争已经正确处理，或延迟回调不会破坏状态。验证必须从“能够运行”深入到业务不变量、异常路径和系统影响。

验证证据还要独立于生成过程。让模型根据自己的实现反推测试，可能把同一个误解同时写进代码和断言。测试应由契约、历史故障和独立反例约束。代码看起来合理、单次调用成功或覆盖率较高，都不能代替这些证据。

运行反馈还要检验需求本身是否有效。退款逻辑正确以后，团队仍要确认到账等待和客服求助是否真正改善。如果反馈到达得太晚，生成提速就可能让更多代码建立在未经证实的需求上。缩短反馈路径，团队才能更早决定继续、调整或停止投入。

因此，评估研发提效时，需要同时计算两端新增的投入。可复用的上下文能够降低左侧的知识交付成本，独立且可自动执行的检查能够降低右侧的验证成本。AI 应参与这两类工作，不能只扩张中间的代码生成能力。

02

AI 编码的收益因任务而异。隐性约束越少、验收越直接、生命周期越短，生成节省的时间就越容易转化为交付提效。系统关联越多、验证范围越大、维护时间越长，首次生成的收益就越容易被后续成本抵消。

 2.1 日抛型应用最容易兑现生成收益

日抛型应用逻辑简单、生命周期短，通常用完即丢。这类任务输入明确、验收直接，也很少受历史系统约束。代码多为常规结构，AI 可以快速生成；业务方验收后，通常无须承担集成和长期维护成本。

例如，退款需求如果只做交互原型，可以使用虚构订单和模拟的到账结果。业务方点击取消，确认页面状态和操作流程符合预期，随后即可删除原型。生成节省的时间很少被后续成本抵消，因此更容易体现 AI 编码的收益。

 2.2 复杂系统会放大信息损耗与验证成本

复杂系统要在已有系统上继续演进。一次修改既要实现当前功能，也要满足兼容、性能、一致性、安全和可靠性要求，并避免破坏其他组件与调用方。AI 可以加快代码生成，但系统原有的关联不会随之消失。

同一个退款功能，在原型中只需完成“点击取消，显示退款成功”。接入真实支付、库存和发货流程后，一次取消可能正好遇上仓库发货；退款请求可能已经被渠道受理，系统却因等待超时再次发起；延迟回调还可能覆盖新的订单状态。此时，接口调用成功只能证明一条路径跑通，无法证明整套状态变化正确。

在这些系统关联之上，AI 编码还会叠加信息损耗。相关规则分散在代码、文档、历史故障和团队经验中，经由 chat 和任务交接进入模型时，可能被压缩或遗漏。如果实现与测试沿用同一份不完整的上下文，错误假设还可能同时进入代码和验证。系统关联越多，查证、回归和人工判断的成本就越高。

因此，在复杂系统中，AI 节省的编码时间往往会被上下文搜集、集成验证、异常处理和后续维护抵消一部分，净收益通常明显低于日抛型应用。复杂系统能否真正获得收益，取决于系统事实能否充分进入上下文，以及变更能否通过独立证据完成验证。

03

在复杂系统中，关键事实分散在多个组件和专业领域，仅靠自动检查还无法覆盖所有未知约束，因此人仍需承担需求判断、异常处理和质量责任。研发人员的工作向需求与验证两端移动后，能否持续掌握业务目标、实现约束与验收依据，就成为影响交付效率的关键。

超级个体与 AI Native 组织分别从个人和组织层面减少交接损耗，使目标、约束和责任贯穿完整交付过程。

 3.1 超级个体如何减少交付链中的信息损耗

本文所说的超级个体，是指在明确范围内借助 AI 贯通需求、实现和验证，并对交付结果负责的研发人员。

超级个体可能提高端到端效率，一个重要原因是减少了需求在岗位之间的反复转述。这个过程可以用信息论中的数据处理不等式解释。设原始需求为 X、产品表达为 Y、开发理解为 Z。如果开发只能依据产品表达理解需求，无法直接查阅原始材料或获得新的证据，三者就构成马尔可夫链 X → Y → Z：

其中，互信息 I(X; Y) 衡量产品表达中包含多少原始需求信息，I(X; Y) 衡量开发理解中还保留多少原始需求信息。数据处理不等式说明，继续摘要、解释 Y 或根据 Y 生成实现，都不能凭加工本身增加关于 X 的信息。产品在交接时省略的约束，开发无法仅靠推断可靠恢复。只有直接访问原始需求、用户反馈或领域专家，开发才能获得新的信息，打破这条单纯的传递链。

因此，超级个体的价值不仅在于提高个人产出，还在于让同一责任人更接近原始信源，并持续掌握目标、约束和验证依据。以退款需求为例，他在接收“取消后自动退款”之后，还会直接确认用户联系客服的原因，保留退款进度可见性、取消规则和重试约束，并按照这些依据检查异常路径与到账结果。相关知识仍需明确表达给 AI，但同一项约束无须在岗位接力中反复压缩，再由下一位参与者重新理解。

交付上下文保持连续，可以降低交接成本，却也扩大了个人需要承担的责任。只掌握局部编码技能，难以完成端到端交付。超级个体需要想得明白、表达得清楚，同时能够落地实施：既能定义问题和传达约束，也能判断实现与验证结果。AI 降低了代码编写门槛，却没有替人完成这些判断。

只要人仍是软件研发质量的第一责任人，端到端能力就会变得更加重要。在任务边界明确，并且能够获得可靠验证和专业支持时，超级个体和端到端小团队更有可能减少交接损耗，提高交付效率。

 3.2 超级个体需要具备的能力基础

想得明白”需要领域理解和系统判断，“表达得清楚”需要把约束写得可以传递、可以验收，“能够落地实施”则需要组织 AI 和工具完成实现、独立验证结果，并处理上线后的问题。这三项要求可以进一步落实为六类具体能力。

AI 可以完成部分编码操作，但责任人仍要判断变更会影响哪些系统、异常会怎样传播，以及验证结果能否支持交付决定。

当负责的任务逐渐增多时，超级个体也不能每次都从头理解和验证。故障原因、业务取舍和验证结果需要沉淀为契约、测试和决策记录，供后续任务直接复用。否则，任务越多，团队对超级个体个人经验的依赖就越重，端到端效率也越难持续提高。

 3.3 超级个体的验证瓶颈与责任边界

超级个体在减少岗位交接的同时，也把原本由多人承担的判断、验证和运行责任集中到了一个人身上。因此，个人能负责多大范围，取决于他能否验证 AI 产出、发现自己的认知错误，并持续对上线后的运行结果负责。

最直接的限制来自验证能力。由于 AI 可以并行完成多个编码任务，而人的注意力、跨领域理解和验证能力有限，当代码编写能力增长快于个人对需求和实现的验证能力时，就会造成工作积压，人也会成为需求交付的瓶颈。此时继续生成代码，只会增加等待验证的内容。

更隐蔽的风险是同源错误。如果同一个人误解了退款重试规则，AI 可能沿用这项错误假设生成需求说明、实现和测试。三者看起来相互一致，实际却可能共同偏离业务事实。因此，关键规则仍需由领域负责人、支付专家或独立契约检查进行验证，不能只依靠同一套上下文自我证明。

即使功能已经通过验证并上线，责任也没有结束。超级个体还需要观察系统运行情况、处理异常并准备恢复方案，不能用“AI 写的”解释事故；关键决策、运行记录和处理方法也要能被他人接替。因此，个人负责范围的扩大，应建立在可靠验证和专业协作之上。证据不足时停止交付，超出能力范围时引入专业人员，也是端到端负责的一部分。

 3.4 AI Native 组织：小型交付单元、共享平台与专业保障

要弥补个人能力的边界，组织需要提供共享信息、独立验证和专业支持。让每个岗位都使用 AI，并不会自然形成 AI Native 组织。本文所说的 AI Native 组织，是指根据人和 AI 各自的能力，重新安排信息路径、责任和协作方式。

一种可行的组织方式，是建立围绕业务结果的小型交付单元，同时提供组织级的共享上下文、工程平台和专业支持。交付单元可以由超级个体或少量跨职能成员组成，从目标定义到实现、验证和运行结果持续负责。这样，知识、执行过程和验证证据无须随着岗位切换而反复转述。

以退款需求为例，交付单元直接确认用户目标，支付专家只在关键规则上参与，平台则提供支付渠道契约、异常测试和灰度观测。这样，专业人员可以同时服务多个交付单元，无须成为每项需求都必须经过的固定传话站。

要让这种方式真正运转，交付单元的责任必须与权限相匹配。单元需要能够查证业务事实、调整需求范围、调用必要工具，并在证据不足时停止交付。涉及多个系统的共同规则由统一契约维护，专业复核根据风险介入，同时还要明确由谁维护全局一致性。

人和 AI 还需要在共享状态中协作。每项任务使用了哪些资料、依据哪个版本、留下哪些假设、完成哪些检查，都应清楚可见。如果只是把多个岗位各自的聊天窗口串联起来，摘要交接和语境丢失仍会出现，增加 agent 数量也无法消除这些信息损耗。

因此，组织协作应围绕“目标、约束、变更、验证证据和运行结果”展开。人的工作重心随之转向业务取舍、系统设计、独立判断和例外处理，AI 则承担经过授权的信息搜集、常规内容生成、任务执行和检查工作。专业分工仍然存在，但固定的岗位接力链可以缩短。

04

超级个体可以减少交接，却仍受个人理解和验证能力限制。研发平台要把需求资料、验证依据和运行反馈沉淀为团队共享能力，减少重复解释、检查和协调的成本。

4.1 AI 核心问题是有效信息不足，可靠验证跟不上生成

平台需要回答三个问题：关键约束怎样进入实现，生成结果凭什么可以接受，运行结果怎样返回需求判断。流程能够自动执行，不代表这些问题已经解决。

在需求侧，平台要让事实、契约、决策和未决事项可追溯、可复用；在验证侧，平台要提供独立证据，减少人理解和检查陌生代码的负担；在运行阶段，平台还要把业务反馈带回原始需求。只有信息获取、人工核验和反馈等待的成本下降，平台才能产生端到端交付收益。

因此，平台应围绕一次可追溯的变更组织信息：目标是什么，使用哪个版本的约束，修改了哪里，哪些检查已经通过，还有哪些未知，运行结果怎样。agent 和对话可以更换，这些依据必须持续保留。

4.2 Agent 流程串联的效率收益与信息边界

这里讨论的研发平台，是把 Claude Code 等可远端运行的 coding agent 部署在开发环境中。用户在平台上提交任务、提供上下文，或通过 chat 与 agent 协作；agent 在远端读取项目、修改代码、运行命令和检查，再把变更提交到 Git 仓库，进入后续 CI/CD 流程。平台还可以通过连接器，让 agent 访问需求、代码托管、测试和发布等外部系统。

这种平台把原本分散的操作串成一条工作流。它可以统一准备开发环境、分配和并行执行任务、记录上下文与操作过程，并自动衔接代码评审、测试、合并和发布，从而减少环境准备、人工转述、重复操作和阶段间等待。

工作流连通不等于交付质量得到保证。如果多个 agent 只依赖上一步传来的摘要，岗位接力只是变成了 agent 之间的摘要接力。源头没有确认的规则仍会被猜测，已经遗漏的约束无法靠后续加工恢复，多个 agent 还可能共享同一个错误假设。以退款需求为例，如果团队没有明确重试是否沿用同一个退款标识，实现 agent 可能选择默认方案，测试 agent 再根据这份实现生成能够通过的用例。流程执行成功，仍不能证明系统不会重复退款。

平台与 coding agent 应有清楚的能力边界。平台作为控制与证据层，负责身份权限、远端环境、任务状态、资料版本、质量门禁、审计记录和流程推进；coding agent 作为可替换的执行单元，负责理解任务、修改代码、调用工具和返回结果。这样既能使用 agent 已有的 chat、项目理解和工具调用能力，也能避免平台重复建设一套智能执行能力，制造新的信息转述层。

模型能力提高后，agent 对需求和代码的理解、任务规划、工具调用与代码生成通常也会改善，平台会直接获得这部分收益。但平台仍要解决需求信息、执行环境、权限、验证证据和运行反馈如何共同支持可靠交付的问题。因此，研发平台的提效上限不等于 coding agent 的能力上限：前者取决于端到端交付系统，后者主要影响具体任务的执行效果。

4.3 平台的核心工作：关联事实、执行、验证与反馈

研发平台无法代替团队确认所有业务事实，但可以让每次变更依据了哪些事实、执行了哪些操作、通过了哪些检查、产生了什么运行结果都能够追溯，并根据这些证据决定流程能否继续推进。

这些能力可以复用代码仓库、需求系统、CI 和观测工具，再通过标准接口提供给 agent。规则和操作可以封装成指令或技能，但关键检查与权限边界必须由执行系统落实，不能只要求模型“记得遵守”。

流程是否继续推进，应由证据决定。约束得到确认后才能据此实现，必要检查通过后才能进入相应的发布范围。检查失败时，应保留原始结果，补充规格或修改实现后重新检查；生成者不能自行忽略未通过的检查。测试通过只代表已经定义的判据得到满足，尚未覆盖的风险仍要明确记录。

退款功能上线后，团队还要确认实际到账等待和客服求助是否改善。代码可以回滚，却无法撤回已经发生的退款，因此业务恢复必须单独设计。只有把技术结果与业务结果关联起来，平台才能把运行证据带回需求判断，并减少信息在返工过程中的反复流转。

4.4 建设顺序：先扩充证据，再扩充自动执行范围

平台建设可以从一种反复出现、边界可控的真实变更开始，以成熟 agent 作为执行入口。团队应整理关键契约、决策和历史故障，明确资料责任人；同时记录澄清、生成、验证、等待和返工耗时，找出真正的交付瓶颈。

资料能够稳定使用后，再把验收依据转成可执行检查，让 agent 直接取证、执行和返回结果。需求、代码变更、检查结果和运行证据建立关联后，平台才能逐步自动推进流程。现有能力应直接接入，避免另建信息孤岛。

当证据链能够稳定支持交付决定时，平台才适合扩大并行执行和预先授权的范围。团队需要预先明确三类边界：具备哪些证据后，agent 可以自动执行变更或进入下一环节；出现哪些异常时，必须交由相关负责人或相应人员处理；缺少哪些关键信息或面临哪些风险时，平台必须停止变更。

如果等待验证的变更已经形成积压，就应限制新增任务，避免继续增加 agent，使更多未经验证的代码进入队列。

每次扩大自动化范围，都要比较同类任务在相同质量要求下的端到端结果，并计入知识维护、平台运维和专业复核成本。共享资料应减少重复解释，自动检查应减少人工核验；如果这两项成本没有下降，自动化只是把工作转移到了平台维护和异常处理。

4.5 人退出交付关键路径的条件与边界

只要每次交付都需要人重新理解系统、逐项确认风险并处理未知情况，人的判断能力就仍然限制交付速度。把操作交给 AI，不会自动消除这项限制。

责任归属和操作瓶颈需要分开判断。人可以继续承担结果责任，同时通过预先授权、自动检查和例外处理退出常规确认。责任仍在人身上，并不意味着每次交付都要等待人工操作。

人能否退出常规交付的关键路径，要根据系统持续运行的证据判断：

这些条件可能先在边界明确的任务中成立。如果常规流程表面上已经自动完成，专家却需要频繁处理异常，说明工作只是被转移到了例外处理。只有计入这些异常和长期维护成本，才能判断人的瓶颈是否真正移走。

这个临界点要用运行结果检验，不能根据一次能力演示推算兑现时间。平台应逐步扩大已经验证的自动化范围，同时保留识别未知约束、升级处理和安全停止的能力。

4.6 研发平台的提效应以端到端交付结果衡量

研发平台可以把提效范围从编码扩展到资料获取、检查、集成和发布，端到端收益因此可能高于只使用 coding agent 的局部收益。但阿姆达尔约束仍然成立：只要需求确认、人工验证或运行反馈仍是最慢环节，整体效率就不会按编码速度同比提高。

平台能够自动推进多少工作，取决于任务是否容易明确和验证，以及现有证据能够覆盖多大范围。模型能力提高会改善 agent 的执行效果，平台也会从中受益；但它不会自动补齐业务事实、扩大验证容量或加快真实反馈。平台的提效上限与 coding agent 的能力上限并不相同。

判断平台是否真正提效，应比较质量要求不变时的端到端交付时间、人工判断和返工成本、上线缺陷与长期维护成本。平台建设的目标，是通过共享可靠信息、独立验证和运行反馈，逐步扩大能够安全自动执行的范围，而不是增加代码产量或 agent 数量。

05

Vibe coding 改变了软件开发的成本结构，却没有消除需求确认、系统取舍、独立验证和运行反馈。它能更快地把已明确的要求转成代码，但端到端的交付效率，仍取决于业务目标和系统约束能否被充分理解，以及实现结果能否得到可靠验证。

因此，衡量提效的标准，是在质量要求不变的情况下，需求能否更快、更稳定地转化为真实可用的结果。任务越明确、证据越充分，生成速度越容易转化为交付速度；系统越复杂，越需要超级个体、小型交付团队、专业人员和研发平台共同维持目标、约束与责任的连续性，把局部的编码提速转化为整体的交付能力。

基于这些实践，我认为，走向成熟的 AI Native 研发，应当让人的判断、AI 的能力与持续积累的知识和经验不断融合、形成合力，使研发组织在保障可靠交付的同时，更快地探索业务机会、验证创新，并在这一过程中积累持续演进的组织能力。