核心用法
feishu-interactive-cards 是专为飞书(Lark)生态设计的交互式卡片技能,核心设计哲学是"任何不确定场景都发送交互卡片而非纯文本"。该技能通过 Node.js 脚本实现卡片发送与回调处理,支持确认对话框、待办清单、投票、表单等多种交互模式。
使用流程分为三步:启动长轮询回调服务器(无需公网IP)、调用 send-card.js 发送卡片、通过 OpenClaw Gateway 接收用户点击回调。Agent 可在回调处理中执行实际操作,并实时更新卡片状态反馈结果。
显著优点
1. 安全架构完善:v1.0.1 和 v1.0.2 连续修复命令注入和任意文件读取漏洞,全面采用 Node.js 内置 API 替代 shell 命令,实现目录白名单、扩展名验证、路径规范化等多重防护。
2. 交互体验优秀:将不确定决策转化为可视化按钮选择,显著降低用户输入错误,支持卡片状态实时更新,形成完整的交互闭环。
3. 部署门槛低:长轮询模式无需公网 IP 或域名配置,本地即可运行回调服务器,自动重连机制保障稳定性。
4. 文档规范详尽:包含独立的安全最佳实践文档、CHANGELOG 记录修复历史、代码示例均带安全注释,体现成熟的开源治理。
潜在缺点与局限性
1. 依赖外部服务:需长期运行回调服务器和 OpenClaw Gateway,增加了架构复杂度和运维成本。
2. T3 来源可信度:作者为个人开发者(yangyang),非知名组织或官方出品,长期维护承诺存在不确定性。
3. 功能边界限制:自定义模板受限于目录白名单(仅 examples/ 和 templates/),灵活性有所折损。
4. 网络依赖性强:飞书 API 调用和回调传输均依赖网络,弱网环境下可能出现延迟或超时。
适合的目标群体
- 企业飞书用户:需要在群聊或私聊中实现审批确认、任务分派、投票决策等场景
- Agent 开发者:构建需要用户二次确认的自动化工作流,如文件删除、数据修改等敏感操作
- 运维/运营团队:通过交互卡片实现告警确认、值班交接、发布审批等运维场景
使用风险
1. 凭证泄露风险:飞书 appId/appSecret 存储于本地配置文件,需确保文件权限控制(建议 600)。
2. 回调服务器稳定性:长轮询连接中断期间可能丢失用户点击事件,需配合超时提醒机制。
3. 依赖包供应链风险:依赖 axios 和飞书官方 SDK,需定期执行 npm audit 检查漏洞。
4. 权限配置不当:若 Gateway token 配置弱或泄露,可能导致回调数据被截获。