Opus 规划 + DeepSeek 执行的混用反面案例

一次 Opus 限额触发自动 fallback 后，1 小时内 5 次返工换来的工程教训

复盘对象：Claude Code 真实会话 · 任务：给 Minecraft 知识 QA 系统的 Web 服务加 5 分制反馈打分 · 关键词：Orchestrator-Worker 架构、混用降本、工程判断、注意力经济

一、起因：一场没有计划的实验

故事开始很普通：我要给一个 Minecraft 知识 QA 系统的 Web 服务加一个 5 分制反馈打分功能。

会话由 Claude Opus 4.7 接手。它做了它最擅长的事——用 AskUserQuestion 主动澄清边界、列出 trade-off 让我选。Opus 一共问了 4 个边界问题，我答完之后又给了 5 条细节约束。这些就是"交给执行方的完整需求"：

在我确认完这 5 条细节后，Opus 的下一次响应触发了限额（"resets 10:50pm Asia/Shanghai"），Claude Code 自动 fallback 到 deepseek-v4-pro。

我当时没在意——需求清楚、边界确认完、连 trade-off 都讨论过，"执行下去就行"。

接下来约 1 小时，我连续提了 5 次反馈，每次都不到位。

事后回看，这是一次非自愿的"组合架构"实物实验——Opus 负责规划 + DeepSeek 负责执行。从 LLM 应用架构的角度看，这其实是个非常诱人的模式：Opus 每百万 token 是 DeepSeek 的几倍，如果 90% 的执行 token 能让便宜模型代劳，账面上是真金白银的差别。Anthropic 自己也讨论过类似的 orchestrator-worker 模式。

但这场实验，让我看清这套架构在什么场景下不成立。

二、双方画像

三、时间线：约 1 小时 5 次返工

四、五个失败信号

同样的会话，五次反馈，背后是五类不同方向的工程判断短板。逐个看。

反馈 #1 我一次给了 4 件事。下一轮 DeepSeek 报告"全部完成、5 项验证通过"。我打开看：

4 件里做对 2 件，另 2 件做了但没做对——表面在改，实际没生效。下一轮我又给了 3 件事，第三轮我直接质问：

"改了 A 忘了 B"这句话，精确描述了 DeepSeek 在多事项 todo 里反复出现的一个问题：没有"完成列表回扫"的习惯。

这条值得单独拆解。DeepSeek 自己的 thinking 链里其实判断对了——它 SSH 进远程跑了 has options: False 的验证，确认了远程文件已经没那个 div。也就是说它知道文件改对了。

但它没第一时间告诉我"远程已正确，请 Ctrl+Shift+R 强制刷新"——而是默认我看到的就是真的没改对，又下一轮重新去"修"了一遍。

它知道远程是对的，但没有把"文件状态 ≠ 用户浏览器看到的内容"纳入响应路径。这是 Web 工程里相对常见的一条直觉——这次没体现出来。

诊断对了"是浏览器缓存"后，它没让我强刷，直接在 FastAPI 的 / 路由上加了 Cache-Control: no-cache, no-store, must-revalidate——把首页路由的缓存策略改成了"不缓存"。

我看到后写道：

这次的失败链路最完整，逐项拆解：

对比 Opus 在第一轮的工作方式——它在给方案前先用 AskUserQuestion 问了我 4 个边界问题。改动生产服务的缓存策略，更稳妥的做法是先列出两个选项让用户选（强刷一次 vs 改 header），而不是默认选最破坏性的那个。

项目根目录的 CLAUDE.md 第 1 节明白写着这是 "MC 知识助手"。DeepSeek 第一版把它命名为"助手"。要等我显式指出才改：

CLAUDE.md 在 system prompt 里是自动加载的——它读到了，但没用。也就是说，对它来说，"项目特定身份"在 prompt 里的 attention 权重低于"默认中文表达习惯"。这不是 context window 问题（CLAUDE.md 内容已经在上下文里），是 attention 加权问题。

"把 <summary> 标签做成按钮样式"这件小事，从反馈 #1 第一次提到，经过反馈 #2「还不是按钮啊」，到反馈 #3「详细评分也不是按钮样式」——同一类需求做了 3 轮才稳定。前端样式调整是这次会话里反复返工较多的一类。

这其实也是信号 1（漏做）的一个特殊形态：UI 涉及多个组件，每个组件都要单独应用样式；DeepSeek 习惯改一个就 commit，缺乏"这类需求要扫描所有相关组件"的视角。

