你还在设计页面?AI 产品已经在设计上下文啦

我接触了很多产品经理和设计师，发现这两年聊 AI 产品，大家最容易盯着的，还是“它长什么样”、“入口怎么放”、“功能怎么排”。但我越来越觉得，AI 时代真正变掉的，不只是交互形式，而是产品设计的重心。

以前做产品，我们主要在设计页面、功能和信息架构。说白了，是在设计“人怎么操作系统”。可当 AI 开始替人执行任务之后，事情就变了。

不只是要考虑页面怎么摆，还要考虑：模型有没有拿到正确的目标？上下文够不够？工具能不能调用？记忆怎么维护？哪些地方必须让人 review？

很多 AI 产品看起来很聪明，用起来却很蠢，问题往往不在模型，而在这套执行环境根本没设计好。

所以我现在越来越倾向于一个判断：

“ AI 产品的核心，正在从信息架构，变成上下文架构 ”

一

先说什么叫“信息架构”。过去做产品，核心问题通常是这些：

功能怎么拆
页面怎么组织
信息怎么分层
用户从哪个入口进入
操作路径是否顺畅

这套方法在传统软件时代非常有效，因为那个时代的默认前提是：人负责理解问题，人负责执行操作，系统负责提供界面和反馈。

比如你做一个电商后台，重点是菜单怎么分组、筛选怎么设计、数据表格怎么排、详情页放哪些信息。你本质上是在帮人更高效地使用系统。可 AI 产品不一样。

图片来自网络，侵删

当模型开始参与理解、决策、调用工具、执行任务时，执行者不再只是用户本人了。很多时候，系统的一部分操作链条，其实是模型在替你跑。

一旦执行者从 “人” 变成 “人 + 模型”，你要设计的东西就不只是页面本身了。你还得设计模型怎么理解任务，怎么拿上下文，怎么用工具，什么时候该停，什么时候该把控制权还给人。这就是为什么我觉得，只盯着信息架构，已经不够了。不是它没用，而是它已经从“主战场”退成了“基础层”。

二

很多 AI 产品的问题，其实都不是“模型不够强”，而是“上下文设计太烂”。这话听起来有点暴论，但基本就是事实。如果你跟风养了虾，听别人描述、看别人的案例会觉得很惊艳：

“哇，它会写。”

“哇，它会总结。”

“哇，它会帮我自动做任务。”

图片来自网络，侵删

结果你真用起来，几轮之后就开始出问题：

它理解错了你的目标
它抓错了重点
它把不该改的东西改了
它忘了你前面说过什么
它明明调用了工具，但结果根本没法用
它看起来一直在干活，其实越跑越偏

很多人第一反应是：模型不行。然后就开始四处换模型，研究怎么接入 Claude 不被封号。真拆开看，常常不是模型不行，而是设计者压根没把执行环境设计明白。

就像你招了一个很聪明的新员工，但你既没讲清目标，也没给清楚上下文，也没规定权限边界，也没告诉他什么时候该来问你，最后他当然会把事情做歪。

模型也是一样。AI 不是魔法，它只是把“上下文设计”这件事的重要性，放大了一百倍。

三

那什么叫“上下文架构”？

如果让我用最简单的话说：上下文架构，就是你为模型设计的一整套执行环境。它不只是 prompt，不只是知识库，也不只是记忆。

而是：你让模型在什么目标下工作、看到什么信息、能调用什么工具、保留哪些记忆、在哪些节点接受人工 review，这整套东西加起来，才叫上下文。

在我现在的理解里，一个完整的 AI 产品，至少有 5 层上下文要设计。

1. 目标上下文

这是最容易被忽略、但最致命的一层。

模型必须知道：

最终要达成什么结果
什么算成功
什么是不该做的
这次任务的边界在哪里

很多 AI 产品失败，不是因为模型不会做，而是因为目标本身就是糊的。

用户随手说一句，系统随便理解一下，就开始往前跑。跑到最后发现，方向根本不对。传统软件很多时候可以靠用户自己一点点点出来，但 Agent 不行。它一旦开始自主推进，目标稍微歪一点，后面全歪。所以在 AI 产品里，目标表达本身，已经是产品设计的一部分了。

2. 任务上下文

模型还得知道：

当前任务进行到哪一步
哪些步骤已经完成
哪些依赖还没解决
下一步应该推进什么

这一层本质上就是任务状态管理。以前很多软件不太需要系统自己维护这层，因为人脑会补。用户自己知道刚做了什么、接下来该点哪儿。

但当模型参与执行时，如果没有清晰的任务上下文，它每一轮都像刚进门一样。于是就会出现一种很常见的 AI 失控现场：

前面说过的事它忘了，做过的事它重复做，没做完的事它以为已经做完了。

很多所谓 “Agent 不稳定”，本质就是任务上下文没设计好。

图片来自网络，侵删

3. 环境上下文

这层讲的是：

模型可以用哪些工具
能访问哪些文件
可以调用哪些 API
权限边界在哪里

