开头我先不绕弯子：“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最小方案与参数清单

各环节说得再玄，也必须有落地参数。下面这套配置来自我跑过的一个合同问答项目，全栈代码不多，完全可以照抄着起步。我先把思路说清楚，再给参数。

先说思路：文档进来先做切分，存入向量库；用户提问时，把问题向量化，检索相关的块；然后把问题与块一并交给大模型，让它生成答案。这套流程听起来简单，真正决定结果差别的全都在细节里。我用一个表格把我踩过一遍后的推荐值列出来，方便你直接抄：

再看一个非常实用的技巧，叫“查询改写”。用户提问经常是模糊的，比如“合同什么时候到期”，系统如果直接拿这句话去检索，命中质量往往一般。我一般会在检索前加一个轻量步骤：让大模型把用户问题改写成更利于检索的表述，比如“找出合同中关于有效期与自动续约条款的内容”。这个改写动作通常只需一次额外调用，成本可以忽略，但对检索精度的提升很明显。

这一步在代码上并不复杂。核心结构是：先拿用户原始问题调一次模型获得改写后的查询词，再拿这个查询词去向量库检索。需要注意的是，改写这步的模型不需要很强，小参数模型足够，能用便宜的就用便宜的。整套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分的打分标准，再汇总成平均分。这里给一个我在项目中使用的表格：

评估集怎么建？最有效的来源是真实用户反馈和客服记录。先把历史高频问题整理成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 线上问题快速排查表

最后整理一张速查表，线上出了毛病直接对号入座，能帮你少走不少弯路：

这几张表配上面的章节，基本覆盖了从零开始做AI工程的主干。最后再分享一个小习惯：从项目第一天起，就把每一次Prompt的改动、评估集的变化、模型的上下游版本都记录在案。我后来发现，几乎所有“莫名其妙变差了”的问题，最后都能在记录里找到元凶。AI工程没有那么多玄学，多数问题都是可以定位、可以修复的工程问题——前提是你把它当成工程来做。