巅峰对决：Opus4.6又赢了，GPT5.4还差点意思！

目前公认的编程界翘楚就是 Opus4.6 和 GPT5.4！

但是到底谁更强一些，众说纷纭！

无论内网外网，都有人觉得 GPT5.4 要比 Opus4.6 强，当然也有人觉得 Opus4.6 明显要比 GPT5.4 强！

如果只是隔空对战，其实很难分出胜负。

我们要有一个具体的场景，才能分胜负。我发现我最近测试的例子非常好，很能区分实力等级。

所以今天就来看一下 Opus4.6 和 GPT5.4 的开发实战情况。

下面先看基准，再看例子，然后对比，最后发表一下我自己感受！

按GPT一贯的表述风格：结论先行，GPT5.4能力还行，但是有点“自以为是”。

1、基准数据

为了让大家对这两个模型了解的更加透彻，以及对比基准和实战差异。

我先给大家整理一下基准数据：

整理这数据真是一个头两个大。

这两家也是牛逼，我发的基准你不发，你不发的基准我来发！

尤其是编程这一块，一个发 SWE-Bench Verified，另一个发 SWE-Bench Pro，还有一些是基准参数或者基准版本不同……

凑合看吧，我们还是实际效果为主。

2、测试场景

基准看完了，我们来看一下我的测试场景。

我的测试场景是，我正在开发一个 Coding Plan 的测试平台。

可以管理各种平台的 API。

可以一键批量测试不同的平台的速度、tokens 消耗、回答内容等。

可以进行单聊和群聊。

可以进行系统提示词和角色提示词的管理。

目前已经具备把不同平台的模型拉到同一个群里面的功能。

但是我希望更进一步。

我希望扩展角色功能，然后让角色进行群聊，而不是直接拉平台去群聊。这样自由度和可玩性就大大提高了。

然后我希望AI能帮我完成这次功能升级！

这次测试和从头开始不一样，当前已经有一定的上下文！

我统计了一下，源代码有 60 个文件，总共 6682 行。

src/
├── app/              # 页面和 API 路由
│   ├── api/          # 后端 API (chat, roles, platforms, upload, test...)
│   ├── chat/         # 群聊页面
│   ├── single-chat/  # 单聊页面
│   ├── platforms/    # 平台管理页面
│   ├── settings/     # 系统设置页面
│   ├── test/         # 批量测试页面
│   └── history/      # 测试历史页面
├── components/       # React 组件
│   ├── ui/           # 通用 UI 组件 (shadcn + 自定义)
│   ├── platforms/    # 平台相关组件
│   ├── layout/       # 布局组件
│   └── test/         # 测试相关组件
├── lib/
│   ├── types.ts      # 所有类型定义
│   ├── prompt-builder.ts  # 4 层提示词组合
│   ├── store/        # 数据 CRUD (JSON 文件读写)
│   └── api-clients/  # 统一 API 客户端
data/                 # 数据文件 (platforms.json, roles.json, chat-sessions/, ...)
public/avatars/       # 角色头像上传目录

除了有一定的代码方面的上下文之外，这次还涉及到数据结构和业务逻辑的修改。

同时涉及到多个功能页面的修改！

虽然这不是什么高精尖的系统，但是这次的修改，还是有一定的难度。

如果这个需求能被轻松搞定，那么证明这个模型，已经有一定的工程实战能力。

如果完美完成，没有遗漏，就证明有一定的“心智”。

目前做最好的是 Opus4.6，其次是 GLM5……

号称编程和智能体 SOTA 的 MiniMax 最拉跨，这个事情我要说很久，因为它吹了最厉害的牛逼。

今天虽然叫巅峰对决，其实主要是看 GPT5.4 表现，然后把 Opus4.6 拿过来对比一下！

3、测试结果

基于相同的 Base 代码，GPT5.4 的结果已经出来了。

我们还是用三个步骤来评判：能不能用，好不好用，全不全面？

能不能用

第一个问题是能不能用，这个很关键！

首先我可以明确的告诉大家，GPT5.4一次搞定的结果，是完全可以使用的。

系统设计中的角色功能已经升级，现在包含了头像，平台，模型内容。而且增删改查都没有任何问题。也对原始数据进行了升级，加载没有平台的数据，也不会出错。

好不好用

基本是好用的，但是有些细节需要提升。

你们看头像这个字段，它居然让我填写 URL，这是什么魔鬼体验~~。

而且我提示词里面明确说了，这个头像需要能上传，需要有预设，如果我都不选，那么应该有默认。

这一点需求实现的不是很好。

除此之外，基本体验还是不错的。

全不全面

我这个需求里其实有一个隐藏考点。

这个考点就是：能不能主动删除冗余功能。

