今天發點新模型對抗測評相關的東西。
國產大模型最近連出兩員大將：DeepSeek-V4-Pro 和 GLM-5.3。
兩款模型發佈後，網上的評價不統一，只看跑分很難判斷真實差距。
所以這次不聊參數，直接上任務，讓兩款模型使用相同提示詞、相同材料和相同交付要求逐項完成。
兩款模型均在 Claude Code 中運行，擁有相同權限和相同初始文件；每個 Case 只運行一次，沒有針對單個模型調整提示詞。
跑完看看，誰是國模一哥，誰是國模一哥們兒。
01. 模型實測
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沒有凍結表頭，列寬拉得很大，數據表瀏覽體驗一般。
Word沒有圖表。
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 在組合完整性和交付形式上領先。
02. 實測總結
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 更像國模一哥們兒。
03. 挖一挖
AI 模型正在從聊天窗口進入真實生產流程。
這輪 12 個 Case 涵蓋辦公文件、代碼倉庫、前端頁面、3D 項目和長文檔審查，模型需要讀取材料、調用工具、運行測試，還要留下可以檢查和繼續使用的交付物。企業真正願意付費的，正是這些能縮短工期、減少返工的能力。
GLM-5.3 在本輪拿到更多勝場，優勢集中在完整交付。需要快速完成方案、原型或整套項目材料的任務，GLM-5.3 更容易接入現有工作流。
DeepSeek-V4-Pro 在關鍵計算、算法實現和事實覈對上更穩。大文件排序、驗收資料審查和 3D 模型結構都體現出紮實的底層能力。數據處理、核心代碼和高風險審查對準確性要求更高，DeepSeek-V4-Pro 仍然值得優先考慮。
更現實的商業用法是按任務分配模型：GLM-5.3 負責需求覆蓋、項目搭建和成品交付，DeepSeek-V4-Pro 負責關鍵計算、核心實現和結果複覈。
國產模型的下一輪競爭，也會發生在這些真實工作裏。
原文鏈接：DeepSeek V4 Pro 正式版 VS GLM-5.3，誰更勝一籌
