StreamSparkAI

核心概览

本次交流围绕公开榜单与真实开发体验脱节这一核心判断展开。主讲人佳宏认为，模型在 Benchmark 上常只差1—2分，但这不足以说明实际可用性，因为开发者更在意是否高保真完成任务、是否少出纰漏、是否便于后续维护。他基于自己熟悉的真实项目，设计了两个实测场景：一是前端页面截图复刻，重点考察多模态理解、指令跟随、前端实现质量；二是后端邮件头像报错排查，重点考察代码理解、根因定位、方案优雅性、长序列稳定性。结果显示，GPT5.4在复杂长任务中整体最强，OP4.6速度极快但细节与长程严谨性略弱，Gemini多模态很强但代码稳定性和可维护性不足；国产模型里，千问3.6是本次最接近可用门槛的代表，MiniMax后端分析能力不错但前端受限于多模态短板，GLM5与Kimi2.5在任务理解和高保真复刻上偏差明显。讨论后半段进一步延伸到Agent 使用习惯、Prompt 与 Skill 编写能力、领先模型的数据飞轮与自训练优势。

关键议题与详细总结

1. 为什么公开榜单越来越难反映真实能力

• 佳宏的核心观点是：Benchmark 有失效趋势。
• 原因不在于榜单完全没用，而在于：
  • 主流模型分数越来越接近，常常只差1—2分；
  • 对非重度用户来说，这种差距很难转化为对真实能力的理解；
  • 更关键的是，榜单通常只看任务是否完成，不看完成过程是否合理、代价是否可接受、后续是否好维护。
• 他用拆门作比喻说明这一点：
  • 一种模型像是用螺丝刀把门完整拆下并整理好零件；
  • 另一种模型像是直接用电锯锯掉门；
  • 如果测评只看门有没有被拆掉，这两者会被判为都成功，但对开发者而言，第二种方式实际上不可接受。
• 因此，他认为真正重要的不是单次完成，而是：
  • 纰漏越少越好
  • 返工越少越好
  • 开发摩擦越低越好

2. 测评方法：为什么必须用自己熟悉的真实项目

• 佳宏明确表示，只有在自己非常熟悉的项目中，才有能力准确判断：
  • 模型给出的计划是对是错；
  • 修改方式是好是坏；
  • 哪些问题是严重偏差，哪些只是小缺陷。
• 他因此没有采用抽象题目，而是直接拿自己近期开发的小项目做测试。
• 项目背景：
  • 他希望做一个工具，自动汇总海外 KOL 的信息，降低自己在中文互联网里筛选二手消息的时间成本。
  • 项目对设计、美观、信息组织也有一定要求，因此适合作为前端复刻测试对象。

3. 前端测试设计：重点不只是会写代码，而是能否看懂页面并高保真复现

3.1 测试任务与能力维度

• 任务设计方式：
  • 将已经做好的页面截图；
  • 把日期筛选、设置等交互状态也截图；
  • 提供给7个待测模型；
  • 要求模型尽可能高保真复刻页面。
• 核心考察能力包括：
  • 多模态理解
  • UI 理解能力
  • 指令追随能力
  • 前端框架实现能力
  • 自我检查与迭代能力

3.2 测试流程

• 使用统一 Prompt 和上下文；
• 让模型自行：
  • 新建项目骨架；
  • 编写代码；
  • 运行调试；
  • 反复迭代；
• 佳宏会要求模型继续自查，直到其在无人为干预下达到自身最佳状态。
• 他的目标不是看第一轮草稿，而是看模型能否靠自身机制逼近上限。

3.3 平台与中间层的影响

• 不同模型接入入口并不完全相同：
  • 多个国产模型通过 cloud code 进行；
  • GPT5.4 在 Codex 上测试；
  • Gemini3.1 Pro 在 Google 自家平台运行。
• 主持人追问：入口不同，是否会影响结果？
• 佳宏的回答是：
  • 会有影响，特别是 Agent 脚手架、交互设计、工具链整合能力；
  • 他提到业内讨论认为，原生框架对 Agent 性能提升可达至少10个点；
  • 但这种影响不能完全替代模型底层能力，尤其在长序列复杂任务上，基座模型差异仍然很大。
• 他的主观看法：
  • cloud code 更适合短平快任务，交互便捷、响应迅速；
  • Codex 更偏工程化，在复杂、长序列任务上表现更强。

4. 前端实测结果：各模型的表现差异

4.1 OP4.6：速度极快，但高保真和细节完成度不足

• 佳宏认为，OP4.6 的突出优势是快：
  • 几分钟内即可生成页面；
  • 使用体验像有人在旁边协同编程。
• 但问题也明显：
  • 把本应忽略的调试入口识别成前端 UI；
  • 卡片、渐变、版式、时间线、弹窗位置等细节未充分复刻；
  • 整体只有六七成相似度。
