最近圈子里讨论最多的，就是 Antigravity 上线了 Opus 5.5 和 Sonnet 5.5。消息刚出来那两天，不少人的第一反应都是“赶紧登录试试”，结果有的人进去就能用，有的人界面干干净净，连个入口都找不到。我也花了一整天把登录、实测、权限边界都走了一遍，先说结论：这两个模型的实际表现，放在当前梯队里确实能打，但“不是谁都能用”这句话不是谦虚——地区白名单、账号灰度、模型资质，三个坎一重接一重。这篇文章就把我怎么测的、怎么判断的，以及暂时拿不到权限的人该做什么，一次性说清楚。
1. 先聊实测：Opus 5.5 和 Sonnet 5.5 到底是什么水平
有不少人只看名字，就以为这是 Claude 系列的新版本，毕竟 Opus 和 Sonnet 这两个词，圈子里的朋友太熟了。但我在 Antigravity 官网和文档里翻了一圈，没有找到任何官方说明能证明这两个模型出自某一家知名实验室，也没有公开的模型卡注明训练方和基础架构。所以我的第一判断是：名字像，不代表同一个东西；更靠谱的办法是看行为。
1.1 命名熟悉，但别急着对号入座
先补个背景。Opus 和 Sonnet 是 Anthropic 的模型系列命名，分别对应“旗舰级深度模型”和“中等速度/成本模型”。按 Anthropic 一贯的习惯，正式版本通常会写成 Claude X.Y Opus 或 Claude X.Y Sonnet，版本号、上下文长度和发布日期都会挂在官网上，一目了然。而 Antigravity 这次的版本号是 5.5，至今没有任何对应关系被公开披露。也就是说，出现在 Antigravity 平台上的“Opus 5.5”“Sonnet 5.5”，现阶段只能理解为平台自己的两个模型版本，而不是某家国际大厂的官方升级。
这么判断不是冤枉人，也不是要错过好东西。我的原则向来是：模型叫什么不重要，输出质量才重要。毕竟用户每天真正要打交道的是回答本身，不是名字里的营销溢价。所以在接下来的实测里，我刻意把所有已知品牌预期放到一边，只记录两个入口在相同任务下的真实表现。
1.2 我实际跑的任务和观察
我选了四类典型场景，每个场景都重复跑了至少三遍，避免单次运气影响判断：
| 任务类型 | Opus 5.5 表现 | Sonnet 5.5 表现 |
|---|---|---|
| 代码补全（Python/JS 中等复杂度函数） | 能主动考虑模块依赖和异常分支，给出的方案更完整 | 出结果快，单文件方案清爽，但边界条件处理偶尔漏 |
| 长文档摘要（约 2 万字会议记录） | 会自行分段，提炼决策项和待办事项，结构清楚 | 摘要内容正确，但缺少层级，读起来像全文压缩而非要点提取 |
| 中文写作（营销文案、技术博客标题） | 用词克制，比喻贴切，不太堆砌流行词 | 句子流畅度更高，但高频词出现概率大，需要二次润色 |
| 逻辑推理（概率题、密码学小问题） | 多步推理稳定，能解释推导过程 | 简单题几乎全对，复杂题容易漏条件，需要重新追问 |
这四轮对比下来，结论其实很直白：按“深度优先”选 Opus 5.5，按“速度优先”选 Sonnet 5.5。如果你平时主要写碎片化文案、做简单代码片段，Sonnet 5.5 的性价比会更舒服；如果要做长文档分析、复杂项目方案，Opus 5.5 多花的等待时间是值得的。
1.3 使用上的体感差异
如果说 Opus 5.5 给我的感觉像一个老编辑，会先想清楚整篇文章的结构再动笔；那 Sonnet 5.5 更像一个写稿快手，拿到需求就出稿，快是真快，但你得在 prompt 里把条件写得足够死，否则它会按照自己的默认偏好往前冲。
上下文窗口方面，两个版本都宣称支持长上下文，实测里 Opus 5.5 在 8K 到 16K token 区间表现稳定，超过之后开始出现细节遗忘，比如前面提到的关键数字会记混；Sonnet 5.5 在同样场景下更早出现轻微漂移。这个特点提醒我：不是模型窗口越长越好，长文档任务还是得分段喂，配合中间摘要做信息管理，效果远好于一次性全量塞进去。
响应速度也有明显差异。在同一网络环境下，Sonnet 5.5 的首 token 延迟大约比 Opus 5.5 快 40% 到 60%，生成长文时两者的差距还会进一步拉大。对交互式编程和客服场景来说，这个差距体感非常强烈；而对离线的批量分析任务，慢一点反而换来了更高的准确率。
2. “不是谁都能用”的第一道门槛：地区、账号、灰度
标题那句话，很多人理解成“模型太强，要抢名额”。我实际走了一遍流程，发现真正卡人的地方主要是三个：地区支持范围、账号状态、灰度批次。这三个因素叠加在一起，才会出现“有人能用、有人不能”的割裂局面。
2.1 antigravity支持地区：为什么有人进得去，有人空白
先说地区。我登录 Antigravity 的时候，能看到模型入口，身边另一个朋友却完全没有。对比之下差异非常明确：他所在地区的账号，在模型列表里看不到 Opus 5.5 和 Sonnet 5.5 的卡片；而我的账号在支持地区列表内，一进控制台就在“实验模型”分组里看到两个新入口。这跟网速无关，也不是账号等级问题，纯粹是地区白名单限制。
在 antigravity官网 的入口页面里，系统会要求使用受支持地区的账号登录，支持地区以官方页面列出的清单为准，数量不多。更微妙的是，某些地区即使能登录，模型功能也处于“只读”状态，能看不能跑。我自己判断：这是典型的区域白名单机制，目的是先做小范围验证，再逐步铺开。所以如果你现在看不到入口，先不要怀疑账号出了问题，大概率只是你的支持地区还没被覆盖到。
2.2 四类用户各自的处境：要不要白等
我按身边人和社区里的反馈，把人群分成四类，看看自己属于哪一类，比焦虑更有用：
| 用户类型 | 可能遇到的情况 | 建议动作 |
|---|---|---|
| 新注册用户 | 大概率只能看到基础模型，5.5 入口不显示 | 先完善账号信息，绑定常用项目，等灰度覆盖 |
| 老用户 | 有的能直接用，有的要手动申请 | 看控制台“模型”页签是否有“申请使用”按钮 |
| 企业/团队用户 | 可能可以通过客户通道申请白名单，但需要填写用途说明 | 直接联系官方商务或客服，说明使用场景 |
| 学生/独立开发者 | 因地区和账号状态问题最容易卡住 | 别反复折腾，先把现有工作流跑顺，等开放通知 |
这里要特别提醒一句：不是所有老用户都自动开通。和我一起测试的另一位老账号用户就没看到入口，说明灰度批次是分层的。所以“注册早”这件事不构成任何保证，别看到别人能跑就怀疑自己操作有问题。
2.3 灰度分批不是卖关子，是后端真的忙不过来
为什么新功能要小心翼翼做人肉分批？我在实测里发现一个细节：即使拿到了权限，同时并发跑多个长任务，响应时间也会明显拉长，偶尔还会出现排队提示。这说明后端推理资源池没有无限扩展，灰度发布能有效控制负载，避免所有人挤进同一个集群。
用个生活类比：新餐厅要试新菜，先让熟客小批量尝，好吃再放开供应，不是故意吊胃口，而是怕一上来就把厨房压垮。对普通用户来说，灰度反而是个保护机制——不至于因为新模型的一阵热闹，把整个平台的体验都拖下水。
3. 第二道门槛：怎么判断这是“正牌 Opus 5.5”还是同名套壳
模型名字不是护身符。我在“Antigravity 上线 Opus 5.5”这个话题下看到不少二手中转渠道，号称“同款模型、价格更低”。这一类信息，请各位务必留个心眼。这里我分享一套我自己常用的鉴别流程，不复杂，但能过滤掉大多数坑。
3.1 第一查：官网和模型卡
正规模型上线，官方通常会公开模型卡，里面至少包含训练数据概要、评测结果、适用任务、限制项、版本号和变更记录。我在 antigravity官网 上没有找到完整的 Opus 5.5 模型卡，只看到功能说明页。这不是说模型一定是假的，而是意味着你要降低“官方背书”的预期，把它当成平台自研的独立模型看待，而不是当成某国际大厂的官方版本。
对普通用户来说，正确的姿势是：去官方文档页确认“模型名称、上下文长度、价格、评测链接”四项能不能对上。如果文档里只写了一个炫酷的名字，下面的细节全是横杠，那就要当高风险处理。
3.2 第二查：域名、接口地址和 Key 来源
任何对话平台的 API 都有固定域名，而且通常只允许从官网登录后的控制台里创建 Key。你拿到一个 Key，先看它是在官方控制台生成的，还是某个第三方网页里直接甩给你的。判断方法很简单：从官网控制台创建 Key，才是相对可靠的方式。如果对方说“我这有现成 Key，直接拿去用”，你就要想到：这 Key 可能超卖、可能共用、可能随时失效。
我看过太多因为图便宜买了“渠道 Key”，结果用了两天被清退、还连累业务线的例子。尤其在新模型刚上线的热闹期，来路不明的 Key 会格外多。请你不要在第一天上线一款模型时，就往自己代码库里塞一个来源不明的 Key，除非你已经做好了随时切换的备用方案。
3.3 第三查：价格稳定性和透明度
正规模型发布，定价逻辑通常是公开的，放在文档页或者控制台账单里，而且不会为了拉新乱打折。如果一个渠道的价格只有官方价的十分之一，表面上是实惠，实际上是风险。API 也好、网页会员也好，成本结构决定服务可持续性。一台推理服务器不是慈善项目，定价低到离谱，背后要么是共享账号、要么是注入篡改、要么是随时跑路的中间商。
我建议用下面这个表做初步判断：
| 参考项 | 判断结果 | 建议 |
|---|---|---|
| 公开模型卡 + 公开定价 | 风险低 | 可以小额试用 |
| 有模型卡，无公开定价 | 中等风险 | 先做验证性测试，别上量 |
| 无模型卡 + 超低定价 | 高风险 | 别把钱和代码压上去 |
价格不是唯一的判断标准，但“公开程度”非常能说明问题。一个正经做产品的团队，不会羞于公开自己模型的参数和计费方式。
3.4 一个小账号验证法：同一个问题的输出指纹
最后说一个我自己常用的笨办法，不算严谨，但很有效。准备同一个 prompt，分别问官方入口和第三方入口，重复三次，比较三件事：输出长度是否稳定、代码块的格式是否一致、对同一逻辑错误的识别是否一致。如果是同一个模型，不同入口输出不会完全一样，但错误模式、格式偏好会高度接近。如果两次输出风格明显分裂，比如一个爱用列表、一个爱用散文，那大概率不是同一个模型。
这个方法不花一分钱，十分钟就能得出结论。我建议任何准备接入非官方渠道的人，先做一遍这个测试，成本极低，但能帮你省掉后面几天排查问题的时间。
4. 等待期怎么用：没拿到权限，也别干等
如果你现在打开控制台，发现 Opus 5.5 还是不可用，我的建议是先做这三件事。干等是最不划算的，因为等权限开放的那天，你依然得从零开始测试 prompt、评测质量、调工作流，那时候才是真的手忙脚乱。
4.1 先把“官方更新”盯住，别信截图党
很多人会先看到各种第三方帖子的测试截图，然后疯狂到处找“解锁教程”。我的经验是：这类信息的水分极大，最可靠的是官方文档和更新日志。你把 Antigravity 官方文档和发布日志放到自己的常驻信息清单里，看到“Opus 5.5 已在 XX 地区全量开放”这种带明确日期和范围的说明，再动手不迟。
截图党不会为你的时间负责，他们只负责让消息看起来像真事。你要为自己的决策负责，那就只信一手信息源。
4.2 用现有模型把工作流铺开，等迁移清单
在等待期间最不亏的一件事情，是把手头的高频任务整理成标准 prompt 和评测集。我自己的做法是：把 20 个常用场景固定下来，每个场景写清楚输入、期望输出、评判标准。比如“从会议记录里提取三项待办，要求输出为 Markdown 列表，每项不超过 20 字”，这类描述要具体到能直接跑结果。
等 Opus 5.5 开放后，直接拿这套评测集跑一遍，看哪个版本在哪些场景里实际提效最多。这样既不耽误现在的活儿，也为迁移做了准备，比到时候临时试 prompt 高效得多。
4.3 管理好预期：版本号变高，不等于所有问题自动消失
最后想说一句大实话。模型从老版本换成 5.5，能解决一部分问题，但很多“模型解决不了的”问题——比如糟糕的需求描述、不清晰的验收标准、没有上下文约束——升级之后依然存在。我用 Opus 5.5 测试一个很模糊的任务时，它的表现并没有比常用模型好到哪去。这说明什么？说明新模型更适合“你已经知道要什么”的场景，而不是“你希望它替你思考”的场景。
把预期调整好，才不会在一阵热闹过后，对新技术产生伤害性的失望。模型的进步是一步步来的，5.5 大概率比老版本强，但它不会替你定义问题。
我自己在这轮测试里最大的感受是：模型发布经常会制造一种“晚一步就落后”的紧张感，但实际上的竞争壁垒，从来不在“能不能第一时间用上某个模型”，而在于你有没有一套稳定的评测方法、一批可靠的业务数据、一份清晰的迁移清单。Opus 5.5 和 Sonnet 5.5 值得关注，但把基础设施和判断标准握在自己手里，才是更长期的事。先把手头能做的事做扎实，等到权限真正开放的时候，你比别人多出来的不只是体验资格，而是一套已经验证过的使用方案。
