1. 首发实测两个新模型同时上线我拿什么测的早上刷到消息的时候我正在改一个老项目的构建脚本群里突然炸了锅——Opus 5.5 和 GPT-6 Sol 同一天发布。这种撞车场面不常见上一次有印象的还是两家前后脚更新主力模型。我第一反应不是去看跑分而是先把手里正在用的几个工具链理了一遍Cursor 还开着Codex 的终端窗口没关浏览器里挂着三四个待测的提示词草稿。先说清楚我这次实测的定位。我不是跑分党也不做那种几十道题的基准测试那种东西看看就好真实开发场景里根本不是一个玩法。我的测试思路很简单拿三个我日常真正会遇到的活儿分别用两个模型跑一遍看谁更省心、谁更少让我返工。这三个活儿分别是——一个中等复杂度的重构任务、一个从零写 SVG 动画的需求、以及一个需要跨文件理解上下文的调试场景。为什么选这三个因为它们覆盖了三种不同的能力维度。重构考的是对代码结构的理解和对副作用的预判SVG 动画考的是空间想象和精确的坐标计算跨文件调试考的是上下文窗口的利用效率和信息检索能力。这三样东西跑分榜单上体现不出来但你每天写代码都会碰到。测试环境我统一了一下同一台机器同样的网络条件Cursor 里分别切换两个模型Codex 那边也是同样的配置。提示词我尽量保持一致只在必要的地方做微调——因为两个模型的指令遵循风格确实有差异这个后面会细说。每个任务我跑三轮取中间那次的结果避免偶然性。提示做模型对比测试的时候一定要控制变量。网络波动、上下文残留、甚至编辑器的缓存状态都可能影响结果。我习惯每换一个模型就重启一次会话把之前的对话历史清干净。先给个总体印象具体的后面拆开讲。Opus 5.5 在代码理解和重构类任务上给我的感觉是稳它不太会给你惊喜但也很少让你失望。GPT-6 Sol 则在创意类任务上明显更活跃SVG 那个任务它第一轮就给出了一个我没想到的方案。但到了跨文件调试环节两者的差距反而没那么大都能用只是风格不同。这里要提一句 Cursor 的模型切换体验。新模型上线当天 Cursor 就推了更新切换入口在设置里的模型选择下拉框不需要改配置文件。Codex 那边稍微麻烦一点需要手动更新 CLI 版本然后重新登录一次。如果你在用 cc switch 之类的配置管理工具记得检查一下 endpoint 配置有没有被覆盖——我就遇到了cc switch local proxy failed while handling codex endpoint /responses这个报错折腾了十几分钟才搞定。2. 重构任务实测谁更懂别乱动我的代码2.1 任务设定与预期我挑了一个大概八百行的 Python 服务模块里面有几个函数职责重叠还有两处明显的重复逻辑。我的要求是把重复的部分抽出来但不要改变任何对外接口的行为也不要引入新的依赖。这个任务的关键在于克制——好的重构是尽量少动而不是趁机大改。提示词我写得很直白这个文件里有重复逻辑帮我抽成一个公共函数。不要改任何函数签名不要改 import不要动测试文件。然后我把文件内容贴进去。2.2 Opus 5.5 的表现Opus 5.5 给我的第一版方案就很保守。它只动了那两个重复的函数体抽了一个私有方法出来其他什么都没碰。我特意检查了它有没有偷偷改 import 顺序或者格式化别的代码——没有。这一点让我挺满意因为很多模型在做重构的时候会手痒顺手把不相关的地方也改了review 的时候很痛苦。但它也有个问题抽出来的函数命名有点啰嗦叫_process_and_validate_input_data其实内部逻辑没那么复杂。我手动改短了。另外它在注释里写了一段解释说为了保持向后兼容性保留了原有的参数校验逻辑——这个判断是对的但它没告诉我它考虑过哪些其他方案。我想要的是它把取舍讲清楚而不是直接给结果。第二轮我追问了一句你有没有考虑过用装饰器来做它回答说考虑过但装饰器会改变函数的调用栈可能影响现有的错误追踪逻辑所以放弃了。这个回答质量很高说明它是真的理解了代码的约束条件而不是随便选了个方案。2.3 GPT-6 Sol 的表现GPT-6 Sol 的第一版方案就激进多了。它不仅抽了公共函数还顺手把两个函数的参数校验逻辑合并了并且改了一个内部变量的命名。功能上没问题但这就超出了我的要求范围。我让它回退它倒是很听话第二版就收敛了。不过它在解释方案的时候更主动。它列了一个小表格对比了三种抽取方式的优缺点还标注了每种方式对现有测试的影响。这个习惯很好省了我自己去推演。但它有个小毛病它倾向于用更现代的写法比如用functools.cache做缓存而我的项目里根本没用到这个引入新 import 就违反了不加依赖的要求。我指出来之后它才改掉。2.4 对比小结维度Opus 5.5GPT-6 Sol指令遵循严格不多动偏主动需要约束方案解释追问后才展开主动给出对比代码风格保守贴近原风格偏现代可能引入新写法返工次数1 次命名调整2 次回退去依赖这个环节我的结论是如果你做的是那种别给我惹事的重构Opus 5.5 更省心。如果你想要模型帮你多想几种方案GPT-6 Sol 更合适但你得盯着它别跑偏。注意不管用哪个模型做重构一定要在提示词里明确不要改什么。模型默认倾向于优化而重构场景下不改变行为比优化更重要。3. SVG 动画实测鹈鹕骑自行车到底难在哪3.1 为什么用这个提示词generate an svg of a pelican riding a bicycle这个提示词最近在圈子里传得很广我一开始以为是玩笑后来发现它其实是个很好的测试用例。原因有三第一鹈鹕这个动物有特征性的喙和喉囊画不像就一眼假第二骑自行车涉及人体鸟体与机械的结构关系考验空间布局第三SVG 是纯代码生成没有差不多的空间坐标错了就是错了。我用的提示词是Generate an SVG of a pelican riding a bicycle. The pelican should be pedaling, and the bicycle should have visible spokes. Use a viewBox of 0 0 400 300.3.2 Opus 5.5 的 SVG 输出Opus 5.5 给出的 SVG 结构很规整。它用了g分组把鹈鹕的身体、喙、翅膀、腿分别放在不同的组里自行车也分了车架、轮子、踏板。坐标计算基本合理鹈鹕的喙画得挺像喉囊用了一个椭圆加路径组合。但它有个明显问题鹈鹕的腿和自行车的踏板没有对齐。腿画在了踏板后面看起来像是悬空的。我让它修正它调整了腿的坐标但第二轮又出现了新问题——翅膀的位置挡住了车把。第三轮才勉强能看。整体来说Opus 5.5 的 SVG 是工程正确的结构清晰代码可读性好但艺术性一般。它画的鹈鹕更像是一个示意图而不是插画。3.3 GPT-6 Sol 的 SVG 输出GPT-6 Sol 第一版就让我意外了。它没有用简单的几何图形拼而是用贝塞尔曲线画了鹈鹕的身体轮廓流畅度明显更好。自行车的轮子它用了circle加line组合来画辐条还加了stroke-dasharray做了一点动态感。但它的坐标精度有问题。鹈鹕的喙和身体连接处有一个明显的缝隙放大看能看出来。而且它用的 viewBox 是它自己定的没按我要求的 400x300导致整体比例有点怪。我指出后它改了 viewBox但喙的缝隙问题改了两轮才修好。有意思的是它主动加了一个animateTransform让轮子转起来。这个我没要求但确实是个加分项。不过在实际项目里这种未经要求的动画可能会带来性能问题所以我最后还是删掉了。3.4 SVG 生成的实操心得做 SVG 生成测试我总结了几个检查点你可以直接拿去用viewBox 是否符合要求模型经常自作主张改尺寸导致嵌入页面时比例不对。分组结构是否清晰g的嵌套层级决定了后续好不好改。层级太深或者全平铺都不好。坐标是否对齐重点看连接处比如肢体与躯干、零件与零件之间。是否有冗余代码有些模型会生成大量无用的defs或重复的样式定义。动画是否可控如果模型主动加了动画确认它用的是标准属性别用了一些奇怪的写法。提示如果你要把生成的 SVG 转成 Compose 的 ImageVector比如svg → compose imagevector kotlin这个场景一定要先让模型把 SVG 简化去掉所有动画和滤镜只保留路径和基本形状。否则转换工具很容易报错。另外提一句SVG 在室内导览系统里的应用最近也挺多。如果你做的是这类项目建议让模型生成时就用统一的坐标系和图层命名规范不然后期维护很头疼。4. 跨文件调试实测上下文窗口的真实利用率4.1 任务设计我模拟了一个真实场景一个项目里有五个文件其中三个是业务逻辑两个是配置和工具函数。我在业务逻辑里埋了一个 bug——一个变量在某个分支下没有被正确初始化导致后续计算出现 NaN。这个 bug 的特点是单看一个文件看不出来必须跨文件追踪数据流。我把五个文件的内容都贴给模型然后说这个项目运行时报 NaN帮我找到原因并修复。4.2 两个模型的排查路径Opus 5.5 的排查路径很线性。它先看了入口文件然后顺着调用链往下走在每个函数入口处检查参数。它很快就定位到了那个未初始化的变量但它花了不少篇幅解释为什么这个变量在某个分支下不会被赋值。这个解释很详细甚至画了一个简单的分支树用文字描述的。修复方案也很直接加一个默认值。GPT-6 Sol 的路径不太一样。它先扫了一遍所有文件然后列了一个可疑点清单按可能性排序。它把那个未初始化变量排在了第二位第一位是另一个其实没问题的配置项。然后它逐个排除最后定位到真正的 bug。这个过程更接近人类调试的思路但多花了一轮对话。4.3 上下文利用效率这里有个关键差异。Opus 5.5 在处理长上下文时倾向于深挖——它会反复引用前面文件里的内容确保理解一致。GPT-6 Sol 则倾向于广撒网——它会快速扫描所有文件建立一个大致的索引然后按需回查。这两种策略各有优劣。如果你的项目文件之间耦合度高Opus 5.5 的方式更稳。如果文件之间相对独立GPT-6 Sol 的方式更快。但要注意GPT-6 Sol 在上下文特别长的时候我试了大概一万五千行代码偶尔会出现记错的情况——它会引用一个不存在的函数名。Opus 5.5 在同样长度下没有这个问题但响应速度明显慢了一些。4.4 调试场景的实操建议跨文件调试是我日常用得最多的场景几个经验分享给你文件顺序很重要把入口文件放在最前面工具函数放在最后面。模型处理上下文时对开头和结尾的内容记得更牢。明确告诉模型从哪开始比如从 main.py 的 process 函数开始追踪比让它自己找效率高很多。要求模型给出排查路径不只是要结果还要它说清楚怎么找到的。这样你能判断它是真找到了还是蒙的。分轮次喂文件如果文件特别多别一次性全贴。先贴核心的定位到大概范围后再贴相关的。注意Codex 在处理跨文件任务时如果你用的是 CLI 版本记得检查工作目录设置。我有一次因为工作目录不对它读到的文件是旧版本排查了半天才发现问题。5. 工具链配置与踩坑记录5.1 Cursor 的中文设置与模型切换Cursor 的中文设置其实挺简单但入口藏得有点深。在设置里找到General然后找Language选简体中文就行。但要注意界面语言和模型回复语言是两回事。如果你想让模型用中文回复需要在提示词里明确说或者在自定义指令里加一句Always respond in Chinese。模型切换在Models选项卡里Opus 5.5 和 GPT-6 Sol 都在列表里。切换后建议新开一个会话避免上下文混淆。我试过在同一个会话里切换模型结果第二个模型会继承第一个模型的错误理解很麻烦。5.2 Codex 的安装与配置Codex 的安装包在官网可以下载桌面版和 CLI 版都有。我两个都装了日常用 CLI 多一些。安装过程没什么特别的但登录环节可能会遇到网络问题。如果你在用代理工具记得把 Codex 的域名加到规则里。cc switch那个报错我前面提过原因是本地代理配置和 Codex 的 endpoint 冲突了。解决办法是检查~/.codex/config文件里的 endpoint 设置确保它指向的是正确的地址。如果你不确定就把配置备份一下然后重置为默认值再重新登录。5.3 常见问题速查表问题可能原因解决办法Cursor 模型列表里没有新模型版本未更新检查更新重启编辑器Codex 登录失败网络或 endpoint 配置问题检查配置文件重置后重试模型回复语言不对未设置语言偏好在自定义指令里加语言要求SVG 转换 Compose 报错SVG 含不支持的属性简化 SVG去掉动画和滤镜跨文件调试找不到 bug上下文太长导致遗漏分轮次喂文件明确起始点重构后测试失败模型改了不相关代码提示词里明确不要改什么5.4 一些零散但有用的经验Cursor 的代码跳转功能类似 Source Insight 那种在最新版里已经支持了快捷键是Ctrl点击。如果你之前用惯了 Source Insight这个功能能省不少事。但它对动态语言的跳转支持一般Python 里如果用了getattr之类的动态调用它可能跳不过去。关于提示词泄露的问题我个人的看法是不用太紧张。模型的能力在于理解和生成不在于记住某个特定的提示词。你真正该关注的是怎么把需求描述清楚而不是去猜模型的隐藏指令。Codex 接入 DeepSeek 这个玩法我试过配置起来不算复杂但稳定性一般。如果你只是偶尔用用建议还是用官方支持的模型。生产环境里稳定性比省钱重要。6. 我的选择与后续计划测完这三个任务我现在的分工是这样的日常重构和调试用 Opus 5.5创意类任务比如 SVG 生成、文案草稿用 GPT-6 Sol。Cursor 作为主力编辑器Codex 作为补充主要用在需要终端操作的场景。这个分工不是固定的。模型更新很快可能下个月我的用法就变了。但有一个原则我觉得不会变别迷信跑分拿你自己的真实任务去测。跑分高不代表在你手里好用跑分低也不代表不能干活。后面我打算再测两个场景一个是多轮对话下的需求变更追踪看模型能不能记住前面说过的约束另一个是代码审查看它能不能发现一些不那么明显的逻辑问题。这两个场景更贴近团队协作测出来的结果可能更有参考价值。如果你也在用这两个模型欢迎交流你的实测结果。特别是如果你发现了什么我漏掉的坑或者有更好的提示词写法直接说就行。这种东西一个人测不如一群人测。
