两个字「深圳」,差点毁掉我的自动化系统

一个成熟的自动化系统，最脆弱的地方，往往就藏在基准数据里的两个字。

两个月前，我写了一个叫 bankclean 的自动化技能。它接管的是一件看起来不复杂、做起来极耗人的事：把每个月下载下来的银行流水和回单整理规范，统一清洗成财务系统能直接使用的格式，再给出质检报告，第一时间洞察财务数据。

前面三篇，我分别写了它解决了什么问题、规则是怎么长出来的、清洗引擎又是怎么搭起来的。到这一篇，我想讲交付之后的事。

听起来没什么了不起。但 6 家公司、23 家银行、58 个账号、每个月几千条流水，每家银行的导出格式都不一样——这个"简单"的工作，之前每个月要耗掉3-5天甚至更长的时间。bankclean 把它变成了三十分钟不到。

先别急着讲规则，先看结果。下面这张图把原始文件、整理后目录和清洗后结果放在了一起，bankclean 到底替我接管了哪一段工作，一眼就能看清。

它省下来的从来不只是点击次数，而是每个月反复整理、核对、返工的那几天。

上个月，我以为这件事已经做到了头。

然后 7 月 2 日凌晨，一条消息改变了这个想法。

凌晨的发现

7 月 2 日凌晨，bankclean 刚把泰恒牧业的 30 条银行流水推送进【进销存】系统，表面上看一切正常。

但我打开【进销存】核对数据时，发现内部往来对不上——有两笔差额，怎么也对不齐。直觉告诉我，问题可能不在数据本身，而在某个更基础的地方。

于是我切回 Claude Code，给 skill 发了一条指令：

"查看一下 skill 中的开户行配置表，泰恒牧业华夏银行的开户行名称、账号，再对比一下进销存。"

配置表 bank-accounts.md——这是 bankclean skill的核心配置文件，记录了每家公司每个银行账户的全称和账号，清洗脚本会从这张表读取开户行名称填入每一笔流水。skill反馈泰恒牧业的那一行——

华夏银行深圳xx支行。

再打开【进销存】文件，找到泰恒牧业的"银行余额表"，同一行写的是——

华夏银行xx支行。

少了"深圳"两个字。

两秒钟的静默。然后我意识到：不只是华夏银行。农商银行也一样——配置表写的是深圳农商银行xx支行，【进销存】里写的是农商银行xx支行。

又是"深圳"。

那一刻我立刻明白：这不是一个命名小误差，而是一条会顺着系统往下游扩散的线索。

图里看着只差两个字，落到真实数据里，已经足够把整条链路带偏。

两个字，四层污染

这两个字的后果，远比看起来严重。

bankclean 的清洗脚本在填充每一笔流水时，会从配置表读取开户行全称，写入本方开户行 字段。

内部往来对账时，如果对方是本公司其他账户，还会从配置表反查 对方开户行。集团往来对账时，如果对方是集团内其他公司，也会填对方的开户行。

也就是说，配置表里多出来的这两个字，会污染三个字段：本方开户行、对方名称中的银行填充、对方开户行。 而且不只是泰恒牧业自己的流水——其他公司如果跟泰恒牧业的华夏或农商有往来，对方开户行也会写错。

我先修了配置表——去掉"深圳"。然后打开泰恒牧业清洗后的 Excel，逐行扫描。

华夏和农商两组里，本方开户行写了旧名。对方名称中由结息、手续费等规则填充的银行名，也带了"深圳"。对方开户行，同样带了旧名。

共计 49 处。

修完清洗后数据，再打开已经推送的【进销存】文件。那 30 行里有 26 处旧名称——因为推送时用的就是修正前的清洗数据。

一层一层修完，还有一个问题悬在头顶：其他公司清洗后数据里，有没有引用泰恒牧业华夏/农商的旧名当对方开户行？

排查结果：泰恒牧业唯一一笔跨公司往来——广发银行收锦程科创的款——对方开户行填的是锦程科创的华夏银行，名称本身就是正确的。没有传播。虚惊一场。

但这让我背脊发凉。如果跨公司往来再多几笔，污染的就不是 49 处，而是几百处。

