很多人第一次接触“AI工程”这个词是在调完Prompt、看着模型输出了一段漂亮回答之后。那一刻确实很有成就感但等真正要把这个能力放进业务流程里问题就接踵而至换一个模型版本同样的提示词输出就飘了问题稍微绕一点模型就答非所问更别提并发、成本、日志、评估这些完全没有着落的事。我自己在从零搭建AI应用的过程中把该踩的坑基本都踩了一遍所以想把这套从“写提示词”到“做系统”的方法论完整整理出来。这篇文章里所有内容都围绕AI工程化落地展开会覆盖架构选型、数据准备、提示词设计、效果评估和问题排查适合那些已经会调用API、但还没完全弄清楚“工程化”这三个字意味着什么的开发者。AI工程真正的分水岭不在于你能不能调通一个接口而在于你有没有一套方法去约束、度量、维护这个系统。我接下来会从最核心的思路讲起逐步拆解到代码层面的实现细节。1. 从“写提示词”到“做系统”先搞清楚AI工程到底在解决什么问题1.1 为什么说提示词工程只是冰山一角我见过太多的团队把AI应用的成败押在提示词上。提示词当然重要但如果你把提示词当作工程的全部很快会撞上一堵墙提示词是不可测试的是不可版本化的也是不可复现的。所谓“不可测试”指的是同样的提示词今天跑和明天跑结果可能完全不同。模型有采样温度有随机性有版本更新这些变量叠加在一起你根本无法断言“这个提示词是好的”。所谓“不可版本化”是指你改了一个字可能需要回归验证所有历史case而这个工作靠人肉根本做不完。所谓“不可复现”就是线上出了一个问题你把当时的输入原封不动再跑一遍可能就复现不出来了。AI工程的第一步就是承认这个现实提示词只是系统的一小部分。你需要在其外围搭建一整套基础设施包括数据管道、检索链路、缓存策略、评估闭环和监控告警。只有把这些东西都立起来提示词才谈得上被“管理”而不是被“依赖”。1.2 边界思维把AI能力锁进“接口”里我这两年做AI工程最大的体会可以用一个词概括边界。AI模型是一个极其强大的“黑盒子”但它也是一个极其不稳定的“黑盒子”。工程化的本质就是给这个黑盒子画出一条边界让不稳定性被关在笼子里让系统的主体保持可控。打个比方你雇了一位能力很强但不按常理出牌的顾问。你不会让他直接去跟客户对接而是会给他一份标准化的brief把他的产出放在一个固定模板里再由你来做终审。AI工程里检索层、路由层、提示词模板、输出校验器干的就是这个活。这也就是为什么有人会用“Harness Engineering”这个词来描述AI应用开发。Harness本意是“挽具”或“线束”工程上可以理解为“把一股股凌乱的线整理固定起来”。AI应用开发也是这样模型的能力是一条条看似无序的线工程要做的是把它们整理成有明确接口、可插拔、可监控的管道。没有这层整理AI应用永远只是一个实验品而不是一个产品。1.3 工程化的最终检验标准什么才叫“工程化”完成了我有一个简单的检验标准当模型换了一个版本当服务流量翻了三倍当某个检索组件挂了你的系统是否依然可用、可查、可恢复如果答案是“不确定”那说明工程化还没有完成。反过来说工程化的目标不是让模型永远不出错——模型一定会出错——而是让系统在你的掌控之内出错。你需要知道它为什么错、错在什么场景、影响面有多大、如何快速降级。这些能力全部需要在模型之外构建。所以这篇文章的叙事逻辑也很清晰先搭底座再做数据再写提示词最后建评估。这个顺序是我在实践中调试过很多次的按照这个顺序走你会在第一个星期就感受到“工程化”和“调接口”之间的区别。2. 从零搭建AI应用的工程底座模型选型与整体架构2.1 模型层的选择不是越强越好模型选型是很多人的第一道坎。直觉告诉你选最强的模型总没错。但工程实践会告诉你最强的模型意味着最高的成本、最大的延迟以及最不可预测的输出。我个人的习惯是分层选择简单的分类、抽取、改写任务用轻量级模型就够了复杂的推理、分析、长文本生成才用最强模型中间态的任务交给中等规模模型配合良好提示词和检索效果完全可以逼近大模型。你可能觉得这样做会牺牲效果。但请注意一个关键事实80%的应用场景里用户需要的不是“更聪明”而是“更稳定”。你用轻量模型干净数据往往比用重型模型脏数据的效果要好得多。模型选型还有一个容易被忽略的维度一致性。同一系列模型的输出风格相对可控跨系列切换模型往往意味着提示词全部重写。所以如果条件允许尽量锁定一个模型系列把精力放在数据和链路上而不是反复横跳换模型。2.2 宿主框架自己写还是用编排框架模型选完之后紧接着的问题就是业务逻辑怎么组织。市面上有不少编排框架它们把多轮对话、工具调用、记忆管理都做了抽象开箱即用。但如果你是从零开始做AI工程我建议一开始不要贪图这些框架的“全”。原因很简单框架把你和底层逻辑隔离开了一旦线上出问题你排查起来会非常痛苦。我更推荐的做法是用手写代码把核心链路搭起来只把框架当成代码库参考。你自己的代码里应当包含三个核心模块入口模块负责接收请求、做基础校验、准备上下文处理模块负责调用检索、组装提示词、请求模型出口模块负责解析模型输出、做格式校验、返回结果。这套结构看起来简单但它是可观测、可测试、可替换的。等你对链路烂熟于心再去引入框架也不迟。顺便说一句很多人喜欢在第一步就开始设计Agent。我的建议是不要。Agent只有在任务边界不清晰的时候才需要。如果你连“输入是什么、输出是什么”都没定义清楚Agent只会把不确定性放大而不是解决不确定性。2.3 本地知识库的接入设计AI工程里最常被问到的就是“怎么让模型懂我的业务知识”。答案几乎总是同一个外挂知识库而不是重新训练模型。外挂知识库的标准链路是文档清洗、切片、向量化、存储、检索。听起来不复杂但每个环节都有值得注意的细节。文档清洗决定了数据质量切片方式决定了召回效果向量化模型选择决定了检索准确率存储方案决定了查询性能。这些细节我会在实操章节展开这里先给一个重要提醒知识库不是“建完就完”的静态资源。业务文档会更新检索结果会反馈你需要一套文档版本管理和索引刷新机制。否则知识库会随着时间推移逐渐“腐化”直到用户开始抱怨“模型怎么还在用去年的规章制度”。2.4 可观测性AI应用最容易忽视的一块传统软件工程里日志、链路追踪、指标监控是不需要提醒的标配。但到了AI应用里很多团队却把这一步省了。这让我非常费解。一个AI请求的完整链路比普通API请求要长得多用户请求进来系统做意图识别拼装历史记忆发起检索召回结果组装提示词模型推理流式返回再经过校验、后处理整个链路里随便哪一环慢几毫秒用户感知就明显变差。所以从第一天起就必须给自己留三样东西完整的请求日志记录每一次调用的输入、输出、检索结果、模型参数、耗时一套质量打标机制让用户对生成结果进行反馈定时回放的回归测试集用于评估每次改动是否带来效果回退。这三样东西构成了AI应用可观测性的底座。没有它们一切效果优化都是盲人摸象有了它们你才能在数据基础上做判断而不是靠感觉拍板。3. 完整实操从零构建一个“资料问答助手”3.1 先定义需求和边界再谈技术我会用一个非常典型的场景走完全流程给团队做一个“内部资料问答助手”输入是员工的自然语言问题输出是准确引用资料来源的回答。开工第一件事不是写代码而是定义边界。我梳理了几个关键约束回答必须基于内部资料库资料库里查不到就明确说“不知道”回答需要附带引用来源方便用户核验可接受的响应延迟在3秒以内先只支持单轮问答不做多轮对话。你可能觉得这些约束太细了。但正是这些约束决定了后面所有的技术选型和实现方式。比如“必须附带引用来源”这直接导致我必须把检索结果与回答映射关系显式传给模型而不是让模型自由发挥。3.2 文档切分的参数选择过程资料问答第一步是要把文档切成长度合适的分块。切太短上下文信息不完整检索时语义不足切太长检索命中后塞给模型的内容太多既浪费Token又稀释注意力。我最终采用的策略是分层切分按照标题结构把文档切成章节每个章节内部再按段落进一步切分单块目标长度控制在350到500字中文相邻分块保留20字左右的重叠。这里有个值得实操的小细节重叠不是随便留的它主要是为了防切分点落在语义边界上导致连续的文本被拦腰切断。20字的重叠足够在召回时拼接回完整的语义单元。切分之后还有一道筛选工序。内部文档经常有大量与问答无关的内容比如页眉页脚、目录、表格、图片。我写了一个启发式规则把纯目录页、纯图片页、超过100字的长表格单独标记出来不进入检索索引必要时单独走结构化处理。3.3 Prompt模板的系统化设计很多教程会告诉你“提示词要写清楚”却不告诉你怎么才算“清楚”。我的经验是Prompt模板应该被当作代码来管理需要有稳定的结构和版本号。我给问答助手的系统提示词设计了四个区块角色定义用一句话说明“你是什么、你要做什么”知识来源约束说明只能基于给定资料回答不知道时如实说明输出格式要求说明回答的结构和引用规范工作流程说明先看资料再回答、引用格式等操作顺序。更重要的是我要求模型在输出时保留“证据链”。具体做法是在提示词里加一条指令“回答中每一个关键结论需要用括号标注对应的资料编号例如资料3”。有了这条指令用户和开发者就能一起判断模型是不是在胡编。我见过不少人怕Prompt模板太长会增加Token消耗。我的体会是这个担心可以理解但不需要过分。一个结构清晰的系统提示词对输出质量的提升远超那几个Token的成本。真正应该避免的是在用户问题里堆砌冗长的背景材料那才是真正的浪费。3.4 检索链路与模型调用的代码实现这里给出一个极简但可运行的核心链路代码我会用伪代码风格来写方便你迁移到自己的技术栈。# 检索与回答的核心流程伪代码风格 def answer_question(question: str) - dict: # 第一步检索候选资料块 candidates search_docs(question, top_k5) # 第二步构造可控的上下文 context_blocks [] for i, block in enumerate(candidates, start1): context_blocks.append(f[资料{i}]\n{block.text}) context_str \n\n.join(context_blocks) # 第三步组装提示词 system_prompt build_system_prompt() user_prompt f 请根据以下资料回答问题。 资料 {context_str} 问题{question} 要求 1. 只使用资料中明确提到的信息 2. 如果资料中没有相关信息直接回复“资料中未找到相关信息” 3. 回答中的关键结论请用资料编号标注来源。 # 第四步调用模型降低随机性 response call_llm( systemsystem_prompt, useruser_prompt, temperature0.2, # 问答场景用低温保持稳定 max_tokens500 ) # 第五步后处理与格式校验 result parse_and_validate(response) return result这段代码里最值得说的其实是temperature参数。很多人以为temperature是“质量旋钮”调高一点回答更“聪明”。实际上它控制的是采样随机性。在问答场景我建议把temperature压在0.2以下在创意文案场景才考虑调到0.7以上。方向对了模型行为才可控。另外注意一下top_k5这个参数。它不是越高越好。检索回来的资料块越多塞给模型的噪声也就越多模型被“带偏”的概率越高。我的经验是大多数内部问答场景top_k在3到5之间表现最好。如果你发现回答经常“东拉西扯”先看看是不是丢给模型的资料太杂了。3.5 评估闭环没有评估就没有工程链路跑通之后最重要的一件事不是继续加功能而是把评估体系搭起来。我维护了一个评估集里面有四类测试样本标准问答资料里明确有答案的问题边缘问答资料里没有答案应该回复“不知道”的问题混合问答答案分散在多份资料里需要拼接的问题对抗问答包含易混淆概念、需要准确区分的问题。我每次修改提示词或检索策略都会拿这个评估集跑一遍观察正确率变化。这个过程听起来繁琐但它是让AI应用走向“可维护”的必经之路。没有评估集你根本说不清一次改动是变好了还是变坏了。评估还可以做得更细。比如对“回答正确性”和“引文准确率”分开打分。很多系统回答内容是对的引用的资料编号却是错的这会让用户失去信任。把评估维度拆得越细你定位问题的速度就越快。4. 常见问题与排查技巧实录4.1 模型“一本正经地胡说八道”怎么办这是AI应用上线后收到的第一类客诉。排查时先不要急着改提示词。我建议按下面的顺序逐一排查先看检索召回的资料块问题是否真的被覆盖到了再看提示词里的约束指令是否被模型无视了最后看模型输出是“语义跑偏”还是“来源标注错误”。大多数情况下问题的根源出在检索不在模型。你给定的资料里根本没有答案模型为了完成任务只能硬编。所以把精力花在优化检索质量远比在提示词里反复强调“不要胡说”有效。如果确认资料里有答案但模型没用上那就要看是不是资料块切得太碎或者检索排序把真正相关的资料排到了后面。这时候可以调整top_k、修改检索重排序策略这类问题改提示词是解决不了的。4.2 上下文窗口永远不够用模型上下文窗口是有限的而业务资料可以无限增长。这个矛盾是AI工程的核心难题之一。我的处理方式是建立“摘要辅助层”对长资料做分层摘要先用摘要命中的信息判断该把哪段原文完整引入上下文。这相当于在检索和模型之间增加了一个“粗筛”环节能显著减少塞给模型的无关内容。还有一个很实用的技巧将多轮历史对话压缩成摘要而不是把全部历史事实原样保留。用户问了三轮问题真正影响当前回答的往往只有最近两轮意图。保留完整历史一方面浪费Token另一方面还会干扰模型对“当前问题”的注意力。4.3 延迟和成本同时失控AI应用上线后你一定会经历一个“花钱如流水”的阶段。我看到很多项目在第一个月就被账单吓到了。优化延迟和成本我有几个亲身验证有效的思路给模型输出设置max_tokens上限防止模型“话痨”在低峰期对答案做缓存相同问题直接命中缓存对简单问题用轻量级模型兜底复杂问题才调用大模型开启流式输出让用户感知延迟明显降低而不必等完整生成结束。其中缓存是性价比最高的方案。因为企业内部知识库的变化频率其实很低大量问题都是同一个高频子集的变体。只要做好缓存键的设计建议用语义向量匹配而不是精确字符串匹配缓存命中率能到30%以上这部分节省的成本非常可观。4.4 效果不稳定无法复现“昨天还好好的今天就不行了”这大概是AI工程师最常听到的一句话。稳定复现是AI工程里最磨人的议题。我的排查思路是把变量一个个孤立出来先固定模型版本确认线上模型没有被平台侧悄悄切换再检查检索索引确认没有误触发全量重刷导致索引“漂移”最后回归评估集看是新问题导致的退化还是本来就有隐患。针对“本来就有隐患”的情况我还有一个补充建议在提示词里增加“如果问题表述不明确请先提问澄清不要猜测用户意图”。这能有效降低因为问题歧义导致的输出波动。这个技巧看起来朴素但它能大幅提升用户对系统稳定性的感知。顺带说一句AI应用上线后要养成“每次只改一个变量”的习惯。很多团队一出问题就同时改提示词、改参数、换模型然后问题“消失”了但没人知道是哪个改动生效的。这种混沌状态是做AI工程最忌讳的。5. 写在最后的几条体会关于AI工程我还有一些零散但很关键的经验想分享出来。第一AI工程里80%的时间花在数据清洗、评测用例准备和边界处理上真正的模型调用代码只占很小一部分。如果你觉得AI项目开发“很快”那很可能是你跳过了大量本该做的工程环节。第二不要迷信“效果不好就换模型”。请始终记住系统效果是数据和链路的函数模型只是其中一个变量。把检索做好了、数据洗干净了、评估闭环跑起来了你手上最普通的模型也能释放出足够好的效果。反过来以上这些没做好换成最强的模型也只是更有“创意”地犯错。第三AI工程能力是一种元能力可以复用到来年的所有新项目里。你学会的检索、评估、边界设计、可观测性其实都是“控制不确定性”的底层能力。这类能力永远不会过时而且会随着你做的项目增多而越来越值钱。我个人的习惯是每参与一个新项目都会把当时的评估集、Prompt模板和问题记录整理成一份复盘笔记留待后续排查时对照。多记录、多回看几次之后很多曾经让你困惑的随机波动都会逐渐显露出它的规律。这就是工程感和所谓的“经验”一点一点积累起来的样子。