Larkspur：10分钟上手：如何让飞书成为你的远程Vibe Coding控制台

Larkspur：10分钟上手：如何让飞书成为你的远程Vibe Coding控制台 Larkspur：10分钟上手：如何让飞书成为你的远程Vibe Coding控制台 Modified January 16 3）“防刷屏”逻辑 03 它的几个关键选项 A. 两种工作方式：你想“像在电脑前一样聊”，还是“每次问一次算一次”？ • tui 模式 ： 可以理解为：桥接进程“开了一个真的终端会话”，你在飞书里发的话，会像键盘输入一样写进 Codex。 优点 ：上下文最稳，体验最像“人就在电脑前”。 • exec 模式 ： 可以理解为：你每发一条飞书消息，它就跑一次 codex exec ，拿到结果后再继续 resume last 。 优点 ：输出更干净，更像“一问一答”。 不想折腾：优先用 tui 。 想要“任务式问答”：用 exec 。 B. 两种拿输出的方法：想“更干净”还是“更实时”？ • session （更干净） ： 直接从 Codex 的会话日志里抽最后一条 assistant 消息（比如 /.codex/sessions/ /rollout .jsonl ）。 优点 ：少杂音，发到飞书更像“整理过的回答”。 • pty （更实时） ： 直接读终端输出，然后做 stripAnsi /去噪。 优点 ：实时； 缺点 ：可能比 session 更“热闹”。 推荐组合： tui + session （稳 + 干净）。 C. 防刷屏：它不会一行一行往群里轰炸 你知道最可怕的不是它说得多，而是它 一边生成一边刷屏 。 所以这里有个选项： idlePushMs —— 默认等 10 秒没新输出了，再把这段回复合并推送一次 。 D. 安全底线：别让任何人都能“远程敲你终端” 这个真的别省： allowedOpenIds 白名单。 意思是： 只有白名单里的 open id 才能控制你本地的 Codex 输入 。 04 10 分钟上手（按这个走就行） 1）你需要准备这些 • Node.js 18+ • 本地装好 Codex CLI（能在命令行跑 codex ） • 飞书自建应用：订阅 im.message.receive v1 ，并开 长连接 接收 • 一个群自定义机器人 Webhook（用来推送消息） 2）安装 & 启动 Code block Plain Text Copy npm install copy config.example.json config.json npm start 3）想指定工作目录？两种方式 Windows CMD： Code block Plain Text Copy set WORKING DIR=E:\Your\Project npm start PowerShell： Code block Plain Text Copy $env:WORKING DIR="E:\Your\Project" npm start 或者直接启动传参： Code block Plain Text Copy npm start dir=E:\Your\Project 05 配置里最常用的 8 个字段 字段 说明 appId / appSecret 飞书应用的“身份证” webhookUrl 往群里发消息用的地址 allowedOpenIds 谁能控制你终端（强烈建议配） mode tui（连续对话） / exec（一问一答） outputSource session（干净） / pty（实时） idlePushMs 多久没新输出就合并推一次（默认 10s） sendToUserOnIdle 推群的同时，要不要私聊回发起者（通勤很香） maxMessageChars 单条消息最长，防止超长炸群 06 两个常见坑 1）群里收到的回复有乱码/碎字符？ 优先用：tui + session（从会话日志拿结果更干净） 2）open id 怎么拿来做白名单？ 临时把 allowedOpenIds 设为空数组跑起来，你给机器人发条消息，控制台会打印你的 open id，再填回去。 07 安全提醒（真心：别偷懒） 一定要配 allowedOpenIds：不然“能私聊机器人的人”，理论上都能把指令写进你本地终端。 建议限制 workingDir：避免误操作到不该动的目录。 08 结尾：把“终端里的生产力”带出工位 这个桥接工具的目标很简单：让 Codex 的对话不断线。 你可以在电脑前深度协作，也可以在飞书里补一句：“把刚才那个函数再抽成 util，顺便补两个用例。” 3）“防刷屏”逻辑 03 它的几个关键选项 A. 两种工作方式：你想“像在电脑前一样聊”，还是“每次问一次算一次”？ • tui 模式 ： 可以理解为：桥接进程“开了一个真的终端会话”，你在飞书里发的话，会像键盘输入一样写进 Codex。 优点 ：上下文最稳，体验最像“人就在电脑前”。 • exec 模式 ： 可以理解为：你每发一条飞书消息，它就跑一次 codex exec ，拿到结果后再继续 resume last 。 优点 ：输出更干净，更像“一问一答”。 不想折腾：优先用 tui 。 想要“任务式问答”：用 exec 。 B. 两种拿输出的方法：想“更干净”还是“更实时”？ • session （更干净） ： 直接从 Codex 的会话日志里抽最后一条 assistant 消息（比如 /.codex/sessions/ /rollout .jsonl ）。 优点 ：少杂音，发到飞书更像“整理过的回答”。 • pty （更实时） ： 直接读终端输出，然后做 stripAnsi /去噪。 优点 ：实时； 缺点 ：可能比 session 更“热闹”。 推荐组合： tui + session （稳 + 干净）。 C. 防刷屏：它不会一行一行往群里轰炸 你知道最可怕的不是它说得多，而是它 一边生成一边刷屏 。 所以这里有个选项： idlePushMs —— 默认等 10 秒没新输出了，再把这段回复合并推送一次 。 D. 安全底线：别让任何人都能“远程敲你终端” 这个真的别省： allowedOpenIds 白名单。 意思是： 只有白名单里的 open id 才能控制你本地的 Codex 输入 。 04 10 分钟上手（按这个走就行） 1）你需要准备这些 • Node.js 18+ • 本地装好 Codex CLI（能在命令行跑 codex ） • 飞书自建应用：订阅 im.message.receive v1 ，并开 长连接 接收 • 一个群自定义机器人 Webhook（用来推送消息） 2）安装 & 启动 3）想指定工作目录？两种方式 Windows CMD： PowerShell： 或者直接启动传参： 05 配置里最常用的 8 个字段 字段 说明 appId / appSecret 飞书应用的“身份证” webhookUrl 往群里发消息用的地址 allowedOpenIds 谁能控制你终端（强烈建议配） mode tui（连续对话） / exec（一问一答） outputSource session（干净） / pty（实时） idlePushMs 多久没新输出就合并推一次（默认 10s） sendToUserOnIdle 推群的同时，要不要私聊回发起者（通勤很香） maxMessageChars 单条消息最长，防止超长炸群 字段 字段 说明 说明 appId / appSecret appId / appSecret 飞书应用的“身份证” 飞书应用的“身份证” webhookUrl webhookUrl 往群里发消息用的地址 往群里发消息用的地址 allowedOpenIds allowedOpenIds 谁能控制你终端（强烈建议配） 谁能控制你终端（强烈建议配） mode mode tui（连续对话） / exec（一问一答） tui（连续对话） / exec（一问一答） outputSource outputSource session（干净） / pty（实时） session（干净） / pty（实时） idlePushMs idlePushMs 多久没新输出就合并推一次（默认 10s） 多久没新输出就合并推一次（默认 10s） sendToUserOnIdle sendToUserOnIdle 推群的同时，要不要私聊回发起者（通勤很香） 推群的同时，要不要私聊回发起者（通勤很香） maxMessageChars maxMessageChars 单条消息最长，防止超长炸群 单条消息最长，防止超长炸群 06 两个常见坑 1）群里收到的回复有乱码/碎字符？ 优先用：tui + session（从会话日志拿结果更干净） 2）open id 怎么拿来做白名单？ 临时把 allowedOpenIds 设为空数组跑起来，你给机器人发条消息，控制台会打印你的 open id，再填回去。 07 安全提醒（真心：别偷懒） 一定要配 allowedOpenIds：不然“能私聊机器人的人”，理论上都能把指令写进你本地终端。 建议限制 workingDir：避免误操作到不该动的目录。 08 结尾：把“终端里的生产力”带出工位 这个桥接工具的目标很简单：让 Codex 的对话不断线。 你可以在电脑前深度协作，也可以在飞书里补一句：“把刚才那个函数再抽成 util，顺便补两个用例。” 🔗 原文链接： https://mp.weixin.qq.com/s/bS6crMmS... https://mp.weixin.qq.com/s/bS6crMmS... 原创 Larkspur技术分享 Larkspur技术分享 Little Shock2026年1月15日 23:54 上海 你有没有这种瞬间崩溃的场景： 电脑前跟 Codex CLI 聊得正顺，转头去开会/通勤/拿杯水； 等你回来，它刚好回了关键几行……你没看到，思路也断了。 我就是被这个“掉线感”折磨久了，于是做了个小桥接工具： 飞书 ↔ Codex CLI Bridge 。 已开源，求个Star🙏： https://github.com/Larkspur Wang/feishu X codex 一句话讲清楚它干嘛：让 Codex 的回复自动出现在飞书里；你在飞书回一句，它能继续把话接到你本地的 Codex 会话里。 01 它到底解决了什么？ 简单说就是三件事： 1. Codex 一有新回复 → 自动推飞书 （走机器人 Webhook） 2. 你在飞书回一句 → 真的写进本地 Codex （不会变成“复制粘贴工程”） 3. 不想搞公网回调 ：飞书这边用 长连接 收消息事件 im.message.receive v1 02 它怎么工作的 1）架构总览 2）消息时序