前端学 LLM

什么是 AI Native Application

AI Native Application 不是“接入一个大模型 API”的应用，也不是在页面右下角放一个聊天框。

如果一个传统 SaaS 增加了“帮我总结当前页面”的按钮，它可以叫 AI feature，但不一定是 AI Native。如果一个知识库增加了文档问答入口，它可以叫 AI-enhanced search，但也不一定是 AI Native。

AI Native Application 的关键变化在于：AI 不再只是某个功能点，而是参与重新组织产品的入口、上下文、能力编排、数据沉淀和权限边界。

换句话说，AI Native 不是“软件里有 AI”，而是“软件的主要工作流被 AI 能力重新塑形”。

一个工程化定义

可以把 AI Native Application 定义成：

一种围绕 AI 推理、生成、检索、工具调用和上下文编排重新设计的应用。它让 AI 成为用户意图入口、任务编排层和工作空间连接器，并把结果沉淀回业务对象与长期工作流。

这个定义里有几个重点。

第一，AI 是入口。用户不一定先找到正确页面、正确表单、正确按钮，而是可以先表达目标。系统再把目标映射到搜索、编辑、生成、自动化或 Agent 执行。

第二，AI 是编排层。模型不是直接替代业务系统，而是根据上下文选择合适能力：查知识库、读当前文档、调用 API、生成草稿、请求确认、写回结果。

第三，AI 依赖上下文。真正有用的 AI Native 产品，不是每次都把用户当陌生人，而是能理解当前工作对象、历史记录、权限范围、组织知识和任务状态。

第四，AI 输出会沉淀。AI 生成的内容不是一次性聊天记录，而会成为文档、任务、代码、配置、工单、决策记录或自动化流程的一部分。

第五，AI Native 必须有边界。越是深度嵌入工作流，越需要权限、审计、确认、评估和失败恢复。

AI Native 和 AI Feature 的区别

AI Feature 通常是局部增强。它在已有产品路径上增加一个生成、总结、翻译、问答或改写能力。

AI Native Application 则会改变用户完成任务的方式。

维度AI FeatureAI Native Application
产品位置某个按钮或局部能力核心入口和工作流
用户意图用户已经知道要点哪里用户先表达目标，系统帮助推进
上下文当前文本或当前页面跨文档、任务、历史、权限和工具结果
能力组织单次模型调用检索、生成、工具、Workflow、Agent 的组合
输出形态一段文本或一次回答可编辑对象、任务状态、自动化结果、知识沉淀
风险控制简单提示和免责声明权限、确认、审计、Eval、回滚和观测

一个产品可以从 AI Feature 起步，但如果只停留在按钮级能力，就很难形成真正的 AI Native 体验。

AI Native 的五个层次

理解 AI Native，不要只看 UI 长什么样。更好的方式是看它是否具备五个层次。

入口层

入口层决定用户如何表达意图。

传统软件通常要求用户先理解软件的信息架构：去哪个菜单，打开哪个页面，选择哪个字段，点击哪个按钮。

AI Native 产品允许用户从更接近目标的语言开始：

  • “帮我把这份会议记录整理成行动项。”
  • “找出最近三个月流失客户的共同原因。”
  • “把这个 PR 的风险点按严重程度列出来。”
  • “根据这封邮件生成一个客服回复草稿。”
  • “把这个表格里的异常数据解释一下。”

这并不意味着所有入口都要变成聊天框。入口可以是搜索框、命令面板、编辑器选区、表格列操作、侧边栏 Copilot、语音输入、自动触发的 Workflow，甚至是后台任务。

AI Native 的问题不是“要不要聊天”，而是“用户在什么位置表达意图最自然”。

上下文层

上下文层决定 AI 能理解什么。

没有上下文的 AI 只能泛泛回答。有上下文的 AI 才能进入业务场景。

上下文可以包括：

  • 当前页面：用户正在看的文档、表格、工单、客户、PR、订单。
  • 选中内容：用户选中的一段文字、一个图表、一行数据、一段代码。
  • 业务对象：文档、任务、用户、团队、项目、客户、交易、评论。
  • 历史状态：对话历史、编辑历史、审批记录、工具调用结果。
  • 组织知识：知识库、规范、FAQ、代码仓库、历史案例。
  • 用户偏好：语言、语气、常用模板、角色、权限范围。

上下文层不是简单地“把更多内容塞进 Prompt”。它需要做筛选、压缩、引用、权限过滤、缓存和版本管理。

好的上下文层会让 AI 像“在这个工作空间里工作”，而不是像“拿到一段孤立文本后猜测”。

编排层

编排层决定 AI 如何完成任务。

用户说“帮我分析这个客户为什么可能流失”，系统可能需要：

  1. 读取客户档案。
  2. 查询最近工单。
  3. 总结沟通记录。
  4. 对比历史流失客户特征。
  5. 生成风险判断。
  6. 给出可执行的跟进建议。
  7. 生成一封客户成功邮件草稿。

这不是一次简单的模型调用，而是多种能力的组合。

