一

很多年前，我第一次接触ERP系统，那是Oracle的EBS。第一次登录的感觉，我到现在还记得：蒙了。

整个系统有几千个各式各样的界面，每个界面上密密麻麻地排着几十个字段，菜单一层套一层，像迷宫一样。想生成一张报表，要先记住它在哪个菜单的哪个子菜单的哪个功能项里，中间还要经过好几步参数设置，少一步就出不来。想改一个客户的主数据，先要知道这个操作在哪个模块里——我猜很多人和我一样，第一次进去光找入口就找了半天。

最夸张的是，用这个系统，居然要先参加三天的培训，培训通过了，才允许上岗操作。

一个给企业用的软件，门槛高到要培训、要考试、要持证上岗——在今天听起来像天方夜谭，但在那个年代，这是常态。那时候我们管这叫"专业性"，觉得这是系统强大的证明：你看，这系统功能多全，全到一般人学不会。

现在回头看，那句话的真正意思是：这套系统承载了极为复杂的业务逻辑，但是没有用户体验。 使用ERP系统，竟然成了"专业人士"才能做的事情——这不是系统的荣耀，是系统的失败。

但更值得琢磨的是另一个问题：为什么它这么难用？

菜单是迷宫，是因为操作太多了。几千个界面，是因为业务动作太多了——采购、库存、生产、销售、财务、人事，每个领域几十上百种动作，每一种动作都要有一个预先设计好的界面来承接。字段密密麻麻，是因为每种动作要交代的信息太多了——一张采购订单，供应商、物料、数量、单价、交期、付款条件、收货地址、审批链，哪个都不能少。

你发现没有：那个时代的界面，本质上是一个"意图的容器"。 用户通过界面告诉系统"我想干什么"——我在这个菜单里选了"创建采购订单"，系统就知道我要采购；我在这个表单里填了字段，系统就知道我这次采购的具体内容。界面复杂，是因为意图复杂；而当时的软件，只能用一种笨办法来容纳意图——穷举。

机器听不懂人话，这是那个时代一切复杂性的根源。它听不懂"我想买一批物料，供应商是老张，下个月要"，它只能听懂"你在采购订单界面里，把这个字段填上，那个字段选上，然后点保存"。所以系统必须把"所有可能的意图"预先穷举成界面、菜单、字段——用户的操作，就是在这个穷举出来的迷宫里，一格一格地走。

我把这个时代叫**"意图的迷宫"**。系统把企业所有的意图都锁进了一栋巨大的建筑里，用户要做的事，是拿着地图（那三天的培训）记住每一条路。

二

后来，互联网起来了，移动互联网起来了，IT界慢慢地开始讲一个词：用户体验。

那几年，UCD——以用户为中心的设计——成了行业里的时髦词。软件不但要功能强大，还要好用、易用。苹果的iPhone重新定义了什么是"软件应该有的样子"，企业软件再也无法假装自己可以永远难用下去。

我也做过这个事情。

那时候我负责了一个头部的 ERP+CRM 的软件包在企业的落地和产品的定制开发。那个软件包功能强大，但界面是十几年前的设计，操作路径散落在几十个菜单里。系统一上线就被用户深恶痛绝，被骂是常事。痛定思痛，我们决定对软件包做用户体验重构，我是用户体验改进的负责人。我们的做法是：把软件包的界面整个抛弃掉，保留它底层的应用逻辑，在它的上面重新做一层界面——以不同岗位的用户为核心。

一个采购员要用的功能，原来散落在五个模块、七个菜单、十几张界面里：查物料在A界面，下订单在B界面，看交期在C界面，查价格历史又在D界面。我们把这些散落的功能点，按照采购员实际干活的操作流程，重新组合、串成一条线，做成一个"采购工作台"——他每天上班打开这一个界面，从早到晚的活都在这条线上走。

同时尽量简化操作：用户要录入的信息，尽量通过关联、搜索自动带出来。以前填一张采购单，供应商编码要背下来手敲；现在输入供应商名称的前几个字，下拉列表自动带出来，点一下就行。能少填一个字段，就少填一个字段。

效果立竿见影。培训从三天缩短到半天，上岗从"持证上岗"变成"看一眼就会"。

现在回头看那次改造，我意识到一件当时没想明白的事：那其实也是一种"意图识别"。

