PRD → 原型 → SDD
全链路交付方案

评分细则

• 需求背景（20分）：问题陈述清晰（0-10）+ 目标用户明确（0-10），低于15分打回
• 价值衡量（20分）：业务价值可量化（0-10）+ 与产品路线图对齐（0-10），低于15分打回
• 解决方案（30分）：功能清单完整（0-10）+ 验收标准可测试（0-10）+ 优先级明确（0-10），低于24分打回
• 影响范围（30分）：依赖关系清晰（0-10）+ 数据权限说明（0-10）+ 非功能性需求（性能/安全/可用性）已覆盖（0-10），低于24分打回

命名格式：

{模块}_{页面}_{组件类型}_{序号}

示例：Order_Checkout_Btn_Submit_01

含义：订单模块 → 结算页 → 按钮 → 提交按钮 → 序号01

交付物清单

• .ep 源文件：Pencil 原文件（含全部页面、组件、母版）
• 导出 PDF：全页截图 PDF，用于存档和跨组传阅
• 标注说明文档：独立 Markdown/Word，详述每页交互逻辑
• 组件清单：导出全组件列表（含命名、类型、状态说明）
• 版本记录：记录每次修改日期、内容、修改人

澄清发起流程

• 产品经理在原型设计过程中，发现 PRD 描述不清或存在歧义的条款，立即记录到「需求澄清单」
• 通过协同工具（如飞书/Confluence）提交给原 PRD 作者（产品/业务），须在 2 个工作日内回复
• PRD 作者更新需求后通知产品经理，产品经理确认后继续设计
• 若超过 2 个工作日未回复，技术负责人介入协调

SDD 章节结构

• 章节一：概述 — 模块定位、目标、非功能性约束（性能/安全/可用性）
• 章节二：数据模型 — ER 图、核心实体、字段说明、索引策略
• 章节三：接口协议 — API 清单（路径、方法、请求/响应结构、错误码）
• 章节四：模块设计 — 子模块划分、类/服务设计、核心流程时序图
• 章节五：依赖矩阵 — 模块间依赖关系、上下游接口消费、部署顺序
• 章节六：执行清单 — 研发阶段 / 测试阶段 / 部署阶段具体操作步骤

讲解会要求

• 参与人员：产品经理（主讲）+ 技术负责人 + 相关开发 + 业务代表（观察席）
• 会议时长：每模块 30-60 分钟，视复杂程度而定
• 讲解内容：核心流程走查 → 关键页面说明 → 交互细节 → 异常状态 → Q&A
• 会前准备：产品经理提前在协同工具发布 Pencil 链接和标注文档，开发须提前预览
• 会议产出：讲解纪要（含 Q&A 结论）存入项目文档库

研发阶段

• 基于 SDD 分章节模板生成代码结构（Controller / Service / Mapper / Model）
• 基于代码层级结构自动生成单元测试用例（覆盖率目标 ≥70%）
• CodeBuddy / OpenClaw 辅助代码生成，AI 代码采纳率目标 ≥80%

测试阶段

• Lego MCP 一键拉起测试环境（耗时 5-10 分钟，0 平台切换）
• DDL Skill / MCP 工具将数据库变更申请耗时降低到秒级
• 接口自动化测试：AI 自动识别代码生成测试用例，通过 MCP 一键发起接口自测
• 测试用例覆盖：功能测试 + 异常测试 + 边界测试，测试用例通过率须 ≥95%

产品验收阶段

• 测试报告完成后，产品经理基于原型 + PRD 验收标准进行功能验收
• 验收内容：所有 P0/P1 功能点逐一核查，确认实现与原型一致
• 验收异常记录：若发现与原型不符，提交缺陷单（Bug），开发修复后重新测试
• 验收通过后，产品经理在验收确认单上签字，方可进入部署阶段
• 重要：产品验收是上线前的强制门禁，未通过验收不允许部署

部署阶段

