当AI成为开发主力军，传统PRD的漏洞正在被无限放大。一篇血泪教训揭示：某团队用Cursor开发的权限管理模块，因AI照搬前端校验逻辑导致重大安全漏洞。本文独创'意图+护栏+验收'三层结构，拆解如何将PRD升级为AI可执行的精准协议——少一层，AI都可能高效地完成错事。
某团队用 Cursor 开发后台权限管理模块。PM 把需求压成 3 条提示词扔进去，AI 连续给出 4 版代码，每版跑起来都很顺，界面也不丑，角色显示逻辑看起来也对。
直到联调那天，后端同学发现：所有权限校验，全在前端。
什么意思？任何人打开浏览器控制台，改几个 JS 变量，就能绕过全部权限限制，直接访问管理员功能。一个教科书级的安全漏洞，在”看起来正常运行”的代码里藏了整整一周。
返工。折回重写核心逻辑，损失 3 个工作日，外加一场让所有人都不舒服的复盘会。
PM 事后只说了一句话”不是 Cursor 不够聪明。是我从来没告诉它，权限校验必须放在服务端。”
这句话在人类开发对接时，靠一句口头约定就能传递。但 AI 没有这个上下文——它只会用训练数据里”最常见的前端权限实现”来补全，而那恰好是最危险的那种。
这不是个例，这是一种系统性的误解正在被复制：把需求文档降级成聊天记录，然后抱怨 AI 总是跑偏。
问题不在工具，在认知。把 PRD 压成提示词，本质上是在用”聊天”替代”协议”。对人类协作者，模糊可以靠经验兜底；对 AI 执行者，所有没写出来的边界，都会被它用”最合理的猜测”填满——而那个猜测，往往不是你的业务规则。
写给 AI 的需求文档，不是更短的 PRD，而是一份“意图 + 护栏 + 验收”三层结构的可执行协议。少一层，AI 都可能很努力地把错事做完。
很多人的第一反应：是不是 PRD 写得不够详细？
不对。问题不是信息量，是信息类型。
传统 PRD 的默认对象，是”会脑补上下文的人类研发”。研发看到一句模糊描述，会追问，会结合经验修正，会凭常识绕开明显的坑。就像权限那个案例，换一个人类开发，他大概率会直接问一句：这个权限校验前端做还是后端做？
AI 不会这样做。它不追问，不凭常识，不主动识别你没提到的风险。它只做一件事：把模糊性转化成错误的确定性。
给它一个模糊需求，它会用”最合理的猜测”补全所有空白——而那个”合理”，来自训练数据里最常见的实现方式，不是你的业务规则，不是你的安全边界，不是你那个特定系统的架构约定。
这里有一个值得单独说的反常识判断:PRD 写得越“清晰完整”，有时候对 AI 越危险。
原因很简单：信息量大、表述流畅的 PRD，会让 AI 更有把握地在错误方向上高速执行，而不是停下来问你。如果文档里写了很多背景、愿景、用户价值，但没有约束边界，AI 会把这份”自信”投入到一个没有护栏的执行路径里——方向感十足，越界也十足。
真正的问题是：信息类型给错了。
传统 PRD 给的是叙事型信息——背景是什么、目标是什么、用户是谁、价值在哪里。这些对人类研发有用，能帮他们理解意图、建立认同。但 AI 需要的是执行型信息——边界在哪里、不能做什么、做到什么程度算对。
一份能驱动人类研发的好文档，不等于一份能驱动 AI 的好文档。这是两种完全不同的文档形态。
三层结构的第一层，是意图层。
有人会说：PRD 里不是有”需求背景”和”产品目标”吗？
不一样，差别很大。
传统 PRD 里的目标，通常写给评审会和老板看：偏抽象，偏汇报，喜欢用”提升用户体验””提高转化率””优化流程效率”这类词。这些表达对人类有意义，因为人类会用上下文和经验去解读它。
AI 需要的意图，是可执行的指令入口。它必须回答三个具体问题：这是谁的问题？为什么现在解决？做到什么程度算成功？
如果意图层缺失，AI 就会用”默认假设”补全所有空白：
这些补全不是错的，只是不是你的。
同一个需求，两种写法，结果天差地别：
错误的是”帮我做一个登录页”
正确的是”为首次注册用户提供手机号验证码登录入口，目标是降低首次进入门槛，确保用户在 30 秒内完成登录，不需要支持第三方登录”
区别不是信息量多少。后者明确了服务对象（首次注册用户）、核心动作（手机号验证码）、量化目标（30 秒内完成）、排除项（不需要第三方登录）。每一项都是 AI 做决策时真正需要的依据。
意图层建议固定写四项：
有一点必须强调：意图不是产品愿景，不是行业趋势，也不是”提升体验”这种放到哪个产品都能用的抽象词。它是 AI 后续所有判断的方向盘，写虚了，AI 就会自己定方向——而它定的，大概率不是你想要的那个。
没有意图层，AI 不是不会干活，而是会朝着一个你没定义清楚的方向，高效地干活。
意图层解决”往哪走”，护栏层解决”哪里绝对不能走”。
三层结构里，这一层最容易被低估，价值却最高。
开头那个权限案例，根源就在护栏层缺失。PM 告诉了 AI 要做什么，但没告诉它绝对不能怎么做。于是 AI 用它认为”最合理”的方式实现了——前端权限控制，代码干净，逻辑清晰，跑起来效果不错，只是踩了一个所有安全工程师都会皱眉的坑。
AI 的核心特征是：信息不足时，进行合理补全。这本身没问题，问题在于它眼中的”合理”，来自训练数据里的统计规律，不来自你的架构约束和业务红线。
所以在 AI 协作里，约束不是补充说明，而是优先级极高的主体信息。
护栏层至少要覆盖三类内容：
护栏层最有效的写法，不是”建议怎么做”，而是明确写“不允许做什么”：
为什么禁止项比建议项更有效？
告诉 AI”你可以这样做”，它会把这个选项加入备选池，再综合其他信息做决策——建议项，它理解成”参考”；告诉它”你不能这样做”，它会直接排除这条路径——禁止项，它理解成”边界”。负向约束在大模型推理时的权重，天然高于正向建议。这不是技巧，是大模型处理指令的基本机制。
很多 AI 返工，不是因为 AI 不会做，而是因为你从来没告诉它什么不能做。
没有护栏层，AI 往往交出”方向大体正确、细节全面越界”的产物——看起来很勤奋，实际上最费时间。
很多 PM 写需求时，心里默认”做出来我一看就知道对不对”。这个习惯在人类协作里能容忍，因为研发交付后你可以当场拍板、反复沟通。
AI 协作里，这个习惯代价极高。
AI 最大的问题不是偷懒，而是极其擅长交付一种东西——形式上完成、结果上偏题。 它会认真地满足你的字面需求，但如果你没有定义清楚”什么叫做对”，它就会交付一个”看起来像答案的答案”：跑得起来，但不是你要的那个。
验收层要做到三个词：可测试 / 可量化 / 可复现。
可测试，意味着验收条件必须能被逐条核查，不是靠主观感觉拍板；可量化，意味着能用时间、数量、条件、结果来定义是否达标；可复现，意味着换一个人、换一次执行、换一个环境，判断结论应该基本一致。
这些描述，必须从你的需求文档里消失:“用户体验流畅” / “页面简洁美观” / “逻辑合理” / “响应及时”这类词在人类之间勉强能沟通，对 AI 几乎无效。它不知道”流畅”是 1 秒还是 3 秒，不知道”合理”是哪种实现，不知道”及时”的上限在哪里。
有效的写法是这样的：
验收层还有一个更高效的写法：Bad Case 驱动。
与其描述”理想输出是什么样的”，不如列举”哪些输出是不可接受的”。在写验收层之前，先问自己：AI 在这个需求里最可能犯哪几个错？然后把这些错误写成禁止条件。比正向描述更精准，也更容易直接转化成测试用例。
这也是为什么验收层有一个很多人没意识到的额外价值：它天然可以转化为测试用例、检查清单，乃至后续的 AI 产品评测集。 验收层写得越清楚，上线回归越省成本。尤其对 AI 功能来说，这个收益会在每次迭代里持续兑现。
下面是登录功能的完整状态校验示意：
不会写验收标准的产品经理，不是在定义需求，而是在制造返工。
没有验收层，AI 不是交不了付，而是会交付一份”你没法稳定判断对错”的结果。
讲完三层，有人可能觉得：我平时只写其中一两层，好像也能凑合？
能凑合，但一定在某个地方出了问题，只是还没爆。
缺一层，会发生什么：
只有意图层，缺护栏——AI 知道你想去哪里，但会一路抄近道，最后越过所有不该碰的边界。方向正确，执行失控。
只有护栏，缺意图——AI 做事小心谨慎，却不知道真正目标是什么，结果常常保守、机械、低价值。没有越界，但也没有价值。
只有验收，缺意图和护栏——AI 可能非常努力地满足测试条件，但满足的是一个从根上就理解错的问题。努力方向正确，努力对象是错的。
三层的协作关系，一句话说清楚:意图层决定它为什么做 → 护栏层决定它不能怎么做 → 验收层决定它做到什么才算真的做对
这三层合在一起，构成的不是一份普通说明文档，而是一份可执行、可约束、可判断的协作协议。真正高质量的 AI 协作，不是让 AI 自由发挥，也不是把它绑死，而是给它方向、边界和判卷标准——这三件事，人类不做，AI 就会自己做，而它做出来的，往往不是你的答案。
有一个认知误区要先拆掉：用 Prompt 替代 PRD，不是进化，是降级。
提示词和需求文档是两种不同层级的工具，本来就不该互相替代。正确的姿势不是用 Prompt 替代 PRD，而是用 PRD 约束 Prompt，用 IDE 工程化挂载驱动执行。
在 2026 年的 AI IDE（如 Cursor、Trae）工作流中，这三层结构不是一次性粘贴到对话框里的长文本，而是对应着不同的工程文件级别。
第一步：护栏层下沉为全局配置（项目级记忆）
不要每次对话都重复技术边界。把最核心的护栏（如”禁止前端校验权限”、”必须使用 TailwindCSS”）直接写进项目根目录的 .cursorrules 文件。这是 AI 的潜意识，只要在这个项目里，它永远不会违背。
第二步：意图与验收封装为特性文档（模块级上下文）
为每个独立功能新建一个 Markdown 格式的 PRD 文件（如 feature_role_auth.md），里面只写该模块的”意图层”和”验收层（Bad Case）”。
第三步：用引用替代长文本投喂（任务级驱动）
在实际对话框里，你的 Prompt 应该变得极度简短，只负责下达单次动作指令。例如：
@feature_role_auth.md 帮我实现这个文档里的前端页面，注意对照验收层的 Bad Case 进行自测。
三步的文件对应关系如下：
产品经理未来最核心的能力，不是会写一条字数过万的提示词，而是能把复杂问题拆解成 AI 可以精准挂载的结构化文件。
为了看清这套结构的威力，回到文章开头的那个案例。
如果那个 PM 当时使用了三层结构来写”后台权限管理模块”，悲剧根本不会发生。以下是填入三层结构后的真实文档样貌：
第一部分：意图层（feature_auth.md）
第二部分：护栏层（写入 .cursorrules 全局规则）
第三部分：验收层（Bad Case 驱动）
这份模板的使用顺序：
当 AI 带着这样的协议去写代码时，那个”权限写在前端”的漏洞，在第一行代码生成前就被彻底锁死了。
把 PRD 降级成提示词，不是进化，而是误把”聊天”当成了”协作”。
AI 没有让需求文档失效，恰恰相反——它第一次逼着产品经理认真回答一个从来没有被认真回答过的问题：什么信息才是真正可执行的信息？
在人类协作时代，模糊表达能靠经验兜底。你写”注意权限问题”，老研发心领神会；你写”体验要流畅”，UI 同学自然有理解。整个协作系统靠人的判断和经验在运转，文档只是辅助工具，写得再模糊也有人去补全。
在 AI 协作时代，这个兜底机制消失了。所有的模糊，都会被放大成返工成本——而且是不动声色地放大，直到联调才爆，就像那个权限漏洞。
但这不是坏消息，这是一个信号：产品经理的核心价值，正在从“需求的搬运工”，回归到“可执行信息的定义者”。
当写代码的门槛被 AI 大幅拉低，当研发资源变得越来越充沛，真正稀缺的反而是那个能把业务问题拆解成 AI 可以精准挂载的结构化文件的人。那个人，就是产品经理——只要他们真的想清楚了意图在哪里、边界在哪里、判卷标准是什么。
未来被淘汰的，不是写 PRD 的产品经理。
而是那些只会写功能说明，却不会定义意图、护栏和验收的人。
本文由 @苏苏的AI笔记 原创发布于人人都是产品经理。未经作者许可，禁止转载
题图来自Unsplash，基于CC0协议
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。