Sider Claw · 基准测试报告 · 2026-09-03

同一份需求说明书裁剪任务，六种模型与链路组合的耗时、成本与交付质量

用户上传一份 1.9 MB、746 段、191 张表的 Word 需求说明书和一份 48 个功能点的 Excel 清单，要求按清单裁剪文档并更名系统。六个会话提示词与附件完全相同。结论：思考档位比模型型号影响更大，同一个 gpt-5.6-luna 从 low 到 medium 到 high，质量 3 → 6.5 → 8，耗时 1.5 → 4 → 9.4 分钟；high 档是当前时间、成本、质量的最佳平衡；deepseek 在 OpenClaw 链路上 31 分钟的耗时有 88% 花在等待模型生成 token。

数据来源 claw.apps.wisebox.ai /api/session/{id}/messages 成本来源 Request Logs 按 Session ID 过滤 质量检查 python-docx + lxml 对照原文
会话 111:19
deepseek-v4-flash
OpenClaw 插件 · 默认档
耗时30.9 min
成本$0.382
工具调用132
质量6/10
会话 216:22
gpt-5.6-sol
harness · low
耗时4.0 min
成本$0.700
工具调用22
质量7/10
会话 316:30
deepseek-v4-flash
harness · low
耗时18.5 min
成本$0.186
工具调用66
质量7.5/10
会话 416:51
gpt-5.6-luna
harness · low
耗时1.5 min
成本$0.015
工具调用13
质量3/10
会话 5 · 推荐17:10
gpt-5.6-luna
harness · high
耗时9.4 min
成本$0.208
工具调用67
质量8/10
会话 617:30
gpt-5.6-luna
harness · medium
耗时4.0 min
成本$0.078
工具调用41
质量6.5/10

三张图、总览格与下文两张表都按会话 1 到 6 的顺序排列。成本取自请求日志页的 Total Cost；质量为本报告第三节的综合评分。

1. 任务与方法

用户提示词共五条要求：按功能清单只保留相关功能；把系统名从"业务中台运营支撑工具"改为"面向省侧中台服务智慧运营支撑软件"；在完整版基础上做删除而非重写；图片和表格同步裁剪并保持完整；保持文档连续性。原文关键规模如下。

原文指标数值与任务的关系
段落 / 表格 / 图片746 / 191 / 21业务流程分项说明下 36 个 H5 流程图，其中 6 个属于保留功能
共享融合需求16 条按"涉及流程"判断，9 条与保留功能相关或通用，7 条纯属已删模块
业务信息清单 / 明细表78 行 / 77 张清单行与明细表一一对应，删除时必须成对处理
修订标记 w:ins173 处原文带未接受的插入修订，全部在表格内
目录缓存悬空条目5 条参考资料、主要依据、4.6.2、附录两条在原文里就没有对应标题

每个会话的消息通过接口分页拉取，按 created_at 排序后拆分为 thinking、text、tool.call、tool.result 四类。交付的 docx 从 file-cdn 下载，与原文一起用同一套脚本检查 20 余项结构指标。

时间归因方法。同一步的 tool.result、thinking、text、tool.call 落库时间相差仅几十毫秒，说明 relay 是把上一次工具结果和下一次模型输出一起刷上来的。因此每条 tool.result 之前的间隔等于"工具执行时间 + 模型生成时间"，而工具的 duration_ms 大多只有 0.1 到 0.4 秒。会话 1 的 31 分钟里工具执行合计 147 秒，其余约 1640 秒都是等模型。

2. 速度与成本

项目会话 1会话 2会话 3会话 4会话 5会话 6
Session ID01M1JMF1AT28J5K22X7K3V8V7D01M1K5SCH62B94WZQJWE04273B01M1K675C1A41ZW92J6774WQ9501M1K7D23QB44EHT0EGNDY1PA701M1K8G8A0X2GZ0X98SCBMA82H01M1K9NSG74HPT3F43EN1YZCXP
链路OpenClaw 插件 1.0.43sider-harnesssider-harnesssider-harnesssider-harnesssider-harness
模型 / 思考档位deepseek-v4-flash-vision-rv / 默认gpt-5.6-sol / lowdeepseek-v4-flash-vision-rv / lowgpt-5.6-luna / lowgpt-5.6-luna / highgpt-5.6-luna / medium
开始时间11:19:5716:22:5416:30:2416:51:0917:10:2017:30:49
总时长30.9 min4.0 min18.5 min1.5 min9.4 min4.0 min
消息数4802569167044
工具调用1322266136741
LLM 请求数（日志）1312060136240
Input tokens19,739,894615,7296,997,528278,490——
Output tokens152,6187,68793,6214,412——
Cache Read 占比99.5%94.0%99.0%91.6%——
平均每请求上下文15.1 万3.1 万11.7 万2.1 万10.5 万5.9 万
thinking 字符40.2 万0.4 万29.9 万0.4 万2.4 万0.7 万
reasoning tokens（harness）—1,42687,2091,34822,0604,866
Total Cost$0.382$0.700$0.186$0.015$0.208$0.078
扣除积分—132035728322129
每分钟成本$0.012$0.175$0.010$0.010$0.022$0.019
单步最长等待71 s31 s93 s17 s92 s21 s
工具报错015033

