出码率到 90% 之后，我们真正验证了什么？端到端自动化的第一次真实落地

最近一段时间，我们在真实业务研发中，初步跑通了一条端到端自动化链路。

在部分新增类、变更类需求里，出码率已经达到 90%。这里的“90%”，指的是在当前已验证的部分新增类、变更类需求中，AI 生成代码提交占比阶段性达到约 90%，并不代表全团队、全场景的长期平均水平。

如果只看这个数字，它当然足够吸引人。过去一年，关于 AI Coding 的讨论很多，最容易被放大的，往往也是这类结果：生成了多少代码、提效有多高、能不能进入生产环境。

但这篇文章真正想讨论的，不是“90%”本身。

更重要的是，这个结果背后已经开始显现出一种结构变化：端到端自动化，已经不再只是一个判断，而开始在真实业务研发中形成阶段性闭环。

这里说的“真实业务研发”，不是脱离约束的 demo 环境，也不是一句“做一个页面”式的开放题，而是发生在真实的 B 端业务场景中：有历史仓库，有既有实现方式，有团队规范，有上下游依赖，也有对结果可维护性、可交付性的要求。

当前已验证的需求，主要来自真实 B 端的 Web 与移动端研发场景。本文讨论的“端到端自动化落地”，首先成立于这类带有历史仓库、团队规范与业务约束的真实工程环境中，而不是泛指脱离上下文的开放式生成任务。

所以，到今天我们真正需要回答的问题，已经不是“AI 能不能写代码”，而是：

研发任务能否在真实业务约束下，被稳定地表达、执行与验证。

如果把问题只理解为“AI 生成代码的能力怎么样”，那这次实践很容易被误读成一次普通的提效复盘。

但我们这次真正验证的，并不是某个模型够不够聪明，也不是某次生成是否刚好成功，更不是某套 prompt 是否足够巧妙。我们真正验证的，是：一条面向真实业务研发的自动化链路，是否已经开始成立。

更具体一点说，我们在验证的是四件彼此关联的事情：

第一，需求能否被稳定承接，而不是停留在模糊描述上。
第二，任务能否从原始输入，被组织成更适合执行的对象。
第三，执行能否带着仓库上下文、团队规范和技术约束运行。
第四，结果能否进入验证闭环，而不是只靠人工主观判断“差不多可以”。

只有把验证对象放回这条链路里，前面的“90%”才有真正的解释力。否则，它只是一个结果；而一旦放回链路里，它才开始说明：端到端自动化正在从单点生成，走向系统性成立。

从当前结果看，我们大致已经走到这样一个位置：

在新增类、变更类需求中，这条链路已经具备了明确的可运行性，并且开始在真实业务研发里表现出稳定价值。AI 不只是“能写”，而是开始能在仓库上下文、历史实现、团队规范和工程约束之下，完成相当部分实际工作。

这和早期那种“写出一段像样代码”是两回事。

前者意味着，AI 已经进入真实研发流程；后者更多只是证明模型具备生成能力。两者之间真正拉开差距的，不是模型本身，而是上下文、边界、约束和验证。也正是这些部分，决定了一段代码到底是“看起来可用”，还是“可以进入真实仓库继续维护”。

更关键的是，这类结果不再主要依赖一次性把 prompt 拼对，而是链路本身开始具备了承接上下文、约束和验证要求的能力。

当然，这组结果也远远不意味着问题已经解决完毕。

对设计稿依赖更强、多模态信息更复杂的需求，当前仍然会受到工具能力、表达方式和上下文装配方式的限制。对跨页、多状态、交互联动更复杂的场景，稳定性也还需要继续验证。

所以，这次结果真正说明的，并不是“端到端自动化已经全面成熟”，而是：

在部分真实业务场景里，一条自动化链路已经开始成立。

这比“出码率提高了多少”更重要。因为数字是阶段性的，而链路是否开始成立，决定的是下一阶段到底该继续建设什么。

这里有一个很关键的问题：为什么过去我们也做出过一些局部结果，却没有形成今天这种“链路开始成立”的感觉？

答案不在结果表面，而在结果产生的方式。

过去不是没有结果。恰恰相反，早在 2025 年 3 月，我们就已经在新增类需求上做过一轮探索。当时主要依赖 Copilot 与人工组织 prompt、补齐上下文、指定实现边界，在一些场景里已经能拿到相当不错的产出。后续在变更类需求中，我们也不断看到，AI 在局部任务上已经具备了较强的可用性；而在 IdeaBox 这个真实项目中，这种可用性又进一步被验证，其中该项目还在公司 AI Hackathon 2025 中获得了开放技术赛道二等奖。

但这些结果有一个共同问题：它们高度依赖少数人的手工组织。

依赖人去判断哪些上下文该给、哪些规范要先说清楚、哪些边界要提前约束、哪些历史实现方式必须被带进执行阶段。一次成功，很多时候并不是系统稳定地产生出来的，而是靠熟悉业务、仓库和规范的人，把信息“拼”到一个刚好足够工作的状态。

这类探索当然重要。没有这些前期实践，就不会有今天这条链路的形成。它们让我们更早看到：AI 在真实研发里不是不能用，而是不能只靠“临场发挥”去用。

因为如果结果只能靠高手临场拼装出来，它就还不是真正的自动化能力。

