DeepSeek 赢 Opus 的秘密，在怎么用它

看完 Latent Space 最新一期播客，我最大的感受不是「DeepSeek v4 多厉害」，而是一种隐约的不安，我们可能一直在浪费时间。

播客嘉宾 Ahmad Awais 带来了一组对比数据：在相同编码任务下，用他的方法调教 DeepSeek v4，效果可以逼近甚至压过 Opus 4.7。是的，那个号称地表最强的编码模型。

但最让我在意的不是这个结果本身。

而是他做这一切的方法，既不靠微调，也不靠换更大的算力。他靠的是一套他称之为 Taste 的方法论，说白了就是「怎么用模型」。

一、一个简单的事实，说明很多人用错了模型

节目开头，Awais 说了一句话，我反复看了两遍：「所谓多种 AI Agent，本质上最后都会收敛为一种，Coding Agent。」

这句话猛的地方不在于它对不对，而在于它直接否定了当下最火的多 Agent 协作叙事。你写 prompt 的那些 AI 写作助手、数据分析 Agent、客服机器人，在他看来都只是包装。只要是最终要落地为可执行结果的，底下跑的都是同一个发动机：代码生成。

但这不是我今天最想说的。

最让我触动的是他接下来的发现：在 CLAI 这个早期项目里，他们用了当时最好的模型，结果并不好。起初他们和所有人一样，觉得是模型不够强。但后来发现，问题不是模型，是他们「喂给模型的东西」，那些模糊的、缺乏上下文的、随意拼凑的指令。

再聪明的工程师，如果被扔进一个什么都没有的空房间，也做不出好东西。模型也一样。

二、Taste 不是玄学，它是被编码的工程直觉

Taste 这个词听起来很虚，很像那种「你学不来的感觉」。但 Awais 把它拆解成了几个非常具体的动作。

你如何拆解一个编码任务。你在什么阶段要求模型给你代码、而不是解释。你如何限制它的自由度，避免它生成不安全或低质量的代码。

这些听起来都很基础对吧？但问自己一个问题：你上一次给模型的提示里，有没有花 5 分钟去拆解任务结构？有没有明确告诉它「这个函数不要用递归」或「先给我架构再写实现」？

大多数人的答案是：没有。我们太习惯像用搜索引擎一样用模型了，丢一个问题进去，祈祷答案出来。

而 Awais 做的事情，本质上是把资深工程师的那些「隐性知识」，也就是通过多年踩坑积累下来的工程直觉，转译成了模型能理解的、结构化的输入。

他说了一个比喻：像对待一个初级工程师一样对待模型。给上下文、给约束、给反馈、别指望一次就完美。

这提醒了我，模型再强，也架不住你不会用。

三、从「选模型」到「用模型」，竞争维度变了

如果这件事只停留在技术圈，我不会专门写这篇文章。

但它有更广泛的意义。当同一个模型，在不同人手里可以差出几个档次的性能，这说明什么？说明竞争的本质在发生变化。

过去两年，AI 行业的核心叙事是「谁的模型更强」。GPT 打 Claude，Claude 打 Gemini，开源社区追闭源巨头。所有人都在盯着跑分，盯着榜单，盯着参数量。

Taste 方法论的出现，意味着一个新的竞争维度正在成形：不是选哪个模型，而是你会不会用。

这对创业者来说非常现实。如果你的团队能通过搭建一套稳定的方法论，提示模板、工作流约束、质量反馈闭环，让开源模型接近旗舰闭源模型的水平，那你的成本结构会发生根本性变化。

不再需要烧钱去追最贵的 API。不再被模型供应商绑定。你从「选模型的人」变成了「懂模型的人」。

四、对你来说，现在该做什么

节目最后提了一个问题，我觉得值得放在这里作为结尾。

回去看看你每天给模型的那些指令。它们，真的配得上一个优秀的工程师吗？

如果你发现自己被问到这个问题时犹豫了，那说明 Taste 这个维度，你确实还没有建立起来。

不需要一下子搞出什么高大上的方法论。就从最基础的三件事开始：写 prompt 之前先拆任务、给模型足够的上下文、控制它的输出边界而不是完全放任。

这听起来不像什么了不起的技能。但在一个所有人都在比「谁的模型更强」的行业里，懂得「怎么用模型」反而成了最稀缺的能力。

已经有读者在问了，下一期我打算写一篇 Taste 方法论的实操指南。感兴趣的可以先关注，别错过了。

如果觉得有启发，点赞、分享、推荐三连吧。也可以给我个星标，方便第一时间看到更新。

谢谢你看我的文章，我们，下次再见。