开头我先不绕弯子“ai-engineering-from-scratch”是我给自己立的一个硬性目标——不靠所谓“提示词魔法”不依赖任何现成平台的黑盒封装从最底层的能力开始把AI工程这条链路完整地趟一遍。写了很多年代码、玩了不少大模型之后我的真实感受是AI工程和普通人理解的“用AI写个文案、画张图”完全是两码事。前者是一套系统性的工程能力包含需求拆解、上下文设计、数据接入、工具编排、评估回归、成本控制后者只是这套能力链路的最后一步。这篇文章不是概念科普更不是“AI玄学”分享。它是把“从零开始做AI工程”这件事拆成可执行路线图先搞清楚你真正要解决的问题再打牢提示词基本功然后进入RAG、Agent这些主流工程范式最后用测试、成本、运维手段让东西真正能上线。无论你是刚入行的开发者、想转AI方向的技术人还是被老板一句话“做个AI功能”砸中的全干工程师这套思路都能直接拿去用。下面所有内容都来自我实际项目里的取舍和踩坑尽量说人话能抄作业的就直接抄。1. 先想清楚你要工程化的是“智能”不是“咒语”1.1 为什么看了一百个教程却还是做不出能用的AI功能我见过太多这种情况收藏了一堆“价值万元的Prompt模板”买个会员把市面上主流模型问了个遍但真要你做一个“自动汇总行业政策并生成分析简报”的小工具时照样卡壳。原因很简单——你把AI工程理解成了“找对咒语”而真正的工程化是把一个模糊的业务需求翻译成模型能执行的指令、程序能跑通的数据流、以及用户可以信任的稳定输出。举个例子。你在对话框里让模型“帮我写一份新能源行业周报”这属于“聊天”你做一个系统每周五定时抓取行业新闻、用Embedding筛选出高相关段落、再调用模型按照固定模板输出一份简报自动推送企业微信这属于“AI工程”。两者之间的差距不是模型能力决定的而是你有没有把流程拆成输入、处理、输出、反馈四个环节并且每个环节都有明确的规则兜底。从零开始的AI工程第一步根本不该是学模型原理而是学会“需求翻译”。你要能把“让AI帮我们提高客服效率”这种口号拆成“问题分类→知识库匹配→人工介入条件→工单生成”这样的具体链路。拆得越细AI能做的部分就越清晰剩下的交给代码。我在实践中发现一个规律一个AI项目如果做到一半推倒重来90%不是因为模型不行而是原始需求没有被拆解成模型可执行的原子任务。1.2 五大件输入、上下文、工具、动作、反馈我习惯把任何AI工程系统都抽象成五个部分反复套用这套框架基本不会跑偏。第一是输入设计。用户给了什么是自然语言、结构化表单、还是系统日志输入决定了你要不要做预处理、格式转换、意图识别。第二是上下文构建。模型能看到的“世界”只有你塞进Token窗口的内容所以信息怎么筛选、排序、截断直接决定回答质量。第三是工具开放。模型需要“动手”的能力比如查数据库、调API、读网页、发邮件。没有工具的模型只是个会说话的脑子有工具的模型才是个能干活的实习生。第四是动作编排。模型输出结果之后你的系统要不要继续执行是返回给用户还是写入数据库还是触发下一个流程第五是反馈闭环。回答得好不好用户点了赞还是点了踩系统能不能把它变成下一次优化的一环这五个部分都齐了AI工程才叫闭环少一个都只能算“高级聊天”。这套五件套还有一个好处它是模型无关的。今天你用的是这个模型明天换另一个只要五件套结构不变换的就是一个底层引擎业务逻辑不需要重写。这就是工程和玩具之间最本质的差别——你要的是可替换、可测试、可演进而不是一段写死在代码里的“神谕式”提问。2. 打地基Prompt Engineering是基本功不是玄学2.1 六个能直接抄走的Prompt结构模板很多人把提示工程当成“文学创作”其实它更像“结构化需求文档”。模型再强也需要你给足信息、给清约束。我在团队内部沉淀了一套六段式模板几乎覆盖日常80%的场景你完全可以照抄角色定义说清楚“你是谁”。不仅是“你是AI助手”而是“你是拥有十年财税经验、熟悉小微企业所得税优惠政策的资深顾问”。角色越具体模型采用的知识框架越明确。任务描述你要模型做什么用一两个动词开头比如“阅读以下政策法规列出其中适用于年营收低于300万企业的条款”。这里的关键是给出可检验的交付物动词——列出、对比、判断、改写而不是“分析一下”这种虚词。背景信息与输入数据把需要处理的内容直接贴在Prompt里且做必要的边界标注例如“以下是原始政策全文用【开始】和【结束】标记”。模型是“上下文即信息”的动物你喂什么它信什么。约束条件不能怎么做必须怎么做。比如“不要使用超出原文的信息”“每条回答不得超过200字”“如果信息不足直接回复信息不足”。输出格式指定结构化格式。JSON、Markdown表格、带编号的清单都可以直接要求。这一步对后续程序解析至关重要我后面会展开。示例Few-shot给一个输入/输出的配对示例。哪怕只有一个回答的稳定性和风格一致性也会明显提升。别嫌麻烦示例是成本最低的“模型对齐”手段。我自己整理这样一个模板列表之后团队新人上手写Prompt的效率提高了不少。语气和措辞固然重要但真正拉高下限的是结构的完整度。你随便挑一个项目里的Prompt检查大概率会发现漏了约束或漏了输出格式——补上这两样很多“玄学”问题当场消失。2.2 从“写得好”到“控得住”让输出稳定可复用只追求“看着好像不错”的Prompt还配不上“工程”两个字。工程级的Prompt至少要做到三点可复现、可解析、可容错。可复现意味着同样的输入Prompt模型多次调用输出的内容在结构上应保持一致。做法就是我在上面提到的约束条件与输出格式双管齐下。注意你不该要求模型“每次都一模一样”大模型天然有随机性结构稳定已经足够工程使用。温度参数也要控制需要事实性回答的场景温度可以调到0.2甚至更低需要创意发散的任务再调到0.7以上。工程上千万不要一个温度打天下。可解析是很多初级项目最容易崩的地方。你要让程序读取模型输出就尽量让模型输出JSON。但大模型输出JSON时偶尔会夹带Markdown标记或多余解释我常用的解法有三种一是Prompt里写明“只输出JSON不要输出任何其他内容”二是在代码里用正则把JSON块抠出来三是“输出安全兜底”——解析失败时给一个默认结构并把原始输出记录到日志里。记住一个原则用户的体验不能依赖模型输出的运气解析层要做最坏的打算。可容错则是从产品和系统层面接受“模型不是确定性函数”。你在设计Prompt时就要想好如果这次回答质量很差系统该怎么办是重写一次、换一个模型、还是直接交给人工这个兜底逻辑越早埋进系统上线后你睡得越安稳。提示Prompt不是一成不变的静态文本它应该像代码一样被版本管理。输出好的Prompt存进代码仓库配合评估集做回归测试才能保证你下次优化不把以前跑通的结果搞坏。这一点我在第五节展开讲。3. 上强度RAG是当下落地率最高的工程范式3.1 RAG四环节拆解切分、检索、重排、生成如果你的AI应用需要回答私有业务问题比如“上季度华东区销售额波动的主因”“这份合同里有哪些违约金条款”你也想让模型基于实际数据而不是凭空瞎编。该怎么让知识“长”进模型这就是RAG检索增强生成出场的场景。它的本质一句话就能说清先让模型“查资料”再让模型“照着资料写答案”。这套流程我拆成四个环节。切分把几千页文档切成可以检索的小块。切得太小上下文碎片化信息不完整切得太大检索精度下降还白烧Token。我的经验是通用文本按300到500字切一块保留一定的句间重叠通常50字左右表格、代码等结构化内容则建议按逻辑边界整体切割别硬拆。切分最忌讳的是“一刀切”没有考虑文档结构。你至少应该识别标题层级让同一小节的内容尽量在一个块里这样检索时能拿到完整语义。检索把用户问题转成向量或关键词去文档库里找最相关的块。向量检索擅长语义匹配但关键词检索在专有名词、代码片段上更精准成熟系统一般做混合检索。向量库选择也别跟风。数据量在万级以内用文件型的SQLite加向量扩展就够了再往上才需要上专用的向量数据库。工程上最便宜的第一步永远不是换数据库而是先优化你的切分方式和查询改写。重排第一轮检索拉回20个候选块但真正能进模型上下文的可能只有三到五块。这个时候需要一个重排器按相关性打分把最精准的内容捞到前面来。别小看这一步。没有重排的时候检索第一名的准确率可能只有六成加一层重排在不少知识库场景能稳到八成以上。生成把问题和重排后的知识块按固定模板拼成Prompt送给模型生成答案。这里还要做一个细节Prompt里要明确告诉模型“只能基于提供的资料回答资料中没有的信息要明确说明资料不足”。这句话能有效减少幻觉。否则模型还是可能凭自己的训练记忆给你补一段“合理但不靠谱”的内容。3.2 一个能跑的RAG最小方案与参数清单各环节说得再玄也必须有落地参数。下面这套配置来自我跑过的一个合同问答项目全栈代码不多完全可以照抄着起步。我先把思路说清楚再给参数。先说思路文档进来先做切分存入向量库用户提问时把问题向量化检索相关的块然后把问题与块一并交给大模型让它生成答案。这套流程听起来简单真正决定结果差别的全都在细节里。我用一个表格把我踩过一遍后的推荐值列出来方便你直接抄环节参数项推荐配置备注切分块大小300~500字中文场景按字符数计切分块间重叠50字左右避免关键句被切开切分是否按标题切是先识别Markdown/Word标题结构检索候选集大小20~30个块给重排留足空间检索最终进入上下文块数3~5个块兼顾信息量与Token成本检索检索方式向量关键词混合专有名词场景关键词权重可拉高生成温度参数0.1~0.3事实性问答必须低温生成提示词约束强制标注“基于资料回答”有效压低幻觉再看一个非常实用的技巧叫“查询改写”。用户提问经常是模糊的比如“合同什么时候到期”系统如果直接拿这句话去检索命中质量往往一般。我一般会在检索前加一个轻量步骤让大模型把用户问题改写成更利于检索的表述比如“找出合同中关于有效期与自动续约条款的内容”。这个改写动作通常只需一次额外调用成本可以忽略但对检索精度的提升很明显。这一步在代码上并不复杂。核心结构是先拿用户原始问题调一次模型获得改写后的查询词再拿这个查询词去向量库检索。需要注意的是改写这步的模型不需要很强小参数模型足够能用便宜的就用便宜的。整套RAG的最小代码核心链路也就四五十行Python的事。很多人败在“想复杂了”一开始就上多路召回、图数据库、Agent记忆这些重装备。我的建议是先用最朴素的方案把链路跑通记录瓶颈再做针对性优化。4. 玩真的AI Agent的工程化实现路径4.1 Agent不是黑盒把ReAct循环吃透就够了AI Agent是这两年被说得最“神”的词。剥开包装Agent其实就是让模型在“思考—行动—观察结果—继续思考”这个循环里反复迭代的机制。业界管这种模式叫ReAct也就是Reason与Act的交替。怎么理解你想想自己是怎么干活的接到一个任务先想清楚要做哪几步然后动手干活干完观察结果如果结果不对换个方法再来。Agent无非就是把这套流程自动化。模型先根据你的任务输出一个“下一步工具调用请求”你的代码执行这个工具把结果放回上下文模型继续判断下一步做什么直到它认为任务完成。理解这一点之后你的工程重心就变了你不再绞尽脑汁让模型“一步到位输出正确答案”而是设计好工具和边界让模型在循环里自己逼近答案。这里需要格外留意的是工具越多模型可操作的空间越大潜在风险也越大。工具设计要遵从最小权限原则只暴露任务必需的接口别让模型持有“删数据库”这种权限。我见过多起事故模型因为在工具列表里看到了删除接口就把用户数据给清了。开源模型权限意识不强你写的工具企划说明书就得把它控制死。4.2 落地案例一个自动资料调研与报告生成Agent我拿一个真实做过的“自动调研竞品动态并生成简报”的功能来拆解这套结构可以直接平移到多数信息搜集场景。整个Agent的设计涉及三类工具网页搜索与打开、目标页面正文提取、简报模板生成。系统启动时先给模型一条总任务调研指定竞品最近一个月的公开动态包括版本更新、市场活动、用户口碑并输出一份结构化简报。然后模型进入ReAct循环自行决定先搜索哪个关键词、打开哪篇文章、提取哪些信息最后在它认为信息足够时调用简报模板工具按固定格式整理答案。下面这段伪代码是这个Agent骨架的核心你可以照着这个思路去搭自己的版本# Agent 主循环伪代码 tools { web_search: search_engine.search, fetch_article: article_parser.fetch, brief_builder: brief_template.render, } max_steps 12 context {task: task_description, observations: []} for step in range(max_steps): # 1. 让模型基于当前上下文决策下一步 action model.decide(context) # 2. 取出对应工具并执行 if action[type] call_tool: result tools[action[tool_name]](action[args]) context[observations].append(result) # 3. 模型判断任务是否完成并输出最终答案 elif action[type] finish: final_answer model.generate_report(context[observations]) return final_answer # 4. 达到步数上限强制收尾输出已完成部分的总结 return model.generate_partial_report(context[observations])这里最值得注意的就是max_steps这一步。模型在自由发挥时很容易陷入死循环——反复搜索同一个关键词、反复读取同一篇文章。你必须给循环设定硬上限到了步数就强制收尾。别把Agent当成无限耐心的员工不设上限它真的会一直“研究”下去账单上烧的全是你自己的Token。同样重要的还有“错误重试”的逻辑。我在实测中发现工具偶尔会返回异常比如网页打不开、反爬拦截、返回空内容。你不应该让整个Agent流程当场崩溃。正确的做法是把异常信息当作观察结果写回上下文让模型自己判断“这次失败了换个关键词再来”。给模型看到失败信息往往比隐藏失败处理更能产生稳定的表现。4.3 多Agent协作把一个人的活拆成一个团队单个Agent能做的事情终究有限当任务复杂度上升你想要的是“拆解并行”。这时候就会出现多Agent协作也就是让不同的Agent各司其职比如一个负责任务规划、一个负责执行检索、一个负责质量审核类似一个微型项目组。这种结构虽然听起来高级但工程难度同样水涨船高。它要求你对任务做清晰合理的拆分还要在Agent之间设计一套信息交接的协议。我最常用也最稳妥的方案是“规划者—执行者—评审者”的三角结构。规划者Agent把大任务拆成子任务清单执行者Agent拿到清单逐项完成把结果汇总评审者Agent对执行结果做质量检查不合格的打回重做。每一轮都在接收和传递结构化数据这比让多个Agent自由聊天式的协作稳定得多。这里分享一个我踩过很深的坑多个Agent协作时别让它们之间传大段自然语言也别让“聊天记录”成为共享记忆。你想象一下一个Agent输出了一长段情绪化的总结另一个Agent基于这个不精确的总结继续推理错误就会被层层放大。解决方法是让Agent之间只传结构化数据比如“任务ID、输入引用列表、结构化结论”每一种字段都有明确格式。Agent协作的稳定性不取决于谁更聪明而取决于你们之间的接口契约是否足够严格。我甚至见过一个方案把Agent之间所有的通信日志都下沉到数据库表里做审计追踪——这个习惯建议你一开始就养成否则出了事查起来会非常崩溃。5. 质量关AI应用的测试与评估怎么做5.1 模型输出会漂移测试必须自动化传统软件测试讲究确定性同样的输入预期输出是固定的。AI应用没有这个待遇。同一个Prompt配同一个模型今天跑和明天跑结果可能都不同模型厂商更新一个参数整个系统的回答风格都可能漂移。这就决定了AI应用的测试不能靠手工点两下验收必须建立自动化评估机制。我习惯把AI质量体系拆成三层。第一层是单测级评估为每个Prompt准备一组固定的测试用例每次修改Prompt或升级模型时跑一遍这组用例检查输出是否还满足要求。这相当于普通项目里的回归测试。第二层是场景级评估把用户真实会话或任务流录下来形成按模块划分的测试集系统跑完一轮看看整体链路有没有坏。第三层是线上监控对生产环境的输入输出做采样由人工或更强模型对回答质量打分低于阈值的自动告警。这里有一个非常容易忽略的管理细节Prompt和模型的组合一定要当成“代码依赖”来管。你哪天想升级模型版本先跑一遍离线评估集比对指标再决定要不要切。我在项目里亲身体会过好多次“升级模型后业务效果反而变差”的情况没有评估集就贸然上线用户投诉会直接教你做人。5.2 一份可以直接照抄的评估清单做完这些你可能更关心到底评估哪些点。我建议至少覆盖下面这些维度每条定一个1到5分的打分标准再汇总成平均分。这里给一个我在项目中使用的表格维度考察内容评分要点准确度输出是否基于给定资料、是否杜撰事实出现幻觉直接0分完整性用户问题里所有关键点是否都得到回答漏答扣分一致性多次生成的结果在结构逻辑上是否统一结构漂移扣分格式合规是否严格按JSON或模板结构输出解析失败直接0分安全性是否输出不当、违规或诱导性内容出现即一票否决可执行性建议/结论是否具备实际可操作性空话套话扣分评估集怎么建最有效的来源是真实用户反馈和客服记录。先把历史高频问题整理成50到100条覆盖典型、边界、异常三类场景再逐条标注期望答案或评价标准。规模不用太大50条精心挑选的用例性价比远超过盲目的300条。提示不要只评估“答得好不好”也要评估“答错时系统反应对不对”。模型答不出时的兜底话术、超时处理、重新生成逻辑都应当放进评估集里一起验收。用户能接受AI不懂但不能接受AI不懂装懂还态度傲慢。6. 成本与运维从Demo到上线的最后一公里6.1 成本估算别让一个请求烧掉一杯咖啡钱很多项目死在Demo阶段是因为没人算过Token的成本账。大模型API按Token计费看似单价很低用起来却是乘法关系。一个普通的RAG问答请求上下文里可能塞了系统提示词、检索出的若干个知识块、历史对话记录这还没算模型生成答案的Token。我在项目里做过一次统计一个知识库问答请求的实际Token消耗平均是用户输入字数的五到十倍。所以上线前必须做成本测算。公式很简单单次请求成本等于输入Token数乘以输入单价加上输出Token数乘以输出单价。假设你的系统提示词加检索上下文固定消耗3000 Token每小时有1000个请求日成本按人民币算就已经相当可观。我常用的优化手段有三个一是缓存高频问题完全相同或高度相似的问题直接命中历史答案省掉一整个生成流程二是按复杂度路由模型简单任务走小参数模型复杂任务再切大模型三是控制上下文体积检索到的知识块只保留关键部分历史对话做窗口截断。模型选型也同样重要。别一味追求“最聪明的模型”。如果任务只是从固定格式文档里提取字段一个小参数模型完全够用成本可能只有旗舰模型的十分之一。工程上正确的姿势是准备好多个模型按任务难度动态分配。我一度在项目里维护一个“模型路由表”按输入长度、任务类型、预算上限做分流这是控制成本最有效的手段没有之一。6.2 上线必做的三件事缓存、限流、可观测AI应用上线和普通Web应用本质相似但因为模型调用极不稳定、耗时又长运维策略要更保守。第一件是缓存。缓存策略要分两层接口层面用户短时间重复提交完全可以去重语义层面向量化的相似度超过阈值比如0.95就不必再调模型。第二件是限流与熔断。外部API不稳定动不动就超时、限流、报错。你的系统必须能承受这种不确定性否则一次上游抖动用户就看到一片加载失败。我的做法是给模型调用加上超时控制和自动重试重试次数通常设为两次并配合指数退避。第三件是可观测性。每一次模型调用的输入摘要、输出摘要、Token数量、耗时、错误码全部记录成结构化日志。没有这些数据你只能靠运气排查线上问题。我还额外建议做一个简单的“异常答案识别”机制。比如用户问的是事实性问题模型却输出了“非常抱歉作为AI我无法回答”或者明显偏离主题的内容这类输出往往以特定句式出现。写一个规则正则去命中这些信号命中后自动触发重新生成。这套小机制在项目里帮我挡住了很多线上“翻车”的瞬间。记住模型可以犯错但系统必须有办法发现错误并自我修复完全依赖模型自觉你会睡不好觉。7. 踩坑记录与排查速查表7.1 我踩过最深的五个坑第一个坑是上下文超限。上线前测试数据量不大没暴露问题上线后真实用户一问就带超长历史直接loading不出内容。后来我加了历史压缩策略把超过一定轮次的对话做摘要压缩到原长度的十分之一问题才算解决。这个教训告诉我做AI应用时必须提前假设“用户输入永远是超长的”并按这个前提设计截断与压缩。第二个坑是解析失败没兜底。当时让模型输出JSON结果线上某些请求返回了带注释的JSON代码解析直接抛异常。我原以为Prompt里写了“必须输出JSON”就够了结果现实给了我一巴掌。后来我强解析失败时进入“重生成正则提取”的第三方通道覆盖率才算拉满。模型输出永远比你想象的更不可靠这是心态问题得早点调整过来。第三个坑是缓存命中标准太宽。我当时把语义相似度阈值设成了0.85结果很多问法不同但意思相近的问题会命中同一个旧答案用户看到的是“风马牛不相及”的回复。后来阈值调高到0.95以上只在字面重复度极高的场景走缓存体验正常了。缓存是双刃剑省了钱也可能丢了准确性。第四个坑是Agent工具没有超时。一个爬虫Agent在抓某个页面时卡住了几分钟整个流程挂在那。我后来给每个工具调用都套上了超时控制超时就把“工具无响应”写回观察结果让模型自行判断。别以为模型比程序聪明程序上的“看门狗”机制永远不能省。第五个坑是升级模型前没有跑回归。有一回我把项目底层模型切到新版本离线看几个样例好像都挺对上线后才发现它在特定的“双关语”场景中输出怪异。从那以后我给自己立了个规矩任何模型切换必须先跑一遍完整评估集绝不看几个样例就拍板。7.2 线上问题快速排查表最后整理一张速查表线上出了毛病直接对号入座能帮你少走不少弯路现象优先排查项常见解法回答质量突然下降模型版本是否有变更、上下文里是否混入噪声切回旧版本、清理上下文输出格式频繁解析失败Prompt约束是否被削弱、模型是否升级强约束输出、增加重解析通道响应时间暴涨上下文是否过大、外部API是否慢压缩历史、并行检索、加超时Token消耗超标是否有重复调用、上下文是否有冗余加缓存、缩减知识块、路由模型Agent陷入死循环是否缺少步数上限、工具返回异常设max_steps、异常信息回写上下文检索结果完全离题切分是否破坏了语义、查询是否需改写优化切分、增加查询改写环节这几张表配上面的章节基本覆盖了从零开始做AI工程的主干。最后再分享一个小习惯从项目第一天起就把每一次Prompt的改动、评估集的变化、模型的上下游版本都记录在案。我后来发现几乎所有“莫名其妙变差了”的问题最后都能在记录里找到元凶。AI工程没有那么多玄学多数问题都是可以定位、可以修复的工程问题——前提是你把它当成工程来做。