而且这种错误，不是靠质检里那种"字段是否为空"就能查出来的。两个名称都合法，只是一个是【进销存】的历史口径，一个是配置表的新口径。质检不可能知道哪个才是"对"的。

下面这张图，就是我当时脑子里迅速展开的风险路径。

看到这条路径之后，我做的第一件事，不是继续猜，而是把所有基准逐条翻出来核。

所以才有了那次逐条比对

修完泰恒牧业，我向claude code发了一条新指令：

"现在，先检查 skill 中的开户行配置表与进销存中的'银行余额表' sheet 中的开户行是否全部一致。"

全部。 不是只查泰恒牧业。是全部 6 家公司。

【进销存】的"银行余额表"在每个公司的【进销存】文件里，横向从 A6 到 H6，包含开户行全称和账号。锦程科创那张表最长——连标题行一共 24 行。

我写了一个对比脚本，遍历 6 家公司的【进销存】文件，提取银行余额表的所有开户行-账号对，与bank-accounts.md的配置逐条比对。过滤掉贷款配置区、缴税配置区、空白行，只留真正有流水交易的活跃账户。

结果出来了：

58 个活跃账户，只有 2 处不一致——都在泰恒牧业。但这两处不一致，足以让内部往来平衡校验全部失效。

也就是在这次逐条比对之后，bank-accounts.md 多了一条最高优先级的铁律：

开户行名称以【进销存】"银行余额表"为准，不得自行命名。任何新增/修改开户行前，必须先读取【进销存】文件中该公司的"银行余额表" Sheet（A6:H6 起），以【进销存】的历史名称覆盖配置。

不是"建议"。不是"提醒"。是铁律。

因为配置表的一个字，会通过规则引擎的层层引用，污染清洗后数据、推送后的【进销存】、内部往来对账、集团往来统计——每一个环节。自动化系统的残酷之处在于：你给它的基准数据，它会毫不怀疑地用到所有地方。

所以那次逐条比对，核的已经不是 58 个名称，而是整个系统还能不能继续相信自己的基准。

也正是从这里开始，经验不再只是经验，而是被写成了不能破例的铁律。

这个故事里不只有深圳

其实，"深圳"只是这次迭代里最醒目的一处。真正让我警觉的是，同一轮排查里，系统又连续露出了另外三条裂缝：

"手续费"漏了。 昌隆生态浙商银行有一笔手续费，对方名称就只有"手续费"三个字；而关键词表里写的是"手续费收入"。

_contains_any 当时还是单向匹配 kw in text，长词去找短词，当然找不到。

这个 bug 在生产环境里静悄悄跑了三个月。

"利息支出户"漏了。 锦程科创邮政储蓄银行有一笔结息，对方名称是银行系统生成的占位名"利息支出户"。

它既绕过了结息关键词表，也绕过了替换关键词表，因为两套规则都围着"收入"场景在设计。

"应付代收业务款项-代付业务专户"漏了。 惠民生鲜农业银行有 8 笔工资代发，对方名称就是这个系统名。

问题不在某个关键词漏了，而是整个规则引擎里压根没有"工资代发"这个类别。

四种遗漏，暴露了四类根因。

"手续费"漏了——因为匹配函数的方向反了。这是逻辑设计的盲区。

"利息支出户"漏了——因为关键词表只覆盖了"收入"场景，没考虑"支出"场景。这是分类体系的盲区。

"工资代发"漏了——因为整个规则引擎压根没有"工资代发"这个类别。这是领域建模的盲区。

"深圳"污染了——因为配置表里多写了两个字，系统毫不怀疑地照单全收。这是基准数据的盲区。

逻辑、分类、建模、基准——这是一个自动化系统的四层地基。每一层都可能塌。

而且它们不会同时塌：今天塌这一层，你修好了；下个月塌那一层，你再修。自动化系统的维护，本质上就是在四层地基之间来回填水泥。

前面几次像是在补洞，到这里我才看清：洞不是一个，是四层。

修系统，修到最后，修的不是某一条规则，而是这张"哪里最容易塌"的认知地图。

填水泥填到第四次，我放弃了

如果说"深圳"和"手续费"是在修补系统内部的裂缝，那接下来这件事，让我重新思考了系统的边界到底该画在哪里。

