首页/AI专区/OpenRouter Fusion 适合做工程交付主力吗？我的判断：Plan 很强，但不建议拿来独立开发部署

OpenRouter Fusion 适合做工程交付主力吗？我的判断：Plan 很强，但不建议拿来独立开发部署

admin2026/8/13阅读 0AI专区OpenRouter Fusion工程交付AI模型评测多模型协同技术方案
AI 摘要 / TL;DR

针对OpenRouter Fusion在完整工程交付任务中的实测，结果显示其需求理解和功能设计（Plan阶段）表现优秀，但在开发、测试、部署等执行环节稳定性差，综合分137/200排名第7，建议仅用于计划阶段辅助，不适合独立开发部署。

先说结论：如果你的目标是完整工程交付，OpenRouter Fusion 目前还不适合当主力开发模型。

很多人测评大模型还在比“谁代码写得快”“谁算法题得分高”，但真实开发里，需求理解、测试补全、Docker 部署、云端验收这些脏活累活，才是决定你能不能下班的关键。

这次优刻得技术研究院把 OpenRouter Fusion 丢进一个真实工程任务，要求它从需求分析一路干到 UCloud 公网验收。测完之后我的建议是：如果你要的是完整工程交付，而不是几段能跑的 Demo，别把它当主力。

在这次测试里，OpenRouter Fusion 的综合分是 137/200，在 8 个模型中排名 第 7，只比 Kimi K2.6 高 1 分。

但这个分数不能简单理解为“Fusion 不行”。更准确地说，它是一个很典型的“Plan 强、Build 弱”的模型组合方案：

  • 需求理解：20/20
  • 功能设计：20/20
  • 但前端、后端、测试、问题处理、代码质量、部署阶段明显下滑
  • 总耗时 4h46m34s，是本轮最长
  • 开发阶段被拆成 18 段，需要人工续跑
  • 出现 Expected 'id' to be a string 这类工具调用错误
  • 人工验收发现 3 个程序 Bug
  • 最终部署偏离原始 Docker Compose 三服务要求

一、问题背景：为什么会测 Fusion？

这次测评对象是 OpenRouter Fusion API，测试工具是 opencode。

选它进行这次实测，理由很直接：OpenRouter 给 Fusion 的定位是"市面上最智能的复合模型"，官方号称靠多模型并行+裁判聚合，能以半价达到甚至超越 Fable 5 的水平。 这套话术在技术社区讨论度很高，但已有的公开评测基本集中在深度研究、文档问答这类"动动嘴皮子"的任务上，真正把它拉进完整工程交付链路（写代码、跑测试、做部署）的实测非常少见。

而 Fusion 的核心卖点恰恰是"不同模型互相补短板"。如果这套逻辑成立，它最该发挥优势的战场不是做几道题，而正是像 FlowTask 这样需要长链路执行、多环节协同的真实工程项目。 所以我们把它扔进了 opencode 的测试场，用 TeamTask-Board 这个全栈项目，验一验它到底是能扛活的"团战"架构，还是只擅长纸上谈兵的"参谋"模型。

任务不是简单问答，而是一个完整工程交付项目：FlowTask / TeamTask-Board 团队任务看板系统。

任务链路包括：

  1. 需求分析
  2. 技术方案设计
  3. 前后端开发
  4. 自动化测试
  5. UCloud 云端部署
  6. 公网验收
  7. Bug 修复

也就是说，这不是“让模型写一段代码”那么简单，而是模拟一个相对真实的工程交付过程。

本次 Fusion 配置如下：

{
  "model": "openrouter/fusion",
  "tool_choice": "required",
  "plugins": [
    {
      "id": "fusion",
      "analysis_models": [
        "moonshotai/kimi-k2.6",
        "deepseek/deepseek-v4-pro",
        "qwen/qwen3.7-max"
      ],
      "model": "deepseek/deepseek-v4-pro"
    }
  ]
}

其中：

角色模型
analysis modelKimi K2.6
analysis modelDeepseek V4 Pro
analysis modelQwen3.7 Max
judge / final modelDeepseek V4 Pro

这里的 OpenRouter Fusion，可以理解为 OpenRouter 提供的一种多模型协同机制：多个 analysis models 先并行分析，再由 judge / final model 汇总、判断并输出。

而 UCloud 在本文中指的是本次工程任务的云端部署环境。原始要求是把团队任务看板系统部署到 UCloud 云端，并按指定方案完成公网访问与验收。

