将claude code用于快速原型开发后技术债积累的量化跟踪

去年六月，我们技术团队用Claude Code在七个工作日内完成了一个跨境电商后台的原型，订单管理、库存同步、物流追踪三个核心模块全部跑通。演示那天投资人当场给了TS。散会后CTO把我拉到一边：“原型跑通不代表什么，我想知道三个月后维护这套代码的真实成本。”

这句话扎在我脑子里整整半年。

我们后来真的做了一个决定：把那个AI快速生成的原型项目拆了，逐模块复盘，逐文件量化技术债。 拆解过程持续了18天，最后产出一份47页的内部技术债量化报告。核心发现很反直觉，不是AI写的代码太烂，而是我们对AI代码的评估方式和跟踪机制完全失位。这之后我们花四个月搭了一套针对Claude Code的技术债量化跟踪体系，现在已经迭代到第三版，覆盖了我们四个在跑的商业项目。

这篇文章不是Claude Code的使用教程，也不是“效率如何惊人”的赞美帖。我要讲的是：当你的团队开始用Claude Code做快速原型开发后，如何持续量化、跟踪那些正在悄悄累积的技术债，以及在不同阶段应该怎么取舍。

一、核心结论先行：AI技术债的五个关键特征

在展开具体方法论之前，我先给出我们跟踪了六个项目后的核心判断。这些结论不是推导出来的，是每次Sprint结束复盘会上一个个校验出来的。

第一，Claude Code引入的技术债不是“代码质量差”，而是“理解成本高”。 传统技术债通常表现为耦合严重、重复代码多、缺乏注释。Claude Code生成的原型代码往往有注释、有类型定义、甚至有错误处理，但你读三遍都搞不清楚它为什么在某个地方选择用reduce而不是for循环。

第二，AI生成代码的技术债累积曲线与传统开发不同。 传统项目技术债是线性累积的，迭代越多，债越多。但Claude Code项目呈现“J型曲线”：前两周原型阶段代码质量尚可，第三周开始当需求复杂度超过AI单次理解能力后，技术债指数级攀升。

第三，最危险的债不是代码本身，是开发者对代码的“心理所有权”崩塌。 当一个模块你自己没写、也懒得读只是“看起来能跑通”，你就失去了对这个模块负责的意愿。这是我们观测到的最隐蔽、最致命的债务形态。

第四，常规的代码质量工具（ESLint、SonarQube、覆盖率报告）无法有效捕获AI技术债。 这点我们在第三节会展开。一个AI生成的文件可以完美通过所有lint规则、拿到90%测试覆盖率，但仍然是一颗定时炸弹。

第五，量化跟踪的关键不是“发现债”，而是“定义债的偿还门槛”。 很多团队停留在“代码写得不好”的抱怨层面，但没有一个数字告诉他们：当前项目的技术债已经到了必须介入的阈值。没有阈值就没有行动，没有行动就只剩焦虑。

二、背景与真实场景：我们为什么必须量化AI的技术债

2.1 那个原型项目拆解时我们看到了什么

拆解那个跨境电商项目时，我们逐文件做了人工review并按四个维度打分：可读性、可维护性、边界处理、逻辑一致性。18个核心文件，满分72分。

打分结果是47分。作为对比，我们另一个从零手写的同类项目（代码量相近）得分64分。更重要的是分数分布，手写项目低分集中在两个老旧模块（之前就知道有问题），AI项目低分均匀分布在12个文件上。这说明AI的技术债是系统性的，不是局部问题。

翻出当时Claude Code的交互记录，我们发现了更深层的问题。每个原型模块的prompt描述都非常优秀，功能边界清晰、异常场景列得全、甚至给出了性能预期。但Claude Code在三次以上的连续对话中出现了“上下文遗忘”，它记住了你上一个问题，但忘记了两个回合前定义过的数据模型。结果是在订单模块和库存模块之间悄悄造出了三个字段名不一致（orderStatus vs statusCode vs state），这在原型跑通时完全看不出来。

