企业官网建设流程全解析

如何用 BMAD-METHOD 的 bmad-prd 校验一份已有 PRD 并拿到 findings 报告

【免费下载链接】BMAD-METHODBreakthrough Method for Agile Ai Driven Development项目地址: https://gitcode.com/gh_mirrors/bm/BMAD-METHOD

PRD 已经写好了，你不确定它的质量够不够支撑后续的 UX、架构和拆 story——但不想让它被顺手改写。BMAD-METHOD 的bmad-prd提供了三个意图：create、update、validate，其中Validate就是专门做这件事：对已有 PRD 只批评、不修改（"Critiques without changing"），最后合成一份 findings 报告（validation-report.html+validation-report.md）给你打开。Define Requirements and a Specification 对 Validate 的原文描述是："critiques without changing and produces a findings report"。

这篇文章按实际操作顺序走一遍：前置条件、如何触发校验、报告会落在哪里、报告怎么读、怎么复跑和继续处理 findings。

前置条件

• 项目里已安装 BMad。Choose a Planning Path 的前置说明明确要求：使用任何 BMad 工作流之前先安装 BMad。
• 有一份已落盘的 PRD：prd.md；如果存在配套addendum.md（存放 PRD 正文之外、属于下游文档的深度内容），校验时会被一并读取。
• 环境里可用uv。bmad-prd的激活步骤要通过uv run {project-root}/_bmad/scripts/resolve_customization.py ...之类的命令解析定制配置（见 bmad-prd 的 SKILL.md），这些脚本依赖uv执行。
• 交互语言来自项目配置{project-root}/_bmad/bmm/config.yaml（若存在config.user.yaml则一并加载）；缺失的键走中性默认值，不会阻塞运行。

触发校验：明确说 validate

Choose a Planning Path 说得很直白："bmad-prdhas three intents, create, update, and validate; say which one you want when you invoke it, or it will ask." 也就是说：

1. 在新的会话里调用bmad-prd；
2. 第一句话就说明你要validate已有的 PRD，并把prd.md的路径（或所在 run 目录）告诉它；
3. 如果你没说清意图，skill 会停下来问你三者选哪个——不会猜。

两点提醒：

• 老版本的独立 skillbmad-validate-prd已废弃，现在只是一个转发壳：它向前转发给bmad-prd并预置 validate 意图（见 bmad-validate-prd shim）。新工作直接调用bmad-prd。
• 校验全程不改动PRD 正文；Validate 结束后不会执行 Create/Update 流程里的 Finalize 阶段（memlog 审计、polish、status 置 final 等都不做）。

交给它之后发生了什么

流程定义在 references/validate.md，分三步：

1. Orient：对.memlog.md（如果该 PRD 之前跑过 Create/Update，memlog 里有历史决策）、你提供的原始输入、以及 PRD/addendum 本身做 source-extract，由子代理抽取、父代理汇总。
2. Reviewer Gate：并行派发评审子代理，每个把自己的完整评审写入 run 目录（{doc_workspace}）下的review-{slug}.md，只向父代理返回紧凑摘要（verdict、top 2–5 findings、文件路径）。其中：
   • rubric walker 是默认评审入口。它逐条对照质量 rubric（默认 assets/prd-validation-checklist.md）走 PRD，对七个维度各给出strong / adequate / thin / broken判断：Decision-readiness、Substance over theater、Strategic coherence、Done-ness clarity、Scope honesty、Downstream usability、Shape fit。findings 只写在真正有信息量的地方，要求引用 PRD 的具体位置并原话引用；严重度（critical/high/medium/low）衡量的是对 PRD 实用性的影响，而不是修复难度。结果写入{doc_workspace}/review-rubric.md。
   • 附加评审来自finalize_reviewers配置（references/validate.md 注明默认含 adversarial-general），条目支持skill:、file:前缀或纯文本提示词。
3. Synthesis：父代理读取所有review-*.md，填入 HTML 骨架（默认 assets/validation-report-template.html），写出两份报告，然后用平台默认方式打开 HTML——macOS 用open，Linux 用xdg-open，Windows 用start ""，路径加双引号：

open "{doc_workspace}/validation-report.html"

打开失败时不会换别的 opener 重试，而是直接告诉你文件路径继续往下走。headless 模式跳过打开这一步。

