thinking-map-territory

地图与疆域

文档、测试、图表、指标、注释和心智模型都是地图。运行中的代码和实际数据才是疆域。两者不一致时，应核实疆域并更新模型——绝不要强行让现实符合描述。

适用场景

• 观察到的行为与文档、测试预期、图表、注释、仪表板或先前假设相矛盾。
• 关于系统的论断依据的是次要来源，而非当前代码或数据。
• 测试通过了，但生产环境或手动操作的结果不正确。
• 你还没检查实际情况，就要开始推测原因。
• 某项决策取决于某个模型、架构或指标是否仍然有效。

不适用场景

• 你要编辑的就是这张地图（文档、图表、规范）——该制品就是任务疆域。
• 本次会话中已核实过相同路径——复用该观察结果。
• 地图具有权威性且可生成其他内容（代码生成类型、派生架构），并且没有人声称其已过时。
• 这种不一致不会影响决策——记录下来，继续处理。
• 已确认疆域无误，但仍有多个相互竞争的因果假设——改用 scientific-method。
• 构造安全漏洞利用——使用 red-team；此技能只用于解决模型与观察结果不一致的问题。

流程

1. 指出地图。 说明所信任的具体表示：是哪份文档、测试、指标、图表、注释或假设。引用原话，不要改述。
2. 指出疆域核查方式。 明确说明什么观察结果能够证实或证伪该论断：代码路径、运行时值、查询、复现、近期变更或实时指标。
3. 核实来源和时效性。 确认地图的来源（作者、生成器、上次更新时间），并判断相对于部署、配置或数据变更，它是否可能已经过时。优先采用当前的一手来源，而非摘要。
4. 观察疆域。 阅读实际代码路径、运行或检测代码、查询实际数据，或复现行为。不要只凭签名或名称进行预测。
5. 记录差异并更新。 如果疆域与地图相矛盾，对于已发布行为，以疆域为准。记录差异，修订模型，然后决定修复什么（代码、地图或两者）。指出未覆盖的路径——这些路径很可能是下一个故障点。
6. 确认后停止。 一旦通过具体观察确认或推翻该论断，就停止重复检查同一路径。

输出

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>

验证

• 如果你只根据地图进行推理，没有观察疆域；信任了过时的次要来源；或在未核查地图和代码的情况下，强行让代码符合错误的文档，则判定为未通过。
• 矛盾解决后，或确认其与决策无关后，即可停止。
• 避免过度应用：编辑地图时、地图是生成式真实来源时，或差异不会影响下一步行动时，不要重新核查整个系统。