技术债务管理：识别、量化、偿还与预防——从一句会议室比喻到 AI 时代的四环节闭环 未开始

题记与说明

时间截面：2026-11-05
视角约束：单人长周期项目（bus factor = 1、生命周期以十年计、无团队、运维与采购预算趋近于零）
研究方法：本文由同课题两份章节研究综合而成——纵轴章节（16 轮网络检索 + 3 次一手网页读取：Cunningham 1992 OOPSLA 原文、Fowler 两篇 bliki 原文）与横轴章节（WebSearch × 9 + WebFetch × 2，含 1 次 WebFetch 全文验证的中立对比页）。两章中已标注"（待核）"的个别时间点，本稿保留该标注；厂商口径数字均明确标记；关键事实均附来源 URL。综合时对两章之间的三处出入做了调和，记录见 3.5 节。本稿为终稿：已按独立审读意见（2026-11-05，共 8 条）逐条修订，修订与来源核验方式见文末终稿说明。

TL;DR

技术债务从 1992 年 Cunningham 向老板解释"为什么必须回头改代码"的比喻起步，到 2026 年已是一门有旗舰会议、专著与工具生态的学科，34 年经历六个阶段。每代工具的共同方向是缩短"现在省时"与"未来付息"的结算周期；而 AI 让两个方向首次同时运动——偿还被配方引擎加速，产生被无人理解的生成代码放大。2026 年横向格局：识别、量化、偿还、预防各有专精方案，无一覆盖四环。对单人长周期项目：识别靠开源 CLI 加自算 git 热点；量化降级为"修复分钟数 + 热点标记 + 直觉分"三档（全文统一定义见 3.4 节），四象限只作定性底色；偿还押注配方引擎与 AI 代理、以 Strangler Fig 为默认姿势；预防本地化为提交钩子与带护栏的童子军规则。全部组件免费可得，价值在粘合成单人可持续的闭环。

一、纵轴：发展脉络（1992–2026）

1.1 主线：一条"从比喻到学科，再回到个人"的弧线

技术债务的研究对象，是那些为了短期速度而欠下的、未来必须连本带息偿还的软件内部质量亏欠。这条线经历了六个阶段：隐喻诞生（1992–2002）→ 概念显性化（2003–2009）→ 学术建制化（2010–2016）与产业量化工具化（2010–2018）两条线并行推进 → 会议与专著建制、偿还方法论成熟（2018–2021）→ AI 时代（2022–2026）。贯穿 34 年的驱动因素只有一个：软件的生命周期越来越长、维护者越来越换手，而"省下的设计成本"始终会以利息形式出现。

值得先立住的一个事实：这个如今被大公司拿来做百万美元预算论证的概念，最初诞生在一个小团队向老板解释"为什么必须回头改代码"的沟通场景里。它从未离开过"个人/小团队如何与未来的自己打交道"这个原初语境——单人长周期视角因此不是外挂，而是本课题的源代码。

1.2 阶段一：隐喻诞生期——WyCash 与"未偿还的债"（1992–2002）

1992 年，Ward Cunningham（当时在 Wyatt Software）在 OOPSLA '92 经验报告《The WyCash Portfolio Management System》中首次使用债务隐喻。原文的关键句："Shipping first time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite."（首次交付的代码就像举债，只要及时用重写偿还，少量债务反而加速开发。）以及"The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt."（不偿还时危险降临——在"不太对"的代码上花的每一分钟都是利息。）一手原文见 c2.com/doc/oopsla92.html。Cunningham 后来回顾：这个隐喻是他读了《Metaphors We Live By》之后，为了向不懂技术的老板解释"为什么要花时间重构 WyCash 报表引擎"而发明的（见 wiki.c2.com DebtMetaphor、Wikipedia: Technical debt）。本文标题所说的"一句会议室比喻"，指的就是这个场景：一个工程师面对决策者，用债务解释"为什么必须花时间回头改代码"——这个为会议室沟通而生的修辞，此后长成了整个学科。

背景节点：WyCASH+ 是 Smalltalk 实现的债券组合管理系统，团队靠增量生长维护约 4MB 代码，"成熟一段就回头合并设计（consolidate）"来控制债务——隐喻诞生时的语境是一个难以扩编的小团队，不是大厂。1995 年前后，Cunningham 与 Bo Leuf 创建世界上第一个 Wiki（WikiWikiWeb，c2.com），此后二十余年"技术债务"的社区讨论一直以这个 Wiki 为母港（wiki.c2.com/?TechnicalDebt）。（Wiki 创建年份待核，凭既有知识。）1999 年，Martin Fowler 出版《重构：改善既有代码的设计》，敏捷/XP 体系把"重构"从英雄行为变成日常动作——债务隐喻有了配套的偿还工具。（待核，凭既有知识。）

单人视角：技术债务这个概念从第一天起就是一个人（或几个人）与未来的自己签的合同。"利息"支付给谁？支付给两年后忘了当初为什么这么写的那个人。单人长周期项目的债务问题因此比大团队更纯粹：没有交接文档，没有新人背锅，欠债者与还债者完全同一。

1.3 阶段二：概念显性化——Fowler 定义与四象限（2003–2009）

2003 年 10 月 1 日，Martin Fowler 发表 bliki《TechnicalDebt》，首次系统化定义：用金融债务来思考内部质量的亏欠。该条目 2019 年 4 月重写、5 月更新，至今仍是引用最多的入门定义（一手读取确认：原文自述"first published it on October 1, 2003 and rewrote it in April 2019"；martinfowler.com/bliki/TechnicalDebt.html）。

2009 年 10 月 14 日，Fowler 发表 bliki《TechnicalDebtQuadrant》，提出著名的 2×2 四象限：故意+鲁莽（"我们没时间做设计"）、故意+审慎（"先上线再说"）、无意+鲁莽（"什么是分层？"——即 Uncle Bob 所说"a mess is not a debt"的那类烂泥）、无意+审慎（做完才知道当初该怎么设计——连优秀团队也无法避免）。一手读取确认发布日期与四象限原文（martinfowler.com/bliki/TechnicalDebtQuadrant.html）。其中 Uncle Bob 的原帖是 Robert C. Martin 的《A Mess is not a Technical Debt》（2009-09-22，名句"A mess is not a technical debt. A mess is just a mess."，Fowler 四象限原文即链接此文；现存档见 sites.google.com/site/unclebobconsultingllc）。同年，Cunningham 本人对隐喻做官方澄清：在 OOPSLA 原文页面加 2009 年后记并发布五分钟视频（转录见 c2.com DebtMetaphor），纠正社区把"债务"等同于"烂代码"的误读——他强调隐喻本意是为重构辩护，而不是给偷懒发许可证。

驱动因素：2001 年敏捷宣言后，敏捷实践落地近十年，团队普遍学会了"快"，但向管理层解释"为什么还要投入时间做看不见的质量"缺一个修辞工具；四象限恰好把债务从"道德问题"变成"决策问题"。

单人视角：四象限里最被忽视、却对单人长周期项目最致命的是第四象限（无意+审慎）——昨天的最佳实践被今天的认知超越，本身就是债。单人项目没有"设计评审会"来对冲认知演进，十年里语言版本、框架范式、自己对领域的理解全都换了几轮，第五年的你会持续为第一年的你付利息。这也解释了为什么单人维护者的主要偿还动作常常不是"修 bug"，而是"按新认知重做旧设计"。四象限在单人场景还有一个特殊用途：没有人评审你的决策，它是防止自我合理化的自省框架（详见横轴 2.2 节梯队 D）。

