作者：Lei阅读 --

从 Agent 供给工程到设计即交付：三份 AI 研发规范背后的生产线逻辑

结合论文与 KaiHub、Echo Builder、设计上下文、物料渲染等实现，解读 Skills & MCP、提示词与上下文工程、D2D 如何组成公司级 AI 研发生产线。

AIAgentMCPSkillsContext EngineeringD2DAI Engineering

从 Agent 供给工程到设计即交付：三份 AI 研发规范背后的生产线逻辑

如果只把这几份规范当成制度文件读，很容易读散：

  • 一份讲 D2D，设计稿怎么解析、匹配物料、生成 Schema、出码、测试、验收、发布。
  • 一份讲提示词与上下文工程，系统提示词、用户提示词、RAG、会话上下文、Token 窗口、幻觉抑制怎么治理。
  • 一份讲 Skills 与 MCP，Skill 怎么开发、MCP 怎么接入、能力怎么上架到统一 Hub。

但它们真正指向的不是三块独立工作，而是一条新的 AI 研发生产线：

能力供给 -> 行为控制 -> 场景交付 -> 质量回流

也就是说，我们不是在讨论“怎么更会用大模型”，而是在讨论一件更具体的事：

如何把 AI 从个人效率工具，变成公司级、可治理、可复用、可验收的交付能力。

这篇文章想换一种读法：不按章节编号讲，而是把三份规范放进一个统一框架里看。对应到学术研究，这条线也非常清楚。ReAct 和 Toolformer 说明模型需要和外部工具协同；RAG、Self-RAG 和 Lost in the Middle 说明上下文不能随便堆；SWE-bench 和 Design2Code 说明真实软件交付远不止“生成一段代码”；Reflexion 和 CRITIC 则说明 AI 系统必须接入反馈、测试和修复闭环。

这些论文不是为了给规范贴金。它们共同证明了一件事：AI 工程的关键对象，已经从“模型调用”转向“可控的交付系统”。

为了避免这篇文章只停在概念层，我也会穿插当前工程里的实现线索。这里有两类内容需要区分：

  • 已实现的工程骨架：来自 KaiHub、设计平台、MasterGo 插件、Echo Builder、本地 AI 客户端、物料组件库等项目里的现有模块。
  • 建议补齐的闭环设计：当前项目已经有部分基础，但如果要完全达到 D2D 规范，还需要继续产品化和平台化的环节。

换句话说，本文不是只讲“应该怎样”，也会讲“现在已经怎么做”，最后再讲“还差哪几块才能闭得更完整”。

一、为什么不能只讲“AI 提效”

过去很多团队使用 AI 的方式，是把它当成聪明的个人助手：写点代码、改点文案、解释一下报错、生成几个测试用例。这当然有价值，但它只能提升个人局部效率，不能自然变成组织能力。

组织级 AI 研发至少会遇到四个问题。

第一，能力从哪里来？

一个 Agent 要完成真实任务，不能只靠模型参数里的知识。它要会调用模型、读文件、查知识库、操作设计稿、生成代码、跑测试、部署预览、发起审批。ReAct 提出的核心模式就是让语言模型交错地“推理”和“行动”：推理负责计划、跟踪和处理异常，行动负责访问外部环境。Toolformer 进一步说明，模型可以学习什么时候调用工具、传什么参数、如何使用工具返回结果。换到工程语言里，这就是 Skills 与 MCP 要解决的问题：把外部能力标准化地供给给 Agent。

第二，Agent 怎么稳定地做事？

同样一个模型，给它不同的提示词、不同顺序的上下文、不同质量的检索材料，输出会完全不同。RAG 证明了外部知识检索能提升事实性，但 Self-RAG 又提醒我们，检索不是越多越好，模型需要判断什么时候检索、检索结果是否有用。Lost in the Middle 则进一步说明，长上下文并不等于模型能稳定使用全部上下文，关键信息的位置和组织方式都会影响结果。换到工程语言里，这就是提示词与上下文工程要解决的问题：不要把输入当成一段 prompt，而要把它当成一次可治理的信息装配。

