大模型写代码到底行不行，不能只看算法题和 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

核心结论：

1. Claude Opus 4.8 综合分最高，为 186/200，实际费用 808.18 元，全程没有人工介入，自主完成度最好。
2. ChatGPT 5.5 综合分 182/200，费用 223.01 元，总耗时 1h41m03s，功能和测试表现较好，但过程中有 1 次人工介入，主要是部署断点重启。
3. Deepseek V4 Pro 和 Kimi K2.6 成本较低，但交付后的使用问题更明显。Deepseek 的主要问题集中在前后端接口约定和部署后使用 Bug；Kimi 的主要问题集中在部署链路、安全边界和资源治理。
4. 成本效率不能只看账单费用。低费用模型如果需要大量人工检查、修复 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。

模型需要尽量独立完成以下流程：

1. 需求分析；
2. 技术方案设计；
3. 前端开发；
4. 后端开发；
5. 自动化测试；
6. Docker Compose 部署；
7. UCloud 云服务器公网验收；
8. 部署调试与资源清理说明。

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 开发要求

模型需要实现一个可用的团队任务管理系统，核心功能包括：

1. 用户注册和登录

   • 支持默认账号；
   • 支持 JWT 鉴权；
   • 支持基础登录态管理。

2. 项目管理

   • 支持查看项目；
   • 支持进入项目详情；
   • 支持查看项目成员和任务。

3. 成员邀请和权限控制

   • 项目成员角色包括 edit 和 readonly；
   • edit 用户可以邀请成员、创建任务、编辑任务、删除任务、推进状态；
   • readonly 用户只能查看，不能执行写操作。

4. 任务管理

   • 支持创建任务；
   • 支持编辑任务；
   • 支持删除任务；
   • 任务字段包括标题、描述、负责人、优先级、状态、截止日期。

5. 状态流转

   • 任务状态需要按照规则推进；
   • 后端必须拦截非法状态流转；
   • 例如不能直接从“待办”跳到“完成”。

6. 看板和日历

   • 支持三列看板视图；
   • 支持日历视图；
   • 任务需要能够按状态和截止日期展示。

7. 筛选功能

   • 支持按成员筛选；
   • 支持按状态筛选；
   • 看板和日历切换时，筛选条件需要保持一致。

8. 数据约束

   • 正确实现字段类型和长度限制；
   • 覆盖用户名、密码、标题、描述、角色、优先级、任务状态等字段。

9. 自动化测试

   • 包含前端 E2E 测试；
   • 包含后端单元测试；
   • 覆盖权限、状态流转、筛选、日历等关键场景。

2.2.2 部署要求

模型不仅要写代码，还要完成云端部署。部署要求包括：

1. 使用 UCloud CLI 创建云服务器和公网 IP；
2. 记录 UHostId、EIPId、公网 IP、Region、Zone 等资源信息；
3. 正确连接服务器；
4. 识别 Ubuntu 镜像默认不适合直接 root 登录的问题；
5. 优先使用 ubuntu@公网 IP 登录，并通过 sudo 执行部署命令；
6. 配置 UCloud 防火墙或安全组；
7. 确保前端 80 端口、后端 health/API 端口可以公网访问；
8. 使用 Docker Compose 部署前端、后端和 PostgreSQL；
9. 配置 volume、环境变量、端口映射和服务重启策略；
10. 完成公网验收，包括前端页面、后端 health 接口、默认账号、种子数据、关键 API、E2E 测试；
11. 支持服务器重启后的服务恢复；
12. 提供部署调试和资源清理说明，避免资源残留或误删。

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 评分口径

本轮评分有几个关键口径：

1. 需求理解 RU

   • 只看 AI 在 Plan / 需求阶段返回的需求或技术方案文档；
   • 不能用最终代码实现反向补分。

2. 功能设计 FD 和架构设计 AD

   • 以 Plan 为主，代码为辅；
   • 代码只能验证设计是否兑现；
   • Plan 没写的内容不能靠最终代码反向补满。

3. 前端、后端、测试、部署、质量分

   • 必须看实际代码；
   • 必须看 session；
   • 必须看部署结果；
   • 必须看人工测评记录。

4. 前端功能缺失

   • 算 Bug；
   • 不在评测过程中修复；
   • 只记录并扣分。

5. 人工验收问题数

   • 只统计人工测评记录和报告中明确出现的交付后问题、核心功能 Bug、部署问题或文档 / 设计错误；
   • 不把每个评分细项扣分都算作 Bug。

6. 开发自修 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 适用场景

该测评方法适合以下场景：

1. 评估不同大模型 API 的工程交付能力

   • 不只看代码片段；
   • 关注完整项目落地。

2. 对比国产模型和海外模型

   • 使用同一任务；
   • 使用同一环境；
   • 使用同一评分标准。

3. 验证模型是否具备部署能力

   • 包括 SSH 登录、Docker Compose、云防火墙、数据库初始化、公网验收等。

4. 构建企业内部模型选型基准

   • 支持从质量、费用、耗时、人工介入等维度评估。

5. 避免工具链绑定单一厂商

   • 使用 opencode 管理多模型测试流程；
   • 降低对 Claude Code 或 Codex 单一工具的依赖。

5.2 不适用场景

该方法不适合以下场景：

1. 只想测试模型问答能力

   • 本文方法偏工程交付，不是普通问答评测。

2. 没有云资源或部署验收条件

   • 如果无法进行公网验收，部署分和质量分会缺少依据。

3. 只看单次调用价格

   • 本文强调总交付成本，而不只是 Token 单价。

4. 希望直接得出所有模型最终排名

   • 原文未提供所有模型完整阶段得分和费用，不能补全不存在的数据。

5. 生产环境直接无人值守上线

   • 即使模型得分较高，也仍需要人工安全审查、代码审查和运维兜底。

---

总结

• 追求最强能力，不太敏感成本：选 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：如果要复现这类评测，最小闭环是什么？

建议至少保留以下闭环：

1. 固定任务需求；
2. 固定测试环境；
3. 使用 opencode 记录 session；
4. 导出 session；
5. 统计 Token、耗时、人工介入；
6. 检查代码、测试、部署脚本；
7. 云端公网验收；
8. 按统一评分表打分；
9. 记录费用和问题清单。