القائمة
通过连续追问和逐步澄清，帮助用户把一句话需求挖掘成清晰、可执行的 Product Spec 和 UI Spec。适用于从 0 到 1 的产品设计，也适用于对现有规格文档的迭代更新。
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
| name | easy-product-builder |
| version | 0.2.0 |
| description | 通过连续追问和逐步澄清，帮助用户把一句话需求挖掘成清晰、可执行的 Product Spec 和 UI Spec。适用于从 0 到 1 的产品设计，也适用于对现有规格文档的迭代更新。 |
这个技能的目标是把用户脑中“差不多有个方向”的一句话需求，逐步逼近成两类可执行文档：
.easy-coding/spec/Product-Spec.md.easy-coding/spec/UI-Spec.md其中：
Product-Spec.md 负责定义产品本身：用户、场景、范围、流程、对象、规则、边界、验收标准UI-Spec.md 负责定义界面层：信息架构、页面结构、关键交互、视觉方向、布局原则、主题色与风格约束这个技能不是为了尽快产出文档，而是为了先把会影响 spec 方案的必要问题问完整，再把答案沉淀成文。
[待确认] 或 当前假设[待确认] 只用于已经触达但尚未定案的问题当前假设 只用于用户明确不确定、拒答，或授权 AI 先代补的情况A/B/C/D 形式标注选项；允许用户直接回复字母，不要求复制选项内容A/B/C/D 选项和简短取舍，推动其做决定默认只围绕两类核心产物工作，且统一产出在 .easy-coding/spec/ 目录下：
.easy-coding/spec/Product-Spec.md.easy-coding/spec/UI-Spec.md：仅当产品包含用户界面、页面流程、表单、工作台、移动端界面或其他可视交互面时生成或更新兼容但不默认新增的产物：
PRD.md、Product Spec、需求文档：作为迭代输入使用Product-Spec-CHANGELOG.md：仅在用户明确要求保留变更记录时追加Product-Spec.mdUI-Spec.md 中的附录或独立补充输出.easy-coding/spec/_draft/明确不要默认生成：
PRD.md 与 Product-Spec.md 双份规格Product-Decision-Log.mdWireframe.mdUI-Prototype-Prompt.md开始时先以 .easy-coding/spec/ 作为默认规格目录，但不要把“该目录暂时没有文件”直接等同于“项目里没有现有规格”。
目录规则：
.easy-coding/spec/然后按以下顺序扫描现有产品规格文档：
第一层：优先扫描 .easy-coding/spec/
.easy-coding/spec/Product-Spec.md.easy-coding/spec/PRD.md.easy-coding/spec/*spec*.md.easy-coding/spec/*prd*.md.easy-coding/spec/*需求*.md.easy-coding/spec/*product*.md第二层：如果第一层没有命中，再扩展扫描工作区常见规格位置
docs/spec/prd/扩展扫描时优先检查这些明确文件名：
Product-Spec.mdPRD.mdproduct-spec.mdprd.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.mdUI-Spec.mdWireframe.mdUI-Prototype-Prompt.mddocs/*ui*.mdspec/*ui*.md判定规则：
Product-Spec.mdProduct-Spec.mdUI 文档规则：
.easy-coding/spec/UI-Spec.md，后续优先原地更新.easy-coding/spec/Wireframe.md 或 .easy-coding/spec/UI-Prototype-Prompt.md，可作为历史输入参考，但默认收敛到 .easy-coding/spec/UI-Spec.md在多轮对话中，持续维护一份轻量决策账本，并把它同步沉淀到内部 spec 草稿中。
账本至少包含：
每轮追问后都要先更新内部工作草稿：
.easy-coding/spec/_draft/ 中的草稿文件[待确认]当前假设问题矩阵未覆盖完成前：
.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每轮新提问前都要先做一次快速回看：
对用户侧的同步应保持轻量，通常只包含：
不要每轮都展示完整文档，完整稿只在问题矩阵覆盖完成后输出。
进入成文前，先判断本轮需求会波及哪些问题域，并逐类覆盖。每个问题域都要在内部标记为：
只要某个适用问题域仍处于“未触达”，就不能输出完整 spec。
至少检查这些问题域：
只要识别到有 UI，就默认进入 UI 矩阵，不要把视觉问题视为可有可无。
UI 的三层问题域都覆盖完成前，不要输出完整 .easy-coding/spec/UI-Spec.md。
用于当前还没有明确规格文档的情况。
在正式提问前，先向用户展示一份简洁的探讨计划，至少包含：
计划展示规则：
最先确认这些核心信息：
其中“项目或产品名称”必须最优先明确，因为它会影响后续 spec 表达、术语统一和 UI 渲染方向。
再确认最低限度的产品骨架：
如果用户已经说过，就不要换个说法再问一遍。
根据当前需求，判断哪些 Product 问题域和 UI 问题域适用。
此时先列出内部缺口，不急着写完整正文。接下来每一轮都围绕同一主题打包追问，让每轮问题能明显改变 spec 的内容，而不是只问大框架。
正式产品设计阶段的提问规则：
A/B/C/D追问时优先选当前最影响方案的同一问题域：
每轮结束后：
.easy-coding/spec/_draft/Product-Spec.draft.md.easy-coding/spec/_draft/UI-Spec.draft.md[待确认] 或 当前假设只有产品包含用户界面、页面流程、操作面板、表单、工作台、移动端界面时，才进入本分支。
进入 UI 分支后，必须依次覆盖：
如果用户没有明确 UI 偏好，不能直接脑补一个方案写进文档。必须结合产品类型、目标用户、使用场景和任务密度，给 2-3 套 UI 方向，并附简短取舍。例如：
要给出推荐结论，而不是只平铺选项。只要让用户做 UI 方向选择，就必须把选项写成 A/B/C/D。用户还没拍板时，可以把推荐方向写为 当前假设，但必须标清楚。
只有在以下情况下，才引入 AI 相关章节：
如果需要 AI，先在 .easy-coding/spec/Product-Spec.md 的 AI 章节中写清业务级定义：用户价值、触发位置、输入、输出、约束、失败处理。
只有用户明确要求系统提示词、执行提示词或 AI 行为规范时，再读取 references/system-prompt-template.md，并作为独立补充产物输出，例如 .easy-coding/spec/AI-System-Prompt.md。
不要把整份系统提示词模板原封不动塞进 Product-Spec.md。
如果不满足，就跳过，不要强塞。
只有当适用的问题矩阵都已完成覆盖时，才读取模板并输出完整文档：
成文规则：
[待确认] 只能标记已触达但未定案的问题当前假设 只能标记用户允许 AI 先代补的问题.easy-coding/spec/_draft 中间稿，应由正式稿替换或吸收.easy-coding/spec/Product-Spec.md 和 .easy-coding/spec/UI-Spec.md 分工明确，避免互相重复用于已有规格文档、这次是在做修改或扩展的情况。
先搞清楚：
不要只按“轻度、中度、重度”粗略判断。要先判断这次变更会波及哪些 Product 问题域和哪些 UI 问题域。
只要变更影响以下任一内容，就需要重新追问并覆盖对应问题域：
围绕被波及的问题域继续追问，并同步更新现有文档草稿：
.easy-coding/spec/_draft/ 中间稿，不要直接覆盖正式规格迭代模式下也遵守相同规则：
不要在问题域尚未覆盖完成时直接给出最终修改稿。
当被波及的问题域都已完成覆盖后，再输出最终版规格文档。
只有在用户明确要求时，才追加 Product-Spec-CHANGELOG.md。
优先问能逼出决策、能改变 spec 的问题，例如：
避免低价值问题，例如：
.easy-coding/spec/Product-Spec.md 重点回答：
.easy-coding/spec/UI-Spec.md 重点回答：
不要把同样的内容在两份文档里大段重复。
不要条件反射式联网。
在以下情况再调研：
在以下情况不要调研：
如果做了调研，只提炼会影响产品决策的部分。
当以下条件满足时，可以认为技能完成本轮任务：
按需读取：