这个发现改变了我们对AI技术债的定义方式：债不在代码行内，在模块间的连接处。

2.2 快速原型的真实语境：不是“写完就扔”那种原型

很多讨论把“原型”等同于一次性验证、用完即弃的代码。但现实中的原型有多少是真的“用完就弃”？我们调研了自己团队和三个合作方的14个“原型项目”，结果：

• 11个在原型阶段结束后直接进入迭代开发；
• 其中7个的原型代码保留率超过60%；
• 3个项目的核心业务逻辑直到上线都在用最初Claude Code生成的代码。

这意味着大多数“原型”实际上就是V0.1的正式产品代码基础。这个语境下讨论技术债量化，才有真实的业务价值。

2.3 为什么传统代码质量指标在这个场景下失灵

我们最初尝试用SonarQube来跟踪Claude Code项目的技术债。结果很有意思：

• SonarQube对AI生成代码的技术债评分普遍高于手写代码（平均高8-12分）；
• 代码重复率指标上，AI代码反而更低，因为Claude Code很少复制粘贴，每次都重新生成；
• 圈复杂度指标几乎失明，AI喜欢把复杂逻辑平铺成if-else链，单看每个函数复杂度都不高，但合在一起的认知复杂度爆炸。

这就是为什么我们需要一套专门的量化体系。下面进入实操部分。

三、量化体系的五个核心维度

我们这套体系经过了四个项目的迭代校验，最终确定了五个互相独立、加总可形成综合技术债指数（Aggregate Tech-Debt Index，ATDI）的维度。

3.1 维度一：代码认知负载指数（Cognitive Load Index, CLI）

定义： 测量一个开发者从零开始理解某个文件核心逻辑所需的平均时间。

背景： 这个概念的灵感来自认知心理学中的“认知负荷理论”。代码的认知负载不是代码行数的函数，而是逻辑跳跃次数、跨文件引用深度的函数。Claude Code生成的代码特定问题是，它往往可以写出一个单文件内逻辑通顺的模块，但这个模块和你项目里其他文件的交互方式非常别扭。

我们的测量方法：

不是拍脑袋，我们设计了一套标准的测量流程：

1. 选取目标文件，准备一个干净的IDE环境；
2. 找一位未接触过该文件的中级开发者；
3. 计时：从打开文件到能准确回答“该文件的核心职责、输入输出、三个关键边界条件”的时间；
4. 单位：分钟。CLI = 理解时间(分钟) × 跨文件依赖数权重系数。

权重系数表：

真实数据： 我们在那个电商项目里测了8个核心文件。Claude Code生成的文件平均CLI为32.7，手写的同类文件平均CLI为18.4。差距最大的是一个促销规则引擎文件，CLI达到61，因为依赖了7个外部模块，且每个依赖都是为了满足一个prompt里的需求临时引入的，没有全局设计。

量化工具建议： 我们内部做了一个CLI计算脚本，用ESLint的依赖图插件提取import链路，自动计算跨文件依赖数，再配上计时数据。如果团队无法做人工计时，可以先用“import深度”作为CLI的简化近似值。

3.2 维度二：模块耦合度偏移率（Coupling Drift Rate, CDR）

定义： 测量项目模块间耦合度在引入AI代码后的增长速率。

背景： Claude Code最大的原型加速能力来自“它能快速理解你的需求并直接产出可运行代码”。但代价是它几乎不考虑你现有的模块分层。如果你告诉它“在订单模块加一个同步库存的功能”，它会直接在订单模块里写库存查询逻辑，而不是去调用已有的库存服务。每次快速原型迭代，都在破坏你的模块边界。

测量方法：

1. 使用dependency-cruiser或madge工具扫描项目模块依赖图；
2. 记录两个关键指标：模块间非法依赖数（违反分层规则的依赖）和循环依赖数；
3. CDR = (当前月非法依赖变化量 + 循环依赖变化量) / 基准月模块总数。

