先想清楚：对话框解决了什么，没解决什么
对话框（Chat 范式）的伟大之处在于零学习成本和无限表达空间，ChatGPT 靠它把 AI 带给了所有人。但它的短板同样明显：用户得自己把需求翻译成 prompt——「想让 AI 干活，先学会说话」，这本身就是门槛；输出是一大坨文本，看完还要手动搬运到真正干活的地方；对话是线性的，改方案、比版本、并行探索都很别扭。所以真实的留存数据往往不好看：大量用户聊三轮就不知道还能问什么了。对话框是好的「能力演示器」，但对大多数具体任务，它不是效率最高的形态。
范式一：嵌入式 AI，能力长在原来的工作流里
用户在哪干活，AI 就出在哪，输入输出都是现成的，不需要用户描述需求。Notion AI 在文档里选中一段文字直接「润色/扩写/翻译」，Copilot 在 IDE 里边写边补全，飞书的智能纪要开在会议里。这类设计的要点是 AI 不抢入口，作为既有操作的自然延伸，触发成本几乎为零。我的判断是：对存量产品做 AI 化改造，嵌入式几乎是首选——用户习惯不用迁移，价值立竿见影。它的天花板是只能优化已有流程，创造不出新流程。
范式二：生成式 UI，输出不再是文本
模型输出的不该只是文字，而应该是界面本身。你问天气，传统对话框回你一段文字，AI Native 的做法是直接渲染一张可交互的天气卡片；你说「帮我规划东京五日游」，出来的不是两千字攻略，而是可拖拽调整的行程表。Gemini 在试生成式界面，很多旅行、数据分析类 AI 产品也在走这条路。核心思想是「文本是模型的母语，不是用户的母语」——结构化任务就该给结构化界面，对话只负责收集意图，界面负责承载结果。这个范式对前端工程和流式渲染的要求高不少，但体验是代际差。工程上有个坑要提：模型流式输出的是半成品结构化数据，界面得能边收边渲染、收错了能降级回纯文本，否则一次解析失败就是白屏。做这类产品，「界面渲染的容错」和「模型输出的稳定格式」要写进需求文档，不能甩给研发自由发挥。
范式三：Agent 委托，从「问答」到「交活」
Chat 是一问一答，Agent 模式是用户说目标，AI 自己拆步骤、调工具、跑流程，中间给你看进度，最后交付结果。Manus 的走红、Devin 的演示、各家出的「深度研究」（Deep Research）都是这个路子。这个范式的设计难点不在技术而在信任：用户敢不敢把一件要跑十分钟、花掉不少 token、还可能跑偏的活交出去。所以 Agent 产品的必修课是过程可见（它在干什么、干到哪一步）、中途可干预（能喊停、能纠偏）、结果可验收（交付物附带它做了什么）。一上来就做「全自动黑盒」的，基本都死在信任关上。靠谱的路径是从「人走一步、AI 走一步」的协作模式起步，信任攒够了再放开自动化程度。Cursor 从补全到 Composer 到 Agent 模式的演进，就是这个节奏。
范式四：环境式智能，没有交互的交互
最高级的 AI 是用户感知不到它的存在：垃圾邮件过滤、相册自动分类、输入法预测、风控系统默默拦掉欺诈交易。AI 完全退到后台，只在其判断需要人类介入时才浮现。这类范式对准确率的要求最苛刻——用户没参与过程，错了就是事故，所以通常只适用于「错了代价低、对了省大事」或者纯后台的场景。
怎么选：看任务结构化和容错率
我的选型框架就两条轴。任务结构化程度：越结构化（填表、修图、写代码），越适合嵌入式和生成式 UI；越开放（探索、咨询、创作），对话和 Agent 更合适。容错率：错得起（写文案初稿）可以放心自动化，错不起（转账、发邮件给老板）必须留人工确认环节。还有一句实话：别为了显得 AI Native 而 AI Native，很多场景一个搜索框加一个好用的列表页，比一个会聊天的对话框有用十倍。