很多公司的AI使用，最后停在一个聊天窗口里。
员工把会议纪要复制进去，生成一份任务清单，再复制到飞书项目、Jira或CRM。局部确实快了，但信息仍然靠人搬来搬去。
真正进入业务流程，要多走一步：让系统自动拿到输入，AI只负责自己擅长的整理和判断草稿，人确认以后，再把结果写回原来的业务系统。
这一步听起来复杂，其实可以先从一条很窄的流程开始。
这次只做“会议纪要转任务”
目标流程：
飞书妙记或会议记录
→ n8n接收Webhook
→ Dify提取任务和待确认问题
→ 飞书发送确认卡片
→ 负责人确认或修改
→ n8n写入Jira、飞书项目或测试表
→ 记录处理日志最小版本先不写正式任务系统。
把最后一步写进一张测试表，确认任务提取和人工审批稳定，再换成Jira、CRM或工单接口。这样出错时容易清理，也不会污染生产数据。
为什么用n8n做外层流程
n8n适合处理Webhook、API调用、条件分支、等待、重试和系统写回。Dify更适合管理模型、提示、知识检索和Agent流程。FastGPT也可以承担知识和模型处理，国内团队可以根据模型接入和部署条件选择。
如果公司已经重度使用Microsoft 365，可以评估Power Automate。以飞书为中心的团队，也可以先使用飞书现有自动化，再在需要模型和跨系统处理时接n8n。
我会把职责分开：
| 层 | 负责什么 | 不负责什么 |
|---|---|---|
| n8n | 触发、系统连接、审批状态、重试、写回、日志 | 不承担复杂业务判断 |
| Dify或FastGPT | 模型、知识、结构化提取、提示版本 | 不直接拥有生产系统高权限 |
| 飞书/Jira/CRM | 正式业务记录和人员权限 | 不把AI中间结果当最终事实 |
| 人 | 确认需求、负责人、时间和承诺 | 不重复搬运已经结构化的信息 |
开始前准备这些东西
- 一个n8n测试环境；
- 一个Dify或FastGPT测试应用；
- 公司批准的模型API；
- 飞书测试应用或其他可发送确认消息的渠道；
- 一张测试任务表，至少包含标题、描述、负责人、截止时间、来源链接和状态；
- 10段脱敏会议记录；
- 一个只对测试系统有写权限的服务账号。
API密钥放在n8n凭据管理或环境变量里，不要写进工作流节点文本、Markdown或截图。
Dify只做结构化提取
先把任务定义得克制一点。
输入是一段会议记录，输出固定JSON：
{
"meeting_id": "meeting-20260724-01",
"tasks": [
{
"title": "确认设备断线后的补传策略",
"owner": "待确认",
"due_date": null,
"source_quote": "需要技术部确认断线期间的数据怎么补传",
"confidence": "medium"
}
],
"open_questions": [
"补传数据是否需要覆盖原有统计结果？"
]
}提示里要明确：
- 不猜负责人和截止时间；
- 每个任务保留原文依据；
- 没说清楚的内容进入
open_questions； - 不生成报价、合同或交付承诺；
- 输出必须符合JSON结构。
先用10段记录手工调用，确认JSON稳定，再接n8n。
n8n工作流需要哪些节点
不依赖具体版本名称，可以按职责搭建：
- Webhook接收会议ID、文本和来源URL；
- 校验必填字段，缺少会议ID直接返回错误；
- 生成
idempotency_key，例如会议ID加记录版本； - 查询处理日志，已经成功的请求不重复创建任务；
- HTTP Request调用Dify或FastGPT API；
- 校验返回JSON和任务数量；
- 生成飞书确认消息；
- 等待负责人确认、修改或拒绝；
- 确认后写入测试任务表；
- 保存输入摘要、模型版本、输出、人工修改和最终状态。
这里最容易被忽略的是第3、4步。
Webhook可能重发，人工也可能重复点击。如果没有幂等键，同一场会议会创建两遍任务。自动化流程不是跑通一次就够了，它要能面对重复、超时和中断。
人工确认应该看什么
确认卡片不要只有“同意”和“拒绝”。
至少显示：
- 任务标题；
- 原文依据；
- 建议负责人；
- 截止时间；
- 置信度；
- 尚未确认的问题；
- 原会议链接。
负责人可以修改后确认。最终写入系统的内容和AI原始结果都保留，方便以后知道模型在哪些地方经常出错。
失败时不要悄悄丢掉
这条流程至少会遇到这些失败：
| 失败 | 处理方式 |
|---|---|
| 模型API超时 | 指数退避重试有限次数，仍失败则进入人工队列 |
| 返回不是合法JSON | 保存原始输出，不写业务系统，等待人工处理 |
| 飞书消息发送失败 | 记录错误并通知流程负责人 |
| 等待确认超过时间 | 标记超时，不自动创建任务 |
| 写入业务系统失败 | 保留已确认数据，允许安全重试 |
| Webhook重复 | 用幂等键返回已有处理结果 |
不要让失败分支直接结束。
每个失败都要有状态、日志和责任人。否则流程看起来自动化了，实际错误只是从员工眼前消失了。
权限尽量小
n8n使用的服务账号第一阶段只写测试表，不要给删除、审批和管理员权限。
Dify或FastGPT只接收脱敏后的会议文本。涉及客户合同、个人信息或未发布经营数据时，要确认数据能否进入所选模型和部署环境。
写入正式系统以后，也只创建“待确认”任务，不自动改变项目承诺、客户报价或生产状态。
怎样验收这条流程
用10段会议记录跑完整流程，记录：
- Webhook到确认卡片需要多久；
- JSON成功率；
- 提取任务的准确率；
- 人工修改了哪些字段；
- 重复请求是否只创建一份结果；
- 模型和系统失败能否恢复；
- 每次调用成本；
- 负责人是否愿意继续使用。
在测试表稳定运行两周，再接正式任务系统。
如果人工每次都要重写大部分内容，先调整输入和提取规则，不要急着增加更多节点。
真正有价值的自动化，不是流程图上有多少个方块。
而是信息只输入一次，错误看得见，关键决定仍然有人负责，系统失败以后还能回到一个清楚的位置继续处理。
暂无评论