我从阅读克劳德代码重构源码中学到的东西

2026西湖龙井茶官网DTC发售：茶农直供，政府溯源防伪到农户家 

我从阅读克劳德代码重构源码中学到的内容

大约在2026年3月31日，人们普遍得知克劳德代码命令行界面（CLI）的部分实现可以从保留在npm软件包中的源码映射（source maps）中重构出来。当时曾有一个公开镜像流传了一段时间，但这并非由安托皮克公司（Anthropic）官方发布的开源版本，此后该镜像已演变为另一个项目。

本文是我当时保存在本地的重构源码副本阅读后的个人印象备忘录。我并不打算讨论任何公开镜像的当前状态，而是希望聚焦于通过实际追踪代码所揭示出的设计特征。

我的第一印象：这比我预想的要庞大得多的产品代码库

最令我惊讶的是代码库的规模之大。在我手头的重构源码中，大约有1900个文件，总计约51万行代码。这绝非一个小型专用命令行工具，而是一个相当庞大的产品级代码库，将终端用户界面、工具执行、安全控制、集成开发环境（IDE）集成、记忆机制以及扩展机制整合到了一个系统之中。

从技术角度看，该项目似乎以TypeScript为核心，使用Bun作为运行时环境，并采用类似React/Ink的架构来构建终端用户界面。换句话说，它给人的感觉不像“一个在小型命令行工具上附加了人工智能功能”，而更像是“一个体量可观的TypeScript产品，其中融入了人工智能体验”。

提示词比我预期的更多地存在于客户端

在这个代码库中最容易开始追踪的部分之一就是提示词的构建过程。至少在可重构的部分中，系统指令层中有相当大一部分直接存在于客户端代码中，运行时上下文随后被注入其中。

这些运行时上下文包括当前日期、Git状态、最近的提交记录、Git用户信息以及本地指令文件的内容。在此基础上，系统还会叠加额外的指令和与记忆相关的文本，最终组合成接近完整形态的系统提示词。

尤其令我感兴趣的是，那种直觉性的假设——“真正的提示词一定是在服务器端以黑盒方式组装而成”——在这里似乎并不太成立，至少在我所能检查的代码部分中是如此。当然，这并不能证明服务器端没有额外的处理逻辑，但它确实表明大量提示词逻辑也存在于客户端。

在工具设计中，重要的不是工具的数量，而是它们如何被暴露和控制

该设计中另一个引人注目的部分是决定哪些工具对模型可见的层级，以及独立管理执行权限的层级。系统显然功能丰富，但常规暴露的工具与内部工具、受功能开关控制的工具或以其他条件启用的工具之间有着相当清晰的界限。

我的印象非常明确：这个代码库看起来并非围绕“工具越多，系统就越强大”这一理念构建。如果有什么倾向的话，反而更接近相反的观点：在正常运行状态下，暴露给模型的接口表面应尽可能保持狭窄。

此外，还有一些实现细节表明，工具列表本身必须与提示词缓存保持一致。这意味着工具的数量及其结构定义不仅仅是实现细节，似乎也是稳定提示词操作的一部分。

这与当前越来越普遍的认知高度吻合，即“较少的工具往往能带来更稳定的行为”。话虽如此，这是我对此代码库的解读……