真实案例 它平时干的活，长这样
从日常运行里挑了四段，都是桌面端的原始记录 —— 用户的原话、它自己的交付前自检、
被治理层拦下的那几步，以及它明确交回给人核对的地方。
用户原话 帮我将汇总版的excel文档拆分成多个excel文件，每个excel文件的行数不可超过5000行数据，需要保留原文件的表头
交给它1 个 xlsx 汇总表（分账记录业务月份模板）
产物 - 更新分账记录业务月份模板-1.xlsx ~ -15.xlsx
- 前 14 个各 ≈63 KB，第 15 个 22.3 KB
运行度量 21 步 · 22 轮 · 159s · 4 步被治理层拦下 · 132 in / 5505 out
交付前自检 - 原文件行数 71,465 行（不含表头）
- 表头 分账记录流水号 · 业务月份 · 业务月份补充说明
- 拆分文件数 15 个
- 每文件行数 第 1–14 个各 5,000 行，第 15 个 1,465 行
- 表头保留 ✓ 全部一致
- 总行数核对 14 × 5000 + 1465 = 71,465 ✓
交付结果：左侧是对话与自检表，右侧栏是 15 个产物文件，可单个打开或一次下载全部。 
同一段活的处理过程视图 —— 21 步逐条摊开。其中 4 步被治理层挡回：两次 mv / rm 越出了本次会话允许的工作目录，一次写入未获授权的路径；挡回之后它换了路子继续干活。（拒绝原因在对话里是原样展开的，本站截图对这几段做了模糊。） 这里没有一个叫「拆分工作簿」的按钮。它先写脚本探查表结构，再写拆分脚本，最后把总行数加回去对一遍 —— 14 × 5000 + 1465 = 71,465，对上了才说完成。自检要带得出数字，不然「已完成」只是一句话。
用户原话 请你把文件夹下的这几个excel文件合并成一个汇总的EXCEL文件，并汇总说明下数据情况
交给它1 个文件夹 · 3 个 xlsx（列名完全一致，共 20 列）
产物 - 支付流水汇总_2026年8月.xlsx（40.4 KB）
- 工作表 1「汇总明细」：301 行原始数据，含来源标记
- 工作表 2「门店汇总」：按门店聚合的笔数与金额
运行度量 10 步 · 12 轮 · 88s · 1 步被治理层拦下 · 66 in / 5373 out
保真自检 - 行数守恒 3 个源文件共 301 行 → 产物 301 行
- 标识符列 7 个标识符列全部文本格式，无科学计数法
- 抽查 随机 10 行逐字一致
- 合计 301 笔 · ¥3,421.00
- 状态分布 已支付 210 / 支付关闭 52 / 已退款 36 / 待支付 2 / 退款失败 1
- 时间跨度 2026-08-03 ~ 2026-08-31
它主动报出来的数据质量问题 - 第三方交易流水号 23.6% 为空 —— 多为会员卡余额支付，属正常
- 合单交易流水号 83.4% 为空 —— 非合单交易，属正常
- 交易时间 18.3% 为空 —— 主要集中在「支付关闭」状态
它先探查三个表的结构、处理掉一个挡住 Python 标准库的同名旧脚本，再写合并脚本。 
交付结果：状态与支付方式分布（两个维度各自加总都等于 301）、数据质量提示、保真自检结论。 它没有只交一个文件走人。合并之前它先看了三个表的结构，发现有 7 列是订单号、流水号这类标识符，必须按文本保留（否则 Excel 会把长数字变成科学计数法，一张表就毁了）；合并之后它报出三列的空值比例，并逐一说明「这个空是正常的」。不替你美化数据，也不让你自己去发现坑。
用户原话 帮我把当前文件夹下的发票PDF文件合并成一个汇总的PDF文件
交给它1 个文件夹 · 29 个 PDF
产物 - 发票汇总_29份.pdf（1.8 MB，29 页）
运行度量 2 步 · 3 轮 · 34s · 0 步被拦下 · 18 in / 2294 out
交付前自检 - 输入 29 个发票 PDF
- 产物 1 个汇总 PDF，共 29 页
- 页数核对 29 个文件 → 29 页 ✓
一句话、两步、34 秒。右侧栏是可直接打开的产物。 这段记录的看点是它的便宜：2 步、3 轮、34 秒、2294 个输出 token，没有一次多余的探查。简单的活就该简单地干完 —— 复杂度按任务给，不是按功能给。同一个引擎，上一段用了 21 步，这一段只用 2 步。
用户原话 帮我将当前文件夹下的所有发票票面信息都提取到同一个excel表格中
交给它1 个文件夹 · 49 个发票 PDF（六种票种混在一起）
产物 运行度量 51 步 · 55 轮 · 1208s（约 20 分钟）· 2 步被治理层拦下 · 282 in / 74185 out
交付前自检 - PDF 总数 49 张
- 汇总表行数 51 行 —— 地铁那张 PDF 里贴了 3 张定额发票，拆开成 3 行
- 类型分布 全电票 25 / 增值税电普 18 / 通用机打 2 / 铁路客票 2 / 交通全电 1 / 定额 3 = 51
- 金额合计 ¥14,131.51
- 税额合计 ¥938.14
- 价税合计 ¥15,069.65
- 提取方法 48 张有内嵌文本 → 直接取字 + 正则解析；1 张地铁扫描件 → 渲染后 OCR
- 表格保真 标识符列按文本写入并设
@ 格式；金额列按数值保留两位小数 - 读回自检 行数守恒 · 标识符长度分布一致 · 抽样 10 行逐字比对通过
它点名交回给人核对的三处 - 3 张加油发票：这几张 PDF 的数据区顺序特殊（销方税号出现在购方税号之前），导致购方 / 销方税号两列颠倒，需要人工互换
- 3 张地铁定额发票：票面上本来就没有开票日期，该列留空
- 2 张铁路客票：票面没有单独税额，税额合计留空
先探查、再动手：查有没有预抽的文字层 → 抽一张看内嵌文本 → 批量探测 49 张分成两组 → 多抽几张不同票种验证正则 → 才开始提取。 
交付结果：处理结果、提取方法、表格保真自检，以及最下面那段「需要你手动核对的地方」。 这一段正好是「能举证才有结论」在实际运行里的样子。它没有把颠倒的税号悄悄塞进表里，也没有给缺失的开票日期编一个值 —— 它把三处说不清的地方点名交回给人，并说清为什么说不清（票面本来就没有 / PDF 数据区顺序特殊）。同时它也不怕慢：20 分钟、51 步，先查有没有现成的文字层和契约定义、再抽一张看内嵌文本、再批量探测 49 张分成两组、再多抽几张不同票种验证正则 —— 六轮试探之后才动手提取。