想把需求落地成 n8n 节点流程？别一上来就盯着节点名找。先攥住一句明确的验收标准：这条流程跑通后，n8n 里得留下什么结果？哪儿能看成功状态，哪儿能看失败原因？n8n-skills 的用法，也得围着这个最终目标来。

第一步：把需求改写成“输入、动作、输出”

别笼统说「帮我自动整理邮件」，得拆成这样：「当 Gmail 收到带发票附件的新邮件时，提取附件、识别金额和供应商，超过 500 美元发财务审批，低于 500 美元写入表格并标记已处理」——就这么一句话，已经能拆出对应节点了。

我自己常用的法子是：先让 Claude Code 只输出字段表，别急着生成流程。字段包括邮件主题、发件人、附件文件名、金额、供应商、审批状态、错误原因。字段捋顺了，后面搭节点才不会乱。

第二步：让 n8n-skills 参与节点选择

提示词可以写得更具体些，比如：

请按 n8n workflow lifecycle 的方式拆解。
先给节点流程，不要创建。
每个节点写：用途、输入、输出、关键配置、失败信号。
涉及表达式时，请检查 {{ }}、$json、$node 的写法。

这种提示方式，刚好能对上官方 skills 覆盖的能力范围：生命周期、节点配置、表达式、二进制数据、错误处理和调试。记得把失败信号也写清楚，比如附件为空、OCR 没识别出金额、供应商字段为空、审批接口返回 401 这类情况。

第三步：把节点流程写成可测试顺序

1. Trigger：接收邮件、Webhook、表单、定时任务或是数据库变化。
2. Normalize：统一字段命名，把不同来源的数据捋成同一套结构。
3. Decide：用 IF 或是 Switch 做金额、地区、状态、重复数据的判断。
4. Act：调用 Slack、HTTP Request、CRM、表格或是内部系统。
5. Record：记下执行结果、失败原因和重试标记。

我一般会这么做：每加完一段节点，就让 Claude Code 给一条对应的样本输入和预期输出。没配样本的节点流程，大多只是看起来顺而已。

第四步：别跳过验证和调试

n8n 工作流刚搭好时的 bug，多半藏在字段引用里。比如上一个节点输出是 company.name，下一个节点写成 companyName，界面上看着好像没啥大问题，真跑起来就会丢值。让 AI 用 debugging skill 挨个检查表达式，可比上线后翻执行日志省事多了。

第五步：让 AI 交付“节点说明”，不是只交付结果

最后记得让它输出一份简短说明：每个节点为啥存在、删掉会有啥影响、出问题了看哪条日志。这样后面团队接手时，不用再瞎猜这条流程当初为啥这么搭。

一套合格的 n8n-skills 使用流程，得先把需求捋清楚，再把节点拆具体，最后让测试结果能复现。要是直接从一句话需求蹦到完整 JSON，往往是开头快，返工的时候反倒费时间。