正在加载…
先看它交的作业
这是一份纽约市 311 系统住房类工单的季度复盘，十五万多条数据，作者让它站在运营负责人的角度分析：
这一屏里藏着三件值得说的事。
第一，它没有停在表面。 月报口径显示处理时长在涨，看着像效率下降该加人了。它往下拆了一层，发现是品类结构变了：处理最快的暖气类工单随着供暖季结束大量消失，把整体中位数抬了上去。同口径再看，13 个品类里 12 个都在变快。这是统计学里经典的辛普森悖论，它自己撞上、自己拆对了。
第二，它把口径分歧摆在明面上。 32.4% 的工单是以「没能进门」结案的，官方口径全算达成。所以达成率是 86.5% 还是 49.5%，取决于你认哪个口径。它没有替你选，两个都给你，让你自己决定对外说哪个。
第三，它承认自己算不出来的东西。 这份数据里根本没有 SLA 这个字段，十五万行全是空的。它没有硬编一个出来，而是明说「这个数不可能从这份数据本身算出来」，然后用纽约市在别处公布的承诺线来替代，并逐条标注来源。
再看一份，一百零六万行的英国电商交易明细，给销售负责人做业绩复盘：
标题直接把结论写在脸上：表面的营收增长，是新品补出来的。两年都在卖的三千多个老商品营收掉了 12.9%，新品填上了窟窿，而同期整个英国线上大盘还在两位数扩张。
然后它顺势把问题改写了。导语里那句我特别喜欢：明年预算的问题不是「投国内还是投海外」，是「先止血还是先扩张」。这就是从「发生了什么」推到「所以该做什么」。
这份数据里还有一万多个转不成数字的发票号。它没有静默丢掉，而是逐个去看，查出 C 开头的是取消单、A 开头的是坏账调整，甚至从商品代码里摸出了这家公司上线新销售渠道的时间点。那一万多个脏值，最后一个个都成了业务线索。
三个我觉得特别聪明的设计
它的工作流是八步：体检、清洗、对齐、分析、对账、交付、验图、质控。听着很重，但实际是按需走的，查一个数就直接查，要报告才全走。这八步里有三个地方值得单独讲。
第一个是体检。
大部分工具拿到表的第一件事是直接读进来。但读进来那一刻，合并单元格、单元格格式、原始类型就全丢了，之后所有判断都建立在损坏的信息上。
作者实测过一份典型的中国式销售表：标题占两行、两级表头、中间夹着「华东小计」、尾巴三行是合计。用「找对表头加清掉千分位」这种看着挺周全的做法去算月度总额，结果比真值高出 161%，零报错、零警告。
所以这个 Skill 先去读原始单元格做体检，把表头在哪、哪几行混着标题和小计、哪些列有猫腻全列出来，然后才开始算。
第二个是对账。
表里的「合计」行，几乎所有工具都当噪音过滤掉。但作者的看法不一样：那是原表作者用公式算出来的真值，等于一个免费的校验和。
所以它会拿清洗后的明细自己求和，去对表里自带的合计。测试的时候揪出过一个差 10 块钱的错，表内小计写 6,490,430，明细算出来 6,490,420。相对误差 0.00%，肉眼永远发现不了，后来查明是造表的人手填小计时填错的。
第三个是质控，我觉得这个最狠。
数字全对账、脚本全跑通，结论仍然可能是错的，而且你自己查不出来。因为那个分析窗口是你自己挑的，你看它的时候带着「它应该成立」的预期。
所以最后一步是另派一个没参与前面工作的 AI，从原始数据重算一遍，专门来拆台：这个时间段是不是挑出来的？外部基准的分母对得上吗？「已剔除某某偏差」这类话，代码里真做到了吗？
这一步不是多余的。作者举了个例子：市政预算那份数据，第一版算出来行数守恒、金额恒等、内部校验全绿，拿去对外部权威数字，错了整整一个财年。因为那份数据的列名和字面意思对不上。内部校验全对的报告，可以整体错一个财年，而且没有任何内部检查能发现。
看到这儿，后面是学员专属
后面这一半是训练营学员的内容。你要是学员，用手机号登录就能接着往下看。