冗余未必是坏事儿，但是在我这个系统里面，一旦角色功能升级之后。平台管理里面，就没必要，也不应该留角色设置的选项了。

平台只负责管理平台相关的内容，比如API接口，模型，协议等。

这个地方GPT5.4并没有考虑到，也没有询问我。

4、对话过程

这部分，我会分享一下，我是如何写提示词的，它又是如何回答的。

但是不会讲一行代码，因为我们用“自然语言”编程。

主要是考验模型对需求的理解能力和实现能力。

我的需求：

目前群聊接力的时候可以选择平台管理中的模型，也可以对这些模型预先配置系统提示词和角色提示词，这样已经可以通过系统提示词来个性化聊天了。但是通过平台配置里面绑定角色比较有局限性——这样一个平台就只能是一个角色。
​
我希望换另外一种设置：**角色里面选模型**，然后群聊开始的时候，我可以直接选平台，也可以直接选角色。角色的管理还是在系统设置的"角色管理"中进行。
​
为了实现上面的需求，角色功能需要升级：
​
- 除了可以设置提示词之外，还得能**选择平台和模型**
- 另外还能**设置头像**
- 如果设置了头像，群聊的时候就显示自定义头像；如果没有设置头像，就用对应模型平台的 logo 作为头像
​
我的需求大概是这样。说说你对这个需求的理解，不急着写代码

GPT5.4 的分析：

这会带来两个很重要的产品变化：
​
  - “平台”回到基础设施层，只负责连接能力和模型列表
  - “角色”变成业务层身份，同一个平台可以派生出多个不同角色，因为每个角色都能选自己的模型和提示词，
    不再受“一个平台只能绑一个角色”的限制
​
  关于头像，我理解你的规则是：
​
  - 角色配置了头像：群聊里显示角色头像
  - 角色没配置头像：回退显示其所绑定平台的 logo
  - 直接选平台参会时：还是显示平台 logo
​
  再往下落到聊天行为上，我的理解是：
​
  - 如果群聊里选的是“角色”，真正调用接口时仍然走它绑定的平台和模型
  - 但前端展示、会话身份、接力队列里的名字，应该优先按“角色名”显示，而不是平台名
  - 平台名更像底层来源信息，模型名仍可作为附加信息展示
​
  我还顺手确认了当前实现，现状也和你的判断一致：
​
  - src/lib/types.ts 里 Role 目前只有 name + content
  - src/lib/prompt-builder.ts 现在是把“平台默认角色”拼进系统提示词
  - src/app/chat/page.tsx 和 src/components/ui/chat-message.tsx 当前也都是以“平台”为参会主体
​
  如果继续往下做，我下一步会先把这个需求拆成一份实现方案，重点明确：
​
  - 数据结构怎么改
  - 群聊参与者到底用“平台项”和“角色项”怎样统一建模
  - 旧数据如何兼容迁移
​
  这轮结果我已经按仓库规则写入 docs/chatlogs.md。

这个环节 GPT5.4 分析的已经很全面了，而且它代码也看了，所以并不是单纯建议，而是结合了需求和现有代码给出了它的理解。

这一点是做的很好的。

并且做了下一步的规划。这一点也是对的。

但是它其实忘了一个很关键的问题：询问我的意见

如果是 Opus 系列的模型，就会找我确认关键需求了。

三、待确认的问题
​
​
1. 角色与平台的关系：一个角色绑定一个平台+一个模型，对吗？还是说一个角色可以绑定多个平台？（我理解应该是一对一：一个角色 = 一个人格 + 一个特定的平台/模型）
​
2. 群聊中混合选择：是否允许同一个群聊里既选了几个"裸平台"，又选了几个"角色"？比如群里有"角色A（用 GPT-4o）"+"角色B（用 Claude）"+"裸的 Gemini 平台"？
​
3. 同模型多角色：是否允许同一个模型被多个角色使用？比如"严谨学者"和"搞笑段子手"都绑定 GPT-4o，在同一个群聊里同时出现？
​
4. 头像格式：自定义头像是上传图片文件，还是选择预设图标/emoji，还是都支持？
​
5. 平台上原有的 defaultRoleId 字段：是否要废弃掉？既然角色不再绑定在平台上，平台配置表单里的"默认角色"选择器是不是可以移除了？
​

但是 GPT5.4 似乎没有这个想法，它完全没有要询问我的意思，而是直接说它准备干什么了

我下一步会先把这个需求拆成一份实现方案，重点明确：
​
- 数据结构怎么改
- 群聊参与者到底用“平台项”和“角色项”怎样统一建模
- 旧数据如何兼容迁移

注意，这些句子是没有问号的，是陈述，也就是它已经打定主意了要这么干。除非我直接阻止它！

