All You Need Is Skill：端到端自动化的 MVP 闭环是如何跑起来的

前两篇文章里，我们分别回答了两个问题：端到端自动化到底验证了什么《出码率到 90% 之后，我们真正验证了什么？端到端自动化的第一次真实落地》，以及 90% 出码率是如何被组织出来的《90% 出码率是怎么来的？我们如何把研发任务组织成可运行的自动化链路》。继续往下走，一个更具体的问题开始变得绕不过去：这条链路在 MVP 阶段，到底是靠什么真正跑起来的？

如果只看表面，答案似乎是 Workflow、是 Agent、是模型能力；再往前一步，也可能会被归结为 Context Engineering、Harness、长时执行这些新的系统化能力。但真正进入实践之后，我们越来越清楚地看到，难点并不只是“把代码写出来”，也不只是“把流程串起来”，而是如何把 PRD、设计输入、API、仓库现状、团队规范、历史实现这些分散的信息，组织成一个可执行、可推进、可中断、也可恢复的系统。

对我们来说，MVP 阶段最关键的，不是先做一个庞大的平台，而是先找到一个足够轻、足够稳、又能承接这些约束的最小组织单元。这个单元，就是 Skill。

如果只是把 AI Coding 理解成“把一句需求丢给模型，然后等它把代码写出来”，那很多真实问题很快就会暴露出来。

首先，真实研发任务从来不是单一输入。一个需求背后，往往同时涉及 PRD、设计稿、图片、接口文档、代码仓库、业务知识、编码规范，甚至还包括历史实现方式。它不是一个 prompt 能天然装下的东西，而是一组需要被理解、筛选、重组的信息源。

其次，上下文窗口并不是无限的。信息一多，模型就开始漂移；内容一杂，指令边界就会变模糊。很多时候，问题不是模型不会写，而是还没开始写，上下文就已经被无效信息吞掉了。你把所有材料一股脑塞进去，看起来像是在补充上下文，但在实践里，常常更接近于把任务重新推回混乱。

再进一步，即便是今天已经比较成熟的 spec / workflow 方式，也只是把“生码流程”组织了起来。它能让步骤变得可见，但并不天然等于任务就被真正组织好了。因为每一个节点内部，仍然会继续面对那些熟悉的问题：上下文限制、信息选择、边界模糊、Agent 该不该主动补全、什么时候应该停下来问人。流程被画出来了，不代表任务已经被系统化了。

所以，端到端自动化真正难的地方，从来不只是“怎么生成代码”，而是：怎么把这些分散输入，先收敛成一个能被系统持续处理的任务。 如果这个问题不先解决，后面的执行、验证、修复都会变得脆弱。你可能偶尔也能把代码写出来，但它很难稳定，也很难复用，更谈不上规模化。

回头看我们自己的 MVP 验证，最关键的一步并不是模型突然更强了，而是我们开始认真处理一件过去经常被忽略的事：任务在进入执行之前，必须先被组织。

也正是在这个背景下，Skill 在我们的实践里，逐渐不再是一个“提示词集合”，也不是一个零散的工具目录。

它更像是一种行为契约。

一个 Skill，不只是告诉 Agent “这件事可以怎么做”，还会同时定义很多更关键的东西：什么输入可以接受，什么产物必须输出，哪些边界不能越过，哪些节点必须暂停，哪些问题一定要回到用户确认之后才能继续。换句话说，Skill 在这里承担的，不只是能力调用，而是行为约束和系统组织。

当我们把 Skill 放到整个链路里再看，这个角色会更清楚。

在这套 MVP 实践里，Skill 并不是平铺的一组能力，而是被分成了几层：有的负责在开发前建立 AI 可以消费的项目知识和开发指导；有的负责把需求推进成结构化任务，再推进到代码生成；还有的负责路由、状态推进，以及约束所有 SubAgent 的执行方式。也就是说，Skill 在这里并不是“一个功能点”，而是一种能够把不同阶段、不同职责、不同边界串起来的组织结构。

这也是为什么，我更愿意把它理解成端到端自动化 MVP 里的“最小组织单元”。

它足够小，不需要一开始就先做一个庞大的平台；
它又足够稳，不只是把能力暴露出来，而是把能力的边界、输入输出和协作方式一起定义出来；
更重要的是，它足够贴近真实工程问题。因为当任务真正进入系统时，我们需要的从来不是一个“更会说话的 Agent”，而是一套能把多源输入、任务建模、执行与人工决策点稳定组织起来的骨架。

从这个意义上说，Skill 之所以重要，不是因为它比 prompt 更高级，也不是因为它比 workflow 更时髦，而是因为它第一次让我们在 MVP 阶段看到了这样一种可能：端到端自动化并不需要一开始就长成终局系统，它也可以先依靠一组被明确定义、能够稳定协作的 Skill，形成一个真正可运行的闭环。