第三，生成结果怎么进入真实交付？

前端页面不是一张截图，也不是一段 HTML。它涉及设计规范、物料组件、交互逻辑、响应式布局、代码结构、测试、验收和发布。Design2Code 这类研究已经把“视觉设计转代码”做成了 benchmark，结论也很现实：多模态模型虽然已经能生成前端代码，但在视觉元素召回和布局设计上仍然有明显短板。换到工程语言里，这就是 D2D 要解决的问题：不能幻想模型一次性从设计稿吐出完美页面，必须用物料、Schema、测试、人工回流和验收卡点把生成能力嵌进交付流程。

第四，失败后怎么回流？

真实软件工程不是一次生成，而是理解任务、修改代码、运行测试、观察失败、修复缺陷、再次验证的循环。SWE-bench 之所以重要，是因为它把 LLM 放到真实 GitHub issue 和真实代码仓库里评估，暴露出跨文件理解、长上下文、执行环境和复杂推理的难度。Reflexion 和 CRITIC 则从 Agent 角度说明，外部反馈、工具验证和自我修正能显著改善结果。换到工程语言里，这就是 D2D 里的 FE Agent、测试智能体、缺陷回流和全量回归的价值：AI 交付必须有反馈闭环。

所以，三份规范不是并列关系，而是递进关系：

flowchart LR
  A[Skills 与 MCP<br/>能力供给层] --> B[提示词与上下文工程<br/>行为控制层]
  B --> C[D2D 设计即交付<br/>场景交付层]
  C --> D[测试、验收、发布<br/>质量控制层]
  D --> E[日志、版本、报告、人工修改<br/>资产回流层]
  E --> A

二、第一层：Skills 与 MCP 解决“Agent 能调用什么”

Agent 不是一个会聊天的模型，而是一个能在任务中感知环境、做决策、调用工具、产出结果的执行单元。LLM-based agent 的大量综述论文都会把 Agent 拆成类似“大脑、感知、行动、记忆、工具”的结构。这里最容易被低估的是“行动”。

没有工具，Agent 只是语言模型。

有了工具但没有规范，Agent 只是脚本集合。

有了统一协议、统一托管、统一权限、统一日志，Agent 能力才开始变成组织资产。

这就是 Skills 与 MCP 规范的底层意义。

在这套规范里，MCP 是底层公共能力协议层，负责通用能力的协议封装、请求转发、参数适配、通道管控和通用规则校验。它不应该写业务逻辑，也不应该为某一个业务场景私有化。Skill 则是业务技能单元，基于 MCP 封装具体场景流程，负责把底层能力编排成一个可复用的业务动作。

可以这样理解：

层级解决的问题不应该做什么
MCP通用能力怎么被安全、稳定、统一地调用不写业务判断，不私设协议，不破坏兼容
Skill某个业务场景怎么形成闭环能力不重复造底层工具，不绕过平台调用
Hub 平台能力怎么注册、安装、发布、监控、下线不让能力散落在个人机器和私有脚本里

这和 Toolformer、ReAct 的研究方向是相通的。论文里关心的是模型何时调用工具、如何把工具结果纳入推理；工程里更进一步，要关心工具从哪里来、谁有权限调用、调用是否幂等、失败如何降级、日志如何追踪、版本如何回滚。

这也是为什么规范强调：

  • MCP 单一职责；
  • Skill 单一场景闭环；
  • 统一请求结构和响应结构；
  • 参数强校验；
  • 统一错误码；
  • 全链路日志；
  • 平台统一托管。

这些要求表面上像“工程洁癖”，实际是在解决 Agent 能力供应链的问题。

如果没有这层，AI 能力会出现几个典型坏味道：

  • 每个团队都写一套自己的工具封装；
  • 同一个能力有多个版本，没人知道哪个是最新；
  • Prompt 里直接塞工具说明，无法权限控制；
  • 工具失败被吞掉，无法观测；
  • 能力只在某个人电脑上能跑；
  • 上线后出了问题，没有 requestId、版本号和调用链可以追。

