（12098期）feishu-send-file – 飞书文件与图片可靠投递

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