二、核心痛点：Fusion 的问题不是不会想，而是不好稳定执行

如果只看 Plan 阶段，Fusion 表现其实不错，甚至可以说很强。

它在需求理解和功能设计上都拿了满分：

阶段满分得分说明
需求理解 RU2020Plan 文档完整覆盖实体、字段约束、权限、状态机、筛选、日历和 UCloud 部署要求
功能设计 FD202012 个 API、E2E-0115、UT-0121 设计完整

但问题出现在后半段：真正要写代码、调试、部署、验收时，Fusion 的稳定性和工程闭环能力开始明显下降。

本轮核心数据如下：

指标结果
综合分137/200
排名8 个模型中第 7
质量分8/20
实际费用¥279.53
美元费用$39.26
汇率口径1:7.12
Token 总数46.15M
对话消息总次数264
assistant 总消息数235
需求分析 assistant 消息数1
开发阶段 assistant 消息数234
总耗时4h46m34s
需求阶段耗时12min23s
开发阶段耗时4h34m11s
人工续跑 / 中断恢复次数18
人工验收程序 Bug3
Fusion 服务稳定性问题3
开发自修 Bug12

我在看这组数据时，最关注的不是单一分数，而是几个信号：

  1. 开发阶段 assistant 消息数达到 234 条，说明执行链路很长。
  2. 18 次人工续跑 / 中断恢复，说明它很难保持连续推进。
  3. 总耗时 4h46m34s，是本轮 8 个模型中最长。
  4. 真实验收仍有核心 Bug，说明测试和自修没有把问题挡住。
  5. 部署形态偏离原要求，说明它最后更像“绕过去了”，而不是“按要求交付了”。

三、不同方案对比：Fusion 并没有因为“多模型”而超过单模型强者

企业做模型选型时，不能只看概念。Fusion 的卖点是多模型协作，但真正落到工程交付上，要看质量、耗时、费用、人工介入和验收结果。

本轮 8 个模型对比如下：

排名模型综合分费用（¥）Token总耗时人工介入/续跑人工验收问题数结论
1GLM 5.2189/20050.7416.62M1h55m25s02综合最优，费用低，交付稳定
2Claude Opus 4.8186/200808.1819.82M1h28m09s01自主完成度好，但价格最高
3ChatGPT 5.5182/200223.0111.16M1h41m03s12质量和费用较平衡
4GLM 5.1151/20063.7121.38M1h31m45s23成本低，但前端问题明显
5Qwen3.7 Max148/200148.2724.93M1h54m34s23设计较完整，部署后核心功能有问题
6Deepseek V4 Pro146/20039.7049.23M2h43m43s45费用最低，但实际 Bug 多
7OpenRouter Fusion137/200279.5346.15M4h46m34s183Plan 强，但开发慢、中断多、交付 Bug 明显
8Kimi K2.6136/20042.4523.76M3h43m37s34部署和资源治理风险突出

几个直接结论：

  • Fusion 费用 ¥279.53，高于 ChatGPT 5.5 的 ¥223.01，但综合分低 45 分。
  • Fusion 费用约为 GLM 5.2 的 5.5 倍，但综合分低 52 分。
  • Fusion Token 为 46.15M，接近 Deepseek V4 Pro 的 49.23M，但得分更低、费用更高、耗时更长。
  • Fusion 人工续跑 18 次，是非常明显的稳定性信号。

所以，我不会把这次结果解读为“多模型一定更强”。至少在这个工程任务里，结论恰好相反：

多模型分析提升了方案完整度，但没有自动提升工程交付质量。

四、为什么我不建议用 Fusion 做长链路开发主力？

1. Fusion 的定位更像评审委员会，不像全栈执行者

根据原文引用的 OpenRouter Fusion 官方文档，Fusion 更适合在单模型不足时做多模型并行分析，再由 judge 模型比较结果。它适合研究、专家批判、多视角分析。

但这次任务不是单轮研究，而是完整工程交付：

  • 生成方案
  • 写前后端代码
  • 写测试
  • 本地调试
  • 创建 UCloud 资源
  • SSH 部署
  • 处理 Docker / 网络 / 防火墙问题
  • 公网验收
  • 修 Bug

这类任务最需要的是：

  • 连续执行能力
  • 工具调用稳定性
  • 对代码状态的持续记忆
  • 对错误的快速闭环
  • 对部署环境的持续跟踪

