当前位置：首页 > news >正文

Telegram AI Bot实战：5步打造自动化工作台

news 2026/7/8 5:04:44

1. 项目概述：为什么 Telegram 不该只是个聊天工具？

Telegram AI Bot 教程 —— 别再只会建群，5步把 TG 变成你的自动化工作台。这句话不是营销话术，而是我过去三年在真实业务场景中反复验证过的一条技术路径。我服务过17家中小团队，从跨境电商客服组、独立开发者工作室，到本地律所和自由撰稿人联盟，他们最初用 Telegram 的方式都高度一致：建一个群发通知、拉几个频道做内容分发、偶尔用 bot 转发 RSS。但三个月后，其中12支团队的 TG 账号已悄然变成「无人值守的数字前台」——自动收订单、自动查物流、自动归档客户咨询、自动同步飞书日程、自动触发 Jenkins 构建任务、甚至自动把用户语音转文字后喂给本地部署的 Qwen3 模型生成法律意见初稿。这不是科幻设定，是基于 Telegram Bot API + 开源 Agent 框架 + 你已有 SaaS 工具链的轻量级集成。

核心关键词里，“Telegram” 是载体，“AI Bot” 是能力中枢，“自动化” 是最终形态，“Make”（指 Make.com）是其中一种低代码编排方案，但绝非唯一解。真正关键的是“agent+大模型+自动化”这个组合范式：它意味着 Bot 不再是被动响应指令的菜单式工具（比如 /start → /help → /status），而是具备上下文记忆、多步骤推理、跨平台调用能力的轻量级数字代理。它能理解“帮我查昨天下午三点发给张总的合同PDF是否已签回”，然后自动翻飞书文档库、比对签署状态、截图生成摘要、再通过 TG 私聊推给你——整个过程无需你打开任何网页或客户端。

适合谁来学？第一类是技术背景不强但有明确流程痛点的人：运营要每天手动导出10个渠道的咨询记录再合并 Excel；HR 要反复核对入职材料是否齐全；客服主管要盯三台电脑看不同平台的未读消息。第二类是有基础开发能力但不想重造轮子的工程师：你已经会写 Python，但不想花两周从零搭 Webhook 服务、写重试逻辑、做消息去重、处理 Telegram 的 4096 字符限制和文件大小策略。第三类是正在探索 AI 落地场景的产品/项目经理：你手上有现成的大模型 API（通义千问、DeepSeek、Ollama 本地模型），但缺一个稳定、可触达、带身份体系的交互入口。Telegram 就是那个入口——它自带用户 ID、设备指纹、群组权限体系、文件传输通道，且国内用户通过合规渠道下载安装率超85%（据第三方应用市场2024Q2数据），远高于自建网页或小程序。

很多人卡在第一步：觉得“Bot 开发=要懂 Node.js + Express + 数据库 + 部署运维”。其实完全不必。Telegram Bot 的本质是一个 HTTP 接口代理：你注册 Bot 后拿到一个 token，所有用户消息都会以 JSON 格式 POST 到你指定的服务器地址（Webhook）或由你主动轮询（getUpdates）。而“AI”部分，完全可以复用现有大模型服务，你只负责把用户输入拼成 prompt，把返回结果按 Telegram 消息格式包装好发回去。真正的难点不在代码，而在三个实操层：如何设计 Bot 的对话状态机，让它不把“查物流”和“查订单”搞混；如何让大模型输出结构化数据（JSON），而不是自由发挥的散文；如何把 Bot 和你真正用的工具（飞书、Notion、MySQL、Jenkins）安全、稳定、可审计地连起来。这篇教程就直击这三个点，用 5 个可立即执行的步骤，带你把 TG 从通讯工具升级为你的个人/团队自动化工作台。每一步我都附了真实调试日志、参数计算依据、以及踩坑时的错误截图（文字描述版），你可以直接抄作业。

2. 整体架构设计与方案选型逻辑

2.1 为什么放弃纯代码方案，选择“Bot API + Agent 框架 + 编排平台”三层架构？

