用 mattpocock/skills 给一个 73 万行的十年 Java 系统
装一条「能停下来的传送带」

00摘要：十二条核心论断

这份手册不是技能说明书的中文版。它的论点是：在一个十年高龄的单体上，Matt Pocock 技能包的价值不在于"让 AI 写得更快"，而在于"让每一次 AI 的产出都能被更便宜地验证"。下面是支撑该论点的十二条论断，后续每一章都服务于其中一条。

1. 主瓶颈是反馈延迟，不是代码生成速度。73 万行 Maven 单体的全量构建与测试动辄数十分钟，而 TDD 技能的红-绿循环只有在"单次反馈 ≤ 分钟级"时才成立。先让某一个模块的单测能在 60 秒内跑完，再谈让智能体写功能——这是所有工作的第一步。
2. 技能包的本体是一条「先压缩歧义、再动手」的流水线。它的五个修复目标（对齐、啰嗦、跑不起来、糊球赋值、导航慢）分别对应 grill → glossary → tdd → review → retro。跳过前面的阶段直接 implement，等于把下游的全部负担推给代码评审。
3. 对这个系统最有杠杆的一个决策，是把"投标"和"项目"拆成两个概念。五个子模块横跨两个生命周期。旧系统最常见的熵源是用同一个实体承载中标前后，于是评审、作废、变更全部要靠 status 分支打补丁。这条分界线应当先落在 GLOSSARY.md 里，再落到包结构上。
4. 在这个体量的代码库上，AI 大概率先让你变慢，而且你察觉不到。METR 的 RCT 选取的正是"平均 10 年历史、百万行级"的成熟仓库，结果是慢 19%，而参与者事后仍自认为快了 20%。感知与实测的缺口意味着：任何"我觉得快了"的证据等级为零。
5. AI 是放大器，而 15 模块单体是紧耦合：这是最不利的组合。DORA 2025 的核心结论是"AI 放大既有强弱"，并明确指出紧耦合架构 + 缓慢反馈循环的团队几乎拿不到收益。先降耦合，再谈加速。
6. 默认工作模式下 AI 会把"整理"这件事挤掉。GitClear 对 2.11 亿行变更的纵向分析显示：被移动/重构的行从 24.8% 降到 9.5%，复制粘贴从 8.4% 升到 12.3%，重复代码块增长约 8 倍。对一个债已经很重的系统，这是负利滚利。
7. 防腐的着力点不是"让 AI 少写"，而是"让人工性的验证更便宜"。code-review 技能的双轴设计（Standards / Spec 并行子智能体）与 Fowler 十二种代码气味基线，本质是把验证环节的成本后者，而不是把闸门设在生成端。
8. 在欠缺测试的老系统上，TDD 的第一步是写"表征测试"，不是写新功能的测试。tdd 技能要求"只在事先约定的接缝处测试"。这个系统在建立特征锁之前没有可靠接缝，因此第一个 ticket 永远是给即将触碰的旧代码加表征测试（Michael Feathers 的做法）。
9. 五个子模块不是五个同等规模的工作包，它们的"blast radius"相差一个数量级。新增子模块是垂直切片；而"基础信息维护"中改动一个被全系统引用的字典/枚举字段属于宽重构，必须按 expand–contract 三段走，不能塞进 tracer bullet。
10. 上下文窗口装不下 3412 个文件，所以"上下文指针"是一等工程手段。implement-spec 明确要求子智能体之间通过指针而非复制内容通信，探索结果落在仓库之外的 Markdown 笔记里。这一点在你的单体上比其他项目重要得多。
11. 这套技能要真正生效，必须先做一次仓库级配置。to-spec、to-tickets、code-review、wayfinder 全都以"问题跟踪器已经被告知"为前提，未配置就直接报错。第一步是 /setup-matt-pocock-skills，而且内网环境应当选本地 Markdown 跟踪器。
12. 技能必须本地化，直接使用是半成品状态。作者的立场是"小而可组合、随便改"。对这个系统至少需要自研三个技能：快速反馈通道、Maven 模块边界守门、遗留代码安全网。它们决定了前九条能不能落地。

01先给系统画像：它属于哪一类难题

在谈任何技能之前，必须先把这套十年单体的"难题类别"判定清楚。因为后续所有纪律的强度都由这个判定决定：新项目可以宽松，高默契 + 紧耦合 + 弱自动化验证的存量系统必须严格。

1.1 三个特性，决定了纪律的强度

