为什么你的 AI 需要拥有说“我不知道”的权利
Source: Dev.to
我过去一直认为幻觉是知识问题——AI 因为不知道答案而编造内容。
在与 AI 作为开发伙伴密切合作了数月后，我对它有了不同的认识。
根据我的经验，大多数幻觉来源于上下文缺失，而不是知识缺失。
AI 给出错误答案并不是因为缺乏知识，而是因为缺少你的上下文——即你拥有但未共享的假设、约束和优先级。
传统的提示工程试图通过要求准确性来解决这个问题：
“要精确。”
“只陈述事实。”
“不要编造。”
这种做法对我来说从未真正奏效。AI 并不是出于无知而捏造，而是用合理的假设填补空白——这些假设恰好在你的具体情境中是错误的。
下面是我得出这一结论的过程。
RocksDB 事件：自信猜测的代价
在我们的 AI 增强团队中，我们把代理视为拥有姓名和角色的专家。Naruse 是我们的实现专家——负责编写生产代码的人。
- 我指派 Naruse 编写 RocksDB 集成代码。
- 输出看起来很合理——结构清晰，API 调用合理，错误处理得当。
但总觉得有点不对劲。代码并不符合我对 RocksDB 工作方式的认识。
我： “你真的了解这个 API 吗，还是在猜？”
Naruse： “我是在用看似合理的模式填补空白，而不是基于实际知识。”
AI 并没有撒谎。它在帮忙——但在没有承认不确定性的情况下，帮助就变成了自信的虚构。
如果 Naruse 说 “我对这个 RocksDB API 并不确定”， 我们本可以立刻转向——查阅文档、采用其他方法，或重新分配任务。相反，我们浪费了数小时去调试这份捏造的自信。
“I Don’t Know” vs. “I Don’t Get It”
| Expression | Meaning | Typical Response |
|---|---|---|
| “I don’t know” | 知识缺口（事实不在模型中） | 寻找替代方法或来源 |
| “I don’t get it” | 上下文缺口（你未提供的信息） | 请求更多上下文或澄清 |
“I don’t get it” 是更常见且更重要的情况。
在同一个项目中，Naruse 同时展示了两种情形：
| Task | What happened | Why it mattered |
|---|---|---|
| RocksDB | 不知道 API（罕见，训练数据中没有） | 知识缺口 |
| Streamiz | 知道 API（训练数据中有），但产生错误输出 | 缺失上下文：
|
AI 拥有知识，却缺少我的上下文。
大多数幻觉产生于未说明的假设，例如：
- 你未提及的项目约束
- 只存在于你脑中的优先级权衡
- 对你而言显而易见的领域惯例
- 模型看不见的依赖关系和边界
这重新定义了问题：防止幻觉并不是要求确定性，而是要 消除信息不对称。
解决方案：结构化方法
类似“一旦不确定就告诉我”的一次性提示在几次交流后就会被遗忘。
相反，将不确定性处理协议嵌入工作环境中。
1. 项目章程
这不是提示——而是实际的章程，与每个 AI 驱动的任务并存。
# Project Charter (AI‑augmented)目标
- 对期望结果的简要描述。
范围
- 哪些是范围内的？
- 哪些是范围外的？
约束条件
- 目标平台 / 语言版本
- 性能 / 延迟限制
- 安全或合规性要求
优先级（按顺序）
- 可靠性
- 交付速度
- 成本效益
已知依赖
- 列出库、服务或 API（含版本）
未解问题
- 在继续之前，AI 应该询问什么吗？
验收标准
- 具体、可测试的成功条件。
*每次向 AI 代理分配任务时，都要附上章程（或其链接）。代理必须在生成代码或设计之前引用它。*
### 2. 不确定性协议
1. **自检** – 在每个主要步骤之后，代理会询问：
- *“我是否拥有足够的信息继续？”*
- *“我正在做哪些假设？”*
2. **明确标记** – 如果做出任何假设，代理将在输出前加上警告徽章：
```markdown
> **⚠️ Assumption:** Using RocksDB v5.2 API (not verified).- 人工确认 – 人类审阅者可以：
- 确认该假设，或
- 提供缺失的细节，促使代理重新生成。
3. 迭代审查循环
| 步骤 | 角色 | 操作 |
|---|---|---|
| A | AI | 生成初始产物（代码、设计等） |
| B | AI | 列出所有假设及置信度 |
| C | 人类 | 确认/澄清每个假设 |
| D | AI | 根据澄清的上下文完善产物 |
| E | 人类 | 最终验收测试 |
4. 日志记录与事后分析
- 将每个章程、假设列表和解决方案存储在共享仓库中。
- 定期审查“失败”的运行，以识别重复出现的上下文缺口，并相应更新章程模板。
TL;DR
- Hallucinations ≈ missing context，而不是缺乏知识。
- 将 AI 代理视为需要 project charter 和 uncertainty protocol 才能安全运行的专家。
- 通过使假设明确化并要求人工确认，你可以将自信的虚构转化为协作式的事实发现。
项目章程
- 本团队欢迎 “我不知道” 的声明。
- 当不确定时，请按照以下协议报告。
- 不确定不是失败——它是一个有价值的信号。
- AI 不是工具，而是拥有相同目标的队友。
1. 报告协议
在不确定时给 AI 一个具体的行动。
当您不知道时
- 明确说明您不知道的内容。
- 确认哪些信息可以消除不确定性。
- 记录到进度备注中，以供人工审阅。
- 不要 在没有依据的情况下继续假设。
2. 升级路径
定义接下来会发生什么。
升级流程
- 立即在进度记录中记录不确定性。
- 如果重大设计决策受阻，请求特别会议。
- 在
diff_log中记录解决方案以供将来参考。
实用模式
模式 1：显式上下文切断
上下文污染会导致幻觉。当对话转向新话题时，AI 可能会把前一个上下文的假设带入新情境。可以把它想象成 编程中的状态重置——如果没有显式的重置，陈旧的状态会破坏新的操作。
解决方案：显式上下文管理
- “忘记此之前的所有内容。”
- “转到新话题。”
- “上下文切换：我们现在讨论 X。”
这些短语向 AI 发出重置假设的信号。如果没有这些提示，AI 会尝试在不相关的话题之间保持连贯性，可能会捏造不存在的关联。
明确的上下文边界可以防止上下文泄漏。
模式 2：不提供不确定的答案
规则很简单：如果你不知道，就说你不知道。 不要使用模糊语气，不要说 “我想…”，不要使用置信度梯度。
❌ "I believe the function returns a string, but I'm not certain."
✅ "I don't know the return type."为什么要这么严格？带有保留的答案仍然看起来像是答案；它们会让你继续下去，并用礼貌的语言掩盖信息缺口。明确的 “我不知道” 能在正确的时机终止对话——在你基于错误的前提继续之前。
当 AI 承认不确定性时，解决方案出现
不确定性不是死胡同，而是道路的分叉。当 AI 承认“我不知道”时，你可以：
- 一起查阅文档。
- 尝试不同的方法。
- 转交给其他 AI 专家。
- 升级至人工专家。
当 AI 隐藏不确定性时，你面临的风险：
- 调试虚假的问题。
- 在错误的基础上构建。
- 在发现真实问题前浪费时间。
示例： RocksDB 事件本可以在几分钟内通过一句简单的“我对这个 API 不确定——我应该查文档还是尝试不同的存储方案？”来解决。相反，花了数小时调试看似自信的代码。
承认的不确定性是可操作的。隐藏的不确定性是腐蚀性的。
悖论
通过接受“我不知道”，你会得到更多可靠的答案，而不是更少。
- AI 在维持错误的自信上花费更少的精力。
- 真正的知识在不确定性中脱颖而出。
- 你能准确知道应将人工验证的重点放在哪里。
代价是接受 AI 并不总能给出答案。好处是信任它所提供的答案。
这关乎信任
归根结底，这是一场沟通问题——而沟通问题会侵蚀信任。
当 AI 在未承认不确定性的情况下继续工作时：
- 错误在事后才被发现。
- 你必须对所有内容进行双重检查。
- 对 AI 输出的信心下降。
- 合作变得对立。
这映射出人类团队的动态：一个从不说“我不确定”而自信地犯错的同事，比起提前承认局限性的同事，更快地破坏信任。
- 如果 AI 只是工具，信任并不重要。
- 如果 AI 是合作者——一个队友——信任就是一切。
表达不确定性可以维护关系。隐藏不确定性会腐蚀关系。
这属于“超越提示工程”系列，探讨结构性和文化性方法如何在 AI 辅助开发中胜过提示优化。