我最早用纯 Python 写过一个 Telegram Bot，功能是自动回复 GitHub Issue 状态。代码不到 300 行，但上线三天就暴露出四个硬伤：第一，当用户连续发三条消息，Bot 回复顺序错乱（因为异步处理没加锁）；第二，某次 GitHub API 限流，Bot 卡在重试循环里，导致后续所有消息积压；第三，想加个“语音转文字”功能，得自己集成 Whisper.cpp，编译报错折腾六小时；第四，老板临时说“把回复抄送一份到飞书群”，我又得改代码、测 webhook、配飞书机器人 token。这让我意识到：Bot 的核心价值不在“能做什么”，而在“能多快、多稳、多灵活地响应变化”。于是我把架构拆成三层：

底层：Telegram Bot API—— 这是 Telegram 官方提供的 HTTP 接口，稳定、免费、文档清晰。它只做一件事：可靠地收发消息。我们绝不自己实现 MTProto 协议，也不碰 Telegram 的客户端 SDK。Token 有效期永久，Webhook 地址支持 HTTPS，失败消息自动重试三次（间隔 1s/3s/10s），这些官方保障的能力，我们直接拿来用。
中层：Agent 框架—— 这是“AI”的执行引擎。我对比过 LangChain、LlamaIndex、AutoGen、Dify 和自研框架。LangChain 生态全但太重，一个简单查天气要装 12 个依赖；AutoGen 多 Agent 协作很炫，但单 Bot 场景下启动慢、内存占用高；Dify 是优秀产品，但私有化部署需 PostgreSQL + Redis + Celery，小团队维护成本高。最终我锁定Ollama + OpenWebUI + 自定义 Python Agent 脚本组合：Ollama 提供本地模型运行时（Qwen3-4B 仅占 2.1GB 显存），OpenWebUI 做可视化调试界面，而核心 Agent 逻辑用不到 200 行 Python 实现——它只负责解析用户意图、调用对应工具函数、把结果喂给模型、格式化输出。这样既保有大模型的推理能力，又避免被框架绑架。
上层：编排平台（Make.com / n8n / 自建 Flask）—— 这是连接 TG 和外部世界的“胶水”。比如用户说“同步我上周的飞书日程到 Notion 表格”，Agent 识别出这是“跨平台同步”意图，但它不直接调飞书 API，而是向 Make.com 发送一个含用户 ID 和时间范围的 HTTP 请求；Make.com 收到后，自动执行“飞书日历 → 解析事件 → Notion 创建 Page”整条流水线。好处是：第一，飞书 token 存在 Make 安全 vault 里，Bot 代码里永远不出现密钥；第二，同步逻辑变更（比如新增过滤条件）只需在 Make 界面点几下，不用改代码、不重启服务；第三，所有请求/响应都有完整日志，哪一步失败一目了然。我测试过 Make.com、n8n 和自建 Flask，结论是：Make.com 对新手最友好（拖拽界面、内置 1000+ 应用连接器、错误提示直白），n8n 更适合需要深度定制 HTTP 请求头的场景，而 Flask 则留给必须 100% 数据自主可控的团队。本教程默认用 Make.com，因其免费版已足够支撑 90% 的个人自动化需求（每月 1000 次操作，含 Telegram、飞书、Notion、Gmail 等主流服务）。

这个三层架构的本质，是把“消息路由”、“AI 推理”、“系统集成”三件事彻底解耦。Bot 只管“听”和“说”，Agent 只管“想”，编排平台只管“跑”。当你要加新功能（比如接入 Jenkins），只需在 Make.com 新建一个模块，配置 Jenkins 的 API URL 和 token，再让 Agent 在识别到“构建”意图时调用它——整个过程不碰 Bot 代码，不改 Agent 模型，不影响现有功能。这才是可持续演进的自动化工作台。

2.2 为什么坚持用 Telegram 官方 Bot，而非第三方客户端或 MTProto 库？

网络上常看到“用 Telethon 库实现更强大 Bot”的说法，这其实是认知偏差。Telethon 是一个 Python 的 MTProto 协议实现，它让你能模拟真实 Telegram 客户端行为（比如获取联系人列表、监听群组所有消息、甚至登录他人账号）。但正因如此，它带来三个致命风险：第一，违反 Telegram ToS。Bot API 是官方授权的机器人接口，而 MTProto 登录属于“客户端模拟”，Telegram 明确禁止用于自动化商业用途（见其 Developer Policy 第 4.2 条）；第二，稳定性差。MTProto 连接需维持长链接，国内网络波动时频繁断连重连，消息丢失率高达 15%（我实测数据）；第三，安全黑洞。你要在代码里硬编码用户手机号和验证码，一旦服务器被黑，等于交出整个 Telegram 账号控制权。

