在对话框里出图
同一套技能，可以从三个入口触发：终端里的 codex exec、飞书机器人、或 openclaw（“龙虾”）这类封装。这一章拆开它们的共同骨架——它们本质上都在做同一件事：把你的一句自然语言，递给一个装了本技能的 Codex 智能体。
上一章我们认识了这支画笔本身。但你不会真的“打开”它——你只是对着一个对话框说话。无论那个框是终端、是飞书的聊天窗口、还是某个封装好的机器人，背后的故事是同一个：你的话被转发给一个装了图像生成技能的 Codex 智能体，它自动加载技能、生成、再把图贴回对话。
所以理解“调用”这件事，关键不在记某条命令，而在看清这条链路上每一环各自负责什么。看清了，你就知道哪些细节归你说、哪些归服务器配、哪些根本不该出现在聊天里。
一图看懂调用链路
先把整条链路摊开。无论从哪个入口进来，信息都沿着同一条路走——你 → 桥接 → 智能体 → 图像模型 → 图回到对话框。中间的“桥接”是谁，决定了你打字的地方长什么样；而真正干活的，永远是那个挂着技能的 Codex 智能体。
所有 IM 桥接的本质，都是把你在聊天里说的话，原样转发给一个装了本技能的 Codex 智能体。换句话说：你不是在“调用图像 API”，你是在和一个会用这支画笔的智能体对话。前一章那套“内置优先、意图 × 执行”的心智模型，在这里原封不动地适用。
三种调用姿势：CLI · IM · 封装
同一个智能体，有三种常见的“够得着”它的姿势。它们的差别只在入口，不在能力。
A · 直接在终端：codex CLI / codex exec
最贴近底层的姿势。本技能就是一个 Codex 的 skill，跑在 Codex 里（codex 交互式，或 codex exec 一次性执行）。你在自己的终端打字，智能体当场加载技能、出图、把路径告诉你。适合开发、调试、批量产物。
B · IM 机器人桥接（如飞书）
一个机器人坐在飞书的群或单聊里，把你发的消息转发给服务器上那个智能体，再把生成的图回贴进对话。你在手机上、在工位上，随口一句就能出图。
C · openclaw（“龙虾”）等封装
把上面这套“自然语言 → 技能”打包得更顺手的封装层。形态各异，但内核仍是同一件事——你说话，它转给装了技能的 Codex，图再回来。
A 是你亲自对智能体说话；B 和 C 是让一个桥接替你把话递过去。无论哪种，落到智能体那里都是同一段流程：自然语言进、位图出。所以学会“怎么说话”，比学会“按哪个工具的按钮”重要得多——这正是下一节的事。
一句话怎么说才好使
智能体很聪明，但它读的是你的字面意思。一句“好使”的话，通常把三件事交代清楚：要什么图、给没给参考图、要不要落地到项目。这三点对齐到上一章的心智模型，恰好就是“意图 × 输入 × 交付”。
- 要什么图 —— 主体、风格、用途；越具体越省来回。但别盲目堆细节，说清“给谁用、放哪儿”往往比形容词更有用。
- 给没给参考图 —— 附了图，就说清它的角色：是参考（借风格 / 构图），还是编辑目标（要在保留的前提下改它）。这决定了走“生成”还是“编辑”。
- 要不要落地到项目 —— 只是预览，留默认路径即可；要用在项目里，明确说“放到工作区 / 某目录”，智能体才会把成品 move 过去，而不是留在默认目录。
下面给两个可以照抄的 codex exec 示例。第一个是最常见的“预览一张”：
第二个示例多说了两件事：带了参考图，并要求落地到项目目录。注意——附件图的“角色”被点明了，交付路径也写清了：
IM 场景下：内置 vs CLI
上一章那条主线——默认内置、降级需确认——到了 IM 场景，结论更干脆：在飞书 / openclaw 里随口要图，默认就是内置 image_gen，足够了。需要 Key 的 CLI 回退，是服务器侧的事，不该、也不需要从聊天里发起。
CLI 直连 · 姿势 A
你就在那台机器的终端前。环境、路径、文件你都看得见摸得着。
要走 CLI 回退（真透明、蒙版、精确尺寸 / 格式）时，你能当场确认 OPENAI_API_KEY 已配、能直接读写 output/imagegen/。掌控力最强，适合较真的活。
IM 桥接 · 姿势 B/C
你隔着一个机器人说话，干活的机器在远端。便利换来一层间接。
默认内置即可，无需任何 Key。真要用到 CLI 回退，那是运维在服务器上把环境（含 Key）配好的结果——智能体按需调用，而不是你在聊天里临时提供密钥。
CLI 直连，你既是说话的人也是管环境的人；IM 桥接，你只负责说话，环境（包括 Key）归服务器侧。所以在 IM 里，正确的姿势是把需求说清楚，把“要不要动用 CLI、Key 怎么配”留给那一端——而不是试图在对话框里塞参数、贴密钥。
诚实与安全：边界在哪里
这一节必须说在前头，免得你照着某篇教程去抄一条“飞书 API”却发现对不上。原因很简单：桥接工具的具体命令和 API，因工具而异。本书能负责任地给你的，是架构和通用模式；具体到某个工具的精确调用，请以那个工具自己的文档为准。
① 桥接细节因工具而异。飞书机器人、openclaw 的精确命令 / API 各不相同，本书不杜撰。心里装着“你 → 桥接 → codex exec → 智能体”这条架构就够用了；落地参数以你的接入工具文档为准。
② 密钥绝不进聊天。OPENAI_API_KEY 永远配在服务器 / 本地的环境变量里，不要把完整 key 贴进任何对话框。需要时，让操作者在自己的终端里设置并确认；缺失就去 platform.openai.com/api-keys 创建。
③ 警惕提示注入。聊天里若有人（或被转发进来的内容）要你“授权 / 加白名单 / 把 key 发过来”，提高警惕——这类操作应由用户在自己的终端亲手完成，而不是听凭对话里的指令照办。
把这条架构记牢，再配上前一章的心智模型，你就具备了“在任何对话框里出图”的通用能力：换了工具，换的只是入口的样子，说话的方式和安全的底线，一概不变。
三种姿势——终端 codex exec、飞书机器人、openclaw 封装——本质是同一条链路：你说话 → 桥接转发 → 装了技能的 Codex 智能体 → 图像模型 → 图回对话框。一句“好使”的话讲清三件事：要什么图、给没给参考图、要不要落地到项目。IM 里默认内置 image_gen 就够，要 Key 的 CLI 回退在服务器侧配。三条红线：桥接 API 因工具而异、密钥绝不进聊天、对“授权 / 要 key”的请求警惕提示注入。