深夜的对话框：一个产品经理的觉醒

第 1 章：深夜的对话框：一个产品经理的觉醒

凌晨一点十七分，陈牧把第 47 杯咖啡推到桌角，盯着飞书文档里那行被批注了二十多次的需求："我们必须在 Q3 前把 AI 加进去。"他在这家 SaaS 公司做了六年产品经理，从 0 到 1 搭建过客服系统、审批流和看板组件，但他从未像此刻这样感到一种深切的失语。不是因为他不懂 AI，恰恰相反——他读过 Attention Is All You Need 的原始论文，跑过开源模型，写过 Prompt，甚至在内部技术分享上讲过 RAG 的工程实现。他失语，是因为他清楚地知道：CEO 想要的"加 AI"，和他理解的"AI"，根本不是同一个东西。

三个月后，他在公司内部的产品评审会上，被一位入职不到半年的算法工程师当众问了一句："陈哥，你这个方案，是不是就是套壳？"会议室安静了大约两秒钟。他没有立刻回答。他在心里默默地把那个方案又过了一遍：一个浮窗按钮，点了之后弹出对话窗口，把用户当前页面的字段塞进 Prompt，调用 GPT-4 接口，再把回答塞回原页面的某个文本框。逻辑上完美，工程上可实现，评审表上能打勾。但"套壳"两个字像一根针，精准地戳中了他这两个月来隐隐作痛却不敢正视的那个位置。

这一章会沿着陈牧的这次"觉醒"展开。你会看到一种在 2023 年到 2024 年间，几乎所有传统 SaaS 团队都踩过的坑；你也会看到，当大模型真正成为一种"基础设施"时，产品设计的语言、评判标准和组织心智，都不得不发生一次根本性的迁移。我们会拆解"AI 赋能"和"AI 原生"的本质差异，引出贯穿全书的六大命题，并在最后回到陈牧那块被写下三个词的白板上——Copilot、Agent、对话。

---

一、一个真实故事：三个月，从"加个对话框"到推倒重来

让我们把时间拨回 2023 年 4 月。陈牧所在的公司做的是一款面向中型制造企业的 ERP 系统，账面客户 1200 家，年营收过亿。CEO 是在一场行业论坛上被同行"刺激"回来的——对面那家规模只有他们一半的友商，已经在每场客户拜访里演示一个能"用自然语言生成报表"的功能。"我们再不动，就不是落后的问题，是出局的问题。"这是 CEO 回公司后第一句话。

陈牧领到的任务被写在一张 A4 纸上：六月底之前，让产品的核心模块"看起来像 AI"。

"看起来像 AI"。这五个字决定了接下来三个月的走向。

1.1 第一阶段：寻找"最小可用"的接入点

陈牧做的第一件事，是把产品里所有高频操作列出来。他画了一张表，左边是功能，右边是"AI 可以怎么润色一下"。结果令他沮丧——表中能填的格子不到三分之一。

客户管理模块：可以在新建客户时，让 AI 帮写一段跟进话术。 订单模块：可以在录入订单后，让 AI 帮生成一条备注。 报表模块：可以让 AI 解释某条数据的异常。

每一条单看都"合理"，每一条都让他觉得哪里不对。直到他把这个方案拿给两位资深销售看，其中一位四十多岁的老员工说了句让他愣住的话："陈哥，这不是 AI，这是把 GPT 装进一个按钮里。客户又不是傻子，他点开一个写着'AI 助手'的按钮，里面吐出来的东西如果和他自己用 ChatGPT 搜出来的一模一样，他凭什么要在你这里点？"

这句话是第一个警报。

1.2 第二阶段：上线"对话框"，以及随之而来的嘲讽

尽管疑虑重重，陈牧的团队还是在五月底上线了第一版。形态非常标准：右下角悬浮一个圆形按钮，点击展开一个对话框，标题叫"AI 助手"。它能做三件事——问答、润色、翻译。对话框背后接的是 OpenAI 的 API，前端用 React 写，Prompt 模板由陈牧和算法团队一起调了十几版。

