学 AI 应用开发,别只背概念

很多人开始学 AI 应用开发，是从一串名词开始的。

LLM、RAG、Agent、MCP、Prompt Engineering、Context Engineering、评测、模型网关、AI Coding。

这些词都重要。

但如果只是一个个背下来，很容易出现一种错觉：好像自己已经知道很多，但一到真实项目，还是不知道从哪里下手。

这篇文章想讲的就是这件事：

AI 应用开发不是概念表，而是一条工程链路。

最近我在看 AIGuide。

它是 JavaGuide 作者 Snailclimb 新维护的一套 AI 应用开发、AI 编程实战与面试指南。

我看完总览之后，最强烈的感受不是“又多了一份 AI 教程”。

而是它把一件很容易被讲散的事情，重新串成了一条开发者能理解的路线。

先理解 LLM 的基本工作方式。

再理解 RAG、Agent、Prompt、评测和系统设计。

最后把 AI Coding 放回日常研发流程。

这条路线对开发者很重要。

因为现在很多人学 AI，问题不是资料不够，而是资料太碎。

你今天看一篇 Prompt 技巧，明天看一个 RAG 项目，后天看一个 Agent demo，再过几天又刷到 Claude Code、Codex、Cursor、Trae。

每个东西都像有用。

但它们之间到底是什么关系？

一个真实 AI 应用从 demo 到上线，到底要补哪些工程环节？

如果这个问题没想清楚，概念越多，反而越乱。

一、很多人知道很多 AI 名词，但还是不会做 AI 应用

先看一个很常见的场景。

团队想做一个内部知识库问答。

一开始很顺。

接一个大模型 API，写一句 prompt，把文档丢进去，让它回答问题。

Demo 很快就能跑。

但真实使用时，问题马上出来：

• • 文档太长，塞不进上下文
• • 回答看起来流畅，但引用不到来源
• • 有些问题答非所问
• • 文档更新以后，旧答案还在
• • 用户问法一变，召回结果就漂
• • 没有人知道这次回答到底该不该算成功
• • 成本越来越高，但没人能归因到具体功能

这时候你会发现，单独知道一个 LLM 或一个 RAG 概念，并不能解决问题。

你要理解的是一整条链路。

模型怎么调用。

知识怎么进入模型。

任务怎么被拆开推进。

上下文怎么组织。

结果怎么评测。

系统怎么上线。

成本、安全、权限、审计怎么治理。

这才是 AI 应用开发。

不是把概念排成一张表，而是把它们放回工程位置。

二、LLM 是能力底座，但不是应用本身

LLM 很重要。

没有模型的语言理解、生成、推理能力，后面很多事情都无从谈起。

但开发者一旦要把它接进系统，就不能只把它当成一个聊天接口。

你要关心很多更具体的问题：

• • Token 怎么计费
• • 上下文窗口怎么影响输出
• • Temperature、Top-p 这些采样参数什么时候该调
• • 流式输出怎么处理
• • 超时以后怎么重试
• • 用户取消请求以后后端怎么中断
• • 模型返回的 JSON 不合法怎么办
• • Function Calling / Structured Outputs 的契约在哪里校验

这些问题都不性感。

但它们决定了一个 AI 功能是不是能进业务系统。

很多 Prompt Demo 之所以看起来很快，是因为它绕开了这些工程问题。

真正上线时，模型调用会变成一条调用链。

有请求、有响应、有超时、有重试、有日志、有成本、有错误分类，也有服务端校验。

所以第一步不是“会不会调模型”。

而是要从一开始就意识到：

LLM API 不是聊天入口，而是一条工程调用链。

三、RAG 解决知识进入模型的问题

如果 LLM 是能力底座，RAG 解决的就是另一个问题：

模型不知道你的私有知识怎么办？

企业文档、项目资料、接口说明、会议纪要、历史工单，都不在模型参数里。

不能每次都靠人工复制粘贴，也不能指望模型凭空知道。

RAG 的思路很自然：

先检索相关材料，再把材料放进上下文，让模型基于这些材料回答。

