5分钟搭建n8n+飞书自动化，告别重复劳动

5分钟搭建n8n+飞书自动化，告别重复劳动 5分钟搭建n8n+飞书自动化，告别重复劳动 Modified June 16, 2025 No access n8n+飞书演示 00:00 n8n × 飞书：打造自动化工作流 Unable to preview. Please download the file. Code block Plain Text Copy Error Trigger ↓ Get Feishu Token（获取令牌） ↓ Create Error Record（创建错误记录） ↓ Done 步骤一：获取访问令牌 首先添加一个HTTP Request节点，专门用于获取tenant access token： 🙋 节点配置： 根据飞书的接口文档(https://open.feishu.cn/document/server docs/api call guide/calling process/get access token)，配置以下字段内容 ①method：post ②url：https://open.feishu.cn/open apis/auth/v3/tenant access token/internal ③Authentication：none ④Send Query Parameters：无需选择 ⑤Send Headers：添加一个Header Parameters字段 name：Content Type value：application/json; charset=utf 8 ⑥Body Content Type 选择 Form Urlencoded，Specify Body 选择 Using Fields Below Body Parameters 添加两个字段 app id 和app secre t，然后把我们创建飞书应用时生成的id和secret维护进去即可。 配置完成后，我们来做下测试！点击节点右上角的"Test step"按钮，验证是否能拿到 tenant access token。 步骤二：创建错误记录 第二个 HTTP Request 节点用于实际创建错误记录，这里的关键是正确配置认证头。 🙋 节点配置： ①method：post ②url：https://open.feishu.cn/open apis/bitable/v1/apps/MPA1bOjK0aVUcnsSWg8cmCrCnve/tables/tblPJEMuO7zMJVOA/records ③Authentication：none ④Send Query Parameters：无需选择 ⑤Send Headers：添加二个Header Parameters字段 • name：Authorization value：Bearer {{ $json.tenant access token }} • name: Content Type value: application/json; charset=utf 8 ⑥Body Content Type 选择 Form Urlencoded，Specify Body 选择 Using JSON，具体数据结构如下 Code block Bash Copy { "fields":{ "Workflow": "{{ $('Error Trigger').item.json.workflow.name }}", "URL": "{{ $('Error Trigger').item.json.execution.url }}", "Timestamp": "{{ $now.format('yyyy MM dd HH:mm:ssa') }}", "Node": "{{ $('Error Trigger').item.json.execution.error.node.name }}", "Error Message":"{{ $('Error Trigger').item.json.execution.error.message }}", "Execution ID": "{{ $('Error Trigger').item.json.execution.id }}" } } HTTP Request 方式的核心优势 1. 动态Token管理 每次工作流运行时都会先获取最新的tenant access token，然后后续节点使用这个最新的Token进行API调用。这样就彻底避免了Token过期问题。 2. 配置集中化 App Secret只需要在获取Token的节点中配置一次，后续节点通过表达式引用，避免了敏感信息的重复暴露。 3. 完全的API访问能力 不受社区节点功能限制，飞书开放平台的任何API都可以直接调用。新功能上线？立刻就能使用。 4. 高度可定制化 可以添加复杂的错误处理逻辑、重试机制、数据验证等高级功能，完全按照你的业务需求定制。 这种方式虽然初期配置稍显复杂，但一旦搭建完成，你将拥有一个强大而灵活的自动化系统。特别是当你的需求超出标准功能范围时，HTTP Request 方式的价值就会充分体现出来。 结语：自动化时代，从现在开始 技术的进步从来不是线性的，而是跳跃式的突破。n8n与飞书的深度集成，为我们提供了一个窥见未来工作方式的窗口。 从今天开始： • 选择一个简单的重复性任务作为起点 • 设计你的第一个自动化工作流 • 逐步扩展，将更多业务场景纳入自动化范围 • 与团队分享经验，形成自动化文化 记住，最好的自动化不是替代人的工作，而是解放人的创造力。当机器处理例行公事时，我们就有更多时间去思考、创新、解决真正有价值的问题。 未来已来，你准备好了吗？ 🔗 原文链接：https://mp.weixin.qq.com/s/NpXu6lNRhhYd5JUyhH7X0g 作者：林月半子的AI笔记 No access n8n+飞书演示 00:00 No access n8n+飞书演示 00:00 n8n × 飞书：打造自动化工作流 Unable to preview. Please download the file. n8n × 飞书：打造自动化工作流 Unable to preview. Please download the file. 步骤一：获取访问令牌 首先添加一个HTTP Request节点，专门用于获取tenant access token： 🙋 节点配置： 根据飞书的接口文档(https://open.feishu.cn/document/server docs/api call guide/calling process/get access token)，配置以下字段内容 ①method：post ②url：https://open.feishu.cn/open apis/auth/v3/tenant access token/internal ③Authentication：none ④Send Query Parameters：无需选择 ⑤Send Headers：添加一个Header Parameters字段 name：Content Type value：application/json; charset=utf 8 ⑥Body Content Type 选择 Form Urlencoded，Specify Body 选择 Using Fields Below Body Parameters 添加两个字段 app id 和app secre t，然后把我们创建飞书应用时生成的id和secret维护进去即可。 节点配置： 根据飞书的接口文档(https://open.feishu.cn/document/server docs/api call guide/calling process/get access token)，配置以下字段内容 ①method：post ②url：https://open.feishu.cn/open apis/auth/v3/tenant access token/internal ③Authentication：none ④Send Query Parameters：无需选择 ⑤Send Headers：添加一个Header Parameters字段 name：Content Type value：application/json; charset=utf 8 ⑥Body Content Type 选择 Form Urlencoded，Specify Body 选择 Using Fields Below Body Parameters 添加两个字段 app id 和app secre t，然后把我们创建飞书应用时生成的id和secret维护进去即可。 配置完成后，我们来做下测试！点击节点右上角的"Test step"按钮，验证是否能拿到 tenant access token。 步骤二：创建错误记录 第二个 HTTP Request 节点用于实际创建错误记录，这里的关键是正确配置认证头。 🙋 节点配置： ①method：post ②url：https://open.feishu.cn/open apis/bitable/v1/apps/MPA1bOjK0aVUcnsSWg8cmCrCnve/tables/tblPJEMuO7zMJVOA/records ③Authentication：none ④Send Query Parameters：无需选择 ⑤Send Headers：添加二个Header Parameters字段 • name：Authorization value：Bearer {{ $json.tenant access token }} • name: Content Type value: application/json; charset=utf 8 ⑥Body Content Type 选择 Form Urlencoded，Specify Body 选择 Using JSON，具体数据结构如下 节点配置： ①method：post ②url：https://open.feishu.cn/open apis/bitable/v1/apps/MPA1bOjK0aVUcnsSWg8cmCrCnve/tables/tblPJEMuO7zMJVOA/records ③Authentication：none ④Send Query Parameters：无需选择 ⑤Send Headers：添加二个Header Parameters字段 • name：Authorization value：Bearer {{ $json.tenant access token }} • name: Content Type value: application/json; charset=utf 8 ⑥Body Content Type 选择 Form Urlencoded，Specify Body 选择 Using JSON，具体数据结构如下 HTTP Request 方式的核心优势 1. 动态Token管理 每次工作流运行时都会先获取最新的tenant access token，然后后续节点使用这个最新的Token进行API调用。这样就彻底避免了Token过期问题。 2. 配置集中化 App Secret只需要在获取Token的节点中配置一次，后续节点通过表达式引用，避免了敏感信息的重复暴露。 3. 完全的API访问能力 不受社区节点功能限制，飞书开放平台的任何API都可以直接调用。新功能上线？立刻就能使用。 4. 高度可定制化 可以添加复杂的错误处理逻辑、重试机制、数据验证等高级功能，完全按照你的业务需求定制。 这种方式虽然初期配置稍显复杂，但一旦搭建完成，你将拥有一个强大而灵活的自动化系统。特别是当你的需求超出标准功能范围时，HTTP Request 方式的价值就会充分体现出来。 结语：自动化时代，从现在开始 技术的进步从来不是线性的，而是跳跃式的突破。n8n与飞书的深度集成，为我们提供了一个窥见未来工作方式的窗口。 从今天开始： • 选择一个简单的重复性任务作为起点 • 设计你的第一个自动化工作流 • 逐步扩展，将更多业务场景纳入自动化范围 • 与团队分享经验，形成自动化文化 记住，最好的自动化不是替代人的工作，而是解放人的创造力。当机器处理例行公事时，我们就有更多时间去思考、创新、解决真正有价值的问题。 未来已来，你准备好了吗？ 🔗 原文链接：https://mp.weixin.qq.com/s/NpXu6lNRhhYd5JUyhH7X0g 作者：林月半子的AI笔记 还记得上次因为忘记更新项目状态而被 PM 追着跑的尴尬吗？或者那种在五个不同系统间反复 copy paste 客户信息的机械感？ 停！这种21世纪还在做重复劳动的画面，实在太违和了。 今天我要分享的，不是又一个"提效工具推荐"，而是一套能让你彻底告别手工搬砖的自动化组合拳：n8n × 飞书。这不仅仅是工具的叠加，更是一次让工作流程脱胎换骨的技术实践。 废话不多说。上干货。 🙋 工作流文件：https://pan.quark.cn/s/94592ecaa291 工作流文件：https://pan.quark.cn/s/94592ecaa291 同时，我用这篇文章内容生成了一个播客，非常有趣，且更容易理解本篇内容。感兴趣的朋友可以听听。 路径选择：两条道路的分岔口 连接 n8n 和飞书，你面前摆着两条截然不同的技术路径。选择哪条？这个问题比"今晚吃什么"更值得深思。 🎯 社区节点：快准狠的"即食方案" 社区中存在一个名为 n8n nodes feishu lite 的飞书节点，由社区成员开发。 n8n nodes feishu lite —— 这个名字听起来就很轻盈的社区节点包，像极了那种"开箱即用"的预制菜。一分钟安装，几次点击配置，就能让你的工作流跑起来。 优势显而易见： • 学习成本？几乎为零 • 配置复杂度？点点鼠标的事 • 上手速度？光速级别 但是——注意这个"但是"——当你的需求开始变得复杂，当飞书推出新功能而节点还没更新，当你想要实现一些"标准配置"之外的骚操作时...你会发现自己被困在了一个精美的笼子里。 ⚡ HTTP Request：硬核玩家的无界疆土 如果说社区节点是"傻瓜相机"，那么 HTTP Request 节点就是"专业单反"。复杂？确实。强大？绝对。 选择这条路意味着： • 飞书的每一个 API 接口都是你的武器库 • 新功能上线？你比社区节点更新得还快 • 自定义程度？想怎么玩就怎么玩 当然，这也意味着你需要撸起袖子，深入理解 API 文档、认证流程、参数规范...但正如健身界的名言："No pain, no gain"。短期的学习投入，换来的是长期的技术自由度。 入场券：飞书开放平台的通关攻略 应用创建：你的专属身份证 第一步，我们需要在飞书开放平台注册一个"数字身份"。 1. 打开飞书开放平台 飞书开放平台 2. 找到"开发者后台"，点击"创建企业自建应用" 3. 填写基本信息时别偷懒——名称要有辨识度，描述要清晰，图标要好看（颜值即正义！） 创建成功后，你会拿到两个关键凭证：App ID和App Secret。把它们当作银行卡号和密码一样保护，千万别泄露！ 权限申请：精准化的能力配置 飞书的权限系统设计得相当精妙，遵循"最小权限"原则。根据你的具体需求，申请对应的权限，建议遵循最小权限原则，只申请必要权限。 比方说当前文章我主要以操作多维表格举例，只需申请多维表格相关的权限。 实战演练：从0到1的完整案例 让我用一个真实场景将 n8n 和飞书串联起来——工作流错误统计。 想象这样的痛点：你的 n8n 工作流偶尔会在某个节点出错，邮件通知固然及时，但错误信息散落各处，无法形成有效的统计分析。如何将这些错误信息自动汇总到飞书多维表格，为后续的故障分析和系统优化提供数据支撑？ 这个案例将完美展示两种技术路径的具体实现。 🚨 错误处理工作流：三重保障通知体系 当n8n工作流执行出错时，我们可以设计一个多层次的通知和记录机制，确保问题能被及时发现和有效跟踪。 📋 快速选择指南 根据你的实际需求选择合适的通知方式： • 需要即时响应？ → 选择飞书群组通知 ◦ 优势：实时性强，团队协作方便 ◦ 适合：紧急错误、需要团队讨论的问题 ◦ 优势：实时性强，团队协作方便 ◦ 适合：紧急错误、需要团队讨论的问题 • 需要正式记录存档？ → 选择Email通知 ◦ 优势：正式、可追溯、支持附件 ◦ 适合：重要系统错误、需要向管理层汇报的问题 ◦ 优势：正式、可追溯、支持附件 ◦ 适合：重要系统错误、需要向管理层汇报的问题 • 需要长期统计分析？ → 选择飞书多维表格记录 ◦ 优势：结构化存储、便于分析、支持筛选统计 ◦ 适合：错误趋势分析、系统优化决策支撑 ◦ 优势：结构化存储、便于分析、支持筛选统计 ◦ 适合：错误趋势分析、系统优化决策支撑 🔄 三种通知方式的组合策略 最佳实践： 1. Email 作为基础通知，确保有正式记录 2. 多维表格 作为数据统计，便于后续分析优化 3. 飞书群组 作为即时通知，促进团队快速响应 这样的三重机制既保证了问题的及时发现，又为长期的系统优化提供了数据支撑。 🎯 准备工作：搭建数据基座 步骤一：创建多维表格 在飞书中新建一个多维表格，这将是我们的"错误日志数据库"。 创建完成后，在多维表格的 URL 这里，我们需要提取关键参数 app token 和 table id 这两个值。 这两个ID就像是你的专属"数据库地址"，后续所有API调用都需要用到。 步骤二：权限配置 权限这事儿，一步都不能少！我们需要给当前的多维表格，添加文档应用（就是之前创建的应用），在这个入口，把你的应用添加进去即可 步骤三：字段设计 为错误日志表格设计合理的字段结构： 字段名 类型 说明 Workflow 文本 工作流名称 URL 文本 工作流执行URL Timestamp 文本 错误发生时间 Node 文本 出错节点名称 Error Message 文本 详细错误信息 Execution ID 文本 执行实例ID 字段名 字段名 类型 类型 说明 说明 Workflow Workflow 文本 文本 工作流名称 工作流名称 URL URL 文本 文本 工作流执行URL 工作流执行URL Timestamp Timestamp 文本 文本 错误发生时间 错误发生时间 Node Node 文本 文本 出错节点名称 出错节点名称 Error Message Error Message 文本 文本 详细错误信息 详细错误信息 Execution ID Execution ID 文本 文本 执行实例ID 执行实例ID 这样的设计既保证了信息完整性，又便于后续的筛选和分析。 现在，基础设施就绪！让我们看看两种不同的实现方式。 方式一：社区节点实现错误日志统计 有了前面的准备工作，现在我们用社区节点的方式来实现错误统计功能。社区节点的魅力在于"开箱即用"——复杂的 API 调用被封装成了简洁的可视化配置。 工作流设计思路： 步骤一：创建飞书凭证 首先需要在 n8n 中创建一个飞书的凭证配置。这一步是为了让 n8n 能够安全地访问你的飞书应用。 凭证配置： • Name: 给凭证起个好记的名字，比如"飞书错误日志" • App ID: 复制之前在飞书开放平台创建的应用ID • App Secret: 复制对应的应用密钥 这里要注意的是，App ID 和 App Secret 必须与你在飞书开放平台创建的应用信息完全一致。一个字符都不能错！ 步骤二：配置多维表格节点 接下来配置多维表格节点的基本信息： 基础配置： • Credential: 选择刚才创建的飞书凭证 • Resource: 选择"多维表格" • Operation: 选择"新增记录" 关键参数： • 多维表格 Token: 填入之前提取的app token • 多维表格 ID: 填入之前提取的table id 这两个参数就是我们之前从 URL 中提取的关键信息，它们告诉 n8n 要往哪个表格写入数据。 步骤三：定义请求体结构 最关键的部分来了——请求体JSON配置。这里定义了要写入多维表格的具体数据结构： 重要提醒： 这里的字段名（如"Workflow"、"URL"等）必须与你在飞书多维表格中定义的字段名完全一致。包括大小写、空格、标点符号都不能有任何差异！ 表达式说明： • {{ $json.workflow.name }} 获取当前工作流名称 • {{ $json.execution.url }} 生成执行实例的访问链接 • {{ $now.format('yyyy MM dd hh:mma') }} 格式化当前时间 • {{ $json.execution.error.node.name }} 获取出错节点名称 • {{ $json.execution.error.message }} 获取具体错误信息 • {{ $json.execution.id }} 获取执行实例ID 步骤四：测试验证 配置完成后，最重要的一步就是测试！点击节点右上角的"Test step"按钮，验证配置是否正确。 如果测试成功，你应该能在飞书多维表格中看到新增的错误记录。 如果失败，检查以下几个常见问题： • 凭证信息是否正确 • 字段名是否与表格定义一致 • 权限是否已正确配置 方式二：HTTP Request 实现错误日志统计 如果说社区节点是"即食套餐"，那么 HTTP Request 就是"自由烹饪"。这种方式虽然配置相对复杂，但给了你完全的控制权和无限的扩展可能。 认证流程与凭证管理 使用 HTTP Request 方式，首先要解决的是认证问题。飞书API 主要通过access token进行认证，常用的有两种： tenant access token（应用级别凭证） • 代表应用自身进行操作 • 适用于大部分机器人、自动化场景（如发送群消息、操作应用拥有的多维表格等） • 需要使用App ID和App Secret获取 • 这是我们当前场景的首选方案 user access token（用户级别凭证） • 代表某个具体用户进行操作 • 适用于需要模拟用户行为的场景（如操作用户个人日历、以用户身份发送邮件等） • 获取流程遵循标准的OAuth 2.0，相对复杂，需要用户授权 对于我们当前的自动化任务场景，主要使用tenant access token。需要注意的是，tenant access token有效期通常为2小时，需要在使用前获取或刷新。 在n8n中处理 token，最佳实践是动态获取。为什么？因为token会过期，而手动更新token比手动搬砖还要痛苦。这样设计的好处是显而易见的：每次工作流执行都会获取最新 token，彻底避免过期问题。 工作流设计：