会话 5、6 的 token 明细未在日志页截图中，平均上下文按 harness 记录的累计 cacheRead 推算（会话 5 为 62 次调用 653 万，会话 6 为 40 次调用 234 万）。积分与美元成本的换算在三个有记录的会话里都是每美元约 1900 积分，说明 luna 与 sol 的 46 倍价差来自模型单价而非计费系数。

deepseek 为什么慢

会话 1 与会话 3 的模型吞吐都稳定在每秒 310 到 340 字符。两者最慢的步骤全部是 thinking 超过 2 万字符的"规划"步骤，单步 50 到 93 秒，而对应的命令只有几百字节、执行不到半秒。会话 1 按阶段拆分如下。

阶段（会话 1）耗时调用数thinking 量
读文件 + 结构探索3.2 min1430k
修订标记（w:ins）清理2.0 min720k
章节 / 表格映射与规划5.3 min1888k
编写并运行 edit1 到 edit44.2 min1951k
图片 / TOC / 书签 / 图表目录清理6.9 min28111k
LibreOffice 转 PDF 失败排查0.8 min610k
一致性校验 + 反复修补 + 重打包5.8 min3075k
变更记录 + 交付发送1.6 min912k
skill_workshop 复盘（独立 run）1.1 min01k

同一 deepseek 模型换到 harness 链路后省下 12 分钟，原因是 harness 预置了附件、允许 heredoc 多行脚本，探针步数从 116 次 exec 降到 47 次，并且没有再走修订标记 unwrap 两次失败的弯路。但 deepseek 在两条链路上都表现出相同倾向：范围自我扩大，把 TOC 缓存、图表目录重编号、孤儿图片清理这些用户没要求的事做了一遍。

3. 交付物质量

六个 docx 全部下载后用同一套脚本对照原文检查。LibreOffice 在沙箱里连原文都打不开，本机也未安装，因此渲染效果未验证，以下全部是结构层面的结论。

检查项会话 1会话 2会话 3会话 4会话 5会话 6
一级章节完整4/44/44/43/4 第 5 章整章被删4/44/4
已删模块残留标题00012 个含正文00
旧系统名残留000000
流程 / 活动 / 步骤清单裁剪全部流程清单漏一行全部全未裁全部全部
业务信息清单行数382325783028
业务信息明细表4 张，缺 34 张23 张，一致25 张，一致26 张，51 个孤儿题注29 张，一致31 张，一致
BI 编号悬空引用041001
共享融合需求取舍留 3，误删 6留 9，误留 1留 8，误留 1整章删除留 9，十三/十六改写重编留 6，误删 4，误留 1
保留流程的活动表2525252524，少了服务评价24，少了服务评价
48 个功能点覆盖无新增功能范围表无无写进业务目标正文无
章节目录30 条，2 条继承目录域被删，页面空白37 条，4 条继承45 条，21 条悬空38 条，4 条继承45 条未清理，14 条悬空，已设打开时刷新
图表目录29 条悬空已删重建，0 错误54 条悬空重建，0 错误209 条未清理，115 条悬空
图片 / 文件大小干净 / 392 KB13 张孤儿 / 757 KB干净 / 418 KB13 张孤儿 / 771 KB干净 / 435 KB13 张孤儿 / 772 KB
修订标记 w:ins 残留05959795959
结构问题无书签不配对分节 5 变 4无书签不配对分节 5 变 4，书签不配对
修订记录表已填已填未填未填未填未填
改写量（段落 / 单元格）6 / 108 / 1236 / 56 / 313 / 2710 / 6
封面项目名直接改为系统名用清单里的科技项目名沿用旧模板句式改为"建设项目""设计开发实施项目""设计开发实施项目"
最终消息下载链接无链接，走 message 工具sandbox:/claw/…无链接裸 claw/…sandbox:/mnt/data/… 不存在sandbox:/mnt/data/… 不存在
XML 良构通过通过通过通过通过通过
综合评分677.5386.5