但真正做起来，你会发现 RAG 最难的地方往往不是向量库。

而是整条知识链路：

• • 文档怎么解析
• • PDF、表格、图片怎么处理
• • Chunk 怎么切
• • 召回怎么评估
• • 要不要混合检索
• • 什么时候需要 Rerank
• • 文档更新以后怎么增量同步
• • 旧版本怎么回滚
• • 错误答案怎么追溯到召回片段

这也是我看 AIGuide 时觉得值得入库的原因。

它没有把 RAG 只讲成“Embedding + Vector DB”。

它把文档处理、索引、更新、优化和评测都放进去了。

这就更接近真实系统。

顺便说一句，这也能解释我为什么一直维护这个 Personal Knowledge OS。

RAG 更像查询时临时合成。

而这个知识库更像摄入时持续合成。

前者适合面对大量材料快速问答。

后者适合把一个领域长期沉淀成可复利的知识图谱。

两个都重要，但它们解决的问题不一样。

四、Agent 解决任务如何被持续推进的问题

有了模型调用，有了知识检索，还不等于有了 Agent。

普通 LLM 应用更像一次请求响应。

用户问，模型答。

Agent 关心的是另一件事：

一个任务如何被持续推进。

它要处理目标、计划、工具、状态、记忆、检查点和人工确认。

比如你让 AI 帮你“排查一个线上慢查询问题”。

这不是一句 prompt 能完整解决的。

它可能要先读告警，再看慢查询日志，再分析 SQL，再查索引，再判断是否需要改代码，再生成修复建议，再跑测试，最后还要把风险和回滚方案写出来。

这就不是一次回答。

这是一条任务链。

所以 Agent 的重点不是“会不会调工具”。

真正关键的是：

• • 它有没有清楚的目标
• • 它能不能保存中间状态
• • 它知道什么时候该继续，什么时候该停
• • 它能不能留下过程轨迹
• • 它会不会在高风险节点等人确认

这部分和我之前写 Hello-Agents 系列时的判断是一致的。

Hello-Agents 更适合系统理解 Agent 是什么。

AIGuide 更适合把 Agent 放回开发者工程路线里：

它不是单独一个热词，而是 AI 应用从问答走向任务执行时必须面对的一层。

五、Prompt 之后，真正要学的是 Context Engineering

很多人学 AI，最先学 Prompt Engineering。

这没问题。

但如果停在 prompt，很快会遇到瓶颈。

因为 prompt 只是上下文的一部分。

真正影响模型输出的，还有很多东西：

• • 系统指令
• • 用户目标
• • 项目规则
• • 检索材料
• • 工具返回结果
• • 历史状态
• • 错误日志
• • 验收标准
• • 人工限制

这些信息怎么进入模型？

哪些应该常驻？

哪些应该按需加载？

哪些应该压缩？

哪些绝对不能混进当前任务？

这就是 Context Engineering 的问题。

在 AI Coding 里，这件事尤其明显。

你让 Codex 或 Claude Code 改一个功能，效果好不好，经常不只取决于模型。

还取决于它有没有看到：

• • 项目的 AGENTS.md
• • 相关源码
• • 错误日志
• • 测试命令
• • 验收标准
• • 不能碰的边界

如果上下文给少了，它会猜。

如果上下文给多了，它会乱。

所以真正要学的不是“神奇 prompt”，而是设计一套信息供给系统。

这也是为什么我觉得 AIGuide 适合输出式学习。

它把 Prompt、Context、Skill、MCP、AI Coding 放在一起看，而不是把它们拆成互不相关的技巧。

六、评测和系统设计决定 AI 应用能不能上线

Demo 阶段，很多人靠感觉。

“这个回答看起来不错。”

“这个 Agent 好像能跑。”

“这个 RAG 大部分时候还可以。”

但生产系统不能只靠感觉。

你至少要回答几个问题：

• • 什么样的回答算正确
• • 哪些问题必须引用来源
• • 哪些失败可以接受
• • 哪些失败必须阻断上线
• • 换模型以后有没有退化
• • prompt 改了以后有没有影响旧场景
• • 成本升高是哪个功能导致的
• • 出错后能不能回放 trace

