deepen

deepen — 让模块更深

行为至关重要：修改前后测试都必须通过。每次改动都要缩小接口或隐藏一项决策——让模块更深，而不是折腾代码。

深模块用小接口隐藏大量内容；浅模块的接口使用成本，和自己编写代码一样高。复杂度 = 依赖 + 晦涩，而且会层层累积。Deepen 会利用闲置时间降低复杂度，在它变成 §B 之前。当构建通过且有余裕可用时再运行——不要赶工期时运行。

何时使用 DEEPEN

• 构建通过、测试通过，且有剩余 token 预算。
• 某个模块的接口感觉和实现一样复杂（浅模块的迹象）。
• 同一项改动总是涉及许多文件（改动放大）。
• 用户明确要求提升设计质量。

⊥ 不要在功能开发中途或有压力时运行。Deepen 是有意为之的阶段，不是条件反射。

五个步骤

1. 选择浅模块

扫描规范涉及的模块。按浅程度排序——比较接口表面积与完成的工作量。选出最糟糕的一个。迹象：

• 只把调用转发给另一个方法的透传方法（浅层）。
• 调用方必须正确设置 5 个标志才能使用（配置泄漏）。
• 同一抽象在两层重复出现（没有信息隐藏）。
• 某个 ? 或 §B 可追溯到令人困惑的接口。

每轮只处理一个模块。加深要精准，⊥ 不是全面清扫代码库。

2. 诊断

用最直白的话指出设计缺陷，并引用文件:行号：

src/auth/token.go: 6-arg ctor 把轮换策略泄漏给每个调用方。太浅。 只有当复杂度确实表现出来时，它才是真实存在的：改动放大、认知负担过高，或未知中的未知（调用方必须知道某个隐藏事实才能正确调用）。

3. 研究如何加深

更深的版本是什么样？借鉴已知模式（外部案例交给 research → §R），或从代码库中更好的模块推导。能加深模块的做法：

• 把复杂度往下收——在内部隐藏难点，为调用方提供简单路径。
• 从设计上消除错误——设计接口，让边界情况无从发生。
• 信息隐藏——一项决策，一个模块；调用方无需了解这项决策。
• 采用通用接口，而不是堆砌特殊情况方法。

4. 提议

把改动起草为规范编辑，而非悄悄重写：

• 模块的新／更简单的 §I 形态。
• 用于锁定加深后不变量的 §V，防止未来构建时模块重新变浅。
• §T 重构条目，每条都引用它所服务的 §V/§I。 交由 spec 撰写。展示改动前后的接口，让用户看到缩减之处。

5. 验证行为未变

重构 ≠ 重写。开始前和结束后，完整测试套件都必须通过。改变行为的加深实为伪装成功能——停止，并通过 /spec + /build 处理。为新接口添加测试，证明旧调用方仍然可用。

何时停止

当选定模块的接口确实缩小、隐藏的决策不再泄漏、测试通过，且 §I/§V 记录了新的形态时，即可完成。加深一个模块，胜过折腾五个模块。若还有预算 → 另起一轮，选择下一个最浅的模块。

边界

• ⊥ 改变行为。修改前通过，修改后也通过。只改结构。
• ⊥ 编写 SPEC.md。提议 §I/§V/§T；由 spec 撰写。
• ⊥ 每轮加深多个模块。
• ⊥ 赶工期或功能开发中途运行。这是利用剩余预算的阶段。
• ⊥ 为只用一次的代码增加抽象。深模块值得隐藏；臆想出来的模块只会扩大表面积。