古法编程

Context Mode 的反幻觉机制通过一套多层次的机械验证流程来对抗大语言模型（LLM）固有的幻觉倾向。其核心在于将平台行为声明和修复假设视为未经证实的假设，并强制要求通过可追溯的源代码引用（file:line）进行证明。这套机制由三个紧密协作的部分构成：针对环境变量等具体声明的5步验证协议、存储平台源码的 refs/ 证据库及其自动恢复协议，以及在处理多适配器审计结果时的 Fan-out Claim Verification 三阶段门控，从而将基于猜测的编码转变为基于证据的工程。

Context Mode 的反幻觉机制：平台行为验证、refs/ 证据库与 Fan-out Claim Verification

大语言模型在生成代码和理解平台行为时，存在“走捷径”的倾向，即基于其训练数据中的统计规律进行臆断，而非核实当前具体的事实。Context Mode 作为一个需适配 15 个 AI 编码平台、跨 3 个操作系统的复杂系统，其项目管理流程被这种“幻觉”严重伤害过。一次典型的事故是 inheritEnvKeys：一个 LLM 智能体断言“Claude Code 会从子进程中剥离环境变量”，团队基于此断言实施了修复，结果发现该平台行为声明完全错误。为了根治此类问题，Context Mode 在其 context-mode-ops 技能中构建了一套系统性的反幻觉架构，其设计哲学是：不信任任何来自 LLM 的行为声明，一切以可验证的源码证据为准。这不仅是一个最佳实践，更是一套强制执行的工作流门控。

架构级反幻觉设计：MUST 规则与 Engineering Manager 模式

反幻觉的第一层防线始于项目治理的核心——SKILL.md 中定义的 Owner Operating Directive。它以 12 条非谈判的 MUST 规则，从根本上改变了 LLM 智能体的工作模式。其中，MUST-6 直接针对幻觉问题：

Anti-hallucination via refs/ + LoC reading. LLMs lie cheaply. Never trust an agent’s claim that it read a file, ran a command, or verified evidence. Demand file:line citations from actual Read tool output. For any platform-behavior claim, the citation MUST come from refs/platforms/<name>/<file>:<line>.

这条规则将验证责任从主观的“我觉得”转移到了客观的“代码显示”。它强制要求每个智能体扮演工程经理（EM）的角色——协调、委派、验证，而非亲自编码。所有关于平台行为的断言，必须附带从 refs/ 目录中读取的具体源码行号作为证据。如果证据链断裂，该工作即被判定为未完成。

ENV 变量验证协议：5 步溯源与裁决

环境变量是 LLM 最容易产生幻觉的领域之一。Context Mode 在 validation.md 中建立了一套严格的 5 步验证协议，确保每个被提及的 ENV 变量都是真实存在的。

  1. GREP source：首先在 Context Mode 自身的源码库中搜索 (rg "{ENV_VAR}" src/)。如果找到，说明项目已在使用，验证通过。
  2. WebSearch：针对目标平台进行网络搜索，查询其官方文档、GitHub 仓库或发布说明，确认该变量是否被官方记录。
  3. Context7：利用 Context7 工具查询平台的最新官方文档，进行二次交叉验证。
  4. GitHub：如果平台是开源的，直接检查其 GitHub 源码，查找该变量的定义和使用处。
  5. VERDICT：根据证据给出最终裁决：
    • VERIFIED：在 Context Mode 代码或官方源码中确认存在。
    • REAL_NEW：平台拥有但 Context Mode 尚未使用。
    • HALLUCINATED：无任何证据表明其存在。
    • DEPRECATED：已弃用。

validation.md 中提供了一个已验证的环境变量表（如 CLAUDE_PROJECT_DIR, OPENCODE 等），任何未在该表中的变量都必须走完这 5 步完整流程。例如，当一个 PR 声称使用了 OPENCODE_HOOK_PATH 时，协议会强制智能体去搜索 OpenCode 的实际源码或文档来验证，而非依赖 LLM 的“记忆”。

refs/ 平台证据库与自动恢复协议

