让Kimi2.6/OpenClaw做裁判,DeepSeek V4 vs GLM5.1 复杂任务编码谁更强?-夜雨聆风

让Kimi2.6/OpenClaw做裁判,DeepSeek V4 vs GLM5.1 复杂任务编码谁更强?

DeepSeek 于今日正式发布 V4 系列模型。结合 DSA 稀疏注意力（DeepSeek Sparse Attention），实现了全球领先的长上下文能力。并且从现在开始，1M（一百万）上下文将是 DeepSeek 所有官方服务的标配。 Agentic Coding 专项优化是 V4 的另一大卖点。

DeepSeek 官方明确表示，DeepSeek-V4 针对 Claude Code 、OpenClaw、OpenCode、CodeBuddy 等主流的 Agent 产品进行了适配和优化，在代码任务、文档生成任务等方面表现均有提升。

那既然这么说了，我们想到了一个非常有意思的测评系统：使用OpenClaw+Kimi作为Agent平台和裁判模型，在零人工干预的极限条件下，让被评测模型，基于同一个开发PRD，限时30分钟，让模型在同样的环境下，完成一个包含前端、后端、数据库、量化算法和回测引擎的复杂金融系统。我们也给V4 Pro找了一个对手：GLM 5.1。

在这个评测体系中，PRD、评测、验收均由OpenClaw+Kimi2.6自主完成；而具体的代码部分则由被评测模型来完成。可以说是一定意义上的客观独立第三方了。

我们先看下PRD：这份PRD总计 47 个可验收功能点。

当然我们也给两个模型一些开发限制给一些压力：

量化算法必须手写 Python，禁用 TA-Lib、pandas_ta、Backtrader、Zipline 等库（numpy/pandas 基础运算可用）。
每个模型都是30分钟的开发时间，结束后，功能点实现程度作为主要依据，迭代轮次、Token用量等作为次要判断。

先看下DS V4 Pro的基本实现情况：

架构选择：FastAPI + SQLAlchemy + SQLite + Vanilla JS；第一轮响应耗时 224 秒，策略为”先搭骨架，再填血肉”。
亮点：数据库模型完整。User、Account、Order、Trade、Position、KLine、StockQuote、PortfolioSnapshot、RealizedPnL——PRD 要求的 10+ 个实体全部到位，关系定义、索引、唯一约束均正确实现。
量化指标严格合规。MA 采用 sum(window)/period 循环实现，EMA 采用递推公式 alpha * price + (1-alpha) * prev_ema，MACD/RSI/KDJ/BOLL 全部纯 Python 手写，未调用 pandas 的 rolling() 或 ewm()。
核心交易链路已打通。JWT 认证、订单撮合引擎、限价单挂单、市价单成交、订单状态流转均有基础实现。

问题：代码有点碎片化。152 个代码块分散在 86 个文件中，每轮仅提供 1-2 个文件片段，在30分钟内，未形成统一的可运行项目。另外因为规划问题，前端功能只实现了40%；

GLM5.1这边：

架构选择：Flask + SQLAlchemy + SQLite + React + Vite；第一轮响应耗时 181 秒，策略为”整文件输出”。
亮点：文件结构清晰完整。35+ 个文件按模块组织：后端 routes/、services/、models/ 分层明确，前端 pages/、components/、api/ 目录规范。
相比之下，前端完成度显著领先。Login.jsx、Dashboard.jsx、Market.jsx、Trade.jsx、Portfolio.jsx、Quant.jsx——6 个完整页面全部实现，采用 ECharts 做 K 线图和资产曲线。用户系统 100% 完成、前端 80% 完成、回测引擎完整实现。
Token 效率更高。以比V4 Pro少 23% 的 token 消耗，完成了更多功能点。

问题：量化指标未严格手写，这个实际是PRD里面严格要求的。MA 和 EMA 直接调用了 pd.Series.rolling().mean() 和 pd.Series.ewm().mean()，虽 pandas 不属 TA-Lib 范畴，但与 PRD “手写 Python 实现”要求存在偏差。代码仍需手动合并。虽然每个文件内部完整，但分散在 7 个迭代文件中。

OpenClaw随机抽取 5 个核心功能点做代码验证，结论是：GLM 5.1 的”完成度”更高，产出代码更接近可直接运行的状态； DeepSeek V4-Pro 展现了更强的工程严谨性：数据库模型更完整、量化指标完全合规手写、架构设计更专业。