我们的实践： 我们在CI管道里集成了dependency-cruiser，每次PR合并后自动生成依赖报告。工具配置了分层规则：

• Controller层不应直接访问Repository层；
• Domain层不应依赖Infrastructure层；
• 不同业务域之间不应有直接调用。

初始配置后，我们设定了CDR阈值：当单月CDR超过0.15时（即每10个模块出现1.5个新的非法依赖），触发架构评审。

真实案例： 上线这套机制的第三周，一个Sprint内CDR达到了0.23。追查发现Claude Code在实现“批量导入订单”功能时，绕过OrderService直接调用了ProductRepository和InventoryRepository。开发者在原型验证阶段觉得很方便就没改，合入主分支后污染了依赖图。这个功能从原型到合并只花了2小时，但修复依赖污染花了1.5天。

3.3 维度三：注释依赖比（Comment Dependency Ratio, CDR-2）

为避免与上一维度缩写冲突，内部报告中常记为 CDR(注释) 和 CDR(耦合)，下同。

定义： 代码注释中用于“解释AI生成逻辑”的行数，与用于“解释业务逻辑”的行数的比值。

背景：这是我从三个项目review中提炼出来的独特指标。 传统代码的注释通常解释“为什么这么做”，业务规则、边界条件、临时权衡。但AI代码催生了一类新的注释，我把它们称为“投降注释”（Surrender Comments）。典型例子：

• // Claude建议这里用reduce，我没看懂但测试过了能跑
• // 不知道为什么要加这个判断，但去掉后库存就对不上了
• // AI生成的错误处理，暂时保留

这类注释越多，说明团队对代码的实际控制力越弱。而“缺失控制力”正是技术债的最危险形态。

测量方法：

1. 扫描项目中所有注释；
2. 人工分类（或训练一个分类器）：将注释分为“业务解释型”和“AI逻辑解释型”；
3. 注释依赖比 = AI逻辑解释注释行数 / 业务解释注释行数；
4. 健康阈值：小于0.3。危险阈值：大于0.7。

真实数据： 我们分析了那个电商原型项目的注释。在AI密集迭代的第三周，注释依赖比飙升到1.4（AI解释注释超过了业务注释）。同期的“投降注释”中，有37%在两个月后对应的代码被重构或废弃，说明当时AI生成的逻辑确实不可持续。

这个指标的优势在于它非常直观，不需要专业工具就能感知。我们现在的Sprint Review里，会让团队成员快速过一遍新增注释，“投降注释”率过高的模块自动进入重构列表。

3.4 维度四：脆弱测试覆盖率（Fragile Test Coverage, FTC）

定义： 测试代码中“仅验证AI当前输出”的快照式测试占比。

背景： Claude Code在帮你写代码时，默认也会生成对应的测试。但这些测试有一个致命特征，它们验证的是“代码长这样”，而不是“行为符合业务预期”。比如AI生成了一个calculateDiscount函数，测试就是assert这个函数在特定输入下返回特定输出，而这个特定输出是AI在同一轮对话里自己定下来的。

问题是：当需求变更、代码重构时，这些测试要么因为返回值变了而报错（假阳性），要么AI会“热心”地帮你把测试也改了（失去验证意义）。 传统的测试覆盖率指标在这里完全瞎了，你的覆盖率可能高达90%，但实际有效验证不到40%。

测量方法：

1. 识别项目中每个测试文件的生成来源，标注是否为AI生成；
2. 对AI生成的测试，进一步分类为“快照型”（验证具体值）和“规范型”（验证业务规则）；
3. FTC = 快照型测试用例数 / 总测试用例数；
4. 健康阈值：低于15%。

我们的实践： 我们在Jest配置里加了一个自定义reporter，标记每个test case的断言模式。pattern matching识别以下几种快照模式：

• expect(result).toBe(具体字面量)
• expect(result).toEqual(具体对象字面量)
• toMatchSnapshot()

