早期做 Coding Agent 都比较喜欢将本地代码库进行向量化，结合 IDE 上下文，提前构建一份“高质量上下文”，再交给大模型去推理。这种方式延续了很久，为了加速响应，甚至会在本地部署一个小模型，用于做 tab-tab 的决策。

Claude Code 出来之后，整个流派就发生了变化，开始倾向于转到 Terminal 编程，cc 的行为特别像人类工程师 debug 的过程：看代码 → grep → 试改 → 跑命令 → 报错 → 再查 → 再改 → 直到跑通。

它对代码仓库的理解是比较片面的，但这并不影响它解决问题。通过最小试错的方式，一边做任务一边理解全貌，这个操作反而更符合直觉。

一个巨石应用在运转的时候发生了错误，我们不需要对巨石应用有全面了解，只需要根据报错特征，修复当前的报错问题就好了。

有个库叫做 CodeGraph，它支持跟 Claude Code 协作，首先将仓库代码进行向量化，然后提供 MCP 给 cc 调用，以替代 cc 的 grep 操作。它的核心目标是节省 token，从数据看，确实可以节省大概 20%+ 的 token，但效果大概率会有折扣。

CodeGraph 这类方案，存在几个比较难搞定的问题：1）代码是活的，图谱很容易过期，而 grep 永远是新的；2）很多时候并非找不到代码，而是改得对不对，得去改、去执行、去验证，CodeGraph 只解决了查找问题；3）一大堆的图谱数据交给 LLM，它能不能正确消化？要知道 LLM 也是不稳定和有幻觉的。

不过度依赖“看得很准”，才开始动手。 一边做，一边修正，一边逼近答案。这就是 Claude Code 的编程哲学。