"继承"指原文目录本身就有的悬空条目，不算新引入。共享融合需求的"应保留"判定依据每条的"涉及流程"字段是否包含服务创建、上下架、白名单、待定区、能力地图、服务申请调用等保留流程。

4. 各会话要点

会话 1 · deepseek-v4-flash · OpenClaw 插件

01M1JMF1AT28J5K22X7K3V8V7D
耗时30.9 min
成本$0.382
工具调用132
质量6 / 10
  • 清理最彻底的版本：唯一接受了全部修订标记、图片全清、汇总表全裁剪，还填写了修订记录。
  • 严重错误：业务信息清单保留 38 条，对应明细表只剩 4 张，白名单指标维护表等保留功能的数据表被删。表目录里 29 条仍指向这些表。
  • 共享融合需求删得过头，四到七条各业务中台数据同步和十六条服务目录同步都与保留功能相关。
  • 116 条 python -c 探针逐块看 XML，全貌靠 thinking 拼出，仅"章节映射"和"TOC 清理"两个阶段就产生近 20 万字符 thinking。
  • 交付走 message 工具 send，交付后还有一个 69 秒的 skill_workshop 独立 run。

会话 2 · gpt-5.6-sol · harness · low

01M1K5SCH62B94WZQJWE04273B
耗时4.0 min
成本$0.700
工具调用22
质量7 / 10
  • 第二步就用 python-docx 把 xlsx、段落结构、191 张表一次性导出为三个文本文件，两三轮掌握全貌。
  • 唯一主动补了 48 个功能点清单表的版本，封面正确使用了清单里的科技项目名。
  • 目录域被整体删除，目录页只剩"目 录"和一个"图"字，打开时不会重建。其交付说明中"已设置目录打开时自动更新"与实际不符。
  • 流程清单仍留"应用管理"一行，4 个 BI 编号悬空，13 张孤儿图片使文件达 757 KB。
  • 五个会话里最贵，每分钟成本是其他会话的 8 到 17 倍。

会话 3 · deepseek-v4-flash · harness · low

01M1K675C1A41ZW92J6774WQ95
耗时18.5 min
成本$0.186
工具调用66
质量7.5 / 10
  • 内容一致性好：明细表与清单对得上，表目录是重建的，0 条错误。
  • 分节从 5 个变 4 个，页眉页脚文件从 5 个变 9 个，末尾章节的页面设置可能已变。
  • 封面仍是"企业中台-2022年…设计开发实施项目"旧句式，只换了括号里的名字。
  • 59 处修订插入标记未接受；工具报错 5 次，含两次脚本 bug 和三次 LibreOffice 加载失败。
  • 与会话 1 同样出现范围扩大：从 16:40 到 16:44 花 4 分钟重建前置列表。

会话 4 · gpt-5.6-luna · harness · low

01M1K7D23QB44EHT0EGNDY1PA7
耗时1.5 min
成本$0.015
工具调用13
质量3 / 10
  • 只看了 3 眼就按硬编码段落索引区间删除，第 5 章共享融合需求整章消失。
  • 业务流程分项说明下需求与服务受理、服务运营监测、系统配置三个小节连标题带正文都还在，共 12 个残留标题。
  • 四张汇总表一张未裁，业务信息清单仍为 78 条；按索引删了 51 张明细表但题注段落全部留下。
  • 第一步误读了 presentation 技能的 SKILL.md，与任务无关。
  • 这个版本交付给用户会被立刻退回。

会话 5 · gpt-5.6-luna · harness · high

01M1K8G8A0X2GZ0X98SCBMA82H
耗时9.4 min
成本$0.208
工具调用67
质量8 / 10
  • 前 4 分钟用 15 条探针看完 xlsx、段落、表格和 XML 域结构，一次写出 12.8 KB 脚本（这一步等待 92 秒），随后 18 次 edit 迭代修脚本并重跑校验。
  • 唯一做了内容改写而非只删除的版本：背景和业务目标按"省侧"口径重写，共享融合需求十三、十六改写后重编为八、九，业务目标段落逐条列出 48 个二级功能。
  • 一处越权：把"中台服务能力管理"全局改成"服务能力管理"，共 10 处，用户未要求。
  • 服务申请调用流程下的"服务评价"活动表被删，其他四版都保留了。59 处修订标记未接受，书签 3 处不配对，修订记录未填。
  • 最终消息里的下载链接指向 sandbox:/mnt/data/…，路径不存在，前端只能依赖消息中的 file 部件。

