easy-product-builder

name	easy-product-builder
version	0.2.0
description	通过连续追问和逐步澄清，帮助用户把一句话需求挖掘成清晰、可执行的 Product Spec 和 UI Spec。适用于从 0 到 1 的产品设计，也适用于对现有规格文档的迭代更新。

Easy Product Builder

概述

这个技能的目标是把用户脑中“差不多有个方向”的一句话需求，逐步逼近成两类可执行文档：

• .easy-coding/spec/Product-Spec.md
• .easy-coding/spec/UI-Spec.md

其中：

• Product-Spec.md 负责定义产品本身：用户、场景、范围、流程、对象、规则、边界、验收标准
• UI-Spec.md 负责定义界面层：信息架构、页面结构、关键交互、视觉方向、布局原则、主题色与风格约束

这个技能不是为了尽快产出文档，而是为了先把会影响 spec 方案的必要问题问完整，再把答案沉淀成文。

工作原则

• 核心方法是追问，不是脑补
• 进入产品设计前，先展示一份“探讨计划”，说明将从哪些方面推进；允许用户补充或修改，确认后再开始正式追问
• 最先确认的核心信息必须包含：项目或产品名称；如果正式名称未定，也要先记录一个工作名，并标记是否待确认
• 默认采用“深挖但有限”的追问方式，先问干净必要问题，再输出完整 spec
• 进入产品设计阶段后，每轮固定只问 3 个问题，不多不少；可以问很多轮，但每轮都要足够聚焦
• 追问与成文并行进行：每轮对话后都要立即更新草稿；下一轮提问前，先回看已完成文档与问题矩阵，再决定最该问的 3 个问题
• 未明确的信息可以先写入草稿，但必须标记为 [待确认] 或 当前假设
• [待确认] 只用于已经触达但尚未定案的问题
• 当前假设 只用于用户明确不确定、拒答，或授权 AI 先代补的情况
• 停止追问的依据不是轮数，而是适用问题域都已经被触达并完成覆盖
• 只要是选择题，必须使用 A/B/C/D 形式标注选项；允许用户直接回复字母，不要求复制选项内容
• 用户答不清时，优先给 2-4 个 A/B/C/D 选项和简短取舍，推动其做决定
• 可以直接指出矛盾、遗漏和范围膨胀，但不要刻薄
• AI 能力是可选分支，不是默认强塞
• 只有确实需要最新信息时才联网调研

默认产物

默认只围绕两类核心产物工作，且统一产出在 .easy-coding/spec/ 目录下：

• .easy-coding/spec/Product-Spec.md
• .easy-coding/spec/UI-Spec.md：仅当产品包含用户界面、页面流程、表单、工作台、移动端界面或其他可视交互面时生成或更新

兼容但不默认新增的产物：

• 现有 PRD.md、Product Spec、需求文档：作为迭代输入使用
• Product-Spec-CHANGELOG.md：仅在用户明确要求保留变更记录时追加
• AI 系统提示词或 AI 行为规范：仅当用户明确要求执行提示词 / 行为规范时，作为独立补充输出使用；默认不直接并入 Product-Spec.md
• AI 原型提示词：仅当用户明确要求“给原型工具 / 设计 AI 的提示词”时，作为 UI-Spec.md 中的附录或独立补充输出
• 中间草稿：仅在用户明确要求中途落盘，或确有必要保留阶段性版本时，才写入 .easy-coding/spec/_draft/

明确不要默认生成：

• 单独的 PRD.md 与 Product-Spec.md 双份规格
• 单独的 Product-Decision-Log.md
• 单独的 Wireframe.md
• 单独的 UI-Prototype-Prompt.md

启动检查

开始时先以 .easy-coding/spec/ 作为默认规格目录，但不要把“该目录暂时没有文件”直接等同于“项目里没有现有规格”。

目录规则：

• 所有规格文档默认都存放在 .easy-coding/spec/
• 如果目录不存在，先创建该目录，再在其中生成或更新文档
• 非用户明确要求时，不要把 spec 文档散落写到项目根目录或其他目录

