给 AI 写需求：让 Agent 一次做对的 PRD 写作法

用 AI 写代码一年下来，我最大的体会不是"模型又变强了"，而是：瓶颈从"写代码"转移到了"说清楚要什么"。同一个需求，写得好的 PRD（产品需求文档）能让 agent 一次交付可用版本；写得差的，你改三轮 prompt 还不如自己写。这篇文章把我给 agent 写需求的方法论完整拆开——它本质上是一套"把模糊想法翻译成机器可执行规格"的写作法。

先说一个反直觉的结论：给 AI 写需求文档，要比给人写更严格，而不是更随意。很多人觉得"反正是 AI，随便说两句它能理解"。错。人类同事能靠共识、经验和"你懂的"补全你的省略，agent 只会按字面执行——你没写的，它要么瞎猜，要么跳过。Vibe coding 里 80% 的返工，根子都在需求文档里。

一份 Agent 可执行的 PRD 长什么样

我用的模板是七段式，每段都有明确目的。注意，这不是给投资人看的 PRD，是给 agent 的"施工图纸"：

• 1. 一句话目标。用一句话说清这个东西是什么、给谁用、解决什么问题。例："给独立开发者用的极简番茄钟网页应用，解决手机 App 太重、打开太慢的问题。"如果一句话说不清，说明你自己还没想清楚，agent 更不可能想清楚。
• 2. 非目标（Not Goals）。这是最被低估的一段。明确写出"这次不做什么"：不做用户系统、不做多端同步、不支持离线。Agent 的"过度发挥"是返工大户——你不写边界，它会自作主张给你加上登录、加了深色模式、加了你不想要的动画。
• 3. 用户故事（3-5 条）。用"作为…我想要…以便…"的格式写核心流程。不要写 20 条，agent 会迷失优先级。每条故事就是一条可验收的交付线。
• 4. 功能规格：页面/接口/数据。列出页面清单（每个页面的元素和交互）、数据模型（字段、类型、关系）、关键接口的输入输出。不需要 UML，但字段名和类型必须精确——这是 agent 最容易"自由发挥"的地方。
• 5. 技术约束。指定技术栈、必须用的库、不能用的东西（"不要引入新的 CSS 框架，用 Tailwind"）、部署目标。约束越具体，agent 的发挥空间越可控。
• 6. 验收标准。每条用户故事对应 2-3 条可验证的标准，写成"当…时，应该…"的句式。这是你 review 交付物的 checklist，也是 agent 自我检查的依据。
• 7. 里程碑拆分。把工作拆成 2-4 个可独立交付的阶段，每个阶段结束都有可运行的东西。永远不要让 agent 一次性交付全部——上下文会爆，质量会崩。

三个真实案例：好需求 vs 坏需求

案例一：坏需求。"做个好看的待办应用，要有统计功能。" agent 交付了一个带 5 种图表、3 种主题、番茄钟、标签系统的"巨无霸"，而你只是想要个每天打勾的清单。问题：没有非目标，没有验收标准，"好看"无法验证。

改写后："极简待办网页（目标）。不做：用户系统、标签、统计图表、移动端适配（非目标）。用户故事：作为用户，我每天打开页面能看到今天的任务并打勾。验收：首屏加载<1秒；任务数据存 localStorage；只有'今天'一个视图。" 同一个 agent，这次一次做对。

案例二：字段含糊的代价。"用户表要有基本信息。" agent 建了个只有 name 和 email 的表，第二轮你说要头像，第三轮说要时区——每次改表结构都要迁移数据。改成"用户表字段：id(uuid)、name(string, 必填)、email(string, 唯一)、avatar_url(string, 可空)、timezone(string, 默认 UTC)"，一次到位。

案例三：验收标准救了你。"搜索要快。" agent 用了最简单的 filter 实现，100 条数据没问题，上线后 10 万条直接卡死。改成"验收：10 万条记录下搜索响应 <300ms，需用数据库索引而非前端过滤"，agent 会自己选对方案。

四个进阶技巧

技巧一：先让 AI 帮你写 PRD。把你的粗糙想法丢给 AI："我要做个 X，帮我按七段式模板写成 PRD，并向我追问 5 个你最需要澄清的问题。"你会发现，AI 提问的质量，恰恰暴露了你想法的模糊地带。回答完这 5 个问题，PRD 就完成了 80%。

技巧二：用"反例"定义边界。除了说"要什么"，明确说"不要像什么"："交互参考 Linear 的简洁，不要 Notion 那种重型编辑器。"反例比正例更能收敛 agent 的发挥。

技巧三：把"为什么"写进文档。在关键决策后加一句括号说明："用 localStorage 而非后端（因为这是单文件 demo，不需要服务端）"。Agent 理解决策意图后，后续的自主发挥会更贴合你的思路，而不是机械执行字面要求。

技巧四：PRD 是活的，每轮迭代更新它。很多人的 PRD 写完就扔了，第三轮需求变更时 agent 开始"精神分裂"——新指令和旧文档打架。正确做法：每次大的需求变更，先更新 PRD 再让 agent 动手。文档和代码，永远保持同一步调。

我的观点：PRD 能力正在取代"写代码能力"，成为新的稀缺技能

去年这个时候，vibe coding 社区还在争论"提示词工程是不是伪科学"。一年过去，答案已经很清楚了：重要的不是提示词技巧，而是"把事情说清楚"的能力——需求分析、边界定义、验收设计，这些传统产品经理的基本功，正在成为 AI 时代每个开发者的必修课。

更深一层：PRD 写作法的本质，是把隐性知识显性化。你脑子里"这个 obviously 应该这样"的部分，恰恰是 agent 最可能猜错的部分。写 PRD 的过程，就是把你作为领域专家的直觉，一条条翻译成机器可执行的规格。这个能力，模型再强也替代不了——因为"想要什么"永远是人的事。

所以，别再收藏"100 个神级 prompt"了。花一个下午，认真写一份七段式 PRD，拿去喂你最常用的 coding agent，对比一下交付质量。这个练习的回报，会超过你看过的所有 prompt 教程。