想入行 AI 应用开发被各种新名词吓到不敢动手的人我见过太多了。什么 Agent、RAG、Token、微调、向量数据库、工作流……刷一圈社交平台感觉要学的东西能排到明年去。但说句实在话真正做 AI 应用开发要啃的核心东西就 6 块。把这 6 块理清楚剩下的都是工具和熟练度问题。这篇文章是“01 开篇”先把整体地图给你铺开。我不会跟你聊什么深度学习数学原理也不会让你先从训练模型开始——那是算法工程师的活不是应用开发者的活。我们做应用的人核心任务是“把大模型的能力稳定、可控、有效地集成到产品里”所有技术选型都要围绕这件事展开。读完这篇你心里应该对“学什么、按什么顺序学、学到什么程度算够用”有个明确的框架。后面我会按这个框架拆成多篇每一篇都能直接落地。1. 先搞懂一件事AI 应用开发到底在开发什么很多新手第一步就走偏了以为 AI 应用开发 训练模型。于是抱着深度学习教材死磕反向传播学了三个月连个能跑的 Demo 都没有。我当年也走过这段弯路回头看不值得。AI 应用开发的核心工作用一句话概括是设计一套流程让大模型在接受指令和上下文之后稳定地产出你需要的业务结果。你是在“使用”和“编排”大模型不是在“创造”大模型。这个过程涉及怎么跟模型沟通Prompt、怎么给它喂资料RAG、怎么让它自己决定调用什么工具Agent、怎么把它包成服务对外提供API 与后端以及怎么保证它不胡说八道评估与运维。打一个比方传统开发是“自己造轮子”AI 应用开发是“老司机开别人的车”。你要懂的是油门、刹车、方向盘、路况判断而不是从头造一台发动机。所以学习路径应该是“以调用为中心以场景为驱动”的。这 6 块分别是大模型基础与 API 调用Prompt 工程RAG检索增强生成Agent 与工具调用应用框架与后端集成测试评估与应用运维下面逐块拆给你看每块我都会讲清楚“为什么重要、核心学什么、学到什么程度可以往下走”。你也不用一次性全学完按顺序来每一块学完都能做出一个小东西。2. 第 1 块大模型基础与 API 调用——先跑通最小闭环2.1 为什么这一块是起点很多人一上来就研究各种复杂架构结果连最基本的 API 请求都没发通过这是本末倒置的。大模型是 AI 应用唯一的“计算核心”你所有的工作都是围绕它展开的。不理解它的基本行为模式后面谈 Prompt、RAG、Agent 全部是空中楼阁。这一块的核心学习内容就三件事模型能力边界搞清楚什么是“生成式”、上下文窗口是什么、Token 怎么计算、温度参数Temperature影响什么API 的基本用法学会发一个 Chat Completion 请求处理返回结果理解流式输出和非流式输出的区别成本意识输入输出 Token 怎么计费缓存机制怎么用同样一个功能不同模型贵多少2.2 实操从注册到跑通第一个对话具体动作很简单随便选一家大模型服务商注册拿 Key然后把官方文档里的“快速开始”代码复制下来跑一遍。我用某云厂商的 API 举例虽然各家参数名略有差异但整体逻辑是通用的。# 一个最基本的大模型调用示例 from openai import OpenAI client OpenAI( api_key你的API_KEY, base_urlhttps://api.example.com/v1 ) response client.chat.completions.create( modelyour-model-name, messages[ {role: user, content: 用一句话总结什么是AI应用开发} ], temperature0.7 ) print(response.choices[0].message.content)跑通这个你就完成了 AI 应用开发的最小闭环。第二步是在这段代码上迭代比如加上多轮对话记忆把 messages 变成一个列表把每轮的 user 和 assistant 消息都追加进去。加个简单循环就能做命令行版聊天机器人。到这里“API 调用”这块就算站在门槛上了。提示不要一上来就看各家 SDK 的所有功能只学“发消息、接响应”这一个主链路就行。其他功能等用到再查效率高得多。2.3 学到什么程度可以进入下一块判断标准很简单你能不能不看文档独立写一个 20 行以内的多轮对话程序。能就过。不能再练习几次。别在这里停留太久因为模型的行为特性你在实际使用中会自然加深理解等做了几个真实场景的应用再回头总结会通透得多。另外建议顺手调研一下市面主流模型的差异不用太深知道各家擅长什么方向即可。这关系到后续做方案选型时你的决策依据。2.4 这块我踩过的坑第一是忽略 Token 计算。做了一个长文档问答把十万字的资料全塞进 Prompt 里一次调用要十几块钱响应还巨慢。后来才老老实实学 Token 折算一算才发现根本不能这么干这也是为什么后面必须学 RAG。第二是盲目调 Temperature。当时为了让回答更“有创意”把 Temperature 拉到 1.5结果模型开始胡言乱语。后来才明白温度控制的是随机性业务场景下通常 0.2 到 0.7 之间比较稳需要确定性输出就调低需要发散性内容再调高。这块入门不难但概念基础打牢一点后面能少走很多弯路。3. 第 2 块Prompt 工程——AI 开发的“编程语言”3.1 为什么 Prompt 工程是必修课如果说传统开发的编程语言是 Python、Java那么 AI 应用开发的编程语言就是自然语言也就是 Prompt。模型能不能按你的要求干活一半取决于模型本身的能力另一半取决于你怎么说。同一个模型同一道题Prompt 写得好的和写得差的结果可以差出好几个量级。很多人对 Prompt 工程有一个误解觉得就是“礼貌一点、说清楚一点”。没那么简单。它是有方法论、有结构、有调试手段的。一个合格的 Prompt 至少涉及角色设定、任务描述、输入输出格式约束、示例引导Few-shot、边界条件声明这几个方面。它不是“写一句话”而是“写一段逻辑严密的指令”。3.2 核心内容清单学这一块你需要掌握这些具体技能结构化 Prompt 编写把指令拆成角色、背景、任务、要求、输出格式几块模型理解成功率显著提升思维链引导Chain of Thought让模型分步骤推理再给出最终答案复杂计算和逻辑题的准确率大幅提升少样本学习Few-shot在 Prompt 里给一两个输入输出示例模型会模仿你的格式作答这是控制输出格式最有效的手段变量与模板化在 Prompt 里留出可替换的变量位做成适用于不同场景的模板方便复用常见陷阱规避防止 Prompt 注入、防止模型内容越权、防止输出不稳定3.3 实操对比同一个问题两种写法给你看个直观的例子。我让模型扮演客服处理用户退款申请。先看一个草率的 Prompt用户说我买的东西坏了想退款。 请回应他。模型确实能回应但回应内容完全随机可能说“亲可以退款呢”也可能长篇大论讲一遍退货政策而且语气不统一格式乱七八糟。再看一个结构化 Prompt角色你是一名电商平台的资深客服态度耐心专业。 任务处理用户的退款申请。 背景用户在平台购买了一双运动鞋收到后发现鞋底开胶。 要求 1. 先对用户的问题表达理解 2. 说明退款申请的受理条件 3. 引导用户提供订单号和商品照片 4. 语气亲切自然不超过100字 5. 按照“回应—条件—下一步行动”的结构输出。 用户消息我买的东西坏了想退款。第二种写法模型能稳定输出一个格式清晰、语气统一的客服回复只要你把“用户消息”替换成真实内容就能直接复用。这就是 Prompt 工程的价值不是碰运气而是通过结构设计和约束条件把模型的输出引导到稳定可控的轨道上。3.4 这一块建议学到什么程度能独立为一个业务场景设计一套稳定的 Prompt 模板并且能在输出结果不稳定时定位到是模型问题还是指令问题。最好再掌握一套 Prompt 调试方法比如先不加约束跑一遍看模型默认行为再逐步加约束看哪个约束起作用。很多新手一次把所有约束全塞进去出了问题不知道是哪句指令引起的没法迭代。这里分享一个我自己的调试习惯每写一个 Prompt 都建一个测试用例集里面放 5 到 10 条覆盖不同边界的输入每次改动 Prompt 都跑一遍回归。虽然前期麻烦但效果非常稳定这也是后面做复杂应用时最省心的保障之一。注意Prompt 不是一次性工作。模型版本更新、业务场景调整都可能让原本好用的 Prompt 失效所以调试能力比背诵模板更重要。4. 第 3 块RAG检索增强生成——让模型懂你的业务数据4.1 为什么必须学 RAG大模型的训练数据是有截止日期的而且你的业务知识、私有文档、最新资讯它一概不知道。你想做一个“公司制度问答机器人”直接拿大模型做它一定会胡编。这时候有两个方案一个是微调模型成本高、周期长、更新难另一个是 RAG也就是把资料提前切好存起来用户提问时先检索出相关片段再把片段和问题一起交给模型回答。对于绝大多数 AI 应用开发者来说RAG 是首选方案理由很简单不需要训练模型不需要 GPU资料更新只要重灌数据库就行。这也是当前 AI 应用落地中最主流的技术栈。4.2 核心知识拆解RAG 涉及的完整链路是文档解析 - 文本切片 - 嵌入向量化 - 存储与索引 - 相似度检索 - 重排序 - 上下文组装 - 大模型生成。每个环节都有讲究。文本切片切大了检索精度下降把无关内容混进去切小了语义信息不完整模型理解不充分。选择合适的嵌入模型直接决定向量化的质量相似度检索的 TopK 设置多少关系到喂给模型的上下文是“够用”还是“淹没”。这些细节都需要实际操作才能体会。4.3 实操过程从文档到问答系统的最小流程第一步准备一份 PDF 格式的操作手册几百页那种用文档解析器转成纯文本顺道清理掉页眉页脚和多余换行。第二步按固定长度切片比如每片 500 字、重叠 50 字把长文档拆成多个片段。第三步把每个片段用嵌入模型转成向量存进向量数据库。第四步用户提问时把问题也转成向量去数据库里做相似度检索取回最相关的几片。第五步把这几片内容拼到 Prompt 里加上“请根据以下资料回答问题”的指令发给大模型。这里给一个简化伪代码帮你理解链路是怎么串起来的用户提问 - 问题文本 - 嵌入模型转成向量 - 向量数据库相似度检索返回Top5片段 - 组装Prompt资料片段 用户问题 - 调用大模型 - 输出答案做完这个流程你就拥有了一个真正“懂你资料”的问答系统而不是一个只会泛泛而谈的聊天机器人。再往后可以优化检索效果、加混合检索、做重排序但先把主链路跑通是最重要的.4.4 学习深度建议与一个我踩过的大坑RAG 这块前期把“切分、嵌入、检索、生成”四个节点做通即可不要一上来就钻研各种高级优化技巧。等你发现检索结果明显不准了再回来研究 Embedding 模型选型、切分策略调优、混合检索和重排序那时候你已经知道“为什么要优化”学习效率完全不同。我必须重点提醒一个常见的隐蔽问题切片策略必须结合业务场景设计。我之前做一个合同审核助手按固定 500 字硬切结果很多条款被拦腰截断检索到下半段时根本不知道它是哪份合同、约束条件是什么回答自然错误百出。后来改成按章节和条款边界切再给每片加上“所属合同名称、条款编号”等元数据检索准确率立刻上来了。文档切片不是简单按字数切而是要让每个切出来的片段“自成一体”包含足够的上下文语义。5. 第 4 块Agent 与工具调用——让模型从“会说话”到“会办事”5.1 为什么 Agent 是 AI 应用开发的分水岭前 3 块学完你能做的应用是“你问我答”本质上是把大模型当成一个聪明的输入输出转换器。到 Agent 这一块玩法完全变了你给模型一个目标它可以自己决定调用什么工具、按什么顺序执行、遇到问题怎么调整。这也是大家常说的“AI 从被动响应走向主动执行”。Agent 的核心机制是“模型自己决定行动”这背后的关键能力叫做“工具调用Function Calling / Tool Use”。模型在回答你之前会先判断“我需要查询天气”然后在系统预设的工具列表里选一个带上参数发起调用拿到工具返回的结果之后再综合生成最终回复。这个过程可以循环多次直到它认为任务完成了。5.2 Agent 架构里必须掌握的能力学这一块你需要掌握这些核心点工具定义把外部能力封装成模型可以理解的“函数”写好函数名称、功能描述、参数说明。描述写不好模型就不知道什么时候该用这个工具任务规划与执行循环理解 ReAct 模式思考-行动-观察知道模型如何一步步逼近最终目标多工具协同让模型在多个工具之间做选择比如既能查数据库又能发 HTTP 请求还能算数学题安全边界与控制设定 Agent 的权限范围、允许调用清单、最高迭代次数防止它在执行中跑偏记忆与状态管理多轮交互中的上下文保留以及长期记忆怎么存5.3 实操示例给 Agent 封装一个计算工具最低成本的实践方式就给模型接一个“计算器”工具。模型本身就擅长语言生成但算数并不总是准五位数乘法经常出错。你封装一个准确的 Python 计算函数用工具调用的格式提供给模型它会自己判断“这个数学问题我自己搞不定应该用计算器工具”然后发起调用拿到正确结果再组织语言回复用户。工具描述写成这样模型就能精准理解工具名称calculate 功能描述当用户需要数学计算时使用此工具支持加减乘除、幂运算和数学函数。 参数说明 expression (string必填)要计算的数学表达式如 12*345678 返回结果数字字符串实现完之后你可以在一个 50 行左右的 Python 脚本里模拟整个循环接收用户问题 - 调用大模型 - 模型返回工具调用请求 - 执行工具 - 把结果喂回模型 - 模型生成最终答案。这个简单的循环跑通你就理解了 Agent 的本质不是一层高深莫测的黑魔法而是一个“循环决策”的工程实现。提示做 Agent 的第一原则是“把工具描述写到小学生都能看懂”。很多模型用不好工具不是模型笨是工具描述含糊不清模型不知道它存在、不知道何时用、不知道参数格式。5.4 这块的最终目标学完 Agent你应该能独立设计一个“目标驱动型”的小应用比如一个能根据用户需求自动查资料、算数据、汇总成报告的多步骤助手。你不一定要一开始就上多复杂的架构重点是理解“决策循环”怎么实现、怎么控制。这个基础打牢了后面那些热门的自动化工作流、多智能体协作都只是这种基础能力的进阶组合。6. 第 5 块应用框架与后端集成——把模型能力变成产品6.1 为什么框架学习放在第五位我见过不少新人第一周就在学各种重型框架结果连基础 API 都没搞熟。为什么不建议这么做因为框架是“别人封装好的最佳实践”你直接上手框架遇到问题根本不知道底层是哪个环节出了问题排查起来一地鸡毛。把前 4 块基础打牢再理解框架的设计思路就非常快你已经能看懂框架“帮我做了什么、省了哪些事”而不是把它当成黑盒。AI 应用框架的价值在于把上面讲的 Prompt 管理、工具调用、记忆存储、文档加载等脏活累活统一起来让你专注于编排业务逻辑。目前主流框架大致分两类一类是低代码/可视化工作流平台适合快速搭原型和简单业务另一类是代码优先的开发框架灵活度高适合复杂业务集成。6.2 这一块需要掌握的核心技能在应用框架与后端集成这一块重中之重是后端工程能力。AI 应用终究是一个 Web 服务用户从网页或客户端发起请求你的后端接收请求、组装 Prompt、调用模型、处理流式输出、把结果返回给前端这个链路里涉及大量传统后端技术。你需要掌握API 服务设计怎么把自己的 AI 能力包装成标准 HTTP 接口包括请求参数、鉴权、错误处理流式输出处理大模型生成内容需要时间要支持 SSE 或者 WebSocket 做流式推送提升用户体感异步任务设计耗时长的大模型任务要设计任务队列后台执行、前端轮询或者回调通知结果状态与记忆存储会话数据要落库用户的历史消息要能随时拿出来组装上下文基础部署知识至少会本地跑服务搞清楚依赖管理和环境隔离6.3 实操路径把自己做的 Agent 包成服务建议的练手路径是把你之前写的 Agent 程序包成一个 FastAPI 服务提供一个/chat接口前端或者命令行工具可以往里发消息服务端负责调用大模型、管理对话历史把最终结果返回。再往后加一个 Option把对话记录存到 SQLite 或者 Redis支持多用户隔离——到这里你的“AI 玩具”已经变成“AI 产品原型”了。我做这个阶段的练习时有一个List特别值得提不要把大模型的调用逻辑和业务代码耦死。也就是说在代码里抽象出一个模型接口层今天用的是某家厂商的模型明天想换另一家或者换开源模型只改配置就行不需要把业务代码翻个底朝天。这个习惯在后续对接不同模型时省了我无数时间。6.4 学到什么程度可以算过关标准是你能独立把一个带数据库、多用户、流式响应的 AI 应用部署到公网服务器让别人访问并使用。到这里你不再是“会用大模型的调包侠”而是一个有能力交付完整产品的 AI 应用开发者了。很多纯算法转过来的人容易在这里卡住因为他们不熟悉用户体系、数据库、并发这些工程概念。反过来如果你的本职工作就是后端开发这一块对你来说基本是无缝衔接重点只在补充“大模型调用特征”相关的知识比如流式处理和长耗时请求的处理方式。7. 第 6 块测试评估与应用运维——让应用跑得久、跑得稳7.1 为什么最后才讲这块因为前面所有功能开发完了你才会真正体会到评估和运维有多重要。一个只在你自己电脑上跑通的 Demo和一个有真实用户使用的线上应用是完全不同的物种。真实用户会问出你没预料过的问题模型会抽风外部 API 会不稳定费用可能失控。没有评估和运维意识这些坑分分钟能把你埋了。传统软件测试有明确的对错标准AI 应用测试不一样回答是开放式的没有标准答案你的任务反而是“定义什么叫好”。可能同一道题模型昨天答得很好今天换了个模型版本就答偏了。所以 AI 应用的评估是一套专门的方法论。7.2 核心内容清单这一块需要掌握的内容包括评测集建设设计一组覆盖常规场景和边界场景的测试用例用例里要有预期行为描述不一定要逐字死板但要有明确的好坏判断标准评估指标理解常见的相似度指标、忠实度、相关性等概念不用精通数学推导但要明白每一种指标衡量什么怎么指导调优线上监控关注错误率、平均响应延迟、Token 消耗费用等核心指标。一次用户问题消耗了多少成本必须心里有数模型版本管理与回归测试模型厂商更新版本你的应用功能可能变好也可能变坏因此每次切换模型版本前必须跑一遍评测集确认没变差再切灰度发布与紧急回滚新功能上线不是大面积推而是先让一小部分流量使用有问题能立刻回滚。这一条不仅适用于业务需求大模型相关配置的变更同样适用7.3 实操经验一个成本监控的例子举一个很实际的场景。我做过一个文档总结工具上线一周后发现成本比预期翻了三倍。排查后发现原因是一个用户上传了一篇超长文档系统把全文拆成了几十个片段每个片段都单独调用一次模型总结碎片化调用导致成本直线上升。这就是没有成本监控的后果。后来把所有请求的 Token 消耗都做日志记录按用户、按功能、按天聚合统计每两天看一次报表成本异常才能第一时间发现。再比如你用 RAG 搭的问答系统用户总问一些检索不到答案的问题系统不应该硬答而是应该配置“超出知识范围”的兜底话术。这个能极大避免模型胡编乱造。这种看似小细节的处理实际决定了用户对产品的信任度。7.4 这一块的目标学到这个阶段你已经不是“完成功能就好”的状态了。你考虑的是这个功能的响应速度多少算及格一次请求成本是多少模型升级了我的效果会不会变用户问倒模型了我怎么兜底当这些指标你能如数家珍的时候你已经是一名合格的 AI 应用开发工程师了而不是随便调调接口的入门玩家。我会强烈建议你在第一个线上项目里就建立一套最简评估流程不要等到用户投诉才动手哪怕初始只有十几个用例也能帮你避免大量线上事故。8. 实操心法从第 1 块到第 6 块的最短学习路径六块内容都讲完了给你一条最短的可执行路径每家情况不同但大方向是通用的。第一个月搞定第 1、2 块目标是跑通 API、熟练改写 Prompt做一个主题明确的聊天机器人第二个月主攻第 3 块 RAG给自己的聊天机器人“喂”一份真实资料做成问答助手这是当前岗位需求最集中的技能之一第三个月学第 4 块 Agent把问答助手升级成能调用搜索、计算、数据库工具的任务助手第四个月学第 5、6 块把任务助手做成一个多用户服务补齐评估、监控、成本管理形成完整交付过程中持续跟进比如看看开源框架更新、追踪主流模型动态但不要见一个新东西就学核心六块不变其他都是围绕它们的延展这个路径里投入产出比最高的两块是 Prompt 工程和 RAG它们在大多数实际项目中都是直接决定成败的技术。Agent 是当前热点的核心各种工程化的机会很多技能溢价也高。框架和后端决定你能不能把前面积累的技术真正变成一个能用的产品运维和评估决定产品的生命周期和质量。常见问题速查表问题大概率原因解决方向模型回答不相关Prompt 缺乏约束和示例用结构化 Prompt 方法重写加 Few-shot 示例输出格式老是乱没在 Prompt 中明确格式要求给出期望输出模板或做一层输出解析校验长文档问答瞎编直接塞全文或切片不合理改用 RAG把相关资料检索出来再生成工具调用总是不触发工具描述不规范模型不理解重写工具名称、描述、参数说明参考官方最佳实践应用上线后悄悄变差缺少评估集与回归流程建立评测集模型升级前先跑回归设置告警基线费用突然飙升调用设计不合理比如拆得太碎或循环无上限记录 Token 消耗设置调用次数上限和熔断阈值9. 我的几点额外建议在文章最后分享几个我在实践中的经验和观察不算结论纯属个人体会。第一条是不要追求“用最新”。AI 领域每天都有新框架、新模型、新概念出现但不是每个都值得你扑上去。真正让你站稳脚跟的始终是那六块基本功。技术会迭代基础不会过时。新东西来了你能迅速判断它解决的是六块里的哪一块问题值不值得用这才是核心能力。第二条是尽快做出一个端到端的作品。学习过程中功能完整性比深度重要。哪怕它很简陋但完整跑通了“用户输入 - 后端处理 - 模型调用 - 结果返回”全链路你对 AI 应用开发的理解就会比只看教程强出一个量级。从第一块学到第四块中间每隔两周就应该给自己安排一个能发布的小项目用输出来倒逼输入。第三条是把“最坏情况”想清楚再上线。我自己做过一次线上事故复盘印象极其深刻某个 Agent 在循环里连续调用多次工具费用直接飙到几十块整个系统被一个用户“折腾”得几乎不可用。从那以后所有上线功能都要先想一想——如果用户疯狂点击、如果模型连续调用、如果数据量爆炸系统撑得住吗把上限和兜底设计好才能安心睡个好觉。这套学习框架是我自己琢磨了很久才理出来的希望你不用再像我当初一样绕远路。后面我会把这六个模块逐个展开每个模块都配合可运行的代码和完整设计思路。既然已经看到这里不如就从一个最简单的 API 请求开始动手试一试才知道这扇门后面到底藏着什么。