1. 前言

过去我们使用一款软件，往往需要先了解它有哪些功能，再学习如何操作。比如我们想要完成一次财务报销，就需要找到对应的入口、填写表单、上传材料，再按照规定的流程一步步提交。虽然软件提供了完整的功能，但用户仍然需要花费不少时间去理解这些功能，并把它们组合起来完成自己的工作。

不过，随着大语言模型能力的不断提升，我们开始有机会重新思考这样一个问题：能不能让用户不再需要熟悉软件的每一个功能，而是直接告诉软件自己想完成什么，再由软件帮助用户完成后续的工作？

这种思考的转变其实非常的重要。过去我们更多是在已有的软件中添加 AI 功能，帮助用户提高某些环节的效率。而现在，我们可以进一步围绕 AI 的能力，重新设计应用的功能、交互方式，甚至整个业务流程。

这也引出了近年来越来越受到关注的一个概念——AI 原生应用（AI-Native Application）。

那么，究竟什么是 AI 原生应用？是不是只要接入了大语言模型，就可以称为 AI 原生？它与传统应用、AI 赋能应用到底有什么区别？接下来，我们就从这三种应用的设计思路出发，再结合一个具体的财务报销案例，看看 AI 原生应用究竟改变了什么。

2. AI 原生概念解析

其实，AI 原生（AI-Native）并不是随着 ChatGPT 的出现才被提出的概念。在大语言模型普及之前，人工智能就已经被应用到各种软件和系统当中，只不过当时的 AI 通常是围绕某一类特定任务进行设计的。

比如，我们可以训练一个图像分类模型来识别图片中的物体，也可以利用语音识别模型将语音转换成文字，或者通过推荐算法向用户推荐感兴趣的商品。这些 AI 技术在各自的领域都能够发挥很大的作用，但它们通常只能完成预先定义好的任务。如果希望系统具备其他能力，往往还需要开发新的模型或者设计额外的处理流程。

而随着大语言模型的发展，这种情况开始发生变化。如今的大语言模型不仅能够理解和生成自然语言，还能够结合上下文进行分析、推理和判断。

同一个模型既可以帮助我们整理文档、分析问题，也可以根据用户的需求决定下一步应该调用什么工具。如果再为模型接入数据库、业务系统和外部工具，它就能够进一步查询信息、执行操作，参与到一些原本需要人工协调的工作流程当中。

这意味着，我们不再只能让 AI 完成某一个预先定义好的功能，而是可以围绕 AI 的通用能力，重新思考整个应用应该如何设计。这也是为什么近年来 AI 原生应用开始受到越来越多关注。

那么，到底什么是 AI 原生应用呢？简单来说，AI 原生应用就是从产品设计之初，便将 AI 作为核心能力，并围绕这种能力来设计应用的功能、交互方式和工作流程。

这里的关键并不是应用使用了多少 AI 技术，而是 AI 在整个应用中承担什么角色。假如 AI 只是帮助用户完成某个额外的小功能，那么它更多属于 AI 赋能；但如果一款应用的主要服务就是围绕 AI 的能力建立起来的，AI 直接参与核心任务的完成，那么它就更符合 AI 原生的设计思路。

这里也需要注意，AI 成为核心能力，并不意味着所有工作都要交给 AI。它与用户、已有业务系统如何分工，同样是应用设计的一部分。不过，单纯从概念上理解，可能还是有些抽象。接下来，我们就通过传统应用、AI 赋能应用和 AI 原生应用之间的对比，进一步看看它们究竟有什么区别。

3. 三类应用的设计思路

为了让大家更直观地看到应用之间的区别，这里我们就以财务报销为主线，看看传统应用、AI 赋能应用和 AI 原生应用分别怎样帮助用户完成同一件事。这里先关注一个问题：用户需要做什么，应用又承担了什么？

3.1 传统应用：让用户按照既定流程完成工作

首先是我们最熟悉的传统应用。这里所说的传统应用，并不是指很多年前开发的老旧软件，而是指主要依靠预先设计好的功能、规则和业务流程来完成工作的应用。实际上，我们现在使用的大量软件都属于这种类型。

比如学校的财务报销系统。当我们需要报销一笔费用时，就要先登录系统，找到对应的报销入口，填写报销信息，选择经费项目，上传发票和相关材料，最后提交审批。整个过程中，系统已经为我们提供了完整的功能，但我们仍然需要按照它规定的步骤，一步步完成操作。

