借助Claude优化PRD撰写：AI协作提升效率与质量

本篇内容将探讨如何将 Claude 作为你的“思考搭档”，以更高效、高质量地完成产品需求文档（PRD）的撰写。AI的核心价值或许并非替代你的思考，而是帮助你更好地组织和深化思考过程。如果你还未安装相关环境，可参考之前的教程：产品经理的 Claude Code - 0.1 安装 和 产品经理的 Claude Code - 0.2 教程下载。准备就绪后，运行 /start-2-1 即可开始交互式学习。

传统的工作流程与引入AI协作后的流程有何不同？我们可以通过一个对比来直观感受：

可以看到，AI协作流程将后置的反馈环节大幅前移，让你在正式提交前就能对方案进行多轮打磨。

@资料：为AI提供完整上下文

避免AI“凭空想象”的关键，是在对话一开始就为它提供充分的背景信息。你可以通过 @-mention 功能，引入以下类型的资料：

• 公司背景：产品战略、客户洞察、核心业务指标。
• 用户研究：用户访谈记录、调研数据分析、核心痛点总结。
• 模板：团队内部惯用的PRD结构模板。
• 方法论：如将要使用的“苏格拉底式提问”框架。
• 相关文档：历史PRD版本、竞品分析报告、产品路线图等。

示例指令：

帮我为「智能会议纪要」功能撰写PRD，请结合以下资料和我一起思考：
@company-context.md —— 产品与客户背景
@user-research/pain-points.md —— 20次用户访谈总结
@prd-template.md —— 我们的标准PRD模板
@methods/socratic-questioning.md —— 用于澄清思路的方法框架

用结构化提问梳理逻辑

在动笔之前，先用一系列结构化的问题来审视你的想法，消除模糊地带。以下是一个基于苏格拉底式提问的框架，你可以从中挑选3-5个最核心的问题进行探讨：

• 问题本身是否清晰
  • 这个功能具体解决了哪一类用户的哪一个痛点？
  • 如果不解决这个问题，用户会付出什么代价？
• 解决方案是否合理
  • 为什么当前设想的方案是最佳的？我们考虑过哪些替代方案？
  • 这个功能的“最小可行版本”(MVP)应该包含什么？
• 如何定义成功
  • 我们用什么指标来衡量这个功能是否成功？提升幅度期望是多少？
  • 在什么情况下，我们认为这个功能是失败的？
• 存在哪些约束
  • 主要的技术风险或实施难点是什么？
  • 为了确保项目可控，我们明确 不 做哪些事情？
  • 如果研发时间减半，我们必须砍掉什么？
• 是否符合战略
  • 为什么现在是做这个功能的最佳时机？
  • 它如何与我们产品的整体战略对齐？

Agents：并行生成多种战略方案

不要满足于第一个冒出来的想法。你可以要求Claude针对同一个功能需求，构思2-3种不同的战略路径，以便对比和抉择。

示例：为一个“AI语音+待办事项”功能生成方案

• 方案A：聊天优先
  • 核心思路：以自然语言对话为主要交互方式，适合移动场景下的快速记录。
  • 成功指标：通过语音创建任务占总创建任务的比例。
• 方案B：列表优先
  • 核心思路：以传统、可视化的待办列表为核心，语音作为补充输入手段。
  • 成功指标：语音功能的日活跃用户数(DAU)。
• 方案C：平衡型
  • 核心思路：根据用户场景（如通勤、桌面办公）动态切换聊天与列表视图。
  • 成功指标：用户满意度(NPS/CSAT)与功能整体采用率。

你可以为每一种方案分别创建一个Agent，让它们并行地生成PRD初稿，而不是按顺序一个一个来，这能极大地提升思考的广度。

Sub-Agents：获取多视角的模拟反馈

在将PRD草稿发给真实的工程师、管理层之前，不妨先让AI扮演这些角色，进行一次“内部预审”。这能帮你提前发现盲点。

• 工程师视角：评审技术可行性、实现复杂度、潜在风险、系统依赖关系、研发时间预估。
• 管理层视角：评估商业价值、战略匹配度、资源投入的合理性、对竞争格局的影响、投资回报率(ROI)。
• 用户研究视角：判断方案是否贴合真实用户需求、存在哪些可用性问题、是否考虑了边界场景、用户采用可能遇到的阻力、设定的指标是否合理。

真实工作流示例

让我们将上述步骤串联起来，看一个完整的模拟流程：

1. 第一步：设定上下文

   我正在为“智能会议纪要”功能撰写PRD，请结合以下资料和我一起思考：
   @company-context.md
   @user-research/calendar-pain-points.md
   @prd-template.md
   @methods/socratic-questioning.md

2. 第二步：澄清关键问题

   请基于苏格拉底提问框架，围绕“问题定义”、“解决方案”、“成功指标”、“技术约束”和“战略时机”五个方面，向我提出5个当前最需要厘清的关键问题。

3. 第三步：生成并对比战略方案

   • 生成三种可能的产品方案：日历内嵌式、邮件优先式、独立应用式。
   • 要求对每种方案简要阐述其核心问题定义、解决思路和首要成功指标。

4. 第四步：获取多角色模拟评审

   现在，请依次模拟工程师、产品总监和用户研究员三个角色，对上面选定的方案草案进行评审，并汇总他们的主要观点与风险提示。

常见问题与实战建议

为了帮助你更好地应用这套方法，下表总结了一些推荐做法与需要避免的陷阱：

Q1：生成的PRD感觉比较空泛，怎么办？
A：这通常是因为提供给AI的上下文信息不足，或者你将决策权完全交给了AI。解决方法是提供更具体的公司背景、用户画像和数据，并在提示词中强调“帮我思考”和“和我一起分析”，而不是“帮我写”。

Q2：子代理的反馈听起来很笼统，没有深度。
A：可能的原因是角色设定不够具体，或者PRD草案本身信息量不足，让AI无法深入。可以尝试在指令中强化角色，例如：“假设你是一名有10年后端经验的架构师，请重点关注这个方案的技术架构风险、性能瓶颈和可能的替代技术选型。”

Q3：这个完整流程看起来很耗时，每次都要走一遍吗？
A：当然不是。对于低风险或小优化需求，可以只使用“提供上下文”和“澄清问题”这两个核心步骤。而对于高价值、高复杂度的新产品功能，则建议完整运行全流程，以实现收益最大化。

Q4：多个AI生成的版本如何管理？
A：建议使用清晰的文件命名来区分版本和思路，例如：PRD-智能纪要-v1-日历内嵌.md， PRD-智能纪要-v2-邮件优先.md。如果能结合Git等版本控制工具来管理变更记录，效果会更佳。

掌握与AI协作的正确姿势，能让你从重复性的文档整理中解放出来，更专注于产品策略和用户价值的思考。如果你对产品经理如何高效利用AI工具还有其他想法，欢迎在云栈社区与大家交流探讨。