直接切入正题。我最近被问最多的一个问题是“我想学AI该从哪里开始”市面上有无数课程、框架、现成SDK但真正能让你理解AI工程本质的路径反而是那种“从零开始”的笨办法——不要一上来就套LangChain不要急着接Agent框架先用手上的Python代码把一条最简单的人工智能管线从数据到部署完整走一遍。这个思路就是我这次想展开聊的“ai-engineering-from-scratch”。这篇文章写给三类人刚入门但被各种术语绕晕的新手已经在用AI写代码但没系统梳理过工程链路的开发者以及想在企业内部做AI落地但总被“幻觉”“评估”“提示词”这些词卡住的转型者。你会看到一条清晰的学习路线问题定义、数据准备、模型选型、评估闭环、工程化上线每一步都给出可复现的思路和踩坑经验。它不是一篇概念科普更像一份我从实践里整理出的“最小工程手册”。1. 先讲清楚AI工程从零开始的真正含义很多人以为“from scratch”是指自己写神经网络、从反向传播开始手撸Transformer。如果真这么做你可能还没跑通一个模型就先流失了兴趣。我理解的“从零开始”是指不依赖任何封装好的AI应用框架不直接套用别人写好的一站式平台而是从最原始的需求、最朴素的代码、最简单的数据结构出发一步步构建出一个能用的AI系统。换句话说你要亲手走过数据清洗、特征构造、调用模型、解析结果、设计评估指标、写接口、做日志监控这一整条链路。哪怕最终你大概率还是会用开源大模型API或本地部署的开源模型但因为你亲手搭过这条链路你会明白每个环节为什么存在、哪里容易出错、如何排查问题。这种“底层理解”比会用某个框架重要得多。举一个直觉的例子。你第一次看到LangChain里那个“chain load_qa_chain(llm, chain_typestuff)”的时候如果不清楚底层发生了什么你只是在调用一个黑盒。一旦结果出错你完全不知道是检索环节没找到文档、还是提示词格式不对、还是模型输出解析失败。而如果你自己写过一轮“文档切分-向量化-相似度检索-拼提示词-调模型-解析回复”的代码再回来用任何框架你都是在“使用工具”而不是“被工具使用”。所以我建议的路线是先裸写、先调通、先跑起来再去接触框架。这个顺序能帮你省掉后面大量的debug时间。2. 不要急着上框架自己动手造轮子为什么值得我见过太多人一进项目就上全套框架结果连最基础的“数据从哪来、答案给谁看”都没想清楚。框架不是银弹它只是把你需要写的样板代码藏起来了。如果你不理解样板代码背后的业务逻辑框架甚至会阻碍你调试。自己动手造一个最小轮子的价值主要体现在四个层面你会真正理解输入输出结构。无论是调用大模型API还是本地跑模型本质都是“给一段输入拿一段输出”。这个输入怎么写、输出怎么解析是整个工程的核心。用框架时这些往往被抽象掉了你会失去对数据流的敏感度。你能控制每一个环节的成本和延迟。框架会默认帮你做很多事包括不必要的向量化、多余的检索重排、复杂的缓存逻辑。自己写的时候你会发现很多步骤在早期是完全可以砍掉的这对性能优化至关重要。排查错误时你有完整视野。自己写的代码每一段都能print出来看中间结果。框架里的链式调用一旦出错你连中间结果都很难截获。你的系统不会依赖某个特定版本。维护过生产环境的人都知道框架升级带来的破坏性变更有多可怕。自己写的最小实现依赖少、可替换性强后续想换模型、切换向量库都更容易。当然这不是说永远不用框架。我的意思是先用裸代码跑通再在理解的基础上引入框架这样框架就只是替你省时间的工具而不是替你思考的黑盒。这样的学习曲线前期慢一点后期会飞快。3. 五个核心环节从零构建AI工程必须打通的地基3.1 需求定义三板斧输入、输出、约束从零开始第一步不是选模型也不是买算力而是把问题定义清楚。很多人死在第一步就是因为需求太模糊。你跟业务方聊完他说“帮我做一个智能助手”你以为他想要一个对话机器人结果他真正想要的是“把每天早上的销售日报自动汇总成重点摘要”。我习惯用三板斧把需求问清楚输入是什么用户会提供什么格式的数据是纯文本、PDF、网页链接还是数据库里的结构化记录输入的长度范围大概是多少输出是什么最终交付给用户的形式是自然语言段落、JSON结构、分类标签还是一份固定模板的文档输出格式直接决定后续的解析成本和稳定性。约束条件是什么响应时间要求多快成本上限是多少是否涉及敏感信息、能否调用外部API数据会不会跨地域传输这三板斧问完你会发现相当一部分所谓的“AI项目”根本不需要大模型用正则表达式和模板就能解决。我印象里有一次业务方要做“智能客服意图识别”我一看历史对话数据80%的问题都能靠关键词规则命中。最后用100行Python加一个轻量分类器就上线了成本比GPT-4方案低了两个数量级而且效果非常稳定。这就是从零开始的价值你会先思考“问题最简形式是什么”而不是“我该用哪个花哨模型”。3.2 数据准备小数据优先别一上来就堆语料数据环节是AI工程里最不性感但最决定成败的部分。很多刚入门的人会陷入“数据越多越好”的误区一上来就想搞几百万条语料。但实际上对于大多数工程落地场景几千条高质量数据就够跑通第一版。小数据优先的思路有几个实际好处你可以人工检查每一条数据发现标注错误和格式问题。迭代速度快改完数据立刻能重跑评估。训练或调用成本低排错时不会因为“一次跑半天”而崩溃。我自己在做数据准备时通常会按这个顺序来收集原始数据。从业务系统导出原始记录不要急着清洗先保存一份“原样备份”。人工抽样看50条。这一步最重要你会发现很多你压根没想到过的数据形态空值、重复、全角半角混用、截断文本、格式错乱等。设计统一格式。比如规定文本统一用UTF-8、换行符统一转\n、日期统一成YYYY-MM-DD。写清洗脚本。用Pandas或纯Python写把上一步发现的问题批量处理掉。做答案标注。如果是监督学习需要人工标注正确答案。标注规范要写清楚尽量让两个不同的人标出的结果一致。很多初学者在数据阶段最常犯的错误是清洗过度。把“脏”信息全删掉结果模型在真实场景里见到脏数据就崩。清洗和保留之间要平衡——保留真实噪声才能训练出能处理真实数据的系统。3.3 模型选型规则、传统ML、大模型三层递进到了选择模型这一步我的建议非常明确先规则再传统机器学习最后才上大模型。这不是保守而是工程效率上的理性选择。第一层是规则方案。关键词匹配、正则表达式、模板渲染适用于结构稳定、逻辑清晰的任务。优点是零成本、零延迟、完全可解释排查问题就是一秒钟的事。第二层是传统机器学习。当规则覆盖不住所有模式时可以用朴素贝叶斯、逻辑回归、随机森林或轻量级 embedding 加分类器。训练成本低、推理速度快、效果可预期。适合有标签数据的分类任务比如工单自动分派、情感极性判断。第三层才是大模型。面对开放式生成、语义理解、跨领域推理等传统方法搞不定的任务才需要考虑大模型。选择时也要区分可以调用API也可以本地部署开源模型。业务对数据隐私要求高就本地部署追求开箱即用和效果上限就调用成熟API。我自己做方案选型时常用一张表来对比结构大致如下方案成本延迟效果上限可解释性适用场景规则模板极低毫秒级低完全可解释格式稳定、模式明确传统ML低毫秒级中可通过特征分析解释有标注数据、分类任务大模型API高秒级高弱开放生成、复杂理解本地开源模型中受硬件限制中高弱数据敏感、需要定制记住一句话模型选型不是为了炫技而是为了用最低的成本达到可接受的业务效果。一个正则能搞定的任务不要动用千亿参数模型。3.4 评估闭环先定指标再谈效果做AI工程和写普通程序最大的区别在于普通程序跑通了就是对的AI系统“跑通了”不一定是对的。你需要一套评估机制来回答“这个系统到底行不行”。我常用的评估闭环四步走定义指标。生成类任务用准确率含人工评定、召回率、BLEU/ROUGE等分类任务用准确度、F1检索任务用RecallK。这些指标要在需求阶段就跟业务方对齐。构建测试集。准备一批业务方认可的标准输入和标准答案测试集一旦确定尽量冻结不要随意改。跑测并记录得分。每个版本在同样的测试集上跑得到可对比的分数。回归对比。每次改动改提示词、换模型、换检索策略后都重新跑同一套测试集看分数变化防止“改好了A领域、搞砸了B领域”。很多小团队在评估上偷懒靠“看一眼觉得效果不错”就上线这是最危险的做法。我自己踩过这种坑某次优化后人工看几条结果感觉很好上线后用户反馈完全相反。后来做了隔离测试集才定位到问题——原来我“感觉很好”的几条恰好是模型本来就擅长的样本真正的难点样本变得更差了。评估闭环看似繁琐但它才是AI系统能持续迭代的发动机。没有它你每次改动都像在赌运气。3.5 工程化落地接口、日志、监控一个都不能少实验室里的Jupyter Notebook跑得飞起不代表系统能上线。工程化落地是从零开始AI进阶的分水岭。上线前我至少要保证三件事输出结构化。不要直接让模型吐一段自由文本给用户。我习惯让模型输出JSON格式再在代码层做严格校验拿不到关键字段就报错重试。这样下游系统不会因为模型“多说了几句话”就崩溃。日志全覆盖。记录每一次请求的输入、模型原始输出、解析结果、耗时、token消耗。日志不仅是排查问题的依据也是评估数据积累的来源。没有日志出了问题你连“是输入问题还是模型问题”都不知道。监控与告警。线上系统要盯住几个关键指标请求成功率、平均耗时、解析失败率、异常输入触发率。任何指标出现明显波动都要能自动告警。有一次我发现解析失败率突然从1%涨到5%排查后才发现是模型供应商更新了版本输出格式变了。如果没有监控用户可能已经骂了半天你还在蒙圈。把这三个基础打好AI应用才算真正具备“能被可靠使用”的工程底色。4. 实战路线从零做出一个“会议纪要助手”聊完理论我带大家完整走一个最小可行的项目做一个“会议纪要助手”。这个项目规模适中既能展示从零开始的完整工程链路又不至于复杂到让人打退堂鼓。你完全可以在一天内跟做一遍。4.1 需求拆解与方案选型目标用户是每天都开各种会的项目负责人。他的痛点是开会一小时写纪要半小时而且经常遗漏待办事项。我们做一个助手输入是会议录音转写文本输出是结构化会议纪要包含三块内容讨论主题归纳、关键结论、待办事项含负责人和截止时间。按前面说的三板斧约束条件是这样的输入文本长度通常在2000到8000字之间。输出必须结构化方便后续同步到项目管理工具。响应时间在5秒内可以接受。成本要控制在每份纪要不超过几块钱人民币。不涉及核心敏感数据可以调用成熟API。方案选型上第一版不引入向量数据库、不搞多Agent。就是一个最简单的“提示词大模型API输出解析”的管线。等第一版跑通了再往后加检索增强或更多Agent分工。4.2 第一版MVP用规则和模板先跑通第一版我连大模型都不想急着调用。先用规则把文本按段落和时间戳切分提取“沈总”“张工”这类人名、“本周五”这类时间词再用模板拼出一份纪要。这一步的目标不是效果好而是把整条链路跑通。在代码结构上我会拆成三个模块输入清洗模块、字段抽取模块、模板渲染模块。哪怕后面换成大模型这三个模块的边界依然能复用只是把“字段抽取模块”的实现从正则换成LLM调用而已。一个很实际的建议把清洗和解析做成独立函数每一步都能print出中间结果。这样调试第一版的时候你能清楚地看到哪一步出了问题而不是面对一坨报错无从下手。第一版通常不会花太多时间半天就能写完但它把整个系统的“管线形状”立起来了。4.3 第二版加入RAG检索增强第二版考虑一个重要场景会议中提到了“按上个月的流程走”如果只看本次会议文本你根本不知道“上个月的流程”是什么。这时需要引入RAG检索增强生成让模型能参考历史文档。RAG的完整实现需要哪些环节我简单列一下文档切分。把历史项目文档、过往会议纪要切成固定长度且语义相对完整的片段。切分时要按标题、段落边界切不要硬按字符数截断。向量化。把切好的片段用embedding模型转成向量存入向量数据库早期用内存里跑一个简单的向量列表就行。检索。用户输入当前会议文本后把当前文本与待办事项相关的那几段内容作为查询检索最相似的历史片段。上下文拼接。把检索到的历史片段与当前会议文本一起放进提示词让模型结合上下文生成纪要。加入RAG后生成质量会有明显提升但也引入了新的复杂度切分过大过小都会影响检索效果embedding模型的选择会改变相似度计算的语义偏向检索到的内容不相关时模型生成会“被带偏”。这些都是从零实现时才能真正体会到的。4.4 第三版提示词工程的系统调优很多人以为提示词工程就是“把需求写得礼貌一点”其实它是在定义模型的任务接口。一个好的提示词本质上是把需求转化为模型能稳定遵循的指令集合。我总结调提示词的五步法给角色和任务定义。用一句话说明模型扮演什么角色、完成什么任务。比如“你是会议纪要助理负责把会议转写文本整理成结构化摘要”。给出输出格式样例。与其用文字描述“请输出JSON”不如直接给一个完整的JSON示例。模型对“模仿样例”的服从度远高于“理解描述”。列出负面约束。明确禁止什么“不要合并不同人的观点”“不要编造未出现的待办事项”“没有明确负责人时写‘待定’”。提供参考上下文。把RAG检索到的相关历史内容放在提示词的独立区间内告诉模型“仅参考非直接事实”。设定解析要求。要求模型只输出合法JSON不要加任何解释性文字。每次调提示词都要回到评估闭环在冻结测试集上跑分数对比不同提示词版本的差异。不要靠“这条效果好”的主观感觉要靠测试集分数说话。我经常用A/B对比同一批输入分别用v1和v2的提示词跑输出结果逐条对照找出差异规律。4.5 评估与回归怎么判断改动是变好还是变差这个项目的评估集我准备了30条会议转写文本每条都有人工编写的标准纪要。评估时用三个指标主题归纳是否准确人工评定、关键结论是否遗漏召回率、待办事项抽取的精确匹配率。实际操作时每次改提示词或换模型后我都在同一套评估集上跑一遍记录三个指标的数值变化。可能的结果是待办抽取精确率从70%升到85%但关键结论召回率从90%掉到80%。这时就需要权衡业务优先级而不是盲目追求单一指标。这套评估过程就是AI工程里的“测试驱动开发”。它把不可控的模型行为变成可控的工程迭代。5. 容易被忽略的配套工程提示词工程与Agent编排5.1 提示词工程不是写话术是在定义任务接口继续把提示词工程说得再透一点。我们往往把提示词当成“跟AI说的话”但从工程视角看提示词就是一段程序代码的输入契约。你写出的每一条指令都在约束模型的输出空间。举一个实际案例。最初我用这样一个提示词“总结会议纪要”模型输出五花八门效率极低。后来改成你是一名会议助理。输入是一段会议转写文本。 请输出JSON格式包含三个字段 - summary: 一段200字以内的讨论总结 - conclusions: 关键结论列表 - todos: 待办事项列表每项包含task、owner、due_date 忽略与以上字段无关的寒暄内容不要编造。效果立刻稳定下来。这背后的原理是大模型在训练时见过大量“结构化输出”示例你给它的格式越像一份可填写的表单它就越倾向于按表单填充。把提示词想象成表单设计器你会自然而然地开始关注字段名、字段类型、取值范围。提示词工程真正难的地方在于它没有编译期报错。你只能在输出结果上发现问题然后再跑一轮评估看是否修好。这种循环很像调试只不过调试对象是一个你无法完全掌控的模型。5.2 Agent编排让多个模型和工具协作起来单次提示词调用解决不了复杂任务时就需要Agent编排。比如会议纪要助手如果还要自动去日历系统创建待办事件、去知识库检索历史文档、去OA系统同步项目状态那就是多个工具协作。一个最小Agent编排系统的核心组件包括任务分解器。把大目标拆成多个子任务。可能是模型生成也可以是代码里的固定逻辑。工具注册表。每个工具是一个函数描述里写清楚“这个工具能做什么、需要什么参数”。模型看到描述后决定调用哪个工具。循环执行器。模型输出一个“调用某工具参数为XXX”的结构化指令代码解析后执行对应函数把结果返回给模型模型继续推理直到完成目标。终止条件。设定什么时候停止循环比如子任务全部完成、达到最大轮数、或用户显式给出结束信号。要注意的是Agent编排是“复杂度放大器”一旦多个模型加多个工具串起来任何一个环节出错都可能让最终结果完全跑偏。我建议从最简单的“两个工具、一个流程”开始练手比如先让模型能在“搜索文档”和“生成摘要”两个动作间切换再逐步加工具。5.3 测试与灰度AI应用上线前的最后一道关AI应用测试比普通软件复杂因为模型的行为具有概率性。同一输入两次调用可能得到不同输出。这个特性决定了我们必须在测试和上线策略上多留一手。我的实践是分三层单测层。针对清洗函数、解析函数、模板渲染等纯代码逻辑写单元测试保证确定性部分永远正确。集成层。用测试集跑端到端流程校验结构化输出是否完整、字段类型是否正确、耗时是否达标。灰度层。线上流量先让10%的用户进入新系统对比新老系统在关键指标上的差异再逐步放量。灰度发布是AI应用最实用的护城河。因为AI系统很难在实验室里完全模拟真实用户输入只有小流量上线后才能看到最真实的分布。灰度期间要盯住错误率、用户反馈率和“无响应率”任何一个指标异常都按下暂停键。6. 从零起步最常见的5个坑与排查思路6.1 改了提示词效果反而变差怎么定位这是最让人头疼的问题。原因是模型对提示词的高度敏感性一个词的变化就可能颠覆输出风格。排查思路分三步先确认改动的变量只有一个。很多人一次改了好几处出了问题都不知道是哪里引起的。在冻结测试集上做A/B对比。分别用旧版提示词和新版提示词跑同一批输入逐条看差异。如果确实是新版变差不要强行调回来检查是不是输出格式约束被弱化了。很多时候“效果变差”不是模型变蠢而是格式要求不够严格导致内容质量被噪声稀释。6.2 数据标注口径不一致模型越训越偏标注是AI工程里的暗坑。两个人对“待办事项”的理解可能不一样一个人认为“会后跟客户确认报价”算待办另一个人认为只有“明确写了某人在某日前完成某件事”才算待办。这种不一致会让模型无所适从。避免的方法是写一份标注规范并找两个人各自标同一批样本计算一致性比如用Cohen‘s Kappa。低于0.8就要继续对齐口径直到一致性达标后再扩大标注规模。6.3 模型输出长度失控解析结果频繁失败当提示词里没有明确限制输出长度时模型可能把JSON字段跑飞甚至输出一长串解释性文字直接在解析阶段报错。我的对策是三个第一提示词里写明“只输出JSON不要输出任何额外说明文字”第二代码层做截断保护超长输出只截取关键段落再尝试解析第三解析失败时自动重试一次第二次调用时附带“上次输出格式错误请严格按照JSON格式输出”的纠错指令。多重保护下来解析失败率可以从5%降到0.5%以下。6.4 外部接口超时与并发问题调用外部模型API时最常见的是超时和限流。用户不会在乎底层是哪个模型出了问题他只在乎“页面怎么一直在转圈”。几个实操建议设置合理的超时时间我认为15到30秒比较合适太长影响体验太短容易误判。调用失败时采用指数退避重试连续失败三次后熔断直接返回兜底文案不要再继续烧钱。对并发做限流控制。API供应商有每秒请求数限制超了会返回429。你需要在代码层做好排队和缓冲。6.5 结果不可复现同一输入两次不同输出这是概率模型的固有属性。如果业务上需要稳定结果比如给用户生成合同摘要两次结果不能差太多一个简单办法是调低模型温度参数temperature设置为0或接近0。但即使温度调到0有些模型供应商为了保证服务质量内部仍然有采样随机性。更稳妥的做法是把模型的原始输出缓存下来同一输入哈希命中时直接返回历史结果。既保证一致性又能减少成本。这个方案尤其适合高频重复输入的场景。7. 给准备入坑的人几句实在话做了这么多年AI工程我最大的体会是真正决定项目成败的往往不是模型有多先进而是工程链路有多扎实。数据清洗不干净、评估指标没对齐、日志缺失、解析逻辑脆弱任何一个基础环节都能让最先进的模型变得不可用。反过来只要基础链路扎实哪怕只用一个中等能力的开源模型也能做出稳定可靠的产品。如果你刚开始走这条路我的建议是找一个你日常里真实存在的痛点任务别太大也别太小最好是一个你每周都要手动做一遍的繁琐工作。然后按文章里的思路先画输入输出和约束再准备一小批数据用最简单的规则写第一版再尝试接大模型API逐步加入检索、评估、监控。这个过程走完一遍你对AI工程的认知会比看十篇教程都深刻。我最自豪的项目从来不是用了多复杂的架构而是把一条简单的管线打磨到极致稳定数据不出错、格式不跑偏、接口有监控、失败有兜底、迭代有回归。AI工程从零开始这件事练的就是这些“不起眼但决定生死”的功夫。
