核心用法
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 配置弱或泄露，可能导致回调数据被截获。