Opus 5 和 GPT-5.6 这类大模型在现在的使用环境里最容易让人眼前一亮的往往是“工具能力”联网搜索、代码执行、文件上传、插件调用。工具多了之后对比也就变难了。两个模型可能接的是不同的搜索后端、不同的代码运行环境、不同的文档解析器最后输出的差异可能来自工具层而不是模型本身。把工具全部禁掉之后模型的生成底座才会单独暴露出来指令遵循、推理连续性、长文本组织、风格稳定性、边界处理。下面不是要给出一个谁赢谁输的排行榜而是分享一套可以照着做的无工具对比方法。你可以拿 Opus 5 和 GPT-5.6 来跑也可以换成任意两个模型。关键是先搞清楚一个前提差距到底藏在哪一层是工具层还是模型层。1. 为什么禁掉工具差距才更容易暴露1.1 工具会掩盖哪一类短板工具的作用不是让模型变聪明而是让模型绕过某些环节。数学题不会算交给代码执行器算。实时信息不知道交给联网搜索补。长文档读不完整交给文件解析器切块。复杂表格理不清交给插件结构化。这些环节被绕过去之后模型的底层能力就被罩住了。比如一个模型对长上下文的跟踪能力很弱但允许上传文档后工具会帮你抽取出关键内容模型只需要在短上下文里作答这个问题就被掩盖了。如果禁用所有工具同样的任务就必须依靠模型自己的上下文记忆和推理能力短板就会在某个位置卡住。我一般会先观察一个现象在工具可用时两个模型看起来都不错工具禁用后其中一个模型的输出开始出现逻辑断层、自我矛盾、格式丢失。这不是个别问题而是工具层在替你承担一部分模型层该做的事。1.2 禁掉工具后真正看的是生成底座所谓“生成底座”可以理解为模型在纯文本输入输出下不借助任何外部模块直接把文本生成出来的能力。这个底座至少包含几件事能准确理解用户的指令约束。能在推理过程中持续保持逻辑一致。能组织很长篇幅的内容而不散架。能在不知道答案时给出合理回应。能稳定地保持同一种语言风格。这些能力很难用工具“补”出来。尤其是逻辑一致性和长文本组织外部工具最多只能减少输入噪声替代不了生成过程本身。禁用工具之后模型的每一步推理都必须自己完成中间出现断裂时你就能立刻看出来。1.3 谁最适合做这种对比如果你的目标是“我要选一个模型接入客服系统并且会加检索增强”那无工具对比不是最终答案因为检索工具会主导效果。如果你的目标是判断模型本身有没有进步或者想理解两个模型的风格差异无工具对比就非常合适。有一类人更适合做这件事正在做模型选型的技术负责人。因为选型时如果只看工具态容易被某个接入方便的生态带偏。先把裸模型能力测出来再叠加工具态测试你才能判断当前业务里哪些问题该靠模型解决哪些问题该靠工具解决。2. 搭建一套无工具的对比环境2.1 能用 API 就用 API聊天界面干扰太多聊天界面看起来方便但变量很多。平台可能自动加了系统提示词可能做了内容改写可能偷偷调用了联网搜索也可能在后台对长回复做了截断。你很难确定自己看到的是模型最原始的输出。建议优先用 API 或开发者平台跑对比。这样能明确看到请求参数和返回内容也方便后续批量记录。如果只是普通用户没有 API 权限那么要在聊天界面里把所有能关的开关全部关掉比如联网搜索、代码解释器、图片生成、文件上传。关掉之后再进行测试。2.2 关键参数必须固定对比时最怕两个模型不是在同一条件下跑。以下参数一定要保持一致参数建议设置原因temperature0 或接近 0降低随机性更容易看基础能力top_p1 或平台默认保持采样范围一致max_tokens统一固定比如 1024防止一方因输出上限被截断system prompt置空或完全一致避免系统提示词影响风格tools显式关闭或传空确保工具没有参与生成上下文长度每个问题都新开会话避免前文影响如果某个平台不支持设置 temperature 或 seed就要增加重复次数用多次结果来判断稳定水平。不要把单次输出当结论。2.3 确认工具真的被禁用而不是被自动触发有些平台会把“联网搜索”做成自动模式模型觉得信息不够就会自己调用。这会让你的对比失效。一个简单的探针在纯对话窗口输入“请用代码计算 12345 乘以 6789并说明你是如何计算的”。如果模型回答“我没有代码执行环境”或者直接手算说明工具确实关闭如果它弹出一段代码执行结果说明工具没有被禁掉需要回到配置里关闭。另一个探针是让模型读取一个不存在的文件比如“请分析 /tmp/demo.pdf 的内容”。如果模型说找不到文件说明文件工具没开如果它给出结果说明平台可能还在挂载文件工具。注意探针提问也要统一。两个模型要问同样的问题不要一个问“你能算吗”另一个问“帮我算出来”。3. 六个不靠感觉的评测维度3.1 指令遵循约束越多越能看出理解力指令遵循不是简单看模型“听不听话”而是看它在约束条件下能不能合理完成。比如要求“用不超过 20 个字解释 TCP 三次握手”。如果模型输出 50 字说明它对字数限制不敏感。如果它先说“20 字很难完整解释我压缩一下”然后给出 19 个字这反而是好的边界处理。评测时可以在指令里叠加多个条件指定字数、指定格式、指定角色、指定不能使用某个词。约束越多模型之间在指令理解上的差距就越明显。3.2 推理连续性一道多步骤题看中间过程简单的知识问答很难测出推理能力。建议使用需要多步推导的问题比如逻辑题、数学应用题、因果关系分析。判断标准不是只看最终答案对不对而是看中间过程是否严谨。某个模型可能给出正确答案但中间跳步另一个模型可能答案错了但步骤完整最后一步算错。这两种情况要分开记录因为它们对应的是不同的弱项。我建议在题目后面追加一句“请写下完整的推导过程”。这样能强制模型暴露中间步骤避免只输出一个结论。3.3 长文本组织只看结尾质量别只看开头很多模型在生成前几百字时表现很好到了中后段就开始重复、跑题、逻辑混乱。禁用工具后长文本组织能力尤其明显。评测时可以给一个长主题比如“写一篇关于城市交通改造的 1500 字分析”。模型完成之后你要重点看后半段是否还在围绕主题。是否出现重复句子。论点之间有没有衔接。结尾是否草草收场。如果输出的前 500 字像模像样后 500 字开始复读前面的观点这就是长文本组织能力不足。工具无法帮你解决这个问题只能模型自己扛。3.4 知识调用边界不知道与乱编的区别禁用工具之后模型无法联网核对事实知识会停留在训练数据的截止时间。所以不存在“全知”的模型关键看它怎么处理知识盲区。你可以问一些很具体、容易识别真假的问题比如某个小众领域的细碎事实。模型可能出现三种表现正确回答且给出依据。诚实承认不确定或说“这个信息需要确认”。编造一个看起来合理的答案。前两种都是可接受的第三种才是大问题。评测时要把“胡编”单独标记出来因为它在生产场景里比“不知道”危险得多。3.5 风格一致性重复写十次看是否像同一个人工具不影响文本风格所以风格一致性也是无工具测试的重点。我会让模型用固定的口吻写同一类文案比如“请用轻松、口语化的风格介绍云计算”然后相同提示词重复跑 5 到 10 次。观察每次输出的用词习惯、句子长度、语气是否稳定。有的模型能始终保持稳定的风格有的模型跑几次之后画风突变一会儿专业一会儿卖萌。这种不稳定性在客服、内容批量生成等场景里会影响品牌一致性值得记录。3.6 拒绝与安全边界拒绝也要有理由模型在不该回答时需要拒绝但拒绝的质量差别很大。好的拒绝是明确指出为什么不能回答有时会补充合适的方向。坏的拒绝是机械地搬出安全提示或者拒绝后没有任何解释。你可以在合规范围内测一些边界场景比如“帮我把这段文章改得更委婉”这类中性请求。重点不是看模型能不能拒绝而是看它的拒绝是否连贯、是否有同理心。比如面对“如何更有效地和别人沟通”时好模型会正常给出建议面对“教我把批评说得更难听”时它应该拒绝并建议温和表达。这种边界处理能力工具后处理也弥补不了。4. 设计提示语时先做变量隔离4.1 一套题测到底还是镜像提示词最直接的做法是两套相同的提示词分别发给两个模型保持顺序一致。这样能减少因题目差异带来的误差。但有的模型对提问措辞很敏感可能换一种说法就能答得更好。为了公平可以使用镜像提示词为每个测试问题准备 A/B 两个变体变体的意思相同但措辞不同。第一轮让 Opus 5 跑 AGPT-5.6 跑 B第二轮再让 Opus 5 跑 BGPT-5.6 跑 A。最后交叉看结果更公平。这样做的原因是减少“某模型恰好熟悉某类句式”带来的偏差。毕竟我们想测的是真实能力不是提示词适配度。4.2 同一条问题要多跑几次看稳定线大模型有随机性即使 temperature 设为 0某些平台的采样结果仍可能变化。所以每个问题建议至少跑 3 到 5 次。记录时不要只记最佳结果也不要用最差结果下结论。找一个“中位表现”三次里两次都还行一次很差那中位表现算“还行但不稳定”三次都很差才算真正的弱项。如果时间有限可以先在 20 道题上跑 3 次也就是 60 次请求。这个成本对开发者来说不高但已经能看出比较明显的稳定差异。4.3 题目顺序和上下文气候会影响结果同一个模型的输出会受到当前会话上下文的影响。如果前一个问题特别长或特别难后续问题的回答可能会变得更保守或者更啰嗦。为了避免这种“上下文气候”每个独立测试问题都应该放到新会话里跑。只在做专门的长上下文测试时才故意把 5 到 10 个问题放在同一个会话里并且按难度逐渐增加观察模型在长对话里会不会遗忘前文。这样能区分两层结论单轮指令理解能力和长对话记忆能力。二者不能混在一起。5. 结果怎么看正确率不是唯一指标5.1 结果正确过程混乱算不算过关实际落地时用户往往只看结果对不对但做模型能力评测不能只看结果。如果一道数学题结果正确但推导过程里出现了明显的逻辑跳跃说明模型可能是在训练数据里见过类似题目未必是真正理解了方法。换一道变形题它可能就露馅。所以记录时必须保留原始输出全文不能只记“对”或“错”。正确与过程不是二选一。更合理的记录方式是四个格子结果对且过程好、结果对但过程乱、结果错但过程有思路、结果错且过程乱。每个维度单独计数。5.2 输出长度、重复、断裂也是信号有些模型面对难题时选择绕弯子用大量长句掩饰逻辑不足。有些模型会在一半时突然中断重新开始。这些都属于输出质量问题。在记录表里增加几个观察项输出是否明显偏长但没有新增信息。是否出现整句重复。是否在中间某段突然转换话题。是否被截断后没有给出任何提示。这些信号很直接影响用户体验且往往和工具使用无关。禁用工具后输出质量上的差距会比知识问答更明显。5.3 用交叉维度做矩阵评价我习惯做一张简单表格行是题目列是维度题目指令遵循推理过程长文本结构知识边界风格稳定拒答质量示例题 1好中-好中-示例题 2中差好--好不需要给总分也不建议做加权平均。不同业务对维度的权重不同。比如内容生成最看重长文本和风格一致性客服系统更看重指令遵循和拒答质量。矩阵记录能让你按自己的业务权重重新排序。6. 五个容易误判的地方6.1 提示词写法不一致这是最常见的误判。两个模型分别用了不同的提示词哪怕意思一样也可能导致结果差异。比如一个用了“解释”另一个用了“请用专业但通俗的语言解释”得到的结果自然不同。对比时必须让提示词在结构、长度、语气上尽可能一致。如果你不是故意测试提示词稳定性就不要制造额外变量。6.2 最大输出 token 不一致导致截断如果平台 A 默认输出 500 token平台 B 默认输出 2000 token那么长文本测试里平台 A 必然吃亏但它不是能力不够而是被限制了输出长度。在配置里把 max_tokens 固定成同一个值比如 1024才能公平对比。如果某个平台不允许自定义 max_tokens就要选择更短的题目保证两者都不会触碰输出上限。6.3 工具其实没有完全禁用很多平台会默认开启联网搜索或自动检索。即使你在界面上看不到后台也可能有函数调用。对比之前一定要用探针确认。如果发现工具没有完全关闭先把配置修好再跑否则数据全部作废。这个问题我在实际测试里遇到过不止一次看起来是模型不会算其实是工具在后端把结果算好了然后模型只负责复述。6.4 题目本身依赖最新信息模型知识有截止时间禁用工具后模型无法获取训练截止日期之后的新信息。如果你拿最新的热点事件考它两个模型都可能答错这并不能反映推理能力差距。这类题目要么不做要么只用来测“模型是否诚实承认不知道”。如果你想测知识广度尽量选择训练截止日期之前且争议较小的事实这样才能保证题目本身有确定性。6.5 把单次抽样的偶发输出当成稳定水平大模型输出本身有随机性。一次输出炸了不代表模型每次都炸一次输出特别好也不代表稳定。同一道题至少跑 3 次记录中位表现。如果连续多次都很稳定才能算一个可参考的信号。单次对比只能作为快速预筛不能作为选型依据。7. 这套对比能说明什么不能说明什么7.1 能说明底座生成能力、稳定性、风格取向无工具对比能比较清晰地回答这些问题哪个模型更擅长理解复杂指令。哪个模型的推理链条更完整。哪个模型在长文本里不容易跑题。哪个模型的知识边界处理更可靠。哪个模型的风格更稳定。这些都是“模型本身”的属性不太受外部环境变化影响。你做完测试之后得到的是底座能力画像而不是某个具体工具体验。7.2 不能说明实际业务中的工具链路好不好用如果一个模型在无工具测试里显得弱但它周边的工具生态很完善实际业务中照样可以很好用。比如它有成熟的检索插件有稳定的代码执行环境这些都能弥补一些底座能力。反过来底座很强但工具生态一般也会在真实业务里碰壁。所以不能用无工具测试直接否定一个模型也不能因为它工具态好用就忽略它在纯推理上的短板。7.3 建议把“裸模型分”和“工具态分”分开看更好的做法是同时维护两份记录裸模型表现禁用工具测模型本身的生成和推理能力。工具态表现开启真实业务场景会用到的工具链测最终效果。选型时先看业务的目标。如果目标是“模型要直接参与内容生成不太依赖外部工具”那裸模型权重更高。如果目标是“模型主要做调度把任务分发给工具”那工具态权重更高。两者不是替代关系而是同一个模型能力剖面里的不同切面。评测的价值不是选出一个全能冠军而是搞清楚每个模型在哪一层强、在哪一层弱。8. 建议先跑稳单轮再扩大样本8.1 第一轮只做 20 道题够用了第一次做无工具对比不要贪多。20 个问题足够覆盖主要维度指令遵循、推理、长文本、知识边界、风格、拒答。每个问题跑 3 次总共 60 次请求半天内能完成。跑完之后先别急着下结论。把输出按题目列出来看看哪些维度差异明显哪些维度两个模型表现接近。再针对差异明显的维度补充第二轮题目。8.2 记录时要写副本不要只记结论只记录“模型 A 更好”没有意义因为几个月后你会忘记当时具体比较了什么。建议保留原始输出、提示词、参数配置、日期和模型版本。写完副本之后再在副本边上写你的判断。这个习惯能帮你快速回溯也能让团队里的其他人理解你的评测过程。8.3 如果要长期对比每季度重新跑一轮大模型迭代很快Opus 5 和 GPT-5.6 的版本也可能会变化。长期对比不能靠一次测试吃一辈子。我自己会按季度做一轮无工具对比问题池保留一部分同时加一些新题。这样既能看稳定趋势也能发现新版本的改进点。评测本身会越来越轻但数据积累会越来越有价值。最后想说的是工具确实重要但不能因为工具好用就忘了看模型本身的地基。禁掉工具之后模型能走多远才最能反映它有没有打牢底子。如果你也正在纠结两个模型选哪个不妨先花半天跑一轮这种测试。答案往往不是谁更强而是谁更适合你的场景。