前言

Github：https://github.com/HealerJean

博客：http://blog.healerjean.com

一、token

Token 是 AI 模型工作方式的基本组成部分。在输入时，模型将单词转换为 token。在输出时，它们将 token 转换回单词。

• 英文：平均 1 个单词 ≈ 1-2 个 Token
• 中文：平均 1 个汉字 ≈ 1-2 个 Token
• 代码：根据语言和复杂度，差异较大

1、token 拆分

就像我们阅读时会将句子拆分成词语来理解，AI 将文本拆分成 Token 来处理。一个 Token 可能是：

• 一个完整的词（如 “AI”）
• 一个词的一部分（如 “understand” 可能被拆成 “under” + “stand”）
• 一个标点符号（如 “，”）
• 甚至是一个空格

2、token 视角

1）它是 AI 的“消化单位” (技术视角)

AI 并不像人类一样直接阅读“单词”或“句子”。它只能处理数字序列。

• 原文：“模型将单词转换为 token… 一个 token 大致相当于一个单词的 75%”
• 通俗理解：
  • 想象 AI 吃东西（文本），它不能一口吞下一整块牛排（一句话），它必须把肉切成小块（Token）才能消化。
  • 切分规则：在英语中，一个 Token 大约等于 4-5 个字母，或者 0.75 个单词。
    • 比如单词 “Spring” 可能是一个 Token。
    • 比如单词 “Artificial Intelligence” 可能会被切分成 “Art”, “ificial”, “ Int”, “elligence” 几个 Token。
  • 中文语境：虽然文档主要讲英语，但在中文里，通常一个汉字或者一个常用词（如“你好”）大约对应 1-2 个 Token。

2）它是 AI 的“计价货币” (商业视角)

• 原文：“Tokens = 金钱… 输入和输出都计入总 token 数量”
• 通俗理解：
  • 使用 AI 模型（特别是商业模型如 GPT-4）就像打车或者用水用电。
  • 计费方式：不是按“次”收费，而是按“量”收费。
  • 双向收费：你发给 AI 的内容（提示词）要算钱（输入 Token），AI 回复你的内容也要算钱（输出 Token）。
  • 省钱技巧：你的提示词越精简，或者你要求 AI 回答得越简短，花费的 Token 就越少，账单也就越便宜。

3）它是 AI 的“短期记忆” (能力视角)

• 上下文窗口就是 AI 的“工作台大小”或者“瞬时记忆力”。
• 限制：AI 一次只能“看”这么多 Token。如果你的书有 100 万字，但模型的窗口只有 8K Token（约 6000 个单词），AI 就无法一次性读完这本书。
• 后果：超出限制的内容，AI 会直接“遗忘”或截断，根本处理不了。
• 对比：
  • GPT-3 (4K)：像是一个只能记几句话的小纸条。
  • Claude (100K+)：像是一本厚小说，可以一次性读完。

3、Token 优化实战技巧

1）提示词优化

• 去除冗余词汇（”请你”、”帮我”、”详细”）
• 使用简洁的结构化表达
• 避免重复说明

2）上下文管理策略

a、策略 1：定期清理对话历史

• 每 5-10 轮对话后，总结关键信息，开启新对话
• 只保留必要的上下文

b、策略 2：使用系统提示词（System Prompt）

• 将固定的角色设定、规则放在系统提示词中
• 避免每次对话都重复说明

c、策略 3：分段处理长文本

❌ 一次性处理：
"分析这10篇文章..." [10,000 tokens]

✅ 分段处理：
1. "总结文章1的要点" [1,000 tokens]
2. "总结文章2的要点" [1,000 tokens]
...
10. "综合前9篇的总结，给出结论" [500 tokens]

d、策略 4：选择合适的模型

根据任务复杂度选择模型：

e、策略 5：缓存机制利用

将常用的系统提示词、文档等内容缓存起来，后续请求时不重复计费。

节省比例： 在 Agent 执行中，可减少 50-95% 的输入 Token 成本。

二、上下文工程

1、什么是”上下文工程”？