1.4 阶段三与阶段四（并行推进）：学术建制化 + 产业量化（2010–2018）

这两条线时间重叠、角色分工：学界负责把隐喻变成可理论化的对象，产业界负责把债务折算成钱和天。

学术线（2010–2016）：

• 2010 年，首届 "Managing Technical Debt"（MTD）国际工作坊在 ICSE 2010（开普敦）举办；2011 年第二届在檀香山召开，目标是把技术债务纳入软件工程研究议程（第二届报告见 ACM DL）。
• 2012 年 11–12 月，IEEE Software 出版技术债务专刊（vol. 29, no. 6），头条社论即 Kruchten、Nord、Ozkaya 的《Technical Debt: From Metaphor to Theory and Practice》（DOI 10.1109/MS.2012.167；SEI 页面）。标题本身宣告了阶段使命：让隐喻变成可理论化、可实践的东西。同期 SEI 线的"技术债务全景图"由 Nord、Bellomo、Kruchten、Ozkaya 等在 MTD 2012 上梳理成型（SEI 工作坊报告页）。
• 2012 年，微软研究院发布《Towards a Taxonomy of Technical Debt》（MSR-TR-2012-77，Kim/Zimmermann/Nagappan），给出代码债、设计债、架构债、测试债、基础设施债、文档债、需求债等类型学；后续实证研究被广泛转引为"至少 30% 的技术债务与代码债相关"（Microsoft Research 出版页；30% 数字经二手系统综述转引，待核原始页）。
• 2013 年，Kruchten 等发表《Technical Debt: Towards a Crisper Definition》（DTIC PDF），试图给出更严格定义、与"烂代码"划清界限。
• 2014 年，两个里程碑同年出现：Potdar 与 Shihab 在 ICSME 2014 提出自认技术债务（Self-Admitted Technical Debt, SATD）——开发者自己在注释里承认欠债（TODO/HACK），手动分析四个开源项目发现多达 31% 的文件含 SATD，且 SATD 文件更易变更、更易出缺陷（DOI 10.1109/ICSME.2014.31）；Alves 等人在 MTD 2014 发表术语本体（DOI 10.1109/MTD.2014.9）。
• 2016 年 4 月，Dagstuhl 研讨会 16162《Managing Technical Debt in Software Engineering》召开，产出共同定义、概念模型与研究议程（dagstuhl.de/16162；报告 DOI 10.4230/DagRep.6.4.110）。同年 Alves 等人的系统性映射研究发表于 Information and Software Technology（第 70 卷，pp. 100–121，《Identification and management of technical debt: A systematic mapping study》，ScienceDirect；DOI 10.1016/j.infsof.2015.10.008），确认文献已具规模。

产业线（2010–2018）：

• 2010 年前后，Jean-Louis Letouzey 在咨询公司 Inspearit 提出 SQALE（Software Quality Assessment Based on Lifecycle Expectations）方法：为每条规则定义"修复成本"，折算成时间/钱，形成债务比率与 SQALE 评级（Wikipedia: SQALE；方法论文 ResearchGate；其 IEEE Software 2012 论文《Managing Technical Debt with the SQALE Method》见 IEEE）。2010 年 SonarSource 发表博客《SQALE, the ultimate Quality Model to assess Technical Debt》，随后 SQALE 进入 Sonar（后称 SonarQube）的指标体系，"技术债务"从此成为静态分析平台的内置概念（SonarSource 博客）。（关于 SQALE 是否计量"利息"，两章表述有出入，调和后的结论见 2.3 节。）
• 2015 年 3 月，Adam Tornhill 出版《Your Code as a Crime Scene》（Pragmatic Bookshelf，出版页），把版本控制历史当作犯罪现场证据做行为分析；2018 年续作《Software Design X-Rays》确立 hotspot 方法：变更频率 × 复杂度 = 债务集中地，据此决定"先还哪笔债"。方法论商业化为 CodeScene 工具（codescene.com）。
• 2018 年 9 月 6 日，Stripe 发布《The Developer Coefficient》：开发者平均每周工作 41.1 小时，其中 13.5 小时（约 33%）花在技术债务上，加上"烂代码"耗时合计约 17.3 小时（约 42%）；估算全球每年因此损失约 3000 亿美元 GDP（报告 PDF；新闻页；批评性讨论见 Hacker News；二手转述见 sciodev.com）。这是"技术债务"第一次被放进董事会级别的经济叙事。需要注意：此类市场统计口径不一（另有 JetBrains 调查、Chainguard 调查等，见横轴），只作背景参考，不作精确依据。

单人视角：学术建制化给单人维护者留下了一件最实用的工具——SATD。单人项目没有评审会、没有债务登记簿，但"在注释里向未来的自己承认欠债"是零成本动作，而且机器可检测（从 Potdar & Shihab 起检测工具迭代至今）。类型学（代码/设计/架构/测试/文档债）则给了单人项目一张自查清单：欠债不是一种东西，是七种东西。产业线的工具化对单人项目是双刃的：好的一面，hotspot 方法不需要团队组织数据，只需要 git log——对单人长周期项目，版本控制历史是唯一不会随人员流动而丢失的"组织记忆"，Tornhill 方法论天然适合决定偿还顺序；坏的一面，把债务折算成"天数"的 SQALE 式量化隐含了"有团队、有排期"的假设，单人项目真正的约束不是钱，而是认知带宽与动力——负债表好看并不能让人打开编辑器。

1.5 阶段五：会议建制与偿还方法论成熟（2018–2021）

• 2018 年，首届 ACM/IEEE 国际技术债务会议（TechDebt 2018）在哥德堡举办，与 ICSE 同址——MTD 工作坊系正式升格为旗舰会议；第二届 TechDebt 2019 于 2019 年 5 月 26 日在蒙特利尔举行（论文集 DOI 10.1109/TechDebt.2019.00013）。
• 2018 年，SonarQube 7.2 引入 Maintainability Rating（A–E），取代旧的 SQALE 评级命名；底层仍是技术债务比率（A < 5%，B 5–10%，C 10–20%，D 20–50%，E > 50%），指标内部键至今仍是 sqale_rating（Sonar 指标文档；Stack Overflow 解析）。同年前后，Sonar 提出 "Clean as You Code"（CaYC，边写边清）方法论：只对"新代码"设定质量门，存量债不主张一次性还清（Sonar 文档）。
• 2019 年，Kruchten、Nord、Ozkaya 出版《Managing Technical Debt: Reducing Friction in Software Development》（Addison-Wesley，SEI 系列专著，272 页），给出债务的形态、根因与管理原则（SEI 图书页）。
• 2020 年 1 月 1 日，Python 2.7 正式 EOL（PEP 373）。一场从 2008 年宣布、耗时十一年余的"平台迁移债"清偿完毕——单人/中小项目最典型的长周期债务样本：社区层面的"利息"（双版本兼容）支付了十余年。
• 2021 年，两本专著同年落地：Neil Ernst、Julien Delange、Rick Kazman 的《Technical Debt in Practice》（MIT Press，开放获取，DOI 10.7551/mitpress/12440.001.0001），按识别—量化—排序—管理的完整闭环组织章节；2021 年 12 月 10 日，Log4Shell（CVE-2021-44228）披露，一个深埋在传递依赖里的库让全球互联网陷入修补风暴（CISA 公告 AA21-356A）——依赖债从工程议题升级为国家安全议题，直接催化 SBOM 与依赖可见性规范。
• 阶段背景事件：2016 年 3 月，npm left-pad 事件——一个 11 行的包被下架，数千个项目（含 Babel）经传递依赖断粮约 2.5 小时（Wikipedia: Npm left-pad incident），生态级债务的预演。

