AI 做界面时，最迷惑人的地方是：它经常看起来已经做完了。

按钮有了，表格有了，侧栏有了，弹窗也有了。第一眼扫过去，像一个完整产品；真正点起来，才发现很多东西只是“摆在那里”。

一个筛选图标看起来能点，点了却没有筛选面板。

一个“添加任务”按钮能加一行，却没有完成、删除、撤销。

一个成员资料卡能编辑姓名，却没有保存状态，也不知道是否真的改成功。

一个文件夹被选中了，右侧预览变了，左侧却看不出当前选中的是哪个文件夹。

这些问题表面上像交互 bug。

但我后来发现，它们其实暴露的是同一个问题：AI 没有真正理解页面里的对象。

更准确地说，它没有区分两类对象：

设计对象，以及操作对象。

这两个词不一定是行业里的固定叫法，但它们非常适合描述人和 AI 协作时最容易丢失的那层产品直觉。

设计对象：用户手里拿来操作的东西

设计对象，是页面上用户能看见、理解、点击、编辑、选择、展开或关闭的东西。

按钮是设计对象。图标是设计对象。表格行、输入框、标签、左侧导航、详情面板、弹窗、空状态、错误提示，也都可以是设计对象。

但一个东西成为设计对象，不是因为它“长得像组件”。

它必须回答几个问题：

它是什么？

用户为什么会注意到它？

它能不能操作？

默认、悬停、选中、禁用、加载、错误时分别是什么状态？

触发后谁会变化？

成功、失败、撤销或完成后，反馈在哪里出现？

如果这些问题没有答案，它就只是一个视觉元素，不是一个合格的设计对象。

这就是为什么很多 AI 生成界面看起来完整，却一用就散。

AI 很擅长把“这里应该有一个按钮”翻译成一个按钮。

但它不一定会继续追问：这个按钮是不是应该存在？它和旁边那个入口是不是同质？如果它点了没反应，是应该补功能，还是应该删除？

一个有经验的产品经理或设计师看到这种东西，会很自然地警觉：这不是一个“还没接功能”的按钮，这可能是一个不该存在的设计对象。

但 AI 不会天然知道这个默认判断。

除非我们把它说出来。

操作对象：真正被改变的东西

操作对象，是被设计对象操作的业务对象。

用户点按钮，不是为了点按钮本身。用户编辑输入框，也不是为了改变输入框本身。

按钮、输入框、菜单、弹窗这些设计对象，最终都指向某个被操作的东西：一条任务、一个联系人、一个文件、一条订单、一篇文档、一个配置项。

这些才是操作对象。

操作对象最重要的不是“出现在页面上”，而是它有没有生命周期。

如果可以新增它，就要问：

能不能命名？

能不能校验？

能不能删除？

能不能撤销？

能不能排序？

能不能保存？

保存前能不能预览变更？

提交后有没有回执？

失败时能不能知道原因？

这就是很多 AI 界面最容易漏掉的地方。

它会做出“添加任务”按钮，但不会自然补上完成、删除或恢复。

它会让你改联系人姓名，但不会告诉你这次修改是已保存、未保存，还是保存失败。

它会显示一个文件夹列表，但不会让当前选中的文件夹有足够清楚的激活态。

它会做一个“提交”按钮，却没有把本次新增、修改、删除的内容汇总给用户确认。

它不是不会写代码。

它是没有被迫沿着操作对象的生命周期继续推理。

一个简单例子：为什么“添加任务”不是一个按钮问题

假设一个任务管理工具里有一个“添加任务”的按钮。

普通的组件视角会这样看：

这里需要一个按钮，点击后出现一条新任务。

但对象视角会继续问：

这个按钮是设计对象，它触发的操作对象是什么？

答案是一条任务。

既然操作对象是任务，那就不能只问“能不能新增”。还要问：任务标题能不能为空？能不能设置负责人和截止时间？新增后是立即保存，还是进入未保存状态？用户能不能取消？能不能删除？能不能标记完成？如果保存失败，错误提示在哪里出现？

如果这些都没有，界面就不是“添加任务功能已完成”，而只是“页面上出现了一条新任务”。

这两者差别很大。

前者是产品功能，后者只是静态组件。

再比如，一个成员资料卡右上角有一个铅笔图标。

如果资料卡里的姓名、职位、邮箱本来就可以直接点击编辑，那么这个铅笔图标就要被审查：

它作为设计对象是否有必要？

如果有必要，它触发的是整张资料卡进入编辑模式，还是只编辑某一个字段？

如果没有必要，为什么还要留下来让用户误以为可以点击？