这其实也是传统软件开发中非常常见的一种思路：开发者根据业务需求设计功能和操作流程，再由用户学习如何使用这些功能。这种设计的价值，在于把业务要求落实为明确的规则和流程。例如，哪些费用可以报销、不同金额需要经过哪些审批，都可以在系统中得到规范执行。

不过，这类应用通常有一个特点，就是用户需要主动适应系统的操作方式。即使我们只是想完成一件简单的事情，也可能需要先了解系统有哪些功能、应该在哪个页面操作，以及每个字段具体是什么意思。

对于经常使用系统的人来说，这些操作可能早已习以为常。但对于不熟悉业务的用户来说，学习和理解这些操作本身，就需要花费一定的时间。

3.2 AI 赋能应用：利用 AI 改善原有功能

随着人工智能技术的发展，越来越多的软件开始加入 AI 功能，希望借助 AI 来提升使用体验和工作效率。这就是我们经常提到的 AI 赋能应用。它的设计思路其实很好理解：原有的软件功能和业务流程基本不变，只是在某些适合的环节加入 AI，让用户能够更方便地完成操作。

比如，我们在使用邮箱时，可以让 AI 帮忙润色邮件；在使用办公软件时，可以让 AI 总结文档、生成表格；在使用数据分析软件时，也可以利用 AI 帮助理解数据、生成分析报告。

对于前面提到的财务报销系统，同样可以加入很多实用的 AI 功能。例如，上传发票时，利用文字识别技术自动提取发票号码和金额；填写报销说明时，让大语言模型根据已有信息生成一段文字；上传附件时，自动识别文件内容并进行分类。

这些功能虽然没有改变原有的报销流程，但确实能够减少用户的重复操作，让原本比较繁琐的工作变得更加方便。所以，AI 赋能本身也是一种很有价值的应用方式，并不是说只有 AI 原生应用才值得开发。

不过，我们在设计 AI 功能时，也需要思考这些功能是否真正解决了用户的问题。现在有些应用为了融入 AI，加入了各种各样的智能化功能，但实际使用的人却很少，甚至让原本简单的操作变得更加复杂。

与此同时，引入大模型还需要考虑调用费用、响应时间以及后续维护等成本。因此，衡量一个 AI 功能是否有价值，关键不在于它使用了多么先进的模型，而在于它有没有真正改善用户的使用体验。

当然，即使这些 AI 功能确实发挥了作用，我们也会发现一个问题：它们通常只是优化了原有流程中的某个环节，而整个工作依然需要用户自己组织。比如，在财务报销系统中，即使 AI 已经能够自动识别发票、填写金额和生成说明，用户仍然需要自己了解报销要求、选择对应的功能，并按照规定的流程一步步完成操作。

这就让我们有了一个新的思考方向：既然 AI 已经能够帮助我们完成某些具体的操作，那么有没有可能更进一步，让 AI 不只是参与其中的某个环节，而是直接围绕用户想要完成的事情，协助组织和完成整个工作流程呢？

3.3 AI 原生应用：围绕 AI 的能力重新设计应用

这其实就引出了 AI 原生应用的一种重要设计思路。与其在原有的软件中不断增加 AI 功能，我们不妨重新思考一下：用户使用一款软件，真正想要完成的是什么？

还是以财务报销为例，用户真正关心的其实是把符合要求的费用报销下来。至于需要填写哪些表单、准备什么材料、按照什么顺序操作，这些都是为了实现目标而需要完成的过程。

如果 AI 已经具备了理解需求、分析问题和调用工具的能力，我们就可以尝试让用户直接表达自己的目标，再由 AI 帮助整理材料、协调相关功能，并在必要时让用户进行确认，而不必让用户亲自处理每一个操作步骤。

这就是两种设计思路之间一个很重要的区别：AI 赋能更多是在已有流程中引入 AI，帮助用户完成某些具体的操作；而 AI 原生则可以进一步围绕 AI 的能力重新设计整个应用，让 AI 直接参与核心任务的处理，改变用户与系统之间的分工。

当然，这里并不是说 AI 原生应用就一定要取消所有的按钮和表单，全部通过聊天来操作。对于需要核对金额、查看数据或者确认操作的场景，传统的界面可能反而更加方便。真正发生变化的是 AI 在应用中的角色。它不再只是某个功能的辅助工具，而是直接参与应用核心价值的实现。

同样需要注意的是，AI 原生应用也不一定都像财务报销这样，需要 AI 去协调和执行多个操作。例如，围绕 AI 图像生成能力设计的创作工具，也可以是一种 AI 原生应用。在这类产品中，AI 的核心作用是帮助用户创作内容，而不一定是自动执行复杂的业务流程。

