乐于分享
好东西不私藏

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

你还在设计页面?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 时代,产品设计的主战场,正在从页面,转向上下文。