大概从去年开始我隔三差五就会收到同一种问题“我也知道大模型很能干活但真要自己动手构建一个能处理实际业务的东西应该从哪里开始”问的人多了我发现大家缺的其实不是某个模型账号也不是某个工具的下载链接而是一条把AI应用真正做成“工程”的完整路线。这篇内容是我从零搭建AI工程化项目的复盘涵盖了提示工程、Agent能力、工作流编排、测试评估和上线监控这些环节。适合后端工程师、算法工程师也适合所有想把大模型认真用起来的产品技术团队。你完全可以把它当成一份避坑地图来翻。1. 先说清楚AI工程化到底是个什么“工程”1.1 别再把它当成“写提示词”最容易低估的一件事是AI工程化并不等于“写一段好提示词”。提示词只是你和模型之间沟通的界面真正做工程的时候还要回答一连串更实际的问题模型输出的格式谁来校验和解析上下文超限了怎么办模型需要调用外部系统通过什么方式接进去需求变了怎么做自动化回归线上出了问题怎么快速定位到具体哪一步我打个比方。提示词像菜谱写清楚“盐放几克、煎几分钟”照着做一道菜没有问题。但AI工程化是开餐厅要考虑备菜、供应链、质量控制、上菜顺序、后厨分工还要处理客诉。单靠一份菜谱解决不了开餐厅的所有问题。所以从零开始做AI工程化第一件事是建立系统观你真正要交付的不是一次对话而是一条贯穿业务系统的自动化链路。提示词只是链路里的一部分模型在链路里完成的是某一类认知任务而工程化负责的是给这些认知任务配上可靠的输入、可控的执行和可反馈的输出。1.2 从零起步的三条主线把过去一年多的实战经验浓缩一下我认为有三条主线必须理清。提示工程解决“模型怎么准确理解任务”的问题。包含角色设定、Few-shot示例、输出约束、链式思考这些基本功。Agent技术解决“模型怎么自主完成多步任务”的问题。包含意图规划、工具调用、结果反思、多轮循环。工作流编排解决“AI能力怎么嵌进业务链路”的问题。包含流程状态、分支条件、人工审批、异常降级。很多人把这三者混为一谈实际它们是不同层次的东西。提示工程是最底层的手艺Agent是把提示词扩展成“行动循环”工作流则是把这些能力放进一个可控的业务管道里。比如客服工单助手这条链路提示词负责让模型理解工单内容工具调用让模型能查订单状态工作流则决定“哪些工单自动回复、哪些转人工、哪些进审批”。我习惯用一张表来对比传统软件工程和AI工程化的差异这个差异直接决定了你要用一套全新的方法去构建。维度传统软件工程AI工程化需求确定性输入输出基本明确结果语义开放只能约束边界状态管理程序变量、数据库明确上下文窗口、会话记忆新增状态维度测试方式断言结果评估语义质量加业务指标调试方式断点、堆栈需要全链路日志与提示词快照上线标准功能验收需质量基线加成本预算加人工兜底这张表不是空谈每一个差异在开发过程中都会变成实打实的坑。1.3 从零起步的技能顺序如果你是一个人或者小团队我建议按这个顺序补技能先会写提示词并掌握结构化输出接着会用API做函数调用然后能搭一个简单的检索增强流程最后再上Agent和工作流编排。不要跳过基础直接玩花活。我见过不少开发者一上来就装一堆Agent框架结果连“模型没按我的格式返回JSON”这个问题都处理不了。基础技能的作用不是炫技而是让你在框架失效的时候仍然能手工把链路救回来。2. 工具链怎么搭先搞出一套能跑通的AI开发环境2.1 选型的底层逻辑本地模型还是云端API工具链搭建的第一个选择题是用本地模型还是云端API。我见过不少团队卡在选型上其实可以从三个约束出发数据敏感度、预算、实时性要求。本地模型可以通过Ollama这类工具来跑适合数据不能出内网、预算紧、对延迟不敏感的场景。优势是隐私好、调用免费缺点是能力天花板明显复杂推理容易翻车。云端API的能力更强尤其适合数学、代码生成、复杂多步推理而且按量计费、不需要自己维护显卡缺点是数据出域有网络依赖和成本波动。我的建议很直接初期用云端大模型跑通原型同时把关键链路抽象成统一接口别把供应商绑死在代码里。这两者的对比可以简单看这张表。对比项本地模型云端API数据隐私数据不出内网数据出域部署成本需要硬件有运维成本无部署按量计费模型能力偏弱适合固定场景强适合复杂推理稳定性依赖本地资源依赖网络与供应商典型场景隐私要求高的内部系统通用助手、复杂Agent2.2 一套最小开发环境的搭建步骤以我常用的环境为例一套最小开发环境包括四部分Python环境、IDE、模型访问层、向量数据库。命令很简单关键是理解每一层的作用。# 安装基础依赖 pip install openai chromadb python-dotenv # 如果要用本地模型安装 Ollama 并拉取模型 # curl -fsSL https://ollama.com/install.sh | sh # ollama pull qwen2.5:14b # 环境变量 .env 示例 # MODEL_BASE_URLhttp://localhost:11434/v1 # MODEL_API_KEYnot-needed # MODEL_NAMEqwen2.5:14b之所以采用兼容OpenAI接口格式的调用是为了统一访问层。不管后面换本地模型还是云端API改环境变量就能切换应用代码不用动。初始化客户端的代码也很短。import os from openai import OpenAI client OpenAI( base_urlos.getenv(MODEL_BASE_URL), api_keyos.getenv(MODEL_API_KEY), ) resp client.chat.completions.create( modelos.getenv(MODEL_NAME), messages[{role: user, content: 你好}], temperature0.2, ) print(resp.choices[0].message.content)这里我把temperature设为0.2而不是0。原因很简单纯生成类场景可以把温度调低让输出更稳定但完全为0会让模型偶发死板个别场景还会出现重复输出。0.2到0.3是我做业务处理时比较常用的范围。2.3 容易被忽视的辅助设施向量库和可观测性光能调通模型还不够工程化还需要两类辅助设施。第一类是向量数据库。RAG场景下需要把文档切片后做向量化存储Chroma很适合本地起项目FAISS适合做小规模检索生产环境再考虑分布式方案。不搞RAG的时候可以跳过但只要涉及知识库这一层就会非常关键。第二类是可观测性。从调模型的第一天起就要把每次调用的请求体、响应体、耗时、token数全部记下来。没出问题的时候这些日志看起来是垃圾出了问题时它们就是救命稻草。我后面排查那部分会细讲在这里先立个规矩日志宁多勿少。3. 核心实操一个可控的AI应用是怎么从0到1的3.1 场景定义拿“工单自动处理助手”练手我用一个最常见的业务场景来说明完整实现客服工单自动处理助手。业务需求是每天收到大量重复问题目标是把工单自动分类检索知识库生成回复草稿拿不准的转人工。整体拆成五个环节预处理清洗文本、脱敏去掉手机号和无关标签。意图分类判断工单属于订单、退换货、发票还是其他。知识检索在知识库中找到和工单相关的片段。回复生成基于片段和建议话术生成回复草稿。分级处理置信度足够高就直接回复否则转人工。注意我没有让模型一步直接生成最终答案。拆开设计的好处是每一环都可控、可测试、可替换这是AI工程化的核心思想。比如知识检索效果不好可以单独优化切块策略不需要动整个流程。3.2 提示词设计的细节不是一段大白话提示词不是一段大白话而是结构化配置。我给系统提示词定了四个必须包含的板块角色定位、任务边界、处理流程、输出约束。{ system_message: { role: 你是客服工单处理助手。, task_boundary: [ 仅处理订单、退换货、发票三类工单, 不回答与业务无关问题, 无法判断时标记为 NEED_MANUAL ], workflow: [ 1. 判断工单类别, 2. 检索知识库, 3. 生成回复草稿, 4. 给出置信度0-1 ], output_constraint: { format: json, fields: [category, confidence, reply_draft, need_manual] } } }任务边界尤其关键它定义了“模型不该做什么”这是控制风险的第一道闸口。我踩过的坑是只告诉模型该做什么不告诉它不该做什么结果它把无关问题也回答了。后来把所有禁止事项写清楚误判率一下子降下来。输出约束也要下功夫。让模型直接输出JSON程序才好解析。如果只是让模型“用中文回复”下游系统还得文本解析既脆弱又容易出错。如果任务有标准处理手法在系统提示词里加入2到3个Few-shot示例比说十句话都管用。示例要覆盖常规正确和边界处理两种情形让模型有参照。3.3 让模型“动手”函数调用与工具设计对话式的AI应用如果只靠生成文本是没办法查询物流、创建订单的。函数调用让模型自主判断“此时应该调用哪个工具传入什么参数”程序拿到参数再执行真实系统操作。这是Agent的基础能力。functions [{ name: get_order_status, description: 根据订单号查询最新物流状态, parameters: { type: object, properties: { order_id: {type: string, description: 订单号} }, required: [order_id] } }] messages [ {role: system, content: 你是订单助手}, {role: user, content: 我的订单A10001到哪儿了} ] resp client.chat.completions.create( modelos.getenv(MODEL_NAME), messagesmessages, tools[{type: function, function: f} for f in functions], tool_choiceauto, )如果返回结果里带有tool_calls字段就解析调用参数、执行真实函数再把执行结果作为一条tool角色消息塞回对话上下文继续请求模型。这个循环必须设置最大工具调用次数防止模型反复调同一个工具死循环。我刚才处理过的一个实际案例是工单说“订单一直显示运输中我想退款”。助手需要先调用get_order_status查真实物流节点再根据物流状态判断是否可以直接退款而不是光凭用户一句话就生成“可以退款”的回复。这就是函数调用的价值让模型基于真数据做判断而不是靠猜。函数设计的经验是参数尽量扁平description把枚举值范围写清楚能显著降低模型传错参数的概率。比如给status字段写“只能填processing, shipped, delivered, cancelled之一”比写“查询订单状态”可靠得多。3.4 上下文与记忆给模型装一个“工作台”上下文管理是新手最容易踩的坑。所有API都有自己的上下文窗口超过就报错。而且更隐蔽的问题是“有效信息密度”模型会把早期信息冲淡导致答非所问。实际工程里我会把记忆分成三层。短期记忆只保留最近N轮对话用滑动窗口实现。摘要记忆把更早的对话压缩成一段摘要作为背景信息放进系统提示词。长期记忆把业务数据写入向量库按需检索回来。一个最小实现是def build_messages(history, current_turn, max_rounds6): recent history[-max_rounds:] messages [{role: system, content: SYSTEM_PROMPT}] for h in recent: messages.append({role: h[role], content: h[content]}) messages.append({role: user, content: current_turn}) return messages这个函数逻辑很直白系统提示词在最前面然后是最近几轮对话最后拼上当前用户输入。hard截断会丢失一些信息但胜在稳定、省钱、不会爆上下文。等业务量大了再上摘要记忆不要一开始就写复杂的记忆管理系统。上下文还有一个值得注意的点函数调用结果如果特别长比如返回了完整订单详情不要把整个原文都塞回对话只抽取模型需要的关键字段重新拼一个精简的tool message能省不少token。4. 测试与评估AI应用翻车的重灾区4.1 为什么传统测试方法不够用传统软件工程里测试就是写断言输入一个值期待一个结果。AI应用做不到这一点同一个输入换一个温度参数或者换一个模型版本输出可能完全不同。所以AI测试的本质是把“语义质量”变成一个可量化、可回归的指标。我经常打比方传统测试像阅卷机判断选择题标准是唯一答案AI评估更像质检老师看作文标准从“对不对”变成了“合不合格”。你要先定义清楚什么样的回复算合格比如“提到了退款政策”“语气友好”“没有包含未经验证的信息”。另一个容易被忽视的点大模型应用的主要故障模式不是崩溃而是在错误的方向上自信地输出。所以测试目标必须包含兜底路径比如置信度低于阈值时是否正确地转人工而不是让模型硬答。4.2 评估集怎么建从20个典型案例开始我从一个真实项目里总结出适合起步的评估集结构。不需要一开始就搞上百条二十个精心挑选的案例就能暴露出大部分问题。类型数量说明正常标准案例8各类工单应被正确分类、生成合格回复边界案例6缺订单号、语气极差、跨类别混合问题恶意或对抗案例3试图诱导模型输出系统提示词、夹带违规内容转人工案例3疑难问题应返回 NEED_MANUAL举个例子一条真实工单是“我买了一双鞋41码穿了一天磨脚想换37码但我已经洗过了还能换吗”。这条应该分类为“退换货”知识检索应命中退换货政策里关于“清洗后商品影响二次销售”的条款回复草稿应说明可能无法换货置信度小于0.7需要转人工。每次改动提示词、模型或检索逻辑之后跑一遍评估集记录通过率作为基线。通过率不下降才允许上线。评估指标一般看五样分类准确率检索命中Top3率回复可接受率平均耗时每请求成本回复可接受率可以靠人工打分也可以用大模型代打。但我得提醒一句大模型评分不能全信它存在系统偏好比如倾向于说“看起来不错”这类套话。用来初筛可以最终还是要靠人工抽检。4.3 灰度发布与回归给AI应用装一个“安全阀”改完代码只是第一步上线才是真正考验。我的流程是新版本先在影子环境跑同一批流量比对新旧输出的差异再灰度10%生产流量观察人工转接率和投诉率确认指标平稳后全量。同时要监控三条曲线调用成功率、平均延迟、千次调用成本。转人工率一旦异常上升立刻回滚到旧版本。这条链路在工程上并不复杂难的是坚持执行。我见过太多项目上线前没做基线就全量出问题以后连对照都没有只能干瞪眼。5. 常见问题、性能优化与排查实录5.1 高频问题速查表这几类问题在AI工程化项目里出现频率极高我整理成了一张速查表。高频问题常见原因解决思路模型答非所问系统提示词任务边界模糊明确角色与“不做什么”增加Few-shot函数调用不生效参数schema结构不合理简化参数枚举写清楚给调用示例上下文超限日志和工具结果全堆进对话滑动窗口、摘要、检索裁剪知识库检索不到切块策略和embedding不匹配调整块大小增加重叠换embedding模型延迟高提示词太长、模型太大减token、换小模型、开并发缓冲成本失控重流程反复调用大模型加缓存、模型分层、降采样其中知识库检索不到这个问题最坑。我一开始把文档切成512字符一块结果很多问题跨块分布怎么检索都命中不了。后来切成256字符、重叠20%命中率明显改善。embedding模型也要试同一个文档在不同embedding模型下的表现差异很大。5.2 性能与成本优化先动三个地方性能优化我优先动三个地方。第一提示词瘦身。删掉每轮都重复的大段背景说明把固定背景放到系统上下文里把指令和用户输入压缩到最小。实测一个长提示词从3000 token减到800 token延迟能降差不多一半。第二模型分层。意图识别、实体抽取这类简单任务用小模型就够了复杂写作、长流程决策用大模型。混合使用之后成本大约可以下降一半而且体验没有明显下降。第三语义缓存。相同或高度相似的问题直接返回上次结果适合高频客服问答场景。但注意缓存要带业务状态校验比如订单状态变了旧缓存就不能再用了。5.3 排查思路没有trace数据寸步难行AI应用调试不像普通程序断点能看到的只是模型的输入和输出很难知道它为什么这么想。我的排查方法是三层定位。第一层是链路层。确认请求有没有到达模型、有没有报错检查限流和超时配置。第二层是上下文层。把发出去的messages完整打印出来逐条检查是不是上下文被污染了比如把上一单的订单号漏进了这一轮对话。第三层是结果层。固定温度为0复跑同一个case看输出是否稳定。我强烈建议从第一天就给每个请求分配一个trace_id把提示词、输出、token数、耗时全部关联起来。没有这套数据AI问题的排查会变成猜谜游戏。很多团队上线后遇到问题才发现日志里只有模型返回内容前面的上下文一个字都没有那基本没法定位。6. 从零开始的最后几条实用心得关于从零开始做AI工程化我最后分享三点真实体会。先跑通再优化。我最早做Agent的时候连续三天都在调框架最后发现自己连最基础的“模型调工具再回到模型”这个循环都没跑通。正确的顺序是先拿一个最简单的case打通全链路有反应了再谈质量。全流程没跑通之前所有优化都是空谈。用“最小可接受标准”定义成功。做AI应用时很容易追求满分答案但真正的关键是先定义清楚哪些场景必须做对、做错了有什么兜底。比如工单助手只要做到“不误伤正常用户、疑难单必须转人工”就算及格。这个标准比一味追求模型聪明程度要实用得多。别一开始就追新框架。框架迭代太快今天的热门架构可能三个月后就变了。把提示工程、上下文管理、函数调用、评估测试这四个基本功练扎实任何框架都只是工具而不是内核。我见过不少朋友陷入“换框架式学习”工具换了一轮又一轮手上的项目却没有一个真正稳住。如果你准备从零开始先别急着上复杂架构。找一个小而真的业务场景搭最小链路跑通一套评估然后让它在真实流量里接受检验。这条路虽然慢但每一步都在积累最后做出来的东西是能扛住线上压力的。