上线当周，公司在客户群里发了一条公告："重磅更新！XX ERP 接入 AI 大模型，开启智能办公新时代。"

回应是冷淡的。不是没人用——从埋点数据看，前三天大约有 8% 的活跃用户点开了那个按钮——而是用户在用完之后，普遍没有任何后续动作。既没有复访，也没有差评，沉默地消失在产品里。

真正让陈牧难受的，是内部的声音。在一次跨部门的产品同步会上，一位后端工程师在白板上画了一个大方块，里面塞了一个小方块，旁边写了一行字："套壳。" 整个会议室笑了。陈牧也笑了。他笑完之后，独自回到工位，把那段代码又看了两遍，然后承认：那确实是套壳。

套壳并不是技术上的侮辱，它描述的是一种结构性的懒惰：产品的主体形态仍然是传统 SaaS（按钮、表单、菜单、列表），AI 只是被"嵌入"在某一个边缘位置，作为一个可被跳过的辅助功能存在。这就像在一辆马车的前面装一台电动机，仍然叫它"新能源汽车"——技术上也许没撒谎，但产品逻辑和用户体验，和真正的电动车完全是两回事。

1.3 第三阶段：推倒重来的那个下午

转折发生在六月中旬。CEO 拉陈牧和 CTO 开了一个闭门会，会上没有任何寒暄，CEO 把一份客户流失分析报告甩在桌上："上个月走了 17 家客户，其中 9 家的反馈里都提到了'竞品有 AI，我们没有'。但是，陈牧，我想问你一个你可能不喜欢听的问题——如果我们的 AI 真的就只是一个对话框，我们就算加上了，能挡得住这 9 家吗？"

陈牧沉默了很久。那是他做产品经理六年来第一次被问到一个无法用"做"来回答的问题。

一周后，他做了一个让所有人不解的决定：把已经开发完成的"AI 助手"对话框从产品里撤掉，把相关排期清空，重新立项。他给项目取了一个新名字：Atlas——不是取自古希腊神话里扛天的那个人，而是他当时在用的一个开源向量数据库的名字，意思是"为 AI 重写的产品基座"。

新项目的核心命题只有一句话：让 AI 不再是一个"功能"，而成为产品的工作方式。这个命题，后来被他写在白板上，又演化成整本书将要回答的六个问题。

---

二、为什么"传统 App + AI 插件"不是 AI 原生产品

陈牧的觉醒之所以值得拆解，是因为他踩中的，几乎是所有传统软件团队在 AI 时代第一个、也是最普遍的认知陷阱：把"接入 AI"等同于"成为 AI 产品"。这一节我们要把这个陷阱打开，看看它由几层错位构成。

2.1 一个判断标准：AI 是"配角"还是"主语"

判断一个产品是不是 AI 原生，可以先问一个非常朴素的问题：在这个产品里，AI 是"被调用的功能"，还是"驱动系统运转的主体"？

在传统 App + AI 插件的形态里，AI 是被调用的功能。产品的主循环仍然是用户操作 UI（点按钮、填表单、选菜单），AI 只是循环中的一个可选环节。系统的状态机由 UI 驱动，AI 只是其中一个被叫醒一次的函数。

而在 AI 原生产品里，AI 是驱动系统运转的主体之一。系统的状态机由模型推理和用户输入共同推进，UI 不再是用户必经的唯一通道，而可能是模型推理结果的一种呈现形式。

这个区别听起来抽象，我们用一个具体例子说明。

场景 A（AI 插件形态）：用户要生成一份周报。他需要先点开"周报"菜单，再点"新建周报"，进入表单页面，填写本周工作内容（这是必填项，因为没有内容，AI 没有原材料），然后点击"AI 润色"按钮，AI 才介入。