所以，Skills 与 MCP 的宣贯重点不是“大家以后要按目录写文件”，而是要让大家形成一个共识：

Agent 能力必须像软件包一样被生产、发布、安装、治理和淘汰。

三、第二层：提示词与上下文工程解决“Agent 怎么稳定地做”

有了能力供给，不代表 Agent 就能稳定完成任务。工具是手，Prompt 和 Context 是作业指导书、任务单和现场资料。

很多人对提示词工程的理解还停留在“把话说清楚一点”。这在原型阶段够用，但在生产环境远远不够。

一次真实的模型调用通常包含：

  • 系统提示词；
  • 用户提示词；
  • 会话历史；
  • RAG 检索片段；
  • 工具返回；
  • 业务元数据；
  • 输出格式约束；
  • 安全规则；
  • 示例；
  • 历史失败经验；
  • 当前任务状态。

模型看到的不是一个 prompt，而是一包上下文。

这也是为什么规范把“提示词工程”和“上下文工程”放在一起讲。提示词定义行为边界，上下文决定模型当前能看到什么事实、什么状态、什么证据。

可以把它拆成三句话：

系统提示词定义不可破的规则。
用户提示词定义当前任务实例。
上下文工程决定模型这次调用的事实现场。

系统提示词不应该只是“你是一个资深专家”。它应该承担权限层职责：哪些事情可以做，哪些事情不能做，什么情况下必须拒绝，资料不足时必须如实说明，输出必须满足什么格式，工具调用必须遵守什么边界。

用户提示词也不应该只是“帮我写一个页面”。它应该包含目标、输入、约束、输出形态和成功标准。

上下文工程则更像运行时系统。它要回答：

  • 哪些业务参数优先级最高？
  • 哪些检索片段真的相关？
  • 哪些历史对话已经过期？
  • 哪些工具结果必须进入上下文？
  • 超过 Token 预算时先裁剪什么？
  • 敏感信息如何脱敏？
  • 检索不到有效资料时如何防止幻觉？

这和 RAG 论文线的结论高度一致。RAG 的核心价值，是把模型参数中的隐式知识和外部显式知识结合起来，提升知识密集任务的事实性。但后续研究已经不断提醒我们：检索上下文不是越多越好，长上下文不是万能，相关性、位置、压缩、引用和验证都很重要。

Lost in the Middle 的结论尤其适合拿来解释规范里的容量管控要求。模型即使支持长上下文，也可能对位于中间的关键信息使用不稳定。因此，规范要求单次入模文本不超过窗口上限的 80%，并且按“核心业务参数、当前用户指令、高相关检索片段、关键历史对话、辅助说明内容”的优先级排序，本质上是在做输入侧的可靠性工程。

这里有一个很重要的观念转变：

提示词不是文案，提示词是控制面。
上下文不是材料堆叠，上下文是运行时状态。

所以提示词模板库、版本号、变更记录、灰度验证、回滚机制，不是形式主义。它们对应的是生产系统里的配置管理和变更管理。

如果一个核心业务 Agent 的系统提示词可以被随手改、不能追踪版本、没有测试集、没有回滚路径，那它的风险并不比随手改一段线上代码低。

四、第三层：D2D 是 AI 交付生产线的样板间

D2D 最容易被误读成“设计稿自动生成代码”。这个理解太窄了。

真正的 D2D，不是 design to code，而是 design to delivery。

它不是把 Figma 或 MasterGo 的画面转成一段前端代码，而是把设计稿变成可发布、可测试、可追溯、可二次编辑、可长期维护的业务页面。

这条链路里至少有七个关键环节：

flowchart TD
  A[设计稿上传] --> B[设计稿解析]
  B --> C[物料自动分析匹配]
  C -->|物料缺失| D[插件唤起 AI 物料生成]
  D --> E[物料校验入库]
  E --> C
  C -->|物料齐全| F[基于 Schema 的 AI 协同搭建]
  F --> G[自动出码]
  G --> H[流水线与测试智能体]
  H -->|通过| I[预览环境与多方验收]
  I --> J[应用发布系统]
  H -->|失败| K[FE Agent 与本地 AI 客户端修复]
  K --> F

