产品需求发生变化后，最容易遗漏的不是 PRD，而是接口说明、页面文案、测试用例和旧逻辑。
如果只让 AI 阅读一份需求文档，它无法判断项目中的其他文件是否已经同步。MainBody 可以围绕整个项目目录搜索和比较资料，适合做一次跨文件的一致性检查。
适用场景
- PRD 已修改，准备进入测试；
- 接口字段刚完成调整；
- 页面文案或业务规则发生变化；
- 需要在发版前制作验收清单；
- 新成员需要快速了解需求与实现差异。
第一步：准备资料
建议项目中至少包含：
docs/prd.md
docs/api.md
src/
tests/
如果需求来自在线文档，可以先导出到项目目录，或者在任务中明确允许访问的官方页面。
不要把客户隐私、生产密钥或与本次检查无关的目录一起开放。
第二步：先定义检查口径
“检查有没有问题”太宽泛。产品经理应先说明重点：
检查当前项目中 PRD、接口说明、前端页面和测试是否一致。
重点关注：字段名称、状态流转、按钮文案、错误提示和权限条件。
先只读检查，不修改任何文件。
每项差异附文件路径和依据，无法判断的内容标记为待确认。
Agent 会先搜索相关资料，再按统一维度比较。
第三步：让结果按风险分类
可以继续要求：
把发现的问题分为三类：
P0 会导致数据或权限错误；
P1 会导致功能与需求不一致；
P2 文案、格式或测试覆盖问题。
同一根因不要重复列出。
风险分类能帮助团队决定修复顺序，而不是得到一份没有优先级的长清单。
第四步：生成验收文件
在 docs/review-output 中生成：
1. consistency-report.md：差异、依据和风险；
2. acceptance-checklist.xlsx：功能、前置条件、操作步骤、预期结果、状态。
保留原项目文件不变，完成后检查链接和表格字段。
报告用于解释原因，Excel 用于测试和跟踪。
第五步：人工复核关键差异
重点检查：
- Agent 引用的文件路径是否正确；
- 需求是否存在多个版本；
- 代码中的旧逻辑是否仍被实际调用；
- 权限和状态条件是否被简化；
- 测试缺失是否真的意味着功能未实现。
AI 能快速发现线索，但最终业务含义仍需要产品、开发和测试共同确认。
可以继续怎样使用？
确认清单后，可以把已批准的问题交给编程 Agent 修改，并要求逐项运行测试。不要让“发现问题”和“自动改代码”在没有确认的情况下混成一步。
总结
产品经理使用 MainBody 的价值，不是让 AI 重写 PRD，而是把需求、接口、代码和测试放进同一个检查范围，形成带路径、依据和优先级的验收清单。
可直接复制的核心指令是：先只读比较，再分类风险，最后生成报告和验收表。
了解 MainBody：https://mainbody.cn