1. 这轮AI工程实践的三个关键转向打开工作日志翻到一个备注为“AI 相关 20260827”的文件夹里面塞满了这几个月做模型部署、Agent系统、AI测试和一堆场景落地的零散记录。趁着项目告一段落我把这些材料重新捋了一遍发现很多当初觉得“只是某个项目里的小决定”其实背后都指向同一个大趋势AI工程实践正在从“把模型调通”转向“把系统做稳”。这篇文章不是教科书式的原理讲解而是我结合实际项目踩过的坑、改过的方案、验证过的路径整理出来的一份可复用的实操笔记。这套内容适合几类人正在做AI应用开发的工程师想搞清楚Agent系统怎么落地的技术负责人被老板要求“把AI用起来”的产品经理以及负责模型效果评估的测试同学。我会尽量少讲虚的多给能直接参考的判断标准、配置思路和踩坑记录。1.1 任务完成率比模型精度更值得盯以前评估一个模型好不好大家习惯看准确率、召回率、BLEU分数这类指标。但在实际业务系统里这些指标经常“看着很高、用起来很废”。举个我实际遇到的例子。做一个AI客服工单分类功能用测试集跑分类准确率能到96%。这个数字很好看但上线后真实用户的问题根本不会像测试集那么规整。用户会夹杂口语、表情、错别字还会一句话里包含两个意图。最后我又加了真实工单回流的数据做评测把“用户问题能否被完整解决”作为核心指标也就是任务完成率。这个指标不看模型某一轮答得好不好而是看从用户发起问题到问题被判定关闭整个会话有没有真正走到目标状态。建议每个AI项目都定义一个“任务完成率”的评测口径。比如AI客服用户问题是否被解决且用户没有转人工投诉内容生成生成内容是否通过格式校验、事实校验、业务规则校验Agent系统多步骤任务是否在限定步数内成功执行完代码辅助生成的代码能否通过编译和单元测试把任务完成率放在模型指标前面团队的目标感会清晰很多。你优化的所有技术选型、提示词、部署方案都是服务于“任务能不能跑通”而不是“分数能不能刷高”。1.2 单模型调用正在让位给Agent工作流二季度我做的几个项目明显感到架构设计变了。以前是一个请求进来调用一次大模型接口拿到结果就返回。现在很多AI功能天然需要多轮思考、多步操作比如“分析这份文档并生成摘要再把摘要翻译成英文发到指定邮箱”它不是一个Prompt能搞定的。我拆过的一个典型Agent工作流整体上分四个环节意图识别和任务拆解上下文检索与信息收集调用外部工具或API执行动作对执行结果做验证和修正用伪代码表示大概是这样def run_agent(user_task): plan planner.plan(user_task) final_result [] for step in plan: context retriever.search(step.query) action_result tool_executor.execute(step.action, context) verified validator.check(action_result) if not verified: action_result repair(step, action_result) final_result.append(action_result) return final_result这个架构本身不复杂复杂的是每一步都可能出错。计划拆错、工具调用失败、检索结果不相关、验证误判任何一个环节出问题最终任务完成率都会崩。所以工程重心从“调一个模型”变成了“编排多个环节并保证整体稳定”。这部分后面我会单独展开讲。1.3 成本、延迟和可观测性决定一个AI功能能否上线很多AI项目死掉不是模型效果不行而是成本和延迟算不过账。我之前做一个面向C端的生成式功能模型用的是较大参数量版本单次生成平均耗时4秒单次成本约0.08元。听起来不多但如果每天有10万次调用一天就是8000元一个月就是24万元。产品客单价撑不住这个成本最后只能降模型规格、加缓存、做结果复用把单次成本压到0.02元以内才敢上线。我整理了一张选型时要同步算清楚的账指标上线前要回答的问题我常用的判断标准单次调用延迟用户能等多久普通读写类功能最好在1秒内生成类功能可放宽到5到10秒但要给进度反馈单次调用成本业务毛利能不能覆盖按DAU、日调用量、付费转化率倒推成本占比超毛利30%就要优化并发支撑能力峰值流量来了扛不扛得住至少预留3倍日常峰值容量并做好排队和降级效果可观测性出了问题能不能快速定位必须记录输入输出、token消耗、错误类型、耗时分布可观测性是最容易被忽略的。不少团队上线时连日志都没接全线上模型飘了都不知道是Prompt变化引起的、还是模型服务降级了、还是数据源变更了。我现在做任何AI功能第一个想的就是这个功能上线后我怎么知道它正在变好还是变坏没有全链路日志和监控AI功能就是一个黑盒出了问题只能靠用户骂。2. 大模型部署选型本地推理与托管API的算力账大模型部署是个老问题但每次做新项目都要重新算一遍。没有绝对的最优方案只有特定业务场景下的合适方案。这个季度我同时推进了两个项目一个偏内部工具对数据隐私要求高一个偏面向C端的轻量应用对响应速度和成本更敏感。两个项目最终选了完全不同的部署路线。2.1 先定一个可复现的评测基准在选部署方案之前一定先建评测集。没有评测集你根本没法对比不同模型、不同量化级别、不同推理框架的效果差异。我建评测集的经验是三条从真实业务场景里抽数据不要拿网上公开数据集硬套每条评测样本都要有可验证的“标准答案”或“通过标准”评测集要包含边界情况比如超长输入、多轮对话、错误格式输入一个可以落地的做法是把评测集做成JSON文件用脚本自动跑分{ task: 客服工单分类, cases: [ { input: 我上周买的商品到现在还没发货想退单, expected: 订单取消, difficulty: normal }, { input: 收到货了但少了一个零件麻烦补寄另外发票抬头要改一下, expected: 补寄发票修改双意图, difficulty: hard } ] }评测脚本思路批量调用模型接口对返回结果做规则校验或大模型打分输出通过率。有了这个基线后面无论换模型、换部署还是调Prompt都能看到明确的效果变化数字。2.2 托管API适合的场景与成本模型先说托管API就是直接调用大模型服务商提供的接口。它最大的优势是省心不用买显卡、不用维护推理服务、不用处理扩容效果通常也是厂商调好的最优状态。我判断业务要不要用托管API主要看三点数据敏感度数据能不能出内外网边界调用量稳定性调用量忽高忽低时托管API按量付费更灵活团队运维能力小团队没有专门的人维护推理服务托管是更好的选择不过托管API也有明显的坑。一是单次调用成本在规模上来后不一定便宜二是服务商版本更新后行为可能变化三是长文本、高并发场景下延迟波动明显。三季度我做过一个对比测试同样的任务托管API的P99延迟是1.8秒自托管优化后能压到0.9秒。如果业务对延迟敏感这个差距要提前评估。2.3 自托管推理vLLM与网关层的关键细节自托管推理我重点说两个工具vLLM做推理加速网关层做流量治理。vLLM让我最满意的功能是Continuous Batching连续批处理和Prefix Caching前缀缓存。连续批处理可以把多个请求动态拼到一个批次里推理吞吐量比普通方案高很多。前缀缓存适合“所有请求共享一段系统提示词”的场景系统提示词的计算结果被缓存后续请求就能跳过这段计算首字延迟明显下降。部署时几个重要参数--max-model-len控制最大输入长度太长会爆显存--gpu-memory-utilization设置显存利用率通常0.85到0.9比较稳--quantization量化方式我用AWQ比较多--enable-prefix-caching开前缀缓存长系统提示词场景建议开网关层我通常用一套轻量代理来做核心功能是限流、超时、重试和降级。自托管推理不是永远稳定的显卡故障、OOM、模型加载异常都可能发生。网关必须能快速把流量切到备用模型或托管API不能让下游业务直接挂掉。自托管省的是单次调用费花的是运维精力和显卡钱。小团队如果一个月调用量不到百万次算下来可能并不划算。我现在的判断原则是验证期用托管API规模上来后再考虑自托管两个方案在架构上做成可切换不要把路走死。2.4 Spring AI在Java生态里的接入经验团队里大部分后端是Java技术栈所以Spring AI我们认真试了一圈。它的价值在于把“对接大模型”这件事抽象成了统一接口换模型厂商时不用改业务代码只改配置。用Spring AI接一个聊天补全功能大致是RestController public class ChatController { private final ChatClient chatClient; public ChatController(ChatClient.Builder builder) { this.chatClient builder.build(); } PostMapping(/chat) public String chat(RequestBody String message) { return chatClient.prompt() .system(你是一个严谨的技术文档助手回答要简洁、准确。) .user(message) .call() .content(); } }用下来体验好的地方是它对PromptTemplate、输出解析器的支持比较完整项目中常见的几个问题都能直接解决想把输出结果转成Java对象有内置的BeanOutputConverter想给模型补充企业知识库内容有向量数据库的抽象想记录每次调用的token消耗可以用Audit API或自行拦截需要提醒的是Spring AI版本迭代很快有些API变动比较大。我踩过的一个坑是升级小版本后原来的某些配置项被弃用了导致启动报错。所以接生产环境前一定要锁定版本并写好回归用例。3. Agent系统开发边界设计比提示词更棘手演进到Agent系统阶段难度完全不一样了。单模型调用做的是“输入到输出”的映射Agent则是在一个开放环境里自主执行一系列动作。它最容易翻车的地方反而不是大模型不够聪明而是边界没有划清楚。3.1 自动化工单Agent的实际拆解我做过一个自动化工单分类和处理建议的Agent核心模块五个任务解析器识别工单类型、紧急程度、客户意图知识检索器从工单知识库、历史工单、产品文档里检索相关信息处理建议生成器基于检索结果生成处理方案工具调用器调用内部系统API完成查单、改单、通知等操作结果验证器检查工具执行结果是否符合预期不符合则触发修正这五个模块串起来就是一个有记忆、有工具、有反馈的Agent。但真正让它稳定运行的不是每个模块的Prompt写得有多华丽而是模块之间的接口设计。比如任务解析器输出的JSON结构必须稳定否则后面的检索器根本不知道要去查什么。任务解析器的输出格式我一般这样约束{ intent: order_cancel, urgency: high, entities: { order_id: 202608270001, reason: 发货太慢 }, requires_human: false }把中间结构固定下来比让Agent自由发挥要稳得多。3.2 工具权限与可信执行的隔离Agent能调用工具就意味着它能直接影响真实系统。权限设计如果不到位一个Bug可能就变成事故。我常用的几道隔离措施工具最小权限Agent能访问的API和数据范围必须小于等于操作员权限高危操作人工确认删除、退款、发消息、改配置这类操作Agent只能生成建议不能直接执行执行沙箱化代码生成类Agent生成的代码在沙箱里运行不直接上生产全量操作留痕每次工具调用都要记录参数、返回结果和触发原因最让我印象深刻的是一次事故。测试环境里让Agent自动处理工单它把一个普通咨询工单错误地识别为“取消订单”然后真的调了取消订单的API。虽然测试环境没造成真实损失但让我们意识到只要Agent能自动调用写操作就一定会出错。后来统一改成“只建议、不执行”上线跑了一个月零事故。3.3 多Agent协作的收敛与逃生舱单Agent做不了一些复杂业务就需要引入多Agent协作。比如一个Agent写初稿一个Agent审稿一个Agent做合规检查。很多人一听多Agent就激动实际做起来会发现最大的问题是Agent之间互相等、互相改任务永远结束不了。解决收敛问题我用了三个手段给任务加轮次上限超过指定轮数就强制进入结果汇总给每个Agent定义明确的输入输出格式不允许跨级传递中间结果设“裁判Agent”或规则引擎在两个Agent结论冲突时做最终裁决还有逃生舱任何Agent链路都必须支持人工接管。用户等得不耐烦、任务进入死循环、模型输出明显有问题时系统要能自动降级到人工处理或者简单规则处理。这个逃生舱往往是项目能不能落地的最关键因素比多Agent多么智能更重要。4. AI编程与AI测试研发流程里的真实变化AI编程是很多团队落地效率提升最快的一个点。但如果你以为“有了AI写代码程序员就没事了”那说明还没真正把它用到生产级项目里。4.1 把提示词当代码维护用AI写代码提示词的质量直接决定产出质量。但提示词不是写一次就完了它要跟着项目演进持续迭代。我习惯把常用提示词放在一个文件里统一维护比如.ai/prompts/code-review.md、.ai/prompts/refactor.md。一个实用的代码生成提示词模板你是这个项目的资深开发者。 项目技术栈Spring Boot 3 MyBatis Plus MySQL 代码风格Controller薄、Service承载业务逻辑、Mapper只做数据库操作 任务为下面的需求编写Service层实现。 需求{需求描述} 约束 1. 必须处理参数为空的情况 2. 必须使用已有的Result类包装返回 3. 不许引入新的第三方依赖 4. 输出完整代码不要省略关键不是把Prompt写得多么复杂而是把上下文约束到位技术栈、代码风格、任务边界、输出要求。这样生成代码直接可用的概率才会高。4.2 Code Review的人机分工AI辅助Code Review我已经用了很长一段时间。它的定位是“抓低级问题”不是“评审架构设计”。提交代码前先在本地过一遍AI检查大概能提前拦截这些问题明显的空指针风险日志打点缺失异常处理过于粗糙事务使用不当SQL查询缺少索引提示我现在的代码审查流程是AI先过一遍基础检查开发人员针对检查结果逐条确认然后人工Reviewer重点看业务逻辑和设计意图。AI帮人省掉机械劳动人集中精力做价值判断。这个分工明确之后评审效率和评审质量都上来了。不过也要提醒AI Review有较强的“建议倾向”有时候会因为过度追求规范而忽略业务场景。比如为了消除警告它会建议改掉一些“看着不规范但实际是合理Trade-off”的写法。最终决策一定得是人来做不能无脑采纳AI意见。4.3 AI测试工程师的新职责数据、效果、回归AI项目里的测试工程师工作内容和传统功能测试差异很大。传统测试验证的是“逻辑对不对”AI测试验证的是“效果稳不稳”。我带过的AI测试方向至少包含这样几块评测集建设与标注模型输出正确性和安全性的回归Prompt变更后的效果对比推理服务的压测与性能回归线上数据回流后的效果监控其中回归测试是最容易被忽视的。模型服务升级后效果可能变化Prompt略微调整后可能引出新问题这些都要靠自动化的回归评测来兜底。我建立的AI回归测试流程是每天早上自动跑一遍评测集输出一份效果报告包括任务完成率、平均延迟、失败样例分布。如果任务完成率比前一天下降超过2%系统会自动标记风险通知到相关开发。这个机制帮我提前拦截了多次潜在回归。5. 应用场景落地观察电商、视频、短剧、专利除了技术组件这段时间我也花了不少精力看AI在具体业务场景里的落地。很多团队问“AI还能做什么”其实与其追着热点跑不如把已有业务流程翻一遍找出“重复劳动密集、判断规则相对明确、出错容忍度适中”的环节。这些环节最适合先上AI。5.1 AI电商素材、导购、客服、数据分析的推进顺序AI电商不是一个单点功能而是一条完整的数字化链路。我梳理过一条推进路径按投入产出比从高到低排序商品素材生成商品图背景替换、卖点文案批量生成智能导购基于用户画像和浏览行为推荐商品智能客服订单查询、退换货、物流问题自动处理数据分析评论情感分析、竞品价格监控、趋势预测我的建议是先从素材生成入手。原因很简单这类任务即使效果一般人工还能二次修改容错空间大而且素材需求量巨大每天都有ROI很容易测算。做智能导购和智能客服时要注意这两类功能直接面向消费者用户对错误容忍度非常低。我建议初期以“辅助人工”的方式上线AI生成推荐理由或回答草稿人工确认后发送积累足够的信心再逐步提高自动化比例。5.2 AI绘画与视频生成的工作流步骤AI绘画和AI视频工具已经进入了工作流阶段。纯靠一句话生成成品仍然不现实成熟做法是把生成环节拆开每个环节选择合适的工具人工在关键节点干预和修正。我常用的一个视觉内容工作流需求拆解明确主体、风格、构图、氛围、画幅文生图生成底稿用提示词描述画面主体局部重绘做修正改细节、换背景、调节构图图片转视频让静态画面动起来后期剪辑和调色在传统剪辑软件里完成核心经验是不要指望一次生成。在单次生成中你的提示词越“结构化”越好。比如主体一位身着工装的产品经理站在白板前 动作正在用记号笔补充流程图 环境现代办公室自然光 风格写实产品摄影浅景深 画幅16:9这样生成的内容可控性强后续修图成本低。如果直接写“一个产品经理开会”生成结果基本不可用纯粹浪费时间。5.3 AI短剧生产管线里的人机分工AI短剧是这段时间关注度很高的方向它的生产流程比想象中更接近工业化流水线而不是“输入一句话自动生成一集剧”。我看到的成熟管线大致是剧本创作AI辅助生成大纲、场景、台词分镜设计AI生成分镜脚本和画面参考图像生成批量生成角色和场景图动态化用图片转视频让画面动起来配音和配乐TTS配音、AI生成背景音乐剪辑合成在剪辑软件里完成成片这个流程里“人”的作用仍然很大尤其是剧本的叙事结构和分镜的逻辑连贯性。AI可以高效地生成素材和草稿但最后的故事能不能立住还是要靠人来把控。为了控制角色一致性我会把所有角色图单独整理成一个素材库并在生成其他画面时引用角色参考图。这样能有效降低AI生成时角色长相漂移的问题。这个细节可以说是AI短剧制品质量的分水岭。5.4 AI辅助专利文档起草被低估的专业场景知识产权领域AI辅助比大多数人想得更实用。专利文档写作有一个特点它有高度标准化的结构和范式语言但又需要大量的背景技术调研、实施例扩充和权利要求表述打磨。这些恰恰都是生成式AI擅长的事情。我辅助一个技术团队处理材料类文档时的流程用AI列出技术交底书提纲和历史文献检索建议描述技术点后生成多版权利要求表述备选生成实施例的多种变体描述丰富说明书内容检查逻辑矛盾点和用语不一致AI在这里不是一个“自动写专利”的工具而是一个“提高撰写效率”的助手。它能帮起草者快速扩展思路、补充表述角度、保持术语统一。但专利申请人命关天的事情必须由专业代理师把关。我不会主张用AI替代任何专业判断。对于知识产权创作者来说AI辅助的正确用法是用AI把素材铺开让人来筛选和判断。这与广告文案、技术文档、市场材料的用法都是一致的。6. AI产品经理的能力变化与一点个人体会随着AI从Demo走向生产AI产品经理的工作方式也必须跟着变。只会画原型、提需求的时代过去了现在的AI产品经理得像半个工程师得知道效果边界在哪、成本瓶颈在哪、数据回流怎么设计。6.1 定场景边界明确的小闭环优先很多团队做AI产品失败根源在于选了边界过大的场景。一上来就要“AI客服解决所有问题”结果需求发散、效果评测无从下手、上线后被用户一句话就问倒了。我的经验是选“小切口、闭环完整”的场景。比如限定在“订单状态查询”这一类意图上做AI客服限定在“商品主图背景替换”这一种操作上做视频素材工具限定在“技术文档翻译并统一术语”这一条流程上做文档工具场景边界越小评测集越好建、效果越好验证、用户预期也越好管理。先在小闭环里做出稳定效果再逐步扩展意图范围。这个节奏要比一上来铺大摊子稳健得多。6.2 PRD到上线效果指标与迭代节奏AI产品经理写PRD跟传统PRD有一个明显差异你没法在PRD里写死每一个具体输出你需要写的是“评测标准和可接受的容错范围”。我常用的一个AI功能PRD骨架功能目标说明解决什么业务问题场景边界明确哪些输入是支持的、哪些明确不处理输入输出定义定义接口的输入字段和输出结构效果指标任务完成率目标、响应时间目标、成本上限失败处理超出边界时的兜底方案评测计划评测集来源、评测方式、上线前标准上线之后最重要的是建立数据回流闭环。用户输入、模型输出、最终结果、用户反馈都要记录。这些数据每个月回流到评测集里模型才能越迭代越贴合真实场景。6.3 我踩过的坑和给同样在做AI项目的人几条建议最后说几个我自己反复踩过、后来终于长记性的坑第一不要跳过评测集直接调Prompt。没有评测集你根本分不清效果提升是“改对了”还是“运气好”。我见过团队花了三个星期调Prompt最后发现效果波动只是因为换了模型版本。第二不要一开始就追求大模型“一步到位”。很多时候小模型加规则引擎加检索流程效果比大模型单独硬扛更好成本还低得多。先用最便宜的方案跑通再根据瓶颈决定要不要更重的方案。第三不要忽略人工兜底。AI功能的用户体验要想清楚模型不确定的时候怎么办用户不满意的时候怎么转人工一个设计良好的兜底流程往往比模型本身更能决定用户满意度。第四把成本当成产品功能来设计。AI项目的成本会随着用户增长线性上升如果你没有缓存、没有降级、没有用量控制业务增长越快公司虧損越快。这些经验是我在这个项目周期里最想留下来的部分。AI技术迭代太快具体工具不断被替代但“先定好评测再看效果、先划好边界再上系统、先做兜底再谈智能”这套思路放在什么时候都不过时。下次再接到一个“用AI做点什么”的需求我建议你先别急着选模型、写Prompt先把场景边界、评测集、成本上限、兜底流程这四件事定了。这四件事定清楚了项目就已经成功一半了。