1. 为什么需要“从零开始”的系统化布局做AI工程的人百分之八十都会经历同一个阶段一开始兴致勃勃用几个现成的大模型API、套一个爬虫脚本、写几段prompt就以为出了产品等真正要落地、要稳定运行、要支撑业务才发现到处都是补丁——token上不去、效果忽好忽坏、跑一次换一个结果、上下文一长就崩。我也走过这条路。早期一个人用零散脚本折腾AI应用前后换了不下五种架构最后才意识到一个很基本的问题AI工程不是“会调用模型”就行它是一整套从数据、提示词、评估、链路到运维的基础设施。所谓“从零开始”ai-engineering-from-scratch不意味着你要从神经网络反向传播推导开始造轮子而是说你应当具备在完全没有现成框架依赖的情况下亲手搭建一条完整AI应用链路的能力——至少要知道每个环节为什么存在、它解决什么问题、哪些坑是在说明书上根本不会写的。这篇内容不是教程式的八股它更像是我自己从零搭建一套AI工程能力时的真实过程复盘。我把整个过程分成几个主题来讲先讲为什么要把重心放在“工作流设计”而非“模型堆叠”再讲我在技术选型和基础设施上做了什么决定然后拆解数据、提示词、Agent、评估这个几大核心模块的具体落地方法最后把工程中最常见的坑和排查思路整理成一份速查表。哪怕你是刚入门的开发者照着这条路径走也能搭出一个可复现、可迭代、可评估的AI应用骨架。这个项目适合三类人给正在做AI应用开发、但感觉一直在“面向运气编程”的工程同学给想从“调API”升级为“做AI应用架构设计”的产品和技术负责人也很适合准备做AI测试开发或平台工程方向的人因为里面很大一部分内容就是在讲如何让AI行为可被度量、可被控制、可被回归验证。标题里的“from scratch”真正的含义不是回到原始人时代而是要求你对每一个依赖都有清醒认知为什么要用向量数据库、为什么需要评估集、为何不能把业务逻辑全塞进提示词。把这些想明白了后面所有工程决策都会变得非常自然。2. 整体设计与路线选择2.1 先把“工程”二字拆开看当我决定以“ai-engineering-from-scratch”为项目目标时我给自己定下的第一个原则是先画地图再迈步子。所谓地图就是把AI应用工程全链路拆成六个环节需求定义、数据准备、提示词/模型层、Agent与工具编排、评估与回归、部署与监控。每个环节之间不是流水线关系而是相互回环——评估结果会反过来改提示词监控数据会触发新一轮数据清洗。这个框架我参考了当前工程界比较认可的“LLM工程实践”路线但加了点自己的改动把“评估”提到了与“模型调用”同等的核心地位。在早期做AI Agent也就是带工具调用能力的智能体应用时最容易犯的错就是把精力全放在Agent本身的花活上——多轮对话、复杂思维链、自动调工具——而完全没想清楚“怎么判断它做得好不好”。后来踩了一堆坑才在项目初期就坚持引入两套评估机制离线评估集和线上行为日志。这个习惯后期帮我省了至少一半的调试时间。另一个重要的设计思路是“分层解耦”。我会把所有模型调用封装在一个统一的接口层后面不管是调用云端大模型API还是本地部署的开源模型上层业务代码不感知。这么做的好处很直接模型可以随时换prompt可以单独调不同业务场景甚至可以路由到不同的模型不会因为一家模型平台的接口变动导致全盘崩溃。2.2 为什么选这条路而非“直接堆功能”在项目一开始摆在我面前的有两条路第一条拿像LangChain这种现成框架两三天就能跑起一个基础对话应用第二条自己写核心抽象层把提示词管理、工具调用协议、评估回路全部用自己的代码实现。两个方案我都试过。LangChain确实速度快但它在早期版本里抽象层太重很多底层细节被“魔法”掉了。比如某个工具调用返回异常框架层面吞掉错误继续走下一步——这在生产环境里非常致命。相反如果自己写一个轻量抽象虽然前期代码量会增加但每个环节的行为都是可控的调试时肉眼可见运行时的可观测性也强得多。我最终选了“轻框架自研核心”的混合路线提示词模板、工具注册、上下文管理、评估接口这些核心能力自己实现路由调度和接口兼容层则自己写一个极简版本不依赖重量级框架。这样既保留了敏捷开发的节奏又没有丢失对关键路径的掌控感。如果你也准备从零构建AI工程能力我建议你认真评估一下“框架依赖度”这个问题——它比你想象的更能决定项目后期的维护成本。2.3 技术栈与基础设施选型整套项目我用的技术栈不算复杂但每一条都经过实际验证跑生产环境没有出过原则性问题。模型层用的是多个云端大模型API作为主力推理引擎同时也接入了本地开源模型的调用能力用于做数据脱敏场景下的推理。开发语言用了Python这个生态在AI领域确实最成熟不管是数据处理、模型调用还是评估工具链都有现成库可用。存储层我根据数据类型做了拆分结构化业务数据放进PostgreSQL向量数据放进一个支持HNSW索引的向量数据库会话和链路日志以JSON行格式落盘。这里提一下很多人容易在存储上“过度设计”项目一开始就上分布式存储和复杂的消息队列实际上是没必要的。从零起步的AI应用单体数据库加一个向量库已经足够应对绝大多数场景等流量真正起来了再考虑拆分也不迟。基础设施方面我全程使用了容器化部署所有服务都跑在内网环境里通过一层轻量的API网关对外暴露。这样做的核心目的在于AI服务有一个显著特点就是模型调用耗时通常比普通API长得多网关层可以方便地做超时管理、重试策略和限流避免上游模型的抖动直接拖垮下游业务。3. 从零搭建AI核心链路的实操过程3.1 数据准备AI工程的“隐形地基”很多从零开始的AI项目第一个正式环节不是写代码而是处理数据。我在项目里维护了一套持续更新的“数据资产地图”把每一类任务需要的数据按用途打标签用于少样本示例的标注数据、用于评估模型的基准数据、用于检索增强RAG的领域知识数据、还有用于在线反馈收集的隐式信号数据。数据清洗部分我踩过最深的坑就是“以为原始数据能用”。哪怕是从业务库里导出的干净结构化数据放进RAG检索时也经常自带干扰信息——比如过长的BOM头、非业务字段、同一产品的不同叫法。我后期养成了一个习惯所有入库数据进行一轮统一清洗包括字段裁剪、去重合并、同义别名映射三件事再走语义切块和向量化。这套流程看起来笨但直接效果是检索相关性肉眼可见地提升。为了让你有个直观感知我把数据流水线的基本步骤列一下这套流程在多数内容类AI应用中可以直接套用先用Python脚本从源库抽数据清洗为统一JSON格式再做语义层面的去重与主题聚类然后根据内容长度和结构做切块切块策略建议“固定字符数标题感知”避免把一个完整语义段拦腰截断最后批量向量化写入向量库并同步维护一份映射表方便后续定位数据和调整切块策略。3.2 提示词工程从“碰运气”到“有章法”prompt engineering这个词在AI圈已经火了一年多但真正把它当成工程活来干的团队其实不多。我的理解是提示词本质上就是“运行在语言模型上的代码”它同样需要版本管理、变量隔离和回归测试。看到这里你可以试着自问一下你的提示词是存在代码里、参数表里还是会话历史里如果散落得到处都是那你已经欠下技术债了。我通常把一条生产级提示词拆成五大模块角色定义、任务上下文、输入变量区、输出格式约束、退化兜底策略。前三个模块大家比较熟悉重点是后两个。输出格式约束直接决定了后续解析的成功率要求模型输出JSON时一定要在提示词里给出严格的字段定义和示例并且在工程侧做一次“容错性JSON解析”——因为再严的提示词也挡不住模型偶尔不听话。兜底策略则是对“模型给出了空值或离谱答案”的处理方案我一般会在提示词最后加一句“如果你认为问题无法基于给定上下文回答请输出信息不足”然后工程侧据此走第二条备选链路。调试prompt时一个务实的建议是不要凭感觉逐字修改而是建立“单变量对照测试法”。每次只改一个要素——比如只换示例、只调角色描述、只改格式约束——然后在一组固定的测试用例上跑至少五遍看输出稳定性和准确率变化。没有这套流程的话你永远是在用运气改提示词根本无法判断是哪个改动产生了效果。3.3 上下文与检索增强治好“记忆健忘症”如果做AI应用只调模型不作任何上下文管理那几乎不会有什么实用价值。大模型的默认上下文窗口是“一次性的”每次对话开始它都不记得你之前聊了什么。解决这个问题的常规路径有三条一是靠对话历史拼接简单直接但会随着轮次增长而膨胀二是靠向量检索召回相关背景材料目前业务场景中用得最多三是靠外部记忆模块写摘要或结构化沉淀长期交互场景必备。我在项目中主要做的是把RAG流程做扎实因为检索增强几乎是现在大多数知识类AI应用的标配。完整实现链路是用户查询进入系统后先做意图分类和关键词重写然后基于重写后的查询去向量库做相似度检索返回Top-K相关切片再把切片拼装进提示词的上下文区域同时附上来源标识和置信度信息最终由模型综合生成回答。这里面有一个特别容易被忽略但极其影响效果的细节查询重写。用户原始的搜索表达往往不适合直接做向量匹配比如用户问“那篇文章里说的方法3是什么”如果不重写直接去向量库检索大概率会检索到“文章介绍”之类的泛泛内容。我在工程里维护了一个轻量的查询重写层借助大模型做一个“把指代关系落到具体主题”的改写之后再做检索。这一改动实测下来能让命中率提升20%以上算得上整个RAG链路里投资回报率最高的一步。3.4 Agent与工具调用让AI从“会说”到“会做”AI Agent的核心能力在于“可以调用外部工具完成任务”这也是我从零构建AI应用时最花功夫的部分。一个可用的Agent必须包含五个组件任务分解器、工具清单注册表、调用决策层、结果解析器、状态记忆管理器。前四个组件大家多少都能理解第五个状态记忆管理器经常被忽视——它负责记录当前任务已经执行到哪一步、有哪些中间结果、下一步需要什么。工具调用的协议设计上我采用了一个非常工程化的方案每个工具都登记一份声明式配置字段包括工具名称、功能描述、入参定义的JSON Schema、出参格式、超时时间和最大重试次数。模型在决定是否调用工具时其实就是根据工具描述和当前上下文做一次“函数选型”这比在提示词里用一段长文本描述工具规矩要稳定得多。多Agent协作是我在项目后期才验证的进阶能力也是近期“多AI协作”这个热门方向的核心。我的做法是定义了一个极其轻量的“角色通信协议”每个子Agent在完成自己模块的任务后把结果以结构化消息的形式发到协作总线由编排Agent决定下一步是把消息传给另一个Agent、还是直接汇总输出。这种架构遇到任务边界清晰、可以并行拆解的场景时效果显著但我也必须提醒一句如果任务本身高度耦合、各步骤强依赖多Agent架构反而会因为消息传递开销和意图偏移表现得比单Agent更差。所以不要为了追热点而强行上多Agent先想清楚你的任务是不是真的适合“分工协作”。4. 评估体系与质量保障4.1 从“感觉还行”到“有指标可依”做AI工程一个难忍的地方就是“效果好坏全凭感觉”——今天模型回答得不错明天同样的问题换了个问法就翻车。为了终结这种状态我从项目一开始就坚持建立一套可量化、可回归、可追踪的评估体系这也是我在“ai-engineering-from-scratch”整条链路里最想强调的一环。我把评估维度分成三块准确度、稳定性和合理性。准确度考察“关键信息是否与参考答案匹配”用LLM打分或关键词抽取两类方式组合验证稳定性考察“同一输入多次运行时结果变化程度”这在大模型应用里非常重要因为温度参数、采样策略都会造成输出波动合理性则考察“回答内容是否来自给定上下文、有无编造信息”对RAG类应用来说这是底线指标。为了实现自动化评估我搭建了一个评估运行器把线上真实用户请求中的脱敏样本加上人工构造的边界测试用例组合成评估集每次修改提示词或更换模型后跑一次全量评估集把指标结果和上一版对比任何一个指标下降超过阈值就拦截发布。这套机制听起来简单但它在实际工程里的价值巨大——它让AI应用具备了传统软件工程中“CI回归测试”的等价能力也是我后续所有迭代能够安心推进的底气。4.2 可观测性AI系统的“黑匣子破解”普通后端服务出了问题看日志、看监控就能定位。但AI应用出了问题时最大的困难是你不知道是哪一环出了问题——是数据没检索到是提示词写得不妥是模型本身抽风还是输出格式解析失败了为了回答这些问题我给自己定了一条铁律从第一行代码开始全链路埋点。我设计的观测体系分为三层。第一层是链路层每一次用户请求都生成一个全链路trace ID从输入到检索、从提示词拼装到模型响应、从结果解析到返回输出每一环节耗时和中间产物全部落盘记录。第二层是行为层记录模型的原始输出、解析后的结构化结果、以及工具调用触发的真实副作用。第三层是质量层对每一次线上响应做低成本自动评分把分数低于阈值的样本捞出来单独入库定期交给人工抽检。这一套观测体系在执行时的确增加了不少工作量但收获远远大于成本。我曾经排查过一个诡异Bug用户反复反馈回答不准但离线评估集表现很好。最后就是靠全链路日志发现线上请求在检索环节拿到了空结果原因非常简单——用户问题经过了一个新加的词权重预处理导致偏了方向。这在没有观测体系的系统里恐怕要猜上几天。如果你从这个项目中学到一件事我希望是“可观测性不是运维阶段才补的作业而是从第一天就要写进代码里的约定”。5. 常见问题与排查技巧实录5.1 token消耗失控AI工程里面最现实的烦恼之一就是token成本不受控。明明功能没多大每个月账单却蹭蹭涨。我的经验是token消耗通常发生在三个盲区对话历史无限累积、检索结果过多导致上下文膨胀、输出格式要求不严导致生成了大量废字。优化手段有优先级从性价比最高的开始做第一给历史会话设滚动窗口比如只保留最近五轮对话内容更早的信息通过总结压缩为一个摘要块来保留第二控制向量检索返回的切片数量Top-K从默认的5条调整到3条在多个场景下准确率几乎不掉但token消耗少了近三分之一第三在输出约束里加上“只输出必要字段”“不要重复问题内容”“不要输出思考过程”等压缩指令第四有条件的话在模型层做路由简单问答走低档小模型复杂推理才走能力更强的大模型。走完这几步成本基本能降到优化前的五成左右。5.2 模型回答经常“变”线上体验不稳定大模型输出天然存在随机性哪怕温度设为0在一些模型实现里也可能因为采样细节产生漂移。第一个排查点是确认推理参数是否真的传到位了有次我在服务框架里发现温度参数根本没进到调用参数里等于一直在用默认值运行第二个排查点是提示词里是否存在含混的开放式指令凡是“可以”、“比如”这类词换成明确的固定动作会显著降低输出漂移第三个做法是把输出结构模式化——让模型先输出包含枚举合法值的选择字段再做自由文本生成这样至少把“可解析的部分”和“可变动的部分”分开核心逻辑不再受影响。5.3 上下文窗口不够用长文本处理总被截断处理长篇文档时“上下文长度超限”几乎是必然踩中的问题。我的处理思路是“切-选-拼”三阶段策略。切先把长文档按语义边界切成独立切片每片控制在八百字左右选通过一次检索选出与当前问题最相关的三到五块拼不按原始顺序简单拼接而是把它们和用户问题一起放入提示词时按“内容与问题的相关性排序”把最相关的放在最靠近问题的位置。长文本不用全塞进上下文让模型只看见它需要看见的部分才是工程上最合理的解法。5.4 常见问题速查表现象排查思路常用解法回答与事实不符看检索结果是否准确优化查询改写、检查切块粒度、提高Top-K同一问题每次回答都不一样检查温度、验证输出约束设置温度到0、增加格式模板和推理固定性提示词修改后效果变差回滚对比上版提示词建立提示词版本库和评估差异集工具调用没反应或报错检查注册表与出入参协议弱化工具描述中的歧义、增加解析容错调用外部接口超时检查网关与模型平台状态增加重试和降级策略、配置熔断线上成本突增分析链路日志统计token压对话窗口、控检索量、路由分层5.5 避坑心得三条行为准则第一永远不要在生产环境直接调提示词。所有修改先在评估集上跑一遍确认指标不降再上线这个习惯能挡住绝大多数低质量问题。第二时刻保留一份“坏答案日志”。你可能觉得这是很简单的动作但它是后续判断哪些边界需要加固、哪些提示词容易翻车的最好传感器。第三做AI工程要保持“有限信任”心态。模型输出的任何内容在进入业务系统之前都要经过格式校验、逻辑校验或人工确认想象它是你团队里最聪明的实习生但有时也会犯低级错误——责权边界必须清晰。6. 在实践中的一些体会走到这一步我最大的感受是AI工程从零开始这件事真正难的其实不是调用模型也不是把几个框架拼起来而是建立一套“让AI行为可理解、可预测、可控制”的思维惯性。从我的实际经验看无论外部的框架和技术名词怎么变数据质量、提示词管理、评估闭环和可观测性这四根支柱一直不会过时。你搭建的第一版不需要多么宏大哪怕只是接一个大模型API配合一套评估脚本再配上完整链路日志就已经比绝大多数“跑起来再说”的AI应用走得更远了。另外想分享一个实操层面的小心得项目初期我会刻意要求自己每周做一次全链路复盘把线上日志里的低质量回答、评估集里的失败用例、观测面板里耗时异常的请求逐条过一遍。这看起来会增加时间开销但正是在这些“非创造性”的重复劳动里才能真正理解系统的边界在哪里。以后不管是换模型、调提示词还是加新工具判断力都会变得敏锐许多。如果这篇内容能让你避免几个我当年踩进去的坑就在下一轮迭代时先为自己搭一个评估回路吧。好东西都是长出来的不是堆出来的。