1. 从“一次性提示词”到“可维护的AI系统”1.1 第一个成品项目毁在一句话上我刚开始接触AI工程时和大家一样以为这事儿的核心就是写提示词。辛辛苦苦把Prompt调到“十全十美”demo演示时掌声一片结果一上线用户随便发来一句话格式稍微不对整个输出就崩了。不是返回了一堆废话就是直接报错。那一刻我才意识到提示词写得再漂亮也只是AI工程里最薄的一层皮。所谓的AI工程本质上是把大模型从一个“会聊天的Demo”变成“能稳定跑业务的系统”。它要考虑的不只是“模型答得对不对”还包括输入输出格式稳不稳定、异常输入怎么办、连续多轮会不会跑偏、token成本会不会失控、用户反馈能不能追踪。这些题目的总和才叫AI工程。而“从零开始”这四个字意味着你要亲手把这套链路从无到有搭起来而不是在别人的框架里当个螺丝钉。适合谁来读这篇两类人。一类是刚想入行、被各种“Prompt技巧”轰炸得头晕眼花的同学另一类是后端或全栈出身、接了个大模型需求却不知道从何下手的朋友。我会把冷启动的步骤、评估方法、Harness工程的关键点以及我踩过的坑全部分享出来。1.2 Harness Engineering和Loop Engineering到底是什么这两年“Harness Engineering”和“Loop Engineering”被频繁提起。我第一次看到这两个词也很懵后来在项目里才慢慢体会到它们的价值。Harness Engineering字面意思是“挽具工程”指的是你把模型、工具、提示词、控制逻辑封装成一个可受控的完整执行环境。类比一下模型是一台发动机Harness就是发动机盖下的管线、传感器、冷却系统和仪表盘。没有Harness发动机还是能转但你不知道它的转速、温度也无法在异常时立刻断电。Loop Engineering则研究的是“多轮循环”模型可能因为一个任务反复调用工具、反复思考、反复自我修正。这个循环如果没做限制轻则烧钱重则死循环。我在一个AI Agent项目里就遇到过模型为了确认用户地址连续调了七次工具最后直接超预算。所以从零开始做AI工程第一课不是“怎么把Prompt写得更花哨”而是“怎么把系统边界划清楚”。我们得先有稳定可控的外壳再去谈智能。2. 冷启动先定义输入输出契约再碰模型2.1 给每次模型调用立个“数据合同”我做AI工程的第一步从来不是“选个厉害的模型”而是写数据合同。所谓数据合同就是明确规定系统接收什么输入、必须产出什么输出、用什么数据结构表达。你可以把它理解成你和模型之间的约定。比如你要做一个“从简历里提取候选人信息”的功能那么输入可能是PDF解析后的一段纯文本输出必须是一个JSON对象里面有姓名、工作年限、技能列表、离职状态等字段。只要模型输出不符合这个JSON结构系统就必须能识别出“这一次不合格”而不是硬着头皮往下游传。为什么不直接让模型自由发挥因为自由发挥的文本接到下游代码里就是一场灾难。你的负责人工复盘的同事没法快速扫描几百条自由文本你的自动化测试也没法断言“答对了没有”。一旦输出不是结构化数据整个AI系统的可维护性瞬间归零。具体操作上我会在项目里准备一份契约文档至少包含三块字段名与类型、必填项与选填项、约束条件比如枚举值范围、最大长度。然后把这份契约写进校验函数。每次模型返回内容先过校验再进业务逻辑。校验不通过就直接触发重试或走兜底策略。2.2 最小管道调用、解析、校验、重试定了合同之后就要搭起第一条可用管道。我建议一开始不要追求花哨先跑通四段式调用、解析、校验、重试。调用阶段就是把用户的输入整理成Prompt或消息序列发给模型解析阶段把模型返回的文本转成结构化对象校验阶段检查字段是否齐全、类型是否正确、内容是否在允许范围内重试阶段对解析失败或校验不通过的情况换个策略再来一次。这里有个很容易犯的错把重试做成同一个Prompt反复调。模型不是数据库同样的输入加上同样的Prompt下一次返回也可能不一样。如果你不加任何变化就重试通常只会浪费一倍token结果还是失败。更合理的做法是第一次失败后在Prompt里主动附上错误信息告诉模型“你刚才的返回不符合JSON格式请只返回合法JSON”这样模型才有机会自我纠正。一个经验值管道刚搭好的时候先把解析失败率打到一个可观测的水平。我个人的及格线是“非极端输入下格式错误率低于2%”。如果连这个都做不到后面的评估、调优全都白搭。2.3 模型选型与成本预算冷启动阶段别在模型选型上太纠结但也别有“什么贵用什么”的心态。我的原则是优先选择你日常最容易迭代、调试起来最快的那一个方案。如果业务跑在API上那就以响应速度、稳定性、上下文长度、单位成本为四个维度建一个简单对比表。拿一个典型的问答类功能举例小参数量模型可能单次调用成本很低但每十个回答里就有一个事实错误大参数模型准确率高价格也高。这时候你需要算的不是“单次调用多少钱”而是“每月跑十万次加上重试和兜底成本总账单是多少”。我习惯在Excel里建一套粗算模型预估日活用户、日均请求量、平均输入输出token数、缓存命中率、重试率最后乘上单价。哪怕数字都是估的也比“觉得便宜”靠谱得多。另一个该注意的是上下文长度很多业务场景输入本身就有几千字你还把历史记录全塞进去模型还没回答上下文窗口就快满了。这时候要做的不是换超大窗口模型而是设计截断、摘要、分段等策略。3. 把Prompt当代码管版本化、模板化、回归化3.1 从乱写字符串到模板工程很多初学者写Prompt喜欢直接在代码里拼接一个巨大的字符串改的时候就去全局搜索替换。这在个人脚本里没问题一旦产品上线就成了定时炸弹。Prompt里任何一句微调都可能影响线上所有用户。所以从零开始做AI工程必须从第一天就把Prompt当代码管理。具体做法有三步。第一把Prompt拆成模板文件用占位符代替会变化的变量比如用户问题、上下文、示例数据第二为每个模板赋予版本号哪怕只是改了一个标点也要升一个小版本第三把模板统一放进代码仓库走正常的评审和合并流程不允许任何人直接在线上改Prompt。这样做的好处是你可以随时回答“线上到底用的是哪版提示词”而不是“大概是前天那版吧”。我见过太多排查事故时翻遍服务器日志却不知道当时代码里嵌入的Prompt是什么内容最后只能靠猜。版本化之后这类问题直接消失。3.2 少样本示例与思维链的应用边界调Prompt时少样本示例和思维链是两大基本功但很多人用错了地方。少样本示例就是在Prompt里给模型展示一两个“正确做法”的样例。它特别适合格式要求严格、或者业务里存在大量隐性规则的场景。比如你要让模型判断“用户吐槽是否包含退款诉求”与其写一大段抽象规则不如给它三个典型例子“这句话有诉求因为提到了退款”“这句话只是抱怨因为没提补偿”“这句话不确定因为语气含糊”。模型看到具体例子通常比读十句抽象要求表现更稳。思维链则是让模型“先想后答”适合推理类任务。但注意一点不是所有任务都需要展示完整推理过程把思考过程暴露给最终用户往往是画蛇添足。工程上的常规做法是让模型在内部先输出思考内容再根据思考内容生成最终答复最后只把答复展示出去。我用下来的心得是少样本示例负责“教规矩”思维链负责“教思路”。两者比例不是越多越好示例超过五个之后边际收益会急剧下降反而增加token成本和Prompt稳定性风险。最好按场景做几组A/B实验以评估集上的指标为准不要凭感觉加料。3.3 给Prompt加CI回归测试这是我觉得最值得推广的实践。既然把Prompt当代码管那它就应该有自动化测试。AI项目的回归测试和传统后端回归测试有一点不同不能只断言“报不报错”还要断言“答得好不好”。做法是建一个精简的回归集规模不用大三十到五十条足够。每条样本包含输入、期望输出以及判断逻辑。判断逻辑可以是规则判断比如“回复里必须包含订单号”也可以是模型打分甚至可以是你人工复核后留下的“标准答案”。每次改动Prompt先跑一遍回归集看整体通过率有没有下降。这个习惯救过我很多次。有一次我为了提升某个小类别的准确率改了两句Prompt示例小类别分数上去了结果基础问题类别准确率掉了十个百分点。如果没有回归测试这种问题通常要等用户骂上门来才能发现。有了它一次提交就能挡住回归省下的时间不可估量。4. 评估与观测告别“我试了好几个都不错”4.1 第一批评估集怎么建刚开始做AI项目时我最常犯的错是“凭印象评估”这边试一个例子觉得不错那边再试一个也还行就认为自己完成了优化。结果一上真实流量形形色色的输入涌进来才发现自己看到的只是冰山一角。所以项目的第二周我就会拉出一个评估集至少包含四类样本。一是“常规黄金样本”就是业务里最常见的提问和标准答案二是“边界样本”比如空输入、超长输入、半句话、错别字连篇的句子三是“高危样本”涉及隐私、敏感内容、诱导模型输出不当信息的输入四是“长尾样本”来自真实的用户反馈或历史日志挑那些之前曾经让模型翻过车的。评估集的维护比建立更重要。每次线上发现一个新问题我都有个习惯先把出问题的输入和期望输出补充到评估集里再去修改Prompt或代码。这样确保同类问题不会反复出现。一个月下来这个集子就会成为整个团队最值钱的资产之一。4.2 指标矩阵质量、格式、成本、延迟评估AI系统我最怕一件事只盯准确率。准确率当然重要但达到90%准确率而格式错误率高达10%照样没法上线准确率没问题但平均延迟超过十秒用户照样流失。我在这类项目里习惯维护一张指标矩阵至少四个维度回答质量准确率、相关度、幻觉率格式合规JSON解析成功率、必填字段缺失率性能首token延迟、总延迟成本每千次调用的平均token消耗、重试损耗。每个维度给一个当前的基线值和一个目标值每次迭代后回填。特别想说幻觉率这件事。很多人以为降低幻觉是靠换更大的模型但在我自己的实践里把知识检索结果完整地拼接进Prompt、并在输出指令里强调“没有依据就明确说不知道”比单纯换模型更立竿见影。关键是你得先把幻觉率量化下来否则永远不知道自己改完是变好还是变坏。4.3 日志与追踪出问题时能回答“当时发生了什么”AI系统有个臭名昭著的特性同一个问题前后两次调用输出可能差出十万八千里。这就意味着排障不能依赖“复现”必须依赖日志。我从第一版就强制要求每次请求都记录完整的请求ID、时间戳、模型版本、Prompt模板版本、输入内容、输出内容、token数和耗时。同时每次重试也要留在日志里最好能串联成一个trace。真实用户的问题往往不是“单次输出错了”而是“某次重试之后得到错误结果”这时候只有把完整过程串起来才能定位。日志不只是给程序员用的。我会让负责内容运营或客服的同学也能看一份简化版日志他们发现异常时可以直接把请求ID丢给我。配合之前建的评估集一个新问题从被用户报告到进入回归集基本可以实现当天闭环。5. 从单次调用到自主循环Harness工程实战5.1 搭一个最小的Harness当你的AI系统开始接工具、查数据库、执行代码它就不再是“一问一答”而是一个自主行动体。这个时候核心工作就变成了Harness工程把模型、可用工具、系统指令和控制逻辑组合在一个可控的框架里。我搭最小Harness的套路是这样先定义一份“工具清单”每个工具写明名称、用途、输入参数、输出格式再把这份清单整体告诉模型并限定它只能调用清单里的工具。模型每次想调用工具不是直接执行而是“申请调用”由Harness去校验参数、检查权限、执行真实操作再把结果塞回上下文。为什么要用这种“模型提申请、Harness来执行”的架构因为安全与可控。比如要限制模型只能读某个目录、不能删文件、调用外部接口前必须经过校验直接在Harness层施加限制比寄希望于模型“自觉”要可靠一万倍。5.2 循环控制的四个关键参数真正让AI Agent项目翻车的地方往往在循环。模型“想好了要做什么”Harness去执行执行完再让模型“想下一步”这个循环如果失控轻则耗时耗钱重则反复做同一件无效操作。我总结下来循环控制至少要盯四个参数。最大迭代次数。这是最基础的一条。哪怕是复杂任务我也很少把上限设超过十轮防止模型在原地打转。终止条件。不仅要在“任务完成”时终止还要在“连续N轮无进展”时终止。我见过模型连续五轮都在调用同一个查询工具、结果几乎没有更新的情况没有终止条件就是一场灾难。最大Token消耗。每次循环都会把工具结果追加进历史上下文会越来越长。到达预算上限时必须能主动停下来而不是等账单出来才傻眼。异常恢复策略。比如工具调用报错模型是会换个工具继续尝试还是彻底放弃这两者的行为差异很大。设计时最好给模型一个明确指令“如果某个工具连续失败两次请停止该方向并给出结论。”5.3 什么时候上多Agent什么时候别上最近多Agent协作的概念很火很多项目一上来就要搞“规划Agent、执行Agent、审查Agent互相配合”。我的态度是先问自己要解决的问题是不是真的需要。单Agent加上良好设计的Harness能覆盖大多数业务场景。多Agent的真正优势在于任务之间需要隔离上下文、或者需要不同角色使用不同的Prompt约束。比如“拆解指令的Agent”和“执行具体操作的Agent”分开可以让前者保持高度简洁的指令理解逻辑后者专注在工具调用上互相不污染上下文。但多Agent最大的代价是复杂度。交互次数变多、token消耗翻倍、错误更难追踪。我自己的原则是先用单Agent跑通把评估指标记录下来如果确实因为上下文污染或角色冲突导致指标上不去再拆成多Agent并且每次拆分都用旧样本做回归对比。5.4 权限边界给Agent上一把锁Harness工程里最容易被忽略的是权限模型。模型有工具调用的能力不代表它应该拥有所有权限。我在项目里会把“模型能调用的工具”和“整个系统能执行的操作”严格区分。比如一个Agent能调用“发送邮件的工具”但它只能向特定白名单里的地址发送或者发送前必须由人工确认按钮。权限控制不能做到模型层而是要做到Harness层。模型输出“我想调用发送邮件工具”Harness收到后先判断目标收件人是否在白名单里不在就拒绝并返回“无权限”。这一层是代码逻辑与模型无关是绝对可信的守门人。6. 上线后的六个坑与排障思路6.1 一张表看六个常见故障我把上线这段时间遇到的高频故障整理成了一张表基本覆盖了我和同行交流时最常见的六类问题故障现象核心原因我的第一反应输出格式时好时坏模型对JSON结构理解不稳定在Prompt里加强格式要求并开启格式校验函数多轮对话后答非所问历史上下文越滚越长关键信息被稀释引入摘要机制压缩旧上下文预算超支加了工具后循环重试次数变多检查最大迭代次数和终止条件静默出错模型“自信”地给出错误事实无依据时强制明确说“不知道”同类问题反复出现没有把反馈补充进回归集先补样本再改Prompt用户输入稍歪就崩Prompt过于依赖固定表达加边界样本做输入归一化6.2 一次真实排障从用户报错到找到根因前阵子线上反馈了一个难缠的问题部分用户说“客服助手聊到一半突然回复奇怪的内容像是把别人的聊天记录混了进来”。一开始我以为是上下文串了赶紧检查会话隔离逻辑结果没发现问题。后来把出问题请求的完整trace调出来才发现根因很有意思用户在一轮提问里粘贴了一大段含特殊字符的文本这些字符被某个工具识别成了命令开始标记模型误以为收到了“新指令”于是中断了原本的对话主题。也就是说问题不在上下文隔离而在输入清洗环节。修复很简单在Harness入口对所有输入做转义并把包含特殊标记的文本按普通字符串处理。但排查过程花了整整一下午。如果当初日志里没有记录那一刻完整的输入原文这个问题可能还要拖好几天。这就是我为可观测性付出的时间回报在关键时刻。6.3 迭代路线图把问题排序再动手上线运营之后你一定会同时收到一堆需求这个回答不专业、那个格式不对、这里延迟太高、那里成本太贵。我的经验是千万不要按用户喊得响的顺序来修。修问题要有自己的优先级表否则很容易被带乱节奏。我的排序逻辑是“影响面乘以严重程度”。影响面指问题影响多少用户严重程度指问题是否会导致业务错误、声誉风险或直接的资金损失。每修一个问题前先看两个维度再做决定。这样做的结果是团队不会把精力耗在极少数用户遇到的边角问题上而漏掉影响核心流程的致命问题。有了这张优先级表每个迭代周期只选一件最重要的事修完用回归集对照验证然后再把新样本补充进去。这个闭环走顺之后系统会肉眼可见地稳定下来。7. 给后来者的五条建议最后想用自己的体会给准备从零开始做AI工程的朋友一些建议。这些建议不是教科书上的而是我实际被现实教育过之后总结出来的。第一别急着调Prompt先把输入输出契约和评估集建好。没有评估你所有“优化”都是在黑夜里开车。第二Prompt一定要版本化、模板化它和业务代码一样需要走评审流程。第三从第一天就做日志和trace别等出了问题才后悔。第四给Agent上循环控制和安全权限这比追求“智能”重要得多。第五多Agent是手段不是目的能单Agent解决的事就不要为了架构炫技而拆。我到现在还保持着两个习惯每天看一眼线上日志里格式错误率有没有异常每次修改完任何Prompt模板先跑一遍回归集再部署。这两个习惯花了很少的时间却挡住了绝大部分事故。AI工程这件事说白了没有魔法就是把每一环节都做得足够扎实让系统在大部分时候稳定可靠在异常来临时可查可控。