product-spec-builder

name product-spec-builder description 需求收集与问题澄清。新建或迭代 PRD，通过交互式澄清生成结构化产品需求文档。 Product Spec Builder — 需求文档构建 职责 通过多轮交互式对话澄清用户需求，确保信息完整后输出结构化产品需求文档到 Product-Spec.md 。 核心原则 铁律：信息不完备，绝不输出 PRD。 必须逐维度确认，任何维度缺失都必须继续提问。 二次确认原则： 即使用户在需求描述或说明文档中提及过某个维度的信息（如「用 React」「参考 Notion」），也不能自动视为已明确。必须向用户二次确认：「你提到用 React，确认一下——是用 React + Vite 还是 Next.js？有没有其他偏好？」确保用户对每个决策有明确的认可。 基于需求提问： 所有问题必须从用户的实际需求出发，不要问模板化的、与当前需求无关的问题。例如用户要做日志分析工具，就别问「要不要做社交分享功能」。 触发场景 用户说"我想做一个产品"但需求模糊 需要写 PRD / 产品需求文档 用户要求修改/迭代已有的 Product-Spec.md 用户在开发过程中补充新需求 前置分析：需求成熟度判断 在进入正式需求澄清（Step 0）之前，先用 10 秒判断用户需求的成熟度： 触发条件（满足任一即建议先做结构化思考） 需求描述模糊，只有一句话（如"我想做个类似 Notion 的东西"） 用户自己也不确定要做什么（"你帮我看看"、"分析一下这个想法"） 功能范围明显过大（一口气列了 10+ 个功能） 用户提到"评估"、"分析"、"帮我想想" 用户是在模仿某个现有产品但没说明差异化原因 执行方式 如果触发了上述条件，主动向用户建议： 在写 PRD 之前，要不要先用结构化思考分析一下这个想法？ 它会从三个角度帮你理清思路： 把问题问对 — 你到底在解决谁的什么问题？有多痛？ 回归本质 — 哪些是模仿别人，哪些是真正必须的？ 做剪枝 — 哪些功能可以不做、推迟、或者用现成的？ 分析完再写 PRD，可以避免为一个没想清楚的想法写一堆文档。要不试试？还是直接开始需求澄清？ 用户同意后，调用 structured-thinking skill 进行分析。 structured-thinking 输出后的继承规则 分析完成后，带着结论进入 product-spec-builder 流程。 已覆盖的维度不再重复提问： structured-thinking 输出 映射到 product-spec-builder 处理方式 苏格拉底：问题重定义、关键矛盾 维度 1「产品定位」 跳过 ，直接引用作为产品定位 第一性原理：本质拆解、类比陷阱 维度 0「产品战略依据」（新增） 追加到 PRD 作为战略上下文 奥卡姆剃刀：MVP 边界、可删除项 维度 3「优先级」 MVP 范围已有， 只确认不重问 综合结论：建议方案、定位、第一步 维度 1 + 维度 3 直接引用 ，确认即可 未被覆盖的维度（维度 2 核心功能细节、维度 4 技术约束、维度 5 设计参考）仍需完整走过。 用户拒绝 structured-thinking 则直接进入 Step 0。 工作流程 Step 0: 模式判断（启动时先检查） 执行任何澄清工作前， 先检查项目根目录下是否存在 Product-Spec.md 。 情况 A — 不存在： 进入「新建模式」，从 Step 1 开始完整的需求澄清流程。 情况 B — 已存在： 进入「迭代模式」，流程如下： 告知用户文档已存在 ，并简要展示当前 PRD 的核心内容摘要（产品名称、MVP 功能列表） 询问修改意图 ： Product-Spec.md 已存在（<产品名称>，包含 个 MVP 功能）。你是想： 修改现有功能 — 调整某个功能的描述、验收标准等 新增功能 — 在现有基础上补充功能 删除功能 — 移除某个功能 调整其他维度 — 修改技术选型、设计风格、优先级等 重新来过 — 放弃现有文档，从头澄清 根据用户选择，针对性处理 ： 修改/新增/删除功能 → 按「后续补充需求处理」章节的规则，只追问相关维度，更新对应章节 调整其他维度 → 只针对涉及的维度重新提问确认 重新来过 → 归档旧文档（重命名为 Product-Spec.v<旧版本号>.md ），进入新建模式 变更记录 ：所有迭代操作追加到 Product-Spec-CHANGELOG.md Step 1: 需求澄清（可多轮，直到信息完备） 提问原则： 每轮 1-2 个问题，不要一次性问完 根据用户的回答动态调整后续问题——用户的回答暴露哪个维度的缺失就追问哪个 用户回答某个维度时如果暗示了其他维度的缺失，主动追问 所有问题从需求本身出发，不照搬模板 必须覆盖的 5 个维度（每个都是必填项）： 如果已通过 structured-thinking 前置分析，维度 1 和维度 3 可能已覆盖——参见「前置分析：需求成熟度判断」中的继承规则。 # 维度 必须明确的内容 完备判定标准 前置分析状态 1 产品定位 产品名称、解决什么问题、目标用户画像 能用一句话说清「谁、遇到什么问题、我们的解决方案」 ⚠️ structured-thinking 已覆盖则跳过 2 核心功能 3-5 个核心功能，每个功能的输入/输出/流程 每个功能有清晰的用户故事和使用场景 必须完整走过 3 优先级 MVP 范围 vs 后续迭代、功能依赖关系 MVP 功能列表已锁定，不含模糊项 ⚠️ 奥卡姆剃刀已给出边界，只确认不重问 4 技术约束 平台 (Web/移动/桌面)、技术栈偏好、部署方式 能确定项目初始化的技术选型 必须完整走过 5 设计参考 竞品/参考产品、设计风格、交互模式 能描述目标产品的视觉走向和核心交互方式 必须完整走过 维度 5「设计参考」细化： 设计参考不是简单问一句「有没有参考产品」就完了。必须覆盖两个子维度： 子维度 说明 示例问题 视觉风格 配色、布局、组件风格 「偏好 Material Design 还是极简风格？喜欢暗色还是亮色主题？」 交互模式 核心操作的交互流程、导航结构 「日志导入是拖拽上传还是选择文件？结果是实时刷新还是手动触发分析？」 用户未提供参考时——提供选项： 如果用户对某个维度说「不知道」「你定」或者没有提供参考： 基于需求分析，给出 2-3 个合理的选项 每个选项附带一句话适用场景说明 给出推荐并说明理由 请用户确认或选择 示例（技术栈）： 技术栈方面，根据你的需求，有几个方向： A. Electron + React — 适合需要系统级文件访问和离线使用的桌面工具 B. Next.js 全栈 — 适合需要服务端处理 + Web 界面的场景 C. Python + FastAPI + React — 适合后端计算密集型（日志解析/分析） 考虑到你提到需要「本地文件拖入分析」，推荐 A 或 B。你倾向哪个？ Step 2: 信息完备性自检（进入输出前的关闸） 每轮提问后，在 心里做一次自检 （不要输出给用户），判断标准： 维度 1「产品定位」：□ 已明确（含 structured-thinking 继承）/ □ 缺失 维度 2「核心功能」：□ 已明确 / □ 缺失 维度 3「优先级」 ：□ 已明确（含奥卡姆剃刀继承）/ □ 缺失 维度 4「技术约束」：□ 已明确 / □ 缺失 维度 5「设计参考」：□ 视觉风格 / □ 交互模式 / □ 两者都已明确 前置分析：□ 已完成 structured-thinking / □ 未触发（直接走澄清） 规则： 任何一个维度标记为「缺失」，必须继续提问该维度，不得跳过 即使用户说「随便」「你定」，也不能视为已明确——必须给出建议请用户确认（见「提供选项」规则） 即使用户在需求描述中顺带提过的信息，也要二次确认 （见「二次确认原则」） 全部 5 个维度标记为「已明确」后，进入 Step 3 进度 checkpoint ：5 个维度全部确认后，更新 .claude/progress.json ： current_skill: product-spec-builder , current_step: "需求澄清完成" , milestones 追加「5维度需求确认完成」 Step 3: 确认摘要（最后一道关） 在写入 Product-Spec.md 前，汇总收集到的所有信息，用简短格式呈现给用户确认： ## 需求确认 > 前置分析：□ 已完成 structured-thinking / □ 未触发 **产品定位**：<一句话总结>（来源：structured-thinking 问题重定义 / 维度1澄清） **核心功能**： 1. <功能 1> 2. <功能 2> ... **MVP 范围**：<哪些功能>（来源：奥卡姆剃刀 / 维度3确认） - 绝对不要：<排除项> - 第一步：<最小验证动作> **技术选型**：<技术栈> **设计参考**： - 视觉风格：<风格> - 交互模式：<交互> - 参考产品：<竞品> 以上是否准确？有没有需要补充或修改的？ 用户确认无误后，再进入 Step 4。 Step 4: 输出 PRD 将澄清后的需求写入 Product-Spec.md ，格式如下： # <产品名称> — 产品需求文档 ## 0. 产品战略依据 > 来源：structured-thinking 前置分析 > 如果未经过前置分析，此章节可省略 ### 0.1 问题本质 ### 0.2 核心洞察 | 思维框架 | 核心洞察 | |---------|---------| | 苏格拉底（问问题） | | | 第一性原理（拆问题） | | | 奥卡姆剃刀（做剪枝） | | ### 0.3 MVP 边界 - 必须有： - 绝对不要： - 第一步： ## 1. 产品概述 ### 1.1 背景与目标 ### 1.2 目标用户 ## 1.5 领域术语 > 定义产品核心概念的标准用词。后续所有文档和代码必须引用此表，禁止同义异词。 | 术语 | 定义 | 别名（禁止使用） | |------|------|-----------------| | | | | ## 2. 功能需求 ### 2.1 MVP 功能 - [ ] 功能 1：描述 + 验收标准 - [ ] 功能 2：描述 + 验收标准 ### 2.2 后续迭代 ## 3. 技术约束 ## 4. 设计规范 ### 4.1 视觉风格 ### 4.2 交互模式 ## 5. 验收标准 --- > 变更记录见 [ Product-Spec-CHANGELOG.md ]( ./Product-Spec-CHANGELOG.md ) Step 5: 更新 CHANGELOG 每次对 Product-Spec.md 的修改（包括新建、迭代、补充需求），都必须追加变更记录到 Product-Spec-CHANGELOG.md 。 进度 checkpoint ：PRD 写入后，更新 .claude/progress.json ： current_phase: "requirements" documents.Product-Spec.md ： exists: true , version , last_modified milestones 追加「PRD v<版本号> 已输出」 CHANGELOG 格式： # 需求变更记录 ## v<版本号> — <修改日期> ### 新增 - <新增内容 1> - <新增内容 2> ### 修改 - <修改前> → <修改后> ### 删除 - <删除内容> 版本号规则： 首次创建 PRD → v1.0 每次迭代修改 → 小版本号递增： v1.1 , v1.2 , ... 重大改动（如「重新来过」）→ 大版本号递增： v2.0 , v3.0 , ... 版本号从当前 CHANGELOG 中最新一条自增 分类规则： 操作 CHANGELOG 分类 示例写法 补充新功能、新需求 新增 新增「导出PDF报告」功能 调整现有功能的描述/验收标准/范围 修改 「拖入分析」支持范围改为：支持单/多文件拖入 调整技术选型、设计风格等非功能维度 修改 技术栈：Electron → Next.js 删除功能或需求 删除 删除「社交分享」功能 空分类不显示： 如果某个版本没有「修改」或「删除」项，直接跳过该分类标题，不写 （无） 。 示例： # 需求变更记录 ## v1.0 — 2026-04-29 ### 新增 - 初始版本：日志分析工具 PRD - 功能：本地文件拖入分析、日志解析引擎、可视化报告 - MVP 范围：支持 .log / .json / .csv 格式 ## v1.1 — 2026-04-30 ### 新增 - 补充「实时 tail 模式」功能 ### 修改 - 日志来源：仅本地文件 → 本地文件 + 远端下载 (S3/OSS) - 技术栈确认：Electron + React 后续补充需求处理 用户可能在开发过程中随时补充新需求（如「对了，还要加个导出功能」）。处理规则： 分析影响面 ：补充的需求是否影响已有功能？是否需要调整技术方案？ 按需追问，不照搬 5 维度 ：补充一个导出功能，不需要重新问「你的设计参考是什么」。只追问与补充需求直接相关的维度。例如： 补充「导出报告」→ 追问导出格式 (PDF/Excel/JSON?) 和触发方式 补充「用户登录」→ 追问登录方式 (邮箱/SSO/OAuth?) 和权限模型 记录变更 ：按 Step 5 格式追加到 Product-Spec-CHANGELOG.md （版本号递增，按新增/修改/删除分类），更新 Product-Spec.md 对应章节 对于改动范围大的补充 （如「再加一个移动端」），视为新的需求澄清周期，重新过相关维度 输出 Product-Spec.md — 完整的产品需求文档 Product-Spec-CHANGELOG.md — 需求变更记录（按版本号 + 新增/修改/删除分类） 注意事项 对「随便」「你定」的回复，必须主动给出专业建议并请用户确认，不得直接采纳 用户可能不理解某个维度为什么重要——用 1-2 句话解释该维度对后续设计/开发的影响 如果用户的需求本身很简单（如单页工具），可以适当精简，但 5 个维度至少要有一个明确的回答 不要问和需求无关的问题 。例如用户要做命令行工具，就别问「界面用什么颜色主题」 用户的需求描述中已提及的信息 ≠ 用户已确认。必须二次确认，但确认方式要自然——不要像审问，而是「你提到 X，确认一下细节」