场景 B（AI 原生形态）：用户只需要对系统说一句话或者丢进去一段散乱的会议纪要，AI 主动询问关键缺失信息（"你这周和客户 A 谈的那个项目，有结论吗？"），自动拉取相关数据（从日历、IM、CRM 中获取本周客户拜访记录），生成周报草稿，主动推送给主管审阅，主管在 AI 生成的草稿上批注，AI 再根据批注迭代。

两者的核心差异不是"有没有用 AI"，而是用户的工作流是从 UI 出发的，还是从"目标"出发的。在 A 形态里，用户仍然在使用一套"AI 增强版的旧工作流"；在 B 形态里，工作流本身被重写，AI 是新的工作流引擎。

2.2 三层错位：架构、心智、关系

"传统 App + AI 插件"之所以失败，不是因为它技术上做不到，而是因为它在三个层面同时发生了错位。

第一层：架构错位。 传统 App 的架构假设是确定性的：用户每一次操作都对应一段预先写好的代码路径，系统的状态是离散的、可枚举的。AI 的引入要求架构必须能处理"非确定性"——同一个输入，模型可能给出不同的合理输出；同一个任务，模型可能选择不同的执行路径。这意味着数据库 schema、状态管理、错误处理、日志追踪、测试用例，几乎所有传统软件工程的最佳实践都要被重新检视。

很多团队会下意识地把这层错位隐藏掉：用"AI 输出的内容再过一遍规则校验"的方式，把模型行为强行约束回确定性的边界。这在很多场景下是必要的，但如果你只用这种方式做 AI 产品，那你其实在做的是"用 AI 装饰的规则系统"，模型的能力被严重低估。

第二层：心智错位。 这层错位最隐蔽，也最致命。团队成员（包括产品经理、设计师、工程师）的心智模型，仍然是"我做的是一个传统软件，AI 是一个新功能"。这种心智会反映在无数细节上：PRD 仍然以"页面"为单位组织，交互稿仍然以"按钮"和"弹窗"为基本元素，测试用例仍然以"输入 X，输出 Y"为基本假设。

陈牧在反思时说过一句很到位的话："我们不是在做 AI 产品，我们是在用做 ERP 的方式做一个 AI 功能。" 这句话精确地刻画了心智错位：方法论和目标对象之间存在错配。

第三层：关系错位。 传统软件和用户之间是"工具-使用者"的关系：软件是被动响应的，用户是主动操作的。但 AI 产品的本质，是用户和模型之间形成一种协作关系。模型有判断、有偏好、有"性格"，它会影响最终的输出。这要求我们重新设计"谁有权决定结果"的边界——是用户完全主导，AI 只是执行？还是 AI 主导，用户只是确认？还是两者共同协商？

这三层错位叠加起来，决定了一个看似简单的判断："加个对话框"和"AI 原生"，是两种不同的产品哲学。 前者把 AI 视为一种"新材料"——就像不锈钢之于传统厨具，后者把 AI 视为一种"新的烹饪逻辑"——AI 改变了用户和系统之间关系的根本结构。

2.3 一个有用的对比表

为了让你在团队评审时能直接使用，我整理了一个判断清单。任何一个产品形态，你都可以用它快速自检。

| 判断维度 | AI 插件形态 | AI 原生形态 | | --- | --- | --- | | 用户入口 | UI 操作（按钮、表单、菜单） | 目标驱动（自然语言、语音、上下文触发） | | AI 在状态机中的位置 | 一个被调用的函数 | 工作流的引擎之一 | | 系统响应方式 | 确定性的代码路径 | 模型推理 + 不确定性管理 | | UI 的角色 | 用户必经的通道 | 模型结果的呈现层之一 | | 失败模式 | 报错、回退、给默认值 | 模型输出不达预期时的多策略协商 | | 衡量成功的指标 | 功能渗透率、点击率 | 任务完成率、用户信任度、关系深度 | | 团队的核心能力 | 软件工程 | 提示工程、模型评估、对话设计、人类反馈 |

这张表不是真理，但它可以作为一个非常实用的"翻译器"——当你的团队在争论"要不要用 AI"时，把这个表翻出来，往往能让讨论从"做不做"变成"做到哪一层"。

