AI Native 之后，产品的基本单位变了

模型可能已经知道“这是一条核心论点”，但系统里保存的只是“第 3 页左上角的一个文本框”。它可能知道某张图在支撑市场规模，文件里却只记录了图片的位置和尺寸；它可能知道某个镜头属于人物转折，下一次查找仍然只能靠时间码。

这就是今天大多数“AI 功能”的天花板：模型的理解，装不进产品的数据结构。

打开传统编辑器就能看到原因。文字处理软件围绕页面和段落，演示软件围绕幻灯片和元素，设计工具围绕画布、Frame 和图层，视频编辑器围绕素材、轨道和时间线。这些单位决定了用户看到什么，也决定了产品如何存储信息、组织功能、分配权限和保存版本——它们是为人的直接操作设计的，页面适合阅读打印，图层适合选择叠放，时间线适合控制先后。Notion 的公开 API 把页面表示为 Block 列表，Figma 的公开 API 把文件表示为一棵 Node 树，都是这套逻辑的工程化。

AI 进入软件之后，很多产品先在原有界面旁边加一个聊天框：用户提要求，模型生成内容，结果放回页面或时间线。此时 AI 仍在操作旧产品的基本单位，产品架构并没有随之改变。

变化还要继续往下走：产品的基本单位，正在从页面、文件、图层和功能，转向可被人和机器共同理解的语义对象、关系、任务与操作历史。

用户的任务，从来不以这些单位存在

用户想要的是“让管理层理解为什么项目应该继续”“把这段采访剪成观点清楚的短片”“找出报告中证据不足的结论”，而不是“新建三页”“移动五个图层”“剪掉第 37 秒到第 42 秒”。过去，产品把目标拆解为操作的工作留给了人；AI 出现之后，这部分工作第一次可以由机器承担。

但用户的意图通常跨越多个对象甚至多个应用。“把一份行业研究做成给投资人的演示”至少包含：判断哪些观点最重要，区分事实、推断和假设，为目标受众重组叙事，选择证据和视觉材料，生成页面并检查前后逻辑，根据反馈继续修改。如果产品底层只认识文本框、坐标和页面，模型即使理解了任务，也很难把理解稳定地写回产品状态。

所以 AI Native 产品除了生成内容，还要回答一个更底层的问题：产品是否拥有一种能够表达意图、语义、关系和任务状态的数据结构。

新的第一层：语义对象与关系

语义对象不是给所有内容再包一层标签，它要让产品理解每个对象在任务中的身份。

同一段文字可以是标题、论点、证据、反例、引用或待验证假设；同一张图片可以是素材、证据、背景或情绪参考；同一段视频可以是事件、人物动作、采访观点或节奏节点。这些对象还需要关系：哪条证据支持哪个结论，哪个镜头对应哪段旁白，哪页幻灯片承担什么叙事角色，哪项修改源于哪条用户反馈。

产品领域	传统操作单位	AI 更需要理解的语义单位
文档	页面、段落、字符	论点、证据、引用、受众、待办与决策
演示	幻灯片、文本框、图片	叙事节点、页面角色、论证关系与视觉资产
视频	素材、片段、轨道、时间码	人物、事件、动作、观点、情绪与镜头目的
设计	Frame、图层、组件	用户任务、界面状态、设计意图与约束

右侧不是统一的行业标准，而是一种建模方向：不同品类会有不同对象，重点不在包罗万象的知识图谱，而在找到完成核心任务所需的最小语义集合。

新的第二层：任务与结果契约

语义对象回答“产品里有什么”，任务回答“现在要改变什么”。

传统软件把动作定义得很清楚：新建、删除、移动、导出。AI 产品还需要更高一层的任务定义：目标、输入、工具、权限、约束、结果、验收与失败处理。“生成五页 PPT”是一组动作；“让第一次接触项目的人在五分钟内理解问题、方案和风险”才定义了任务结果。一份完整的任务至少要写清：要产生什么变化，操作哪些内容，哪些事实和边界不能破坏，允许读写什么，怎么判断完成，证据不足或工具失败时怎么办。

今天的 Agent 基础设施正在补这一层——MCP 通过标准化的 Tools 和 Resources 让模型读取外部上下文并调用系统能力，Agent 开发框架越来越强调工具调用、Guardrails、Tracing 和执行过程。但接上工具只是必要条件：产品还要把用户目标翻译成可执行、可检查的结果契约，它决定了 Agent 能判断的是“我做了什么”，还是“事情是否做成”。

