schematic：接手几十个文件的烂摊子，让 Claude Code 先把分支“倒推”成文档

接手同事写到一半的功能分支，最让人头大的一般不是代码烂。

是你根本不知道该先看哪。

几十个文件挂在 diff 里，组件改了一点，类型加了两个字段，测试又藏着真正的业务规则。你顺着提交记录硬啃，半天过去，脑子里还是一堆碎片。老鬼看这种分支，第一反应通常不是让 AI “总结代码”，那样很容易得到一份看起来都对、实际没法接活的废话。

schematic 做得更狠一点：直接从已经写出来的代码，反向倒推产品和技术文档。

它是给 Claude Code 和 Codex 用的 Skill。装好后，在目标分支里说一句“Analyze this branch”或者“Write a spec from the code”，它就开始干活。

有个细节我挺喜欢。

schematic 不会一上来就让模型漫无目的地读文件，而是先跑git log、git diff --stat，确认提交范围和改动规模。它甚至专门检查一种很烦的情况：分支里混进了其他已经合并 PR 的“搭便车提交”。检测到后，会用 PR 的 commit SHA 重新圈定文件，免得把别人的改动也算进文档。

啧，这地方才是重点。

以前接手旧分支，最怕的不是漏掉主模块，而是漏掉某个类型声明、Feature Flag，或者顺手塞进去的兼容修复。schematic 会把文件分成核心实现、接入点、测试和配置几组，再开 2 到 4 个智能体并行读。等它们交卷后，还会拿完整 diff 文件清单再对一遍，把没覆盖的小文件补回来。

最后输出一份 11 章节的 Markdown 文档：问题是什么、方案怎么走、产品需求、架构图、数据流、技术设计、新增和修改文件、测试、灰度上线、风险，以及最终摘要。文件清单要求全部覆盖，测试里的断言也会被拿来反推需求。

先别急着吹。

代码只能说明“做了什么”，不一定能准确说明“为什么做”。schematic 也会根据测试、注释和提交记录推断产品动机，这部分肯定得人再过一遍。尤其是历史包袱重、需求中途改过几轮的分支，生成出来的文档更适合当地图，不是圣旨。

但它解决的确实是脏活。

同事突然离职、功能已经合了却没补设计文档、评审前临时要写 PR 描述，或者你只是想快速搞清楚一条陌生分支到底动了哪根筋，都可以先让 schematic 跑一轮。至少不用对着几十个红红绿绿的文件，从第一个 import 开始猜。

Github地址：blader/schematic。