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