项目经理

这个技能是什么

写 PRD 这种文档最痛苦的不是思考，而是面对空白文档时那种“不知道怎么组织结构”的焦虑。这个技巧能把 AI 变成一个经验丰富的项目经理，帮你把脑子里零散的功能点，快速扩充成一份逻辑严密、覆盖面广的正式需求文档。它不再是简单地列几个功能，而是会强制要求包含问题定义、用户故事、技术要求和 KPI 等核心维度，让你在评审会上显得思考非常周全。

适用场景

• 刚接到一个新功能需求，需要快速出个初稿给技术团队对齐。

• 脑子里有个产品想法，想通过结构化文档理清逻辑，看看可行性。

• 面对甲方或老板模糊的需求描述，需要将其转化为标准开发文档。

• 准备项目评审，需要一份包含风险评估和衡量指标的专业 PRD。

如何使用

你只需要把下面这段话发给 AI，然后告诉它你要做的具体功能或项目名称就行。

我需要你帮我起草一份完整的 PRD（产品需求文档）。在我给你提供具体的主题、功能或开发计划之前，请先确认你已准备好。
一旦我提供了主题，请严格按照以下结构输出文档：
1. Subject（主题）
2. Introduction（引言）
3. Problem Statement（问题陈述：为什么要做这个功能，解决了什么痛点）
4. Goals and Objectives（目标与目的）
5. User Stories（用户故事：以“作为[角色]，我想[动作]，以便于[价值]”的形式）
6. Technical Requirements（技术要求）
7. Benefits（预期收益）
8. KPIs（关键衡量指标：如何定义这个功能上线后是成功的）
9. Development Risks（开发风险点）
10. Conclusion（结论/总结）
现在请确认你已准备好，在我发送具体主题前，不要开始写文档。

使用技巧

• 喂入背景信息：在给 AI 主题时，尽量多给一点上下文（比如：目标用户是谁、目前的痛点是什么），这样生成的“用户故事”和“问题陈述”会精准得多。

• 分步迭代：不要指望一次性出完美文档。建议先让它出初稿，然后针对其中某个章节（比如“技术要求”）让它深入展开，或者根据你的实际情况要求它修改某个风险点。

• 反向挑战：在文档生成后，你可以问它：“如果你是开发人员，看完这份 PRD 会在哪个环节觉得定义模糊？”让 AI 自我审计，帮你在评审前堵住漏洞。

注意事项

• 警惕“幻觉”技术要求：AI 写的技术要求往往比较通用，它不知道你们公司的具体架构，所以技术细节部分必须由你或架构师审核，不能直接拿来当开发标准。

• 避免过度扩充：AI 有时为了填满结构会写一些废话，如果发现某个章节（如引言）太啰嗦，直接要求它“用精炼的 bullet points 重写”即可。