AI工程从零入门：提示工程、RAG与Agent实战路线

最近在复盘一个绕不开的问题：如果一个人真的想“从零进入AI工程”，到底该怎么走，才不会一头扎进论文和框架的海洋里出不来。

这个标题“ai-engineering-from-scratch”很有意思，from scratch可以理解成“从零开始自己动手造轮子”，也可以真的对应那个图形化编程工具Scratch。两条线放在一起看，恰好是我认为AI工程学习里最该并行的两件事：一是掌握底层原理，二是获得工程手感。这篇文章就把这两件事揉在一起讲明白，适合刚开始接触AI、想走工程方向的新人，也适合那些调过API但总感觉没入门的半新手。

我会尽量用“做项目”的视角来拆，不堆公式，也不空谈概念，把提示工程、RAG、Agent这些大热词全部落到能跑、能查、能迭代的具体步骤里。

1. AI工程这件事，“从零开始”到底零在哪里

1.1 先分清你要学的是“AI”还是“AI工程”

很多人一上来就盯着Transformer论文、反向传播推导，几个月下来数学功底涨了不少，但问到他“能不能把一个模型接到自己公司的业务系统里”，依然是懵的。这是因为“AI”和“AI工程”根本是两回事。

AI更偏向模型与算法本身：怎么训练、怎么调优、损失函数怎么设计、效果怎么评估。而AI工程解决的是模型之外那80%的脏活累活：数据怎么清洗、上下文怎么组织、服务怎么编排、出错怎么排查、上线之后怎么观测和回滚。

我见过一个很典型的现象：同样调用一个大模型API，一个纯算法背景的人和一个工程背景的人，最后做出来的产品稳定性完全不一样。算法背景的人关心生成质量，工程背景的人关心“模型答错时系统能不能优雅降级”“超时了有没有兜底”“用户多轮对话时上下文会不会爆掉”。后者才是AI工程的核心能力。

所以如果你目标是“能独立交付AI项目”，那学习重心就应该放在数据流、API协议、编排逻辑、评估体系这些工程要素上，而不是把时间全部花在复现论文数据上。

1.2 AI工程的知识图谱：拆开看看有多大

为了不让自己迷失方向，我一般会把AI工程的知识栈画成一张地图，先看清楚全貌，再决定从哪里切进去。按我的习惯，大概分成五层：

这五层不需要一次学完，但心里要有数。我见过很多人卡在“基础层”反复背语法，也有人跳过基础层直接上应用层，结果出了问题连日志都不会看。正确的姿势是：先保证每一层都有一个能跑的“最小案例”，再回头补深度。

打个比方，AI工程学习就像装修房子。基础层是水电改造，数据层是建材挑选，模型层是理解房屋结构，应用层是设计布局，工程层是最后的竣工验收。哪一步跳过了，后面都会有隐患。

1.3 我更建议的“双线交叉”入门路径

我自己带新人时比较推荐一条“双线交叉”路径，核心思想是：一条线练工程手感，一条线补原理理解，两条线交替推进，而不是等一条线刷完再开始另一条。

先说练手感这条线：用Scratch做小游戏、用Python写自动化脚本、调通几个公开API、搭一个带数据库的小系统。这些事情都不难，但做完之后你会建立起“程序为什么这么跑”的直觉，这种直觉是后面所有复杂工程的地基。

另一条线是补原理：读Prompt工程的核心概念、理解大模型API请求和返回的结构、搞懂Embedding和向量检索的基本流程、自己动手写一个最简的Agent循环。这些任务不求深，只求“自己在代码里实现过一遍”。

两条线交叉推进的好处很直接：你在原理线学到一个概念，马上就能在手感线找到对应的项目去验证。比如学完“上下文窗口”这个概念，立刻去调API做一个带上下文管理的小助手；学完“向量检索”，立刻把之前的文档问答改成RAG版本。知识一旦有了落点，就不会忘。

1.4 为什么我强烈建议先别碰大型框架

这个建议可能会得罪一些人，但我还是要说：初学者最好先别上LangChain、LlamaIndex这类重型框架。原因不是框架不好，而是框架把太多的内部过程封装掉了。

我在带人时发现一个规律：用框架搭RAG，半小时就搭起来了，但出了问题谁都没辙。文档切分逻辑不对、向量检索结果不准、上下文拼接缺失，这些错误藏在框架的抽象层下面，新手根本不知道从哪排查。而裸写一遍RAG虽然多花两三个小时，但你会对数据从进到出的每一个环节心中有数。