识别者，是产品经理和业务分析师。他们花几个月时间泡在业务现场，观察采购员每天怎么干活、先干什么后干什么、哪些信息重复录入，然后把观察到的"用户意图"——用户在什么场景下想干什么事——识别出来，固化进操作界面里。采购员不用再在迷宫里找路了，因为产品经理已经把路修好了，铺成了人行道。

但是，请注意这个"但是"——人行道是修好了，可路还是固定的。

产品经理识别出来的意图，终究是有限的、可枚举的。新的业务场景来了，原来的工作台没有这个入口，怎么办？加菜单、加页面、加按钮——又一次穷举，只是这次穷举得比ERP时代聪明一点、贴人一点。改一条流程，界面又要跟着改一轮；换了岗位职责，工作台又要重新设计。

UCD时代的进步，是意图识别者变了：从"用户自己在迷宫里找路"，变成"产品经理替用户修路"。但识别的方式没变，还是穷举——只是把"系统穷举"变成了"产品经理穷举"。界面依然是意图的固化物：设计好的那天起，它就锁定了用户可能有的意图，多一个，就要重新设计一次。

一句话：那个时代的软件，用界面把"人的意图"翻译成"机器的操作"——翻译是静态的，翻完就焊死在界面里了。

三

现在，到了AI时代。这一章要讲的，就是这件事的第三次变化。

还记得第五章说的吗？AI是主人，UI是仆人。还记得第十一章那张架构图吗？四层架构的最上面一层，写的是"交互层：薄UI + 自然语言对话"——当时我只用了几段话讲它，说它"反而最简单"。现在，该把这"最简单的一层"拆开看了。

先说结论：AI时代，意图识别从静态变成了动态。

它不再需要固定的菜单和界面。用户说出自己的意图，AI Agent理解了，然后由Agent自主决定这一层展示什么——是给一张表格，还是给一张图表，还是弹一个确认框，还是什么都不展示、直接把事办了。

为什么从前做不到？因为从前机器听不懂人话，意图必须靠界面"猜"出来——你点了"差旅报销"菜单，系统才敢猜你要报销。现在机器能听懂人话了（第四、五章反复讲的那件事），意图可以从对话里直接来——你说"我想报销上周出差的费用"，Agent不需要你在菜单里找路，它直接就知道你要干什么。

点击和对话，是两种完全不同性质的意图表达：

点击，是枚举式的。 用户在系统预先列好的意图集合里，选一个。系统提供了"差旅报销"这个菜单项，你才能报销差旅；系统没提供的意图，你就表达不出来——你想报销但系统没有这个菜单，你只能找IT提需求，等八周。

对话，是开放式的。 用户用自然语言表达，意图空间是敞开的。你可以说"报销上周出差费用"，也可以说"把上周出差的住宿费单独算一下超没超标"，也可以说"顺便帮我看看这个月打车花了多少"——三种说法，三种意图，都接得住。

旧世界的界面，是意图的输入设备：用户通过操作界面，把自己的意图翻译成系统能懂的点击。新世界的界面，是理解的呈现设备：用户直接说出意图，机器负责理解，界面负责把机器的理解——它打算干什么、它查到了什么、它需要你确认什么——呈现给人看。

人机交互的位置，从"人向机器翻译意图"，变成了"机器向人呈现理解"。

有人会问：那界面是不是要消失了？

不是。界面没有消失，它换了活法——而且是两种活法。

四

原本那种"一个页面承载一套功能"的界面，在新逻辑下，要分拆成两类。

第一类，固化的展示界面。

还是窗体，还是表单，还是上面有哪些元素——字段、按钮、校验规则，一样不少。但有一个根本性的变化：它没有固定的路径了。

旧世界的窗体，长在固定的位置：菜单里有入口，页面之间有跳转，用户要按设计好的路线走到它面前。新世界的窗体，位置不再由菜单决定——它变成了"原子级"的界面，成为供AI调用的工具。

怎么理解"原子级"？就像积木箱里的零件。零件本身是确定的——方的是方的，圆的是圆的，插口在哪儿就是哪儿——但零件组成什么，由搭积木的人（Agent）根据当下的需要决定。一张"报销确认卡"，不管谁报销、报销什么，它的样子是稳定的：金额、类别、日期、发票、审批链，该有的字段一个不少，该有的校验一条不松。但它出现在什么时候、以什么顺序、和哪张卡一起出现，不再有固定的剧本——Agent按场景决定。

为什么这一类界面必须是"固化"的？因为有些展示，容不得半点随机。

