它根本不知道自己在改什么

---

去年11月，我接了个活，差点把自己搞抑郁。

给一个创业团队搭CI/CD流水线。他们用Claude Code，模型选的Claude 3.5 Sonnet，当时最新。老板拍着桌子说要做AI native开发流程，代码全让AI写，人只管review。听着挺酷，对吧？

第一周就翻了。

Claude Code在本地跑小项目刷刷刷的，挺快。但一接上他们的微服务架构——完了。编译报错之后，Claude根本不知道发生了什么。它只能看到终端输出的最后几行，然后开始猜。猜错了就再试，试错了继续猜。有一次为了修一个类型错误，它连续改了7个文件，把原本没问题的模块也搞崩了。

绝了。

我盯着屏幕看了十分钟，突然意识到一个问题——这玩意儿根本不知道自己在干什么。就像一个蒙着眼睛的顶级厨师，你告诉它"菜咸了"，它能列出一百种可能的原因，但它尝不到那盘菜。

这就是那个"断点"。模型和工程外壳之间，是断开的。你细想，当你的IDE里跑着第三方封装的Claude API，模型看到的只是你喂给它的prompt和它自己生成的代码。编译器的报错、linter的警告、测试用例的失败信息——这些真正能告诉模型"你错哪儿了"的数据，它拿不到。拿不到就瞎猜，瞎猜就瞎改，瞎改就崩得更惨。

我后来跟那个团队的技术负责人聊，他说了一句话我记到现在："我们花在调试AI写的bug上的时间，比我们自己写代码的时间还长。"

挺讽刺的。真的。

到了今年3月，我开始尝试用DeepSeek V3做代码生成。模型本身的能力不差，在纯文本生成上甚至有些场景比Claude还灵光。但问题还是一样——没有好用的Harness。我只能在Cursor里用DeepSeek的API，但Cursor的工程外壳是为OpenAI和Anthropic的模型优化的，很多容错机制、上下文管理策略，套在DeepSeek上就是不对。

举个例子。DeepSeek V3处理长上下文时，注意力的分布方式和Claude完全不同。Claude会死死记住最近的操作，DeepSeek则更容易——怎么说呢——"分心"。它会突然关注到几百行之前的一个注释，然后基于那个注释做决策。这在Cursor里就很灾难，因为Cursor的上下文窗口管理策略是假设模型会优先关注近期内容的。

又翻了。

我当时做了个很蠢的尝试：自己写了个wrapper，在每次调用DeepSeek API之前，手动把最近的编译错误、lint结果拼到prompt里。效果确实好了点，但维护成本高得离谱。每次模型升级，wrapper就得跟着改——这个逻辑大概调整了七八次吧，我已经记不清了。而且我那个wrapper只处理了编译错误，测试失败、运行时异常、依赖冲突——根本顾不上。说白了，就是打补丁，打完一个漏一个。

所以看到DeepSeek组建Harness团队的消息时，我第一反应不是"哦他们要出产品了"，而是"终于有人要解决这个问题了"。

你去看那些细节，会发现一个很有意思的事。DeepSeek对Harness的定义不是"给模型套个壳"，而是"Model + Harness = Agent"。这个等式——对，是等式，不是公式——透露出来的思路是：模型和工程外壳不是两个独立的东西，它们是一起设计的。这事儿圈内人都知道，Anthropic在SWE-bench论文里提到过，他们花在优化工具上的时间比优化提示词还多。为什么？因为工具接口就是你给模型设计的"世界"，这个世界设计得好不好，直接决定了模型能在里面做什么。

崔天一加入Harness团队这件事，外行可能觉得就是个普通的招聘新闻。但我在量化交易圈的朋友告诉我，这人在Jane Street做了9年，做的就是低延迟交易系统的工程架构。量化交易系统对稳定性的要求是什么？几毫秒内做多步决策，每一步都不能出错，出了错要有fallback，要有回滚，要有实时监控。这跟AI Agent要解决的问题几乎一模一样。DeepSeek挖他不是为了写代码，是为了补工程能力的短板——这个判断，我朋友原话是"忒准了"。