把框架当成“翻译层”来学习是更聪明的用法：先裸写一遍理解原语，再看框架源码时你会发现它就是把你的裸写过程模块化了。有了这层理解，框架反而是省力的工具；没有这层理解，框架就是黑盒。

2. Scratch思维的迁移：为什么图形化编程反而是AI工程的第一块跳板

2.1 用积木块获得编程手感

Scratch虽然是很多小学生的入门工具，但它的积木体系把编程中最核心的几个概念提炼得非常干净：事件、循环、分支、变量、消息。这些概念恰恰就是AI工程里天天打交道的东西。

举个例子，Scratch里最常用的“当绿旗被点击”积木，本质上就是一个事件触发器，对应到AI工程里就是收到用户请求时系统的启动点。“重复执行直到”积木则是Agent里最常见的循环结构：“反复执行工具调用，直到拿到可回答的结果”。而“如果…那么…否则”积木，对应着Agent里的条件分支逻辑。

如果你完全没有编程基础，我特别推荐先用Scratch做两个小游戏，不用多，两个就够。第一个做猜数字，体会变量和条件判断的组合；第二个做接水果或者简单闯关，体会事件监听和碰撞检测。做完这两个，你对“程序是由事件、状态、判断组成的”这句话会有非常具体的体感。

有了这个体感，后面写Python时你脑子里是有图的：每一行代码在做什么，当前状态下哪些变量是活的，下一步会触发什么分支。这种图形化思维迁移到文本代码的过程，比零基础直接啃语法书要平滑得多。

2.2 从植物大战僵尸到Agent循环

拿一个很多人都做过的Scratch小项目“植物大战僵尸简易版”来说，里面向日葵生产阳光的逻辑非常经典。完整流程是这样的：向日葵每隔固定时间tick加一次阳光数值，然后循环判断阳光值够不够种新植物，够了就让玩家选择种植位置，扣掉阳光，更新场上状态，等待下一波僵尸。

这个流程看着是个游戏逻辑，但把它抽象出来看，就是Agent系统的基本骨架：感知状态、做出决策、执行动作、更新记忆。把它映射到AI Agent里，就是“检查当前上下文和可用工具 → 由模型决定调哪个工具 → 执行工具并把结果写回上下文 → 重新感知状态 → 决定下一步”。

我特别喜欢拿这个例子启发新人，因为大家会发现：所谓AI Agent的“智能”，本质上就是把这个循环转得足够快、决策足够好而已。游戏循环和Agent循环底层是同构的。你对Scratch小游戏有多熟悉，对Agent循环就能有多熟悉。

2.3 变量、条件判断与列表：AI应用的三个基础件

Scratch的积木块里有三个东西我特别想让初学者认真玩透：变量、条件判断、列表。它们看起来简单，但AI工程里所有复杂系统都是这三样东西的组合。

变量对应状态管理。用户在哪一步、当前上下文累积了多少内容、代币剩余多少、重试次数还剩几次，全都是变量。Scratch里你给“阳光值”设变量，AI工程里你就要给“对话历史长度”设变量。

条件判断对应规则与约束。大模型的输出经常“不听话”，所以工程上要写一堆Guardrail（护栏）：输出必须是指定JSON格式、回复不能涉及某些话题、超长时必须截断，这些全是条件判断的变体。你在Scratch里写的每一个“如果阳光值大于50”，以后都会变成“如果JSON解析失败则重试”的工程代码。

列表则是最朴素的“数据库”。Scratch里列表存游戏得分，AI工程里列表存对话记录、向量索引、工具执行结果。理解列表的增删改查，就理解了数据管理的全部基础。

对了，Scratch里角色还有一个“亮度”特效参数，调高了角色变亮，调低了变暗。这个参数特别好地说明了“超参数”的概念：模型里有大量类似的旋钮，调亮度对应调温度或top_p，不同数值会带来视觉/输出风格上的可感知差异，而且都要小心别调过头。

2.4 从Scratch到Python的最小迁移路径

Scratch玩明白之后，不要恋战，要果断迁移到Python。迁移路径很简单：把Scratch积木逐块翻译成Python语法就行。事件积木变成函数回调或主循环，变量积木变成普通变量，列表积木变成Python列表，条件积木变成if语句。

