夜雨聆风很多团队已经把粗略需求直接丢给 AI Coding 工具。结果常见得很稳定：代码能生成，方向也像那么回事，但边界不清、验收不稳、异常路径遗漏，最后还是要人工返工。
问题通常不在模型写代码慢，而在需求文档没有进入“可执行规格”的状态。人类读 PRD 会自动补全业务语境、历史约定和产品判断，Agent 只能读取文档、代码、测试和工具返回的事实。
AI First 需求文档把模糊愿望整理成结构化输入，让 Agent 能拆任务、找代码、改实现、写测试、跑验证。它服务的对象仍然是人，同时也让机器有稳定的执行依据。
更稳的路径是先让工具重写 PRD，再进入实现。目标、边界、状态、验收和验证整理清楚后，代码生成会有稳定轨道。
AI First PRD 的本质是一条工作流。它把需求澄清、任务拆解、实现、验证和需求回写连成闭环，让 Agent 在每一步都有明确输入和退出标准。沿着这条链路展开，需求文档先要变成一组可执行的结构。
一、先把粗略 PRD 里的隐含上下文摊开
粗略 PRD 对人类团队通常够用，因为产品、设计、研发、测试会在会议和评审里补充大量隐含信息。按钮放在哪里、老用户数据怎么兼容、异常提示用哪套文案、接口失败怎么重试，这些内容经常没有完整写进文档。
AI Coding 工具接到这类文档时，会把缺口转成推断。推断一多，代码就会出现看似合理的偏差：数据库字段随意命名，权限判断漏掉角色，状态枚举少一个分支，测试只覆盖快乐路径。
因此，重写 PRD 的第一步是把“人会补”的部分显式化。工具可以帮忙发现缺口，但产品负责人需要确认业务判断。AI 适合整理结构、提出问题、生成草案和补齐检查项，最终边界仍要由团队确认。
粗略 PRD 进入实现前要先补齐的四类信息
1. 目标： 用户问题、业务收益、成功指标。
2. 边界： 本期做什么、暂缓什么、明确排除什么。
3. 状态： 页面状态、数据状态、权限状态、异常状态。
4. 验收： 用户可见结果、系统行为、测试与人工检查标准。
二、用五块结构组织 AI First PRD
传统 PRD 常按背景、功能点、原型、备注来写。这个结构方便人开评审会，但对 Agent 的帮助有限。Agent 先拿到目标和约束，后面的拆任务、改代码和验证会更稳定。
更适合 AI Coding 的结构可以压成五块：目标与指标、范围边界、状态与规则、接口与数据、验收与验证。五块内容按执行顺序排布，每一块都对应一个实现判断。
三、先做需求审稿，别急着写代码
更稳的做法是分成两轮。第一轮只做需求审稿，不动代码。工具先阅读原始 PRD、项目说明、相关代码目录和历史模式，输出歧义清单、缺失字段、风险路径和建议结构。
第二轮再把确认后的内容改写成 AI First PRD。这样能避免一个常见问题：需求还没有稳定，Agent 已经开始填补实现细节。代码写得越早，猜测越容易固化成提交。
Claude Code、Codex、Cursor、GitHub Copilot Coding Agent 都能参与这类流程。项目级规则可以放在 AGENTS.md、CLAUDE.md、Cursor Rules 或 Copilot repository instructions 中，让工具在审稿和实现计划阶段同时读取需求约束与仓库约束。
需求审稿指令示例
请只审查需求，不要写代码。
阅读这份粗略 PRD 和当前仓库中相关模块。
输出四部分：
1. 需求中已经明确的事实
2. 影响实现的歧义和缺口
3. 需要产品确认的问题，按阻塞程度排序
4. 推荐的 AI First PRD 结构
要求：
每个问题都说明它会影响哪个实现决策。
不要自行替产品做业务判断。
不要进入代码修改。四、把验收标准写到测试能落地
AI First PRD 的核心差异在验收。普通 PRD 常写“支持用户筛选订单”“页面展示状态”“错误时提示用户”。这些句子能表达方向，对实现分支的指导仍然不够稳定。
验收标准要写成可观察行为。用户在什么条件下做什么动作，系统展示什么结果，数据如何变化，失败时返回什么，权限不足时怎样处理。这样的句子可以直接转成测试用例、手工检查路径或 E2E 场景。
验证计划也要进入 PRD。单元测试验证纯逻辑，集成测试验证接口和数据库，端到端测试验证关键用户流程，人工检查覆盖视觉、文案和复杂业务判断。Agent 完成后按照这份计划交出证据。
验收标准写法
对象： 管理员、普通成员、访客、系统任务等角色。
条件： 数据存在、数据为空、接口失败、权限不足、重复提交等状态。
动作： 点击、提交、筛选、刷新、导入、撤销、重试。
结果： 页面反馈、数据变更、错误提示、日志记录、测试断言。
五、把一句功能点改成可执行规格
下面是一条常见粗略需求。它表达了功能方向，但缺少角色、范围、数据字段、异常路径和验收标准。直接交给 Agent，模型只能自己补。
粗略写法
订单列表增加一个导出功能。
用户可以按时间筛选订单，然后导出 Excel。
导出失败时给一个提示。改写后的版本要让 Agent 能看见实现边界。它不需要把所有 UI 细节都写死，但影响代码和测试的决策要写清楚。
AI First PRD 片段
Feature
订单列表支持导出筛选结果。
User
具备订单管理权限的运营人员。
Scope
本期只支持按创建时间导出当前筛选结果。
本期不支持自定义导出字段，不支持异步导出中心。
Data
导出字段包括订单号、创建时间、支付状态、订单金额、收货人和手机号脱敏值。
时间范围最长 31 天。
单次导出最多 10000 条。
Interaction
用户选择时间范围后点击导出按钮。
系统生成 xlsx 文件并触发下载。
没有数据时按钮可点击，导出文件只包含表头。
Error
无权限时隐藏导出按钮。
接口超时或生成失败时展示可重试错误提示。
超过 10000 条时提示缩小筛选范围。
Acceptance
管理员能导出 31 天内订单。
普通成员看不到导出入口。
空结果导出文件只包含表头。
超过上限时不会生成文件，并展示明确提示。
Verification
补充导出字段映射单元测试。
补充权限和上限的接口测试。
手工检查下载文件名、字段顺序和手机号脱敏。六、进入实现前，再做可实现性审查
第三节的需求审稿解决“需求有没有说清”。这里的可实现性审查解决另一个问题：这份规格是否已经可以进入当前仓库。
AI First PRD 写完后，让工具找相似模块、识别可能改动的文件、列出测试入口和风险点。重点放在规格能否落到现有代码，而非继续润色文案。
这一步可以把需求文档和项目说明文件连起来。如果仓库里已经有 AGENTS.md、CLAUDE.md、Cursor Rules 或 Copilot repository instructions，工具应当根据这些规则给出实现计划。需求文档定义“做什么”，项目说明定义“在这个仓库里怎样做”。
审查结果应当回写到 PRD 或任务计划里。比如发现项目没有 xlsx 生成依赖、现有权限模型没有导出权限、订单表缺少必要索引，这些都应当在实现前暴露，避免在代码写到一半时临时补救。
实现前审查清单
1. 现有代码里是否有相似功能、相似接口、相似测试。
2. 需求是否需要新增依赖、数据库字段、权限点或后台任务。
3. 每条验收标准是否能对应到测试、构建或人工检查。
4. 哪些内容属于产品判断，需要人工确认。
5. 哪些风险需要拆成单独任务或放到后续版本。
七、产品判断仍然要由人确认
AI Coding 工具可以把粗略文字整理成结构化规格，也可以根据仓库上下文发现许多实现风险。但产品判断仍然需要团队确认。是否限制导出 31 天，是否允许普通成员导出，手机号脱敏规则采用哪种格式，这些决定都涉及业务、合规、体验和运营成本。
更成熟的用法，是把 Agent 当作需求结构化助手和实现风险审稿人。它负责把遗漏摊开，把选项列清，把验收标准写实，把验证路径补齐。人负责确认取舍、处理冲突、批准范围和承担结果。
这条边界建立起来后，AI Coding 工具的价值会从“帮忙写代码”向前移动到“帮团队把需求变成可执行规格”。需求越扎实，后面的计划、实现、测试和评审越稳定。
总结
1. 粗略 PRD 让 Agent 猜上下文，AI First PRD 把上下文写成可执行规格。
2. 有效流程是先审稿、再重写、再实现，需求不稳定时先暴露歧义。
3. 验收标准要对应测试、构建或人工检查，完成结果要有证据。
4. 工具负责结构化和风险暴露，产品负责人负责取舍和确认。