而 Bot API 是专为机器人设计的：它基于 HTTPS，天然适配 CDN 和负载均衡；它用 Token 认证，token 可随时在 @BotFather 里重置；它只接收发给 Bot 的消息（或你授权的群组），无法越权访问其他数据。更重要的是，Bot API 的消息投递有严格 SLA：99.95% 的消息在 1 秒内送达，失败时自动重试，重试失败才丢弃。我在一个日均 5000 条消息的客服 Bot 上运行一年，消息丢失仅 3 条（均为用户端网络问题），全部通过人工补发解决。所以，除非你在做安全研究或逆向分析，否则请永远选择 Bot API。那些“功能更强”的诱惑，代价是不可控的风险。

2.3 关于“AI”的务实定位：它不是万能大脑，而是精准扳手

很多教程把 AI Bot 描绘成“能帮你写周报、订机票、谈恋爱”的全能助手，这严重误导新手。真实场景中，大模型在 Bot 中的核心价值是“语义理解”和“内容生成”，而非“决策执行”。它擅长把“帮我找张三上个月签的合同”这种模糊口语，解析成结构化查询条件（用户ID=张三，时间范围=2024-05-01 至 2024-05-31，文档类型=合同，状态=已签署）；也擅长把数据库返回的 raw JSON，润色成自然语言摘要（“张三于5月12日签署了《服务协议》，签字页已存档，合同编号 HT20240512001”）。但它不该、也不能直接去数据库删数据、改 Jenkins 构建参数、或替你回复客户情绪化消息。

因此，我的 Agent 设计原则是：所有“执行”动作必须由确定性工具函数完成，AI 只负责“理解”和“表达”。例如，查物流功能的完整链路是：

用户发送：“查单号 SF123456789CN”
Agent 调用parse_tracking_intent()函数，提取单号 SF123456789CN
Agent 调用call_sf_api(tracking_no="SF123456789CN")函数，得到原始 JSON 数据
Agent 把 JSON 和预设 prompt（含格式要求）喂给 Ollama 模型
模型返回 Markdown 格式物流轨迹（含时间、地点、状态 emoji）
Agent 调用send_telegram_message(chat_id, markdown_text)发送

这里，步骤 2、3、6 是确定性代码，100% 可预测；步骤 4、5 是 AI，可能出错（如模型把“派件中”误译为“已签收”），但错误只影响展示层，不影响物流数据本身。这种设计让系统既拥有 AI 的灵活性，又保持工程上的可靠性。记住：自动化工作台的底线是“不犯错”，上限才是“更聪明”。

3. 核心细节解析与实操要点

3.1 Bot 创建与基础配置：5 分钟完成，但有 3 个关键陷阱

创建 Bot 的流程在 @BotFather 里非常简单：发送/newbot→ 输入 Bot 名称（显示名，如“我的工作台助手”）→ 输入用户名（唯一标识，如my_workbench_bot，必须以_bot结尾）→ 得到 Token。整个过程不到 2 分钟。但新手常在这里栽跟头，我总结出三个必须当场处理的关键陷阱：

陷阱一：Token 泄露风险
Token 是 Bot 的密码，形如1234567890:ABCDEFGHIJKLMNOPQRSTUVWXYZabcdef。一旦泄露，他人可完全控制你的 Bot。常见泄露场景：把 Token 写死在 Python 脚本里并上传 GitHub；在 Make.com 的 HTTP 模块里明文填写；甚至截图发群里问“为什么连不上”。正确做法是：所有环境变量统一用.env文件管理，并加入.gitignore。例如，在项目根目录创建.env：

TELEGRAM_BOT_TOKEN=1234567890:ABCDEFGHIJKLMNOPQRSTUVWXYZabcdef MAKE_WEBHOOK_URL=https://hook.make.com/your_unique_path

然后在 Python 代码中用python-dotenv库加载：

from dotenv import load_dotenv import os load_dotenv() BOT_TOKEN = os.getenv("TELEGRAM_BOT_TOKEN")

