目录
为什么传统 Coding Agent 开始失效
向量化代码理解的瓶颈在哪里
Claude Code 为什么选择“终端调试范式”
CodeGraph：节省 Token，但解决不了核心问题
真正的转变：从“看懂代码”到“跑通代码”
这套范式对工程实践意味着什么
一、为什么传统 Coding Agent 开始失效
过去两年，大多数 Coding Agent 的核心思路其实是一致的：
先理解代码，再生成修改方案。
典型做法是：
对本地代码库做向量化 embedding
结合 IDE 上下文构建“高质量上下文”
再交给大模型做推理与生成
为了优化性能，很多方案甚至：
在本地部署小模型
专门用于补全、路径选择、上下文筛选
这一整套体系，本质上是在做一件事：
尽可能在“动手之前”，把代码理解清楚。
但问题也正出在这里。
二、向量化代码理解的瓶颈在哪里
这套范式在 Demo 场景下效果不错，但一旦进入真实工程环境，就开始暴露问题：
1、代码是“活”的，向量是“死”的
代码频繁变更
embedding 很容易过期
维护成本极高
2、理解 ≠ 能修改
很多时候：
问题并不是“找不到代码”
而是“改了之后对不对”
这个问题，无法通过向量检索解决
3、上下文越多，风险越大
大量图谱信息输入 LLM
模型未必能正确消化
幻觉概率反而上升
一句话总结：
你以为是在增强理解，实际上是在增加噪音。
三、Claude Code 为什么选择“终端调试范式”
Claude Code 出来之后，整个思路开始发生明显变化。
它不再强调“先理解全局”，而是更接近真实工程师的行为：
看代码 → grep → 修改 → 执行 → 报错 → 修复 → 再执行
这是一个典型的 终端驱动调试流程（Terminal-first loop）。
核心特点：
不依赖完整上下文
不追求一次性正确
强依赖执行反馈
这种方式有一个关键优势：
可以在不理解全局的情况下，逐步逼近正确答案。
四、CodeGraph：节省 Token，但解决不了核心问题
CodeGraph 是最近讨论比较多的一个方案。
它的思路是：
将代码库构建成图结构
提供 MCP 接口给 Agent 调用
替代 grep 等搜索行为
从数据上看，它确实有价值：
可节省约 20%+ 的 token
提升部分检索效率
但它解决的，本质上还是：
“更快找到代码”
而不是：
“如何正确修改代码”
在真实工程问题中，真正难的往往是后者。
五、真正的转变：从“看懂代码”到“跑通代码”
Claude Code 背后的核心理念，其实可以总结为一句话：
不要过度依赖“看得很准”，而是通过执行不断逼近正确。
这带来了一个非常关键的范式变化：
旧范式
新范式
先理解，再修改
边修改，边理解
强依赖上下文
强依赖执行反馈
一次性推理
多轮试错
静态分析驱动
动态调试驱动
这和真实工程实践是高度一致的：
当一个复杂系统报错时，工程师很少会先完整理解系统，而是优先解决当前报错。
六、这套范式对工程实践意味着什么
这个变化，不只是工具层面的升级，更是工程思维的变化。
1、Agent 从“助手”变成“执行者”
不再只是给建议
而是直接动手修改、运行、验证
2、测试的重要性被进一步放大
每一次修改都需要验证
自动化测试成为闭环关键
3、RAG / 向量检索不再是核心能力
依然有用，但不再是主角
只是辅助信息获取
4、终端能力成为 Agent 的核心接口
未来的 Coding Agent，核心能力不再是：
“我知道多少代码”
而是：
“我能不能把代码跑通”
结尾
过去两年，大家一直在优化：
如何让模型“更懂代码”
但现在，一个更现实的方向正在浮现：
代码不需要完全理解，只需要能被正确修改并跑通。
从“理解驱动”走向“执行驱动”， 这可能才是 Coding Agent 真正的分水岭。
如果你正在做：
AI 编程助手
自动化测试
Agent 工作流
这套范式的变化，基本绕不开。
