Appearance
技术雷达与技术债管理
定位：架构方法论深化系列之三。技术选型没有"对错"，只有"当前环位"；技术债不是耻辱，是没被管理的利率。这篇整理技术雷达四环与共识流程、技术债四象限、还债排期策略。以及"债不还、利息复利"的量化表达。
技术雷达四环
团队需要一个共同的"当前技术观"，否则每个人按个人偏好选型，栈越铺越散。雷达四环：
╭──────────────────────────╮
│ 采用(Adopt) <- 稳态 │ 默认选它，新项目不再讨论
│ ╭──────────────────╮ │
│ │ 评估(Trial) │ │ 允许试点，限定 1-2 个非核心场景
│ │ ╭──────────╮ │ │
│ │ │ 持有 │ │ │ 可用但不再新增，存量维护
│ │ │ (Hold) │ │ │
│ │ ╰──────────╯ │ │
│ ╰──────────────────╯ │
│ 淘汰(Retire) -> 退出 │ 有下线时间表，禁止新代码引入
╰──────────────────────────╯
生命周期：评估 -> 采用 -> (最终)持有 -> 淘汰
跳环必须走共识流程，不允许"私自从评估当采用"| 环位 | 含义 | 新项目 | 存量系统 |
|---|---|---|---|
| 采用 | 团队验证过、有运维能力 | 默认选型 | 迁移目标 |
| 评估 | 业界成熟但团队无经验 | 仅限非核心试点，设观察期 | 不动 |
| 持有 | 能用但已非最优 | 禁止新用 | 不主动迁，改到即还债 |
| 淘汰 | 有明确缺陷或停维护 | 禁止 | 有退出时间表 |
团队共识流程
雷达是共识的载体，不是架构师的私人歌单。最小流程：
1. 提案：任何人发起，一段话写清"解决什么问题、与在位者对比、退出成本"
2. 评审：季度雷达会，按"采用/评估"的准入证据逐条过（性能数据、社区活跃度、团队学习成本）
3. 公示：结论进雷达 + 决策理由落 ADR（见《技术决策与ADR》），后人可追溯为何进出
4. 复审：每季度重扫一遍——技术债的"持有"环最容易被遗忘，没有复审就没有退出两条纪律：同一问题域"采用"环最多两个候选（一主一备），多了就是没有共识。进"淘汰"环必须带下线时间表，没有时间表的淘汰等于没淘汰。
另外两个实操要点：
- 进"评估"环的门槛是有真实业务场景且有人愿意背它的运维，而不是"业界很火"。雷达评的是"我们团队能用好什么"。
- 环位迁移要有证据链：评估升采用附试点数据，持有降淘汰附故障/维护成本记录，证据随 ADR 存档。
技术债四象限
技术债是"当时用更低的成本换到了交付速度，未来要连本带息还回"的决策。按鲁棒性 × 可见性分四象限：
| 明显（deliberate，知道且选择） | 隐蔽（inadvertent，没意识到） | |
|---|---|---|
| 轻率（reckless） | "没时间设计，先上线再说" | "分层是什么？直接全写在 Controller 里" |
| 谨慎（prudent） | "先出 MVP 验证市场，知道还款日会来" | "当时以为这样解耦就够了（现在才知道不够）" |
- 右列比左列危险：看得见的债顶多是贵，看不见的债会复利——没人记账，每次变更都在无声支付利息。
- 谨慎且明显是健康负债（经营性贷款）；轻率且隐蔽是系统性风险。治理动作的优先级是：先把右列的债"显性化"（识别、记账），再谈还。
债的利息与复利：量化表达
利息不用玄学描述，可以写成算式：
单次利息 i = 额外理解成本 + 额外改动成本 + 风险抬升
≈ 新人读懂这段烂代码多花的天数
+ 改一处要同步改 N 处的扩散成本
+ 该模块的线上故障率增量
某债务点的年化利息 I = i × 年变更次数 f <-- 变更越频繁的地方，债越贵复利效应：利息会抬升后续每次变更的成本，变更成本上升又降低"顺手还债"的概率。于是下期本金更大：
第1年真实成本：C
第2年：C × (1 + r) r = 该债务点年化利息率
第3年：C × (1 + r)^2
...
第n年：C × (1 + r)^(n-1)
例：一处热点代码的 r = 20%（很常见的量级），每年变更 12 次：
拖 1 年还：多付 12 × C × 20% <- 可接受，这是"谨慎负债"
拖 3 年还：多付约 12 × C × 73% <- 开始肉疼
拖 5 年还：多付约 12 × C × 149% <- 利息超过本金，还债窗口关闭
-> 只剩"重写论证"一条路结论落在两个排序原则上：
- 还债优先级 = 利息 ÷ 还债成本，不是"哪块最烂还哪块"。角落里烂但没人动的代码，利息趋近于零，可以永远躺着。
- 热点优先：变更频率 f 最大的模块，即使烂得不严重也优先治理，因为它的 I 最大。
利息的估算靠账本，最小字段就五个，别做成流程负担：
债务账本（一条 = 一个债务点）
- 位置：模块/文件（能定位到人负责的范围，边界与团队对齐见《康威定律与团队拓扑》）
- 类型：四象限里的哪一格
- 年变更次数 f：从代码库提交记录直接统计，不拍脑袋
- 单次额外成本 i：最近一次在此处变更的额外耗时（评审/联调/修回归多花的部分）
- 还债方案与预估成本：一句话方案 + 人日
=> 优先级分 = (f × i) / 还债成本，季度重算一次还债排期策略
| 策略 | 做法 | 适合 | 失效形态 |
|---|---|---|---|
| 固定比例 | 每迭代预留 20% 容量专项还债 | 债务面广、团队稳定 | 业务冲刺期被"借用"，借用无归还机制 |
| 随迭代（童子军军规） | 改到哪顺手还到哪，留比来时干净 | 热点分散、债务点小 | 只还路过的，没人路过的债永生 |
| 专项治理 | 季度性立项，集中攻坚一个主题 | 集中在某主题的大债（如升框架） | 专项结束无人维护，回潮 |
组合用法更贴近现实：固定比例兜底 + 军规处理日常 + 大头走专项。无论哪种，还债项要和业务需求同列一个 backlog、同样验收——不进排期的还债叫许愿。
实践清单
选型侧
[ ] 团队雷达是否每季度复审并公示？淘汰环是否都有下线时间表？
[ ] 新引入的技术是否都在"采用/评估"环内，有 ADR 记录理由？
[ ] 同一问题域的默认选型是否唯一（最多一主一备）？
债务侧
[ ] 债务是否有账本：位置、利息要素（理解/扩散/故障）、变更频率？
[ ] 热点模块（变更最频繁）的债务是否排在了最前面？
[ ] 隐蔽象限的债是否在做显性化（CR 中识别烂味道并记账）？
[ ] 每迭代是否有固定还债容量？被借用后有无归还机制？
[ ] 改动范围大的还债是否拆成了可独立上线的小步（见《演进式架构与适应度函数》）？与库内其他篇的关系
- 债务治理的评审入口在 CR：烂味道的识别与分级见《CR的技巧》。
- 还债常涉及框架/协议升级，兼容性检查见《系统设计如何全方位考虑兼容性问题》。
- 债务清理后的新代码如何防止回潮，靠 CI 里的适应度函数见《演进式架构与适应度函数》。
一句话总结
选型用雷达管共识，进出留 ADR；技术债先显性化再按"利息÷成本"排优先级，热点优先。还债走"固定比例兜底 + 军规日常 + 专项攻坚"这套组合措施——债不可怕，可怕的是没有账本和利率。
2026-10 新增（架构方法论深化系列）。