AI Native Application 通常需要一个 Orchestrator，负责把用户意图转成可执行路径：

  • 什么时候检索知识库。
  • 什么时候读取业务对象。
  • 什么时候调用工具。
  • 什么时候生成草稿。
  • 什么时候进入 Workflow。
  • 什么时候启动 Agent。
  • 什么时候请求用户确认。
  • 什么时候停止并解释失败。

编排层是 AI Native 产品从 Demo 走向生产的关键。没有编排层，系统只能靠一个巨大的 Prompt 勉强支撑复杂场景。

对象层

对象层决定 AI 的结果沉淀在哪里。

很多 AI Demo 的问题是：用户得到了一段看似不错的回答，但回答和产品对象没有关系。用户还要复制、粘贴、改格式、创建任务、补字段。

AI Native 产品应该让 AI 输出自然回到工作空间：

  • 总结变成文档段落。
  • 建议变成任务列表。
  • 分析变成报告。
  • 决策变成记录。
  • 代码建议变成 diff。
  • 客服回复变成可审核草稿。
  • 自动化结果变成可追踪运行记录。

这要求产品把“AI 输出”建模成可编辑、可引用、可追踪的对象，而不是只把它存在聊天消息里。

安全与观测层

安全与观测层决定系统能否长期运行。

AI Native 产品一旦深入工作流，就会接触真实数据和真实操作。它必须处理：

  • 用户是否有权限读取某个对象。
  • 模型是否拿到了不该看到的上下文。
  • 工具调用是否越权。
  • 写操作是否需要确认。
  • 输出是否有引用和证据。
  • 错误是否可恢复。
  • 结果是否可评估。
  • 关键行为是否可审计。

AI Native 不是越自动越好，而是越能把自动化放进可控边界越好。

AI Native 产品的常见形态

AI Native Application 不只有一种长相。不同场景会出现不同入口和交互形态。

Chatbot

Chatbot 适合开放式问答、探索、客服、知识库问答和低门槛入口。

它的优势是用户成本低，表达自然。缺点是结构弱、上下文边界容易混乱、结果沉淀不自然。

Copilot

Copilot 通常嵌入已有工作界面，围绕当前对象提供建议、解释、生成和改写。

它适合编辑器、IDE、CRM、数据分析、设计工具和后台系统。它比纯聊天更贴近任务现场。

AI Search 从“找页面”变成“直接回答并给证据”。它适合知识库、文档、客服、企业内部搜索和研究场景。

关键不是语义搜索本身，而是检索、证据、引用、回答和追问之间的闭环。

AI Editor

AI Editor 把生成能力嵌入内容生产过程。用户可以选中文本进行 rewrite、expand、summarize、translate、tone change、format transform。

它的核心不是“一键生成全文”，而是让用户在局部编辑、差异对比和部分接受中保持控制感。

Workflow

Workflow 适合相对稳定的多步骤任务，例如线索评分、合同审查、客服分流、报表生成、文档处理。

它比自由 Agent 更可控，适合生产环境。AI 在其中承担分类、提取、生成、判断或摘要等环节。

Agent

Agent 适合目标明确但路径不完全固定的任务，例如调研、排查、跨系统操作、代码修改、网页操作。

Agent 需要状态、工具、验证、恢复和人工确认。不要把所有 AI Native 产品都做成 Agent。

AI Workspace

AI Workspace 是更综合的形态。它把文档、任务、知识、对话、自动化和权限放在同一个工作空间里，让 AI 能跨对象协作。

它的难点不是聊天能力，而是对象模型、上下文层、权限模型和工作流沉淀。

AI Native 架构视角

从架构上看，AI Native Application 至少包含七个部分。

Intent UI

Intent UI 承接用户目标。它可以是聊天框，也可以是编辑器工具条、命令面板、搜索框、右键菜单、表格操作或自动化入口。

前端要重点处理输入状态、Streaming、取消、重试、引用、确认、局部接受和错误恢复。

AI Orchestrator

Orchestrator 是 AI Native 的中枢。它负责解析意图、选择能力、构造上下文、调用模型和工具、处理失败、返回结构化结果。

很多系统一开始没有 Orchestrator，只是在业务接口里直接调用模型。短期能跑，长期会把 Prompt、上下文、工具、权限和日志散落到各处。

Context Service

Context Service 负责把业务对象转换成模型可用的上下文包。它要处理权限过滤、信息裁剪、引用标记、缓存、版本和 token budget。

AI Native 的质量很大程度取决于 Context Service，而不是只取决于模型型号。

Tool Runtime

Tool Runtime 负责执行受控工具。工具可以查询数据、创建任务、发送消息、操作浏览器、运行代码、调用第三方 API。

所有工具都应该有 schema、权限、风险等级、超时、重试和审计记录。

Model Gateway

Model Gateway 负责模型路由、降级、成本控制、日志脱敏、限流、重试和供应商切换。

AI Native 产品通常不会永远只依赖一个模型，因为不同任务对成本、延迟、上下文长度、结构化输出和多模态能力的要求不同。

