AI 操作办公软件，最重要的不是速度，是让人看得见
最近刷到一条推文，开头就让我愣了一下。
一个叫阿易的人，说自己「刚刚花三分钟装了飞书官方那个 CLI 工具，跑了一句话，建群、建文档、发通知，一次性全做完了」。然后他说，「我盯着终端看了几秒钟，才反应过来这玩意儿真的能让 AI 直接操作飞书。」
我喜欢「盯着终端看了几秒钟」这个细节。
那种感觉我懂。不是「哇好厉害」的那种惊叹，是另外一种东西——有点像你第一次看着 Claude Code 在你的项目里打开文件、修改代码、自己运行测试，然后你意识到你没有参与这整个过程。你只是坐在旁边，看着它做完了。
那几秒钟的沉默，我觉得是很多东西正在重新排列的声音。
说一下背景。
飞书有个官方的开源工具，叫 lark-cli，是一个命令行工具（命令行就是你在电脑上打字下命令的那个黑框框，程序员的老朋友），让 AI 或者你自己，可以直接通过命令操作飞书的各种功能。建群、建文档、发通知、管理日历，诸如此类。
这个工具 45 天拿到了超过 1 万 GitHub star。好家伙。
1 万 star 是什么概念？GitHub 上绝大多数开源项目终其一生可能也就几百 star。能破万的，大多数是历经数年积累的。45 天破万，意味着从发布开始就有大量开发者主动跑来表示「我觉得这东西有价值」。
更值得注意的是，这是国内首个破万星的办公套件开源项目。不是第一个好用的，不是第一个有趣的，是第一个在开发者社区里积累起这个量级热情的。
钉钉没有对标产品。企业微信也没有。
外部贡献者数量，飞书 10 位，钉钉 0，企业微信 0。
有点子牛逼这个数据。不是飞书功能有多强，而是这个对比让你意识到「开发者生态」到底意味着什么，以及它是怎么在不知不觉中形成的。
但 GitHub star 数不是我真正想聊的。
我想聊的是，为什么是命令行工具？
你可能知道，现在最流行的 AI 工具接入方式叫 MCP，全称 Model Context Protocol，是 Anthropic 设计的一套协议，让 AI 模型能标准化地接入各种外部工具和服务——Slack、Notion、GitHub、数据库，基本上你能想到的都有人做了对应的 MCP server。
飞书当然也可以做 MCP。接口完全公开，技术上没有任何障碍。
但 lark-cli 选择了命令行。
这个选择不是技术限制，是哲学立场。
MCP 的工作方式大概是这样，AI 在执行某个任务的过程中，调用 MCP server，MCP server 去操作对应的服务，然后把结果返回给 AI。整个过程的执行发生在「某个地方」。你没有看见它在做什么，你只看到了结果。
不是说这样不好，这是这类工具的正常运作方式。云端执行，高效，但对用户来说像一个黑盒。
CLI 不一样。
你在终端跑一行命令，工具会告诉你「我将要建一个名为 X 的群，添加以下成员，在频道里发以下消息」，你可以 dry-run 预览，确认没问题，然后让它执行，然后看到每一步的输出。你全程可见。你可以在任意一步叫停。
听起来多了几个步骤。但这里面有个关键的东西，信任。
我跟几个在探索 AI agent 自动化的朋友聊过，大家遇到的最大障碍不是「AI 做不到」，而是「我不敢让它做」。
发邮件给客户，万一发错了怎么办。修改数据库记录，万一改了不该改的字段怎么办。在工作群里发通知，万一文案写错了，被所有人看到怎么办。
这些担心不是杞人忧天，是真实的风险。你见过 AI 幻觉，你知道它偶尔会做出你完全没预料到的事。你可以容忍它在写代码时搞错一个函数名，因为你能看到代码再提交，你能 review。但你不能容忍它在飞书群里发出一条措辞奇怪的消息，因为那个你没法撤回，或者说撤回了也有人看到了。
解决这个问题的方式，不是让 AI 更聪明，而是让它的操作变得可见、可审、可在执行前叫停。
lark-cli 解决的恰好是这个。
不是「AI 能操作飞书」，而是「AI 操作飞书时你能看见它在做什么」。
这一字之差，把工具从实验品变成了可信赖的协作者。
我在想一件事，我们其实一直在等的那个时刻，不是 AI 从「不会」变成「会」，而是 AI 从「能用」变成「敢用」。
「能用」是技术问题，早就解决了。Claude、GPT、DeepSeek，随便接个 API 什么任务跑不了？能用，完全能用。三四年前就能用了。
「敢用」是信任问题。你愿意把一件真实的、有后果的事情完整地交给 AI 处理，不守在旁边盯着，不怕它搞砸？这个阈值高得多，而且不是靠 benchmark 分数能提上来的。
可见性是从「能用」到「敢用」的桥梁。
你能看见它在做什么，你才敢让它做。你能看见每一步，你才能判断哪里该介入、哪里该放手。你能看见，你就有控制感，有了控制感，焦虑才会降下来，才能真的把脑力腾出来去做更重要的事情。
这是 lark-cli 打出来的那张牌，不是功能牌，是信任牌。
好，说回飞书为什么能跑出来这个数字。
为什么是飞书，不是其他家？我自己想了想，大概有几层。
第一层比较显然，飞书的 API 文档和开发者生态积累本来就比国内竞品完整。钉钉和企业微信的 API 接入体验，做过的都知道，那种痛苦我就不细说了。飞书在这个层面做了多年，开发者有意愿在这个基础上做工具。
第二层是开源策略的选择。lark-cli 是飞书官方出品，但是完全开源的，可以自由 fork、修改、集成。这个决策意味着飞书放弃了把它做成「付费企业服务」的路子，选择把它做成开发者生态的基础设施。10 位外部开发者已经合并了主干代码贡献，这个数字还会继续增长。飞书等于在说「我不拿这个赚钱，我用这个建社区」。
第三层我觉得最有意思，是时机。
现在是 AI Agent 基础设施建设的爆发期，大家都在摸索「AI 操作工作区」这件事应该怎么做，走什么协议，给用户什么体验。lark-cli 在这个时候出来，不是说它定义了唯一答案，但先出来定义方向的那个，有巨大的先发优势。
而它定义的方向，是可见、可控、本地执行。这个方向现在看起来挺对的。
那个推文的作者说，「一句话，建群、建文档、发通知，一次性全做完了。」
我在脑子里想象这个场景。你开着终端，跟 Claude Code 说「帮我给明天的产品评审建个工作群，把设计、开发、产品几个人拉进去，在飞书文档里建个会议纪要模板，然后在群里发个消息告诉大家明天 2 点」。
然后它真的去做了。你在终端看着它一步一步来，你确认了每一步，两分钟后事情做完了。
这个「你在终端看着它一步一步来」，是我觉得最关键的部分。
不是因为这更安全（虽然确实更安全），而是因为这个过程建立了一种工作关系。你不是在向黑盒下达命令然后祈祷结果正确，而是在跟一个协作者一起干活，这个协作者每步完成后都跟你确认一下。这种感觉不一样。
我以前用过一些「全自动」的 AI 工作流工具，最大的问题不是它们出错，而是它们出错的时候你完全不知道哪一步出的错，只能推倒重来。可见性不只是用来防止失误的，它也是 debug 的基础，是你真正理解系统在做什么的基础。
其实我有点觉得，我们现在在经历的这件事，有点像 Unix 哲学最早被提出来的那段时间。
Ken Thompson 和 Dennis Ritchie 在贝尔实验室搞 Unix 的时候，定了一条原则，每个程序只做一件事，做好，然后通过管道组合。这条原则后来影响了几十年的软件开发方式。
lark-cli 有点像那个方向的延续，不是做一个「全能的 AI 助手」，而是做一个「可见的、可组合的操作接口」，让你和 AI 通过命令行的语言沟通，把权力留在你这边，把透明性留在过程中间。
我知道这两件事不能完全类比，但方向上有点像。
万能青年旅店有一张专辑叫《杀死那个石家庄人》，里面有一首歌我一直很喜欢，叫《揪心的玩笑与漫长的白日梦》，有一句「是谁来自山川湖海，却囿于昼夜厨房与爱」。
我今天看那条推文的时候，鬼使神差地想到这句歌词。
因为我觉得，AI 现在有点处于那个「来自山川湖海」的阶段——能力上已经可以做很多事，但实际上「囿于」信任的围墙，很多场景还是没法真的用起来。可见性，可能是那扇门。
好，有点扯远了。
lark-cli 的 GitHub 地址是 https://github.com/larksuite/lark-cli，飞书官方维护，一直在活跃更新。
有飞书账号的话，三分钟可以装完。
我自己的建议是，装完之后别急着接 AI。先自己在终端手动跑几个命令，看看每一步的输出长什么样，感受一下这种「可见」的操作体验。然后再想想，如果这些操作是 AI 发起的，你会有什么不一样的感受。
这个小实验，值得做一次。
就这样。
如果你也在探索 AI 操作工作区这件事，或者你有用 lark-cli 踩到有意思的坑，评论区见。