飞书秒变 Claude Code 控制台：一个 Bridge 项目，正在改写 AI 编程入口

如果你同时使用飞书和 Claude Code，可以通过开源项目把二者连接起来。你在飞书里给机器人发一句话，本机 Claude Code 就能在指定工作目录里读文件、改代码、跑命令；它的执行过程还能以卡片形式实时回到飞书。

这看起来像一个小工具，但背后其实代表了一个更大的趋势：AI 编程助手正在从“终端里的个人工具”，变成“协作软件里的 Agent 控制台”。

一、飞书连接 Claude Code 的真实价值

通过 feishu-claude-code-bridge / lark-channel-bridge 这类开源项目，可以让飞书或 Lark 消息直接转发给本机 Claude Code CLI，再把 Claude 的执行过程和结果同步回飞书。

你可以在飞书里像和同事对话一样，指挥 Claude Code 处理本机项目。

你可以把推文链接、群聊消息、截图、文件转发给机器人，让 Claude 继续处理。

你可以把执行过程做成飞书卡片，实时显示“正在读哪个文件、正在跑什么命令、当前结果是什么”。

你可以给不同聊天或群绑定不同 Workspace，让每个会话对应不同项目目录。

这件事为什么有爆点？因为它踩中了开发者的三个痛点：

二、别被名字绕晕：Bridge 本质是“消息翻译器”

很多人第一眼会误解：是不是把 Claude Code 部署到了飞书服务器里？不是。更准确的说法是：飞书负责消息入口，Bridge 常驻在你的本机，Claude Code CLI 仍然在你的本机执行。

它像一个“翻译官”：

飞书消息来了：Bridge 把它整理成 Claude Code 能理解的 prompt。

Claude Code 开始执行：Bridge 以 subprocess 方式调用 claude CLI。

Claude 输出文本和工具调用事件：Bridge 解析输出流。

需要展示给用户：Bridge 把文本、工具调用、状态封装成飞书消息或卡片。

三、完整架构：五层拆开看，就很清楚了

1. 入口层：飞书私聊、群聊、截图、文件

入口层解决的是“用户从哪里发任务”。它可以是私聊机器人，也可以是在群里 @bot，还可以把一条消息、一个推文链接、一张报错截图转发给机器人。对于用户来说，入口越顺手，Agent 被使用的频率就越高。

2. 连接层：WebSocket 长连接

飞书开放平台支持通过长连接接收事件。Bridge 从本机主动连向飞书平台，所以很多场景下不需要公网 IP，也不需要把本机端口暴露到外网。这也是这类项目上手快的关键。

3. 编排层：消息队列、Session、Workspace

编排层是 Bridge 的大脑：判断这条消息属于哪个聊天、哪个项目、哪个会话；要不要中断前一个任务；多条连续消息要不要合并；输出应该更新哪张卡片。

4. 执行层：Claude Code CLI

真正的执行发生在本机 Claude Code CLI。项目通常通过 claude -p 或 --output-format stream-json 之类的方式，把 Claude Code 变成可被程序调用的子进程。

5. 展示层：飞书卡片与按钮

最终用户不需要看 JSON，也不需要看终端日志。Bridge 会把中间过程转成飞书卡片：文本增量、工具调用、错误提示、确认按钮、状态命令，全部可视化。

四、从一句飞书消息到本机执行：全过程拆解

第 1 步：用户在飞书发消息

例如：“帮我看一下这个接口为什么 500，把原因写成排查报告。”这条消息可以来自私聊，也可以来自群聊 @bot。

第 2 步：飞书把事件推给本机 Bridge

长连接建立后，飞书平台把收到的消息事件发送到 Bridge。本机不需要等待外网访问进来，而是主动维持连接。

第 3 步：Bridge 做消息预处理

Bridge 会把文本、引用消息、图片路径、文件路径、群聊上下文整理成 prompt，同时读取当前 chat 对应的 session 和 workspace。

第 4 步：Bridge 调用 Claude Code CLI

典型方式是启动 claude CLI 的打印模式，并开启 JSON 或 stream-json 输出。这样程序就能逐行解析 Claude 的文本、工具调用和最终结果。

第 5 步：Claude Code 在本机项目中执行

这一步才是真正的“干活”：读代码、查日志、跑测试、编辑文件、生成文档，能力边界取决于 Claude Code 当前权限和工作目录。

第 6 步：Bridge 将输出流回写飞书