我建议做一个最小翻译项目：用Python写一个命令行版“问答机器人”，这个机器人能记住你之前说过的话，也就是带简单的记忆功能。这个项目原量上对应着AI应用的骨架：输入处理、状态更新、逻辑分支、输出生成。等你把这个项目写完，顺便把每一步的输入输出打印出来，你就已经理解“程序是数据流”这件事了。

之后再切入大模型API调用，你会发现不过是把“问答机器人”的回复逻辑从一个写死的if-else列表，换成一次真实的大模型HTTP请求而已。

3. 大模型时代的第一门工程课：提示工程

3.1 提示词不只是“写句子”，而是“写协议”

现在很多人还在把提示工程理解为“怎么把需求写得清楚一点”，这个理解太浅了。真正的提示工程是把大模型设计成“一个按协议工作的组件”，而不只是“一个会说话的机器人”。

你可以把大模型想象成一位知识渊博但极度需要明确规则的实习生。你给的提示词就是SOP：说什么、不说什么、按什么顺序说、用什么格式输出、遇到什么情况怎么处理。写提示词的人不是在“跟AI聊天”，而是在“为AI可复用组件定义接口规范”。

这中间的分水岭在于：你有没有把提示词当成代码来管理。我在实际项目中会把每个提示词放在独立文件里，纳入版本控制，每次修改都留Commit记录。这样当模型输出质量突然变化时，我能很快定位到是哪一次改动引入的回归。

3.2 一套能直接在工作里用的提示词框架

经过大量项目实践，我沉淀了一套提示词结构，在这里分享出来。它不复杂，但每个部分都有明确作用，能覆盖绝大多数业务场景：

角色定义：你是一个具备某某能力、服务于某某人群的智能助手。 任务目标：你的任务是帮助用户完成某某事情，最终输出某某结果。 工作流程：第一步做什么，第二步做什么，第三步做什么。如果需要用户提供信息，先询问再行动。 输出格式：最终答案必须是什么结构。如果是JSON，必须包含哪些字段，各字段含义是什么。 约束条件：不要编造事实；不确定时说明不确定；文本长度控制在多少字以内；不得讨论超出职责范围的话题。 拒绝策略：当用户提出超出能力范围或不合规的需求时，如何礼貌拒绝。 评价标准：什么样的回答算好，什么样的算差，给自己一个初始的自查清单。

这套结构的价值在于“把模糊的智能变成可校验的输出”。角色定义决定了专业边界，工作流程防止模型自由发挥跳步，输出格式保证下游程序能稳定解析，拒绝策略让产品在边界场景下也能保持体面。

我见过很多失败的AI产品demo，问题不出在模型能力上，而是提示词里没有写清“输出格式”和“拒绝策略”。结果用户问东，它答西；让它输出表格，它输出散文；遇到不该答的问题，它还振振有词地编造答案。

3.3 提示词评测：没有评测你会死在工作台前

提示词最坑的一点是：你感觉改好了，但一放到真实流量里就翻车。时间久了还会出现“提示词改一次坏一次”的恶性循环。破解这个问题的唯一办法是建立评测集。

做法不复杂，把真实用户可能问的问题收集20到50条，作为固定的回归测试集。每条配上你认可的“参考答案”或者至少是“质量评分标准”。以后每次改提示词，就把这几十条跑一遍，逐条记录好、中、差三档的比例。

这个做法听起来很土，但它能终结所有关于“提示词到底行不行”的争论。评测比例变好了就保留，变差了就回滚，完全用数据说话。等你有了一定量的评测集之后，再引入LLM-as-Judge这类自动化评估方案去评分，效率会高很多。

没有评测集的AI工程开发，就像没有单元测试的传统软件开发，全凭运气。我甚至会把“是否建立了最小评测集”作为判断一个团队AI工程质量的第一指标。

3.4 提示工程里最常见的返工原因

聊几个高频返工场景，都是我在项目里真实遇到的：第一，把业务规则一股脑全塞进系统提示词，导致模型在复杂场景下行为混乱，正确做法是让提示词尽量精简，把长文本规则拆到检索或代码逻辑里；第二，只给任务不给示例，模型往往不知道你要求的具体格式长什么样，few-shot示例要两三组，太少没用太多浪费token；第三，不区分角色和调用方，一个提示词试图覆盖多种场景，正确做法是每个场景单独维护一套提示词，通过路由逻辑分发。

4. 真正的从零：不靠封装，自己跑通一条RAG链路

4.1 为什么建议先“裸写”一段RAG再谈框架

