按不确定性选模型：DeepSeek Flash 用法指南

我相信群聊里的那组对比。但我不认为它体现了模型的真正价值。

有人分别使用 GLM 5.2 + Claude Code 和 DeepSeek V4 Flash + Codex，运行了同一个 prompt。第一次运行只用了二十多个回合，就做出了一个可以玩的游戏。另一次类似测试却留下了数百条记录，并陷入漫长的修复循环。第一次对比更有说服力，因为测试者和 prompt 都相同。但这个 prompt 仍然没有明确产品定义：目标用户、平台、核心乐趣、取舍以及验收标准都没有说清楚。

一个模型能让定义不充分的任务跑起来，只能说明它有能力补全缺失的信息。这并不能证明它构建出了你真正想要的产物。

两个维度，而非一张排行榜

我会从两个维度来评估模型。

Capability 决定了模型处理陌生问题时的能力上限：能否提出有价值的问题、制订连贯的计划、权衡产品取舍，以及在 bug 原因未知时提出假设。

Maturity 则体现了流程明确之后的可靠性：能否稳定使用工具、遵循计划、保持状态、从失败中恢复，以及是否愿意再次检查。

参数量可能会影响 Capability 的上限。Maturity 并不是参数量的简单函数；后训练、工具适配、上下文策略以及真实任务反馈同样重要。

这就是我看待当前 Codex 配置中 DeepSeek V4 Flash 的方式。它不是我在确定产品方向或进行开放式探索时的首选。但当目标和步骤已经敲定时，它很有价值：读取文件、进行范围明确的修改、运行检查、修复已知错误，然后再次验证。

如果从零开始，我会怎么做

如果要开发一款受 Angry Birds 启发的轻量级移动游戏，我会先让一个能力强的模型明确目标用户、平台、核心乐趣、视觉与玩法机制之间的取舍，以及第一版具体意味着什么。然后，我会让它把这个方向进一步拆解为模块边界、依赖关系、验收证据和恢复点。

当计划不再摇摆、每个步骤都有可观察的证据，并且经过对抗式审查后整体方向也不再发生变化时，我才会切换到一个 Maturity 更高的执行模型。是否切换，并不取决于对话回合数。

调试也遵循同样的规则。如果我大致知道 bug 在哪里，也知道该如何修复，我会使用速度快、Maturity 高的模型。如果我不知道问题出在哪里，我就会升级到能力更强的模型，让它重新构建对问题的认知模型。验收阶段需要拿到最初目标、计划、diff、测试结果、风险和运行日志，而不只是一句“完成了”。

不同模型之间的交接依据是不确定性，而不是文件扩展名。

我的实际衡量标准很简单：修复后的产物与最初预期有多接近，消耗了多少时间和 token 预算，以及这套方法能否复用。

你的判断信号是什么？在什么情况下，你会认为一项任务已经足够明确，可以交给成本更低的执行模型？

披露：本文在 AI 的协助下完成，并由作者审核。

如需采取进一步措施，你可以考虑屏蔽此人和/或举报滥用行为。