夜雨聆风前段时间做完一场 AI 通识分享后，陆续有同事来找我，问能不能帮他们处理一些工作里重复、耗时间的事情。
我当然可以直接帮忙做一次，但总觉得这样不太够。
授人以鱼，不如授人以渔。
这几次看下来，我反而觉得，行政部门先不用急着做大系统。
能不能先把每天反复处理的 Excel 做顺，可能更实际。
加班统计表要按部门拆，采购明细要一条条对，财务那边也经常要核数量、核金额、核状态。
这些活不难，但人坐在电脑前点半天，最烦的是怕漏、怕错、怕格式一乱又要返工。
复制、筛选、拆分、核对、改格式、查漏项。
一次两次还好，每个月甚至每周都来一遍，就很容易变成一件让人烦的事。
我想借最近两个表格案例，聊一个更实际的话题：行政部门怎么开始做 AI 小工具。
我想写的不是一篇教大家写代码的文章。
更想说的是：先把你每天怎么处理这张表说清楚，后面的工具才知道该怎么做。
先看一张表
很多人一提到 AI 落地，就容易往大系统上想。
要不要上知识库？要不要做智能客服？要不要连企业微信？要不要做一个部门级平台？
这些当然都可以做，但不一定是第一步。
我更愿意先看一个很小的场景：这张表现在是谁在处理？他每次要点哪些按钮？要复制哪些字段？最后要交付给谁？中间最容易错在哪里？
问到这一步，工具就不再是空的想法了。
它至少知道要处理哪张表，替谁省哪几步。
比如人力部门的加班统计。
原来有一张总表，需要按部门或者某个维度拆成多个分表。这个动作本身不复杂，人工也能做，但每次都要重复筛选、复制、另存。后来同事用国产 Agent / 低代码工具做了拆分功能，确实已经省了一大步。
但真正用起来，又发现一个问题：拆出来的数据是对的，表头格式却没保住。
尤其前两行，一行是标题，一行是字段表头。原表里有合并单元格、字体、边框、填充、对齐、行高、列宽，拆完以后这些东西丢了，业务同事还得一个文件一个文件重新调。
这时候就能看出一个小工具有没有真正做完。
对写工具的人来说，可能会觉得：数据已经拆出来了。
但对实际用表的人来说，事情还没结束。因为这张表最后不是放在程序里看的，而是要发出去、存档、给别人继续用。
格式也算结果。
如果导出的表还要人工再整理一遍，那这个工具只是把工作挪了一下，没有真正把人从重复动作里解出来。
格式也算结果
这个细节很容易被忽略。
很多表格自动化一开始只盯着数据：这一列是什么，那一列是什么，筛选条件是什么，最后生成多少行。
这些当然重要。
但在很多行政场景里，格式不是装饰，它就是交付的一部分。
表头要不要保留？标题是不是合并单元格？字段行是不是有固定颜色？列宽是不是刚好能显示完整内容？行高是不是能直接打印？这些看起来是“小事”，但决定了业务同事拿到结果后能不能直接发。
所以做这类小工具时，不能只把 Excel 当成一堆数据。
它还是一个业务文件。
一个能真正落地的表格工具，至少要同时关心两件事：数据有没有处理对，输出能不能直接用。
这也是我觉得行政类 AI 工具很有价值的地方。
这类工具没必要做得很花。
只要同事打开导出文件时不用再挨个调表头，心里就会觉得：这东西确实帮我省事了。
这个案例还有一个提醒：会用 Agent 搭工具，和会选模型，是两件事。
有些问题不是业务规则没讲清楚，而是模型能力不适合。比如处理 Excel 格式、生成代码、修改工具逻辑，这类任务更考验代码能力和长上下文理解。国产路线里，如果是编码和 Agent 工具开发，可以考虑把 DeepSeek API 配置到 WorkBuddy/CodeBuddy 这类工具里，模型优先选 deepseek-v4-pro；如果任务明显涉及图片、截图、视觉理解，再考虑豆包这类多模态能力更强的工具。
这里不是做模型排行榜，而是提醒一句：不要只问“能不能用 AI 做”，还要看“用哪个模型做更合适”。
对账不能靠猜
另一个案例是采购对账。
这个场景比拆表更敏感一点。
一边是系统里的未结算明细，另一边是供应链相关系统里的未结算明细。业务上要判断哪些明细可以开票，哪些需要拿出来复核。
这里就不能让 AI “看着差不多”去判断。
我们最后整理出来的规则，是用“采购订单号 + 行号”作为主键。这个字段原始表里不一定现成存在，那工具就自动从两边的字段里拼出来。
一边用采购凭证和项目号生成编码，另一边用采购订单号和订单行号生成编码。编码对应上以后，再看数量是不是一致。
能确定匹配的，进入可开票明细。
数量不一致、一边有一边没有、或者出现更复杂的多对多情况，就先放进异常明细，让业务人员复核。
这一步我觉得很关键。
AI 可以帮忙整理规则，可以帮忙生成工具，也可以帮忙解释异常。但在对账、开票这种场景里，暂时它不能替人类做最终决策。
规则能确定的，就按规则处理。
规则不能确定的，就老老实实标出来，让人看。
这样做看起来保守，但业务上更让人放心。因为工具不是为了显得聪明，而是为了减少重复劳动，同时把风险留在可复核的位置。
把规则说清楚
两个案例放在一起看，会发现它们其实有一个共同点。
行政表格工作通常不是完全没有规则，而是规则藏在人的手上。
比如这张表先看哪一列，哪几类行要留下，数量要不要合并，相同订单号碰到多行时怎么处理，哪些情况必须停下来让人看。平时这些动作都在手上，真让他写出来，反而需要重新想一遍。
AI 小工具要落地，第一步不是写代码，而是把这些手工经验摊开。
我现在会把这类需求拆成五件事：
输入表 + 处理规则 + 目标结果 + 异常边界 + 样例验证 = 可自动化小工具输入表，就是有哪些文件、哪些子表、哪些字段。
处理规则，就是按什么字段分组、匹配、筛选、计算。
目标结果，就是最后要生成什么文件、什么表、什么字段，格式要不要保留。
异常边界，就是哪些情况工具不能自动处理，必须交给人复核。
样例验证，就是拿一份人工处理过的正确结果，看看工具跑出来是不是一致。
只要这五件事能讲清楚，后面不管是做网页小工具、低代码工具、AI 编程项目，还是 WorkBuddy 这类 Agent 工作流，都知道该从哪里下手。
反过来，如果这五件事讲不清楚，就算工具再先进，也很容易变成“这次好像能用，下次换个表又不行”。
不用先学编程
所以我不太建议一上来就跟行政同事讲代码。
很多人听到代码就会本能地往后退。
但如果换一种说法，事情就容易多了：你不用先学编程，你先把自己每天怎么处理这张表写下来。
可以按这个模板写：
表格自动化需求说明 1. 我现在手工在做什么 说明当前人工流程。 2. 输入文件是什么 文件名、子表名、关键字段。 3. 输出结果是什么 要生成哪些文件或子表，字段和命名规则是什么。 4. 处理规则是什么 按 1、2、3、4 写清楚每一步规则。 5. 异常情况怎么处理 数量不一致、缺失、重复、无法判断时怎么办。 6. 给一个样例 提供原始表和人工处理后的正确结果。 7. 验收标准 例如行数、数量合计、文件数量、格式要求等。这个模板看起来很普通，但它能把很多模糊需求拉回地面。
业务同事提供样例和规则，AI 帮忙整理输入、输出、异常和测试用例。再往后，可以让技术同事或者 AI 编程工具把它做成网页小工具、低代码组件，或者部门内部的工作流。
如果觉得打字麻烦，也可以先用语音输入把流程说出来。我之前也提到过 Typeless、闪电说这类语音输入工具，适合先把脑子里的操作步骤倒出来，再让 AI 帮忙整理成一份需求说明。
做完以后，不是靠感觉说“应该可以”，而是用样例做回归验证。
行数对不对，数量合计对不对，文件数量对不对，格式有没有保留，异常有没有单独列出来。
这些都能对上，工具才算真的能用。
先做小而准
我觉得行政部门用 AI，不一定要从宏大方案开始。
第一步可以很小。
就找一张最常被处理、最容易出错、最让人烦的表，把它拆开看。
如果这张表每个月都要处理，如果每次都要重复 30 分钟到 2 个小时，如果处理错了还会影响后面的核对、开票、统计或者汇报，那它就值得被做成一个小工具。
真正有用的 AI 小工具，往往不是炫技，而是让一张表少折腾一遍。
它帮业务同事省掉重复动作，也逼着我们把原来靠经验做的事情写成规则。
先把这张表的处理办法写清楚，再让工具照着做。
做出来以后，拿旧样例对一遍。
对得上，才交给别人用。