它既然不问，我也就不提了，让他继续。（我提了，那就变成我的功劳了）

然后它做了一个开发方案。

方案做的挺好的–除了没考虑的问题之外，你永远不用怀疑GPT5.4做方案的能力。

做完方案，就直接开始写代码了。

整个过程吧，还算丝滑，先分析问题，再做执行方案，然后开始执行。

对小白来说，是不是非常好的体验？ 你就说两个继续就可以了。

但是……我要说，这个世界上的所有业务都包含了大量的逻辑分支。

所有的程序员在开发之前，都必须确认很多需求。

越是老程序员，越明白这个道理。

否则……结果……很严重。

GPT5.4不问就干，其实多少有点“自以为是”了，我们来看看结果吧！

结果就是测完之后可以发现好几个问题。

基本不是技术问题，而是业务逻辑问题。

第一个问题：平台和角色群聊。

因为它没有询问我，所以它不知道，我希望的是平台和角色一定要分清楚。

不应该把角色和平台混在一起聊天，他们是互斥的选项。选了平台，就不允许选角色，选了角色就不允许选平台。

万幸的是，它在实现过程中并没有 bug：

这个功能是可以用的，还是有点东西的。

但是我要再次强调，我绝对不允许我的程序员，这么处理业务逻辑的。

通过对比，你可以明显感觉到，GPT5.4 和 Opus4.6 的处理过程是完全不一样的。

侧面也可以印证 GLM、Kimi、MiniMax 全“借鉴”了 Opus4.6 的模式。

因为它们处理问题的过程几乎一模一样，只是具体的能力有差别而已。

GPT5.4 这次开发基本是成功的，代码方面没有明显的 bug。

但是相比 Opus4.6 有三个问题：

第一个，头像要有上传功能这一点执行没有做到位，体验没有做好。

第二个，角色和平台互斥，它没有做到。Opus4.6 一脉的全部询问并做到了。

第三个，平台管理里的冗余选项没有删除，处理不够全面。

那么为什么会导致这个问题呢？就是因为它“自以为是”，但凡它问一句，就不会是这个结果。

翻看 Opus4.6 的开发过程，可以发现上面的三个问题全部考虑到了，进行了询问确认，而且给了很详细的建议。

那么问题来了，为什么 Opus4.6 一拿到这个需求，他就能意识到必须要问这些问题呢？

这就是久经战场的老兵和新兵蛋子的最大差别。

当然，这只是一个例子而已，不能说明一切，仅供参考。

5、我的感受

GPT系列模型，整体实力肯定不弱的，绝对是一线水平。

我对 GPT 的整体感觉是下限比较高，大部分常规问题能 hold 住，比较稳。

让它帮你出方案也是一套一套的，考虑非常全面，甚至过度全面。

但是它那个网页版我是用的越来越少了。

很多人都感觉它“爹味”太重！

我也是同感！

ChatGPT 给人的感觉是，非常照顾你的感受，非常愿意指引你，关爱你。

刚开始使用感觉尚可，但是久而久之就会很难受。

换个角度看，其实它是把你当弱智和缺爱儿童一般对待😄！

这就是一种自以为是的傲慢，自以为所有人都需要它的帮助，自以为它全知全能，自以为所有人都爱看它长篇大论。

我在网页对话的时候，随便一个问题，它都洋洋洒洒一大片，生怕我不知道它多厉害，多专业。

还有它那套话术……

我不喜欢这样的人，我也不喜欢这种AI。

所以自从用了 Claude 之后，我就很少用 ChatGPT，只有在配额消耗完成之后，或者 tokens 消耗巨大的场景，才会用一下。

整体来说 GPT-Codex 系列会比网页版的GPT好一些！

在 Codex 中把模型换成 GPT5.4-Codex，然后调整到 High 再加上 Fast。

目前体验还可以：

它终于会在每次修改之前，用中文说清楚，它大概是在做什么了，这个界面清晰了很多。

过度设计、过度输出的问题也有改善很多！

另外 GPT 这一系列，还有一个优点，比较容易用上，不容易封号！

GPT能力还可以，配额又多，那么自然对很多人来说都是最优选择了。

但是的实际使用的感受是，在编程方面上限有限！

总的来说找毛病一流，干开发二流。

还是有点慢，不够犀利。

最后，我的原则是：有得选的话，选最终聪明最能干的。

我觉得这个“人”是 Opus4.6！

最后，我已经把CodingPlan的这个base版本发不到github上面了，大家有兴趣的可以在自己电脑上测试。

地址：

https://github.com/JarvisPMS/codingplan

另外关于Opus4.6和GPT5.4 的9个例子的对比可以看这里：

https://topai.tonyhub.xyz

收工收工！