从Agent时代起来之后，从OpenClaw到Codex，n8n自己的官方社区论坛都有人在问「n8n是不是真的要死了」。定时、触发、自动跑，这些Codex现在都能做了。
比如这是我用Codex，直接把一个n8n的GEO审计工作流变成了一个Skill。
这是官方公开的工作流模板库，10000+个工作流，背后是几年时间、无数人踩坑积累下来的自动化逻辑。就算n8n这个界面真的被时代淘汰，这些工作流背后的自动化逻辑没道理跟着一起死。而且谁都能看，谁都能拿，包括AI。
我做的事情很简单：把这些模板丢给Codex，让它自己解析、自己判断哪些环节该怎么改。甚至原来那些外接的AI节点，Codex自己顶上。门槛这件事，从「学会用n8n」，变成了「判断它做得对不对」。
先解释一下：技能是一个打包好的能力，Codex碰到对应的请求就会调用它，审计网站是一个技能，写Listing文案是一个技能，每一个都只认自己那件事。
所以我打算创建一个这样的元技能：给Codex一个n8n模板链接，不是让它直接生成代码，而是先走一套判断流程，再动手。（相当于把元提示词封装成 skills 了！）
这个元技能完整的skill.md有好几千字，这里就不整个贴了，放圈子了。
| 类型 | 例子 | 默认推荐 |
|---|---|---|
生成式AI/内容生成节点 | LLM文本生成、图像生成、语音生成 | Codex顶上；图像/视频生成先确认Codex有没有对应能力（额度），没有再问是否保留外部API |
爬虫节点 | 无认证HTTP请求，抓公开网页、公开RSS | 脚本直接实现，不需要Key；甚至 |
外部节点·付费数据服务 | GSC、Exa.ai[1]、DataForSEO、Airtop | 保留外部调用，必须用户提供凭证——真实数据，编不出来 |
外部节点·存储协作工具 | Google Sheets、Notion、飞书、Gmail发送 | 默认建议本地化，问是否保留原集成 |
触发节点 | Webhook、Chat Trigger、表单、定时/Cron | 默认改一次性命令，问是否保留定时/常驻 |
数据转换/整形节点 | Set、Code、Edit Fields | 原样保留逻辑，脚本直接实现 |
控制流/分支节点 | IF、Switch、Merge、Loop、Wait | 原样保留逻辑 |
人工审批节点 | sendAndWait、Slack审批 | 问是否保留人工确认步骤 |
子工作流调用节点 | Execute Workflow | 递归解析被调用的子工作流，不能跳过 |
错误处理/重试节点 | Error Trigger、Stop and Error、节点自带Retry | 保留错误处理意图，用try/except实现 |
文档/注释节点 | Sticky Note | 转写进SKILL.md，不参与运行 |
不过再多的规则也只是设计。真正顶不顶用，得拿真实的n8n模板跑一遍才知道：分类对不对，反问准不准，最后跑出来的东西能不能用。
先看下面 SEO & GEO 场景的两个实战Case。
这里审计skill的复刻对象是n8n模板库里的4151，地址传送：https://n8n.io/workflows/4151-ai-seo-readability-audit-check-website-friendliness-for-llms/
这个工作流一共六个节点，大概干的事是：给一个网址，然后爬虫抓取原始HTML，提取可见文本、标题层级、meta信息等等这些特征，再让AI打分——0到10分，可读性有多少，然后输出几条修复建议。
我直接把链接丢给 Codex，让它调用元技能复现：
Codex上网成功扒了工作流，开始评估，然后反问了我几个问题：触发方式、AI节点、输出报告放哪、robots.txt这块要不要加强巴拉巴拉，迎接 Codex 的轰炸吧！！
调用我聪明的大脑回答完毕后，Codex 进一步把详细的方案摆出来，让我确认。
确认之后它就开始噼里啪啦打造这个 skills，完事之后测了我给它的两个竞品独立站——Lovevery和Yoto，都是做儿童玩具的头部DTC品牌。
跑通了，看到 200 心情很美好。Lovevery打了 7.7 分、另一个打了 8.6 分，更有意思的是robots.txt检测结果：六个AI爬虫，两个网站全部放行，而llms.txt返回404。
嗯…我记得Shopify官方5月说过店铺后台默认会生成llms.txt，理论上应该存在。于是我让Codex重新核实了一遍，还是404。所以这两个头部不是Shopify标准模板，而是自建前端，才没有把这个文件透出来。
这一个skill复刻自8768，n8n模板库地址是：https://n8n.io/workflows/8768-google-form-ai-seo-geo-optimization-human-approval/
原模板是这么运作的：表单收集需求，AI生成内容，Gmail人工审批，Google Sheets记录状态。但表单收集的字段其实是一套技术博客案例模板，为了适配跨境中的产品页，直接把字段拆成页面类型、卖点、目标人群等等。Gmail审批也去掉了，改成本地人工确认，不用再接一个邮箱账号。
在阶段二反问时我突发奇想打算串联两个skill，比如传入前一个审计skill生成的报告。内容生成时会读这份报告的具体缺口，针对性地补充：缺H3就生成分层标题，缺JSON-LD就生成schema建议等等。
跑了一次验收，输入产品「Stage-Based Play Kit」，配上Lovevery的真实审计报告做参照。生成结果里有一节专门叫「How This Responds to the Audit Report」，逐条对应审计报告发现的四个问题。
这个内容生成skill 能读取审计报告、能针对性生成内容、能逐条对应缺口。它没法证明、也没有办法证明，这些新写的内容真的会让ChatGPT多引用一次。。。
毕竟 AI 创作的内容没有客观标准、人来审核也是拿主观标准去评判。
站得住脚的「更强」，有三处。
确定性和可审计性，n8n跑一百次同一个workflow，节点执行路径完全一致，出问题还能精确定位到哪个节点。Codex的skill是推理加规则的混合，长期大批量跑，一致性天然不如纯节点链路。
另外是集成桥接，n8n能连很多外部节点，配个凭证立马能用。Codex得现写脚本处理鉴权和数据格式。
需要判断、需要自我纠错的场景，Codex更强。需要成熟连接器、需要一眼看穿哪里出错的场景，n8n目前还是更合适的工具。
n8n没有死，是有些活，换了个更聪明的干法。
