---
name: improve-codebase-architecture
description: 在代码库中发现架构"深化"机会——将浅模块变成深模块的重构，提升可测试性和 AI 可导航性。与 architecture-advisor 互补：architecture-advisor 设计新架构，本技能改善现有代码库结构。触发词：改进代码库架构、架构深化、找重构机会、模块耦合太紧、难以测试、代码难以理解、架构改进、improve architecture、refactor opportunities。
---

# 改进代码库架构

发现架构摩擦点，提出**深化机会**——将浅模块变为深模块的重构。目标：可测试性与 AI 可导航性。

使用 [references/LANGUAGE.md](references/LANGUAGE.md) 中的词汇表，所有建议中严格使用这些术语。

## 核心词汇（速查）

- **模块（Module）**：有接口和实现的任何东西（函数、类、包、切片）。
- **接口（Interface）**：调用者需要了解的一切：类型、不变量、错误模式、顺序、配置。不只是类型签名。
- **深度（Depth）**：接口背后的杠杆——大量行为隐藏在小接口后面是**深**，接口复杂度接近实现复杂度是**浅**。
- **接缝（Seam）**：可以不编辑内部代码而改变行为的地方。
- **适配器（Adapter）**：在接缝处满足接口的具体实现。
- **删除测试（Deletion test）**：想象删掉这个模块。复杂度消失了？那它是透传层。复杂度在 N 个调用者处重新出现？那它值得存在。

## 流程

### 1. 探索

先读取项目的领域词汇表（CONTEXT.md、UBIQUITOUS_LANGUAGE.md 等）和相关 ADR。

使用 Explore 子代理遍历代码库。**有机探索**，记录摩擦点：

- 理解一个概念需要在多个小模块间来回跳转的地方？
- 接口复杂度接近实现的**浅**模块？
- 为可测试性提取出来的纯函数，但真正的 Bug 隐藏在调用方式中（无**局部性**）？
- 紧耦合模块跨接缝泄漏的地方？
- 未测试或难以通过当前接口测试的代码？

对可疑的浅模块做**删除测试**：删掉它会集中复杂度，还是只是移动了它？"集中"是你要找的信号。

### 2. 提出候选项

呈现编号的深化机会列表。每个候选项包含：

1. **模块标识**：名称 + 文件路径
2. **浅度诊断**：为什么它是浅的（接口太多、散布在 N 个调用者、透传层、测试只能通过实现细节）
3. **深化思路**：合并哪些模块、接缝放哪里、哪些依赖需要端口
4. **可测试性收益**：深化后如何改善测试（更少 Mock、直接可测接口、局部性更好）
5. **工作量估算**：小/中/大（不做具体行数预估）

**在提出候选项时停下，等待用户选择。** 不要直接开始重构。

### 3. 为选定候选项设计接口（可选）

若用户想要对选定候选项探索多种接口设计，使用并行子代理模式——详见 [references/INTERFACE-DESIGN.md](references/INTERFACE-DESIGN.md)。

### 4. 实施

用户选定候选项并批准接口设计后：

1. 参考 [references/DEEPENING.md](references/DEEPENING.md) 制定具体深化策略
2. 编写新的集成测试，通过新接口测试行为
3. 合并模块，删掉旧的浅层测试（它们已成废代码）
4. 确认所有测试通过，删除任何遗留的原型代码

## 参考文档

- [references/LANGUAGE.md](references/LANGUAGE.md) — 完整词汇表与定义
- [references/DEEPENING.md](references/DEEPENING.md) — 按依赖类型的深化策略
- [references/INTERFACE-DESIGN.md](references/INTERFACE-DESIGN.md) — 并行子代理接口设计模式