这套系统同时具备三个特性，而这三者的组合恰好是 AI 辅助开发收益最低的区域：

1.2 五个子模块跨越了两个生命周期，不是一个

把用户列出的五个子模块按时序摆到业务时间轴上，会看到一个被很多遗留系统抹平的分界：中标前，处理的对象是"投标机会"；中标后，处理的对象才是"项目"。这两件事的字段、状态机、权限、留痕要求都不同。旧系统最常见的熵源就是把它们塞进同一张主表和同一个"项目"名词里，于是所有差异只能靠 if (status == 6) 之类的分支去补。

1.3 派生出一个数量级：这笔债值多少钱

按 Sonar 公开的 2023 年基准——每百万行代码每年约产生 30.6 万美元技术债敞口、约 5,500 开发小时用于修复——线性折算到 73 万行，约 22 万美元 / 4,000 小时 / 年，折算约 2 个人年。

02为什么是这套技能，而不是别的

市面上"接管整个流程"的框架（GSD、BMAD、Spec-Kit）与这套技能的分野，不在于谁更全，而在于出了问题时你能不能定位到具体某一句话。这是选择它的第一性理由，对一个无法承受流程黑箱的存量系统尤其重要。

2.1 作者的自我定位：小、可改、可组合

仓库 README 的开场自述是"My agent skills that I use every day to do real engineering - not vibe coding"，并明确与 GSD / BMAD / Spec-Kit 划清界限：

"像 GSD、BMAD 和 Spec-Kit 这类方案试图接管整个流程来解决问题。但这样做同时夺走了你的控制权，并且让流程里的 bug 难以修复。"

"这些技能被设计成小而易改、可组合，与任何模型无关……随便 hack，改成你自己的。"

这段话直接决定了本手册第 10 章的立场：不要原样使用，要在第二个 Sprint 开始本地化改造。第 10.4 节给出三个针对本系统的自研技能草案。

2.2 它的组织原理：一条轴、两种调用权

技能包只有一个真正的分类轴——谁能调用它：

一条硬约束（.agents/invocation.md）：用户可调技能可以调用模型可调技能，但永远不能调用另一个用户可调技能。这就是为什么 to-spec 里写着"如果用户没跑过 setup，就告诉用户去跑 /setup-matt-pocock-skills"，而不是自己调用它——它不是调用不到，而是被设计性地禁止。这条约束保证了任何一次长流程都由人掌着方向盘。

2.3 它修复的四个失效模式，恰好对应你的四个痛点

03技能地图与最小可用配置

这一章给出可直接执行的安装、配置与路由规则。目标状态：明天早上团队里任何一个人都能正确启动一次完整的实现流程，不需要记住 27 个技能。

3.1 安装：两条路，不要两条都走

官方文档给了两种安装哲学，并且明确警告二者只能选一：同时安装会让每个技能在你机器上都出现两次。

claude plugins install mattpocock-skills

npx skills@latest add mattpocock/skills

3.2 一次完整的流程长什么样

下图是这套技能在"实现一个新模块"场景下的标准编排。上层六个方块是人敲命令触发的编排层，下层十一个胶囊是被它们自动取用的能力层。箭头方向即推荐顺序。

3.3 最小可用配置：三条必须一次答对的问题

to-spec、to-tickets、code-review、wayfinder 四个技能的前提都是"仓库已经告诉过我它的跟踪器在哪"。没跑过 setup 就直接调用，它们不会替你猜，只会报错让你回去跑 setup。因此这是真正的第 0 步。

写完之后，仓库根部的 CLAUDE.md（若不存在则 AGENTS.md）会增加一段「Agent skills」区块，它只包含三行导航指针，指向 docs/agents/issue-tracker.md 等文件。这个设计值得照抄到你的项目：CLAUDE.md 应当极为克制，只放指针，不放内容（见第 11 章反模式 #9）。

3.4 当前现状探测：动手前先问出五件事

因为你要在别人的十年代码上动刀，图 1 只是假设。先把下面五条命令跑一遍，把答案写进 GLOSSARY.md 的备注与规格草稿：

# 1. 模块边界：本次改动实际会跨越哪几个 Maven 模块
mvn -q -o dependency:tree -Dincludes=com.yourorg | head -60

# 2. 有没有 Conway 式共用实体：搜 Project / 实体名在哪些 module 出现
rg -l "class Project|PO\b|ProjectEntity" --glob "*.java" | xargs -I{} dirname {} | sort | uniq -c

