2026-01-25 18:26
扫码打开虎嗅APP
本文来自微信公众号： 投资实习所 ，作者：StartupBoy
在设计AI产品时，产品经理首先要面对的，往往不是具体场景、模型能力或交互形式，而是一个更基础的问题：设计对象已经发生了变化。
在互联网时代，产品的设计对象是信息。产品所要解决的，是信息如何被生产、组织、分发与消费，因此产品形态最终收敛为各类信息容器。
而在AI时代，产品开始直接承载生产力。问题不再是“信息如何呈现”，而是AI的生产能力如何被组织、被调用、被持续地使用。
当设计对象发生变化，原有的产品方法论与结构假设，也随之开始失效。如果用一个直观的类比来概括这种转变：互联网产品像一份报纸，AI产品更像一间办公室。这是设计对象、产品结构与价值闭环的整体转移。
互联网产品的设计对象是信息
互联网解决的是信息问题：信息如何被生产、组织、分发与消费。
因此，互联网产品的设计对象一开始就很明确——信息。
产品经理的工作，本质是在设计贴合场景的信息容器：信息放在哪儿，如何被组织、分发，又如何被用户持续地消费。
信息容器经历了清晰的三个阶段：
换言之，设计互联网产品，本质上始终是在设计一张报纸。报纸的形态在变化，但设计对象始终是信息，设计范式也始终围绕信息容器展开。
AI产品的设计对象是生产力
AI的出现，并不只是让内容生成得更快，而是把一股可被调用的生产力，直接嵌入产品内部——参与拆任务、选择路径、推进执行、检查结果。在这样的前提下，产品经理开始面对一个全新问题：
如何设计一个能够承载、调度并约束这股生产力的工作容器。
这，正是AI产品与互联网产品之间最根本的差异。类似的，工作容器也经历了阶段性演进：
分水岭不在于“有没有AI”，而在于容器是否为AI生产力而设计。那么,什么样的容器才能真正承载AI的生产力？要回答这个问题,需要分别理解人类的工作方式和AI的工作方式，以及两者如何在同一结构中协作。
文件系统，一种人和AI双向奔赴的工作容器
为什么文件系统适合人类工作
人类工作的本质并不是产出一次性结果，而是将事物从历史状态推进到目标状态的连续过程。每一次推进，都发生在约束之下：既要向目标靠近，也要付出真实的成本。
1.状态的时空结构
任何一个工作状态，都同时存在于时间和空间两个维度中。
在时间维度上，它继承历史、处在当下，并指向下一步；
在空间维度上，它作用于具体对象，存在明确的范围、粒度与成本。
因此，如果工作要能够被持续推进，状态就必须被稳定地表达、获取与操作。
2.文件：状态的最小表达
文件承担的不仅是“内容存储”，也是状态表达。
文件让状态变得可见、可继承、可操作。
3.文件夹：状态的管理与推进容器
文件夹不只是为了整理文件，更重要的是为了管理一次工作的完整上下文。
一个文件夹中并列的历史、当前与目标文件，共同定义了一项工作的范围、来源与下一步。
它们不再是孤立内容，而是一项工作的连续状态。
这并不意味着文件系统是状态推进的唯一方式，但在长期实践中，它以一种极其稳定的形式，成为了自计算机诞生以来，人类组织与推进工作的通用选择之一。
为什么文件系统适合AI工作
在理解了人类工作的状态结构后，再来看AI的工作方式，会发现一个相似但更受约束的逻辑。
1.AI的工作方式：token与上下文
从底层看，无论是生成文本、编写代码，还是制定计划，模型所做的事情始终一致：
在给定的上下文中，根据已有的token，预测并生成下一个token。
所谓“产出”，本质上是一组预测token的组合。因此，产出是否符合预期，并不只取决于模型是否足够“聪明”，更取决于——在生成之前，模型已经被哪些token所约束。
这些上下文token，决定了三件关键的事情：
目标是否明确，粒度是否受控，范围是否清晰。
2.上下文的结构限制：一次性窗口
然而，上下文本身存在一个根本限制。它并不是一个持续存在的工作空间，而是一次性的计算窗口。
这意味着每一次计算开始之前，系统都必须为AI重新构建一份合适的上下文。
3.上下文的经济约束：token成本
与此同时，上下文还是一项成本资源。上下文中的每一个token，都会直接参与推理计算。token数量越多，计算成本与延迟越高。因此，AI产品设计的关键不在于“如何给模型更多信息”，
而在于：如何在有限的token预算内，为当前任务构建最小但充分的上下文。
4.文件系统：上下文的外部状态空间
当工作状态被稳定地保存在外部系统中时，上下文便不再需要一次性完整加载。
系统可以围绕具体任务，从外部状态中按需选择、裁剪与组合相关信息，为AI构建恰好合适的上下文。
文件系统，正是这样一种外部状态空间。文件与文件夹并非零散信息的堆积，而是围绕具体工作逐步沉淀下来的状态表达。
它们具备明确的对象边界，界定清晰的工作范围，并允许历史状态与当前状态同时被读取。
5.已被验证的结构：coding产品
这种结构优势，在coding产品中已被验证。软件产品的推进是通过持续维护和演进一组明确的代码文件完成的。每一次修改都会被写入文件系统，下一次工作又从这些状态继续推进。
AI能够在编程领域展现出持续、可控的生产力，并非因为它在这一领域更“智能”，而是因为代码天然存在于一个高度结构化、可演进的文件系统之中。
6.文件系统如何放大AI生产力
回到AI的工作本质可以发现：文件系统并没有放大AI的智能。
它放大的，是——AI交付物符合预期的概率，以及工作能够连续推进的可能性。
正因如此，这种设计并不会随着模型能力的提升而被“吃掉”。
模型负责变强，文件系统负责让这种强度持续、经济、并且稳定地落在正确的位置上。
当人和AI在同一文件系统中协作时
当文件系统同时满足了人类对工作状态的表达需求，也满足了AI构建上下文、持续交付的结构与成本约束，人和AI的协作方式开始发生变化。
1.从指令往返，到状态接力
协作不再主要发生在对话层，而是围绕工作状态本身展开。
文件成为人和AI的共同工作对象，文件夹界定双方共享的工作边界。
人通过调整目标与约束文件来改变方向，AI则基于已有状态持续推进执行。
协作由此从“指令往返”，转变为一种围绕状态的接力：人负责判断与校验，AI负责执行与推进。
2.从一次性交付，到可演进的工作资产
当AI的产出被稳定地写入文件系统，结果的性质也随之发生改变。
产出不再是一次性的内容，而成为可以被继承、修改和再利用的工作状态。
历史文件记录已经完成的部分，当前文件承载正在推进的工作，目标文件指向期望抵达的方向。
工作由此形成连续轨迹，而不是零散结果的堆叠。
3.从运转惯性到系统潜力
在这样的结构下，系统开始显现出一种运转惯性和潜力。工作不再完全依赖高频人工介入，而是在既定状态与约束下持续向前。
人定义目标、处理例外，AI在范围内推进执行，文件系统沉淀过程与资产。就像“一间会自运转的办公室”，并不是因为AI取代了人，而是因为——工作被放置在了一个可以被人和AI共同推进的结构之中。
总结
从互联网到AI，产品设计的核心正在从“信息如何呈现”，转向“生产力如何被组织”。当工作被理解为状态的持续推进，产品的关键不再是入口或交互，而是能否承载这种推进。
文件系统并非一种偏好，而是在当前技术与成本约束下，使人和AI协作成为可能的合理结构。它所描述的不是功能形态，而是AI能否被组织吸收为生产力的一次设计判断。
End！
