AI 技能人工智能开发工具【免费下载链接】BMAD-METHODBreakthrough Method for Agile Ai Driven Development项目地址https://gitcode.com/gh_mirrors/bm/BMAD-METHOD点击查看免费下载Deletion Check 是 BMAD-METHOD 开源仓库中bmad-build技能内置的代码审查机制作为 Edge Case Hunter 审查透镜review lens的次级通道secondary pass专门在 diff 删除了有意义代码时运行。本文从该机制的定位、触发条件、判断标准、JSON 输出契约到与 Claims Check 的配合关系结合仓库源码完整拆解其原理与实战用法帮助读者理解并复现这套删除即审查的回归防线。Deletion Check 在审查体系中的定位Deletion Check 不是独立运行的审查器而是 Edge Case Hunter 审查指令 中的Step 4。该指令将审查者定义为纯路径追踪者pure path tracer核心方法论是穷举路径枚举exhaustive path enumeration——机械地遍历每一条分支而非凭直觉狩猎。Edge Case Hunter 的执行序列被强制固定Step 1接收审查内容diff、完整文件或函数识别内容类型以确定作用域规则Step 2穷举路径分析——遍历所有分支路径与边界条件仅报告未被处理unhandled的路径Step 3完整性验证——重新审视所有边缘类别缺失 else/default、空输入、off-by-one、算术溢出、隐式类型转换、竞态、超时缺口等Step 4Deletion Check——仅当 diff 删除了有意义代码时加载并执行Step 5Claims Check——对照规格文档中的意图与验收声明逐条证伪Step 6以单个 JSON 数组输出全部发现从源码结构可以推断这套Step 4 Step 5的设计意图是形成互补的两道防线Edge Case pass 盯着新增/修改的代码缺了什么处理Deletion Check 盯着被删掉的代码带走了什么Claims Check 则盯着代码声称做到的事是否属实。三者共享同一个输出数组与四个标准字段便于后续统一分类triage。触发条件什么情况下才运行 Deletion CheckDeletion Check 指令 的第一句就划定了边界Secondary pass for the Edge Case Hunter — runs only when the diff removed meaningful code.即它只在 diff 删除或替换了有意义代码时运行并且明确排除两类假删除纯重命名pure renames仅改名不改行为不触发空白改动whitespace格式、缩进、换行等不携带语义不触发同时它的定位被明确标注为从属于边缘用例通道Subordinate to the edge-case pass发现通常很少或没有findings are usually few or none。这意味着 Deletion Check 不是要放大审查噪音而是在主通道之外补一个低成本、高针对性的检查删除往往意味着信息丢失而这种丢失恰恰是最容易被主通道忽略的。核心判断标准行为与契约的迁移审计Deletion Check 对每一块被删除或替换的代码排除重命名与空白后提出一个核心问题did it carry behavior or a contract that the change neither re-established nor intentionally retired?即这段被删的代码是否携带了某种行为behavior或契约contract而本次改动既没有重新建立它也没有有意地将其退役围绕这个问题指令给出了三类需要产生发现finding的结果回归regression删除导致原有功能失效或行为改变孤立引用orphaned reference删除后仍有关联方引用被删的符号、字段、接口或状态新死代码newly-dead code删除后某些代码成为永远不可达或永不生效的尸体同时明确要求去重跳过任何已被边缘用例发现覆盖的内容Skip anything already covered by your edge-case findings。这保证了主通道与次级通道的发现不重复计费最终数组中的每条记录都有唯一价值。输出契约统一的 JSON 数组与字段语义重映射Deletion Check 的发现追加append到与边缘用例发现相同的 JSON 数组中在 Edge Case Hunter 定义的四个标准字段之上再附加两个字段。四个标准字段在 Edge Case Hunter 输出格式 中定义location发现位置file:start-end单行为file:line无法精确到行时为file:hunktrigger_condition触发条件一句话描述最多 15 词guard_snippet关闭缺口的最小代码草图单行转义字符串不含裸换行或未转义引号potential_consequence可能实际发生的后果最多 15 词Deletion Check 附加的两个字段kind固定为deletion——用于区分同数组中的边缘用例发现与 Claims Check 的claim发现confidence取high、medium或low——因为删除审查本质上是推断inference指令明确要求为其评级对于删除类发现四个标准字段被重映射为专门语义字段删除发现的语义location被删除的条目the removed itemtrigger_condition被删代码原本强制保障的行为或契约guard_snippet在何处、以何种方式重新建立该行为/契约potential_consequence由此产生的回归或孤立引用以下是一个遵循该契约构造的示例字段语义据指令定义[{ location: src/auth/validator.ts:12-18 (removed), trigger_condition: Deleted pre-check rejected empty token before lookup, guard_snippet: if (!token) { return { error: empty token }; }, potential_consequence: Empty token now reaches DB lookup, causing 500s, kind: deletion, confidence: high }]指令同时强调如果没有符合条件的发现就什么都不加Add nothing if nothing qualifies——被删除的代码若其行为已被重新建立或有意退役则不产生发现空数组[]是合法输出。与 Claims Check 的配合删除审查的对偶通道Deletion Check 之后紧跟 Claims CheckStep 5两者形成对偶关系Deletion Check 审查失去的删除的代码带走了什么行为或契约改动方是否重新建立或有意退役Claims Check 审查声称的规格文档中## Intent与## Tasks Acceptance部分声明的可检查声明做什么、保留什么、顺序、算术、与现有代码的对等性逐条对照已追踪的代码尝试证伪Claims Check 有严格的防污染设计审查者直到 Step 5 才第一次读取 claims 文件路径追踪在 Steps 2–3 必须完成声明不能追溯性地影响路径分析并且规格是改动对自身的陈述是证词不是证据testimony, not evidence——代码注释里重复的声明仍是同一声明不算确认。两个通道的发现都追加到同一 JSON 数组分别以kind: deletion与kind: claim区分且都遵循无发现则不输出的原则。这保证了审查器在 Step 6 输出时数组中的每一条记录都对应一个真实、未重复、可被后续 triage 处理的问题。发现的下游处理Step 4 的分类路由Deletion Check 产生的发现不会直接决定代码的去留而是进入 bmad-build 的 Step 4 审查流程 的分类Classify阶段经过三层处理验证Verify在引用位置确认审查者描述的坏结果是否真实发生需沿调用链追查对每条发现必须给出唯一裁决high/medium/low真实缺陷并定级、false检查后不成立并写出反证、maybe-false无法判定并写出所需证据分组Group仅当同一缺陷同时产生多条发现时才归入同一条目位置相同或修复相同都不算共享根因路由Route每条目进入恰好一个分类——intent_gap意图捕获不完整、bad_spec规格缺陷、patch最小修复即解决、defer非本次改动引入的存量问题从该分类体系可以推断删除类发现的典型去向若删除导致回归且最小修复直接、无新增公共面则路由为patch若规格本应阻止该删除却未做到则路由为bad_spec触发回环loopback若属改动前就存在的存量问题则记入deferred-work.md延后处理。运行环境与启用方式Deletion Check 作为 bmad-build 技能的一部分通过技能入口 bmad-build/SKILL.md 启动uv run --no-cache {project-root}/_bmad/scripts/render_skill.py --project-root {project-root} --skill {skill-root}审查通道由workflow.review参数控制none、quick、thorough支持auto自动解析完整执行序列见 workflow.md 与 step-04-review.md只有走完整审查路径非none时才会铺开审查透镜Edge Case Hunter 及其 Deletion Check 子通道才会被激活。技能元数据见 module-manifest.toml当前版本 6.13.0-next。值得注意的是该指令并非 bmad-build 独有仓库中 bmad-build-auto/references/deletion-check.md 与 bmad-code-review/references/deletion-check.md 承载着完全相同的文本说明 Deletion Check 是 BMAD-METHOD 审查体系中的标准化通用组件被自动构建与独立代码审查两条路径复用。实践要点小结触发是条件性的只有删除/替换了有意义代码才运行纯重命名与空白改动直接跳过核心问题是契约审计被删代码是否携带未被重建或未被有意退役的行为/契约关注回归、孤立引用、新死代码三类后果与主通道去重已由边缘用例覆盖的内容不重复报告输出契约严格追加到同一 JSON 数组四个标准字段 kind: deletionconfidence三档评级字段语义按删除场景重映射下游分类闭环发现经验证、分组、路由进入intent_gap/bad_spec/patch/defer之一由审查流程统一裁决无发现即无输出空数组[]合法Deletion Check 不制造噪音这套设计把删除从审查盲区变成显式检查点行为与契约不会因为一行git diff中的减号而无声消失——要么被重新建立要么被有意退役要么被记录在案。赞分享AI 技能人工智能开发工具【免费下载链接】BMAD-METHODBreakthrough Method for Agile Ai Driven Development项目地址https://gitcode.com/gh_mirrors/bm/BMAD-METHOD点击查看免费下载相关推荐BMAD-METHOD 代码审查之 Deletion Check系统化捕获删除代码引发的回归、悬空引用与死代码BMAD METHOD 代码审查之 Deletion Check系统化捕获删除代码引发的回归、悬空引用与死代码 导读 Deletion Check删除检查AI 技能人工智能开发工具BMAD-METHOD 变更走查指南用 bmad-walkthrough 引导人工评审一次代码变更BMAD METHOD 变更走查指南用 bmad walkthrough 引导人工评审一次代码变更 在 BMAD METHODBreakthrough MeAI 技能人工智能开发工具BMAD-METHOD 变更走查bmad-walkthrough按理解顺序而非 diff 顺序审阅一次代码变更BMAD METHOD 变更走查bmad walkthrough按理解顺序而非 diff 顺序审阅一次代码变更 bmad walkthrough 是AI 技能人工智能开发工具创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考