这两类产品的形态虽然不同，但 AI 都直接支撑了它们的主要价值。因此，判断一款应用是否符合 AI 原生的设计思路，不能只看它有没有聊天界面，或者能不能自动执行一串操作，还要看 AI 在核心任务中承担了什么。

接下来，我们把报销场景展开，看看这种设计思路如何落到实际的办理过程中。

4. 以财务报销为例，理解流程如何改变

前面我们已经看到，AI 可以减少某些步骤中的重复操作。如果进一步让它参与整个报销事项，应用又可以怎样设计呢？我们不妨把场景具体一些：假设我刚参加完一次学术会议，手里已经有了会议通知、车票和住宿发票，现在准备报销相关费用。我可以先把这些材料上传给应用，再告诉它：

“我刚参加完这个学术会议，需要报销相关费用。你帮我看看这些材料够不够，如果没有问题，就帮我准备报销申请。”

4.1 整理材料，找出缺项

接下来，AI 就可以先对这些材料进行整理。比如，从会议通知中提取会议名称、时间和地点，从发票中识别对应的费用金额，再根据已有材料整理出本次报销的费用明细。如果应用已经接入学校的报销制度，还可以进一步检查材料是否符合要求。

假如发现缺少某份证明，或者某张发票的信息不够完整，就可以直接提醒我补充，并且说明为什么需要这份材料。这样一来，我就不必自己反复查阅报销要求，而是可以根据系统的提示逐步准备。

4.2 核对信息，确认提交

等材料准备齐全以后，AI 还可以继续帮助我整理报销申请。例如，根据会议材料生成报销事由，按照费用类型整理各项支出，并结合学校的经费管理规则查询可能适用的报销项目。

当然，有些信息并不能仅凭材料确定，比如这次会议的费用究竟应该从哪个经费项目中支出，或者应该使用哪张银行卡收款。这时，AI 可以主动向我询问，或者将可选择的信息展示出来，让我进行确认，而不是自行猜测。

当所有必要信息都确认以后，系统就可以生成一份完整的报销申请供我检查。如果没有问题，我只需要确认提交，AI 就可以通过财务系统提供的接口，在获得相应权限的情况下完成申请创建、附件上传和流程提交等操作。

当然，申请是否真正提交成功，要以财务系统返回的回执为准。如果系统返回“已受理”，应用就可以告知我申请已经提交；如果返回失败，则应说明原因，并根据实际情况继续处理。这里的“已受理”也只是进入审批流程，并不代表报销已经获批。

4.3 跟进审批，处理后续事项

提交申请以后，报销事项还没有结束。假如系统还能够获取审批进度，就可以在申请被退回、需要补充材料或者审批完成时主动提醒用户。

如果后续需要提交纸质材料，也可以根据学校的实际要求，帮助整理需要打印的表单、附件以及提交顺序，并在合适的时间进行提醒。这样，应用处理的就不只是“填写报销单”这个操作，而是尽可能帮助用户完成整个报销事项。

4.4 明确 AI 与财务系统的分工

上面描述的是一种应用设计设想。要真正实现，还需要将 AI 与学校已有的财务系统、报销制度和相关工具连接起来，并处理好用户授权、信息核对和操作记录等问题。

不过我们可以看到，在这套设计中，AI 应用负责理解需求、整理信息和组织任务，原有财务系统负责数据管理、规则校验以及正式的业务处理。已有的业务能力可以通过接口或工具提供给 AI，调用后再将实际结果返回给应用。涉及费用合规性判断、正式审批等有明确管理责任的环节，仍然要遵循学校的业务制度，由相应规则和责任人员把关，不能交给模型自行决定。

在这样的分工下，AI 承接了过去由用户来回协调的一部分工作，同时保留了财务业务所需的规则与责任边界。用户的办理方式发生了变化，原有系统也继续发挥着作用。

4.5 考虑 Token 消耗与实际成本

不过，让 AI 承接这些工作，也会带来一个很实际的问题：完成一次报销，究竟需要消耗多少模型资源？对于这类依赖大语言模型的应用，用户看到的可能只是一句请求，背后却可能需要多轮模型调用。例如，先读取材料、找出缺项，等用户补充信息后再整理申请，调用财务系统以后，还要根据返回结果判断下一步该怎么做。