# 3. 状态机是否散落：数一下 status== 的分支密度
rg -c "status\s*==|getStatus\(\)\s*==" --glob "*.java" | sort -t: -k2 -rn | head -20

# 4. 反馈延迟基线：单模块跑一次测试的墙上时间
time mvn -q -pl <目标模块> -am -DskipITs test

# 5. 现有 seams：有没有能直接作为表征测试入口的 Service 接口
rg -l "@Service|@Repository" --glob "*.java" | wc -l

04理论根基：每条理论都必须能推出一个具体动作

这一章只收录能推出工程动作的理论。凡是只能当比喻用、推不出具体该改哪条命令或哪个文件的，一律不收。每条给出：理论 → 推导 → 在你这个 15 模块系统上的具体动作。

05第一优先级：把「项目计划管理」的术语砸实

作者的论证很直接：智能体被丢进一个项目里被迫边做边猜术语，于是它用二十个词表达本来一个词就够了。统一语言的价值不止于省 token——它让变量、函数、文件的命名自动一致，从而让检索变得更准。

5.1 grilling 的机制：前沿、轮次、必须给推荐答案

grilling 是整个技能包复用次数最多的原语。它的协议有四条硬规则：

1. 把对手表示为设计树——每个决策分叉出挂在它下面的决策。
2. 按"前沿"问，而不是按顺号问题清单问。frontier = 所有前提已经尘埃落定的决策，也就是"现在问不会猜错"的那批。
3. 一轮问完整个前沿，每个问题编号，并必须给出你的推荐答案（➡️）。
4. 找事实是你（智能体）的活，不是人的活。前沿里需要事实（文件系统、命令行）的，派子智能体去查，别问人；别因为等待而阻塞——只把依赖该事实的问题推到下一轮。

会话结束的条件是"前沿为空"：设计树的每个分支都走过一遍，没有剩下的隐含假设。而且在你确认双方达到共识之前，不许动手。

一次 Round 1 示范（针对本项目，推荐答案已给出）

这三题的答案会分别落成 ADR-0001 / ADR-0002 / ADR-0003，见 5.3。

5.2 可直接抄用的术语表草案

下面是按卢文件格式写好的种子，条目内容需要根据你们实际的申请表字段校准——但结构与"Be opinionated / 给 Avoid 列"这个做法是照抄的。核心规则：定义一到两句、只定义"它是什么"而非"它做什么"、只收录本项目特有的概念（超时、通用错误码这类不收）。

# 投标上下文 bid-intake

我方从识别招标信息到递交投标文件这一段的信息对象。此上下文内的东西都还不是"项目"。

## Language

**Bid Opportunity（投标机会）**:
我方识别出的一条可参与的外部招标线索及其跟踪状态。
_Avoid_: 项目前期、招标、业务机会

**Invitation to Tender（招标）**:
甲方发出的招标行为与招标文件本身。方向是甲方→我方。
_Avoid_: 投标（混淆方向）、标讯

**Bid（投标）**:
我方对一次招标的响应行为与其提交的整套文件。方向是我方→甲方。
_Avoid_: 标书（既指文件又指行为）、报价

**Package（标段）**:
一份招标文件拆成的可独立投标、可独立中标的最小单元。
_Avoid_: 包、标段包、标包

**Bid Opening（开标）**:
甲方公开拆封投标人提交的文件的时点与过程。
_Avoid_: 开标（与"开始评标"混用）

**Award Notice（中标通知书）**:
甲方向我方正式发出的中标确认文件。是本上下文唯一能触发下一个上下文的事件。
_Avoid_: 中标结果（太宽，含落标）、成交通知

**Award Outcome（中标结果）**:
一次投标的最终结局，取值：中标 / 未中标 / 主动弃标。含结果日期与原因。
_Avoid_: 结果（任何含糊说法）

# 项目上下文 project-delivery

中标后进入内部交付与评审阶段的信息对象。仅由 Award Notice 触发创建。

## Language

**Project（项目）**:
中标通知书生效后，公司正式启动的一次内部交付活动。是本上下文的根实体。
_Avoid_: 工程、订单、标的

**Project Initiation（立项）**:
把已中标的投标机会登记为公司内部项目的动作。此前不得存在 Project。
_Avoid_: 建项、立项申请（与审批动作混用）

**Economic Review（经济评审）**:
对项目的成本、预算、付款与保证金等经济条款的独立评审。
_Avoid_: 财务评审、成本审核、商务评审

