空白环境复测：n8n 显示成功也可能失效

把自己写的 n8n 工作流搬到全新环境，10 个全部导入成功、全部激活，最后却有 3 个没完成任务，其中 2 个还显示绿色成功。作者这次检查暴露的问题很具体：旧环境里藏着凭据、地址和操作记忆，导出的 JSON 并没有把这些一起交给新用户。

对经常分享 AI 自动化模板、接手别人工作流的程序员，这篇最有用的提醒是：导入、激活、HTTP 请求成功，分别只能证明一小段链路正常。真正的验收，要看结果有没有送到该去的地方。

全新安装，才能测出文档漏了什么

作者用 npm 安装 n8n 1.123.84，运行在 Node 24 上，并使用全新的空用户目录，没有凭据，也没有其他工作流。

测试覆盖 10 个场景：线索评分、客服 FAQ、冷邮件个性化、发票提取、RSS 市场日报、会议行动项、评论回复、内容改编、简历筛选和每周指标解读。其中，线索评分和评论回复两个工作流，与免费仓库里的文件逐字节一致。

它们的结构基本相同：触发器进入 Config Code 节点，再构建提示词，通过 HTTP Request 调用 /chat/completions，解析结果，最后返回调用方或发送消息。

为了隔离模型的不确定性，作者在 localhost 搭了兼容 OpenAI 的模拟服务，按工作流要求返回合法 JSON，Slack 和指标接口也在本地模拟。因此，这次测的是配置和交付流程，不是 AI 回答质量。

验收条件也很克制：只按 README 和工作流内 Read Me 便签完成设置，跑一次真实风格的输入，确认结果返回或消息发出。文档没写的步骤，就不做。

静态检查没有发现节点版本不兼容。Webhook 使用 v2，最新版为 2.1；HTTP Request 使用 4.2，最新版为 4.3；Respond to Webhook 使用 1.1，最新版为 1.5；RSS Feed Read 使用 v1，最新版为 1.2。旧版本仍被 n8n 支持，作者最初怀疑的节点过时并不是故障原因。

随后通过 n8n import:workflow 导入，10 个全部成功。即使 LLM 节点仍引用不存在的凭据 ID REPLACE_ME，10 个也都能激活。

激活只代表触发器开始监听，不能证明工作流已经具备完成任务的条件。

作者又调用了其中 8 个 webhook 工作流。调用方拿到 HTTP 200 和空响应体，如果只判断状态码，就会继续往下执行。

为什么绿色执行，Slack 却收不到消息

完成文档要求的配置后，7 个通过，3 个失败。恰好，所有只向自身调用方返回结果的工作流都通过了，需要向其他服务发送结果的 3 个全部失败。

线索评分工作流返回了正常 JSON，分数是 82，高于 70 的阈值，也确实进入 Post to Slack 分支，但模拟 Slack 没收到消息。

原因是节点里还留着占位地址：

https://hooks.slack.com/services/REPLACE/WITH/YOUR_WEBHOOK

这个地址没有直接报错。作者观察到，Slack 返回 302，将请求重定向到开发者文档页；HTTP Request 默认跟随重定向，最终拿到 HTTP 200 和 HTML，于是把执行标成成功。

网络请求完成了，业务动作却没发生。

每周指标解读工作流也是同样的问题。两者的便签都漏写了 Slack URL 配置步骤。每周指标解读的便签甚至没提 LLM 凭据，只因仓库 README 写过，作者才按规则补上。

第三个失败是市场日报。它的便签明确要求填写 Slack webhook，但默认 RSS 地址 https://news.ycombinator.com/rss 在测试服务器上无法完成 TLS 握手，首个读取节点就报出 Read RSS: socket hang up。同机运行 curl 也失败，而 hnrss.org、TechCrunch 和 dev.to 的 feed 都返回 200。