Fusion 的机制更像“几个人开会给意见”，但最终真正落代码、调环境、修 Bug 的仍然是一个执行链路。开会开得好，不代表交付一定稳。

2. 多模型投票不等于代码正确

Fusion 的 panel 模型可以并行给出分析意见，judge 可以比较这些意见，final model 可以整理输出。

但工程交付有几个现实问题：

  • panel 模型不一定能持续看到真实文件系统变化。
  • judge 负责比较方案，不负责逐行验证代码。
  • 最终写代码的仍然是一个模型，不是多个模型共同维护代码状态。
  • 多模型建议可能增加上下文噪声，让执行路径更长。

这也是为什么它 Plan 阶段很好，但 Build、Test、Deploy 阶段明显掉分。

完整评分如下：

阶段满分得分结论
需求理解 RU2020Plan 文档完整覆盖实体、字段约束、权限、状态机、筛选、日历和 UCloud 部署要求
功能设计 FD202012 个 API、E2E-0115、UT-0121 设计完整
架构设计 AD2016方案完整，但 DDL 约束落地不足，SSH 用户口径仍写 root，最终部署偏离 Docker Compose
前端实现 FE2014看板、日历、筛选基本存在；登录态、退出按钮、邀请 500、动画和响应式细节扣分
后端实现 BE2016认证、状态机、权限基本完成；邀请接口函数签名不一致导致 500
功能测试 TS2012有测试文件，但 E2E 多数只点击不强断言，未挡住核心 Bug
问题处理 PD208多次自修后公网可访问，但 Fusion 中断和调用错误严重影响闭环
代码质量 CR2010有基础分层，但接口签名错误、CORS 全开、敏感信息暴露、部署与文档不一致
UCloud 部署 DP2013公网可访问，但 Docker Compose 后端失败，最终绕过原部署方案
质量分208人工验收 3 个程序 Bug，另有 3 个 Fusion 服务稳定性问题
综合分200137低于 Deepseek V4 Pro，高于 Kimi K2.6 1 分

3. 本次 panel 模型组合本身不是最强工程组合

本次 Fusion 的 analysis models 是：

模型单模型综合分
Qwen3.7 Max148/200
Deepseek V4 Pro146/200
Kimi K2.6136/200

judge / final model 又是 Deepseek V4 Pro。

而本轮 Deepseek V4 Pro 自身的问题包括：前后端接口不一致、实际使用 Bug 较多、人工介入多。

所以，Fusion 并不是把几个模型组合起来就必然超过 GLM 5.2、Claude 或 ChatGPT。更现实的判断是：

Fusion 更像把几个模型的意见交给一个裁判整理。如果裁判和候选模型本身工程执行能力不够强，最终交付仍然会出问题。

4. tool_choice: required 可能放大了工具调用问题

本次配置里设置了：

"tool_choice": "required"

这可能导致模型更频繁地被迫进入工具调用链路。

对普通问答或方案讨论，这不一定是问题。但在 opencode 这种需要持续 shell、读文件、写文件、调试、部署的场景里，多一层工具调用，就多一层失败点。

本轮现象也比较一致：

  • 输出反复中断
  • session 被拆成很多短段
  • 频繁出现 Expected 'id' to be a string
  • 开发阶段 assistant 消息数高达 234 条

这不是单纯“模型慢”，更像是 Fusion 调用机制和工程工具链叠加后，连续执行不够顺。

5. Fusion 对长上下文工程状态不友好

工程任务里，模型需要持续记住很多状态：

  • 哪些文件已经写过
  • 哪些测试失败过
  • 哪些命令已经执行过
  • 服务器当前状态是什么
  • 哪些 Bug 已经修过
  • 哪些部署步骤已经验证

而 Fusion 的 panel / judge 机制，更适合围绕一个问题做多视角分析，不太适合持续围绕真实工作区状态迭代。

本次最典型的例子是部署：

原始要求是 Docker Compose 三服务部署，但后端 Docker Compose 失败后，最终变成主机 uvicorn + systemd，数据库还在 Docker，前端由 nginx 托管。

结果是：公网能访问，但交付形态已经偏离了原要求。

对真实企业交付来说，这种差异不能轻描淡写。因为“能跑”和“按架构要求交付”不是一回事。

五、实际问题：人工验收发现了哪些 Bug？

本次人工验收发现 3 个程序 Bug：