这套设计的关键，不在“自动”两个字，而在每一步都有明确的工程对象。

第一，物料平台是视觉和工程一致性的源头。

规范要求所有页面渲染依赖统一物料平台，禁止脱离物料库自定义样式、私有组件。这个要求看起来很硬，但它解决的是设计和前端长期不一致的问题。没有统一物料源头，AI 生成页面时会倾向于临时拼样式，短期看起来快，长期会把组件体系打碎。

第二，页面 Schema 是唯一中间标准。

Schema 的意义是让页面不直接等于代码。它承载布局、组件引用、样式配置和交互逻辑，是 AI 搭建、多端适配、二次编辑的中间协议。没有 Schema，AI 生成的页面只能停留在一次性代码；有了 Schema，页面才能被重建、迁移、对比、回滚和继续编辑。

第三，Web 平台和本地 AI 客户端分工不同。

Web 平台负责调度、资源、版本、预览、流水线。本地 AI 客户端负责本地视觉精调、离线渲染、编译预览和人工修复。这个边界很关键。它既避免所有重型交互都压到 Web 平台，也让研发本地的修复动作能被标准化回流，而不是变成不可追踪的私有改动。

第四，测试智能体不是最后补一道测试，而是交付卡点。

视觉 Diff、功能用例、多端兼容、控制台错误，这些都应该成为流水线里的自动阻断条件。Design2Code 的研究已经说明，当前多模态模型在视觉元素召回和布局还原上仍有明显短板。因此，视觉校验不能靠人工最后看一眼，而要成为自动化质量门禁。

第五，FE Agent 和人工干预不是失败，而是闭环的一部分。

AI 自动出码失败、视觉偏差、特殊业务逻辑需要人工修复，这些都很正常。关键是人工修复必须通过本地客户端记录快照、打包回流、重新触发全量回归，并进入页面版本详情。这样，人工经验不会游离在平台之外，而会变成下一次 AI 交付的资产。

这就是 D2D 的真正价值：

它把“AI 生成”改造成“AI 参与的工程交付流水线”。

五、把规范落到当前实现里

如果只讲到这里，D2D 仍然像一套漂亮架构。真正让它变得可信的，是工程里已经出现了几条可运行的链路：KaiHub 负责能力供给，MasterGo 插件负责设计上下文，Echo Builder 负责页面 Schema 和本地 AI 会话，物料组件库负责 Schema 渲染，后端出码服务负责把产物推向 GitLab MR 和集成环境。

这些实现还没有覆盖规范里的每个终态目标，但已经能看出一条完整生产线的雏形。

先看一张映射表：

规范里的抽象对象当前实现里的落点它证明了什么
Skill/MCP 能力供给ai-tools-hub、kai publish、kai install能力可以被发布、审批、安装、校验和治理
设计稿上下文mastergo-plugin-design-context、saveSnapshot设计稿可以转成结构化 snapshot 和物料绑定
Web + 本地 AI 协同buildDeepLink、echo-builder、start_harnessWeb 可以调度，本地客户端可以承接重型 AI 修复
AI 任务上下文getToolpack、Builder Skill、session tools上下文可以被打包成受控工作区，而不是临时 prompt
修改回流uploadPatchset、schemaHash、toolpackVersionAI 产物必须基于当前 Schema 和当前工具包回流
Schema 出码runCodegen、runBatchCodegenSchema 可以投影成目标仓代码、MR 和集成环境
物料运行时EchoLayoutRenderer、assertSchema页面渲染依赖 Schema + material registry，而不是私有样式

1. KaiHub：能力供给不是复制 Skill 文件

Skills 与 MCP 那一层，在工程里对应的是 KaiHub，也就是 ai-tools-hub。它不是一个简单的文件下载站，而是把 Skill/MCP 的发布、审批、制品、安装、同步和客户端适配串成一套能力供应链。