**Technical Review（技术评审）**:
对项目的技术方案、工期、资源与实施可行性的独立评审。
_Avoid_: 方案评审、技术审核

**Review Verdict（评审结论）**:
一次评审给出的正式结论。取值：待审 / 审核通过 / 附条件通过 / 退回修改 / 否决。
_Avoid_: 评审状态、审核标志、isPassed

**Review Comment（评审意见）**:
评审人针对某一具体条款提出的可追溯书面意见，含提出人与处理状态。
_Avoid_: 备注、说明

5.3 三条候选 ADR 的判断

技能对 ADR 的把门极严——必须同时满足三条：难以逆转 / 缺了上下文会让人困惑 / 是真实权衡的结果。缺任一条就不写 ADR。按此筛：

对照：还会触发 ADR 的情形之一是"用户在 grill 中以一个站得住的理由否决了某个候选"——此时应主动提议："要不要把你这个理由记成 ADR，免得以后的架构复查又推荐一遍？"

06接缝：整个方案的地基在哪里

tdd 技能有一条极硬的规则："只在事先约定好的接缝处写测试。没有确认过的接缝，一个测试都不许写。"对一个没有测试的十年系统，这条规则会立刻暴露真正的问题——你现在根本没有可用的接缝。

6.1 第一张 ticket 永远是表征测试，不是新功能

这里要引入技能包之外的一个必要补充：Michael Feathers 的表征测试（characterization test）。技能作者自己强调他关心的是"care about the design of the code"，但没写如何处理零测试遗产，而 Feathers 的做法正好补上缺口：

6.2 这个系统的四层接缝地图

把 73 万行按"测试它需要付出多少"重新分层，会得到下面这张图。深浅不是艺术效果，而是单位时间能得到多少次反馈。

6.3 依赖四象限：决定每个接缝要不要加 port

技能给出一张判断表，用来决定"这个接缝值不值得抽象出一个接口"。核心纪律是 T3：只有一个适配器的接缝是假的，别加。

来源：skills/engineering/codebase-design/DEEPENING.md。原词为 In-process / Local-substitutable / Remote but owned / True external。

6.4 三条反模式：技能自己点名的坏测试

07拆票：五个子模块的任务图与那个"宽重构"陷阱

to-tickets 把工作拆成追踪弹式的垂直切片，每张票声明它阻塞谁。它同时有一条极其重要的例外规则，而这条例外恰好命中你的"基础信息维护"。

7.1 垂直切片的三条硬规则

• 纵向而非横向：每个切片窄而完整地穿过所有层（表结构 → 服务 → 接口 → 测试），不是"先把所有 DAO 写完"这种横向一层。
• 单独可验证：一个切片完成后单独可演示或可验证。
• 装得进一个全新的上下文窗口：切片大小的上限由 context 决定，而不是由业务重要性决定。这一点对 3412 个文件的系统尤其关键。

每条票在发布前必须亲自问过人三个问题：颗粒度合适吗？阻塞边对吗（每张票只依赖真正门控它的票）？有没有该合并或该再拆的？迭代到人认可为止。

7.2 那个例外：什么叫"宽重构"，为什么要排除出垂直切片

技能还给出最后一道保险：如果连批次都无法各自保持绿色，就让它们共用一个集成分支，全部阻塞在一个"集成并验证"票上，此时"绿"只在这一处承诺。

在你的五个子模块里，属于宽重构的典型情形是：

7.3 五个子模块的任务图

下图给出一组推荐的任务图。"前沿（frontier）"是所有前置都已完成、可以立刻开工的票的集合——这个概念在 to-tickets、grilling、implement-spec、wayfinder 四个技能里反复出现，是这套方法论的核心概念之一。

7.4 对照：怎样才算切得好

08证据全景：正反同列，并标注证据强度

这一章把支持与反对的证据放在同一张表里。任何只引一边的结论都不可信——尤其当一个 25 万+ 星的技能包正处在舆论的顺风上时。每条都标注来源、年份与证据强度：RCT > 受控实验 > 大样本观察 > 自报调查 > 单一案例 > 建模。

8.1 主证据：为什么在这个系统上，"先用起来"大概率是错的

8.2 J 曲线：这笔学费要交多久

DORA 团队把 AI 采纳早期的稳定性下滑明确称为"expected J-Curve (or tuition cost)"——并给出了压平曲线的处方：投资平台工程 + 强版本控制实践 + 小批量size。这条处方与本手册第 06、07 章的建议是同一件事的两种说法。

09度量：怎么知道它到底有没有用