每一轮中，模型读取的内容和生成的内容都会产生 Token 消耗。这里的 Token，可以简单理解为模型处理文本时使用的基本单位，它与汉字或单词并不是固定的一一对应关系，也是很多模型服务计算调用费用的依据。

如果每一轮都把完整的报销制度、全部材料和历史对话重新交给模型处理，输入的内容就可能越来越长。遇到材料识别不清、工具调用失败，或者需要重新分析的情况，还可能增加额外的调用。

因此，用户操作变少，并不意味着应用背后的处理成本也会同步减少。除了 Token 带来的费用，多轮调用和重试也可能增加等待时间。具体开销则取决于模型选择、材料长度、任务复杂程度，以及应用怎样组织这些调用，不能简单认为 AI 原生应用就一定很贵。

这也进一步说明，前面提到的分工很重要。比如，费用金额的加总、已经明确的报销额度校验，以及审批状态的查询，都可以由程序或原有财务系统完成，不必每一步都让大模型重新分析。

应用也可以保存已经核对过的信息，只在需要时提供相关材料和制度条款，避免反复处理无关内容。对于审批进度，程序可以先查询状态或接收状态变化通知，再在需要解释退回原因、整理补充材料等情况下调用模型。

因此，设计这类应用时，需要把模型费用、用户等待时间，以及节省下来的人工时间放在一起考虑。如果一次报销能够减少用户反复查制度、整理材料和来回修改的时间，适当增加模型调用可能是值得的；但如果只是完成一个简单查询，却让模型来回分析多次，就未必划算。真正需要衡量的，是在保证结果可靠的前提下，完成这件事的整体成本是否合理。

5. 结语

回到前面的会议报销案例，如果把用户需要做的事情放在一起比较，就会发现，变化不只体现在填表更快、操作更少。

过去，用户既是信息的提供者，也是整个流程的组织者：要自己查清要求，把材料对应到表单字段，再记住下一步该做什么。AI 赋能可以减轻其中某些步骤的负担，而 AI 原生的设计，则进一步让应用承接这些步骤之间的协调工作。

对用户来说，工作的重点逐渐从“亲自组织并操作每一步”，转向“说明目标、提供真实信息，并在关键处作出选择和确认”。比如，我仍然需要说明这次会议的实际情况，选择合适的经费项目，核对费用并授权提交；但不必再为了完成报销，先把系统的入口、字段和办理顺序都学一遍。

这也意味着，用户眼前变得简单，应用背后的工作反而更加完整了。AI 要把会议通知、车票和发票整理成可以使用的信息，结合报销制度找出缺项，向用户询问无法确定的内容，再把确认后的信息交给相应工具执行。

原来需要用户在材料、规则和不同页面之间来回衔接的工作，开始由应用持续组织起来。流程中的复杂性并没有凭空消失，而是更多地由应用来承担。

不过，承担更多工作，也意味着应用需要更清楚地知道自己能做什么、做到哪一步，以及什么时候应该停下来请人判断。材料中没有的信息不能靠猜，经费选择和提交授权不能被跳过，正式审批也仍然属于原有业务规则和责任人员。

AI 可以帮助组织任务，财务系统则继续负责规则校验、审批流转和正式记录。两者之间的交接，要有明确的权限和实际返回结果。

因此，评价这类应用时，除了看它能替用户完成多少操作，还应该看：用户是否少操心了，关键决定是否仍然清楚可控，以及出现问题后能否继续处理。如果 AI 已经生成了申请，却没有真正提交，就应该明确停留在“待提交”；如果系统已经受理，也不能直接说报销已经完成。

缺少材料、提交失败或者申请被退回时，应用还需要说明当前进展、问题所在，以及接下来由谁处理。只有这样，用户才不必一边让 AI 办事，一边重新检查整个流程。

当然，这三种应用的设计思路并没有绝对的优劣。对于规则稳定、操作简单的任务，清晰的传统界面可能已经足够；对于某个重复性很强的环节，加入一个实用的 AI 功能也可以带来明显价值。是否需要进一步采用 AI 原生的设计，仍然要看它能否减少用户实际承担的工作，并且值得为此付出相应的成本。

总的来说，我认为 AI 原生应用真正值得关注的，是我们能否借助 AI 重新安排人与软件之间的分工：让应用承担更多理解信息、组织步骤和衔接执行的工作，让人把注意力放在目标、判断和责任上。对于开发者来说，从具体场景中找出这些可以重新分配的工作，再把确认、执行和反馈设计完整，或许比先决定要增加多少 AI 功能，更接近用户真正需要的应用。