新的第三层：操作历史、证据与来源

当 AI 可以一次修改大量对象，传统的“撤销一步”就不够用了。产品需要记录：谁在什么时候提出了什么目标，AI 用了哪些材料与工具，哪些对象被创建、删除或修改，哪个结论来自哪个来源，哪部分是原始内容、哪部分是模型推断，用户接受、拒绝或手工修正了什么。

这些记录同时关系到安全、协作和学习。如果系统只保存最终像素，用户很难判断结果是否可信；如果系统保存对象级 Diff、来源和操作记录，用户就能比较版本、局部回退、审核证据，并把有效修改沉淀为下一次任务的规则。

编辑器不会消失，但会降级为视图

一种常见误解是：既然 Agent 能直接完成任务，编辑器和 GUI 就会消失。但人仍然需要浏览全局、比较方案、局部精修、做审美判断、处理例外并最终确认——文字、画布、幻灯片、时间线仍然是高效的人机界面。变化在于：它们不必再各自拥有一份割裂的“真相”。

同一组语义对象可以被呈现为一篇完整文档、一组演示页面、一张白板关系图、一个网页、一条视频脚本与时间线。不同视图负责不同任务：文档适合线性阅读，白板适合空间组织，幻灯片适合演示，时间线适合精确控制节奏。GUI 也从唯一的操作入口，转为三种角色——让人看见 AI 理解了什么、改变了什么的状态反馈；让人直接处理模型不擅长的局部问题的精细控制；处理冲突、高风险动作和最终验收的例外确认。

为什么只加聊天框不够

聊天是表达开放意图的高效方式，但它不是完整的产品架构。如果每次任务都从一段新对话开始：上下文散落在历史消息里难以持续维护；用户不知道模型当前依据的是哪一版内容；多人和多个 Agent 难以围绕同一状态协作；修改结果缺少对象级 Diff；记忆持续累积，却无法被结构化检查和删除。

更清楚的分工是：对话负责提出意图和解释结果，任务负责管理执行，语义对象承载状态，操作历史记录变化，编辑器负责浏览、控制与确认。聊天只是入口之一。

迁移分三步，不会一步到位

成熟产品不可能抛弃原有文件格式、用户习惯和生态。第一步，在旧编辑器里增加 AI 动作：模型完成改写、生成、补全和局部编辑，底层状态仍以文件、页面、图层为主——这一步检验的是单点能力是否省时间、结果是否可控。第二步，建立语义层并与原有对象双向同步：产品开始识别人物、论点、素材、任务和关系，AI 操作语义对象、界面把变化映射回页面和图层，用户的手工修改也同步回语义状态——这一步最难的是身份一致性、同步、冲突、权限和用户信任，生成质量只是其中一部分。第三步，语义与任务状态成为主状态：文件和编辑器变成多个视图，同一任务可以跨文档、演示、设计和外部工具完成，Agent 围绕共享对象、权限和操作历史协作。

这仍是长期推演。它能否成立，取决于产品是否真的需要跨介质任务，以及建立语义层的收益是否高于复杂度。

路线图和指标也要跟着换

如果基本单位改变，产品团队衡量进展的方式也会变化。以功能为单位的路线图——增加一个生成入口、支持一种格式、上线一个模型——会让位于另一组问题：能稳定覆盖哪些完整任务；任务完成率和人工修正成本；关键对象和关系是否被正确识别；来源与证据是否完整；大规模修改是否可检查、可回退；同一状态能否在多个视图中保持一致；用户是否愿意把同一任务再次交给系统。生成质量仍然重要，但它只是任务完成的一部分。

传统编辑器围绕人的直接操作建立，页面、文件、图层和时间线也因此成为产品的基本单位。AI 可以理解更高层的意图、一次操作多个对象，产品要承接这种能力，就需要重新表达自身状态——旧界面旁边的聊天框只是第一步。并非所有产品都要做 Agent，所有内容也不必进入复杂的语义图谱；更实用的判断是：如果用户的核心任务跨越多个页面、对象和工具，而 AI 需要持续理解目标、关系和历史，那么产品就应该把任务与语义状态提升为第一层对象。

页面仍会存在，文件仍会交付，编辑器仍会被使用。但它们会越来越像人观察和控制产品状态的窗口，而不是产品状态本身。