K Kiara's Tech Planet Tech Planet
AI / AIEngineering

什么是 AI 工程？从「调 API」到「AI 基建」的鸿沟

AI 工程 AI 基建 LLM 应用 Prompt 工程 Eval 可观测性

📚 前言

先讲个真实场景。

面试的时候被问到一句话：

「关于 AI 开发，你有没有做过什么基建？」

这句话杀伤力很大。

因为大部分人对 AI 开发的理解，停在这一步：

1
2
3
拿到 API Key
调一下 chat/completions
把模型返回的文字渲染到页面上

这当然没错，但它回答不了「基建」两个字。

面试官真正想问的是：

当 AI 功能要上线、要稳定、要省钱、要持续迭代的时候，你在「调 API」和「能用的产品」之间，补了哪一层？

这一层，就是 AI 工程。

这篇是整个专栏的开篇，目标只有一个：

把「AI 工程到底在解决什么」讲清楚，并且建立起后面所有文章共用的那张「地图」。

一、「调通 API」为什么不等于「做了 AI 工程」

我们先把「调 API」这件事的真相摊开。

写一个 demo，代码大概是这样：

1
2
3
4
5
6
const res = await client.chat.completions.create({
  model: "xxx",
  messages: [{ role: "user", content: input }],
});

return res.choices[0].message.content;

这段代码在 demo 里跑得很好。

但当它要变成「线上功能」，下面这些问题会一个接一个砸过来：

  • 用户输入很长，超了 token 上限怎么办？
  • 模型偶尔胡说八道，怎么发现、怎么兜底？
  • prompt 改了一版，效果到底是变好还是变差？凭感觉吗？
  • 这个月 token 花了多少钱？哪个功能最烧钱？
  • 模型偶尔超时、限流、报错，整个功能就挂了？
  • 模型厂商涨价 / 下线模型，要换一家，改动有多大？

你会发现：

demo 解决的是「能不能跑通」，工程解决的是「能不能长期、稳定、可控地跑」。

这个差距，和前端从「写个页面」到「前端工程化」是一模一样的。

只学会调 API，等于只学会写 <script> 标签。

二、AI 工程到底在解决什么问题

把上面那堆问题归一下类，AI 工程的核心其实就是在和 LLM 的几个「天生缺陷」对抗。

LLM 和我们熟悉的普通函数完全不同：

1
2
普通函数：输入确定 → 输出确定，可测试、可调试、可预期
LLM    ：输入确定 → 输出不确定，概率性、黑盒、还会变

围绕这个根本差异，AI 工程要解决五件事。

1. 不确定性（Quality）

模型输出是概率性的，同样的输入可能给出不同结果，还可能一本正经地胡说八道。

工程手段：结构化输出、约束、重试、评测（Eval）、回归测试。

一句话：把「碰运气」变成「有质量基线」。

2. 上下文限制（Context）

模型的 context window 是有限的，而且越长越慢越贵。

工程手段：上下文工程、token 预算、压缩裁剪、检索增强（RAG）。

一句话：在有限的「窗口」里，塞进最该塞的信息。

3. 成本与性能（Cost & Latency）

每一次调用都在花钱，每一个 token 都有延迟。

工程手段：缓存（含 Prompt Cache）、流式输出、模型路由（贵的活给大模型、简单的活给小模型）。

一句话：又快又省，还不牺牲体验。

4. 可靠性（Reliability）

模型会超时、会限流、会报错，厂商还会涨价、下线模型。

工程手段：AI 网关、降级、限流、多模型容灾。

一句话：别让单点的模型，拖垮整个系统。

5. 可观测与可迭代（Observability）

prompt 改了效果是好是坏？线上质量在掉吗？钱花哪了？

工程手段：Tracing、token/成本监控、Prompt 版本管理、Prompt CI/CD。

一句话：让 AI 功能像普通服务一样「看得见、改得动」。

把这五件事连起来看，「AI 基建」的轮廓就出来了：

AI 基建 = 在「业务代码」和「模型 API」之间，专门处理 质量、上下文、成本、可靠性、可观测 的那一整套工程能力。

三、AI 应用的全景：一次请求都经过了什么