{doc_workspace}是本次运行绑定的 run 目录；headless 模式下对 Validate 意图，工作区默认取 PRD 所在目录（见 headless.md）。报告文件就落在这个目录里。

怎么读这份 findings 报告

HTML 报告（validation-report.html）头部会给出 PRD 名称、路径和总体评级。评级是文档中定义的映射，不是主观打分：

• Excellent：所有维度 strong/adequate，且无 high/critical findings；
• Good：至多 1 个 thin 维度，且无 critical findings；
• Fair：多个 thin 维度，或存在任意 high finding；
• Poor：任意 broken 维度，或存在任意 critical finding。

Markdown 孪生文件（validation-report.md）按严重度而不是维度分组，是文档明确标注的"canonical form for downstream re-reading"，后续复读建议看这份。它的结构固定为：Overall verdict（2–3 句综合判断）、Dimension verdicts（各维度结论）、Findings by severity（Critical/High/Medium/Low 四档，每条 finding 带标题、§ 位置、Note 和建议 Fix）、Mechanical notes（术语漂移、ID 连续性、断链等轻量问题）、Reviewer files（本次产出的各review-*.md列表）。

交互模式下，findings 不会一次性倾倒出来：先给一句 gate verdict，然后逐条过 critical 和 high，medium/low 收成一句"plus N more in {file}"收尾。对每条 finding 你可以选autofix、discuss、defer to open items 或 ignore。想看某条的完整上下文，再读对应的review-{slug}.md。

复跑校验与后续处理

• 复跑：重新跑一次 validate 会就地覆盖合并报告（validation-report.html/.md）；各个review-*.md单独保留，方便下钻。
• 收尾：validate 结束时 skill 会列出工件路径，并且总会提供把 findings 滚进一次 Update 的选项。如果你要真正按 findings 修改 PRD，下一步就是用 update 意图再跑一次bmad-prd——Update 会先把改动与 memlog 里既有决策的冲突摊出来，再应用。

可选分支：headless（非交互）校验

如果调用来自另一个 skill 或非交互 runner（无 TTY），bmad-prd按 headless 模式运行：第一条消息里给出intent: "validate"和prd.md的路径（或包含它的工作区路径），可选附 checklist 覆盖路径；工作区默认取 PRD 所在目录。差异有三点：

• 无论 findings 数量多少，validation-report.html和validation-report.md都会写出；
• 跳过打开浏览器，写完即返回；
• 以 JSON 状态收尾（完整 schema 见 assets/headless-schemas.md）：

{ "status": "complete", "intent": "validate", "validation_report": "{doc_workspace}/validation-report.md", "findings_summary": { "critical": 0, "high": 0, "medium": 0, "low": 0 }, "offer_to_update": true }

上面的数值是文档给出的示例形态，实际计数以本次运行为准。status的判定规则：rubric/checklist 加载失败等"产物生成了但留了缺口"的情况是partial（open_questions[]非空时也是）；意图无法推断时blocked并带reason，不会产生工件。

可选分支：换一套团队 rubric

默认 rubric 是assets/prd-validation-checklist.md，但bmad-prd的定制面允许覆盖。在团队级_bmad/custom/bmad-prd.toml或个人级_bmad/custom/bmad-prd.user.toml中把validation_checklist_template指向你自己的 rubric 文件即可（字段说明见 customize.toml）；HTML 骨架同样可用validation_report_template换成组织品牌版本。

边界与限制

• Validate 只批评不修改，也不跑 Finalize：memlog 审计、输入对账、polish、frontmatter 置status: final都不属于这个意图，那是 Create/Update 收口时的事。
• 报告评级和 findings 是文档定义的判断 rubric 的产出，severity 按"对 PRD 有用性的影响"排序，不是按修复成本排序；文档没有给出任何自动通过/失败的量化阈值，别把评级当成门禁数字用。
• 想让 findings 生效，路径只有两条：选 autofix/discuss 处理后通过 Update 意图回写 PRD，或把 deferred 项记入 memlog 留待复看（memlog.py append是 skill 内部机制，一般由它自己执行）。

【免费下载链接】BMAD-METHODBreakthrough Method for Agile Ai Driven Development项目地址: https://gitcode.com/gh_mirrors/bm/BMAD-METHOD