Product PRD & Prototype Studio（产品 PRD 与原型工作台）

Overview

为产品经理提供从「想法 · 需求 · 功能清单」到「标准 PRD + 可交互 HTML 原型」的端到端工作流。覆盖平台/中后台/B2B SaaS/运营后台（桌面端）与移动端（APP/小程序）及其配套后台。

核心目的（C46）：帮产品经理把模糊想法做成「研发可直接落地」的 PRD + 可点击原型；做好的标准 = deliver.py 总闸 PASS（关联零漂移 ∧ 零功能缺口）且交付报告逐条对得上原始需求。

对话拟人（C44，按读者分流）：面向用户/下游的人读文档去壳添魂——有观点直说、不堆敷衍开场与连接词；产出给机器消费的机读件（JSON/契约）不拟人，保持结构化。铁律：只改语气不改事实。

三模式：A 全新设计（澄清→PRD→原型→自测→交付）；B 历史迭代（在已有 PRD+原型上增量改→回归→交付）；D 需求评审/走查（评审挑问题、出报告，不重新产出）。

质量底线：交付前必须严格自测、完全按用户需求设计（不遗漏/不臆造/不自行加戏）；自测未过不得交付；最终必须附《交付报告》逐条对比原始需求并附证据（脚本输出/走查截图），不得只给结论。

When to Use

触发词见文件头 description。覆盖：产 PRD/产品需求文档；设计中后台/平台/SaaS/移动端原型；已有 PRD/原型迭代；已有方案评审挑问题。

模式选择

• 用户未提供已有资产、从想法/需求开始 → Mode A。
• 用户提供了已有 PRD 和/或原型、要求在其上改动 → Mode B。
• 用户已有 PRD+原型、只要求评审挑问题 → Mode D。

模式切换与边界情况（v1.9.85 新增 · 外部审计 F-7）

简单 if-else 之外的边界，按下列规则处理（避免「做一半发现要切模式」时乱跳）：

2. D 评审后要求直接改：D 本身不产出新 PRD/原型。转 Mode B Step 2，按 iteration-guide.md 的「D→B 问题映射」导入评审报告结构化问题清单为《待变更明细表》草稿执行修复（不重评 D 已审维度）。
3. A/B 做完要出高保真：A/B 产出 ui-tokens.json / element-spec.json 供 prototype-hifi-pipeline 消费；hifi 是下游，不反向改 A/B 源（契约见 ai-readable-convention.md §6 / §2.2）。
4. D 与 B 的闸口分工：D-Gate 只卡「评审报告合规」（结构项 FAIL + B 级/P0 结论自洽），不卡项目质量；项目质量由 A/B 的 deliver.py 总闸兜底，D 的 finding 回流 A/B 修复（见 gate-matrix.md）。

项目文件夹约定（所有模式通用前置）

本技能自身目录只放定义与模板，不放项目产物。产物落 projects/<产品名>/<版本号>/{prd,machine,prototype,delivery}/（研发交接七件套放 delivery/dev-handoff/）；该目录即 tools/association-validator.py 的 <项目根> 参数。人审主文档始终单文件完整 PRD，modules/ 仅多 Agent 并行时可选派生、禁止只交 INDEX+modules。详见 references/project-layout.md。

知识库联动挂载（KB-SYNC，所有模式通用前置 + 收尾，可选增强 · 自动挂载）

知识库路径：$HOME/Doubao/chats/2026-09-02/new-chat/knowledge-hub/personal-kb/（Obsidian vault，纯 Markdown，AI 直接读写；路径按 KB-SYNC 技能实际配置填写，默认不存在则自动跳过）。本技能经 KB-SYNC 自动挂载「知识库联动」（@skill:knowledge-hub-sync）——关联不复制，协同/沉淀完整规则见该技能唯一权威源；本技能只保留下方挂点。

⚠ 可选项：本知识库为个人增强层。如该路径不存在（技能迁移/分享给他人/新环境），自动跳过所有读取和写入，不影响 PRD/原型的核心交付流程。技能本身不依赖知识库运行。

两层沉淀协同：技能自带 references/lessons-learned.md 写全文（权威源，强制），知识库 02-技能经验/product-prd-prototype/lessons.md 写摘要+回链（索引层），不重复写。使用技巧.md 为知识库独有。读取时先读知识库摘要（先辅），需要细节再读技能自带全文（后主）。