上下文工程解决的是“让模型在合适的时刻看到合适的信息

1）定义

a、工作定义

上下文工程，是一门为 LLM 构建和管理”信息环境”的工程方法，决定模型”看到什么、忽略什么、什么时候看到”，从而在有限的上下文窗口内稳定完成任务。

b、核心任务

你可以简单地把它理解成三件事：

• 整理信息：对输入信息进行筛选和组织

• 控制窗口：管理上下文窗口的大小和内容

• 管理成本：优化Token使用，控制调用成本

c、典型应用场景

● 对话型Agent和客服机器人

● 代码/文档助手

● 多轮工具调用和长流程编排

2）为什么聊着聊着，它就忘事，还越来越贵？

• 聊到一半，模型突然“忘记”之前说过的关键条件；
• 长对话里，前后回答自相矛盾，很难保持同一套设定；
• 对话轮次一多，账单像打车计价一样不断往上走。

面对这些挑战，单纯依靠“写好提示词”已经捉襟见肘。我们需要一套更系统的工程方法，来在有限的窗口和预算内，让模型始终获得最关键的信息。这正是上下文工程试图解决的问题。

a、问题现象

● 上下文难以保持一致：对话一长，前后语义容易脱节

● 关键事实容易丢失：早期给出的信息在后续轮次中难以被准确引用

● 调用成本持续上升：每一轮都要重新处理大量历史内容

b、可能的成因

● 视野仅限当前调用：模型只能依赖这一轮提供的上下文

● 信息缺乏结构化组织：重要信息与次要细节混在一起

● 历史内容反复计算：大量固定前缀在多轮对话中被一遍遍重新处理

c、带来的影响

● 回答质量不稳定：对话越长，模型越难保持一致性

● 成本难以预估：每轮上下文大小高度波动

● 难以工程化落地：缺乏明确的上下文管理策略

3）从”血泪教训”说起：Manus 团队踩过的坑

本章案例来自 Manus（一款通用 AI Agent）。 与普通对话不同，Manus 需要自主规划并调用工具完成长任务（涉及几十甚至上百轮交互）。

这带来了核心矛盾：

• 如果不记：关键信息丢失，任务中断。
• 全记：成本和延迟爆炸，甚至超出窗口限制。

Manus 团队经历过多次架构重构，才明白一个道理：上下文不能只靠“写”，而要靠“设计”。

a、四次重构教会我们什么？

核心领悟：不是记得越多越好，而是记得越巧越好。

b、AI 的”记性”到底像什么？

Manus 的经验：小黑板要用得省，用得巧，别用来存百科全书。

传统电脑内存 = 硬盘：

• 容量大：可以长期保存大量数据；
• 价格低：存放一年成本较低；
• 读写速度相对较慢，查找信息需要一定时间。

AI 的上下文 = 小黑板：

• 读写快：模型可以在一次调用中直接看到全部上下文；
• 容量有限：写满后不得不擦除旧内容；
• 每写入一个 token 都会带来额外计算与费用。

4）上下文工程的本质

从实践来看：不是记得越多越好，而是记得越有结构、越有选择性越好。

从成本视角看：

• 大部分浪费来自对固定前缀的重复计算，需要通过前缀稳定和缓存机制解决；
• 重要信息被误删，往往源于“一视同仁”的滑动窗口，需要通过信息分级与钉住策略解决；
• 面对超长文档和知识库时，仅依赖增大上下文窗口并不现实，必须结合检索与压缩机制。

2、第一步：认识成本 - 你的每一分钱花在哪？

1）为什么要先看成本？

让我们看看一次典型的 AI 对话，你的钱是怎么花的：

💰 成本构成（一次对话）：
├─ 70% 重复看旧内容（"刚才聊了什么？"）
├─ 20% 处理新内容（"现在说什么？"）  
└─ 10% 生成回复（"怎么回答？"）

惊人发现：70% 的钱花在让 AI 重新看你之前说过的话！

2）什么是 KV Cache？（前缀复用）

在讨论价格之前，我们得先搞懂一个核心技术概念：KV Cache（键值缓存）。 别被这个技术名词吓到，它其实就是 AI 的“短期记忆速查表”。