RAG（检索增强生成）是现在AI应用里最主流的范式，核心思想很简单：先把资料切块、向量化、建索引；用户提问时，先检索出最相关的几个片段，再把这些片段和大模型能力拼在一起生成回答。

很多人学RAG直接上LangChain，两三行代码就跑通了。但问他们“为什么这么切分”“为什么召回的片段不对”“为什么回答质量忽高忽低”，全都不清楚。因为框架把这中间的数据流整个吞掉了。

我强烈建议初学者用最基础的工具裸写一遍RAG，哪怕只是几百行代码。你不需要自己实现Embedding模型，直接调API；不需要上向量数据库，用内存里的列表加余弦相似度就够。关键是要亲手把每个环节的数据形态看一遍：文本是怎么变成向量的，向量是怎么比的，凑出来的上下文长什么样。

4.2 从零实现RAG的四个环节与代码骨架

一个最小可运行的RAG链路包含四个环节：加载与切分、向量化、检索、生成。下面这个代码骨架就是我在教学里用的“保姆级”版本，去掉了复杂工程，只保留核心逻辑：

import requests # 1. 加载文档并切分成片段 doc = open("knowledge.txt", encoding="utf-8").read() chunk_size = 200 overlap = 50 chunks = [] for i in range(0, len(doc), chunk_size - overlap): chunks.append(doc[i : i + chunk_size]) # 2. 对每个片段做向量化 def embed(text: str, api_key: str) -> list: resp = requests.post( "https://api.xxx.com/v1/embeddings", headers={"Authorization": f"Bearer {api_key}"}, json={"input": text, "model": "text-embedding-ada-002"}, ) return resp.json()["data"][0]["embedding"] db = [embed(c, api_key="your-key") for c in chunks] # 3. 检索：算余弦相似度取Top K def cosine(a, b): dot = sum(x * y for x, y in zip(a, b)) norm_a = sum(x * x for x in a) ** 0.5 norm_b = sum(x * x for x in b) ** 0.5 return dot / (norm_a * norm_b + 1e-9) def search(query, top_k=3): qv = embed(query, api_key="your-key") scored = [(cosine(qv, dv), i) for i, dv in enumerate(db)] scored.sort(reverse=True) return [chunks[i] for _, i in scored[:top_k]] # 4. 把检索结果拼进提示词，调大模型生成回答 query = "什么是RAG？" context = "\n".join(search(query)) prompt = f"基于以下资料回答问题。\n\n资料：\n{context}\n\n问题：{query}\n回答：" resp = requests.post( "https://api.xxx.com/v1/chat/completions", headers={"Authorization": f"Bearer {api_key}"}, json={ "model": "gpt-4o-mini", "messages": [{"role": "user", "content": prompt}], "temperature": 0.3, }, ) answer = resp.json()["choices"][0]["message"]["content"] print(answer)

这段代码里我特意用了chat/completions和embeddings两个接口，因为这是理解大模型API结构的最短路径。你一旦看清“输入文本→输出向量”和“输入消息列表→输出回复”这两个过程，后面用任何框架都不会再有黑盒感。

4.3 数据切分和检索的坑：我踩过的三个细节

第一，切分不能无脑按固定长度硬切。我踩过最典型的坑是：一句话被从中间截断，导致上下文语义残缺，检索时永远召不回最优片段。后来改成“按段落优先、长度超限再手动切、切分时保留重叠窗口”的混合策略，召回质量明显改善。

第二，检索之后别直接把Top K全塞进提示词。如果数据库切了上千块，而规则不严谨，可能召回的3块内容主题一致但细节冲突，模型就会被带偏。我的习惯是检索后加一道“重排+过滤”：先去掉相似度明显低于阈值的片段，再按语义完整度排序，必要时只取前2块最相关的。

第三，永远保留溯源信息。生产环境里所有生成回答都要能回答“这句话是模型自己说的还是资料里的”。每次检索时把命中的片段来源、索引位置、相似度分数记到日志里，一旦回答出错，你才能顺着日志往回追。

5. 从提示词到智能体：Harness Engineering的工程化视角

5.1 什么是Harness Engineering：给模型套上“缰绳”

Harness原义是马具、挽具，Harness Engineering直译就是“给AI套上缰绳的工程”。这个概念在2025年前后开始流行，核心意思是：大模型本身是一个能力很强但行为不确定的组件，要让它稳定完成复杂任务，必须围绕它构建一套工程化的约束和编排系统。

