这玩意儿本质上就是个定时炸弹，只不过我亲手点燃了引信。昨天下午六点，看着后台日志里那些整齐划一的“任务已分发”、“状态已更新”，我甚至有种错觉，觉得这套用 Python + 企业微信 API 攒出来的东西，真能把那七八个脑子转速不一的家伙拧成一台机器。我给这系统起了个名字叫“中枢”，听着挺唬人，其实就是个高级点的传话筒加记事本。
核心逻辑简单到可笑：我每天上午手动把客户需求拆成颗粒度极细的 checklist，写进一个 Google Sheet。然后“中枢”每隔半小时去爬一次这个表，把新增的、状态变更的行抓出来，通过企业微信的机器人，一对一推给对应负责人。对方回复“完成”或者上传个截图，机器人再自动去表里把状态从“进行中”改成“待验收”。我想象的画面是：我坐在中军帐，令旗一挥，小兵们按部就班冲杀，战报自动汇总到我面前。省掉我每天在群里@所有人、追着屁股问“做到哪了”的口水，也杜绝他们用“忘了”、“没看到”当借口。管理嘛，不就是把不确定性尽可能封装掉？
我花了三个晚上，主要卡在 API 的频率限制和表格的读写权限上。企业微信机器人发消息有每分钟条数上限，你不能噼里啪啦一瞬间把任务全怼出去，得用 `time.sleep` 做个简单的队列延迟。表格那边更烦，我用 `gspread` 库，每次读取都要处理 OAuth 2.0 认证，还得小心别触发 Google 的反爬。测试的时候一切完美，我的小脚本像一个沉默而高效的监工。
然后今天就崩了。崩得毫无尊严。问题出在一个 UI 设计稿的验收环节。负责的设计师需要把修改后的 Sketch 文件链接贴到表格里一个特定单元格。我设定的规则是，只要那个单元格非空，就视为“已完成”，系统会自动标记并通知下一环节的前端开发。结果那位大哥，大概是想省事，直接把上一版的文件链接复制了过来，没换新链接。系统哪管你内容对不对，它只检测“非空”这个布尔值。于是，一个根本没更新的旧链接，被当成“已完成”的信号，欢快地送给了前端。
前端小哥点开链接一看，火冒三丈，在群里直接开喷：“这改了个屁！和昨天的一样！” 设计说他明明上传了，两人吵了五分钟，最后发现是链接贴错了位置——他贴到了备注栏，而不是我规定的“交付物链接”栏。就这么一个手工输入的、偏离预期格式几个单元格的微小错误，让整个链条卡死。前端等着新稿子开工，设计觉得自己冤，我不得不停下手里正在谈的新客户需求，去当裁判，查日志，手动修正表格数据。
更讽刺的是，为了处理这个意外，我在群里打的字、打的语音电话，比过去一周加起来都多。所谓的“自动化”，非但没解放我，反而因为引入了新的故障点（人对规则的错误执行），制造了一场需要更多人工干预的小型灾难。我盯着那个跑错的脚本，它还在傻乎乎地、每隔半小时去扫描那个已经错乱的表格，准备制造更多混乱。我赶紧 `Ctrl+C` 停了它。
那一刻我明白了，我想用代码解决的，是“人执行指令的不可靠性”。但我这套系统，恰恰把最不可靠的环节——人工输入和规则理解——当成了信任的基石。我试图给员工“装上大脑”，预设他们都能像机器一样精确理解并遵守我制定的输入协议。这太傲慢了。他们不是函数，不是接收固定参数就一定返回预期结果的 `API`。他们有情绪，会疲劳，会图省事，会对模糊的规则做自己的解读。
晚上我对着代码发呆，没改。我在想，也许方向错了。问题可能不在于“如何让他们更听话地执行我的流程”，而在于“如何设计一个容错率高、即使人犯点小错也不会全盘崩溃的流程”。或者更根本的是，我是不是太沉迷于用技术手段去解决一个本质上关于沟通、培训和人性惰性的管理问题？这套系统像个蹩脚的脚手架，搭在我对“失控”的恐惧之上。今天它塌了一角，砸醒了我。明天怎么办？继续加固这个脆弱的脚手架，还是承认有些东西，代码真的替代不了，比如手把手教他们为什么那个链接必须放在那个格子里的耐心？妈的，管理真难，比写爬虫绕过京东的反爬系统难一万倍。