• 没有 KV Cache 时：AI 每次都要像第一次看到这篇文章一样，从第一个字开始重新阅读、理解、计算。
• 有了 KV Cache 时：AI 会把看过的部分（Pre-fill）计算结果存下来。下次如果开头的内容没变，它就直接调取记忆，不用重新算了。

这就好比：你去考场考试。

• 情况 A：每次都要把整本教材从头读一遍，再开始答题。（慢、累、贵）
• 情况 B：教材内容你已经背滚瓜烂熟了（Cache），坐下直接答题。（快、轻松、便宜）

在云厂商的计费表里，“背过的书”（Cache Hit）通常比“新看的书”（Cache Miss）便宜 90% 以上

3）避坑指南：别让时间戳毁了你的“缓存”

很多开发者习惯把“当前时间”写在 System Prompt 的第一句，觉得这样很严谨。 但这其实是上下文工程中最大的反模式之一。

想象一下：你背了一整本历史书（System Prompt），结果书的第一行写的是“现在的秒数”。 如果这行字每秒都在变，那你上一秒背的所有内容，下一秒就全废了——你得从头再背一遍。

这就是前缀复用（KV Cache）的死穴：只要开头变了，后面全都要重算。

a、错误示范：把动态信息放前面

System: 现在是 2024-01-01 12:00:01。你是助手...
(一分钟后)
System: 现在是 2024-01-01 12:01:01。你是助手...

后果：虽然只变了几个字，但因为在开头，导致后续 99% 的固定内容无法复用缓存，每次请求都像第一次一样慢且贵。

b、正确姿势：动静分离

System: 你是助手... (这里放几千字的固定规则、知识库)
User: (在这里通过工具调用或用户消息传入当前时间)

好处：前面的几千字规则永远不变，AI 只需要“背”一次。后续请求直接调用记忆，速度极快。

3、第二步：滑动窗口 - 当”记性”变成”成本”

随着对话越来越长，最先遇到的问题就是：窗口满了怎么办？

1）为什么“先进先出”会出问题？

最简单的记忆管理是滑动窗口（Sliding Window）：新的进来，旧的出去。 这听起来很公平，但在实际任务中却是个灾难。

场景重现：

对话记录：
[1] 用户：我是张三，负责支付系统  
[2] 用户：项目用 Go 语言开发
[3] 用户：数据库是 PostgreSQL
...
[20] 用户：帮我写个接口

结果：当聊到第 20 句时，第 1 句“我是张三”已经被挤出了窗口。AI 彻底忘了你是谁，也不知道你在负责什么系统。

问题本质：这种策略把重要信息（身份、技术栈）和废话（“好的”、“收到”）同等对待，一起被踢了出去。

2）”中间失忆症” - 为什么 AI 总看不到关键信息？

除了“忘得快”，AI 还有一个怪癖：它也会“看漏”。 研究发现：AI 对开头和结尾最敏感，中间最容易被忽略。这就是著名的 Lost in the Middle（中间迷失）现象。

U 型记忆曲线：

位置：开头 → 中间 → 结尾
记忆： 高  →  低  →  高

a、应对策略

• 排序优先：把核心任务描述或最高相关文档放在开头，总结性提醒放在结尾。
  • 例如，要求总结报告时，开头写明“请总结以下内容”，结尾再追加“现在请给出你的总结”。
• 结构重组：需要整合多篇文档时，将最相关的两篇分别置于上下文最前与最后，次相关按降序填充中间，人为制造“头尾重要、中间次要”的排列。
• 提示锚点：在文本中段刻意插入强化标记（如 ⚠️ 重要提醒），或重复核心指令（例如“再次强调，回答必须为 JSON 格式”），重新捕获模型注意力。
• 工程压缩：利用检索增强（RAG）只提取高相关片段，缩短上下文；或对超长文档分块摘要，用摘要替代原文，压缩中间区域。

b、举例说明