所以评测不是上线前打个分。

评测应该是 AI 应用的回归系统。

Golden Set、LLM-as-Judge、人工抽检、Trace 回放、CI 回归、线上灰度，都应该进入同一条质量链路。

再往后，就是系统设计。

只要 AI 功能进入真实业务，模型网关、限流、fallback、成本归因、审计、安全、权限都会冒出来。

这些问题没有一个是 prompt 能解决的。

它们属于工程系统。

这也是 AI 应用开发和“玩模型”的分水岭。

七、AI Coding 是这条链路回到开发者日常的地方

AIGuide 还有一条很重要的线：

AI Coding。

Claude Code、Codex、Cursor、Trae、Qoder 这些工具，表面上看是在帮你写代码。

但我现在越来越觉得，它真正改变的不是“代码谁敲”。

而是整个研发流程。

你要重新思考：

• • 需求怎么拆给 AI
• • 上下文怎么准备
• • 什么时候用 CLI，什么时候用 IDE
• • 哪些规则应该写进 AGENTS.md 或 CLAUDE.md
• • 哪些流程应该沉淀成 Skill
• • 代码生成以后怎么测试
• • diff 怎么 review
• • 提交粒度怎么控制
• • 出问题怎么回滚

所以 AI Coding 不是另一条完全独立的线。

它是 AI 应用开发回到开发者日常的地方。

你学 LLM，是为了理解能力底座。

你学 RAG，是为了让知识进入模型。

你学 Agent，是为了让任务能持续推进。

你学 Context Engineering，是为了让模型看到正确的信息。

你学评测和网关，是为了让系统可上线、可观测、可回滚。

最后你把这些东西带回研发流程。

这才是 AI Coding 的真正意义。

八、这个系列准备怎么学

所以，我不准备把 AIGuide 当成一份目录来复述。

那样意义不大。

我更想把它当成输入材料，做一组输出式学习。

每篇只解决一个核心问题。

先读，再入库，再输出。

接下来这组文章会按这条路线走：

1. 1. 学 AI 应用开发，别只背概念
2. 2. LLM API 不是聊天接口，而是一条工程调用链
3. 3. RAG 最难的不是向量库，而是知识链路
4. 4. Agent 不是会调工具，而是能推进任务
5. 5. Prompt Engineering 之后，真正要学的是 Context Engineering
6. 6. 评测不是打分，而是 AI 应用的回归系统
7. 7. 大模型网关，才是 AI 应用进入生产的分水岭
8. 8. AI Coding 不是让 AI 写代码，而是重组研发流程
9. 9. Spec、Skill、Agent，怎么组成一条可控的软件生产线
10. 10. 开发者转向 AI 应用工程，真正要迁移的是工程判断力

这不是一套“AI 名词解释”。

它更像一条开发者升级路线。

你不一定要转算法岗。

也不需要一上来训练模型。

但如果你想把 AI 放进真实项目，就需要把已有的工程判断力迁移过来。

接口、缓存、队列、数据库、网关、观测、测试、安全，这些经验并没有失效。

它们只是开始围绕 LLM、RAG、Agent 和 AI Coding 重新组合。

这也是我决定把 AIGuide 放进知识库，并且按输出式学习继续写下去的原因。

因为现在真正稀缺的，不是再多知道几个 AI 名词。

而是能把这些名词放回工程链路里，知道它们分别解决什么问题，也知道它们解决不了什么问题。

学 AI 应用开发，别只背概念。

先把链路看清楚。

来源说明

本文内容主要基于 Snailclimb / JavaGuide 的开源项目 AIGuide 整理，并结合我自己的理解、知识库实践和 AI Coding 经验做了重写和串联。原项目与在线阅读地址如下：

• • https://github.com/Snailclimb/AIGuide
• • https://javaguide.cn/ai/
• • https://javaguide.cn/ai-coding/

如果你也在系统学习 AI 应用开发、RAG、Agent、Context Engineering、评测、系统设计和 AI Coding，欢迎继续关注这个系列。