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.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 常见问题速查表

5.4 一些零散但有用的经验

Cursor 的代码跳转功能（类似 Source Insight 那种）在最新版里已经支持了，快捷键是Ctrl+点击。如果你之前用惯了 Source Insight，这个功能能省不少事。但它对动态语言的跳转支持一般，Python 里如果用了getattr之类的动态调用，它可能跳不过去。

关于提示词泄露的问题，我个人的看法是：不用太紧张。模型的能力在于理解和生成，不在于记住某个特定的提示词。你真正该关注的是怎么把需求描述清楚，而不是去猜模型的"隐藏指令"。

Codex 接入 DeepSeek 这个玩法我试过，配置起来不算复杂，但稳定性一般。如果你只是偶尔用用，建议还是用官方支持的模型。生产环境里，稳定性比省钱重要。

6. 我的选择与后续计划

测完这三个任务，我现在的分工是这样的：日常重构和调试用 Opus 5.5，创意类任务比如 SVG 生成、文案草稿用 GPT-6 Sol。Cursor 作为主力编辑器，Codex 作为补充，主要用在需要终端操作的场景。

这个分工不是固定的。模型更新很快，可能下个月我的用法就变了。但有一个原则我觉得不会变：别迷信跑分，拿你自己的真实任务去测。跑分高不代表在你手里好用，跑分低也不代表不能干活。

后面我打算再测两个场景：一个是多轮对话下的需求变更追踪，看模型能不能记住前面说过的约束；另一个是代码审查，看它能不能发现一些不那么明显的逻辑问题。这两个场景更贴近团队协作，测出来的结果可能更有参考价值。

如果你也在用这两个模型，欢迎交流你的实测结果。特别是如果你发现了什么我漏掉的坑，或者有更好的提示词写法，直接说就行。这种东西，一个人测不如一群人测。