当长聊天悄然导致构建失败

Source: Dev.to

请提供您希望翻译的正文内容，我将把它翻译成简体中文并保持原有的格式、Markdown 语法以及技术术语不变。谢谢！

上下文比你想象的更快消失

我进行了一周的调试讨论，期间我们反复迭代迁移、API 接口以及测试框架。开始时我告诉模型：Node 18、Postgres 13、TypeScript，不使用原生模块。经过几十轮对话后，助手开始建议只能在更新的 Postgres 中使用的 Python 代码片段和客户端库。每个新回复看起来仍然连贯，但它不再遵守我给出的约束。

结果是一个通过快速手动检查的补丁，却在 CI 中失败，因为测试数据库是生产模式的 MySQL 副本。失败方式并不显眼；它是一种缓慢的上下文漂移——对话内容与我实际运行的系统之间出现了潜移默化的不匹配。

幻觉通过缺失的工具潜入

我们将模型连接到模式提取器和 CI 状态端点。这些工具有时会返回部分或空的负载，随后模型会填补空白。

• 示例： 从提取器返回的模式被截断，模型猜测了列的类型。
• 生成的迁移在本地运行时创建了精度错误的列。
• 测试没有捕捉到问题，因为它们对模式层进行了 mock。

在这些猜测的基础上，后续的更改悄然依赖于错误的列。相比单行幻觉，我更担心的是链式反应：在长链路中的一个小错误假设会成为后续更改的基础。

隐式假设在长时间会话中累积

每次我们保持聊天打开时，都会累积隐含的默认设置。模型更倾向于最近的 token，因此新的示例和随手的评论比最初的约束拥有更大的权重。

• 我们看到助手在有人把另一个仓库的代码片段粘贴到同一线程后，开始默认超时、内存限制，甚至采用不同的认证流程。
• 一旦模型假设了错误的运行时或依赖版本，它会提出在语法上有效但在实际运行中错误的代码。

为了解决这个问题，我开始定期重置并在提示顶部添加显式的清单块。当我需要比较不同方法时，我会使用单独的多模型工作区，这样一个对话中的漂移不会污染另一个。拥有一个用于比较的空间，在我想通过共享聊天工具以受控方式并排测试替代修复时，帮助很大。

实用的验证和日志记录，切断反馈循环

在多次浪费的回滚之后，我们构建了廉价的防护措施：

1. 日志记录 – 将模型返回的所有内容以原始文本形式记录下来，并一起保存提示词和工具输出。这使我们能够随时间对比回复，检测建议何时偏离先前的约束。
2. 流水线检查 – 生成的代码在审查前会经过一条流水线：
   • 静态类型检查，
   • 使用精简数据集的沙箱运行，
   • 一组针对性的集成测试，以断言环境假设。
3. 工具验证 – 如果模式提取器返回的列数少于 N 列，或状态端点响应缓慢，我们会停止并将工具错误呈现给人工，而不是让模型自行猜测。
4. 引用验证 – 为了来源和验证，我常让模型精确引用文档章节或变更日志条目，然后通过正式的研究工作流进行交叉检查，而不是直接相信聊天中的声明。

我现在实际遵循的操作规则

• Segment work – 将冗长的工作拆分为短小的片段。在自然的检查点重置上下文：在重大重构之前、在合并之前以及每当有新成员加入讨论时。
• Manifest requirement – 在对话开头强制提供最小清单：运行时环境、数据库、测试夹具，以及一份简短的禁止更改列表。
• Tool call logging – 记录每一次工具调用，并使用简单断言验证响应。
• Changelog & assumptions – 强制模型输出紧凑的变更日志和它所做假设的列表（机器可读格式），以便 CI 能够拒绝引入未声明新假设的合并。
• Structured research pass – 当需要更丰富的验证或三角验证时，将论断交由结构化研究流程处理，分离模型推理与证据收集，并将外部来源视为事实依据，而非可选引用。