工作流 11：从需求到可交付代码的 AI 多专家开发工作流¶
适用岗位：程序员、技术负责人、独立开发者、产品型开发者
真实场景：你接到一个功能需求（一段口头描述、一个 issue、或一份产品文档），需要在保证质量的前提下完成从需求理解到可交付代码的全过程，而不是直接让 AI 写一坨能跑但难维护的代码。
最终目标：一份可交付的代码包，包含：澄清后的需求清单、技术方案、数据结构与接口定义、实现代码、测试用例、代码审查报告、重构建议、技术文档，以及交付检查清单。
输入材料清单¶
- 原始需求（issue / 产品文档 / 口头描述整理稿）
- 技术栈约束（语言、框架、运行环境、版本要求）
- 现有代码库情况（是否在已有项目中开发，相关模块路径）
- 非功能要求（性能、并发、安全等级、兼容性）
- 交付标准（是否需要测试覆盖率、文档、CI 通过）
工作流总览¶
节点 1：需求澄清专家
↓ 输出：结构化需求清单 + 待确认项
节点 2：技术方案专家
↓ 输出：技术方案文档（架构 + 选型 + 权衡）
节点 3：数据结构与接口专家
↓ 输出：数据模型 + 接口定义（签名 + 契约）
节点 4：代码生成专家
↓ 输出：实现代码（含注释）
节点 5：测试用例专家
↓ 输出：测试用例 + 边界用例清单
节点 6：代码审查专家（招牌节点）
↓ 输出：审查报告（8 维度 + 问题等级）
节点 7：重构建议专家
↓ 输出：重构建议清单（按收益排序）
节点 8：文档生成专家
↓ 输出：技术文档（使用 + 维护）
节点 9：交付检查专家
↓ 输出：交付检查清单结果
最终交付：可交付代码包
专家节点详解¶
每个节点包含六部分：节点定位、输入与输出、使用顺序、提示词包（A 快速 / B 专家 / C 自查 / D 返修）、交付给下游节点、人工验收清单。
C 自查审稿版和 D 返修优化版是当前节点内部的工作模式，不是新的专家角色。
节点 1：需求澄清专家¶
1.1 节点定位¶
将模糊或口语化的需求转化为结构化、可验证的需求清单，并标记所有需要确认的歧义点。需求不清就开始写代码，是返工的首要原因。
1.2 输入与输出¶
输入：原始需求 + 技术栈约束 + 非功能要求
输出：结构化需求清单（功能需求 + 非功能需求 + 验收标准 + 待确认项）
1.3 使用顺序¶
- 先用「快速生成版」得到结构化需求初稿。
- 需求复杂或涉及多方依赖时，改用「专家增强版」。
- 用「自查审稿版」检查是否有需求缺少验收标准、是否有隐藏歧义。
- 有问题则用「返修优化版」补充。
- 对照 1.6 验收清单确认，通过后交给节点 2。
1.4 提示词包¶
A. 快速生成版¶
你是一位资深开发者。请将以下需求整理为结构化需求清单。
原始需求：【粘贴需求】
技术栈：【填入语言/框架】
输出：
1. 功能需求（编号列表，每条可独立验证）
2. 非功能需求（性能/安全/兼容性，如有）
3. 每条需求的验收标准（怎样算完成）
4. 待确认项（歧义或缺失信息，标注需向谁确认）
B. 专家增强版¶
你是一位资深需求分析工程师。
任务：将以下原始需求转化为开发可直接执行的结构化需求清单。
输入：
- 原始需求：【粘贴需求】
- 技术栈约束：【填入语言/框架/版本】
- 现有代码库情况：【填入是否已有项目、相关模块】
- 非功能要求：【填入性能/并发/安全等级】
处理步骤：
1. 拆分功能需求为可独立验证的原子条目（编号 R-001 格式）
2. 为每条需求标注优先级（必须/应该/可选）
3. 为每条需求定义明确的验收标准（输入→预期输出）
4. 识别需求之间的依赖关系
5. 列出所有假设前提（开发默认成立但未确认的条件）
6. 列出待确认歧义项（标注影响范围）
输出格式：需求清单表格（编号|描述|优先级|验收标准|依赖）+ 假设前提清单 + 待确认项清单
约束：每条需求必须可验证，不能出现"做好用户体验"这类无法判断完成的描述。
质量标准：他人仅凭此清单即可判断功能是否完成，无需追问。
常见失败情况：把多个功能混在一条需求里；验收标准写成"功能正常"这类无法验证的表述。
C. 自查审稿版¶
此为当前节点的自查模式，不是新的专家角色。
请检查以下需求清单是否存在以下问题：
1. 是否有需求条目混合了多个功能（应拆分为多条）？
2. 是否有需求缺少可验证的验收标准？
3. 待确认项是否标注了影响范围和确认对象？
4. 是否遗漏了非功能需求（性能/安全/兼容性）？
【粘贴需求清单】
逐条说明问题。
D. 返修优化版¶
1.5 交付给下游节点¶
将结构化需求清单（含待确认项）复制，交给节点 2（技术方案专家）。待确认项应在技术方案设计前完成确认，或在方案中标注"待确认后调整"。
1.6 人工验收清单¶
- [ ] 每条功能需求是否可独立验证？
- [ ] 每条需求是否有明确的验收标准（输入→预期输出）？
- [ ] 待确认项是否都标注了确认对象？
- [ ] 是否覆盖了非功能需求？
节点 2：技术方案专家¶
2.1 节点定位¶
基于需求清单，设计技术实现方案，包括架构选择、技术选型和关键权衡。方案先行能避免"写到一半发现架构不对"的返工。
2.2 输入与输出¶
输入：节点 1 需求清单 + 技术栈约束 + 现有代码库情况
输出：技术方案文档（整体架构 + 模块划分 + 技术选型 + 关键权衡 + 风险点）
2.3 使用顺序¶
- 先用「快速生成版」得到方案初稿。
- 涉及架构决策或多方案权衡时，改用「专家增强版」。
- 用「自查审稿版」检查方案是否覆盖所有需求、选型是否合理。
- 有问题则用「返修优化版」修正。
- 对照 2.6 验收清单确认，通过后交给节点 3。
2.4 提示词包¶
A. 快速生成版¶
你是一位软件架构师。请根据以下需求设计技术方案。
需求清单：【粘贴节点1的需求】
技术栈约束：【填入】
输出：
1. 整体架构（模块/分层）
2. 关键技术选型（库/框架，附选择理由）
3. 数据流向（请求到响应的处理路径）
4. 风险点（实现中可能的难点）
B. 专家增强版¶
你是一位资深软件架构师。
任务：为以下需求设计可落地的技术方案。
输入：
- 需求清单：【粘贴节点1的完整清单】
- 技术栈约束：【填入语言/框架/版本】
- 现有代码库：【填入是否在已有项目内、相关模块路径】
- 非功能要求：【填入性能/并发/安全】
处理步骤：
1. 划分模块/组件，明确各模块职责边界
2. 设计数据流向（从入口到出口的处理路径）
3. 针对关键技术点提供 2 个候选方案并对比（性能/复杂度/维护成本）
4. 标注每个选型决策的权衡理由
5. 识别实现风险点和应对策略
6. 如在已有项目中，说明与现有代码的集成方式
输出格式：
- 架构概览（文字 + 模块关系）
- 模块职责表（模块|职责|依赖）
- 选型对比表（技术点|方案A|方案B|选择|理由）
- 风险点清单（风险|等级|应对）
约束：方案必须覆盖需求清单的每一条；选型必须给出理由，不能只说"用 X"。
质量标准：开发者据此可直接进入接口设计，无需重新调研架构。
常见失败情况：过度设计（为简单需求引入复杂架构）；选型无理由；遗漏非功能需求对架构的影响。
C. 自查审稿版¶
此为当前节点的自查模式，不是新的专家角色。
请检查以下技术方案是否存在以下问题：
1. 是否每条功能需求都能在方案中找到对应的实现路径？
2. 是否存在过度设计（为当前需求规模引入了不必要的复杂度）？
3. 技术选型是否都给出了理由？
4. 是否考虑了非功能需求（性能/并发/安全）对架构的影响？
5. 风险点是否都有应对策略？
【粘贴技术方案】
逐条说明问题。
D. 返修优化版¶
2.5 交付给下游节点¶
将技术方案文档复制，交给节点 3（数据结构与接口专家）。模块划分和数据流向是接口设计的直接依据。
2.6 人工验收清单¶
- [ ] 是否每条功能需求都有对应的实现路径？
- [ ] 是否没有过度设计？
- [ ] 技术选型是否都有理由？
- [ ] 风险点是否都有应对策略？
节点 3：数据结构与接口专家¶
3.1 节点定位¶
定义数据模型和接口契约，包括数据结构、函数签名、API 定义和输入输出约定。接口先定义清楚，代码生成和测试才有明确目标。
3.2 输入与输出¶
输入：节点 2 技术方案 + 节点 1 需求清单
输出：数据模型定义 + 接口签名 + 接口契约（参数/返回/异常）
3.3 使用顺序¶
- 先用「快速生成版」得到接口定义初稿。
- 涉及复杂数据关系或多接口协作时，改用「专家增强版」。
- 用「自查审稿版」检查接口是否完整、契约是否明确。
- 有问题则用「返修优化版」修正。
- 对照 3.6 验收清单确认，通过后交给节点 4 和节点 5。
3.4 提示词包¶
A. 快速生成版¶
你是一位接口设计工程师。请根据技术方案定义数据结构和接口。
技术方案：【粘贴节点2的方案摘要】
技术栈：【填入语言】
输出：
1. 数据模型（结构体/类/表，含字段类型）
2. 接口签名（函数名 + 参数 + 返回值）
3. 每个接口的输入输出约定
4. 异常/错误返回定义
B. 专家增强版¶
你是一位资深 API 与数据建模工程师。
任务：为以下技术方案定义完整的数据结构和接口契约。
输入：
- 技术方案：【粘贴节点2的完整方案】
- 需求清单：【粘贴节点1的需求】
- 技术栈：【填入语言/框架】
处理步骤：
1. 定义核心数据模型（字段名、类型、约束、默认值）
2. 定义模块间接口签名（命名遵循语言惯例）
3. 为每个接口编写契约：
- 输入参数（类型、是否必填、取值范围）
- 返回值（类型、结构）
- 异常/错误码（触发条件、返回内容）
- 副作用（是否修改状态、是否有 IO）
4. 标注接口的幂等性、并发安全性（如相关）
输出格式：
- 数据模型定义（代码块）
- 接口契约表（接口|参数|返回|异常|副作用）
约束：接口命名与签名必须符合目标语言惯例；每个接口必须定义错误处理路径。
质量标准：代码生成专家据此可直接实现，测试专家据此可直接编写用例。
常见失败情况：只定义正常路径不定义错误返回；数据模型缺少约束（如字段长度、是否可空）。
C. 自查审稿版¶
此为当前节点的自查模式，不是新的专家角色。
请检查以下接口定义是否存在以下问题：
1. 是否每个接口都定义了错误/异常返回（不只有正常路径）？
2. 数据模型字段是否标注了类型和约束（可空、长度、范围）？
3. 接口命名是否符合目标语言惯例？
4. 是否覆盖了需求清单中所有需要接口支撑的功能？
【粘贴接口定义】
逐条说明问题。
D. 返修优化版¶
3.5 交付给下游节点¶
将数据模型和接口契约复制，同时交给： - 节点 4（代码生成专家）：作为实现目标。 - 节点 5（测试用例专家）：作为测试目标（可与节点 4 并行）。
3.6 人工验收清单¶
- [ ] 是否每个接口都定义了错误/异常返回？
- [ ] 数据模型字段是否都有类型和约束？
- [ ] 接口命名是否符合语言惯例？
节点 4：代码生成专家¶
4.1 节点定位¶
基于接口契约实现功能代码，遵循技术方案的架构约定。代码必须实现接口定义的全部契约，包括错误处理路径。
4.2 输入与输出¶
输入：节点 3 接口契约 + 节点 2 技术方案
输出：实现代码（含必要注释）
4.3 使用顺序¶
- 先用「快速生成版」生成实现代码。
- 涉及复杂逻辑或需要遵循特定规范时，改用「专家增强版」。
- 用「自查审稿版」检查代码是否实现全部契约、是否有明显问题。
- 有问题则用「返修优化版」修正。
- 对照 4.6 验收清单确认，通过后交给节点 6。
4.4 提示词包¶
A. 快速生成版¶
B. 专家增强版¶
你是一位资深开发工程师，注重代码可读性和可维护性。
任务：根据接口契约实现功能代码。
输入：
- 接口契约：【粘贴节点3的完整契约】
- 技术方案：【粘贴节点2的架构约定】
- 技术栈：【填入语言/框架/版本】
- 现有代码风格（如有）：【粘贴或描述项目代码规范】
处理步骤：
1. 按接口契约逐个实现，包含全部错误处理路径
2. 遵循技术方案的模块划分和架构约定
3. 关键决策点和复杂逻辑添加注释（解释为什么，而非是什么）
4. 避免硬编码（配置项、魔法数字提取为常量或配置）
5. 输入校验放在边界处
输出格式：
- 按模块组织的代码（代码块，标注文件路径）
- 关键实现说明（哪些地方做了什么权衡）
约束：必须实现接口契约定义的全部错误返回；不得引入接口契约之外的功能；不得硬编码可配置值。
质量标准：代码可直接进入审查环节，无需补全基本错误处理。
常见失败情况：只实现正常路径忽略错误处理；硬编码配置值；为简单逻辑添加冗余抽象层。
C. 自查审稿版¶
此为当前节点的自查模式，不是新的专家角色。
请检查以下代码是否存在以下问题：
1. 是否实现了接口契约定义的全部错误返回路径？
2. 是否存在硬编码（魔法数字、写死的配置）？
3. 是否实现了接口契约之外的功能（范围蔓延）？
4. 边界输入是否做了校验？
5. 注释是否解释了"为什么"而非复述代码？
【粘贴代码】
逐条说明问题。
D. 返修优化版¶
4.5 交付给下游节点¶
将实现代码复制，交给节点 6（代码审查专家）。同时确保节点 5 的测试用例已基于同一份接口契约编写。
4.6 人工验收清单¶
- [ ] 是否实现了接口契约的全部错误返回路径？
- [ ] 是否没有硬编码可配置值？
- [ ] 是否没有引入契约外的功能？
- [ ] 边界输入是否做了校验？
节点 5：测试用例专家¶
5.1 节点定位¶
基于接口契约编写测试用例，覆盖正常路径、边界条件和异常场景。测试用例基于契约而非实现编写，才能真正验证功能正确性。
5.2 输入与输出¶
输入：节点 3 接口契约 + 节点 1 需求验收标准
输出：测试用例（正常 + 边界 + 异常）+ 边界用例清单
5.3 使用顺序¶
- 先用「快速生成版」生成测试用例。
- 需要高覆盖率或复杂边界分析时，改用「专家增强版」。
- 用「自查审稿版」检查覆盖是否完整。
- 有问题则用「返修优化版」补充。
- 对照 5.6 验收清单确认，通过后交给节点 6。
5.4 提示词包¶
A. 快速生成版¶
你是一位测试工程师。请根据接口契约编写测试用例。
接口契约：【粘贴节点3的契约】
技术栈/测试框架：【填入】
输出：
- 正常路径用例
- 边界用例（空值、极值、临界）
- 异常用例（错误输入触发的错误返回）
每个用例：输入 + 预期输出
B. 专家增强版¶
你是一位资深测试工程师。
任务：根据接口契约和需求验收标准编写测试用例。
输入：
- 接口契约：【粘贴节点3的完整契约】
- 需求验收标准：【粘贴节点1的验收标准】
- 测试框架：【填入框架名】
处理步骤：
1. 为每个接口设计正常路径用例（覆盖验收标准）
2. 设计边界用例（空、null、最大值、最小值、临界值、超长输入）
3. 设计异常用例（触发每个已定义的错误返回）
4. 标注每个用例对应验证的需求编号
5. 列出未覆盖的场景（如有）及原因
输出格式：
- 测试用例代码（可运行，按接口组织）
- 用例-需求映射表（用例|对应需求|类型）
- 边界用例清单
- 覆盖说明（哪些验收标准已覆盖，哪些受限未覆盖）
约束：每个接口的每个错误返回都必须有对应异常用例；用例必须基于契约编写，不依赖具体实现细节。
质量标准：测试用例可直接运行，覆盖需求清单的全部验收标准。
常见失败情况：只测正常路径；测试依赖实现细节导致重构后失效；遗漏边界和异常用例。
C. 自查审稿版¶
此为当前节点的自查模式，不是新的专家角色。
请检查以下测试用例是否存在以下问题：
1. 是否覆盖了需求清单的每条验收标准？
2. 是否为每个已定义的错误返回都编写了异常用例？
3. 是否覆盖了边界条件（空/极值/临界/超长）？
4. 用例是否依赖了具体实现细节（导致重构后失效）？
【粘贴测试用例】
逐条说明问题。
D. 返修优化版¶
5.5 交付给下游节点¶
将测试用例和覆盖说明复制，交给节点 6（代码审查专家）。审查时会对照测试覆盖情况。
5.6 人工验收清单¶
- [ ] 是否覆盖了每条需求的验收标准？
- [ ] 是否为每个错误返回编写了异常用例？
- [ ] 是否覆盖了边界条件？
节点 6：代码审查专家（招牌节点）¶
6.1 节点定位¶
这是本工作流的招牌节点。 对实现代码进行系统性审查，覆盖八个维度：是否满足需求、是否存在明显 bug、是否存在异常处理缺失、是否存在硬编码、是否存在过度设计、是否存在安全隐患、是否容易维护、是否需要测试覆盖。审查输出按问题等级排序，给出可直接执行的修改建议。
6.2 输入与输出¶
输入：节点 4 实现代码 + 节点 1 需求清单 + 节点 3 接口契约 + 节点 5 测试用例
输出：代码审查报告（八维度结果 + 问题等级 + 修改建议）
6.3 使用顺序¶
- 先用「快速生成版」做基础审查。
- 正式代码审查或交付前审查，使用「专家增强版」。
- 用「自查审稿版」确认审查是否遗漏维度。
- 审查发现问题则返回节点 4 修改；可用「返修优化版」复审。
- 对照 6.6 验收清单确认。
6.4 提示词包¶
A. 快速生成版¶
你是一位代码审查员。请审查以下代码。
代码：【粘贴代码】
需求：【粘贴节点1需求摘要】
按以下维度审查，每条标注"通过/问题"：
1. 是否满足需求
2. 是否有明显 bug
3. 是否有异常处理缺失
4. 是否有硬编码
5. 是否过度设计
6. 是否有安全隐患
7. 是否容易维护
8. 是否需要补测试覆盖
输出：问题清单 + 修改建议
B. 专家增强版¶
你是一位资深代码审查专家，审查标准严格、建议具体。
任务：对以下代码进行八维度系统审查。
输入：
- 实现代码：【粘贴节点4的代码】
- 需求清单：【粘贴节点1的需求】
- 接口契约：【粘贴节点3的契约】
- 测试用例：【粘贴节点5的用例】
审查维度（逐一评估）：
1. 需求符合性：代码是否实现了需求清单的每一条，有无遗漏或多余
2. 正确性：是否存在逻辑 bug、边界错误、并发问题
3. 异常处理：是否覆盖了接口契约的所有错误路径，有无吞掉异常
4. 硬编码：是否有魔法数字、写死的路径/配置/密钥
5. 过度设计：是否有当前需求不需要的抽象层、配置项、扩展点
6. 安全隐患：注入风险、未校验输入、敏感信息泄露、不安全的依赖调用
7. 可维护性：命名、结构、注释质量、函数复杂度
8. 测试覆盖：现有测试是否覆盖关键路径，哪些需要补充
每个问题标注等级：
- 阻断（Blocker）：必须修复才能交付
- 重要（Major）：应当修复
- 建议（Minor）：可选优化
输出格式：
| 维度 | 等级 | 问题位置 | 问题描述 | 修改建议 |
约束：每个问题必须定位到具体代码位置；修改建议必须可执行，不能是"优化一下"。
质量标准：开发者据此报告可直接修复，无需追问问题在哪、怎么改。
常见失败情况：只看风格不看逻辑；指出问题不给修改方向；遗漏安全维度。
C. 自查审稿版¶
此为当前节点的自查模式，不是新的专家角色。
请检查以下代码审查报告是否存在以下问题：
1. 是否覆盖了全部八个审查维度（尤其是安全隐患维度是否被跳过）？
2. 每个问题是否定位到了具体代码位置？
3. 每个问题是否给出了可执行的修改建议？
4. 问题等级（阻断/重要/建议）是否合理？
【粘贴审查报告】
逐条说明问题。
D. 返修优化版¶
6.5 交付给下游节点¶
- 存在"阻断/重要"问题：返回节点 4（代码生成专家）修复后重新审查。
- 审查通过（无阻断问题）：将审查报告交给节点 7（重构建议专家）。
6.6 人工验收清单¶
- [ ] 是否覆盖了全部八个审查维度？
- [ ] 安全隐患维度是否被实际检查（而非跳过）？
- [ ] 每个问题是否定位到具体代码位置并给出修改建议？
- [ ] 是否所有"阻断"级问题都已修复？
节点 7：重构建议专家¶
7.1 节点定位¶
在代码通过审查后，提供进一步的重构建议，提升代码质量。重构建议按"收益/成本"排序，避免为了重构而重构。
7.2 输入与输出¶
输入：节点 4 实现代码 + 节点 6 审查报告
输出：重构建议清单（按收益排序，含成本估计）
7.3 使用顺序¶
- 先用「快速生成版」得到重构建议。
- 需要系统性质量提升时，改用「专家增强版」。
- 用「自查审稿版」检查建议是否有实际收益、是否改变行为。
- 有问题则用「返修优化版」调整。
- 对照 7.6 验收清单确认，通过后交给节点 8。
7.4 提示词包¶
A. 快速生成版¶
你是一位代码重构顾问。请为以下代码提供重构建议。
代码：【粘贴代码】
审查报告：【粘贴节点6报告摘要】
输出：重构建议清单，每条含：
- 重构点
- 收益（可读性/可维护性/性能）
- 是否改变外部行为（应为否）
B. 专家增强版¶
你是一位资深重构专家，遵循"重构不改变外部行为"的原则。
任务：为通过审查的代码提供有实际收益的重构建议。
输入：
- 实现代码：【粘贴节点4的代码】
- 审查报告：【粘贴节点6的报告】
处理步骤：
1. 识别可改进点（重复代码、过长函数、命名、坏味道）
2. 为每个改进点评估收益（可读性/可维护性/性能/测试性）
3. 评估重构成本（改动范围、回归风险）
4. 按"收益/成本"排序
5. 标注每个重构是否需要相应调整测试
输出格式：
| 重构点 | 收益 | 成本 | 是否改变行为 | 是否需调整测试 |
约束：所有重构必须保持外部行为不变；不建议"为了模式而模式"的改动；优先高收益低成本项。
质量标准：每条建议都能说清"改了之后好在哪"，且可独立实施。
常见失败情况：建议引入不必要的设计模式；重构改变了外部行为；建议无法独立实施（互相耦合）。
C. 自查审稿版¶
此为当前节点的自查模式，不是新的专家角色。
请检查以下重构建议是否存在以下问题：
1. 是否有建议会改变代码的外部行为（重构不应改变行为）？
2. 是否有"为了模式而模式"的过度重构？
3. 每条建议是否说清了具体收益？
4. 建议是否按收益/成本排序？
【粘贴重构建议】
逐条说明问题。
D. 返修优化版¶
7.5 交付给下游节点¶
将重构建议清单复制，交给节点 8（文档生成专家）。文档需反映采纳重构后的最终代码结构。
7.6 人工验收清单¶
- [ ] 是否所有建议都保持外部行为不变？
- [ ] 是否没有过度重构的建议？
- [ ] 建议是否按收益/成本排序？
节点 8：文档生成专家¶
8.1 节点定位¶
为代码生成使用文档和维护文档，让他人（包括未来的自己）能快速理解和使用代码。
8.2 输入与输出¶
输入：节点 3 接口契约 + 节点 4 代码 + 节点 2 技术方案
输出：技术文档（使用说明 + 接口文档 + 维护说明）
8.3 使用顺序¶
- 先用「快速生成版」生成文档初稿。
- 对外交付或开源时，改用「专家增强版」。
- 用「自查审稿版」检查文档与代码是否一致。
- 有问题则用「返修优化版」修正。
- 对照 8.6 验收清单确认，通过后交给节点 9。
8.4 提示词包¶
A. 快速生成版¶
B. 专家增强版¶
你是一位技术文档工程师。
任务：为以下代码生成完整的使用和维护文档。
输入：
- 接口契约：【粘贴节点3】
- 实现代码：【粘贴节点4】
- 技术方案：【粘贴节点2的架构摘要】
文档结构：
1. 功能简介（这段代码解决什么问题）
2. 快速使用（最小可运行示例）
3. 接口文档（每个接口的参数、返回、异常、示例）
4. 架构说明（模块关系，关键设计决策）
5. 维护说明（已知限制、扩展点、修改注意事项）
约束：所有代码示例必须可运行；文档描述必须与实际接口契约一致，不得描述不存在的功能。
质量标准：新成员据此文档可独立使用该模块，无需阅读全部源码。
常见失败情况：文档与代码不一致；示例无法运行；只写"是什么"不写"怎么用"。
C. 自查审稿版¶
此为当前节点的自查模式，不是新的专家角色。
请检查以下文档是否存在以下问题：
1. 文档描述的接口是否与实际接口契约一致？
2. 代码示例是否可运行？
3. 是否描述了不存在的功能？
4. 是否包含了维护注意事项（限制、扩展点）？
【粘贴文档】
逐条说明问题。
D. 返修优化版¶
8.5 交付给下游节点¶
将技术文档复制，交给节点 9（交付检查专家）作为交付物之一。
8.6 人工验收清单¶
- [ ] 文档接口描述是否与实际代码一致？
- [ ] 代码示例是否可运行？
- [ ] 是否包含维护注意事项？
节点 9：交付检查专家¶
9.1 节点定位¶
在交付前进行最终检查，确认所有交付物齐全、质量达标。这是代码出门前的最后一道关卡。
9.2 输入与输出¶
输入：全部前序节点输出（需求/方案/接口/代码/测试/审查/文档）
输出：交付检查清单结果（通过/不通过 + 缺口清单）
9.3 使用顺序¶
- 先用「快速生成版」做交付检查。
- 正式交付前，使用「专家增强版」。
- 用「自查审稿版」确认检查无遗漏。
- 有缺口则返回对应节点补齐。
- 对照 9.6 验收清单确认。
9.4 提示词包¶
A. 快速生成版¶
你是一位交付检查员。请对照以下交付物做交付检查。
需求清单：【粘贴】
代码：【粘贴摘要】
测试：【粘贴摘要】
文档：【粘贴摘要】
检查：
1. 需求是否全部实现
2. 测试是否覆盖验收标准
3. 审查阻断问题是否已清零
4. 文档是否齐全
输出：通过/不通过 + 缺口清单
B. 专家增强版¶
你是一位交付质量负责人。
任务：对完整交付包进行系统性交付检查。
输入：
- 需求清单：【粘贴节点1】
- 技术方案：【粘贴节点2摘要】
- 接口契约：【粘贴节点3摘要】
- 代码：【粘贴节点4摘要】
- 测试用例：【粘贴节点5摘要】
- 审查报告：【粘贴节点6】
- 文档：【粘贴节点8摘要】
检查清单：
1. 需求完整性：每条需求是否都已实现并可追溯
2. 测试覆盖：每条验收标准是否有对应测试且通过
3. 审查闭环：所有"阻断/重要"问题是否已修复
4. 文档齐全：使用文档、接口文档、维护说明是否完整且与代码一致
5. 交付物清单：代码、测试、文档、配置是否齐全
6. 非功能验证：性能/安全等非功能要求是否验证
输出格式：
| 检查项 | 状态 | 缺口/备注 |
+ 总体结论（可交付/需补齐）+ 优先补齐项
约束：任何"阻断"问题未闭环都不能判定为可交付。
质量标准：通过此检查的代码包可直接交付，无遗留必修问题。
常见失败情况：需求实现了但缺测试；审查问题未闭环就交付；文档与代码不同步。
C. 自查审稿版¶
此为当前节点的自查模式，不是新的专家角色。
请检查以下交付检查结果是否存在以下问题：
1. 是否核对了每条需求的实现和测试覆盖？
2. 是否确认了所有阻断问题已闭环？
3. 是否检查了文档与代码的一致性？
4. 结论是否与检查项一致（有缺口却判定可交付）？
【粘贴交付检查结果】
逐条说明问题。
D. 返修优化版¶
9.5 交付给下游节点¶
本节点是工作流终点。检查通过后，整合全部交付物为最终代码包。存在缺口时返回对应节点补齐。
9.6 人工验收清单¶
- [ ] 每条需求是否都已实现并有测试覆盖？
- [ ] 所有阻断级审查问题是否已闭环？
- [ ] 文档是否与代码一致？
- [ ] 交付物（代码/测试/文档/配置）是否齐全？
节点交接说明¶
| 上游节点 | 交接内容 | 下游节点 |
|---|---|---|
| 节点 1 需求澄清 | 结构化需求清单（含待确认项） | 节点 2 |
| 节点 2 技术方案 | 技术方案文档（架构+选型+风险） | 节点 3 |
| 节点 3 接口定义 | 数据模型 + 接口契约 | 节点 4、节点 5 |
| 节点 4 代码生成 | 实现代码 | 节点 6 |
| 节点 5 测试用例 | 测试用例 + 覆盖说明 | 节点 6 |
| 节点 6 代码审查 | 审查报告；有阻断问题则返回节点 4 | 节点 7（或返回节点 4） |
| 节点 7 重构建议 | 重构建议清单 | 节点 8 |
| 节点 8 文档生成 | 技术文档 | 节点 9 |
| 节点 9 交付检查 | 交付检查结果；整合最终代码包 | 最终输出模板 |
最终输出模板¶
【功能名称】交付代码包
━━ 需求 ━━
需求清单：见 节点1 输出（R-001 ...）
待确认项：【已确认 / 列出未决项】
━━ 技术方案 ━━
架构概览：【填入】
关键选型：【填入】
━━ 接口契约 ━━
数据模型：【代码块】
接口定义：【代码块】
━━ 代码 ━━
文件清单：
- path/to/file1 —— 【职责】
- path/to/file2 —— 【职责】
━━ 测试 ━━
测试文件：【路径】
覆盖说明：【覆盖了哪些验收标准】
━━ 审查 ━━
审查结论：【阻断问题已清零】
遗留 Minor 项：【列出或无】
━━ 文档 ━━
文档路径：【填入】
━━ 交付检查 ━━
结论：【可交付 / 需补齐】
常见错误¶
错误 1：跳过需求澄清直接让 AI 写代码
表现：代码写完才发现理解错了需求，整段返工。
修复：必须先完成节点 1，待确认项确认后再进入技术方案。需求不清不写代码。
错误 2：代码审查只看风格不看逻辑和安全
表现：审查只提了命名和格式，漏掉了空指针、未校验输入、SQL 注入等实质问题。
修复：执行节点 6（招牌节点）的八维度审查，尤其确认"正确性""异常处理""安全隐患"三个维度被实际检查，而非跳过。
错误 3：测试依赖实现细节
表现：测试通过，但一重构就大面积失败，因为测试断言的是内部实现而非接口契约。
修复：节点 5 的测试用例必须基于接口契约编写，断言输入输出和错误返回，不断言内部调用过程。
人工验收清单¶
- [ ] 需求清单中每条需求是否可独立验证？
- [ ] 代码是否实现了接口契约的全部错误返回路径？
- [ ] 代码审查是否覆盖了全部八个维度（含安全）？
- [ ] 测试是否覆盖了每条验收标准且基于契约编写？
- [ ] 交付检查中所有阻断问题是否已闭环？
延伸玩法¶
- 变体 1：Bug 修复版：将节点 1 替换为"缺陷复现与定位"，节点 2-3 简化，重点走节点 4（修复）→ 节点 5（回归测试）→ 节点 6（审查），适合处理线上问题。
- 变体 2：小脚本快速版：对一次性脚本，只执行节点 1（需求）→ 节点 4（代码）→ 节点 6（审查，聚焦安全和正确性），省略接口设计和文档。
- 进阶组合：与"工作流 12（Agent 协作工作流）"结合，将本工作流的节点 3 接口契约作为多 Agent 分工的边界定义；与"工作流 13（安全审查工作流）"结合，对节点 4 产出的代码做专项安全审查。