给软件加上 AI 聊天框，首先改变的是交互入口。但如果页面、功能、流程和后续推进方式没有变化，产品本身并未因此完成重构。本文从投标方案场景出发，讨论 AI 进入软件后更深的三层变化：产品设计对象、能力结构和运行机制。

这两年在做软件产品时，我最容易看到的一类变化，就是越来越多的软件开始加入 AI 聊天框。以前用户要先找菜单、进页面、选功能，现在可以直接告诉系统：“帮我整理一下这个项目”“根据这些资料写一份方案”“看看现在还有哪些风险”。

这个变化当然有价值。尤其对功能复杂的企业软件来说，自然语言可以让用户不必先熟悉菜单和功能层级，就能直接表达自己想做什么。但也正是在这个过程中，我一直有个疑问：如果聊天框背后的页面、功能、表单和流程基本都没有变化，我们到底是在重新设计产品，还是只是给原来的软件换了一个更聪明的入口？

这个区别看起来不大，往下走却会直接影响 AI 产品怎么设计。

聊天框改变了入口，但工作还是可能留给人

传统软件有一套已经非常成熟的使用方式。用户知道自己要做什么，然后去找对应的功能，进入页面，完成操作。自然语言出现以后，这条路径可以变得短一些：用户先说出意图，AI 再理解并调用后面的能力。

因此，我并不反对聊天框。恰恰相反，它很可能成为以后软件里非常重要的一种交互方式。自然语言让用户不必先熟悉软件内部的菜单和功能结构，也让软件开始尝试理解人的意图。

图1｜加聊天框，不等于产品重构

真正的问题是，AI 完成这次调用以后，事情是不是就结束了。

拿一份项目投标方案来说。今天的大模型已经可以根据项目需求、背景材料和参考资料，很快生成一个不错的初稿。但真正做过投标的人都知道，初稿通常只是工作的开始。接下来还要确认资料是不是最新的，多个版本之间有没有冲突，不同角色要不要评审，评审意见怎么合并，修改以后由谁确认，最后哪个版本才可以正式提交。

如果这些事情仍然需要人自己在文件、邮件、聊天工具和不同业务系统之间来回切换，同时靠脑子记住“目前做到哪里了”“谁还没有反馈”“哪个才是正式版本”，那么 AI 的确提高了一个环节的效率，但完整工作并没有因此被产品真正接住。

图2｜生成，只是完整工作中的一个节点

这也是为什么我觉得，产品经理讨论 AI 时不能只问“这个功能能不能加 AI”。还要继续问一句：

这个系统到底有没有开始围绕一件完整的工作来组织自己？

产品真正要重新考虑的，是围绕什么设计

很多传统软件的产品设计，仍然很容易围绕一个个功能来组织。查询、录入、审批、统计、导出，每个能力可以单独设计、单独上线，也可以不断优化。这种方式长期有效，今天也依然有效。

但用户面对的现实工作并不是一组彼此孤立的功能。一个项目、一项审批、一份方案或者一次客户服务，通常都有自己的目标、当前状态、参与者、资料、过程结果和下一步行动。用户真正关心的也往往不是“我刚才调用了什么功能”，而是“这件事现在进行到哪里了，还有什么没处理”。

所以，当 AI 开始进入产品以后，我越来越倾向于把一个更前置的问题放到产品设计里：设计的中心究竟还是一个个 Function，还是需要进一步走向一项持续发生的 Work？

这并不是说 Function 要消失。成熟的查询、计算、审批、存储、权限控制仍然非常重要。真正发生变化的是，这些能力不再只是作为一个个独立入口存在，而需要被放进完整工作中重新理解。

系统过去可能只需要知道用户点击了什么、提交了什么；如果它开始参与工作，就还要逐步知道用户究竟在完成什么、当前到了哪里、哪些信息现在仍然有效、刚刚得到的结果意味着什么，以及下一步还有哪些事情需要处理。

产品围绕什么设计一旦变化，后面的能力组织方式也会跟着变化。