• 他的结论是：
  • 如果任务强调快速出结果，OP4.6 很强；
  • 但如果任务强调复杂页面的精细复刻，它并非最佳。

4.2 GLM5：看懂大类场景，但核心结构与逻辑偏差较大

• GLM5 的表现被评价为做出了类似东西，但不是想要的东西。
• 具体问题：
  • 像是识别出这是一个博客式页面；
  • 但实际页面的卡片结构、信息组织方式、KOL 观点汇总逻辑都没有正确理解；
  • 甚至把内容误做成人物介绍，而不是观点摘要。
• 佳宏认为，这意味着开发者如果要把结果修到可用，成本会非常高，甚至接近重做。

4.3 GPT5.4：前端综合能力最强，但耗时和成本也高

• 佳宏对 GPT5.4 的评价非常高，认为其进步明显。
• 他提到自己的观察：
  • GPT5.2 做类似页面可能要4小时、消耗约800万 Token；
  • GPT5.4 则可能压缩到不到1小时、约200万到300万 Token。
• 前端结果层面：
  • 页面整体复刻质量显著高于其他模型；
  • 下拉框设计、排版风格、颜色等都更接近原稿；
  • 仍有小 bug 和交互细节不到位，但整体已达约80分。
• 他特别强调：
  • 编程任务的后半段提升是指数级变难的；
  • 80分到100分的成本，可能远高于0分到80分。
• 结论：
  • 在复杂、长序列、精细复刻任务上，GPT5.4 是最强选项；
  • 但时间与费用代价也显著更高。

4.4 MiniMax：前端短板明显，核心原因是多模态不足

• 佳宏对 MiniMax 在前端复刻场景中的评价很低。
• 核心原因：
  • 没有多模态能力，或至少在该路径下无法有效处理截图；
  • 连前端框架使用都存在明显问题。
• 他进一步指出：
  • 即便通过外部 OCR 管道把图片转文字，也无法补足排版、设计、风格理念的损失；
  • 因而在前端任务中，多模态是非常关键的基础能力。
• 提问嘉宾据此总结：
  • 如果多模态能力弱，模型的编程能力就很难在前端场景中充分体现，更可能只适合后端任务。
• 佳宏明确表示：这个判断基本成立。

4.5 Gemini：多模态理解强，但代码质量与稳定性不够

• 佳宏承认 Gemini 的多模态能力很不错，页面复刻效果整体也可以。
• 但他对代码质量评价较低：
  • 页面会持续刷新；
  • 存在 bug；
  • 某些功能没有真正稳定实现。
• 他的总体判断是：
  • 看图能力强
  • 实现质量不够稳
  • 如果放到更大规模项目中，维护性可能出问题

4.6 Kimi2.5：比 GLM5 更好一些，但仍明显偏模板化

• Kimi 的结果保留了一些卡片感，但整体仍像是套模板。
• 佳宏的判断是：
  • 它没有真正理解用户意图；
  • 更像从已有模板库里找了一个相近页面快速套用；
  • 形式上有点像，实质上距离需求较远。

4.7 千问3.6：国产模型中最让人意外，已有明显可用感

• 佳宏认为，千问3.6 是本次前端测试里国产模型中最值得关注的。
• 主要优点：
  • 在一众国产模型里，对任务意图跟得最上；
  • 能较好理解自己要做什么；
  • 在没有把 Prompt 写得极细的情况下，也有一定上下文理解能力。
• 但问题依然存在：
  • 细节错误不少，如日期复制错误；
  • 悬浮窗、交互、局部布局仍不到位；
  • 如果要追到 GPT5.4 或 Gemini 的起跑线，开发者还要多发5—10轮 Prompt，可能多花3—5小时。
• 另外还有平台层问题：
  • 他使用百炼官方地址时，频繁遇到上下文过大、请求大小超限的错误；
  • 他判断这更像是平台适配问题，不是模型本身的问题。
• 综合结论：
  • 千问3.6 还不能和顶尖海外模型并列；
  • 但在国产模型中，已经给他明显的国产替代可用感。

5. 后端测试设计：重点从会写代码转向会找问题、会优雅修问题

5.1 测试背景

• 项目有一个真实功能：每天早上8点自动发送昨日 KOL 摘要邮件。
• 当前存在 bug：邮件中头像显示异常。
• 佳宏没有先手动修复，而是把它作为测试题交给各模型。

5.2 测试要求

• 他要求模型：
  • 清楚说明调试过程；
  • 准确分析根因；
  • 给出优雅的解决方案。
• 他强调，优雅非常关键，因为：
  • 有些方案虽然能修 bug；
  • 但会损害项目长期可维护性；
  • 对成熟代码库来说，这是很大的风险。