财务凭证，每一笔都要对得上账，格式必须是铁板钉钉的；审批单，谁批的、批了什么、依据是什么，是要进审计的，长什么样必须稳定；合同、订单、发票，这些是"凭据"，凭据不能每次生成长得都不一样。凭据性的界面必须固化——它不是给机器看的，是给人看的、给审计看的、给法律看的。它要的是"确定"，不是"灵活"。

第二类，临时性的动态生成界面。

这一类，是AI现场生成的。用户要一张报表，Agent从数据中台取了数，当场画一张——图表、表格、摘要卡片，渲染出来给你看；你要一份方案对比，Agent拉出几个候选，生成一张对比视图；你问"这个月回款为什么慢"，Agent分析完，生成一张原因拆解图。

这类界面的特点是：内容是它要表达的东西，形式随内容走。 同一份数据，你要柱状图就给柱状图，要趋势线就给趋势线，要表格就给表格——形式不是预先设计好的，是按场景、按偏好、按问题当场定的。它的价值在"说得清楚"，不在"长得固定"。

两类界面，一句话分工：

确定性交给窗体，表达力交给生成。

需要"铁板钉钉"的——凭证、审批、签核、数据录入，用固化的原子界面；需要"随机应变"的——报表、分析、对比、摘要，用动态生成的界面。

这个分工，不是拍脑袋想出来的，它和企业治理几十年的智慧是一回事。企业做流程管理，从来都是"用模板约束结构、容忍内容"：一份制度文件，框架结构是规定的，但具体表述是允许不同的；一份评审报告，必填的段落是固定的，但段落里写什么，是写报告的人的自由。界面也一样——结构该固定的固定，内容该自由的自由。 原子界面负责"结构"，动态界面负责"内容"，各管各的。

还有一层意思值得点破：这两类界面的服务对象也不同。

原子界面，是Agent的"手"——它替Agent把确定性的信息摆到人面前，替Agent承接人的确认和录入。动态界面，是Agent的"话"——它替Agent把理解表达给人看。手要稳，话要活。一个负责把事办准，一个负责把事说清。

五

两类界面讲完了，把镜头拉回一个具体的人。还是那个场景，第十一章的报销。

第八章开头讲过报销的故事——员工打开报销系统，三十次点击，二十个字段。第十一章我们跟着它走了一遍，看的是逻辑藏在哪里：两份Skill——《差旅报销提交》和《差旅报销审批》——接管了旧系统里的校验、路由和审批。这一次，我们把镜头对准交互层，看看人在这套系统面前，到底在干什么。

先看旧世界，人是怎么"表达意图"的。 员工在各种菜单里翻到"差旅费报销"，打开一张表单，六项费用——住宿费、在途费用、市内交通费、餐饮费、补贴、其它——一笔一笔填；发票一张一张传；再选部门、选项目号，关联出差申请单，指定权签人，写备注。填完检查一遍，提交。二十个字段，三十次点击，每一次点击和填写，都是在向系统交代一个信息碎片：我是谁、我干了什么、我花了多少钱、我为什么花。人在用操作，一个字一个字地把自己的意图"敲"给系统听。

再看新世界，人是怎么"表达意图"的。 出差回来，打开对话框，说一句："我上周去广州出差三天，一共花了3860，其中住宿3000，剩下的是交通和餐饮。"

后面的事，人基本不用管了。

Agent读《差旅报销提交》Skill——住宿标准，每天一千（第十三章说过，标准从八百调到了一千），三天正好三千，卡在线上，不用解释；3860的总金额，超过五百元直入线，按路由要转部门主管，Agent心里有数；出差申请单，自动关联；六项费用，自动拆好；发票，提示拍照上传即可。然后，它生成一张"报销确认卡"——就是第一类界面，原子级的：六项费用整整齐齐列在上面，金额、日期、标准、是否超标，一目了然，需要人做的只剩一件事——核对，然后确认。

人不再"填"二十个字段，而是"看"一张已经填好的卡。二十个字段的信息，Agent从对话里听走了大半，从系统里查到了剩余——人只负责最后的确认。这就是"意图识别"从点击到对话最直观的样子：以前是人在表单里告诉系统"我花了什么钱"，现在是人在对话里告诉Agent"我出了趟差"，剩下的一切，系统自己问自己答。