一个具体对照 有助于把策略落到实处。假设你要让模型基于三篇文档回答用户问题，文档 D1 是关键依据，D2 是补充背景，D3 只是边缘参考：

text
❌ 错误排列（重要信息沉没在中间）：
[用户问题]
[文档 D2]
[文档 D1]   ← 最关键文档被夹在中间，极易被忽略
[文档 D3]
[指令：根据以上文档回答]

✅ 正确排列（头尾重点，中间填充）：
[指令：请仔细阅读并严格依据以下文档回答]
[文档 D1]   ← 最高优先级放在开头
[文档 D2]
[用户问题]  ← 问题放在接近末尾，保证模型看到
[文档 D3]
[关键提示：回答必须引用 D1 中的具体段落]

4、第三步：选择性保留 - 如何”钉”住关键信息？

上下文窗口是流动的，新消息不断涌入，旧信息被挤向边缘。若对所有信息一视同仁，真正要紧的约束、事实很快就会随波逐流，我们需要一套分层与钉住机制，让关键内容像钉子一样牢牢固定在模型的可见区域内。

1）等级划分

不再平等对待每条信息，而是根据重要程度决定它们的去留：

核心思想：用 25% 的成本增加，换取 90% 的关键信息保留。

2）三个信息层次

任何一条信息进入上下文前，先问一句：“它属于哪一层？” 然后按照该层的策略去放置和保护，而不是无差别地追加到对话历史。

3） 钉住（Pinning）的实现思路

• 前缀固定区：把会话层的关键事实（如 重要约束：用户等级VIP，免除运费）放在 System Prompt之后、对话历史之前，确保每次请求都出现在模型视野的开头。只要前缀不变，KV Cache 就能持续复用。

• 特殊标记强化：用 <critical>...</critical> 或 ⚠️必守规则 等醒目符号包裹关键约束，防止模型在长上下文中滑向遗忘。这些标记还可以作为后续自动检测“是否遵守”的锚点。

• 末尾回填：对于本次请求最需要“最后一瞥”的事实（如刚刚查到的账户余额、上一轮提取的订单号），直接在用户消息或最后一条 assistant 消息之后追加一个简短的 [当前关键事实：余额 230 元，订单状态：待支付]。这比让模型在长长的历史里自己翻找可靠得多。

4）主动回填：别等模型忘，要主动喂

异步 Agent 或多轮业务流程中，可以设计一个简单的 “fact retriever” 触发器。每当检测到：

• 需要引用 5 轮之前的某个实体；
• 用户切换子任务，但共享相同约束；
• 上下文长度超过预设阈值；

就从外部存储中提取对应的“会话层事实单”，回填到当前请求的末尾。这样做不是多花钱，而是把原本可能浪费在重复推理和纠错上的成本，转移到精准的信息注入上。

5）冲突裁决

当新的指令与旧的事实冲突时（例如用户说“现在取消VIP资格”，但之前钉住了“用户是VIP”），分层本身就能提供裁决规则：临时层 > 会话层 > 固定层。新指令属于临时层，自动覆盖旧的会话层信息。可以在代码中通过简单的匹配逻辑，将旧事实移除或打上“已失效”标记。

5、第四步：RAG - 当”记性”需要”图书馆”

有时候，我们要处理的信息太多了（比如几百页的技术文档），黑板根本写不下。这时候就需要外挂大脑——RAG（检索增强生成）。

1）为什么“小黑板”不够用？

Manus 面对百万字级的技术文档时，对比了两种做法：

1. 全量写入：所有内容一次性塞进上下文。
   • 后果：黑板瞬间被占满，处理极慢，而且根据“中间迷失”理论，AI 根本记不住中间的内容。
   • 成本：约 $50/次，等待 15 秒。
2. 按需检索（RAG）：先去图书馆（数据库）查，只把相关的几段话抄到黑板上。
   • 后果：黑板很清爽，AI 聚焦于关键信息。
   • 成本：约 $0.5/次，等待 2 秒。

省了 99% 的钱，87% 的时间！

2）”查资料”的最佳实践

Manus 的经验总结：

