你的"自动化专家"给你造了个定时炸弹，一旦引爆他们就会消失得无影无踪。

让我吐槽一下。每隔几周我就会接到同样的电话。某个企业主花了高价请了一位"自动化专家"，结果他们得到的工作流……有时能运行。在好日子里。要是风向对了的话。然后他们让我搞清楚为什么他们那套"全自动"系统需要一个人24小时盯着。 所以让我告诉你我反复发现的问题，因为几乎总是同样的套路。 他们雇的那个人直接跳进去就搞了个能做X的东西。酷。但他从未问过这个业务实际做什么，或者这个工作流涉及什么，或者在它触发后三步下游会发生什么。他太专注于怎么构建，以至于从不停下来思考为什么这些东西应该以这种方式工作。这就是整个事情开始跑偏的地方，甚至在他完工之前。 错误处理？根本不存在。正常路径运行得很好，在演示里看起来像魔法。然后某天一个字段传过来是空的，或者某个API决定限速，整个东西当场扑街。现在客户坐在那里面对一个死掉的工作流，完全不知道怎么修复，因为没人教过他们，所以他们把代码贴到Claude里祈祷。当奇迹没有出现时，惊喜，那个构建者已经跑了。玩消失了。所以这个可怜的老板以为自动化本身是个骗局，其实他们只是雇了个只关心演示的人，一遇到困难就溜之大吉。 还有那些纯属意外才能正常运行的逻辑。我打开过筛选条件，它们因为完全错误的原因输出了正确的结果，纯粹是因为那天的测试数据恰好干净得一尘不染。生产数据从来都不干净。最妙的是？构建它的人自己都说不清它当初为什么能运行。没有文档，没有注释，没有任何可供核对的东西。所以你无法调试它，因为根本无从下手。你能看到这个循环在自我强化。 显然，所有东西都塞进了一个巨大的场景里。一个怪兽级的工作流，改变其中任何一个东西都意味着你得先理解整个系统。祝那个接手这烂摊子的人好运。 凭证？有一半的情况下API密钥就那么明文放在配置里，好像这很正常。有些人真的不知道有密钥管理器存在。 还有文档，天哪。从来就没有。没有注释，没有README，没有一行解释这个东西为什么存在或者它是干什么的。它就是一个漂浮在虚空中的工件，没有记忆，没有父级。 但有一点，没有一个人——我说的是没有一个人——会谈到。治理。 每一次关于自动化的对话都围绕着构建。工具、触发器、逻辑、最终的炫酷结果。没错，那是好玩的部分。但没有人停下来问上线之后会发生什么。这东西归谁管？凌晨2点坏了谁接电话？构建它的人走了怎么办？如何在不悄悄炸掉下游所有依赖的情况下修改一个组件？那就是治理，而且它每次都被跳过，因为它太无聊了。感觉就像文书工作而不是构建。所以自动化上线了，漂亮地运行了三个月，然后有人"只是微调了一点点"，整个系统开始悄悄失灵，没人注意到，直到酿成真正的灾难。 听着，我不是叫你别学这些东西。真的，全去学。但如果你要自动化一个真实的业务流程，就是这些因素决定它能否在现实面前存活五分钟。而且如果你要雇人帮你做，听听他们怎么说话。真正的高手不仅问你如何做某件事。他们会问你为什么做，以及它改变时会影响到谁。如果整场对话只围绕怎么做的，我会开始对他们即将交给你的东西提出一些相当尖锐的问题。