Make.com 也提供“加密变量”功能，在 Settings → Variables 里创建，调用时用{{variables.your_variable_name}}，绝不明文出现。

陷阱二：Webhook 地址必须 HTTPS 且可公网访问
Bot 默认用轮询（getUpdates），但生产环境必须切 Webhook，否则延迟高、资源消耗大。Webhook 地址需满足：1）以https://开头；2）域名已备案（国内云服务器）或使用 Cloudflare Tunnel（海外）；3）服务器 443 端口开放。很多新手用本地http://localhost:5000/webhook测试，结果一直收不到消息。解决方案：用 Cloudflare Tunnel 免费开通公网地址。步骤：下载cloudflared→ 运行cloudflared tunnel create my-tg-bot→ 编辑 YAML 配置，将ingress[0].service指向http://localhost:5000→ 运行cloudflared tunnel run my-tg-bot。它会生成一个类似https://abc123.cloudflare.dev的地址，把这个地址填入 Webhook 设置即可。实测延迟稳定在 300ms 内，且无需备案。

陷阱三：群组消息权限需手动开启
Bot 默认只能收到私聊消息。若要在群组里使用（如客服群自动回复），必须在群设置里启用“Inline Mode”并添加 Bot 为管理员。具体操作：进入群 → 点右上角… → Manage Group → Administrators → Add Admin → 选择你的 Bot → 开启 “Post Messages” 和 “Edit Messages” 权限（其他权限按需）。否则，Bot 在群里的消息会被静音，你完全收不到。这个步骤 90% 的教程都漏掉，导致用户以为 Bot 坏了。

提示：设置 Webhook 的命令是curl -F "url=https://abc123.cloudflare.dev/webhook" https://api.telegram.org/bot<YOUR_TOKEN>/setWebhook。成功返回{"ok":true,"result":true,"description":"Webhook was set"}。若返回{"ok":false,"error_code":400,"description":"Bad Request: bad webhook"，大概率是 URL 格式错误或证书问题。

3.2 Agent 意图识别与状态管理：让 Bot 听懂人话，而不是关键词

Bot 最常见的失败，是把“查张三的合同”当成“查张三的电话”。根源在于用简单关键词匹配（if "合同" in text），而非真正的语义理解。我的 Agent 采用“双层识别”策略：第一层用规则引擎快速过滤高频意图，第二层用大模型做细粒度解析。这样兼顾速度和准确率。

第一层：规则引擎（FastPath）
针对 70% 的固定模式请求，用正则和关键词树快速响应，不调用大模型，毫秒级返回。例如：

/start或 “你好” → 返回欢迎消息和功能菜单
“物流 SF123456789CN” → 直接提取单号，跳过 AI 解析
“日程今天” → 解析为{"date": "today", "action": "list"}规则引擎代码极简：

import re def fast_intent_match(text): text = text.strip().lower() if re.match(r'^/start|你好|hi|hello', text): return {"intent": "welcome"} if m := re.search(r'物流\s*([A-Z0-9]+)', text): return {"intent": "tracking", "tracking_no": m.group(1)} if "日程" in text and ("今天" in text or "明天" in text): date_key = "today" if "今天" in text else "tomorrow" return {"intent": "calendar", "date": date_key} return None # 交给 AI 处理

第二层：大模型解析（SlowPath）
对规则引擎无法识别的复杂请求（如“把上周五王总发的那份带红色标题的 PDF 找出来”），交给 Ollama 模型。关键不是让它“回答”，而是让它“结构化输出”。我用的 prompt 模板经过 37 次迭代：

你是一个 Telegram Bot 的意图解析器。请严格按以下 JSON 格式输出，不要任何额外字符： { "intent": "string, 必须是以下之一: [contract_search, calendar_sync, jenkins_build, email_forward]", "entities": { "person": "string, 人名，如'张三'，无则为空字符串", "date_range": "string, 如'上周'、'2024-05-01至2024-05-31'，无则为空字符串", "file_type": "string, 如'PDF'、'Excel'，无则为空字符串", "keyword": "string, 文档中的关键词，如'红色标题'，无则为空字符串" } } 用户输入：{user_input}

模型（Qwen3-4B）在 8GB 显存 GPU 上平均响应 1.2 秒，JSON 输出准确率 92.3%（测试集 500 条真实用户语句）。若输出非 JSON，Agent 会自动重试一次，仍失败则返回“抱歉，我没听懂，请换种说法”。

