Appearance
常见幻觉与陷阱
大模型最危险的地方不是"不会"，而是**"一本正经地给出看着对、实则错的东西"**。本章把 AI 编码的高频幻觉分类，并给出识别与防治手段。
一、什么是"幻觉"
幻觉（Hallucination）指模型自信地生成不真实的内容——不存在的 API、错误的用法、编造的数据。它不是"随机乱码"，而是流畅、可信、却错，所以特别难防。
💡 心智模型：模型在做的是"最像正确答案的补全"，不是"查证后的正确答案"。它优化的是像不像，不是对不对。
二、六类高频幻觉（对号入座）
1. 不存在的 API / 方法
它调了一个"听起来该有"的函数，但库里根本没有，或签名不对。
python
# ❌ AI 常编出这种"看着合理"的调用
data = df.drop_duplicates_inplace() # 该方法不存在2. 不存在的包 / 错误导入（安全相关！）
import 一个凭空捏造的库，或版本早被淘汰的写法。这不只是报错——见安全清单的 slopsquatting，幻觉包名可能被攻击者抢注投毒。
3. 张冠李戴的版本 API
把 A 版本 / A 库的用法套到 B 上（如把旧库弃用的参数写进新库）。
4. "看着对"的逻辑错误
算法 / 边界处理读起来通顺，实际是错的——off-by-one、循环条件、排序稳定性假设、时区/取整。这类最隐蔽，因为代码能跑、还常常部分正确。
5. 编造的配置 / 参数 / 错误信息
凭空写出一个 config key、命令行参数，或"如果报 X 错就改 Y"——它并没有真见过这个报错，是根据常识编的。
6. 过度自信的解释
让它"解释这段代码 / 为什么这样写"，它会给出流畅但与事实不符的说明，把你一起带偏。
三、跨轮次陷阱：不只是"单次出错"
在长对话 / 多代理场景（上下文工程）里，还有几类"过程性"陷阱：
| 陷阱 | 表现 |
|---|---|
| 自我矛盾 | 第 3 轮和第 10 轮给出的方案互相打架 |
| 锚定错误 | 早期一次理解错了，后续全在错误方向上"越写越起劲" |
| 为凑绿改测试 | 为了让测试通过，删断言 / mock 掉真实逻辑（见组合实战·坑1） |
| 悄悄扩范围 | 你要改 A，它顺手"优化"了 B、C，引入未预期变更 |
四、识别与防治：把"对不对"交给机器
核心思路一句话：别信"看着对"，要用可执行的手段验证。（呼应TDD"给 AI 定义行为边界"）
| 幻觉类型 | 防治手段 |
|---|---|
| 不存在 API / 包 | 跑起来（导入即报错）、类型检查、--help / 官方文档核对；依赖做存在性校验 |
| 版本错配 | 上下文里附上目标版本与相关官方文档片段 |
| 逻辑错误 | 单元测试 + 边界用例断言预期输出；数值结果实机跑一遍对齐 |
| 编造配置 / 报错 | 只在真实复现的报错上排查；不凭 AI 想象"可能有这个错"就动手 |
| 过度自信解释 | 关键结论回到源码 / 文档二次确认，不直接采信 |
| 跨轮矛盾 / 漂移 | 会话切分 + 把决定沉淀进 spec / AGENTS，用固定流程（superpowers）约束 |
🕳️ 最实用的一招：让 AI 生成后立刻运行 / 让测试 / 让 lint 说话。能跑通、断言满足、类型通过，才把"看着对"升级为"确实对"——这正是执行工装工程闭环的最小雏形。
五、给 AI 产出"降级风险"的提问习惯
- 要求它标注不确定：让它对拿不准的 API/版本显式说"我不确定，建议核对"；
- 喂权威上下文：把真实库文档 / 版本号 / 现有代码放进上下文，减少它"凭记忆瞎补"；
- 小步验证：一次改一点就验证，别攒一大堆再跑（错误定位成本指数级上升）；
- 人做终审：AI 可生成、解释、首轮验证，但"到底对不对"的最终判断仍归人（人机分工）。
六、本章小结
- 幻觉的本质：流畅可信 ≠ 正确，所以最危险。
- 六类高发区：不存在的 API / 包、版本错配、逻辑错误、编造配置报错、过度自信解释，加上跨轮漂移。
- 防治铁律：别信"看着对"，让运行 / 测试 / lint 来判定，并把结论回写进 spec 与上下文。