从《Refactoring》到 Archon —— 翻译路径与工程落地
把 Martin Fowler 的《Refactoring: Improving the Design of Existing Code》（第 2 版，2018）放到 Archon 框架下评估，提炼可操作的工程纪律。
权威性说明：本文档记录完整的翻译过程（为什么 + 怎么做）。每条纪律的有效定义住在
soul.md—— 如本文档与 soul 冲突，以 soul 为准。
1. 为什么要审视这本书
《Refactoring》解决一个核心问题：如何在不改变外部行为的前提下持续改善内部结构。这件事在 AI 工程治理里同样重要 —— 但不能复制粘贴。Fowler 的语境是人类团队协作；Archon 的语境是基于会话的 AI 代理自主。下面是一条翻译路径，不是教材移植。
2. 概念速查
| 概念 | 一句话总结 |
|---|---|
| Refactoring | 在不改变外部行为的前提下，以小步改善内部结构 |
| Code Smells | 暗示更深结构问题的表面症状（22+ 类） |
| Two Hats（两顶帽子） | 任意时刻只做一件事：加特性或重构，永不并行 |
| Rule of Three（三次法则） | 第一次写出来；第二次容忍；第三次抽象 |
| Characterization Test（特征化测试） | 重构前先写测试钉住当前行为，再去碰结构 |
| Branch by Abstraction（抽象分支） | 大规模替换不停机 —— 新旧并存、渐进迁移、最后删掉旧版 |
| Refactoring Catalog | 每种 smell 对应一组命名技术，构成可复用的诊断查找表 |
3. 与 Archon 的关系
3.1 已经对齐（无须新动作）
Archon soul.md 里若干原则与 Fowler 天然重合，只是用了不同词汇：
| Fowler | Archon | 评估 |
|---|---|---|
| 消除死代码 | 死代码零容忍 | 完全对齐 |
| 单一职责 / 抽取类 | 一个文件一件事；膨胀就拆 | 对齐 |
| DRY / 消除重复 | 模式一致性 —— 一件事一种做法 | 对齐 |
| 测试作为安全网 | Validate gate（验证全绿） | 对齐 |
| 持续改进胜过大规模重写 | 漂移小步累积 + 演进机制 | 对齐 |
| 避免投机性抽象 | 精简 > 累积 | 对齐 |
| 命名即设计 | 命名就是设计 | 完全对齐 |
这些不是巧合。Fowler 从人类团队协作中提炼；Archon 从 AI 代理自主治理推导。两者抵达同一片工程基岩。
3.2 缺口（已采纳并落地）
下列五项 Fowler 中有、Archon 中缺。五项如今都写入了 soul/delivery.md：
| # | 缺口 | Fowler 原文 | Archon 适配 | 落地位置 |
|---|---|---|---|---|
| 1 | 两顶帽子 | 不混合特性与重构 | 先发特性那次交付，再做一次重构交付 —— 分开提交 | soul/delivery.md §产品质量 |
| 2 | 三次法则 | 第三次重复时再抽象 | 避免过早泛化；两次重复不是抽象触发 | soul/delivery.md §产品质量 |
| 3 | 渐进替换 | Branch by Abstraction | 新旧共存；分步迁移；不做停机重写 | soul/delivery.md §产品质量 |
| 4 | 节奏克制 | 临近 deadline 不重构 | 里程碑特性未完成时，把 smell 记为债务；不就地修 | soul/delivery.md §产品质量 |
| 5 | 特征化测试 | 重构前先写 Characterization Test | 重构既有模块前，先加固定当前行为的测试 | soul/delivery.md §新代码 = 新护栏 |
3.3 显式拒绝
| 候选 | 拒绝理由 | 引用的 Archon 原则 |
|---|---|---|
| 强制 TDD | Fowler 推荐测试先行，但 Archon 代理自己选最优执行路径。强制会牺牲灵活性；validate gate 已守住质量底线 | 所有权（代理判断自己的路径） |
| 独立的重构 Catalog 文档 | 22 类通用 smell 是教材内容，不是项目知识。需要时翻书；不值得维护副本 | 精简 > 累积 |
| 专门的重构 skill 文件 | 目前没有累积的项目特异 smell 模式。空壳 skill 违反"创建即守护" | 知识卫生 |
| 重构计划文档模板 | 每次重构产生一份计划文件 = 治理膨胀。两顶帽子 + validate gate 已足够 | 精简 > 累积 |
4. 适配思路：人类纪律 → AI 机制
Fowler 的重构纪律依赖自律、code review、团队文化。Archon 的风险面不同：AI 代理不会像人那样"忘记规则"，但它会丢失上下文并跨会话发生认知漂移。因此适配目标是把人类的行为纪律翻译成 AI 的结构性约束：
| 人类（Fowler） | AI（Archon） | 翻译 |
|---|---|---|
| "记得别混合特性与重构" | 两顶帽子写入 soul/delivery.md → 每次交付自动加载 | 行为纪律 → 认知预载 |
| "Code Review 抓 smell" | 推理胶囊嵌入 skill → 症状直映射到修复 | 团队评审 → 自演进知识 |
| "第三次重复时重构" | 三次法则写入 soul/delivery.md → 决策锚点 | 经验法则 → 决策原语 |
| "重构前先写测试" | 特征化测试写入「新代码 = 新护栏」→ 接到 validate gate | 最佳实践 → 结构性守护 |
| "大重构分阶段" | 渐进替换写入 soul/delivery.md → 与漂移小步累积对齐 | 项目管理技巧 → 工程原则 |
关键洞察：人类需要记住原则；AI 需要把原则装进上下文。Archon 的 soul（核心 + 模式加载的扩展）每次 boot 按需读取；写入 soul 等于写入代理的工作记忆。
5. Code Smell 在 AI 编码中的角色
Fowler 的 22 个 Code Smell 是给人用的诊断清单。对 AI 代理而言，价值不在"背诵"它们，而在建立 smell → 重构 的快速决策路径。
Archon 的处理策略：
- 不预存通用 Catalog —— 22 个 smell 是 AI 已有的书本知识
- 累积项目特异映射 —— 同一个 smell 在本项目第二次出现时，作为推理胶囊（症状 → 根因 → 修复）嵌入对应 skill
- 从诊断到自动化 —— 如果某个 smell 能用 lint 规则检测，就提升到 L1（沿约束金字塔上移）；比文档更可靠
这与 soul 的结晶路径优先级一致：lint 能抓的就别写散文；推理胶囊能装的就别建专属文件。
6. 采纳后的完整质量卫生图
| 原则 | 来源 | 强制方式 |
|---|---|---|
| 命名即设计 | 原生 | 认知预载 |
| 单一职责 | 原生 / 与 Fowler 对齐 | 认知预载 |
| 死代码零容忍 | 原生 / 与 Fowler 对齐 | 认知预载 |
| 类型即文档 | 原生 | L0 编译约束 |
| 模式一致性 | 原生 / 与 Fowler 对齐 | 认知预载 |
| 架构边界 | 原生 | L1 lint 约束 |
| 不留 TODO | 原生 | 认知预载 |
| 两顶帽子 | 采自 Fowler | 认知预载 + commit 可审计 |
| 三次法则 | 采自 Fowler | 认知预载（决策锚点） |
| 渐进替换 | 采自 Fowler | 认知预载 + 与漂移联动 |
| 节奏克制 | 采自 Fowler | 认知预载 + 与债务联动 |
| 特征化测试（新护栏） | 采自 Fowler | L2 测试约束 |
7. 未来演进方向
下列尚未落地，但日后可能触发演进：
| 触发信号 | 行动 |
|---|---|
| 同一 smell 在项目里第 3 次出现 | 写一颗推理胶囊并嵌入对应 skill |
| 某个 smell 变得能被静态分析检测 | 写一条自定义 lint 规则；把约束从 L3 提到 L1 |
| 里程碑要迁移关键基础设施 | 用渐进替换（Branch by Abstraction）执行 |
| 页面层重构（目前缺测试） | 先加特征化测试，再碰结构 |