Prompt Engineering for PMs：文档自动化
Prompt Engineering for PMs：文档自动化
PM 学 prompt engineering，真正的价值不是“会不会写很长的 prompt”，而是能不能把模糊需求快速变成结构化 output。很多 PM 觉得自己在用 AI 提效，实际上只是把原来的口头模糊需求复制给模型，然后花更多时间改废稿。
所以这页不讲“prompt 玄学”，而是讲 PM 最常见的文档、SOP、评审场景，怎么写出可复用、可协作、可落地的 prompt。
先说结论：PM Prompt 的核心不是更会写，而是更会限定
AI 写文档最常见的问题不是不会生成，而是：
- 结构看起来完整，但没有决策价值
- 语气很专业，但信息很空
- 写得很多，但没法直接给 team 用
所以 PM prompt 最重要的不是“多描述一点”，而是先限定 4 个变量：
- context
- task
- format
- acceptance bar
这四个没写清，输出质量通常不会稳。
为什么 PM 用 AI 最容易翻车
| 问题 | 根因 |
|---|---|
| PRD 很长但没重点 | 只写主题，没写目标和边界 |
| SOP 看起来完整但不可执行 | 没写 owner、timebox、异常处理 |
| meeting summary 漏关键信息 | 没定义“什么必须保留” |
| 需求评审文档太泛 | 没写 audience 和使用场景 |
AI 不会自动理解“你心里真正想要什么”。
它只会尽量填满你给的空白。
一个更适合 PM 的 Prompt Framework
比起通用框架，PM 更适合用下面这套：
| 模块 | 你该写什么 |
|---|---|
| Context | 产品背景、用户、业务目标 |
| Task | 要生成什么文档或分析 |
| Constraints | 必须包含什么，不能乱补什么 |
| Output format | section、table、checklist、字数 |
| Review bar | 什么叫合格 output |
重点不在名字，而在你有没有把这些内容补齐。
PRD 生成，别让 AI 一口气写整份
更稳的方式是拆成 3 步：
step 1: clarify problem
step 2: generate PRD skeleton
step 3: fill each section with constraints
如果你直接说“帮我写一份 PRD”，AI 往往会产出一个形式完整、内容空泛的标准模板。
一个更靠谱的 PRD Prompt
You are acting as a senior product manager.
Context:
- product: [name]
- target user: [who]
- business goal: [why this matters]
Task:
Create a PRD draft for the following feature:
[feature summary]
Constraints:
- clearly separate must-have scope from nice-to-have scope
- include unacceptable failure cases
- do not invent technical certainty
- mark assumptions as [assumption]
Output format:
1. problem statement
2. user task
3. feature scope
4. success metrics
5. edge cases
6. risks and dependencies
这类 prompt 的价值在于，它逼模型先写“决策需要的部分”，而不是先堆大段套话。
SOP Prompt 最容易被忽略的地方
很多 SOP prompt 只会要求“写出流程步骤”，但真正可执行的 SOP 至少还要包含：
| 项目 | 为什么不能少 |
|---|---|
| owner | 没人负责就不会执行 |
| trigger | 什么情况下启动这条 SOP |
| exception path | 出错时怎么办 |
| handoff | 角色之间怎么交接 |
| done definition | 什么叫流程完成 |
没有这些，AI 写出来的 SOP 很容易像培训材料，不像实际操作文档。
Meeting Summary Prompt，要先定义“什么不能漏”
如果你只是说“帮我总结一下会议”，大概率会得到一版看起来很平滑、但丢掉关键信号的摘要。
更实用的写法是：
Summarize this meeting transcript.
Must preserve:
- decisions already made
- open questions still unresolved
- action items with owner
- deadlines if explicitly mentioned
Do not:
- turn discussions into confirmed decisions
- invent missing owners
- compress away disagreement
PM 用 AI 总结会议时，最怕的就是把“讨论过”写成“已决定”。
Prompt Library 应该沉淀什么
PM team 真正值得沉淀的，不是几百条零散 prompt，而是高频模板。
建议优先沉淀：
- PRD draft prompt
- meeting summary prompt
- competitor analysis prompt
- research clustering prompt
- risk review prompt
- weekly update prompt
这些模板一旦固定，团队文档质量会明显更稳定。
Prompt 不是一次性输入，而是 team asset
一个成熟的 PM team，会开始给 prompt 做这些事：
- versioning
- owner
- example input
- expected output
- known failure mode
这和写内部模板库其实是一回事。
只不过以前是写表格模板，现在是写 AI instruction template。
常见翻车点
| 问题 | 修法 |
|---|---|
| AI 老写废话 | 强制 section 和长度限制 |
| 过度自信乱补 | 明确要求标注 assumption |
| 输出风格不统一 | 固定 voice 和 format |
| 团队每个人都各写各的 | 建 prompt library 和 review 机制 |
Practice
把你现在最常用的一条 PM prompt 拿出来，检查这 4 件事：
- 有没有明确 context
- 有没有写 output format
- 有没有写“不能乱补什么”
- 有没有定义什么叫合格
如果这 4 项里缺两项以上，这条 prompt 基本还不够稳。