3 篇博文 含有标签「软件工程」

很多人刚开始做大模型应用时，会把上下文理解成“聊天记录”。用户说过的话越多，全部拼接给模型，似乎模型就越了解用户。

但实际情况往往相反。历史消息越长，越容易混入过期信息、无关闲聊和互相冲突的指令。模型还可能因为上下文太长而超出限制，或者忽略真正重要的内容。

科学的上下文管理不是尽可能多地塞内容，而是：

每次只给模型完成当前任务所必需、可靠、最新的信息。

大模型很擅长理解人话，也很擅长把结果组织成看起来完整的句子。但在真正的业务系统里，“看起来合理”远远不够。

比如用户让 AI 查询订单，大模型可能返回这样一段内容：

{
  "order_id": "12345",
  "include_items": true
}

这段内容看上去没有问题，可它只说明模型提出了两个参数。它没有证明订单 12345 真的存在，也没有证明当前用户有权查看这个订单。

因此，大模型应用通常需要连续做三层校验：先确认内容能不能读，再确认格式是否符合约定，最后确认它是否符合真实业务规则。

有次上线一个看起来很轻的生成接口，前端只是多加了一个“重新生成”按钮，工作流层为了稳妥又补了自动重试，结果当天晚上数据库里就出现了三份互相打架的结果。产品同学以为模型突然变飘，工程同学第一反应去翻 Prompt，最后真正把问题钉住的，却是一串再普通不过的事实：入口没有幂等键，调用链没有统一 traceId，谁也说不清那三次请求到底是不是同一件事。