会话 6 · gpt-5.6-luna · harness · medium

01M1K9NSG74HPT3F43EN1YZCXP
耗时4.0 min
成本$0.078
工具调用41
质量6.5 / 10
  • 工作方式介于 low 与 high 之间：9 条探针后写了一个 7.8 KB 脚本，再用 9 次 edit 迭代，两次校验脚本因 heredoc 写错报错。
  • 正文清理到位：无残留标题，四张汇总表全裁，业务信息明细表 31 张与清单一致，业务活动改名为"省侧中台服务能力管理"。
  • 共享融合需求取舍最差：删掉了与保留功能相关的二、七、十六，却留下纯属告警指标的十五。
  • 前置目录完全没动：章节目录 45 条含 14 条悬空，图表目录 209 条含 115 条指向已删表，只设置了打开时刷新。Word 打开会提示更新域，WPS 或预览场景会看到过期目录。
  • 分节从 5 个变 4 个，13 张孤儿图片使文件仍有 772 KB，"服务评价"活动表同样被删，下载链接同样指向不存在的 sandbox:/mnt/data。

5. 结论与建议

结论 · 模型与档位

思考档位比模型型号影响更大

  • 同一个 luna 三档单调：low 1.5 分钟 / $0.015 / 3 分，medium 4 分钟 / $0.078 / 6.5 分，high 9.4 分钟 / $0.208 / 8 分。
  • medium 档正文已可用，缺的是前置目录清理和共享融合需求取舍；high 档补上了这两项。
  • deepseek 的吞吐固定在每秒 310 到 340 字符，low 档下规划步骤仍产生 2 万多字符 thinking，这是链路无法优化的。
结论 · 链路

链路是次因，决定步数而非单步速度

  • 同一 deepseek：OpenClaw 31 分钟，harness 18.5 分钟。
  • harness 的附件预置与 heredoc 多行脚本让探针步数减半，上下文膨胀相应减小。
结论 · 速度与质量

越快的会话验证越少

  • 会话 4 的 1.5 分钟是跳过表格行裁剪和功能点核对换来的。
  • 会话 1 的 31 分钟里有 7 分钟花在用户没要求的 TOC 清理上。
建议 · 路由

默认路由到 gpt-5.6-luna / high

  • 质量最高，成本与 deepseek 持平，时间是 deepseek 的一半，只有 sol 的 30% 成本。
  • 需要 4 分钟档位时选 luna / medium 而不是 sol / low：质量相近（6.5 对 7），成本只有九分之一。
  • sol 留给用户明确要求高质量且不在意成本的场景。
  • deepseek 在这类任务上没有性价比优势。
建议 · docx skill

补两条硬规则和一份收尾清单

  • 提供一次性"全文结构导出"脚本：段落索引、表格、标题层级、域代码，避免探针式拼图。
  • 删除前先建立"清单表行与明细表"的对应关系再成对删除。
  • 收尾清单：接受修订标记、清理或重建目录与图表目录、填写修订记录、核对 BI 悬空引用。六个版本没有一个全部做到。
建议 · 前端

下载链接以 file 部件为准

  • 六个会话出现 sandbox:/claw、裸 claw/、sandbox:/mnt/data 三种写法，luna 的三个会话里两个指向不存在的 /mnt/data。
  • 前端应忽略模型自己写的 markdown 链接，统一渲染消息中的 core.file 部件。

附录 · 数据与脚本

消息拉取使用会话消息接口并按 cursor 分页；会话 1 有 480 条消息分三页。质量检查脚本依赖 python-docx、lxml、openpyxl，主要检查项：

标题层级与已删模块残留 · 旧/新系统名计数 · FN01–FN48 与 48 个二级功能名覆盖
流程清单 / 业务活动清单 / 步骤清单 / 业务信息清单 行级裁剪
业务信息详单 明细表数 vs 题注段落数 · BI-xxx 引用 vs 定义（悬空）
共享融合需求：按"涉及流程"判断应保留集合，与各版本保留集合求差
目录缓存条目 vs 实际标题 · 图表目录条目 vs 实际题注 · TOC 域数 · updateFields
图片：drawing 数 / media 文件数 / 被引用数（孤儿）
w:ins / w:del 残留 · bookmarkStart/End 配对 · sectPr 数 · 页眉页脚文件数 · 每个 XML 部件良构
改写量：正文段落与表格单元格不在原文中逐字出现的数量

原始 JSON、六个交付文件与检查结果保存在分析会话的临时目录下的 s1 到 s6、files/ 与 quality.json。