我以为OA系统跑通了，结果是个假自动化

大家好我是李奔腾。最近我在用AI从0开始写一套OA系统这件事对我来说其实挺有意思的。以前没有完整做过这种内部系统这次是完全围绕公司业务把流程一点点搭出来。CRM客户管理、收入报单、报销审批、请假审批这些核心模块我都已经做完了而且系统已经能跑。我一开始的设计思路其实很简单也很符合直觉员工继续在飞书发起审批审批完成之后飞书通过接口把数据推送到我的服务器我这边接收、入库然后进入财务系统。以前这些事情都是财务一条一条录现在自动完成。从效率上看这一步是成立的。而且是那种“明显变轻松”的提升。我当时的判断是这套系统已经跑通了。问题不是出在功能而是出在结构但系统真正用起来之后我慢慢发现不对劲。飞书是主动推数据我的服务器负责接收这个逻辑本身没有问题。但只要换个场景想一下如果服务器刚好挂了会发生什么审批还在继续但数据推不过来。等服务器恢复的时候这一批数据已经丢了而且是补不回来的。最后只能人工去查、去补、再录一遍。这时候你再回头看会发现一个很扎心的点问题不在推送失败而在数据“不可恢复”。你以为你做的是自动化其实只是“在大多数情况下自动”。只要需要人工兜底这个系统就不算自动化。系统一旦依赖人工补数据本质就是没跑通。这不是代码问题。这是结构问题。我一直在优化但其实是在绕远路这个问题我卡了挺久的。一开始我的反应很正常就是往技术上去想加重试、做补偿、甚至考虑消息队列。但你越往下想就越复杂而且你会隐隐感觉不对劲。你在修补一个不稳定的结构。你在解决现象而不是问题本身。后来我才慢慢意识到一个更本质的点依赖外部系统本质就是在引入不可控风险。只要这个依赖存在你就永远要为异常兜底。但即便意识到这一点我当时还是没想明白怎么解。昨天晚上有一刻我突然反应过来了昨天晚上洗澡的时候我脑子里突然闪过一个点。我之前一直在想怎么把“飞书推送”这一步做稳定但那一刻我意识到这条路可能一开始就是错的。问题不在飞书推不过来。问题在我为什么要把入口放在飞书。这一瞬间整个思路就变了。我突然发现一件事我不是在解决问题我是在绕着问题打补丁。一旦把入口收回来问题就消失了这个思路一换事情一下就简单了。我现在的方案是不再用飞书做报单入口而是自己写一个小程序来做报单再结合服务号做消息推送和审批提醒。员工在小程序报单服务号通知审核人审批完成之后数据直接进入OA系统。整个过程从数据产生到数据落地都在同一个系统里完成。这里最关键的变化其实只有一个数据从一开始就在我这里。这样一来逻辑就完全不一样了。如果服务器挂了那就直接报不了单但只要报不了单就不会出现“业务已经发生但系统没有记录”的情况。从“数据可能丢”变成“数据根本不会丢”。从“补救错误”变成“避免错误”。顺带我看清了一个更大的问题这个是我后来才意识到的。如果我继续用飞书做入口那用钉钉的团队就没法用这套系统。等于一开始我就把市场砍掉了一半。但如果入口在我自己手里这个问题就不存在了。不管你用飞书、钉钉还是其他工具都不影响。从依赖平台变成独立于平台。从工具变成系统本身。这个变化不只是技术层面的而是产品层面的。接下来其实就是用Codex把这套小程序和服务号流程实现出来把整个链路闭环这反而是最简单的部分。这件事让我一个很深的感受是很多人现在在讨论AI能不能写代码但这件事本身其实没那么重要。代码这件事已经越来越不稀缺了。真正稀缺的是你能不能把问题想清楚。流程怎么走数据怎么流依赖关系怎么处理这些东西AI帮不了你。会写代码的人很多但能把业务真正跑通的人很少。差距不在技术而在认知。