前置读取（任务开始时，如知识库存在则读）：
1. 06-个人偏好/ 全部 4 文件（产品风格/沟通/交付格式/工作习惯）——对齐用户偏好
2. 00-索引层/术语表.md——统一业务术语
3. 02-技能经验/product-prd-prototype/使用技巧.md + lessons.md 摘要（先辅，快速认知）
4. 03-项目档案/ 类似项目——参考历史需求结构和决策（Mode A/C）
5. 03-项目档案/{{当前项目名}}/——读取项目历史和决策记录（Mode B/D）
6. 05-业务知识/ + 09-外部文档切片/——补充行业背景和外部文档（Mode A/C，09 只读——写入归整理任务）
7. 需要细节时读技能自带 references/lessons-learned.md 全文（后主）

收尾沉淀（交付后，如知识库存在则写）：
1. 踩坑全文 → 技能自带 references/lessons-learned.md（强制）
2. 踩坑摘要+回链 → 知识库 02-技能经验/product-prd-prototype/lessons.md
3. 成功范式同理（全文写技能自带，摘要写知识库）
4. 新项目（Mode A）：在 03-项目档案/{{项目名}}/ 创建完整档案（7 子目录），写入 PRD/原型/产物索引
5. 决策记录：项目期间的重要决策写入 03-项目档案/{{项目名}}/02-需求与决策/决策记录-*.md
6. 重要决策（跨项目可复用）：另汇总到 08-决策记录/决策记录-{YYYYMMDD}-{简述}.md
7. 外部文档：用户提供的外部文档如需切片 → 交整理任务写 09-外部文档切片/（本技能不直接写 09）；项目内使用的切片写 03-项目档案/{{项目名}}/01-外部文档切片/

大输入处理（上下文预算协议，所有模式通用）

大输入把文档当磁盘数据、靠工具与机读层当外部记忆，绝不预加载全文。详见 references/large-input.md。

⛔ 四道红线：① 真实精读底线——必须实际解析/扫描/精读，禁止"只 grep 几点+重组旧报告"冒充通读；② 读不全必提示用户——无法全量覆盖时显式提示并给选项，等确认后再产出；③ 覆盖声明强制——每个交付物必含"读了/抽样了/没读什么"（由 review-gate.py/deliver.py 卡）；④ 输入评估（Intake Triage）强制前置——任何 Mode 开工前先执行 large-input.md §3，向用户报告"读不全+策略+局限"后再动手。

通用交付纪律（A/B/D 单一可信源）

⛔ 本块是 Mode A/B/D 全部通用纪律的唯一权威定义；改任一条只改此处 + 其指向的详细出处。

