高炉后端 139 个接口，一条 Python 脚本全量索引是怎么搭出来的

打开 .workbuddy/tools/CODE_INDEX.md，翻到目录——烧结模块的接口列表整整齐齐，高炉那边直接是空的。四个模块：admin-server、admin-web、ironmaking-server、ironmaking-web，一个都没扫到。而高炉后端光接口就有 139 个，不建索引，后面排查线上问题基本靠 Ctrl+F 盲搜。

先摸骨架，别急着写脚本

打开四个模块的目录树，两件事立刻明确：

• 两个后端（admin-server、ironmaking-server）都是 weshyper-manage 同构布局，跟之前烧结的后端一模一样
• 三个前端共享同一套组件目录，结构也类似

这意味着索引脚本不用从零写。核心逻辑复烧结那版就行，主要改的是路径扫描范围和模块标识。省掉了大量猜测工作。

4 个子代理并行跑，我同步改脚本

深度分析这部分，我拆成 4 个 Explore 子代理并行跑，每个代理负责一个模块。我这边同时动手改 code-index.py。

为什么拆 4 个而不是一口气串行跑完？单个模块代码量不小，串行等太久。并行之后，4 份深度报告基本同时到手，质量都不错——每个模块的依赖关系、接口清单、工艺对应逻辑都梳理出来了。

索引脚本的关键改动

把 code-index.py 的扫描范围从 2 个模块扩到 6 个（三后端 + 三前端），核心改动就三处：

• 模块注册表从硬编码 2 项改成循环遍历配置列表
• 接口提取正则适配了 ironmaking-server 里嵌套路由的写法（router.get('/api/blow', { sub: [...] }) 这种）
• 输出从按模块分文件改成统一 CODE_INDEX.md，最终 50KB 左右

跑完 python .workbuddy/tools/code-index.py，高炉后端 139 个接口条目全部落进索引。抽查了几个路由路径，确认嵌套的那批没漏。

最终交付和一条经验

产出两份东西：

• 《高炉模块-代码全景分析.md》（项目根目录）——四模块深度报告 + 依赖图 + 工艺对应表 + 端到端业务流程
• .workbuddy/tools/CODE_INDEX.md ——升级后的全模块索引，随时 python .workbuddy/tools/code-index.py 重生成

最值钱的一条经验：接手一个多模块项目，别一上来就写索引脚本。先花 10 分钟把目录树过一遍，确认模块间的同构关系。这次三个后端全是同一个 weshyper-manage 基座，如果一开始没发现这点，正则和解析逻辑至少要多写两套。先摸骨架再动手，后面每一步都省时间。

---

做自动化这几年，最耗时间的从来不是写代码，是摸清每个平台的脾气。

这篇里提到的坑，都是真金白银踩出来的。
这篇里的场景你踩过类似的吗？是卡在「需求说不清」还是「改完就崩」？
评论区说说，我按最多人卡的点接着写。