这不能证明默认 RSS 在所有环境都不可用，却能证明单一硬编码地址会成为故障点。云服务器、公司网络和家用主机的可达性，不能靠作者电脑上的结果担保。

把配置遗漏变成明确错误

作者采取的修复，是把所有必须修改的值集中到 Config 节点，并在执行外部调用前检查占位符：

// Edit these values. Any OpenAI-compatible endpoint works (OpenAI, Groq, OpenRouter, Together, local Ollama /v1).
const cfg = {
  baseUrl: 'https://api.openai.com/v1',
  model: 'gpt-4o-mini',
  slackWebhook: 'https://hooks.slack.com/services/REPLACE/WITH/YOUR_WEBHOOK',
};
// Fail loudly if setup isn't finished, instead of "succeeding" against a placeholder.
const unset = Object.entries(cfg)
  .filter(([, v]) => !v || /REPLACE|YOUR_|example\.com/i.test(v))
  .map(([k]) => k);
if (unset.length) throw new Error(`Setup not finished: set ${unset.join(', ')} in the Config node`);
return [{ json: { ...$input.first().json, ...cfg }, pairedItem: 0 }];

关键是 .filter(...) 和随后的 throw：发现空值或 REPLACE、YOUR_、example.com，立即报出需要修改的字段。它能拦住明显未配置的值，但不能证明任意非空地址都正确。

Post to Slack 再从 Config 取地址：

{{ $node['Config'].json.slackWebhook }}

这里要留意取值语法。作者在该版本中使用 {{ $('Config').first().json.slackWebhook }} 时得到 undefined，并出现 URL parameter must be a string, got undefined；换成上面的写法才成功。他没有追查原因，因此不能把它扩展成所有版本的通用结论。

这项修改让漏配置能触发红色执行，也能被 Error Trigger 工作流捕获。但如果错误发生在 Respond to Webhook 之前，调用方仍可能收到 HTTP 200 和空响应体，调用端还需要判断结果是否完整。

另一个交付问题是文件缺少 workflow id。作者重复导入评论回复工作流后，n8n 新建了副本；激活副本时，因为 Webhook 路径已占用而报错。他准备给文件加入稳定 id，让重复导入能够匹配已有工作流。对于需要并存的副本，仍应另行处理标识和路径。

我的判断

我认同这次检查的验收边界：从空环境出发，只使用公开说明，最后检查业务结果。它比在旧实例里再运行一次，更接近用户真正遇到的问题。作者说 10 个工作流检查下来不到一小时，这个投入很值得参考。

不过，7 个通过不能理解成 7 个已经达到生产可用。每个只跑了一次，模型被模拟，Slack 和指标接口也被模拟，真实模型输出异常、服务限流、超时和鉴权变化都没有得到验证。

集中配置能减少遗漏，业务响应校验才能识别部分假成功。

对于 Slack，作者提出检查真实 incoming webhook 返回的 ok，这比只检查 HTTP 200 更贴近任务是否完成。关闭自动重定向也可能暴露这次异常，但仍无法单独证明消息已发送。

这篇没有提供修复前后的长期故障率，也没有与其他配置方案做对照。它是一次边界清楚的经验检查。尤其原文在部分复测位置没有展示具体结果，不宜替作者补成完整的回归报告。

能拿来做什么

• 发布 n8n 模板前，用空用户目录执行一次 n8n import:workflow，只照 README 和便签配置，再确认调用方收到有效结果或目标服务收到消息。
• 把必须修改的地址、模型名等集中到 Config，保留凭据在凭据系统中管理，并让便签逐项覆盖配置要求，避免凭记忆写说明。
• 为外部请求检查符合业务约定的响应，例如 Slack 的 ok；前端或 Node 调用 webhook 时，同时检查空响应和必要字段。
• 给默认 RSS 准备可替换源或回退方案，并验证重复导入时的 id、Webhook 路径和副本行为，让更新方式也成为交付说明的一部分。