单人视角：这一阶段最有价值的产出是两件事。其一，Clean as You Code 几乎是为单人项目量身定做的策略：它承认"全量还清不可能"，把唯一可执行的原则（不让今天的债新增）写得极简，用"新代码"定义代替意志力。其二，长周期项目的三大典型债务事件在本阶段全部上演：平台迁移（Python 2→3）、依赖连锁（left-pad、Log4Shell）、以及随时间失效的"当初的正确设计"。单人项目没有中央安全团队来防 Log4Shell 式事件，可执行的对策只有：控制依赖面、固定版本策略、让"升级依赖"成为日历上的例行偿还而非应急手术。

1.6 阶段六：AI 时代——债务的生产函数变了（2022–2026）

• 2023 年 2 月，SonarQube 9.9 LTS 发布，产品主线全面围绕 CaYC 重构（BusinessWire 公告）；2023 年 8 月，Sonar 正式引入"Clean Code"属性体系，把债务管理的终点定义为"持续产生干净代码"而非"还清旧账"（Sonar 社区公告）。
• 2025 年 2 月，GitClear 发布《AI Copilot Code Quality》报告：基于 2020–2024 年 2.11 亿行变更代码，发现 2024 年 5 行以上重复代码块暴增 8 倍，历史上首次出现"复制粘贴行超过重构搬移行"（GitClear 官方页；报告 PDF）；其 2026 年后续报告《The Maintainability Gap》显示重复代码占比从约 8% 升至 18%（GitClear）。AI 代码助手在放大产能的同时放大了债务的生产速率。
• 2025 年，学术线跟上：Moreschini 等发表《The Evolution of Technical Debt from DevOps to AI-Enhanced Development》（Journal of Systems and Software，ScienceDirect）；多声部文献综述《Faster Code, Deeper Debt?》指出 LLM 放大传统债务并引入全新债务类别（ACM DL）；arXiv 上已出现《Towards Understanding GenAI-Induced Self-Admitted Technical Debt》——SATD 的研究范式被平移到 AI 生成的注释与代码上（arXiv）。工业界调查（Sonar《State of Code》开发者调查）显示 88% 的开发者报告 AI 对技术债至少有一项负面影响，同时 93% 的开发者报告至少有一项正面收益——"toil shift"（劳役转移）成为新关键词（SonarSource 博客，2026-02）。另有另一口径的调查显示 43% 的 IT 经理担心 AI 制造新的技术债——出自 HFS Research 与 Unqork 的联合调研（123 位大型企业高管与经理样本，2025-09 调查），见 ZDNet 报道，2025-11。开发者侧还有一份 Chainguard 调查：开发者被非编码事务占满、三分之二工程师"持续"遇到技术债（The New Stack 报道）。三组调查对象不同（开发者 vs IT 经理）、口径不一，本稿并列为互补证据而非互相矛盾（详见 3.5 节）。
• 新债务类型的命名：Addy Osmani 提出 comprehension debt（理解债）——人类无法理解自己仓库里 AI 生成的代码的隐性成本（Addy Osmani《Comprehension Debt – the hidden cost of AI generated code》，作者官网；亦见 Medium 版、O'Reilly Radar 版）。债务定义的边界从"写错了"扩展到"没人读懂"。
• 2026 年 4 月 12–13 日，第 9 届 ACM/IEEE 国际技术债务会议（TechDebt 2026）在里约热内卢举行，仍与 ICSE 同址（会议官网）——从工作坊到会议的 16 年里，这门学科保持了每年一届的连续性。

单人视角：AI 时代对单人长周期项目是把双刃剑挥到了极致。正面：AI 第一次让单人项目可以像团队一样扩产能——"有人帮你写测试、帮你读十年前的旧代码"。负面：理解债对单人项目的杀伤比对团队更大——六个月后读不懂那段 AI 代码的人正是你自己，而且没有同事可以问。本阶段给单人维护者的净结论：把 AI 用在"识别与偿还"（解释旧代码、生成测试、清理重复）比用在"生产新代码"上更划算，因为前者的产出经过你自己的理解，后者绕过了它。

1.7 纵轴总账：34 年沉淀的四件武器与一条元规律

把六个阶段横着切开，对"一个人维护一个十年项目"的场景，技术债务管理沉淀了四件可复用资产：

1. 测试纪律（偿还的发动机）：SQLite 是单人/极小团队长周期项目的活标本——D. Richard Hipp 领导的约三名提交者维护着部署在数十亿设备上的数据库，测试代码与实现代码之比约 711:1，追求 100% MC/DC 覆盖，全套覆盖测试约三分钟跑完、每次改动后必跑（Hipp 在 SIGMOD Record 访谈中的自述：SIGMOD Record PDF；长访谈见 CoRecursive）。它证明：债务管理的天花板不由团队规模决定，由测试基础设施决定——测试是"付得起利息"的前提。
2. SATD 台账（识别的最小成本形态）：从 2014 年 ICSME 论文确立的研究范式反推到个人实践——在注释里向未来的自己承认欠债（TODO/HACK/DEBT），配合机器检测。对单人项目，这比任何债务仪表盘都可靠，因为它只在有真实认知时才写下。（台账的跨环节角色见 3.3、3.4 与附录 A.2。）
3. Clean as You Code（偿还与预防的总体策略）：存量全清不可能、增量不可欠——2018 年前后由 Sonar 定名的方法论，恰好也是单人长周期项目唯一可持续的策略。
4. hotspot 行为分析（排序方法）：变更频率 × 复杂度定位债务集中地；对单人项目，git 历史是唯一不会丢失的组织记忆，该方法的适用性反而高于团队项目。

以及一条 34 年不变的元规律：技术债务管理工具每一代的演进方向，都是把"现在省下的时间"与"未来要多付的时间"之间的结算周期缩短——1992 年靠开发者的自我修养按月结算，2009 年靠四象限按决策结算，2010 年代靠 CI 仪表盘按次结算，2020 年代靠"新代码质量门"按提交结算。单人长周期项目的特殊处境是：结算周期最长（没有发布压力逼迫你还债）、结算对象最明确（你自己）、违约成本也最高（没人接盘）。因此它最需要的是用外部化的仪式（质量门、例行升级日）替代团队环境中天然存在的偿还压力。

二、横轴：横向对比（2026-11 时间截面）

2.1 对比基准：单人长周期项目的三条评估原则

本课题主张的不是又一个工具，而是一套四环节闭环的生命周期方法论：识别（找出债在哪）→ 量化（债有多大、利息多高）→ 偿还（按优先级还）→ 预防（不再新增）。它要回答的问题是：在一个没有团队、没有专职 QA、没有采购预算的长期项目里，这套闭环能不能用近乎零成本的组合落地？因此它的"竞品"不是单一产品，而是六个梯队的现成方案——每一个梯队都把四环节中的某一环做到极致，但没有一个完整覆盖四环。

单人长周期视角带来三条与主流企业级叙事截然不同的评估原则：

1. 无协作冗余：为团队设计的仪表盘、组合视图、向高管汇报的评分体系，对单人项目几乎没有价值；
2. 运维预算趋近零：需要自托管服务器、持续维护的方案，其"免费"是伪免费；
3. 决策闭环极短：发现与修复可以在同一天完成，因此"量化"的价值从"向上汇报、争取预算"退化为"给自己排优先级"——量化手段可以便宜很多，但必须快。

2.2 六个梯队与总对比表

