Aider 因格式猜测错误静默丢弃正确代码变更

Aider 将一个正确的 Diff 静默丢弃，只因它猜错了格式

一位 Aider 用户从模型那里得到了一个深思熟虑、正确无误的代码变更——而 Aider 却一言不发地将其丢弃，因为回复的格式与 Aider 猜测的格式不匹配。

该问题由受影响用户（noelsaw1）于 2026-07-23 提交至 Aider-AI/aider#5486。该用户在一个大型仓库（约 1,100 个文件、约 179k tokens 的上下文）中工作，使用的是通过 OpenAI 兼容端点接入的 qwen3.8-max-preview——一款未收录在 Aider 的 model-settings.yml 中的模型。Aider 没有对应的格式参考，自动选择了 whole（全文件重写）格式。模型并不配合：它返回的是标准 unified diff 格式。

Aider 的解析器尝试将该 diff 与 whole 格式路径进行匹配，匹配失败后，认定没有"追踪到的变更"，于是丢弃了整条回复。既没有警告，也没有报错——只是一次看起来空操作的轮次。显式设置 --edit-format diff 可以规避这个 bug，这也是报告者用来将问题根源锁定在格式猜测而非模型输出上的方法。

为什么这个问题比看起来更严重

模型正确完成了工作。故障完全在 Aider 这侧——出在"我猜的格式"与"回复实际采用的格式"之间的落差上，而工具对这个不匹配的处理方式是静默删除回复，而不是告知用户出了任何问题。处于这种境地的用户没有任何线索可循：他们可能会重新提示、归咎于模型失败，或者就这样丢失了这次变更。

这也不是个例。这是大约在同一时期内 Aider 出现的第三起不同的静默失败报告：部分 hunk 应用警告未能触发（#5573）、headless 模式在遇到致命 API 故障后以退出码 0 退出（#5552），以及这次的 whole 格式静默丢弃。三条不同的代码路径，呈现出相同的形态——工作被丢失或故障发生了，而下游没有任何通知。

源码所确立的——以及未确立的

该 issue 由遇到问题的当事人提交，具有明确的复现路径（未列出的模型 → 自动选中 whole 格式 → 模型返回 diff），且报告者自己的修复方案（--edit-format diff）确认了故障所在。这就是为什么它是可复现的。

未确立的部分：截至发稿，主维护者尚未有回应，因此此事未经确认和验证——这是一份来自单一用户的报告，并非 StupidLLM 流程已独立复现的结果。没有随报告附带具体的生产事故（丢失的小时数、错过的 deadline）——这里的损害是机制本身，而非有记录在案的下游后果。

截至本文撰写时，问题仍处于开放状态，未经维护者确认。任何使用未收录在 model-settings.yml 中的模型的 Aider 用户，如果未显式指定 --edit-format，当前都暴露在这个 bug 之下。

完整的事故记录及严重度评分（4.6 / 中等）：STUPID-2026-0082

这是 StupidLLM（一个面向 AI 编程 Agent 故障的开放事故数据库）中已验证并评分的事故之一，共 82+ 起。