为了让后面每篇文章都能挂得上，我们先画一张「地图」。

一个生产级 AI 功能，一次请求大致会穿过这几层：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
用户输入
   │
   ▼
┌─────────────────────────────┐
│  应用层（业务逻辑 / 前端 UI）        │
└─────────────────────────────┘
   │
   ▼
┌─────────────────────────────┐
│  上下文层                          │
│  Prompt 模板 + RAG 检索 + 历史裁剪    │
└─────────────────────────────┘
   │
   ▼
┌─────────────────────────────┐
│  编排层                            │
│  Agent / 工具调用 / 工作流           │
└─────────────────────────────┘
   │
   ▼
┌─────────────────────────────┐
│  网关层                            │
│  路由 / 缓存 / 限流 / 降级           │
└─────────────────────────────┘
   │
   ▼
┌─────────────────────────────┐
│  模型层（LLM API）                  │
└─────────────────────────────┘
   │
   ▼
   贯穿全程：评测 Eval + 可观测 Observability

注意最后一行：评测和可观测不是某一层，而是贯穿全链路的。

这张图，基本就对应了本专栏的四大支柱：

  • LLM 应用基建 → 上下文层 + 网关层
  • Agent 与工具调用 → 编排层
  • RAG 与知识库 → 上下文层里的检索
  • 评测与可观测 → 贯穿全程的那条线

后面每一篇，都是在放大这张图里的某一块。

四、AI 工程 vs 传统工程：像，但不一样

如果你有前端 / 后端工程化的底子，这里有个好消息：

AI 工程的「方法论」和传统工程高度相通，迁移成本不高。

传统工程 AI 工程对应
单元测试 / 回归测试 Eval 评测集 / 回归
日志 / APM / Tracing LLM Tracing / token 监控
配置管理 / 版本管理 Prompt 版本管理
CI/CD 流水线 Prompt CI/CD
网关 / 限流 / 熔断 AI 网关 / 模型路由降级
缓存 语义缓存 / Prompt Cache

但有三个地方是 AI 工程独有的、最反直觉的：

  1. 测试对象是概率性的。
    传统断言是 expect(x).toBe(y)；AI 里你往往只能断言「足够接近」「符合某种标准」，于是诞生了 LLM-as-judge 这种「用模型评模型」的玩法。

  2. prompt 是一种新的「代码」。
    它没有类型、没有编译器，改一个词都可能让效果天翻地覆 —— 所以才需要把它纳入版本管理和 CI。

  3. 成本是一等公民。
    传统接口你很少按「字数」付费，但 LLM 是按 token 计费的，成本会直接反过来影响你的架构设计（比如要不要上 RAG、要不要换小模型）。

理解了这三点「不一样」，你就抓住了 AI 工程的精髓。

五、回到那个面试题：该怎么答

绕了一圈，我们回到开头那句话。

如果再被问「AI 开发做过什么基建」，与其只说「我调过 XX 模型」，不如顺着这张地图答：

我把 AI 功能拆成几层来做工程化 ——
上下文这块做了 Prompt 模板化和 token 预算控制；
调用这块走了统一网关，做了缓存和失败降级；
质量这块搭了一套 Eval 评测集，prompt 每次改动都跑回归；
线上做了 token 成本和调用链的监控。

哪怕你只真正做过其中一两块，用这套框架去组织你的经历，呈现出来的就是「有体系」而不是「只会调 API」。

这也正是这个专栏接下来要逐块填实的内容。

小结

这一篇我们只做了一件事：建立心智模型。

记住三句话就够了：

1
2
3
1. 调通 API 只是起点，AI 工程是补上「质量、上下文、成本、可靠性、可观测」这一层
2. AI 基建本质是在「业务」和「模型」之间，对抗 LLM 的概率性、有限上下文和高成本
3. 方法论可以从传统工程迁移，但「概率性测试、prompt 即代码、成本一等公民」是它独有的

下一篇，我们把第三节那张架构图彻底拆开 ——

《LLM 应用全景架构：一次请求从前端到模型再回来的完整链路》

把每一层「具体在做什么、为什么需要」讲透，作为整个专栏的骨架。