梯队 A——事实标准 SonarQube 与它的镜像们。SonarQube 对单库做静态分析，用基于 SQALE 的技术债比率映射为 A–E 等级，配合 Quality Gate 在 CI 里门禁"新代码"，官方方法论即 CaYC（来源：SonarQube 官方文档、中立对比页 technicaldebtcost.com）。单人成本细账：Community Build 免费开源、可自托管，但不支持分支与 PR 分析——而 PR/分支分析恰是 CaYC 工作流的核心（SonarSource 开源版页、第三方对比 corgea.com）；替代路径是 SonarQube Cloud 免费层，私有项目 5 万行以内免费且支持完整 PR 分析（SonarSource 官方博客，2025-02）。结论：单人项目只要长期控制在 5 万行内，可零成本拿到完整 CaYC；超过后要么付订阅，要么忍受社区版功能残缺；自托管则把成本转嫁为服务器运维——单人视角下这是真实的持续负债。Qlty：2025 年 1 月 Code Climate 的质量产品重塑为 Qlty（Code Climate 公告，2025-01-13），继承经典 A–F 等级 + 技术债比率体系（十点技术债评估、Qlty 文档），CLI 开源、聚合 70+ 静态分析工具（GitHub qltysh/qlty）——对单人项目是"零运维、零订阅"的识别+量化组合，适配度高于 SonarQube 自托管。Codacy、NDepend 差异主要在语言覆盖与评分口径（对比见 repowise.dev）。

梯队 B——CodeScene，把"利息"算进优先级。行为代码分析：把代码质量与 git 历史（改动频率、协作模式）叠加，找出复杂度与变更频率重叠的"热点"，即真正拖慢维护速度的债。Code Health 指标按 1–10 分、25+ 因子加权（CodeScene 技术债产品页、热点分析文档）。它从概念上回应了 SQALE 的最大盲区（见 2.3）：SQALE 主要算本金（修复成本），CodeScene 试图把利息（改不动的代价）纳入优先级。两点诚实标注：CodeScene 官方宣称其指标"比 SonarQube 准 6 倍"是厂商口径，中立对比页明确标记为"方向性参考而非独立结论"（technicaldebtcost.com；另见 code-quality.io 的 CodeScene vs SonarQube 对比）；定价约每活跃开发者每月 €18（第三方口径），私有库免费版功能受限（SourceForge 报价页，现价以官网为准）。单人视角下有个有趣的替代：热点的原始数据（改动频率 × 文件复杂度）完全可以用一段 git log 脚本 + 圈复杂度 linter 自算（脚本骨架见附录 A.1）——CodeScene 的方法论可复制，这是"识别+排序"环节可以近乎零成本自建的部分。

梯队 C——组合级与认证模型，为"多人决策"而生。CAST Highlight 面向 CIO 的组合级扫描，输出 Software Health 指数并对照 CRASH 基准，用于决定"几十上百个应用里先现代化哪一个"（CAST 官方新闻、对比页）——单人项目只有一个应用，组合级毫无用武之地。SIG Sigrid 的可维护性模型按 ISO/IEC 25010 评估单元大小、复杂度、接口、耦合四属性，输出 1–5 星评级并由 TÜViT 独立认证，2024 年刚更新模型（SIG 官方博客，2024-08）；其学术根基是 Nugroho 等人 2011 年的"技术债与利息实证模型"——5 星代表理想质量水平，利息即为相对该水平多耗的维护工时（Nugroho et al., 2011, ACM）。"利息"概念在这里被形式化，这是量化环节的重要理论参照；但交付形态是咨询合同，单人不可得。vFunction 用静态+运行时分析观察架构退化，为单体拆分服务——单人只能靠架构测试（ArchUnit 类断言）自行近似。

梯队 D——量化模型与纯方法论，理论主干与最大批判靶区。SQALE 的强项是归一化、可聚合；弱点在 2024 年被学术研究点名："The SQALE Index Case"（Robredo 等，2024）指出业界至今没有一致的技术债度量方法，SQALE 指数在工具间与场景间的一致性存疑（Robredo et al., 2024, University of Southern Denmark / ACM）。另有 practitioner 撰文指出技术债并非总是可量化的——组织型、知识型债务抗拒任何指标（Matt Holford, Medium）。SQALE 的结构性盲区有四：只覆盖静态规则可检出的债（架构债、设计债漏检）；修复工时是分析师拍的经验值；标准指标只算本金不算利息；对不可量化债务无能为力。这四条恰是"量化"环节应诚实承认的边界。Fowler 四象限（martinfowler.com）的价值在"预防"环节：区分"有意的谨慎负债"（合理）与"鲁莽负债"（事故源）。童子军规则（每次提交让代码比来时更干净）是流程级预防的极致形态，但争论明确存在：aim42 方法手册指出在严重劣化的代码库上执行该规则会引发巨量 diff 与范围蔓延（aim42.org 模式页）；Philippe Bourgau 论证该规则对大规模重构无能为力，需要显式台账与专项容量补充（When the Boy Scout Rule Fails）。单人项目没有 code review 缓冲，巨量 diff 的代价由自己全额承担——童子军规则需要设"每次 ≤30 分钟"之类的预算护栏。aim42（aim42.org）作为免费开源方法手册，提供"分析→评估→规划→改进"完整流程，是方法论层面最直接的免费同类。

梯队 E——自动化偿还引擎，2024–2026 年格局剧变的最大变量。OpenRewrite / Moderne：开源规模化重构引擎，基于无损语义树（LST）用声明式配方改代码；Moderne 2023 年 2 月获 1500 万美元 A 轮（Intel Capital 领投，官方新闻稿），2025 年 2 月完成 3000 万美元 B 轮（Acrew Capital 领投，TechCrunch 报道，2025-02-11）；配方已覆盖 Spring Boot 4 / Spring Framework 7 迁移（OpenRewrite 文档）；近期配方分发正从 Maven Central 迁往新的 "Code Genome Project"（社区仍在讨论，细节待进一步核实）。对单人 Java 系长周期项目，OpenRewrite 是把"依赖升级债"从手工地狱变成一条命令的最短路径。Amazon Q Developer Transform：代理式代码升级，官方示例将 1 万行以上项目从 Java 8 升到 Java 17，2025 年 6 月新增"选择性转换"（Java 8→21，仅升级最小必要依赖）（AWS 产品页、AWS 文档、AWS 博客 2025-06）；代价是绑定 AWS 生态与 Java 系。Codemod.com：AI + 编译器感知技术做企业级代码迁移编排，2025 年 8 月获 Propeller 种子轮投资（Propeller 投资手记，2025-08-28、codemod.com）。Grit.io：GritQL 声明式重构语言 + AI 迁移，2025 年 4 月被 Honeycomb 收购——梯队内首个标志性退出事件（Honeycomb 官方博客，2025-04）。对课题的含义：当"偿还"可以被配方和代理近乎自动化，管理技术债的瓶颈从"改不动"转移到"识别得准、排得对"。

