PRD怎么写，vibe coding能够减少50%以上的测试时间？
公众号名称：gnash的AI实验室
作者名称：gnash
发布时间：2026-04-23 09:54
上周我看一份 PRD （产品需求文档），看到第 27 页的时候，有点坐不住。
不是它写得差。
恰恰相反，它很完整。背景、目标、页面、字段、流程，全都有。看起来像一份标准答案。
但我脑子里一直冒出一个问题：
这东西给 AI （人工智能）去开发，真的能少返工吗？
答案挺刺耳。
不能。
因为它写清楚了“产品长什么样”，但没写清楚“开发怎么判断做完了”。更麻烦的是，它也没写清楚“测试应该怎么证明没做偏”。
这就是现在很多人做 vibe coding （氛围编程）最容易踩的坑：以为把需求丢给 AI ，开发速度就会飞起来。结果代码是快了，测试却变成补锅现场。
你改一个页面，另一个入口坏了。
你修一个字段，三条边界路径崩了。
你让 AI 生成测试，它倒是生成了，问题是测的东西和真实需求隔着一层雾。
很烦。
测试时间为什么会被 PRD 吃掉？
我以前也以为，测试慢是因为测试用例写得晚。
后来发现，不对。
测试慢，很多时候是因为 PRD （产品需求文档）写得太“像文档”，不像“可执行约束”。
传统 PRD 经常写这些：
•用户可以创建任务
•支持编辑和删除
•系统自动评分
•展示统计结果
看着没问题。
但测试同学打开以后，心里会冒出一串问号：
•创建任务要校验哪些字段？
•删除后关联数据怎么办？
•自动评分失败算失败，还是进入待处理？
•统计结果按实时算，还是按缓存算？
•用户没权限时，提示什么？
这些问题没有提前写，测试阶段就会变成大型问答节目。
PM （产品经理）补一句，研发改一版，测试重测一轮。来回三次，一下午没了。
所以我越来越觉得， vibe coding （氛围编程）真正节省测试时间的地方，不是“AI 帮你写测试”。
而是：PRD 写作阶段就把测试问题提前暴露出来。
这才是那个 50% 的来源。
不是少测一半。
是少掉一半“测了才发现需求没说清”的时间。
一份适合 vibe coding 的 PRD ，必须拆成两层
如果只写一份巨大的 PRD （产品需求文档）， AI 会很难受。
人也难受。
我的建议是拆成两层：一层是总体介绍，一层是单个 US （用户故事）。
总体介绍文档不负责展开所有细节，它负责当“地图”。里面要有产品背景、目标用户、业务闭环、功能地图、页面地图、 US （用户故事）索引、术语编号、非功能需求总则。
这件事有点像装修前先看户型图。
你得知道厨房在哪，水电从哪走，承重墙不能动。别一上来就讨论某个抽屉拉手用什么颜色。
单个 US （用户故事）文档才是施工单。
它要写清楚：
•作为谁，我希望做什么，以便得到什么收益
•前置条件是什么
•业务规则是什么
•字段类型、必填、约束是什么
•状态怎么变化
•页面线框怎么长
•正常路径怎么验收
•边界路径怎么验收
•哪些明确不做
注意那个“不做”。
很多 AI 项目返工，坏就坏在这里。你没告诉 AI 不做什么，它就会热心过头，顺手给你加一堆“看起来很聪明”的功能。
整挺好。
但上线前全是债。
50%的测试时间，是从 US 文档里省出来的
我说一个很具体的写法。
每个 US （用户故事）都必须有两张表：正常路径验收标准、边界路径验收标准。
正常路径写什么？
写用户在满足前置条件时，做了某个动作，系统必须给出什么结果。
比如：
| Given （给定） | When （当） | Then （那么） |
|---|---|---|
| 教师已登录，班级存在 | 发布包含 10 道题的任务 | 系统创建任务并进入待作答状态 |
| 学生已收到任务 | 提交全部答案 | 系统保存答题记录并触发评分 |
边界路径写什么？
写那些最容易让系统发疯的情况。
比如：
| Given （给定） | When （当） | Then （那么） |
|---|---|---|
| 任务已发布 | 教师尝试删除任务 | 系统禁止删除，并提示先归档 |
| 评分服务超时 | 学生提交答案 | 系统保留提交记录，状态进入待评分 |
这两张表一写，测试时间会立刻变短。
为什么？
因为测试不用再猜 PM 想测什么，研发也不用猜 AI 生成的实现算不算对。每个 US （用户故事）从一开始就是一个可开发、可测试、可回归的小闭环。
我甚至会更狠一点：没有验收标准的 US （用户故事），不允许进入开发。
听起来官僚。
实际省命。
Agent 产品更要写“判断”，不然测试会爆炸
如果你做的是普通 CRUD （增删改查）产品， PRD 写字段和流程还勉强能撑住。
但如果你做 Agent （智能体）产品，只写页面就完了。
Agent （智能体）真正难测的不是按钮。
是判断。
用户说“帮我整理一下会议纪要”，系统到底要生成摘要，提取待办，还是写成汇报材料？什么时候要追问？什么时候可以直接执行？什么时候必须停下来让用户确认？
这些不写，测试阶段会变成玄学。
同一条输入，今天算通过，明天又说不符合预期。
AI （人工智能）最怕这种湿漉漉的需求，抓不住，拧不干。
所以 Agent PRD （智能体产品需求文档）要额外写三块：
•意图空间：用户可能真正想完成什么
•工具调用规则：在什么条件下调用搜索、知识库、日历、工单系统
•边界条件：信息不足、工具失败、高风险动作、多解冲突时怎么停
这三块不是高级配置。
它们就是测试用例的来源。
比如“创建任务”这种高风险动作， PRD 里必须写：责任人和截止时间不明确时，只能生成草稿，不能自动提交。那测试就很清楚：构造一个缺责任人的输入，看系统有没有停下来。
这比上线后用户来骂强多了。
vibe coding 的正确节奏：不是一口气生成全项目
我见过最糟糕的 vibe coding （氛围编程）姿势，是把一份大 PRD （产品需求文档）丢给 AI ，然后说：
“帮我实现整个系统。”
这不是提效。
这是开盲盒。
更稳的节奏应该是：
1.写总体 PRD （产品需求文档），锁定业务闭环、角色、功能地图、页面地图。
2.拆成 US （用户故事），每个 US 只处理一个最小业务闭环。
3.给出 US （用户故事）构建顺序，遵守“先生产数据，再消费数据”。
4.为每个 US （用户故事）写验收标准和边界路径。
5.让 AI （人工智能）按单个 US 开发。
6.每个 US 完成后，产出测试验收报告和独立检查报告。
7.通过后再进入下一个 US 。
这套流程看着慢，其实快。
因为 AI 不再需要在一堆上下文里猜你的意图。它只要完成一个小闭环，然后用测试报告证明自己没跑偏。
这里有个关键原则：先做生产数据的 US （用户故事），再做消费数据的 US 。
比如先有学校、年级、班级、学生，后面才能发任务；先有任务和答题记录，后面才能做监控统计。你要是先做统计页，只能接假数据，后面每个底层能力一变，统计页都要返工。
这不是 AI 的错。
是施工顺序错了。
真正减少测试时间的，是“证据链”
我现在会要求每个 US （用户故事）带证据来源。
证据可以来自 PRD （产品需求文档）章节、用户调研、业务规则、接口文档、历史问题。格式不复杂，一张表就行：
| 证据编号 | 来源文档 | 原文摘要 | 支撑内容 |
|---|---|---|---|
| E-001 | PRD 第 3 章 | 教师可向班级发布任务 | 支撑任务发布入口 |
| E-002 | 业务规则 | 已发布任务不可删除 | 支撑删除边界 |
这张表有什么用？
它让测试和检查不再靠感觉。
AI （人工智能）做出来以后，检查报告可以直接问：这个功能是否覆盖了 E-001 ？有没有违反 E-002 ？如果没有证据，先别加功能；如果证据冲突，先回到文档修正。
这会显得有点冷。
但项目到了后半段，你会感谢它。因为每次回归都能追到源头，而不是靠群聊里那句“我记得当时好像说过”。
那句话太贵了。
如果你只记一件事： PRD 要写到测试能直接接手
所以， PRD （产品需求文档）怎么写，才能让 vibe coding （氛围编程）减少 50% 以上测试时间？
我的答案就一句：
把 PRD 写到测试能直接接手，而不是写到研发大概看懂。
研发大概看懂，只能开始写代码。
测试能直接接手，才说明边界、状态、验收、范围、证据都已经被压实。
从这个角度看， PRD 不是文档。
PRD 是 AI 开发的轨道，也是测试回归的地图。
你轨道铺得直， AI 跑得快；地图画得清，测试走得少。
我不敢保证每个项目都能稳定省 50%。这个数字要看需求复杂度、团队习惯、 AI 工具能力。
但我敢说，如果你现在的测试时间大量花在“需求没说清、边界没写、返工重测”上，那把 PRD 拆成总体介绍 + 单个 US （用户故事） + 验收标准 + 证据链，省掉一半无效测试时间，并不夸张。
可能还不止。
就看你愿不愿意把文档写到那一步。
gnash gnash的AI实验室
内容效果不满意？点此反馈