Menu
需求收集与问题澄清。新建或迭代 PRD，通过交互式澄清生成结构化产品需求文档。
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
构建验证、版本管理与发布上线。多轮确认发布目标与推送路径后执行门禁与发布，写入状态与 release notes。用户提到发布、上线、deploy、打 tag、发版、merge 到 main、推远程、构建生产包、创建 PR 时，即使未说 release 也必须使用本 skill。
技术架构设计。调研技术方案、评估开源项目、输出架构决策记录，写入 Tech-Arch.md。在 dev-planner 之前调用。
设计执行。基于 Design-Brief.md 产出原型、设计稿或设计系统。支持 Figma、Pencil、HTML/CSS 原型等多种输出方式。
系统化调试修复 Bug。五阶段：收集证据→重现用例→分析(含根因归因)→假设→修复→进化记录。支持触发 code-review 和 feedback-writer。
代码审查和质量检查。调度 code-reviewer sub-agent 审查代码，检查是否符合计划和编码标准。
根据开发计划编写代码。按任务调度 implementer sub-agent，在 <project-name>/ 目录下创建项目。
| name | product-spec-builder |
| description | 需求收集与问题澄清。新建或迭代 PRD，通过交互式澄清生成结构化产品需求文档。 |
通过多轮交互式对话澄清用户需求，确保信息完整后输出结构化产品需求文档到 Product-Spec.md。
铁律：信息不完备，绝不输出 PRD。 必须逐维度确认，任何维度缺失都必须继续提问。
二次确认原则： 即使用户在需求描述或说明文档中提及过某个维度的信息（如「用 React」「参考 Notion」），也不能自动视为已明确。必须向用户二次确认：「你提到用 React，确认一下——是用 React + Vite 还是 Next.js？有没有其他偏好？」确保用户对每个决策有明确的认可。
基于需求提问： 所有问题必须从用户的实际需求出发，不要问模板化的、与当前需求无关的问题。例如用户要做日志分析工具，就别问「要不要做社交分享功能」。
Product-Spec.md在进入正式需求澄清（Step 0）之前，先用 10 秒判断用户需求的成熟度：
如果触发了上述条件，主动向用户建议：
在写 PRD 之前，要不要先用结构化思考分析一下这个想法？ 它会从三个角度帮你理清思路：
- 把问题问对 — 你到底在解决谁的什么问题？有多痛？
- 回归本质 — 哪些是模仿别人，哪些是真正必须的？
- 做剪枝 — 哪些功能可以不做、推迟、或者用现成的？
分析完再写 PRD，可以避免为一个没想清楚的想法写一堆文档。要不试试？还是直接开始需求澄清？
用户同意后，调用 structured-thinking skill 进行分析。
分析完成后，带着结论进入 product-spec-builder 流程。已覆盖的维度不再重复提问：
| structured-thinking 输出 | 映射到 product-spec-builder | 处理方式 |
|---|---|---|
| 苏格拉底：问题重定义、关键矛盾 | 维度 1「产品定位」 | 跳过，直接引用作为产品定位 |
| 第一性原理：本质拆解、类比陷阱 | 维度 0「产品战略依据」（新增） | 追加到 PRD 作为战略上下文 |
| 奥卡姆剃刀：MVP 边界、可删除项 | 维度 3「优先级」 | MVP 范围已有，只确认不重问 |
| 综合结论：建议方案、定位、第一步 | 维度 1 + 维度 3 | 直接引用，确认即可 |
未被覆盖的维度（维度 2 核心功能细节、维度 4 技术约束、维度 5 设计参考）仍需完整走过。
用户拒绝 structured-thinking 则直接进入 Step 0。
执行任何澄清工作前，先检查项目根目录下是否存在 Product-Spec.md。
情况 A — 不存在： 进入「新建模式」，从 Step 1 开始完整的需求澄清流程。
情况 B — 已存在： 进入「迭代模式」，流程如下：
Product-Spec.md 已存在（<产品名称>，包含 个 MVP 功能）。你是想：
- 修改现有功能 — 调整某个功能的描述、验收标准等
- 新增功能 — 在现有基础上补充功能
- 删除功能 — 移除某个功能
- 调整其他维度 — 修改技术选型、设计风格、优先级等
- 重新来过 — 放弃现有文档，从头澄清
Product-Spec.v<旧版本号>.md），进入新建模式Product-Spec-CHANGELOG.md提问原则：
必须覆盖的 5 个维度（每个都是必填项）：
如果已通过
structured-thinking前置分析，维度 1 和维度 3 可能已覆盖——参见「前置分析：需求成熟度判断」中的继承规则。
| # | 维度 | 必须明确的内容 | 完备判定标准 | 前置分析状态 |
|---|---|---|---|---|
| 1 | 产品定位 | 产品名称、解决什么问题、目标用户画像 | 能用一句话说清「谁、遇到什么问题、我们的解决方案」 | ⚠️ structured-thinking 已覆盖则跳过 |
| 2 | 核心功能 | 3-5 个核心功能，每个功能的输入/输出/流程 | 每个功能有清晰的用户故事和使用场景 | 必须完整走过 |
| 3 | 优先级 | MVP 范围 vs 后续迭代、功能依赖关系 | MVP 功能列表已锁定，不含模糊项 | ⚠️ 奥卡姆剃刀已给出边界，只确认不重问 |
| 4 | 技术约束 | 平台 (Web/移动/桌面)、技术栈偏好、部署方式 | 能确定项目初始化的技术选型 | 必须完整走过 |
| 5 | 设计参考 | 竞品/参考产品、设计风格、交互模式 | 能描述目标产品的视觉走向和核心交互方式 | 必须完整走过 |
维度 5「设计参考」细化：
设计参考不是简单问一句「有没有参考产品」就完了。必须覆盖两个子维度：
| 子维度 | 说明 | 示例问题 |
|---|---|---|
| 视觉风格 | 配色、布局、组件风格 | 「偏好 Material Design 还是极简风格？喜欢暗色还是亮色主题？」 |
| 交互模式 | 核心操作的交互流程、导航结构 | 「日志导入是拖拽上传还是选择文件？结果是实时刷新还是手动触发分析？」 |
用户未提供参考时——提供选项：
如果用户对某个维度说「不知道」「你定」或者没有提供参考：
示例（技术栈）：
技术栈方面，根据你的需求，有几个方向：
- A. Electron + React — 适合需要系统级文件访问和离线使用的桌面工具
- B. Next.js 全栈 — 适合需要服务端处理 + Web 界面的场景
- C. Python + FastAPI + React — 适合后端计算密集型（日志解析/分析）
考虑到你提到需要「本地文件拖入分析」，推荐 A 或 B。你倾向哪个？
每轮提问后，在心里做一次自检（不要输出给用户），判断标准：
维度 1「产品定位」：□ 已明确（含 structured-thinking 继承）/ □ 缺失
维度 2「核心功能」：□ 已明确 / □ 缺失
维度 3「优先级」 ：□ 已明确（含奥卡姆剃刀继承）/ □ 缺失
维度 4「技术约束」：□ 已明确 / □ 缺失
维度 5「设计参考」：□ 视觉风格 / □ 交互模式 / □ 两者都已明确
前置分析：□ 已完成 structured-thinking / □ 未触发（直接走澄清）
规则：
.claude/progress.json：current_skill: product-spec-builder, current_step: "需求澄清完成", milestones 追加「5维度需求确认完成」在写入 Product-Spec.md 前，汇总收集到的所有信息，用简短格式呈现给用户确认：
## 需求确认
> 前置分析：□ 已完成 structured-thinking / □ 未触发
**产品定位**：<一句话总结>（来源：structured-thinking 问题重定义 / 维度1澄清）
**核心功能**：
1. <功能 1>
2. <功能 2>
...
**MVP 范围**：<哪些功能>（来源：奥卡姆剃刀 / 维度3确认）
- 绝对不要：<排除项>
- 第一步：<最小验证动作>
**技术选型**：<技术栈>
**设计参考**：
- 视觉风格：<风格>
- 交互模式：<交互>
- 参考产品：<竞品>
以上是否准确？有没有需要补充或修改的？
用户确认无误后，再进入 Step 4。
将澄清后的需求写入 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)
每次对 Product-Spec.md 的修改（包括新建、迭代、补充需求），都必须追加变更记录到 Product-Spec-CHANGELOG.md。
进度 checkpoint：PRD 写入后，更新 .claude/progress.json：
current_phase: "requirements"documents.Product-Spec.md：exists: true, version, last_modifiedmilestones 追加「PRD v<版本号> 已输出」CHANGELOG 格式：
# 需求变更记录
## v<版本号> — <修改日期>
### 新增
- <新增内容 1>
- <新增内容 2>
### 修改
- <修改前> → <修改后>
### 删除
- <删除内容>
版本号规则：
v1.0v1.1, v1.2, ...v2.0, v3.0, ...分类规则：
| 操作 | 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
用户可能在开发过程中随时补充新需求（如「对了，还要加个导出功能」）。处理规则：
Product-Spec-CHANGELOG.md（版本号递增，按新增/修改/删除分类），更新 Product-Spec.md 对应章节Product-Spec.md — 完整的产品需求文档Product-Spec-CHANGELOG.md — 需求变更记录（按版本号 + 新增/修改/删除分类）