当地图（文档/测试/指标/假设）与真实行为冲突时…

当观察到的行为与文档、测试、图表、注释、仪表盘或先前假设矛盾时，先验证活代码/真实数据，再更新模型。

适用场景

解决思路

1. 命名地图：明确被信任的确切表示——哪个 doc、test、metric、diagram、comment 或 assumption；引用原始 claim，不要转述。
2. 命名领土检查：指定能证实或证伪该 claim 的观察——代码路径、运行时值、查询、复现步骤、近期变更或实时指标。
3. 验证来源与新鲜度：确认地图的来源（作者、生成器、最后更新时间）以及它是否可能相对于 deploy、config 或 data change 已过期；优先使用当前一手来源而非摘要。
4. 观察领土：阅读真实代码路径，运行或插桩它，查询真实数据，或复现行为；不要仅凭签名或名称预测。
5. 记录差异并更新：如果领土与地图矛盾，已发布行为以领土为准；记录差距，修订模型，然后决定修复方案（代码、地图或两者）；记录未被地图覆盖的路径——很可能是下一个故障点。
6. 确定后停止：一旦用具体观察确认或推翻 claim，就停止对同一路径反复检查。
7. 按输出模板记录：Map: <claim + source + freshness>；Territory check: <what was inspected/run/queried>；Observation: <concrete result, not interpretation>；Delta: <aligned | map wrong | territory incomplete>；Updated model: <corrected understanding>；Action: <fix code | update map | no decision impact>；Uncovered: <paths no map covers>。
8. 核验：如果仅从地图推理而没有领土观察、信任过期的二手来源，或未检查任一方就强迫代码匹配错误文档，则判定为失败。
9. 核验停止：当矛盾已解决或与决策无关时停止。
10. 防止过度应用：编辑地图、地图是生成式真相来源、或差距不能改变下一步行动时，不要重新验证整个系统。

适用边界 · 注意事项

• 地图本身就是你要编辑的任务对象（doc、diagram、spec）时，该 artifact 就是任务领土，不要套用此技能去验证整个系统。
• 同一路径本次会话已经验证过，或地图是权威且生成式的（codegen types、derived schema）且没有声称漂移。
• 不匹配无法改变决策时，记录并继续；若已确认领土后还要在竞争因果假设间选择，应转 scientific-method；安全漏洞利用应转 red-team。