• G1 提问与确认：grill-me（一次一问，按风险排序，附原因+推荐+取舍）；给选项/方案须带推荐——呈现多个选项/方案/修复项时须标推荐项+理由、说明其它项适用条件，禁止只罗列不表态（无明显更优项时明说、不硬凑）；三桶（已确认/合理假设/待确认，AI 假设须可见可推翻）；禁 TBD 躲藏（最高红线）——会改变范围/实现/验收的问题不得暂存"开放问题"，归宿＝已确认/已明确延期·范围外/待确认（仅用户亲口授权）；授权铁律——待确认/自主设计只能由用户亲口确认产生，AI 不得自行标，须带显式 ID + 文末登记表含授权证据，否则机器闸 FAIL。
• G1.1 提问停手纪律（v1.9.96 新增）：一次一问之外还须知道问到什么程度停、问不动了怎么办——① 停手信号可判定：满足任一即停止追问、进入下一步——能一句话复述需求四要素（目标用户 / 核心问题 / 范围边界 / 验收口径）且用户确认，或能说出用户未提到的盲点；"我有把握了"不作停手依据（主观不可验证，与 G1 授权铁律同源）；② 追问上限 3 轮：问满 3 轮仍无把握 → 停止追问，转「最小可看初稿」（一屏原型 / 最小 PRD 骨架）让用户对着实物改（用户自己也说不清的隐性需求，只能靠实物触发）；③ 分场景省流：Mode B 迭代或需求显而易见时，先读既有材料（PRD / 原型 / 机读件）再动手，不为走流程强行提问。
• G2 来源可靠性：PRD「需求投影型」章节内容须源自已确认需求，无法识别须停下询问，严禁凭感觉补。由 deliver.py check_source_traceability() 校验（Mode D 复用作第 14 项透镜，WARN）。双源冲突（权威源分层）：布局/交互/视觉以原型为权威，规则/安全/数据/状态以PRD 为权威，禁止一刀切（详见 review-checklist.md）。
• G3 必答维度（13 项）：7 核心（角色/功能/故事/流程/指标/NFR含权限/里程碑，FAIL）+ 2 硬约束（国际化与多区域 / 关键失败语义与并发仲裁，FAIL）+ 4 条件维度（移动端/海内外/多语言/设备与物联平台，WARN）。每项「有实质内容 或 显式声明本期不涉及+理由」二选一。反沉默规则：4 项条件维度 AI 必须主动询问、命中与否皆须在 requirements.json:dimensions{} 声明。详见 references/prd-template.md 顶部纪律块。
• G3.1 标签治理：每项须带 [source: 需求id/待确认:ID/自主设计:ID]，缺/悬空/裸待确认/缺证据 → FAIL。
• G4 疑问即沟通：写 PRD/原型中凡有疑问立即停下沟通，不得基于假设落笔、疑点不得暂存靠收尾兜底。
• G5 双视图/机读件：PRD 必配 requirements.json、原型必配 screens.json+data-req、Gate 必出 coverage.json，三者需求 ID 须对上；人读↔机读分叉 → Gate 拦截。Mode B 增量改须同步双写。Web UI 设计规范（G31）：ui-tokens.json 为强制产出——Mode A 含 Web 端 或 Mode B 新增 Web 页面时（不论是否同时含 APP），必须在 Phase 0 / Step 2 获取 UI 设计规范（文档/链接/知识库均可），填写 assets/brand-spec-template.md，跑 tools/emit_ui_tokens.py --spec brand.json 产出 prototype/ui-tokens.json，供高保真管线直接消费；纯 APP 端不触发此条。可选增强：① 原型可额外产出 element-spec.json（逐屏元素规格交付表：页面+弹框的交互/动效/字段/几何，接地检查点登记，render_element_spec.py 渲染「元素规格表.md」给研发与高保真；deliver.py check_element_spec() WARN 非阻断，schema 见 ai-readable-convention.md §2.2）。
• G6 IA 确认门：IA 页面树须经用户确认才生成 HTML 原型；双端先确认一端再镜像。
• G7 开发视角复审：交付前叠加 依赖/数据契约/权限安全/并发/降级/回滚/测试可执行性 复审（纯静态展示类可标不适用）；见 references/dev-perspective-review.md。
• G8 前置沟通 + 产品原则预审：信息不足/矛盾/缺关键决策 → 必须先沟通再动手（A 在 Phase 0.5、B 在 Step 1.8、D 对应"读不全必提示用户"红线）。
• G9 大输入红线：即上方「大输入处理」四道红线。

四模式总览

> ⛔ 执行前必读 references/mode-playbook.md 对应章节——本总览只够判断走哪条路，不够执行。
> 完整步骤（含各版本累积的强制纪律）全部在该文件，正文仅内联不可跳过的闸口。

Mode A — 全新项目设计（Greenfield）

触发：用户从零提需求、无既有 PRD/原型。通用纪律见 G1–G9。
- 闸口（内联，不可跳过）：Phase 0 Intake → Phase 0.5 产品原则预审 → Phase 0.7 残留假设晾晒轮 → Phase 2.5 交付前自测。
- 流程：Phase 0/0.5/0.7 → Phase 1 PRD 生成（含对抗性三问 + 可观测性标注 + 表模板填充）→ Phase 2 原型（接地检查点：先读 §4.2 产 field-binding.json 再写 HTML，字段约束须与 §4.2 一致）→ Phase 2.5 自测 → Phase 3 交付（PASS 后才问是否产 dev-handoff/）。
- 产出：PRD + requirements.json + 原型（screens.json + data-req，可选 ui-tokens.json）+ coverage.json + 交付报告。
- 完整步骤：references/mode-playbook.md §Mode A；配套 prd-template.md / prototype-guide.md / self-test-checklist.md。

