我一直觉得，市面上的模型榜单有个很尴尬的地方：你盯着那个综合分数看了半天，最后还是说不清某个模型“拿来写方案到底好不好使”“被人怼两句会不会当场倒戈”。基准测试更像体育考试里的体测，能反映基础素质，可真实干活时拼的是对抗、应变、守不守得住自己的立场。所以我这次换了个玩法：搭了一场真正的“大模型辩论赛”，把 DeepSeek、Qwen、GLM 三个主流模型拉进同一个流程里，让它们围绕一个辩题轮番立论、互相质询、再做总结陈词。整场辩论的调度脚本跑在蓝耘的 GPU 云主机上，三个模型通过统一接口接入，吵了整整三个多小时。这篇文章我就把整套思路、代码、实测结果和踩过的坑完整地写出来。这套方案的成本很低，一个下午就能跑通。适合谁看？想对比大模型能力但又不想只看跑分的人、正在做模型选型的开发者、对多 Agent 对抗式应用感兴趣的技术爱好者，哪怕你是刚接触 API 调用的小白，照着这篇文章也能把“辩论赛”跑起来。1. 与其跑分，不如让模型当面对质：这个玩法到底在测什么先说动机。我一直觉得单轮问答式的评测有一个致命短板：它测的是模型“单兵作战”的能力，但人在真实使用 AI 时，面对的多半是连续对话、观点碰撞、被别人否定之后继续表达的复杂场景。你问“AI 会取代程序员吗”，它回答得再好，那也只是背答案；你让它听完另外两个模型的反对意见之后再组织第二轮的回应，它还能不能站稳脚跟，这才是真本事。辩论恰好是天然的对抗式评测。参与者需要做到几件事：理解并拆解对手的观点，组织反论据，守住自己的核心立场，同时还要保证表达的完整性和流畅度。这几个维度单靠跑分是看不出来的，跑分只能告诉你“谁的准确率高”“谁的向量相似度更接近标准答案”，却告诉不了你“谁更擅长应对压力”。具体来说，一场辩论能暴露的重要指标有这么几项：第一个是立场稳定性，模型被对方连续质询两次之后，会不会偷偷改变自己的观点；第二个是论据多样性，两个回合下来还在重复一样的事，说明模型的知识链很短；第三个是上下文记忆能力，它能不能在第三轮准确引用第一轮对手说过的话，这直接反映长对话能力；第四个是语言风格的个性差异，同样的辩题，DeepSeek、Qwen、GLM 三种不同的模型讲出来的味道完全是不同的，这个差异也恰恰影响你在实际应用里的“手感”。蓝耘这台云主机在这里起的作用，是保证一个公平的“比赛现场”。我对比模型时最怕变量不统一：网络延迟不一样、出口 IP 位置不一样、调用库版本不一样，结果就不可信。我把三个模型的 API 调用全部放在同一台蓝耘 GPU 实例上发出，统一用 OpenAI 兼容格式写请求，这样至少能保证比赛是在同一个“球馆”里打的，变量只剩下模型自身的参数和调参。从另一个角度看，辩论赛也是一种低成本的“模型压力测试”。你不用自己设计复杂数据集，不用打标注，只要准备一个辩题、几个人设提示词、一套循环调度脚本，就能让模型自己在对抗中把能力的边界暴露出来。这也是我强烈推荐大家去复现的原因：它门槛低、效果好、可观察性强。2. 环境准备：在蓝耘上让三个模型站到同一个“擂台”第一件事是准备算力。为什么要租云 GPU，而不是直接在本地跑？因为本地没有 A100/H100 这种级别的大卡，而跑大模型推理对显存的要求非常苛刻，显卡一到位，代码没到位，纯浪费时间。蓝耘的好处是按时计费、即开即用，可以按小时租一台带显卡的主机，跑完辩论就释放，成本完全可控。我没有选择本地部署开源模型，是因为这一次的目标是调用 DeepSeek、Qwen、GLM 三个商业模型的在线 API，重点是逻辑编排和应用层实现，不是部署运维层。模型接入方面，国内三个模型厂商都提供了 OpenAI 兼容的 API 接口，这意味着我的代码里不用为每家单独写 SDK，统一用 OpenAI 的 Python 库就能把三个模型全部接进来。这是整个项目能快速跑通的关键前提。三个模型的接入参数我整理成了常量配置，方便后面统一维护：模型接口地址调用模型名API Key 来源DeepSeekapi.deepseek.comdeepseek-chat环境变量 DEEPSEEK_API_KEYQwendashscope.aliyuncs.com/compatible-mode/v1qwen-plus环境变量 QWEN_API_KEYGLMopen.bigmodel.cn/api/paas/v4glm-4-plus环境变量 GLM_API_KEYAPI Key 我坚持只放到环境变量里，绝对不写进代码仓库，这也是一个最基本的工程卫生习惯。接下来是统一的客户端创建函数，代码如下：import os from openai import OpenAI def create_client(provider: str): config = { "deepseek": { "base_url": "https://api.deepseek.com", "model": "deepseek-chat", "api_key": os.environ["DEEPSEEK_API_KEY"], }, "qwen": { "base_url": "https://dashscope.aliyuncs.com/compatible-mode/v1", "model": "qwen-plus", "api_key": os.environ["QWEN_API_KEY"], }, "glm": { "base_url": "https://open.bigmodel.cn/api/paas/v4", "model": "glm-4-plus", "api_key": os.environ["GLM_API_KEY"], }, } c = config[provider] return OpenAI(base_url=c["base_url"], api_key=c["api_key"]), c["model"]这个函数的写法比较取巧：OpenAI 库不关心你连的是谁的服务器，只要地址兼容、Key 正确，它就能以完全一致的方式使用三家模型。这意味着后续所有辩论流程代码，根本不需要区分模型厂商，统一走一个 ask 函数就可以。这一步会大大减少后续编码的复杂度。再说说蓝耘这台主机的具体配置。我租的是带一块主流显卡的实例，装好 Python 3.10 和 openai 库就够了。因为所有请求都通过 HTTP 发出，实际上 GPU 在这里承担的计算任务很少，更多是作为一个稳定、统一网络的“调度中心”。这里大家不用盲目追求高配置，中等性价比的显卡实例就完全跑得动整个辩论流程。我当时选择的时候，主要比较过计费方式和网络稳定性，最终定下来是因为它提供小时级别计费，跑完即释放，不需要长期持有资产，非常适合这类临时实验。真正花时间的反而是后面的提示词设计。模型能力再强，提示词不给力，辩论赛也会变成三个复读机在互相客套。接下来的编排环节才是整篇文章最核心的部分。3. 辩论赛的编排逻辑：状态机、上下文管理和裁判系统这一部分决定辩论质量的高低。我把整个赛制设计成四个阶段：立论、自由辩一、自由辩二、总结陈词。每一轮让三个模型依次发言，每个模型发言时都能看到对手上一轮的最新发言，然后针对性地进行回应。核心难点有两个：一是上下文怎么管理，二是怎么防止模型变成“车轱辘话复读机”。先说上下文管理。大模型 API 有 Token 上限，我不能把整场辩论的历史全部塞进请求里，否则六七轮之后系统就会提示上下文超长。我的做法是给每个模型单独维护一个滑动窗口，只带最近两轮的全部发言，更早的就不带了。这样既保证模型能回应当前局面，又不会把 Token 撑爆。其次是防重复机制。我研究过很多辩论 Demo，最大的通病就是模型第二轮开始把第一轮的论点换了个说法重新输出，表面看一直在说话，实际没有任何新信息。为了压制这个现象，我在每一轮提示词里加了两条硬性约束：一是“禁止重复你之前已经表达过的论点”，二是“你必须直接引用并回应对手最近一次发言中的某个具体观点，不能泛泛而谈”。除了约束，我还给每个模型设置了一个固定的人设前缀，让风格差异更鲜明。DeepSeek 扮演冷静的深度分析者，要求逻辑严谨、结构化表达；Qwen 扮演全面客观的评审式选手，要求体系化梳理、注重证据；GLM 扮演语言犀利的交锋型辩手，要求表达生动、擅长抓对手漏洞。这个人设不是为了玩花样，而是为了让三个模型在自由表达的基础上带上可区分的识别特征，方便观察和评分。整个辩论流程的状态控制，用最简单的双层循环就能实现。外层循环控制回合数，内层循环遍历三个模型。下面是我当时跑的核心调度代码，为了可读性我做了一些精简：def run_debate(providers, topic): # 每个模型保存自己的上下文历史 histories = {p: [] for p in providers} # 阶段一：立论 for p in providers: prompt = build_prompt(p, "立论", topic) reply = ask(p, prompt, histories[p]) histories[p].append({"role": "user", "content": f"这是你的立论发言：{reply}"}) # 阶段二：自由辩论（两轮） for round_no in range(2): for p in providers: others = get_other_latest(histories, exclude=p) prompt = build_prompt(p, "自由辩", topic, others) reply = ask(p, prompt, histories[p]) histories[p].append({"role": "user", "content": f"你的第{round_no + 1}轮回应：{reply}"}) # 阶段三：总结陈词 for p in providers: prompt = build_prompt(p, "总结", topic) reply = ask(p, prompt, histories[p]) histories[p].append({"role": "user", "content": f"你的总结陈词：{reply}"}) return histories这里的 ask 函数会调用统一客户端，同时负责控制温度和最大生成长度等采样参数。温度我设置在 0.9，比日常问答的 0.7 要高。为什么？因为辩论需要观点发散，太低的温度会让模型倾向选择概率最高的表达，三个模型很容易说出高度相似的答案。高一点温度能提高论点的多样性，代价是会偶尔出现一些奇怪的表达，但在对抗场景里这点代价是值得的。系统架构里还有一个关键角色：裁判。我单独选了另一个模型，不参与辩论，只负责赛后打分。裁判提示词也花了不少心思，我要求它按照五个维度打分：论点清晰度、论据质量、逻辑自洽性、立场坚守能力、语言表达感染力。每个维度十分，总分五十分，最后还需要给出一段二百字以内的评语。为什么不直接让裁判评价“谁赢了呢”？因为“赢”这个标准太模糊，模型对模糊指令容易给出中庸的答案，最后全给七十多分。拆成五个明确的维度之后，模型才能给出有区分度的分数。这场辩论赛我分别跑了五组不同辩题，每组结果我都记录了完整对话和裁判评分，最后汇总出一个横向对比表。下一节我就拿其中一场具体的比赛做详细拆解。4. 现场实录：当三个模型围绕“AI 辅助编程会不会削弱程序员创造力”开吵这一节的辩题我选的是“AI 辅助编程是否会削弱程序员的创造力”，选它的原因是这个话题既有技术深度又贴近开发者日常，三个模型都会有丰富素材，不容易冷场。立论阶段，DeepSeek 是最早抛出一个清晰框架的。它把“创造力”拆成三层来谈：问题定义层面的创造力、方案设计层面的创造力、实现落地层面的创造力，然后逐一分析 AI 在每一层是补充还是替代。这个立论方式非常典型，逻辑链条完整，属于典型的深度分析型输出。Qwen 的立论则是另一条路：它先定义创造力的可量化维度，然后引用软件工程历史上类似的范式变化，最后给出“AI 是创造力的放大器而非替代者”的结论。结构上更像一份行业报告，证据意识很强，但缺少一点交锋的锋芒。GLM 的立论最不“正经”，它一上来就把矛头指向“程序员每天写重复代码的时间”，反问一句“当你不用再花时间补括号的时候，创造力是被削弱了还是被解放了”。这句话的表达效果相当好，典型的语言型选手风格。第一轮自由辩是真正的分水岭。DeepSeek 开始主动引用 Qwen 历史范式变化的论据，指出“每一次工具革命都伴随着对既有技能体系的冲击，但创造力转向了更高层级”，这个点接得非常准。Qwen 应对对手的方式是把话题重新拉回证据层面，强调“目前没有任何实证研究表明使用 AI 的开发者创新能力下降”。GLM 则抓到 DeepSeek 立论里的一个细缝，质疑“你把创造力分这么多层，是不是本身就预设了 AI 干预的合法性”。到了第二轮自由辩，我注意到一个很有价值的现象：Qwen 的发言有一半是在重复第一轮的框架，新信息密度明显下降。DeepSeek 则开始综合两个对手的观点做融合式回应，路径是“先承认 GLM 的反问有价值，再指出这个价值反而支持自己的框架”。这种处理方式是整场辩论里质量比较高的一次临场回应。总结陈词阶段，三个模型的风格差异也很明显。DeepSeek 的总结是理性派，重新收束到三层框架，强调 AI 让创造力上移。Qwen 的总结持平稳健，保持“放大器”的比喻，同时提醒关注技能重新分配的社会成本。GLM 的总结走的是情绪共鸣路线，用一句“工具从来没有杀死创造，它杀死的是重复劳动”收尾。站在旁观者角度，这一场辩论给我的直观感受是：分数最高的是 DeepSeek，因为它的论据组织和临场吸收能力最扎实；GLM 的表达最有记忆点，适合写在方案摘要里打动观众；Qwen 则稳定但略显保守，缺乏“意外之喜”。这种结论，光看榜单是得出来的。我把这一场的评分列表放在这里，方便大家直观感受：评分维度DeepSeekQwenGLM论点清晰度987论据质量976逻辑自洽性987立场坚守能力886语言表达感染力769总分（50分制）423735当然，单场得分会有随机波动，因为模型采样带温度，同一场比赛重跑一次结果可能有变化。我连续跑了五组不同辩题之后，得出一个更稳健的判断：DeepSeek 在逻辑复杂度和论证深度上稳定领先，GLM 的表达风格始终是三者里最有辨识度的，Qwen 则倾向平衡稳妥，很少翻车但也很少惊艳。接下来这一节，我把这些观察整理成对选型有实际价值的结论。5. 一场辩论暴露的模型“性格”，以及对选型的实际启示辩论赛相比普通评测，最大的优势是能把模型的“性格”逼出来。这种性格差异在平时单轮问答里不容易注意到，但在真实产品里会影响整个用户体验。第一个容易被观察到的差异是立场稳定性。比赛过程中，GLM 在遭到连续质询之后，出现过一次明显的“立场松动”，它原本坚持的观点在强反驳之后悄悄调成了“其实两边都有道理”。这种现象在辩论里叫立场漂移，放到实际业务场景里就变成了致命问题，比如你用模型做客服、做决策辅助，客户多问两三句它就动摇，那用户信任度会直接崩塌。相比之下，DeepSeek 和 Qwen 都能在对抗中守住原有框架，DeepSeek 是通过不断深化论证来防御，Qwen 是直接回到自己的证据体系里找依据。第二个差异是论据的“储蓄池”大小。我给同一个辩题跑了五轮，DeepSeek 每次都能换一个角度切入，比如历史视角、经济视角、教育视角、组织管理视角，说明它的知识链比较长，单次生成时能调用的知识面更广。Qwen 的表现也很稳，但更多是围绕行业案例和工程实践打转，角度相对集中。GLM 属于短打型，单点表达能力很强，但要从多个维度铺开去论证一个复杂命题的时候，深度会快速下降。第三个差异是语言风格。如果说 DeepSeek 像一个逻辑严谨的咨询顾问，Qwen 像一个有行业研究报告背景的分析师，那 GLM 更像一个懂传播的即兴演讲者。你需要正式严谨的输出，前两者更合适；你需要文案感强、能抓眼球的表达，GLM 的优势就很突出。这些差异落到选型上，我有几个非常实用的建议：如果你做的是知识问答、法律咨询、报告分析这类对逻辑要求极高的场景，DeepSeek 是首选，尤其在多轮对抗式追问下它的稳定性最强。如果你做的是企业级应用、客服辅助、标准化流程产出，Qwen 的稳健特性和较低幻觉倾向更加合适。如果你做的是营销文案、短视频脚本、面向 C 端用户的互动内容，GLM 的表达感染力会对转化率更友好。还有一个容易被忽略的点：模型之间的搭配使用。我在辩论赛里发现，三个模型的强项实际上是互补的。DeepSeek 负责深度分析，GLM 负责精彩表达，Qwen 负责稳证据查漏。如果你已经接入了一家模型，第二家可以做“交叉复核”，第三家可以做“对外包装”，多模型协作的价值在对抗场景里体现得比单人单模型要明显得多。现在很多团队在选型时被榜单上的总分牵着走，但总分是无数场景的平均值，具体到你自己的产品里，可能十个需求里有七个用不上那个平均优势。我建议所有人花一个下午跑一次这样的辩论赛，用你的真实业务题目让几个模型当面对质一次，选型结论会比看一百份评测报告都准。6. 搭建这套系统踩过的五个坑，以及绕开它们的方法下面这部分全是我现场实测时踩出来的，没有绕弯，按坑的严重程度来说。第一个坑是模型不按格式输出。我在设计裁判环节时，要求模型直接输出 JSON 格式的五维打分，结果三个模型里有两个偶尔会夹带一段解释性文字，导致 JSON 解析直接崩溃。解决方式是妥协：我放弃了纯 JSON 输出的幻想，改用“先输出五维分数表格，再单独输出评语”的宽松格式，同时配合正则解析。这里的经验是，对大模型不要提出过于严格的格式要求，它在长文本生成时很难完全遵守，你需要做的是格式的容错处理而不是让它“绝对听话”。第二个坑是上下文长度超限。第一版我贪心地把所有历史发言全部塞进请求里，跑到第三轮就开始报错。后来我把滑动窗口逻辑从“保留全部”改成“只保留最近两轮”，问题直接消失。数据实测下来，三模型、四阶段、每阶段三方的完整辩论历史，累计消耗的 Token 量接近两万个，如果全量塞进一轮请求，早就超出窗口限制了。第三个坑是模型重复发言。在自由辩第二轮，Qwen 回答时几乎复读了第一轮的核心句子。这个问题的根源是温度太低加提示词缺少防重复指令。我的解决方法是双管齐下：提示词里明确加“直接引用对手观点进行回应，并给出至少一个全新论点”，同时把温度从 0.7 上调到 0.9。实测效果很明显，复读现象大幅减少。第四个坑是立场漂移。GLM 在被我要求回应对手质询时，出现过话锋突转的情况。原因也好理解：当模型被放在“回应别人的反驳”这个位置时，它的默认倾向是保持对话和谐，不会太过激烈地对抗。我的做法是在每轮发言的提示词中加一句“你的目标是在这个辩题上获得胜利，不需要向对手妥协”，用人设把立场焊死。对抗类应用里，“目标导向”的提示词比“友好礼貌”的提示词更重要。第五个坑是裁判的评分不稳定。第一版裁判提示词是“请评价三方表现并选出胜者”，结果第二轮换辩题再跑时，裁判突然给出完全相反的获胜方。我复盘后发现原因在于评价标准被模糊掉了，裁判只能凭整体印象打。拆成五个维度并给出明确加权规则之后，裁判的输出稳定了很多，重跑同一场辩论，分数波动控制在合理范围内。这几个坑单独看都不大，但串在一起会非常消磨耐心。我建议第一次搭这套系统的人，先把流程骨架跑通，再加上防重复和裁判评分机制，不要一开始就追求完美。7. 这个“辩论赛”还能怎么玩：从评测工具到协作框架的几种延伸在我把整场辩论结果抛到团队群里之后，大家第一反应都是“这不只是评测，这也是个协作框架”。顺着这个思路，我整理了几种值得尝试的延伸用法。第一种是“交叉审查模式”。把一份方案同时丢给三个模型，让它们互相挑对方逻辑漏洞，最后输出各自的修改意见。这种模式比单模型自我检查要全面得多，因为模型之间的盲区是互补的。我用一个技术方案验证过，三个模型轮番修改之后，方案的可执行性描述比单模型版本明显更好，更像是“一个团队经过多轮评审后的产物”。第二种是“红蓝对抗安全评测”。让一个模型生成风险内容，另一个模型专门负责拆解、举报和反制。这种玩法可以用于近似评测模型的安全边界，比单纯跑安全测试用例更接近真实攻击场景。不过要提醒一句，这类测试只适合开发者在自己受控的环境中实验，要严格限制在合法合规的应用范围内。第三种是“品牌人格化测试”。如果你正在给产品做 AI 客服或虚拟人，你可以把竞争对手的模型请来当评委，让它们评价你选的模型“像不像一个真实的人”。在二次元社区做简单测试时，我意外发现这种玩法对判断 AI 的“性格魅力”很有参考价值，因为评委模型能捕捉到很多人工评测不容易注意到的表达细节。第四种是自动化迭代评测。把辩论赛脚本挂到定时任务里，每次某个模型发布新版本，就自动重跑同一组辩题，把裁判的评分历史和发言记录存下来做趋势分析。这套系统一旦搭好，以后模型升级到底变没变强、变的哪个方向，一眼就能看出来。我个人还有一个更轻量的玩法：不开辩论赛，只把三个模型的“立论阶段”跑出来并排放在一起，就能快速生成一个“多视角观点对比报告”。很多内容创作团队拿它做选题灵感，效果比单个模型穷举角度要好得多。讲到这里，这套基于蓝耘的“大模型辩论赛”系统从设计、实现到延伸应用已经全部覆盖了。最后再分享一个小技巧：辩论赛的辩题选择非常关键，尽量用你业务里真正需要决策的问题，而不是网上的热门口水话题。因为只有贴近真实场景的对抗，模型暴露出来的差异才能直接转化成你对技术选型的判断依据。按照这个思路去跑，你一定会比我更快得出属于自己的评测结论。
我一直觉得，市面上的模型榜单有个很尴尬的地方：你盯着那个综合分数看了半天，最后还是说不清某个模型“拿来写方案到底好不好使”“被人怼两句会不会当场倒戈”。基准测试更像体育考试里的体测，能反映基础素质，可真实干活时拼的是对抗、应变、守不守得住自己的立场。所以我这次换了个玩法：搭了一场真正的“大模型辩论赛”，把 DeepSeek、Qwen、GLM 三个主流模型拉进同一个流程里，让它们围绕一个辩题轮番立论、互相质询、再做总结陈词。整场辩论的调度脚本跑在蓝耘的 GPU 云主机上，三个模型通过统一接口接入，吵了整整三个多小时。这篇文章我就把整套思路、代码、实测结果和踩过的坑完整地写出来。这套方案的成本很低，一个下午就能跑通。适合谁看？想对比大模型能力但又不想只看跑分的人、正在做模型选型的开发者、对多 Agent 对抗式应用感兴趣的技术爱好者，哪怕你是刚接触 API 调用的小白，照着这篇文章也能把“辩论赛”跑起来。1. 与其跑分，不如让模型当面对质：这个玩法到底在测什么先说动机。我一直觉得单轮问答式的评测有一个致命短板：它测的是模型“单兵作战”的能力，但人在真实使用 AI 时，面对的多半是连续对话、观点碰撞、被别人否定之后继续表达的复杂场景。你问“AI 会取代程序员吗”，它回答得再好，那也只是背答案；你让它听完另外两个模型的反对意见之后再组织第二轮的回应，它还能不能站稳脚跟，这才是真本事。辩论恰好是天然的对抗式评测。参与者需要做到几件事：理解并拆解对手的观点，组织反论据，守住自己的核心立场，同时还要保证表达的完整性和流畅度。这几个维度单靠跑分是看不出来的，跑分只能告诉你“谁的准确率高”“谁的向量相似度更接近标准答案”，却告诉不了你“谁更擅长应对压力”。具体来说，一场辩论能暴露的重要指标有这么几项：第一个是立场稳定性，模型被对方连续质询两次之后，会不会偷偷改变自己的观点；第二个是论据多样性，两个回合下来还在重复一样的事，说明模型的知识链很短；第三个是上下文记忆能力，它能不能在第三轮准确引用第一轮对手说过的话，这直接反映长对话能力；第四个是语言风格的个性差异，同样的辩题，DeepSeek、Qwen、GLM 三种不同的模型讲出来的味道完全是不同的，这个差异也恰恰影响你在实际应用里的“手感”。蓝耘这台云主机在这里起的作用，是保证一个公平的“比赛现场”。我对比模型时最怕变量不统一：网络延迟不一样、出口 IP 位置不一样、调用库版本不一样，结果就不可信。我把三个模型的 API 调用全部放在同一台蓝耘 GPU 实例上发出，统一用 OpenAI 兼容格式写请求，这样至少能保证比赛是在同一个“球馆”里打的，变量只剩下模型自身的参数和调参。从另一个角度看，辩论赛也是一种低成本的“模型压力测试”。你不用自己设计复杂数据集，不用打标注，只要准备一个辩题、几个人设提示词、一套循环调度脚本，就能让模型自己在对抗中把能力的边界暴露出来。这也是我强烈推荐大家去复现的原因：它门槛低、效果好、可观察性强。2. 环境准备：在蓝耘上让三个模型站到同一个“擂台”第一件事是准备算力。为什么要租云 GPU，而不是直接在本地跑？因为本地没有 A100/H100 这种级别的大卡，而跑大模型推理对显存的要求非常苛刻，显卡一到位，代码没到位，纯浪费时间。蓝耘的好处是按时计费、即开即用，可以按小时租一台带显卡的主机，跑完辩论就释放，成本完全可控。我没有选择本地部署开源模型，是因为这一次的目标是调用 DeepSeek、Qwen、GLM 三个商业模型的在线 API，重点是逻辑编排和应用层实现，不是部署运维层。模型接入方面，国内三个模型厂商都提供了 OpenAI 兼容的 API 接口，这意味着我的代码里不用为每家单独写 SDK，统一用 OpenAI 的 Python 库就能把三个模型全部接进来。这是整个项目能快速跑通的关键前提。三个模型的接入参数我整理成了常量配置，方便后面统一维护：模型接口地址调用模型名API Key 来源DeepSeekapi.deepseek.comdeepseek-chat环境变量 DEEPSEEK_API_KEYQwendashscope.aliyuncs.com/compatible-mode/v1qwen-plus环境变量 QWEN_API_KEYGLMopen.bigmodel.cn/api/paas/v4glm-4-plus环境变量 GLM_API_KEYAPI Key 我坚持只放到环境变量里，绝对不写进代码仓库，这也是一个最基本的工程卫生习惯。接下来是统一的客户端创建函数，代码如下：import os from openai import OpenAI def create_client(provider: str): config = { "deepseek": { "base_url": "https://api.deepseek.com", "model": "deepseek-chat", "api_key": os.environ["DEEPSEEK_API_KEY"], }, "qwen": { "base_url": "https://dashscope.aliyuncs.com/compatible-mode/v1", "model": "qwen-plus", "api_key": os.environ["QWEN_API_KEY"], }, "glm": { "base_url": "https://open.bigmodel.cn/api/paas/v4", "model": "glm-4-plus", "api_key": os.environ["GLM_API_KEY"], }, } c = config[provider] return OpenAI(base_url=c["base_url"], api_key=c["api_key"]), c["model"]这个函数的写法比较取巧：OpenAI 库不关心你连的是谁的服务器，只要地址兼容、Key 正确，它就能以完全一致的方式使用三家模型。这意味着后续所有辩论流程代码，根本不需要区分模型厂商，统一走一个 ask 函数就可以。这一步会大大减少后续编码的复杂度。再说说蓝耘这台主机的具体配置。我租的是带一块主流显卡的实例，装好 Python 3.10 和 openai 库就够了。因为所有请求都通过 HTTP 发出，实际上 GPU 在这里承担的计算任务很少，更多是作为一个稳定、统一网络的“调度中心”。这里大家不用盲目追求高配置，中等性价比的显卡实例就完全跑得动整个辩论流程。我当时选择的时候，主要比较过计费方式和网络稳定性，最终定下来是因为它提供小时级别计费，跑完即释放，不需要长期持有资产，非常适合这类临时实验。真正花时间的反而是后面的提示词设计。模型能力再强，提示词不给力，辩论赛也会变成三个复读机在互相客套。接下来的编排环节才是整篇文章最核心的部分。3. 辩论赛的编排逻辑：状态机、上下文管理和裁判系统这一部分决定辩论质量的高低。我把整个赛制设计成四个阶段：立论、自由辩一、自由辩二、总结陈词。每一轮让三个模型依次发言，每个模型发言时都能看到对手上一轮的最新发言，然后针对性地进行回应。核心难点有两个：一是上下文怎么管理，二是怎么防止模型变成“车轱辘话复读机”。先说上下文管理。大模型 API 有 Token 上限，我不能把整场辩论的历史全部塞进请求里，否则六七轮之后系统就会提示上下文超长。我的做法是给每个模型单独维护一个滑动窗口，只带最近两轮的全部发言，更早的就不带了。这样既保证模型能回应当前局面，又不会把 Token 撑爆。其次是防重复机制。我研究过很多辩论 Demo，最大的通病就是模型第二轮开始把第一轮的论点换了个说法重新输出，表面看一直在说话，实际没有任何新信息。为了压制这个现象，我在每一轮提示词里加了两条硬性约束：一是“禁止重复你之前已经表达过的论点”，二是“你必须直接引用并回应对手最近一次发言中的某个具体观点，不能泛泛而谈”。除了约束，我还给每个模型设置了一个固定的人设前缀，让风格差异更鲜明。DeepSeek 扮演冷静的深度分析者，要求逻辑严谨、结构化表达；Qwen 扮演全面客观的评审式选手，要求体系化梳理、注重证据；GLM 扮演语言犀利的交锋型辩手，要求表达生动、擅长抓对手漏洞。这个人设不是为了玩花样，而是为了让三个模型在自由表达的基础上带上可区分的识别特征，方便观察和评分。整个辩论流程的状态控制，用最简单的双层循环就能实现。外层循环控制回合数，内层循环遍历三个模型。下面是我当时跑的核心调度代码，为了可读性我做了一些精简：def run_debate(providers, topic): # 每个模型保存自己的上下文历史 histories = {p: [] for p in providers} # 阶段一：立论 for p in providers: prompt = build_prompt(p, "立论", topic) reply = ask(p, prompt, histories[p]) histories[p].append({"role": "user", "content": f"这是你的立论发言：{reply}"}) # 阶段二：自由辩论（两轮） for round_no in range(2): for p in providers: others = get_other_latest(histories, exclude=p) prompt = build_prompt(p, "自由辩", topic, others) reply = ask(p, prompt, histories[p]) histories[p].append({"role": "user", "content": f"你的第{round_no + 1}轮回应：{reply}"}) # 阶段三：总结陈词 for p in providers: prompt = build_prompt(p, "总结", topic) reply = ask(p, prompt, histories[p]) histories[p].append({"role": "user", "content": f"你的总结陈词：{reply}"}) return histories这里的 ask 函数会调用统一客户端，同时负责控制温度和最大生成长度等采样参数。温度我设置在 0.9，比日常问答的 0.7 要高。为什么？因为辩论需要观点发散，太低的温度会让模型倾向选择概率最高的表达，三个模型很容易说出高度相似的答案。高一点温度能提高论点的多样性，代价是会偶尔出现一些奇怪的表达，但在对抗场景里这点代价是值得的。系统架构里还有一个关键角色：裁判。我单独选了另一个模型，不参与辩论，只负责赛后打分。裁判提示词也花了不少心思，我要求它按照五个维度打分：论点清晰度、论据质量、逻辑自洽性、立场坚守能力、语言表达感染力。每个维度十分，总分五十分，最后还需要给出一段二百字以内的评语。为什么不直接让裁判评价“谁赢了呢”？因为“赢”这个标准太模糊，模型对模糊指令容易给出中庸的答案，最后全给七十多分。拆成五个明确的维度之后，模型才能给出有区分度的分数。这场辩论赛我分别跑了五组不同辩题，每组结果我都记录了完整对话和裁判评分，最后汇总出一个横向对比表。下一节我就拿其中一场具体的比赛做详细拆解。4. 现场实录：当三个模型围绕“AI 辅助编程会不会削弱程序员创造力”开吵这一节的辩题我选的是“AI 辅助编程是否会削弱程序员的创造力”，选它的原因是这个话题既有技术深度又贴近开发者日常，三个模型都会有丰富素材，不容易冷场。立论阶段，DeepSeek 是最早抛出一个清晰框架的。它把“创造力”拆成三层来谈：问题定义层面的创造力、方案设计层面的创造力、实现落地层面的创造力，然后逐一分析 AI 在每一层是补充还是替代。这个立论方式非常典型，逻辑链条完整，属于典型的深度分析型输出。Qwen 的立论则是另一条路：它先定义创造力的可量化维度，然后引用软件工程历史上类似的范式变化，最后给出“AI 是创造力的放大器而非替代者”的结论。结构上更像一份行业报告，证据意识很强，但缺少一点交锋的锋芒。GLM 的立论最不“正经”，它一上来就把矛头指向“程序员每天写重复代码的时间”，反问一句“当你不用再花时间补括号的时候，创造力是被削弱了还是被解放了”。这句话的表达效果相当好，典型的语言型选手风格。第一轮自由辩是真正的分水岭。DeepSeek 开始主动引用 Qwen 历史范式变化的论据，指出“每一次工具革命都伴随着对既有技能体系的冲击，但创造力转向了更高层级”，这个点接得非常准。Qwen 应对对手的方式是把话题重新拉回证据层面，强调“目前没有任何实证研究表明使用 AI 的开发者创新能力下降”。GLM 则抓到 DeepSeek 立论里的一个细缝，质疑“你把创造力分这么多层，是不是本身就预设了 AI 干预的合法性”。到了第二轮自由辩，我注意到一个很有价值的现象：Qwen 的发言有一半是在重复第一轮的框架，新信息密度明显下降。DeepSeek 则开始综合两个对手的观点做融合式回应，路径是“先承认 GLM 的反问有价值，再指出这个价值反而支持自己的框架”。这种处理方式是整场辩论里质量比较高的一次临场回应。总结陈词阶段，三个模型的风格差异也很明显。DeepSeek 的总结是理性派，重新收束到三层框架，强调 AI 让创造力上移。Qwen 的总结持平稳健，保持“放大器”的比喻，同时提醒关注技能重新分配的社会成本。GLM 的总结走的是情绪共鸣路线，用一句“工具从来没有杀死创造，它杀死的是重复劳动”收尾。站在旁观者角度，这一场辩论给我的直观感受是：分数最高的是 DeepSeek，因为它的论据组织和临场吸收能力最扎实；GLM 的表达最有记忆点，适合写在方案摘要里打动观众；Qwen 则稳定但略显保守，缺乏“意外之喜”。这种结论，光看榜单是得出来的。我把这一场的评分列表放在这里，方便大家直观感受：评分维度DeepSeekQwenGLM论点清晰度987论据质量976逻辑自洽性987立场坚守能力886语言表达感染力769总分（50分制）423735当然，单场得分会有随机波动，因为模型采样带温度，同一场比赛重跑一次结果可能有变化。我连续跑了五组不同辩题之后，得出一个更稳健的判断：DeepSeek 在逻辑复杂度和论证深度上稳定领先，GLM 的表达风格始终是三者里最有辨识度的，Qwen 则倾向平衡稳妥，很少翻车但也很少惊艳。接下来这一节，我把这些观察整理成对选型有实际价值的结论。5. 一场辩论暴露的模型“性格”，以及对选型的实际启示辩论赛相比普通评测，最大的优势是能把模型的“性格”逼出来。这种性格差异在平时单轮问答里不容易注意到，但在真实产品里会影响整个用户体验。第一个容易被观察到的差异是立场稳定性。比赛过程中，GLM 在遭到连续质询之后，出现过一次明显的“立场松动”，它原本坚持的观点在强反驳之后悄悄调成了“其实两边都有道理”。这种现象在辩论里叫立场漂移，放到实际业务场景里就变成了致命问题，比如你用模型做客服、做决策辅助，客户多问两三句它就动摇，那用户信任度会直接崩塌。相比之下，DeepSeek 和 Qwen 都能在对抗中守住原有框架，DeepSeek 是通过不断深化论证来防御，Qwen 是直接回到自己的证据体系里找依据。第二个差异是论据的“储蓄池”大小。我给同一个辩题跑了五轮，DeepSeek 每次都能换一个角度切入，比如历史视角、经济视角、教育视角、组织管理视角，说明它的知识链比较长，单次生成时能调用的知识面更广。Qwen 的表现也很稳，但更多是围绕行业案例和工程实践打转，角度相对集中。GLM 属于短打型，单点表达能力很强，但要从多个维度铺开去论证一个复杂命题的时候，深度会快速下降。第三个差异是语言风格。如果说 DeepSeek 像一个逻辑严谨的咨询顾问，Qwen 像一个有行业研究报告背景的分析师，那 GLM 更像一个懂传播的即兴演讲者。你需要正式严谨的输出，前两者更合适；你需要文案感强、能抓眼球的表达，GLM 的优势就很突出。这些差异落到选型上，我有几个非常实用的建议：如果你做的是知识问答、法律咨询、报告分析这类对逻辑要求极高的场景，DeepSeek 是首选，尤其在多轮对抗式追问下它的稳定性最强。如果你做的是企业级应用、客服辅助、标准化流程产出，Qwen 的稳健特性和较低幻觉倾向更加合适。如果你做的是营销文案、短视频脚本、面向 C 端用户的互动内容，GLM 的表达感染力会对转化率更友好。还有一个容易被忽略的点：模型之间的搭配使用。我在辩论赛里发现，三个模型的强项实际上是互补的。DeepSeek 负责深度分析，GLM 负责精彩表达，Qwen 负责稳证据查漏。如果你已经接入了一家模型，第二家可以做“交叉复核”，第三家可以做“对外包装”，多模型协作的价值在对抗场景里体现得比单人单模型要明显得多。现在很多团队在选型时被榜单上的总分牵着走，但总分是无数场景的平均值，具体到你自己的产品里，可能十个需求里有七个用不上那个平均优势。我建议所有人花一个下午跑一次这样的辩论赛，用你的真实业务题目让几个模型当面对质一次，选型结论会比看一百份评测报告都准。6. 搭建这套系统踩过的五个坑，以及绕开它们的方法下面这部分全是我现场实测时踩出来的，没有绕弯，按坑的严重程度来说。第一个坑是模型不按格式输出。我在设计裁判环节时，要求模型直接输出 JSON 格式的五维打分，结果三个模型里有两个偶尔会夹带一段解释性文字，导致 JSON 解析直接崩溃。解决方式是妥协：我放弃了纯 JSON 输出的幻想，改用“先输出五维分数表格，再单独输出评语”的宽松格式，同时配合正则解析。这里的经验是，对大模型不要提出过于严格的格式要求，它在长文本生成时很难完全遵守，你需要做的是格式的容错处理而不是让它“绝对听话”。第二个坑是上下文长度超限。第一版我贪心地把所有历史发言全部塞进请求里，跑到第三轮就开始报错。后来我把滑动窗口逻辑从“保留全部”改成“只保留最近两轮”，问题直接消失。数据实测下来，三模型、四阶段、每阶段三方的完整辩论历史，累计消耗的 Token 量接近两万个，如果全量塞进一轮请求，早就超出窗口限制了。第三个坑是模型重复发言。在自由辩第二轮，Qwen 回答时几乎复读了第一轮的核心句子。这个问题的根源是温度太低加提示词缺少防重复指令。我的解决方法是双管齐下：提示词里明确加“直接引用对手观点进行回应，并给出至少一个全新论点”，同时把温度从 0.7 上调到 0.9。实测效果很明显，复读现象大幅减少。第四个坑是立场漂移。GLM 在被我要求回应对手质询时，出现过话锋突转的情况。原因也好理解：当模型被放在“回应别人的反驳”这个位置时，它的默认倾向是保持对话和谐，不会太过激烈地对抗。我的做法是在每轮发言的提示词中加一句“你的目标是在这个辩题上获得胜利，不需要向对手妥协”，用人设把立场焊死。对抗类应用里，“目标导向”的提示词比“友好礼貌”的提示词更重要。第五个坑是裁判的评分不稳定。第一版裁判提示词是“请评价三方表现并选出胜者”，结果第二轮换辩题再跑时，裁判突然给出完全相反的获胜方。我复盘后发现原因在于评价标准被模糊掉了，裁判只能凭整体印象打。拆成五个维度并给出明确加权规则之后，裁判的输出稳定了很多，重跑同一场辩论，分数波动控制在合理范围内。这几个坑单独看都不大，但串在一起会非常消磨耐心。我建议第一次搭这套系统的人，先把流程骨架跑通，再加上防重复和裁判评分机制，不要一开始就追求完美。7. 这个“辩论赛”还能怎么玩：从评测工具到协作框架的几种延伸在我把整场辩论结果抛到团队群里之后，大家第一反应都是“这不只是评测，这也是个协作框架”。顺着这个思路，我整理了几种值得尝试的延伸用法。第一种是“交叉审查模式”。把一份方案同时丢给三个模型，让它们互相挑对方逻辑漏洞，最后输出各自的修改意见。这种模式比单模型自我检查要全面得多，因为模型之间的盲区是互补的。我用一个技术方案验证过，三个模型轮番修改之后，方案的可执行性描述比单模型版本明显更好，更像是“一个团队经过多轮评审后的产物”。第二种是“红蓝对抗安全评测”。让一个模型生成风险内容，另一个模型专门负责拆解、举报和反制。这种玩法可以用于近似评测模型的安全边界，比单纯跑安全测试用例更接近真实攻击场景。不过要提醒一句，这类测试只适合开发者在自己受控的环境中实验，要严格限制在合法合规的应用范围内。第三种是“品牌人格化测试”。如果你正在给产品做 AI 客服或虚拟人，你可以把竞争对手的模型请来当评委，让它们评价你选的模型“像不像一个真实的人”。在二次元社区做简单测试时，我意外发现这种玩法对判断 AI 的“性格魅力”很有参考价值，因为评委模型能捕捉到很多人工评测不容易注意到的表达细节。第四种是自动化迭代评测。把辩论赛脚本挂到定时任务里，每次某个模型发布新版本，就自动重跑同一组辩题，把裁判的评分历史和发言记录存下来做趋势分析。这套系统一旦搭好，以后模型升级到底变没变强、变的哪个方向，一眼就能看出来。我个人还有一个更轻量的玩法：不开辩论赛，只把三个模型的“立论阶段”跑出来并排放在一起，就能快速生成一个“多视角观点对比报告”。很多内容创作团队拿它做选题灵感，效果比单个模型穷举角度要好得多。讲到这里，这套基于蓝耘的“大模型辩论赛”系统从设计、实现到延伸应用已经全部覆盖了。最后再分享一个小技巧：辩论赛的辩题选择非常关键，尽量用你业务里真正需要决策的问题，而不是网上的热门口水话题。因为只有贴近真实场景的对抗，模型暴露出来的差异才能直接转化成你对技术选型的判断依据。按照这个思路去跑，你一定会比我更快得出属于自己的评测结论。