Appearance
Improve Codebase Architecture 解决的是 AI 越重构越浅的问题。它不急着抽函数、拆文件，而是先找理解和测试上的摩擦：哪些模块接口太复杂，哪些 seam 不真实，哪些抽象只是把复杂度搬到了调用方。
AI 改架构怎么避免越改越浅：Improve Codebase Architecture 怎么用
下载 improve-codebase-architecture 中文版 Skill ZIP
AI 很擅长整理代码。
也很擅长把代码整理得更碎。
文件多了，函数小了，名字统一了，但理解一个业务动作要跳十几个地方。这不是架构变好，只是复杂度换了位置。
improve-codebase-architecture 这个技能关注的是 deep module：用更小的 interface 承载更多稳定能力。
先看摩擦，不先提方案
这个技能不应该一上来就说“抽一个 service”。
它先找摩擦：
- 理解一个概念要在多个文件来回跳。
- 模块 interface 和 implementation 差不多复杂。
- 为了测试拆出了纯函数，但真实 bug 藏在调用关系里。
- 两个模块看似分开，实际互相泄漏细节。
- 没有好的测试 seam。
这些摩擦比“代码不够优雅”更重要。
deep module 是什么
deep module 不是大文件。
它指的是：调用方只需要理解一个小而稳定的 interface，就能获得一大块可靠能力。
反过来，shallow module 是 interface 很复杂，内部却没藏住多少东西。删除它以后，复杂度不会消失，只会散到调用方。
这个判断很适合交给 AI 做第一轮扫描，但最后是否改，仍然要人决定。
deletion test 很实用
技能里有一个判断方法：想象把这个模块删掉。
如果删除后复杂度也消失了，它可能只是 pass-through。
如果删除后复杂度散到很多调用方，它可能正在提供真实价值。
让 AI 评估模块时，可以这样问：
md
请对这些模块做 deletion test。
如果删除某个模块，复杂度会消失，还是会扩散到多个调用方？
请只列出真实造成理解或测试摩擦的候选，不要提出泛泛重构建议。这个问题能过滤很多“为了重构而重构”的建议。
不要马上让 AI 实施
架构改动很容易越界。
更好的流程是：
- 让 AI 列出 deepening candidates。
- 每个候选说明涉及文件、当前摩擦、改动方向、测试会怎么变好。
- 人选择一个候选继续讨论。
- 讨论清楚 interface 和 seam 后，再拆成小任务。
不要让 AI 一次性改完整个架构。
和代码简化的关系
站内已有 AI 写复杂了怎么收回来。那篇更偏“把当前 diff 收敛”。
这篇更偏结构判断：哪些模块浅，哪些 interface 不稳，哪里需要加深而不是继续拆碎。
你可能还需要
同类技能：
如果你让 AI 做架构优化，先让它列摩擦和候选，不要直接让它动代码。