sequenceDiagram
  autonumber
  participant Author as 能力作者
  participant Kai as kai CLI
  participant API as portal-api
  participant Store as 制品存储
  participant Approval as 飞书审批
  participant Client as Codex/Claude/Cursor

  Author->>Kai: kai publish skill或mcp
  Kai->>Kai: 校验 ref、SemVer、manifest
  Kai->>API: 创建发布请求
  API-->>Kai: 返回预签名上传地址
  Kai->>Store: 上传 Skill/MCP 制品并计算 SHA
  Kai->>API: 二阶段提交 artifactURI 和 artifactSHA
  API->>Approval: 创建或查询审批
  Approval-->>API: 审批通过
  API->>API: 创建版本、写审计、发通知
  Client->>Kai: kai install
  Kai->>API: 申请 install token
  Kai->>Store: 下载制品并校验 SHA
  Kai->>Client: 写入各 IDE 原生配置和技能目录

几个实现点很关键：

  • newPublishCmd 负责发布入口，校验 kind/ns/name@semver、读取 manifest、打包目录、上传制品，并支持有制品和 manifest-only 两种模式。
  • publishWithApproval 把发布和审批绑定起来：没有审批就创建审批，审批中就返回 pending，审批通过后才真正创建版本并写审计。
  • installSkill 和 Installer.Install 不只是下载文件，而是申请 install token、下载制品、校验 SHA、写入多个客户端的 Skill root，并写 .kai-managed 标记。

这正好对应规范里的一个核心判断：

Agent 能力不能靠口口相传或手动复制，必须像软件包一样有版本、审批、制品完整性和安装适配。

2. 设计上下文：从图层快照到物料绑定

D2D 的起点不是代码，而是设计稿。当前实现里，mastergo-plugin-design-context 和 ksher-design-be 已经形成了一条设计上下文入库链路。

flowchart TD
  A[设计工具中选中图层] --> B[插件 buildSnapshot]
  B --> C[导出设计树、token、source 元信息]
  C --> D[搜索并绑定物料]
  D --> E[插件 uploadSnapshot]
  E --> F[后端 saveSnapshot]
  F --> G[按物料库版本解析 builder materials]
  G --> H[抽取 nodeId 到 materialId 绑定]
  H --> I[压缩存储 snapshot 与 nodeBindings]
  I --> J[后续 AI 搭建和规则读取]

插件侧 buildSnapshot 会从当前图层根节点导出设计树、token bundle、source 信息、插件版本和物料映射。runSearchVC 通过平台接口搜索可绑定物料，uploadSnapshot 在上传前会检查平台地址、文件 ID、物料库版本，然后把快照压缩后同步到平台。

后端侧 saveSnapshot 会做几件事：校验 snapshot/source/rootNodeId，解析 libraryName 和 libraryVersion，读取当前版本的 builder materials，抽取图层节点到物料 ID 的绑定关系，压缩 snapshot 并落库。getVirtualComponentRules 则能根据某个物料返回 props、runtimeProps、slots、variants 和约束规则。

这里有一个很重要的工程取舍：系统没有试图完全靠视觉猜测物料，而是强调显式绑定和显式 props。也就是说，AI 可以辅助，但设计上下文进入平台时，必须变成结构化、可追踪、可复用的工程事实。

这和规范里的“物料唯一源头”和“Schema 标准化”是一致的：设计稿不是直接变代码，而是先变成可被平台理解的上下文和绑定关系。

3. Echo Builder：Web 唤起本地 AI，而不是把所有能力塞进浏览器

D2D 规范里有一个很现实的判断：Web 平台和本地 AI 客户端要权责分离。当前实现里，echo-app-server 和 echo-builder 已经把这条链路跑通。

sequenceDiagram
  autonumber
  participant Web as Builder Web
  participant Server as echo-app-server
  participant Desktop as Echo Builder 桌面端
  participant Harness as 本地 harness
  participant Agent as Codex或Claude Code
  participant Platform as 平台回流接口

  Web->>Server: 创建 AI session
  Server-->>Web: 返回 echo-builder deep link
  Web->>Desktop: 唤起 echo-builder://open
  Desktop->>Desktop: 解析 apiBase/appId/pageId/sessionId/token
  Desktop->>Harness: start_harness
  Harness->>Server: 拉取 toolpack
  Server-->>Harness: AGENTS、Skill、session-tools、upload-result
  Harness->>Agent: 执行页面编辑任务
  Agent->>Harness: 生成 patchset 和 evidence
  Harness->>Platform: 上传结果
  Platform->>Server: 校验并进入 pending_review