状态管理：防止上下文混乱
Telegram 没有原生会话状态，用户可能同时在私聊和群聊发消息。我的方案是：每个 chat_id（群或用户 ID）对应一个内存中的状态对象，超时 15 分钟自动销毁。状态对象记录当前进行中的任务（如“正在等你发送合同文件”）、已收集的参数（如已识别出 person=张三）、以及下一步引导语。代码用 Pythondict+threading.Timer实现，轻量且可靠。实测在 200 并发下内存占用 < 15MB。

3.3 大模型输出结构化：为什么必须强制 JSON，以及如何驯服它的“自由发挥”

让大模型输出 JSON 看似简单，实则充满陷阱。我最初用response = model.generate(prompt)，结果模型常在 JSON 外围加解释性文字（如“好的，这是您要的 JSON：\n{...}”），导致json.loads()报错。后来发现，强制 JSON 的关键是“约束输出格式”而非“要求输出 JSON”。Qwen3 的最佳实践是：

Prompt 中明确禁用解释性文字：在模板末尾加一句“注意：只输出纯 JSON，不要任何前导、后缀、说明文字，不要用代码块包裹。”
API 调用时设置temperature=0.1：温度值越低，输出越确定、越少随机性。0.1 是平衡准确性和少量必要变化的黄金值。
后处理增加容错解析：即使模型“不小心”加了前缀，也要能救回来。我的解析函数：

import json import re def safe_json_parse(text): # 先尝试直接解析 try: return json.loads(text) except json.JSONDecodeError: pass # 再尝试提取第一个 { } 包裹的内容 match = re.search(r'\{.*?\}', text, re.DOTALL) if match: try: return json.loads(match.group(0)) except json.JSONDecodeError: pass # 最后尝试修复常见错误：单引号替换为双引号，末尾逗号删除 fixed = text.replace("'", '"').rstrip(',') try: return json.loads(fixed) except: raise ValueError("无法解析为有效 JSON")

这套组合拳让 JSON 解析成功率从 68% 提升到 99.4%。更重要的是，它教会我一个原则：不要指望 AI 100% 正确，而要设计能容忍 5% 错误的健壮系统。就像汽车安全气囊，不是为了防止车祸，而是为了在车祸发生时保命。

4. 实操过程与核心环节实现

4.1 步骤一：创建 Bot 并配置 Webhook（含 Cloudflare Tunnel 实操）

我们从零开始，用真实终端命令演示。假设你有一台 Ubuntu 22.04 服务器（阿里云/腾讯云均可），已安装 Docker。

第一步：获取 Bot Token

在 Telegram 中搜索 @BotFather
发送/newbot
按提示输入 Bot 名称（如My Workbench）和用户名（如my_workbench_bot）
保存返回的 Token（形如1234567890:ABC...xyz），这是你 Bot 的唯一密钥

第二步：部署 Cloudflare Tunnel
Cloudflare Tunnel 是绕过国内 ICP 备案、获得免费 HTTPS 地址的最简方案。全程命令行操作：

# 下载并安装 cloudflared curl -L https://github.com/cloudflare/cloudflared/releases/latest/download/cloudflared-linux-amd64 -o cloudflared chmod +x cloudflared sudo mv cloudflared /usr/local/bin/ # 登录 Cloudflare 账户（会打开浏览器） cloudflared tunnel login # 创建隧道 cloudflared tunnel create my-tg-bot # 获取隧道 ID（用于后续配置） cloudflared tunnel list # 编辑配置文件（路径通常为 ~/.cloudflared/<TUNNEL_ID>.yml） # 将以下内容写入 YAML 文件： tunnel: <YOUR_TUNNEL_ID> credentials-file: /root/.cloudflared/<YOUR_TUNNEL_ID>.json ingress: - hostname: tg-bot.example.com # 可选，若想用自定义域名 service: http://localhost:5000 - service: http_status:404

第三步：启动 Webhook 服务（Python Flask 示例）
创建app.py：

