让 AI 编程助手去修复一个陌生服务中的 bug，看看它第一步会做什么：它开始读文件。打开一个，再打开一个，grep 某个函数名，又打开四个。每一轮都消耗 token 和时间，而智能体抵达编辑点时仍是半盲状态——它只是采样了代码库，而非真正理解它。
Codna 颠覆了这个顺序。在智能体写下第一行代码之前，它已读完整个代码库，在毫秒内构建出整个项目的结构映射。智能体在读你的代码，Codna 在理解它。
AI 编程助手为何盲目阅读
大型代码库不是一堆文本文件，而是一张图——由导入关系、调用点、类型定义，以及团队多年积累的隐性约定共同构成。当 AI 编程智能体逐文件游走于这张图时，它要付出双重代价：一是重复阅读已见内容所消耗的 token，二是因从未看到关键部分而犯下的错误。
这种失败鲜少戏剧性地显现。智能体修补了表象，却错过了三层目录之外的公共辅助函数；它重复实现了一个已有的工具；它修改了一个函数签名，却没注意到下游的七处调用方。这些都不是推理失败，而是上下文失败——模型从未获得足够的代码库信息，无从知晓更好的做法。
多数糟糕的 AI 编辑不是推理错误，而是上下文缺失错误。
常见的补救方式是塞入更多文本：把文件堆进提示词，寄望于相关内容恰好在其中。这不过是以一个问题换另一个问题。上下文窗口被填满，成本攀升，智能体真正需要的信号被无关内容淹没。
先映射，再行动
Codna 的核心前提是：理解代码库与编辑代码库是两项不同的工作，应由两套不同的引擎来承担。映射引擎一次性完成高代价的结构分析并持续保持更新；编程智能体负责写作，携带精确上下文而非一份待读清单抵达现场。
映射过程消耗零 token。Codna 通过静态分析对代码库建立索引，而非将源代码送入语言模型，因此构建和刷新一个百万行项目的映射不产生任何推理成本。模型的预算花在真正创造价值的地方——变更本身，而非每次会话都从头重新探索项目。
最终呈现的是一款将代码库上下文视为基础设施的 AI 编程助手。映射始终存在，始终最新，并可在智能体需要的瞬间完成查询。
理解。修复。演进。
这个闭环分四步，每次智能体开始工作时依序执行。
第一步，Codna 映射代码库——将项目解析为包含文件、符号、依赖关系和调用图的结构索引。第二步，理解该映射，厘清各部分之间的关联，使针对某个函数的查询能感知到调用它的代码和它所依赖的代码。第三步，当任务到来时，Codna 检索上下文——精确抽取变更所涉及的那一片代码库，不多不少。第四步，引导智能体，将这份聚焦的上下文交付出去，使编程智能体以资深工程师的认知水位进行编辑。
理解。修复。演进。这三个词的选择是刻意为之的。理解先于修复，因为没有理解的修复不过是猜测；而演进——重构、迁移、系统随时间的持续改善——只有在每次变更都以全局为基础时才是安全的。
精确上下文带来的改变
当智能体不再盲目阅读，差异体现在实际工作中，而非演示里。
- 编辑落在正确位置，因为智能体能看到所修改函数的每一处调用方
- token 消耗下降，因为模型不再在每一轮中重复读取文件
- 重构更安全，因为映射在变更上线前就呈现出完整的影响范围
- 熟悉陌生代码库不再是猜谜游戏——结构已经一目了然
这就是 AI 编程智能体与真正代码智能之间的分界线。前者尽其所能地阅读，后者在开始之前就知道该读什么。在众多 AI 编程助手工具中，这一差异在快速试用时容易被忽视，但在一个季度的真实工作中无从回避——它正是将聪明的自动补全与真正适合你所维护代码库的最佳 AI 编程助手区分开来的东西。
为你已有的代码库而生
Codna 面向真实项目运行——那些庞大、分层、文档残缺的项目，而非教程里整洁的示例。它与团队已在使用的编程智能体协同工作，包括作为 VS Code 的 AI 编程助手，让映射赋能开发者惯用的工具，而非取而代之。目标从来不是增加一个窗口，而是让你现有窗口中的智能体抵达时就已知晓自己身处何处。
随着系统不断增长，读懂代码与理解代码之间的鸿沟只会越来越宽，而能弥合这一鸿沟的助手，将是那些先映射再行动的工具。Codna 已上线，为那个未来而生——在那里，理解代码库是你的工具做的第一件事，而非最后一件。