序号问题类型影响
1登录状态没有保存前端状态刷新或重新进入时影响持续使用
2找不到退出登录按钮前端导航 / 账号操作用户无法正常切换账号或退出
3邀请用户 500核心功能 / API成员邀请核心功能不可用

同时还有 3 类 Fusion 服务稳定性问题：

序号问题类型影响
1速度很慢服务机制 / 性能总耗时拉长到 4h46m34s
2输出反复中断工具兼容 / 稳定性开发阶段被拆成 18 段，需要大量人工续跑
3Expected 'id' to be a string 频繁出现API / tool 调用错误打断连续开发，增加人工维护成本

其中“邀请用户 500”的代码根因很明确：

  • backend/routers/members.py 调用：invite_member(project_id, body.user_id, body.role, current_user["id"])
  • backend/services/member_service.py 定义：def invite_member(project_id: int, user_id: int, role: str)

也就是说，路由传了 4 个参数，服务函数只接收 3 个参数。真实调用时会直接触发 500。

退出按钮缺失也很直接：

  • frontend/src/components/Layout/Navbar.tsx 只展示了 user?.username
  • authStore.ts 里虽然实现了 logout()，但页面没有可见按钮调用它

这类问题的特点是：模型“写了一部分能力”，但没有真正交付到用户能用的界面和路径上。

六、实际使用建议：我会怎么安排 Fusion？

如果是在企业内部选型，我不会完全否定 Fusion，但会明确限制它的使用边界。

适合场景

Fusion 比较适合：

  • 需求分析
  • 架构取舍讨论
  • 多模型观点对比
  • 风险清单生成
  • 需求盲区检查
  • 对已有方案做反方审查
  • 方案评审前的 checklist 生成

原因也很简单：本次它在 RU 和 FD 两项都拿到 20/20。这说明它确实有助于把需求和方案想完整。

不适合场景

Fusion 不适合：

  • 长时间连续编码
  • 云端部署
  • 需要稳定 shell / tool 调用的任务
  • 需要低人工介入的交付
  • 需要严格按同一工作区状态迭代的项目
  • 对部署形态有严格要求的生产级任务

更合理的组合方式是：

  1. Fusion 做 Plan / Review。
  2. 工程能力更稳定的单模型做 Build / Test / Deploy。
  3. 部署阶段用明确 checklist 验收。
  4. 对核心接口增加强断言测试，不能只做“点了页面”的浅层 E2E。

一句话：让 Fusion 做评审者，不要让它单独做执行者。

七、本地结果详情：为什么说这不是主观印象？

1. Session 统计

指标数值
Session IDses_1116367bbffek1XTn9dNJnPCxE
Session 标题Fusion - FT - TeamTask-Board 技术方案设计
代码目录/Users/imnight/Documents/flowtask-test/fusion/FlowTask
AI 输出需求文档行数883
AI 输出需求文档非空行数722
输入需求总行数330
输入需求非空行数279
session 总消息数264
assistant 总消息数235
需求分析 assistant 消息数1
开发阶段 assistant 消息数234

2. Token 统计

阶段总 token输入输出推理缓存读取
Plan assistant78,02860,91516,4816320
Build assistant46,073,46416,581,242175,33812,82029,304,064
Assistant 合计46,151,49216,642,157191,81913,45229,304,064

3. 耗时详情

阶段耗时
需求分析阶段12min23s
开发阶段合计4h34m11s
总耗时4h46m34s

开发阶段被拆成 18 段：

4min1s + 4min54s + 7min29s + 10min33s + 21min54s + 45min35s + 18min29s + 22min42s + 18min55s + 5min28s + 5min57s + 11min59s + 20min15s + 3min4s + 25min4s + 11min0s + 21min5s + 15min47s

这些数据说明：Fusion 在开发阶段不是一次稳定推进，而是多次中断、恢复、续跑。对于工程交付来说，这会直接抬高人工维护成本。

八、问题 - 解决方案 - 验证：这次测评给企业选型什么启发？

问题

Fusion 在完整工程交付中暴露出：

  • 耗时长
  • 中断多
  • 工具调用不稳定
  • 测试没有挡住核心 Bug
  • 部署与原要求不一致
  • 成本并不低

解决方案

不要把 Fusion 放在“主力开发模型”的位置，而是放在“评审和审查”的位置：

  • 开发前：让 Fusion 检查需求遗漏和架构风险。
  • 开发中：让稳定单模型负责代码实现。
  • 开发后：让 Fusion 做反方审查、风险复盘和验收清单。
  • 部署时：用固定脚本和 checklist 控制，不依赖模型临场绕路。

