夜雨聆风前阵子我越来越强烈地感觉到一件事：
很多人对 AI 的使用，其实还停留在“它会回答我”。
但真正拉开差距的，往往不是回答本身，而是结果能不能直接落进你的工作系统里。
以前我的流程是这样的：
AI 帮我整理完资料，我还得自己复制；
AI 帮我列完清单，我还得自己切去飞书建表；
AI 帮我写完一段内容，我还得再确认格式、再粘贴、再排版。
看起来都只是几步小动作。
可一旦这些动作每天重复十几次，AI 就很容易从“助手”重新退化回“高级聊天框”。
所以我最近专门做了一件事：
把 `Codex` 接到 `飞书`。
结果比我预期里更值。
因为一旦跑通，AI 产出的内容就不再只是停在对话里，而是可以直接进入：
- 飞书文档
- 飞书表格
这意味着很多原本需要人手动收尾的动作，第一次真的能被串起来。
比如：
- 让 AI 调研完资料，直接生成飞书文档
- 让 AI 整理清单，直接生成飞书表格
- 把本地的 Markdown、CSV 文件，直接导进飞书
我后来越来越确定，`AI 能不能接进你每天真正在用的协作系统`，是一个非常关键的分水岭。
不是因为它听起来高级。
而是因为只有到了这一步，AI 才开始真正替你“做事”，而不是只是“给建议”。
真正省下来的，不是复制粘贴，是注意力
很多人会低估复制粘贴的成本。
因为单次看，它几乎不痛。
但真实工作里，最耗人的往往不是那种一整天的大任务，而是那些不断把你打断的小动作。
你刚让 AI 整理完一段内容，本来思路还在，下一秒就要切去飞书。
你刚在一个问题上想出一点判断，又得先去建一张表、补字段、对格式。
这种感觉很像什么都做了，但节奏一直被切碎。
我这次把链路打通之后，最直观的变化不是“炫技”，而是工作终于顺了。
AI 写完内容，可以直接落文档。
AI 整理完数据，可以直接建表。
本地已经有的 Markdown 和 CSV，也可以一把导进去。
以前是：
1. AI 输出结果
2. 人手动复制
3. 打开飞书
4. 新建文档或表格
5. 再粘贴和整理
现在更像：
1. AI 产出结果
2. 直接写进飞书
流程少掉的不是一两步，而是一整段来回切换。
我怎么把 Codex 接上飞书的
这件事我最后跑通，用的核心工具是飞书官方的 `lark-cli`。
它最重要的一点，不是“有很多命令”，而是它给了 AI 一个稳定的入口，让 AI 能把结果直接写进飞书 API。
最小闭环其实就三步。
第一步，安装飞书 CLI
前提是本机已经有 `Node.js`。
安装命令：
npx @larksuite/cli@latest install装完后可以先验证一下：
lark-cli --help只要能正常输出帮助信息，说明 CLI 本体已经装好了。
第二步，初始化应用
lark-cli config init --new执行后，终端会给出一个飞书开放平台链接。
按页面提示创建应用就行，不复杂。
做完这一步，本地就相当于有了一个能代表你调用飞书能力的应用身份。
第三步，登录授权
lark-cli auth login --recommend浏览器里点同意授权，然后再回到终端检查状态：
lark-cli auth status我这边实际跑通后，最关键的两个状态是：
-`identity: user`
-`tokenStatus: valid`
只要这两个值正常，基本就说明 API 这条主链路已经通了。
跑通之后，最实用的三个动作
如果你只是想判断“这值不值得折腾”，其实不用一下子研究很深。
先看三个动作能不能跑通就够了。
只要这三个动作成立，后面很多工作流都能自己长出来。
1. 直接写飞书文档
lark-cli docs +create --as user --title "测试文档" --markdown "hello"这条命令成功后，会返回文档 ID 和文档链接。
也就是说，只要 AI 最终能产出 Markdown，它就可以直接落进飞书文档，而不是停在聊天窗口里。
对我来说，这一步的意义非常大。
因为调研总结、方案草稿、会议纪要、日报周报，很多本质上都是“生成一份文档”。
过去 AI 只能帮你写。
现在它能顺手帮你写进去。
2. 直接建飞书表格
lark-cli sheets +create \--as user \--title "测试表" \--headers '["列1","列2"]' \--data '[["a","b"]]'
这条我也实际跑通了，成功后会返回表格链接和 token。
只要这一步能成，很多原来很碎的记录动作就会突然变顺。
比如：
- 账号记录
- 测试清单
- 资料台账
- 任务列表
- 外部线索整理
表格这件事看起来普通，但它恰好是很多工作真正落地的地方。
3. 继续写已有表格
建表只是开始，更实用的是能继续往已有表格里补数据。
先查表格信息：
lark-cli sheets +info --as user --spreadsheet-token <token>拿到 `sheet_id` 之后，就可以定点写入：
lark-cli sheets +write \--as user \--spreadsheet-token <token> \--sheet-id <sheet_id> \--range 'A2:E2' \--values '[["2026/5/15 16:09","a@example.com","******","https://example.com","成功"]]'
我专门测了这一步，因为它决定了这条链路到底只是“能创建”，还是“能持续使用”。
结论是，可以持续写。
这很关键。
因为真正有价值的不是演示一次新建成功，而是之后每天都能顺手把数据继续补进去。
我后来又多做了一步，把命令收成一个统一入口
真实工作里，没人想每次都记一长串参数。
所以我后面又补了一个自己的统一命令入口：`feishu-quick`。
它本质上就是把常用动作收起来，方便 Codex 直接调用。
最常用的几个动作是：
创建文档：
feishu-quick doc --title "标题" --markdown "内容"创建表格：
feishu-quick sheet --title "标题" --headers '["列1","列2"]' --data '[["a","b"]]'Markdown 文件转文档：
feishu-quick doc-file --file /path/to/file.mdCSV 文件转表格：
feishu-quick csv-sheet --file /path/to/file.csv我很喜欢这一步。
因为一旦你把最常用的动作压缩到足够短，AI 工作流就不再像“调接口”，而开始像真正的日常工具。
这套东西为什么值得做
我觉得这件事真正的价值，不在于“又多学会了一个 CLI”。
而在于你会突然发现，AI 的位置变了。
以前它更像一个会说话的搜索框，或者一个更聪明的草稿机。
现在它开始变成一个能把结果直接推进到下一步的人。
这两者的差别非常大。
前者提升的是回答质量。
后者提升的是整段工作流的完成度。
如果你平时经常做这些事：
- 整理调研资料
- 输出会议纪要
- 维护账号和测试记录
- 生成清单、台账和协作文档
那把 Codex 接进飞书，几乎一定会比你想象中更实用。
因为你的问题从“AI 会不会写”变成了“AI 能不能写完并放对地方”。
而在真实工作里，后一个问题往往更重要。
我这次踩到的几个坑
当然，这事不是完全无坑。
我自己跑的时候，主要碰到三个点。
1. 命令帮助和实际行为，最好都以本机实测为准
有些命令看 `--help` 还不够，最稳的方式还是做一次真实创建测试。
尤其是 `docs +create` 这类动作，版本差异有时会让帮助信息和实际体验不完全一致。
所以我的建议一直都是：
- 先看 `--help`
- 再做一条真实创建
不要只看文档，不落地验证。
2. 飞书 API 偶尔会遇到网络超时
我实测碰到过 TLS 握手超时。
这通常不是命令写错了，而是链路偶发不稳定。
大多数时候，重试一次就过。
所以如果你第一下失败，不用急着怀疑整套方案有问题，先重试。
3. 桌面自动化能做，但主链路还是更推荐 API
我也试过飞书桌面端自动化。
它适合做一些轻量动作，比如：
- 激活窗口
- 搜索
- 发送简单消息
但如果你的目标是稳定写文档、建表格、补数据，还是更推荐走 `lark-cli` 这条 API 路线。
因为它更稳，也更容易被 AI 编排进长期工作流。
看法
如果你问我，这件事值不值得做，我的答案是：值得，而且越早越值。
因为很多人现在都在讨论 AI 工作流。
但真正能跑起来的工作流，通常不是多加了几个提示词，而是把 AI 接进了原本就承载你工作的系统。
当 `Codex` 能直接写飞书文档、建飞书表格、导入本地文件的时候，AI 才第一次真正有了“交付结果”的味道。
它不再只是陪你聊天。
它开始帮你把事往前推。
如果你也想先跑一个最小闭环，那就从这三步开始：
npx @larksuite/cli@latest installlark-cli config init --newlark-cli auth login --recommend
跑通之后，先不要追求复杂。
先让它成功写出第一篇飞书文档，建出第一张飞书表格。
只要这两步成了，你很快就会明白，为什么这条链路值得接。
如果你也在把 AI 接进飞书、Notion、表格或文档系统，欢迎留言交流你跑通的工作流。