Mode B — 历史项目迭代（Incremental）

触发：用户提供既有 PRD/原型，在其上改。通用纪律见 G1–G9。
- 闸口（内联，不可跳过）：Step 2 变更闸门——收「确认修改」回执才动、先出《待变更明细表》+ 残留假设晾晒轮；Step 3 机读件双写（人读↔机读分叉即 FAIL）。
- 流程：Step 1 盘点 → 1.4 schema-drift 扫描（外部/旧 schema 资产先基线化）→ 1.5 基线化（S0–S4 定级，缺机读件先跑 bootstrap-legacy.py）→ 1.8 原则预审 → Step 2 变更闸门 → Step 3 增量产出 → Step 4 回归 → Step 5 交付（强制跑 deliver.py）。
- 完整步骤：references/mode-playbook.md §Mode B；配套 iteration-guide.md。

Mode D — 需求评审 / 走查（Review-only）

触发：只评审挑问题，不产出新 PRD/原型。通用纪律见 G1/G2/G3/G9。
- 闸口（内联，不可跳过）：Step 5 D-Gate——python tools/review-gate.py <项目根>（共 28 项），任一 [FAIL] exit 1，有 P0 或 B 级差异禁判可交付。
- 流程：Step 1 接收对象 → Step 2 五维评审（先判原型层次再定走查深度 + 对抗性透镜 5 维）→ Step 3 跑自测脚本 → Step 4 评审报告（§5 结论强制三选一）→ Step 5 D-Gate。
- 完整步骤：references/mode-playbook.md §Mode D；配套 review-checklist.md（v2.9）。

结果上报须带证据（禁止凭记忆与猜测断言）

⛔ 向用户汇报任何结论 / 结果 / 状态时，两条缺一即违规：

1. 附可验证证据——命令输出、文件读取内容、检查器 / 测试报告、退出码、日志片段；无证据不结论，结论须能被证据回溯。
2. 严禁猜测 / 假设 / 推断——拿不准、未验证、未读取的部分必须明说「未验证 / 未读取」；"大概率是 X""应该就是 Y""我记得"这类无依据表述等同猜测，须先查证再下结论。

与既有条款的关系：「G1 授权铁律」禁"AI 自行标待确认"、「回忆纪律」禁"不确定记忆当事实复述"、本条禁"无证据下结论"——同一条「宁停勿猜」纪律在授权 / 记忆 / 输出三个环节的投影。

Resources（索引）

• references/mode-playbook.md — 四模式完整执行步骤（A/B/C/D 全链路，执行前必读）
• references/prd-template.md — PRD 模板（十三章+拆分+来源/维度锚点）
• references/prototype-guide.md — 原型方法论（IA/接地检查点/i18n/a11y/token）
• references/split-convention.md — Feature-Scoped 拆分约定
• references/large-input.md — 大输入协议
• references/iteration-guide.md — Mode B 迭代方法论
• references/self-test-checklist.md — 交付前自测清单
• references/delivery-report-template.md — 交付报告模板
• references/review-checklist.md — Mode D 评审清单（v2.9+D-Gate 28 项）
• references/product-review-principles.md — 产品原则预审库
• references/dev-perspective-review.md — 开发视角复审维度
• references/ai-readable-convention.md — AI 可读规范（json schema）
• references/artifact-association.md — 关联契约+校验器
• references/dev-handoff-convention.md — 研发交接规范（七件套+Gate）
• references/project-layout.md — 项目文件夹约定
• references/document-versioning.md — 文档版本化约定
• references/professional-review.md — 外部专业体检（可选）
• references/anti-patterns.md — 反模式全集（25 条）
• references/changelog.md — 完整版本变更历史
• references/lessons-learned.md — 自我迭代日志（防重复踩雷）
• references/success-patterns.md — 成功经验范式库（先套用再调整）
• references/example-charging-admin.md — 最小示例 few-shot
• references/skill-self-iteration.md — 改本 skill 的迭代纪律（Step 0 + C1–C6 守卫表）
• @skill:knowledge-hub-sync（外部引用 KB-SYNC） — 个人知识库（Obsidian）协同/沉淀规范唯一权威源（本地副本已迁出，见「知识库联动挂载」节）
• assets/admin-prototype-template/ · assets/mobile-prototype-template/ — 原型 boilerplate
• tools/association-validator.py — 关联校验器（FAIL exit 1）
• tools/bootstrap-legacy.py — 遗留资产基线化（Mode B Step 1.5）
• tools/coverage-gen.py — 覆盖率矩阵生成
• tools/deliver.py — 交付统一入口（全 PASS exit 0 / 任一 FAIL exit 1）
• tools/design-token-lint.py — 原型设计规范 lint
• tools/emit_ui_tokens.py — 品牌规范 → ui-tokens.json 共享 Token 契约产出（键空间对齐 hifi ui-tokens-template.md §6 键名权威全集，扁平键归一化为 / 分层；--selftest 内置正样本）
• tools/render_element_spec.py — element-spec.json → 「元素规格表.md」逐屏元素交付表渲染（页面总览/元素明细/弹框明细三表；交互·动效·字段·几何；--selftest 内置正负样本；v1.9.78）
• tools/package_delivery.py — 交付包打包（四文件夹 zip + MANIFEST；hifi 在场自动排除 lofi/，v1.9.64）
• tools/review-gate.py — Mode D 评审闸门（共 28 项 D-Gate，实跑 association-validator）

