最近在复盘一个绕不开的问题如果一个人真的想“从零进入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工程的知识栈画成一张地图先看清楚全貌再决定从哪里切进去。按我的习惯大概分成五层层级核心内容具备的标志基础层Python编程、数据结构、HTTP与API、JSON与文件处理能独立写脚本处理日常数据数据层数据清洗、pandas基础、SQL、向量化与索引能组织百条到百万条数据模型层机器学习基本概念、Transformer直觉理解、大模型调用能解释黑盒模型的基本行为应用层提示工程、RAG、Agent、评测与调优能搭建并迭代一个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, encodingutf-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: fBearer {api_key}}, json{input: text, model: text-embedding-ada-002}, ) return resp.json()[data][0][embedding] db [embed(c, api_keyyour-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_k3): qv embed(query, api_keyyour-key) scored [(cosine(qv, dv), i) for i, dv in enumerate(db)] scored.sort(reverseTrue) 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: fBearer {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: fBearer {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_asciiFalse)}) 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 阶段拆解每个阶段该有什么产出我不知道你会不会和我一样学习的时候最怕的不是不会而是“不知道自己到了哪一步”。所以我整理了一张阶段自检表供你对照阶段核心任务完成标志阶段一用Scratch做两个小游戏能独立说清程序里每个积木的作用阶段二Python基础与脚本能写出批量处理文件的脚本阶段三API调用与数据格式能调用3个公开API并解析JSON阶段四提示工程与最小评测集建立20条以上固定测试集并跑过三轮迭代阶段五裸写RAG链路不用框架跑通“检索生成”闭环阶段六手写最小Agent循环实现带工具调用的Harness骨架阶段七完整项目交付做一个真实场景的小应用并部署上线每个阶段的重点不是“学过”而是“跑通”。我见过太多人卡在阶段四和阶段六之间反复横跳一会儿去学微调一会儿去研究模型架构手里的主线项目却迟迟没有建起来。6.2 常见问题排查速查表做AI工程开发写代码出Bug是常态我这里把最高频的问题整理成一张速查表症状可能原因排查方法模型输出JSON解析失败response_format未设置或提示词里没给出JSON示例打开日志查看原始输出尝试加JSON模式参数上下文越长回答越差超出模型窗口早期信息被截断启用滑动窗口或摘要压缩控制传入消息量RAG检索结果明显不相关切分粒度过大或查询与库主题不匹配打印所有切分片段手动调整切分窗口Agent反复调用同一个工具循环退出条件设计不合理设置最大迭代次数并记录每一步决定改了一次提示词后效果全面下降缺乏回归评测立即跑评测集对比分档比例决定是否回滚API偶发超时网络波动或服务端限流加入指数退避重试并允许用户在超时时重发这六个问题覆盖了我大部分项目里遇到的情况。你可以把这张表打印出来贴在工位旁边排查效率会高很多。6.3 学习过程中最容易踩的五个坑第一坑框架熟练代替原理理解。框架用得很溜但原理一塌糊涂。一旦框架版本升级或出现隐藏Bug你就完全失控。对策是裸写一遍核心链路。第二坑不建评测集就疯狂调提示词。这是所有AI应用做不稳定的第一大原因。对策是0.5天建评测集再谈优化。第三坑把不稳定的东西直接上线。很多人demo跑通了就急着部署结果线上翻车。好的做法是先加日志和兜底策略再推上线出问题能下能回滚。第四坑无视Token成本。长上下文和多次重试会快速烧光额度。对策是给每次API调用都记录token数并在代码里设上限。第五坑一个人埋头苦写从不输出。写项目总结、录一段讲解视频、带别人做一个项目都是极好的学习反馈方式。你会发现教别人一次比自己闷头学一周都管用。6.4 学完这些能做什么方向当你走完这七个阶段你能做的事情其实已经很多了做一个带检索能力的知识库问答助手做一个能查天气、查时间、做计算的个人助理做一个对接内部文档的团队答疑机器人甚至把这些能力组合成一条自动化的业务流程。市面上常见的“AI旅游助手”“AI文档工具”这类应用底层都是这套能力。不必贪多但一定要有一个项目是完整交付的。哪怕是“读一个PDF目录里的所有文件用RAG回答用户问题”这种小工具只要跑通全链路就算数。真实项目会逼你处理切分策略、评测、异常处理、部署上线这些“教室之外”的问题而这些才是AI工程真正的分水岭。说句掏心窝的话我见过太多人卡在“准备学习”这一步上收藏夹里的教程比代码库里的项目还多。AI工程这条路没有捷径但也不需要蛮力把这条双线路径走完你会发现从一开始那个连一个积木块都不会拖的新手到能独立调模型、搭链路、部署服务的人中间只隔了四五个认真做完的小项目而已。到最后我的体会是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工程的知识栈画成一张地图先看清楚全貌再决定从哪里切进去。按我的习惯大概分成五层层级核心内容具备的标志基础层Python编程、数据结构、HTTP与API、JSON与文件处理能独立写脚本处理日常数据数据层数据清洗、pandas基础、SQL、向量化与索引能组织百条到百万条数据模型层机器学习基本概念、Transformer直觉理解、大模型调用能解释黑盒模型的基本行为应用层提示工程、RAG、Agent、评测与调优能搭建并迭代一个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, encodingutf-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: fBearer {api_key}}, json{input: text, model: text-embedding-ada-002}, ) return resp.json()[data][0][embedding] db [embed(c, api_keyyour-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_k3): qv embed(query, api_keyyour-key) scored [(cosine(qv, dv), i) for i, dv in enumerate(db)] scored.sort(reverseTrue) 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: fBearer {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: fBearer {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_asciiFalse)}) 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 阶段拆解每个阶段该有什么产出我不知道你会不会和我一样学习的时候最怕的不是不会而是“不知道自己到了哪一步”。所以我整理了一张阶段自检表供你对照阶段核心任务完成标志阶段一用Scratch做两个小游戏能独立说清程序里每个积木的作用阶段二Python基础与脚本能写出批量处理文件的脚本阶段三API调用与数据格式能调用3个公开API并解析JSON阶段四提示工程与最小评测集建立20条以上固定测试集并跑过三轮迭代阶段五裸写RAG链路不用框架跑通“检索生成”闭环阶段六手写最小Agent循环实现带工具调用的Harness骨架阶段七完整项目交付做一个真实场景的小应用并部署上线每个阶段的重点不是“学过”而是“跑通”。我见过太多人卡在阶段四和阶段六之间反复横跳一会儿去学微调一会儿去研究模型架构手里的主线项目却迟迟没有建起来。6.2 常见问题排查速查表做AI工程开发写代码出Bug是常态我这里把最高频的问题整理成一张速查表症状可能原因排查方法模型输出JSON解析失败response_format未设置或提示词里没给出JSON示例打开日志查看原始输出尝试加JSON模式参数上下文越长回答越差超出模型窗口早期信息被截断启用滑动窗口或摘要压缩控制传入消息量RAG检索结果明显不相关切分粒度过大或查询与库主题不匹配打印所有切分片段手动调整切分窗口Agent反复调用同一个工具循环退出条件设计不合理设置最大迭代次数并记录每一步决定改了一次提示词后效果全面下降缺乏回归评测立即跑评测集对比分档比例决定是否回滚API偶发超时网络波动或服务端限流加入指数退避重试并允许用户在超时时重发这六个问题覆盖了我大部分项目里遇到的情况。你可以把这张表打印出来贴在工位旁边排查效率会高很多。6.3 学习过程中最容易踩的五个坑第一坑框架熟练代替原理理解。框架用得很溜但原理一塌糊涂。一旦框架版本升级或出现隐藏Bug你就完全失控。对策是裸写一遍核心链路。第二坑不建评测集就疯狂调提示词。这是所有AI应用做不稳定的第一大原因。对策是0.5天建评测集再谈优化。第三坑把不稳定的东西直接上线。很多人demo跑通了就急着部署结果线上翻车。好的做法是先加日志和兜底策略再推上线出问题能下能回滚。第四坑无视Token成本。长上下文和多次重试会快速烧光额度。对策是给每次API调用都记录token数并在代码里设上限。第五坑一个人埋头苦写从不输出。写项目总结、录一段讲解视频、带别人做一个项目都是极好的学习反馈方式。你会发现教别人一次比自己闷头学一周都管用。6.4 学完这些能做什么方向当你走完这七个阶段你能做的事情其实已经很多了做一个带检索能力的知识库问答助手做一个能查天气、查时间、做计算的个人助理做一个对接内部文档的团队答疑机器人甚至把这些能力组合成一条自动化的业务流程。市面上常见的“AI旅游助手”“AI文档工具”这类应用底层都是这套能力。不必贪多但一定要有一个项目是完整交付的。哪怕是“读一个PDF目录里的所有文件用RAG回答用户问题”这种小工具只要跑通全链路就算数。真实项目会逼你处理切分策略、评测、异常处理、部署上线这些“教室之外”的问题而这些才是AI工程真正的分水岭。说句掏心窝的话我见过太多人卡在“准备学习”这一步上收藏夹里的教程比代码库里的项目还多。AI工程这条路没有捷径但也不需要蛮力把这条双线路径走完你会发现从一开始那个连一个积木块都不会拖的新手到能独立调模型、搭链路、部署服务的人中间只隔了四五个认真做完的小项目而已。到最后我的体会是AI工程最忌讳的是“觉得懂了”。提示词读一遍觉得懂了RAG了解概念觉得懂了Agent框架装好了觉得懂了但真要你从零把它们写出来还是两眼一抹黑。所以如果你看完这篇文章只带走一个动作我建议就是——挑一个今天的话题用最朴素的代码亲手跑通一次。一旦你跑通了一个后面的路就会自己铺开。