下面放上原始测评数据：

测评环境：

参数	配置
调度平台	OpenClaw + Kimi 2.6
硬件环境	裸 VM，40G 磁盘，无 Docker/Podman
Python	3.12.3
Node.js	v24.14.1
左侧模型	DeepSeek V4-Pro（max reasoning）
右侧模型	GLM-5.1

PRD部分：

模块	功能点	核心要求
用户与账户系统	5 点	注册/登录/JWT 认证/虚拟资金账户（100 万 HKD）/账户总览
行情数据模块	6 点	25 只港股/实时报价（Yahoo Finance）/60 天 K线/缓存/搜索
模拟交易引擎	10 点	买入/卖出/市价单/限价单撮合/撤单/订单查询/成交记录/费用计算/资金冻结/权限校验
持仓与盈亏	6 点	持仓列表/加权平均成本/已实现盈亏/资产快照/资产曲线/实时刷新
量化分析工具	12 点	手写 MA/EMA/MACD/RSI/KDJ/BOLL/指标 API/前端展示/回测引擎/双均线策略/策略列表
前端可视化	5 点	登录页/仪表盘/行情浏览/交易页/持仓量化分析页
系统与文档	3 点	README/数据库自动初始化/错误处理与日志

测评规则：

规则	说明
零人工干预	模型启动后，人类不发任何消息引导、纠错或提示
30 分钟硬上限	到点即停，无论写到哪一步
计时器 + Token 计数器	实时监控时间和 API 消耗
产物隔离	各自输出到独立目录，供后续人工验收

DS V4 Pro数据

指标	数值
实际耗时	33 分钟
迭代轮数	14 轮
Token 消耗	311,588
代码块数	152
原始内容量	209KB
独立文件数	86
功能完成度	~53%

GLM5.1 数据

指标	数值
实际耗时	30.1 分钟
迭代轮数	8 轮
Token 消耗	241,562
代码块数	122
原始内容量	176KB
独立文件数	~20（完整文件）
功能完成度	~70%

细项对比：

维度	DeepSeek V4-Pro	GLM-5.1	优势方
实际耗时	33 分钟	30.1 分钟	—
迭代轮数	14 轮	8 轮	—
Token 消耗	311,588	241,562	GLM（省 23%）
代码块数	152	122	DeepSeek
原始内容量	209KB	176KB	DeepSeek
独立文件数	86（碎片化）	~20（完整文件）	GLM
功能完成度	~53%	~70%	GLM
量化指标合规	✅ 纯手写	⚠️ pandas 捷径	DeepSeek
Token 效率	0.17 功能点/千 token	0.29 功能点/千 token	GLM

产出观察：

模型	输出模式	典型每轮产出	影响
DeepSeek	碎片模式	1-2 个文件片段	Token 浪费在重复说明和导入，上下文切换开销大
GLM	整文件模式	2-4 个完整文件	文件内聚性高，功能点更容易对应 PRD 验收标准

测试结果：

测试项	DeepSeek V4-Pro	GLM-5.1	评估
用户注册 + 密码加密	✅ bcrypt 哈希	✅ Werkzeug 哈希	合规
买入下单 + 费用计算	✅ 佣金 + 印花税正确	✅ 佣金 + 印花税正确	精准
MA 指标计算	✅ 纯循环实现	⚠️ `pandas.rolling()`	DeepSeek ✅
前端登录页面	❌ HTML 骨架	✅ React 完整表单	GLM ✅

Token效率

模型	总 Token	功能点完成数	效率（功能点/千 token）
DeepSeek V4-Pro	311,588	~25	0.17
GLM-5.1	241,562	~33	0.29

量化部分：

指标	DeepSeek	GLM
MA 实现	`sum(window)/period` 循环	`pd.Series.rolling().mean()`
EMA 实现	`alpha * price + (1-alpha) * prev` 递推	`pd.Series.ewm().mean()`
MACD	基于手写 EMA 计算	基于 pandas EMA 计算
RSI/KDJ/BOLL	纯手写	纯手写

客观场景评价。

场景	推荐模型	理由
快速原型 / MVP 交付	GLM-5.1	全栈平衡策略，交付覆盖面广
底层算法精度 / 后端性能优先	DeepSeek V4-Pro	代码工程质量更高，类型安全
合规性要求严格	DeepSeek V4-Pro	量化指标完全手写，不找捷径
Token 成本敏感	GLM-5.1	效率更高，单位 token 产出更多