夜雨聆风
飞书、淘宝都在做同一件事:软件开始不再只是给人用
#
很多人看到飞书开放 CLI，第一反应可能是：
“哦，飞书又多了一个给程序员用的工具。”
如果只是这么理解，那大概率低估了这件事。
因为飞书开放 CLI，真正重要的，从来不是命令行本身。前段时间，像淘宝这样的平台，也在释放出类似的信号。
一个是办公协同平台，
一个是商业交易平台。
看起来完全不是一个赛道，但它们都在朝同一个方向变化：
把自己的能力拆出来，变成 AI 可以直接调用、组合、执行的结构。
这背后真正发生的，不是某个产品多了一项新功能，而是：
软件，正在从“给人用”走向“给 AI 调用”。
这不是一次普通升级。
这可能是未来几年软件行业最重要的底层变化之一。
一、飞书开放 CLI，真正重要的不是 CLI
CLI 当然是个技术词，叫命令行接口。
但今天如果我们还只是把 CLI 理解成“可以在终端里敲命令”，那其实已经太表层了。
因为在 Agent 时代，CLI 的意义不再只是“方便开发者”，而是：
把原本藏在软件内部的能力，变成可被调用、可被编排、可被自动执行的动作单元。
过去，很多操作只能由人手工完成：
这些能力原来都锁在 UI 里，必须由人打开页面、点按钮、填参数、确认执行。
但一旦它们被标准化成可以被调用的结构，事情就变了。
它们可以被：
– 脚本调用
– 工作流调用
– Skill 调用
– 甚至直接被 Agent 调用
所以飞书开放 CLI，真正值得关注的，不是“多了一个工具”，而是它释放了一个更深的信号：
软件的价值中心，正在从“页面功能”转向“可调用能力”。
二、这不是飞书一个人的动作，而是整个软件世界在变
如果只看飞书，这像一个产品动作。
但如果把视野拉开，你会发现这不是孤例。
越来越多的软件和平台，正在做同一件事：
第一，开始为 AI 提供第二套入口
过去的软件只需要服务一类用户：人。
所以产品的重点是：
– 页面够不够清晰
– 操作够不够顺手
– 菜单够不够好找
– 学习成本够不够低
但未来的软件，不只要给人用，还要给 AI 用。
于是你会看到越来越多产品开始重视：
– API
– CLI
– Tool Schema
– Workflow 接口
– 事件回调
– 权限体系
– 上下文读写能力
这意味着软件不再只有一个入口，而开始同时面向两类使用者：
这件事一旦成立，软件的很多设计逻辑都会被改写。
第二，软件的最小价值单元变了
过去大家比的是“有没有这个功能”。
我有文档，你有表格，他有审批，谁做得更全，谁就更有竞争力。
但在 Agent 时代，更重要的问题开始变成了：
也就是说，软件的最小价值单元，正在从“页面功能”变成“可调用能力”。
这不是表达方式变了，这是软件结构真的在变。
第三，平台开始为“自动执行”做准备
飞书代表的是组织协同平台。
淘宝代表的是商业交易平台。
这两个平台，一个偏组织，一个偏商业，原本属于两个世界。
但如果它们都开始往“能力开放、接口化、组件化”的方向走，那说明这已经不是某个垂直领域的小变化了。
它更像是一个行业级趋势：
平台不再只是让人操作，也开始为智能体执行任务做准备。
这一步一旦迈出去，平台的意义就会被重新定义。
三、为什么飞书和淘宝值得放在一起看？
因为它们恰好代表了两类最核心的平台形态。
飞书，代表组织协同系统
它连接的是：
– 人
– 文档
– 知识库
– 日历
– 任务
– 消息
– 表格
– 流程
– 审批
飞书的核心价值，在于承载组织内部的信息流和协作流。
淘宝，代表商业交易系统
它连接的是：
– 商品
– 店铺
– 内容
– 用户
– 交易
– 营销
– 服务
– 履约链路
淘宝的核心价值，在于承载商业行为和交易行为。
这两个平台原本解决的是不同问题，但如果它们都在往“能力开放、结构化调用、支持智能体接入”的方向走，那它们其实共同说明了一件事：
未来的平台，不只是连接人与服务，也会越来越多地连接 Agent 与能力。
这句话看似简单，但含义很重。
因为过去平台竞争的核心是：
– 用户规模
– 功能完备度
– 生态覆盖范围
– 流量入口
但未来平台竞争，很可能还会多出一项：
谁更适合被 Agent 接入、调度和执行。
这就是另一层竞争了。
四、真正的变化，是软件开始从“给人点”走向“给 AI 调”
如果把这轮变化说得最直白，我觉得就是一句话：
过去的软件主要是给人点击的，未来的软件会越来越多地变成给 AI 调用的。
这不是一个修辞句，它会直接改变软件怎么被设计。
给人用的软件，核心是交互体验
它最关心的是：
– 页面结构
– 视觉层级
– 操作路径
– 用户引导
– 使用成本
给 AI 用的软件，核心是能力结构
它更关心的是：
– 功能是否标准化
– 输入输出是否明确
– 参数是否可理解
– 权限是否可控
– 调用是否稳定
– 结果是否可回写
– 过程是否可审计
所以你表面上看到的是飞书开放 CLI，但更深一层，它其实在提醒我们：
软件行业，正在从 GUI 中心走向能力中心。
这才是飞书、淘宝这些变化真正值得看的地方。
五、为什么它最后一定会走向 Skill、Workflow，甚至 Agent？
因为单个能力本身没有业务价值，被组织起来的能力，才会形成真正的结果。
比如系统如果只提供这些动作：
– 建文档
– 发消息
– 查日历
– 改表格
– 拉任务
那它只是“有很多工具”。
但如果这些动作能被自动组织成一个完整过程：
那它就不再只是工具，而变成了一个完整的 Skill，甚至是一个 Workflow。
再往前一步，如果系统还能根据上下文自己决定：
– 该调哪个能力
– 下一步该做什么
– 哪一步需要找人确认
– 哪一步要把结果回写系统
那它就开始接近真正的 Agent 了。
所以如果把能力的演化路径画出来，大概就是：
能力开放 → Skill 化 → Workflow 化 → Agent 化
飞书 CLI 值得关注，不是因为它是 CLI，而是因为它站在这条链条的起点上。
六、但 Skill 会是最终形态吗？
说到这里，一个更本质的问题就来了：
如果飞书只是把自己的能力写成各种各样的 Skill，那 Skill 会不会就是未来最好的形态？
我的判断很明确：
Skill 很重要，但 Skill 不是终局。
它是当前阶段最实用、最容易落地、最容易理解的一种中间形态。
为什么它现在这么重要？
因为 Skill 有几个天然优势：
所以在今天这个阶段，Skill 一定会很有生命力。
但它也有明显边界：
所以从更长周期看，Skill 更像什么？
它更像移动互联网早期的 App，或者更准确一点，像插件和功能包。
重要，但不是终局。
七、比 Skill 更高一层的，可能是什么？
如果继续往前走，我觉得真正更重要的，会是 Skill 之上的三层结构。
1. Workflow Template
未来用户要的，可能不是“一个 Skill”，而是一个完整任务模板。
比如：
– 招聘流程模板
– 客户跟进模板
– 会议复盘模板
– 培训沉淀模板
用户真正关心的不是“我该调用哪个 Skill”，而是：
这件事能不能被自动完成。
所以 Skill 很可能会逐渐退到底层，而 Workflow Template 成为用户真正感知的产品形态。
2. Agent Role / Policy
再往上一层，关键的不只是能力，而是 Agent 的角色和边界。
比如：
– 它能做什么
– 不能做什么
– 什么情况下必须找人确认
– 什么情况下可以自动继续
– 什么情况下必须停下来
到这个层面，问题已经不只是工具问题，而是决策系统问题。
3. Capability Runtime
如果再往基建层看，未来真正决定上限的，可能不是 Skill 本身，而是一个“能力运行时”：
如果把 OpenClaw、小龙虾这类平台看成未来的 Agent OS，那 Skill 更像应用层对象，而真正决定生态上限的，是运行时本身。
也就是说：
Skill 也许会很火，但真正决定未来的，不是 Skill 数量，而是系统如何组织、调度和运行这些能力。
八、所以真正的机会，不是学会一个工具，而是看懂这次重构
如果把视角拉高，飞书、淘宝这些动作带来的机会，就不能只理解成“会不会用某个 CLI”。
真正的机会在于：
第一，看懂软件为什么开始能力化
这不是功能升级，而是底层结构变化。
第二，看懂谁能把业务动作封装成可调用能力
真正值钱的，不只是写代码的人，而是那些能把工作流程抽象成 Skill、Workflow 和 Agent 的人。
第三，看懂谁在争夺下一代入口
未来平台之间竞争的，不只是用户入口、流量入口、功能入口。还包括：
所以问题的重点，已经不再只是：
“这个工具怎么用？”
而是：
在一个软件越来越适合被 Agent 调用的世界里，谁能最先重构自己的工作方式、产品结构和交付方式？
这才是真正的机会点。
rnrn## 写在最后
飞书开放 CLI，淘宝开始释放能力，这些表面上看都只是产品动作。
但真正的大事，从来不在动作本身，而在于：
软件正在改写自己的服务对象。
过去，软件的默认用户是人。
未来，软件的默认用户会变成“人 + 智能体”。
一旦这个前提成立，产品怎么设计、平台怎么开放、能力怎么组织、生态怎么构建，都会跟着变。
所以真正值得问的，不是：
“飞书这个 CLI 好不好用？”
而是：
当软件开始为 AI 重构自己时，谁会先变成下一代工作系统的底座？
这，可能才是飞书 CLI 背后真正的大事。