这也是为什么，今天回头看，过去那种方式更像是在证明“局部场景里 AI 可以工作”；而我们现在真正要解决的问题，已经变成了：如何让它不再依赖少数人的手工组织，而成为一条可以被重复运行、被持续优化、被团队复用的链路。

这次实践真正不同的地方，不是模型突然跨过了某个神奇阈值，不是我们碰巧写出了一套更强的 prompt，也不是某个 Agent 一夜之间变得足够万能。真正的变化是：我们开始不再把需求原样直接扔给执行阶段，而是开始组织一条完整链路。

如果把这次变化压缩成一张图，大致就是下面这条链路：

先看输入端。

在真实业务研发中，需求本身往往带着大量对人默认成立、对系统却并不成立的省略。产品语言、设计表达、仓库现实、历史实现方式、团队规范，这些东西在人协作时可以靠背景默契补齐，但系统不会自动理解“差不多”的部分。

所以，需求不能再被简单理解为“一段自然语言描述”。它需要先经过输入治理和任务建模，被转成更稳定的任务表达。这里真正关键的，不是“多加了一层结构”，而是：当任务要进入执行系统时，它必须先从“人能看懂的大意”，变成“系统能承接的对象”。

再看执行端。

真实研发不是白纸作业。它发生在已有仓库里，发生在既有组件体系、工程结构、团队规范、接口约束和业务边界之中。离开这些上下文，模型当然也能生成代码，但那更接近“看起来像个答案”，而不是“可以进入真实仓库持续维护的结果”。

所以，这次执行阶段真正的变化，不是让 AI 写得更快，而是让它开始在更具体的工程环境中执行：带着 repo context，带着项目经验，带着约束和边界，带着更明确的任务对象进入实现阶段。

最后看验证端。

只要验证还停留在“人看一眼差不多就行”，自动化结果就更像一次性展示，而不是能进入组织级使用的能力。真正让一条链路开始成立的，不只是输入被表达清楚、执行被组织起来，更是结果开始被验证、被反馈、被修正。

也正因为输入、表达、执行、验证第一次被串成了链路，这次结果才和过去的局部成功不一样。它不再像若干高水平个体的“手艺合集”，而开始更像一种能够被持续运行的系统能力。

当这条链路开始成立之后，我们看到的，就不只是结果更好了，而是瓶颈本身发生了迁移。

第一个发现：结果提升不只来自模型能力，更来自链路能力。

模型当然重要，没有今天的基础模型能力，很多事情根本无从谈起。但如果把结果全部解释为“模型更强了”，那就会错过真正发生变化的地方。真实研发里的自动化效果，越来越不只是模型参数的问题，而是输入治理、任务表达、仓库上下文、执行约束和验证闭环共同决定的问题。

同样的模型，放在不同链路中，最后产出的稳定性和可用性会完全不同。能不能进入真实业务，不取决于它是不是在某个 benchmark 上更高，而取决于它是不是被放进了一套足够真实、足够具体、足够可验证的执行环境里。

第二个发现：当前瓶颈已经从“生成”迁移到了“稳定”。

今天真正难的，已经不是生成一段代码，而是稳定地产出一段符合历史仓库方式、符合团队规范、可维护、可验证、可继续演进的代码。这个“稳定”比“生成”难得多，因为它要求的不是一次对，而是反复对；不是看起来能跑，而是能长期落在真实系统里。

从这个角度看，软件研发里的关键约束，确实已经开始从“实现本身”迁移到“表达质量、上下文完备性、执行约束与验证能力”上。过去我们习惯把难点理解为“代码不好写”；而现在越来越多的难点，其实出现在“任务如何表达给系统”“边界如何被说明”“结果如何被约束和确认”这些位置上。

第三个发现：端到端自动化的核心，不是寻找一个更强的 Agent，而是组织一套可持续运行的执行链路。

这可能是这次实践带给我们最清晰的判断。单点 Agent 当然很重要，但它无法单独解决真实业务里的复杂约束。真正让自动化开始成立的，不是某个万能执行者的出现，而是输入、表达、执行、验证被放进了一个能够反复运行的结构里。

换句话说，端到端自动化真正建设的对象，不再只是“一个会写代码的工具”，而是“一个能把研发流程组织起来的系统化链路”。

这也是为什么，到了今天，我们越来越不把注意力只放在“再找一个更强的模型”上，而开始把重点放在另一类问题上：输入如何更稳定，任务如何更清晰，执行如何更受控，验证如何更自动，反馈如何真正进入链路本身。

从这个意义上说，这次实践最重要的意义，不是让我们拿到一个 90% 的结果，而是让我们第一次更清楚地看到：端到端自动化，正在从判断走向成立。

它当然还远不是终局。设计稿、多模态、复杂交互、更广场景覆盖、更高稳定性、更强验证能力，这些都还是接下来必须继续解决的问题。甚至可以说，真正更难的部分，现在才刚刚开始。

但这次结果已经足够说明，软件研发里真正值得建设的对象，正在发生变化。

接下来真正需要回答的问题，已经不再是“AI 能不能写代码”，而是：

我们如何把这条链路做成一个稳定、可验证、可持续运行的系统。

而这，也正是下一篇文章想继续展开的部分：当我们不再把原始需求直接交给执行阶段，而开始从多源输入、任务表达、上下文装配、执行组织和验证闭环去理解研发流程时，这条端到端自动化链路，到底是如何被搭起来的。