自动标记后，每个Sprint跑一次FTC报告。

真实教训： 我们有一个物流费用计算模块，13个测试用例全部是AI生成的快照测试。后来业务方改了一个计费规则，开发者改了源码，AI“贴心”地把13个测试的期望值也同步修改了，所有测试通过，但实际上漏掉了一个边界场景（跨区计费），导致线上计费错误6小时。跟踪下来发现，这6小时线上故障的直接根因，就是FTC过高导致的虚假安全感。

3.5 维度五：重复决策密度（Repeated Decision Density, RDD）

定义： 同一业务规则在多个模块中被独立重新实现的次数密度。

背景： 这是Claude Code最隐蔽的技术债模式。当你分多次、在不同模块中让AI实现功能时，AI不会跨会话记住它之前的决策。结果是你可能在三个不同模块里，得到了同一条业务规则的三次独立实现，而每次实现的细节可能不同。

典型案例： 在我们的电商项目中，“VIP用户免运费”这个规则：

• 在订单模块里，AI判断的是user.level === 'vip'
• 在促销模块里，AI判断的是user.tier >= 3
• 在前端展示里，AI用了一个异步查询checkVipStatus()

三处实现，三种方式，没有一个统一的数据源。这在原型阶段完全没问题，功能都跑通了。但一旦VIP规则需要改动（比如增加银卡会员也免运费），就要改三个地方，且很容易漏掉。

测量方法：

1. 提取项目中所有“业务规则关键词”（如“免运费”“折扣”“限购”）；
2. 扫描代码中这些关键词的出现位置；
3. 人工判断同一规则的不同实现方式；
4. RDD = 重复实现的业务规则数 / 唯一业务规则总数；
5. 健康阈值：低于0.2。

四、跟踪框架：从数据采集到预警的完整链路

有了五个维度，下一步是把它们嵌入日常开发流程。这一节我会详细介绍我们怎么搭建这套跟踪体系，从工具选型到阈值设定，都是踩过坑之后的版本。

4.1 跟踪节点设计：不是每个Commit都跑全量分析

一开始我们犯了一个错误：每次Commit都触发全量五维分析。结果CI管道从40秒膨胀到11分钟，团队怨声载道。后来我们改为三级跟踪节点：

第一级：每次PR合并时（轻量）

• 只跑模块耦合度偏移率（CDR）检测
• 因为架构破坏是最紧急的技术债，需要实时拦截
• 耗时控制在30秒以内

第二级：每个Sprint结束时（中量）

• 跑CDR + CLI + CDR-2（注释依赖比）
• 产出“Sprint技术债简报”
• 在Sprint Review上过一遍

第三级：每个Release前（全量）

• 跑全部五个维度
• 生成ATDI综合指数
• 触发“技术债偿还决策会议”

这个分级机制让跟踪成本降到了可接受范围，同时保证了关键节点的数据覆盖。

4.2 工具链搭建

以下是我们当前的工具栈，全部开源或自建，没有商业依赖：

关键工具配置分享：

dependency-cruiser的分层规则配置（.dependency-cruiser.js片段）：

// 核心分层规则
{
  name: 'no-controller-to-repository',
  comment: 'Controller不能直接访问Repository',
  from: { path: 'src/controllers' },
  to: { path: 'src/repositories' },
  severity: 'error'  // CI阶段直接阻断
}

自建CLI脚本的核心逻辑：用madge提取依赖图→计算每个文件的import深度→结合人工标注的理解时间→输出每个文件的CLI值。

FTC检测的Jest自定义reporter：在afterEach钩子里检查断言模式，识别toBe、toEqual携带字面量或快照匹配的用例，打上fragile标签。

4.3 阈值设定与预警机制

这套体系的核心价值在于“自动预警，人工决策”。我们设定了三级警报：

🟢 绿灯区（健康）： ATDI < 40，且各子维度均在健康阈值内。

• 行动：正常迭代，无需特殊处理。