验证

本轮结果支持这个判断：

  1. Plan 阶段得分高：RU 20/20，FD 20/20。
  2. 工程阶段明显下滑：FE 14/20，TS 12/20，PD 8/20，CR 10/20。
  3. 人工验收有 3 个程序 Bug。
  4. 服务稳定性有 3 类问题。
  5. 横向对比中，Fusion 排名第 7，费用和耗时都不占优。

九、如果还想复测 Fusion，我建议怎么测？

如果后续还想复测 Fusion，我不会再直接让它独立做完整开发部署，而会换一种更匹配它定位的方法：

  1. 只测需求分析和方案评审，不要直接测完整开发部署。
  2. 去掉 tool_choice: required，让模型自行决定是否调用 Fusion。
  3. 使用更强的 judge 模型，例如 Claude / GPT 系列，而不是本轮表现一般的 Deepseek。
  4. panel 模型里加入工程表现更强的模型，例如 GLM 5.2 或 ChatGPT 5.5。
  5. 把任务拆成两段：Fusion 做方案审查，另一个稳定模型做代码实现。
  6. 单独记录稳定性指标：中断次数、调用错误次数、每轮平均等待时间。

这样测出来的结果，可能更能反映 Fusion 的真实价值。

十、FAQ

Q1：OpenRouter Fusion 是不是完全不值得用？

不是。Fusion 的价值在于多模型分析和方案评审。本次它在需求理解和功能设计上都拿到 20/20，说明它在 Plan 阶段确实有优势。

但不建议把它作为长链路工程交付主力。

Q2：为什么 Plan 满分，最后综合分却只有 137/200？

因为工程交付不只看方案，还要看代码、测试、部署和真实验收。Fusion 的问题主要出现在 Build、Test、Deploy 阶段，包括中断多、工具调用错误、测试断言不足、部署偏离和实际 Bug。

Q3：Fusion 多模型协同，为什么没有超过单模型？

因为多模型协同更容易提升“观点完整度”，但不一定提升“代码正确性”。最终维护文件状态、修 Bug、跑部署的仍然是执行链路。工程任务更依赖连续性和稳定性。

Q4：本次最严重的问题是什么？

如果只选一个，我认为是 连续执行不稳定。18 次人工续跑、4h46m34s 总耗时、频繁工具调用错误，会显著增加工程使用成本。

Q5：Fusion 适合放在研发流程的哪个环节？

适合放在：需求评审、架构评审、风险审查、反方意见生成、验收 checklist 生成。

不适合单独负责：编码、测试、部署、生产级交付。

Q6：UCloud 部署最后成功了吗？

公网可访问，但没有按原要求完整交付 Docker Compose 三服务部署。后端 Docker Compose 失败后，最终改为主机 uvicorn + systemd，数据库仍在 Docker，前端由 nginx 托管。因此只能说“可访问”，不能说“完全按原部署方案交付”。

Q7：如果企业已经在用 Fusion，该怎么降低风险？

建议把 Fusion 的权限和任务边界收窄：

  • 不让它独立做生产部署。
  • 不让它承担长时间连续编码。
  • 用它做方案评审和风险检查。
  • 核心接口必须有强断言测试。
  • 部署必须有人工或自动化 checklist 验收。

总结建议

这次测完我最大的感受是：方案写得再漂亮，也不代表项目能顺利交差。

Fusion 搞多模型分析，确实能把 Plan 做得滴水不漏，看着像那么回事。但真到了"写代码、跑测试、Docker 部署、云端验收"这套脏活累活，短板全暴露了——又慢又贵，还老中断，工具链也磕磕绊绊。 最离谱的是，前面分析得头头是道，最后该犯的低级接口 Bug 一个没落，部署也能跑偏。

所以我的建议很直白：

别把它当主力开发模型。 那种需要一口气从代码写到上线的长链路任务，它扛不住，也别指望它当备选主力。

如果你非要找个地方用它，就留在需求分析、架构评审、风险审查这些偏"动脑"的阶段，当个帮你开阔思路的实验工具，点到为止。

参考信息：

说明：本文中的费用、耗时、Token、评分、Bug 数和模型对比均来自原文提供的测评记录。若用于正式发布，建议补充可公开访问的原始 Activity 截图、opencode session 日志、部署验收记录和评分规则说明，以增强可追溯性。