Anti-Patterns（反模式）

> 完整 25 条见 references/anti-patterns.md。四条最高红线：

• 禁 TBD 躲藏：会改变范围/实现/验收的问题必须回 Phase 0 确认，不得写进 PRD「开放问题」暂存；唯一允许的是带授权证据的待确认项。
• 禁关联漂移：PRD↔requirements↔screens↔HTML↔coverage↔dev-handoff 必须零漂移，改一处必同步其余（tools/association-validator.py）。
• 零缺口交付原则（最高优先）：deliver.py 总闸 = 关联零漂移 且 coverage.blockingMissingCount==0；存在未显式豁免的需求一律「不通过」。豁免仅 requirements.json 标 outOfScope:true+exclusionReason。
• 禁单视图产出（AI 可读红线）：PRD 必配 requirements.json、原型必配 screens.json+data-req、Gate 必出 coverage.json，ID 零 DANGLING；Mode B 增量改须机读件同步双写。

迭代交付纪律（改本 skill 时适用）

⛔ 本块管"改 skill 自身"的闭环，与 G1–G9 管"用 skill 产 PRD"不同。用本 skill 产 PRD/原型时无须读；改 product-prd-prototype 自身时必读 references/skill-self-iteration.md：Step 0 三步（先读经验——含成功范式同类匹配 → ABD 覆盖核对 → 双声明落 changelog）+ Step 0.5 外部方案对标（条件触发：动质量门 / 核心流程 / 纪律或引入外部体系时，先提炼主张 → 业界对标检索 → 三栏结论 + 三条硬边界） + C1–C6 机器守卫表 + 版本扫描器误读禁区（L25 已 promoted：写完版本变更段自查「段内 x.y.z 的 max==frontmatter」，描述清理/标记类机制先 grep 检查器关键词表绕开字面）。

回忆纪律（v1.9.81）：回答"上次怎么做的/这个坑踩过吗"类问题时，先检索 lessons-learned.md / success-patterns.md 沉淀并引用原文（ID/版本）；未检索到或不确定时明说"未在沉淀中找到"，禁止把不确定记忆当事实复述（与 C37 互补）。

版本变更

> 完整版本变更历史（共 89 条）见 references/changelog.md；本段仅保留最近 1 条，供 C1 一致性守卫读取。
- v1.10.7（2026-09-17）：登记 SkillHub 分发封包器（C34）+ 纠正打包工具误用 —— 用户报「打包文件超 200、无法上传 SkillHub」。根因：此前用 skill-crafting 的 skill_ops package 封包，它不排除 verification/ → 打出 634 文件（其中 verification/ 独占 572）。正解：改用 skill-forge 侧的分发封包器 package_skill.py（EXCLUDE_DIRS 含 verification / _work / deliverable），实测 61 文件 / 0.47MB（SkillHub 上限 200 文件 / 10MB）且强制先过 forge_check --strict（0 BLOCK 0 WARN）。已在关联索引登记 C34（外部工具·SkillHub 分发封包）以防再犯。PATCH。