10分钟用n8n+Gemini搭建无代码AI应用生成器

一个Telegram机器人，如何变成你的私人开发团队

在Telegram里发一句"帮我做个马卡龙色番茄钟"，不到10秒就收到一个可点击的网页应用链接——完整的HTML、CSS、JavaScript，已部署上线。这是YouTube博主展示的n8n + Gemini实战项目，机器人名叫Terris。

它的技术栈并不复杂：n8n负责编排流程，Google Gemini负责生成代码，GitHub Pages负责托管。整个过程无需编写任何代码，只需要在n8n画布上串联四个节点。

这套方案值得关注的地方在于，它把"想法→代码→部署→交付"压缩成了一条消息的距离。传统流程中，即使使用AI生成代码，开发者仍需手动创建文件、推送到仓库、配置托管。Terris将这一切自动化，用户只面对一个聊天窗口。

n8n是一款开源的工作流自动化平台，可以理解为“可自托管的Zapier/Make”。它通过可视化画布把多个服务（如Telegram、Google Gemini、GitHub）用节点串联起来，每个节点执行一个具体动作（接收消息、调用API、创建文件等），节点之间通过表达式传递数据。相比纯代码脚本，n8n的优势在于托管方便、调试直观、支持Webhook和定时触发，非常适合搭建“消息进来→处理→输出结果”这类自动化代理。本地可Docker部署，也可使用官方云服务。

Google Gemini是Google推出的多模态大模型系列。文章中通过Google AI Studio获取API Key，并以“Message a Model”节点调用。Gemini支持长上下文和大段代码生成，适合一次性输出完整HTML文件；但不同模型（如Pro与Flash）在速度、成本和推理质量上有差异，实际部署时需根据场景选用。

四个节点串起完整工作流

第一步：Telegram Trigger——机器人的耳朵

在n8n画布上点击加号，搜索Telegram Trigger，选择"On Message"。凭据部分需要填入从BotFather获取的机器人Token。

这个节点相当于Terris的听觉系统。任何人向机器人发送文本或语音消息，触发器立即捕获并启动工作流。博主在演示中强调，这一步是整个流程的入口，Token配置错误会导致后续所有节点无法工作。

第二步：Google Gemini——机器人的大脑

从Telegram Trigger节点拉出连接线，搜索Google Gemini，选择"Message a Model"操作。填入Google AI Studio获取的API Key后，选择模型并添加消息。

关键在于系统提示词的设计。博主设置的指令是："你是Terris，一位专家级Web应用开发者。创建一个单文件响应式HTML应用，内嵌CSS和JavaScript。只输出原始代码，以[指定标签]开头，不要用Markdown代码块包裹。"

消息内容通过表达式引用前一个节点的数据：{{ $json.message.text }}。这意味着用户在Telegram中发送的每一句话，都会作为指令传给Gemini。同时需要打开"Simplify Output"开关，确保输出格式适配后续节点。

博主特别提到，系统提示词的结构直接影响输出质量——"它决定了你拿到的是破碎的垃圾还是一份完整可用的高价值Web应用"。

系统提示词（System Prompt）是大模型在接收用户输入前预先设定的“角色+规则”说明，它决定了模型响应的边界与风格。与普通对话提示不同，系统提示词通常包含身份设定、输出格式约束、禁止事项等。文章中的示例就是把“你是什么角色”“输出什么格式”“不要做什么”三件事一次性写清楚。实践中，约束越明确，模型越不容易“自由发挥”；而格式错误（例如用Markdown代码块包裹）会直接破坏后续节点的解析逻辑，因此需要反复测试和微调提示词。

第三步：GitHub节点——自动部署到云端

从Gemini节点继续连接，搜索GitHub，选择"File: Create or Update"。使用Personal Access Token连接GitHub账户，然后配置几个字段：

