这几年“AI工程”这个词被炒得越来越热尤其是在GitHub上刷到“ai-engineering-from-scratch”这类项目时很多人的第一反应是这跟“Prompt Engineering”有什么区别跟“调API”又有什么区别我自己在把几个真实业务场景落地之后最大的感受是——AI工程不是某个单一技能而是从“能跑通”到“稳定跑、能维护、可评估、敢上线”的一整套方法体系。这篇文章不聊大模型内部原理也不做算法推演只讲怎么从零开始把AI功能做成工程化产品包含工具选型、流程设计、踩坑实录和一套可以直接抄走的实践模板希望能对正在从“会调接口”走向“能做工程”的朋友有些实际帮助。1. 内容整体设计与思路拆解1.1 为什么“从零开始”的关键不是模型而是系统很多人学AI工程时容易陷入一个误区花大量时间追最新的模型榜单、研究各种推理框架却忽略了一个基本事实——在一个真实项目里模型能力只占最终效果的一部分甚至不是最大的一部分。数据质量、任务拆解方式、提示词策略、输出校验、失败兜底、监控评估这些环节共同决定了用户实际感受到的“智能程度”。我见过好几个团队拿着开源大模型做了很惊艳的Demo但一上生产环境就崩有的因为输出格式不稳定导致下游解析报错有的因为用户在连续对话里“绕晕”了模型导致意图识别错乱还有的因为响应延迟高、成本估算错误被业务方直接否决。“从零开始”的真正含义是你愿意在模型之外花同等的精力去设计周边系统。这里可以用一个生活类比来理解模型像一个天资不错的厨师AI工程则是餐厅的后厨管理体系。厨师再厉害没有标准菜谱、没有食材质检、没有出菜顺序管理面对高峰期一样会翻车。AI工程做的事情就是把“厨师的手艺”变成“餐厅可复制、可扩张的出品能力”。从这套思路出发一个合格的AI工程团队至少要覆盖四个角色能力任务定义把模糊需求拆成机器可执行的任务、输入工程数据清洗、格式规范、示例组织、输出控制结构化生成、校验、纠错、效果评估离线测试 线上监控。不一定是四个人一个人如果能把这四件事都跑通就已经比很多只会“写提示词”的开发者强一个量级了。1.2 边界意识先确定“什么不该让AI做”我踩过最大的坑之一是早期恨不得把所有功能都塞给大模型处理。“既然模型什么都会那就让它直接输出结构化数据好了”——这个想法听起来很香实际上会让系统变得不可控、不可预测成本还高。真正成熟的AI工程思路是最小化模型承担的责任。能靠正则、规则、穷举、传统NLP解决的问题绝不调用大模型必须让模型做判断和生成的地方尽量把任务切小给足约束条件。比如一个客服工单分类系统如果类别总数不超过50个且关键词特征明显那一个简单的文本分类器或规则引擎可能是最优解只有当用户表达方式极其自由、类别边界模糊时才需要让大模型出场。这里需要明确一个“AI工程分层”的思维模型L0 层固定规则、字典匹配。成本趋近于零响应毫秒级L1 层传统机器学习分类/回归。适合有历史标注数据的场景L2 层单次大模型调用。适合自由度高的理解和生成任务L3 层大模型 工具调用 多步编排。适合需要推理、操作、检索的复杂任务。“从零开始”的意义就在这里不是从Llama、GPT这些模型本身开始而是从“判断哪一层方案最合适”的工程决策开始。很多时候最优解是用L0层过滤掉80%的简单请求只把剩下20%的复杂请求交给L2/L3层整体成本能下降一个数量级稳定性和响应速度反而大幅提升。2. 核心细节解析与实操要点2.1 提示词工程从“写作文”到“写接口契约”Prompt Engineering 是AI工程里最基础也最容易被误解的一环。很多人写提示词像在跟老朋友聊天各种口语化表达、无关的背景信息一大堆结果模型输出跟抽盲盒一样随机。真正工程化的提示词本质上是一份接口契约文档——它必须精确告诉模型你是什么角色、输入什么结构、输出什么格式、遵循什么约束、遇到什么情况怎么处理。我常用的提示词结构可以拆成六个部分系统设定System、任务说明Task、输入格式Input、输出格式Output、约束条件Constraints、示例Few-shot Examples。前四部分保证“能跑通”后两部分决定“跑得好”。拿一个在线教育平台的“题目自动批改”场景举例第一版提示词我写的是“帮我看看这道题学生答得对不对给出分数”结果输出千奇百怪有的写“很不错”有的给一段小作文式的点评纯靠人工二次处理。改造后的系统提示词变成了这样角色你是一名严格的中学数学教师。 任务对比标准答案和学生答案判断学生答案是否正确并给出评分。 输入题目内容、标准答案、学生答案均以JSON格式提供。 输出仅输出JSON对象包含三个字段 is_correct: boolean是否完全正确 score: number0-100整数 feedback: string不超过50字的点评用中文 约束 1. 学生答案包含正确计算过程但有轻微誊写错误时is_correct视为true但score酌情扣分。 2. 不得在JSON之外输出任何其他文字。 3. 无法判断时is_correct输出nullscore输出0。 示例...改动后的效果立竿见影解析失败率从15%降到接近0评分一致性大幅提高。核心原因是模型不需要“猜测”人类想要什么每条产出都有明确的格式约束和判断标准。在实际操作里还要养成一个习惯把提示词当代码管理——存进Git仓库、写版本记录、做A/B测试不要直接在网页版对话框里反复试。因为“能跑”不等于“能上线”提示词在离线测试里表现好不代表在线上真实流量里同样好必须有一份可演化、可追溯的版本。2.2 结构化输出的工程化设计JSON不是万能的现在的大模型直接输出JSON已经比较可靠了尤其是一些支持Json Mode或Function Calling的新版模型。但如果你做过生产级系统就明白最大的坑不是“模型偶尔输出非JSON”而是“模型输出的JSON结构对但字段内容不符合业务预期”。我见过太多团队在解析层写死“data.result.answer”结果模型某天在result后面多加了一层嵌套或者把answer字段输出成了null代码直接炸掉。防御性解析是结构化输出工程里必须补的一课不要假设模型会完美遵守契约要在解析层做类型检查、范围检查、缺字段兜底。一个更隐蔽的问题是JSON Schema 约束本身可能限制模型的长文本生成能力。某些开源模型在强制JSON模式下回答质量会明显下降出现“为了满足结构、牺牲内容合理性”的情况比如数学推理题在JSON输出模式下频繁算错。如果是这类任务比较实用的折中方案是让模型先输出一段自由文本的推理过程然后再通过第二次调用把这段文本转成结构化JSON或者使用正则从自由文本中抽取关键字段。有一种生成策略值得在工程里推广先草稿、后格式化Draft then Format。和人类写报告一样先不考虑格式把思考和答案写出来再花精力排版。两个分开的调用虽然多花了点Token和时间但在复杂任务上内容的准确性和结构的稳定性反而都提升了这部分额外成本通常值得。另外要特别留意输出长度的控制。有些模型在“越详细越好”的暗示下能生成几千字的废话对于大多数业务场景响应时间和Token成本都不允许这种浪费。与其在提示词里反复说“请简洁”不如在解码参数上直接设置Max Tokens上限物理层面限制输出长度效果明显更可靠。2.3 上下文管理对话历史不是越长越好做聊天机器人、客服助手这类多轮交互系统时上下文管理是最容易失控的地方。多数人的直觉是“把全部对话历史都传给模型这样它最了解上下文”但实际测试下来这会带来三个问题成本线性上涨、响应延迟明显增加、模型注意力被无关历史干扰导致关键信息反而被忽略。有效上下文管理是AI工程里相对独立的技术活核心思路叫“上下文窗口的预算分配”。整段对话就像一次采购预算有限Token上限你得决定买什么、不买什么。我会把上下文划分成三类核心上下文当前问题计算的必要信息占预算的大头参考上下文可检索的领域知识、历史结论按需动态注入压缩上下文很久以前的对话内容用摘要替代原文。实践中长对话通常采用“滑动窗口 摘要”的方式设定一个窗口比如最近10轮对话完整保留超过窗口的部分每隔一定轮次用模型生成一段摘要把摘要放到上下文的最前面。这样既保留了关键历史信息的连贯性又避免了阻塞窗口。另外实体和状态信息尽量从对话中抽取出来存成结构化字段而不是指望模型每次从原始文本里重新理解一遍。比如客服系统里用户的会员等级、订单编号、问题类型一旦识别到了就入库后续轮次直接读库注入不再依赖模型记忆。这里要特别注意“记忆幻觉”问题有些模型会把当前对话里被用户纠正过的信息搞混如果你明确告诉它“用户说他不买手机了”它可能下一轮又沿用旧信息推荐手机壳。工程上的解法是对关键实体做独立维护在生成时通过模板强约束尽量不让模型自行决定该用哪个版本的信息。3. 实操过程与核心环节实现3.1 从“能跑的脚本”到“可维护的AI服务”有了前面的基础下面我用一个实际的“AI文章审核辅助系统”来完整演示怎么从零开始搭一个AI服务。这个场景很典型业务方每周有几百篇用户投稿需要审核以前全靠人工阅读判断现在想用AI做第一轮筛查。纯调用大模型当然是最快的办法但工程化就要想更多调用失败怎么办输出怎么解析误判率怎么量化后续优化从哪里下手为了应对这些问题整体架构分成三层路由层负责判断哪些内容需要走AI审核执行层负责模型调用和结构化输出校验层负责规则复核和人工抽检。路由层的实现不复杂核心是一个规则引擎加一个轻量分类器。先通过正则把包含明显违禁词的投稿直接判为“待人工复核”再把没有明显问题的内容交给大模型做语义级判断。为什么不全部交给模型因为线路层只有几十毫秒的延迟且费用极低几十倍成本差距在先做一遍过滤是绝对划算的。执行层是整个系统的核心需要把提示词、模型参数、运行日志串联起来。代码框架大致是这样import json from dataclasses import dataclass from typing import Optional import openai # 仅示意实际可替换任意SDK dataclass class AuditResult: risk_level: str # low / medium / high risk_types: list # [广告, 暴力, 色情, ...] confidence: float # 0-1 reason: str # 审核依据摘要 needs_human: bool # 是否需要人工复核 SYSTEM_PROMPT 你是一名内容安全审核专家... 只输出JSON{risk_level: ..., risk_types: [...], confidence: 0.0, reason: ...} 规则细节... def audit_content(text: str, client) - Optional[AuditResult]: try: resp client.chat.completions.create( modelgpt-4o-mini, # 实际按成本/效果选型 messages[ {role: system, content: SYSTEM_PROMPT}, {role: user, content: f请审核以下内容\n{text[:2000]}} ], temperature0.1, max_tokens500, response_format{type: json_object} ) data json.loads(resp.choices[0].message.content) # 校验层强制字段存在性检查 risk data.get(risk_level) if risk not in {low, medium, high}: raise ValueError(fUnexpected risk_level: {risk}) return AuditResult( risk_levelrisk, risk_typesdata.get(risk_types, []), confidencefloat(data.get(confidence, 0.0)), reasondata.get(reason, ), needs_human(risk high or float(data.get(confidence, 0.0)) 0.6) ) except Exception as e: # 失败兜底绝不能直接抛错降级到人工审核 return AuditResult( risk_levelhigh, risk_types[unknown], confidence0.0, reasonfmodel_error: {e}, needs_humanTrue )这段代码里最核心的设计不是“调用了模型”而是三处工程化细节异常降级策略保证模型挂了不会影响主流程、字段校验防止模型乱输出、needs_human 判断逻辑把低置信度结果强制转到人工。这些都是线上运行必不可少的一环实际做的时候千万别图省事删掉。3.2 费用与性能的平衡模型选型和参数调优实验任何AI工程项目在落地前必须做一次模型选型对比实验用数据说话而不是拍脑袋选个最强的。我通常选三类候选模型做对比顶尖旗舰模型如GPT-4o级别、中端均衡模型如GPT-4o mini、Claude Haiku级别、开源可私有化模型如Qwen系列中等尺寸版本。测评维度包括准确率、格式遵循率、平均延迟、单次成本。我当时测出来的一组典型数据可以给大家参考模型准确率格式遵循率平均延迟秒单次成本相对值旗舰级95.2%99.8%2.81.0中端级92.7%99.5%1.20.02开源7B85.4%96.1%0.9GPU0.003准确率只差2.5个百分点成本却是50倍的差距这就意味着中端模型通常是绝大多数业务的甜点。旗舰模型只该被用在最难的5%样本上比如语义极模糊、低置信度需要二次判断的内容。实际部署时还需要做“动态路由”先用中端模型低成本处理如果它对结果置信度不高再升级到旗舰模型。我在实验中发现这样优化后整体成本能再降50%以上而最终准确率几乎不受影响。整个方案的本质是把成本花在刀刃上而不是让每个请求都享受顶配待遇。温度参数方面也值得多说一句。工程系统里的生成任务比如分类、审核、抽取跟创意写作不一样需要的是稳定和一致温度建议设在0到0.3之间凡是看到有人用高温度跑这类任务的基本都没想清楚系统要的是稳定性。另外把Top-P从1降到0.8左右也能在不伤准确率的前提下减少一些无序输出这是我在评测里发现的稳定有效的组合。3.3 效果评估体系没有评测就没有优化很多团队做AI工程时最缺的其实不是写代码的能力而是评测意识。没有一套可量化的评估体系你根本不知道改动提示词是变好了还是变坏了也不知道线上出现的问题是模型退化还是数据出了问题。评估体系至少需要三层。第一层是离线测试集在项目启动时就要开始积累比如审核系统里准备几百条已标注的“好内容/坏内容”每次改提示词、换模型、调参数都跑一遍回归。第二层是线上A/B测试把新策略跑在10%的流量上对比旧策略的准确率、误判率、人工介入率。第三层是实时监控记录每天的调用量、延迟、Token消耗、异常率、人工复合率设置告警阈值。离线测试要特别小心“测试集泄漏”问题。用真实线上数据构造测试集时要确保和模型训练数据的时间段错开不然过了几个月模型参数更新后效果评估虚高的现象会骗过所有人。我一般会保留最近一个月的线上数据做“盲测”前一个月的做“调试”滚动更新来避免评估失效。在人工评估维度上还需要引入“混淆矩阵思维”。单纯看准确率会掩盖很多问题比如内容审核系统里把“低风险内容标成高风险”和“高风险内容漏成低风险”的代价完全不同。前者只是浪费人工复核时间后者可能引发内容安全事故。因此工程上要给不同类型的错误设置不同权重把评估指标从准确率改成“加权风险分”这个数字才能真实反映线上风险水平。4. 常见问题与排查技巧实录4.1 模型“突然变蠢”怎么排查线上AI服务最莫名其妙的问题就是昨天还好好的今天输出突然变差了。很多人第一反应就是“模型被官方偷偷换了”说实话这种可能确实存在但大部分时候其实另有原因。我建议按这个顺序排查先看输入数据漂移再查上下文污染最后才怀疑模型本身。输入漂移的例子很常见业务方某天改了投稿格式上传的内容里混入了大量HTML标签或Markdown符号模型被这些噪声干扰导致判断不准。排查方法也简单把最近输出异常样本的原始输入调出来人眼扫一遍通常很快就能发现规律。上下文污染在高频出现且隐蔽的问题中排前两名。如果你的用户会话里有历史消息排查时一定要看Prompt实际拼出来是什么样有时某个历史轮次里带着HTML标签有时用户往上下文里塞了很长的无关文本直接把后续生成带偏。我的习惯是给线上每次请求都打印一份“完整提示词日志”这在排查时价值极高虽然存储成本高一点但关键时刻能省几小时排查时间。排除掉上面两个因素后才考虑模型服务商端的更新问题。可以做一个标准化基准测试集每天定时跑一遍如果连续几天效果分数持续下降且我们自己没改过任何东西那才是真·模型退化。4.2 成本失控的幕后黑手AI工程上线后最大的一张账单往往不是来自模型本身而是来自“重复计算”。最常见的情况是缓冲区没做好同一段文本在多个请求里被反复编码成Token另一个是重试逻辑太粗暴模型超时就立刻整单重跑一次任务烧掉好几次的钱。在排查成本问题时我会先查单请求Token分布。比如在日志里看Max Tokens设置了多大的输出限制有些模型即使你只需要它输出“是/否”它还是会老老实实生成几百字这就在白白烧钱。建议把所有生成任务的Max Tokens压到业务所需上限的1.2倍左右本质是一个保险系数但不给模型留下挥霍空间。另一个隐蔽的成本项是“上下文缓存未命中”。现在多个主流服务商都支持Prompt缓存功能如果请求间有共同的前缀部分会被缓存复用费用大降。但缓存命中率取决于Prompt前缀的稳定程度。有些人习惯把当前时间、随机ID拼进系统提示词导致每次前缀都不同缓存全部失效。把动态内容移到消息末尾是让缓存生效最简单的技巧之一改动很小但成本优化立竿见影。4.3 多步骤任务的状态与重试设计当AI工程从“单次调用”进化到“Agent多步编排”后最折磨人的问题往往集中在上一步输错、下一步就跟着错。比如一个“AI写稿助手”工作流里模型先生成大纲再根据大纲生成全文如果大纲阶段就偏离了主题后面全文越写越离谱而且几乎无法通过调优提示词解决。工程化解法是引入“中间产物校验门”。每步执行完、进入下一步前加一道检查逻辑。这个检查分两种轻量规则检查负责格式、字段、关键词等的验证语义检查本质是再调用一次模型来审视上一步的产出质量。虽然增加了一些调用次数和延迟但放在任务成功率和高价值场景里这笔账通常是划算的。在更高的技术上这种做法叫“Plan-Execute-Review”模式核心思想就是让每一步都有明确的成功标准。要对每一步设定判定规则建议提前和业务方对齐“请给明确的标准而不要你对我说尽量做好”掌门人会给模糊标准则模糊结果带标准规则才能收获可靠流程。失败重试设计上也值得有章法。不要做普通的“失败就整段重跑”那样既浪费又可能重蹈覆辙。更合理的做法是分步重试哪一步失败就只重跑哪一步并允许把失败原因反馈给模型让它调整策略再试一次。连续两次不成功就标记给人工或降级方案。5. 工具链选型与工程化基础设施5.1 核心工具矩阵LLM框架、可观测性与评测平台聊完实操环节补充一下工具链选型的思路这是“从零开始”的路线上绕不开的决策点。当前AI工程圈常用的技术栈大致可以分成四层编排层、调用层、可观测层、评测层。我的个人选型建议如下层级推荐工具适用场景备注编排层LangGraph / Ray有状态多轮Agent复杂流程LangGraph对有向图流程表达更直观调用层LiteLLM / OpenAI SDK多供应商统一接口LiteLLM适合同时接多种模型做切换可观测层Langfuse / HeliconePrompt版本记录、Token消耗、延迟追踪Langfuse可把评测结果也收进系统评测层Ragas / DeepEval / Promptfoo离线回归、效果对比、Prompt集成测试Promptfoo在提示词回归测试上极好用向量检索Qdrant / Milvus / pgvector知识库RAG场景数据量小于百万级pgvector够用很多人在这些工具里挑花眼。我的建议是按“被需要时才引入”的原则来选择刚开始只在调用层加一个LiteLLM避免绑定单一厂商等到项目有了第二、第三个功能后再考虑编排框架可观测层建议从第一天就接哪怕只是简单打个日志因为早期数据才是后续优化评估的起点。5.2 RAG类应用的工程细节与避坑大模型RAG是现在AI工程里实用性极高的一类应用但也是表面上简单、暗坑最多的一类。第一代做RAG的团队通常都会遇到“检索到了但回答没用”的情况原因往往是分块策略没做好。最常见的错误是把一个合同文本按固定字符长度截成几块导致一个完整法律条款被拦腰切断模型在生成时哪一块碎片都看不全。我做知识库问答时分块前会先做结构解析PDF按章节标题切、Markdown按Heading切、法律文本按条/款/项切、对话记录按轮次切。每个分块还带上一层“父文档块”的上下文信息检索命中到子块同时把父块内容一起注入Prompt。这样既保证了片段足够聚焦又不丢失大语境信息效果提升非常明显。检索环节还存在一个嵌入模型很关键但常被忽略的事实Embedding模型的长度限制和相似度分布都是需要专门做适配的。通用中文文本适合用开源BGE系列时先做一波相似度统计搞清楚命中分数段的分布再定“取几个块、相似度阈值多高”对整体回答质量有决定性影响。5.3 从单机脚本到服务化部署的完整链路最后把服务化部署这条链路串一遍。一个标准的AI工程服务化流程至少包含以下环节Prompt模板版管理存在Git库发版走普通代码评审流程顺便做版本标注模型配置集中管理包括模型名、温度、Max Token、重试次数、超时等等都集中到同一个配置文件或配置中心请求入口加一层签名认证与限流控制防止刷量攻击AI服务比普通接口的调用成本高得多限流是刚性需求反正接的结果异步化尽量做实像审核这类的场景用户不需要秒级返回直接把请求丢进队列模型处理完回调结果即可写一个独立的健康检查接口对模型供应商做探活返回服务状态供负载均衡使用。实际业务中被问到最多的是怎么评估性能。这里带一个基本计算假设单次模型调用耗时2秒一台单机并发数16那每分钟最多处理480个请求如果每天有10万篇内容需要审核就需要至少3台机器同时还要考虑重试和调用的高峰冗余。这种“用吞吐量倒推开机器数量”的计算方法避免了拍脑袋扩容和预算失真。6. 从工程实践到个人成长路线图6.1 从“会用”到“会设计”的能力进阶做了这么多项目有个感受越来越深AI工程不是一个静态的技术栈而是一套持续演进的思维方式。入门时你可能专注于写提示词和调模型这是正常的做了几个真实项目后注意力会自然转向数据流设计、评估体系、成本控制、故障恢复这些更底层的议题。从我个人经验看比较顺滑的成长路径倒是不复杂先完成一个最小闭环项目把它完整跑通上线然后回顾这个项目里哪些环节最不稳定、成本最高、效果最差分别针对性地去做优化优化过程中自然会接触更多工具和方法论慢慢就把整条技术栈拉通了。这个过程中最重要的一条心态是“不要神话AI能力”模型只会越做越强而工程体系的竞争力永远是数据、评估和业务理解。每条工作流里最容易被新人忽略的往往是对输出的珍视程度无论你是用提示词让模型生成内容还是让Agent执行一系列动作都要假设每次输出的结果会用于正式场合于是你会自然愿意在结构化、校验、兜底上花功夫。这是把“玩AI”变成“做AI”的分水岭。6.2 后续可以继续扩展的方向如果在当前思路上还想往深里走下面这几个方向都特别适合作为下一阶段的实验课题多Agent协作不同角色模型分别承担“分析、执行、审查”用策略把它们串成闭环特别考验状态交互设计能力小模型微调在特定业务场景里把“调用大模型”变成“本地小模型”成本可能降到原来的十分之一以下推理延迟也会更理想反馈飞轮设计在线上让用户对AI输出打分或点踩把数据回流到评测和提示词优化里形成持续改进多模态工程把图像、音频、视频等非结构化输入纳入原有流程场景比纯文本多不少后续想象空间也大。这些方向每次都能单独写出好几篇实战记录但根基永远是前面聊到的那套方法论边界判断、任务拆解、结构化输出、评测闭环、降级恢复。把这些基本功打扎实后续往上怎么长都不会跑偏。我自己刚接触AI工程时也觉得这领域变化太快、工具太多学不过来。真正做了几个项目之后才明白底层那套“系统化解决问题”的框架跟做传统软件工程没有什么本质区别——都是想清楚边界、设计清楚流程、盯紧数据和结果不断迭代。AI能力只是为你提供了一个新的、更强大的功能模块工程思维仍然是那根顶梁柱。