PRD撰写

多数 PRD 读起来像需求堆砌：上来就写功能清单，没有背景，没有衡量标准，上线之后没人说得清算不算成功。这个技能的思路，是把 PRD 从「一份文档」拉回「一个决策产物」。

它解决什么问题

• 顺序错位：先谈方案再谈问题，团队对齐的是「怎么做」，而不是「为什么做」
• 成功标准缺失：没定义怎样算成功，上线后只能靠感觉判断
• 文档过重：几十页细节把关键结论淹没，开发者直接跳过
• 静态文本沟通低效：AI 和 UI 类需求尤其明显，文字描述的歧义远大于跑起来的原型
• 缺 Why Now：没有论证「为什么是现在做」，优先级评审时站不住

它如何工作

它不是填空模板，而是一套可以对话推进的流程：

1. 从 why 开始 —— 在讨论功能之前，先问清解决的问题是什么、为什么此刻重要
2. 前置定义成功 —— 把「成功」写成可以被判断的表述
3. 选对载体 —— 判断该用传统文档、原型，还是可执行的 evals
4. 保持可执行 —— 确保文档直接导向团队行动，而不是停留在描述

每条原则都挂在具体实践上：Maggie Crowley 坚持文档第一部分必须是背景与上下文；Bill Carr 的 PR/FAQ 用新闻稿式的写法逼出清晰度；Aparna Chennapragada 提出 prompt sets 就是 AI 时代的新 PRD；Hamel Husain 与 Shreya Shankar 把需求翻译成持续运行的评估。完整的 14 条洞察存放在 references/guest-insights.md，可按需展开阅读。

它还内置了提问清单和常见错误检查，例如「功能跑通后哪个指标会变？」「明确不在范围内的是什么？」「能不能先做个原型，而不是继续写文档？」

适用边界

• 它产出的是结构化思考和文档草稿，不替代产品判断，关键决策仍需要人来定
• 内容偏向北美科技公司的产品实践，落到自己团队需要裁剪
• AI 与 UI 类需求更强调原型和可执行评估，传统后端需求则以轻量文档为主