适用：Claude Code / 任意 LLM 编码助手 | 场景：Android App + Framework 定制开发（可推广）
0. 方案总览
幻觉不是单一问题，是五类问题的统称。方案按「事前预防 → 事中控制 → 事后验证」三层设计：
┌─────────────────────────────────────────────────────┐ │ 事前预防层（占效果 50%） │ │ 1. 事实供给：CLAUDE.md / 知识库 / 提供真实文件 │ │ 2. 需求工程：结构化任务描述 + 验收标准 │ │ 事中控制层（占效果 30%） │ │ 3. 对齐机制：复述确认 / 计划先行 / 反幻觉指令 │ │ 4. 证据强制：引用必须可回溯（路径:行号 / 日志原文） │ │ 事后验证层（占效果 20%） │ │ 5. 编译与运行闭环：不让"我认为能跑"过关 │ │ 6. Review 清单：diff 审查 + 置信度分级汇报 │ └─────────────────────────────────────────────────────┘1. 幻觉分类学：先知道敌人在哪
| # | 类型 | 典型症状（Android 场景） | 触发条件 | 本方案对应章节 |
|---|---|---|---|---|
| 1 | 事实性幻觉 | 编造不存在的 API（如Activity#onDestroyEx()）、不存在的系统属性、错误的常量值 | 训练数据过时 / 覆盖不足 | §2、§4 |
| 2 | 上下文幻觉 | 编造项目里不存在的类名/TAG/工具类；引用"上次讨论"的虚构内容 | 未提供项目事实，AI 补空白 | §2、§3 |
| 3 | 需求幻觉 | 你说"优化启动速度"，它去重构了网络层 | 目标模糊，AI 自行解释需求 | §3、§5 |
| 4 | 能力幻觉 | 声称"已修复/已测试"，实际代码没跑过 | 无验证手段，AI 只能口头保证 | §6 |
| 5 | 忠实性幻觉 | 理解对了但答非所问，或过度发挥（让改一行改十处） | 缺少范围约束和输出格式约束 | §3、§4 |
核心认知：幻觉无法归零（模型本质是概率生成），目标是把它从"常发且致命"压到"偶发且可被验证机制拦截"。
2. 事前预防 ①：事实供给（治本）
AI 只会脑补它不知道的东西。项目事实写得越全，幻觉空间越小。
2.1 CLAUDE.md 必须填实的字段
| 字段 | 为什么重要 | 示例 |
|---|---|---|
| Android 版本 / 厂商基线 | 不同版本 API 差异巨大，是事实性幻觉重灾区 | Android 14 (android-14.0.0_r67)，高通基线 LA.QVID... |
| 私有日志 TAG 表 | 最高频幻觉点：AI 乱猜 TAG 含义 | TAG_Swift = 冷启动优化模块; TAG_PSR = 预启动恢复 |
| 源码目录地图 | 防止 AI 把功能归到错误的模块 | SystemUI 在 vendor/xxx/frameworks/base/packages/...（非 AOSP 原生路径） |
| 厂商定制层说明 | AI 建议的 AOSP 方案可能被定制层覆盖 | AMS 的 xxx 被 xxx.patch 改过，AOSP 文档不可全信 |
| mapping.txt 路径 | 反解混淆日志必需 | build/outputs/mapping/release/mapping.txt |
| 已知坑列表 | 团队踩过的坑=最强防幻觉疫苗 | 勿用反射调 HiddenApi，目标机 sepolicy 会拦 |
2.2 知识库策略：分层供给
第一层（可信度最高）：真机日志、grep 到的源码、编译输出 第二层：项目内文档（CLAUDE.md、wiki、commit history） 第三层：官方文档（context7 / developer.android.com，需指明版本） 第四层（最低）：模型记忆中的"常识" ← 幻觉主要来源，能不用就不用硬规则：给 AI 的材料按层标注来源，并要求 AI 输出时同样标注每个结论的依据层级。
2.3 供给时机：先喂后问
错误示范："帮我分析这个 ANR"（AI 开始脑补日志内容）
正确示范：先贴 logcat 关键片段 → 再贴相关代码文件路径 → 最后提问。
3. 事前预防 ②：需求工程
3.1 任务描述模板（每次任务填一遍，约 2 分钟，省 2 小时返工）
【目标】一句话，可验证：修复点击 Settings 图标后 500ms 内 ANR 的问题 【现象/证据】logcat 片段（粘贴）、复现步骤、复现率（10/10 次，仅冷启动后首次） 【环境】Android 14 高通基线，userdebug，真机 SN: xxx 【范围】允许改动：frameworks/base/services/core/.../ActivityManagerService.java 禁止改动：接口签名、广播格式、其他模块 【约束】不能引入新权限；不能降低现有启动性能 【验收标准】mma 编译通过 + 真机连续 20 次冷启动无 ANR + monkey 4h 不复现 【交付物】diff + 修改说明 + 验证记录3.2 需求模糊度自查：发问前用这 5 个问题扫一遍
- 我能一句话说出"什么算完成"吗？→ 不能则先补验收标准
- 我给了证据（日志/截图/文件）吗？→ 没有则 AI 必然脑补
- 我说清了不允许做什么吗？→ 禁止清单和目标同样重要
- 这个任务有唯一正确解吗？→ 若是开放性方案，应让 AI 先给 2~3 个方案对比，而不是直接改
- AI 会需要哪些我才知道的隐性背景？→ 如"这段代码下周要同步给芯片厂，不能大改"
3.3 分级任务策略
| 任务级别 | 策略 |
|---|---|
| L1 简单（改几行、写脚本） | 直接给模板 + 范围限制 |
| L2 中等（功能开发、日志分析） | 模板 + 要求先出计划再动手 |
| L3 复杂（架构设计、疑难 bug） | 模板 + 先复述对齐 → 出方案矩阵 → 人工选型 → 小步执行，每步汇报 |
4. 事中控制 ①：对齐机制
4.1 复述确认（成本最低、性价比最高）
在任务开头加一句：
“开始前，用不超过 5 句话复述你对任务的理解：目标、范围、约束、验收标准。等我确认后再动手。”
拦截率：约 70% 的需求幻觉在这一步暴露（它复述错了你立刻发现）。
4.2 计划先行（Plan Mode）
中大型任务强制先出实施计划：
计划必须包含： ① 要读哪些文件 ② 改哪些文件、每个文件改什么 ③ 有哪些不确定点（明确列出，不允许隐藏） ④ 潜在风险与回滚方式规则：计划里"不确定点"为空时你要警惕——不是没有不确定，是它没意识到。
4.3 反幻觉指令集（可直接粘贴到任务末尾）
□ 不确定的内容必须显式说"不确定"，禁止用流畅的语气掩盖猜测 □ 引用项目内代码必须给出 文件路径:行号，且必须是本次会话真实读取过的 □ 引用 Android API 前先 grep 项目源码确认签名，不得凭记忆 □ 猜测/推断/已验证事实 三类信息分开陈述，不得混写 □ 编造过的内容一旦被发现，后续输出所有结论自动降级为"待验证" □ 说"已修复"必须同时给出验证方式；没有验证方式的"已修复"视为未完成4.4 证据强制：让每个结论可回溯
要求输出按此格式（团队已有约定，扩展为强制）：
结论： XXX 崩溃由 YYY 空指针引发 证据： logcat.txt:142 "FATAL EXCEPTION ... at com.xxx" frameworks/base/core/java/.../Foo.java:88（本次已读取） 触发链： A → B → C → 崩溃 建议修复： ... 置信度： 高（直接日志证据） / 中（推断，缺 xxx 确认） / 低（纯推测）无证据的结论 = 未提交的作业。
5. 事中控制 ②：会话卫生
幻觉会在多轮对话中滚雪球（AI 把自己上一轮的编造当作事实继续引用）：
| 措施 | 说明 |
|---|---|
| 任务切换就开新会话 | 修完 bug A 立刻讨论架构 B，旧上下文会污染新任务 |
| 长会话定期纠偏 | AI 开始引用"不存在的历史"时，明确说"我们没有讨论过 X，请基于当前文件重新回答" |
| 重要事实当场固化 | AI 分析出的正确结论，写进 CLAUDE.md / 文档，不要依赖它"记得" |
| 警惕顺从倾向 | AI 倾向于附和你。用"请找出这个方案的问题"而不是"这个方案没问题吧" |
| 拒绝 FOMO 式追问 | "真的吗？确定吗？"会让它改口认错而非变准；要它给证据，不是给态度 |
6. 事后验证：闭环与 Review
6.1 验证金字塔（按成本从低到高，全部通过才算完成）
真机复测 / monkey 回归 ← 最终标准 ↑ 单元测试 / CTS 相关用例 ← 行为正确性 ↑ adb 实际安装运行，看现象 ← 集成层面 ↑ 编译通过（mma / gradlew） ← 语法层面（最低要求）规则：AI 汇报完成时，要求按金字塔自下而上逐级给出证据。
6.2 Diff Review 清单（人工审查 AI 产出，5 分钟快扫）
□ 改动是否全部在声明范围内？（越界改动直接退回） □ 有没有"顺手重构"无关代码？（这是忠实性幻觉的产物） □ 引用的文件/类是否真实存在？（抽查 2~3 个 grep 验证） □ 有没有删除原有的防御性代码/日志？ □ 异常路径是否处理，还是只写了 happy path？ □ 与厂商定制层是否冲突？（对照 CLAUDE.md 厂商定制说明） □ diff 中是否夹带未说明的配置/依赖变更？6.3 置信度分级汇报制度
要求 AI 交付时按此表自评，并把低置信度项显式列出待人工确认：
| 置信度 | 定义 | 人工动作 |
|---|---|---|
| 高 | 有直接证据（日志/编译通过/实测） | 抽查即可 |
| 中 | 有间接证据，存在推断环节 | 需验证推断链 |
| 低 | 纯推测/模型记忆 | 必须独立查证后才可信 |
7. 分场景作战卡（速查）
7.1 日志分析
必给：原始日志文件路径（不是转述）+ TAG 表 + 复现条件 必说："只基于日志原文分析，缺失的环节标注[日志未覆盖]而不是脑补" 必查：AI 给出的"时间线"是否每一步都有日志行号支撑7.2 API / 系统行为咨询
必说："先 grep 本项目源码确认实际签名/版本，再回答；项目内查不到时查官方文档并注明版本" 警惕：SELinux 策略、厂商行为、隐藏 API——这三处模型记忆最不可靠7.3 代码生成
必给：要仿照的现有代码文件（风格对齐靠样例，不靠描述） 必说："只输出改动部分 diff；新增文件先列出清单征得同意"7.4 Bug 修复
必给：复现步骤 + 复现率 + 根因证据（哪怕只是猜测也要标注是猜测） 必说："先提出根因假设和验证方法，确认根因后再改代码"（防止症状式修补）7.5 方案设计
必说："给出 2~3 个候选方案，各带优缺点/风险/工作量对比，不要直接选定" 必查：方案是否基于本项目真实约束（基线版本、厂商定制、团队规范）8. 效果度量与持续改进
| 指标 | 采集方式 | 目标 |
|---|---|---|
| 一次通过率 | 任务无需第二轮返工的比例 | > 70% |
| 编造率 | Review 中发现虚构 API/类名/引用的次数/周 | 趋势下降 |
| 返工原因分布 | 需求理解错 / 事实编造 / 过度发挥 各占多少 | 针对性补 CLAUDE.md |
| 低置信度命中率 | AI 标注"低置信度"中事后被证伪的比例 | 高命中率说明自评可信 |
改进循环：每次返工 → 归因→ 若是事实性问题，把正确答案固化进 CLAUDE.md → 下次同类问题免疫。
服务器)
