当长 AI 线程漂移且小错误滚雪球式增长

抱歉，我目前没有看到需要翻译的正文内容。请您提供要翻译的文本（除代码块和 URL 之外的部分），我会按照要求将其翻译成简体中文并保留原有的格式。

Context windows and decaying constraints

我把一个聊天窗口打开了三天，以便在旧功能上进行迭代。在线程的开头，我写了 “Django 3.2, Python 3.8, synchronous codebase” 并粘贴了几段真实的模型定义。到了第二天，助手开始建议使用 URL 路径转换器和异步视图。听起来很有道理，直到我尝试应用补丁时，测试套件因导入错误而崩溃。最近的 token 主导了注意力。模型一直在跟随最新的代码片段和示例，而不是我在线程顶部声明的约束，导致早期的假设悄然消失。

小的差异累积导致危险的运行

我曾经接受过一个生成的迁移，看起来在 diff 形式下还不错，但它使用了我三条消息前示例中使用的单数表名。该迁移在预演环境中运行，修改了错误的表。没有任何单一的建议是极端错误的。每个建议都依赖于一个微小的、隐藏的假设：变量名、默认标志、环境。这些假设叠加在一起，导致 CI 作业应用了我们不想要的迁移。模型并不理解副作用；它只会镜像最容易预测的上下文。

Source:

工具调用失败，助手填补空白

将模型连接到我们的日志搜索后，情况在好转之前变得更糟。一次查询因超时返回了截断的日志。模型读取了这段片段，并提出了一项代码更改，解决了完整日志未显示的问题。随后它自信地写出了补丁，而我们的自动化尝试应用它。由于助手从未看到超时错误，补丁中没有包含对日志形状的任何检查。从外部看，这似乎是糟糕的推理。实际上，这是一次缺失的工具响应以及提示中缺乏负向路径导致的。

在几起事件后，我添加了对工具输出的显式检查。现在每次工具调用都会返回状态码和长度字段。如果响应是部分的，助手会被要求回复一个特定短语，我们的编排器会检测到它。这是枯燥的管道工作：验证、记录，并拒绝在部分数据上采取行动。这个小改动防止了许多后续错误——模型本会捏造数值来完成叙述。

我实际采用的实用防护措施

我不再把长对话视为单一会话，而是把它们当作可变文档来处理。每隔几轮，我会发布一个简短的 “Current constraints” 区块，列出精确的版本、项目路径以及必须参考的一个小示例。如果模型生成的内容忽略了该区块，这就会触发我重置对话。我们还会对提示进行快照，并在沙箱化的测试运行器中执行生成的代码，只有在通过后才允许任何可部署的产出离开流水线。这些人为的摩擦虽然会增加一点工作量，却能捕捉到流畅回答可能隐藏的漂移。

在验证方面，我现在并行使用两种交叉检查。对于快速比较，我在共享工作区中对多个模型运行相同的提示，以便不一致之处显露出明显的假设；我已在团队笔记中记录了该工作流，并有时在专用的多模型聊天中执行它。对于任何涉及运行时行为的内容，我会让助手引用文档或测试，然后通过一次聚焦的研究过程（使用类似研究流的来源工作流）来验证这些声明。这两种模式结合起来，能够捕获大量隐藏的漂移。

更改我接受答案的方式

我把助手的输出视为需要机器和人工检查的草稿。听起来很枯燥，但它防止了另一次宕机：一次假设操作是幂等的重试循环提案。测试标记出非幂等性，补丁从未进入生产。我现在坚持在提示中提供简易、可运行的示例，并要求对任何自动化更改进行日志记录。模型仍然帮助我更快迭代。改变的是我们验证的方式、日志记录的位置，以及当对话开始出现偏差时我们重置上下文的速度。