Claude 总把推断说成事实？用规则和核查流程约束它
不少人反馈 Claude 的 Opus 系列灵活、写代码强，但用量一大就爱把印象和推断当成核实过的结论说出口，出错后道歉得很到位，下一次却照旧；而 GPT 系列又防御过头，动不动就免责声明。这篇整理成因——上下文压缩、会话过长、规则膨胀、缺少可核查数据源——并给出一套可落地的约束方案：把「要诚实」改写成可执行判据、让结论自带证据、数字交给脚本、规则文件分层、控制会话与上下文。
很多人对 Claude 的 Opus 系列有个共同的体验：刚上手时惊艳，写代码、做重构、处理抽象问题都很灵，比前几代顺畅太多。但用量一上来就开始难受——它会把凭印象拼出来的东西，用非常确定的语气说成「已核实」的结论。你指出错误后，它道歉得极其到位，甚至能准确复盘「我是拿压缩后的印象当场组织的回答，没有回头对原文」，然后下一次照犯。
另一边的 GPT 系列则是反方向：防御拉满，每句话都像免责声明，频繁要求确认、频繁阻断，慢但不敢乱说。一个太敢说，一个太不敢说，实际工作里都影响效率。这篇文章把这类问题的成因拆开，给一套可落地的约束办法。
问题不在于「答错」，而在于混用了两种语气
真正让人没法依赖的，不是模型偶尔不知道，而是它不区分「我查过」和「我猜的」。同一段回答里，核过的结论、推断、脑补全部用同一种肯定句式输出，你就必须逐句复核，成本比自己做还高。
更麻烦的是它会替你做决定：重构代码时顺手改了行为却不告知，被测试发现后淡定认错——认错是真诚的，但它没有把「改动范围需要报备」当成硬约束。这属于流程缺失，不是态度问题。
几个常见成因
推断型模型的固有代价
擅长跳跃、抽象、联想的模型，往往不擅长「停下来核对」。它倾向于先给一个连贯的解释，再让细节去配合这个解释。你让它描述数据，它会顺着「一句话能解释通」的方向把话说满。
上下文压缩后，印象替代了原文
长会话压缩过几轮之后，原始文档细节丢失，留下的是摘要。模型拿着摘要回答需要精确引用的内容，就会出现「说得有模有样但和原文对不上」。这是很多错误复盘的直接来源。
会话太长、旧结论混入
一个会话跑到底、开记忆功能、把历史决策和新事实堆在一起，模型很难分辨哪条还有效。有反馈说压缩次数不算多（几轮），但压缩本身就可能引入上下文矛盾。
规则文件膨胀与互相冲突
有人一开始让它「犯错就反思并记录」，两周下来规则文件涨到几百 K，规则之间互相打架，实际约束力反而下降。规则不是越多越好。
缺少可核查的数据源
如果模型只能看到聊天记录，那它除了猜没有别的选择。能查数据库、日志、文档仓库，和只能凭记忆，是两种完全不同的可靠性。
可操作的约束方案
1. 把「要诚实」改写成可执行判据
「不要脑补」「请严谨」这类态度性指令基本无效。写判据，写能被检查的动作。例如在项目规则文件里加一段：
## 事实与引用
- 转述他人说法时，必须贴出原话片段并注明位置；找不到原话就写「未找到原文」。
- 引用文档时输出三件套：结论 / 支持的原文片段 / 位置。只给链接不算证据。
- 某来源查到 0 条记录时，必须同时给出该来源的总量，否则只能说「没查到」，不能说「没有发生」。
- 样本量过小时只报现象，不报根因。
- 推断必须单独标注为推断，不得与已核实内容混写。
- 涉及代码行为变更时，先输出变更清单与影响面，等我确认再动手。
每条后面附一句「为什么有这条」，说明当初踩过什么坑。模型在边界情况下能自己判断这条适不适用，比死规则更耐用。
2. 让结论自带证据，降低复核成本
试一项具体结论时，要求它同时交三样：结论、支持这句话的原文、原文位置；推断另起一段；没查到就留空。这样你只需要核对证据，不用重读整篇回答。注意链接不算过关——要点进去确认那段话确实支持结论。
3. 数字和统计不要交给模型
凡是计数、求和、比例、时间窗口，一律用脚本或 SQL 跑出结果，模型只负责解释结果。它自己算数是最容易出隐性错误的地方。
4. 规则文件分层，别全塞一处
| 位置 | 放什么 | 注意 |
|---|---|---|
| 项目规则文件 | 稳定的判据、流程、禁令 | 保持精简，定期清理 |
| 记忆/变更记录 | 决策、口径、变更历史 | 已作废的不要删，标注作废日期和原因 |
| 命令/技能 | 重复性操作步骤 | 按需加载，不常驻 |
旧结论直接删掉很危险，它可能从别的旧文档里把错的捡回来。标「已作废」并写原因更稳妥。定期回看规则总量，膨胀了就合并同类项。
5. 控制会话与上下文
- 新任务新开会话，不要让一个会话从需求跑到上线。
- 压缩发生后，主动把关键约束重述一遍再让它继续。
- 分层处理：规划层和执行层尽量少压缩，协调层压缩影响相对小。
- 需要长时间挂着跑的任务（比如远程跑 Claude Code 做批量改造），本地电脑休眠、断网会导致会话中断，重连后上下文也容易丢。把这类长任务放到一台长期在线的机器上执行是可选做法之一，网络环境稳定能减少重连和会话重建带来的偏差。
6. 不可逆操作必须人工验收
重构、改配置、动数据这类操作，先要变更清单和影响面，确认后再执行；执行完对比差异，跑一轮冒烟测试。别只因为「它这次道歉很诚恳、保证得很好」就放手。
两种风格怎么取舍
| 灵活型（Opus 这类） | 保守型（GPT 这类） | |
|---|---|---|
| 强项 | 写代码、重构、抽象推理，出活快 | 边界清晰，不乱下结论 |
| 弱点 | 脑补、把推断当事实、擅自改行为 | 啰嗦、防御过度、频繁阻断 |
| 适合 | 有明确验收标准和证据链的任务 | 高风险、需要反复确认的场景 |
| 用法建议 | 配规则 + 证据 + 人工验收 | 给它明确的授权边界，减少确认疲劳 |
实际做法是按任务分工：探索性、有测试兜底的开发用灵活型；涉及对外发布、数据处理、不可逆操作时换保守型，或者在同一模型上加更严格的流程约束。换客户端或换模型都不能消灭幻觉，只能改变出错的方式。
注意事项
- 模型版本和行为会持续调整，以上是流程层面的做法，具体某代模型的表现请以自己实测为准，功能与配额以官方最新说明为准。
- 规则不是一次写完就永久有效，每隔一段时间要回看是否膨胀、是否互相冲突。
- 任何「它已经保证过」都不算验收通过，关键结论仍要人工核对一次。
小结
问题的核心不是模型笨，而是它没有把「已核实」和「推测」分开表达，也没有被要求为结论附证据。可以做的最小改动是：把态度要求换成可执行判据，让每条结论带原文和位置，数字交给脚本，规则分三层存放，长任务拆会话并保留关键上下文，不可逆操作先要变更清单再执行。做完这几步，道歉的次数会明显下降——剩下那部分，本来就是该由人来把关的。
