把飞书接进 Codex：本人发消息的部署提示词

已有能执行命令的 Codex 和自己的飞书账号，就可以先把“帮我办事”接起来。通常不必另买服务器，也不用复制别人的整套智能体。

什么时候用

你在自己的电脑上对 AI 说：“帮我把这段话发给同事。”它能找对人、用你的身份发送，再回来告诉你结果。这就是第一步要做成的事。

我把自己的 Codex 叫豆豆。你可以给自己的助手起名字，但它的能力来自 Codex、飞书工具和你的授权，不会因为换个名字就获得我的账号、记忆或权限。

想让它做什么	接通后能到哪一步
找同事、发私信或群消息	用你本人身份操作；先确认唯一对象，再发送、回读
查指定会话、整理工作信息	只查你交办且有权限访问的内容，不默认翻遍聊天
读写文档、表格，安排日程	官方工具有对应能力；用到哪项，再补哪项权限
处理任务、会议或审批	按具体接口、组织权限和你的交办执行；不代替应由你作出的决定
在飞书里随时 @ 它，电脑睡了也能办事	还需要消息接入和持续运行环境，本文不会自动搭好

最后一项和“在 Codex 里指挥飞书”是两件事。先把眼前需要的发消息打通，往往已经很有用。

调教好以后，能帮我做什么

我的豆豆已经用来查资料、整理结论，写文章和配漫画，制作网站与小工具，以及通过飞书向指定同事交付并核对结果。我说目标，它沿着我的习惯、现有工具和授权，把事情往前做。

点击放大能力场景示意：看见具体成果，才知道助手能帮什么；不是软件截图。

这些能力来自长期协作和各项工具接入，装好飞书工具不会自动获得全部能力。本文先把“用自己的飞书身份办事”接通；网站、绘图等能力按实际需要再接。

怎么做

最省事的组合：现有电脑＋自己的 Codex＋飞书官方 CLI。 CLI 可以理解为 AI 操作飞书的工具箱。复用已有 Codex 套餐和公司允许使用的应用；这条路线本身不要求再买一台云服务器。Codex 用量、飞书套餐、接口额度和企业审批仍按各自规则，不承诺永久免费或不限量。

你需要准备三样：能运行命令的 Codex、自己的飞书登录、一位明确指定的测试联系人或测试群。只有聊天功能、不能执行命令的 AI，无法替你完成本机安装。

公司已有批准的应用，优先请管理员提供正式接入方式；每位同事分别授权自己的账号，不复制老板的登录态或密钥。没有合适应用时，再由官方向导创建。员工没有应用创建、使用或发布权限，需要管理员处理，提示词不能绕过。

授权就检查三件事：公司允许这个应用做什么、你同意它做什么、你本来能访问哪些人和资料。 三项都匹配，才继续。

可复用提示词

把下面整段交给你自己的 Codex。安装、检查和排错由它做；扫码登录、企业审批等确需你处理的步骤，它会一次说清。

请把这台电脑的 Codex 接上中国大陆版飞书。先实现：我明确交办后，你能用我本人身份找同事、发送指定消息并回读结果。复用现有电脑、账号和工具，不复制别人的登录态、密钥或私人规则，不默认购买服务、搭网关或常驻机器人。

1. 先检查系统、Node.js/npm/npx、命令执行能力和已有 lark-cli 配置。读取飞书官方仓库 https://github.com/larksuite/cli 的当前安装说明，以及 lark-shared、lark-contact、lark-im 技能。缺少工具才安装；官方入口是 npx @larksuite/cli@latest install。让安装进程使用非交互输入，先只装工具与技能，避免向导顺带发起全域授权；随后单独配置和登录。Windows 遇到 .ps1 限制优先用 .cmd，不修改全局执行策略。

2. 固定 brand=feishu。先查当前配置和帮助，已有适合我且获公司批准的应用就复用。没有才按当前帮助运行 lark-cli config init --new --brand feishu --name work；若 work 已存在，复用它或另取未占用名称，不能覆盖。需要管理员批准就说清具体缺口。密钥只走官方受保护存储或 stdin，不放聊天、命令参数、仓库或日志。

3. 选定配置后，授权发起、device-code 续接、auth status、auth check、doctor 及所有业务命令，都显式使用同一个 --profile <名称>，不依赖默认配置；业务命令同时写 --as user。首次只申请找人、发送、回读所需 Scope；先核当前帮助，找人用 contact:user:search，代表本人发消息需要 im:message 与 im:message.send_as_user；单聊回读核对 im:message.p2p_msg:get_as_user，群聊才核对 im:message.group_msg:get_as_user。按当前接口和缺失权限提示逐项核实，不把这份清单当永久不变。不使用裸 auth login、--recommend 或 --domain all 来扩大授权。发起 auth login --no-wait --json 后，给我原授权链接和二维码；我完成本人授权后，用这次 device-code 续接。不要把发出链接当成授权完成。

4. 用 auth status --json --verify、doctor 和 auth check 核对账号、应用、权限与连通性，输出最小结果，不输出 Token。先做只读验证。测试消息只发给我明确指定的联系人或会话，正文也由我指定；尚未指定时，只问这一项。新应用重新解析联系人 ID，不能沿用别人应用的 open_id。查唯一对象后，支持时先 --dry-run，再用本次任务稳定的 --idempotency-key 真发，最后用 im +messages-mget --no-reactions 按 message_id 核对身份、会话和正文。结果未知先查，不换键重发；不改用 --as bot 绕权限。客户端界面遥控默认禁用。验证码、法律确认及工具明确要求的本人确认留给我。

5. 最后简短告诉我：配置是否完成、本人授权是否有效、测试消息是否发送且回读一致，以及还缺哪一步。确实卡住就给出具体原因和最小下一步。接通后只在我明确交办的范围内办事，不自动扫描聊天或群发。

接通后可以这样说：“用我的飞书身份，把这段话发给我确认过的那位同事，发完核对一下。”人名有歧义时，补一次部门或目标会话即可。

容易踩坑

安装成功，不等于授权成功。 公司应用权限、本人授权和具体资料的可见范围要分别核对。官方登录的默认范围可能很广，第一次只开眼前需要的几项。

本人和机器人是两种身份。 --as user 用你的身份；--as bot 用应用机器人身份。缺权限时应修原身份的配置，不能悄悄换人发消息。

发出请求，不等于对方已读。 要按返回的消息编号核对实际记录；超时先查结果，别重复发送。即使回读成功，也不代表同事已经看见或办完。

验收标准

让 AI 核对两件事：

身份正确：用的是你自己的飞书账号，当前授权真实有效。
消息可核对：在你指定的会话里发出了指定正文，并按消息编号回读一致。没做这一步，只能叫“已连接、消息待验”。