DeepSeek V4 Flash 应该怎么用：把强模型留给不确定性
[series:Harness 深水区] [date:2026-08-01] [read:13min] [words:6.1k] #DeepSeek#Agent#模型选择#Codex#Harness
群里最近有一个很典型的对比。
同一个人先后用相同的提示词测试了 GLM 5.2 + Claude Code 和 DeepSeek V4 Flash + Codex。他说，GLM 二十多轮就把一个游戏做到了“第一遍写入的文件可以直接玩”。后来群里另一个人也拿类似的提示词测试 V4 Flash，留下了几百条会话记录，写代码很快，后面的改代码却花了很久。第一个人据此得出结论：GLM 比 V4 Flash 强。
这个前一个对比的证据说服力确实更强一些：它至少说明，在这个人的实际工作流里，两种模型—Harness 组合带来了明显不同的结果。我相信他们的测试结果，但我不认为这个结果能够反映模型真正的价值。这里的细节来自群聊转述，我没有把完整提示词、初始代码状态、客户端配置和验收过程当成已经独立核验的事实。
相同提示词提高了前一个对比的可比性，却不等于所有条件都相同。更重要的是，这个提示词本身也没有定义一个可以被一致验收的产品：它大致要求做一个“愤怒的小鸟”风格的 HTML 游戏，包含六种小鸟，符合物理规则，没有 Bug，交付前做几轮 Review。它看起来很通用，实际上把最重要的问题都留白了：给谁玩，什么平台，最重要的乐趣是什么，画面和玩法如何取舍，什么叫“符合物理规则”，以及怎样才算符合提问者心中的那个项目。
一个模型把这样的任务跑通了，只能证明它能替自己补需求、写出一个能启动的东西。它还没有证明自己做出了你真正想要的东西。
这里说的 Harness，就是 Codex、Claude Code 这类承载模型的运行环境：它决定模型能调用哪些工具，怎样保留上下文，如何处理失败，以及什么证据才算完成。
能跑，不等于交付
我现在会把 AI 产出的项目分成四层看：
| 层次 | 真正要问的问题 |
|---|---|
| 能不能跑 | 有没有一个可以启动、点击或执行的结果？ |
| 对不对 | 功能、约束和验收标准是否满足？ |
| 像不像 | 它是否接近人最开始想做的那个产品？ |
| 值不值得 | 为了这个结果，花掉的时间、Token 和返工是否合理？ |
群里的游戏提示词主要测第一层，可能碰到一点第二层，几乎没有测到第三层和第四层。它没有预期产品，只有“通了”或者“没通”。没有预期，就很难谈一致性；没有成本口径，也很难谈效率。
“二十五轮”和“三百三十三条记录”也不能直接相减。不同的 Harness 可能把工具调用、状态消息、重试和子任务记成不同的单位。它们可以作为真实工作流的信号，却不能当作严格控制变量的 benchmark。
真正值得比较的，不是“哪个模型把模糊题做通了”，而是：在同一份目标、同一份验收标准和同一份代码状态下，哪个模型组合能以更少的返工交付更接近预期的结果。
我更愿意把模型看成两条轴
我不太喜欢把模型排成一条从弱到强的直线。至少在我的工作流里，模型有两条可以区分、但实际会相互影响的轴：能力和成熟度。
能力，更接近模型面对未知问题时的上限：
- 能不能从一个模糊兴趣里提出真正有价值的问题；
- 能不能做产品取舍，建立复杂系统的整体模型；
- 能不能在架构和未知 Bug 面前提出有用的假设。
成熟度，更接近模型进入确定流程后的可靠性：
- 能不能稳定使用工具；
- 能不能遵循已经确定的计划，不随意扩大范围；
- 能不能保持上下文和中间状态；
- 出错后能不能从当前路径里跳出来，重新回到可验证的步骤；
- 是否愿意反复检查，而不是很快宣布“已经完成”。
能力像是在陌生城市里找到方向，成熟度像是拿着一张明确的清单把事情办完。一个模型可以很有想法，却在工具调用和长任务恢复上漂移；也可以没有太多启发性，却在明确的步骤里非常稳定。参数量可能影响能力上限，但成熟度不是参数量的简单函数，它还来自后训练、工具适配、上下文策略和真实任务反馈。所以我不会把 V4 Flash 简单归类成“小参数模型”；这里讨论的是它适合什么任务，不是用参数量替它做判断。
因此我说的“成熟度”也不是模型脱离环境后的一项固定属性，而是模型、Harness 和任务共同呈现出来的工作属性。
这也是我看 DeepSeek V4 Flash 的方式。我的观察不是它在所有问题上都更聪明，而是：当目标和步骤已经确定时，它更像一个可靠的执行节点。它通常能更稳定地使用工具、遵循既定计划，发现问题时也有机会主动跳出，而不是机械地沿着错误路径继续。这是截至 2026-08-01、我在当前 Codex/DeepSeek 接入方式下的工作流观察，不是统计结论。
这句话同时包含边界。V4 Flash 不是我用来讨论产品方向的模型。它在我当前的使用方式里不是多模态模型（不能直接读图、看截图），多模态工作本身就不适合交给它；即便只看代码，它对 UI 和视觉层的理解也比较弱。它的思考更流程化、基础化。当我需要真正探讨一个问题、寻找启发或做隐含取舍时，我不会先找它。
所以问题不是“V4 Flash 能不能做大任务”，而是：这个大任务里，哪些部分已经足够确定，可以交给它？
如果从零做一个愤怒的小鸟项目
假设我没有任何自动化流水线，今天才开始做这个兴趣项目，我不会把上面的游戏测试提示词直接扔给执行模型。我会先和最强的模型进行第一轮对话，大概这样说：
我有一个想法，想基于大家熟悉的愤怒的小鸟概念，做一个轻量级移动端游戏。暂时不考虑商业化，只希望用户玩得开心。我的美工资源有限，可能需要你协助出图，所以核心不在画质，而在玩法、数值和排行榜。我还没有完整的想法，请你先做必要的调研，然后和我一起讨论这个项目应该怎么开始。这是一个兴趣项目，不用过度考虑投入产出比。
这段话不是在要求模型马上写代码。我要它先帮助我把问题说清楚：受众是谁，平台是什么，用户为什么会玩，什么是卖点，哪些地方可以放弃，第一版做到什么程度才算成功。
这一轮最重要的产物也不是用户画像或一份漂亮的产品简报，而是人与模型共同形成的方向感。如果连“想做什么”都还在变化，我不会让一个执行模型替我把变化固化成几千行代码。
接下来仍然会用强模型，把方向变成方案，再把方案拆成实施计划。这里的“拆计划”并不等于列一个任务清单，而是要继续回答：模块边界在哪里，依赖关系是什么，每一步如何验收，失败时回到哪里。
什么时候可以切换模型
我没有一个“讨论满十轮就换模型”的规则。真正的切换信号是：方案已经成熟，继续发散不会显著改善结果。
在我自己的工作里，通常会看几件事：
- 候选方案已经比较过，关键取舍不再需要改变；
- 目标、非目标和验收口径已经写清楚；
- 下一步可以被拆成有边界的步骤，而不是继续问“我们到底要做什么”；
- 每一步都有可观察的完成证据，失败时知道回到哪个稳定点；
- 对抗式 Review（专门尝试推翻方案的审查）没有再提出会改变整体方向的问题。
有时是我自己判断这一刻到了，有时反而是强模型提醒我：这个方案已经足够成熟，不需要继续讨论。Review 在这里不只是交付后的检查，它也负责告诉我们何时可以从思考切换到执行。
下面这张表是一个判断辅助，不是一条必须照抄的固定流水线：
| 当前状态 | 更合适的模型 | 需要升级或回退的信号 |
|---|---|---|
| 目标还在变化，验收说不清 | 能力强的模型 | 候选方案或关键取舍仍在改变 |
| 计划已定，步骤可验收 | 成熟执行模型 | 计划漂移、工具错误反复、上下文丢失 |
| Bug 位置已知，修复路径清楚 | 速度快的成熟模型 | 小修复连续失败，或影响范围扩大 |
| Bug 位置未知，或进入最终验收 | 能力强的模型 | 验收失败，或产物与原始预期不一致 |
执行阶段才是 V4 Flash 的位置
计划成熟以后，任务的性质发生了变化。它不再是“请你发明一个产品”，而是：读取文件，修改明确的位置，遵循接口，运行测试，修复已经知道的错误，再检查一遍。
这时我更看重成熟度，而不是把最强模型一直占在每一个位置上。DeepSeek V4 Flash 可以承担这类工作：它不需要替我决定产品方向，只需要把已经决定的事情稳定地做出来。
这不是说执行模型永远不能思考，也不是说旗舰模型永远不应该写代码。它只是说明，模型选择应该跟着任务的不确定性移动：不确定性高时，能力是主要预算；不确定性降下来后，稳定性、速度和成本变得更重要。
Review 和查 Bug 也要按不确定性分流
我会把“查 Bug”再拆成两类。
| 情况 | 我的倾向 |
|---|---|
| 已经知道 Bug 大概在哪里，修复路径也清楚 | 交给速度快、成熟度高的模型，快速验证一个小改动 |
| 不知道 Bug 在哪里，只能提出假设、搜索和定位 | 交给能力更强的模型，让它重新建立问题模型 |
验收和 Review 则更接近第二类。执行模型交付的材料，不应该只有一句“已完成”，而应该包括原始目标、实施计划、代码 diff、测试结果、已知风险，以及必要的截图或运行记录。另一个强模型重新对照最初的预期，判断它是不是只做到了“能跑”。
如果不考虑 Token，我希望旗舰模型在 Review 后直接修改代码，而不是只给一份意见。但现实里要计算成本，所以我会动态交接：第一轮问题很多时，让旗舰模型先定位和判断，成熟模型实施；如果第一轮没有改对，或者我对执行模型第二次修复的信心已经下降，第二轮通常就让旗舰模型直接接管。
这不是一条固定的“强模型思考、成熟模型写代码”流水线。问题越小、路径越清楚，执行模型越合适；剩余的不确定性越大、返工代价越高，就越应该把任务升级回强模型。模型之间真正交接的，是不确定性，不是文件扩展名。
这也是为什么我不把它写成模型排行榜
我当然有自己的使用倾向：最强的模型留给产品定义、复杂规划、未知 Bug 和最终判断；速度快、成熟度高的模型做已知位置的修改；DeepSeek V4 Flash 则适合明确实施、工具操作、检查和重复性生产任务。
如果把这句话映射到我当前手上的工具箱，大致是：Fable 5 或 GPT 5.6 Sol Max 留给产品定义和真正未知的问题；Grok 4.5 处理我已经知道位置的 Bug；DeepSeek V4 Flash 则承担已经拆清楚的实施和检查。这里的型号只是 2026-08-01 的个人例子，原则比型号更重要。
但这不是一张永久有效的型号表。模型会更新，Harness 会改变，同一个模型在不同任务和运行环境里也会呈现不同的成熟度。读者真正可以带走的不是“下一次一定要用哪个型号”，而是三个问题：
- 这一步还有多少关键的不确定性？
- 失败以后，我能否判断它错在方向还是执行？
- 我是在为一次成功交付付费，还是只是在为一段看起来很聪明的轨迹付费？
我最关心的交付指标也因此很朴素：修完 Bug 后，产物和我最开始预期的东西有多一致；完成它花了多少时间和 Token；这套做法能不能在下一个项目里继续复用。单次“跑通”只是入口，不是结论。
换成更工程化的说法，就是看一次通过验收的成功交付成本，而不是看某一轮回答有多漂亮。做研究报告、整理表格或搭一个内部工具时，阶段也许不同，但“先降低不确定性，再把确定的步骤交给稳定的执行者”仍然成立。
DeepSeek 让我尊敬的地方
公开事实。 DeepSeek 在 7 月 31 日的官方更新里明确写到，V4 Flash 的公开 benchmark 使用了自家的 Harness minimal mode，推理级别为 max；同时，官方称 V4 Flash 原生支持 Responses API，并针对 Codex 做了特定适配。更新日志还把模型版本、评测运行环境和调用方式一起写出来了。官方更早的 V4 发布说明也提到面向 Agent 能力的专门优化，并表达了朝向 AGI 的长期愿景。V4 发布说明这些材料说明了产品动作和长期愿景，但不等于已经证明 V4 Flash 在所有任务里成熟度更高。
我的解读。 这些动作至少说明，在 DeepSeek 自己的产品理解里，模型和它所处的运行环境不是两件可以完全分开的事。至于“让每个人都能把 AI 当成生产力”，是我对它当前阶段的理解；它不是 DeepSeek 发布过的一句中间路线图。AGI 是公开的长期愿景，但不能反过来当成今天模型能力的证明。
我真正尊敬的，正是这个方向感：模型不只是为了在榜单上赢，而是要让更多人能把它放进真实工作里。V4 Flash 的价值未必是每次都替代旗舰模型，而可能是把大量已经明确、可验证、需要反复执行的工作，变成更多人负担得起、用得起、能持续交付的工作流。
这也解释了我为什么认为，短期内 Harness 可能比模型那条腿更粗——前提是模型已经跨过任务所需的能力门槛，而主要损耗来自工具、上下文、恢复和验收。Harness 不能替模型凭空创造判断力，但它能让已经存在的判断力少一点浪费，多一点兑现。上一篇文章《同一个 DeepSeek-V4-Flash，为什么在 Codex 里像换了模型？》讨论的是这条腿；这一篇讨论的是，什么时候该把哪种模型放上去。
结尾：不要问它能不能做，先问这一步是什么
我现在不会再用“让一个模型从头做完一个模糊项目”来判断它是不是好模型。那更像是在测试模型愿不愿意替你填空，而不是它能否交付一个你真正想要的东西。
我会先把工作分成思考、规划、执行、验收和修复，再看每一步剩下多少不确定性：强模型处理未知，成熟模型执行确定，独立的强模型负责判断是否真的完成。当执行中重新出现未知，路由就回退；当方案稳定下来，模型就可以换成更成熟、更快、更省的那一个。
这也顺带解释了上一篇留下的一句话：为什么同一个 K3 放在 Claude Code 里，可能比放在 Kimi 自家的 Harness 里更好用——模型名没有变，任务和它所处的完整运行栈变了。
本文引用
- DeepSeek API 更新日志：DeepSeek-V4-Flash-0731（公开评测的 Harness minimal mode、Responses API 与 Codex 适配说明）
- DeepSeek V4 Preview Release（Agent 优化、模型规格与 AGI 长期愿景）
- DeepSeek：Integrate with Codex（官方 Codex 配置）
注：文中关于模型成熟度、任务分工和群聊案例的判断，是作者截至 2026-08-01 的个人工作流观察，不是 GLM、DeepSeek 或任何模型的普遍排行榜。群聊截图不公开，数字只用于说明证据口径不能直接混比。