还是投标方案这个例子。如果产品只负责“生成一份方案”，模型、提示词和一批参考资料也许已经足够。但如果产品真的要参与方案准备全过程，它还要面对很多传统 AI Demo 不会处理的问题：当前使用的是哪个版本，哪些资料已经确认，哪些信息仍然缺失，谁在参与评审，哪些意见已经处理，哪些动作受权限约束，哪些结果可以正式进入下一步。

这时候，AI 就不可能永远只是一个单独的模型调用。它必须和业务对象、资料、角色、权限、工具、服务发生关系。产品需要考虑的不再只是“AI 能力够不够强”，而是这些能力怎样与原来那些确定性的系统能力一起工作。

所以我后来越来越觉得，顺序不能反过来。不是市场上出现一种新的 AI 技术，就在产品里增加一个对应模块；应该先弄清楚系统究竟要参与什么工作，再看为了把这项工作真正接住，需要哪些智能能力、业务能力和确定性能力。

更难的问题，是一次 AI 输出以后怎么办

生成效果很容易吸引注意力，因为它看得见。一份文档出来了，一段代码生成了，一份分析结果出现了，我们很容易感觉“AI 已经把事情做完了”。

但真实工作通常不是这样结束的。方案生成以后可能要评审，评审以后要修改，修改之后要确认；资料变化了，之前的判断可能需要重新计算；出现异常，还要决定是继续执行、退回前一步，还是交给人处理。

所以一个 AI 产品真正开始参与工作以后，迟早都会面对另一个产品问题：一个结果产生以后，接下来的工作怎么继续？

到这里，讨论已经不只是模型或者智能能力，而是软件自己的运行方式。系统什么时候应该继续，什么时候应该等待新的信息，什么时候需要重新判断，哪些动作能够自动执行，哪些动作必须经过授权，哪些关键结果必须由人确认，这些都必须进入产品设计。

而且，AI 越接近真实业务，边界越重要。所谓让 AI 参与工作，并不意味着把目标交给它以后，让它自己无限执行下去。对于企业软件，尤其是政务、金融、生产等责任要求比较高的场景，很多时候真正关键的不是 AI 能不能“再聪明一点”，而是它为什么可以做这个动作、依据是什么、谁给了权限、结果由谁确认，以及出现问题之后谁承担责任。

写到这里，其实已经可以看到，聊天框只是最外面、也最容易被看到的变化。真正做产品时，问题很快就会往里面走：系统究竟围绕什么来设计？为了参与完整工作，原来的能力和新的 AI 能力怎样组织到一起？一次结果出来以后，工作又怎样继续，而且还能保持必要的授权、确认和责任边界？

这些问题最后落到的，正是我一直在研究的三个层面：产品设计对象、能力结构和运行机制。

图3｜AI Native 产品真正改变的三层

所以，未来的软件不会只剩一个聊天框

我并不认为 AI 出现以后，页面、按钮、表单和流程都会消失。至少在大量企业软件和政务软件中，很多确定性能力仍然是系统真正能够工作的基础。正式数据怎样保存，规则怎样执行，审批结果怎样形成，权限如何控制，这些事情不会因为模型越来越强就失去意义。

AI 更可能带来的变化，是让这些原有能力开始围绕完整工作重新组织。聊天框可以负责理解用户意图，模型可以负责分析和生成，但产品还需要知道当前工作是什么、进行到哪里、哪些结果已经确认，以及接下来需要哪些能力参与。软件从“提供很多功能”走向“参与一项工作”，真正的产品变化才开始出现。

因此，我会把“软件增加 AI”和“产品走向 AI Native”看成两个不同层次。前者完全可以从一个聊天框、一次生成或者一个智能功能开始，而且这些改进本身就有价值；后者则需要继续往下追问：这个产品到底围绕什么设计，能力怎样组织，一个结果产生以后，工作又怎样继续。

聊天框改变的是人与软件的交互入口；AI Native 改变的是产品设计对象、能力结构和运行机制。

给传统软件增加 AI，是变化的开始。真正的产品重构，要从聊天框之后继续往里走。