飞书文件与图片可靠投递

基于飞书官方 API 构建，稳定解决文件（HTML/PDF/代码等）上传与发送问题，并专门修复本地图片发送显示路径而非图片的常见故障，提供可靠消息触达保障。

基本信息

• 技能名称?feishu-send-file
• 中文名称?飞书文件与图片可靠投递
• 作者?dadaniya99
• 分类?专业技能
• 版本?1.2.1
• 标签?docs, content-media, automation, api, backend

使用方法

使用说明
核心用法
feishu-send-file 是一款专门用于通过飞书机器人向用户发送普通文件（如 HTML、PDF、ZIP、代码文件）和稳定投递本地图片的技能。它严格遵循飞书官方 API 规范，提供两种主要功能：第一，普通文件的两步发送机制（先调用 im/v1/files 获取 file_key ，再通过 msg_type=file 发送）；第二，针对“本地图片在飞书中只显示路径文本而非图片本体”这一棘手问题，提供了基于 im/v1/images 接口的稳定图片上传脚本，确保用户最终看到的是图片本身，而非无效的路径字符串。
显著优点

1. 解决真实痛点 ：技能专门补救 OpenClaw 或飞书插件在某些场景下无法正确处理本地图片路径的固有问题，提供了一条稳定、可靠的图片发送备选链路，实用性极强。
2. 行为高度透明 ：所有网络请求仅发往飞书/Lark 官方 API 端点（ open.feishu.cn 与 open.larksuite.com ），无任何第三方中转或数据泄露风险，并且代码功能与声明完全一致，无隐藏行为。
3. 零外部依赖 ：两个核心 Python 脚本仅使用 sys 、 os 、 json 、 urllib 、 subprocess 等 Python 标准库，杜绝了供应链攻击和依赖冲突风险，部署和维护极为简单。
4. 多环境兼容 ：脚本同时支持飞书和 Lark（国际版）环境，只需通过 domain 参数或 --lark 标志即可切换，覆盖更广泛的用户群体。
   潜在缺点或局限性
5. 代码实现有轻微质量顾虑 ：Python 脚本使用 subprocess.run 调用外部 curl 命令进行文件上传，而非使用 Python 原生的 urllib.request 进行多部分表单上传，这引入了对系统 curl 的依赖，且存在理论上的命令注入窗口（尽管在内部参数传递的场景下实际风险极低）。
6. 凭证传递方式不够安全 ：飞书应用的 app_id 和 app_secret 通过命令行参数传入脚本，在多用户系统中，可能通过 ps aux 或 /proc/*/cmdline 被他人窥探，存在凭证泄露隐患。
7. 文档示例存在不良实践 ：SKILL.md 中为 AI 助手展示的 exec(f"""...""") 动态拼接命令的示例模式，虽然是教学用途，但容易误导开发者采用不安全的动态代码执行，有违安全编码原则。
8. 来源可信度有限 ：该技能由个人开发者 dadaniya99 维护（T3 来源），其公开的信誉和社区影响力信息较少，用户需要自行评估长期维护和问题响应能力。
   适合的目标群体
   深度使用飞书/Lark 进行工作协作的开发者 ，尤其是经常需要通过机器人自动发送报告、代码文件或数据导出结果的团队。
   使用 OpenClaw 或类似飞书消息框架的 Agent 开发者 ，他们在开发中频繁遇到图片发送降级为路径文本的问题，急需一套可靠的解决方案。
   任何希望通过脚本化或自动化流程向飞书用户下发文本化文件 （如日报、HTML 摘要、压缩包）的运维人员或产品运营人员。
   使用该技能可能存在的风险
   性能风险 ：对 subprocess 和 curl 的调用会为每一次文件/图片上传创建一个新的进程，在高并发或批量发送场景下，进程创建开销和系统资源消耗会显著增加，效率远低于使用原生 HTTP 库实现连接复用。
   依赖项风险 ：脚本依赖运行时环境中 curl 命令可用，在某些极简 Docker 镜像或沙箱环境下可能因缺少 curl 而导致脚本执行失败。
   安全风险 ：虽然目前风险较低（A 级），但命令行凭证泄露、文档中 exec() 的不良示范等，在安全要求极高的生产环境中依然是减分项。若系统存在其他漏洞，攻击者联合利用本地进程列表信息获取凭证，可接管飞书应用权限。建议用户在使用时优先通过环境变量注入凭证，并提取脚本中的核心逻辑用 urllib 重写。