梯队 F——流程型替代，换一种还债姿势。Strangler Fig（绞杀者无花果模式）：在旧系统边缘渐进替换而非大爆炸重写（Fowler 模式原文）。Fowler 体系常引的估计是完整重写的实际成本约为预估的 1.8 倍（Tappable 引述 Fowler；另一决策指南见 aidev.com）——大重写因此以反面教材为主，只在"地基本身错误"时值得考虑。单人长周期项目恰恰是 Strangler Fig 的最佳土壤：没有协调成本，可以无限小步——它不是工具，是"偿还"环节的最优单人策略。Stepsize：IDE + Jira 的债务台账工具，把债做成可见工单而非散落的 TODO 注释，至今仍在运营并被 2025 年榜单收录（stepsize.com、Atlassian Marketplace、Zenhub 2025-06 榜单）。单人替代方案极其朴素：一个 DEBT.md 文件 + TODO 注释规范即可获得 80% 的价值（模板见附录 A.2）——这正与纵轴的 SATD 研究传统（1.4 节）接上了头。台账的价值有实证支撑：JetBrains 开发者生态调查显示，超过半数开发者每月花 1–5 个工作日处理技术债，若无台账，这些时间会以"隐性返工"形式散失（JetBrains Developer Ecosystem Survey）。

横切变量——AI 编程代理正在同时制造与偿还债务。2024–2026 年的横切观察：一方面，AI 编程代理（Claude Code、Cursor、Copilot 等）让单人开发者的"偿还"能力放大；另一方面，43% 的 IT 经理担心 AI 制造新的技术债（HFS Research 与 Unqork 联合调研，ZDNet 报道——见 1.6 节来源），叠加 GitClear 的重复代码暴增数据（1.6 节）。AI 是偿还加速器，也是债务放大器——"预防"环节因 AI 而变得更重要而非更不重要。这是本课题最有时效性的差异化论点。

2.3 一个需要调和的分歧：SQALE 到底算不算"利息"

纵轴章节曾表述 SQALE"并可估算'不修的成本（利息）'"，横轴章节则把"只算本金不算利息"列为 SQALE 的结构性盲区。调和后的结论（本稿全文采用）：SQALE 方法论文层面讨论过不修复的后果，但进入 SonarQube 的标准指标体系（技术债比率、A–E 评级）完全由"修复成本"（本金）构成；真正把"利息"实证化的是 SIG/Nugroho 2011 的维护工时模型（利息 = 相对 5 星理想水平多耗的维护工时），把"利息"行为化的是 CodeScene 的热点分析（改不动 = 利息在累积）。换言之，"利息"至今没有进入主流工具的默认指标，它是量化环节的公开难题，而非 SQALE 已解决的问题——Robredo 等 2024 年的研究（业界度量无共识）进一步佐证了这一点。

2.4 当下时间截面（2026-11）的三点格局观察

1. "偿还"环节的竞争已结束，"识别/排序"成为新瓶颈。 OpenRewrite、Amazon Q Transform、Codemod 等引擎使批量重构成本坍缩；此前属于稀缺资源的"重构人力"正在贬值，识别与优先级判断的价值相应上升。梯队 E 的融资与并购（Moderne B 轮、Grit 被 Honeycomb 收购、Codemod 获投——各笔来源见 2.2 梯队 E）都发生在这条线上。
2. 量化环节的学术共识仍未收敛。 SQALE 十余年后仍被 2024 年的研究质疑一致性；"利息"只有 SIG 模型做了实证化。对课题而言，诚实的立场是接受"粗糙但自洽"的三档量化——修复分钟数、热点标记、直觉分（全文统一定义见 3.4 节；四象限只作定性底色），而非追逐精确指数。
3. 工具层正在洗牌，单人项目应优先押注开源与自算。 Code Climate 重塑为 Qlty、Grit 退出独立市场、SonarSource 收紧社区版权限（无 PR 分析）、云免费层设 5 万行门槛——每一件事都在提示：把识别能力建立在"70+ linter 的开源 CLI + 一段自写热点脚本"上，比绑定任何单一厂商的 SaaS 更抗时间侵蚀。这正是单人长周期视角对"生态成熟度"维度的修正性定义：成熟 = 存续概率高 + 可退出，而非 = 功能全。

三、交叉洞察：两轴结合说明了什么

3.1 结算周期持续缩短，AI 让它第一次局部反向

纵轴的元规律说：每一代工具都在缩短"省时"与"付息"之间的结算周期（月→决策→构建→提交）。横轴补上了 2026 年的新变量：AI 代理让"生产"提速了一个量级，但理解没有同步提速——债务的产生速率（复制粘贴、无人读懂的生成代码）首次快于结算机制的覆盖速率（GitClear：重复代码占比 8%→18%；Sonar《State of Code》口径：88% 开发者报告 AI 对技术债至少有一项负面影响——来源见 1.6 节）。也就是说，结算周期在"偿还"一侧被 AI 缩短了（配方引擎一条命令还债），却在"产生"一侧被 AI 拉长了（生成者与维护者都不理解代码）。这是 34 年来第一次两个方向同时运动，也是"预防"环节价值重估的根本原因。

3.2 偿还环节的竞争已经结束，瓶颈移到识别与排序

把纵轴的阶段五、六与横轴的梯队 E 放在一起看：2018–2021 年 Sonar 从"查债指标"转向"还债方法论"（CaYC），2024–2026 年 OpenRewrite/Amazon Q/Codemod 把批量偿还成本打到接近零。两轴共同指向同一结论：稀缺资源已经从"重构人力"变成"识别得准、排得对"。一个识别/排序失误的长周期项目，会让自动化引擎以同样高的效率把重构做错方向。这为本课题"识别与量化优先于偿还"的主张提供了 2026 年的新论据——它同时解释了为什么在 Stripe 的 33% 叙事（债很贵）与 JetBrains 的 1–5 天/月调查（债很常见）之后，故事并没有停在"更贵的债"上：自动化引擎已构成偿还侧的银弹，因此真正的瓶颈与空白在识别/排序侧（与 2.4 第 1 条互为印证）。

3.3 长周期改变债务贴现率：惩罚与豁免同时生效

纵轴说单人项目的结算周期最长、违约成本最高；横轴说长周期让每笔债的复利周期更长（热点债更凶）、但也让 Strangler Fig 式渐进偿还的时间预算最充裕。两轴合并后的判断是：长周期对债务既是惩罚也是豁免——分水岭在于有没有台账把债记下来。这里需要给台账的角色正名：台账是识别/记录工具（1.7 的"识别的最小成本形态"），它既不是偿还动作也不是预防动作本身，而是通过支撑这两个环节生效——记下来的债才能被例行偿还、被增量预防，没记下来的债两者皆无。有台账（SATD/DEBT.md），渐进偿还的豁免就生效：依赖升级的例行化（1.5 的"日历上的例行偿还"）能缩短 left-pad、Log4Shell 这类突发事件的暴露面与修复时间——但 left-pad 是包被下架、Log4Shell 是零日漏洞披露，事件本身都无法预约，应急不能被消灭；能整体转为例行升级的，是 Python 2 EOL 这种提前十一年预告的平台迁移。没有台账，惩罚就生效：债以"隐性返工"形式散失（JetBrains 口径），最终指向 1.8× 超支的大重写（Tappable 引 Fowler 口径）。

3.4 对用户的判断与建议：单人长周期项目的四环节闭环

纵轴的四件武器与横轴的四环节最优组合，指向同一套落地配置（全部组件今天免费可得）。本文的量化口径在此统一定义，全文（含 TL;DR 与 2.4）以本节为准：所谓"三档量化"，指 ①修复分钟数（这笔债修多久，估法见附录 A.3）、②热点标记（它是否落在变更最频繁的文件上，算法见附录 A.1）、③直觉分（1–5 分，"它会不会让我不敢改"）；Fowler 四象限只作定性底色（给每笔债标注故意/无意 × 鲁莽/审慎，帮助自省），不参与排序。

