前言

产品经理和开发之间的矛盾，根源往往不在需求本身，而在于需求表达方式。一个合格的需求文档应该包含：功能描述、业务规则、边界条件、异常处理、验收标准。但现实中，很多 PRD 长这样：

“用户点击支付后，系统要快速响应，提升支付成功率。”

这叫什么？这叫作文，不叫需求。快速是多久？提升到多少？失败怎么处理？全没写。

以前我拿到这种文档，只能自己猜、自己补、自己扛。猜错了，上线出 bug，责任在我；补漏了，工期延误，背锅也是我。后来我想：能不能让 AI 帮我 “翻译” 这份天书？把产品经理的模糊语言，自动转成可执行的技术验收点。

我试了，效果超出预期。今天我把这套方法拆给你，包括 Prompt 模板、操作步骤、以及我踩过的坑。以后你拿到 “天书”，也可以让 AI 帮你 “翻译”。

一、先看对比：同一份需求，“人话版” vs“产品版”

产品经理写的原文：

“订单列表页需要支持高级筛选，用户可以根据多种条件查询订单，提升查找效率。筛选条件要易于理解，不要给用户造成困扰。”

我用 AI 翻译后的版本：

【功能】订单列表高级筛选
【输入条件】
- 筛选字段：订单号（文本精确匹配）、订单状态（下拉：待支付/已支付/已取消/退款中）、下单时间（日期范围选择器）
- 默认展示最近30天的订单
【业务规则】
- 多个筛选条件之间为 AND 关系
- 订单号匹配：忽略前后空格，大小写不敏感
- 时间范围：开始时间 <= 结束时间，否则提示“开始时间不能晚于结束时间”
- 无结果时，显示“暂无符合条件的订单”，并提供“清空筛选”按钮
【异常处理】
- 接口超时：提示“查询失败，请重试”，保留当前筛选条件
- 数据量超过1000条：前端分页，每页20条
【验收标准】
- 筛选后URL同步筛选参数，刷新页面保留筛选状态
- 点击“重置”清空所有筛选条件，恢复默认状态
- 筛选操作平均响应时间 < 500ms

你看，同一个需求，一个模糊，一个可执行。AI 帮我补全了所有产品经理漏掉的细节。

金句：产品经理写的是 “愿望”，AI 帮他翻译成 “工程”。

二、我是怎么做的：三步搞定

第一步：把原始 PRD 喂给 AI

我打开 Cursor（或任何支持长上下文的 AI 工具），把那份 15 页的 “天书” 分成几个部分粘贴进去。提示词如下：

你是一位资深技术架构师兼产品顾问。请将以下产品需求文档（PRD）翻译成一份“开发者可执行的技术验收文档”。

要求：
1. 为每个功能点补充：输入条件、业务规则、边界情况、异常处理、验收标准
2. 对模糊的描述（如“体验更好”“性能提升”）给出具体可测量的指标
3. 对缺失的逻辑分支（如空数据、网络超时、权限不足）补充标准处理方式
4. 输出格式使用Markdown，分模块列举

原始PRD内容：
[粘贴内容]

第二步：AI 生成初稿，我逐条审核

AI 生成的文档不可能一次完美。它会过度补充（比如加上 “支持暗黑模式” 这种无关内容），也会漏掉一些特定业务规则。我花 15 分钟逐条过了一遍：

• ✅ 保留合理的补充（如边界条件、异常处理）
• ❌ 删除过度的猜测（“用户希望导出发送邮件”）
• ✏️ 修正错误的业务逻辑（比如我们订单状态只有 5 种，AI 写了 6 种）

第三步：拿着新文档找产品经理 “对线”

我打印出 AI 翻译后的文档，约小马开会。我跟他说：“这是我根据你的 PRD 整理的可执行版本，你看看有没有遗漏。”

他一页页翻，越翻越慢。翻完后说：“这比我自己写的还细。边界条件我都没想到，你怎么想出来的？” 我笑了笑：“AI 想的。” 他沉默了几秒，然后说：“以后我写完 PRD，你先跑一遍这个流程？”

金句：最好的需求评审，不是开发挑产品的刺，而是 AI 帮产品补漏。

三、注意事项：不要完全信任 AI

• AI 会 “过度脑补”：它可能加一些你公司根本不存在的功能。一定要人工审核。
• 保护敏感信息：不要把公司核心业务数据、未公开的定价策略等喂给云端 AI。可以用本地模型或脱敏。
• 与产品保持沟通：AI 补充的内容，要让产品确认。不要自作主张改了需求，上线后产品不认账。
• 版本管理：每次用 AI 生成的新文档，保留原始 PRD 的版本号，方便追溯。

四、完整的 Prompt 模板（直接复制用）

# 角色
你是一名资深技术架构师，擅长将模糊的产品需求转化为精确的可执行技术文档。

# 任务
将以下产品需求文档（PRD）翻译成“开发者可执行的技术验收文档”。请遵循以下格式：

## [功能模块名称]
### 输入条件
- 列出所有输入字段、类型、是否必填
### 业务规则
- 具体的计算逻辑、状态流转、权限判断
### 边界情况
- 空数据、极限值、重复提交、并发等
### 异常处理
- 网络超时、接口报错、权限不足、数据不一致
### 验收标准
- 用可量化的指标描述：响应时间、成功率、UI状态等

# 输出要求
- 使用Markdown格式
- 对原始PRD中模糊的词语（如“快速”“友好”“鲁棒”）给出具体数值或标准
- 不要添加与原始需求明显无关的功能

# 原始PRD内容：
[请粘贴内容]

五、写在最后

以前我总觉得产品经理是 “敌人”，后来我发现，他们只是不会用开发的语言表达需求。AI 成了我们之间的 “翻译官”。

下次你拿到一份 “天书” 般的 PRD，别急着骂，先让 AI 帮你翻译。你会发现，原来产品经理想说的没那么糟，只是他没说清楚。

你遇到过最离谱的 PRD 是什么样的？后来怎么解决的？