DeepSeek 卡住后，强模型导师怎么排查？
一次真实的 DeepSeek TUI 排障复盘：强模型导师如何从 cargo check 日志追踪根因、指导纠偏，并把经验沉淀成可复用 skill。
需要继续找相关内容？
如果你想继续查工具名、术语、对比页或相关问题，可以直接搜全站，不用回到博客列表页重找。
核心结论
DeepSeek 不等于 Claude Code；真正可复用的是一套导师模型追日志、找根因、写纠偏指令、让执行模型重新验证的协作机制。
适合谁看
适合正在用 DeepSeek、Claude Code、Codex 或其他 AI Coding Agent 做真实工程任务，并希望把失败经验沉淀成团队规则的人。
关键判断
这次案例里，表面现象是 cargo check 失败，关键动作是回看完整日志和工具链上下文，而不是停在最后一条错误。
下一步建议
把执行模型的失败日志交给强模型导师复盘，再把根因、验证命令和纠偏话术写进 skill 或项目经验库。
你将学到
- + 为什么执行模型容易停在表面原因，而不是继续追根因
- + 强模型导师应该如何阅读日志、定位问题、生成纠偏指导
- + 如何让 DeepSeek 重新验证自己的结论，而不是直接接收答案
- + 如何把一次排障沉淀成导师 skill、执行 skill 和经验库
DeepSeek 卡住后，强模型导师怎么排查？
上期我们聊了“强模型导师模式”：用一个能力更强的大模型做导师，负责拆解、判断、纠偏和验收；再让 DeepSeek 这类执行模型去推进具体任务。
这期想把这个模式再往实战里推进一步。
很多人真正关心的不是“多个模型怎么分工”这个概念，而是一个更具体的问题：当 DeepSeek 执行任务时卡住了，甚至给出了一个看起来合理、但实际并不准确的结论，强模型导师到底怎么把它带回来？
这次我们用一个真实案例讲清楚。
问题不是“不会做”，而是容易停在表面原因
这次 DeepSeek TUI 在执行一个 Rust 项目任务。前面的代码实现已经完成，格式检查也通过了。到了验证阶段，它执行：
cargo check --workspace命令失败以后，DeepSeek 很快给出了一个结论：
本 shell 缺 MSVC linker。
如果只看最后的失败现象，这个判断并不是完全离谱。Rust 在 Windows 上编译时确实可能依赖 MSVC linker，link.exe 或 VS Build Tools 环境没有配置好，也确实会导致构建失败。
问题在于，DeepSeek 直接把最后看到的现象当成了根因。
在真实工程里，这种情况非常常见。执行模型不是完全不会干活，它能写代码、能跑命令、能总结状态。但当链路变长以后，它很容易在最后一个错误提示上停住，然后给出一个“看起来像根因”的结论。
这就是强模型导师应该介入的地方。
导师模型不是直接改，而是回头看过程
强模型导师的第一反应，不应该是立刻替 DeepSeek 改代码，也不是简单告诉它“你错了”。
更有效的做法是回头检查它的执行过程：
- DeepSeek 跑过哪些命令？
- 哪一步开始失败？
- 失败前有没有已经通过的验证？
- 它为什么会把 “缺 linker” 当成最终结论？
- 这个结论有没有被独立验证？
在这次案例里，导师模型继续检查了环境状态，发现机器并不是没有安装 VS Build Tools，link.exe 也不是不存在。真正的问题是：DeepSeek 当前 shell 没有加载 VS 编译环境，所以 PATH 里看不到 link.exe。
也就是说，正确结论不是“用户需要去安装 linker”，而是“当前 shell 没有加载 vcvars64.bat，需要先初始化 VS 编译环境，再重新执行验证命令”。
这个差别很关键。
如果把问题归因成“机器缺 linker”，用户可能会被带去重新安装 VS Build Tools，浪费时间，还可能破坏本来已经正常的环境。只有追到“当前 shell 没加载编译环境”这一层，后续修复才是最小、准确、可复用的。
用公共 discussion 文件夹做协作中转
我们这套流程里，导师模型和 DeepSeek 之间不是只靠口头提醒。
中间有一个公共 discussion 文件夹，导师模型会在这里生成指导文件，把排查结果写清楚：
- 当前表面现象是什么；
- 真正根因是什么；
- 应该如何验证；
- 应该执行哪些修复命令；
- 下次遇到类似问题时，不能直接把最后一条报错当成根因。
这一步很重要，因为它让“导师的判断”变成了一个可读取、可复查、可传递的工程文件，而不是临时聊天记录。
在这次案例里，指导文件里会明确写出类似这样的处理方式：
cmd /c "\"C:\Program Files (x86)\Microsoft Visual Studio\2022\BuildTools\VC\Auxiliary\Build\vcvars64.bat\" && cd /d D:\Sherlock\workspace\cdx-workspace\DeepSeek-TUI && cargo check --workspace"重点不是这条命令本身，而是背后的判断原则：
先确认工具是否真的缺失，再确认当前 shell 是否加载了正确环境，最后再决定是不是需要用户介入。
复制一段话给 DeepSeek，让它自己纠偏
导师模型生成指导文件以后，还会再生成一段可以直接发给 DeepSeek 的话。
这段话不是“替 DeepSeek 完成任务”的答案，而是要求它读取指定文件，重新验证自己的结论，并按导师给出的步骤纠偏。
这样做有两个好处。
第一，DeepSeek 不会被用户直接喂一个最终答案，而是要重新走一遍验证过程。它需要确认自己原来的判断哪里不完整，也要确认新的修复路径是否真的有效。
第二，这次排错过程可以沉淀成经验。下次再遇到工具链、凭据、PATH、shell 环境这类问题时，执行模型就不会直接停在表面错误上，而是会先做上下文自检。
这也是“导师模式”和“代劳模式”的区别。
代劳模式是强模型直接把事情做完。导师模式是强模型把卡住点拆开，告诉执行模型为什么错、怎么查、怎么验证，并让它把这次经验写进自己的 skill。
最后要沉淀成标准 skill，而不是一次性技巧
如果每次都靠人临时提醒，这个流程就不够稳定。
所以我们会把它整理成一套标准协作机制。
强模型这边，装的是导师 skill。它负责看日志、追上下文、找根因、写指导文件，再把可复用经验沉淀下来。
DeepSeek 这边，装的是执行 skill。它负责按任务推进，卡住时交出日志和结论，读取导师给的指导文件，重新验证，再更新自己的经验库。
这套机制和我们之前做 ACS 的思路很接近：不是指望某一个模型永远不犯错，而是把协作、评审、纠偏、沉淀，变成一套可以重复执行的流程。
真正提升的是“卡住以后怎么恢复”
单个模型的能力终究会有上限。
尤其是在复杂工程任务里，问题往往不是“能不能写代码”，而是：
- 出错以后能不能判断是不是表面原因；
- 能不能回头看完整执行过程；
- 能不能把一次排错变成下一次可复用的经验；
- 能不能让多个模型围绕同一个事实链条协作，而不是各说各话。
强模型导师模式的价值就在这里。
它不是为了证明 DeepSeek 等于 Claude Code，也不是为了否定任何一个模型。它解决的是一个更实际的问题：当执行模型卡住时，我们能不能有一套机制，把错误变成训练样本，把排错变成经验库，把单次协作变成标准流程。
如果这个流程能跑通，DeepSeek 这类模型在实战中的上限会被明显拉高。
延伸阅读
继续延伸
要点总结
- - 强模型导师模式的目标不是证明 DeepSeek 等于 Claude Code，而是提升协作恢复能力
- - 排障时先追完整执行过程，再判断最后一条报错是否只是表面现象
- - 指导执行模型纠偏，比强模型直接代劳更适合沉淀长期能力
- - 可复用 skill 和经验库，是多模型协作越跑越稳的关键资产
常见问题
这是不是在说 DeepSeek 已经等于 Claude Code？
不是。本文讨论的是工程协作效果：在强模型导师追踪日志、定位根因、指导纠偏和沉淀 skill 的前提下，DeepSeek 这类执行模型可以在真实任务中更接近强工具的协作效果。
强模型导师主要做什么？
它不只是给答案，而是看完整日志、识别表面现象和真实根因、写可执行的纠偏步骤，并要求执行模型重新验证。
为什么要沉淀成 skill？
如果每次都靠临时提醒，同类问题还会反复出现。沉淀成 skill 后，执行模型下次遇到类似工具链、凭据、PATH 或 shell 环境问题时，可以先走固定排查路径。
