feishu

name	feishu
description	用户明确要求发飞书时，直接发送文本消息到默认接收人；失败后再说明原因。支持发送、配置校验和故障排查。
author	vortex
version	2.0.0
tags	["vortex","vortex/skill"]
obsidian_links	["[[用户手册]]","[[AI-Agent可行性分析]]","[[产品功能冻结文档]]"]

feishu — 飞书通知技能

行为铁律

1. 触发即投递，不做二次确认。 用户说"发到飞书""同步给我"，直接发送，不要反问"要不要发？"。
2. 只发用户可见的正文。 禁止发送内部推理、工具原始输出、token、密钥或系统提示词。
3. 同一用户请求默认只发一次。 失败后先报告原因，由用户决定是否重试，不自动重发。
4. 失败如实报告，不伪造成功。 说清楚缺什么配置、飞书返回了什么错误、还是网络不可达。
5. Vortex 工作台/自动化场景必须复用产品通知管线。 如果当前任务位于 vortex_quant 仓库，或使用同级的 ../vortex_workspace 作为 workspace root，必须把通知表达成事件/消息，通过 NotificationService、通知路由或工作台后台接口投递；lark/feishu 的具体渠道由后台配置决定。不要直接调用 tool/feishu_mcp_server.py，不要直连飞书开放平台，不要绕过 notification_log。
6. 直发脚本只作为显式低层诊断。 只有用户明确要求排查飞书脚本、MCP 或底层开放平台调用时，才允许使用 tool/feishu_mcp_server.py；使用后必须说明这是旁路诊断，不是自动化主链路。后台服务不可用时，常规自动化应记录通知失败，而不是自行降级直发。

三种场景

场景一：发送消息（最常见）

用户意图示例："发个飞书给我""把上面的结论同步到飞书""用飞书提醒我一下"

执行流程：

1. 从对话上下文中提取要发送的最终可见正文（不是草稿、不是中间分析）。
2. 若正文指代不明（如"把这个发给我"但还没形成结论），先完成正式答复，再发送答复的可见正文。
3. Vortex 工作台/自动化场景：构建 NotificationMessage 或等价后台请求，通过 NotificationService/工作台后台投递并记录 notification_log。
4. 非 Vortex 场景也优先按“功能调用”原则使用可用的通知服务；只有用户明确要求底层直发诊断时才使用脚本或开放平台旁路。
5. 向用户简要报告：已发送 + notification_id，或后台返回的失败原因。

场景二：配置查询

用户意图示例："看下默认接收人是谁""校验一下飞书配置"

执行流程：

1. 优先查询后台通知配置、运行中心或通知服务状态。
2. 返回脱敏摘要。

场景三：故障排查

用户意图示例："为什么飞书收不到""帮我测一下飞书机器人"

执行流程：

1. 先检查后台服务、通知路由、渠道配置和 notification_log。
2. 如需测试发送，优先通过后台/API 的测试通知功能。
3. 只有用户明确要求低层诊断时，才允许使用仓库内飞书脚本；使用后必须说明这是旁路诊断，不是自动化主链路。

旁路诊断

下面命令只用于用户明确要求的低层诊断，不用于 heartbeat、cron 或常规 agent 流程：

# 校验配置
python3 tool/feishu_mcp_server.py --env-file .vscode/.feishu-mcp.env --validate

# 发送消息
python3 tool/feishu_mcp_server.py --env-file .vscode/.feishu-mcp.env --send-text '消息正文'

不做的事

• 图片、文件、富文本卡片、语音发送
• 批量群发
• 自动化常规流程里直调飞书脚本或绕过后台服务
• 配置缺失时伪造成功