Policy Engine

Policy Engine 负责安全和业务规则，例如哪些内容可见、哪些操作要确认、哪些输出不能生成、哪些工具不能调用。

它不应该只依赖 Prompt 里的“不要做坏事”，而应该成为应用层的明确约束。

Eval & Observability

AI Native 产品必须知道自己是否真的变好。它需要记录输入、上下文版本、模型输出、工具轨迹、用户操作、接受率、失败率和人工修正。

没有 Eval 和 Observability，AI Native 很容易变成“看起来很智能，但没人知道是否可靠”的黑盒。

从前端视角看 AI Native

前端工程师在 AI Native 产品里不只是做聊天 UI。

你需要重新理解应用的交互结构。

第一，入口会变多。用户可能从页面顶部搜索、侧边栏、选中文本、命令面板、表格行、文档块、自动化规则进入 AI 流程。

第二，状态会变复杂。AI 任务可能有 queued、running、streaming、waiting_confirmation、failed、retrying、completed、cancelled 等状态。

第三，结果不再只是文本。结果可能是 diff、patch、task、form draft、chart insight、citation list、tool trace、workflow run。

第四，用户需要控制权。停止、重试、编辑、接受一部分、拒绝、回滚、查看证据，这些不是锦上添花，而是生产可用的基本能力。

第五，界面要展示不确定性。AI Native UI 不能假装每次都正确。它要告诉用户依据是什么、哪些地方不确定、哪些操作还没提交。

一个 AI Native 前端状态可以这样理解：

type AiNativeRunView = {
  id: string;
  entry: 'chat' | 'copilot' | 'search' | 'editor' | 'workflow';
  status: 'idle' | 'running' | 'waiting_confirmation' | 'failed' | 'completed';
  intent: string;
  contextObjects: Array<{ type: string; id: string; title: string }>;
  steps: Array<{ title: string; status: string; evidence?: string[] }>;
  output?: {
    kind: 'answer' | 'draft' | 'diff' | 'task' | 'workflow_result';
    content: unknown;
  };
};

这类结构比纯 message list 更能承载真实产品。

常见坑

坑一：把 AI Native 等同于聊天框

聊天框是入口之一，但不是终点。很多任务更适合编辑器、命令面板、表格操作、工作流或 Copilot。

如果所有 AI 能力都塞进聊天框，用户会在“表达目标”和“把结果落回工作对象”之间反复搬运。

坑二：没有上下文层，只有 Prompt 拼接

早期 Demo 常常把当前页面文本、用户输入和几段规则拼成一个 Prompt。

这在小场景可行，但一旦涉及权限、多个业务对象、引用、历史状态和 token budget，就会失控。

上下文层应该是系统能力，不是散落在各个接口里的字符串模板。

坑三：只追求自动化，不设计确认和回滚

AI Native 产品最容易犯的错误是把“少点几下”当成唯一目标。

真实生产环境里，用户更关心：它为什么这么做、我能否修改、提交前能否确认、出错后能否恢复。

坑四：输出没有对象化

如果 AI 输出只能停留在聊天记录里，它就很难成为工作流的一部分。

应该尽量把输出转成可编辑对象：文档块、任务、表单草稿、代码 diff、审批项、报告章节、自动化运行记录。

坑五：忽视评估，只看演示效果

AI Native 的演示通常很惊艳，因为它展示的是成功路径。

但生产系统要看失败路径：答错率、引用缺失率、工具失败率、用户撤销率、人工修改率、任务完成率、平均耗时、成本和延迟。

坑六：权限边界后补

AI Native 产品会跨对象读取上下文，也可能调用工具写入业务系统。

权限如果后补，很容易出现数据泄露、越权操作和审计缺失。权限过滤应该发生在上下文构造、工具调用和结果展示的每一层。

如何判断一个产品是否 AI Native

可以用这组问题快速判断：

  • 用户是否可以用目标而不是菜单路径启动任务？
  • AI 是否理解当前工作对象和历史状态？
  • 系统是否能组合检索、生成、工具和工作流？
  • AI 输出是否能沉淀成业务对象？
  • 用户是否能查看证据、编辑结果、确认操作和回滚？
  • 权限、审计、Eval 和观测是否是架构的一部分？
  • 产品是否因为 AI 改变了主要工作流，而不只是多了几个按钮？

如果答案大多是否，那它可能只是 AI-enhanced product。它仍然有价值，但还没有进入 AI Native。

小结

AI Native Application 的核心不是“调用更强的模型”，而是重新设计软件如何接收意图、组织上下文、编排能力、沉淀结果和控制风险。

对前端工程师来说，AI Native 意味着 UI 不再只是展示数据和提交表单，而要承载不确定性、过程、证据、编辑、确认和多步任务状态。

真正的 AI Native 产品会把 AI 放进工作流的骨架里。用户不是和一个孤立机器人聊天，而是在一个能理解上下文、调用工具、尊重权限并留下可审计结果的工作空间里完成任务。