当一条需求真的开始往端到端自动化链路里走时，AI 最大的问题，往往不是不会写，而是不知道这个项目里到底该怎么写。

你问它一个具体问题，比如某个页面点击一个按钮之后，完整链路会发生什么。没有项目知识时，它通常会给出一套“方法论式”的回答：去找点击事件、去看跳转逻辑、去追接口调用。这个方向当然不算错，但它回答的，其实只是“通常应该怎么查”，而不是“你的项目里真实发生了什么”。

而真实项目最难的部分，恰恰不在方法论里。
同样一个功能，在不同项目里可能走完全不同的链路；某些逻辑看起来还在代码里，实际上已经废弃；某些渲染条件并不写在当前页面，而是依赖某个历史字段、埋点参数，或者灰度开关。也就是说，项目理解从来不是通用常识问题，而是上下文资产问题。

所以，项目知识不能靠每次临时补上下文，它必须被显式管理，变成一种能够被 AI 稳定消费的前置能力。对我们来说，这就是“项目知识 Skill”要解决的问题。

如果再说得更直接一点，我们后来其实接受了一个很重要的判断：源码不是最终交付物，知识才是。

当然，这里说的“知识”，不是把源码人工转述一遍。它不是“给代码写文档”，而是从源码中抽取出更适合 AI 使用的结构：页面职责是什么，入口和出口在哪里，哪些字段驱动展示，某个交互失败时会怎么兜底，出问题时应该先看哪几个文件。源码仍然是最原始的事实来源，但在大多数场景里，真正被系统消费的，已经不再是源码本身，而是从源码提炼出来的知识层。

这也是“项目知识 Skill”最有价值的地方。
它让 AI 不再每次都从零开始“读项目”，而是先拥有了一层可以路由、可以索引、可以回答的项目记忆。没有这层记忆，后面的 Task IR 很容易只是一个脱离项目现实的抽象表示；有了这层记忆，任务建模才开始真正贴近“这个项目里的真实约束”。

但只把基线知识做出来，还远远不够。因为代码是持续变化的，知识也必须跟着变化。否则，项目知识很快就会从资产变成误导：它看起来像真相，实际上却悄悄过时了。

也正因为这样，我们后来并没有把项目知识理解成一次性生成物，而是把它看成一个需要持续演进的对象：有第一次的完整生成，有开发过程中的增量更新，也有合并后的语义覆盖。这里面很关键的一点是，知识不能像日志一样机械追加；如果旧描述已经不准确了，就必须被新的语义覆盖，而不是在后面补一句“后来改过”。否则文档是越来越长了，系统却会越来越混乱。

这背后其实还有一个非常重要的工程边界：脚本做结构，SubAgent 做语义。
脚本适合建目录、跑 diff、校验格式；但一旦进入“这段旧知识是否已经失效”“哪一部分应该被覆盖”“这次改动真正影响了哪个页面职责”这种问题，就不能再靠规则去硬套了。知识之所以能够长期维持可用，不是因为脚本更复杂了，而是因为语义判断被明确交给了具备上下文理解能力的 SubAgent。

回头看，项目知识 Skill 的意义，并不只是“给 AI 多喂一点资料”。它真正做的，是把项目理解从一次性的 prompt 消耗，变成了一个可以被系统反复调用的前置能力。也正是从这里开始，端到端自动化才第一次拥有了一种更稳定的“项目记忆”。

如果说项目知识 Skill 解决的是“AI 如何真正理解这个项目”，那接下来另一个更有意思的问题就是：这些 Skill 本身，是怎么来的？

一开始，很多人对 Skill 的理解，可能还是“把某类经验封装起来，供 Agent 调用”。这当然没问题，但当我们真的把它放进一条持续运行的研发链路里时，很快就会碰到新的边界：如果每一个 Skill 都要靠人工手工写、手工整理、手工维护，那它很快就会成为新的瓶颈。尤其是像项目知识、开发指导这种东西，本身就带有很强的项目依赖和持续演进特征，它不可能只靠一次性沉淀来维持。

于是，问题自然往前走了一步：我们能不能不只消费 Skill，而是开始生产 Skill？

也就是在这个阶段，Generator Skill 这层东西才真正变得重要起来。

在我们的实践里，Skill 后来逐渐分成了两类：一类是直接使用型 Skill，它直接告诉 Agent 如何完成某件事；另一类是 Generator Skill，它本身并不直接完成业务，而是负责生成另一种可以被反复调用的 Skill 产物。比如，项目知识 Skill 和开发指导 Skill，本质上都不是靠人每次手工现写，而是由对应的 Generator 生成出来的。换句话说，Generator 的输出不是业务结果，而是另一层可复用能力本身。

