这篇文章是我一次真实排障的完整记录：把 Outlook 邮箱里 OpenAI 登录验证码邮件，自动提取后推送到飞书机器人。
我一开始以为只是“连三个模块”，结果中间被各种细节绊住：字段不知道怎么填、变量不出现、正则看起来匹配但输出是空、链路跑通后又卡在常驻运行配置。
最后是跑通了，而且已经稳定工作。这里把完整过程写下来，给未来的自己，也给遇到同类问题的人一个可以直接复用的版本。
目标与最终结果
目标很简单：
- Outlook 收到 OpenAI 登录验证码邮件。
- 自动提取其中 6 位验证码。
- 飞书群机器人实时收到验证码消息。
最终结果：
- 全链路已跑通。
- 消息只包含验证码，不再转发整封邮件。
- Scenario 已开启自动调度，可持续运行。
先说结论：这条链路的正确结构
flowchart LR
A["Outlook / Email Trigger"] --> B["Text parser: Match pattern"]
B --> C["HTTP: Make a request (Feishu Webhook)"]
关键点不是“模块数量”，而是“数据流顺序”和“变量可见条件”：
- HTTP 只能用到它上游真实跑过的数据。
- Text parser 必须用支持自定义正则的
Match pattern动作。 - 验证码正则必须带捕获组：
\b(\d{6})\b。
过程复盘：我踩过的坑和修复动作
下面按真实推进顺序写。
坑 1：HTTP 模块第一步就卡字段
问题现象：
Authentication type报必填。- 不确定 Headers、Body content type 怎么填。
修复动作：
Authentication type选None（飞书 Webhook 已在 URL 中携带鉴权能力）。Method选POST。Body content type选JSON。- URL 填飞书机器人 Webhook 地址。
最小可用 Body：
{
"msg_type": "text",
"content": {
"text": "Pipeline test message."
}
}
先把“能发出去”做出来，再做动态变量替换。
坑 2：打通后，Body 还是写死文本
问题现象：
- 飞书能收到消息，但内容是固定字符串。
- 还没有连接到上游邮件数据。
修复动作：
- 保留 JSON 骨架。
- 把
text内容改为“文本 + 上游变量”的组合。 - 优先使用邮件模块的
Text content，避免 HTML 正文把 JSON 搞乱。
这一步让我意识到：先“可用”，再“正确”；先“链路通”，再“内容精确”。
坑 3：想提取验证码，结果 Pattern 不能自定义
问题现象：
- 进入了 Text parser，但 Pattern 是下拉菜单，不能输入正则。
根因：
- 选错了 Text parser 的动作（用了预设提取动作，不是正则匹配动作）。
修复动作：
- 删除当前解析模块。
- 重新添加 Text parser。
- 在 Action 里明确选择
Match pattern。
坑 4：Text parser 跑完，HTTP 里看不到它的变量
问题现象：
- HTTP 变量面板只有 Webhook/邮件模块，没有 Text parser。
根因（两个）：
- 模块顺序或连线不对（不是严格上游链路）。
- Text parser 没有真实运行过，Make 不知道它会产出什么结构。
修复动作：
- 确认链路顺序：
Email/Outlook -> Text parser -> HTTP。 - 右键 Text parser，执行
Run this module only，喂一段真实邮件文本。 - 让输出结构被 Make 识别后，再回 HTTP 插入变量。
这一步是全程最关键的“平台机制认知”转折点。
坑 5：输入里有验证码，输出却是 empty
问题现象：
- Text parser Input 明明包含
674293。 - Output 却是
empty。
根因：
- 正则用了
\b\d{6}\b，能匹配但没有捕获组，导致没有可映射字段输出。
修复动作：
- 把 Pattern 改成
\b(\d{6})\b。 - 重新
Run this module only。 - 输出出现
$1: 674293，链路恢复。
这一步直接决定后面能不能把验证码塞进飞书消息。
坑 6：链路跑通后，如何持续运行
问题现象：
Run once可用，但不是常驻自动化。
修复动作：
- 保存 Scenario。
- 打开
Scheduling开关（ON）。 - 在
Schedule settings里把Maximum runs to start per minute留空（我的场景需要即时触发）。
如果担心突发邮件洪峰，可以填 10 或 20 做软限流。
最终配置（可直接对照）
Text parser（Match pattern）
Pattern: \b(\d{6})\b
Global match: No
Case sensitive: No
Multiline: No
Singleline: No
Continue route if no matches: No
Text: map from Email module -> Text content
HTTP（Make a request -> Feishu）
Method: POST
Body content type: JSON
URL: https://open.feishu.cn/open-apis/bot/v2/hook/xxxxx
{
"msg_type": "text",
"content": {
"text": "OpenAI login code:\n{{Text parser.$1}}"
}
}
说明：
{{Text parser.$1}}代表在 Make 中点击变量面板插入的彩色变量，不是手打字符串。- 光标位置必须在
text字段字符串内部。
验证清单（我实际用这套）
- 右键 Text parser，
Run this module only，确认输出有$1。 Run once全链路测试，飞书收到验证码。- Outlook 再收一封真实验证码邮件，飞书再次收到。
- 打开 Scheduling，观察一段时间，确认持续触发。
这次最有价值的三条心得
- 先通链路，再做精细化：先让 HTTP 发出去，再做变量映射和验证码提取，效率最高。
- 排障看“数据流”，不是看“感觉”：每次都问自己，当前模块输入是什么、输出是什么、下游是否可见。
- 正则不是匹配到就结束：在 Make 这种平台里，能被下游用到的数据要有可输出结构，捕获组是关键。
后续可选增强
- 在邮件触发阶段加过滤条件，只处理发件人为
noreply@tm.openai.com且主题包含Log-in Code的邮件。 - 飞书消息模板增加时间戳和来源标识，便于审计。
- 将 Webhook URL 存到安全变量，避免在多人协作时明文暴露。
如果你也在做类似的验证码自动化，建议直接照着“最终配置 + 验证清单”先跑通，再按自己的场景做裁剪。