AI 产品的下一种形态：数据、API 与 Skill

最近在思考一个问题：AI 产品到底应该从哪里开始设计。

过去做产品，我们很自然会先想页面、菜单、后台、流程。一个需求来了，第一反应是画原型、拆功能、做管理端。这个路径在传统软件时代当然有效，因为界面是用户接触系统的主要方式，页面组织能力就是产品能力的一部分。

但进入 AI 时代之后，这件事正在发生变化。界面变得越来越便宜，甚至可以被实时生成。真正稀缺的，不再是做一个漂亮页面，而是把业务对象、数据关系和能力边界建模清楚。

四层结构：数据、API、Skill、界面

我越来越倾向于把 AI 产品拆成四层：底层是数据建模，其次是 API，再往上是 Skill，最后才是 SaaS 或生成式 UI。

数据建模决定系统如何理解业务世界。一个企业、一条政策、一项任务、一次审批、一份报告，它们之间是什么关系，哪些字段是稳定的，哪些状态会变化，哪些动作会触发后续流程，这些如果没有想清楚，后面接再强的模型也只是临时发挥。

API 决定能力能不能被稳定调用。AI 不应该总是去模拟点击人类界面，而应该直接调用清晰的能力接口。查询、生成、归档、审批、推送、计算、导出，这些能力如果被 API 化，智能体就有了可以使用的手脚。

Skill 则是把能力包装成可复用的工作单元。单个 API 解决的是一个动作，Skill 解决的是一个流程。比如从资料收集到报告生成，从日记整理到任务抽取，从客户信息分析到推荐下一步动作。Skill 的价值在于把人的经验、业务 SOP 和工具调用串成一个稳定流程。

最后才是界面。它可以是传统 SaaS 页面，也可以是聊天入口、工作台、移动端卡片，甚至是根据用户任务临时生成的 UI。界面的形式会越来越灵活，但它背后的数据、接口和流程必须足够稳定。

智能体平台不是万能聊天框

这也改变了我对智能体平台的理解。智能体不是一个万能聊天框，而是一组可组合的能力矩阵。一个智能体能做什么，不取决于它会不会说，而取决于它背后接了哪些工具、有哪些数据、能否在具体任务中稳定完成闭环。

产品经理的工作正在下沉

如果从这个角度看，很多 SaaS 产品未来都可能被重新拆解。不一定先做一个大而全的系统，而是先把业务能力 API 化，再包装成一个个可调用的 Skill，最后根据用户场景生成不同的交互界面。

产品经理的工作也会随之变化。过去我们大量时间花在页面结构、入口层级和字段摆放上；未来更重要的工作，可能是定义业务对象、能力边界、调用方式、失败处理和人机协作关系。

AI 时代不是不需要产品设计了，而是产品设计的重心下沉了。谁能把业务世界建模得更清楚，谁就更有机会在生成式界面之上，做出真正可复用、可扩展的 AI 产品。