为了执行上述验证，特别是步骤 4，Context Mode 维护了一个名为 refs/platforms/ 的关键目录。这是项目的“地面真相”数据库，存放着它所集成的所有上游平台（如 Codex CLI, Gemini CLI, Zed 等）的本地克隆源码。任何关于“Codex 做了X”、“Cursor 读取Y”的断言，都必须通过引用 refs/platforms/codex/src/...:123 或 refs/platforms/cursor/src/...:456 来佐证。

这个目录并非随主仓库分发（为了保持发布包精简），因此需要一个 自动恢复协议 来保证其可用性：

  1. 检测缺失：检查 refs/platforms/<name> 目录是否存在或为空。
  2. 并行克隆：如果缺失，立即通过 ctx_batch_execute 并行克隆对应的上游仓库（并发度控制在 4-8 以避免触发速率限制）。
  3. 阻塞断言：在克隆完成前，任何涉及该平台的行为声明都被阻塞。
  4. 引用证据：克隆完成后，智能体必须引用新克隆的源码文件行号来支撑其断言。

这个协议直接源于教训。inheritEnvKeys 事故就是因为智能体跳过了直接检查 Claude Code 源码这一步。如果没有 refs/ 和这个协议，团队将不断重复同样的错误。

Fan-out Claim Verification：三阶段门控防止过度工程化

当进行跨适配器审计时，一个智能体可能会得出“10 个适配器都需要修复”的结论。Context Mode 在此设立了第二个关键门控——Fan-out Claim Verification，明确指出：“一次审计返回的列表是一个假设，而不是待办清单。” 它强制实施三阶段验证，防止基于不实声明进行大规模并行开发。

Phase A：复现每个声明 为列表中的每个项目单独派遣一个验证智能体。该智能体的唯一任务是：阅读相关的平台源码（从 refs/ 或实时克隆），尝试复现故障，并返回带有 file:line 证据的 CLAIM_VERDICT（确认/证伪/不确定）。没有源码引用等于未经验证。

Phase B：仅研究已确认的项 只有状态为 CONFIRMED 的项才会进入下一阶段。智能体需要为每个确认的问题识别具体的修复形态：文件位置、修改格式、多窗口安全性以及可行性评估。

Phase C：仅实现已验证的项 只有通过前两个阶段的项才会被分派实施智能体。通常，经过此门控后，最终需要实施的项目数量仅为初始审计列表的 5-20%，其余都被识别为未经证实的猜测。

validation.md 中记录了一个真实案例：在一次统计准确性审计中，最初报告 10 个适配器需要修复。经过 Fan-out 验证，结果是 2 个被证伪，3 个被确认但修复方案各异，最终实际工程量只是一行代码的修改。没有这个门控，团队可能为 10 个不存在或性质不同的问题编写并行修复，重蹈 inheritEnvKeys 的覆辙。

总结

Context Mode 的反幻觉机制是一个精心设计的防御体系。它通过 MUST 规则将验证提升为强制性纪律，通过 ENV 验证协议建立了针对具体声明的标准化核验流程，通过 refs/ 证据库为验证提供了物理基础，并通过 Fan-out 门控遏制了基于假设的过度工程化。这套机制共同确保了项目的每一次修改都建立在坚实的、可追溯的证据之上，而不是建立在 LLM 的随机臆测之上。对于构建复杂、高可靠性系统的团队而言，这种将“不信任，去验证”理念产品化的思路，具有重要的参考价值。

FAQ

Q: 为什么 Context Mode 不直接使用 LLM 训练数据或在线文档来验证平台行为，而要维护一个本地的 refs/ 证据库？ A: 因为 LLM 的训练数据可能过时，在线文档可能不完整，且两者都无法提供精确到代码行的证据。本地克隆的 refs/ 目录提供了一个稳定、版本明确、可精确引用的源码真相源，使得验证工作机械化且可重复，彻底避免了因信息来源不可靠而产生的幻觉。

Q: Fan-out Claim Verification 的三阶段门控是否会显著拖慢开发进度？ A: 短期内看，它增加了一个验证阶段。但长期看，它通过过滤掉大量错误的假设，避免了在错误方向上浪费更多时间进行编码、测试和调试。如案例所示，它将 10 个可能的并行任务缩减为 1 个正确任务，总体上提升了工程效率和代码质量。