服务端 buildDeepLink 会把 apiBase、appId、pageId、sessionId、token、modelClient 等参数编码进 echo-builder://open?...。桌面端 parse_echo_builder_link 校验协议、动作和必要参数，start_harness 再校验本地服务端路径、检测 pnpm、启动本地进程，并把 stdout/stderr 关键进度通过事件回传 UI。

真正体现上下文工程的是 getToolpack。它不是把一大段 prompt 丢给模型，而是下发一组结构化工作区文件：AGENTS.md、CLAUDE.md、Codex/Claude Skill、.echo-builder/session-tools.mjs、.echo-builder/validate-session.mjs、.echo-builder/upload-result.mjs 和 agent-task 模板。这样，本地 Agent 拿到的是一个受控任务工作区，而不是一段无边界的聊天上下文。

回流侧 uploadPatchset 也不是简单接收文件。它会校验 baseRevisionId、sessionId、pageId、schemaHash、toolpackVersion，再检查 patchset scope。换句话说，AI 的修改必须证明自己基于当前页面版本、当前 Schema、当前工具包，而不是基于旧上下文或本地残留记忆。

这正是 D2D 里“人工干预必须回流平台、所有修改留痕”的实现基础。

4. Schema 出码：页面不是代码，代码是 Schema 的一个投影

在 echo-app-server 里，runCodegen 和 runBatchCodegen 负责把 Builder 页面配置变成目标仓库代码。它们的流程不是“拿 Schema 就写文件”这么简单，而是有一连串门禁：

flowchart TD
  A[Builder Page Schema] --> B[生命周期校验]
  B --> C[业务 profile 校验]
  C --> D[解析物料包版本]
  D --> E[物料 propsSchema 校验]
  E --> F[生成 Builder files]
  F --> G[clone 目标仓库]
  G --> H[物料版本门禁]
  H --> I[写文件与路由多语言补丁]
  I --> J[提交分支并推送]
  J --> K[创建 GitLab MR]
  K --> L[创建集成环境]

几个实现细节值得注意：

  • 页面必须处于 validated 或 codegen_pending 生命周期，否则不能出码。
  • 如果应用 profile 绑定了物料包，出码前会解析实际物料版本，并在目标仓工作区做版本门禁。
  • validateMaterialProps 会用物料清单里的 propsSchema 校验页面里每个物料实例，避免生成运行时才爆炸的非法 props。
  • 出码不是直接写主干，而是创建分支、提交、推送，并创建 GitLab MR。
  • 批量出码还会检查多页面物料版本一致性和文件冲突。

物料渲染侧，kgp-h5-components 里的 EchoLayoutRenderer 则证明了 Schema 的定位：同一份 LayoutPageSchema 加 materialId -> component registry，渲染出页面。assertSchema 会对不支持的 schemaVersion 直接抛错，MissingMaterial 会把未注册物料显式渲染成占位，而不是静默失败。

这解释了为什么规范反复强调：

Schema 是页面的唯一中间标准。
代码是 Schema 在某个技术栈、某个仓库、某个物料版本下的投影。

一旦接受这个判断，很多工程决策就变得自然：出码要有物料版本门禁，AI patchset 要带 schemaHash，目标仓文件不能反过来取代 Schema，缺失物料不能靠页面私有样式绕过去。

5. 当前还应该补齐的闭环

从当前实现看，D2D 的主骨架已经存在：能力供给、设计上下文、物料规则、本地 AI、Schema 出码、MR、集成环境、patchset 回流都有对应模块。但如果要完全达到规范里的“业务发布级闭环”，还需要补齐几块。

第一，视觉 Diff 闭环需要从“要求”变成“一等产物”。

