AI-First 产研团队的交付路径

指标：AI 初稿准确率。

底座：上下文工程 (L0/L1/L2三层收敛）。

载体：Skill-as-Code—把团队规范和工作方法硬编码为可版本管理的工程资产。

AI 编程之后，管理者要面对的是一个更具治理意义的判断：为什么同样使用模型，不同团队的产出质量会出现显著差异？

差异的根源不在模型能力，而在于 AI 所获得的上下文质量。上下文充分且精准时，第一版初稿往往已接近可交付标准；上下文残缺或含混时，AI 的产出更像基于有限信息的推测，返工成本随之上升。

这张图描述的，是一套围绕上下文工程构建的 AI-First 团队工作模式。它的目标是把 AI 编程从依赖个人经验的"玄学"，拉回到可管控、可度量、可复制的"工程学"。底层逻辑只有一条：上下文即资产——谁能持续向 AI 提供高质量、可执行的上下文，谁就越能降低输出波动，提高初稿可用率，并让交付过程更可控。

初稿准确率是AI协作的前置变量之一

在评估 AI 协作效果时，代码行数和生成速度都不是可靠指标。更值得优先观察的，是一个更朴素的度量：AI 生成的第一版初稿，有多大比例可以进入审查流程，或仅经少量调整后即可交付。

这个指标直接关联 AI 协作的真实 ROI。初稿准确率高，人的精力更多用在审查和决策上；初稿准确率低，人的精力则会持续消耗在返工和修补上。很多团队引入 AI 后体感"快了但不稳"，本质上就是这个指标波动过大——标准化场景尚可，业务规则复杂的场景则产出质量骤降。

初稿准确率由什么决定？同一个模型，接收一句模糊描述和接收完整的技术方案、编码规范、数据模型、业务规则与参考实现，产出质量完全不同。模型能力是固定的，但上下文质量是可工程化管控的。

上下文工程，即用系统化的方法管理 AI 在每个任务中所获取的信息质量，从而降低输出波动，提高首稿可用率。 但需要补充说明的是，首稿可用率解决的是"第一次产出是否足够接近交付标准"，验证闭环解决的是"最终交付是否可验证、可修复、可回滚"。二者共同构成 AI 协作的治理基础。

六段式交付闭环: 上下文逐级收敛与同步更新

这张图将交付链路拆为六个阶段。如果只看动作名称——需求、PRD、方案、拆解、编码、更新——很容易将其理解为一条普通流程线。但从架构视角看，这六个阶段的核心逻辑不是线性流程编排，而是上下文逐级收敛、阶段持续校验、结果最终回写。其中前两个阶段本质上是产研协同对业务意图、边界条件和验收口径的显性化，后四个阶段则由研发侧将这些约束转化为可执行的工程资产和交付结果。

注意"隐性上下文"这一列：每个阶段的显性产出是给人审查的，而隐性上下文才是下一阶段 AI 的真正"燃料"。 需求阶段提供业务意图，PRD 阶段将意图转为结构化约束，技术方案阶段将约束收敛为技术决策，任务拆解阶段再将决策压缩为最小执行单元。到 Daily Coding Agent 阶段，AI 拿到的已不是一个模糊需求，而是一份高度收敛的任务上下文——初稿准确率高，正是因为主要不确定性已在前置环节被逐步消化。

因此，这六个阶段更准确地说不是瀑布式串行推进，而是一个"前置收敛、阶段校验、结果回写"的交付闭环。最后一个阶段"上下文更新"负责闭合整个循环：代码变更后上下文同步刷新，确保下一轮迭代时 AI 的输入不会过时。

上下文工程：知识库与分层加载

流水线是交付动作的组织方式，上下文工程则是支撑这些动作的基础设施。它由两部分组成：系统知识库与分层加载模型。

系统知识库

知识库的作用是将团队积累的系统事实显性化。它需要同时覆盖业务与技术两个面向：

两者之间通过共享术语表打通，确保 AI 在生成内容时，业务概念与技术实现使用同一套语义。

知识库的价值常被低估。AI 真正需要的不是代码本身，而是代码背后的业务规则、边界约束和设计意图。这些信息如果只存在于少数核心成员的经验中，AI 便无法利用，新成员也无法快速继承。知识库的完整度，直接决定了 AI 理解业务的深度，也决定了首稿在业务逻辑层面的可用程度。这里的知识库也不应被理解为研发单方面的整理结果，业务负责人和产品经理同样需要对业务流程、状态口径、例外场景和验收标准承担持续维护责任。

三层加载模型

知识库解决的是"有没有"，加载模型解决的是"怎么给"。这张图采用 L0（项目级）、L1（文件级）、L2（任务级）三层模型，分别解决全局一致性、局部适配和单次任务准确率的问题。三层模型的设计原理与实践细节已在此前文章中详述，此处不再展开。

核心原则只有一条：在对的层级，把对的信息，以对的颗粒度，交给对的执行环节。

上下文工程为什么应被视为组织级投入

上下文工程不是技术团队的内部优化，它直接影响交付效率与质量。

第一，它决定了 AI 投入能否产生实际回报。上下文质量不足，初稿准确率上不去，返工成本不会下降。

第二，它是团队能力的沉淀载体。知识库和上下文规则建立之后，人员流动对团队的冲击会显著减小。

第三，它具备复利效应。上下文越完善，AI 产出越准确，人的审查成本越低，团队便有更多精力持续完善上下文——这是一个正向循环。反之则是负向衰减。

Skill 体系：上下文工程的可复用封装

上下文工程的落地面临一个现实问题：如何让它在团队中可复用、可标准化、可规模化。Skill-as-Code提供了一种可行的封装思路：把团队的工作方法与质量约束写成可版本管理的文本契约，而不是散落在聊天窗口里的一次性指令。

Skill 的定义

Skill 本质上是结构化的契约文件——约定在何种场景下触发、加载哪些上下文、按何种步骤执行、产出应满足何种标准、以及哪些边界不可逾越。落地时通常以仓库中的 Markdown 或类 Markdown 文件承载，例如 Claude Code 生态中的 `SKILL.md`、Cursor 中的 `.mdc` Rules 等；不同工具的文件名与目录约定不同，但契约内容（触发条件、上下文装配、流程、输出标准、约束）是可迁移的。它与普通 Prompt 模板的本质区别在于：它将上下文加载策略、执行流程与质量约束封装为“可评审、可 diff、可回滚”的工程资产，而不是一段不可追溯的自然语言。

流水线中的核心 Skill

对照图中六个阶段，整条流水线由以下 Skill 驱动：

• write-prd Skill：输入需求文档、沟通记录与知识库，输出包含功能目标、业务规则、异常场景和验收标准的结构化 PRD。Skill 明确要求 AI 从知识库提取相关领域知识，而非凭空推测。

• write-tech-design Skill：输入 PRD、知识库与项目上下文，输出技术方案与接口契约。自动加载 L0 层架构文档与技术规范，确保方案不偏离项目整体架构。

• breakdown-tasks Skill：输入技术方案与上下文，输出可独立执行的 WBS 任务单元，每个任务包含明确的输入、输出、依赖和验收标准。

• 编码 / 单测 / CR Skills：三者在 Daily Coding Agent 中协同运作，形成"编码→单测→CR→修复"的自动闭环。编码 Skill 加载 L0 + L1 + L2 三层上下文；单测 Skill 自动补全测试用例；CR Skill 对照编码规范与架构约束做结构审查。

• update-context Skill：每轮开发完成后，自动将模块变更、接口变更、新增业务规则等回写到知识库。这个环节的价值不仅是"跟上新代码"，更在于通过 AI 自动逆向梳理，将那些埋在旧代码中的业务孤岛——未文档化的规则、隐式的状态流转、散落的边界约束——重新结构化，回写到知识库中。上下文更新既是"建新城"的闭环，也是"还旧账"的路径。没有这个闭环，知识库会逐渐滞后于代码现实，初稿可用率也会随之下降。

Skill 的工程价值

Skill 在团队层面解决了三个问题。

标准化：同一个 Skill 由不同工程师调用，AI 的产出结构与质量保持一致，消除了对个人 Prompt 水平的依赖。

可复制：Skill 以文件形式存在，可跨项目复用，团队的 AI 协作能力从个人经验转化为组织资产。

可度量：每个 Skill 的输出是明确的——PRD 的结构完整度、技术方案的可执行性、代码的 CR 通过率——可以针对具体环节追踪初稿准确率，定向优化。

但 Skill 更深层的价值在于治理。

Skill 本质上是团队规范的硬编码——以前靠 Code Review 事后指出的规范问题（命名风格、异常处理策略、分层约束），现在通过 Skill 在代码生成阶段就被强制收敛。这不仅是效率的提升，更是架构一致性的前置保障。当 Skill 覆盖了从 PRD 到代码到上下文更新的全链路，团队规范就不再依赖人的自觉和记忆，而是被固化到 AI 的执行过程中。

Agent 执行：在约束下运行的自动化单元

Skill 定义了执行方法，上下文提供了执行所需的事实，两者组合构成 Agent 执行任务的完整条件。

Daily Coding Agent 的理想工作方式不是自由发挥，而是在精确的上下文与 Skill 约束下完成闭环：读取任务级上下文 → 生成代码 → 补全单测 → 结构审查 → 修复显性问题 → 

回写变更。人在这个闭环中承担的，不是"永远审对"的职责，而是核心业务逻辑、架构边界与最终风险责任的判断。

这里需要特别说明：这套体系并不建立在"人永远比 AI 正确"的假设上。人同样会遗漏问题、误判风险，也不可能穷尽所有细节审查。工程治理真正要做的，不是让人去补救 AI 的全部不确定性，而是通过上下文工程、验证闭环和执行边界管理，把 AI 的输出波动控制在可验证、可修复、可回滚的范围内。AI 的非确定性不会消失；团队能做的，是把这种非确定性从不可预期的风险，收敛为可管理的工程变量。

当任务拆解得足够独立时，多个 Agent 可以在各自的分支上并行工作。但并行的前提仍然是上下文工程的质量：L0 缺失则风格分裂，L2 模糊则需求偏离。并行放大的不只是效率，也包括上下文缺陷的后果。

从架构角度看，知识库、分层加载、Skill 和 Agent 是一个整体：知识库提供事实，分层加载负责装配，Skill 定义方法，Agent 完成执行。更抽象地说，这是一套围绕模型构建的外围执行框架：模型负责推理，框架负责提供工具调用、上下文管理和执行环境。在业界，这类组合通常可以统称为 Agentic Harness；在 Claude Code 的语境里，也沿用这一叫法。模型决定了"能力上限"，Harness 决定了"实际产出"。换言之，本文所讨论的上下文工程、Skill 体系和验证闭环，本质上就是在构建团队自己的 Harness。模型是公共资源，Harness 才是团队的私有竞争力。

工具生态的求同存异：底层逻辑正在收敛

这套工作模式并非绑定某一款工具。事实上，当前主流 AI 编码工具在底层架构上正在显著收敛。

• Claude Code 提供了 Skill（SKILL.md）+ Agent + Plan 模式的组合。

• Cursor 提供了 Rules（.mdc）+ Agent 模式 + Background Agent 的组合。

• Codex CLI 更强调规划、执行与验证的分离。

• Kiro IDE 原生内置 Spec 驱动开发。GitHub Spec Kit 则以开源工具包的方式，将 Specify → Plan → Implement → Review 流程标准化。

表面上各有差异——Claude 偏终端自治，Cursor 偏 IDE 集成，Codex 偏受控执行，Kiro / Spec Kit 偏规范先行——但如果拆开底层机制，它们正在解决的是同一组问题，也正在趋向同一套架构。

从业界最佳实践看，它们的共同趋势主要体现在四个方面：

• 结构化上下文注入：不再依赖一次性 Prompt，而是通过 Skill、Rules、Spec、项目记忆文件等机制，持续注入团队知识、规范和约束。

• 先规划再执行：先探索、先收敛不确定性，再进入实现阶段，已经成为复杂任务中的通行做法。

• 执行与验证分离：编码、测试、审查、修复被明确拆分，避免把"能生成"误当作"可交付"。

• 结果持续回写：无论是回写知识库、更新规则文件，还是维护 Spec，目标都是让后续任务复用已沉淀的上下文资产。

如果按实现路径来区分，则可以看到更清晰的差异：

• Claude Code 更强调以终端为中心的自治式协作，通过 Skill、Plan 模式和多代理机制支撑长链路任务执行。

• Cursor 更强调 IDE 内的人机协同，通过 Rules、Plan 模式、Background Agent 和工作区上下文实现高频交互。

• Codex CLI 更强调受控执行与环境隔离，将规划、执行、验证拆开，适合对运行边界要求较高的团队。

• Kiro / GitHub Spec Kit 更强调规范先行，将 Spec 作为长期有效的任务约束和团队共识载体。

"求同"在于：所有主流工具都已认识到，模型能力不是唯一瓶颈，上下文组织、验证闭环与执行边界管理才是决定交付质量的关键。无论叫 Skill、Rules 还是 Spec，本质上都在做同一件事：将团队知识、规范和工作方法，以结构化方式注入到 AI 的执行过程中。

"存异"在于：不同工具在交互范式、自治程度和安全边界上的取舍不同。这种差异决定了它们分别适合何种团队、流程和治理要求，但并不改变底层方法论的趋同。

对团队而言，理解这一层"求同存异"的意义在于：上下文工程的投入具有跨工具迁移性。 知识库、编码规范、架构约束、术语体系、任务模板——这些资产并不依赖某一款工具的专有格式。与其在工具选型上反复纠结，不如优先把上下文资产建起来。工具可以调整，资产可以迁移，而上下文质量、验证能力和治理机制带来的交付改善，会沉淀为团队自己的长期能力。

结 语

模型能力正在快速趋同，工具生态正在加速收敛。在这个背景下，AI-First 团队需要建立一套可持续的工程治理体系——知识库是否完整、上下文加载是否精准、Skill 是否成熟、验证闭环是否可靠、执行边界是否清晰。

初稿正确率的稳定提升，是 AI 从"效率工具"转变为"组织能力"的分水岭。而上下文工程，就是通过这条分水岭的路径。