这时最好的修复，可能不是给它硬补一个动作，而是删掉它。

设计不是“每个看起来能点的东西都要接功能”。设计是判断：这个对象是否应该存在，它操作的对象是否真实，它和其他对象是否同质，整条操作链是否闭合。

人和 AI 协作，真正要显化的是默认判断

这件事让我重新理解了人在 AI 设计协作里的价值。

人不一定比 AI 更会枚举所有组件，也不一定比 AI 更会生成漂亮页面。

人的关键作用，是把自己脑子里那些默认判断显化出来。

很多产品经理和设计师看界面时，会本能地做这些判断：

这个东西看起来能点，就应该真的能触发。

如果它不能触发，就应该说明原因，或降级成不可操作状态。

如果多个入口都在操作同一个东西，它们的状态应该一致。

如果一个对象能被新增，就要考虑完成、删除、排序、撤销、保存。

如果右侧预览变了，左侧必须让用户知道当前是谁被选中。

如果一个功能暂时不做，界面不能伪装成已经可用。

这些判断对人来说太自然了，所以我们很少专门写出来。

但 AI 不会稳定继承这种“自然”。

它会把需求、截图、历史讨论、工程说明和审查报告都看成材料，然后尽可能拼出一个完整界面。除非我们明确告诉它：先不要急着摆组件，先把设计对象和操作对象找出来。

这个转变很关键。

过去我们可能会对 AI 说：帮我审查这个页面交互是否完整。

现在我更愿意这样说：

请逐一盘点页面上的可见元素，判断它是不是设计对象；如果是，它操作的操作对象是什么；是否和其他设计对象同质；它的默认、选中、禁用、错误和完成状态是否成立；它触发后，操作对象的生命周期是否闭合。

这句话看起来更啰嗦，但它会把 AI 从“看页面像不像”拉到“推理对象是否成立”。

让 agent 变强，不是给它更多审美词

很多时候，我们想提升 AI 的设计能力，会继续给它补设计原则。

信息层级、渐进披露、可访问性、视觉一致性、反馈闭环、认知负担。

这些当然重要。

但如果只停在原则层，AI 很容易复述原则，却不知道在某个具体界面上该怎么落地。

真正有效的提升，是把原则压到对象层：

不要只说“交互要完整”，而要问这个设计对象触发后改变哪个操作对象。

不要只说“状态要清楚”，而要问选中态、激活态、焦点态、禁用态分别属于谁。

不要只说“闭环要完整”，而要问这个操作对象有没有新增、校验、删除、撤销、保存、提交。

不要只说“信息要分层”，而要问反馈、原因、证据、历史分别由哪个对象承载。

一旦这样要求，agent 的工作产物也会变化。

它不应该只交一张截图，或者一份“我已经优化了交互”的报告。

更好的产物应该是：

设计对象清单

：页面上哪些东西是真正可操作对象，哪些只是展示或装饰。

操作对象地图

：每个设计对象最终改变的是哪类业务对象。

生命周期检查

：新增、选择、编辑、校验、删除、排序、保存、提交、恢复是否闭合。

同质对象合并判断

：功能重复的按钮、入口、状态是否应该合并或删除。

修复队列

：哪些是假交互，哪些是缺状态，哪些是操作对象生命周期缺口。

验证证据

：真实浏览器里点过哪些对象，哪些状态变化被证明了，哪些仍然是未来能力。

这才是在提升 agent 的设计方法论水平。

不是让它背更多设计术语，而是让它用产品经理和设计师的对象化思维去工作。

最后，界面不是组件集合，而是操作系统

我现在越来越觉得，复杂产品界面不是一堆组件的组合，而是一套小型操作系统。

设计对象是用户手上的控制器。

操作对象是系统里被创建、选择、修改、删除和提交的东西。

状态、反馈、确认、撤销、历史，是它们之间的运行规则。

AI 做界面最容易停在“组件都在了”。

但产品真正成立，要继续问：

这个对象为什么存在？

它操作谁？

操作之后谁变化？

变化后怎么反馈？

如果能新增，为什么不能删除？

如果不能做，为什么看起来像能做？

这些问题一旦被显化，AI 的输出会立刻变得更收敛。

它不再只是把页面补满，而是开始沿着对象关系修界面。

这也是我想用 AI 做设计时最重要的经验：

不要先问 AI 能不能画得更好看。先问它：这个界面里，哪些是设计对象，哪些是操作对象？

只要这一步没想清楚，再漂亮的页面也只是静态稿。

一旦这一步想清楚，AI 才真正开始进入产品设计。