注（SATD 台账的跨环节角色）：SATD 台账是识别/记录工具（1.7），其"对应纵轴资产"位置在识别行；但它同时跨环节生效——偿还侧，台账是"长周期惩罚与豁免"的分水岭（3.3）；预防侧，DEBT.md 是"增量不可欠"的登记面（模板见附录 A.2）。为避免同一资产在表中重复计数，此处集中说明，不再在预防行单列。

五条具体建议：

1. 识别：用 Qlty CLI 做静态识别，用一段自写脚本（git log 变更频率 × 圈复杂度）做热点排序（脚本骨架见附录 A.1）。不要绑定单一 SaaS——2025 年的洗牌（Qlty 重塑、Grit 退出、Sonar 社区版收紧）证明可退出性比功能全更重要。
2. 量化要克制：Robredo 2024 证明业界无一致度量，单人无需假装精确。三档就够：修复分钟数回答"这笔债修多久"（排期），热点标记回答"它是不是热点"（顺序），直觉分回答"它会不会让我不敢改"（优先级兜底）；四象限只作定性底色，不参与排序。估法与一个完整示例见附录 A.3。
3. 偿还押注自动化，但方向要对：配方引擎与 AI 代理优先用于"识别与偿还"（解释旧代码、生成测试、清重复、跑依赖升级），而非无监督地生成新代码——前者经过你的理解，后者绕过它，并在六个月后以理解债的形式向你收息。
4. 预防是单人场景性价比最高、却最易被忽视的环节：团队靠评审互检兜底，单人没有第二双眼睛；Quality Gate 思想必须本地化为 pre-commit 钩子与覆盖率红线，否则 AI 代理与赶工冲刺会无声地堆债。童子军规则要加预算护栏（每次 ≤30 分钟），防止巨量 diff。
5. 把升级变成日历仪式：依赖面控制 + 固定版本策略 + 例行升级日，替代团队环境中天然存在的偿还压力——这是 Log4Shell 教训的单人版答案（例行升级缩短暴露面与修复时间，但消灭不了应急，见 3.3），也是 SQLite 式测试纪律的前提（三分钟跑完全套覆盖测试，才谈得上每次改动必跑）。

3.5 综合时调和的三处章节间出入（记录）

1. SQALE 是否计量"利息"：纵轴章写作"并可估算不修的成本（利息）"，横轴章列为 SQALE 盲区"只算本金不算利息"。调和结论见 2.3 节——标准指标只含本金，"利息"的实证化在 SIG 模型、行为化在 CodeScene，本稿全文统一采用此表述。
2. AI 对债务影响的三组调查数字：纵轴引 Sonar《State of Code》开发者调查（88% 开发者报告 AI 对技术债至少有一项负面影响、93% 报告至少一项正面收益，来源见 1.6 节），横轴引另一调研（43% IT 经理担心 AI 制造新债，HFS Research × Unqork，ZDNet 报道）。此外还有开发者侧的 Chainguard 调查（The New Stack 报道）。三组调查对象与口径不同，不构成矛盾；本稿并列引用并标注口径，避免单引一处造成"开发者担心/经理担心"的片面对比。
3. 重复内容合并：git 历史作为单人项目"唯一不会丢失的组织记忆"在两章各出现一次（纵轴 1.4/1.7、横轴 2.2 梯队 B），SATD 研究传统（纵轴 1.4）与单人台账实践 DEBT.md（横轴 2.2 梯队 F）本是一件事的研究端与实践端，本稿分别归位至 1.4 节与 2.2 节梯队 F，并在 3.3 节合并为"台账是长周期惩罚与豁免的分水岭"这一交叉结论。另：Stripe "1/3 时间"数字，纵轴给细节、横轴仅作背景，本稿统一为"细节保留 + 标注口径不一仅作背景参考"。

附录：单人闭环的最小工具包

正文三次推荐"自算 git 热点"与 DEBT.md，本附录给出可直接落地的最小版本。三件东西：脚本骨架（A.1）、台账模板（A.2）、估法与量化示例（A.3）。

A.1 git 热点自算脚本（骨架）

原理即 1.4/2.2 梯队 B 的 hotspot 方法：热点 = 变更频率 × 复杂度。两步：

第一步，统计近 N 个月每个文件的变更次数（已在修订环境实测，git 2.51.0）：

git log --since="12 months ago" --name-only --pretty=format: \
  | grep -v '^$' | sort | uniq -c | sort -rn | head -30

第二步，对每个文件取圈复杂度，与频率拼接。圈复杂度工具用开源的 lizard（pip install lizard，支持 Python/Java/JavaScript/C/C++/C#/Go 等多语言；Python 项目也可用 radon，C 系可用 pmccabe）。脚本骨架（已实测：修订环境临时仓库 11 次提交，lizard 1.25.0；--csv 无表头行，第 2 列即 CCN，示例输出行 9,6,36,1,9,"tangled@1-9@src/complex.py",...）：

#!/usr/bin/env bash
# hotspot.sh —— git 变更频率 × 平均圈复杂度（骨架）
# 用法：./hotspot.sh [回看月数=12]
# 依赖：git；lizard（pip install lizard）
set -euo pipefail
MONTHS=${1:-12}

# 第 1 步：近 N 个月每个文件的变更次数
git log --since="$MONTHS months ago" --name-only --pretty=format: \
  | grep -v '^$' | sort | uniq -c | sort -rn | head -30 > hotspot_freq.txt

# 第 2 步：逐文件取 lizard 平均圈复杂度（CSV 第 2 列 = CCN；无表头，从第 1 行累加）
printf '变更次数\t平均CCN\t文件\n'
while read -r freq file; do
  ccn=$(lizard --csv "$file" 2>/dev/null \
        | awk -F, '{s+=$2; n++} END {if (n>0) printf "%.1f", s/n; else print "-"}')
  printf '%s\t%s\t%s\n' "$freq" "$ccn" "$file"
done < hotspot_freq.txt

读法：两个数字都高的文件是热点，先处理"变更次数高且 CCN 高"的文件；只高频不复杂的是稳定代码，不动它。两点提醒：脚本默认只统计当前分支；lizard 解析行以 lizard --csv 在你机器上的实际输出为准（不同版本列序可能调整），骨架未经真实项目验证，首次使用请人工抽查两三个文件。

A.2 DEBT.md 模板（SATD 台账的单人版）

配套的代码注释规范：写 SATD 注释时同步登记台账，注释带台账 ID 与日期，如 // TODO(debt:D-001,2026-11-05): 登录与注册重复实现校验；还清条件＝抽出共享校验函数。还清时同时删除注释、回填台账。

# DEBT.md —— 技术债台账（单人版）

约定：
- 类型七选一：代码 / 设计 / 架构 / 测试 / 文档 / 依赖 / 理解债（1.4 节类型学）
- 象限按 Fowler 四象限标注：故意/无意 × 鲁莽/审慎（仅定性底色，不参与排序）
- 修复分钟数只记三档：<30 / 30–120 / >120；还清后回填实际值校准（见 A.3）
- 热点列填 hotspot.sh 输出的"近 12 月变更次数 + 全仓排名"
- 直觉分 1–5："会不会让我不敢改这块"
- 每个例行升级日（月度）扫一遍：热点高且直觉分 ≥3 的开放条目优先排入偿还

| ID | 日期 | 位置 | 描述 | 类型 | 象限 | 修复分钟数(估/实) | 热点(近12月) | 直觉分 | 状态 |
|----|------|------|------|------|------|------------------|--------------|--------|------|
| D-001 | 2026-11-05 | src/auth.py:88 | 登录与注册重复实现了同一套校验规则 | 代码 | 无意+审慎 | 90 / – | 23 次（全仓第 2） | 4 | 开放 |