🟡 黄灯区（关注）： ATDI 40-70，或任一子维度超标。

• 行动：超标维度对应的模块进入“观察列表”，下个Sprint重点关注。

🔴 红灯区（危险）： ATDI > 70，或三个以上子维度同时超标。

• 行动：冻结AI生成新功能的权限，当个Sprint只做技术债偿还，直到ATDI降至黄灯区。

真实触发案例： 今年三月我们的核心项目触发了一次红灯。ATDI达到76，其中CDR和FTC双双超标。团队执行了一次“技术债清算Sprint”，两周内停止了所有功能开发，集中修复耦合问题和替换脆弱测试。修复后ATDI降到38，更重要的是团队对这套指标产生了真正的信任：他们看到了数字下降对应的代码质量提升。

五、团队协作：量化数据如何驱动决策和行为改变

工具和数据只是基础，真正的挑战在于让团队接受并行动。这一节分享几个实际的团队协作机制。

5.1 “AI代码责任归属”制度

我们用Claude Code的第一个月发现一个现象：开发者对AI代码的责任感明显低于自己写的代码。 Review时会更宽容，出问题时会更倾向于甩锅给AI（“这是Claude生成的，我不知道它为什么这么写”）。

为了解决这个问题，我们定了一条硬规矩：任何合入主分支的AI生成代码，合入者对其负有100%的维护责任。 不能说“这是AI写的”。因为你选择了使用AI、选择了审核通过、选择了合并，这是你的决策，不是AI的。

配合这个制度，我们在Git commit信息里加了ai-generated: true/false标记，可以追踪哪些文件是AI参与的。两个月的数据显示：标记为AI生成的文件，后续被重构的概率是手写文件的2.3倍；但“合入者责任制”推行后，AI代码的首次Review通过率下降了15%（审查更严），但上线后的Bug率也下降了22%。

5.2 Sprint Review中的“技术债五分钟”

每个Sprint Review我们固定留出五分钟，过三张幻灯片：

1. 本周ATDI趋势图，和各维度的变化；
2. Top 3高风险模块，按CLI或CDR排序的“重灾区”；
3. 技术债偿还进度，上个Sprint承诺偿还的债，实际偿还了多少。

效果： 第三个月开始，团队会主动在Sprint Planning里预留“还债时间”。因为数据摆在明面上，很容易达成共识，不需要CTO拍桌子说“我们要重构”。

5.3 不同职级的责任矩阵

这个矩阵让每个人知道自己的责任边界。一线开发者不需要操心架构层面的事，但需要对自己文件的CLI负责；而架构师不需要审查每一行代码，但需要监控ATDI趋势并做出阶段性决策。

六、不同阶段的取舍策略

不是所有阶段都需要同样的标准。这是量化体系最容易被误用的地方，对原型阶段的项目施加生产环境的质量标准，结果就是所有人都不再用AI，因为“用了就要达标”。我们内部定义了三个阶段的差异化策略。

6.1 原型探索期（第0-3周）

核心目标： 快速验证产品可行性，速度优先于质量。

ATDI容忍度： 只要CDR不触发红灯（＜0.3），其他维度基本不管。

行动规则：

• 所有Claude Code生成代码放在独立分支，严禁直接合入主分支；
• CDR检测仍然运行，因为架构破坏是最不可逆的；
• 其他维度只记录数据，不设阈值，不触发告警；
• 开发者被鼓励“用AI尽情探索”，但要接受“原型分支的代码大概率不会直接用于生产”。

为什么CDR仍然要管？ 因为即使在原型阶段，模块依赖关系一旦被污染，后续重构成本是指数级的。我们有过教训：原型阶段一个循环依赖没被发现，两个月后这个依赖链上挂了9个模块，解耦花了整整四天。

6.2 产品化过渡期（第4-8周）

核心目标： 保留有价值的原型代码，系统化地将原型转化为可维护的产品代码。

ATDI容忍度： 进入黄灯区是正常的，但不能突破红灯阈值（ATDI < 70）。