这件事为什么重要？因为它意味着系统开始从“调用能力”走向“生产能力”。

以前，一条链路能不能跑，更多取决于人有没有把 prompt 写好、有没有把经验补全；
而有了 Generator 之后，系统开始具备一种新的自我扩展方式：当某类项目知识还不存在，或者已经过时，它不必完全依赖人工先把这些材料补齐，而是可以在合适的时机触发生成过程，把新的知识 Skill 生产出来，再交给后续环节使用。

但这里真正难的地方，不是“让它生成一点文档”，而是让它生成的东西，后续还能被系统稳定使用。

所以，Generator Skill 和普通 Skill 最大的不同，不只是“多了一步生成”，而是它必须对产物负责。它不能只产出一堆零散内容，而要定义清楚输入参数、模式选择、产物结构、职责边界，以及后续消费方如何读取它。也正因为这样，我们后来越来越重视另一件事：Generator 的输入必须是结构化的，而不能是一个模糊请求。它需要知道现在是全量生成、增量更新还是合并覆盖，目标仓库是什么，作用范围是什么，输出应该落到哪里。只有这些条件明确了，后续产物才会稳定。否则，Generator 只是把不确定性从业务环节提前到了能力生成环节。

再往深一点说，Generator Skill 的价值，还在于它让“标准化”这件事第一次真正落地了。

如果每个项目知识 Skill 的目录结构、文件职责、命名方式都不一样，那后续的 SubAgent 每次使用前都得重新猜结构，可靠性会迅速下降。Generator 的存在，恰恰是把这些产物标准固定下来，让能力第一次具备了规模化复用的可能。也就是说，它不是单纯提高效率，而是在做一件更底层的事：把本来依赖人工经验维持的能力，转成可持续生产、可稳定消费的系统对象。

当然，到了这里，边界问题依然存在。
Generator 也不是万能的脚本工厂。它内部同样需要区分：哪些部分由脚本处理，哪些部分必须交给 SubAgent 做语义判断。前者适合目录初始化、diff、格式校验；后者才适合理解变化、判断旧知识是否失效、决定哪一段应该被覆盖。也正因为这个边界被明确了，Generator 才没有变成一个“自动生成很多文字”的工具，而是真正成为了系统里“生产能力”的一层。

如果回头看，这一层实践其实很值得单独记一下。
因为它意味着，Skill 驱动不再只是“我们有一套 Skill 可以用”，而是开始变成：我们可以持续地生成新的 Skill，让系统在运行中不断补齐自己的能力结构。

这跟普通的 prompt 复用、模板沉淀，其实已经不是同一层事情了。
前者还是在消费已有经验，后者则开始让经验本身，变成一种可以被生产、被维护、被反复调用的能力对象。

也正是从这里开始，这条 MVP 链路才第一次显出一点“系统”的样子。

如果说前面几节回答的是：为什么端到端自动化在 MVP 阶段需要 Skill、为什么项目知识要被显式管理、为什么我们甚至开始用 Generator 生成 Skill，那么接下来更具体的问题就是：一条真实需求，究竟是怎么在这套系统里被推进下去的？

在我们的实践里，这条链路不是“从需求直接跳到代码”，而是被拆成了几个边界清晰的阶段：W0 做前置检查，W1 处理原始输入，W2 生成 Task IR，W3 进入代码生成，最后再补上一个轻量的 W4 Review，形成闭环。真正重要的，不是步骤被分成了五段，而是每一步都开始拥有明确的输入、产物、暂停点和责任边界。

W0 的价值，是把“执行准备”从隐性前提变成显式环节。它检查的不只是项目知识 Skill 和开发指导 Skill 是否已经存在、是否仍然有效，也检查输入侧是否达到最基本的推进条件：PRD 是否存在，设计输入是否齐全，接口资料是否具备。很多链路之所以越跑越歪，往往不是 W3 写错了，而是 W0 根本没准备好。

W1 和 W2 则是在做真正的收敛。
W1 不直接进入代码生成，而是先把原始输入整理成可消费的结构化材料；W2 再把这些材料收敛成 Task IR，让任务第一次从“材料集合”变成“执行对象”。也正是在 W2，系统会明确暴露澄清问题，并在这些问题没有闭环之前强制暂停。这里的关键不是多了一个步骤，而是系统终于开始承认：有些边界、范围和风险，不能靠模型“顺着往下做”来解决。

