系列：破而后立的 TDD 流程迭代（第三篇） 第一篇：失之东隅，收之桑榆的实验 · 第二篇：以尺度尺，用方法改进方法
TL;DR： 阶段六已经在集成层做诊断——逐个 bug 追问根因。它不做的事是跨缺陷的模式扫描、组件缝隙检查、执行顺序分析。这些事归阶段七。小系统里阶段七多拦几个 bug；系统大了，同样是这三件事，产出变成建测试基础设施、硬化 CI 规则、驱动架构演进。阶段七不做架构决策，但它提供架构决策最稀缺的输入——基于证据的问题定位。
前两篇留下的线头
第一篇讲了 V0.8 实验——精炼阶段六没达到预期，但精炼版在全局视角上比原版强[1]。第二篇倒叙了 V0.7——阶段一到阶段五的精炼为什么成功[2]。
V0.7 成功，V0.8 失败。同一个策略，不同结果。区别在哪？
不是阶段六不够好
阶段六已经做到了原则驱动的集成缺陷诊断。
它追问的不是函数逻辑——是组件接线、配置传递、进程启动的交叉点。从"这个组件能独立启动吗"到"完整真实流程能走通吗"，逐层排除。每个 bug 追到底，找到根因，给出修复方案。这套方法在之前的系列文章里已经验证过了[3][4]。
阶段六的问题不是能力不足，是它的活动类型只有诊断个体缺陷这一种。
它擅长回答"这个 bug 的根因是什么"。它不回答另一些问题：“这 18 个 bug 里面有没有共同模式？““有没有从来没被检查过的组件缝隙？““验证链的执行顺序本身有没有设计缺陷？”
V0.8 精炼版之所以在全局视角上表现更好，恰恰是因为它没有被"逐个诊断"的节奏锚死——有余力去扫到跨 bug 的模式。但这个能力不应该通过"削弱阶段六的操作约束"来获得。阶段六的诊断精度依赖这些约束。
正确的做法是：阶段六不动，给它上面加一层做不同类型的事。
阶段七：上线前的系统性扫描
阶段七在阶段六完成后运行。它不做诊断——那是阶段六的事。它做的是阶段六不会做的事：扫描系统整体，找个体诊断发现不了的东西。
三件事，指向三个不同的方向
组件缝隙检查。 先枚举系统中所有交互的组件对——直接 API 调用、间接数据流、生命周期耦合、测试与生产的路径偏差。规则只有一条：如果系统中存在一对交互组件但不在你的清单上，那就是一个没被检查到的缝隙。系统小的时候补一个测试就行。系统大了，组件对数量是平方级增长的，手动补不过来——这意味着你的测试基础设施需要升级。
模式缺陷扫描。 从 18 个真实 bug 归纳出的缺陷模式目录，每条配 grep 命令。设计原则：系统化覆盖胜过直觉。grep 命令没找到什么比找到了什么更重要——它意味着这个模式在你的项目里不存在，可以放心移到下一个。如果同一个模式反复出现，说明不是个别 bug，是架构在鼓励这类缺陷——需要把模式硬化成 CI 规则或者改设计。
执行顺序分析。 多个验证阶段顺序执行时，前一个阶段的提前返回阻止了后一个阶段执行。具体案例：一组金融数据做中位数合理性检查，异常后提前 return，把所有股票标记为无效。下游的逐股检查永远不会执行——每个验证函数单独看都是对的，只有从执行顺序维度审视整个链才能看到问题。这不是 bug 修复能解决的，是架构层面需要重新设计验证链。
三个方向汇聚到一处
小系统，阶段七的发现是多拦几个 bug。系统变大了，同样是这三件事，产出的不再是 bug fix——是需要建测试基础设施、需要把模式变成 CI 规则、需要重新设计架构。
阶段七提供的不是结论，是证据。“为什么这 5 个 bug 共享同一个根因模式？““为什么这些组件对从来没被检查过？““为什么验证链的执行顺序有依赖？"——这些问题在系统小的时候不是问题，在系统大的时候指向的都是同一件事：当前架构不再匹配当前的复杂度。
架构演进最稀缺的输入不是技术愿景，是基于证据的问题定位。阶段七做的就是这个。
为什么和阶段六正交
阶段六是法医——擅长对单个死因做完整尸检报告。阶段七是流行病学家——看 18 个死亡之间有没有共同模式。不是升级法医的工具箱，是加一个不同职业。
深度与广度
| 阶段六 | 阶段七 | |
|---|---|---|
| 活动类型 | 诊断个体缺陷 | 系统性扫描 |
| 核心方法 | 追问（连续五层 + 证据链） | 扫描（模式目录 + grep） |
| 注意力方向 | 一个 bug 钻到底 | 整个项目过一遍 |
| 发现的问题类型 | 单个 bug 的根因 | 跨 bug 的共同模式、未覆盖的组件缝隙、执行顺序缺陷 |
| 产出导向 | bug fix | 建测试基础设施、硬化 CI 规则、或驱动架构演进 |
| 运行时机 | 预发布测试阶段 | 阶段六完成后 |
两层缺一不可。只有阶段六，每个 bug 都追到底了，但没人看 bug 之间的共同模式。只有阶段七，模式匹配找到了疑似问题，但没有追问链确认因果关系。
收尾
三篇文章，一条线：实验失败，失败暴露了信号，信号有了归宿。
一条规律浮出来：诊断个体缺陷做到极致之后，系统性扫描还能发现架构层面的压力点。 这些压力点在小系统里是 bug fix，在大系统里指向的是架构演进。阶段七不做架构决策，但它提供架构决策最稀缺的输入——基于证据的问题定位。
这个规律不只适用于 TDD Pipeline。任何"把局部诊断做到极致后遭遇瓶颈"的场景，都值得问一句：我是不是只在做个体诊断，从来没做过系统性扫描？
参考
- 失之东隅，收之桑榆的实验：tdd-pipeline-v08-failed-experiment-discovery
- 以尺度尺，用方法改进方法：tdd-pipeline-v07-refinement-experiment
- 测试全绿，系统不能用：18 个 bug 的六种死法：six-bug-patterns-and-integration-gaps
- 修不完的 bug 与逃不出的循环：AI 辅助根因诊断实战：ai-bug-root-cause-diagnosis
- AI 辅助 TDD 全流程：从需求到代码的完整防线：ai-tdd-full-pipeline-from-requirements-to-code