从 source map 里把 Claude Code 挖出来

前端的构建产物默认是不可读的：打包、压缩、改名，一个几十万行的 bundle 摊在那里，看起来像噪声。但如果发布时把 .map 文件一起传上去了，情况就完全不同——source map 里存着原始文件路径、原始内容，甚至变量名。

Open-ClaudeCode 这个仓库做的就是这件事：把 npm 上公开发布的 source map 还原成一棵能读的源码树。

还原本身不难，难的是让它成立

source-map 这个库几行就能把 sourcesContent 吐出来。真正花时间的是之后：

同一个逻辑文件可能被拆进多个 chunk，也可能在不同版本里换了路径。要让还原结果稳定可比，得先建立一套规范化规则：路径去掉构建期前缀、按内容哈希去重、同名不同内容的保留版本后缀。做完这一步，跨版本 diff 才有意义——你能看到某个函数在两个小版本之间改了什么，而不是被文件重排淹没。

还有一类文件是还原不出来的：sourcesContent 为空的条目。这时候只剩压缩后的代码，变量名已经没了。我的处理是保留原样并标记，不去猜、不去伪造一份「看起来像源码」的东西。归档的价值在于可信，编出来的部分会毁掉整体。

运行时产物比源码更有意思

除了源码，还原出来的目录里有一批运行时才存在的东西：提示词模板、工具定义、配置默认值。它们在源码里是字符串常量，在编译产物里也是字符串常量，所以完整地留了下来。

读这些比读源码有意思。一个工具的参数描述怎么写、什么时候用 few-shot、错误提示怎么措辞，这些决定了实际行为，却很少有人专门讨论。

边界

这个仓库是研究归档，不是发行版。做的时候给自己划了三条线：只处理发布方自己公开的构建产物；不重新分发可运行的完整程序；README 里写清楚来源和用途。

拆东西看它怎么工作，和把拆下来的零件拿去卖，是两件事。