如果把提示工程比作“怎么对模型说话”，那Harness Engineering就是“怎么把模型编进一套系统里干活”。它涵盖的范围很广：上下文编排、工具调用协议、状态管理、记忆压缩、可观测性和评估机制都在其中。

为什么这个概念很重要？因为单靠提示词，你已经很难约束模型完成多步骤的复杂任务了。比如让AI“先查三份资料，再对比分析，最后输出一份带表格的建议”，模型在自由发挥模式下经常跳过中间步骤。而在Harness框架下，模型每一步都被系统检查：是否调用了检索工具、返回数据是否符合规范、最终输出是否满足格式要求，每一步不达标就回退重试。

5.2 手写一个最小的Agent Harness骨架

不借助任何框架，你也可以用很短的代码搭出一个带工具调用能力的Agent骨架。核心是一个循环：让模型输出“结构化指令”，程序据此执行真实工具，把结果回填给模型。

import json, requests def retriever(question): return "检索到的相关资料片段……" def calculator(expr): return eval(expr) # 仅为教学示例，生产环境请谨慎 TOOLS = { "retriever": {"func": retriever, "desc": "查找知识库资料"}, "calculator": {"func": calculator, "desc": "执行数学计算"}, } system_prompt = """ 你是任务助手。你可以调用工具完成复杂任务。 请以JSON格式输出你的下一步，格式如下： {"thought": "你的想法", "tool": "工具名", "args": {"参数": "值"}} 当你已经获得足够信息，输出最终答复时必须包含final字段。 """ messages = [{"role": "system", "content": system_prompt}] messages.append({"role": "user", "content": "知识库里有没有提到RAG优化策略？同时帮我算一下两倍检索阈值是多少，阈值是50。"}) for _ in range(5): # 设置最大迭代次数，避免死循环 resp = requests.post("https://api.xxx.com/v1/chat/completions", headers={"Authorization": f"Bearer {api_key}"}, json={"model": "gpt-4o-mini", "messages": messages, "response_format": {"type": "json_object"}}) act = json.loads(resp.json()["choices"][0]["message"]["content"]) if "final" in act: print("最终回答：", act["final"]) break tool_name = act["tool"] args = act.get("args", {}) result = TOOLS[tool_name]["func"](**args) messages.append({"role": "assistant", "content": json.dumps(act, ensure_ascii=False)}) messages.append({ "role": "tool", "content": f"工具{tool_name}返回：{result}", })

这个骨架里最关键的设计有三个：一是给模型规定了统一的JSON输出协议，程序才能稳定解析；二是设置了最大迭代次数，防止Agent在错误分支里空转；三是一轮结束后把模型上一轮的决定和工具结果全部追加回上下文，让模型能在完整历史基础上继续推理。

一旦你把这段骨架跑通，再看市面上那些Agent框架，你的视角会完全不同——你看到的不是神奇魔法，而是一堆工程模块的组合。

5.3 用AI编程助手快速搭建一个小型Harness工程

这个话题热度很高，但很多人误解了AI编程助手的用法，以为它就是“你把需求一把扔进去，它把整个系统吐出来”。我实际用下来最有效的姿势其实是“人写意图，AI写代码”。

比如你想搭一个带检索和计算能力的小助手。你可以先把系统设计写成人话发给AI编程助手：系统分三层，提示词层负责说明模型角色和工具清单，工具层提供retriever和calculator，循环层负责解析模型输出、执行工具、回填上下文。然后把上面那段骨架代码贴给它，让它帮你补齐JSON解析异常处理、日志记录、超时重试这些工程细节。

AI编程助手真正适合干的是这些“费力但明确”的活：生成单元测试、补全异常处理、把一段过程式代码重构为类结构、为代码写注释和文档。它不适合干的是说一不二的架构决策——哪部分逻辑放提示词里、哪部分放代码里、需要哪几个工具、如何定义工具协议，这些还是要人拿主意。

5.4 可观测性：没有日志的Agent就是个黑盒

我接手过的AI项目里，最让人头疼的就是没有日志的Agent。用户问了一个问题，系统做了一个工具调用，内部发生了什么完全无从知晓。排查问题只能靠猜，改一次代码凭一次运气。

正确做法是把每一次Agent运行的完整轨迹都记录下来。我的记录表一般包含这些字段：会话ID、时间戳、用户输入、模型每一步的决定、工具名、工具参数、工具返回结果、token消耗、延迟毫秒数、是否命中重试、最终答复摘要。