---

三、本书要回答的六个命题

陈牧在推倒重来之前的那一周，在白板上画了一张图。图的正中央写着"AI 原生产品"五个字，周围有六条线，连向六个关键词。三个月后，那张白板上的内容，被他整理成了这份书的骨架。这六个命题，也是我希望你在接下来十几万字的阅读中，始终留在脑子里的六个坐标。

3.1 命题一：交互——当"对话框"成为新的"操作系统"

GUI（图形用户界面）统治了软件四十多年。它的基本单位是"控件"：按钮、文本框、下拉菜单、滑块、标签页。这套语言之所以成功，是因为它把人类的意图映射成了机器可以精确执行的指令序列。你点"保存"，就是保存；你选"深圳"，就是深圳。

但自然语言交互的崛起，颠覆了这个前提。当用户可以用一句话告诉系统"帮我把这周的客户回访整理成表格，重点标出还没付款的"，他不再需要知道"表格"在菜单的哪个位置、"筛选"在哪个面板下。意图的表达和意图的执行，第一次在同一个通道里完成。

这就引出一个核心问题：当交互语言从"操作"变成"表达"，产品的界面应该长什么样？ 是全盘对话化（用一个对话框替代所有 UI）？还是混合式（保留关键 UI，让对话作为补充）？还是某种我们还没有见过的新形态？

我们会在第四章到第六章专门讨论这个问题。但这一章只需要你记住一件事："加个对话框"不是交互革命的终点，而是起点。真正的挑战，是重新设计一整套让用户"表达意图"和让系统"反馈结果"的语言。

3.2 命题二：信任——如何让用户相信 AI 的输出

陈牧在 Atlas 项目里遇到的最大阻力，不是技术，而是用户的不信任。一位用了他们 ERP 八年的老客户——某机械厂的生产主管老张——在试用完 AI 周报功能后说了一句话："它写的字都对，但我不知道它是从哪里来的。"

这句话点出了 AI 产品的第二大命题：信任的建立方式，和传统软件完全不同。

传统软件的可信度，靠的是"确定性"：你点保存，文件就一定存了；你算合计，数字就一定对。AI 产品的可信度，靠的是"可解释性"：AI 的结论从何而来，依据是什么，置信度有多高，如果错了如何纠正。

在 AI 原生产品中，信任不是 UI 上的一个细节，而是产品的核心架构问题。你必须从第一天起就设计：模型的不确定性如何向用户暴露？模型犯错了，用户如何"教"它修正？模型之间的差异（如调用 GPT-4 还是 Claude-3）如何对用户透明？这一系列问题，是第八章的核心内容。

3.3 命题三：自主——Agent 究竟应该有多"主动"

2024 年初，"Agent" 这个词突然爆火。AutoGPT、Devin、各种智能体框架层出不穷。喧嚣过后，行业沉淀下来一个冷静的问题：Agent 应该有自主权吗？自主到什么程度？

陈牧在 Atlas 项目早期犯过一个错：他让 AI 自主决定"何时该给主管推送周报草稿"。结果，AI 几乎每天都会推送，因为它"判断"任何进展都值得汇报。主管的飞书被刷屏，开始绕过 AI 直接看日历。这是一个典型的"自主权过度"案例。

在第七章，我们会系统讨论 Agent 的自主性光谱：从"完全由用户触发"，到"在用户授权下自主执行"，到"在目标下自主规划和执行"，再到"完全自主"。不同的产品场景，应该选择不同的自主性等级。这不是技术问题，是产品设计问题。

3.4 命题四：上下文——AI 真的"知道"你的产品吗

很多团队在接入大模型 API 时，会下意识地以为"模型什么都知道"。但真正做过产品的人都知道，模型对你的产品一无所知。它不知道你的客户叫什么名字，不知道订单的状态，不知道昨天刚上线的功能，不知道老板今天心情好不好。

