1. 这不是跑分报告，是我在真实编码场景里踩出来的坑
我从 GPT-3.5 时代就开始把 AI 当成日常开发搭档——写脚手架、补单元测试、重构老旧逻辑、甚至帮实习生 debug。不是为了偷懒，而是想搞清楚：当它说“已理解需求”，到底理解到了哪一层？当它生成一段能跑的代码，这段代码在真实项目里能活过三天吗？最近半年，我明显感觉到一种微妙的“倦怠感”：GPT-5.1 的回复开始出现模板化收尾，Gemini 的思考链越来越长但关键判断点反而模糊，Claude 在复杂状态机建模时会悄悄绕开边界条件……这不是模型退步，而是能力边界在高速扩张中变得愈发崎岖。更现实的问题是：你手头有个紧急的前端需求要赶在下午三点前上线，或者一道周赛 Hard 题卡在超时上动弹不得，这时候打开哪个网页版模型，输入 prompt 后最可能给你一个“能直接粘贴进项目、改两行就能用”的结果？本文不谈参数量、不列 MMLU 分数、不对比训练数据规模，只聚焦两个最硬核也最日常的战场：前端交互实现和算法工程落地。所有测试均基于当前公开可访问的网页端版本（无 API 调用权限），所有代码均在我本地 Chrome 128 环境下实测运行，所有 bug 都是我亲手点击、输入、等待、报错后截图记录下来的。省流建议：直接跳到 Part 4 的总分表，但如果你正被某个模型的“渐变色没生效”或“主席树死活不肯用”折磨得睡不着，那接下来这五千字，就是我替你试错换来的操作手册。
2. 前端能力横评：一个番茄钟，照出九个模型的“工程直觉”
2.1 测试设计逻辑：为什么是“单 HTML 文件的番茄钟”？
很多人觉得前端测试该用 React/Vue 组件，但恰恰相反——单 HTML 文件才是对模型工程直觉最残酷的考场。它强制模型面对三个真实世界约束：第一，没有框架帮你兜底 DOM 操作和事件绑定，document.getElementById('startBtn').addEventListener('click', ...)这种基础操作必须手写且零容错；第二，所有样式、逻辑、资源（如提示音）必须内联或 Base64 内嵌，不能依赖外部 CDN 或构建工具；第三，“极简风格”“背景渐变”“自定义倒计时”这些模糊需求，考验的是模型对 CSS 渲染机制、JavaScript 定时器精度、Web Audio API 兼容性的隐性知识储备。我刻意避开了“用 React 实现 TodoList”这类高语义化题目，因为那更像是在考 prompt 工程能力而非模型本身。而番茄钟这个看似简单的任务，会像 X 光一样照出模型在 DOM 生命周期管理、用户交互反馈、视觉动效实现上的真实水位。比如，当用户输入 “abc” 作为分钟数时，是该弹窗警告、静默忽略、还是自动 fallback 到默认值？不同模型的选择，暴露的是它们对“前端防御性编程”这一工程常识的理解深度。
2.2 核心评分维度拆解：主观不等于随意
可用性（10分）：表面看是“点开始按钮能否倒计时”，实则暗含三重校验。第一重是 DOM 绑定是否成功——很多模型生成的代码里getElementById查找的 ID 和 HTML 中实际 ID 不一致，这种低级错误在真实项目里每天都在发生；第二重是定时器逻辑是否健壮——setInterval是否被正确清除，避免内存泄漏；第三重是浏览器兼容性意识——比如 Web Audio API 在 Safari 上需要用户手势触发，模型若直接new Audio().play()就会在 iOS 设备上静音。我测试时特意用了 Chrome、Firefox、Safari 三端验证，凡是在任一主流浏览器失效即扣分。
完整性（10分）：这里的关键陷阱在于“番茄钟基本功能”的定义。行业共识包含：启动、暂停、重置、时间显示、结束提示。但模型常犯的错误是“功能幻觉”——比如 Gemini 生成的代码里有<button id="pauseBtn">暂停</button>，但 JS 里根本没写对应的事件监听器，按钮纯属摆设。更隐蔽的是状态管理缺失：DeepSeek 生成的代码在倒计时归零后再次点击“开始”，会进入负数倒计时并卡死，这暴露了它对 JavaScript 闭包作用域和状态重置逻辑的严重误判。
审美（10分）：这不是让你做 UI 设计师，而是考察“技术决策的审美意识”。比如，要求“极简风格”，GPT-5.1 生成的纯白背景+黑字+居中框体，虽然安全但缺乏呼吸感；而 Claude 用 CSS Grid 布局配合 subtle 的阴影和圆角，既满足极简又提升可读性。真正的审美分，给那些用transition: background-color 1s ease实现平滑渐变，而不是用setTimeout每 100ms 硬切一次颜色的模型——后者在视觉上会产生明显的“卡顿感”，这是前端工程师一眼就能识别的劣质实现。
Bug（10分）：我采用“可复现性”作为唯一标准。只要在标准操作流程（输入合法数字→点击开始→等待倒计时→点击暂停/重置）中，出现一次 JS 报错、DOM 渲染异常、或功能逻辑断裂，即扣 5 分。DeepSeek 的“输入 1 分钟变成 251 分钟”问题，根源在于它把用户输入的字符串"1"和预设的"25"字符串做了错误拼接（"1" + "25"→"125"），这暴露了它对 JavaScript 类型转换规则的系统性误解，比单纯的功能缺失更危险。
渐变理解（10分）：这是区分“调用 API”和“理解原理”的试金石。提示词明确要求“背景随时间流逝渐变颜色”，但 Grok 和豆包都只实现了离散的颜色切换（如 0-25% 蓝、25-50% 绿、50-75% 黄、75-100% 红）。真正的平滑渐变需要将时间进度映射为 HSL 色彩空间的 Hue 值，并用 CSS transition 或 requestAnimationFrame 平滑插值。Claude 和 Gemini 做到了，而 GPT-5.1 虽然用了transition，但起始/结束色值选择不当，导致渐变过程出现突兀的灰阶断层——这说明它懂语法，但不懂色彩心理学。
2.3 九个模型实战表现深度复盘
ChatGPT-5.1Thinking 的代码结构清晰，JS 逻辑分层合理（Timer 类封装、UI 控制器分离），但致命伤在交互设计：它完全忽略了“暂停”和“重置”这两个核心按钮的 DOM 绑定。我反复检查了它生成的 HTML，<button id="pauseBtn">和<button id="resetBtn">标签确实存在，但 JS 里只有document.getElementById('startBtn').addEventListener(...)这一行绑定。这不像疏忽，更像模型在“执行指令”和“理解用户意图”之间出现了断层——它记住了“写一个番茄钟”，却忘了番茄钟的本质是“可交互的计时器”。它的合法性校验很扎实（isNaN(parseInt(input))），但审美上用了过于生硬的box-shadow，在深色模式下文字几乎不可读。
Gemini-3.0pro 的视觉呈现最接近专业设计师手稿：Flexbox 布局精准，字体层级分明，倒计时数字用了font-variant-numeric: tabular-nums确保等宽对齐。但那个“点击‘设置时长’文字才能激活输入框”的 bug，根源在于它把<label>的for属性指向了一个不存在的id，导致label点击无法聚焦 input。这暴露了它对 HTML 表单可访问性（a11y）规范的陌生——在真实项目里，这种 bug 会导致屏幕阅读器用户完全无法操作。它的渐变用了linear-gradient，但角度固定为 135deg，导致颜色过渡方向与时间流逝方向不匹配，视觉上缺乏“流动感”。
Grok-4.1Thinking 的最大问题是“需求翻译失真”。Prompt 明确要求“渐变”，它却理解为“在几个固定时间点切换颜色”。我尝试追加提示：“请用 HSL 色彩空间，将时间进度 0%→100% 映射为 Hue 0°→360°”，它依然返回离散切换代码。这说明它的指令遵循能力存在结构性缺陷：当需求涉及跨领域知识（前端+色彩理论）时，它倾向于退回自己最熟悉的“if-else 分支”舒适区。它的输入校验是空的，非法输入直接导致NaN传入setInterval，浏览器控制台报错后整个计时器瘫痪。
Claude-Opus4.5 Thinking 的艺术字和预设时间选项（25/5/15 分钟）展现了惊人的产品思维，但它的“合法性校验”是个反面教材：当输入"abc"时，它没有报错，而是把parseInt("abc")的结果NaN直接传给Math.max(1, NaN)，最终 fallback 到1分钟。这违反了前端最基本的“失败快速”原则——用户输入错误时，系统应立即给出明确反馈，而不是静默降级。它的渐变实现最优雅，用hsl(${hue}, 80%, 60%)动态计算 Hue 值，并通过requestAnimationFrame确保 60fps 平滑过渡，连 Safari 的 WebKit 渲染引擎都做了兼容处理。
DeepSeek 的代码让我花了整整 47 分钟才定位到核心 bug。它生成的 JS 里有一个timerId变量，但在startTimer函数中，它错误地写了clearInterval(timerId)而不是clearInterval(this.timerId)，导致每次点击“开始”都创建新定时器，旧定时器却未被清除。更糟的是，它的resetTimer函数里有一行this.timeLeft = this.duration * 60，但this.duration是从 input 读取的字符串，未做parseInt转换，所以"1"分钟变成了"1" * 60 = 60秒，而"2"分钟变成了"2" * 60 = 120秒——等等，这和我看到的“1 分钟变 251 分钟”不符？继续深挖发现，它在updateDisplay函数里把this.timeLeft和预设的"25"字符串做了拼接！这才是真相：模型混淆了数值运算和字符串拼接的优先级。这种 bug 在真实项目里足以让初级工程师通宵。
豆包的代码是本次测试中“工程完成度”最高的：它实现了键盘快捷键（空格暂停、R 重置）、倒计时归零时自动播放提示音、甚至考虑了移动端 touch 事件。但它的渐变用了background: rgb(0, 0, 0)到rgb(255, 255, 255)的线性过渡，在 0%-100% 进度时，中间 50% 区间全是令人不适的灰色，违背了“极简但不丑陋”的要求。它的 bug 修复能力很强，当我把 DeepSeek 的错误代码发给它，它立刻指出timerId作用域问题，并给出let timerId;的全局声明方案——虽然这不是最优解（破坏了封装性），但胜在简单可靠。
千问（Qwen3-Max-Thinking-Previex）的代码结构最“教科书式”：ES6 Class 封装、JSDoc 注释完整、错误处理用 try-catch 包裹。但它在渐变实现上犯了和 Grok 同样的错误，且拒绝接受我的修正提示：“请用 HSL 色彩空间”。它的算法题表现也印证了这一点：当题目明确要求主席树（Persistent Segment Tree）时，它坚持用暴力的二维数组模拟，即使我强调“时间复杂度必须低于 O(n²)”。这说明它的知识图谱存在明显的“技术栈盲区”——对高级数据结构的掌握停留在概念层面，缺乏工程化落地经验。
文心5.0Preview 的响应速度慢得惊人，平均生成时间 18 分钟，期间两次因超时中断。但它的代码质量意外地高：CSS 使用了@layer进行样式隔离，JS 里用AbortController处理定时器取消，连 Web Audio 的context.resume()兼容性都做了处理。它的 bug 来自过度设计：当输入非法值时，它试图用正则/\d+/g提取数字，结果"1abc2"被解析为12分钟，导致逻辑彻底混乱。这提醒我们：在 AI 编码中，“聪明的错误”比“愚蠢的错误”更难调试。
智谱 glm4.6 的代码注释最详细，每个函数都有输入输出说明，但它的渐变实现是硬编码的 5 个 CSS 类，通过classList.toggle切换——这在现代前端开发中属于已被淘汰的“jQuery 时代”做法。它的算法题表现同样保守，始终回避主席树，最终用std::map模拟动态开点，时间复杂度卡在 O(n log n)，但空间占用爆炸式增长。这反映出一个深层问题：模型在面对“需要跳出舒适区”的技术决策时，会本能地选择熟悉但低效的路径。
2.4 前端横评核心结论：工程直觉比语法正确更重要
提示：前端能力的天花板，往往不是“会不会写”，而是“知不知道为什么要这样写”。
这次测试最颠覆认知的发现是：语法正确性与工程可用性之间存在巨大鸿沟。所有模型生成的代码都能通过 ESLint 基础校验，90% 的代码能在 Chrome 里跑起来，但只有 3 个模型（Gemini、Claude、豆包）的代码能直接放进我的个人项目仓库，无需修改即可交付。GPT-5.1 的代码需要重写交互逻辑，DeepSeek 的代码需要重构整个状态管理，Groks 的代码需要重写渐变引擎——这些工作量，远超一个资深前端工程师手动编写的时间。真正拉开差距的，是那些看不见的“工程直觉”：对浏览器渲染管线的理解、对用户操作路径的预判、对错误边界的敬畏。比如，当用户疯狂点击“开始”按钮时，模型是否意识到需要防抖？当页面被切换到后台标签页时，setInterval是否会失准？这些细节，才是区分“玩具代码”和“生产代码”的分水岭。我在实际工作中发现，一个模型如果能在 prompt 里主动询问“是否需要支持 PWA 离线缓存？”或“是否需要适配深色模式？”，那它大概率已经具备了初级前端工程师的工程素养。
3. 算法能力横评：LeetCode Hard 题，测出模型的“数学建模肌肉”
3.1 选题深意：为什么是 LeetCode 第 478 场周赛第 4 题？
这道题名为《查询数组中最大异或值》，表面是经典 Trie 树应用，实则暗藏三重陷阱：第一重是数据规模，n=10⁵，q=10⁴，暴力 O(n*q) 必超时；第二重是异或性质，需要将查询转化为“在区间 [l,r] 内找与 x 异或最大的数”，这天然指向主席树（可持久化线段树）或离线莫队；第三重是边界条件，当 l=r 时需特判，当 x=0 时需保证返回原数组值。我刻意避开高频题库里的“两数之和”“反转链表”，因为那些题目的解法早已被模型嚼烂，生成的代码只是语料库的回声。而周赛新题，尤其是 Hard 难度，能逼出模型真实的“现场建模能力”——它是否能在没有先验答案的情况下，从零推导出最优解法？是否能识别出题目与主席树的映射关系？是否能在超时提示后，精准定位到瓶颈是“单次查询 O(n) 还是 O(log n)”？这才是算法工程师的核心竞争力。
3.2 评分标准背后的工程逻辑
最优测试用例通过数（10分）：这不是简单的“AC 数量”，而是考察模型对“测试用例设计意图”的理解。LeetCode 的测试用例从来不是随机生成的，而是精心构造的边界组合：大数据量（检验时间复杂度）、极端值（检验整数溢出）、特殊模式（检验算法鲁棒性）。比如，当模型通过 1071/1118 个用例时，我专门提取了那 47 个失败用例，发现它们全集中在“l=1, r=n, x=0”这一组——这说明模型的特判逻辑只覆盖了部分边界，暴露了其数学归纳能力的短板。
最优时空复杂度（10分）：这里的关键是“最优解法”的判定。本题理论最优是 O((n+q) log n) 时间 + O(n log n) 空间，使用主席树。但 Gemini 给出的 O(n log n) 解法实际是离线排序+双指针，空间复杂度 O(n)，这在工程上更优（避免主席树的内存开销）。我给它满分，因为模型选择了“工程权衡”而非“理论完美”——在真实系统中，内存带宽往往比 CPU 时间更稀缺。而 Grok 的 O(n log n + (n+m)√n log n) 解法，虽然理论复杂度更高，但它用分块思想规避了主席树的实现难度，对中级工程师更友好，我也给了 10 分。
稳定性（10分）：这是最容易被忽视的维度。在真实开发中，你不会只提交一次代码，而是经历“写→测→改→再测”的循环。Gemini 两次首轮都 AC，说明它的初始建模非常稳定；而 ChatGPT-5.1 在第二次尝试时，把原本正确的 Trie 树逻辑改成了错误的贪心策略，导致通过用例数从 1071 降到 982。这种“越改越错”的现象，在团队协作中叫“回归缺陷”，是模型不可靠性的致命信号。
优化效果（10分）：我设置了严格的五轮优化挑战，每轮只给一句提示：“你的代码超出时间限制，请优化时间复杂度”。Gemini 每轮都精准定位到瓶颈：第一轮用排序优化，第二轮引入双指针，第三轮用前缀和剪枝……而 DeepSeek 在第三轮突然引入std::unordered_map导致哈希冲突，第四轮又删掉 map 改用 vector，第五轮干脆放弃优化开始重写——这暴露了它缺乏系统的性能分析框架，优化行为像无头苍蝇。
3.3 九个模型算法实战深度剖析
ChatGPT-5.1Thinking 的初始解法是暴力遍历，这不意外。但它的“优化失败”极具启发性：当我提示“请用 Trie 树优化”，它真的构建了一个 Trie，但把查询逻辑写成了for (int i = 0; i < 32; i++) { if (node->child[bit] == nullptr) break; }——这只能找到“存在”的数，而非“异或最大”的数！它混淆了“前缀匹配”和“贪心选择”。更讽刺的是，它在后续优化中，把原本正确的暴力解法改错了，把maxXor = max(maxXor, a[i] ^ x)写成了maxXor = a[i] ^ x，导致只保留最后一次计算结果。这说明它的代码生成是“片段拼接”而非“逻辑推演”。
Gemini-3.0pro 的解法堪称教科书：第一轮就用离线排序+双指针 AC，时间复杂度 O(n log n + q log q)，空间 O(n)。当我提示“请进一步优化到 O((n+q) log n)”，它没有盲目追求理论最优，而是分析道：“当前瓶颈在排序，若用主席树可避免全局排序，但会增加内存开销。考虑到题目约束，当前解法已足够高效。”——它给出了工程决策的完整推理链。它的代码注释里甚至标注了“此解法在 n<10⁶ 时比主席树更快”，这种对真实硬件性能的感知，远超多数人类工程师。
Grok-4.1Thinking 的解法走的是“分块暴力”路线：把数组分成 √n 块，每块预处理最大异或值。这思路本身很巧妙，但它的实现有硬伤：块大小计算用了sqrt(n)而非ceil(sqrt(n))，导致最后一块越界访问。更严重的是，它在优化过程中，把原本 O(√n) 的块内查询，错误地优化成 O(n) 的线性扫描，导致耗时不降反升。这反映出它对“优化目标”的认知模糊——优化是为了降低复杂度，不是为了改代码。
Claude-Opus4.5 Thinking 的初始解法是主席树，但实现有重大缺陷：它把主席树的build函数写成了递归，深度超过 1000 时栈溢出。当我提示“请优化空间复杂度”，它立刻重写为迭代版，并加入内存池管理。最惊艳的是它的调试能力：当我提供一个超时用例，它能精确指出“瓶颈在query函数的 while 循环，当前每次查询需 32 步，可优化为 bit-level 并行”。它甚至给出了 SIMD 指令伪代码——虽然 C++ 标准库不支持，但这种底层洞察力令人震撼。
DeepSeek 的主席树实现语法正确，但存在致命的逻辑错误：在query函数中，它用if (r - l > 0)判断左右子树，但r和l是节点索引而非区间端点，导致永远走左子树。这个 bug 在 10⁵ 数据量下必然超时，但它自己无法发现。当我指出“查询总是返回最小值”，它回答：“可能是数据范围问题，建议扩大测试用例”——它在逃避问题，而非分析代码。这暴露了它缺乏基本的调试心智模型。
豆包的解法最“务实”：它没有碰主席树，而是用std::set维护有序数组，每次查询用lower_bound找最接近的数。时间复杂度 O(q log n)，虽非最优但绝对稳定。它的失败用例全集中在“x=0”时返回 0 而非原数组值，这是典型的边界条件遗漏。但它的修复极其迅速：当我指出问题，它立刻添加if (x == 0) return *max_element(a.begin()+l, a.begin()+r+1);——这种“小步快跑、快速验证”的工程哲学，正是优秀程序员的特质。
千问（Qwen3-Max-Thinking-Previex）的困境在于“知识幻觉”。它坚称“主席树在此题不适用”，并列举了三条理由，其中两条是错误的（如“主席树无法处理动态插入”——本题是静态数组）。当我提供官方题解链接，它承认错误，但转而用std::priority_queue实现了一个 O(q n log n) 的解法，依然超时。这说明它的知识库存在系统性偏差：对高级数据结构的理解停留在二手资料层面，缺乏亲手实现的经验。
文心5.0Preview 的解法最“学术”：它用数学归纳法证明了主席树的正确性，代码实现严谨，连constexpr和noexcept都标注完整。但它的致命伤是响应时间——每轮优化平均耗时 17 分钟，期间三次因超时中断。在真实开发中，这种“正确但不可用”的方案毫无价值。它的代码里有一行注释：“此实现经 Coq 形式化验证”，这很酷，但我的 CI/CD 流水线可等不了 17 分钟。
智谱 glm4.6 的解法暴露了“框架依赖症”：它试图用 PyTorch 的torch.sort模拟排序，但 C++ 里根本没有这个 API。当我指出错误，它改用std::sort，但把比较函数写成了return a > b（降序），导致后续所有逻辑颠倒。这种对语言生态的陌生，说明它的训练数据可能过度偏向 Python 生态。
3.4 算法横评核心结论：建模能力决定上限，调试能力决定下限
注意：算法能力的分水岭，不在“能不能写出主席树”，而在“知不知道什么时候不该用主席树”。
本次算法测试最深刻的体会是：最优解法不等于最实用解法。Gemini 的离线排序解法，理论复杂度略逊于主席树，但代码量少 60%，调试难度低 80%，在真实项目中部署风险几乎为零。而 Claude 的主席树实现，虽然理论完美，但一个栈溢出 bug 就能让整个服务雪崩。真正优秀的算法工程师，懂得在“理论最优”和“工程可行”之间做动态权衡。我观察到，所有能稳定产出高质量解法的模型（Gemini、Claude、豆包），都具备一个共同特质：它们会主动追问需求细节。比如 Gemini 会问：“查询是否在线进行？是否允许离线预处理？”；Claude 会问：“数据是否静态？内存限制是多少？”；豆包会问：“是否需要支持并发查询？”。这种提问习惯，正是人类工程师在接手需求时的第一反应——先确认约束，再设计方案。而失败的模型，往往一上来就埋头写代码，把 prompt 当圣旨，把解法当终点。这提醒我们：在 AI 编程时代，提问能力比编码能力更稀缺。
4. 综合能力透视：从分数表看模型的真实定位
4.1 前端与算法总分对照表（满分 100）
| 模型 | 前端总分 | 算法总分 | 综合总分 | 核心优势 | 关键短板 | 适合场景 |
|---|---|---|---|---|---|---|
| Gemini-3.0pro | 45 | 39 | 84 | 视觉设计直觉强，工程权衡意识佳，稳定性极高 | 渐变方向感弱，离线算法偏好强 | 快速原型开发、UI 密集型需求、需要稳定交付的中小型项目 |
| Claude-Opus4.5 Thinking | 55 | 29 | 84 | 需求理解深度顶级，数学建模能力强，调试心智成熟 | 响应速度慢，过度设计倾向 | 复杂算法攻坚、需要深度推理的架构设计、对代码质量要求极高的核心模块 |
| 豆包 | 53 | 6 | 59 | 工程完成度最高，快捷键/可访问性等细节到位，修复能力一流 | 算法上限明显，渐变实现欠打磨 | 日常前端开发、快速迭代的业务系统、需要兼顾多端兼容的项目 |
| 千问（Qwen3-Max） | 53 | 9 | 62 | 代码结构最规范，注释最详尽，Class 封装意识强 | 算法知识盲区大，拒绝接受高级数据结构 | 教学演示、代码审查辅助、需要高度可维护性的长期项目 |
| Grok-4.1Thinking | 43 | 23 | 66 | 响应速度最快，分块思想新颖，敢于尝试非主流解法 | 需求翻译失真，优化方向易偏移 | 探索性开发、POC 快速验证、对响应延迟敏感的实时系统 |
| ChatGPT-5.1Thinking | 35 | 9 | 44 | 语法最规范，错误处理最完善，TypeScript 支持好 | 交互逻辑缺失，越改越错现象严重 | 初学者学习、基础脚手架生成、对语法正确性要求严苛的场景 |
| DeepSeek | 25 | 20 | 45 | 键盘快捷键等创新点突出，产品思维活跃 | 核心功能不可用，调试能力近乎为零 | 概念验证、需要激发创意的头脑风暴环节 |
| 文心5.0Preview | 40 | 31 | 71 | 形式化验证意识强，内存管理严谨，深色模式适配好 | 响应时间灾难，边界处理粗暴 | 对安全性/可靠性要求极高的金融、医疗类系统（需人工严格审核） |
| glm4.6 | 40 | 9 | 49 | 注释最详细，C++ 标准库使用最地道 | 渐变完全缺失，算法知识陈旧 | C++ 专项开发、需要严格遵循编码规范的嵌入式/系统级项目 |
这张表不是排名，而是能力坐标系。Gemini 和 Claude 并列第一，但它们的“第一”含义完全不同：Gemini 是“最可靠的队友”，Claude 是“最犀利的军师”。你在赶工期时，Gemini 能给你一个 80 分的可用方案；你在攻克技术难关时，Claude 能带你突破 90 分的理论极限。而豆包的 59 分，是所有模型中“方差最小”的——它可能永远拿不到 90 分，但也绝不会跌到 40 分以下。这种稳定性，在真实项目中价值千金。
4.2 跨模型协作工作流：如何把九个模型变成你的“AI 工程团队”
基于本次测评，我总结出一套高效的跨模型协作模式，已在我的三个实际项目中验证：
Step 1：需求破冰（用 Claude）
把模糊需求（如“做个数据看板”）丢给 Claude，让它输出：① 需求澄清问题清单（至少 5 个）；② 可行性技术方案对比（含优缺点）；③ 推荐的 MVP 功能范围。Claude 的深度思考模式，能帮你避开 70% 的需求陷阱。
Step 2：前端实现（用 Gemini）
把 Claude 输出的 MVP 需求，喂给 Gemini，要求生成“单 HTML 文件，含完整交互和响应式设计”。Gemini 的视觉直觉和工程稳定性，能确保你拿到一个可直接运行的起点。
Step 3：细节打磨（用豆包）
把 Gemini 的代码交给豆包，指令：“请为这段代码添加键盘快捷键（空格暂停/ESC 退出）、深色模式支持、PWA 离线缓存”。豆包对工程细节的执着，能把 80 分的代码打磨到 95 分。
Step 4：算法攻坚（用 Claude 或 Gemini）
遇到复杂算法问题，先让 Claude 建模，再让 Gemini 优化实现。Claude 负责“为什么”，Gemini 负责“怎么做”，二者互补。
Step 5：终极审查（用千问）
把所有代码交给千问，指令：“请逐行审查代码，标注所有潜在安全漏洞、性能瓶颈、可维护性问题”。千问的教科书式结构，能帮你发现人类容易忽略的细节。
这套流程下，我的前端开发效率提升了 3 倍，算法题解决时间从平均 2 小时缩短到 25 分钟。关键不是“哪个模型最强”，而是“哪个模型在哪个环节最不可替代”。
4.3 我的实操心得：三个血泪教训
教训一：永远不要相信“一键运行”的承诺
所有模型都声称“生成的代码可直接运行”，但我的实测表明：100% 的代码都需要至少一次手动修改。最常见的修改是：① 修复 DOM ID 绑定（占 63%）；② 补充浏览器兼容性处理（占 28%）；③ 调整 CSS 单位（rem→px 或反之，占 9%）。我现在的标准流程是：生成代码 → 在 VS Code 里打开 → 运行 Live Server → 手动点击所有按钮 → 记录所有报错 → 用豆包修复。跳过这一步，等于把调试工作留给上线后的用户。
教训二：提示词里必须包含“失败案例”
当我测试渐变时，最初只写“请实现平滑背景渐变”，结果所有模型都失败。后来我把 DeepSeek 的错误代码（离散颜色切换）作为示例发给 Gemini：“请分析这段代码为什么不是平滑渐变，并给出正确实现”。Gemini 立刻指出：“它用了setTimeout硬切，应改用transition或requestAnimationFrame”，并给出 HSL 插值方案。用反例教学，比正向描述有效十倍。
教训三：算法题务必限定“禁止使用的数据结构”
千问和 glm 在主席树上栽跟头，是因为它们默认选择“最熟悉”的解法。当我加上提示：“本题禁止使用暴力遍历、二维数组、哈希表，必须使用可持久化数据结构”，千问立刻转向主席树，并在第三轮给出正确实现。限制，有时是释放创造力的钥匙。
5. 最后一点个人体会
我在写这篇测评时，反复修改了七稿。不是因为数据不准，而是因为每次重跑测试，模型都在进化——Gemini 更新了 3.5 版，Claude 推出了 Sonnet 4.0，豆包上线了新代码模式。这提醒我：任何横评都是过期的快照，但方法论是永恒的指南针。与其纠结“哪个模型现在最强”，不如建立自己的评估体系：用你最痛的业务场景当考题，用你最常犯的 bug 当评分项，用你团队的真实工作流当测试环境。我现在的桌面便签上写着三句话：第一句是“没有完美的模型，只有最适合当前任务的模型”；第二句是“AI 不是替代工程师，而是把工程师从重复劳动中解放出来，去做只有人类能做的创造”；第三句是“今天你教会 AI 如何写一个番茄钟，明天它就可能帮你设计整个前端架构——前提是，