这些日志平时看起来没用，但一旦线上出了问题，它就是破案神器。常见的Case是：模型在第二次工具调用时生成了非法JSON参数，导致工具执行失败，然后系统不断重试，最后叠加token超限。如果没有日志，这种问题你根本不知道从哪查起。

5.5 多Agent协作：广播消息与异步协作

从Scratch的“广播消息”积木出发，能比较自然理解多Agent协作。一个Agent发消息，其他Agent接收并响应，这在Scratch里是事件机制，在AI工程里就是多Agent系统的通信基座。

多Agent协作并不神秘，工程上最朴素的实现就是一个“总控Agent”加若干“子Agent”，总控负责拆解任务、决定把哪部分分给哪个子Agent、收集子Agent结果并汇总输出。复杂一点的方案是让子Agent之间也能互相通信，接近“联邦协作”模式。

给新人的建议是先别碰多Agent，把单Agent的Harness写稳了再扩展。多Agent真正难的不是通信协议，而是每个子Agent自身的可靠性。三个不稳定的Agent组队，只会得到一个方均根误差更大的不稳定系统，而不会自动产生涌现智能。

6. 一条自检路线：从零到能交付AI工程项目的七个阶段

6.1 阶段拆解：每个阶段该有什么产出

我不知道你会不会和我一样，学习的时候最怕的不是不会，而是“不知道自己到了哪一步”。所以我整理了一张阶段自检表，供你对照：

每个阶段的重点不是“学过”，而是“跑通”。我见过太多人卡在阶段四和阶段六之间反复横跳，一会儿去学微调，一会儿去研究模型架构，手里的主线项目却迟迟没有建起来。

6.2 常见问题排查速查表

做AI工程开发，写代码出Bug是常态，我这里把最高频的问题整理成一张速查表：

这六个问题覆盖了我大部分项目里遇到的情况。你可以把这张表打印出来贴在工位旁边，排查效率会高很多。

6.3 学习过程中最容易踩的五个坑

第一坑：框架熟练代替原理理解。框架用得很溜，但原理一塌糊涂。一旦框架版本升级或出现隐藏Bug，你就完全失控。对策是裸写一遍核心链路。

第二坑：不建评测集就疯狂调提示词。这是所有AI应用做不稳定的第一大原因。对策是0.5天建评测集，再谈优化。

第三坑：把不稳定的东西直接上线。很多人demo跑通了就急着部署，结果线上翻车。好的做法是先加日志和兜底策略再推上线，出问题能下能回滚。

第四坑：无视Token成本。长上下文和多次重试会快速烧光额度。对策是给每次API调用都记录token数，并在代码里设上限。

第五坑：一个人埋头苦写，从不输出。写项目总结、录一段讲解视频、带别人做一个项目，都是极好的学习反馈方式。你会发现教别人一次，比自己闷头学一周都管用。

6.4 学完这些能做什么方向

当你走完这七个阶段，你能做的事情其实已经很多了：做一个带检索能力的知识库问答助手，做一个能查天气、查时间、做计算的个人助理，做一个对接内部文档的团队答疑机器人，甚至把这些能力组合成一条自动化的业务流程。市面上常见的“AI旅游助手”“AI文档工具”这类应用，底层都是这套能力。

不必贪多，但一定要有一个项目是完整交付的。哪怕是“读一个PDF目录里的所有文件，用RAG回答用户问题”这种小工具，只要跑通全链路就算数。真实项目会逼你处理切分策略、评测、异常处理、部署上线这些“教室之外”的问题，而这些才是AI工程真正的分水岭。

说句掏心窝的话，我见过太多人卡在“准备学习”这一步上，收藏夹里的教程比代码库里的项目还多。AI工程这条路没有捷径，但也不需要蛮力，把这条双线路径走完，你会发现从一开始那个连一个积木块都不会拖的新手，到能独立调模型、搭链路、部署服务的人，中间只隔了四五个认真做完的小项目而已。

到最后我的体会是：AI工程最忌讳的是“觉得懂了”。提示词读一遍觉得懂了，RAG了解概念觉得懂了，Agent框架装好了觉得懂了，但真要你从零把它们写出来，还是两眼一抹黑。所以如果你看完这篇文章只带走一个动作，我建议就是——挑一个今天的话题，用最朴素的代码，亲手跑通一次。一旦你跑通了一个，后面的路就会自己铺开。