commit 6e411afe9c8da093355da58f2e86de77519a953d Author: Eric Wang Date: Wed Sep 23 09:02:54 2026 +0800 init: 2026黑马复赛 agents-setup 初始提交 diff --git a/.opencode/skills/frontend-design/LICENSE.txt b/.opencode/skills/frontend-design/LICENSE.txt new file mode 100644 index 0000000..f433b1a --- /dev/null +++ b/.opencode/skills/frontend-design/LICENSE.txt @@ -0,0 +1,177 @@ + + Apache License + Version 2.0, January 2004 + http://www.apache.org/licenses/ + + TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION + + 1. Definitions. + + "License" shall mean the terms and conditions for use, reproduction, + and distribution as defined by Sections 1 through 9 of this document. + + "Licensor" shall mean the copyright owner or entity authorized by + the copyright owner that is granting the License. + + "Legal Entity" shall mean the union of the acting entity and all + other entities that control, are controlled by, or are under common + control with that entity. For the purposes of this definition, + "control" means (i) the power, direct or indirect, to cause the + direction or management of such entity, whether by contract or + otherwise, or (ii) ownership of fifty percent (50%) or more of the + outstanding shares, or (iii) beneficial ownership of such entity. + + "You" (or "Your") shall mean an individual or Legal Entity + exercising permissions granted by this License. + + "Source" form shall mean the preferred form for making modifications, + including but not limited to software source code, documentation + source, and configuration files. + + "Object" form shall mean any form resulting from mechanical + transformation or translation of a Source form, including but + not limited to compiled object code, generated documentation, + and conversions to other media types. + + "Work" shall mean the work of authorship, whether in Source or + Object form, made available under the License, as indicated by a + copyright notice that is included in or attached to the work + (an example is provided in the Appendix below). + + "Derivative Works" shall mean any work, whether in Source or Object + form, that is based on (or derived from) the Work and for which the + editorial revisions, annotations, elaborations, or other modifications + represent, as a whole, an original work of authorship. For the purposes + of this License, Derivative Works shall not include works that remain + separable from, or merely link (or bind by name) to the interfaces of, + the Work and Derivative Works thereof. + + "Contribution" shall mean any work of authorship, including + the original version of the Work and any modifications or additions + to that Work or Derivative Works thereof, that is intentionally + submitted to Licensor for inclusion in the Work by the copyright owner + or by an individual or Legal Entity authorized to submit on behalf of + the copyright owner. For the purposes of this definition, "submitted" + means any form of electronic, verbal, or written communication sent + to the Licensor or its representatives, including but not limited to + communication on electronic mailing lists, source code control systems, + and issue tracking systems that are managed by, or on behalf of, the + Licensor for the purpose of discussing and improving the Work, but + excluding communication that is conspicuously marked or otherwise + designated in writing by the copyright owner as "Not a Contribution." + + "Contributor" shall mean Licensor and any individual or Legal Entity + on behalf of whom a Contribution has been received by Licensor and + subsequently incorporated within the Work. + + 2. Grant of Copyright License. Subject to the terms and conditions of + this License, each Contributor hereby grants to You a perpetual, + worldwide, non-exclusive, no-charge, royalty-free, irrevocable + copyright license to reproduce, prepare Derivative Works of, + publicly display, publicly perform, sublicense, and distribute the + Work and such Derivative Works in Source or Object form. + + 3. Grant of Patent License. Subject to the terms and conditions of + this License, each Contributor hereby grants to You a perpetual, + worldwide, non-exclusive, no-charge, royalty-free, irrevocable + (except as stated in this section) patent license to make, have made, + use, offer to sell, sell, import, and otherwise transfer the Work, + where such license applies only to those patent claims licensable + by such Contributor that are necessarily infringed by their + Contribution(s) alone or by combination of their Contribution(s) + with the Work to which such Contribution(s) was submitted. If You + institute patent litigation against any entity (including a + cross-claim or counterclaim in a lawsuit) alleging that the Work + or a Contribution incorporated within the Work constitutes direct + or contributory patent infringement, then any patent licenses + granted to You under this License for that Work shall terminate + as of the date such litigation is filed. + + 4. Redistribution. You may reproduce and distribute copies of the + Work or Derivative Works thereof in any medium, with or without + modifications, and in Source or Object form, provided that You + meet the following conditions: + + (a) You must give any other recipients of the Work or + Derivative Works a copy of this License; and + + (b) You must cause any modified files to carry prominent notices + stating that You changed the files; and + + (c) You must retain, in the Source form of any Derivative Works + that You distribute, all copyright, patent, trademark, and + attribution notices from the Source form of the Work, + excluding those notices that do not pertain to any part of + the Derivative Works; and + + (d) If the Work includes a "NOTICE" text file as part of its + distribution, then any Derivative Works that You distribute must + include a readable copy of the attribution notices contained + within such NOTICE file, excluding those notices that do not + pertain to any part of the Derivative Works, in at least one + of the following places: within a NOTICE text file distributed + as part of the Derivative Works; within the Source form or + documentation, if provided along with the Derivative Works; or, + within a display generated by the Derivative Works, if and + wherever such third-party notices normally appear. The contents + of the NOTICE file are for informational purposes only and + do not modify the License. You may add Your own attribution + notices within Derivative Works that You distribute, alongside + or as an addendum to the NOTICE text from the Work, provided + that such additional attribution notices cannot be construed + as modifying the License. + + You may add Your own copyright statement to Your modifications and + may provide additional or different license terms and conditions + for use, reproduction, or distribution of Your modifications, or + for any such Derivative Works as a whole, provided Your use, + reproduction, and distribution of the Work otherwise complies with + the conditions stated in this License. + + 5. Submission of Contributions. Unless You explicitly state otherwise, + any Contribution intentionally submitted for inclusion in the Work + by You to the Licensor shall be under the terms and conditions of + this License, without any additional terms or conditions. + Notwithstanding the above, nothing herein shall supersede or modify + the terms of any separate license agreement you may have executed + with Licensor regarding such Contributions. + + 6. Trademarks. This License does not grant permission to use the trade + names, trademarks, service marks, or product names of the Licensor, + except as required for reasonable and customary use in describing the + origin of the Work and reproducing the content of the NOTICE file. + + 7. Disclaimer of Warranty. Unless required by applicable law or + agreed to in writing, Licensor provides the Work (and each + Contributor provides its Contributions) on an "AS IS" BASIS, + WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or + implied, including, without limitation, any warranties or conditions + of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A + PARTICULAR PURPOSE. You are solely responsible for determining the + appropriateness of using or redistributing the Work and assume any + risks associated with Your exercise of permissions under this License. + + 8. Limitation of Liability. In no event and under no legal theory, + whether in tort (including negligence), contract, or otherwise, + unless required by applicable law (such as deliberate and grossly + negligent acts) or agreed to in writing, shall any Contributor be + liable to You for damages, including any direct, indirect, special, + incidental, or consequential damages of any character arising as a + result of this License or out of the use or inability to use the + Work (including but not limited to damages for loss of goodwill, + work stoppage, computer failure or malfunction, or any and all + other commercial damages or losses), even if such Contributor + has been advised of the possibility of such damages. + + 9. Accepting Warranty or Additional Liability. While redistributing + the Work or Derivative Works thereof, You may choose to offer, + and charge a fee for, acceptance of support, warranty, indemnity, + or other liability obligations and/or rights consistent with this + License. However, in accepting such obligations, You may act only + on Your own behalf and on Your sole responsibility, not on behalf + of any other Contributor, and only if You agree to indemnify, + defend, and hold each Contributor harmless for any liability + incurred by, or claims asserted against, such Contributor by reason + of your accepting any such warranty or additional liability. + + END OF TERMS AND CONDITIONS diff --git a/.opencode/skills/frontend-design/SKILL.md b/.opencode/skills/frontend-design/SKILL.md new file mode 100644 index 0000000..decdff4 --- /dev/null +++ b/.opencode/skills/frontend-design/SKILL.md @@ -0,0 +1,55 @@ +--- +name: frontend-design +description: Guidance for distinctive, intentional visual design when building new UI or reshaping an existing one. Helps with aesthetic direction, typography, and making choices that don't read as templated defaults. +license: Complete terms in LICENSE.txt +--- + +# Frontend Design + +Approach this as the design lead at a small studio known for giving every client a visual identity that could not be mistaken for anyone else's. This client has already rejected proposals that felt templated, and is paying for a distinctive point of view: make deliberate, opinionated choices about palette, typography, and layout that are specific to this brief, and take one real aesthetic risk you can justify. + +## Ground it in the subject + +If the brief does not pin down what the product or subject is, pin it yourself before designing: name one concrete subject, its audience, and the page's single job, and state your choice. If there's any information in your memory about the human's preferences, context about what they're building, or designs you've made before – use that as a hint. The subject's own world, its materials, instruments, artifacts, and vernacular, is where distinctive choices come from. Build with the brief's real content and subject matter throughout. + +## Design principles + +For web designs, the hero is a thesis. Open with the most characteristic thing in the subject's world, in whatever form makes sense for it: a headline, an image, an animation, a live demo, an interactive moment. Be deliberate with your choice: a big number with a small label, supporting stats, and a gradient accent is the template answer, only use if that's truly the best option. + +Typography carries the personality of the page. Pair the display and body faces deliberately, not the same families you would reach for on any other project, and set a clear type scale with intentional weights, widths, and spacing. Make the type treatment itself a memorable part of the design, not a neutral delivery vehicle for the content. + +Structure is information. Structural devices, numbering, eyebrows, dividers, labels, should encode something true about the content, not decorate it. Many generic designs use numbered markers (01 / 02 / 03), but that's only appropriate if the content actually is a sequence - like a real process or a typed timeline where order carries information the reader needs. Question if choices like numbered markers actually make sense before incorporating them. + +Leverage motion deliberately. Think about where and if animation can serve the subject: a page-load sequence, a scroll-triggered reveal, hover micro-interactions, ambient atmosphere. An orchestrated moment usually lands harder than scattered effects; choose what the direction calls for. However, sometimes less is more, and extra animation contributes to the feeling that the design is AI-generated. + +Match complexity to the vision. Maximalist directions need elaborate execution; minimal directions need precision in spacing, type, and detail. Elegance is executing the chosen vision well. + +Consider written content carefully. Often a design brief may not contain real content, and it's up to you to come up with copy. Copy can make a design feel as templated as the design itself. See the below section on writing for more guidance. + +## Process: brainstorm, explore, plan, critique, build, critique again + +For calibration: AI-generated design right now clusters around three looks: (1) a warm cream background (near #F4F1EA) with a high-contrast serif display and a terracotta accent; (2) a near-black background with a single bright acid-green or vermilion accent; (3) a broadsheet-style layout with hairline rules, zero border-radius, and dense newspaper-like columns. All three are legitimate for some briefs, but they are defaults rather than choices, and they appear regardless of subject. Where the brief pins down a visual direction, follow it exactly — the brief's own words always win, including when it asks for one of these looks. Where it leaves an axis free, don't spend that freedom on one of these defaults. Just like a human designer who's hired, there's often a careful balance between doing what you're good at and taking each project as a chance to experiment and learn. + +Work in two passes. First, brainstorm a short design plan based on the human's design brief: create a compact token system with color, type, layout, and signature. Color: describe the palette as 4–6 named hex values. Type: the typefaces for 2+ roles (a characterful display face that's used with restraint, a complementary body face, and a utility face for captions or data if needed). Layout: a layout concept, using one-sentence prose descriptions and ASCII wireframes to ideate and compare. Signature: the single unique element this page will be remembered by that embodies the brief in an appropriate way. + +Then review that plan against the brief before building: if any part of it reads like the generic default you would produce for any similar page (work through a similar prompt to see if you arrive somewhere similar) rather than a choice made for this specific brief — revise that part, say what you changed and why. Only after you've confirmed the relative uniqueness of your design plan should you start to write the code, following the revised plan exactly and deriving every color and type decision from it. + +When writing the code, be careful of structuring your CSS selector specificities. It's easy to generate CSS classes that cancel each other out (especially with a type-based selector like .section and a element-based selector like .cta). This can happen often with paddings/margins between sections. + +Try to do a lot of this planning and iteration in your thinking, and only show ideas to the user when you have higher confidence it'll delight them. + +## Restraint and self-critique + +Spend your boldness in one place. Let the signature element be the one memorable thing, keep everything around it quiet and disciplined, and cut any decoration that does not serve the brief. Not taking a risk can be a risk itself! Build to a quality floor without announcing it: responsive down to mobile, visible keyboard focus, reduced motion respected. Critique your own work as you build, taking screenshots if your environment supports it – a picture is worth 1000 tokens. Consider Chanel's advice: before leaving the house, take a look in the mirror and remove one accessory. Human creators have memory and always try to do something new, so if you have a space to quickly jot down notes about what you've tried, it can help you in future passes. + +## More on writing in design + +Words appear in a design for one reason: to make it easier to understand, and therefore easier to use. They are design material, not decoration. Bring the same intentionality to copy that you would bring to spacing and color. Before writing anything, ask what the design needs to say, and how it can best be said to help the person navigate the experience. + +Write from the end user's side of the screen. Name things by what people control and recognize, never by how the system is built. A person manages notifications, not webhook config. Describe what something does in plain terms rather than selling it. Being specific is always better than being clever. + +Use active voice as default. A control should say exactly what happens when it's used: "Save changes," not "Submit." An action keeps the same name through the whole flow, so the button that says "Publish" produces a toast that says "Published." The vocabulary of an interface is the signposting for someone navigating the product. Cohesion and consistency are how people learn their way around. + +Treat failure and emptiness as moments for direction, not mood. Explain what went wrong and how to fix it, in the interface's voice rather than a person's. Errors don't apologize, and they are never vague about what happened. An empty screen is an invitation to act. + +Keep the register conversational and tuned: plain verbs, sentence case, no filler, with tone matched to the brand and the audience. Let each element do exactly one job. A label labels, an example demonstrates, and nothing quietly does double duty. diff --git a/codefree-spec-driven-dev-v2.zip b/codefree-spec-driven-dev-v2.zip new file mode 100644 index 0000000..47b512b Binary files /dev/null and b/codefree-spec-driven-dev-v2.zip differ diff --git a/docs/codefree-spec-driven-dev.zip b/docs/codefree-spec-driven-dev.zip new file mode 100644 index 0000000..0e32b5f Binary files /dev/null and b/docs/codefree-spec-driven-dev.zip differ diff --git a/docs/external-agent-skill-specs_v2.md b/docs/external-agent-skill-specs_v2.md new file mode 100644 index 0000000..47118af --- /dev/null +++ b/docs/external-agent-skill-specs_v2.md @@ -0,0 +1,1165 @@ +# 外部 Coding Agent 技能规范（研发云协同 · 离线生产层） + +> **定位**：外部 Coding Agent 不访问研发云 MCP，专注离线生成高质量中间产物（文档/代码/分析建议），交付给研发云数字员工（在线执行层）落地。 +> +> **共 5 个技能**（1 个总控 + 4 个域技能），总控负责意图路由与任务规划，4 个域技能按优先级排序：PRD 生成 → 架构设计文档 → HTML 原型 → 工作项拆分建议。 + +--- + +## 技能 0：意图路由与任务规划（orchestrator-router-distilled） + +### 0.1 职责 + +分析用户原始输入，完成**意图识别 → 域路由 → 任务拆解 → 上下文压缩**，生成标准化任务指令（JSON），分发给下游 4 个域技能之一或多个。这是外部 Coding Agent 的**总控入口**——所有用户请求先经过本技能分析，再路由到具体域技能执行。 + +### 0.2 核心价值 + +| 价值点 | 说明 | +|--------|------| +| **意图识别** | 从模糊自然语言中精确判断用户想做什么（生成PRD？做原型？拆工作项？） | +| **域路由** | 根据意图自动选择对应的域技能，避免用户手动指定 | +| **任务拆解** | 复合请求拆成有序子任务链（如"帮我做个客户管理功能"→PRD→架构→原型→拆分） | +| **上下文压缩** | 把长对话/多文档/历史消息压缩成结构化上下文摘要，降低下游技能的 token 消耗 | +| **参数预填** | 从用户输入中提取域技能所需的关键参数（项目名、设计体系、平台等），减少下游交互轮次 | +| **缺失检测** | 识别关键信息缺失项，一次性向用户追问，避免下游技能多次打断 | + +### 0.3 输入 + +| 字段 | 类型 | 必填 | 说明 | +|------|------|------|------| +| `user_input` | String | 是 | 用户原始话术（未经加工的自然语言） | +| `conversation_history` | String | 否 | 对话历史摘要（多轮对话场景，最近5轮） | +| `attached_files` | String[] | 否 | 用户附件内容摘要（文档/图片/截图的文本描述） | +| `user_context` | Object | 否 | 用户上下文（项目ID、团队信息、当前迭代等已知信息） | + +### 0.4 输出（标准化任务指令 JSON） + +```json +{ + "meta": { + "request_id": "唯一标识", + "timestamp": "生成时间", + "user_input_raw": "用户原始话术", + "intent_confidence": 0.0-1.0 + }, + "intent": { + "primary_domain": "prd | architecture | prototype | workitem_split | multi_step", + "secondary_domains": ["architecture", "prototype"], + "action_type": "create | modify | query | analyze", + "description": "一句话描述识别到的意图" + }, + "task_plan": { + "execution_mode": "single | sequential | parallel", + "steps": [ + { + "step_id": 1, + "skill": "srdcloud-prd-distilled", + "skill_label": "PRD生成", + "depends_on": [], + "status": "ready" + }, + { + "step_id": 2, + "skill": "architecture-design-doc-distilled", + "skill_label": "架构设计文档", + "depends_on": [1], + "status": "blocked" + } + ] + }, + "context_summary": { + "project_name": "从输入提取或推断的项目名", + "requirement_text": "整理后的需求描述（去除口语化、补全隐含信息）", + "key_entities": ["客户管理", "跟进提醒", "消息推送"], + "tech_constraints": "已识别的技术约束（框架/数据库/平台等，无则null）", + "design_hints": { + "design_system": "Neutral Modern | null（未指定）", + "platform": "响应式Web | null", + "page_type": "dashboard | null" + }, + "team_info": "团队成员信息（无则null）", + "sprint_info": "迭代信息（无则null）" + }, + "missing_info": [ + { + "field": "project_name", + "reason": "用户未提及项目名", + "question": "请问这个需求属于哪个项目？", + "is_blocking": false, + "default_value": "未命名项目" + } + ], + "delivery_instructions": [ + { + "target_skill": "srdcloud-prd-distilled", + "parameters": { + "requirement_text": "{context_summary.requirement_text}", + "project_name": "{context_summary.project_name}" + } + } + ] +} +``` + +### 0.5 意图识别规则 + +#### 关键词 → 域技能路由表 + +| 关键词/语义模式 | 路由目标 | action_type | 说明 | +|----------------|---------|-------------|------| +| PRD/需求文档/产品需求/写需求 | srdcloud-prd-distilled | create | 生成PRD | +| 修改PRD/更新需求文档/补充需求 | srdcloud-prd-distilled | modify | 修改已有PRD | +| 架构/技术方案/技术规约/接口设计/数据模型 | architecture-design-doc-distilled | create | 生成架构设计文档 | +| 修改架构/调整技术方案 | architecture-design-doc-distilled | modify | 修改已有架构文档 | +| 原型/页面/demo/界面/UI/设计稿/HTML | design-proto-distilled | create | 生成HTML原型 | +| 换风格/调平台/改文案/换色/调布局 | design-proto-distilled | modify | 迭代修改已有原型 | +| 拆分/拆任务/工作项/用户故事/排期/指派 | workitem-split-advisor-distilled | create | 生成工作项拆分建议 | +| 做个功能/帮我实现/我想要一个 | multi_step | create | 复合请求，需多技能串联 | + +#### 复合请求识别（multi_step） + +当用户输入同时包含以下信号时，判定为复合请求，触发多技能串联： + +| 信号组合 | 串联顺序 | +|---------|---------| +| "做个XX功能"（无已有PRD） | PRD → 架构 → 原型 → 拆分 | +| "做个XX功能"（已有PRD） | 架构 → 原型 → 拆分 | +| "根据这个需求做个原型" | PRD → 原型 | +| "写个PRD然后拆任务" | PRD → 拆分 | +| "需求文档+技术方案+原型" | PRD → 架构 → 原型 | + +#### 置信度评估 + +| 置信度 | 判定条件 | 处理方式 | +|--------|---------|---------| +| ≥0.8 | 关键词明确命中单一域 | 直接路由，不追问 | +| 0.5-0.8 | 关键词部分命中或有多域信号 | 路由到主域，标注次要域 | +| <0.5 | 关键词模糊或无明确意图 | 向用户追问一次，提供选项 | + +### 0.6 上下文压缩规则 + +#### 需求描述整理 + +将用户口语化输入转化为结构化需求描述： +1. **去除口语化**：删除"帮我""我想""能不能"等无信息量词汇 +2. **补全隐含信息**：根据上下文推断省略的主语、宾语 +3. **结构化**：按"目标用户 + 核心功能 + 业务价值"三要素整理 +4. **标注不确定项**：对推断的部分标注 `[推断]`，对缺失的部分标注 `[待确认]` + +#### 关键实体提取 + +从需求描述中提取以下实体类型： +- **功能模块**：如"客户管理""跟进提醒""消息推送" +- **用户角色**：如"销售""主管""运营" +- **技术关键词**：如"Spring Boot""MySQL""Redis"（用于架构设计预填） +- **设计关键词**：如"后台""仪表盘""登录页"（用于原型设计预填） +- **业务约束**：如"7天内完成""支持1000并发" + +#### 设计简报预提取 + +当路由目标包含 `design-proto-distilled` 时，从需求中预提取设计简报参数： + +| 参数 | 提取规则 | 默认值 | +|------|---------|--------| +| `design_system` | 匹配9套设计体系关键词表 | Neutral Modern | +| `platform` | 匹配6种平台关键词表 | 响应式Web | +| `page_type` | 匹配13种页面类型关键词表 | 通用前端 | +| `page_topic` | 提取页面主题（产品名/功能名） | [待确认] | +| `target_audience` | 提取目标用户角色 | null | +| `core_content` | 提取核心功能描述（1-2句） | [待确认] | +| `multi_view` | 检测是否含≥2个功能模块 | false | + +> 预提取的设计简报参数直接注入 `delivery_instructions` 的 `parameters` 中，下游技能无需再次推断。 + +### 0.7 缺失信息检测 + +检测下游技能所需但用户未提供的关键信息，生成追问清单： + +| 检测项 | 对应域技能 | 阻断级别 | 追问示例 | +|--------|-----------|---------|---------| +| `project_name` 缺失 | PRD/架构/拆分 | 非阻断（有默认值） | "请问这个需求属于哪个项目？" | +| `requirement_text` 过于模糊 | PRD | 阻断 | "能否详细描述一下核心功能和目标用户？" | +| `page_topic` 缺失（原型） | 原型 | 阻断 | "请问页面的主题是什么？比如'客户管理后台'" | +| `design_system` 无法推断 | 原型 | 非阻断（有默认值） | "请问偏好哪种设计风格？" | +| `team_members` 缺失（拆分） | 拆分 | 非阻断（标注"待分配"） | "请提供团队成员列表，用于处理人建议" | +| `sprint_info` 缺失（拆分） | 拆分 | 非阻断（跳过迭代规划） | "是否需要规划到特定迭代？" | +| `tech_constraints` 缺失（架构） | 架构 | 非阻断（按最佳实践推荐） | "是否有技术栈要求？如指定框架/数据库" | + +#### 追问规则 +1. **一次性追问**：所有缺失项合并为一次提问，不分多次打断 +2. **阻断项优先**：阻断项排在前面，非阻断项排在后面并标注默认值 +3. **提供选项**：对设计体系/平台等枚举型参数，提供选项列表 +4. **最多追问一次**：用户回复后不再追问，按回复值或默认值执行 + +### 0.8 任务编排规则 + +#### 单步模式（single） + +当 `intent.primary_domain` 为单一域且无 `secondary_domains` 时： +- 直接生成1条 `delivery_instructions`，路由到对应域技能 +- `task_plan.execution_mode = "single"` +- `task_plan.steps` 仅含1个步骤 + +#### 串联模式（sequential） + +当识别为复合请求时： +- 按依赖关系生成有序步骤链 +- 前序步骤的输出作为后序步骤的输入 +- `task_plan.execution_mode = "sequential"` +- 每步 `depends_on` 指向前序步骤ID +- **执行策略**：逐步执行，前序完成后将输出注入后序的 `parameters` + +#### 并行模式（parallel） + +当复合请求中存在无依赖关系的步骤时： +- 如"架构设计 + 原型设计"（两者都依赖PRD但互不依赖） +- `task_plan.execution_mode = "parallel"` +- 无依赖的步骤 `depends_on` 相同（都指向PRD步骤） +- **执行策略**：PRD完成后，架构和原型可并行生成 + +#### 依赖关系矩阵 + +| 下游技能 | 依赖上游 | 依赖字段 | +|---------|---------|---------| +| 架构设计 | PRD | `prd_content` ← PRD输出文件内容 | +| 原型 | PRD（页面设计章节） | `core_content` / `page_topic` ← PRD第8章 | +| 拆分 | PRD（功能列表章节） | `requirement_content` ← PRD全文 | +| 架构 ← → 原型 | 无直接依赖 | 可并行 | + +### 0.9 质量检查清单 + +- [ ] `intent.primary_domain` 是否准确匹配用户意图 +- [ ] `intent_confidence` 是否合理（≥0.5） +- [ ] `task_plan.steps` 的依赖关系是否正确（无循环依赖） +- [ ] `context_summary.requirement_text` 是否已去除口语化、补全隐含信息 +- [ ] `context_summary.key_entities` 是否提取了所有功能模块和用户角色 +- [ ] `context_summary.design_hints` 是否在路由含原型时已预提取 +- [ ] `missing_info` 中的阻断项是否已识别 +- [ ] `delivery_instructions` 的 `parameters` 是否已用 `context_summary` 预填 +- [ ] 复合请求的串联顺序是否符合依赖矩阵 + +### 0.10 输出示例 + +#### 示例1：单步请求 + +**用户输入**："帮我写一个在线商城的PRD" + +**输出**： +```json +{ + "meta": { + "request_id": "req-001", + "timestamp": "2026-09-22T10:00:00", + "user_input_raw": "帮我写一个在线商城的PRD", + "intent_confidence": 0.95 + }, + "intent": { + "primary_domain": "prd", + "secondary_domains": [], + "action_type": "create", + "description": "用户要求生成在线商城的PRD文档" + }, + "task_plan": { + "execution_mode": "single", + "steps": [ + { + "step_id": 1, + "skill": "srdcloud-prd-distilled", + "skill_label": "PRD生成", + "depends_on": [], + "status": "ready" + } + ] + }, + "context_summary": { + "project_name": "在线商城", + "requirement_text": "在线商城系统，支持商品浏览、购物车、订单管理、支付等功能", + "key_entities": ["在线商城", "商品浏览", "购物车", "订单管理", "支付"], + "tech_constraints": null, + "design_hints": null, + "team_info": null, + "sprint_info": null + }, + "missing_info": [ + { + "field": "tech_constraints", + "reason": "用户未提及技术栈要求", + "question": "是否有技术栈要求？如指定框架/数据库", + "is_blocking": false, + "default_value": null + } + ], + "delivery_instructions": [ + { + "target_skill": "srdcloud-prd-distilled", + "parameters": { + "requirement_text": "在线商城系统，支持商品浏览、购物车、订单管理、支付等功能", + "project_name": "在线商城" + } + } + ] +} +``` + +#### 示例2：复合请求（串联模式） + +**用户输入**："帮我做一个客户跟进提醒功能，要PRD、技术方案和原型" + +**输出**： +```json +{ + "meta": { + "request_id": "req-002", + "timestamp": "2026-09-22T10:05:00", + "user_input_raw": "帮我做一个客户跟进提醒功能，要PRD、技术方案和原型", + "intent_confidence": 0.9 + }, + "intent": { + "primary_domain": "multi_step", + "secondary_domains": ["prd", "architecture", "prototype"], + "action_type": "create", + "description": "用户要求完整的产品设计流程：PRD→架构设计→HTML原型" + }, + "task_plan": { + "execution_mode": "sequential", + "steps": [ + { + "step_id": 1, + "skill": "srdcloud-prd-distilled", + "skill_label": "PRD生成", + "depends_on": [], + "status": "ready" + }, + { + "step_id": 2, + "skill": "architecture-design-doc-distilled", + "skill_label": "架构设计文档", + "depends_on": [1], + "status": "blocked" + }, + { + "step_id": 3, + "skill": "design-proto-distilled", + "skill_label": "HTML原型", + "depends_on": [1], + "status": "blocked" + } + ] + }, + "context_summary": { + "project_name": "客户跟进提醒", + "requirement_text": "客户跟进提醒功能，支持设置跟进提醒时间、多渠道消息推送（企微/站内）、逾期升级提醒、主管逾期客户看板", + "key_entities": ["客户跟进", "提醒设置", "消息推送", "企微通知", "站内消息", "逾期升级", "主管看板"], + "tech_constraints": null, + "design_hints": { + "design_system": "Ant", + "platform": "桌面Web", + "page_type": "dashboard" + }, + "team_info": null, + "sprint_info": null + }, + "missing_info": [ + { + "field": "page_topic", + "reason": "原型页面主题需确认", + "question": "原型的页面主题是什么？如'客户管理后台'或'跟进提醒看板'", + "is_blocking": true, + "default_value": null + } + ], + "delivery_instructions": [ + { + "target_skill": "srdcloud-prd-distilled", + "parameters": { + "requirement_text": "客户跟进提醒功能，支持设置跟进提醒时间、多渠道消息推送（企微/站内）、逾期升级提醒、主管逾期客户看板", + "project_name": "客户跟进提醒" + } + } + ] +} +``` + +> **注意**：步骤2和步骤3的 `delivery_instructions` 在步骤1完成后动态生成，将PRD输出内容注入为 `prd_content` 参数。 + +#### 示例3：并行模式 + +**用户输入**："根据这个PRD同时出技术方案和原型" + +**输出**： +```json +{ + "meta": { + "request_id": "req-003", + "timestamp": "2026-09-22T10:10:00", + "user_input_raw": "根据这个PRD同时出技术方案和原型", + "intent_confidence": 0.85 + }, + "intent": { + "primary_domain": "multi_step", + "secondary_domains": ["architecture", "prototype"], + "action_type": "create", + "description": "用户已有PRD，要求并行生成架构设计文档和HTML原型" + }, + "task_plan": { + "execution_mode": "parallel", + "steps": [ + { + "step_id": 1, + "skill": "architecture-design-doc-distilled", + "skill_label": "架构设计文档", + "depends_on": [], + "status": "ready" + }, + { + "step_id": 2, + "skill": "design-proto-distilled", + "skill_label": "HTML原型", + "depends_on": [], + "status": "ready" + } + ] + }, + "context_summary": { + "project_name": "[从对话历史提取]", + "requirement_text": "[从对话历史提取PRD内容]", + "key_entities": [], + "tech_constraints": null, + "design_hints": { + "design_system": "Ant", + "platform": "桌面Web", + "page_type": "dashboard" + }, + "team_info": null, + "sprint_info": null + }, + "missing_info": [], + "delivery_instructions": [ + { + "target_skill": "architecture-design-doc-distilled", + "parameters": { + "prd_content": "{从对话历史提取的PRD全文}", + "project_name": "{从对话历史提取}" + } + }, + { + "target_skill": "design-proto-distilled", + "parameters": { + "design_system": "Ant", + "platform": "桌面Web", + "page_type": "dashboard", + "page_topic": "{从PRD第8章提取}", + "core_content": "{从PRD提取核心功能描述}" + } + } + ] +} +``` + +### 0.11 交付给研发云数字员工的总指令 + +总控技能本身不直接交付文件给研发云数字员工，而是将 `delivery_instructions` 分发给下游域技能执行。下游域技能完成后，各自按其交付指令（见技能1-4的对应章节）与研发云数字员工协同。 + +当所有步骤完成后，总控技能可生成一份**执行摘要**： + +```json +{ + "execution_summary": { + "request_id": "req-002", + "total_steps": 3, + "completed_steps": 3, + "artifacts": [ + { + "step_id": 1, + "skill": "srdcloud-prd-distilled", + "artifact_path": "PRD-客户跟进提醒.md", + "delivery_action": "upload_to_doc_space" + }, + { + "step_id": 2, + "skill": "architecture-design-doc-distilled", + "artifact_path": "tech-spec-客户跟进提醒.md", + "delivery_action": "upload_to_doc_space" + }, + { + "step_id": 3, + "skill": "design-proto-distilled", + "artifact_path": "客户管理后台-proto.html", + "delivery_action": "save_to_design_center" + } + ], + "next_step_suggestion": "可继续调用工作项拆分建议技能，将PRD转化为工作项" + } +} +``` + +--- + +## 技能 1：PRD 生成（srdcloud-prd-distilled） + +### 1.1 职责 + +将用户需求描述（自然语言/问需单内容/附件摘要）转化为**结构化产品需求文档（PRD）**，产出为 Markdown 文件，交付给研发云数字员工上传文档空间或关联到工作项。 + +### 1.2 输入 + +| 字段 | 类型 | 必填 | 说明 | +|------|------|------|------| +| `requirement_text` | String | 是 | 用户原始需求描述或问需单内容摘要 | +| `project_name` | String | 否 | 项目名称，用于文档命名 `PRD-{项目名称}.md` | +| `template_override` | String | 否 | 用户自定义模板要求（章节结构/格式约束） | +| `reference_docs` | String[] | 否 | 参考文档内容（已有PRD、竞品分析等） | +| `existing_workitems` | String | 否 | 已有工作项摘要（用于增量PRD场景） | + +### 1.3 输出（中间产物） + +**文件**：`PRD-{项目名称}.md`（Markdown 格式） + +**标准模板结构**（9 章，用户无自定义要求时使用）： + +```markdown +## 1. 功能名 +[功能名称] + +## 2. 需求描述 +核心需求的简要描述，确保开发团队快速理解总体目标。 + +## 3. 项目概述 +**项目背景**: 简述项目背景和启动原因。 +**目标用户**: 描述主要用户群体及其特征。 +**业务目标**: 明确项目旨在解决的问题或达成的目标。 +**关键指标(KPIs)**: 定义衡量项目成功的KPI。 + +## 4. 用户旅程 +**触发点** → **第一步** → **第二步** → ... → **结束点** + +### 流程图（Mermaid graph TD 格式） +- 判断节点用菱形，流程节点用矩形 +- 标注每步执行角色和核心操作 +- 正确使用 Mermaid 语法，不生成中文标点 + +## 5. 功能列表 +列出所有功能模块名称。 + +## 6. 功能详细描述 +每个功能包含：详细描述、实现逻辑、输入、输出。 + +## 7. 页面列表 +列出所有页面名称。 + +## 8. 页面详细设计 +每个页面包含：布局、元素、交互、边界条件、错误处理。 + +### 页面结构图（markmap 格式） +- 层级：# 主模块 → ## 页面 → ### 功能区域 → #### 控件/操作 → ##### 规则/反馈 +- 覆盖控件输入规则、默认文案、交互动作、成功/失败反馈 +- 节点命名 ≤12 字 + +## 9. 统计需求 +### 用户行为统计（埋点表） +| 序号 | 埋点名称 | 含义 | key值 | 参数 | 备注 | + +### 统计指标 +| 序号 | 统计指标名称 | 定义/公式 | 数据来源 | 目的/用途 | 备注 | +``` + +### 1.4 生成规则 + +1. **需求不清晰时仅追问一次**关键信息，若仍不清晰则按现有信息生成并标注不确定部分 +2. **一次写入**产物文件，不分两步操作 +3. **严格按模板结构**填充，保持核心章节完整性 +4. 流程图必须使用 `mermaid graph TD` 语法，页面结构图必须使用 `markmap` 语法 +5. 所有内容必须**真实可执行**，禁止填充文案（lorem ipsum / "feature one"） +6. 验收标准必须**可量化**（能明确判断通过/不通过） + +### 1.5 质量检查清单 + +- [ ] 9 个章节是否完整（功能名/需求描述/项目概述/用户旅程/功能列表/功能详细描述/页面列表/页面详细设计/统计需求） +- [ ] 流程图是否使用正确的 Mermaid graph TD 语法 +- [ ] 页面结构图是否使用正确的 markmap 语法，层级覆盖到控件级 +- [ ] 每个功能是否有输入/输出/实现逻辑 +- [ ] 每个页面是否有布局/元素/交互/边界条件/错误处理 +- [ ] 统计需求是否包含埋点表和统计指标表 +- [ ] 是否无填充文案、无编造数据 +- [ ] 文件名是否为 `PRD-{项目名称}.md` + +### 1.6 交付给研发云数字员工的指令 + +```json +{ + "skill": "prd-upload", + "artifact_path": "PRD-{项目名称}.md", + "action": "upload_to_doc_space", + "doc_title": "PRD-{项目名称}", + "next_step_hint": "上传文档空间后，可关联到工作项或用于后续架构设计" +} +``` + +--- + +## 技能 2：架构设计文档生成（architecture-design-doc-distilled） + +### 2.1 职责 + +将 PRD 或需求设计文档转化为**可据以实现的技术规约（架构设计文档）**，产出为 Markdown 文件。这是从需求到实现的桥梁——规约一旦冻结，就是开发的唯一依据。 + +### 2.2 输入 + +| 字段 | 类型 | 必填 | 说明 | +|------|------|------|------| +| `prd_content` | String | 是 | PRD 文档内容（来自技能1的输出或用户提供） | +| `tech_constraints` | String | 否 | 技术约束（指定框架/数据库/部署环境等） | +| `existing_architecture` | String | 否 | 已有架构描述（增量设计场景） | +| `project_name` | String | 否 | 项目名称，用于文档命名 | + +### 2.3 输出（中间产物） + +**文件**：`tech-spec-{项目名称}.md`（Markdown 格式） + +**标准模板结构**（5 章 + 修订历史）： + +```markdown +# 技术规约 + +> 状态：📝 草案 | 🧊 已冻结 +> 版本：v1.0 +> 冻结日期：（冻结后填写） + +## 1. 架构设计 +- **整体架构**：（前后端分离 / 单体 / 微服务）+ 架构图（Mermaid） +- **技术选型**： + - 框架：___（理由：） + - 数据库：___（理由：） + - 关键库：___（理由：） +- **部署架构**：（如相关） + +### 架构图（Mermaid） +使用 graph TD 或 graph LR，标注组件间依赖关系和数据流向。 + +## 2. 模块拆分 +| 模块 | 职责 | 依赖 | +|------|------|------| + +### 模块依赖图（Mermaid） +使用 graph TD 展示模块间依赖。 + +## 3. 接口契约（最关键） +每个对外接口必须定义： + +### 接口：{接口名} +- **方法/路径**：`POST /api/xxx` +- **输入**： + ```json + { "field": "type" } + ``` +- **输出（成功）**： + ```json + { "field": "type" } + ``` +- **输出（失败）**： + ```json + { "error": "string", "code": "number" } + ``` +- **错误码**：400 参数错误 / 401 认证失败 / 429 限流 + +## 4. 数据模型 +### 实体：{实体名} +| 字段 | 类型 | 约束 | 说明 | +|------|------|------|------| + +### ER 图（Mermaid erDiagram） +展示实体间关系。 + +## 5. 验收标准 +对应 PRD 的每个功能，写可验证的验收点： + +### 功能：{功能名} +- [ ] 验收点 1：___ +- [ ] 验收点 2：___ + +--- + +## 修订历史 +| 版本 | 日期 | 变更内容 | 原因 | +|------|------|---------|------| +``` + +### 2.4 生成规则 + +1. **仔细阅读 PRD**，理解每个功能的意图、非功能需求、范围边界。不清楚的地方在文档中标注 `[待确认]` +2. **架构设计要具体**：明确整体架构类型、技术选型理由、部署方案 +3. **接口契约是硬约束**：字段名、类型、错误码都要明确，实现时不得偏离 +4. **验收标准要可验证**：每条都能明确判断"通过"或"不通过" +5. **技术选型要说明理由**——为什么选这个、不选那个 +6. 如果 PRD 涉及 UI，规约里应包含前端组件/页面的结构定义 +7. 架构图、模块依赖图、ER 图必须使用 Mermaid 语法 +8. **规约要具体到可实现、可验收**——模糊的规约（如"提供良好的用户体验"）无法接受 + +### 2.5 质量检查清单 + +- [ ] 架构设计是否明确整体架构类型 + 技术选型理由 +- [ ] 架构图是否使用正确的 Mermaid 语法 +- [ ] 模块拆分表是否完整（模块/职责/依赖三列） +- [ ] 每个接口是否包含：方法/路径、输入、输出（成功/失败）、错误码 +- [ ] 数据模型是否包含：字段、类型、约束、说明 +- [ ] ER 图是否使用正确的 Mermaid erDiagram 语法 +- [ ] 验收标准是否对应 PRD 中的每个功能，且每条可验证 +- [ ] 是否无模糊描述（"良好的用户体验"等不可验收的描述） +- [ ] 文件名是否为 `tech-spec-{项目名称}.md` + +### 2.6 交付给研发云数字员工的指令 + +```json +{ + "skill": "tech-spec-upload", + "artifact_path": "tech-spec-{项目名称}.md", + "action": "upload_to_doc_space", + "doc_title": "技术规约-{项目名称}", + "next_step_hint": "上传后可关联到版本或工作项，作为开发依据" +} +``` + +--- + +## 技能 3：HTML 原型生成（design-proto-distilled） + +### 3.1 职责 + +根据设计简报，生成**生产级自包含 HTML 原型文件**。这是外部 Coding Agent 价值最高的技能——直接产出可运行的 HTML 文件，交付给研发云数字员工保存到设计中心。 + +### 3.2 输入（设计简报 Design Brief） + +| 字段 | 类型 | 必填 | 说明 | +|------|------|------|------| +| `design_system` | String | 是 | 设计体系（9选1，见下方速查表） | +| `platform` | String | 是 | 目标平台（6选1，见下方速查表） | +| `page_type` | String | 是 | 页面类型（13种子技能或通用前端） | +| `page_topic` | String | 是 | 页面主题（如"AI产品发布会""客户管理后台"） | +| `target_audience` | String | 否 | 目标受众（如"技术开发者""销售团队"） | +| `core_content` | String | 是 | 核心内容摘要（1-2句话描述页面主要内容） | +| `component_library` | String | 否 | 组件库（element-plus / shadcn，不传则不启用） | +| `multi_view` | Boolean | 否 | 是否多视图（≥2个功能模块时为true） | + +### 3.3 设计体系速查表（9套） + +| 编号 | 名称 | 主色调 | 适用场景 | 关键词 | +|------|------|--------|---------|--------| +| 1 | Neutral Modern | 浅蓝 | 通用极简、B2B、仪表盘 | 简约/现代/清爽 | +| 2 | Claude | 暖棕 | 文档、博客、内容型 | 中文/博客/温暖 | +| 3 | ElevenLabs | 青蓝 | 音频、轻量化 | 音频/语音/优雅 | +| 4 | Hugging Face | 暖黄 | 开发者工具、ML | ML/开源/模型 | +| 5 | MiniMax | 淡紫 | 数字人、多模态 | 海螺/视频/中国AI | +| 6 | Runway | 亮蓝 | 创意AIGC、影视 | 电影/创意/影视 | +| 7 | OpenAI | 极简白 | AI研究、极简科技 | AI/OpenAI/研究 | +| 8 | Ant | 商务蓝 | 政企金融、后台 | 后台/数据/企业 | +| 9 | Colorful | 灼橙 | 多彩创意 | 多彩/活泼/创意 | + +> 默认值：Neutral Modern + +### 3.4 平台速查表（6种） + +| 编号 | 名称 | 关键词 | 默认设计体系联动 | +|------|------|--------|-----------------| +| 1 | 响应式Web | 分享/多端/落地页/网页 | Neutral Modern | +| 2 | 桌面Web | 桌面/后台/大屏 | Ant | +| 3 | iOS应用 | iPhone/iOS | Neutral Modern | +| 4 | Android应用 | Android | Neutral Modern | +| 5 | 平板应用 | iPad/平板 | Neutral Modern | +| 6 | 桌面应用 | Electron/客户端 | Neutral Modern | + +> 默认值：响应式Web + +### 3.5 页面类型速查表（13种子技能 + 通用前端） + +| 关键词 | 页面类型 | 推荐设计体系 | 推荐平台 | +|--------|---------|-------------|---------| +| FAQ/常见问题/帮助中心 | faq-page | OpenAI | 响应式Web | +| 登录/注册/sign in | 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 | pricing-page | Neutral Modern | 响应式Web | +| 邮件/newsletter | email-marketing | MiniMax | 响应式Web | +| 海报/朋友圈/分享图 | poster-hero | Runway | 桌面Web | +| 看板/kanban/task board | kanban-board | Ant | 桌面Web | +| 发票/invoice/账单 | invoice | Neutral Modern | 响应式Web | +| 文档/docs/guide/tutorial | docs-page | OpenAI | 桌面Web | +| 原型/prototype/demo/页面 | 通用前端 | 按关键词推断 | 按关键词推断 | + +### 3.6 输出（中间产物） + +**文件**：`{page_topic}-proto.html`（单个自包含 HTML 文件） + +**产物必须满足**： +1. **自包含**：所有 CSS 和 JS 内联在单个 HTML 文件中，不引入任何 CDN/外部脚本 +2. **可直接运行**：保存为 .html 文件后双击即可在浏览器中打开 +3. **语义化**：使用 HTML5 语义化标签 +4. **可访问**：键盘可达、ARIA 属性正确、对比度达标 +5. **无占位符泄漏**：所有内容都是真实的、与简报相关的文本 + +### 3.7 代码合成规则（铁律） + +#### 设计令牌注入 +- 将设计体系的 `tokens.css` 中的 `:root { ... }` 块整体注入 HTML `