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

> 作者/来源: admin
> 发布时间: 2026-08-13T10:14:18.001Z
> 分类: AI专区
> 标签: OpenRouter Fusion, 工程交付, AI模型评测, 多模型协同, 技术方案
> 原文链接: http://117.50.162.249:3000/yun/articles/2690

---

先说结论：**如果你的目标是完整工程交付，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 配置如下：

```text
{
  "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 model | Kimi K2.6 |
| analysis model | Deepseek V4 Pro |
| analysis model | Qwen3.7 Max |
| judge / final model | Deepseek V4 Pro |

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

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

---

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

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

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

| 阶段 | 满分 | 得分 | 说明 |
| --- | --- | --- | --- |
| 需求理解 RU | 20 | 20 | Plan 文档完整覆盖实体、字段约束、权限、状态机、筛选、日历和 UCloud 部署要求 |
| 功能设计 FD | 20 | 20 | 12 个 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 |
| 人工验收程序 Bug | 3 |
| Fusion 服务稳定性问题 | 3 |
| 开发自修 Bug | 12 |

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

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

---

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

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

本轮 8 个模型对比如下：

| 排名 | 模型 | 综合分 | 费用（¥） | Token | 总耗时 | 人工介入/续跑 | 人工验收问题数 | 结论 |
| --- | --- | --- | --- | --- | --- | --- | --- | --- |
| 1 | GLM 5.2 | 189/200 | 50.74 | 16.62M | 1h55m25s | 0 | 2 | 综合最优，费用低，交付稳定 |
| 2 | Claude Opus 4.8 | 186/200 | 808.18 | 19.82M | 1h28m09s | 0 | 1 | 自主完成度好，但价格最高 |
| 3 | ChatGPT 5.5 | 182/200 | 223.01 | 11.16M | 1h41m03s | 1 | 2 | 质量和费用较平衡 |
| 4 | GLM 5.1 | 151/200 | 63.71 | 21.38M | 1h31m45s | 2 | 3 | 成本低，但前端问题明显 |
| 5 | Qwen3.7 Max | 148/200 | 148.27 | 24.93M | 1h54m34s | 2 | 3 | 设计较完整，部署后核心功能有问题 |
| 6 | Deepseek V4 Pro | 146/200 | 39.70 | 49.23M | 2h43m43s | 4 | 5 | 费用最低，但实际 Bug 多 |
| 7 | OpenRouter Fusion | 137/200 | 279.53 | 46.15M | 4h46m34s | 18 | 3 | Plan 强，但开发慢、中断多、交付 Bug 明显 |
| 8 | Kimi K2.6 | 136/200 | 42.45 | 23.76M | 3h43m37s | 3 | 4 | 部署和资源治理风险突出 |

几个直接结论：

- 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 阶段明显掉分。

完整评分如下：

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

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

本次 Fusion 的 analysis models 是：

| 模型 | 单模型综合分 |
| --- | --- |
| Qwen3.7 Max | 148/200 |
| Deepseek V4 Pro | 146/200 |
| Kimi K2.6 | 136/200 |

judge / final model 又是 Deepseek V4 Pro。

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

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

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

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

本次配置里设置了：

```text
"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 段，需要大量人工续跑 |
| 3 | Expected '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 ID | ses_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 assistant | 78,028 | 60,915 | 16,481 | 632 | 0 |
| Build assistant | 46,073,464 | 16,581,242 | 175,338 | 12,820 | 29,304,064 |
| Assistant 合计 | 46,151,492 | 16,642,157 | 191,819 | 13,452 | 29,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 一个没落，部署也能跑偏。

所以我的建议很直白：

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

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

参考信息：

- OpenRouter Fusion 官方文档：https://openrouter.ai/docs/guides/features/plugins/fusion

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