bankclean 最初用 COM（win32com）往【进销存】文件里写数据。5 月份跑得好好的。

7 月 2 日，推送丰源农业 24 条数据。写完用户发现：所有日期全偏移了 -1 天。6 月 11 日变成了 6 月 10 日。

排查下来，是 Python 的 naive datetime 被 COM 当成 UTC 存储，东八区减 8 小时，午夜 0 点直接跨日。

修好日期 bug，推送泰恒牧业 30 条数据。写完又发现：交易时间变成了 0.0513，长账号变成了 1.0857E+16。

前者是 Excel 时间序列值，后者是科学计数法。排查下来，是 WPS 的 Table 列格式覆盖了单元格的文本格式设置。

改用逐格写入强制设@文本格式。结果——WPS 每次写一个单元格，触发整簿 1.3 万行 + 透视表全部重算。30 条数据，卡了 30 分钟还没写完。

第四版用 openpyxl 直写 xlsx，秒级完成。但用户打开后发现——切片器没了、公式缓存失效了、透视表需要手动刷新。

四轮之后，我停下来想了想：【进销存】文件是 WPS 生态里的活文件，公式、透视表、切片器相互关联。任何外部程序去写它，要么被 COM 的兼容性吃掉，要么被 openpyxl 的局限性阉割。

我跟用户说：skill 以后只负责清洗 + 质检 + 报告。推送由你在 WPS 里手动完成。

不是认输。是认清边界。判断标准不是"能不能自动化"，而是"自动化之后的维护成本是否低于手动操作"。 清洗和质检远比推送复杂，也远比推送有价值。把精力花在刀刃上。

连着翻了四次车之后，我终于明白：该重写的不是代码，而是系统边界。

边界一旦重画，系统反而更稳了。

如果你也在维护一个自动化系统

在讲完这些故事之后，我想直接跟你说三件事。不是感悟，是你可以马上做的事。

第一，找到你的"权威来源"。

你的系统里一定有一个类似于 bank-accounts.md 的配置表。它可能是账号表、产品表，也可能是客户名表。

找到它，再找到它的"权威来源"：ERP 里的原表、数据库里的主数据，或者手工维护的那份 Excel。然后做一次逐条比对。

两个字就能毁掉一个系统。你永远不知道，你的配置表里有没有藏着另一个"深圳"。

比对完之后，把"配置以权威来源为准"写进规则里。不是建议，是铁律。

第二，检查你的规则用的是"名单"还是"模式"。

如果你的质检规则是一张"已知错误名单"——每出现一种新错误就往名单里加一个词——那它不是在检测问题，而是在追认历史。

试着问自己：如果明天出现一个从未见过的错误，这条规则能抓住它吗？

不能的话，你需要的是模式规则。不是"列出所有已知的错误"，而是"判断什么是可疑的"。

第三，画出你的自动化边界。

不是所有环节都该自动化。但大多数人在做自动化的时候，从没认真想过"哪里不该自动化"。

现在就可以列一张表：你的自动化链路里有哪些环节？过去三个月，哪些环节因为自动化出过问题？

如果某一个环节的返工时间超过了手动操作的时间，就砍掉它。这不是认输，是把精力花在真正高价值的自动化上。

结语：一个在裂缝里成长的系统

回到"深圳"这两个字。

"它为什么会出现在配置表里？"因为最初写配置时，"华夏银行深圳xx支行，感觉应该有深圳"——这是人最自然不过的直觉。

"它为什么能潜伏两个月没被发现？"因为之前的清洗数据没有和【进销存】历史口径做逐条比对——没有触发点。

"修完之后，它还会再发生吗？"不会——因为现在多了一条铁律：任何配置变更前，必须先读【进销存】确认口径。下次 LLM 想当然地加一个前缀，这条铁律会拦住它。

这就是 bankclean 的真实生长过程。不是某天有人坐下来设计了一套完美的规则体系。而是每一次踩坑、每一次漏网、每一次返工——都在经验库里多一条规则，在代码里多一道检查，在质检里多一个维度。

它不是在交付那天完成的。它是在一次又一次"又漏了"中，慢慢变得不再漏的。

如果你也在维护一个自动化系统，你会懂的。

bankclean 系列阅读顺序