我上周试着用了下DeepSeek V4的API，配合他们新出的缓存机制。缓存命中之后，每百万token 0.0145美元。这个数字什么概念？Claude同级别的模型是0.50美元。差了将近40倍。

这意味着什么？

意味着DeepSeek可以设计极高频率的交互验证循环。你写一行代码，模型跑一次编译检查，失败了立刻修正，再跑一次，再修正。这个循环可以跑几十次，成本几乎可以忽略不计。但在Claude上，同样的操作会让你的账单直接爆炸——我上个月做测试的时候差点没被Claude的账单吓死，0.17美元看起来不多，但那是跑一个小脚本，如果是个中型项目呢？你品。

我在一个小项目上实测了一下。用DeepSeek V4写一个Python的数据处理脚本，开启高频率验证模式。模型写了代码之后，自动跑pytest，失败了就读报错信息，修正，再跑。来来回回跑了11轮，最后出来的代码一次通过。总花费：0.003美元。同样的任务我用Claude Code跑了一遍，花了0.17美元。代码质量差不多，但Claude只验证了2轮就停了——因为成本太高，工具层做了限制。

这就是成本优势带来的设计自由度。巴适得很。

不过说实话，DeepSeek Harness现在还处于早期。团队刚组建，产品大概还要6到12个月才能出来。而且他们现在严重缺人，崔添翼在X上天天发招聘，面试排满了还是招不够——我上周刷到他的帖子，下面评论都在调侃"这是要把整个AI圈的人都面一遍"。

我猜他们现在最头疼的是找到既懂模型又懂工程的人。纯模型研究员不懂工程系统的复杂性，纯工程师又理解不了模型的行为模式。这种人本来就没几个，还要愿意加入一个从零开始的项目。

挺难的。

但这事儿真正让我兴奋的点，不是DeepSeek要出一个对标Claude Code的产品。而是这是第一次有中国公司在"模型+工程外壳"这个完整闭环上，有了和Anthropic正面对抗的能力。OpenAI有Codex，Anthropic有Claude Code——它们每天有上百万次真实编程交互，这些交互暴露模型的薄弱点，反馈到下一版训练，模型变强了，Harness就能处理更复杂的任务。这个循环每转一圈，差距就拉大一点。没有这个循环的公司，模型进步靠的是公开数据集和benchmark。但公开数据集是静态的，是办公室里想出来的问题。真实交互是活的。

DeepSeek现在要做的，就是把这个循环建起来。

我去年踩过的那些坑——编译错误拿不到、测试反馈进不去、上下文管理策略不对——本质上都是因为这个循环没转起来。模型和工程外壳各干各的，中间断了一环。现在有人要把这一环接上了，而且是用一种很DeepSeek的方式：极致的成本控制、开源生态的加持、中文场景的天然优势。Claude Code和OpenAI的Codex都是以英文场景为主优化的，面对中文技术栈里的API文档、特定社区生态——你试试让Claude读阿里云的文档，经常理解偏差得离谱——DeepSeek有天然的理解优势。我最近在帮一个国内团队做技术选型，他们用的都是阿里云、腾讯云的国产服务，文档全是中文的。Claude Code处理这些文档时经常理解偏差，但DeepSeek V4读中文技术文档的准确率高出一截。如果再加上量身定制的Harness，这个差距会更大。

当然，路还很长。Harness团队刚组建，产品还没影。而且Claude Code已经跑了两年，市场占有率52%，年化收入25亿美元——这个数字我昨天才查的，应该没记错。这个差距不是几个月能追上的。

但方向对了。

我这些年写代码，最大的感受就是：工具决定你能走多远。一个好的Harness，不是让模型变聪明，而是让模型少犯错。或者说，让模型犯了错之后能自己发现、自己修正。

这才是Agent该有的样子。

不是"我帮你写代码"。

是"我帮你把代码写好"。