用 opencode 横评 6 款大模型 API：从代码生成到 Docker 部署全流程实测
大模型写代码到底行不行，不能只看算法题和 Demo。
这次，优刻得技术研究院采用了一种更接近真实开发的测评方式：给 6 款主流大模型 API 同一个工程任务，让它们从 0 到 1 完成一个 FlowTask 团队任务看板系统，并最终部署到 UCloud 云服务器，通过公网访问验收。
整个测试流程覆盖需求分析、代码开发、测试修复、Docker Compose 部署和云服务器验收。也就是说，这次不只是看模型会不会生成代码，而是看它能不能真正完成一次工程交付。
本次参与测试的模型包括：
- Claude Opus 4.8
- ChatGPT 5.5
- Deepseek V4 Pro
- Qwen3.7 Max
- Kimi K2.6
- GLM 5.1
核心结论：
- Claude Opus 4.8 综合分最高，为 186/200，实际费用 808.18 元，全程没有人工介入，自主完成度最好。
- ChatGPT 5.5 综合分 182/200，费用 223.01 元，总耗时 1h41m03s，功能和测试表现较好，但过程中有 1 次人工介入，主要是部署断点重启。
- Deepseek V4 Pro 和 Kimi K2.6 成本较低，但交付后的使用问题更明显。Deepseek 的主要问题集中在前后端接口约定和部署后使用 Bug；Kimi 的主要问题集中在部署链路、安全边界和资源治理。
- 成本效率不能只看账单费用。低费用模型如果需要大量人工检查、修复 Bug、重新部署，真实工程成本会被放大。
| 角色 | 推荐模型 | 推荐理由 | 使用条件 | 风险提示 |
|---|---|---|---|---|
| 综合首选 | Claude Opus 4.8 | 综合分最高，全程 0 人工介入，自主完成度最好 | 适合关键任务、复杂需求，或者希望尽量少安排人中途接管的场景 | 费用 808.18 元，本轮成本显著高于其它模型 |
| 性价比首选 | ChatGPT 5.5 | 综合分第二，费用 223.01 元，明显低于 Claude | 适合正式项目开发，希望质量和费用比较平衡时优先使用 | 有 1 次人工介入，仍建议安排工程师检查部署过程、架构实现和测试覆盖 |
| 低成本备选 | GLM 5.1 | 综合分 151/200，费用 63.71 元，成本明显低于 GPT/Claude | 适合预算有限的任务，但需要安排人重点检查和维护前端 | 前端实际使用问题较多，不建议直接交付上线，建议多花人力审核和维护 |
| 暂不优先 | Qwen3.7 Max | 综合分 148/200，设计较完整，但费用高于 GLM，交付质量没有明显优势 | 可以后续再测一次，看部署和前端功能是否改善 | 本轮状态流转 405、邀请功能缺失，性价比不突出 |
| 低成本实验 | Deepseek V4 Pro | 费用最低 39.70 元，后端和状态机有一定基础 | 适合低成本试用或生成局部代码 | 部署后使用时出现的 Bug 多，必须有人审核、修 Bug 和重新验证 |
| 不建议直接上线 | Kimi K2.6 | 费用低，但部署和资源治理风险突出 | 只适合非关键任务或低成本实验 | 部署、安全和资源使用问题比较突出，不建议直接交付上线 |
一、场景背景
1.1 要解决的问题
很多团队在评估代码生成模型时，会遇到几个实际问题：
- 只使用 Claude Code 或 Codex，容易绑定单一厂商工具链；
- 模型 Demo 能跑，但放到真实工程任务里不一定能完整交付；
- 只看 Token 或单次调用价格，无法反映部署、测试、返工成本；
- 模型生成代码后，缺少统一的验收标准和评分口径；
- 国产模型和海外模型难以在同一任务、同一环境、同一标准下横向对比。
因此，本次测评选择 opencode 作为测试工具，目标是通过统一流程评估不同模型在真实工程交付中的表现。
1.2 本次测试任务
测试任务是开发并部署一个团队任务看板系统：FlowTask。
模型需要尽量独立完成以下流程：
- 需求分析；
- 技术方案设计；
- 前端开发；
- 后端开发；
- 自动化测试；
- Docker Compose 部署；
- UCloud 云服务器公网验收；
- 部署调试与资源清理说明。
1.3 测试环境
本轮测试环境如下：
- 云服务器：UCloud 云服务器；
- 操作系统：Ubuntu 镜像；
- 网络：公网 IP；
- 安全配置：UCloud 防火墙 / 安全组；
- 部署方式：Docker Compose；
- 数据库：PostgreSQL。
费用口径使用 UCloud 模型服务平台账单截图中的：
- “筛选合计”；
- “订单总额”。
生成日期：2026-06-04。
二、技术方案
2.1 总体思路
要让不同大模型的工程能力可比较，不能只让它们回答理论问题，而是需要设计一个端到端工程任务，并用统一指标验证。
本次方案可以拆成四层：
| 层级 | 目标 | 验证方式 |
|---|---|---|
| 任务层 | 构造真实业务系统 | FlowTask 团队任务看板系统 |
| 工具层 | 避免单一厂商绑定 | 使用 opencode 管理 session 和导出记录 |
| 环境层 | 验证真实部署能力 | UCloud 云服务器 + Docker Compose + PostgreSQL |
| 评分层 | 统一评价模型表现 | 200 分制，10 个评分项 |
2.2 工程任务拆解
2.2.1 开发要求
模型需要实现一个可用的团队任务管理系统，核心功能包括：
-
用户注册和登录
- 支持默认账号；
- 支持 JWT 鉴权；
- 支持基础登录态管理。
-
项目管理
- 支持查看项目；
- 支持进入项目详情；
- 支持查看项目成员和任务。
-
成员邀请和权限控制
- 项目成员角色包括
edit和readonly； edit用户可以邀请成员、创建任务、编辑任务、删除任务、推进状态；readonly用户只能查看，不能执行写操作。
- 项目成员角色包括
-
任务管理
- 支持创建任务；
- 支持编辑任务；
- 支持删除任务；
- 任务字段包括标题、描述、负责人、优先级、状态、截止日期。
-
状态流转
- 任务状态需要按照规则推进；
- 后端必须拦截非法状态流转；
- 例如不能直接从“待办”跳到“完成”。
-
看板和日历
- 支持三列看板视图；
- 支持日历视图；
- 任务需要能够按状态和截止日期展示。
-
筛选功能
- 支持按成员筛选；
- 支持按状态筛选；
- 看板和日历切换时，筛选条件需要保持一致。
-
数据约束
- 正确实现字段类型和长度限制；
- 覆盖用户名、密码、标题、描述、角色、优先级、任务状态等字段。
-
自动化测试
- 包含前端 E2E 测试；
- 包含后端单元测试；
- 覆盖权限、状态流转、筛选、日历等关键场景。
2.2.2 部署要求
模型不仅要写代码，还要完成云端部署。部署要求包括：
- 使用 UCloud CLI 创建云服务器和公网 IP；
- 记录 UHostId、EIPId、公网 IP、Region、Zone 等资源信息；
- 正确连接服务器；
- 识别 Ubuntu 镜像默认不适合直接 root 登录的问题；
- 优先使用
ubuntu@公网 IP登录，并通过sudo执行部署命令； - 配置 UCloud 防火墙或安全组；
- 确保前端 80 端口、后端 health/API 端口可以公网访问；
- 使用 Docker Compose 部署前端、后端和 PostgreSQL；
- 配置 volume、环境变量、端口映射和服务重启策略；
- 完成公网验收，包括前端页面、后端 health 接口、默认账号、种子数据、关键 API、E2E 测试；
- 支持服务器重启后的服务恢复；
- 提供部署调试和资源清理说明，避免资源残留或误删。
2.3 opencode 数据采集流程
本次测试通过 opencode session 记录模型行为，并导出 session 作为审计依据。
常用流程如下：
opencode session list
用于查找本轮带 FT 标记的 session。
opencode export <session_id> > evaluations/models/<model>/sessions/<session_id>.json
用于导出指定模型的 session 记录。
导出后，从 session 中抽取以下信息：
- AI 返回的需求文档；
- AI 返回的技术方案文档；
- 需求分析阶段 assistant 消息数；
- 开发阶段 assistant 消息数；
- Token 消耗；
- 过程中出现的失败、报错、修复、重试记录。
然后结合以下材料进行打分：
- 被测代码；
- 部署脚本；
- 测试文件；
- session 过程记录；
- 人工测评记录；
- 云端服务复查结果；
- 实际账单费用。
2.4 云端验收流程
完成代码生成和部署后，需要对已经启动的云端服务进行复查。
建议验收项如下：
| 验收项 | 验证目的 |
|---|---|
| 前端页面可访问 | 验证 Web 服务是否部署成功 |
| 后端 health 接口可访问 | 验证 API 服务是否运行 |
| 默认账号可登录 | 验证认证链路 |
| 种子数据存在 | 验证初始化数据 |
| 关键 API 可用 | 验证后端业务逻辑 |
| E2E 测试通过 | 验证端到端用户流程 |
| 重启后服务恢复 | 验证 Docker 和服务自恢复能力 |
| 防火墙 / 安全组配置正确 | 验证公网访问链路 |
三、核心指标
3.1 评分模型
本次总分采用 200 分制，共 10 个评分项，每项满分 20 分。
10 个评分项如下：
| 缩写 | 指标 | 满分 |
|---|---|---|
| RU | 需求理解 | 20 |
| FD | 功能设计 | 20 |
| AD | 架构设计 | 20 |
| FE | 前端实现 | 20 |
| BE | 后端实现 | 20 |
| TS | 功能测试 | 20 |
| PD | 问题处理 | 20 |
| CR | 代码质量检查 | 20 |
| DP | UCloud 部署 | 20 |
| 质量分 | Bug 和实现偏差综合判断 | 20 |
综合分为各阶段整数得分相加，便于横向比较。
3.2 评分口径
本轮评分有几个关键口径：
-
需求理解 RU
- 只看 AI 在 Plan / 需求阶段返回的需求或技术方案文档；
- 不能用最终代码实现反向补分。
-
功能设计 FD 和架构设计 AD
- 以 Plan 为主，代码为辅；
- 代码只能验证设计是否兑现；
- Plan 没写的内容不能靠最终代码反向补满。
-
前端、后端、测试、部署、质量分
- 必须看实际代码；
- 必须看 session；
- 必须看部署结果；
- 必须看人工测评记录。
-
前端功能缺失
- 算 Bug；
- 不在评测过程中修复；
- 只记录并扣分。
-
人工验收问题数
- 只统计人工测评记录和报告中明确出现的交付后问题、核心功能 Bug、部署问题或文档 / 设计错误；
- 不把每个评分细项扣分都算作 Bug。
-
开发自修 Bug 数
- 只统计模型在正式 FT session 中自己遇到失败、报错、测试不通过、部署异常后，主动定位、修改并复测的闭环事件；
- 同一根因多次重试合并一次；
- 用户人工指出的问题不计入。
3.3 已知结果摘要
| 排名 | 模型 | 综合分 | 原始权重分 | 质量分 | 人工验收问题数 | 开发自修 Bug 数 | 最终时长 | 实际费用（¥） | Token 总数 | 对话消息总次数 | 人工介入次数 | 主要结论 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 1 | Claude Opus 4.8 | 186/200 | 119/130 | 15/20 | 1 | 10 | 1h28m09s | 808.18 | 19.82M | 171 | 0 | 全程 0 人工介入，自主完成度最好；但费用最高 |
| 2 | ChatGPT 5.5 | 182/200 | 117/130 | 16/20 | 2 | 8 | 1h41m03s | 223.01 | 11.16M | 84 | 1 | 功能和测试结果好，费用中等；但部署断点重启需要人工介入 |
| 3 | GLM 5.1 | 151/200 | 96/130 | 10/20 | 3 | 8 | 1h31m45s | 63.71 | 21.38M | 167 | 2 | 成本低，后端较完整，但前端和部署细节需要人工维护 |
| 4 | Qwen3.7 Max | 148/200 | 94/130 | 10/20 | 3 | 7 | 1h54m34s | 148.27 | 24.93M | 210 | 2 | 设计较完整，但状态流转和邀请功能部署后失败 |
| 5 | Deepseek V4 Pro | 146/200 | 93/130 | 9/20 | 5 | 18 | 2h43m43s | 39.7 | 49.23M | 259 | 4 | 费用最低，但前后端接口不一致，实际使用 Bug 较多 |
| 6 | Kimi K2.6 | 136/200 | 86/130 | 8/20 | 4 | 12 | 3h43m37s | 42.45 | 23.76M | 291 | 3 | 费用低，但部署链路、人工介入和自启动问题严重 |
成本与效率观察
| 模型 | 综合分 | 实际费用（¥） | 每 1 分成本（¥/分） | Token 总数 | 每 1M Token 成本（¥） |
|---|---|---|---|---|---|
| Claude Opus 4.8 | 186/200 | 808.18 | 4.35 | 19.82M | 40.77 |
| ChatGPT 5.5 | 182/200 | 223.01 | 1.23 | 11.16M | 19.98 |
| GLM 5.1 | 151/200 | 63.71 | 0.42 | 21.38M | 2.98 |
| Qwen3.7 Max | 148/200 | 148.27 | 1 | 24.93M | 5.95 |
| Deepseek V4 Pro | 146/200 | 39.7 | 0.27 | 49.23M | 0.81 |
| Kimi K2.6 | 136/200 | 42.45 | 0.31 | 23.76M | 1.79 |
3.4 典型问题分析
Claude Opus 4.8
优点：
- 综合分最高，186/200；
- 全程没有人工介入；
- 自主完成度最好。
扣分点：
- readonly 前端入口存在实现问题；
- 日历查询参数存在问题；
- 响应式 / 动画细节存在实现偏差。
适合：
- 对自主完成度要求高的复杂工程任务；
- 希望减少人工介入的端到端交付测试；
- 能接受较高模型费用的场景。
ChatGPT 5.5
优点：
- 综合分 182/200，排名第二；
- 实际费用 223.01 元，明显低于 Claude Opus 4.8；
- 功能和测试结果较好；
- 总耗时 1h41m03s。
问题：
- 有 1 次人工介入；
- 主要发生在部署断点重启环节；
- 按“第一次没实现就是 0 分”的口径，部署重启恢复能力原始分为 0/2。
适合：
- 需要在质量和成本之间平衡的工程评估；
- 对部署可靠性有要求，但允许少量人工介入的场景。
Deepseek V4 Pro
优点：
- 费用较低。
问题：
- 前后端接口约定问题较明显；
- 部署后使用时出现 Bug。
适合：
- 对成本敏感；
- 有人工 Review 和修复能力；
- 更关注代码初稿生成，而非完全自动交付的场景。
Kimi K2.6
优点：
- 费用较低。
问题：
- 部署链路问题较明显；
- 安全边界问题较明显；
- 资源治理问题较明显。
适合：
- 成本敏感型试验；
- 有运维人员兜底；
- 不直接用于无人值守生产部署的场景。
四、优刻得相关能力
本次测试环境使用了 UCloud / 优刻得相关云资源和服务能力，主要用于验证模型生成系统的真实部署能力。
4.1 UCloud 云服务器
UCloud 云服务器用于承载前端、后端和数据库服务。
在本次任务中，模型需要能够：
- 创建云服务器；
- 获取公网 IP；
- 记录 UHostId、EIPId、Region、Zone；
- 连接 Ubuntu 实例；
- 在服务器上执行 Docker Compose 部署。
4.2 公网 IP 与防火墙 / 安全组
公网验收依赖网络配置正确。
需要重点关注：
- 前端 80 端口是否放通；
- 后端 health/API 端口是否放通；
- 防火墙或安全组规则是否准确；
- 是否存在端口未开放导致服务本地可用、公网不可访问的问题。
4.3 Docker Compose 部署环境
本次部署要求模型使用 Docker Compose 管理：
- 前端服务；
- 后端服务；
- PostgreSQL 数据库。
关键配置包括：
- volume；
- 环境变量；
- 端口映射；
- 服务依赖；
- 重启策略。
尤其需要检查服务器重启后的服务恢复能力，避免关机再开机后 Docker 服务没有自动启动。
4.4 星图模型服务平台账单口径
本次费用统计来自 UCloud 模型服务平台账单截图中的：
- 筛选合计；
- 订单总额。
注意：费用只代表本次账单口径下的实际消耗，不等同于完整工程成本。完整成本还应考虑：
- 人工验收成本；
- Bug 修复成本；
- 重复部署成本；
- 运维排障成本；
- 安全检查成本。
五、适用 / 不适用场景
5.1 适用场景
该测评方法适合以下场景：
-
评估不同大模型 API 的工程交付能力
- 不只看代码片段；
- 关注完整项目落地。
-
对比国产模型和海外模型
- 使用同一任务；
- 使用同一环境；
- 使用同一评分标准。
-
验证模型是否具备部署能力
- 包括 SSH 登录、Docker Compose、云防火墙、数据库初始化、公网验收等。
-
构建企业内部模型选型基准
- 支持从质量、费用、耗时、人工介入等维度评估。
-
避免工具链绑定单一厂商
- 使用 opencode 管理多模型测试流程；
- 降低对 Claude Code 或 Codex 单一工具的依赖。
5.2 不适用场景
该方法不适合以下场景：
-
只想测试模型问答能力
- 本文方法偏工程交付，不是普通问答评测。
-
没有云资源或部署验收条件
- 如果无法进行公网验收，部署分和质量分会缺少依据。
-
只看单次调用价格
- 本文强调总交付成本，而不只是 Token 单价。
-
希望直接得出所有模型最终排名
- 原文未提供所有模型完整阶段得分和费用，不能补全不存在的数据。
-
生产环境直接无人值守上线
- 即使模型得分较高，也仍需要人工安全审查、代码审查和运维兜底。
总结
- 追求最强能力，不太敏感成本：选 Claude Opus 4.8；
- 既要能力，又要性价比：选 GLM 5.1；
- 只看单次调用价格：Deepseek V4 Pro 和 Kimi K2.6 有优势，但需要更多人工兜底；
- ChatGPT 5.5 综合表现不错，但在部署和恢复环节仍需要人工介入。
不过一个模型再好，也不该成为企业 AI 应用的唯一支点。
它可能今天效果最好，明天价格变了；今天调用顺畅，明天策略收紧；今天还能覆盖业务，明天就遇到合规边界。
所以更稳的做法，不是把所有希望都压在一个模型上，而是准备一套可切换的模型组合。
就像出远门不能只看一条导航路线。主路最快，但也可能临时封路；备选路线也许绕一点，却能保证你继续往前走。
Claude、GPT 这类模型可以承担高难任务，国产大模型可以在合规、成本和本地化场景里补位。关键不是谁替代谁，而是让业务在不同情况下都有路可走。
注：本次测评来自优刻得技术研究院，测试过程尽量还原真实工程开发链路，因此结论更关注模型在实际项目中的可交付性，而不是单纯的榜单分数或代码生成速度。
FAQ
Q1：为什么不用 Claude Code 或 Codex 直接测试？
可以使用，但如果只依赖某一个厂商的工具链，容易导致测试流程、上下文管理、执行环境和模型能力强绑定。使用 opencode 的目的，是尽量把测试流程和具体模型厂商解耦，便于在同一任务下比较多个模型。
Q2：为什么测试任务要包含部署，而不只看代码？
因为真实工程交付不等于生成代码。一个模型即使能写出前后端代码，也可能在以下环节失败：
- SSH 登录方式判断错误；
- 安全组端口未开放；
- Docker Compose 配置错误；
- 数据库未初始化；
- 服务重启后无法恢复；
- health 接口或默认账号不可用。
因此，本次将 UCloud 云端部署纳入评分。
Q3：成本效率应该怎么看？
成本效率只反映账单费用与得分、Token 的比例，不代表最终交付质量。
例如，低费用模型如果后续需要大量人工检查、修 Bug 和重新部署，真实成本可能反而更高。因此建议同时看：
- 综合分；
- 实际费用；
- 总耗时；
- 人工介入次数；
- 人工验收问题数；
- 部署成功率；
- 重启恢复能力。
Q4：人工验收问题数和评分扣分有什么区别？
人工验收问题数只统计明确出现的交付后问题、核心功能 Bug、部署问题或文档 / 设计错误。
评分扣分可能更细，例如一个设计点没有覆盖，也可能扣分，但不一定都算作一个 Bug。
Q5：开发自修 Bug 数怎么统计？
只统计模型在正式 FT session 中自己遇到失败、报错、测试不通过或部署异常后，主动定位、修改并复测的闭环事件。
同一根因多次重试只算一次。用户人工指出的问题不计入开发自修 Bug 数。
Q6：为什么 Claude Opus 4.8 得分最高但不一定是所有场景最优？
因为它本轮综合分最高，自主完成度最好，但费用也是本轮最高，为 808.18 元。如果团队更关注成本控制，或者允许人工介入，ChatGPT 5.5 这类质量和成本更均衡的选择可能更合适。
Q7：为什么低成本模型不能只看费用？
因为低费用模型可能带来更多后续返工。例如原文提到：
- Deepseek V4 Pro 主要问题是前后端接口约定和部署后使用 Bug；
- Kimi K2.6 主要问题是部署链路、安全边界和资源治理。
这些问题会增加人工 Review、修复和重新部署成本。
Q8：如果要复现这类评测，最小闭环是什么？
建议至少保留以下闭环：
- 固定任务需求；
- 固定测试环境；
- 使用 opencode 记录 session；
- 导出 session；
- 统计 Token、耗时、人工介入；
- 检查代码、测试、部署脚本；
- 云端公网验收；
- 按统一评分表打分；
- 记录费用和问题清单。
欢迎加入DeepSeek 技术社区。在这里，你可以找到志同道合的朋友，共同探索AI技术的奥秘。
更多推荐
6
0- 0
已为社区贡献1条内容
所有评论(0)