1. 从跑通Demo到扛住生产流量中间隔着什么很多团队第一次把大模型能力接进业务时都会经历一个极其相似的阶段某个下午某位开发者用几十行代码调通了一个接口模型返回的结果看起来像模像样演示给相关方看的时候大家都很兴奋觉得这件事成了。然后进入排期、准备上线问题开始一个接一个冒出来——响应时间忽高忽低、同样的输入两次结果不一样、某些请求莫名其妙超时、成本账单比预期高出一大截、出了badcase却不知道从哪查起。这个落差不是某个团队的问题而是AI应用落地过程中普遍存在的结构性断层。传统软件的行为是确定的输入A必然得到B测试用例写好了就能回归验证。但AI应用的核心是一个概率系统同样的输入可能得到语义相近但表述不同的输出甚至偶尔给出完全偏离预期的结果。把这样一个系统放进生产环境需要补的课远不止“把接口调通”那么简单。这篇笔记想聊的就是这个补课过程——AI应用的工程化治理。所谓治理不是写几份文档、开几次评审会而是围绕一个概率型系统建立一整套可观测、可控制、可迭代的工程机制。它覆盖的范围包括但不限于提示词怎么管、模型输出怎么校验、成本怎么控制、效果怎么评估、线上异常怎么定位、版本怎么回滚。适合正在把AI能力往生产环境推的工程团队参考也适合刚接触这块、想提前了解坑在哪里的开发者。我自己的体会是Demo阶段拼的是“能不能跑通”生产阶段拼的是“跑不通的时候你能不能快速知道、快速定位、快速恢复”。这两件事需要的能力模型完全不同。下面按我实际踩过的顺序把几个核心环节拆开讲。2. 提示词不是字符串是要纳入版本管理的工程资产2.1 把提示词散落在代码里是第一个要改的习惯最开始做AI应用的时候提示词往往就是代码里的一个字符串常量或者配置文件里的一段文本。改一改、测一测、上线看起来没什么问题。但当业务迭代到一定阶段你会发现提示词的数量和复杂度都在膨胀不同场景用不同的提示词、同一个场景针对不同用户群体有变体、为了修复某个badcase临时加了一段约束、为了适配新模型版本又调了一版措辞。这时候如果提示词还是散落在各个代码文件里会出大问题。最典型的场景是线上效果变差了你想回滚到上一个版本结果发现根本不知道上一个版本的提示词长什么样因为它是跟着代码一起提交的而代码可能已经合并了好几个其他改动。你没法单独把提示词回滚回去。我的做法是把提示词从代码中彻底抽离出来作为独立的资产来管理。具体来说每个提示词有唯一的标识符有版本号有变更记录有对应的负责人。存储上可以用配置中心、可以用数据库、也可以先用文件加版本控制关键是它必须能独立于代码进行发布和回滚。2.2 提示词版本管理的最小可用方案不一定一上来就搞得很重但有几个要素是必须的。下面这张表是我认为提示词管理的最小要素集要素作用缺失后的典型问题唯一标识定位具体是哪个提示词出问题时不知道改哪个版本号区分不同迭代无法回滚无法对比变更说明记录改了什么、为什么改过两周自己都忘了关联评估结果知道这个版本效果如何凭感觉判断好坏生效范围控制灰度还是全量一改全量风险不可控我见过比较务实的做法是用一个简单的表来存提示词字段包括标识、版本、内容、状态草稿/灰度/全量/下线、创建时间、备注。每次修改生成新版本不覆盖旧版本。线上请求根据标识和当前生效版本去取。这样回滚就是改一个状态字段的事。注意提示词版本和代码版本要解耦。不要用代码的发布流程来管理提示词否则每次改一句话都要走一次完整的代码发布迭代速度会被拖死。2.3 提示词变更必须过评估不能凭感觉这是很多团队容易忽略的一点。改提示词的成本太低了低到让人产生一种“随便改改没关系”的错觉。但实际上提示词的一个措辞变化可能导致模型在某个子场景下的表现大幅波动。你修复了A场景的问题可能同时把B场景搞坏了。所以提示词变更应该有一个轻量的评估环节。不需要像模型训练那样搞大规模评测但至少要有一个固定的评估集覆盖核心场景和已知的边界情况。每次变更后跑一遍评估集对比新旧版本的关键指标。指标可以是准确率、可以是人工评分、可以是某个业务维度的通过率具体看场景。评估集本身也是需要维护的资产。线上发现的badcase应该定期补充进去让评估集越来越贴近真实分布。我一般建议评估集至少覆盖三类样本典型正常样本、已知边界样本、历史badcase样本。三类样本的比例根据业务特点调整但badcase样本一定要有否则评估集就是自嗨。3. 模型输出的不确定性必须用工程手段兜住3.1 为什么不能直接信任模型返回的结果模型输出是概率性的这意味着它可能返回格式不对的内容、可能返回语义偏离的内容、可能返回包含不该出现信息的内容。如果你直接把模型输出透传给下游系统或者展示给用户出问题是迟早的事。我遇到过最典型的情况是要求模型返回JSON格式大部分时候没问题但偶尔会多一句解释性文字导致下游解析直接报错。还有的情况是模型在某个边界输入下返回了空内容下游没做空值处理直接崩了。这些都不是模型“坏”而是概率系统的正常表现工程上必须兜住。3.2 输出校验的分层策略我的经验是把校验分成几层从轻到重依次是第一层是格式校验。如果约定返回JSON就严格解析JSON解析失败直接判定为异常。这一层成本最低能拦掉大部分低级问题。第二层是结构校验。JSON解析成功了但字段是否齐全、类型是否正确、枚举值是否在允许范围内这些都要检查。比如约定返回的某个字段只能是三个固定值之一那就必须校验。第三层是业务规则校验。这一层跟具体场景相关比如返回的内容长度是否在合理范围、是否包含敏感词、数值是否在业务允许区间内。这一层需要结合业务知识来设计规则。第四层是语义校验。这一层最难通常需要另一个模型或者人工来判断输出是否真的符合预期。成本高一般只用在关键路径上或者作为抽样检查。实际落地时前两层是必须的第三层根据业务风险决定第四层看投入产出比。校验不通过时的处理策略也要提前想好是重试、是降级到兜底回复、还是直接报错让上游处理。不同策略对应不同的用户体验和系统复杂度。3.3 重试不是万能药要有退避和上限模型输出不合格时一个自然的想法是重试。但重试有几个坑要注意。首先是重试次数要有上限不能无限重试否则一个坏请求可能拖垮整个链路。其次是重试要有退避连续快速重试往往得到同样不好的结果稍微等一等再试成功率会高一些。最后是重试要考虑幂等性如果这个请求已经产生了副作用重试可能造成重复操作。我的习惯是格式和结构校验失败可以重试一到两次业务规则校验失败看情况有些适合重试有些不适合语义校验失败一般不自动重试而是记录下来人工介入或者走兜底逻辑。重试的间隔用指数退避比如第一次等200毫秒第二次等500毫秒避免给下游造成瞬时压力。4. 成本失控往往不是模型贵而是调用方式粗放4.1 先把成本拆开看才知道钱花在哪很多团队第一次看到AI调用账单的时候会吓一跳觉得怎么这么贵。但如果你把成本拆开看会发现大部分钱花在了不该花的地方。成本的大头通常来自三个地方输入token过多、输出token过多、无效调用过多。输入token过多常见原因是把一大堆无关的上下文塞进了提示词。比如做问答的时候把整个知识库的相关文档全量拼进去其实真正有用的可能就其中一两段。输出token过多常见原因是没限制输出长度模型洋洋洒洒写了一大段但业务只需要一个简短结论。无效调用过多常见原因是没做缓存同样的请求反复调用或者用户误操作触发了大量重复请求。4.2 几个立竿见影的成本优化手段第一个手段是缓存。对于相同或相似的输入如果之前已经调用过并且结果可用直接返回缓存结果。缓存可以按输入内容的哈希来做也可以按语义相似度来做。语义缓存复杂一些但命中率更高。我一般建议先做精确缓存简单有效能省掉相当一部分重复调用。第二个手段是控制上下文长度。在拼装提示词的时候对上下文做筛选和截断。筛选可以用关键词匹配、可以用向量检索、可以用规则目的是只把最相关的内容放进去。截断要有策略优先保留开头和结尾中间部分按重要性取舍。第三个手段是限制输出长度。在调用参数里设置最大输出token数同时在提示词里明确要求简洁。很多模型对“请简洁回答”这类指令是敏感的加上之后输出长度会明显下降。第四个手段是分级调用。不是所有请求都需要用最强的模型。简单任务用小模型复杂任务用大模型。可以先用小模型试置信度不够再升级到大模型。这样整体成本会降不少。优化手段实施难度预期节省注意事项精确缓存低中高注意缓存失效策略上下文筛选中高筛选逻辑要评估输出长度限制低中别把有用信息截掉分级调用中高高需要置信度判断机制4.3 成本监控要细化到场景和调用方只知道总账单是不够的必须能拆到具体场景、具体调用方、具体时间段。这样才能定位到是哪个功能在烧钱是哪个用户或哪个上游系统在异常调用。我一般会记录每次调用的场景标识、输入输出token数、耗时、是否命中缓存然后按维度聚合。有了这些数据成本优化才有方向而不是盲目地砍功能。5. 效果评估不能靠感觉要建立可复现的评测机制5.1 没有评测集所有优化都是盲人摸象这是我最想强调的一点。AI应用的迭代如果缺少评测机制就会退化成一种玄学改了一版提示词感觉好像好了一点但又说不上哪里好换了一个模型好像快了一些但效果是不是降了不确定。这种状态下团队会陷入无休止的争论谁也说服不了谁。评测集的作用是提供一个相对客观的标尺。它不需要完美但需要稳定、可复现、覆盖核心场景。每次变更后跑一遍看指标是升是降决策就有了依据。评测集的建设是一个持续过程从零开始也没关系先覆盖最重要的几个场景然后逐步补充。5.2 自动评测和人工评测怎么配合自动评测适合大规模、高频次的回归验证。可以用规则匹配、可以用另一个模型来打分、可以用向量相似度。优点是快、便宜、可重复。缺点是对于语义层面的细微差别判断不准容易漏掉一些只有人才能发现的问题。人工评测适合小规模、高价值的深度验证。比如新版本上线前的验收、重大变更后的效果确认。优点是判断准确、能发现意外问题。缺点是慢、贵、主观性强。我的做法是日常迭代用自动评测做快速回归发现指标异常再拉人工复核。重大版本上线前自动评测加人工抽检双重确认。人工评测的样本要随机抽取避免只挑容易判断的样本。5.3 评测指标要跟业务目标对齐技术指标好看不等于业务效果好。比如模型输出的BLEU分数很高但用户就是不满意这种情况并不少见。所以评测指标的设计要尽量贴近业务目标。如果业务目标是提升用户问题解决率那评测就应该看问题是否被真正解决而不是看输出和标准答案的相似度。实际操作中可以把业务指标拆解成可评测的子指标。比如问题解决率可以拆成意图识别是否正确、关键信息是否完整、是否有误导性内容、用户是否需要追问。每个子指标设计对应的评测方法综合起来就能比较全面地反映业务效果。6. 线上出问题不可怕可怕的是不知道从哪查起6.1 AI应用的可观测性要补哪些课传统应用的可观测性主要看日志、指标、链路追踪。AI应用同样需要这些但还需要补充一些特有的维度。最核心的是要能还原每一次调用的完整上下文输入是什么、提示词是哪个版本、模型是哪个版本、参数是什么、输出是什么、耗时多少、token消耗多少、走了哪条处理链路。这些信息如果不在调用时就记录下来事后是补不回来的。所以日志设计要在开发阶段就考虑好不能等出了问题再临时加。我一般会把每次调用的关键信息结构化记录下来存到可以快速检索的地方。出问题时根据用户反馈的时间点或者请求标识能快速定位到具体调用记录。6.2 一个真实的排查链路长什么样假设线上收到反馈某个功能最近回答质量下降。排查链路大致是这样的第一步确认问题范围。是个别用户还是普遍现象是特定输入还是所有输入是最近开始的还是一直存在这一步通过日志聚合和用户反馈交叉验证。第二步定位时间点。如果确定是最近开始的对比问题出现前后的调用记录看有什么变化。常见的变化包括提示词版本变了、模型版本变了、上游数据变了、流量特征变了。第三步复现问题。拿问题出现时的输入和当时的配置在测试环境复现。如果能复现就可以逐步排查是哪个环节导致的。如果不能复现可能是环境差异或者数据差异需要进一步对比。第四步验证修复。找到原因后修复并验证。如果是提示词问题回滚或修改提示词如果是模型问题切换版本或调整参数如果是数据问题修复数据链路。修复后要在评测集上验证确认没有引入新的问题。这个链路看起来简单但实际排查时最耗时的是第一步和第二步因为需要足够细粒度的日志和足够灵活的检索能力。如果日志记录不全或者检索很慢排查就会变成大海捞针。6.3 告警要设但要设得聪明AI应用的告警不能只设技术指标比如响应时间、错误率。这些当然要设但还不够。还需要设效果相关的告警比如输出校验失败率突增、缓存命中率骤降、某个场景的调用量异常波动、token消耗异常增长。这些告警能帮你更早发现效果层面的问题而不是等用户投诉才知道。告警阈值不要设得太敏感否则会被大量误报淹没最后大家都不看了。我一般会先观察一段时间的正常波动范围然后阈值设在正常范围之外一点。告警触发后要有明确的处理流程谁来看、看了之后做什么这些要提前定好。7. 版本迭代和回滚要像呼吸一样自然7.1 AI应用的版本维度比传统应用多传统应用的版本主要是代码版本。AI应用除了代码版本还有提示词版本、模型版本、参数配置版本、评估集版本。这些版本之间有关联关系任何一个变了都可能影响最终效果。如果版本管理混乱出了问题根本说不清楚是哪个版本导致的。我的做法是给每次线上变更打一个组合版本号记录这次变更涉及的代码版本、提示词版本、模型版本、参数配置。这样回滚的时候回滚的是整个组合而不是单独回滚某一个维度。组合版本号可以简单用时间戳加序号也可以用更语义化的命名关键是能唯一标识一次变更。7.2 灰度发布是降低风险的关键手段AI应用的效果波动比传统应用更难预测所以灰度发布尤其重要。新版本先放小流量观察核心指标没有异常再逐步放大。灰度期间要重点看效果指标不能只看技术指标。技术指标正常但效果指标下降的情况很常见如果只看技术指标就全量很容易出事故。灰度的粒度可以按用户、按流量比例、按场景。按场景灰度比较适合AI应用因为不同场景的风险不一样可以先在低风险场景验证再推到高风险场景。灰度期间要有快速回滚的能力发现问题能立即切回旧版本。7.3 回滚不是失败是正常的工程操作有些团队对回滚有心理负担觉得回滚意味着这次迭代失败了。这种心态会导致该回滚的时候犹豫结果问题扩大。实际上回滚是工程成熟度的体现说明你有能力控制风险。AI应用的效果受很多因素影响有些问题在测试环境发现不了只有线上才能暴露。回滚是正常的风险控制手段不应该被污名化。回滚要快最好是一键操作。回滚后要保留现场把出问题的版本和相关的调用记录保存下来事后分析原因。分析清楚了再决定是修复后重新发布还是放弃这个方向。8. 团队协作里那些没人明说但很重要的规矩8.1 提示词变更要有评审哪怕很轻量提示词是AI应用的核心逻辑之一它的变更应该像代码变更一样被review。但很多团队没有这个习惯谁都可以改提示词改完直接上线。这会导致两个问题一是变更质量参差不齐二是出了问题找不到责任人。轻量级的评审就可以不需要很重的流程。比如在群里说一下改了什么、为什么改、评估结果如何有一个人确认一下就行。关键是要有记录、有确认而不是完全靠自觉。8.2 评估集是公共资产不是某个人的私货评估集如果只掌握在一个人手里其他人不知道里面有什么、不知道怎么用那它就发挥不了应有的作用。评估集应该是团队公共资产谁都可以跑、谁都可以补充样本、谁都可以看结果。当然补充样本要有一定的审核避免引入低质量样本影响评估准确性。我见过比较好的做法是评估集放在代码仓库里跟代码一起版本管理。每次补充样本走正常的代码提交流程有人review。跑评估的脚本也放在仓库里任何人可以一键执行。这样评估就变成了团队共同维护的基础设施而不是某个人的负担。8.3 线上问题的复盘要聚焦机制不聚焦个人AI应用出线上问题很正常复盘的时候要聚焦机制层面的改进而不是追究个人责任。比如输出校验失败导致下游报错复盘的重点应该是为什么校验规则没覆盖这种情况、为什么告警没提前发现、为什么回滚不够快。而不是“谁写的代码出了问题”。聚焦机制的好处是每次问题都能转化为系统能力的提升。校验规则补上了、告警加上了、回滚流程优化了下次同类问题就不会再造成同样大的影响。如果聚焦个人大家会倾向于隐瞒问题反而让系统更脆弱。9. 我踩过的几个印象深刻的坑第一个坑是提示词里写死了模型名称。当时觉得反正就用这个模型写死省事。后来想换模型对比效果发现要改的地方散落在各处漏改了一处导致线上行为不一致。教训是模型名称、版本、参数这些都应该作为配置项跟提示词内容分开管理。第二个坑是评估集长期不更新。上线初期建的评估集用了大半年没动过。后来发现评估集里的样本跟线上真实分布已经差很远了评估结果好看但线上效果不行。教训是评估集要定期补充线上badcase保持跟真实分布同步。第三个坑是缓存没有失效机制。做了精确缓存之后命中率很高成本降了不少。但有一次更新了提示词缓存里的旧结果还在返回导致新提示词的效果被旧缓存掩盖了。教训是缓存要跟版本关联版本变了缓存要失效。第四个坑是日志记录太粗。只记了请求时间和耗时没记输入输出内容。出问题的时候完全不知道当时模型收到了什么、返回了什么排查无从下手。教训是关键调用要记录完整上下文但要注意脱敏和存储成本。第五个坑是灰度期间只看技术指标。有一次灰度新版本响应时间和错误率都正常就全量了。结果全量后用户反馈回答质量下降。回头看灰度期间的效果指标其实已经有下降趋势只是没关注。教训是灰度期间效果指标和技术指标要一起看。10. 这套治理思路的边界和适用性需要说明的是上面聊的这些不是放之四海而皆准的模板。不同团队、不同业务场景、不同规模需要的治理力度是不一样的。一个内部工具类的AI应用可能不需要那么严格的版本管理和灰度流程一个面向海量用户的核心功能治理就必须做扎实。我的建议是先识别你的AI应用属于哪种风险等级。如果出错的影响可控、用户可以容忍一定的波动那治理可以轻一些优先保证迭代速度。如果出错的影响很大、用户对质量很敏感那治理就必须跟上宁可慢一点也要稳。另外治理机制本身也是有成本的。版本管理、评估集维护、日志记录、灰度流程这些都需要投入人力和时间。如果业务规模还没到那个程度过度治理反而会拖累迭代。找到适合当前阶段的平衡点比照搬一套完美方案更重要。我自己的经验是治理机制应该随着业务规模的增长逐步加码而不是一开始就搞得很重。先解决最痛的问题比如提示词版本管理、输出校验、基础日志这些投入产出比最高。等业务量上来了再补评估体系、灰度流程、成本优化。一步一步来比一步到位更现实。