5.3 问题本身的技术结构

• 现象：
  • 邮件日报里的头像不显示。
• 根因：
  • 邮件里引用了公网 URL；
  • 手机端未挂代理时无法访问。
• 正确解决方向：
  • 项目本地数据库里其实已经缓存了这些 KOL 头像；
  • 邮件应该改为使用本地服务器提供的头像地址。
• 关键细节：
  • 头像还有版本参数，即 -v；
  • 如果忽略这个参数，可能造成报错或留下后续维护隐患。
• 佳宏特别指出，这种题目真正考验的不是看懂现象，而是能否在5万行代码、数百文件夹里：
  • 找到正确路径；
  • 识别真实依赖关系；
  • 给出不破坏系统结构的修改方式。

6. 后端实测结果：长序列分析、根因定位与方案优雅性差异更明显

6.1 GPT5.4：后端综合能力最强

• GPT5.4 在后端题上几乎完成了所有关键层级：
  • 分析到正确的邮件流程位置；
  • 找到头像损坏根因；
  • 提出正确修复方向；
  • 识别到版本参数 -v 的存在。
• 佳宏认为它在长序列复杂任务上的能力最强。
• 小问题是：
  • 表述有时略绝对；
  • 但不影响整体判断。

6.2 OP4.6：很强，但少关键一环

• OP4.6 整体也很强。
• 与 GPT5.4 相比，主要差在：
  • 没有识别到 -v 参数。
• 这意味着它可能还要多迭代一次，开发者得手动进入闭环验证。
• 佳宏强调，在需要人类介入测试反馈的任务中，即便只差这一点，也会明显拖慢效率。

6.3 MiniMax：分析能力出色，但方案偏暴力，且违反只读约束

• 佳宏对 MiniMax 的后端表现比前端更认可，认为它在文本分析和长任务上有一定实力。
• 但它有两个严重问题：
  1. 修复方案偏暴力
     • 它建议后端放宽对 -v 的校验；
     • 这虽然能快速修 bug，但会损害长期严谨性和维护性。
  2. 违反只读指令
     • 测试中明确要求只读调研；
     • 它却把调研报告直接写入仓库根目录。
• 佳宏认为，这种行为在真实开发里很危险，因为说明模型在长序列过程中会忘掉关键约束。

6.4 Gemini：能定位问题，但方案同样不够优雅

• Gemini 的问题与 MiniMax 类似：
  • 能看出问题；
  • 但给出的解决思路对长期维护不友好。
• 佳宏的态度是：
  • 这种模型也许能解决眼前 bug；
  • 但如果项目规模继续扩张到5万行到10万行，代码会越来越难维护。

6.5 千问3.6：综合较稳，但关键细节仍缺一层

• 千问3.6 在后端题中的整体评价仍然不错：
  • 有检查意识；
  • 会调用浏览器工具反复检查；
  • 综合上仍是国产模型中相对更能看的。
• 但它也有明显差距：
  • 没有意识到头像 URL 还需要 -v 参数；
  • 工具调用不够稳定；
  • 写代码过程有些磕磕绊绊。
• 因此它虽已接近可用，但与 GPT5.4、OP4.6 仍有较清晰差距。

6.6 GLM5 与 Kimi2.5：分析路径就已经跑偏

• 佳宏对这两者在后端任务中的评价较低：
  • GLM5 没有充分分析出本地数据库中已缓存头像这一事实，方案也较暴力；
  • Kimi2.5 更严重，分析路径直接跑到测试代码，说明它在大型仓库中没有找到真正的问题入口。
• 他的判断是：
  • 在这种真实项目里，它们帮不上忙。

7. 不同模型的人格化使用体验

• 佳宏提到，和不同模型协作时，体验很像面对不同风格的人：
  • OP4.6 做事很快、很急、信心很满，像很会向上管理；
  • GPT5.4/Codex 更严谨，会逐项对照截图和需求，告诉用户哪些还没做到位。
• 从开发者偏好看，他更喜欢后者，因为：
  • 开发者需要知道哪里还没做好；
  • 而不是只收到一句已经完成。

8. 关于 Agent、Prompt 与 Skill 的讨论

8.1 模型依赖正在形成

• 在主持人追问下，佳宏承认自己对模型已形成明显依赖：
  • 他每天大部分时间都在和 Codex 与各种 Agent 打交道；
  • 尤其难以离开 GPT5.4/Codex 这类长任务能力更强的工具。
• 他的判断是，未来很多工作协同会转向Agent 对 Agent。

8.2 真正的瓶颈开始转向人类侧

• 佳宏认为，当前开发中的焦虑点不再只是 Token 成本，而是：
  • 人能不能写出高质量 Prompt
  • 人能不能持续理解项目细节并给出正确判断