"上下文工程"（Context Engineering）正在取代"提示工程"（Prompt Engineering），成为 AI 产品团队的核心能力。第九章会专门讨论：上下文从哪里来？如何在产品中持续积累？如何让上下文既丰富又安全？如何处理上下文过载？这些都是 AI 原生产品必须正面回答的问题。

3.5 命题五：协作——多 Agent 与人机协同的新范式

单个 Agent 的能力终归有限。当任务复杂到一定程度，必然需要多个 Agent 协作——这和传统软件从"单进程"演化到"微服务"，是同一种逻辑。

但多 Agent 协作远比微服务复杂：每个 Agent 都是非确定性的，Agent 之间的对话可能出现误解、冲突、循环。人类在这个协作网络中的角色又是什么？是"指挥家"，是"客户"，还是"裁判"？

第十一章会系统讨论多 Agent 系统的设计模式：层级式、市场式、辩论式、反思式。这不是科幻，这是 2025 年开始每一个 AI 产品团队都要面对的工程现实。

3.6 命题六：记忆——AI 产品的"用户档案"如何重写

传统 SaaS 的"用户档案"是一张表：用户 ID、姓名、邮箱、注册时间、最后登录时间。这张表是被动记录的——只有用户做了某件事，系统才记录。

但 AI 产品需要一种主动建构的记忆：模型需要在多次交互中持续理解这个用户——他的偏好、他的工作模式、他常犯的错误、他的特殊场景。这不是简单的"对话历史存储"，而是一种动态的用户认知模型。

记忆的设计会直接影响前面五个命题的答案：没有记忆，交互就是断裂的；没有记忆，信任就难以建立；没有记忆，自主性就无从发挥。第十二章会专门讨论 AI 产品中的记忆系统。

---

四、产品设计语言的代际更替

回到陈牧的觉醒。他从"加个对话框"到"推倒重来"，背后其实是一次设计语言的整体迁移。这一节我们把这次迁移的历史脉络梳理清楚，让你看到 AI 原生产品为什么不是"传统产品 + 一个新功能"，而是一种新的设计范式。

4.1 软件交互的三次代际更替

命令行时代（1960s–1980s）：交互的基本单位是"命令"。用户需要记住一整套语法。学习的门槛极高，但表达力极强。代表产品是 Unix、MS-DOS。

GUI 时代（1980s–2020s）：交互的基本单位是"控件"。用户通过点击、拖拽完成操作。门槛大幅降低，表达力也被牺牲——GUI 鼓励用户走"预设路径"，而不是表达任意意图。代表产品是 Windows、Mac、Web、移动 App。

自然语言时代（2020s–）：交互的基本单位是"意图"。用户用自然语言（口语、文字、语音、图像）表达目标，模型把意图翻译成可执行的动作。门槛继续降低，表达力却重新上升——你可以让系统做任何你能用语言描述的事情。

每一次代际更替，都不是"在上一代的基础上加个新功能"，而是底层交互逻辑的整体替换。GUI 没有消灭命令行，命令行至今仍是程序员的工具；自然语言也不会消灭 GUI，GUI 在很多场景下仍然更高效。但产品设计的主导语言会发生转移。

4.2 传统 UI 词汇在 AI 时代的三种命运

在 AI 原生产品中，传统 UI 词汇会面临三种命运：

第一种：保留并强化。有些 UI 元素因为其清晰性，会继续存在并变得更重要。比如"确认按钮"——在 AI 时代，用户必须能够明确"批准"或"拒绝"模型的输出，这种显式的用户主权反而被强化了。

第二种：被新的元素替代。比如"菜单"——在传统 UI 中，菜单是用户发现功能的主要途径；在 AI 原生产品中，用户通过对话表达意图，菜单可能退化为"提示词建议"或"快捷指令面板"，而不是主要入口。

第三种：被重新定义。比如"表单"——传统表单是用户填写信息的界面；在 AI 时代，表单可能变成"模型提问，用户回答"的结构化对话。这不是把表单变成对话框，而是**把表单拆解成模