产品经理把PRD写成“天书”，我用AI半小时重写了一遍，他当场愣住
前言
产品经理和开发之间的矛盾，根源往往不在需求本身，而在于需求表达方式。一个合格的需求文档应该包含：功能描述、业务规则、边界条件、异常处理、验收标准。但现实中，很多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是什么样的？后来怎么解决的？