from flask import Flask, request, jsonify import os from dotenv import load_dotenv load_dotenv() app = Flask(__name__) @app.route('/webhook', methods=['POST']) def webhook(): # 验证 Telegram 请求（可选，但强烈建议） if request.headers.get('X-Telegram-Bot-Api-Secret-Token') != os.getenv("WEBHOOK_SECRET"): return "Unauthorized", 401 data = request.get_json() # 这里是 Bot 的核心逻辑入口，暂留空，后续填充 print("Received:", data) return jsonify({"ok": True}) if __name__ == '__main__': app.run(host='0.0.0.0', port=5000, debug=False)

创建.env文件：

TELEGRAM_BOT_TOKEN=1234567890:ABC...xyz WEBHOOK_SECRET=my_super_secret_token_123

运行服务：

pip install flask python-dotenv python app.py

第四步：配置 Webhook
在服务器终端执行（替换<YOUR_TOKEN>和<CLOUDFLARE_URL>）：

curl -F "url=https://<CLOUDFLARE_URL>/webhook" \ -F "secret_token=my_super_secret_token_123" \ https://api.telegram.org/bot<YOUR_TOKEN>/setWebhook

成功返回{"ok":true,"result":true,"description":"Webhook was set"}。此时，所有发给 Bot 的消息都会实时 POST 到你的https://<CLOUDFLARE_URL>/webhook。

注意：secret_token是可选但强烈推荐的安全措施。它会在每次 Telegram 请求头中带上X-Telegram-Bot-Api-Secret-Token，你的服务可校验此值，防止伪造请求。务必在.env中配置并与 curl 命令一致。

4.2 步骤二：搭建本地大模型服务（Ollama + Qwen3）

为什么选 Ollama？因为它解决了三个痛点：1）一键安装，无需编译 CUDA；2）模型仓库丰富，Qwen3-4B 量化版仅 3.2GB；3）HTTP API 简洁，curl http://localhost:11434/api/chat即可调用。以下是完整部署流程：

第一步：安装 Ollama
Ubuntu 系统：

curl -fsSL https://ollama.com/install.sh | sh # 启动服务 systemctl enable ollama systemctl start ollama

第二步：下载并运行 Qwen3-4B
Qwen3 是通义实验室最新开源模型，中文理解能力显著优于 Llama3-8B，且 4B 版本在 8GB 显存显卡（如 RTX 3070）上流畅运行：

# 拉取模型（约 3.2GB，需 10-15 分钟） ollama pull qwen3:4b # 运行模型（后台服务） ollama run qwen3:4b # 此时会进入交互式聊天，输入 'exit' 退出

第三步：测试 API 调用
Ollama 默认开启http://localhost:11434API。用 curl 测试：

curl http://localhost:11434/api/chat -d '{ "model": "qwen3:4b", "messages": [ {"role": "user", "content": "你好，你是谁？"} ], "stream": false }' | jq '.message.content'

预期输出：我是通义千问，阿里巴巴研发的超大规模语言模型。。jq是 JSON 解析工具，若未安装，apt install jq。

第四步：集成到 Bot Agent
在app.py中添加模型调用函数：

import requests import json def call_ollama_model(prompt): url = "http://localhost:11434/api/chat" payload = { "model": "qwen3:4b", "messages": [{"role": "user", "content": prompt}], "stream": False, "options": {"temperature": 0.1} } try: response = requests.post(url, json=payload, timeout=30) response.raise_for_status() return response.json()["message"]["content"] except Exception as e: print(f"Ollama call failed: {e}") return "AI 服务暂时不可用，请稍后再试。" # 在 webhook 处理函数中调用 @app.route('/webhook', methods=['POST']) def webhook(): data = request.get_json() if "message" not in data: return jsonify({"ok": True}) text = data["message"].get("text", "") chat_id = data["message"]["chat"]["id"] # 简单回复测试 reply = f"收到：{text}。正在调用 AI..." send_telegram_message(chat_id, reply) # 调用大模型 ai_response = call_ollama_model(f"请用一句话总结：{text}") send_telegram_message(chat_id, f"AI 总结：{ai_response}") return jsonify({"ok": True})

现在，当你给 Bot 发送任意消息，它会先回复“收到”，再调用本地 Qwen3 生成总结并发送。这就是自动化工作台的“AI 心脏”第一次跳动。

4.3 步骤三：用 Make.com 连接外部工具（以飞书日程同步为例）

Make.com 是本教程推荐的编排平台，因其零代码、高可靠、中文界面友好。我们以“同步飞书日程到 Telegram”为例，展示完整配置。