• 七彩石配置 + DDL/DML 工单 + 蓝盾流水线联动
• 接入无人值守：自动完成智研发布单申请和执行
• 部署步骤从 12 步优化至 5 步（理想 2 步），平均节约 0.5 人天/需求

三大知识库

• 业务知识库：业务术语、领域模型、业务规则、行业规范，供 AI 生成符合业务语境的 SDD
• 代码知识库：历史代码结构、最佳实践、组件库文档，供 AI 快速熟悉新模块代码
• 技术规范库：编码规范、接口协议、安全标准、部署手册，供 AI 生成符合团队技术标准的代码

变更分级

• P0 变更（重大）：影响已评审通过的 PRD / 原型 / SDD 主架构，须重新走评审流程，milestone 顺延
• P1 变更（中等）：影响 SDD 局部设计（如接口调整），需技术负责人 + 关联开发评审
• P2 变更（轻微）：文档修正、字段调整，不影响架构和接口，技术负责人单审即可

变更申请流程

• 申请人（产品/设计）填写变更申请单（含：变更内容、原因、影响评估、解决方案）
• 技术负责人评估影响范围和工期
• P0 变更须三方（产品+设计+技术）联合评审签字
• 变更批准后，更新对应文档版本号，通知全相关方

统一校验流程

• 输入接收：获取上一环节的产出物（PRD / 原型 / SDD / 代码 / 测试报告）
• 标准校验：按手册阈值逐项检查（阈值可配置）
• 自动修复：不达标项 AI 自动调整，修复后重新校验
• 输出确认：通过则签发合格证，触发下一环节
• 人工升级：无法自动修复 → 通知责任人处理

Skill 1：PRD 校验 · skill:prd-validate

触发时机：产品经理完成 PRD 初稿后，提交评审前

输出：prd-quality-report.json + 合格/不合格状态 + 评分详情

Skill 2：PRD ↔ 原型 一致性校验 · skill:prd-prototype-consistency

触发时机：PRD 和原型同时产出后，进入交接流程前

输出：consistency-report.json + 一致性得分 + 差异清单（AI已修复/待确认）

Skill 3：原型校验 · skill:prototype-validate

触发时机：产品经理完成原型设计后，提交评审前

输出：prototype-check-report.json + 交接确认单（自动生成）

Skill 4：原型 → SDD 交接校验 · skill:handoff-prototype-sdd

触发时机：原型评审通过后，正式交接给开发前

输出：handover-confirm.json（三方签字电子版）+ 未完成项清单

Skill 5：SDD 校验 · skill:sdd-validate

触发时机：技术负责人完成 SDD 初稿后，提交评审前

输出：sdd-quality-report.json + 章节完整性评分

Skill 6：代码 ↔ SDD 一致性校验 · skill:code-sdd-consistency

触发时机：开发完成代码初版，提交 MR 前

输出：code-sdd-consistency-report.json + 差异清单 + 修改建议

Skill 7：测试验收校验 · skill:test-validate

触发时机：测试完成测试报告后，产品验收前

输出：test-report.json + 测试用例清单 + 覆盖率报告

Skill 8：产品验收校验 · skill:product-acceptance

触发时机：测试报告通过后，产品经理进行验收前

输出：acceptance-report.json + 验收通过/待修复清单 + 产品经理签字确认页

校验报告结构（JSON Schema）

{
  "skill": "skill:prd-validate",
  "timestamp": "2026-04-29T07:00:00Z",
  "status": "PASS | FAIL | AUTO_FIXED",
  "score": 85,
  "checks": [
    {
      "item": "需求评分",
      "threshold": "≥80",
      "actual": 72,
      "result": "FAIL",
      "autoFixApplied": "已重写「解决方案」区段，补充验收标准可测试性描述",
      "recheckResult": "PASS"
    }
  ],
  "blocker": null,  // 或 { "item": "...", "message": "..." }
  "nextAction": "进入原型设计环节",
  "signatures": {
    "product": null,  // null 表示无需签字，需签字时为 "2026-04-29 product.pm 已签字"
    "tech": null,
    "test": null
  }
}