底层模型相近，为什么 AI 产品的能力还是不一样？

最近实际用 AI 做产品时，我开始注意到一个以前没有认真想过的问题。

OpenAI 有 ChatGPT、Codex、Work，Anthropic 有 Claude、Claude Code、Claude Design。

同一家公司的这些产品，具体使用的模型版本和配置未必完全相同，但往往建立在相同或相近的模型家族之上。

那为什么实际使用时，能力差异还是很明显？

比如 ChatGPT 本身也会写代码。但真的要进入代码库、修改文件、运行测试、处理 Git，我还是会去 Codex。

Claude 也可以讨论代码和设计，但到了 Claude Code、Claude Design，又分别表现出更强的工程和设计执行能力。

所以，一个 AI 产品最终好不好用，显然不能只看底层模型。

中间还有一个很重要的概念：Harness。

从 Model 到 Product，中间还有一层 Harness

可以先粗略理解成：

Model 提供基础能力，Harness 负责把这些能力组织成可以完成某类工作的系统。

一个 Harness 通常会决定：

• 模型收到什么 instructions；
• 能读取哪些 context；
• 可以使用哪些 tools；
• 在什么 runtime 里工作；
• 能否连续执行多个步骤；
• 有哪些 permission；
• 怎样验证结果是否正确。

所以一个 AI 产品的能力，可以粗略看成：

Model + Harness + Product Design

模型决定理解、推理和生成能力的上限。

但从“模型知道怎么做”到“用户真的拿到了结果”，中间还有很多产品和工程设计。

1. 它能看到什么？

假设我要排查一个 Bug。

在普通 Chat 里，模型通常只能根据：

• 我贴出来的代码；
• 报错信息；
• 上传的文件；
• 当前对话；

来判断问题。

如果真正进入 Codex 或 Claude Code，它还可以主动读取：

• repo 结构；
• 相关源代码；
• Git diff；
• 当前 branch；
• 项目规则；
• build 和测试结果；
• 前一步执行后产生的新状态。

很多软件问题并不存在于某一个文件里。

一个接口出错，原因可能在数据库 schema、另一个 service、旧 migration，甚至前几天的一次改动。

所以 Coding Agent 看起来“更懂项目”，不一定只是模型更强。

它获得了更完整、也更实时的项目上下文。

2. 它有没有实际执行任务的工具？

模型自己并不会真的修改电脑上的文件。

它可以判断：

下一步应该运行测试。

但要真的运行测试，还需要产品给它相应的工具。

Coding Agent 通常会拥有：

• 文件读写；
• 代码搜索；
• Git；
• shell；
• build 和测试工具；
• 浏览器或其他开发工具。

这里的 shell，简单说就是命令行执行环境。

例如我们平时在 Terminal 里运行：

git status npm test python app.py

有了 shell，AI 不只是告诉我“你可以跑一下测试”，而是自己运行、读取真实结果，再决定下一步。

所以：

会生成代码，和能修改一个真实的软件系统，是两件事。

前者主要依赖模型能力。

后者还需要工具和执行环境。

3. 它能不能自己完成“做 → 看结果 → 再做”？

普通聊天很容易形成这样的工作方式：

我问 → AI 回答 → 我去执行 → 把结果拿回来 → AI 再回答

Agent 的工作方式更接近：

理解目标 → 执行 → 看结果 → 判断 → 修改 → 再执行

这就是 agent loop。

它的重要性在于，现实工作很少第一次就完全正确。

代码会报错，测试会失败，依赖会冲突，页面也可能和预期不一样。

如果每出现一次新情况，都需要人重新把信息搬回来，任务仍然主要由人推动。

Agent 可以自己看到测试失败，再继续查原因和修改。

这时候 AI 才从“回答问题”进一步走向“完成任务”。

4. 不同产品，需要不同的工作环境和反馈

这也是为什么 Coding Agent 和 Design Agent 会慢慢变成不同的产品。

