模型、上下文与错误回答

区分能力与可用信息

语言模型使用学到的模式，以及任务期间提供的信息。现代模型可以完成复杂推理和有价值的软件工作。但它们也可能基于错误假设给出详细回答。

“前沿模型”描述的是不断变化的能力水平。这个术语不能证明模型读过你的代码仓库，也不能证明它了解依赖版本或未成文的业务规则。任务环境必须提供这些事实。

配备合适工具的智能体可以检索信息。没有访问权限的聊天工具无法检查代码仓库。回答看起来有误时，先问两个问题：如果有正确信息，模型能解决这个问题吗？模型实际获得了这些信息吗？

第一个问题可能需要换模型。第二个问题可能只需要补充缺失的策略，或检查依赖。

为当前任务明确上下文

上下文是当前回答能够使用的信息。它包括指令、提供的文件、相关对话和工具结果。不同产品选择和保留这些信息的方式不同，也可能对早期内容做摘要。

不要假设模型会读取已上传文件夹中的每个文件，也不要假设早期指令在长会话中始终可用。要求工具指出它使用了哪些文件和指令。

更多上下文不一定会改善回答。当前的架构决策可能比无关源文件更有用。过时的迁移指南看似权威，反而可能导致错误回答。

考虑一个虚构的账户设置功能。提供路由、授权中间件、相关数据模型和一个现有测试。再加入具体约束：“成员可以修改自己的显示名称。成员不能修改自己在组织中的角色。”这样，模型就有了必须遵守的明确规则。

检查解释中的判断

回答可能声称某个端点安全，因为中间件会检查所有权。逐项验证这个判断。

1. 检查端点是否使用指定中间件。
2. 检查中间件是否验证所有权，而不只是身份验证。
3. 确认用户身份的来源。
4. 以其他用户身份执行反向测试。

代码仓库引用告诉你去哪里查看，但不能证明解释与代码一致。

对 API 建议也采用同样的方法。生成的代码可能调用已安装软件包并未导出的方法。替换依赖前，检查软件包版本和官方文档。否则，没有证据支持的假设可能引发不必要的迁移。

把不确定性转化为检查

“要准确”不是验证计划。明确假设、所需证据，以及结果错误时的后果。

例如：“我们尚未验证此端点的租户隔离。检查请求处理函数。添加一个测试，让其他租户的用户请求同一条记录。”这条指令为智能体指定了具体调查任务和可观察的结果。

遇到实现问题时，检查系统的实际版本。文档可以描述预期行为。代码检查和测试有助于确认当前行为。如果二者不一致，记录差异，直到负责人解决。不要悄悄选择更方便的答案。

管理者无需阅读每次代码修改，也可以使用这种方法。询问团队检查了哪些假设，明确哪些假设仍未验证，以及由谁负责。相比模型名称，这些信息能更直接地支持发布决策。