谷歌Gemini被塞进1个HTML文件

一个HTML文件能干什么？有人用它搭了个工作流生成器，把原本需要打开n8n实例、翻找节点、手动连线的流程，压缩成了"打字-粘贴-导入"三步。

开发者是个被n8n折磨过的人。每次灵光乍现想验证个想法，都得先启动实例、 hunt 节点、手动布线——就为了测试一个可能根本跑不通的 prototype 。这种"先 heavyweight 投入，再 lightweight 验证"的倒挂，让他决定自己动手。

零后端架构：浏览器直接调用 Gemini

成品极其简陋：单HTML文件，纯前端运行。用户填入免费的 Gemini API 密钥，用自然语言描述需求，页面返回可直接导入 n8n 的 JSON 文件。

没有服务器，没有后端，甚至不需要 n8n 实例在线。

技术路径很直接——把用户输入的 plain English prompt 发给 Gemini ，搭配一个精心设计的 system prompt ，强制模型输出符合 n8n 规范的 JSON 。包括正确的 node types 、参数结构、以及 connections 的映射格式。

难点在于让 Gemini 生成的 JSON 能被 n8n 干净利落地接受。 n8n 的工作流格式有严格约定：每个节点需要 typeVersion 、 position 数组， connections 对象里的节点名称必须精确匹配。开发者迭代了多个版本，才确保导入时节点和连线完整保留。

安全设计：凭证（credentials）被刻意排除

工具生成的 JSON 里故意不包含任何凭证信息。这并非技术限制—— n8n 本身就不把凭证存进工作流 JSON ，用户导入后仍需自行配置。开发者沿用了这一设计，避免任何潜在的安全争议。

整个工具的定位很明确：给 n8n 用户一个更快的 prototyping 出口。不用为了验证一个想法而启动完整实例，想法验证和正式部署被拆成了两个阶段。

从个人痛点到公开工具

开发者把这套方案打包成了可购买的产品，放在 Gumroad 上。购买链接藏在文末，定价策略未公开——但核心卖点清晰：省时间。

这个案例的有趣之处在于架构选择的极端化。当大多数 AI 工具都在堆砌后端服务时，它反其道而行，用浏览器直接调用大模型 API ，把复杂度压到最低。代价是用户需要自己搞定 API 密钥，收益是零部署成本、零服务器维护、零数据经过第三方。

对于熟悉 n8n 的用户，这种"先外部生成、后导入执行"的 workflow 可能并不陌生。但把它封装成单文件工具，降低了使用门槛——不需要懂 API 调用，不需要写 prompt 工程，填密钥、打字、拿 JSON 。

开发者坦承这篇文章本身也有 AI 辅助撰写。工具与内容的自指，成了这个项目的另一个注脚。

如果你也是那种"想法很多，启动实例很懒"的 n8n 用户，这种浏览器端的 prototyping 捷径，会改变你的工作流习惯吗？