这一层特别重要，因为它直接决定 AI 是“会说”，还是“会干”。比如它能不能读文件？能不能查数据库？能不能打开浏览器？能不能调用业务接口？能不能写回系统？

这不是技术细节，这是产品结构。因为一旦环境上下文不清晰，AI 不是能力不足，而是会变得要么束手束脚，要么乱用权限。

我越来越觉得，像文件系统、工具链、MCP 这类东西，本质都不是“高级技术点”，而是在给模型补全执行环境。

AI 从“对话工具”变成“现实执行者”，靠的不是一句 prompt，而是这层环境上下文。

4. 记忆上下文

这层也被很多人神化了。记忆不是“让 AI 什么都记住”，而是要区分：

什么是长期偏好
什么是历史决策
什么是当前项目状态
什么是这轮任务的临时信息

如果不分层，最后一定会变成垃圾场。今天很多产品都在讲 memory，但很多做法其实很粗暴：只要用户说过，就想办法存进去；只要模型可能用得到，就一股脑塞进去。这不叫记忆设计，这叫囤积。

真正有效的记忆，不是越多越好，而是越准越好。它应该帮助模型少走弯路、少犯重复错误、少让用户重新解释自己，而不是制造更多噪音。

5. review 上下文

这是我觉得现在很多 AI 产品最缺的一层。review 不是“AI 做完了人再看一眼”。review 应该是整个系统在设计之初就明确好的：

哪些步骤可以自动执行
哪些步骤必须人工确认
出现什么信号必须停下来
哪些错误可以自动重试
哪些问题必须升级给人

这层如果不设计，自动化越强，出事越快。很多人把 AI 产品做成了一个“高速黑箱”：能跑，很快，很炫，但你根本不知道它下一步会干嘛，也不知道哪里该插手。这不是智能，这是不可控。

真正靠谱的 AI 系统，不是没有人工参与，而是把人工干预点设计得足够清楚。

四

说到这里，你会发现一个很有意思的变化：

过去产品设计更像是在设计“界面”；现在 AI 产品越来越像是在设计“执行结构”。

以前你思考的是：

页面入口怎么排
一个按钮放左边还是右边
信息先显示哪个后显示哪个

现在你思考的是：

用户怎么表达目标
系统怎么理解任务
模型该拿到哪些上下文
哪些工具可以调用
哪些步骤要停下来 review
出错之后怎么回滚或纠偏

页面当然还重要，但它不再是全部了。未来 AI 产品的 UX，不只是界面体验，而是目标、上下文、记忆、工具、review 机制共同组成的执行体验。

这才是我觉得变化最大的地方。

五

我自己这段时间最明显的一个变化，就是看产品的视角变了。

以前做设计时，我会天然去看：

结构清不清楚
页面顺不顺
信息有没有层次
交互是不是自然

现在看一个 AI 产品，我会先问另外一些问题：

用户目标是怎么被表达的？
模型拿到的上下文是怎么组织的？
它怎么知道现在做到哪一步？
它用了哪些工具？权限边界清楚吗？
中途哪里能让人 review？
它记忆是怎么更新、怎么清理的？
一旦结果跑偏，用户有没有办法及时拉回来？

你会发现，这些问题其实比“界面好不好看”更先决定结果。因为 AI 产品最怕的，不是丑，而是失控。

你界面做得再漂亮，如果模型总是理解错目标、拿错上下文、在错误方向上越跑越远，那体验一样烂。反过来，一个界面不算惊艳、但上下文组织得非常清楚的系统，往往会让人觉得“这玩意儿真能干活”。

六

再往深一点看，这种变化其实还意味着：设计师要开始重新理解自己的工作对象了。

以前我们的工作对象主要是“用户操作界面”；

现在很多时候，我们的工作对象其实是“模型执行环境”。

我们设计的，不只是用户看到什么，还包括模型看到什么。我们设计的，不只是用户点哪里，还包括模型在什么时候应该做什么、停什么、问什么。

我们设计的，不只是信息如何展示，还包括上下文如何被压缩、组织、提取和接力。

这也是为什么我越来越觉得，AI 时代的产品设计，某种程度上正在靠近“系统设计”。

不是让设计师去写底层代码，而是要真正理解：

结果不是只靠页面长出来的，结果是从一整套上下文和执行结构里长出来的。

图片来自网络，侵删

七

当然，信息架构不会消失。

别又一激动就把旧东西全推翻了，那是另一种蠢。

页面依然重要，交互依然重要，结构依然重要。

只是 AI 产品把一个以前没那么显眼的层，推到了台前：上下文设计。

以后谁能把目标、上下文、记忆、工具、review 这几件事设计明白，谁才能真正做出稳定、可用、可信的 AI 产品。

说到底，AI 产品最难的，可能从来不是“让模型说得更像人”，而是“让系统在真实任务里，持续地不犯蠢”。

而这件事，靠的不是更华丽的界面，而是更清楚的上下文架构。如果要把我今天想说的压成一句话，那就是：

AI 时代，产品设计的主战场，正在从页面，转向上下文。