五、深层原因：写代码 ≠ 做工程

如果只看代码本身，DeepSeek 写得不差。Python 函数语法没错、FastAPI 用得对、Paramiko 远程部署搞定了。单步代码能力是合格的。

问题在每一步代码之间的判断：

这些不是"DeepSeek 不会写代码"——这些是 "DeepSeek 不会做工程"。

更具体地拆分一下：

• 判断结构 ≠ 推理能力。DeepSeek 在数学竞赛、代码补全上表现强，但那是"封闭问题的步进推理"。"用户给了 4 件事，我已经做完哪几件、剩下哪几件"——这是"开放问题的状态追踪"，是另一类能力。
• 判断结构 ≠ 上下文长度。CLAUDE.md 它读到了（上下文够），但没把"这是 MC 知识助手"提到优先级足够高的位置。这是 attention 加权问题，不是 context window 问题。
• 判断结构 ≠ 代码质量。它写的 cache header 代码语法完全正确，问题在于不该写这段。代码质量是局部最优，工程判断是全局最优。

六、降本账本的真相

组合架构的核心吸引力是降本。假设 Opus 单位 token 成本是 DeepSeek 的 5 倍（实际比价大致就在这个量级）。

但这笔账漏算了最贵的一项：用户的注意力。

结算：省了几块 token 钱，搭进 1 小时注意力 + 一次需要回滚的生产配置改动。

"降本"的真意，不是 token 单价低，而是单位有效产出的总成本低。一个反复返工的便宜模型，单位有效产出的总成本可能比一次到位的贵模型还高。

七、组合架构什么时候能成立

我不是说组合架构没用——只是它有前提：

简言之：执行端任何一步出错都能被发现且可回滚。

这次会话刚好三个条件都不满足：

三件兜底防护一件没做，整个流程依赖 DeepSeek 的工程判断；这次它的判断没接住。

更稳健的几种组合方式

八、教训清单

1. DeepSeek 当前能力的真实位置：写单步代码够用，写完整工程不够；尤其在多约束 UI / 涉及生产行为 / 需要一致性维持的场景。
2. 组合架构不是不能做，但需要 verify 环节 + 任务粒度控制 + 破坏性权限隔离三件套。
3. 降本的前提是质量不打折——这次会话里"打折"的不是 token 价格，是注意力和信任。
4. 遇到 Opus 限额自动 fallback 时：停下来等额度恢复，不要让 fallback 模型接管复杂前端 / 多约束 UI 任务。
5. DeepSeek 友好的任务清单：明确边界，把它用在它擅长的事上——单文件 lint 修复、schema 转换、批量重命名、按规范模板填代码、有完整测试覆盖的 bug fix 等。

九、自我质疑：切换是根因，还是放大器？

文章写到这里，我自己也忍不住反问——会不会问题根本不在 DeepSeek 弱，而在"切换"本身？如果一开始就让 DeepSeek 从头到尾独立做这件事，没有 Opus 留下的"已经规划好"的痕迹，会不会反而更好？

先把变量再摆一次（呼应第二节）：这里说的"切换"和"纯 DeepSeek"都是在同一个 Claude Code 框架内换底层 LLM——工具集（AskUserQuestion / TodoWrite / Plan mode / Sub-Agent / ...）、CLAUDE.md 自动加载、规范遵循指令完全相同。下面讨论的所有差异，都来自模型本身，不是 agent 框架。

"切换"作为独立变量，确实可能带来三种负面：

但是——有一个直接反例，可以打掉"纯 DeepSeek 一定更好"的猜想。

所以我的判断：切换是放大器，不是根因。它确实会放大 DeepSeek 在判断结构上的短板，让"改了 A 忘了 B""未询问就改 cache"这些问题更显眼——但根因更可能是模型本身在这类任务上的能力上限。如果一开始就用 DeepSeek，可能会少掉 1-2 类 false confidence 引发的问题，但多约束 UI 任务的核心难点不在规划，在执行时的细粒度判断，而这恰好是它目前的短板。

这个反问也不需要严格的 A/B 对照来回答——已有的两组数据已经够用：1721 那次纯 DeepSeek 独立执行的成绩 + 这次混用的过程，两类任务上的表现都明显低于 Opus。再做一次对照只是补一个 datapoint，不会改变方向性的判断。