第一步：在 Make.com 创建新场景（Scenario）

登录 make.com → 点击 “Create a new scenario”
搜索 “Telegram”，选择 “New message in a chat” 触发器
点击 “Connect an account”，按指引授权你的 Telegram Bot（需输入 Bot Token）
配置触发器：选择 “Private chats only”（避免群组干扰），勾选 “Text messages only”

第二步：添加飞书日历模块

点击 “+ Add a module” → 搜索 “Feishu”，选择 “Get events from calendar”
点击 “Connect an account”，用飞书管理员账号扫码授权（需开通飞书开放平台并创建自建应用）
配置参数：
- Calendar ID：选择你的日历（如 “我的日程”）
- Time range：选择 “Last 7 days”（可根据需求调整）
- Max results：设为 50（防超时）

第三步：添加数据处理与 Telegram 发送模块

添加 “Data tools” → “Text parser” 模块，用正则提取用户想查的日期（如r'日程\s*(.*)'）
添加 “Feishu” → “Get events from calendar”，将上一步提取的日期传入Time range

添加 “Telegram” → “Send message”，配置：

Chat ID：来自触发器的chat.id

Text：用模板编辑器拼接，例如：

📅 您的日程（{{modules.text_parser.output.date}}）： {{#each modules.feishu_get_events.output.events}} • {{title}} - {{start_time}} 至 {{end_time}} {{/each}}

第四步：测试与发布

点击右上角 “Run once” 测试，发送 “日程今天” 到 Bot 私聊
Make.com 会显示完整执行日志：Telegram 触发 → 飞书 API 调用 → 数据解析 → Telegram 发送
成功后点击 “Turn on” 发布场景

整个过程无需写一行代码，所有 token 和密钥均由 Make.com 安全存储。当飞书日历 API 更新或 Telegram Bot Token 重置时，你只需在 Make.com 的对应模块里更新凭证，无需动任何代码。这就是低代码编排的核心价值：把集成的复杂性，封装在平台的可视化界面里。

4.4 步骤四：构建 Jenkins 构建触发器（CI/CD 自动化）

对于开发者，把 TG Bot 变成 CI/CD 控制台是刚需。用户说“构建 prod 分支”，Bot 就该触发 Jenkins 构建。这需要 Jenkins 开放 API 并配置 CSRF 保护。

第一步：配置 Jenkins API 访问

Jenkins 管理 → Configure Global Security
勾选 “Enable security” → “Jenkins’ own user database”
在 “Authorization” 中选择 “Matrix-based security”
添加用户（如tg-bot），赋予Overall/Read,Job/Build,Job/Read权限
进入 “People” →tg-bot→ “Configure” → “API Token” → 生成新 Token（记为JENKINS_API_TOKEN）

第二步：在 Make.com 创建 Jenkins 触发场景

新建 Scenario，触发器用 “Telegram: New message in a chat”
添加 “HTTP” 模块（因 Jenkins 无官方 connector）：
- Method：POST
- URL：https://your-jenkins-url/job/YOUR_JOB_NAME/build
- Headers：
  - Content-Type: application/x-www-form-urlencoded
  - Authorization: Basic {{base64_encode("tg-bot:JENKINS_API_TOKEN")}}
- Body：token=YOUR_BUILD_TOKEN&cause=Triggered+by+Telegram+Bot
注意：Jenkins 需在 Job 配置中启用 “Trigger builds remotely”，并设置Authentication Token（如tg-build-token）

第三步：在 Bot Agent 中识别构建意图
修改fast_intent_match函数：

if re.search(r'构建|build|deploy', text) and ('prod' in text or 'dev' in text): env = 'prod' if 'prod' in text else 'dev' return {"intent": "jenkins_build", "env": env}

当识别到此意图，Agent 向 Make.com 的 Jenkins 场景 Webhook 发送 POST 请求，携带{"env": "prod"}。Make.com 收到后，动态拼接 Jenkins URL（如job/my-app-prod/build）并触发构建。

实测效果：从发送指令到 Jenkins 显示 “Started by remote host”，平均耗时 2.3 秒。构建日志会自动推送回 Telegram，形成闭环。这比登录 Jenkins Web UI 点击快 5 倍，且可随时随地操作。