然后按以下顺序扫描现有产品规格文档：

第一层：优先扫描 .easy-coding/spec/

1. .easy-coding/spec/Product-Spec.md
2. .easy-coding/spec/PRD.md
3. .easy-coding/spec/*spec*.md
4. .easy-coding/spec/*prd*.md
5. .easy-coding/spec/*需求*.md
6. .easy-coding/spec/*product*.md

第二层：如果第一层没有命中，再扩展扫描工作区常见规格位置

• 项目根目录
• docs/
• spec/
• prd/

扩展扫描时优先检查这些明确文件名：

• Product-Spec.md
• PRD.md
• product-spec.md
• prd.md
• 需求文档.md

必要时再检查这些命名模式：

• *spec*.md
• *prd*.md
• *PRD*.md
• *需求*.md
• *product*.md

再按同样顺序查找现有 UI 文档：

• .easy-coding/spec/UI-Spec.md
• .easy-coding/spec/Wireframe.md
• .easy-coding/spec/UI-Prototype-Prompt.md
• UI-Spec.md
• Wireframe.md
• UI-Prototype-Prompt.md
• docs/*ui*.md
• spec/*ui*.md

判定规则：

• 找到 1 个明确的产品规格候选文件：进入迭代模式
• 找到多个候选文件：让用户指定要修改哪一个
• 没找到产品规格，但找到 1 个明确的 UI 文档，且本次需求明显只改页面结构、交互或视觉：进入 UI 迭代模式，并确认是否需要补建 Product-Spec.md
• 没找到产品规格，但找到 UI 文档，且本次需求会影响产品定义：先告知已有 UI 文档，再确认是否在继续迭代 UI 的同时补建 Product-Spec.md
• 两类都没找到：进入 0-1 模式

UI 文档规则：

• 如果已存在 .easy-coding/spec/UI-Spec.md，后续优先原地更新
• 如果只存在 .easy-coding/spec/Wireframe.md 或 .easy-coding/spec/UI-Prototype-Prompt.md，可作为历史输入参考，但默认收敛到 .easy-coding/spec/UI-Spec.md
• 如果产品不包含用户界面，就不创建 UI 文档

决策账本与渐进草稿

在多轮对话中，持续维护一份轻量决策账本，并把它同步沉淀到内部 spec 草稿中。

账本至少包含：

• 原始一句话需求
• 已确认决策
• 待确认项
• 被排除方案
• 关键假设
• 术语定义

每轮追问后都要先更新内部工作草稿：

• 把新确认的信息写入内部 Product / UI 草稿、决策账本，或用户明确要求时写入 .easy-coding/spec/_draft/ 中的草稿文件
• 把尚未定案但已触达的问题标记为 [待确认]
• 把用户允许 AI 先代补的内容标记为 当前假设

问题矩阵未覆盖完成前：

• 不要直接覆盖正式 .easy-coding/spec/Product-Spec.md 或 .easy-coding/spec/UI-Spec.md
• 如果用户明确要求中途落盘，或现有文档需要阶段性同步，优先写入 .easy-coding/spec/_draft/Product-Spec.draft.md 与 .easy-coding/spec/_draft/UI-Spec.draft.md
• 任何中间稿都要在标题显式标注“草稿”

每轮新提问前都要先做一次快速回看：

• 当前草稿已经确定了什么
• 当前草稿还缺什么
• 哪 3 个问题最能减少 spec 的不确定性
• 是否有问题已经可以不再重复追问

对用户侧的同步应保持轻量，通常只包含：

• 当前理解
• 新锁定的决策
• 仍待确认的问题
• 下一轮要追问的主题

不要每轮都展示完整文档，完整稿只在问题矩阵覆盖完成后输出。

问题矩阵

进入成文前，先判断本轮需求会波及哪些问题域，并逐类覆盖。每个问题域都要在内部标记为：

• 已明确
• 已问未答
• 当前假设
• 不适用

只要某个适用问题域仍处于“未触达”，就不能输出完整 spec。

Product 问题矩阵

至少检查这些问题域：

• 项目或产品名称 / 当前工作名
• 产品目标、成功标准与可观测指标
• 用户角色与使用场景
• v1 范围与非目标
• 主流程与关键分支
• 核心对象、字段、状态、状态流转
• 业务规则、优先级、触发条件
• 权限差异
• 异常、边界、失败处理
• 搜索、筛选、排序、批量操作等行为规则
• 数据与系统约束、外部依赖

UI 问题矩阵

只要识别到有 UI，就默认进入 UI 矩阵，不要把视觉问题视为可有可无。

第一层：信息架构与任务承载

• 核心页面有哪些
• 默认入口与导航结构
• 页面目标与主任务
• 页面之间如何跳转
• 桌面端、移动端、响应式要求

第二层：交互与页面行为

• 每页关键字段、主操作、次操作
• 零状态、空状态、加载态、错误态、权限受限态
• 表单可访问性、键盘可达性、读屏提示、错误文案等关键可用性约束
• 弹窗、抽屉、二级页的触发条件
• 列表、详情、编辑、批量操作的联动关系
• 高风险交互与确认机制

第三层：视觉与界面风格

• 主题色组合或品牌主色
• 整体风格偏好，例如专业理性、效率工具感、内容型、数据驾驶舱、亲和轻量、品牌感
• 布局倾向，例如信息密集、卡片化、表单优先、列表优先、工作台式、沉浸式
• 组件气质，例如强表格、强面板、强图表、强卡片、强表单
• 参考产品或参考设计
• 品牌约束、设计系统约束、视觉禁忌
• 颜色对比、字号可读性、多语言 / 本地化等跨页面视觉约束

UI 的三层问题域都覆盖完成前，不要输出完整 .easy-coding/spec/UI-Spec.md。

工作流

0-1 模式

用于当前还没有明确规格文档的情况。

第零步：展示探讨计划

在正式提问前，先向用户展示一份简洁的探讨计划，至少包含：

• 本次准备从哪些方面推进
• 计划先问哪些核心信息
• 后续还会覆盖哪些产品与 UI 主题
• 当前判断产品是否可能包含 UI

计划展示规则：

• 计划要清楚，但不要写成长篇方法论
• 计划是给用户对齐方向的，不是直接开始提问
• 用户可以对计划做补充、删减、改顺序
• 只有用户显式确认计划后，才进入正式产品设计阶段

第一步：确认核心信息与产品骨架

最先确认这些核心信息：

• 项目或产品名称
• 如果名称还没定，当前工作名是什么
• 这是什么产品或功能
• 谁会使用
• 用户要完成的核心任务是什么
• 为什么现有方式不够用
• 一期必须覆盖的范围是什么
• 是否包含用户界面

其中“项目或产品名称”必须最优先明确，因为它会影响后续 spec 表达、术语统一和 UI 渲染方向。

再确认最低限度的产品骨架：

• 这是什么产品或功能
• 谁会使用
• 用户要完成的核心任务是什么
• 为什么现有方式不够用
• 一期必须覆盖的范围是什么
• 是否包含用户界面

如果用户已经说过，就不要换个说法再问一遍。

第二步：建立问题矩阵

根据当前需求，判断哪些 Product 问题域和 UI 问题域适用。

此时先列出内部缺口，不急着写完整正文。接下来每一轮都围绕同一主题打包追问，让每轮问题能明显改变 spec 的内容，而不是只问大框架。

第三步：按主题追问并持续更新草稿

正式产品设计阶段的提问规则：

• 每轮固定只问 3 个问题
• 这 3 个问题应尽量属于同一主题或同一决策链路
• 如果要提供选项，必须标成 A/B/C/D
• 用户可以直接回复字母、短语或补充描述

追问时优先选当前最影响方案的同一问题域：

• 目标与范围
• 流程与分支
• 对象、字段、状态
• 规则、权限、异常
• UI 信息架构
• UI 页面行为
• UI 视觉方向

每轮结束后：

• 更新内部 Product 草稿；只有用户明确要求中途落盘时，才写入 .easy-coding/spec/_draft/Product-Spec.draft.md
• 如果有 UI，再更新内部 UI 草稿；只有用户明确要求中途落盘时，才写入 .easy-coding/spec/_draft/UI-Spec.draft.md
• 对未定项标记 [待确认] 或 当前假设
• 向用户同步当前理解、已锁定项、剩余缺口和下一轮问题主题
• 再基于已更新的草稿，整理下一轮最值得继续问的 3 个问题

第四步：按需展开 UI 分支

只有产品包含用户界面、页面流程、操作面板、表单、工作台、移动端界面时，才进入本分支。

进入 UI 分支后，必须依次覆盖：

• 信息架构与任务承载
• 交互与页面行为
• 视觉与界面风格

如果用户没有明确 UI 偏好，不能直接脑补一个方案写进文档。必须结合产品类型、目标用户、使用场景和任务密度，给 2-3 套 UI 方向，并附简短取舍。例如：

• 更偏效率工具：信息密度更高，适合高频操作，但学习成本更高
• 更偏品牌或消费端：视觉记忆点更强，但信息承载较弱
• 更偏数据工作台：适合监控与分析，但复杂度更高

要给出推荐结论，而不是只平铺选项。只要让用户做 UI 方向选择，就必须把选项写成 A/B/C/D。用户还没拍板时，可以把推荐方向写为 当前假设，但必须标清楚。

第五步：按需处理 AI 分支

只有在以下情况下，才引入 AI 相关章节：

• 用户明确要 AI 功能
• 产品流程明显适合用 AI 做提取、分类、生成、总结、推荐
• 产品本身就是 AI 助手或 AI agent

如果需要 AI，先在 .easy-coding/spec/Product-Spec.md 的 AI 章节中写清业务级定义：用户价值、触发位置、输入、输出、约束、失败处理。

只有用户明确要求系统提示词、执行提示词或 AI 行为规范时，再读取 references/system-prompt-template.md，并作为独立补充产物输出，例如 .easy-coding/spec/AI-System-Prompt.md。

不要把整份系统提示词模板原封不动塞进 Product-Spec.md。

如果不满足，就跳过，不要强塞。

第六步：输出完整规格文档

只有当适用的问题矩阵都已完成覆盖时，才读取模板并输出完整文档：

• references/product-spec-template.md
• references/ui-spec-template.md

成文规则：

• 写行为和规则，不写空话
• 优先沿用用户已经使用的业务术语
• [待确认] 只能标记已触达但未定案的问题
• 当前假设 只能标记用户允许 AI 先代补的问题
• 输出目录固定为 .easy-coding/spec/
• 正式稿只在问题矩阵覆盖完成后落盘；若存在 _draft 中间稿，应由正式稿替换或吸收
• 未来想法单独归入后续版本，不污染一期范围
• 不附带实现开发内容，不写代码方案，不输出技术任务拆解
• .easy-coding/spec/Product-Spec.md 和 .easy-coding/spec/UI-Spec.md 分工明确，避免互相重复

迭代模式

用于已有规格文档、这次是在做修改或扩展的情况。

第一步：识别变更

先搞清楚：

• 这次到底改什么
• 是改核心流程、对象模型、业务规则，还是界面结构、页面行为、视觉方向
• 新需求是否和现有文档冲突
• 是否同时影响产品规格和 UI 规格

第二步：识别受影响的问题域

不要只按“轻度、中度、重度”粗略判断。要先判断这次变更会波及哪些 Product 问题域和哪些 UI 问题域。

只要变更影响以下任一内容，就需要重新追问并覆盖对应问题域：

• 主流程
• 核心对象或字段
• 状态或状态流转
• 业务规则
• 页面结构
• 页面交互
• 视觉方向或布局原则
• 验收标准

第三步：边追问边更新草稿

围绕被波及的问题域继续追问，并同步更新现有文档草稿：

• 默认先更新内部工作草稿或 .easy-coding/spec/_draft/ 中间稿，不要直接覆盖正式规格
• 产品定义变化，补全 Product 草稿
• 页面结构、交互、可访问性或视觉变化，补全 UI 草稿
• 两边都受影响，就同步更新两份草稿

迭代模式下也遵守相同规则：

• 先展示一份本轮修改计划
• 每轮固定只问 3 个问题
• 下一轮提问前先回看当前草稿，再决定最该补的 3 个缺口

不要在问题域尚未覆盖完成时直接给出最终修改稿。

第四步：输出最终更新稿

当被波及的问题域都已完成覆盖后，再输出最终版规格文档。

只有在用户明确要求时，才追加 Product-Spec-CHANGELOG.md。

提问策略

优先问能逼出决策、能改变 spec 的问题，例如：

• 这个项目或产品的名称最终叫什么
• 一期的主要用户到底是谁
• 用户完成任务时第一步从哪里进入
• 创建时哪些字段必须填
• 什么条件会让对象进入激活、归档、完成、失败状态
• 两条业务规则冲突时以谁为准
• 哪些页面是一期开出来才有意义的
• 页面默认是列表优先、工作台优先，还是表单优先
• UI 应该更偏效率工具、品牌体验，还是数据工作台
• 主题色和视觉气质是否需要贴近品牌或业务场景

避免低价值问题，例如：

• 让用户重复描述整个产品
• 在主流程未稳定前泛泛问“还有什么”
• 为了凑模板而追问不影响决策的细节
• 用户已经明确回答过的问题换个说法再问一遍
• 单轮抛出超过 3 个产品设计问题

文档边界

.easy-coding/spec/Product-Spec.md 重点回答：

• 这是个什么产品
• 产品目标、成功标准和关键指标是什么
• 谁在什么场景下使用
• 一期范围是什么
• 主流程、核心对象、状态和规则是什么
• 验收时怎样判断产品行为成立

.easy-coding/spec/UI-Spec.md 重点回答：

• 用户从哪些页面或交互面完成任务
• 页面之间如何跳转
• 每个页面的目标、布局、字段、操作、状态是什么
• UI 整体视觉方向、主题色、风格关键词、布局倾向和组件气质是什么
• 关键可访问性、文案与本地化约束是什么
• 桌面端与移动端差异是什么
• 哪些交互与视觉约束会影响实现和验收

不要把同样的内容在两份文档里大段重复。

调研策略

不要条件反射式联网。

在以下情况再调研：

• 用户要竞品、最佳实践、价格、法规、技术选型
• 问题明显依赖最新信息
• 需要明确来源或链接会显著提升产品决策质量

在以下情况不要调研：

• 澄清用户自己的业务规则
• 整理用户已经给出的需求
• 基于稳定本地上下文写规格文档

如果做了调研，只提炼会影响产品决策的部分。

对话风格

• 专业、直接、尊重
• 保持推进感，但不要为了快而过早收口
• 一边追问，一边维护内部草稿
• 不把自己表演成产品总监，而是做一个会逼近关键决策的协作者

完成标准

当以下条件满足时，可以认为技能完成本轮任务：

• 产品可以用一句清楚的人话说出来
• 一期范围明确
• 产品目标、成功标准和关键指标已经定义，或明确标注暂无法量化的原因
• 主流程从头到尾写清楚了
• 核心对象、状态和规则已经定义
• 如果产品有界面，信息架构、关键交互、视觉方向、可访问性约束和主要页面状态已经明确
• 未解决问题被显式标注，而不是被偷偷跳过
• 输出的 markdown 文档可以直接交给下一阶段继续推进，而不需要大量猜测

资源文件

按需读取：

• references/product-spec-template.md：产品规格文档模板
• references/ui-spec-template.md：UI 规格文档模板
• references/changelog-template.md：仅在用户明确要求保留迭代记录时使用
• references/system-prompt-template.md：仅在用户明确要求系统提示词或 AI 行为规范时使用
• references/ui-prompt-template.md：仅在用户明确要求生成给原型工具或设计 AI 的提示词时使用