当前业务图谱示例包含 1.8k+ 核心事件与模型节点、8.7k+ 业务关联关系。
这个规模不能证明图谱质量，却暴露了一个更实际的问题：完整图谱不适合直接塞给一次修改任务。AI 真正需要的，是从大图中抽出的最小业务子图。
例如，一个共享素材字段发生变化时，影响范围可能沿下面的链路展开：
数据表与统一模型
→ 数据控制器
→ Server Logic 与接口
→ Web Logic 与 Workflow
→ View 与验证路径
本文只讨论这张子图怎样从代码和元数据中被构造出来，不再同时展开历史记忆、测试生成和业务沙盘。
大图不是直接交给 AI 的上下文
文件树只能说明代码放在哪里。一次变更还需要回答：
- 哪些 Workflow 订阅了目标 Action；
- StateModel 字段变化会扩散到哪些 View；
- 某个 API 被哪些 Logic 调用；
- 一张共享表同时服务哪些模块；
- 页面动作最终会触达哪种业务状态。
全文搜索能够找到名称相同的文本，但 DSL 别名、事件键、接口路径和数据库映射可能使用不同名称。图谱的第一项工作，是把“文件”提升成带类型和来源的业务节点。
在 MSCE 中，一条典型关系可以表示为：
View
──发送──> Action
──订阅──> Workflow
──转换──> State
──接收──> Logic
这里必须保留 DSL 声明的业务名称。Workflow 判断发送方时依据组件 name，如果图谱改用类名，静态可视化会与真实事件匹配规则发生漂移。
每种关系必须保留事实来源
| 来源 | 可以确认的内容 | 不能单独确认的内容 |
|---|---|---|
| TypeScript AST | 导入、继承、模型引用、部分事件键 | 动态分支是否真实执行 |
| DSL / Workflow | 组件安装、业务名称、订阅与转换关系 | 当前样本是否经过 |
| 运行时追踪 | 某批请求的真实发送方、接收方和结果 | 未观察关系是否不存在 |
| 数据库元数据 | 表、字段和控制器映射 | 字段在业务中的完整语义 |
| 人工业务定义 | 代码未表达的流程含义 | 当前实现是否仍遵守定义 |
AST 提取负责它能够证明的事实，不负责猜测动态关系。无法静态确认的边应保留为待确认状态，再由运行时追踪或人工定义补充。
节点数量和关系数量只说明搜索空间。真正决定可信度的是，每条边能否回到来源，以及来源的证明范围有没有被保留。
一次修改怎样展开最小子图
以共享素材字段为例，一次影响面查询可以按五步收敛：
- 从数据表与统一模型定位字段；
- 回溯读写该表的数据库控制器；
- 找到调用控制器的 Server Logic 与接口；
- 继续定位 Web Logic、Workflow 和 View；
- 根据这些节点生成需要检查的类型、测试与页面路径。
输出不应只是相关文件列表，还应包含：
node 受影响对象
relation 为什么相关
evidence_source 这条关系来自哪里
confidence_limit 当前来源不能证明什么
verification 修改后需要检查什么
这样 AI 获得的是与任务相关的关系集合，而不是仓库的无差别上下文。
图谱不负责回答哪些问题
图谱描述当前结构和可能影响面，不负责证明修改已经正确，也不负责保存过去任务的根因。
历史经验怎样到达下一次任务，由《我删掉了一套数学上正确、工程上无效的学习闭环》和《在向量检索之前，我先做了一个可解释的基线》负责。
静态关系与运行时观察出现分歧时，则进入《同一条边，两种事实：静态图谱与运行时追踪》的范围。
明确分工后，图谱文章只交付两项能力：为一次修改找到相关节点；为每条关系保留可追溯来源。
构建完成的检查条件
一次图谱构建至少应检查：
- DSL 注册的组件能否解析；
- Workflow 订阅的事件是否存在；
- 发送方名称是否与 DSL 的业务名称一致；
- API、模型和数据控制器引用是否有效；
- 无法静态确认的关系是否被标成待确认，而不是强行画成事实。
其中，当前材料能够确认业务图谱规模、节点与关系类型，以及沿组件、事件、接口和数据层展开影响面的设计；不能确认每种动态关系已经被完整提取，也没有提供图谱准确率。
图谱的输出不是一张复杂图片，而是一份可以被查询的影响面。对一次具体修改，它应返回相关节点、关系来源和后续检查；除此之外的结论，不由图谱代替。