干数仓运维这些年，我早上有一套固定仪式：打开调度平台看昨晚有没有任务挂掉，切到监控大盘扫一眼数据量，开个查询窗口跑几条 SQL 确认核心表的数据到位没有，最后翻翻告警记录。顺利的话二十分钟。不顺利就说不好了，某张表数据量掉三成，或者一个任务连挂三次，接下来看日志、查执行计划、捋上下游依赖，有时候还得翻历史数据比对，一个上午就交代进去了。
这些事不难，难的是每一步都得有人盯着，由人决定下一步看哪里。
上周一次值班，这套流程我只花了两小时，顺手还多干了两件事。快是真快，但让我琢磨的不是这个。
把巡检交出去
那天我没自己动手，把活儿交给了 AI。prompt 就一句话：对账单 workspace 做一次运维巡检，查连接状态、过去 24 小时的任务健康度、核心账单表的数据时效性、最近 7 天的数据量趋势、主要字段的数据质量，最后给我一份结构化报告。我没说查哪张表，连字段名都没提。
它先确认连接：巡检使用的用户身份，巡检目标的工作空间。然后开始跑。过去 24 小时的任务，SUCCEED 755,294 条，FAILED 1,690 条，成功率 99.66%，平均执行 0.15 秒，最长的一个跑了 422 秒。99.66% 听着挺好，它却把这条标成了"需要关注"，理由是 1,690 条失败是个绝对数字，比率好看不等于没事。422 秒那个任务也被单独拎出来了。 查时效性的时候出了个小插曲。它猜 billing_summary_mv 上有 billing_month 和 updated_at 这两个字段，账单表嘛，一般都有。结果查询报了语义分析错误，字段不存在。它没回头问我字段名是什么，自己跑了条 DESCRIBE，拿到全部 36 个字段，看到分区字段是 ds，换 ds 重查，最新数据就是当天，时效正常。我是事后翻执行记录才看到这段的，心想，这也行？
顺带它还翻出一个盲点：created_at 全表是 NULL。谁以后想拿写入时间判断时效，这条路走不通。它记了一笔，建议确认要不要补写入逻辑。
最近 7 天的数据量，前六天稳定在 8,700 到 9,700 之间，当天只有 4,375 条，日均的一半不到。我心里咯噔一下，“上游不会断了吧”。它给的标注要平和得多：当天数据尚未完整写入，建议下午再次确认。想想也对，先放着。
然后是那个数字。amount 为 NULL 的记录占 17.4%。这个比例放在哪张核心表上都不小。可能是历史迁移留下的，也可能某些内部计量项没有对客收费。它标注了“严重”，结论等着我来做。
报告最后分六个部分，每部分都有具体数字，没有一个含糊的形容词。我直接转给了团队，一个字没改。
但我盯着其中两条记录看了很久。猜错字段名的时候，它连问都没问我一声，自己就改了 ；碰到 17.4%，它明明可以顺嘴编一句“历史遗留，无需处理”，却一个字的结论都不给 。同一个 AI，一边胆子大得吓人，一边又谨慎得过分 。
同一套规矩的两面
后来我想明白了，这两个行为是同一套规矩的两面。
“怎么做”这一层，整个归AI。我说要什么，它负责找方法：挑哪张表、写什么 SQL、猜字段名、猜错了改，全是它领域里的事。字段名猜错属于领域内部矛盾，翻不出它的手心，也轮不到我操心。它的大胆是这么来的。
“判断”这一层，AI的权力依赖上下文（context） 。15 个离线同步失败该不该关注，把数字摆一起算，上下文全在数据里，它直接给出判断了。17.4% 是不是问题，答案显然不在任何一张表里，在账单系统当年的设计决定里，在上游团队的记忆里。上下文 在它够不着的地方就只把数字摆出来，无从下手判断。AI做不到克制，因为上下文没有相关信息。
别误会，它不是不出错。字段名照样猜错，SQL 照样可能写歪。只是这些错落在它自己的领地里（随着AI能力越来越强，错误率是可以改进的）
十几条 SQL 都是它写的，连字段名猜错了都自己改了。但 17.4% 算不算问题，AI的报告里留空等我填。
18.7 分钟的刷新链路
真正值得拆的，是 05刷新明细表 这条链路。它不是一条 SQL 慢，而是 26 条刷新语句串行跑完，整条任务耗时 18.7 分钟。AI 先没急着下结论，而是把每个物化视图和动态表的耗时排了一遍，结果很直观：vc_cru_calculate 308 秒，igs_detail_mv 206 秒，ai_gateway_token_billing_detail_mv 178 秒，前三个加起来占了 62%。
这就把问题从“任务慢”改成了“哪几步慢”。再往 profile 里看，三步慢法还不一样。vc_cru_calculate 的问题是数据倾斜，一个 stage 的倾斜比到了 15.46，后面还有 DOP=1 的串行阶段；igs_detail_mv 更像被单点卡住了，前面 1.9GB 数据 5 秒扫完，最后 208MB 输入却在单线程 stage 上跑了 185 秒；ai_gateway_token_billing_detail_mv 则是全表扫描，60.1GB 扫进去，最后只剩 100MB 输出。
这些数字摆出来以后，优化方向也跟着变清楚了。倾斜的要查 GROUP BY 和 JOIN key，热点 key 该预聚合就预聚合，该加 salt 就加 salt；单线程的要看是不是无分区 ORDER BY、单值 DISTRIBUTE BY，或者写入阶段被强制串行；全表扫描的优先补时间分区过滤，能只刷当天就别把 60GB 全扫一遍。
这份分析我自己也能做，但通常要在任务列表、SQL、job profile、stage 明细之间来回切。它省掉的是这段体力活：先把 26 条链路排出优先级，再把前三个瓶颈拆成倾斜、串行、全表扫描三类，最后给出能落地的改法。报告里甚至把预期收益也排了出来，先动 igs_detail_mv 的单线程阶段和 ai_gateway_token_billing_detail_mv 的全表扫描，收益最直接。
但最后那一步还是不能替我拍板。加 salt 会不会影响账单口径，增量刷新能不能覆盖迟到数据，按当天分区裁剪会不会漏掉补写数据，这些答案不在 profile 里。AI 能把慢拆成几个可验证的技术原因，也能告诉我先动哪一刀最划算；刀该不该落下，还是得有人知道这条账单链路到底承诺了什么。
顺手补个数
下午等数据追上来的空档，我把第三件事做了。billing_summary_mv 有张下游汇总表 daily_report 缺数据，要补跑。我让它包办全程：建表、建任务、配调度、上线、执行、验证。
有个细节我记了下来。建任务前它发现系统里已经躺着一个叫 daily_report_etl 的草稿态任务，不知道谁哪次留下的。它没另建，直接复用，改了 SQL 和调度配置。换我自己做，八成图省事新建一个，回头系统里两个同名任务，下一个值班的人得猜哪个是真的。
验证完，它把任务下线了。这步没人提醒。忘了下线，这任务每天凌晨两点会自己跑一遍，重复数据就来了。从保存任务到下线一共八步，每步都有理由，没有一步多余。
多出来的半天
三件事干完，下午三点不到。多出来的半天，让我想明白一件以前没想过的事。
我们不是不知道主动巡检好。查得勤，问题发现得早，修起来就便宜，道理谁都懂。但一次完整巡检要写十几条 SQL，在四五个工具之间切来切去，最后还得把结果攒成报告。这么贵的事，谁天天做？所以才形成了痼疾，巡检长期靠告警兜底，靠值班人的手感补漏。
现在一句话换一份报告，巡检便宜了，频率才上得去。往前追一步，便宜是因为写 SQL、切工具这些活儿都不归我了。归属变了，我的时间成本才降下来的。频率提高、发现得早，都是从这儿来的。
这条判断的边界也不是固定的。17.4% 今天要我拍板，是因为“哪些账单类型没有 workspace 维度”这类知识只存在人脑子里。哪天有人把它写进文档，文档进了它的上下文，下次巡检它就自动把这条判掉了。上下文挪到哪，边界就到哪。
顺着想下去，有个结论让我自己自己也觉得后背发凉：以后运维文档的第一读者，可能是 AI，不是下一个值班的同事。文档写得全，它能替你判断的多，那条线就越往后退，退到只剩没法写成文档的部分——没发生过的事，没定过的规矩 。 写文档这件常年被当负担的事，快要变成给自己扩产能了。
干这行的人，也在变。会写 SQL、记得住调度平台哪个菜单藏着什么按钮，这些本事在贬值；能看着一份报告能说出“这个数不对，去查上游”，这个在升值 。
下午四点，我又看了一眼那张表。4,375 变成了 8,900，今天的数据追上来了，虚惊一场。
这个“再看一眼”，还是我的活儿。
文中的活儿，是谁干的
那天值班用的是云器 Lakehouse 的命令行工具 cz-cli 。 文章里它干的三件事，对应三块能力：
- 巡检报告，来自自然语言直接查数——查哪张表、写什么 SQL 都是它自己定的，字段猜错了自己 DESCRIBE 纠错；
- 慢查询那段分析，来自异步执行加 job profile——算子级耗时直接在会话里读，不用切去控制台翻；
- 回填过程，来自任务和调度管理——建表、配调度、上线、下线，一个会话走完，中途不用碰第二个工具。
如果你也想试试，可以参考我那天用的 prompt ：
对 XX workspace 做一次运维巡检，检查连接状态、过去 24 小时任务健康度、核心表数据时效性、最近 7 天数据量趋势、主要字段数据质量，最后输出一份结构化巡检报告。
一句话就够了
试用入口：请访问cz-cli.ai体验，或扫描下方二维码加入cz-cli交流群！
🎁 新用户专享福利
✅ 1 TB 存储 · 1 CRU时/天计算 · 1 年全托管体验
➤ 即刻访问云器官网领取：https://www.yunqi.tech/product/one-year-package