当前链路里已经有设计上下文、集成环境和本地 evidence 基础，但还应该把视觉 Diff 做成标准对象：包含设计基准图、预览截图、差异区域、阈值、浏览器/设备信息、责任归因和阻断状态。它不应该只是 CI 日志里的图片，而应该挂到页面版本和 patchset 上。

flowchart LR
  A[设计基准] --> C[视觉 Diff 任务]
  B[预览环境截图] --> C
  C --> D{是否过阈值}
  D -->|通过| E[进入验收]
  D -->|失败| F[生成视觉缺陷]
  F --> G[推送 FE Agent 或本地 AI]
  G --> H[修复 patchset]
  H --> C

第二，测试智能体需要有统一报告协议。

现在工程里有本地 verificationCommands、项目检查、构建和集成环境，但“测试智能体”的结果还应该统一成一份报告协议：视觉、功能、构建、类型检查、控制台错误、多端兼容分别有状态、证据、日志摘要、失败归因和重跑入口。这样缺陷才能自动回流到 FE Agent，而不是只停留在“某个命令失败”。

第三，验收记录需要成为发布门禁。

D2D 规范要求前端、设计、业务三方验收留痕。建议在页面版本上增加验收状态机：waiting_fe、waiting_design、waiting_business、approved、rejected。每次验收都绑定预览 URL、Schema 版本、代码 MR、测试报告和验收人。没有完整验收记录，就不能推送应用发布系统。

第四，交付结果应该反哺 KaiHub 和物料平台。

这可能是最容易被忽略、但最有复利的一环。每次 D2D 交付后，应该把以下结果沉淀回能力供给层：

  • 多次人工修复同类问题，沉淀为 Builder Skill 或 FE Agent 规则；
  • 多次出现缺失物料，沉淀为物料生成需求或物料库优先级；
  • 某类视觉 Diff 高频失败，沉淀为设计规范或组件 token 约束；
  • 某类上下文缺失导致 AI 修改错误，沉淀为 toolpack/context 规则；
  • 某个业务模板反复复用，沉淀为页面模板或场景模板。

这条反哺链路可以设计成：

flowchart TD
  A[D2D 交付记录] --> B[缺陷聚类]
  A --> C[人工修复摘要]
  A --> D[测试失败模式]
  B --> E[生成 Skill 改进建议]
  C --> F[生成物料或模板需求]
  D --> G[生成测试智能体规则]
  E --> H[KaiHub 发布新版 Skill]
  F --> I[物料平台入库]
  G --> J[流水线质量卡点升级]
  H --> K[下一次 D2D 交付]
  I --> K
  J --> K

有了这条链路，D2D 就不只是“把页面做出来”，而是每做一个页面，系统都更懂一点业务、更稳一点生成、更少一点人工兜底。

六、三份规范其实在定义一套 AI 研发操作系统

如果把三份规范放在一起，它们覆盖的不是三个文档主题，而是一个完整操作系统的三个层面。

规范工程对象核心问题典型资产
Skills & MCP能力供给Agent 能调用什么，能力如何托管MCP、Skill、工具协议、日志、权限、版本
提示词与上下文工程行为控制Agent 如何稳定、合规、少幻觉地执行系统提示词、用户提示词、上下文策略、RAG、模板库
D2D场景交付Agent 如何进入真实业务闭环设计稿、物料、Schema、代码包、测试报告、验收记录

更进一步看，它们分别对应生产线的三个问题。

第一，生产资料标准化。

Skills、MCP、物料平台、提示词模板库、页面 Schema，本质上都是生产资料。它们不是某个项目的临时产物，而是会在多个项目、多个 Agent、多个交付场景里反复使用的基础资产。

第二，生产过程可控化。

上下文优先级、Token 预算、参数校验、错误码、视觉 Diff、流水线卡点、验收权限，都是为了让 AI 的行为从“概率输出”变成“受控过程”。模型仍然是概率模型，但流程不能是概率流程。

第三，生产结果可追溯。

设计稿、物料清单、Schema、生成代码、人工修改、测试报告、验收记录、发布记录全部留痕，这不是为了审计而审计，而是为了让失败可以复盘、资产可以复用、责任可以定位、质量可以持续提升。

