“ai-engineering-from-scratch”这个项目翻译成人话就是不依赖任何现成的AI套件从模型接入、提示词设计、服务封装、质量评估到成本控制自己动手搭一条完整的AI应用生产线。我给自己定的目标很简单在真实业务里跑通一个由大模型驱动的功能而不是只在笔记本上跑通一个demo。这篇文章记录的就是这条线路上最关键的决策、最常踩的坑以及我最后沉淀下来的一套可复用的操作流程。很多人会把AI工程理解成“调一调提示词、把模型API接进来就完事”但真正到了生产环境里你会发现差异全藏在细节里模型返回了非法JSON怎么办用户输入超长怎么截断接口超时是重试还是降级同一个问题换一种问法结果就漂了又该怎么兜底这些才是“工程”二字的真正含义。下面我就按照从拆解需求到上线优化的顺序完整走一遍这个项目。1. 先把“AI工程”四个字拆明白1.1 这不是调参是搭生产线AI工程和算法研究最大的区别在于目标不同。算法研究追求的是模型效果的边界而AI工程追求的是“在有限成本、有限时间、有限可靠性要求下让模型稳定产出可用结果”。所以你会发现一个合格的AI工程实践核心动作往往不是写更聪明的提示词而是设计一套机制让模型即使偶发犯错整体系统依然能交付结果。我在拆解这个项目的时候把整个链路拆成了五层输入层负责清洗和校验用户数据上下文层负责决定哪些内容该进提示词模型层负责实际推理解析层负责把模型的自由文本变成结构化数据兜底层负责处理一切异常。每一层都有独立的判断标准层与层之间通过明确的接口对接。这种分层方式带来的直接好处是出问题时你能第一时间定位是哪一层坏了而不是对着整段代码发愁。1.2 为什么“从零开始”反而更有价值我见过太多团队“接入”大模型很快但“用好”大模型很慢。原因在于现成的SDK帮你省掉了接入的体力活却没法替你做判断这个场景适不适合用大模型用哪种模型温度参数怎么设输出结构怎么保证上下文塞多长才划算这些判断力只能靠完整的项目实践练出来。从零开始搭这个项目逼着我走完了每一个环节。没有现成的封装库我就得自己处理流式输出没有现成的评估脚本我就得自己标注测试样本没有现成的监控看板我就得自己记录Token消耗。这个过程很琐碎但恰恰是这些琐碎的地方藏着AI工程真正的门道。等这些基础能力都过了一遍之后再去看市面上各种框架你会一眼看穿它帮你做了什么、没帮你做什么。1.3 这条路线适合谁如果你是想在真实项目里落地AI功能的工程师这篇文章的路线和踩坑记录值得从头看一遍如果你是刚入门、想从“会调用接口”进阶到“会设计AI系统”的同学可以把第三部分的实操代码当作一个起步模板如果你是团队里负责技术选型的人第二部分关于接入方式和模型部署的对比可以直接拿来当参考。我不建议完全照搬我的技术栈但建议你保留我那份“拆解需求→定义验收标准→选型→写提示词→搭服务→评估→优化”的顺序。这套顺序本身比任何具体工具都重要。2. 工具链选型与核心概念解剖2.1 大模型接入的三种姿势动手写代码之前先要决定模型怎么接进来。我把常见的接入方式分成三种实际项目里可以根据阶段灵活切换接入方式优点缺点适合场景直接调用商用API接入快按量付费运维成本低数据出外网单次调用成本随用量线性增长快速验证、原型开发、中小规模业务本地部署开源模型数据不出内网可控性强长期成本可摊薄需要GPU资源维护复杂模型效果通常弱于顶级商用模型数据合规严、调用量大的场景自建API转发层统一内部接口换模型只改配置可以聚合多路模型做容灾需要额外开发转发本身有少量延迟中大型团队、多模型并行、稳定性要求高的业务我的建议是项目初期直接调用商用API把精力花在业务逻辑上。等业务量起来、需要对比多家模型或者做容灾切换时再补一个转发层。过早抽象反而会增加工作量。我见过有人第一步就搭了一个庞大的模型网关结果后面三个月都在维护网关本身业务功能一点没推进。2.2 提示词工程的三个层次提示词工程不是背模板而是控制模型的输出分布。我习惯分三层来写第一层是角色与任务层告诉模型“你是谁、目标是什么”。这一层决定了模型整体的行为基调。第二层是约束与格式层给出输出结构、长度、语言、风格要求。这一层是工程化最依赖的部分因为只有约束明确下游解析代码才好写。第三层是示例与边界层给出一两个正面样例再说明什么情况下不要怎么做。举个例子我在做“会议纪要素材整理”功能时第一版提示词只写了“把下面这段会议录音转成要点”结果输出经常自带“以上就是本次会议的全部内容”之类的废话。改成“你是一名会议记录助理。请从以下转录文本中提取决定、待办事项、责任人三类信息。输出为Markdown列表不输出任何寒暄”之后输出质量立刻上了一个台阶。关键区别在于把“输出行为”限定死了而不是让模型自由发挥。2.3 Agent不是玄学是任务分解协议搜索引擎里“AI Agent”的热度一直很高不少人把它当成某种神秘能力。我的理解非常简单Agent就是“模型工具循环”的组合。模型负责推理工具负责执行动作循环负责检查结果并决定下一步。让它可靠运转的核心是一份清晰的任务分解协议。协议里要写清楚什么情况下调用哪个工具工具返回什么结果算成功失败之后回退到哪一步。很多Agent翻车的根因不在模型不够聪明而是协议定义得不清晰。比如“帮我查一下订单状态”这句话模型理解了语义但不知道该调“订单查询”接口还是“物流查询”接口。把协议细化到这种程度比单纯换一个更大的模型管用得多。2.4 模型部署的基本形态模型部署听起来偏后端但其实牵扯到整个系统的交互设计。我梳理出三种基本形态在线推理请求一来立刻处理适合实时对话、实时内容分析。批处理定时喂一批数据进去统一产出结果写回存储适合离线报告、批量审核。流式输出服务器边生成边推送前端像打字一样逐字显示能显著降低用户等待感。我在第一版里只做了在线推理加流式输出把主流程跑通批处理等业务量上来之后再补。部署形态不必一步到位但要在架构上留出扩展空间比如把“模型调用”封装成独立模块后续加批处理时不用动业务代码。3. 实操从一条指令到一个可用功能3.1 先定义验收标准再写代码工程化的第一步不是写代码而是把“效果不错”变成可检查的指标。我这个项目做的功能是内容分类与标签生成用户给一段文本系统输出它的分类和3到5个标签。验收标准我一开始就定了三条分类准确率达到90%以上拿50条人工标注样本做测试标签必须来自预设词表不允许发明新标签单次请求的端到端耗时不超过3秒。这三条标准看起来简单但它决定了后面所有技术选型要控制耗时就用流式输出和轻量模型要限定标签就在提示词里给出完整词表并让模型只输出一个JSON对象。没有验收标准的最大风险是“感觉还行”式交付。你觉得模型输出挺像样业务方也觉得挺像样但一旦接到真实流量各种边缘情况全冒出来这时候再回头补标准成本就高了。3.2 提示词版本的迭代过程提示词不是一次写好的我经历了四个版本。V1只有一句话“给下面的文本分类并打标签”。输出格式随意经常把标签写成完整句子。V2增加了输出结构约束“输出JSON包含category和tags两个字段”。这下能解析了但分类标准混乱“科技新闻”和“数码评测”经常混在一起。V3给出了分类定义和词表分类只能从预设列表里选标签必须是词表中的词语不能自创。准确率明显上升。V4又增加了一个少样本示例给出一个输入和期望输出的对照。这一次不仅准确率上去了连格式都完全可控。整个过程中我坚持一条原则一次只改一个变量改完立刻拿同一套测试集跑对比。别同时改温度参数和提示词不然出了问题根本不知道是谁的锅。3.3 服务端代码结构与流式输出我用的是Python FastAPI加一个简单的内存缓存代码结构大致是这样from fastapi import FastAPI from pydantic import BaseModel app FastAPI() class Item(BaseModel): text: str app.post(/classify) async def classify(item: Item): # 1. 参数校验 if len(item.text) 2000: return {error: text too long} # 2. 提示词拼装 prompt build_prompt(item.text) # 3. 模型调用走流式 result await call_model(prompt) # 4. 输出解析与校验 parsed parse_output(result) # 5. 兜底返回 return parsed分层很清楚校验、拼装、调用、解析、兜底各管一件事。实际开发时我建议把build_prompt和parse_output单独拆文件维护因为它们会频繁迭代独立出来后方便做版本管理。流式输出值得单独说一下。大模型接口普遍支持流式返回服务端拿到首块内容就可以推给前端用户感知到的首字延迟会明显下降。但这里有个容易忽略的细节流式传输时HTTP应答头要设置Transfer-Encoding: chunked前端也要用onmessage方式逐块渲染。我第一次实现时没在意这个结果前端要等全部输出完才显示体验跟非流式一模一样等于白做。3.4 质量评估与回归用例在AI工程里评估体系就是“测试用例”。我维护了一份固定的测试样本集大约50条真实文本每次改提示词、换模型之后都会把整份样本集跑一遍记录分类准确率和输出可解析率。另外我还加了一个自动断言输出必须能被json.loads解析category必须命中预设分类标签数量必须在3到5之间。凡是跑不过断言的就人工检查是模型能力问题还是提示词引导问题。这套回归体系在后面一次模型版本升级时帮了大忙。新模型看上去更强但跑完测试集发现它在少数边缘样本上的分类结果和旧模型不一致而且从业务角度看是退步的。要是没有这套评估我可能就直接上线了。4. 常见问题、排查技巧与成本优化4.1 模型输出总是“飘”怎么办输出“飘”是指同样类型的输入结果时好时坏没有规律。我的排查顺序是固定的降低温度参数一般从0.7降到0.2左右检查提示词里是否有歧义把分类定义写得更细增加少样本示例让模型照猫画虎如果还不行换一个更强的模型跑一遍对比判断是引导问题还是模型能力问题。这里最容易被忽视的是温度参数。很多人把它当成摆设其实它控制的是回答的随机性。对结构化输出任务0.1到0.3是合理区间对创意型任务才需要0.7以上。我见过有人在做分类任务时把温度设为1.0结果同样的输入每次返回的标签都不同还以为是模型出 bug 了。4.2 Token用量失控Token用量是AI应用成本的大头我踩过最经典的坑把整本产品手册塞进提示词里当背景知识结果每次请求都在烧钱。后来改成先做关键词检索、按需拼装上下文的方案Token用量直接砍掉七成。控制Token我做了三件事第一给系统提示词设定长度上限超过就抛异常防止拼接逻辑把无用的长文本带进来第二给返回内容设置max_tokens防止模型啰嗦同时在业务层丢弃超长输出第三在业务侧做上下文裁剪只保留对当前任务有用的片段而不是能给的都给。这里有一个容易忽略的权衡点Token用量和模型质量往往成正比上下文越全回答越准。所以裁剪时要先做小范围实验确认质量不掉太多再上线别为了省钱把模型效果砍没了。4.3 并发瓶颈和缓存策略服务上线之后难免被并发请求打满。我的方案分三层缓存层相同输入在前几分钟内直接命中内存缓存减少重复计费。限流层给每个调用方设置每分钟请求上限防止单个用户把配额吃光。降级层主模型超时后自动切换到备用模型同时返回一个质量稍低但依然可用的结果。这套策略里最容易遗漏的是“降级层”。接口不可能永远不出问题出问题时宁可返回一个可靠的低质量结果也不要让整个页面挂掉。我处理过一次线上事故主模型服务端抖动所有请求都在排队页面全部白屏。加了降级逻辑之后同样的场景顶多是回答质量差一点但功能始终可用。4.4 可观测性日志、评估、追踪AI应用的可观测性比传统应用多一层不只记录请求和响应还要记录提示词版本和模型版本。我习惯在每条请求日志里带上prompt_version和model_name两个字段线上出问题时可以快速定位是提示词改坏了还是模型换坏了。请求耗时和Token消耗我也会按天统计按模型维度看当天的调用次数、平均延迟、总Token数和花费。这张统计表就是成本监控的底表。某天费用突然翻倍我先看哪个模型消耗变大再看是哪个功能调过来的基本五分钟内就能定位问题。4.5 实战问题排查速查表症状优先排查项常用解法输出格式错误提示词约束不够增加“只输出JSON”等限制补少样本示例分类结果不稳定分类定义有歧义细化分类说明降低温度参数费用突然飙升上下文过长或调用量异常裁剪上下文加缓存设max_tokens上限接口长时间没响应模型响应量太大或网络抖动启用流式输出限制返回长度切备用模型请求被拒绝参数校验不严前置校验输入长度统一异常返回结构这张表是我平时处理问题的起点。每遇到一个新问题就往里补一行现在已经攒了几十条。排查时先看表能解决大半问题解决不了再深入看日志。5. 接下来还可以往哪边走5.1 多Agent协作的工作流实验单Agent做到一定程度后我尝试了多Agent协作。一个典型的实验是把内容生产拆成两个角色写手Agent负责生成初稿审校Agent负责按标准检查并返工。效果不错但代价是Token消耗翻倍响应时间也变长了。我的建议是先用单Agent解决问题确实出现单模型无法兼顾的质量瓶颈时再拆多个Agent。别为了赶潮流而拆。多Agent的真正价值在于隔离不同任务的质量标准而不是字面上的“多个模型一起干活”。5.2 RAG接入后的数据飞轮把项目从demo变成真正好用的工具最值得加的是RAG检索增强生成先准备知识库用户提问时检索相关片段再把片段拼进提示词让模型基于事实回答。这样一来模型不需要记下所有知识也能给出有依据的回答。做了RAG之后我发现一个隐含的正反馈用户每次提问和纠错都可以沉淀为新的知识片段。知识库越用越准回答质量也随之上升。这就是所谓的数据飞轮它比单纯调提示词的杠杆大得多。如果你做的功能是问答、客服、文档分析这一类我建议尽早把RAG纳入规划。5.3 走向生产环境的最后三件事最后说三件容易被忽略但很关键的事安全边界用户输入里可能夹带恶意指令服务端必须有独立的过滤和长度限制不能盲目信任模型输出。该拦截的拦截该脱敏的脱敏。灰度发布新提示词不要一次性全量上线先放5%流量观察指标没问题再逐步放大。提示词改动看起来小实际影响范围可能很大。成本告警设定每日费用阈值超过阈值自动停掉重模型调用或者发告警通知避免睡一觉起来账单爆炸。这三件事花不了多少时间却能在关键时刻拦住绝大多数生产事故。上线前多问自己几个“如果”比事后补锅划算得多。我自己的体会是从零开始搭AI工程真正的难点不是某一个具体技术点而是把“模型能力”和“工程约束”对齐的过程。模型的输出天生带有概率性工程系统恰恰最排斥不确定性两者之间的磨合就是AI工程师的核心价值所在。每踩一个坑你对这层对齐关系就多一分理解。这个项目做完之后我养成了一个习惯任何AI功能上线前先问自己三句话——如果不返回结果怎么办如果返回错结果怎么办如果调用失败怎么办把这三个问题回答清楚了这个功能的可靠性基本就有保障了。这套思路也分享给你希望你的AI工程之路能比我少踩几个坑。