Stability AI 文生音频

问题背景

在自动化流程里集成 Stability AI 的文生音频能力时，最常见的坑是凭证管理：要么把 API Key 硬编码进脚本，要么在 CI 环境里维护一堆环境变量。一旦密钥泄漏或轮换，整个流水线都要跟着改。这个技能把这件事外包给了 OOMOL：你只管描述要生成什么，凭证由服务端注入，客户端不碰原始 token。

工作原理

技能的核心只有一个动作 text_to_audio：输入文本提示，Stability AI 生成音频文件，随后上传到连接器的 transit storage，你拿到的是文件引用而不是一段临时 URL。

调用流程分两步：

• 先 oo connector schema 拿到输入/输出的权威 schema，不要凭经验猜字段
• 再用 oo action run 传 JSON payload，--data 支持内联字符串或 @path/to/file.json

响应结构固定为 { "data": ..., "meta": { "executionId": ... } }，执行 ID 在 meta.executionId 下，后续排查问题靠它。

凭证策略值得单说：OOMOL 在服务端注入，本地不落盘、不落日志。首次使用时如果命令报认证错误，才走一次性的连接流程；正常运行时不需要重复登录。

使用注意点

• 这个动作会改变 Stability AI 侧的状态（生成并上传文件），属于写操作。运行前应和用户确认确切的 payload 与预期效果
• 音频文件会占用 connector transit storage 的容量，长时间运行的服务要留意清理策略
• oo auth login 不要主动触发，只在命令真正因认证失败时才执行，否则会打断已有的会话状态
• 如果返回 OOMOL_INSUFFICIENT_CREDIT，说明计费停了，需要到 OOMOL console 充值后才能重试，这类问题重试没有意义