A.3 "修复分钟数"怎么估，以及一个量化示例

• 谁估：维护者本人。bus factor = 1 时没有第二个人可估，这正是三档量化的前提——它估的是"我下一次坐下来还这笔债要多久"，不是团队工时。
• 什么粒度：一笔债 = 台账一行 = "一次坐下来能还完的最小单元"；不往小时以下拆。只分三档：<30 分钟（顺手就还，可搭在童子军预算里）、30–120 分钟（单独排一个时段）、>120 分钟（拆成多笔或挂到例行升级日）。
• 怎么校准：还清时回填实际分钟数。积累 10–20 笔后，三档边界会自然校准到你的真实速度——这就是"粗糙但自洽"（2.4 第 2 条）。
• 量化示例（走一遍 D-001）：Qlty CLI 报出重复代码（识别）→ 登记台账、标"无意+审慎"（定性底色）→ hotspot.sh 给出 23 次/全仓第 2（热点标记）→ 自评直觉分 4/5（"每次改登录都不敢动注册那边"）→ 估修复分钟数 90（30–120 档）→ 本周偿还时段还清 → 回填实际 75 分钟。下一次再遇到"重复校验逻辑"，30–120 档的估计就更可信；若某笔债三档都低但直觉分 5，说明它是要人工复核的隐性架构债——三档互相兜底，不追求精确。

四、参考来源

概念源头与定义（一手读取）

• Cunningham, OOPSLA '92 WyCash 原文：https://c2.com/doc/oopsla92.html
• C2 Wiki DebtMetaphor（含 2009 澄清视频转录）：https://wiki.c2.com/?DebtMetaphor
• C2 Wiki TechnicalDebt：https://wiki.c2.com/?TechnicalDebt
• Wikipedia: Technical debt：https://en.wikipedia.org/wiki/Technical_debt
• Fowler《TechnicalDebt》（2003，2019 重写）：https://martinfowler.com/bliki/TechnicalDebt.html
• Fowler《TechnicalDebtQuadrant》（2009）：https://martinfowler.com/bliki/TechnicalDebtQuadrant.html
• Robert C. Martin（Uncle Bob）《A Mess is not a Technical Debt》（2009-09-22，Fowler 四象限原文所链接的原帖存档）：https://sites.google.com/site/unclebobconsultingllc/a-mess-is-not-a-technical-debt
• Fowler《StranglerFigApplication》：https://martinfowler.com/bliki/StranglerFigApplication.html

学术建制

• MTD 2011 工作坊报告（ACM DL）：https://dl.acm.org/doi/pdf/10.1145/1985793.1986051
• IEEE Software 2012 专刊社论《From Metaphor to Theory and Practice》：https://dl.acm.org/doi/10.1109/MS.2012.167 ｜ https://www.sei.cmu.edu/library/technical-debt-from-metaphor-to-theory-and-practice
• SEI MTD 2012 全景图报告：https://www.sei.cmu.edu/library/technical-debt-in-software-development-from-metaphor-to-theory-report-on-the-third-international-workshop-on-managing-technical-debt
• MSR-TR-2012-77《Towards a Taxonomy of Technical Debt》：https://www.microsoft.com/en-us/research/publication/towards-a-taxonomy-of-technical-debt/
• 《Towards a Crisper Definition》（2013）：https://apps.dtic.mil/sti/tr/pdf/AD1015409.pdf
• SATD（Potdar & Shihab, ICSME 2014）：https://ieeexplore.ieee.org/document/6976075
• 术语本体（Alves et al., MTD 2014）：https://doi.org/10.1109/MTD.2014.9
• Alves et al., 2016，《Identification and management of technical debt: A systematic mapping study》，Information and Software Technology 第 70 卷：https://www.sciencedirect.com/science/article/pii/S0950584915001743 ｜ DOI：https://doi.org/10.1016/j.infsof.2015.10.008
• Dagstuhl 16162：https://www.dagstuhl.de/16162 ｜ https://drops.dagstuhl.de/entities/document/10.4230/DagRep.6.4.110
• Nugroho et al., 2011（利息实证模型）：https://dl.acm.org/doi/pdf/10.1145/1985362.1985364
• Robredo et al., 2024, "The SQALE Index Case"：https://portal.findresearcher.sdu.dk/en/publications/the-sqale-index-case
• TechDebt 2019 论文集：https://doi.org/10.1109/TechDebt.2019.00013 ｜ TechDebt 2026 官网：https://conf.researchr.org/home/TechDebt-2026
• Kruchten/Nord/Ozkaya 2019 专著（SEI）：https://www.sei.cmu.edu/library/managing-technical-debt-reducing-friction-in-software-development
• MIT Press 2021 专著（开放获取）：https://doi.org/10.7551/mitpress/12440.001.0001

量化方法与工具

• SQALE：https://en.wikipedia.org/wiki/SQALE ｜ 方法论文 https://www.researchgate.net/publication/239763591_The_SQALE_method_for_evaluating_Technical_Debt ｜ IEEE Software 2012 论文 https://ieeexplore.ieee.org/document/6170022
• SonarSource SQALE 博客（2010）：https://www.sonarsource.com/blog/sqale-the-ultimate-quality-model-to-assess-technical-debt
• Sonar 指标文档：https://docs.sonarsource.com/sonarqube-server/user-guide/code-metrics/metrics-definition ｜ Stack Overflow 解析：https://stackoverflow.com/questions/38923149/how-does-sonarqube-calculate-its-maintainability-rating
• Sonar CaYC 文档：https://docs.sonarsource.com/sonarqube-server/latest/user-guide/clean-as-you-code ｜ 社区版权限：https://www.sonarsource.com/open-source-editions/sonarqube-community-edition ｜ 云免费层（2025-02，5 万行）：https://www.sonarsource.com/blog/choosing-sonarqube-free-tier ｜ 第三方对比：https://corgea.com/blog/sonarqube-alternatives
• Tornhill 2015《Your Code as a Crime Scene》：https://pragprog.com/titles/atcrime/your-code-as-a-crime-scene ｜ CodeScene：https://codescene.com ｜ 产品页 https://codescene.com/manage-and-reduce-technical-debt ｜ 热点文档 https://codescene.io/docs/guides/technical/hotspots.html ｜ 报价（第三方）https://sourceforge.com/software/CodeScene/
• Qlty（原 Code Climate）：https://codeclimate.com/legacy/code-climate-quality-is-now-qlty-software ｜ https://codeclimate.com/legacy/10-point-technical-debt-assessment ｜ https://docs.qlty.sh/what-is-qlty ｜ https://github.com/qltysh/qlty
• SIG 2024 模型更新：https://www.softwareimprovementgroup.com/blog/maintainability-model-2024-update ｜ CAST/WSJ：https://www.castsoftware.com/news/wall-street-journal-highlights-real-world-implications-of-technical-debt

方法论与流程

• aim42：https://aim42.org ｜ 童子军规则模式页：https://aim42.org/patterns/introduce-boy-scout-rule
• Bourgau《When the Boy Scout Rule Fails》：https://philippe.bourgau.net/when-the-boy-scout-rule-fails
• Holford《Can technical debt be quantified?》：https://medium.com/can-technical-debt-be-quantified
• 重写 vs 重构（1.8× 超支，引述 Fowler）：https://www.tappable.co.uk/blog/rebuild-vs-refactor ｜ https://aidev.com/guides/rebuild-vs-refactor
• Stepsize：https://stepsize.com/technical-debt ｜ https://marketplace.atlassian.com/apps/1223357/stepsize-tech-debt-manager-for-jira
• 圈复杂度工具 lizard（附录 A.1 所用）：https://github.com/terryyin/lizard

