从代码可视化到软件理解基础设施
代码可视化的未来不是一组独立工具，而是软件理解基础设施。它连接代码、测试、运行时、变更历史、架构规则和 AI 轨迹，为人和 Agent 提供共同的事实层。
本书从代码结构化讲到程序分析，从代码图谱讲到工程场景，再讲到 AI Agent 和 Review 证据层。到这里可以看到，代码可视化已经不只是“展示代码关系”，而是在软件工程流程中承担理解、验证和治理职责。
从图形工具到代码知识图谱
传统代码可视化工具往往以图形展示为中心：类图、调用图、依赖图、火焰图。它们帮助人看见关系，但通常是局部的、一次性的。
软件理解基础设施更关注事实管理：
哪些事实从哪里来。
何时更新。
置信度如何。
可以回答哪些查询。
能接入哪些工程流程。
代码知识图谱就是这种事实管理的形式之一。它既可以生成图，也可以支持影响面分析、测试推荐、架构检查和 Agent 查询。
从人看图到 Agent 查图
过去，可视化主要服务人。未来，它还要服务 Agent。
人需要可读视图：模块地图、调用路径、风险热力图、影响面报告。Agent 需要结构化查询：定义、引用、调用方、测试、架构规则、历史变更。
两者不应该使用两套事实。更合理的方式是：
同一套代码图谱。
人类界面生成可视化视图。
Agent 工具返回结构化数据。
CI 消费规则检查和报告。
这样，人和 AI 可以围绕同一份证据协作。
多源数据融合
单一数据源无法完整解释系统。
静态代码告诉我们可能结构，运行时数据告诉我们真实路径，变更历史告诉我们演进风险，测试覆盖告诉我们验证范围，架构规则告诉我们边界，组织信息告诉我们责任归属。
软件理解基础设施需要融合这些数据：
融合后的系统才能回答复杂问题：这次 AI 修改是否影响核心路径，相关测试是否足够，是否破坏架构边界，哪个团队应该 Review。
持续更新的软件事实库
软件理解基础设施不能是一次性扫描结果。它应该随软件演进持续更新：
代码提交后更新 AST、符号和调用关系。
测试运行后更新 Coverage。
服务运行后更新 Trace 和性能属性。
PR 合并后更新变更历史。
架构规则变化后重新检查依赖。
Agent 执行任务后记录查询轨迹和修改证据。
持续更新让图谱保持可信。过时的图谱会误导人，也会误导 AI。
嵌入工程流程
基础设施的价值体现在流程集成中：
IDE 中辅助代码导航。
PR 中展示影响面和 Review 证据。
CI 中执行架构和测试规则。
APM 中从 Trace 跳回源码和 owner。
Agent 修改前查询上下文。
Agent 修改后生成验证报告。
如果代码可视化只能手动打开查看，它的使用频率会很低。只有出现在开发者和 Agent 做决策的位置，它才会成为基础设施。
治理 AI 轨迹
AI 时代还有一种新数据：Agent 的工作轨迹。
这包括：
Agent 查询了哪些符号。
读取了哪些文件。
运行了哪些命令。
修改了哪些实体。
参考了哪些测试。
忽略了哪些风险提示。
这些轨迹应该和代码图谱关联起来。它们可以帮助团队判断 AI 是否遵循了工程流程，也可以作为后续改进 Agent 行为的数据。
软件理解基础设施的最小形态
不需要一开始建设庞大平台。一个最小可用系统可以从以下能力开始：
解析源码，提取文件、类、方法和调用关系。
构建节点和边表。
输入 Diff，输出影响面。
关联测试和 Coverage。
生成可读报告。
提供 Agent 查询接口。
这也是本书第六篇实践项目的目标。它不会覆盖所有复杂场景，但会跑通核心闭环。
小结
代码可视化正在从图形工具走向软件理解基础设施。它把代码、运行时、变更、测试、架构和 AI 轨迹连接成事实层，让人和 Agent 能围绕同一套证据协作。
下一篇将进入实践项目，构建一个最小代码理解系统，把本书前面讨论的概念落到可执行的链路中。
Last updated