• 每本书撕成多大片？ 500-1000 字效果最好。
• 一次查几本书？ 3-5 本，多了反而干扰。
• 多相关的书才查？ 相似度 > 0.7，避免“硬凑”不相关的内容。

6、第五步：压缩 - 如何让”小黑板”写得更密？

如果信息都很重要，实在删不掉，又不想查资料怎么办？ 那就只能把字写小点——这就是上下文压缩。

1）什么时候需要”缩写”？

• 检索回来的资料太厚（>2000 字）。
• 对话历史太啰嗦（占了 >80% 黑板空间）。
• 需要快速回答，不想让 AI 读长篇大论。

2）”缩写”的三种境界

7、系统整合：打造 AI 的“记忆宫殿”

• KV Cache：帮我们省钱
• 滑动窗口：帮我们腾位置
• 分级保留：帮我们留重点
• RAG：帮我们开外挂

1）像盖房子一样组装上下文

不要把上下文看作一堆乱糟糟的文字，而要把它看作一座分层的建筑。每一层都有它独特的功能和“居住规则”。

2）为什么这样设计最强？

地基（System Prompt）—— 解决“贵”的问题

• 矛盾：系统设定（你是谁、规则是什么）最长，每次都要发。
• 解法：把它放在最底层，利用 KV Cache 技术，只要不改动，AI 就能“背诵全文”。后续几百轮对话，这部分的计算成本几乎为 0。

支柱（Task Context）—— 解决“忘”的问题

• 矛盾：对话一长，AI 容易忘了最初的任务目标（比如“写一个贪吃蛇游戏”）。
• 解法：利用分级保留策略，把任务目标“钉”在第二层。不管聊了多少轮，这层永远不删，确保 AI 不忘初心。

顶层（Chat & RAG）—— 解决“乱”的问题

• 矛盾：又有新对话，又有查到的资料，混在一起容易晕。
• 解法：
  • 客厅（对话）：用滑动窗口管理，只留最近 5-10 句热乎的。
  • 图书馆（RAG）：资料用完即走，不占地方。

3）实战模板：直接抄作业

8、拿来即用的实战设计

1）场景 1：全栈工程师 Agent（长程记忆型）

核心挑战：任务周期长，容易忘了最初的需求和项目背景。 解决策略：System 层（身份）+ Task 层（钉死目标）+ Chat 层（滑动窗口）。

1. 系统提示词 (Layer 1 & 2)

# Layer 1: 身份设定 (System Prompt) - 永远不变，利用 KV Cache
你是一名资深的全栈工程师，精通 Python 和 Vue3。
代码风格：
- 变量命名严格遵守 PEP8
- 关键逻辑必须包含注释
- 优先使用项目已有的工具函数

# Layer 2: 任务锁定 (Task Context) - 任务期间不许删
当前任务：重构支付模块 (payment_module)
核心约束：
1. 必须兼容旧版 API 接口 v1.0
2. 数据库迁移脚本必须是幂等的
3. 截止时间：本周五

2. 上下文组装逻辑 (Pseudo-Code)

def build_engineer_context(user_input, chat_history, task_info):
    context = []
    
    # 1. 地基层：身份设定 (利用 KV Cache 缓存)
    # 这部分内容几百轮对话都不变，计算成本几乎为 0
    context.append(SYSTEM_PROMPT)
    
    # 2. 支柱层：任务锁定 (Pinned)
    # 无论对话多长，这部分永远插入在 System 之后
    context.append(f"当前任务：{task_info}")
    
    # 3. 检索层：代码片段 (RAG)
    # 根据用户的问题，去代码库里找相关的代码
    relevant_code = search_codebase(user_input)
    if relevant_code:
        context.append(f"参考代码：\n{relevant_code}")
    
    # 4. 交互层：对话历史 (Sliding Window)
    # 只取最近 10 轮，避免撑爆上下文
    recent_chat = chat_history[-10:] 
    context.extend(recent_chat)
    
    # 5. 最新输入
    context.append(user_input)
    
    return context

2）场景 2：智能客服 Agent（精准问答型）