行动规则：

• 启动“原型代码审计”，逐文件过CLI和FTC；
• 高CLI文件（>40）在合入主分支前必须由另一位开发者独立理解并签字确认；
• FTC >30%的模块，必须手动补写业务规则型测试；
• 每周运行CDR分析，非法依赖在合并前清零。

这个阶段的关键认知： 不是把所有AI代码重写一遍，而是筛选出“值得保留的核心逻辑”进行精炼。我们通常在原型阶段结束后保留约40-50%的AI生成代码，其余手动重写或从零设计。保留标准是：CLI <30且FTC <25%。

6.3 生产维护期（第9周起）

核心目标： 持续交付价值，技术债处于可控范围。

ATDI容忍度： 目标维持在绿灯区（ATDI < 40），允许短期波动到黄灯区。

行动规则：

• 全量五维跟踪全部生效；
• 每个Sprint预留15-20%的时间用于技术债偿还；
• 当ATDI连续两个Sprint处于黄灯区时，触发一次“技术债偿还冲刺”；
• AI继续用于新功能开发，但每次AI生成的代码必须满足“绿灯标准”才能合入，CLI <35、CDR不增加非法依赖、FTC增量 <20%。

七、常见误区与校准

在实际推行这套体系的过程中，我们踩过不少坑，也观察到其他团队容易陷入的几个误区。

7.1 误区一：把ATDI当作KPI考核指标

问题： 有团队把ATDI直接设为开发者的绩效考核目标，结果开发者开始“刷数据”，为了避免认知负载高，把大文件拆成碎片化小文件，反而恶化了可读性；为了降低FTC，把AI生成的测试删掉但不补充业务测试。

纠正： ATDI是团队健康指标，不是个人能力指标。它服务于“发现问题→推动改进”的闭环，而不是“打分→排末位”。我们的策略是：只公开团队级ATDI趋势，不拆解到个人；Sprint Review上讨论的也是“哪些模块需要关注”而不是“谁的代码债多”。

7.2 误区二：只看数字不看上下文

问题： 不是所有高CLI都是坏的。某些核心业务逻辑本身就很复杂，认知负载高是合理的。同样，RDD也不是零最好，有时候为了性能或隔离性，有意重复实现是值得的。

纠正： 每个维度的数据必须配合“人工判断标签”。我们给每项超标数据加一个字段：is-acceptable: true/false，由Tech Lead在评审时标注。可接受的超标不参与ATDI加权。半年数据显示，约18%的CLI超标、31%的RDD超标属于“可接受的合理复杂度”。

7.3 误区三：追求零技术债

问题： 有的技术负责人看到ATDI不是个位数就焦虑，要求每个Sprint都把技术债清偿干净。结果团队疲于还债，功能交付严重滞后。

纠正：技术债不是坏东西，未管理的技术债才是。 我们内部有一句话：“技术债是你为了更快交付而做的贷款。问题从来不是你贷了款，而是你没有还款计划。”ATDI的目标不是趋近于零，而是稳定在绿灯区。原型阶段可以容忍高债，因为有明确的“还债窗口期”和“偿还预算”。

八、这套体系的局限性与适用边界

坦诚地说，我们的体系远非完美。以下是我目前认知到的几个关键局限：

第一，高度依赖人工判断。 CLI需要人工计时，CDR-2需要人工分类注释，RDD需要人工识别业务规则。我们尝试过用LLM做自动化分类，准确率在75-80%，还没达到可完全替代人工的水平。对于小于5人的团队，这套体系的维护成本可能过高。

第二，对非JS/TS技术栈的适配不足。 我们的工具链全部基于JavaScript生态（Jest、dependency-cruiser、madge）。虽然核心方法论可以平移，但具体工具需要对等替换。Python生态有pytest、import-linter等替代品，Java生态有ArchUnit、JDepend，但我还没有在其他技术栈做过完整验证。