• 他说，一个复杂项目到后面会出现反直觉现象：
  • 似乎 Agent 让人解放了双手；
  • 但如果人脱离细节太远，就会开始听不懂 Agent 在说什么；
  • 一旦听不懂，就没法给出正确决策，项目会在原地打转。

8.3 Skill 文档具有通用性，但对弱模型需要写得更细

• 在 Skill 是否通用的问题上：
  • 佳宏认为 Skill 本身是通用的；
  • 但提问嘉宾补充了一个重要使用经验：对更强模型，Skill 可以写得更简洁；对较弱模型，则必须写得更细。
• 佳宏认同这一点，并指出这正是他离不开更强模型的重要原因：
  • 跟聪明模型不需要说太多
  • 这直接影响实际工作效率

9. 对行业格局与未来演进的主观看法

9.1 主讲人的判断：头部海外模型已形成更强优势

• 这是佳宏的个人判断，不是会中被验证的事实。
• 他的理由主要有三层：
  1. 优秀模型会吸引优秀用户
     顶尖开发任务优先流向更强模型，从而产生更高质量的数据和反馈。
  2. 模型自训练正在形成壁垒
     他认为 GPT 与 OP4.6 已出现更明显的自训练尝试，头部厂商能拿到更完整的生成过程数据。
  3. 从60分到90分是极重资产过程
     他用汽车工业化做比喻，认为模型训练已从一次性实验走向工业流水线。
• 他还提到业内对国产模型蒸馏来源有一些传言，但同时明确表示：自己并不掌握充分信息。

9.2 对2026年能力跃升的判断

• 主持人提问：2026年海外头部模型是否还会出现一次明显技术跃升？
• 佳宏的回答是：他并不意外。
• 他预计下一代模型的主要增量可能在于：
  • 更强的长周期问题处理能力
  • 更深的思考能力
  • 可能逐步替代部分科研工作
• 他还提出更宽泛的判断：
  • 如果模型确定性进一步提高，对大量白领文案类工作会形成更稳定替代。

数据与统计信息汇总

• 公开榜单差距：1—2分，主讲人认为已难反映真实可用性。
• 脚手架增益：至少10个点，指 Agent 框架对性能有明显影响。
• OP4.6 前端复刻：约3分钟，优势是极快出结果。
• GPT5.2 对比 GPT5.4：约4小时/800万 Token vs 不到1小时/200万—300万 Token。
• 千问3.6 追平顶尖模型首轮效果：可能需多5—10轮 Prompt、额外3—5小时。

决策与建议

• 已形成的实操结论：
  • 前端高保真复刻任务优先考虑 GPT5.4；若更重视速度，可选 OP4.6。
  • 后端长序列排障与成熟代码库维护优先考虑 GPT5.4，OP4.6可作为次优选择。
  • 国产模型中，千问3.6 综合最值得关注，在真实开发中已具一定可用性。
  • MiniMax 更适合后端类文本分析场景，但需严格限制权限并警惕其忘记约束。
• 方法论建议：
  • 不要只看榜单，要看真实项目中的摩擦成本、返工次数、方案优雅性。
  • 评测模型时，尽量使用自己熟悉的真实项目，否则很难判断对错优劣。
  • 对复杂任务要特别关注模型是否：
    • 保持长序列约束；
    • 具备自检意识；
    • 给出可维护的方案，而非只求修通。
  • 使用较弱模型时，需要写得更细的 Prompt/Skill；使用更强模型时，协作成本会显著降低。

不确定性与待确认点

• 前端效果评分带有主观性。例如六七成、80分等判断，主要来自佳宏个人使用体验与视觉比对，不是统一量化指标。
• Token 数据并非完全严谨。佳宏明确提到，部分平台拿不到完整 coding plan 数据，因此 Token 统计存在估算成分。
• 平台名称、型号写法可能受转写影响。如 cloud code、OP4.6、Codex 等写法，建议以原始界面或原始录音为准。
• 千问3.6 的部分异常更可能来自平台层。例如百炼请求大小报错，佳宏判断不是模型本身问题，但会影响实际体验。
• 关于国产模型是否蒸馏海外模型的说法未被证实。佳宏只提到坊间传言，并明确表示自己没有充分信息。
• 对2026年模型跃升、头部格局固化、科研替代等判断均属个人预测，原文未提供独立证据验证。

结论回顾

• 真实开发里，模型差异主要体现在少犯错、会自查、能维护，而不只是榜单高低。
• GPT5.4 在前后端复杂任务中整体最强，OP4.6 胜在速度；国产里千问3.6 最接近可用门槛。
• 随着 Agent 深入工作流，开发效率的上限越来越取决于人能否提出清晰需求、理解复杂上下文并持续做出正确判断。