自动化偿还引擎

• OpenRewrite 文档：https://docs.openrewrite.org/
• Moderne A 轮（2023-02，$15M，Intel Capital 领投，官方新闻稿）：https://moderne.ai/press/moderne-raises-15m-series-a-round-to-bring-continuous-software-modernization-to-market ｜ Moderne B 轮（2025-02，$30M，Acrew Capital 领投）：https://techcrunch.com/2025/02/11/moderne-raises-30m-to-solve-technical-debt-across-complex-codebases
• Amazon Q Developer Transform：https://aws.amazon.com/q/developer/transform ｜ https://docs.aws.amazon.com/amazonq/latest/qdeveloper-ug/code-transformation.html ｜ 选择性转换博客（2025-06）：https://aws.amazon.com/blogs/devops/amazon-q-developer-java-upgrades-a-deep-dive-into-new-selective-transformation-feature
• Codemod 种子轮（2025-08，Propeller）：https://propellerinc.me/post/why-we-invested-in-codemod-1pdt2 ｜ Codemod 官网：https://www.codemod.com/
• Honeycomb 收购 Grit（2025-04）：https://www.honeycomb.io/blog/honeycomb-acquires-grit

产业事件与市场统计（口径不一，背景参考）

• Stripe《The Developer Coefficient》：https://stripe.com/files/reports/the-developer-coefficient.pdf ｜ https://stripe.com/newsroom/stories/developer-coefficient ｜ 批评讨论：https://news.ycombinator.com/item?id=17928067 ｜ 二手转述：https://sciodev.com/blog/technical-debt-hidden-cost
• left-pad 事件：https://en.wikipedia.org/wiki/Npm_left-pad_incident
• Python 2.7 EOL（PEP 373）：https://peps.python.org/pep-0373/
• Log4Shell（CISA AA21-356A）：https://www.cisa.gov/news-events/cybersecurity-advisories/aa21-356a
• JetBrains 开发者生态调查：https://www.jetbrains.com/lp/devecosystem/
• Chainguard 调查（The New Stack 报道）：https://thenewstack.io/survey-engineers-want-to-code-but-spend-all-day-on-tech-debt

AI 时代

• Addy Osmani《Comprehension Debt – the hidden cost of AI generated code》：作者官网 https://addyosmani.com/blog/comprehension-debt/ ｜ Medium 版 https://medium.com/@addyosmani/comprehension-debt-the-hidden-cost-of-ai-generated-code-285a25dac57e ｜ O'Reilly Radar 版 https://www.oreilly.com/radar/comprehension-debt-the-hidden-cost-of-ai-generated-code
• Sonar《State of Code》开发者调查（88% / 93% 口径）：https://www.sonarsource.com/blog/how-ai-is-redefining-technical-debt
• HFS Research × Unqork 调研（43% IT 经理，ZDNet 报道）：https://www.zdnet.com/article/how-ai-can-magnify-your-tech-debt-and-4-ways-to-avoid-that-trap
• Moreschini et al., JSS：https://www.sciencedirect.com/science/article/pii/S0164121225002687
• 《Faster Code, Deeper Debt?》（ACM）：https://dl.acm.org/doi/10.1145/3820165
• GenAI-induced SATD（arXiv）：https://arxiv.org/html/2601.07786v1
• GitClear 2025《AI Copilot Code Quality》：https://www.gitclear.com/ai_assistant_code_quality_2025_research ｜ PDF：https://gitclear-public.s3.us-west-2.amazonaws.com/GitClear-AI-Copilot-Code-Quality-2025.pdf
• GitClear 2026《The Maintainability Gap》：https://www.gitclear.com/the_ai_code_quality_maintainability_gap
• SonarQube 9.9 LTS 公告：https://www.businesswire.com/news/home/20230207005514/en/ ｜ Sonar Clean Code 公告：https://community.sonarsource.com/t/introducing-clean-code-in-our-products/98431

单人项目案例与中立对比

• SIGMOD Record 访谈 Hipp：https://sigmodrecord.org/publications/sigmodRecord/1906/pdfs/06_Profiles_Hipp.pdf ｜ CoRecursive 066：https://corecursive.com/066-sqlite-with-richard-hipp
• 中立工具对比（WebFetch 全文验证）：https://technicaldebtcost.com/technical-debt-tools-comparison ｜ https://repowise.dev/blog/comparisons/technical-debt-measurement-tools-compared ｜ https://www.zenhub.com/blog-posts/the-top-technical-debt-management-tools-2025 ｜ https://www.code-quality.io/codescene-vs-sonarqube

终稿说明（2026-11-05）：本稿按独立审读意见逐条修订——①"三档量化"在 3.4 节统一定义（修复分钟数 + 热点标记 + 直觉分，四象限作定性底色），TL;DR、2.4、建议 2 与四象限相关表述全部对齐；②补齐"理解债"（Osmani，作者官网已抓取核对）、Sonar 88%/93%（博客页已抓取核对原句）、43% IT 经理（HFS Research × Unqork 联合调研，ZDNet 文章已抓取核对，样本 123 位高管/经理）三处来源，并更正 The New Stack 链接的归属——它只对应 Chainguard 调查，不再为 43% 作证；③3.2 节结尾改为"自动化引擎已构成偿还侧的银弹，真正的瓶颈与空白在识别/排序侧"，与 2.4 第 1 条一致；④明确 SATD 台账是识别/记录工具、通过支撑偿还与预防生效，3.4 表格的"对应纵轴资产"重新映射（识别行 = hotspot + SATD 台账，预防行 = Clean as You Code）并加注其跨环节角色；⑤3.3 节限定"依赖升级的例行化"只能缩短 left-pad/Log4Shell 类突发事件的暴露面与修复时间、不能消灭应急，可整体日历化的是 Python 2 EOL 类预告式迁移；⑥梯队 E 融资数字补齐来源（Moderne A/B 轮官方新闻稿与 TechCrunch，Codemod 种子轮 Propeller 手记），2.4 第 1 条的论据随来源成立；⑦新增附录 A：热点脚本骨架、DEBT.md 模板、修复分钟数估法与量化示例；⑧参考文献双向对账：补入正文引用过的 Uncle Bob 原帖与 Alves 2016 IST 映射研究，正文补引 sciodev（Stripe 二手转述）与 code-quality.io（CodeScene vs SonarQube 对比），移除正文从未引用的 isapp.be 与 betterprogramming.pub 两条目，标题"一句会议室比喻"已在 1.2 节落地。来源核验方式：Sonar 博客、ZDNet 文章、Osmani 官网、Uncle Bob 存档页在修订环境中抓取并核对原文；Moderne 官方新闻稿、TechCrunch、Propeller 页面确认可访问（HTTP 200）；Alves 2016 经两组独立书目信息交叉核对（ScienceDirect 有反爬限制，未能直接打开页面）；Medium 版 Osmani 文章与 O'Reilly 版未能从修订环境直接访问，URL 来自检索结果并已在官网版本核实内容。附录脚本：git 变更频率统计与 lizard CSV 列序（第 2 列 = CCN、无表头）已在修订环境的临时仓库实测（git 2.51.0 / lizard 1.25.0，11 次提交），脚本整体作为骨架发布，未在真实项目上验证。两章沿用的"（待核）"标注（1995 年 Wiki 创建年份、1999 年《重构》出版、30% 代码债占比原始出处）本稿保留，仍待核。