用n8n和Codex把重复工作全自动化后我多睡了两小时

入职新公司两个月，最怕的不是写业务代码，而是无穷无尽的重复劳动。我司规模不大，很多事靠人肉。我干脆用n8n搭自动化流程，再让Codex帮我写节点代码。折腾两周，踩了不少坑，分享出来。

接手的第一件活是每天从几个数据源拉运营数据，整理后发到企业微信群。九点半前必须发，不然运营会在群里@你。这不就是定时任务加HTTP请求吗，搞个n8n不就完了。

n8n是开源工作流自动化工具，类似Zapier但能自托管。我用Docker在Mac上跑起来，配好企业微信Webhook，前三个节点十分钟搞定。定时触发、请求API、格式化消息，丝滑。但数据清洗卡住了——有个接口返回的JSON嵌套层级深得离谱，字段名还带中文。n8n自带表达式写起来跟裹脚布一样。

这时候我想起Codex。直接在n8n的Code节点里让它生成JavaScript代码。描述清楚需求：把嵌套JSON拍平，提取字段，计算环比增长率，输出Markdown表格。第一版代码就能跑，但有个致命问题：日期处理写死了。它直接new Date().toISOString()，结果UTC时间比北京时间慢八小时，数据全错位。跑了两天才发现。

这个坑提醒我：Codex生成的代码必须review，尤其是时间、时区、货币相关的。别偷懒直接贴。

第二个坑是n8n版本问题。我用latest镜像，某天更新后工作流挂了，报错node not found。查了半天发现是n8n把某个节点改名了，旧工作流JSON不兼容。后来在docker-compose里固定版本号，每周手动备份工作流导出文件。稳定压倒一切。

还有个坑跟Mac有关。Docker容器默认UTC，我一开始没设TZ=Asia/Shanghai，定时任务全错了。这个低级错误浪费我一个晚上。

现在这套流程跑了一个多月，每天自动拉数据、清洗、发群，我早上能多睡俩小时。后来加了几个工作流：GitHub issue自动同步到飞书、每周生成代码提交统计、监控官网证书过期时间。n8n社区节点库丰富，但质量参差不齐，用前最好看源码和更新频率。

Codex给我的感觉：写样板代码和数据处理逻辑很强，但业务上下文和边界情况要自己把关。我习惯让它写初稿，我改细节。别指望它理解你司那些奇葩接口约定。

总结：n8n适合自托管、对数据隐私有要求、喜欢折腾的场景。个人用Zapier或Make更省心。Codex是编程副驾，不是自动驾驶。自动化省下的时间，记得用来学习或休息，别又拿去卷需求了。