1. 两个模型同天发布，我第一时间跑了同一套题
早上刷到 Opus 5.5 和 GPT-6 Sol 同时上线的消息时，我第一反应不是兴奋，而是怀疑。两家头部模型在同一天发布新版本，这种撞车概率低到不太正常，要么是巧合，要么是有人在抢节奏。但作为一个每天靠 AI 编程助手吃饭的人，我关心的不是商业博弈，而是它们到底能不能让我少改几行 bug。
我给自己定了一个原则：不看官方跑分，不看发布会演示，直接拿我手头真实项目里最烦人的几个任务去测。测试环境统一用 Cursor 作为编辑器外壳，分别接入两个模型，关闭所有自动补全干扰，手动触发对话。测试任务包括：生成一个鹈鹕骑自行车的 SVG 动画、重构一段三百行的 Kotlin Compose 图像处理代码、排查一个 Codex 接入本地代理时的报错、以及用中文写一份技术方案文档。
为什么选这几个任务？因为它们覆盖了当前 AI 编程助手最核心的四个能力维度：创意生成、代码重构、环境排错、中文表达。官方跑分再高，如果在这四件事上掉链子，对我来说就是不可用。实测下来，结果确实让我很意外，但不是那种“谁碾压谁”的意外，而是两个模型在不同维度上表现出了完全不同的性格。
先说结论：Opus 5.5 在代码结构理解和长上下文重构上明显更稳，GPT-6 Sol 在创意生成和中文自然度上更讨喜。但真正让我意外的，是它们在“鹈鹕骑自行车”这个经典 SVG 测试上的表现差异，以及 Codex 接入环节暴露出来的一些配置坑。下面我把整个实测过程拆开讲，包括我用的提示词、遇到的报错、以及最后怎么绕过去的。
2. 鹈鹕骑自行车 SVG：一个看似无聊却极其暴露问题的测试
2.1 为什么大家都爱用鹈鹕骑自行车测模型
“Generate an SVG of a pelican riding a bicycle”这个提示词在 AI 圈子里已经变成一个梗了。它最早被用来测试模型的图形生成能力，后来演变成一种快速判断模型“手活”好不好的土办法。原因很简单：鹈鹕的嘴部结构复杂，自行车有轮辐、链条、车架这些几何细节，两者组合在一起，既考验模型对 SVG 路径指令的理解，也考验它对空间关系的把握。
我这次用的提示词稍微加了一点要求，让它输出带动画的 SVG，鹈鹕的翅膀要上下摆动，车轮要旋转。两个模型都一次性给出了完整代码，但打开浏览器一看，差距立刻出来了。
Opus 5.5 生成的 SVG 结构非常规整，它用了<g>标签把鹈鹕的身体、嘴、翅膀、自行车车架、车轮分组，每个组都有清晰的id命名。动画部分用了<animateTransform>对车轮做旋转，翅膀用了<animate>做d属性的路径变形。整体代码大约 180 行，注释虽然不多，但变量命名可读性很好。渲染出来鹈鹕的嘴是标准的下颌囊结构，自行车车架是菱形结构，轮辐用了<line>循环生成。
GPT-6 Sol 生成的 SVG 更“艺术化”，它给鹈鹕加了一些渐变填充和阴影效果，翅膀动画用了 CSS@keyframes而不是 SMIL 动画。代码大约 220 行，视觉上更讨喜，但结构上稍微乱一些，有些路径的坐标是硬编码的，改起来不如 Opus 5.5 方便。最明显的问题是，它把自行车的前轮画成了一个椭圆，而不是正圆，导致旋转动画看起来有点晃。
2.2 两个模型在 SVG 路径指令上的具体差异
我把两个 SVG 都丢进编辑器里逐行对比，发现了一些很有意思的细节。Opus 5.5 在路径指令上更倾向于使用相对坐标（小写字母命令），比如c和s，这让路径在缩放时更稳定。GPT-6 Sol 大量使用绝对坐标（大写字母命令），虽然定位精确，但一旦你想调整整体尺寸，就得手动改很多数值。
另一个差异在<path>的复杂度控制上。Opus 5.5 会把鹈鹕的嘴拆成三个独立的路径：上喙、下喙、喉囊，每个路径的d属性控制在 8 到 12 个控制点。GPT-6 Sol 把整个头部用一个路径搞定，控制点超过 30 个，虽然渲染结果差不多，但可维护性差很多。如果你后续想单独调整喉囊的颜色，Opus 5.5 的版本直接改对应路径的fill就行，GPT-6 Sol 的版本得重新拆分路径。
提示：如果你也打算用 SVG 测试模型，建议在提示词里明确要求“使用相对坐标命令”和“将复杂图形拆分为独立路径组”。这两个约束能显著提升生成代码的可维护性，尤其是当你后续要接入 SVG Live2D 或者做动态交互时。
2.3 动画实现方式的取舍与兼容性坑
Opus 5.5 用的 SMIL 动画（<animate>和<animateTransform>）在 Chrome 和 Safari 上表现一致，但在某些嵌入式 WebView 里支持不完整。GPT-6 Sol 用的 CSS 动画兼容性更好，几乎所有现代浏览器都支持，但它在 SVG 内部写<style>标签的做法，在某些严格的 XML 解析器里会报错。
我实际测试下来，如果你只是想在网页里展示，两个方案都没问题。但如果你要把 SVG 导入到 Figma 或者 Adobe Illustrator 里继续编辑，SMIL 动画会被直接丢弃，CSS 动画也会变成静态样式。所以如果你需要后续编辑，最好让模型生成不带动画的静态版本，动画单独用 CSS 或 JS 控制。
还有一个坑：GPT-6 Sol 生成的 SVG 里用了filter做阴影，这个在导出为 PNG 时会导致边缘模糊。Opus 5.5 的版本没有用滤镜，导出后边缘很干净。如果你需要把 SVG 转成位图用于室内导览系统或者图标库，建议在提示词里加一句“不要使用 filter 效果”。
3. 代码重构实战：三百行 Kotlin Compose 图像处理代码
3.1 我拿什么代码去测，为什么选这段
我手头有一个正在做的项目，里面有一段用 Jetpack Compose 写的图像处理代码，功能是把用户上传的图片做裁剪、旋转、滤镜叠加，然后生成缩略图。这段代码大概三百二十行，是我半年前赶工期时写的，里面有不少重复逻辑和硬编码的尺寸值。我早就想重构，但一直没腾出时间。这次正好拿它来测两个模型的代码理解能力。
我把完整代码粘贴给两个模型，提示词是：“重构这段 Kotlin Compose 代码，提取可复用的图像处理函数，消除重复逻辑，补充必要的注释，保持原有功能不变。”我没有给任何额外的结构建议，想看它们自己怎么组织。
3.2 Opus 5.5 的重构方案：保守但可靠
Opus 5.5 花了大约四十秒给出结果。它首先把代码拆成了三个文件：ImageProcessor.kt放核心处理逻辑，ImageModifiers.kt放滤镜和变换的扩展函数，ThumbnailGenerator.kt放缩略图生成。每个文件里的函数职责很清晰，比如applyFilter接收一个ImageBitmap和一个FilterType枚举，返回处理后的ImageBitmap。
它做的最有价值的一件事是，把原来散落在各处的尺寸计算逻辑统一成了一个ImageSizeCalculator类，里面用dp和px的转换函数替代了硬编码的数值。这个改动直接解决了我之前在不同屏幕密度下缩略图尺寸不一致的问题。它还主动加了一个@Stable注解在数据类上，提示 Compose 编译器这个类不会频繁变化，可以跳过重组。
不过 Opus 5.5 的重构偏保守，它没有改变原有的函数签名，也没有引入新的依赖。这意味着如果你直接替换文件，调用方几乎不需要改动。对于生产环境来说，这种保守策略其实是优点，风险低。
3.3 GPT-6 Sol 的重构方案：激进但需要人工兜底
GPT-6 Sol 花了差不多同样的时间，但它的方案激进得多。它直接把原来的命令式代码改成了声明式的 Compose 状态流，引入了一个ImageProcessingState数据类，用mutableStateOf管理处理进度和结果。它还建议我把图像处理放到LaunchedEffect里，避免阻塞主线程。
这个思路本身是对的，但它忽略了一个关键问题：我原来的代码里有一些同步的Bitmap操作，这些操作在LaunchedEffect里执行时，如果用户快速切换图片，会导致状态竞争。GPT-6 Sol 没有处理这个边界情况，它假设每次处理都是独立的。我实际跑了一下，快速点击切换图片时，缩略图确实出现了错乱。
另外，GPT-6 Sol 引入了一个第三方库coil来做图片加载，但我的项目里已经用了glide，这会导致依赖冲突。它没有先问我现有依赖是什么，就直接假设了一个方案。这一点在实战中很致命，因为重构的第一原则是不破坏现有构建。
注意：用 AI 做代码重构时，一定要在提示词里明确“不要引入新的第三方依赖”和“保持现有函数签名不变”。否则模型很容易为了追求代码优雅而引入你不需要的库，后续合并代码时非常痛苦。
3.4 重构结果对比与我的最终选择
我把两个方案都合并到本地分支跑了一遍单元测试。Opus 5.5 的版本一次通过，没有编译错误，运行时也没有崩溃。GPT-6 Sol 的版本编译通过了，但有两个测试用例失败，都是因为状态竞争导致的缩略图错乱。
最终我采用了 Opus 5.5 的重构方案，但把 GPT-6 Sol 提出的LaunchedEffect思路手动加了进去，同时补了一个Mutex来防止并发处理。这样既保留了保守重构的低风险，又吸收了激进方案里对主线程友好的部分。
这次对比让我意识到，模型在代码重构上的差异，本质上是对“风险”的理解不同。Opus 5.5 更像一个在成熟团队里待过的工程师，知道什么该动什么不该动。GPT-6 Sol 更像一个刚毕业的聪明学生，想法很好但缺乏生产环境的毒打。
4. Codex 接入本地代理报错：一个让我折腾了两小时的坑
4.1 报错现场：cc switch local proxy failed
测试完模型能力后，我打算把 Codex 接到本地的一个代理服务上，方便统一管理不同模型的 API 调用。结果刚配置完就报错了，错误信息是cc switch local proxy failed while handling codex endpoint /responses。这个报错在社区里搜一下，发现不少人遇到过，但解决方案五花八门，有些已经过时了。
我先检查了代理服务的日志，发现请求确实到达了代理，但在转发到 Codex 的/responses端点时被拒绝了。代理返回的状态码是 502，说明上游连接有问题。我一开始以为是代理配置里的地址写错了，反复检查了三遍，确认地址和端口都没问题。
4.2 逐步排查：从网络层到配置层
排查这类问题，我的习惯是从外往里一层层剥。第一步，用curl直接请求 Codex 的端点，绕过代理，看能不能通。结果直接请求是成功的，说明 Codex 服务本身没问题。第二步，用curl通过代理请求同一个端点，复现了 502 错误。这说明问题出在代理的转发逻辑上。
我打开代理的配置文件，发现它用的是http协议转发，但 Codex 的端点要求https。代理在转发时没有做协议升级，导致上游服务器直接断开了连接。我把代理配置里的target地址从http://改成https://，重启代理，问题解决。
但事情没这么简单。改完之后，新的报错出现了：cc switch local proxy failed while handling codex endpoint /responses变成了timeout。这次是代理等待上游响应超时。我检查了代理的超时设置，默认是 30 秒，而 Codex 在处理复杂请求时可能需要更长时间。我把超时调到 120 秒，再次重启，终于通了。
4.3 配置 Codex 时容易忽略的三个细节
第一个细节是端点路径。Codex 的 API 路径是/responses，不是/v1/responses，也不是/api/responses。很多代理配置模板里写的是/v1/responses，直接套用就会 404。这个路径在 Codex 的官方文档里写得很清楚，但很多人不看文档直接抄配置。
第二个细节是请求头。Codex 要求请求里必须带Content-Type: application/json和Authorization: Bearer <token>。代理在转发时如果丢掉了这两个头，Codex 会直接返回 401。我用的代理默认会保留原始请求头，但有些代理为了“安全”会过滤掉Authorization，这个要特别注意。
第三个细节是流式响应。Codex 默认返回的是流式响应（text/event-stream），如果代理不支持流式转发，会把整个响应缓冲完再返回，导致前端一直转圈。我用的代理需要显式开启streaming: true配置项，否则就会卡住。
提示：如果你也在用 Codex 接入本地代理，建议先用
curl -v发一个最简单的请求，把完整的请求头和响应头打出来看。很多问题看一眼头信息就能定位，比翻日志快得多。
4.4 代理配置的最终可用版本
经过这一轮折腾，我整理了一份最小可用的代理配置。核心就是三点：目标地址用https，超时设到 120 秒，开启流式转发。另外，如果你用的是ccswitch这类工具来管理多个模型的切换，记得在切换配置里把 Codex 的端点单独列出来，不要和其他模型的端点混在一起。不同模型的 API 路径和认证方式差异很大，混在一起很容易出问题。
我还发现一个现象：Codex 在处理中文提示词时，如果代理没有正确设置charset=utf-8，返回的中文会变成乱码。这个问题在英文提示词下不会出现，所以很容易被忽略。如果你主要用中文和 Codex 交互，记得在代理配置里加上字符集设置。
5. 中文表达与提示词泄露：一个意外的发现
5.1 两个模型的中文自然度对比
我让两个模型分别用中文写一份“图像处理模块技术方案”，要求包含背景、目标、架构设计、接口定义、测试计划五个部分。Opus 5.5 的输出非常像一份正式的技术文档，用词严谨，句式偏书面化，比如“本方案旨在……”“基于上述分析……”。GPT-6 Sol 的输出更口语化，它会用“我们打算……”“这里有个坑要注意……”这样的表达，读起来更像一个工程师在跟你聊天。
如果你是要交给领导看的正式文档，Opus 5.5 的风格更合适。如果你是要发在团队内部 wiki 上，GPT-6 Sol 的风格更容易读。但 GPT-6 Sol 有一个小问题，它在技术方案里加了一些不必要的感叹号，比如“这个设计非常棒！”，这在正式文档里显得不够专业。你可以在提示词里加一句“不要使用感叹号”，就能解决。
5.2 Cursor 中文设置与提示词泄露的关联
测试过程中我顺手把 Cursor 的界面语言切成了中文，想看看中文环境下两个模型的表现有没有变化。结果发现一个有意思的现象：当 Cursor 界面语言是中文时，模型在生成代码注释时也会倾向于用中文，即使我的提示词是英文。这说明 Cursor 会把界面语言作为上下文的一部分传给模型。
关于“Cursor 提示词泄露”这个热词，我实际测试了一下。在 Cursor 里输入某些特定指令时，模型确实会暴露出一些系统提示词的片段，比如“你是一个有帮助的编程助手”之类的。但这些都是很通用的提示词，没有泄露任何敏感信息。我的建议是，不要过度关注提示词泄露，把精力放在怎么写好自己的提示词上更有价值。
5.3 中文回复设置的实操步骤
如果你想让 Cursor 里的模型默认用中文回复，有两个方法。第一个方法是在 Cursor 的设置里把界面语言改成中文，这样模型会倾向于用中文回复。第二个方法是在每次对话的开头加一句“请用中文回复”，这个方法更可靠，但每次都要加，比较麻烦。
我实测下来，最稳的方案是在 Cursor 的“自定义指令”里加一条规则：“所有回复使用简体中文，代码注释使用英文。”这样既保证了沟通效率，又避免了代码注释里出现中文导致的编码问题。这个设置对 Opus 5.5 和 GPT-6 Sol 都有效。
6. 我的最终选型建议与日常使用搭配
6.1 什么场景用 Opus 5.5，什么场景用 GPT-6 Sol
经过这一轮实测，我给自己定了一个简单的分工规则。涉及代码重构、长上下文理解、复杂逻辑排查的任务，我用 Opus 5.5。它的输出更稳，不容易引入意外依赖，适合在生产代码上操作。涉及创意生成、中文文档写作、快速原型设计的任务，我用 GPT-6 Sol。它的输出更灵活，视觉效果好，中文表达更自然。
具体到日常使用，我早上写代码的时候用 Opus 5.5 做重构和 review，下午写文档和做演示的时候用 GPT-6 Sol 生成初稿。两个模型在 Cursor 里可以随时切换，切换成本很低。
6.2 关于 SVG 和 Live2D 的后续扩展
这次测试生成的鹈鹕骑自行车 SVG，我后来把它导入到了 SVG Live2D 工具里，想看看能不能做成一个简单的动态桌宠。结果发现 Opus 5.5 生成的 SVG 因为路径分组清晰，导入后每个部件都能独立控制，稍微调一下参数就能让鹈鹕的嘴和翅膀动起来。GPT-6 Sol 的版本因为路径合并太多，导入后只能整体移动，没法做局部动画。
如果你也想用 AI 生成 SVG 来做 Live2D 或者室内导览系统的图标，建议在提示词里明确要求“每个可动部件单独分组，并添加语义化的 id”。这个约束对后续的动画制作帮助很大。
6.3 一个让我意外的小结论
回到标题里说的“结果让我很意外”，意外的地方不在于哪个模型更强，而在于两个模型的差异如此互补。我原本以为 Opus 5.5 会在所有维度上碾压，或者 GPT-6 Sol 会带来某种颠覆性的体验。实际测下来，它们更像是两个风格不同的工程师，一个稳重一个灵活，谁也不能完全替代谁。
如果你只订阅一个，我的建议是看你的主要工作内容。如果你大部分时间在维护老代码、做重构、排查线上问题，选 Opus 5.5。如果你大部分时间在做新项目、写文档、做演示，选 GPT-6 Sol。如果预算允许，两个都留着，按任务切换，效率提升非常明显。
最后分享一个我在这次测试里养成的小习惯：每次让模型生成代码后，不要直接复制粘贴，先让它自己解释一遍关键逻辑。这个步骤能帮你快速判断它是不是真的理解了你的需求，还是只是在套模板。我试过几次之后发现，Opus 5.5 的解释通常更准确，GPT-6 Sol 的解释有时候会跑偏，但跑偏的地方往往能给我一些新的思路。
