扫描——先阅读，再相信
Silex 首先在本地读取你的仓库：解析每个源文件，提取类、方法及其间的关系——调用、继承、跨语言边界的 HTTP 路由、原生 SQL 关联。任何代码都不会离开你的机器。
结果是一张本地图：节点是代码符号，边是源码中发现的关系，每条都可追溯到文件和行号。
社区地图——系统的真实形态
Silex 使用 Leiden 算法将关系图聚类为社区：真正协同工作的类的分组——与目录结构无关。这是系统实际的架构，而不是 src/ 目录树所声称的样子。点击节点查看其真实成员类。
Ordering 领域核心
49 个类 · 内聚度 0.067Order 聚合的契约面：仓储、领域事件（cancelled/shipped/paid），以及把订单 saga 粘合起来的集成事件处理器。
成员（真实类名）描述由 AI 代理阅读该社区真实代码包后撰写——与你将获得的客户端编排流程相同。
saga 以独立社区的形式出现——图在没有被告知什么是 saga 的情况下发现了编排步骤（库存确认、支付）。目录结构说这是 "Ordering.API"；图却说这是"五个独立切片和两条 saga 分支"。
证据锚定——无锚点，不成事实
Silex 的每条论断都带有锚点：证明它的文件和行号范围，且引用片段经过与源码核验。无法锚定的论断不会被存为事实——而是被标记为空白。
个幻觉锚点——在一个真实的 520 类企业项目的 328 次代理提交中。门禁在入口执行：没有来源的代理提交规则会被拒绝。
置信度——用数字表达诚实
置信度表达证据对论断的支撑强度——并携带来源：论断来自静态分析、LLM 处理，还是你自己的 AI 代理。数字从不凭空捏造：代理提出的规则显示 n/a，直到人工审核——而不是编造分数。
未知领域——Silex 无法证明的，它会告诉你
置信度的反面：证据过于单薄的代码区域。Silex 不猜测，而是把它们标出来。对迁移或 AI 辅助的变更而言，知道地图的边界与地图本身同样宝贵。
eShop 参考扫描：14% 由 gap_analysis 标记为未知领域。
状态机——从代码而非文档中恢复
当状态存在于代码中（枚举、状态字段、受守卫的流转）时，Silex 会重建状态机——每次流转都有锚点。从 eShop 恢复的真实订单生命周期（Order.cs:99-131）：Submitted → AwaitingValidation → StockConfirmed → Paid → Shipped，其中 Cancelled 可从早期状态到达。
与第 02 节交叉核对：saga 步骤（库存确认、支付）以社区的形式出现，而它们驱动的状态流转出现在这里——两次独立的重建彼此印证，这正是基于证据的考古应有的样子。
Vendor 与生成代码——分类处理，绝不悄悄删除
真实代码库中总有 vendor 包、压缩资源和生成的迁移。Silex 默认将它们分类移出视线——移出地图、代码包和成本估算——但绝不隐瞒这一事实。
有一条规则保护你：你的团队编辑过的（git 历史中有本地提交）疑似 vendor 文件会被视为你的代码，保留在地图上并标注。2014 年 fork 的、内含业务规则的 jQuery？它依然可见。
人工审核——1.5 层
在原始提取与规范领域模型之间是审核层：每个由 LLM 或代理提出的事实都是候选，直到人工确认。你的 AI 代理通过 MCP 工具完成跑腿工作——阅读社区代码包、提出带锚点的规则——而你始终是权威。第 02 节的社区描述正是这样产生的。
由 Silex v0.11.35 对 eShop（MIT）的真实扫描生成。图、表格和状态机都是数据，不是插图。