核心挑战：成本敏感，且绝对不能胡说八道。 解决策略：System 层（强约束）+ RAG 层（动态注入）。

1. 系统提示词 (Layer 1)

# Layer 1: 身份设定 (System Prompt)
你是一名专业的电商客服专员。
回复原则：
1. 语气温柔、专业、简洁
2. **绝对禁止**编造事实，只根据[参考资料]回答
3. 如果资料里没有答案，请直接回答“非常抱歉，这个问题我需要转接人工客服”

2. 上下文组装逻辑 (Pseudo-Code)

def build_support_context(user_input):
    context = []
    
    # 1. 地基层：身份设定
    context.append(SYSTEM_PROMPT)
    
    # 2. 图书馆层：动态检索 (RAG)
    # 只有客服场景，RAG 才是主角，放在中间位置
    docs = vector_db.search(user_input, top_k=3)
    
    context.append("【参考资料开始】")
    for doc in docs:
        context.append(doc.content)
    context.append("【参考资料结束】")
    
    # 3. 交互层：极短的历史
    # 客服通常不需要太久远的记忆，保留最近 3 轮即可
    context.extend(get_recent_chat(limit=3))
    
    context.append(user_input)
    
    return context

三、AI 原生应用设计

为什么有些 AI 产品让人惊艳，而有些只是”套壳 ChatGPT”？ 差别不在于用了多强的模型，而在于产品是否从底层就围绕 AI 的特性来设计。AI 原生应用不是在传统应用上”加个聊天框”，而是重新思考用户交互、系统架构和产品逻辑的全新范式。

https://datawhalechina.github.io/easy-vibe/zh-cn/appendix/8-artificial-intelligence/ai-native-app-design

传统应用 vs AI 原生应用

• 传统应用：用户操作 → 确定性逻辑 → 确定性结果。每次点击”提交订单”，流程完全一样。
• AI 原生应用：用户意图 → AI 理解 → 概率性结果。同样的问题，每次回答可能略有不同。
• 核心转变：从”编写规则”到”描述意图”，从”确定性”到”概率性”，从”操作界面”到”对话界面”。

1、架构对比：两种完全不同的世界

传统应用的架构是”请求-响应”模型：用户点击按钮，后端执行确定性逻辑，返回确定性结果。整个过程可预测、可测试、可复现。

AI 原生应用则引入了一个全新的角色——大语言模型。它像一个”智能中间层”，接收自然语言输入，输出自然语言结果。这带来了架构上的根本性变化。

1）对比表

2）架构演进

架构演进的三个阶段

1. AI 增强型：在现有应用中嵌入 AI 功能（如自动补全、智能推荐）
2. AI 协作型：AI 作为核心交互方式，但仍有传统 UI 兜底（如 Notion AI、GitHub Copilot）
3. AI 原生型：整个产品围绕 AI 构建，去掉 AI 产品就不成立（如 ChatGPT、Cursor、Midjourney）

2、设计原则：AI 原生产品的”宪法”

设计 AI 原生应用不能照搬传统软件的设计思路。AI 的概率性、延迟性和不可预测性，要求我们建立一套全新的设计原则。

五大核心设计原则

1. 拥抱不确定性：AI 的输出不是 100% 可靠的，产品设计必须考虑”AI 可能出错”的情况。提供编辑、重试、反馈机制，让用户始终拥有控制权。
   • 每一次用户交互都是改进的机会。通过收集用户对 AI 输出的评价（点赞/点踩、修改记录、追问模式）持续优化 Prompt、微调模型、改进检索策略。
2. 渐进式信任：不要一开始就让 AI 做高风险决策。先从低风险场景建立用户信任，再逐步扩展 AI 的自主权。
3. 透明可解释：让用户知道 AI 在做什么、为什么这么做。展示推理过程、引用来源、标注置信度。
   • AI 不是黑盒魔法。用户需要知道 AI 为什么给出这个回答、依据了哪些信息、有多大把握。
   • 透明性建立信任，也帮助用户判断何时该相信 AI、何时该质疑。