METR 那 19% 与开发者自认为快 20% 之间的缺口，直接推出一条度量原则：主观感受不能参与度量，只能作为线索。下面是三层指标与四条防作弊原则。

9.1 三层指标

9.2 四条反 Goodhart 原则

1. 绝不把"AI 生成的行数"当产量。它同时是分子也是分母的一部分——GitClear 的重合数据已经证明这条会导致什么。
2. 每个速度指标配一个质量指标成对看。单票周期 P50 下降而回滚率上升，结论是"变快了她——但没有用"，不能只报前者。
3. 优先采用不可人为修饰的客观指标。构建墙钟时间、回滚率、CI 红灯数都不由填报者决定；自评量表最容易漂移（这正是 METR 那 39 个百分点的缺口）。
4. 基线必须先测两周。没有基线的任何百分比改善都是无从验证的主张。建议把 T1 / T2 两张前置票的周期当作天然基线段。

1090 天落地路线图

这份路线图有一个反常识的安排：前三十天禁止让智能体生成任何业务代码。理由是第 08 章的证据——在紧耦合、慢反馈、高默契约定的系统里，先把前置的安全网与快速反馈建好，是唯一能把 J 曲线压平的做法。

10.1 成熟度阶梯：先判断自己在哪一级

10.2 90 天安排

10.3 投资配比建议

10.4 本地化：至少自研这三个技能

作者的原话是"Hack around with them. Make them your own."。下面是针对本系统最值得自己写的三个技能，都遵循同一套格式约定：YAML frontmatter + 极短的正文 + 按需引用的附属文件。

草案 A · 快速反馈通道（建议命名 legacy-fast-feedback，模型可调）

---
name: legacy-fast-feedback
description: Use when running or changing tests in this Maven reactor, or when a
  test command is needed. Knows which modules are cheap to test alone and which
  fan out through -am.
---

先跑 docs/agents/feedback-baseline.md 里记录的最快命令。
对目标模块优先尝试：mvn -o -q -pl <mod> -am -DskipITs test
不得使用全量 reactor 构建来验证单个模块。
若某模块 -am 会拖入超过 4 个模块，先查阅上述文档里的替代切片。

禁止为了"能跑起来"而跳过测试（-DskipTests / -Dmaven.test.skip=true）。

草案 B · 模块边界守门（建议 maven-boundary-guard，模型可调）

---
name: maven-boundary-guard
description: Use when adding imports across Maven modules, adding a dependency to
  pom.xml, or placing a new class. Classifies each dependency into the four
  DEEPENING categories.
---

跨 import 或新增 pom 依赖前，先回答三个问题：
1. 这次依赖属于 in-process / local-substitutable / remote-owned / true-external 哪一类？
2. 若为 remote-owned，接缝处是否需要 port？是否已有两个及以上适配器？
   只有一个适配器的接缝是假接缝，不要引入。
3. 新增的类不得同时承担业务规则与 I/O。业务规则必须独立于 Spring 容器可实例化。

违反第 3 条时，先在 target seam 处剥离规则，而不是写集成测试绕开。

草案 C · 遗留代码安全网（建议 legacy-safety-net，用户可调）

---
name: legacy-safety-net
description: Weave characterization tests around a piece of old code before any
  change is allowed to touch it.
disable-model-invocation: true
---

改动任何十年以上、无测试的旧代码之前：

1. 找出即将被触碰的最小行为集合（一个服务方法的输入/输出，或一张表的写入结果）。
2. 用 JUnit 或 Approval 风格把"它现在实际做什么"冻结下来。允许对现有 bug
   做记录性断言，并在测试名里标注 @Characterization 与日期。
3. 基线第一次必须由一个人逐字段过一遍并签字（写在票的评论里）。
4. 测试必须能在 60 秒内单独跑完，否则先处理第 3.3 节的第 4 条测量。

红线：不得在没做完第 2 步的情况下让任何智能体改动该段代码。

11反模式清单

每条给症状与修正。症状一律写成"在这类系统上的具体样子"——因为泛泛而谈的反模式，在人们恰好犯了它的时候也认不出来。

11.1 战略层

11.2 工程层

11.3 治理层

12结论与判断

三条最重要的提醒：本手册未访问你的代码库，因此图 1 的架构判断与 5.2 节的术语内容均为待校验的假设；图 5 的 J 曲线是建模值而非实测值；第 1.3 节的成本折算是线性外推的建模结果，不可用于预算。

13参考来源