接下来是审批。部门主管的手机上弹出一条消息，附一张"审批卡"——同样是原子界面：金额3860，标注"超出五百元直入线，按标准转部门主管审批"；住宿3000，标注"三日，日均1000，卡标准线"；旁边是历史对比——这位同事过去六个月的差旅花费，平均值多少、这次是高是低。主管扫一眼，心里有数，点"批准"。

注意这张卡上有什么：该有的依据都在，不该有的操作都没有。 旧世界里，主管审批要看一堆报表、翻历史、估合理性，全凭经验和记忆；新世界里，Agent把判断的依据和存疑的点，直接摆到了卡上。人没有消失，人还是那个最终点头的人——只是他点头之前需要的信息，被系统备齐了。

最后是报表。 财务想看看这个季度各部门的差旅趋势。放在旧世界，这是一场寻宝：找到报表菜单，找到"差旅费用分析"，选部门、选时间范围、选口径，生成，然后对着一个固定的模板瞪眼——模板里没有你想看的维度，也只能将就着看。放在新世界，财务只说一句："帮我看看这个季度各部门差旅费的趋势，标出异常偏高的部门。"

Agent调数据中台的接口，取数，生成一张动态的界面——趋势图、部门对比、异常标注，甚至把异常部门的超标明细列在下面。这是第二类界面：没有预制的模板，当场生成，问什么答什么。

一次报销走完，从录入到确认、到审批、到分析，正好把两类界面都用上了：录入和确认，是原子界面——稳定、可审计；分析和呈现，是动态界面——灵活、可追问；而入口，永远是同一个对话框。

对话，是意图进来的门；界面，是理解呈现的窗。门只有一扇，窗可以有很多。

这背后藏着一个更大的变化，值得单独说一句：交互层开始"服务"人了，而不是"考验"人。

旧世界的交互层，是个考官——它考你记不记得菜单在哪、字段叫什么、流程怎么走，考不过就不让你用（那三天的培训，就是考前辅导）。新世界的交互层，是个助手——它听你说，替你查，把结果摆好，只把需要人把关的地方留给人。过去，人为了用系统而学习系统；未来，系统为了服务人而理解人。

六

最后，把交互层放回第十一章那张全景图里，看看它和另外三层的接缝。

交互层不是悬空的。那张"报销确认卡"为什么长这样？因为《差旅报销提交》Skill里定义了交付件——第四章说过"文档即记忆"，第十五章给了它完整的工程含义：Skill的交付件定义，就是Agent的记忆写入规则。这里再补一句：它也是界面元素的定义来源。Skill说"这一步需要人确认"，交互层就渲染一张确认卡；Skill说"这一步要留痕"，交互层就保证这张卡进入轨迹。数据从哪来？从数据中台来——卡片上的每一项金额、每一次对比，都是事实，不是Agent编的。展示什么、什么时候展示、要不要请人把关，谁决定？Agent决定——这就是第五章那句话的落地：AI是主人，UI是仆人。

所以四层的关系，可以这样收拢：数据中台是事实的家，Skill中台是规则的家，AI中台是引擎房——而交互层，是人与机器对话的窗口。 前三层负责"把事办成"，交互层负责"让人参与"。

到这里，第十一章那张架构图里的四层，就全部落地了：

• 第十二章，盖了数据的家——金库与防盗门；
• 第十三章，盖了规则的家——注册、编排与晋升；
• 第十四章，立了规则的法律——层级、三轨与终裁；
• 第十五章，走进了引擎房——十三步、三层记忆、三层验收、三条执行道；
• 这一章，打开了对话的窗口——两类界面、一个对话框。

还要说一句诚实的话。第八章讲过适用边界，这里依然成立：高频、精细、需要实时视觉反馈的操作——文字编辑、视频剪辑、三维建模——传统界面依然不可替代；多人协作的并发控制，也还是老界面的地盘。新架构的交互层不是"消灭界面"，是"界面不再承载逻辑"。逻辑在Skill里，界面只是呈现；对话是入口，窗体是工具，生成是表达。

四层讲完，回头再看一眼那个"三天培训"的旧世界，会有点恍如隔世：过去二十年，我们一直在教人适应软件；接下来的二十年，轮到软件来适应人了。

从下一章起，我们从图纸走向工地。图纸上的四层都画好了，可工地上的第一个问题是：谁来写Skill？ IT部门转身去干什么？业务部门怎么接住这份自由？——对话的窗口已经打开，第十七章，看人。