4. 人机协作：AI 不是替代人，而是增强人。最好的设计是让 AI 做初稿，人做终审。
   • AI 擅长生成和建议，但不应该在高风险场景中自主决策。
   • 人机协作（Human-in-the-Loop）模式让 AI 负责草稿和推荐，人类负责审核和确认。
5. 优雅降级：当 AI 服务不可用或结果不理想时，产品仍然可用。永远有 Plan B。
   • AI 模型可能超时、返回错误、产生幻觉。优雅降级意味着：
   • 当 AI 不可用时，系统应该有兜底方案，而不是直接崩溃。这是 AI 原生应用与玩具项目的分水岭。

3、 Prompt 工程：AI 应用的”编程语言”

在传统应用中，你用代码告诉计算机做什么。在 AI 原生应用中，你用 Prompt 告诉模型做什么。Prompt 就是 AI 时代的编程语言——写得好，AI 表现惊艳；写得差，AI 胡说八道。

Prompt 设计的四层结构

1. 系统提示词（System Prompt）：定义 AI 的角色、能力边界和行为规范。这是”宪法”级别的指令，用户看不到但始终生效。
2. 上下文注入（Context）：通过 RAG 检索到的相关文档、用户历史记录等，为 AI 提供回答所需的背景信息。
3. 用户输入（User Message）：用户的实际问题或指令。
4. 输出格式约束（Format）：指定 AI 的输出格式（JSON、Markdown、特定模板），确保结果可被程序解析。

4、交互模式：AI 时代的用户体验

AI 原生应用催生了一批全新的交互模式。传统应用的交互是”点击-等待-查看”，而 AI 应用的交互更像是”对话-观察-调整”。

四种核心交互模式

1. 流式输出（Streaming）：AI 生成内容时逐字显示，而不是等全部生成完再展示。这大幅降低了用户的感知等待时间，也让用户可以在生成过程中判断方向是否正确。
2. 多轮对话（Multi-turn）：通过上下文记忆实现连续对话，用户可以逐步细化需求。关键挑战是上下文窗口管理和对话历史压缩。
3. 多模态交互（Multimodal）：支持文本、图片、语音、文件等多种输入方式，AI 也能输出图片、代码、表格等多种格式。
4. Agent 模式（Agentic）：AI 不只是回答问题，而是自主规划、执行多步骤任务。用户给出目标，AI 自行拆解步骤并逐一完成。

5、请求流程：一次 AI 调用的完整生命周期

当用户在 AI 应用中发送一条消息，背后发生了什么？理解这个完整流程，是构建可靠 AI 应用的基础。

请求处理的六个阶段

1. 输入预处理：校验用户输入、内容安全审核、敏感信息脱敏
2. 上下文组装：拼接系统提示词、检索相关文档（RAG）、加载对话历史
3. 模型调用：将组装好的 Prompt 发送给 LLM API，开启流式响应
4. 输出后处理：格式化输出、内容安全过滤、结构化数据提取
5. 结果缓存：对常见问题缓存结果，降低成本和延迟
6. 监控记录：记录 token 用量、响应时间、用户反馈，用于持续优化

6、总结

AI 原生应用设计不是简单地在传统应用上叠加 AI 功能，而是从架构、交互、工程实践等维度进行全面重构。

回顾本章的关键要点：

1. 架构转变：从确定性逻辑到概率性推理，AI 原生应用需要全新的架构思维
2. 设计原则：拥抱不确定性、渐进式信任、透明可解释、人机协作、优雅降级
3. Prompt 是核心：Prompt 工程是 AI 应用的”编程语言”，直接决定产品质量
4. 交互革新：流式输出、多轮对话、多模态、Agent 模式重新定义了用户体验
5. 全链路思维：从输入预处理到监控告警，每个环节都需要针对 AI 特性专门设计

三、AI 伦理、安全与合规

作为 AI 工程师，我们的目标不仅是让模型“变聪明”，更要让它“受控”。在企业级应用中，一次严重的提示词注入或隐私泄露，就可能导致整个项目的商业信任崩塌。

1、数据隐私保护：从源头脱敏