第三，ATDI的权重设定带有业务偏见。 我们当前五个维度的权重是基于“可维护性优先”的偏好设定的。如果你的业务场景对“正确性”的要求远高于“可维护性”（比如金融交易系统），权重分配需要重新校准，FTC的权重应该大幅提高。

第四，只跟踪了代码层面的技术债。 Claude Code还会引入文档债（没有更新文档）、知识债（只有一个人理解那段AI代码）、基础设施债（AI生成了不适合生产环境的配置）。这些我们目前还无法量化，只能通过流程规范（如强制文档更新、知识分享会）来软性约束。

九、给不同团队的行动建议

基于我们的经验和局限性认知，我给不同类型团队的建议如下。

9.1 如果你是一个独立开发者或2-3人的小团队

不建议完整搭建这套体系。 维护成本会吃掉你的开发时间。

替代方案：

• 只跟踪CDR（模块耦合），用dependency-cruiser一键扫描，零维护成本；
• 手工维护一份“技术债清单”，一个共享文档，每次AI生成代码后自己Review时记录觉得“将来会踩坑”的地方；
• 定期“AI代码日”，每月抽一天，集中过一遍近期AI生成的代码，删除没用的、重构有问题的。

核心原则： 与其建体系，不如养习惯。

9.2 如果你是一个5-15人的中小团队（我们的情况）

选择性搭建，从两个维度开始。

我们建议的启动路径：

1. 第一个月： 只上CDR（耦合检测），因为它的自动化程度最高、反馈最快、ROI最明显；
2. 第二个月： 加上FTC（脆弱测试检测），因为它直接影响线上质量；
3. 第三个月： 引入CLI（认知负载），在Sprint Review上过高风险文件；
4. 稳住三个月后： 再考虑CDR-2和RDD。

不要一上来就做全量五维。 我们在内部推了两次才成功。第一次推全量，团队反弹严重（“怎么加了这么多流程”），第二次从CDR单点切入，三个月自然扩展到全部。

9.3 如果你是一个20人以上的中大型团队或有多条业务线

建议投入资源做完整搭建，并配备专人维护。

理由：

• 多线并行时，AI代码的技术债最容易在交叉依赖处爆炸；
• 大团队的代码所有权分散，“心理所有权”问题更严重；
• 有专人维护的ATDI看板可以成为技术治理的数据基础设施。

额外建议： 考虑设立一个“AI代码审计”轮值角色，每个Sprint由不同Tech Lead轮流担任，负责审核当周所有AI生成代码的合并请求、产出ATDI周报。这个角色不是为了找茬，而是确保“有人在全局视角关注债的变化”。

十、结语

回到文章开头那个问题：当CTO问我“三个月后维护这套代码的真实成本是多少”，我当时答不上来。现在我可以给他一个数字，基于ATDI的综合评估、基于五个维度的分项数据、基于偿还计划的估算工时。这个数字不一定精确，但它是可讨论、可追踪、可优化的。这比“我觉得代码质量还行”或“我觉得烂透了”有价值一百倍。

Claude Code不是一个技术债制造机，也不是一个技术债清偿器。它是一个效率放大器，你开发得快，积累债也快；你偿还债快，修复也快。 关键是你的团队有没有配套的量化能力和偿还纪律。

量化不是限制创新，是为创新划出安全区。你不需要在“用AI快速交付”和“保持代码健康”之间二选一，你需要的是知道自己在哪里、要往哪里去。

下一步怎么做？ 我建议从明天开始做三件事：

1. 在你当前的项目里跑一次dependency-cruiser，看看有没有非法依赖已经潜伏在代码库里；
2. 打开你最近一个AI生成的文件，真实计时，你完全读懂它花了多久；
3. 在下一次Sprint Planning里，留出10%的时间，明确标记为“技术债偿还时间”，哪怕只还一个小模块。

从这三件事开始，你就已经在做技术债的量化跟踪了。完整体系可以慢慢搭，但“开始量化”这件事，明天就能做。