企业官网建设流程全解析

BMAD-METHOD 细节走查（Detail Pass）：以爆炸半径排序的变更风险审查与定向复审指南

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

Detail Pass 是bmad-walkthrough五步人类审查工作流中的第三环，其任务不是再查一遍代码正确性，而是把"哪些地方错了代价最大"（blast radius）呈现在人眼前，激活风险意识。读完本文，你将掌握 BMAD-METHOD 中细节走查的完整规则：如何按风险类别扫描 diff、如何按爆炸半径而非复杂度排序输出风险点、如何透传 Spec Change Log 中的机器加固发现，以及如何通过 "dig into [area]" 触发面向正确性的定向复审。

Detail Pass 在五步审查链中的位置

bmad-walkthrough是一个面向人类审查（human review）的技能：它把一个 diff 按"利于理解的顺序"而非git diff的字母序呈现给人类，帮助人在批准变更前真正看懂它。该技能在 docs/build/walk-through-a-change.md 中有专门的使用说明，并在仓库中以五个顺序步骤文件实现：

Orientation → Walkthrough → [Detail Pass] → Testing → Wrap-Up

• step-01-orientation.md：定位变更（PR / commit / branch / spec / 当前 git 状态），输出意图摘要与影响面统计；
• step-02-walkthrough.md：按**关注点（concern）**组织变更，激活设计判断；
• step-03-detail-pass.md（本文主题）：扫描风险点，激活风险意识；
• step-04-testing.md：给出可观察行为的验证建议，强调"亲眼看"而非"再分析"；
• step-05-wrapup.md：让人对 Approve / Rework / Discuss 做出最终决定。

步骤文件的执行由 workflow.md 驱动：它要求按顺序读取步骤文件，"如果某步骤指示读取另一个快照文件，必须完整读取并遵循，无例外"。而技能本身通过 SKILL.md 中的render_skill.py渲染命令激活——触发语如 "walkthrough"、"walk me through this change"、"human review" 即会运行该技能。

从源码结构看，Detail Pass 的设计意图十分清晰：机器加固（如对抗性审查循环）已经保证了正确性，这一步不再重复机器的工作，而是回答"人应该思考什么"。这种分工在相邻步骤中也保持一致——step-02 激活设计判断，step-04 走向亲身体验，step-03 则专门负责风险意识。

IDENTIFY RISK SPOTS：扫描爆炸半径最高的 2–5 个风险点

细节走查的第一步是扫描 diff，找出触及"风险敏感模式"的改动。关键约束是：找的不是最复杂的代码，而是出错时代价最大的代码——path:line位置应选取 2–5 个，一个错误若发生在此处，会造成最大范围的破坏（how much breaks if this is wrong）。

八类风险标签

原文档规定了以下风险类别标签，扫描时按模式匹配（pattern）识别：

其中[other]是兜底类别，文档明确要求使用"描述性标签"（如[concurrency]、[privacy]），而不是笼统贴一个 other 了事。

排序规则：爆炸半径优先

• 按爆炸半径从大到小排序（path:line列表的第一个风险点应是"错了影响最大"的那个），而不是按 diff 顺序或文件顺序；
• 排序只是为了可读性，不要给风险点分配严重度分数或数值排名——LLM 负责按模式识别风险类别，人类负责判断其重要性；
• 若符合条件的位置超过 5 个，只展示前 5 个，并注明：

  "N additional spots omitted — ask if you want the full list."

• 若整个 diff 没有任何命中这些模式的位置，必须明确说出：

  "No high-risk spots found in this change — the diff speaks for itself."

• 严禁强行制造发现（Do not force findings）。

这一"类别识别与重要度判断分离"的机制，与 docs/build/walk-through-a-change.md 中对工作流"呈现给人看、由人决策"的定位一致：机器模式匹配，人做价值判断。

SURFACE MACHINE HARDENING FINDINGS：透传对抗性审查的决策记录

第二步检查 spec 中是否包含## Spec Change Log小节——该小节由**对抗性审查循环（adversarial review loops）**在构建过程中填充，记录机器在实现阶段发现并处置过的问题。

处理规则：

• 如果存在条目：通读它们，只呈现对人类审查者有指导意义的发现——不是那些已被修复的 bug（那无需人类再操心），而是审查循环标记过的、人类应当知晓的决策（what was flagged and what was decided），格式为"被标记事项的简要总结 + 最终决定"；
• 如果不存在条目，或根本没有 spec：整体跳过本节，完全不提及它（Do not mention it）。

这条规则保证了机器与人的分工清晰：机器加固阶段的产物不会变成对人类的噪音，只有那些影响后续决策的信息才被透传。

PRESENT：单条消息呈现风险点与收尾菜单

细节走查要求将全部输出组织为一条完整消息，并以面包屑导航开头：

Orientation → Walkthrough → [Detail Pass] → Testing

Risk Spots 小节

每个风险点一行，采用path:line引用格式（全工作流的全局规则要求在可点击环境中以可点击形式呈现所有file:line引用，终端中则使用 CWD 相对的path:line）：

- `src/auth/middleware.ts:42` — [auth] New token validation bypasses rate limiter - `migrations/003_add_index.sql:7` — [schema] Index on high-write table, check lock behavior - `api/routes/billing.ts:118` — [billing] Metering calculation changed, verify idempotency

