让模型回答“我不知道”，也是一种能力

模型能够把一句话写得很像结论，但读起来笃定，并不是这句话已经获得验证。构建应用时，我更在意它能否说明依据和限制。

先识别正在回答哪一种问题

“这个功能通常如何工作”与“我的设备现在是否正常”看起来相近，证据需求却不同。前者可以依据文档解释原理；后者必须结合当前状态。把历史配置、教程描述或旧截图当成实时状态，会得到形式完整但对象错误的答案。

我会先把问题分成概念、现状和决策。概念需要清楚定义；现状需要有时标的观察；决策还需要知道目标与代价。缺少其中一部分时，应当把缺口说出来，而不是用更长的回答填平它。

区分观察与解释

“接口返回成功”是一条观察；“整个业务全部正常”则是更大的推断。它们之间还可能缺少登录、数据读取或实际任务等证据。记录时，把已验证的步骤和未覆盖的范围分开，能够避免后续学习沿用错误前提。

如果资料给出相互矛盾的信息，我会先记录出处和时间，再判断它们是否讨论同一个版本、设备或场景。有时并不是其中一份资料错误，而是条件发生了变化。直接让模型在两者中挑一个，会掩盖真正需要澄清的问题。

信息不足也要回答得有用

承认不知道，不应该等于停止帮助。一个有用的回答可以先列出已有证据，再说明还差哪一项，以及怎样用低风险的方法补充。例如，在不能确认设备故障时，先读取状态和日志，而不是先重启、删除文件或更改配置。

对于带有执行能力的应用，还应把“能够操作”与“获准操作”区分开。模型提出的办法可以作为候选，但影响数据、权限和外部系统的动作，需要明确边界与验证。这是构建过程的一部分，而不是最后才补上的一句提醒。

回头检查回答留下了什么

学习笔记里值得保留的不只是成功答案，也包括哪些判断因为证据不足被撤回、哪些观察后来被新证据修正。这样，“不知道”就不再是答案的终点，而是下一次验证的起点。