---
date: 2026-05-19
tags: [ai-collaboration, judgment, evidence-hierarchy, squash-merge]
---

# AI 当场推理 vs 用户记忆冲突时：优先信用户 + 用文件级一手证据裁判

## 场景

用户接手 session 说"我记得已经提交了 / 已经合了 / 已经做过 X"，AI 在已重新组织上下文（看 git / API 推理）后倾向回答"没有 / 我查不到"。继续兜 API / git ancestry / patch-id **会越走越偏**，因为这些都是间接证据，且**项目默认 squash + auto-delete 让多数 SHA-based 工具失效**。

## 一手证据 vs 间接证据

判"代码改动是否在 develop 上"，证据强度递减：

| 强度 | 方法 | 项目里的可靠性 |
|---|---|---|
| 🟢 一手 | `git show origin/develop:path/to/file` 看文件具体内容 | **永远可靠** |
| 🟡 强 | `git log origin/develop --grep="<commit msg 关键词>"` | 可靠（squash commit 通常保留主 msg） |
| 🟠 弱 | `git merge-base --is-ancestor` | **squash 后失效**（SHA 全改） |
| 🟠 弱 | `git patch-id` 比对 | **squash 后失效**（多 commit 合 1，patch 改写） |
| 🔴 易误 | Gitea API `head.ref` 含关键词过滤 | **auto-delete 后 head.ref = `refs/pull/N/head`，原分支名丢失** |

详细机制 + 检测脚本：[`2026-05-10-patch-id-detect-zombie-branches.md`](2026-05-10-patch-id-detect-zombie-branches.md)（已扩写覆盖 squash 场景）。

## 用户记忆是高质信号源

- 用户的"我记得已合"是**直接经验**，不依赖工具边界条件
- AI 的"我查不到"是**当场推理**，受工具选择、ref 是否 fetch、API filter 措辞影响
- AI-first 节奏下 PR 高频翻动，AI 重组上下文容易把"已合"误算成"未合"——用户记忆是**重要校准信号**

→ **冲突时不要继续用 API / SHA 查询找证据支撑自己**；停下，问用户具体改动点（"你记得改了哪个文件 / 哪行 / 哪个函数"），然后用一手 diff 一秒结案。

## 5/19 实战（反面案例）

用户接手 slot-4 上 `feature/ffai-agent-optimization` 分支：
- 我用 Gitea API `head.ref` 含 "agent" 过滤 → 没找到（PR #423 auto-delete 后 head.ref = `refs/pull/423/head`）
- 我用 `merge-base --is-ancestor` → false（squash 后 SHA 不在）
- 我用 `git patch-id` 对比 → 不匹配（5 commit 合 1）
- 给用户报告"未合，分支累积一周 Memory M1 工作未推"
- 用户："我怎么记得已经提交了？"
- 我**才** `git show origin/develop:memories.controller.ts` 看到 `TODO(#432)` 注释——**1 秒确认全部已合**

兜了 6 轮 API + 3 个 SHA-based 工具，最后一行 `git show` 结案。如果第一轮直接走文件 diff，会**整个少走 90% 的弯路 + 不会让用户来纠正**。

## 元规则

1. **判定问题：先识别"要回答的是什么"**——"代码是否在 develop 上"的答案是文件内容，不是 SHA 关系
2. **一手证据优先**——能直接读到的事实，不要绕弯到 ancestry / API 列表
3. **用户记忆 vs AI 推理冲突 = 工具边界条件触发的信号**——停下重新推理，转一手证据
4. **本地 ref 永远先 `git fetch origin --prune`**——基准过期会让一切下游推理都错
5. **项目工具有适用边界**——已沉淀的 learning 也可能只覆盖部分场景（5/10 那条 patch-id learning 漏写了 squash 失效，套上去就踩坑）；先验信任的工具用错往往比没工具还危险

## 适用范围

任何"已合 / 已做 / 已发"判定，特别是：
- 项目使用 squash merge（GitHub flow / Gitea flow 默认）
- 项目开启 auto-delete-on-merge
- AI-first 节奏下分支高频翻动
- 接手别人 / 别 session 留下的状态

## 关联

- [`2026-05-10-patch-id-detect-zombie-branches.md`](2026-05-10-patch-id-detect-zombie-branches.md)：squash 场景下 patch-id/ancestry 失效的工具机制与替代方案
- CLAUDE.md「Git 规则摘要」段：feature/* → develop = squash 是项目默认
- CLAUDE.md #10「Bug 解决用第一性原理」：本 learning 是同一原则在"判定问题"上的应用（不是 bug 修复，但同样的"绕 indirection 必踩"教训）