每一行的结构为：路径:行号—[标签] 原因短语。原因短语应当直接说明"为什么这里风险高"（如绕过限流、检查锁行为、验证幂等性），让人类一眼就知道该思考什么。

Machine Hardening 小节（仅当存在发现时）

若 Spec Change Log 有值得呈现的条目，则追加：

### Machine Hardening - Finding summary — what was flagged, what was decided - ...

Closing menu

消息以固定的收尾菜单结束，给出后续动作选项：

--- You've seen the design and the risk landscape. From here: - **"dig into [area]"** — I'll deep-dive that specific area with correctness focus - **"next"** — I'll suggest how to observe the behavior

两个出口分别对应：进入下面的定向复审，或推进到 step-04-testing.md 的"如何亲眼看到行为"。

EARLY EXIT：随时把决定权交还人类

如果人类在任何时刻表示想要对这个变更做决定——例如 "let's ship it"、"this needs a rethink"、"I'm done reviewing"，或任何表明已准备好决策的表述——审查助手必须确认其意图：

• 想approve and ship（批准并上线）→ 完整读取并遵循 step-05-wrapup.md；
• 想reject and rework（拒绝并返工）→ 同样读取并遵循 step-05-wrapup.md；
• 若误读了对方的意图 → 承认并继续当前步骤。

这与 step-05 的决策提示（Approve / Rework / Discuss）形成闭环：Detail Pass 不是强制走完全程的流水线，而是一旦人做出判断，立即转入收尾步骤，避免无意义的继续审查。

TARGETED RE-REVIEW：用 "dig into [area]" 触发正确性深潜

当人类说出"dig into [area]"（如 "dig into the auth changes"、"dig into the schema migration"）时，进入定向复审流程，共七步：

1. 校验目标：若指定区域与 diff 中的任何代码都不对应，明确说明 "I don't see [area] in this change — did you mean something else?"，然后回到收尾菜单；
2. 定位代码：找出 diff 中与该区域相关的所有代码位置；
3. 完整上下文阅读：每个位置都要读完整上下文，而不仅是 diff 块（hunk）——周围代码才能揭示意图；
4. 切换正确性模式：追踪边界情况、检查边界条件、验证错误处理，查找 off-by-one 错误、竞态条件、资源泄漏；
5. 紧凑呈现：每一条发现为path:line+ 发现了什么 + 为什么重要；
6. 无发现时明确说明："Looked closely at [area] — nothing concerning. The implementation is solid."
7. 只展示收尾菜单（不再重复完整风险点列表）。

人类可以多次触发定向复审，每次只呈现新发现与收尾菜单。

注意这一步与 step-02 的对比：Walkthrough 阶段按关注点组织、激活设计判断（"这样做对吗？"）；而 Detail Pass 的定向复审切换到正确性模式（correctness mode），关注的是边界条件与错误路径——这正是 step-02-walkthrough.md 明确"不做正确性检查"之后，唯一承担正确性深潜职责的环节。若没有现成的 Suggested Review Order，step-01 会回退到 references/generate-trail.md 生成审查路线，同样使用path:line停靠点格式，为后续步骤（含本步）提供锚点。

与 Testing 步骤的衔接

Detail Pass 的收尾菜单中，"next" 指向 step-04-testing.md。该步骤与细节走查形成互补：

• Detail Pass 问的是 "did you think about X?"（你想到 X 了吗）；
• Testing 说的是 "you could see X with your own eyes"（你可以亲眼看到 X）。

它强调体验性而非分析性，不重复 CI 与自动化测试的工作，只针对 UI 变化、CLI/终端输出、API 响应、状态变化、错误路径五类可观察行为给出"做什么（Do）/ 期望什么（Expect）"的建议。这与 Detail Pass"机器已处理正确性、人类负责思考与判断"的整体哲学一脉相承。

细节走查全流程速览

以下为 Detail Pass 的完整执行路径，可直接作为复现清单使用：

1. 面包屑：Orientation → Walkthrough → [Detail Pass] → Testing；
2. 扫描 diff，按八类标签识别 2–5 个爆炸半径最高的风险点，无风险则明说，不强行制造发现；
3. 检查 spec 的## Spec Change Log，有则透传有指导意义的机器加固决策，无则整节跳过；
4. 单条消息呈现 Risk Spots（path:line—[tag]reason-phrase）、Machine Hardening（如适用）、Closing menu；
5. 收到 "dig into [area]" 则执行七步定向复审并只回收尾菜单；
6. 收到 "next" 则进入 step-04-testing.md；
7. 人类任何时刻表达决策意图，则转入 step-05-wrapup.md 完成 Approve / Rework / Discuss 闭环。

这一流程在 docs-site/src/diagrams/walkthrough-run.svg 中也有可视化表达：从 bmad-build 产物（spec 文件 / PR / commit / branch）出发，依次经过 Orientation、Walkthrough、Detail Pass（标注 "Highest blast radius first" 与 "dig into [area] for a deep dive"）、Testing，直至 Wrap-Up 的 Approve / Rework / Discuss，并在任一步骤支持 early exit。从源码结构可以推断，这种"五步推进 + 随时可提前退出 + 定向深潜"的设计，保证了机器审查的效率与人类决策的主动权并存：机器负责铺开全貌与排序，人类永远掌握"何时停止、深挖哪里、最终怎么定"的控制权。

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