DeepSeek V4 Pro 与 GLM-5.3 深度实测，谁是国产大模型一哥？
今天发点新模型对抗测评相关的东西。 国产大模型最近连出两员大将：DeepSeek-V4-Pro 和 GLM-5.3。 两款模型发布后，网上的评价不统一，只看跑分很难判断真实...
今天发点新模型对抗测评相关的东西。
国产大模型最近连出两员大将：DeepSeek-V4-Pro 和 GLM-5.3。
两款模型发布后，网上的评价不统一，只看跑分很难判断真实差距。
所以这次不聊参数，直接上任务，让两款模型使用相同提示词、相同材料和相同交付要求逐项完成。
两款模型均在 Claude Code 中运行，拥有相同权限和相同初始文件；每个 Case 只运行一次，没有针对单个模型调整提示词。
跑完看看，谁是国模一哥，谁是国模一哥们儿。
case 1 事故取证与索赔计算
提示词：
根据下面的模拟合同、监控记录、工单、状态页和账单，判断 2026 年 8 月服务是否达到 SLA，并制作索赔材料。
所有时间均为北京时间 UTC+8。
资料一：《主服务协议》第 8.2 条
服务月费为 200,000 元。可用性信用额度按当月服务费计算：
– 月可用性低于 99.90%，但不低于 99.50%，信用额度为 5%。
– 月可用性低于 99.50%，但不低于 99.00%，信用额度为 10%。
– 月可用性低于 99.00%，信用额度为 20%。
– 当月信用额度上限为服务月费的 20%。
资料二：《SLA 附件》第 3 条
– 月可用性 = 1 – 当月不可用分钟数 ÷ 当月总分钟数。
– 超过 20% 的活跃租户无法通过核心健康检查时，服务计为不可用。
– 供应商监控记录是可用性计算的第一证据。
– 状态页和客服邮件只能作为辅助证据。
– 经批准的计划维护可以排除，但供应商必须至少提前 5 个完整工作日通知客户。
– 每月最多排除 4 小时计划维护。
资料三：《SLA 附件》第 4 条
P1 事故时限从客户报告或供应商监控首次告警中较早的时间开始计算：
– 响应时限：15 分钟。
– 临时解决方案时限：4 小时。
– 服务恢复时限：8 小时。
资料四：供应商监控导出
2026-08-05 01:00 至 02:30：
核心健康检查失败租户比例 100%。
2026-08-12 09:12 至 15:42：
核心健康检查失败租户比例 100%。
2026-08-22 02:00 至 03:10：
核心健康检查失败租户比例 35%。
三段时间没有重叠。
资料五：计划维护通知
通知发布时间：2026-08-01 18:00。
计划维护时间：2026-08-05 01:00 至 02:30。
通知写明维护期间核心服务可能不可用。
资料六：8 月 12 日工单
供应商监控首次告警：09:12。
客户创建 P1 工单：09:16。
供应商首次人工响应：09:38。
临时解决方案完成：12:50。
供应商状态页标记恢复：15:10。
监控系统恢复正常：15:42。
工单关闭：17:30。
资料七：客户经理邮件
“8 月 12 日事故已于 15:10 完全恢复，因此恢复耗时没有超过 6 小时。”
资料八：8 月账单
服务月费：200,000 元。
一次性实施服务费：50,000 元。
税费不计入 SLA 信用额度计算。
请交付：
1. 证据表，列出每项事实、来源、证据等级和冲突。
2. 逐段判断三次不可用时间是否计入 SLA。
3. 计算 8 月总分钟数、不可用分钟数和月可用性。
4. 判断对应的信用额度比例和金额。
5. 检查 8 月 12 日的响应、临时解决方案和恢复时限。
6. 说明客户经理邮件中的结论是否成立。
7. 列出资料不足、无法判断的事项。
8. 一份提交给管理层的事故摘要。
9. 一封发给供应商的正式索赔函。
10. 一张适合放进管理层 PPT 的事故时间线。
11. 检查所有时间差、比例和金额计算。
DeepSeek-V4-Pro
GLM-5.3
两款模型都算出了 4 万元信用额度，也都识破了供应商邮件里的错误口径。
DeepSeek-V4-Pro 更像合同审查员，23 条证据拆得细，哪些成立、哪些缺证据交代得很清楚。
但 DeepSeek-V4-Pro 的小问题是把 98.7679% 写成了约 98.76%，标准四舍五入到两位应为 98.77%。
GLM-5.3 更像交付负责人，直接做出了一份能打开、能打印、能拿去汇报的索赔卷宗，版式完成度明显高于 DeepSeek-V4-Pro。
综合来看，GLM-5.3 靠交付完成度拿下 Case 1，DeepSeek-V4-Pro 在证据推理上更稳。
case 2 Excel、Word、PPT 综合办公
提示词：
处理下面的订单数据，并生成一套可以交付的办公文件。
order_id,user_id,paid_at,amount,status,channel,original_order_id
A1001,U01,2026-08-01 23:40:00,299.00,paid,web,
A1002,U02,08/02/2026 09:15,"1,299.00″,paid,ios,
A1002,U02,2026-08-02 09:15:00,1299,PAID,iOS,
A1003,,2026/08/03 14:20,-199,refund,web,A1001
A1004,U04,2026-08-03T16:30:00+08:00,399,PAID,android,
A1005,U05,2026-08-04,0,paid,web,
A1006,U06,bad-date,99,pending,Web,
A1007,U07,2026-08-04 10:15:00,699,paid,android,
R1001,U01,2026-08-05 12:20:00,-99,refund,web,A1001
R1002,U02,2026-08-05 13:30:00,-1500,refund,ios,A1002
A1008,U08,2026-08-06 15:00:00,"1,099.00″,paid,web,
A1009,U09,2026-08-06 16:00:00,499,cancelled,android,
A1010,U10,2026-08-07 11:00:00,199,paid,,
A1011,U11,2026-08-07T12:00:00+08:00,259,paid,ios,
A1012,U12,2026-08-08 09:00:00,299元,paid,web,
清洗规则：
– order_id、user_id、paid_at、amount、status 和 channel 都是必填字段。
– 日期统一为北京时间 `YYYY-MM-DD HH:mm:ss`。
– status 和 channel 统一为小写。
– paid 金额必须大于 0。
– refund 金额必须小于 0，并且能找到有效的原始 paid 订单。
– 单笔退款绝对值不能超过对应订单的支付金额。
– 相同 order_id 且业务内容相同的重复记录只保留一条。
– pending 和 cancelled 订单可以保留，但不计入净收入。
– 有效净收入等于有效 paid 金额加有效 refund 金额。
– 无法可靠修复的数据进入 rejected 表，保留原始值和拒绝原因。
请生成：
1. `cleaned.csv`。
2. `rejected.csv`。
3. `clean_orders.py`。
4. `analysis.xlsx`，包含原始数据、清洗数据、拒绝数据、统计摘要和图表。
5. Excel 365 公式，公式能够随源数据变化重新计算。
6. `memo.docx`，供管理层阅读。
7. `management_report.pptx`，共 7 页。
8. 一份核对报告，列出原始行数、有效行数、重复数、拒绝数和有效净收入。
运行清洗脚本，打开或渲染生成的文件，检查 CSV、Excel、Word 和 PPT 中的数字是否一致。发现问题后继续修正。
DeepSeek-V4-Pro
GLM-5.3
DeepSeek-V4-Pro 最终业务数字全部正确，核对报告列出了全部有效订单，方便人工追溯
但日期日期解析只靠正则，2026-13-40 25:61:00 这样的非法时间也会被接受；遇到 +00:00 时区时，脚本只会删除时区标记，
Excel没有冻结表头，列宽拉得很大，数据表浏览体验一般。
PPT以文字为主，大量留白。
GLM-5.3 使用了 Decimal 处理金额，还能正确换算ISO 时区，并能拒绝非法日期，脚本使用自身目录定位文件，从其他目录执行也不容易找错文件。
Excel 增加渠道分析、状态分析、公式图表和冻结表头。
Word 包含渠道图表。
PPT 有流程图、数据卡、表格和图表，已经接近可直接汇报的成品。
DeepSeek-V4-Pro 交出了一套数字正确、形式偏基础的办公结果；GLM-5.3 完成度明显更高。
case 3 仓库并发 Bug 修复
提示词：
请处理 Order Desk 的重复订单事故。
仓库路径：
D:\360MoveData\Users\win\Desktop\选题\order-desk
客户支持收到多起重复订单反馈。用户快速双击“保存订单”、网络超时后重试，或者两个请求几乎同时到达服务端时，系统可能生成多笔订单。重复订单会分别进入后续流程，目前需要人工取消。
请直接进入仓库处理：
1. 阅读 README.md、TASK.md、应用代码、数据库迁移和现有测试。
2. 运行现有测试，确认当前状态。
3. 稳定复现重复订单问题。
4. 追踪前端、HTTP API、业务服务和 SQLite 之间的调用过程，找到具体根因。
5. 修改代码，解决并发请求、网络重试和服务重启后的重复订单问题。
6. 保持现有 API 以及正常下单、订单查询和列表功能。
7. 补充并发、重复请求、冲突请求、事务失败重试和服务重启相关测试。
8. 检查数据库迁移对新数据库和已有数据库的影响。
9. 运行全部测试，发现错误后继续修复并重新验证。
请在仓库中直接完成修改，不要只提供建议。
完成后说明：
– 根因。
– 修复方案。
– 修改文件。
– 数据库迁移。
– 新增测试。
– 实际运行的命令和结果。
– 仍然存在的风险。
DeepSeek-V4-Pro
GLM-5.3
ON CONFLICT(customer_id, idempotency_key) DO NOTHING
case 4 文件导出安全加固
提示词：
审查并修复下面的 FastAPI 接口：
from fastapi import FastAPI
from fastapi.responses import FileResponse
from pydantic import BaseModel
import os
import requests
app = FastAPI()
class ExportRequest(BaseModel):
url: str
filename: str
@app.post("/export")
def export_pdf(req: ExportRequest):
output = f"/tmp/{req.filename}"
html = requests.get(req.url).text
open("/tmp/page.html", "w").write(html)
os.system(f"wkhtmltopdf /tmp/page.html {output}")
return FileResponse(output)
完成以下工作：
1. 按严重程度列出漏洞、利用条件和影响。
2. 为主要漏洞提供可运行的攻击或测试样例。
3. 提交修复后的完整代码。
4. 增加 pytest 测试。
5. 限制协议、端口、目标主机和重定向次数。
6. 拒绝环回、私有、链路本地、保留地址和云服务元数据地址。
7. 同时检查 IPv4、IPv6、IPv4 映射 IPv6、十进制 IP 和混合编码地址。
8. 处理 DNS 重绑定和解析结果变化。
9. 每次重定向后重新检查目标。
10. 建立连接时固定经过验证的目标 IP。
11. 限制响应头大小、响应体大小、连接时间、读取时间和总时间。
12. 使用流式读取，不能在验证大小前把全部响应载入内存。
13. 阻止命令注入、路径穿越、符号链接攻击和任意文件覆盖。
14. 调用 wkhtmltopdf 时禁止 shell，并限制本地文件访问和外部资源加载。
15. 每个请求使用独立临时目录。
16. 并发请求之间不能共享输入和输出文件。
17. 客户端断开、请求取消、转换失败和发送完成后都要清理临时文件。
18. 处理 FileResponse 仍在读取文件时的清理时机。
19. 为转换进程设置超时、资源限制和终止处理。
20. 运行测试并继续修复发现的问题。
测试至少覆盖：
– `127.0.0.1`
– `::1`
– `169.254.169.254`
– 私有 IPv4
– IPv4 映射 IPv6
– DNS 重绑定
– 重定向到私有地址
– 超大响应
– 慢速响应
– 命令注入文件名
– 路径穿越文件名
– 符号链接输出
– 两个并发导出请求
– 客户端中途取消
– wkhtmltopdf 超时
交付漏洞报告、修复代码、测试代码、运行方法和仍然存在的边界。
DeepSeek-V4-Pro
GLM-5.3
case 5 大文件外部排序
提示词：
使用 Go 实现命令行工具 `ext-sort`。
输入是最大 10GB 的 CSV 文件，可用内存上限为 512MB。
排序规则：
1. `created_at` 升序。
2. 时间相同时按 `user_id` 升序。
3. 前两项相同时按原始行号升序，保证稳定排序。
要求：
– 正确处理引号、逗号、UTF-8 和字段内换行。
– 保留表头。
– created_at 接受 RFC3339 和 `YYYY-MM-DD HH:mm:ss`。
– 无法解析的记录写入 `rejected.csv`。
– 单条坏数据不能导致整个任务失败。
– 支持 `–input`、`–output`、`–temp-dir`、`–memory-limit` 和 `–workers`。
– 不能把整个文件读入内存。
– 内存限制应包含排序块、缓冲区和归并阶段的主要占用。
– 接收到终止信号时清理临时文件。
– 磁盘空间不足、文件损坏或权限不足时给出明确错误。
– 完整生成后才能替换目标输出文件。
– 排序结果可复现。
– 多次运行不能遗留不可识别的临时文件。
请交付：
1. 完整 Go 项目。
2. 单元测试、集成测试和属性测试。
3. 随机测试数据生成器。
4. 排序结果校验工具。
5. 性能测试。
6. 崩溃恢复和临时文件设计说明。
7. 构建及运行命令。
实际生成一份大于可用内存的测试文件，运行排序、校验结果并测量峰值内存。发现错误后继续修改。
DeepSeek-V4-Pro
GLM-5.3
case 6 高密度数据看板
提示词：
使用 React、TypeScript 和 Vite 制作“AI 模型评测实验室”单页应用。
视觉方向：
– 深石墨背景。
– 酸性绿色只用于选中状态、异常提示和少量重点数据。
– 禁止渐变、emoji、玻璃拟态和满屏圆角卡片。
– 信息密度偏高，保持清楚的视觉层级。
– 建立稳定的间距、字体和颜色系统。
– 避免常见后台模板的布局和装饰。
数据规模：
– 本地生成 50,000 条评测运行记录。
– 每条记录包含模型、评测集、时间、正确率、延迟、成本、输入 Token、输出 Token 和运行状态。
– 数据生成使用固定随机种子。
页面内容：
– 模型和评测集筛选。
– 运行参数面板。
– 综合指标矩阵。
– 延迟分布图。
– 成本趋势图。
– 正确率与 Token 消耗关系图。
– 可虚拟滚动的运行历史表格。
– 单次运行详情抽屉。
– 多模型对比模式。
交互要求：
– 筛选条件同步到 URL。
– 浏览器前进和后退能正确恢复筛选状态。
– 快速连续切换筛选条件时，旧请求结果不能覆盖新结果。
– 支持加载、空数据、错误、请求取消和部分失败状态。
– 图表显示 tooltip、图例、异常点和清楚的坐标单位。
– 坐标轴不能通过截断制造误导。
– 表格支持排序、筛选、分页或虚拟滚动。
– 所有交互支持键盘。
– 焦点状态清晰。
– 支持 `prefers-reduced-motion`。
– 适配 1440、768 和 390 三种宽度。
– 使用本地模拟 API，支持延迟、错误和取消请求。
– 增加组件测试、状态测试和关键交互测试。
完成后：
1. 运行格式检查、类型检查、测试和生产构建。
2. 启动应用并检查控制台。
3. 测量 50,000 条数据下的首次渲染和筛选响应。
4. 分别生成 1440、768 和 390 宽度截图。
5. 检查溢出、遮挡、对齐、文字可读性和图表误导。
6. 使用键盘完成一次完整筛选和查看详情流程。
7. 修复发现的问题并重新验证。
DeepSeek-V4-Pro
GLM-5.3
DeepSeek-V4-Pro 的页面更舒服，尤其是在 390px 和 768px 宽度下，筛选区、指标卡和图表仍然保持清楚。
GLM-5.3 对原始需求覆盖得更完整。固定种子配合固定时间轴，换机器、换日期运行，生成的数据仍然一致。图表还提供数据表视图，首次数据渲染约 359ms，筛选响应约 286ms，速度略快于 DeepSeek-V4-Pro。
GLM-5.3 状态处理和验收小幅领先，DeepSeek-V4-Pro 在页面易读性和多模型分析上表现更好。
case 7 节点编辑器
提示词：
使用 React、TypeScript 和 SVG 实现轻量工作流编辑器。
功能要求：
– 创建、选择、拖动、重命名和删除节点。
– 从端口拖线创建连接。
– 拒绝自环、重复连接和不合法方向。
– 单选、多选和框选。
– 复制、粘贴和重复节点。
– 画布缩放和平移。
– 节点自动进入可视区域。
– 撤销和重做，至少保留 50 步。
– 支持 Delete、Backspace、Ctrl/Cmd+C、Ctrl/Cmd+V、Ctrl/Cmd+Z 和 Ctrl/Cmd+Shift+Z。
– 输入框编辑时，快捷键不能误删节点。
– JSON 导入导出。
– JSON 错误需要指出具体字段或位置。
– 刷新后从 localStorage 恢复。
– 500 个节点和 1000 条连线时仍可操作。
– 提供小地图或画布定位工具。
– 支持键盘选择节点。
工程要求：
1. 先设计状态模型、坐标系统和历史记录结构。
2. 业务状态与临时拖拽状态分开管理。
3. 撤销记录不能保存无意义的鼠标移动中间状态。
4. 复制后的节点 ID、位置和连线必须正确更新。
5. 缩放后拖拽、框选和端口连线仍要准确。
6. 为连线规则、撤销重做、复制粘贴和导入导出编写测试。
7. 增加大数据量性能测试。
8. 运行类型检查、测试和生产构建。
9. 启动应用检查交互并修复问题。
交付完整项目、状态设计说明、运行方法和真实测试结果。
DeepSeek-V4-Pro
GLM-5.3
DeepSeek-V4-Pro 的优势集中在架构和页面完成度。深色画布、端口、连线和小地图的视觉统一。
GLM-5.3 的优势是需求覆盖更扎实。开始、步骤、结束三类节点拥有明确的颜色和端口规则，重复粘贴会持续增加偏移量，键盘方向键能按空间位置选择节点，选中画布外节点时还能自动调整视口。
GLM-5.3 拥有更完整的功能和更强的测试证据；DeepSeek-V4-Pro 在拖拽状态设计上更好。
case 8 3D 产品配置器
提示词：
使用 Three.js、TypeScript 和 Vite 制作模块化桌灯 3D 配置器。
建模要求：
– 使用程序化几何体创建灯座、两段灯臂、转轴、灯罩和灯泡。
– 每个部件是独立对象。
– 部件连接位置合理，旋转灯臂时不能脱节。
– 禁止下载外部模型和纹理。
交互要求：
– 点击部件后显示轮廓和名称。
– 支持三种材质、四种颜色和三档灯光。
– 支持调整两段灯臂和灯罩角度。
– 各关节有合理旋转范围。
– 支持爆炸视图动画和尺寸标注。
– 提供配置摘要、价格变化和重置按钮。
– 支持鼠标、触控和键盘。
渲染要求：
– 使用 PBR 材质。
– 有环境光、主光和软阴影。
– 灯泡产生可观察的照明变化。
– OrbitControls 有合理的目标、距离和极角限制。
– DPR 上限为 2。
– 窗口变化后正确调整画布和相机。
– 页面不可见时暂停不必要的渲染。
– WebGL 不可用时显示降级提示。
– 正确释放几何体、材质和事件监听器。
完成后：
1. 运行类型检查、测试和生产构建。
2. 启动页面并检查控制台。
3. 检查关节脱节、穿模、阴影、Z-fighting 和镜头裁切。
4. 检查移动端操作。
5. 生成默认、爆炸、开灯和移动端视图截图。
6. 根据实际画面继续修正。
7. 提交完整项目、运行方法和已知限制。
DeepSeek-V4-Pro
GLM-5.3
DeepSeek-V4-Pro 在 3D 本体上更占优势。灯座、两段灯臂、关节和灯罩的比例比较协调，一眼能看出是可调节桌灯；嵌套关节也写对了，调整父级灯臂时，后面的部件会跟着运动。
GLM-5.3 更像一款能直接演示的商品配置器。材质、颜色、灯光、角度、实时价格和差价都集中在一张卡片里，信息比 DeepSeek-V4-Pro 更容易找到；模型拆成八个可选部件，灯泡点光源还开启了阴影。
GLM-5.3 的主要问题出在视觉结果。灯罩比例过大，默认镜头正对灯罩内部，两段灯臂被遮住后更像环形灯。
DeepSeek-V4-Pro 的 3D 造型、选中效果和移动端可读性更好；GLM-5.3 在配置面板上领先，但明显的视觉问题对 3D 案例影响很大。
case 9 程序化建模
提示词：
为 Blender 4.x 编写 Python 脚本，生成咖啡售卖亭。
默认尺寸：
– 宽 4 米。
– 深 3 米。
– 高 2.8 米。
– 柜台高 1.05 米。
模型内容：
– 地台、墙体、顶棚和服务窗口。
– 柜台、储物柜和货架。
– 咖啡机、磨豆机、杯子和菜单牌。
– 外部招牌。
– 电源插座和走线槽。
– 相机、太阳光和两盏区域光。
结构要求：
– Architecture、Furniture、Props、Lights 分成独立集合。
– 主要对象使用稳定、清楚的英文名称。
– 亭体宽度、深度、柜台高度和货架数量可通过参数修改。
– 参数变化后，各部件位置和比例同步调整。
– 添加合理倒角和法线处理。
– 使用程序化材质。
– 主要尺寸写入对象自定义属性。
– 重复运行时更新脚本管理的集合，不能产生重复对象。
– 不删除其他集合中的用户对象。
交付：
1. 完整 Python 脚本。
2. 生成并保存 `.blend`。
3. 渲染正面、45 度和室内工作区三个视角。
4. 检查悬空、穿插、法线、材质比例和曝光。
5. 修改尺寸和货架数量后重新运行。
6. 确认对象名称和自定义属性保持稳定。
7. 提供运行方法、参数说明和对象结构说明。
实际在 Blender 4.x 中执行脚本并处理错误。
DeepSeek-V4-Pro
GLM-5.3
DeepSeek-V4-Pro 项目包含 59 个对象、14 套材质，按建筑、家具、道具、灯光和相机分类，并提供参数化脚本、三台相机和自动质检。
DeepSeek-V4-Pro 的成片存在明显硬伤。正面招牌和菜单文字被倒置、镜像，招牌还有裁切。
GLM-5.3 的空间完成度明显更高。正面能够看到服务窗口、层板、杯具、咖啡设备、台面和柜体，绿色与木色搭配也更接近可交付的商业空间方案。
GLM-5.3 也有可见问题：菜单文字没有落在黑色菜单板内。
综合三视图、空间完整度、参数验证和最终成片，GLM-5.3 还是强一点；DeepSeek-V4-Pro 的脚本结构有优势，但文字方向错误直接拉低了交付质量。
case 10 资料审查
提示词：
公司准备对项目进行最终验收并支付尾款。项目资料中出现了需求版本、金额、日期、负责人和验收条件不一致的情况。
请完整阅读本轮提供的合同、补充协议、需求文档、会议纪要、邮件、报价单和验收材料，核实项目当前应执行的要求。
请交付：
1. 需求与承诺清单，每条记录包含：
– 编号
– 需求、承诺或决定
– 当前状态
– 来源文件
– 页码、章节或段落位置
– 原文证据
– 生效日期
– 涉及金额
– 负责人
– 验收条件
– 是否已被后续文件修改或废止
– 修改或废止依据
– 需要确认的问题
2. 文件之间的冲突清单，重点检查：
– 合同与补充协议
– 需求文档的不同版本
– 会议纪要与确认邮件
– 正文与表格
– 报价、预算和付款金额
– 计划日期与实际日期
– 负责人和验收人
3. 已经被修改或废止，但仍在后续材料中继续引用的旧要求。
4. 合同承诺、当前实施结果和验收材料之间的差异。
5. 缺少正式证据支持的说法。
6. 可能影响验收、付款或责任认定的高风险事项。
7. 无法读取、缺页、乱码或内容不完整的文件。
8. 需要项目负责人、法务、财务或供应商确认的问题。
处理要求：
– 所有结论都要附带具体文件位置。
– 找不到证据时写“未找到”，不要根据常识补全。
– 同一事项存在多个版本时分别列出，不能自行选择其中一个。
– 后续文件只有明确修改旧要求时，才能认定旧要求已经失效。
– 区分正式合同、签署文件、确认邮件、会议讨论和个人意见。
– 同名人员需要结合部门、邮箱或上下文确认身份。
– 日期、金额、责任人和验收条件逐项核对。
– 发现正文与表格不一致时，同时保留两处证据。
最后给出一份供管理层阅读的验收审查意见，说明当前能否验收、能否支付尾款、需要暂缓处理的事项，以及每项判断的证据。
DeepSeek-V4-Pro
GLM-5.3
DeepSeek-V4-Pro 抓准了所有会改变验收和付款结论的事实，还识别出 4.2 万元重复培训费和 2.52 万元无效税额，正确处理了版本冲突；主要遗漏在档案保存要求。
GLM-5.3 同样得出了正确的验收、付款和金额结论，证据台账也更加细致。
但 GLM-5.3 的问题是分析过猛后出现了数据错误，DeepSeek-V4-Pro 在高风险审查所需的事实准确性上更稳。
case 11 客服工单处理
提示词：
客服系统需要把新工单转换成下游分派服务可以读取的 JSON。
下游服务接受的固定结构如下：
{
"tickets": [
{
"id": "string",
"category": "billing|bug|account|feature",
"priority": "p0|p1|p2|p3",
"requires_human": true,
"reason": "string"
}
],
"summary": {
"total": 0,
"p0_count": 0
}
}
分类规则：
– 账号被盗、陌生扣款或取消订阅后持续扣费，分类为 p0。
– 可以稳定复现的软件崩溃，分类为 p1。
– 无法登录且自动恢复方式失效，分类为 p1。
– 普通功能异常，分类为 p2。
– 功能建议，分类为 p3。
– 涉及资金、账号安全或身份核验的问题需要人工处理。
– JSON 中不能增加下游服务未定义的字段。
待处理工单：
T01：手机昨晚丢失，今天凌晨出现三笔陌生扣款。
T02：导出 PDF 时应用每次都会闪退，重新安装后仍然如此。
T03：希望增加深色模式。
T04：忘记密码，重置邮件一直收不到，垃圾邮件目录也检查过了。
T05：两个月前已经取消订阅，但最近两个月仍然被扣费。
T06：筛选订单后偶尔显示空白，刷新页面可以恢复。
请返回下游服务可以直接解析的合法 JSON，不要添加 Markdown 代码围栏或其他文字。
DeepSeek-V4-Pro
GLM-5.3
DeepSeek-V4-Pro 的 JSON 结构完全合规，6 条工单的分类、优先级和人工介入标记全部正确，total: 6、p0_count: 2 也核对无误。T01、T05 两个资金安全问题判为 P0，T04 账户恢复问题要求人工介入，说明风险边界判断准确。
GLM-5.3 的核心字段与 DeepSeek-V4-Pro 完全一致，同样没有格式错误或多余说明。GLM-5.3 在理由中保留了 T05 的扣费两个月，并补充人工核查退款；T04 也明确写出需要人工核验身份，交给客服人员后更容易继续处理。
这个任务两个模型区别不大。
case 12 项目排期与成本优化
提示词：
为下面的软件发布项目制定排期，并找出满足截止日期的最低加速成本方案。
项目从 2026 年 9 月 7 日星期一开始。只考虑周一至周五，不考虑法定节假日。
排期规则：
– 每项任务在工作日开始时启动。
– 工期按完整工作日计算。
– 依赖任务从所有前置任务完成后的下一个工作日开始。
– 同一个人不能同时参加两项任务。
– 标有两名负责人的任务需要两人同时有空。
– 没有依赖关系且负责人不同的任务可以并行。
– 每项加速方案最多使用一次。
– 需要在 2026 年 10 月 13 日结束前完成全部任务。
任务：
A. 需求分析
负责人：林舟
工期：3 个工作日
依赖：无
不可加速
B. 交互原型
负责人：林舟
工期：4 个工作日
依赖：A
可缩短为 3 个工作日，增加成本 1.2 万元
C. API 开发
负责人：周哲
工期：6 个工作日
依赖：A
可缩短为 4 个工作日，增加成本 2.8 万元
D. 数据迁移
负责人：张敏
工期：5 个工作日
依赖：A
可缩短为 3 个工作日，增加成本 2 万元
E. 前端开发
负责人：陈森
工期：6 个工作日
依赖：B
可缩短为 4 个工作日，增加成本 2.4 万元
F. 安全方案
负责人：张敏
工期：3 个工作日
依赖：B
不可加速
G. 系统联调
负责人：周哲、陈森
工期：3 个工作日
依赖：C、D、E
可缩短为 2 个工作日，增加成本 0.9 万元
H. 安全测试
负责人：张敏
工期：4 个工作日
依赖：F、G
可缩短为 2 个工作日，增加成本 1.6 万元
I. 用户验收
负责人：林舟
工期：3 个工作日
依赖：H
不可加速
J. 应用商店审核
负责人：外部团队
工期：7 个工作日
依赖：I
可缩短为 5 个工作日，增加成本 2.5 万元
请交付：
1. 未加速方案的完整排期。
2. 未加速方案的完成日期。
3. 满足 10 月 13 日截止日期的全部合理加速组合。
4. 最低成本方案。
5. 最低成本方案的逐项排期。
6. 对最低成本进行证明，说明更便宜的组合为什么无法按期完成。
7. 如果张敏在 9 月 17 日请假一天，重新计算最低成本方案。
8. 甘特图形式的排期表。
DeepSeek-V4-Pro
GLM-5.3
DeepSeek-V4-Pro 的核心计算正确，也找到最低成本方案，并正确算出 10 月 13 日完成。张敏 9 月 17 日请假只会推迟 F，最终日期和最优方案都不变。
DeepSeek-V4-Pro 在组合枚举上有遗漏。交付内容只有终端表格和 ASCII 甘特图，查看和复用也不方便。
GLM-5.3 的完成度更高。GLM-5.3 正确列出全部 9 个非冗余加速组合，最低成本、下界证明、请假重算结果都与独立核算一致。
生成的 release-schedule.html 包含摘要卡片、三份排期表和三张甘特图，未加速方案、最优方案、请假方案可以直接对照，作为项目排期材料更容易使用。
DeepSeek-V4-Pro 只是算对了方案，GLM-5.3 在组合完整性和交付形式上领先。
12 个 Case 跑完，GLM-5.3 在 7 个任务中领先，DeepSeek-V4-Pro 在 3 个任务中领先，另外 2 个任务差距不大。
GLM-5.3 的优势集中在完整交付。办公文件的版式更成熟，编程任务覆盖的异常情况更多，前端和节点编辑器更接近可直接使用的成品。到了 Blender 建模和项目排期，GLM-5.3 还能交付更完整的场景与可视化材料。
DeepSeek-V4-Pro 的强项是核心实现和事实准确性。大文件排序速度更快，坏数据处理更稳；3D 桌灯的结构、比例和移动端效果更好；处理高风险验收资料时，DeepSeek-V4-Pro 也没有因为追求分析深度而算错关键数字。
如果日常任务以办公交付、完整项目和长程 Agent 执行为主，我会优先选 GLM-5.3；如果更看重算法实现、关键数字和证据推理，DeepSeek-V4-Pro 依然很有竞争力。
这轮国模一哥可以给 GLM-5.3，DeepSeek-V4-Pro 更像国模一哥们儿。
AI 模型正在从聊天窗口进入真实生产流程。
这轮 12 个 Case 涵盖办公文件、代码仓库、前端页面、3D 项目和长文档审查，模型需要读取材料、调用工具、运行测试，还要留下可以检查和继续使用的交付物。企业真正愿意付费的，正是这些能缩短工期、减少返工的能力。
GLM-5.3 在本轮拿到更多胜场，优势集中在完整交付。需要快速完成方案、原型或整套项目材料的任务，GLM-5.3 更容易接入现有工作流。
DeepSeek-V4-Pro 在关键计算、算法实现和事实核对上更稳。大文件排序、验收资料审查和 3D 模型结构都体现出扎实的底层能力。数据处理、核心代码和高风险审查对准确性要求更高，DeepSeek-V4-Pro 仍然值得优先考虑。
更现实的商业用法是按任务分配模型：GLM-5.3 负责需求覆盖、项目搭建和成品交付，DeepSeek-V4-Pro 负责关键计算、核心实现和结果复核。
国产模型的下一轮竞争，也会发生在这些真实工作里。