最近看到一个观点，说「GUI 是人类认知缺陷的补丁」。
想想还真是。
人的注意力太窄，工作记忆太浅，所以需要漂亮的界面、精心的布局、即时的反馈，才能勉强完成任务。Figma 的精美、Notion 的简洁、Linear 的流畅，都是在补偿人类硬件的不足。
但 AI Agent 没有这个缺陷。
它不需要按钮，不需要下拉菜单，不需要「用户引导」。它需要的是稳定的接口、清晰的文档、可预测的响应。
换句话说，Agent 才是比人类大十倍的用户群。
很多公司嘴上说重视 AI，实际做的事情就是往产品里塞一个对话框，放一个「智能助手」。这不叫拥抱 AI，这叫叶公好龙。结合我自己做飞书多维表格产品的经历，分享一些看法和八卦。
面向 AI 做产品
以前做产品，核心用户是人。人要看界面，点按钮，拖拽配置。产品团队花大量精力做 UI、做交互、做用户体验。
现在不一样了。用户和软件之间，多了一个中间层：AI Agent。
没人想学公式怎么写，没人想研究排版怎么配，没人想花半天搞清楚自动化怎么触发。大家只想输出内容、完成工作。能不动手就不动手。
所以作为软件开发者，真正要想的问题是：你怎样让 AI 更好地使用你的产品？
给 AI 写文档、提供工具、给案例，让 AI 了解你。比给用户写教程教用户操作，重要得多。
旧逻辑是建一个封闭空间，让用户走进来，用体验把他留住。新逻辑是把自己暴露出去，站在 Agent 执行任务的路径上，让它经过时不得不调用你。
这个转变，比在产品里加个对话框，深刻得多。
姗姗来迟的 CLI
最近飞书官方做了一个叫 lark-cli 的工具，用命令行操作飞书的各种功能，日历、消息、文档、多维表格，全都能操作。
其中多维表格部分，有 40 多个原子命令。建表、建字段、写数据、查询聚合、配自动化，全覆盖。
但这不是重点。重点是这些工具怎么设计的。
不是给人用的。是给 AI 用的。
举个例子：多维表格有一种叫「查找引用」的字段类型，逻辑很复杂。涉及跨表查询、过滤条件、聚合方式。一般用户配这个字段，经常出错。
怎么做的？写了一份将近 500 行的参考文档，把所有规则、约束、反模式全部写清楚。然后在命令行里加了一个机制：AI 要创建这种字段，必须先声明「我已经读过文档了」，否则命令直接拒绝执行。
这就是「面向 AI 做产品」。写清楚规则和约束，让 AI 自主、安全地完成操作。
字节有个理念叫「context, not control」，给上下文，不做控制。这个理念在公司内部其实很反人性，人总是想控制，想把流程拆细、权限收紧。但放在 AI 身上，简直完美。给到充分的上下文和数据，AI 就能表现得很好。
人做不好的「context, not control」，AI 天然擅长。
用户说一句「帮我统计每个项目的订单总额」，AI 自己去查表结构、构造配置、执行创建。全程不需要用户理解什么是查找引用、聚合函数、过滤条件。
这种体验，和「在界面上加个 AI 对话框」，完全是两码事。
Teable 也是同样的思路。它把多维表格做成了一个 Agent，你说要什么，它现场帮你建表、写数据、生成仪表盘。从搭积木进化到 3D 打印。
两个八卦
说两个飞书的八卦。
MCP 协议刚出来的时候，我在飞书内部推着做多维表格的 MCP 方案。甚至有工程师已经做了一个基础版本。但这个项目被叫停了。后面他们继续把精力花在「雕花」上，做了什么应用模式。要不是最近 OpenClaw 出来推动，飞书 CLI 这种面向 AI 的工具，压根不会上线。
还有一个更早的事。曾经有人提过「让 AI 直接搭建多维表格」的方案。更高的领导没有明确反对，只是提了一点担忧。于是深谙职场门道的人，从此绝口不提这个方案。
回想起来，当我碰到不合理的事情，选择硬刚的时候，就决定了我活不过三集。
但这不重要。重要的是方向对不对。
事实证明，方向是对的。只是有些组织反应太慢了。