到了 W3，代码生成才真正开始。
它读取的已经不是原始需求，而是被冻结下来的 Task IR，并在开发指导 Skill 的约束下进入实现路径。也正因为前面的准备和收敛已经完成，代码生成才第一次拥有了稳定输入。

W4 则补上了一个轻量但必要的闭环。它不只是“看一眼代码”，而是把结果重新拉回到需求与实现之间：功能是否对上，设计意图是否落地，实现做到什么程度，还有哪些差异、风险和待补项需要被显式说明。

回头看，这条 W0 到 W4 的链路之所以能跑，不是因为流程被画出来了，而是因为不确定性第一次被分阶段地收敛了。

如果要再往下追问一句：这条链路为什么不是偶尔跑通一次，而是开始具备某种稳定性？答案并不是“因为模型更强了”，甚至也不是“因为 Skill 更多了”，而是：因为边界终于开始被认真定义了。

这里面最典型的一个判断，就是主 Agent 的克制。
在这套系统里，主 Agent 被刻意做得很“笨”。它只读状态，只做四件事：读状态、拼 Prompt、启动 SubAgent、展示结果。它不读业务文件，不做业务分析，也不直接碰代码和 PRD。这不是能力不足，而是一种明确的收权。因为一旦主 Agent 进入业务内容，它就会开始被内容牵着走：看到需求就想多做一步，看到代码就忍不住分析，看到信息缺失就试图自发补逻辑。这样一来，它的角色会迅速从“路由者”滑向“全能代理”，而系统边界也会随之变模糊。

与之相连的，是另一个很重要的设计：步骤之间只传路径，不传内容。
这看起来像一个很小的工程实现，但其实背后是非常关键的系统判断。因为一份完整的 ai-prd.md 可能非常长，如果上一步把整份内容直接注入给下一步，还没开始分析，上下文就已经被吞掉一大块。所以，系统在阶段之间传递的，不是“把所有信息都带过去”，而是稳定的产物路径和引用关系。谁需要什么，就按需打开、按需读取。这也是为什么我一直觉得“路径是接口契约，文件系统是上下文缓冲层”这句话特别重要：它让上下文第一次从“模型记忆负担”，变成了“系统可以调度的外部结构”。

再往下看，SubAgent 的角色也不是简单的“多开几个模型”。
它真正重要的地方在于：它天然提供了一种上下文隔离和职责切分机制。每个 SubAgent 只看自己那一份输入，只产出自己那一份结果，互不干扰。也正因为这样，系统才有可能真正并行：W1 可以把多张设计图拆开分别处理，W3 可以在互不冲突的前提下并发生成不同代码任务，项目知识生成也可以按页面拆成多个子任务。这里的关键从来不是“并行数有多大”，而是任务是否被切得足够小，边界是否声明得足够清楚。没有这一层，所谓并行很容易变成上下文污染和结果冲突。

还有一个特别容易被忽略，但我觉得反而最重要的点：给 Agent 主动性，不等于让它越权。
好的主动性，不是模型自作主张地替系统补逻辑，而是在协议约束下及时暴露问题、触发恢复、把缺失的前提重新抛回系统。当跳过中间步骤直接推进代码生成时，SubAgent 在执行中发现必需产物缺失，会主动阻塞并把问题返回给主 Agent；而主 Agent 因为上下文极小、角色单纯，反而更容易识别缺少什么，再重新调用、补齐路径，而不是机械重试。这个例子特别能说明：收权不是让系统更僵，而是让系统在边界清楚的前提下，拥有更好的恢复能力。

最后，还有一条必须保留：用户决策点必须显式暴露。
AI 很擅长分析、生成、执行，但任务边界、风险决策、范围确认这些事，不能靠它在运行中“顺便理解”。哪些地方必须暂停，哪些问题必须回到人，必须被事先写进系统。也正因为这样，这套 MVP 链路最可贵的一点，不是它在追求“全自动”，而是它开始认真对待“可控自动化”。对真实研发场景来说，后者其实比前者重要得多。

所以回头看，这条链路真正稳定下来的原因，既不是模型突然变得无所不能，也不是系统堆了更多能力，而是它开始接受一个更朴素、但也更工程化的事实：系统的可靠性，来自边界的清晰，而不是来自智能的幻觉。

主 Agent 收权，SubAgent 专注，路径承担接口契约，用户掌握决策点——这些东西看起来都不算“炫技”，但恰恰是它们，让端到端自动化第一次有了真正能持续运行的样子。

这篇写到这里，MVP 为什么能跑起来、以及为什么它是有效的，基本算是交代清楚了。

再往后，问题就会变成另一种：不是“能不能跑”，而是“如何评估它、对比它，建立 benchmark，推进后续产品化建设，并把它带向规模化”。这也是我接下来更想继续写的部分。