• Owner：你的GitHub用户名
• Repository：存放应用的仓库名
• File Path：使用表达式生成唯一文件名，如app-{{时间戳}}.html，避免文件互相覆盖
• File Content：引用Gemini节点的输出{{ $json.text }}

这一步让Gemini生成的每一段代码自动推送到GitHub仓库。由于启用了GitHub Pages，推送的文件会立即获得一个公开可访问的URL。文件名使用时间戳确保每次生成都是独立页面，不会覆盖之前的结果。

GitHub Pages是GitHub提供的静态网站托管服务，免费、无需服务器，只要把HTML/CSS/JS等静态文件推送到指定仓库分支，就能获得一个可公开访问的URL。它不执行后端代码，但非常适合本方案中的单文件Web应用。需要注意的是，Pages在文件推送后需要一定时间完成构建与CDN刷新，期间可能出现短暂404；此外，私有仓库的Pages访问权限、仓库命名规则等也影响最终链接形式。

第四步：Telegram发送——把成品递到用户手上

最后一个节点回到Telegram，选择"Send Text Message"。Chat ID通过表达式{{ $('Telegram Trigger').item.json.message.chat.id }}自动获取，确保消息发回给正确的用户。

文本内容可以自定义，博主使用的模板是："Terris已构建你的应用。这是在线链接：[GitHub Pages URL]"。

保存并发布工作流后，Terris正式上线。用户在Telegram中发送需求，10秒内收到可点击的应用链接。

这套方案真正值得学的是什么

表面上看，这是一个"无代码AI应用生成器"的教程。但拆解之后会发现，核心价值不在于n8n的节点配置——那些操作跟着步骤走就能完成。

真正的门槛在系统提示词的编写。博主的观点很明确："构建AI机器人和自主代理的秘诀，不是学习几千行代码，而是掌握系统提示词工程。"Gemini、Claude、ChatGPT的输出质量，取决于你如何组织指令结构。

这个判断有其道理。在当前的大模型能力水平下，让模型生成一个完整的单文件Web应用并不困难，难的是确保输出格式稳定——每次都严格输出原始代码、不添加多余解释、不使用Markdown包裹。这些约束条件需要通过提示词精确控制，否则后续的GitHub节点会因为格式问题而失败。

另一个值得注意的设计思路是"单文件应用"的定位。将所有代码嵌入一个HTML文件，虽然牺牲了工程规范性，但换来了部署极简——一次文件推送即可上线，不需要构建步骤、不需要依赖管理。对于快速原型和个人工具场景，这是合理的取舍。

从教程到产品还差什么

这套工作流可以运行，但距离一个可靠的产品还有明显差距。

代码质量没有验证环节。Gemini生成的代码直接部署上线，如果存在语法错误或逻辑缺陷，用户拿到的链接可能是一个白屏页面。生产级方案需要加入代码校验或预览确认步骤。

GitHub Pages的构建延迟也是一个变量。推送文件后，Pages服务需要一定时间完成构建和发布，用户点击链接时可能遇到404。博主在演示中未讨论这个问题。

此外，当前流程只支持单轮生成。如果用户对结果不满意，需要重新发送一条新消息，生成一个全新的应用，而不是在原有基础上修改。这使得它更像一个"一次性生成器"而非"迭代式开发工具"。

尽管如此，作为一个展示n8n + Gemini集成能力的项目，它清晰地证明了：AI应用开发的门槛正在从"写代码"转移到"设计工作流和提示词"。这个转变本身，比教程中的具体步骤更值得思考。

AI代理（Agent）与普通自动化脚本的关键区别在于“是否具备自动决策与反馈循环”。本方案本质上是线性流水线——触发→生成→部署→回复，没有校验、重试和自我修正环节。若要升级为真正的代理，可加入：代码语法检查节点（如运行ESLint或HTML验证器）、失败重试机制、预览确认步骤（先发草稿链接让用户确认再正式发布），以及基于用户反馈的多轮迭代存储。这些改造会让工作流节点数量翻倍，但可靠性和用户体验会有质的提升。