qiaomu-ai-prd

Qiaomu AI PRD

把一句模糊的产品想法，写成产品经理、人类开发者和 AI 编程助手都能直接执行的 PRD。

Copyright (c) 向阳乔木 X: https://x.com/vista8 GitHub: https://github.com/joeseesun/

运行模式

以轻量级生产级产品规范技能的方式运行。

默认假设：

• 用户通常需要的是一份完整的 PRD，而不是一份问卷。
• 如果输入只有一句话，就推断最稳妥的产品方向并继续。
• 只有当答案会实质性改变产品类别、平台、安全性、法律风险、预算、数据所有权或实现范围时才提问。
• 如果需要做出选择，就采用最佳默认方案，并在相关章节说明原因。
• 除非用户明确要求，否则不要开始实现；此技能负责生成 PRD。
• 除非用户要求使用英语，否则优先使用中文撰写。
• 按顺序输出所有 11 个必需章节。即使在精简模式下也不要跳过章节。
• 在章节前添加 AI 速读卡，让实现 Agent 能在 10 行以内了解产品。
• 除非会影响产品行为、架构风险、数据契约、验证或 AI 交接，否则不要写实现细节。
• 不要编造当前的竞品、API、平台或软件包信息。如果当前事实很重要且无法验证，就标记为未解决或使用 未知。
• 将模糊的产品用语视为方向，而非证据。将其转化为具体的 UI 状态、可衡量的目标、输出和验收标准。
• 将每项重要指令归为 硬约束、推荐默认 或 发挥空间，以便实现 Agent 知道哪些必须遵守，哪些可以自由改进。

工作流程

1. 解析用户输入，以及 references/modes-and-defaults.md 中的可选模式标签。
2. 判断可能的产品类别、目标用户、主要平台和 MVP 范围。
3. 确定产品的 硬约束、推荐默认 和 发挥空间。
4. 识别必须验证的事实、可以安全采用的假设，以及必须如实呈现的未知项。
5. 按照 references/prd-methodology.md 中的确切章节规范生成 PRD。
6. 对于每个模块，提供真实的 ASCII UI／状态图、正常流程、至少两种失败路径、状态、依赖项，以及 1 至 3 个真实的产品决策，或填写 无。
7. 添加 超预期机会：列出 2 至 4 个能让实现令人印象深刻、又不会使 P0 膨胀的产品亮点。
8. 对差异化和技术选型，解释其结构性原因和权衡，而不是说竞品“没想到”。
9. 提供数值化的性能目标、测量方法和降级阈值。
10. 将第 11 章写成直接交给实现 AI 助手的说明，使用第二人称 你，并附上它可以运行或手动验证的验收脚本。
11. 最终输出前，按照 references/output-quality.md 执行自检。
12. 如果 PRD 保存到文件中，运行 python3 scripts/lint_prd.py <file> 并修复报告的所有问题。

输出规范

用户提出产品想法时，直接输出 PRD。按以下顺序组织：

1. # [产品名] PRD
2. ## AI 速读卡
3. ## 第一章：产品概述
4. ## 第二章：整体布局与导航
5. ## 第三章：核心模块详细设计
6. ## 第四章：超越竞品的差异化功能
7. ## 第五章：数据模型
8. ## 第六章：技术架构
9. ## 第七章：交互细节
10. ## 第八章：导出与输出系统
11. ## 第九章：开发优先级
12. ## 第十章：性能指标
13. ## 第十一章：开发者交接说明

不要添加冗长的前言。如果需要说明假设，请将其放在相关章节中，通常是 1.3 可行性边界、模块中的 待决问题，或 第十一章 d) 已知的未知项。

可选模式

识别用户请求中任意位置出现的以下标签：

• [深度模式]：为每个主要模块补充边界情况分析。
• [精简模式]：保留每个章节，但将详细设计聚焦于 P0；将较低优先级标记为 待扩展。
• [前端视角]：在与产品相关的部分补充组件拆分和状态管理指导。
• [后端视角]：在与产品相关的部分补充 API 设计和数据库架构。
• [移动优先]：除非产品显然仅面向桌面端，否则所有布局图都采用移动优先设计。
• [竞品深挖]：深入分析竞品弱点和产品盲点。
• [商业化]：在适当之处补充定价、付费功能和商业化影响。
• [开源友好]：在不损害产品的前提下，优先选择宽松许可的开源库，尤其是 MIT 许可的库。

关于如何组合这些模式，请参阅 references/modes-and-defaults.md。

质量标准

符合此技能要求的 PRD 应：

• 做出产品决策，而不是把所有模糊之处都留给用户。
• 为实现 Agent 提供简明的 AI 速读卡。
• 区分 硬约束、推荐默认 和 发挥空间。
• 包含切实可行的 ASCII 图示，并标注实际内容和代表性示例。
• 指出有意义的竞品差异，而不是用显而易见的功能对等项填满对比表。
• 定义模块状态、数据流、失败路径和待决事项。
• 包含少量 超预期机会，鼓励在基线功能之外进行恰到好处的实现。
• 使用带注释的 JSON 字段和顶层 version 来定义数据结构。
• 诚实说明技术选型及包体积的不确定性。
• 说明技术选型何时可替换，以及哪些内容必须保持不变。
• 根据对用户行为的影响而非实现难度确定优先级。
• 将性能预期转化为明确数值和测量方法。
• 告知实现 AI 应先构建什么、哪些内容不可自行重新解释、哪些内容可自由改进、哪些信息仍未知，以及如何验证首个版本。

拒绝或修订以下 PRD：

• 留有 [产品名]、按钮 A、TODO 或 待补充 等占位符。
• 用 快、流畅、轻量 或 可扩展 等模糊性能描述代替具体数值。
• 声称具备不可能实现的浏览器、iOS、Android、Web、AI 模型或导出能力。
• 臆造竞品事实、包体积或平台限制。
• 第 11 章没有如实列出已知的未知事项。
• 缺少用于验证实现的 验收剧本。
• 把 P0 列成愿望清单，而不是最小可用产品。

参考文件

• references/prd-methodology.md：PRD 必需的 11 章结构和详细编写规则。
• references/modes-and-defaults.md：对低投入用户的默认设定、可选模式、提问规则和不确定性处理。
• references/output-quality.md：输出自检和常见失败模式。
• scripts/lint_prd.py：用于检查必需章节、未解决的占位符、模糊性能术语和结构性遗漏的轻量检查工具。