# 外部 Coding Agent 技能规范(研发云协同 · 算力分级分流) > **架构定位**:强模型(TeleAgent)离线生成高质量中间产物 → 弱模型(研发云数字员工)只做机械提交。 > > **核心原则**:弱模型的工作量降到最低——**读一个清单 + 执行一个动作**,不做语义理解、不做数据解析、不做 API 编排。 > > **共 4 个域技能 + 1 套交接协议**。技能0(总控路由)不作为独立技能加载,其路由表/决策树/缺失检测规则作为 TeleAgent Agent 核心的 prompt 参考(见附录D)。 --- ## 交接协议(Handoff Protocol)—— 弱模型执行层规范 > **这是整个架构的关键层**。TeleAgent 产出中间产物后,通过一个极简清单文件 `.handoff.json` 告诉弱模型"做什么动作、对哪个文件、用什么参数"。弱模型只读清单、逐条执行,不做任何语义理解。 ### H.1 交接清单格式(`.handoff.json`) TeleAgent 每次完成产物生成后,在产物目录下生成一个 `.handoff.json` 文件: ```json { "protocol_version": "1.0", "batch_id": "batch-20260923-001", "generated_at": "2026-09-23T10:00:00", "generated_by": "TeleAgent", "target": "srdcloud-digital-employee", "actions": [ { "action_id": "act-001", "action_type": "upload_file", "file_path": "PRD-客户跟进提醒.md", "file_content_type": "markdown", "params": { "doc_title": "PRD-客户跟进提醒", "folder": "Desktop" }, "version": 1, "depends_on": null, "status": "pending" }, { "action_id": "act-002", "action_type": "upload_file", "file_path": "tech-spec-客户跟进提醒.md", "file_content_type": "markdown", "params": { "doc_title": "技术规约-客户跟进提醒", "folder": "Desktop" }, "version": 1, "depends_on": null, "status": "pending" }, { "action_id": "act-003", "action_type": "save_html_artifact", "file_path": "客户管理后台-proto.html", "file_content_type": "html", "params": { "artifact_title": "客户管理后台原型", "write_mode": "final" }, "version": 1, "depends_on": null, "status": "pending" }, { "action_id": "act-004", "action_type": "create_workitems_from_json", "file_path": "workitems-batch-客户跟进提醒.json", "file_content_type": "json", "params": { "project_id": "从用户上下文获取", "iteration_id": "从用户上下文获取或null" }, "version": 1, "depends_on": null, "status": "pending" } ] } ``` ### H.2 弱模型动作目录(仅4种动作,穷举) 弱模型只需要识别以下 4 种 `action_type`,每种对应一个固定的执行流程: | action_type | 输入文件类型 | 弱模型执行流程 | 研发云 MCP 工具 | |-------------|-------------|--------------|----------------| | `upload_file` | .md / .txt | 读取文件内容 → 调用文档上传接口 → 返回文档链接 | `document_upload_to_desktop` | | `save_html_artifact` | .html | 读取文件内容 → 调用产物写入(mode=final)+发布接口 → 返回产物链接 | `artifact_write`(mode=final) + `artifact_publish` | | `create_workitems_from_json` | .json | 读取扁平JSON数组 → 按顺序逐条创建工作项 → 用返回编号关联父子 → 返回创建结果 | `workitems_batch_create` + `workitems_update_workitem` | | `mark_deprecated` | .json | 读取旧版本清单 → 对工作项加评论/对文档重新上传标注版本 → 产物无法标记则跳过 | `workitems_create_comments` / `document_upload_to_desktop` | > **弱模型不需要理解文件内容**。对于 `create_workitems_from_json`,TeleAgent 已将工作项拆分建议转化为结构化 JSON 数组(见技能4输出格式),弱模型只需逐条 `POST` 到研发云 API。 ### H.3 弱模型执行流程(伪代码) ``` // 弱模型收到 .handoff.json 后的执行逻辑 1. 读取 .handoff.json 2. 遍历 actions 数组: for each action in actions: if action.status != "pending": skip if action.depends_on != null: 检查依赖的 action 是否已完成,未完成则跳过(等下一轮) switch action.action_type: case "upload_file": content = read_file(action.file_path) result = call_mcp("document_upload_to_desktop", { file_name: action.params.doc_title + ".md", file_content: content, folder: action.params.folder, mime_type: "text/plain" }) action.result = { doc_url: result.url } action.status = "done" case "save_html_artifact": content = read_file(action.file_path) mode = action.params.write_mode || "final" call_mcp("artifact_write", { filePath: action.file_path, content: content, mode: mode }) result = call_mcp("artifact_publish", { filePath: action.file_path }) action.result = { artifact_id: result.artifact_id, published_path: result.published_relative_path } action.status = "done" case "create_workitems_from_json": // JSON是扁平有序数组,parent_index指向数组中父项位置 items = read_json(action.file_path) created = [] // 记录每条创建结果 for i, item in enumerate(items): // 构建创建参数 create_params = { title: item.title, description: item.description, workitem_type: item.workitem_type, priority: item.priority, estimated_hours: item.estimated_hours, acceptance_criteria: item.acceptance_criteria } // 第一轮创建(不含parent,因为父编号还没拿到) result = call_mcp("workitems_batch_create", { workitems: [JSON.stringify(create_params)] }) created.push(result[0]) // 记录返回的工作项编号 // 如果有父项,用返回的编号关联 if item.parent_index >= 0: parent_key = created[item.parent_index].workitem_key call_mcp("workitems_update_workitem", { workitemKeys: [result[0].workitem_key], fieldKey: "parent", op: "update", fieldValue: parent_key }) action.result = { created_count: created.length, items: created } action.status = "done" case "mark_deprecated": // 版本更新时标记旧产物 dep_info = read_json(action.file_path) for each dep in dep_info.deprecated_actions: // 工作项:添加评论标记过期 if dep.action_type == "create_workitems_from_json": for each old_workitem in dep.result.items: call_mcp("workitems_create_comments", { workitemKey: old_workitem.workitem_key, content: "⚠️ 需求已变更,此工作项已过期,请参考最新版本 v" + dep.new_version }) // 文档:重新上传标注版本(无法直接编辑已有文档备注) else if dep.action_type == "upload_file": // 文档无法直接标记过期,跳过(新版本上传后旧版本自然在历史中) pass // 产物:无法标记过期,跳过(新版本发布后旧版本在版本历史中) else if dep.action_type == "save_html_artifact": pass action.status = "done" case default: action.status = "error" action.error = "unknown action_type: " + action.action_type 3. 输出执行结果摘要(成功数/失败数/跳过数) 4. 将更新后的 .handoff.json(含各action的result和status)返回给用户 ``` ### H.4 交接失败处理 | 失败场景 | 处理方式 | |---------|---------| | 弱模型找不到文件 | action.status = "error",error_message = "file not found: {path}",跳过该条继续执行下一条 | | 研发云 API 返回错误 | action.status = "error",error_message = API错误信息,跳过继续 | | 依赖的 action 未完成 | action.status = "blocked",本轮跳过,等待下一轮重试 | | 弱模型无法识别 action_type | action.status = "error",error_message = "unknown action_type",跳过继续 | > **关键原则**:单条 action 失败不阻断其他 action 执行。弱模型执行完后输出摘要,用户可决定是否重试失败的 action。 ### H.5 版本管理与失效传播 #### 产物版本号 每个产物文件名带版本号:`PRD-{项目名}-v{N}.md`、`tech-spec-{项目名}-v{N}.md`、`{主题}-proto-v{N}.html`、`workitems-batch-{项目名}-v{N}.json` #### 修改时的失效传播 当 TeleAgent 重新生成某个产物的新版本时,在 `.handoff.json` 中追加一条 `mark_deprecated` action: ```json { "action_id": "act-005", "action_type": "mark_deprecated", "file_path": "deprecated-清单.json", "file_content_type": "json", "params": { "deprecated_actions": ["act-001"], "reason": "PRD内容已更新,旧版本标记为deprecated", "cascade": ["act-002", "act-003", "act-004"] }, "version": 2, "depends_on": null, "status": "pending" } ``` - `deprecated_actions`:直接标记过期的旧 action - `cascade`:级联失效的下游 action(如 PRD 改了,架构/原型/拆分都需要重新生成) - 弱模型执行 `mark_deprecated` 时: - **工作项**:对已创建的工作项添加评论"⚠️ 需求已变更,此工作项已过期,请参考最新版本 v{N+1}"(调用 `workitems_create_comments`) - **文档**:无法直接编辑已有文档备注,跳过(新版本上传后旧版本自然保留在文档历史中,用户可手动删除) - **产物**:无法标记旧版本过期,跳过(新版本发布后旧版本保留在产物版本历史中) #### 串联失效规则 | 修改的产物 | 级联失效 | 用户操作 | |-----------|---------|---------| | PRD v1 → v2 | 架构 v1、原型 v1、工作项 v1 全部标记 deprecated | TeleAgent 重新生成 v2 链 | | 架构 v1 → v2 | 原型 v1、工作项 v1 不一定失效(取决于改动范围) | TeleAgent 判断是否级联 | | 原型 v1 → v2 | 无级联 | 仅原型重新提交 | | 工作项 v1 → v2 | 无级联 | 弱模型创建新工作项,旧工作项标记 deprecated | --- ## 技能 1:PRD 生成(srdcloud-prd-distilled) ### 1.1 职责 将用户需求描述转化为**结构化产品需求文档(PRD)**,产出为 Markdown 文件 + 交接清单 action。 ### 1.2 输入 | 字段 | 类型 | 必填 | 说明 | |------|------|------|------| | `requirement_text` | String | 是 | 用户原始需求描述或问需单内容摘要 | | `project_name` | String | 否 | 项目名称,用于文档命名 | | `template_override` | String | 否 | 用户自定义模板要求 | | `reference_docs` | String[] | 否 | 参考文档内容 | | `tech_constraints_whitelist` | String | 否 | **技术约束白名单**(不压缩、原样传递的关键约束) | | `version` | Integer | 否 | 版本号,默认1,修改时递增 | ### 1.3 输出 **文件1**:`PRD-{项目名}-v{N}.md`(Markdown 格式) **文件2**:追加到 `.handoff.json` 的 action: ```json { "action_id": "act-{序号}", "action_type": "upload_file", "file_path": "PRD-{项目名}-v{N}.md", "file_content_type": "markdown", "params": { "doc_title": "PRD-{项目名}", "folder": "Desktop" }, "version": {N}, "depends_on": null, "status": "pending" } ``` **标准模板结构**(9 章): ```markdown ## 1. 功能名 [功能名称] ## 2. 需求描述 核心需求的简要描述。 ## 3. 项目概述 **项目背景** / **目标用户** / **业务目标** / **关键指标(KPIs)** ## 4. 用户旅程 **触发点** → **第一步** → ... → **结束点** ### 流程图(Mermaid graph TD) - 判断节点用菱形,流程节点用矩形 - 标注每步执行角色和核心操作 ## 5. 功能列表 ## 6. 功能详细描述 每个功能:详细描述、实现逻辑、输入、输出 ## 7. 页面列表 ## 8. 页面详细设计 每个页面:布局、元素、交互、边界条件、错误处理 ### 页面结构图(markmap) - 层级:# 主模块 → ## 页面 → ### 功能区域 → #### 控件 → ##### 规则/反馈 ## 9. 统计需求 ### 用户行为统计(埋点表) ### 统计指标 ``` ### 1.4 生成规则 1. 需求不清晰时仅追问一次关键信息 2. 一次写入产物文件 3. 严格按模板结构填充 4. 流程图用 `mermaid graph TD`,页面结构图用 `markmap` 5. 禁止填充文案,验收标准必须可量化 6. **技术约束白名单**:用户在对话中提到的技术栈/数据库/框架等关键词(如"用PostgreSQL不用MySQL""Spring Boot 3.x""部署到K8s")**不压缩、原样写入PRD第6章功能详细描述中** ### 1.5 质量检查清单 - [ ] 9 章完整 - [ ] Mermaid/markmap 语法正确 - [ ] 每个功能有输入/输出/实现逻辑 - [ ] 每个页面有布局/元素/交互/边界条件/错误处理 - [ ] 无填充文案、无编造数据 - [ ] 技术约束白名单内容已原样写入 - [ ] 文件名含版本号 `PRD-{项目名}-v{N}.md` - [ ] `.handoff.json` 已追加 upload_file action --- ## 技能 2:架构设计文档生成(architecture-design-doc-distilled) ### 2.1 职责 将 PRD 转化为**可据以实现的技术规约**,产出 Markdown 文件 + 交接清单 action。 ### 2.2 输入 | 字段 | 类型 | 必填 | 说明 | |------|------|------|------| | `prd_content` | String | 是 | PRD 文档内容 | | `tech_constraints` | String | 否 | 技术约束(从PRD技术约束白名单传递 + 用户补充) | | `project_name` | String | 否 | 项目名称 | | `version` | Integer | 否 | 版本号,默认1 | ### 2.3 输出 **文件1**:`tech-spec-{项目名}-v{N}.md` **文件2**:追加到 `.handoff.json`: ```json { "action_id": "act-{序号}", "action_type": "upload_file", "file_path": "tech-spec-{项目名}-v{N}.md", "file_content_type": "markdown", "params": { "doc_title": "技术规约-{项目名}", "folder": "Desktop" }, "version": {N}, "depends_on": null, "status": "pending" } ``` **模板结构**(5章 + 修订历史): ```markdown # 技术规约 > 状态:📝 草案 | 🧊 已冻结 | ⚠️ 已过期(见v{N+1}) > 版本:v{N} ## 1. 架构设计 - 整体架构 + 技术选型理由 + 部署架构 - 架构图(Mermaid graph TD/LR) ## 2. 模块拆分 | 模块 | 职责 | 依赖 | - 模块依赖图(Mermaid) ## 3. 接口契约 每个接口:方法/路径、输入、输出(成功/失败)、错误码 ## 4. 数据模型 | 字段 | 类型 | 约束 | 说明 | - ER图(Mermaid erDiagram) ## 5. 验收标准 对应PRD每个功能,可验证的验收点 ## 修订历史 | 版本 | 日期 | 变更内容 | 原因 | ``` ### 2.4 生成规则 1. 仔细阅读PRD,理解每个功能意图。不清楚的标注 `[待确认]` 2. 架构设计要具体:明确架构类型、选型理由、部署方案 3. 接口契约是硬约束:字段名、类型、错误码都要明确 4. 验收标准要可验证 5. **技术约束优先级**:用户明确指定的技术栈 > PRD技术约束白名单 > TeleAgent推荐 6. 架构图/模块依赖图/ER图必须用 Mermaid 7. 文件名含版本号 ### 2.5 质量检查清单 - [ ] 架构设计明确 + 选型理由 - [ ] Mermaid 语法正确 - [ ] 接口契约完整(方法/路径/输入/输出/错误码) - [ ] 数据模型完整(字段/类型/约束/说明) - [ ] 验收标准可验证 - [ ] 技术约束白名单内容已采纳 - [ ] 文件名含版本号 - [ ] `.handoff.json` 已追加 action --- ## 技能 3:HTML 原型生成(design-proto-distilled) ### 3.1 职责 根据设计简报,生成**生产级自包含 HTML 原型文件**。 ### 3.2 输入(设计简报) | 字段 | 类型 | 必填 | 说明 | |------|------|------|------| | `design_system` | String | 是 | 设计体系(9选1) | | `platform` | String | 是 | 目标平台(6选1) | | `page_type` | String | 是 | 页面类型(13种或通用前端) | | `page_topic` | String | 是 | 页面主题 | | `target_audience` | String | 否 | 目标受众 | | `core_content` | String | 是 | 核心内容摘要 | | `component_library` | String | 否 | 组件库(element-plus/shadcn) | | `multi_view` | Boolean | 否 | 是否多视图 | | `version` | Integer | 否 | 版本号,默认1 | ### 3.3 设计体系速查表(9套) | 名称 | 主色调 | 适用场景 | 关键词 | |------|--------|---------|--------| | Neutral Modern | 浅蓝 | 通用极简、B2B | 简约/现代/清爽 | | Claude | 暖棕 | 文档、内容型 | 中文/博客/温暖 | | ElevenLabs | 青蓝 | 音频、轻量化 | 音频/语音/优雅 | | Hugging Face | 暖黄 | 开发者工具、ML | ML/开源/模型 | | MiniMax | 淡紫 | 数字人、多模态 | 海螺/视频/中国AI | | Runway | 亮蓝 | 创意AIGC | 电影/创意/影视 | | OpenAI | 极简白 | AI研究 | AI/OpenAI/研究 | | Ant | 商务蓝 | 政企金融、后台 | 后台/数据/企业 | | Colorful | 灼橙 | 多彩创意 | 多彩/活泼/创意 | > 默认:Neutral Modern ### 3.4 平台速查表(6种) | 名称 | 关键词 | 默认联动 | |------|--------|---------| | 响应式Web | 分享/多端/落地页 | Neutral Modern | | 桌面Web | 桌面/后台/大屏 | Ant | | iOS应用 | iPhone/iOS | Neutral Modern | | Android应用 | Android | Neutral Modern | | 平板应用 | iPad/平板 | Neutral Modern | | 桌面应用 | Electron/客户端 | Neutral Modern | > 默认:响应式Web ### 3.5 页面类型速查表 | 关键词 | 页面类型 | 推荐设计体系 | 推荐平台 | |--------|---------|-------------|---------| | FAQ/帮助中心 | faq-page | OpenAI | 响应式Web | | 登录/注册 | login-flow | Neutral Modern | 响应式Web | | 简历/CV | resume-modern | Claude | 响应式Web | | 文章/博客 | article-magazine | Claude | 响应式Web | | 数据报告/周报 | data-report | Ant | 桌面Web | | 管理后台/仪表盘 | dashboard | Ant | 桌面Web | | SaaS/落地页 | saas-landing | OpenAI | 响应式Web | | 定价/套餐 | pricing-page | Neutral Modern | 响应式Web | | 邮件/newsletter | email-marketing | MiniMax | 响应式Web | | 海报/分享图 | poster-hero | Runway | 桌面Web | | 看板/kanban | kanban-board | Ant | 桌面Web | | 发票/账单 | invoice | Neutral Modern | 响应式Web | | 文档/guide | docs-page | OpenAI | 桌面Web | | 原型/demo/页面 | 通用前端 | 按关键词推断 | 按关键词推断 | ### 3.6 输出 **文件1**:`{主题}-proto-v{N}.html`(单个自包含 HTML) **文件2**:追加到 `.handoff.json`: ```json { "action_id": "act-{序号}", "action_type": "save_html_artifact", "file_path": "{主题}-proto-v{N}.html", "file_content_type": "html", "params": { "artifact_title": "{主题}原型", "write_mode": "final" }, "version": {N}, "depends_on": null, "status": "pending" } ``` ### 3.7 分步生成策略(解决单次生成可靠性问题) > **不强制一次写入**。允许分步生成 + 自检修复,提高 P0 硬门控通过率。 #### 生成步骤 | 步骤 | 产出 | 说明 | |------|------|------| | Step 1:骨架 | HTML骨架 + `:root`令牌注入 + ``平台约束 | 基础结构,不含页面内容 | | Step 2:内容 | ``页面内容 + 语义化标签 + 内联SVG | 注入页面技能定义的区块 | | Step 3:交互 | 多视图JS + 弹窗JS + 分段控件JS | 交互逻辑注入 | | Step 4:自检 | P0门控逐项检查 → 修复不通过项 | 内部静默执行 | | Step 5:交付 | 写入文件 + 追加handoff action | 最终产物 | #### 自检修复规则 - P0 不通过项 → **就地修复后重新检查**,最多3轮修复 - 3轮后仍不通过 → 降级交付(标注未通过项,让用户手动检查) - 自检过程不输出给用户,仅最终交付时附自检摘要 ### 3.8 代码合成铁律 #### 设计令牌 - `tokens.css` 的 `:root` 整体注入 `