这三点合起来，就是 AI 原生研发真正的分水岭：

不是谁更会问模型，而是谁能把模型放进一套可持续运转的工程系统里。

七、对不同角色意味着什么

对前端研发来说，D2D 不等于“以后不用写页面”。相反，前端研发的工作会从重复还原页面，转向物料体系建设、Schema 设计、生成代码审查、视觉偏差修复、复杂交互补充和质量卡点治理。越是成熟的 D2D，越需要前端把经验沉淀成可复用物料和规则。

对 AI 应用研发来说，不能再把 Prompt 当成散落在代码里的字符串。系统提示词、用户提示词、上下文组装、RAG 检索、脱敏、裁剪、日志、版本和测试，都要成为一等工程对象。一个 Agent 的质量，很多时候不取决于模型参数，而取决于它每次调用前看到了什么。

对 Skill 和 MCP 开发者来说，重点不是“包一个接口给模型用”。模型面对的工具接口必须语义清晰、参数严格、错误可解释、权限可控、调用可观测。Skill 要聚焦业务闭环，MCP 要保持底层通用，两者边界不能混。

对测试开发来说，测试智能体不是传统自动化测试的简单替代，而是要进入 AI 交付链路的中枢。视觉 Diff、功能回归、多端兼容、控制台错误、产物溯源，都应该成为可自动判断、可回流修复、可沉淀报告的质量信号。

对设计研发来说，设计稿不再只是视觉输入，而是交付链路的起点。图层规范、样式复用、物料映射、设计插件、AI 物料生成，都会影响后续能不能自动搭建、能不能还原、能不能测试、能不能发布。

这背后有一个共同变化：

每个角色都不只是完成自己的局部任务，而是在为 AI 交付生产线提供标准资产和质量信号。

八、宣贯时最应该讲清楚的三句话

第一句话：

Skills & MCP 解决能力供给，不解决业务交付的全部问题。

它让 Agent 有手、有工具、有能力货架，但还需要提示词和上下文来驱动，需要场景流程来落地。

第二句话：

提示词与上下文工程解决行为控制，不是写几段更漂亮的话。

它本质上是模型调用前的信息治理、权限治理、成本治理和幻觉治理。

第三句话：

D2D 解决场景闭环，是前两层能力在真实业务中的样板工程。

它把物料、Schema、AI 搭建、自动出码、测试智能体、FE Agent、本地客户端、预览验收和发布系统串成一条完整链路。

如果只能用一个比喻讲清楚，可以这样说：

Skills 与 MCP 是机器和工具库。
提示词与上下文工程是操作规程和现场资料。
D2D 是把机器、工具、规程放进真实车间后的第一条标准化生产线。

这比“从 Agent 供给工程到场景化利用”更进一步。它不是从供给到使用，而是从供给到交付，再从交付回流到供给。

九、结语：AI 研发的下一步，是交付系统设计能力

很多关于 AI 的讨论停留在模型能力：哪个模型更强，哪个上下文更长，哪个代码生成更准。这些都重要，但对企业研发来说，更关键的问题是：

模型能力如何进入组织流程，并稳定地产生可验收结果？

三份规范给出的答案是体系化的：

  • 用 Skills 与 MCP 管住能力供给；
  • 用提示词与上下文工程管住行为边界；
  • 用 D2D 管住真实交付链路；
  • 用测试、验收、版本、日志、人工回流管住质量闭环。

这不是为了把研发流程变重，而是为了避免 AI 能力永远停在个人经验和临时 Demo 里。

真正的 AI 原生研发，不是让每个人都多几个聊天窗口，而是让组织拥有一条能持续吸收知识、封装能力、稳定执行、自动验证、不断回流的交付生产线。

未来的竞争力，也不会只来自“某个 Agent 很聪明”。

更重要的是：

我们能不能持续生产 Agent 能力；
能不能稳定驱动这些能力；
能不能把它们嵌入真实业务；
能不能通过交付结果继续反哺能力体系。

这就是从 Agent 供给工程到设计即交付的内在逻辑。

参考论文