从信息容器到工作系统：AI 产品如何从信息走向生产力
在设计 AI 产品时，产品经理面临的第一个挑战，往往不是某个具体用例、模型能力或交互模式，而是一个更根本的问题——设计对象本身已经发生了变化。
在互联网时代，产品围绕信息而设计。需要解决的核心问题是：信息应当如何被生产、组织、分发和消费。因此，产品形态逐渐收敛为各种不同类型的信息容器。
而在 AI 时代，产品开始直接承载生产能力。问题不再是信息应当如何呈现，而是如何组织、调用并持续释放 AI 的生产能力。
一旦设计对象发生变化，既有产品方法论和结构模型背后的假设也会开始失效。
如果用一个简单的类比来描述这种转变：
互联网产品更像报纸，而 AI 产品更像办公室。
这体现的是设计对象、产品结构和价值循环上的根本性变化。
互联网产品围绕信息而设计
互联网解决的是一个信息问题：信息如何被生产、组织、分发和消费。
因此，从一开始，互联网产品的设计对象就很明确——信息本身。
产品经理的核心职责，是设计适配特定场景的信息容器：
信息存在于哪里，如何被组织和分发，以及用户如何持续消费它
随着时间推移，信息容器经历了几个清晰的发展阶段：
| 阶段 | 形态 | 核心特征 |
|---|---|---|
| 阶段 1：实体媒介 | 报纸 / 杂志 | 版面和栏目决定了信息如何被组织。编辑决定什么重要，以及它应当被以多醒目的方式呈现。 |
| 阶段 2：数字化分发 | 网页 / 信息流 | 信息迁移到线上，更新更快、入口更多，但核心设计逻辑依然围绕呈现与展示展开。 |
| 阶段 3：算法策展 | 推荐系统 / 个性化信息流 | 产品不再设计一份固定的“报纸”，而是设计生成这份报纸的规则。每个用户看到的版面都不同，由算法而非编辑来塑造。 |
换句话说，设计互联网产品，本质上一直是在设计一份报纸。即便报纸的形态不断变化，设计对象始终是信息，设计范式也始终围绕信息容器展开。
AI 产品围绕生产力而设计
AI 的出现不仅仅意味着内容生成更快。它把一种可调用的生产力直接引入产品之中——这种力量能够参与任务拆解、路径选择、执行以及结果验证。
在这一前提下，产品经理面临的是一个根本性的新问题：
你要如何设计一个工作容器，来承载、调度并约束这股生产力？
这是 AI 产品与互联网产品最本质的区别。
类似地，工作容器也经历了若干演进阶段：
| 阶段 | 形态 | 协作模型 | 核心特征 |
|---|---|---|---|
| 阶段 1：实体工作容器 | 办公室 | 人 ↔ 人 | 工作依赖物理空间和制度化分工。上下文主要存在于人和会议中，因此经验难以积累或转移。 |
| 阶段 2：数字化工作容器 | Notion、Lark、Docs 等 | 人 ↔ 人 | 办公室迁移到线上，解决了协作、同步和访问控制问题。生产力依然来自人，系统的重点则是实现更高效的协同。 |
| 阶段 3：AI 原生工作容器 | Kuse、Cowork 等 | 人 ↔ AI | AI 不再只是助手，而是容器中的持续性生产力。产品重点也从“人如何高效协作”转向“如何组织并释放 AI 生产力”。 |
真正的分界线，不在于一个产品是否“有 AI”，而在于它的容器是否是为 AI 驱动的生产力而设计的。
要回答什么样的容器才能真正支撑 AI 生产力，我们必须理解人类如何工作、AI 如何工作，以及两者如何在共享结构中协作。
文件系统：人类与 AI 共享的工作容器
为什么文件系统适合人类工作
人类工作并不是产出一次性的结果，而是一个把某件事从历史状态持续推进到目标状态的过程。
每向前一步，都发生在约束之下：朝目标推进始终伴随着真实成本。
为什么文件系统适合人类工作
状态的时间与空间结构
任何一个工作状态都会同时存在于两个维度之中。
在时间上，它承接过去，存在于当下，并指向下一步。
在空间上，它作用于具体对象，具有明确的范围、粒度与成本。
如果工作要持续推进，状态就必须能够被稳定地表达、访问和操作。
文件：状态的最小表达单元
文件不只是存储内容，它表达的是状态。
- 历史文档表达已完成的状态
- 正在工作的文件表达进行中的状态
- 策略或目标文档表达预期的未来状态
文件让状态变得可见、可继承、可操作。
文件夹：管理并推进状态的容器
文件夹不只是用来组织内容。它的首要作用，是管理一项工作的完整上下文。
在一个文件夹中，历史文件、当前文件和目标文件并存，它们共同定义范围、起点与下一步。它们不再是孤立的内容，而是一个连续的工作状态。
这并不意味着文件系统是推进工作的唯一方式。但经过长期实践，自计算机诞生以来，它已经成为组织和推进工作最稳定、最广泛采用的结构之一。
为什么文件系统同样适合 AI 工作
一旦我们理解了人类工作的结构，AI 的工作逻辑也会显现出一种相似——但约束更多——的模式。
AI 如何工作：Token 与上下文
从根本上说，无论是生成文本、编写代码，还是规划任务，模型做的始终是同一件事：
给定一个上下文，基于已有 token 预测下一个 token。
所谓“输出”，本质上就是一串被预测出来的 token 序列。
输出是否符合预期，不仅取决于模型本身有多强，还取决于生成之前有哪些 token 在约束它。
这些上下文 token 决定了三个关键因素：
目标是否清晰、粒度是否可控，以及范围是否定义明确。
上下文的结构性约束：一次性窗口
上下文本身存在一个根本限制。它不是持久化的工作空间，而是一次性的计算窗口。
这意味着，在每次推理之前，系统都必须为模型重新构造合适的上下文。
上下文的经济性约束：Token 成本
上下文也是一种带有成本的资源。每一个 token 都会直接参与推理。
token 越多，计算成本和延迟就越高。因此，AI 产品设计的重点不是给模型更多信息，而是在有限的 token 预算内构造最小但足够的上下文。
文件系统：上下文的外部状态空间
当工作状态被稳定地存储在外部系统中时，上下文就不再需要一次性全部载入。
系统可以有选择地检索、裁剪并组合相关状态，为当前任务构造刚刚好的上下文。
文件系统正是这样的外部状态空间。
文件和文件夹不是一堆信息，而是围绕具体工作不断积累的状态表达。它们定义了清晰的对象边界，建立了明确的范围，并允许历史状态与当前状态被一同读取。
一个已被验证的结构：编程产品
这种结构优势已经在编程产品中得到了验证。
软件通过对具体代码文件的持续维护与修改而演化。每一次改动都会被写回文件系统，后续工作也基于这些状态继续推进。
AI 之所以能在编程中展现出持续、可控的生产力，并不是因为它在这个领域天生“更聪明”，而是因为代码本来就存在于一个高度结构化、可演进的文件系统之中。
文件系统如何放大 AI 生产力
回看 AI 的工作本质，文件系统放大的不是智能本身，而是 AI 输出符合预期的概率，以及工作得以持续推进的可能性。
正因如此，这种设计不会被更强的模型“吃掉”。
模型会越来越强，而文件系统确保这种能力能够持续地、经济地、可靠地落在正确的位置上。
当人类与 AI 在同一个文件系统中协作
当文件系统同时满足人类表达工作状态的需求，以及 AI 构造上下文时的结构与成本约束，协作方式就会发生根本性变化。
从指令循环到状态交接
协作不再主要发生在对话层，而是围绕工作状态本身展开。
文件成为共享的工作对象，文件夹定义共享的边界。
人类通过修改目标文件和约束文件来调整方向。AI 则基于既有状态推进执行。
协作从来回下达指令，转向基于状态的交接：
人类负责判断与验证，AI 负责执行与推进。
从一次性输出到可演进的工作资产
一旦 AI 输出被稳定地写入文件系统，它们的性质就发生了变化。
输出不再是用完即弃的内容，而成为可继承、可修改、可复用的工作状态。
历史文件记录已完成的工作，活跃文件承载正在推进的进度，目标文件指向预期到达的终点。
工作不再是一堆孤立结果，而是一条持续演进的轨迹。
从操作惯性到系统潜能
在这种结构中，系统开始展现出惯性与潜在能力。
工作不再依赖持续不断的人类介入。它会在既定状态和约束下向前推进。
人类定义目标并处理异常。AI 在范围内执行。文件系统积累过程与资产。
一个“自我运转的办公室”之所以能够出现，不是因为 AI 取代了人类，而是因为工作被放入了一个人类与 AI 都能共同推进的结构之中。
结论
从互联网时代走向 AI 时代，产品设计的中心正在从“信息如何呈现”转向“生产力如何组织”。
当工作被理解为连续的状态推进时，产品设计的核心就不再是入口或交互，而是系统能否承载这种推进。
文件系统不是一种偏好。在当前的技术和成本约束下，它是一项让人机协作真正可行的结构性决策。
它所定义的不是一组功能，而是一种关于 AI 能否被吸收到真实生产力中的设计判断。