按证据类型分组。核心部分全部回溯到一手来源——技能的原始 Markdown、研究报告原文、官方博客。

一手来源：技能包本身

1. mattpocock/skills 仓库 README（我去用作应该注意的 Installing 与 Why These Skills Exist 两节）：https://github.com/mattpocock/skills（MIT）
2. skills/productivity/grilling/SKILL.md — 设计树、前沿、轮次协议，"找事实是你的活"
3. skills/engineering/grill-with-docs/SKILL.md — 两行：调用 grilling + domain-modeling
4. skills/engineering/to-spec/SKILL.md — 规格模板、接缝数量、"不超过一个"原则
5. skills/engineering/to-tickets/SKILL.md — 垂直切片三条规则、宽重构的 expand–contract 定义
6. skills/engineering/implement/SKILL.md 与 implement-spec/SKILL.md — 上下文指针、前沿并发、worktree
7. skills/engineering/tdd/SKILL.md — 只测约定接缝、三条反模式、重构不属于循环
8. skills/engineering/codebase-design/SKILL.md 与 DEEPENING.md — 深模块词汇表、依赖四象限、replace-don't-layer
9. skills/engineering/code-review/SKILL.md — 双轴并行、Fowler 十二种气味基线
10. skills/engineering/domain-modeling/SKILL.md 与 GLOSSARY-FORMAT.md — ADR 三门槛、术语表格式
11. skills/engineering/setup-matt-pocock-skills/SKILL.md — 三 Section、五种 triage 标签、CLAUDE.md 区块
12. skills/engineering/improve-codebase-architecture/SKILL.md — 五个摩擦探测点、"勘察不是救援"
13. skills/engineering/retro/SKILL.md — 六个改进类别、机械性问题优先机械化
14. .agents/invocation.md — 两类调用权的定义与"不得跨调用"的硬约束

一手实证

1. METR（2025-07）：Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity。RCT，16 名开发者、246 个任务，仓库平均百万行级、约十年历史。+19% 耗时，预测 -24%，事后自评 -20%。原文含"我们不提供证据的主张"清单。
2. Google Cloud DORA（2025）：State of AI-assisted Software Development，n≈5,000。AI 是放大器；AI 采纳与交付不稳定性正相关；紧耦合 + 慢反馈团队收益最小。另有 DORA The ROI of AI-assisted Software Development（2026）给出标准化效应量与J 曲线（学费成本）表述。
3. DORA（2024）：n=39,000+。AI 采纳每提高 25%，交付速度下降 1.5%、稳定性下降 7.2%该组数字来自二手报道转述，正式引用前请回到报告原文核对。
4. GitClear（2025）：AI Copilot Code Quality，2.11 亿行变更（2020—2024）。move/refactor 24.8% → 9.5%；copy/paste 8.4% → 12.3%；重复块约 8 倍；churn 3.3% → 5.7%。
5. Stripe（2018）：The Developer Coefficient，与 Harris Poll 合作，1,000+ 开发者与 1,000+ 高管，美英法德新。每周 17.3 小时 / 42% 用于债与坏代码。自报调查，且年份较早
6. Stack Overflow 开发者调查（2025）：不信任 46% / 信任 33%。经 DORA 综述引用，原始问卷建议回溯核对。
7. Sonar（2023）：每百万行代码每年约 30.6 万美元债敞口、约 5,500 修复小时。厂商基准，本文仅用于数量级外推

反证据（有意保留）

1. MIT / Princeton / UPenn：4,800 名开发者数据，Copilot 组任务完成数 +26%。
2. GitHub 官方实验：同一任务快 55.8%；可读性 +3.62%、可维护性 +2.47% 等小幅正向。
3. Qodo（厂商数据）：AI 工具配 AI 代码评审时质量改善报告率 81% vs 55%。强度最低，但结论方向与本文一致

方法论补充

1. Michael Feathers，《修改代码的艺术》：表征测试与接缝的概念来源。技能包本身未覆盖零测试遗产的处理，这里是必要补充。
2. John Ousterhout，《软件设计的哲学》：深模块原创表述。注意技能包明确拒绝其"行数比值"定义，改用 depth-as-leverage。
3. David Thomas & Andrew Hunt，《程序员修炼之道》："反馈的速率就是你的速度上限"。被 README 引用两次。
4. Eric Evans，《领域驱动设计》：统一语言。被 README 引用来论证 GLOSSARY 的价值。
5. Martin Fowler，《重构》第 3 章：十二种代码气味，作为 code-review 的默认基线。