★ FEATURED ARTICLE “ai-engineering-from-scratch”这个名字乍看像一个GitHub仓库的标题但我知道它更是一种状态的描述——收藏夹里堆满了大模型新闻、Prompt技巧、部署教程一打开编辑器还是不知道从哪动手。AI工程这个词被说烂了可真正从零把一个AI应用跑起来、跑稳、跑上线的人其实没有想象中那么多。这篇文章想把零碎的知识串成一条线模型选型、Prompt Engineering、RAG、AI Agent、测试评估、部署上线一环扣一环讲清楚。适合刚入行想做AI应用开发的工程师适合想从业务开发转AI方向的全栈同学也适合那些已经用API做过小demo但迟迟不敢推向生产的人。核心目标只有一个让你理解AI工程的全貌然后能照着路径亲手搭出一个能交付的系统。1. AI工程到底在“工程”什么1.1 先别急着跑demoGitHub上AI类的demo项目多如牛毛很多README截图极其炫酷Conversation流画得天花乱坠但真正把它丢到生产环境往往撑不过三天。原因很简单demo解决的是“能不能跑”工程解决的是“能不能稳定交付、维护、迭代”。这个区别就像你用一口锅炒出过一盘好菜和你在后厨同时管几十道菜、保证出餐速度、控制食材损耗、应对客诉完全是两回事。做AI工程也一样。模型只是你的“食材”真正值钱的部分是把食材变成稳定菜品的流程数据怎么清洗提示词怎么管理Agent怎么编排结果怎么评估线上怎么降级成本怎么控制。这些才是AI工程的核心。所以我特别强调一点不要被“大模型很厉害”冲昏头脑你要先接受“模型会出错、会抽风、会不稳定”的现实工程的价值就是在这个不稳定的基底上搭出相对稳定的系统。1.2 把整个系统拆成五个层次我在实际带项目和做咨询时习惯把AI系统拆成五层来看这样讨论问题不会一团浆糊。层次核心问题典型工具/技术模型层选闭源API还是开源权重选哪个底座GPT系列、Claude、DeepSeek、Qwen、Llama等数据层业务知识从哪来怎么灌进系统文档解析、数据清洗、向量库、RAG流水线智能层怎么让模型不瞎说、能规划、能调工具Prompt Engineering、Function Calling、Agent框架应用层怎么和现有业务系统集成Spring AI、LangChain、LangGraph、自研编排交付与运营层怎么测试、上线、监控、控成本评测集、可观测性、量化部署、模型路由每一层都有各自的坑。模型层的问题是选型混乱今天看到一个评测榜单就换模型明天看到一条新闻又换完全没有自己的评估标准数据层的问题是文档解析得稀烂向量检索全凭运气智能层的问题是提示词写成“聊天话术”Agent跑几步就迷路。这五层不是割裂的实际上一个生产级AI应用每一层都得有人负责。1.3 模型选型没有最好的模型只有匹配的方案模型选型是很多人最纠结的一步但也是被浪费时间最多的一步。我给一个非常实用的判断框架第一看场景。通用对话、代码生成、多模态理解、文本分类各自的优势模型不一样直接用榜单第一不见得适合你。第二看数据安全。业务数据能不能出内网这决定了你必须本地部署还是可以调用云API。第三看团队维护能力。选开源模型意味着你要自己处理部署、评测、更新团队没有这个精力就别硬撑。第四看成本。同等的效果下一个7B量化模型跑在自建GPU上和一个旗舰大模型API按token计费长期成本可能差一个数量级。聊到开源模型最近国产开源阵营确实热闹DeepSeek公开了一些智能体训练的新方法Qwen系列也持续迭代。这些消息对工程侧最大的价值不是让普通工程师去复现训练过程而是告诉我们底座模型的能力在不断上探。你在选型的时候不用太执着于“最新最热”而要看它社区活跃度、License限制、量化生态成熟度。如果一个模型连像样的量化版本都没有部署的时候有你哭的。2. Prompt EngineeringAI应用的第一道工序2.1 提示词是代码不是聊天话术很多人写Prompt还停留在“请帮我写一段...”这种聊天口吻。一旦AI项目进入工程化Prompt必须当成代码来管理要有版本、要能评审、要能回滚、要能测试。这是个认知问题。普通用户和用户聊天AI工程师和模型编程——你写的每一段系统提示词都是在定义模型的行为边界。我之前见过一个项目开发阶段提示词在测聊天窗口里试得挺好一上线就崩因为生产环境里用户输入千奇百怪有带攻击性的、有故意诱导越狱的、有超长文本。这时候才发现系统提示词完全没有兜底策略模型被用户牵着鼻子走。所以所有正经的AI工程都应该把提示词纳入代码仓库。你完全可以把每个版本的提示词单独建文件标注修改日期、改动原因、评测结果。这能帮你后期快速定位“上次还正常怎么这周就不对劲”的问题——多半就是模型底座升级或者提示词被悄悄改过。2.2 结构化系统提示词怎么写一段完整的系统提示词至少要包含这几个部分角色定义、任务目标、输入信息、输出格式、约束条件、兜底策略。角色定义告诉模型它是什么比如“你是一个客服助手只处理订单相关问题”。任务目标明确它要完成什么比如“根据用户问题从知识库中查找答案”。输入信息说清楚输入里有什么比如“用户消息、检索到的参考资料”。输出格式给出模板比如“先给结论再列出参考依据”。约束条件告诉它不能做什么比如“不要编造不存在的政策”。兜底策略当信息不足时怎么办比如“如果参考材料中没有答案明确回复‘当前知识范围无法回答’”。这里特别要强调结构化不是让你把提示词写得生硬而是让关键信息在长文本里更容易被模型注意到。原理很简单大模型的注意力机制对清晰的任务描述、明显的边界信号更敏感。你用“你是一个订单助手下面是你的工作原则1... 2... 3...”这种编号结构指令遵从度就是比“你帮我看看这个订单怎么回事”高。2.3 上下文管理和工具调用的边界大模型不是记忆力越好越强上下文窗口再大也是有限资源而且超过一定长度后模型会“迷失在中间”开头和结尾的内容它记得很清楚中间段落常常被忽略。这就是为什么AI工程里一定要做上下文管理。我的经验是把信息分成三层第一层是系统提示词放长期稳定的行为规则不占对话历史的配额第二层是检索到的相关知识每次请求动态塞入控制长度第三层是对话历史这里最需要注意超过一定轮数就要做摘要压缩不能让对话无限膨胀。工具调用则是Prompt层面另一个关键设计。意思是你给模型提供几个函数每个函数配一份JSON Schema格式的“使用说明书”模型根据用户请求决定要不要调用、传入什么参数。这解决了“模型缺乏实时数据”的痛点。设计工具说明时有两个坑一个是描述写得太模糊模型不知道该什么时候用它另一个是工具太多模型反而选择困难。原则上工具数量能少则少描述里写清楚“什么时候用、什么时候不用”比堆一百个工具效果更好。2.4 Prompt也要像代码一样做回归测试提示词是AI应用里最脆弱、也最容易被忽略的瓶颈。改了系统提示词里一句话可能整个输出风格都变了。所以从第一次写Prompt开始就要配一个小的评测集。评测集不用很大先弄几十条典型的输入输出对。每次改Prompt就自动跑一遍评测集看看准确率、格式合规率、拒答率有没有变化。后面我会单独讲评测系统但在Prompt阶段你要先有这个意识任何一处提示词的修改都是一次代码变更必须带着证据上线。我碰到过很多团队上线后效果崩了复盘发现是有人“顺手”在系统提示词里加了一句讨好用户的话结果模型变得只会拍马屁不会干活。这类事故靠Review约定完全可以避免。3. AI Agent让模型从“回答”变成“干活”3.1 Agent的本质是循环不是玄学AI Agent是当前最热的概念但很多人的理解是错的。Agent不是天上掉下来的神秘智能体它的核心是一个循环推理下一步做什么调用某个工具观察工具返回结果再决定下一步。这套机制有一个经典名字叫ReAct循环理解它你就理解了Agent的骨架。我用一个类比解释。你给一个实习生布置任务“去统计这个月的订单数但数据库密码在运维那里你去要一下。”如果这个实习生只会背标准答案他肯定卡死。但一个会干活的实习生会这样先分析任务发现需要数据库权限去找运维拿密码拿到后执行查询发现格式不对再调整SQL最后把结果整理交给你。Agent做的就是这个过程只不过把“分析、行动、观察”变成了模型的循环推理。这个循环执行得顺不顺差别在于你有没有给它足够好的“眼睛”和“手”。眼睛是读到的信息手是能调用的工具。很多Agent项目死在第三轮循环原因就是上下文里塞满了无用信息模型在前面几轮推理里已经把自己绕晕了。3.2 工具注册与Function Calling的工程细节Function Calling是Agent落地最关键的工程点。逻辑听起来简单模型不直接执行代码它只负责决定“该调用哪个工具”和“传什么参数”真正执行由你的程序来做。但工程细节非常多。第一工具定义里的description要面向模型的“意图理解”而不是面向人。比如你写一个查天气的工具描述不要写“接收城市名返回温度”而要写“当用户询问某个城市当前或未来天气时使用其他情况不要使用”。这样能显著提升工具调用的准确率。第二工具执行的结果要整理好再塞回上下文不要直接把原始报错丢给模型。第三工具会失败、超时、返回空结果你必须设计好失败分支要么让模型换一个工具要么明确告诉用户失败了不能卡死在那里做无效循环。我建议所有刚开始做Agent的团队先写一个手工编排的伪Agent把所有分支都跑通了再上框架。直接套LangChain的AgentExecutor看起来快出了问题你根本不知道循环内部发生了什么。3.3 记忆系统别让Agent“失忆”Agent一旦进入持续对话场景记忆问题立刻出现。模型本身是无状态的每次请求都是独立的你需要主动为它搭建记忆系统。记忆分三层。第一层是短期记忆就是当前对话窗口的历史消息。这层需要做长度控制超长时用摘要压缩保留关键事实而不是逐字保存。第二层是长期记忆通常存在向量数据库里比如用户之前聊过的偏好、历史任务记录需要时检索出相关内容放回上下文。第三层是结构化记忆用表格来存比如用户ID、当前任务状态、待确认参数这类信息不适合放向量库直接查记录更可靠。很多Agent“做不下去”不是因为模型不够聪明而是因为它不记得上下文用户说了三分钟后又重复问同一个信息。这种体验非常糟糕。所以设计记忆系统时先列一个问题“哪些信息需要跨对话保持”再决定用什么存储不要一上来就搞复杂的向量记忆框架。3.4 多智能体编排的坑多智能体协作现在很火宣传上是“多个模型像公司一样分工合作”但工程上它带来的复杂度是指数级上升的。我见过不少项目业务完全不需要多Agent但架构非要拆成“规划Agent、执行Agent、审查Agent”结果每一层都在转述消息上下文膨胀严重最后模型互相甩锅输出质量还不如单个Agent。什么时候真正需要多智能体当一个任务可以被清晰拆成几个独立角色且每个角色需要的上下文高度隔离时多智能体才有收益。比如一个写代码的Agent和一个做代码审查的Agent两者看到的上下文不同合并在一起会造成灾难。另一个经验是多智能体之间传递的每一轮消息都会消耗Token你要对通信成本有心理预期。我做过一个四Agent协作的实验一次任务下来Token消耗比单Agent高5倍效果提升却不明显。所以我的态度是能用单Agent解决的绝不拆多Agent真要拆先画清楚谁和谁交互、传什么消息、失败怎么兜底。4. 工程化三件套数据、RAG与微调4.1 高质量数据是唯一的燃料不管你是不是要微调模型数据都是AI工程绕不开的环节。RAG要数据检索评测要数据积累Agent要数据反馈。很多项目死在“模型选对了、链路搭好了但业务知识是空的”。数据工程在这里主要指把散落在PDF、Word、网页、数据库里的业务知识整理成模型能有效利用的形式。第一步是清洗去掉页眉页脚、重复段落、乱码字符第二步是结构化给文档打标签、分章节第三步才是分块和向量化。这些活不性感但没有它们后面所有环节都是空中楼阁。我还见过一个高频错误直接把几千页的PDF全塞给模型以为上下文窗口大就够了。结果模型在长文本里挑挑拣拣回答得又慢又容易漏关键点。正确的思路永远是“先检索再作答”而不是“全量喂入”。4.2 RAG和微调别搞反了很多刚入行的人一听到“模型不够聪明”就想去微调一微调就上GPU一上GPU就烧钱最后效果还不一定好。实际上大部分场景RAG才是优先级更高的方案。我梳理过两者的适用边界需求类型推荐方案原因知识库问答、实时信息RAG可以随时更新知识不需要重新训练输出格式严格、语气风格固定微调让模型学会固定的表达习惯私有专业术语多微调配合RAG让模型认识术语再检索外部细节冷启动、快速迭代阶段先RAG成本低、可控性强、出问题好排查简单说RAG是让模型“查资料”微调是让模型“改习惯”。大多数项目一开始只要“查好资料”就够了微调等产品形态稳定了再考虑。另外微调无法解决“知识时效性”问题模型微调完知识又过时了你还得重训这个周期长到难以忍受。4.3 RAG流水线实操RAG其实是一套流水线每一个环节都有可以优化的地方。我按顺序讲一份可直接复用的实操方案。第一步是文档解析。PDF、Office文档别用普通解析库硬啃试试把文档转成文本后人工抽查十页确认没有乱码和截断。这一步决定了后面检索的天花板。第二步是分块。经验值给你作参考通用文本用512到1024个Token左右的分块大小分块之间保留64到128个Token的重叠。分块太小语义被切碎分块太大一个块里塞了太多主题检索噪声变大。没有绝对最优你需要在自己的数据上做实验。第三步是嵌入向量化。中文场景可以优先考虑开源的BGE系列或商用Embedding接口选型标准是“在你的业务问题集上检索准确率高”而不是榜单数字好看。第四步是向量存储。轻量场景直接用pgvector或SQLite向量插件就行先跑通再上Milvus这类专业库。很多业务远没到需要重引擎的量级。第五步是检索。TopK一般从3到10之间调太少了容易漏太多了噪声多。如果你发现检索出来的片段牛头不对马嘴优先排查切分和Embedding而不是调大TopK。第六步是重排Rerank。这是一个很容易被忽略但性价比很高的环节。检索召回几十条候选后用重排序模型精排一次只取前几段进上下文回答质量会有明显提升。最后是引注设计。所有回答都应该给出来源片段这一是让用户能自查二是方便你定位“模型答错是因为没检索到还是检索到了不会用”。4.4 微调的真实现场如果你确实走到了要微调这一步我提醒三件事。第一微调需要的数据格式必须是“指令-回答”成对的结构靠凭空想象生成训练集是不行的优先从真实业务日志里整理输入和期望输出。第二效果验证要用留出集不能在训练数据里自测。第三微调后的模型一定要和底模做对比测试“回退检查”防止微调把模型原有的通用能力毁了——很多做垂直微调的团队都栽在这上面专业术语是懂了一些常识却变得一塌糊涂。5. 测试、评测与上线部署5.1 AI应用不能只测代码还要测模型行为传统开发里我们写单测、做集成测试断言函数的返回值。但AI应用不一样同一个输入模型两次回答可能不一样输入稍微换个说法回答就可能塌方。所以AI工程的测试要覆盖两层一层是代码逻辑测试另一层是模型行为评测。我建议你尽早建立“评测集机制”收集真实的用户问题可以是几百条给每条标注期望的回答要点或评分标准。每次系统改动就在评测集上跑一遍用规则或者模型打分观察准确率、拒答率、格式合规率的变化。没有这个机制你做任何优化都是靠感觉上线后出问题也不知道是哪次改动导致的。这里顺便提一句现在热门的“AI测试开发”方向本质上就是用大模型来辅助生成测试用例、构造对抗样本。效率提升确实明显但你要留个心眼大模型写的测试用例不一定覆盖到业务的关键路径人工抽检评判仍然不可少。5.2 评测方法规则、人评与LLM as Judge评测AI输出的方法大致有三类。第一类是规则评测适合可以程序化校验的场景比如“是否包含指定字段”“JSON格式是否合法”速度快且稳定。第二类是人工抽检适合开放式的最终效果判断比如对话体验、文案质量人力成本高但最可信。第三类是LLM as Judge让一个大模型当裁判打分适合中等规模批量评测但存在位置偏差、自夸偏差等问题需要你通过设计评分标准、多次取样、用已知答案校正来缓解。从成本和质量平衡来说我建议采用“规则 样本级LLM评测 周级人工抽检”三层组合。全部靠人工迭代速度太慢全部靠模型裁判容易镜面效应——裁判和自己用了同一个底模错也错得一模一样。5.3 本地部署与推理优化什么时候需要本地部署数据不出内网是硬性要求、或按Token计费的API成本已经高到无法接受、或者你需要在离线环境跑Agent流程。这些场景下你就要面对推理优化。工具选型你直接按场景来。个人开发验证用Ollama最省心一条命令拉起一个模型服务。生产环境高并发vLLM是主流选择支持PagedAttention吞吐量高很多。边缘设备或嵌入式环境llama.cpp很有用。量化是成本与效果的权衡艺术。Q4_K_M这种4比特量化在多数场景下和半精度模型的差距很小模型体积却能缩小约75%。我见过有人为了极致省内存上2比特量化结果模型开始胡言乱语业务不可用省下的钱全赔在调试时间上完全不划算。一般从Q4或Q5开始尝试别一上来就追最小体积。部署层面还有一个高频坑并发提高时首Token延迟飙升。这个和生产环境的排队策略、KV Cache预留都有关系不能只看远程benchmark一定要在你自己的业务负载下压测。5.4 可观测性与成本控制AI系统上线后最怕变成黑盒。你必须记录每一次请求的模型版本、Token消耗、响应延迟、调用了哪些工具、用户最终是否满意。这些日志不仅用于排查问题更是调优的依据。我给自己的项目定了一个规矩没有日志的功能不允许上线。成本控制方面有两个实用技巧。一个是模型路由简单问题让小型模型处理复杂问题才上大模型用一个判单模型或分类器做分发。另一个是结果缓存相同或相似的请求在短时间内直接返回缓存结果能省掉大量重复消费。团队规模不大的时候先抓这两条比盲目上各种花哨优化都管用。6. 从入门到能打路线图与常见坑6.1 30天从零到落地路线如果你是真想开始我给你一条我自己验证过的30天路线。第一周搭环境把API调用跑通。用Python或你熟悉的语言调用一个云端大模型API实现基础的对话和流式输出。这期间可以做点小实验比如用不同Prompt让模型扮演不同角色感受指令遵从的变化。IDE里装上AI编程插件比如PyCharm的AI助手让插件帮你写胶水代码把精力留给真正的逻辑。第二周做一个RAG知识库问答。选一个你熟悉的文档集比如产品手册跑完整的解析、分块、向量化、检索生成链路。把评测集建起来每天记录准确率的变化。第三周做Agent。选一个需要多步骤的任务比如“根据订单文件生成周报”让Agent学习调用工具、处理失败、整理结果。这周的重点不是炫技而是把循环逻辑吃透。第四周部署上线。用本地推理或云API把应用部署出来做压测记录并发、延迟、成本数据然后做一轮优化迭代。一个月跑下来你对AI工程的认知会比看三百条资讯都深。6.2 常见问题排查速查表症状可能原因排查建议回答与事实不符检索召回没命中正确片段检查切分粒度、Embedding选型、TopK阈值模型拒绝回答简单问题系统提示词约束过严重新审读兜底策略放宽拒答条件上下文窗口超限对话历史无限膨胀加摘要压缩限制历史轮数工具调用混乱工具描述不清晰或工具太多精简工具数量改写description首Token延迟高并发排队或量化不合适压测看瓶颈调整缓存和路由Token成本飙升上下文冗余、跑偏的Agent循环记录每次请求的Token消耗定位大头这些坑我几乎都在真实项目里踩过。尤其是“上下文窗口超限”很多开发者第一反应是换更大窗口的模型完全没想过自己做摘要压缩。换到百万级上下文的模型后延迟和成本同时爆炸问题依然没有根治。6.3 别只盯着聊天机器人最后想提醒一点AI工程的机会远不止“聊天网页版”。我最近观察到不少行业软件都在悄悄做AI化改造比如立创EDA这类专业设计工具也开始集成AI助手这说明AI工程正在渗透到每一个垂直工具里。如果你只会在通用聊天窗口里调Prompt其实还停留在用户层面真正把你和普通用户区分开的是你能否把AI能力嵌到一个具体的工作流里——自动生成工程文档、辅助测试用例生成、在IDE里做代码审查辅助这些都是AI工程的用武之地。掌握“从零构建”的内功后你会发现所谓的新概念本质上都还是我前面讲的那五层系统在不同场景下的组合而已。懂得这些无论热点怎么变你都能很快拆解它的工程实现路径。
阅读完成 · 觉得有帮助？