写代码时，可以依靠很明确的反馈：

• test pass / fail；
• build 是否成功；
• lint；
• 程序实际运行结果；
• Git diff。

因此 AI 可以：

修改 → 测试 → 失败 → 再修改 → 再测试

设计需要的反馈完全不同。

如果模型只能在聊天框里讨论设计，它很难直接判断：

• 页面重心是否舒服；
• 间距是否合适；
• 字号层级有没有问题；
• 几个组件放在一起到底是什么效果。

设计类产品会给模型画布、渲染结果、组件、设计系统和视觉修改工具。

模型可能相近，但工作环境不同，能形成的反馈循环也不同。

所以工具并不只是帮 AI “执行最后一步”。

模型知道自己能使用什么工具，也会改变它解决问题的方式。

有 shell 和测试，它可以先跑一下再判断。

有画布，它可以先做出来再调整。

5. 一旦 AI 开始动手，权限也变成产品能力的一部分

这也是我最近真实开发中才开始明显感受到的问题。

Chat 主要输出文字时，权限存在感并不强。

但 AI 一旦要：

• 修改文件；
• 访问网络；
• push Git；
• 读取凭据；
• 操作数据库；
• 部署生产环境；

就必须回答另一个问题：

它被允许做到什么程度？

所以成熟的 Agent Harness 还需要处理：

• sandbox；
• 文件访问范围；
• network permission；
• approval；
• 外部服务身份；
• 任务状态和恢复。

这也是为什么我明明告诉 Codex：

这个任务一直做到发布。

执行过程中仍然可能遇到系统审批和外部登录。

业务上允许完成一个目标、系统允许执行某个动作、GitHub 等服务允许当前账号操作，本来就是不同层的权限。

这些问题只有在 AI 真正从“说”走向“做”以后，才会变得非常具体。

所以 ChatGPT 和 Codex 的差别，不只是“谁更会写代码”

ChatGPT 本身当然可以理解代码、设计方案、Review 实现。

但它默认面对的工作对象更接近：

一个问题、一段对话、一项知识工作。

Codex 面对的则是：

一个真实的软件项目，以及需要发生在这个项目里的变化。

因此它需要一套更专门的软件工程 Harness：

Model + Repo Context + File / Git + Shell + Tools + Agent Loop + Permissions + Tests / Verification + Persistent Task State

Claude 和 Claude Code、Claude Design 的区别也可以从同一个角度理解。

重点不只是系统 Prompt 里分别写了“你是程序员”还是“你是设计师”。

更大的差别是：产品分别给模型提供了什么工作对象、工具、环境和反馈。

这也改变了我判断 AI 产品的方式

以前看到一个 AI 产品，我很容易先问：

它用的是什么模型？

现在我还是会看模型，但会继续问几个问题：

它能看到什么？

只能看到 Prompt，还是能够进入真实的工作上下文？

它能做什么？

只能给建议，还是能修改、运行和操作真实对象？

它能不能连续工作？

做一步就回来问人，还是能根据结果自己继续？

它怎么知道自己做对了？

靠语言上“看起来合理”，还是有测试、渲染、真实数据等反馈？

它的权限和工作环境是什么？

有没有足够的执行能力，同时又保留合理的安全边界？

这些问题，往往比只比较模型 benchmark，更接近一个 AI 产品实际能带来多少生产力。

最后的 Take away

模型仍然很重要。

它决定理解力、推理能力，以及一个产品能力的上限。

但最终体验还取决于模型之外的一整套东西：

Context、Tools、Runtime、Agent Loop、Permissions、Verification。

这些可以统称为 Harness 的一部分。

所以现在再看一个 AI 产品，我会把它拆成三层：

Model：它有多强的基础能力。Harness：这些能力怎样被组织起来完成工作。Product：最终怎样让用户使用这套能力。

只知道底层是什么模型，已经不足以判断一个 AI 产品到底能做什么。