Claude 不是只给一个最终答案，而会输出一串增量事件。Bridge 把这些事件翻译成飞书卡片更新，让用户看到任务进度。

第 7 步：用户继续追问或点击按钮

如果需要确认，Bridge 可以通过交互式卡片让用户点按钮；如果用户继续发消息，则复用当前 session，形成连续任务。

五、流式卡片：为什么它不像普通聊天机器人

普通机器人最常见的问题是：用户发完消息后，只能等。尤其 AI 编程任务可能要读文件、执行命令、跑测试，中间几十秒甚至几分钟没有反馈，用户就会怀疑是不是卡住了。

流式卡片解决的就是“过程可见性”。Bridge 先发一张卡片占位，然后在 Claude 输出新内容时不断更新这张卡片。这样飞书里显示的不是一堆零散消息，而是一张持续刷新的任务面板。

从工程角度看，流式卡片至少要处理四个细节：

节流：不能 Claude 每输出一个字就 PATCH，否则 API 压力过大。

结构化：文本、工具调用、错误、总结要分区展示，不能全部糊成一段。

幂等：网络抖动、重复事件、卡片更新失败时，要能重试或降级。

收尾：任务结束后要把临时状态变成最终总结，避免用户看到半截进度。

六、Workspace：为什么它能读取项目上下文

这类项目有一个很重要的设计：Workspace。它不是简单地让 Claude “随便控制电脑”，而是让某个飞书会话绑定到某个工作目录。

工作目录决定了 Claude Code 的上下文：它能看到哪些源码、哪份 CLAUDE.md、哪些项目配置、哪些本地工具，也决定了写文件会写到哪里。

七、能做什么：从“翻译推文”到“远程 code review”

按照这条 X 分享里的例子，用户可以把推文链接发给飞书智能体，让它抓取推文、翻译成中文，再创建成飞书文档。这个例子看似简单，其实串了三类能力：

信息输入：飞书消息里包含链接、引用消息或附件。

Agent 处理：Claude Code 调用工具抓取、总结、翻译、格式化。

协作输出：结果不只回一段文字，还可以沉淀到飞书文档。

放到开发者日常，它的场景会更丰富：

八、风险在哪里：本机权限是能力，也是危险源

必须强调：这类 Bridge 项目的强大，正是因为它连接了本机 Claude Code。也就是说，它不是只能“回答问题”的聊天机器人，而是可能具备读写文件、执行命令、调用工具的能力。

九、如果你要自己做一个：产品化路线图

如果你想照着这个思路做自己的机器人，不建议一上来就追求“大而全”。最稳妥的路线是先把链路跑通，再补齐可视化、权限和协作能力。

从 MVP 到平台化的 5 个阶段

部署和调试时最关键的 6 个环节

一个最小可用版本应该包含什么？

飞书应用：机器人能力、消息权限、事件订阅。

Bridge 进程：能稳定接收消息，能启动 Claude CLI。

基础消息队列：同一个聊天内串行执行，避免并发改同一份文件。

简单卡片输出：至少有“开始、执行中、完成、失败”四种状态。

工作目录配置：不能默认放开整个用户目录。

白名单：只允许指定用户或指定群触发。

真正做成内部工具，还要补什么？

审计日志：谁在什么时候让 Agent 做了什么。

命令审批：删除、部署、写生产配置等高危操作必须确认。

多工作区管理：不同项目、不同群聊、不同负责人隔离。

失败恢复：WebSocket 断线重连、任务中断、卡片更新失败要有兜底。

成本治理：统计调用次数、任务时长、模型使用、失败率。

十、总结：AI Agent 的入口正在变

过去我们谈 AI 编程，第一反应是 IDE 插件、终端工具、命令行 Agent。但这个飞书 + Claude Code Bridge 的价值在于，它把 Agent 带到了开发者每天高频使用的协作界面里。

它的技术难点并不神秘：WebSocket 接事件、子进程调 Claude CLI、解析 stream-json、更新飞书卡片、管理 session 和 workspace。真正有价值的是组合方式：把这些普通模块拼成了一个更自然的工作入口。

第一，它改变了入口。AI 编程助手不再只在终端里，而是可以出现在飞书会话中。

第二，它改变了反馈。流式卡片让执行过程可见，用户不再面对黑盒等待。

第三，它改变了协作。群聊、引用、转发、文档沉淀，让 Agent 开始进入团队工作流。

第四，它放大了安全问题。越接近真实执行环境，越需要权限、审计、确认和隔离。