前面十五篇把零件讲完了模型怎么调、提示词怎么分层、RAG 怎么建、工具怎么挂、trace 和评测怎么做。写到第十六篇我收到的问题反而最不像技术问题——“我这套跑了五六年的系统到底该从哪一层开始加 AI”这类问题通常被回答成两份东西一份能力清单能做问答、能做摘要、能做工单归类一张架构图。两份都没错但都没回答提问人的真实处境——他的排期、他动不了的核心域、他要背的事故责任。更麻烦的是没人说上到哪算完。我见过把内部知识库抠到第九十九分、却答不出它为什么慢、一次提问烧了多少的团队也见过第一周就把 Agent、MCP、多模型路由全上第三周因为一次误改数据被业务方叫停的团队。两批人做的都是对的事只是顺序和止步点不对。所以这一篇不写代码全篇没有一行接入示例全系列以 2.0.1 为基线具体写法看对应篇目。只回答三件事从哪一层开始叠最划算、每层叠完必须拿到哪个数字、什么时候该停。1. 先纠正一个问法不是要不要上 AI是上到哪一层就停来问路线图的团队问题基本都问反了。我们这套系统适不适合加 AI这个问题没有答案因为加 AI不是一个动作它至少是四个动作成本、风险、收益各差一个量级。能拿去开会的问法是另一句这次叠到哪一层以及这一层的验收指标是什么。L4 工程化 观测与成本归因 / 评估集门禁 / 安全边界 / 对话式 UX / 跨团队复用 ^^^^ 有真实用户之后的一期还款 L3 能办事 工具调用 / MCP / Agent 模式只读半区 → 写半区 ^^^^ 风险跃迁点模型开始代表用户写数据 L2 数据可检索 文档盘点 / ETL / 向量库 / 检索与重排 / 引用可追溯 ^^^^ 上限由文档质量决定不由模型决定 L1 能力接入 模型调用 / 结构化输出 / 流式 / 提示词分层 / Advisor 链 ^^^^ 一周能跑通也最容易被高估四层有三个性质决定了路线图能不能画性质说法后果顺序固定上层踩在下层上没有 L1 的调用与结构化输出L3 的工具循环无从谈起没有 L2 的可检索依据L3 的办事就建在模型记忆里可以跳层不能倒着叠每层可独立验收每层有自己的指标第 25 节各一张表不需要整体成功才算成功停在任何一层都是完整交付不是半成品收益与风险不同向往上每叠一层收益更贴近业务动作出错代价也更靠近真实资产止步层是风险偏好选择不是技术先进程度然后是这一篇唯一想留下的判据把 AI 拿掉 → 流程还能跑只是麻烦一点 AI-Enhanced本篇四层都在这条线以下 把 AI 拿掉 → 流程直接不成立 AI-Native第廿二篇展开本篇只立判据把 AI 拿掉这套流程还能不能跑。这条判据为什么在项目立项时就要立起来选止步层本质是在选我愿意让多少业务流程变成离了 AI 就不成立。这句话不说清半年后它会以另一种形式回来——“这个模块没人敢动”。值不值得上 AI 的三问。我的用法是三问至少两问落在有利这一侧再谈叠几层否则先别动。注意三问不是等权——错误成本是一票否决项它落在不利侧L3 写半区直接放弃另外两问决定的是叠多高错误成本决定的是能不能碰写。。一问具体判据有利可以叠不利先别叠错误成本一次答错最坏造成什么有人复审就能兜住客服首答、内部资料检索、工单归类建议直接落到资金或合规且回不去放款、报税、诊疗建议文本 / 非结构化密度业务规则有多少活在文档、工单、聊天记录里而不是在表字段里条款、手册、历史工单占大头规则散在人写的文档中数据全在结构化表里一个 SQL 就表达完整规则能不能穷举入口的分支数量随业务增长有多快分支随字段和场景线性膨胀写不完自然语言入口、多轮补槽、跨系统查询五六个分支写死就够用而且三年不变再补一张表——它其实是判据的分层版本也是停在 L 几的成本对照在哪一层拿掉 AI流程还剩什么结论L1原来的表单和接口照常跑只是少了一个会写字段、会答话的入口典型 AI-EnhancedL2还剩一个能全文检索的文档库人工查完再回答AI-EnhancedL3 只读半区客服和运维回到后台手工点页面慢但可控AI-Enhanced且是多数团队最划算的位置L3 写半区入口只有自然语言意图路由、多轮补槽本身就是 AI 提供的人接不住这条路径开始滑向 AI-Native债务要按第廿二篇算Q1四层必须按顺序叠还是可以跳层可以跳不能倒着跳。存量系统最常见的跳法是 L1 直接接 L3 只读——不建知识库只把几个查询接口包成工具效果往往比先做 RAG 更快被业务方认可。反过来不行在没有 L2 依据、也没有评测集的情况下开写操作等于让模型凭常识去改数据。注意跳层是实现顺序上的跳不是验收顺序上的跳——你可以先做 L3 只读拿业务认可但上线前必须回头补 L2 的评测集否则 L3 的工具选对了没有分母可判。。Q2三问里只有错误成本落在不利侧要不要做可以做 L1 和 L2 的只读部分但 L3 写半区直接放弃。错误成本是唯一不能靠工程手段补的维度延迟能优化幻觉能评测资金损失只能靠不让模型动手来防。我的理解是多数存量系统的正确姿势是顺着叠、跳着做、倒着验——顺序从 L1 起按业务需要直接跳到 L2 或 L3 只读但验收必须逐层补L1 的结构化输出不稳定L2 的检索质量就被模型抖动一起掩盖L2 没有分母L3 的工具选对了根本无从判断。一句话结论路线图不是多久能上完 AI而是在哪一层停下来以及停下来之前那层的数字达标没有。2. L1 能力接入一周能跑通也是被高估最多的一层对应专题第一篇第五篇结构化输出在第七篇前半会话记忆在第六篇。这层几乎所有团队都做出来了问题是把它当成了终点。2.1 这一层给的能力清单能力对应篇目存量系统里的典型用法模型调用与多供应商接入第一篇、第二篇一个ChatClient挂多家通道按环境或成本切换业务代码不感知多模型并存 流式输出第三篇抽取用小模型、生成用大模型长回答改 SSE首字延迟立刻好看起来提示词分层第四篇system / user / template 分开业务方改文案不用发版Advisor 链第五篇日志、脱敏、鉴权、检索都挂在拦截点上不动业务代码会话记忆第六篇严格说它是 L1 与 L3 的接缝多轮补槽没有它就不成立结构化输出第七篇前半稳定拿到 POJO / JSON——这是 L3 工具调用的前置条件2.2 这层的真实成本不在 SDK 上Demo 里挂个依赖半小时生产里这五件事才是账单隐性成本具体问题谁兜住对应篇目超时与重试模型 2 秒返回和 40 秒返回是同一种结果网关、线程池、SSE 三层超时值不一样重试还可能重复扣费超时预算显式写进配置只重试幂等调用退避 调用次数上限第三篇、第八篇痛点 6幂等帮我改一下备注这类请求重放一次就是两条数据或一次重复扣款请求级幂等键业务键不是 trace id写请求一律带第八篇成本核算框架给的只有模型与调用维度的 Token 指标没有成本这个指标单价是你自己的事每次调用把 token / 耗时 / 归因维度写进自己的表别只看厂商控制台第十三篇供应商替换换一家模型参数名不同、temperature 语义不同、思考链字段不同结构化输出失败率会先跳一下抽象层收敛差异替换演练当成验收项一次全链路跑通再上线第二篇、第七篇失败语义模型没答上来和服务挂了在监控里必须可区分否则告警全是噪声拒答 / 空结果 / 异常三条路径分别打点第十三篇2.3 L1 的独立验收指标不做上层也该交这三个数指标怎么取数建议门槛不达标先查什么结构化输出合格率不加人工修补即可反序列化成目标类型的比例稳定在一个高位我项目里的量级是从看着挺像 JSON起步补到九成以上才算能进生产经验值非官方指标schema 是否要求了模型给不出的字段失败后有没有一次带错误的重试P99 延迟 / 首字节端到端计时流式单独看首字节分档定同步接口和流式对话不是一个标准是不是偷偷多了一轮工具往返重试有没有计入用户等待单请求 Token 量级已落库的 usage 汇总按功能维度看趋势不追求绝对值只要求能按功能拆绝对值和单价、模型强相关上下文塞了什么记忆窗口、检索片段、错误重试各占多少供应商替换演练换一家跑一遍既有场景能跑通差异被抽象层吃掉哪些参数写死在业务代码里Q1L1 做到什么程度算完可以往下走三条同时满足结构化输出合格率稳定单请求成本有数注意是已落库不是我能去控制台看供应商替换演练过一次。缺第三条就往下叠等于把选型风险推迟到 L3——那时候要改的是工具契约不是换个 base-url。2.4 说清楚只做 L1 的团队多数不需要第 3、4 层L3 / L4这一条是我自己想跟同行说的。只做 L1 完全可以是终态而不是过渡态前提是你的判断落在这三条上价值来自把非结构化文本压成字段摘要、归类、抽取、改写不需要模型自己决定下一步做什么一次调用能出结果就别引入循环。一次调用的延迟、成本、失败面都是可预估的工具循环三项全部要乘轮次写操作收益说不清或者被合规卡在流程里——那停在 L1 比停在 L3 写半区体面得多。笔者后端 架构的用法是L1 L2 只读是我给自己团队的默认终态候选要不要往 L3 走永远由当前这一层的数字达标了没决定而不是由汇报需求决定。3. L2 数据可检索上限是文档质量不是模型能力对应第十篇第十二篇RAG 全链路、客服实战、评测与幻觉防线。条款/工单/手册 -- 清洗与分块 -- 向量化入库 -- 检索 TopK -- 重排 -- 带引用生成 -- 评测集回归 \______ 这一段决定上限 ______/ \______ 这几段只决定上限能被用出来多少 ______/3.1 盘点哪些内容该进知识库哪些不该这一层的坑不是检索算法是什么都往里塞。内容进不进理由替代做法政策条款、退改规则、SLA 说明进有版本、可引用、变更低频是 L2 的本金按条款粒度切metadata 留生效区间与来源操作手册、排障 SOP、历史工单结论进非结构化密度高规则穷举不动第 1 节第三问工单要先去重、把结论归并成一条再入库含凭证、密钥、内网地址的配置与文档绝不进入库即出网检索命中就是一条泄漏路径注释掉、加权限都救不回来先做脱敏 ETL位置选择参考第十八篇 6.4PII 出网高频变更的运营数据价格、库存、航班动态不进向量库重建永远慢于业务变更答一份旧数据比不答更糟结构化接口 L3 工具。第十一篇里条款走向量库、订单走工具就是按这条分的只存在于口头和群聊里的规则暂时进不去它没有真值来源写下来就变成某人以为的规则评测无法判对错让业务方先签一份必须答对清单再入库第二十篇的题源之一有版权或授权边界的外部资料看合同入库和出网是两件事都要单独确认与供应商授权范围一并核别在上线前一天问法务3.2 L2 的独立验收指标指标怎么取数建议门槛笔者经验值非官方指标不达标先查什么检索命中率 RecallK用带expectedDocIds的小集合看 TopK 是否含期望片段看环比相对上一次变更不掉两个点以上。绝对值没有可比性各家文档质量差一个量级很正常ETL 分块与 metadata不是模型引用可追溯率回答里的关键结论能否指回一条本次真正检索到的片段涉钱、涉时限的回答要求 100%其余看趋势上下文里到底放了什么第十三篇的 trace三类事实错误发生率第十二篇的分类有据不读 / 无中生有 / 张冠李戴门槛只有一个从偶尔会错变成有编号、有分母分别对应中间段丢失、空结果没拒答、噪声召回缺重排空结果行为检索为空时是否拒答必须拒答不能凭常识补检索阈值与拒答提示词3.3 没有评测集的 L2 等于裸奔这层最反直觉的一点做完知识库不等于有了质量只是有了可查询性。把分块从 800 调到 300、TopK 从 4 调到 20、加不加 rerank、换 embedding 模型——没有评测集的时候这些全是玄学改完只能说看起来准了。真实退化通常是两周后从工单和账单里发现的而 diff 里那句参数改动已经没人记得。所以 L2 的验收必须带一份能重跑的题集第十二篇给了评测流水线第二十篇把它变成 PR 门禁。这份东西不需要大——笔者项目里的量级是从几十条起步每条都能指名道姓说明它防哪类退化比几百条来路不明的题有用。Q1能不能不做 L2直接把文档塞进 prompt能而且文档量小的时候这样更好——少一层检索就少一类失败模式。真正的分界不在条数在两个问题一是上下文预算全塞进去会让成本随文档规模线性上涨第 2 节那笔账二是该找哪一段的责任被推给模型注意力长上下文中间段丢失会开始吃掉准确率。只要这两条还没痛就别为了架构好看建向量库。Q2L2 什么时候算撞到天花板当你发现答错的原因不是没检索到而是文档自己就矛盾 / 压根没写过。那是内容治理问题再叠 L3、L4 都不解决它只会被模型编得更像真的。此时正确的动作是回到 3.1 那张盘点表让业务方补文档或改口径。4. L3 能办事从答话到动手是风险跃迁点不是能力升级对应第七、八、九篇结构化输出、Tools / function-call、MCP 第十四、十五篇Agent 五种模式与 Agent Utils 工具箱。L3 只读半区 查订单 / 读条款 / 查状态 -- 出错代价 一次难看的答案可回滚 ---------------------------------------------------------------这条线不是能力线是责任线 L3 写半区 改签 / 退款 / 建工单 / 批量运维 -- 出错代价 真实资损与合规责任4.1 为什么说是跃迁而不是升级三件事同时断裂所以它不能靠再多做一点工程顺过去责任主体变了。一次工具调用链里选哪个工具、参数填什么由模型当场决定。第八篇 7 大痛点里的第 3、4、7 条强行适配参数、接口名不业务化、权限控制说的都是同一件事优化目标是完成请求的模型不会主动如实报告信息不足。失败形态变了。L1/L2 的失败是难看的答案L3 的失败是不该发生的状态变更而且往往不回滚就没人发现——用户不会投诉一次他没要求的改签。权限路径变了。模型代表用户执行身份必须从服务端透传而不是从模型参数里取第十八篇整篇在处理这件事凭证不能进模型视野异常堆栈不能原样回灌给模型。4.2 该不该开放写操作四级分级表级别例子前置条件缺一不许开确认形态错了谁兜只读查询查订单、读条款、查航班状态声明期工具白名单 执行期按用户过滤 归属校验单子是不是他的 异常不外泄无答错是产品问题可容忍低风险写建工单、加备注、设提醒、改偏好上述全部 幂等键 字段白名单模型只能填业务字段不能填 id / 金额 / 状态一次轻确认留可撤销窗口人审 可撤销资金级写改签、退款、赔付、下单上述全部 人工确认确认对象是改动 diff不是要不要执行 金额由服务端算 审计四要素必须人点且确认内容可回放真资损、合规责任批量运维批改签、批量通知、脚本化数据修复建议不要放进模型可达路径走工单审批 确定性任务系统AI 最多生成待执行清单线下流程事故面是乘出来的审计四要素资金级写的最低要求谁发起的真实用户身份不是模型、何时、依据哪些资料那一轮实际检索到的片段、确认后执行了什么参数。缺任何一条事后都还原不出当时为什么这么做。4.3 L3 的独立验收指标指标定义建议门槛经验值说明工具选择正确率该调对的工具、且不该调时没调只读场景先达标再谈写第八篇痛点 4接口名不业务化与description写法直接决定这条参数幻觉率缺失字段被编造的比例必须趋零靠 schema 给不知道留合法出路 后端二次校验这是写半区最贵的一条越权拦截率归属不符 / 身份缺失的请求被拒比例100%有例外就是洞需要有专门的边界用例来证明第二十篇三类题型里的第二类写操作确认完成率有确认记录的写请求 / 全部写请求100%缺一条就是审计缺口循环调用与成本上限单请求最大模型调用轮次、Token 上限有明确数字且能熔断没有上限的工具循环等于把账单交给模型4.4 多数团队的正确止步点L3 的只读半区说得更直接一点只读半区做完你在业务侧能拿到的价值通常已经超过一半而风险还停留在答案难看这一档。从只读跨到写收益的增长是业务动作数不是体验提升代价的增长是责任与审计——这条曲线不是平滑的。三条止损线任何一条成立就退回只读资金级写的前置条件里你没法凑齐金额由服务端算 人工确认 diff 审计四要素这三件幂等做不出来存量接口本来就不幂等且你改不动它无法构造越权必被拒的测试用例也就是说没有证据说明权限过滤真的生效。Q1Agent 模式第十四、十五篇算不算更高一层不算它还在 L3 里面。五种模式和工具箱只是把一次调用换成多轮、由模型决定下一步能力没跨层但延迟、成本、失败面全部按轮次放大。第十四篇里那句哪些需求根本不该用 Agent其实就是 L3 内部的止步建议。Q2MCP第九篇、第廿一篇是 L3 还是 L4取决于动机。只是想让模型多几个工具写Tool就够那是 L3要让别的团队和别的助手复用同一批存量接口才值得上协议层那是 L4 的复用投入。顺序反过来的常见结果是MCP Server 建好了只有作者自己一个人用。5. L4 工程化不是可选项而是有真实用户之后的一期还款对应第十三篇可观测、监控、Token 成本归因 第十七廿二篇对话式 UX、安全边界、多 Agent、CI 门禁、存量接口 MCP 化、架构取舍。这一层唯一要防的是把它当起点。先有真实用户 / 真实改动再做 L4 -- 每一项都有输入投入产出算得清 先建平台再找场景 -- 每一项都在等一个永远不会来的需求5.1 L4 六件事投入产出表#事对应篇目什么时候必须做什么时候是过度工程晚做的代价1trace 日志 Token 成本落库与归因第十三篇AI 入口超过两三个或者要向上汇报成本只有一个内部入口且量小到一张表格记得过来不可算账账单涨了不知道哪个功能、哪个用户贡献的2评估集与回归第十二篇 → 第二十篇有真实用户且答案会影响用户决策业务规则还在天天改真值不稳题集跟着崩质量退化靠工单发现晚两周到一个季度3把评估挂进 CI 当门禁第二十篇多人协作改 prompt / 参数 / 分块一个人维护且每次改动都自己过一遍我本地试过了变成唯一防线4安全边界与人工确认链路第十八篇只要碰 L3 写半区第一天就要全只读且不涉个人数据仍建议留最小审计不可逆资损、越权、泄漏5对话式 UX补槽、追问、中断、确认第十七篇入口字段多且用户是外部客户或一线操作员用户是内部熟练工——表单永远更快用户流失 误操作返工比首做贵6跨团队复用存量接口 MCP 化第九篇 → 第廿一篇同一批接口有两家以上要做 AI 入口只有一个使用方各团队重复包装五份描述五套漂移另外两件单独说一下**多 Agent 拆分第十九篇**不是 L4 必做项它是 L3 内部的重构判据是上下文预算、权限隔离、独立伸缩三条业务量不到就别拆**架构取舍第廿二篇**不是投入项是止步层选完之后回头算总账的位置。5.2 L4 的验收指标都是过程量这层没有准确率只有能不能被管理指标怎么取数说明成本可归因率能按用户 / 功能 / 租户拆开的 Token 成本占比笔者项目第一版只有总量勉强算清一半量级经验值非官方指标。注意别把 userId 塞成 Prometheus tag基数会打死监控门禁覆盖率命中该跑评估集的 PR 里实际跑过的比例分母要用第二十篇那五类触发条件定义清楚否则永远是 100%写操作确认完成率见 4.3必须 100%它同时是 L3 和 L4 的指标越权与注入用例通过率边界题、干扰题单独统计这一条掉了比整体通过率掉了更该停下来MTTR一次答得不一样从工单到定位根因的耗时没有 trace 和录播只能靠重跑复现那就不叫定位Q1为什么不第一天就把 L4 做完反正迟早要还因为 L4 每一项都需要真实流量或真实改动当输入没有真实提问你不知道评测集该出哪几十道题没有真实账单你不知道成本要归因到哪个维度才有意义没有真实用户操作你设计不出他看得懂的确认文案。第一天做 L4 的结果通常是做了一个没人用的平台 一套没人看的仪表盘还会顺手把团队士气用光。Q2那 L4 什么时候从晚做变成欠债三条信号出现两条就该排期① 有人开始用重跑一次来解释线上异常说明没有 trace② PR 里改 prompt 不需要任何人点头说明没有门禁③ 有用户投诉但你复现不出当时那一轮的上下文说明既没有留痕也没有录播。这三条都不是效率问题是会累积成事故的债。5.3 三个典型过度工程信号第二周就搭多 Agent 编排而 L2 的命中率还没有分母内部日调用量很小却要做全链路 A/B 评测平台——一份进版本库的题集就够第二十篇 3.1把 L4 当售前工程先建平台再找场景平台没有主人半年后交还给运维。一句话结论L4 六件事里成本归因和安全确认这两件的等待成本是不可逆的另外四件晚做只是麻烦不是危险。6. 存量系统的落地顺序与三条不要推荐顺序不是最快出效果而是每一步都能单独止损。第 1 步 L1 L2 只读 一个入口 一份能查的文档 12 个月笔者项目量级 ↓ 不达标就退回 L1 第 2 步 单点 L3 只读 只挂 35 个只读工具不建平台 ↓ 工具选择率不涨就退回 L2 第 3 步 内部灰度 只给客服 / 运维答案不直接对客 ↓ 两周没人用就停 第 4 步 L4 补齐 成本归因 评估门禁 安全边界 ↓ 没有真实用户就不做 第 5 步 才谈写操作与对话式入口步骤做什么为什么排在这验收止损条件做了但没成1L1 打通 L2 只读一个知识域只读、不改写路径出错面最小最容易拿到第一个用户结构化输出合格率 RecallK 环比 引用可追溯文档盘点做不动、没人愿意为口径签字 → 退回纯 L1或改成不依赖知识库的抽取场景2单点 L3 只读几个查询工具把答变成查完再答价值跳一档风险仍在答案层工具选择正确率、参数幻觉率、越权拦截率选择率涨不上去 → 不是模型问题回去改 name / description或减工具数量3内部灰度客服、运维先用拿真实提问喂评测集成本可控错误有人工兜底人工改写率、真实拒答率、单请求成本趋势两周没人主动用 → 停在这里别硬推对外多半是场景选错4L4 补齐归因、门禁、安全有了真实用户三项都有输入钱花得清楚第 5.2 节那五个过程量没有真实用户 / 没有多人协作 → 明确不做写进季度结论5才谈写操作与对话式 UX唯一不可逆的一步必须排在有审计之后确认完成率、审计四要素可回放前置条件凑不齐 → 永久停在第 3 步这不是失败6.1 三条不要不要先重构再上 AI。存量系统里等不到重构窗口而且不需要。L1 的抽象层第二篇、L2 的旁路读取不动写路径、L3 只读包一层查询接口——这三招本来就是为不重构也能叠设计的。判据如果你的第一步是先把某个域拆出来那多半是借 AI 之名做架构审美评审时会被问这跟 AI 有什么关系然后两头都黄。不要一上来全量。L2 的起点是一份文档盘点加几十条评测题不是一次全公司文档大入库。全量入库的三个必然结果噪声拉低命中率然后你去调 rerank 掩盖它、含凭证内容混进向量库、变更范围没人说得清。一个域先跑通比十个域都半死不活有用。不要直接对客户开写操作。次序只能是内部只读 → 内部写带确认→ 对外只读 → 对外写确认 审计 限额。跳步的典型事故不是模型乱写而是模型用对了工具、用错了归属——把 A 用户的单子改到 B 用户名下。这类错误的唯一防线是身份不从模型参数里取 执行期归属校验第八篇痛点 7、第十八篇的权限传递而不是更好的提示词。我见过一个完整的反面案例某团队第一周上了 Agent MCP 多模型路由第二周开放了改签工具第三周模型把 A 用户的订单改到了 B 用户名下——工具选对了、参数填对了但归属校验没做身份从模型参数里取。业务方叫停后整个项目再没人敢提 AI。这个案例的教训不是模型乱写而是用对了工具、用错了归属。。顺手把常见的错误顺序也列出来因为它看起来很合理错误顺序看起来合理的理由三个月后的真实状态先建平台再找场景“统一建设更省”平台没主人场景方各写各的脚本L2 没做就先做对话式 UX“聊天界面最讨领导喜欢”界面很顺但每句话都在编因为脚下没有可检索依据先上多 Agent 再补观测“架构要先进”一次提问十几次模型调用没人能解释哪一步该为账单负责先对客户开写操作拿效果“只读没人用”一次误改数据整个项目被停之后再没人敢提 AIQ如果老板要求下周就要看到 AI 效果怎么办三种能承诺的东西成本完全不同承诺实际成本风险我的建议L1 演示抽取 / 摘要 / 归类一周内能出复用既有接口低不碰线上写路径可以但要说清这是 L1不是AI 化完成内部小范围 RAG 试用一个域 几十条题几周到一个月中主要是文档质量被打脸推荐这个并且把评测题集当交付物一起交对客对话入口L1L2L3 只读UX 全链路高且几乎一定要返工不接受。改成先给内部客服用的同一套东西7. 一张决策总表 自检清单如果这一篇只留一页留这页。7.1 决策总表你的情形建议止步层必做篇目可以跳过立刻止损的信号第一次接 AI做内部客服 / 运维问答L1 L2一、二、三、四、五、七、十、十一、十二九、十四、十五、十七廿一评测题集凑不出来、文档没人签口径 → 退回 L1只做摘要 / 工单归类的批处理无对话L1一、二、四、五、七三流式后置、九十二结构化输出合格率上不去 → 改 schema 和提示词不是换模型有对客入口但只做只读咨询L3 只读半区八、十十三九、十四、十五、十九入口字段不多就跳过十七引用可追溯率上不去 / 越权用例过不了 → 停灰度扩量要让 AI 代表用户改数据改签、退款L3 写半区但先在只读停一季八、十三、十七、十八、二十九、十五、十九、廿一确认链路要人肉兜、幂等做不出来 → 退回只读一批存量接口要给两个以上团队复用L4复用项八、九、第廿一篇十四、十五、十九盘完只能核出 3 个可对外 → 先挂工具别建 Server公司要建AI 平台横向组L4 全套但先有主人九、十三、十七、十八、十九、二十—没人对通过率负责 → 不做先去做一个真场景小团队 内部工具 日调用量很小L1 L2L4 只做成本落库二、四、五、七、十、十二九、十四十九、廿一无这层够用很久强监管域资金、医疗、涉个人敏感信息L2 L3 只读写操作留人工十二、十三、十八、二十十四、十五、十七、十九审计四要素缺任一条 → 不给写要做 AI-Native 新产品不是改造存量本篇不适用只当作分层词汇表—见第廿二篇7.2 开工前自检清单#检查项没过关的表征1能说清本次要叠到哪一层且这一层有验收指标需求写的是上一套 AI 能力2错误成本 / 非结构化密度 / 规则可穷举三问落在有利侧至少两条只有别人都做了这一条理由3模型调用有超时预算、重试策略和调用次数上限Demo 里默认配置直连生产网关4Token 与耗时已落库能按功能维度算账不是登控制台看总量月底只知道这个月贵了5换一家模型的演练做过一次差异被抽象层吃掉参数名和字段语义散在业务代码里6知识库有一份能签口径的内容盘点凭证与高频数据被明确排除一次性把全公司文档推进向量库7有几十条带真值的评测题且带expectedDocIds“我手工问了几个都挺准”8改分块 / TopK / prompt 会触发评估集而不是凭手感这三类改动无人 review9工具分只读与写两级写操作有幂等键所有工具一律挂上去注解里没有任何风险标记10身份从服务端上下文透传不从模型可填参数取用户 id 出现在工具入参里让模型填11资金级写有确认链路 审计四要素只能靠事后从日志里拼当时发生了什么12有明确的不做清单和可对外说的止损线路线图只写要做什么这张表怎么用三条开工前对一遍止步层7.1每层叠完对一遍该层的验收表第 25 节每季度重跑一次 7.2看有没有条目从上季已过关掉回表征出现——L4 的债通常是这么开始累积的。一句话结论本篇的止步层是给 AI-Enhanced 用的如果你的产品定义本身就是没有 AI 就不成立那本篇的止损逻辑不再适用该看第廿二篇。最后总结问法要先改不是要不要上 AI而是这次叠到哪一层这层的数字是什么。四层里每一层都能独立验收也都能独立停下来——停在某一层是交付不是半途而废。判断标准我留在第 1 节那一句把 AI 拿掉这套流程还能不能跑。能跑是 AI-Enhanced本篇四层都在这条线以下不能跑你就已经在做 AI-Native那是另一种债务形态第廿二篇专门算这笔账。多数后端团队的性价比区间是L1 L2 L3 只读半区拿掉这三层里任何一层收益都会明显塌往前一步进写半区收益涨的是业务动作数代价涨的是责任和不可逆性。L4 不是可选项是有真实用户之后的一期还款。早做是在给不存在的需求做工程晚做才是欠债——但其中两件成本归因、写操作确认链路的等待成本不可逆别跟着另外四件一起延后。对后端 / 架构读者我认为最该盯的两件事一是成本核算的落库——框架只给到模型和调用维度的 Token 指标成本这个指标不存在单价和归因维度必须自己写进业务表否则你的 AI 功能永远没有报价能力二是写操作的确认链路——谁确认、确认的是哪份 diff、幂等键存哪、审计四要素齐不齐这条链路决定的是项目能不能活过第一次事故而不是模型好不好。顺序上“不要先重构再上 AI”、“不要一上来全量”、不要直接对客户开写操作这三条我见过的失败基本都能归到其中一条。参考资料 致谢[1] Spring AI Reference2.0.1[2] spring-projects/spring-ai - GitHub[3] [AI工程] Spring AI 第一篇2.0 到底升级了什么从 Prompt、RAG、MCP 到 Agent 应用实战[4] [AI工程] Spring AI 第二篇2.0 快速接入 DeepSeek、阿里百炼与 Ollama[5] [AI工程] Spring AI 第三篇2.0 实战多模型、流式输出与工具调用怎么写[6] [AI工程] Spring AI 第四篇提示词使用与设置技巧2.0[7] [AI工程] Spring AI 第五篇Advisor 对话拦截的使用和自定义 2.0[8] [AI工程] Spring AI 第六篇对话记忆——数据库和 Redis 不同的实现[9] [AI工程] Spring AI 第七篇结构化输出与初代 Tools 实现[10] [AI工程] Spring AI 第八篇Tools / function-call 使用 原理 7 大痛点[11] [AI工程] Spring AI 第九篇MCP 实现、原理、源码读与鉴权[12] [AI工程] Spring AI 第十篇RAG 全链路讲解——从 ETL、Modular RAG 到重排序[13] [AI工程] Spring AI 第十一篇基于航空智能客服的 RAG 实战[14] [AI工程] Spring AI 第十二篇RAG 评测与幻觉防线[15] [AI工程] Spring AI 第十三篇给 AI 应用装上仪表盘[16] [AI工程] Spring AI 第十四篇Agent 五种模式在 2.0 里怎么写[17] [AI工程] Spring AI 第十五篇Spring AI Agent UtilsClaude Code 的那套工具箱被人在 Java 里重写了一遍
[AI工程]Spring AI 第十六篇：存量 Spring 系统的 AI 化路线图,四层从哪层开始叠最划算
前面十五篇把零件讲完了模型怎么调、提示词怎么分层、RAG 怎么建、工具怎么挂、trace 和评测怎么做。写到第十六篇我收到的问题反而最不像技术问题——“我这套跑了五六年的系统到底该从哪一层开始加 AI”这类问题通常被回答成两份东西一份能力清单能做问答、能做摘要、能做工单归类一张架构图。两份都没错但都没回答提问人的真实处境——他的排期、他动不了的核心域、他要背的事故责任。更麻烦的是没人说上到哪算完。我见过把内部知识库抠到第九十九分、却答不出它为什么慢、一次提问烧了多少的团队也见过第一周就把 Agent、MCP、多模型路由全上第三周因为一次误改数据被业务方叫停的团队。两批人做的都是对的事只是顺序和止步点不对。所以这一篇不写代码全篇没有一行接入示例全系列以 2.0.1 为基线具体写法看对应篇目。只回答三件事从哪一层开始叠最划算、每层叠完必须拿到哪个数字、什么时候该停。1. 先纠正一个问法不是要不要上 AI是上到哪一层就停来问路线图的团队问题基本都问反了。我们这套系统适不适合加 AI这个问题没有答案因为加 AI不是一个动作它至少是四个动作成本、风险、收益各差一个量级。能拿去开会的问法是另一句这次叠到哪一层以及这一层的验收指标是什么。L4 工程化 观测与成本归因 / 评估集门禁 / 安全边界 / 对话式 UX / 跨团队复用 ^^^^ 有真实用户之后的一期还款 L3 能办事 工具调用 / MCP / Agent 模式只读半区 → 写半区 ^^^^ 风险跃迁点模型开始代表用户写数据 L2 数据可检索 文档盘点 / ETL / 向量库 / 检索与重排 / 引用可追溯 ^^^^ 上限由文档质量决定不由模型决定 L1 能力接入 模型调用 / 结构化输出 / 流式 / 提示词分层 / Advisor 链 ^^^^ 一周能跑通也最容易被高估四层有三个性质决定了路线图能不能画性质说法后果顺序固定上层踩在下层上没有 L1 的调用与结构化输出L3 的工具循环无从谈起没有 L2 的可检索依据L3 的办事就建在模型记忆里可以跳层不能倒着叠每层可独立验收每层有自己的指标第 25 节各一张表不需要整体成功才算成功停在任何一层都是完整交付不是半成品收益与风险不同向往上每叠一层收益更贴近业务动作出错代价也更靠近真实资产止步层是风险偏好选择不是技术先进程度然后是这一篇唯一想留下的判据把 AI 拿掉 → 流程还能跑只是麻烦一点 AI-Enhanced本篇四层都在这条线以下 把 AI 拿掉 → 流程直接不成立 AI-Native第廿二篇展开本篇只立判据把 AI 拿掉这套流程还能不能跑。这条判据为什么在项目立项时就要立起来选止步层本质是在选我愿意让多少业务流程变成离了 AI 就不成立。这句话不说清半年后它会以另一种形式回来——“这个模块没人敢动”。值不值得上 AI 的三问。我的用法是三问至少两问落在有利这一侧再谈叠几层否则先别动。注意三问不是等权——错误成本是一票否决项它落在不利侧L3 写半区直接放弃另外两问决定的是叠多高错误成本决定的是能不能碰写。。一问具体判据有利可以叠不利先别叠错误成本一次答错最坏造成什么有人复审就能兜住客服首答、内部资料检索、工单归类建议直接落到资金或合规且回不去放款、报税、诊疗建议文本 / 非结构化密度业务规则有多少活在文档、工单、聊天记录里而不是在表字段里条款、手册、历史工单占大头规则散在人写的文档中数据全在结构化表里一个 SQL 就表达完整规则能不能穷举入口的分支数量随业务增长有多快分支随字段和场景线性膨胀写不完自然语言入口、多轮补槽、跨系统查询五六个分支写死就够用而且三年不变再补一张表——它其实是判据的分层版本也是停在 L 几的成本对照在哪一层拿掉 AI流程还剩什么结论L1原来的表单和接口照常跑只是少了一个会写字段、会答话的入口典型 AI-EnhancedL2还剩一个能全文检索的文档库人工查完再回答AI-EnhancedL3 只读半区客服和运维回到后台手工点页面慢但可控AI-Enhanced且是多数团队最划算的位置L3 写半区入口只有自然语言意图路由、多轮补槽本身就是 AI 提供的人接不住这条路径开始滑向 AI-Native债务要按第廿二篇算Q1四层必须按顺序叠还是可以跳层可以跳不能倒着跳。存量系统最常见的跳法是 L1 直接接 L3 只读——不建知识库只把几个查询接口包成工具效果往往比先做 RAG 更快被业务方认可。反过来不行在没有 L2 依据、也没有评测集的情况下开写操作等于让模型凭常识去改数据。注意跳层是实现顺序上的跳不是验收顺序上的跳——你可以先做 L3 只读拿业务认可但上线前必须回头补 L2 的评测集否则 L3 的工具选对了没有分母可判。。Q2三问里只有错误成本落在不利侧要不要做可以做 L1 和 L2 的只读部分但 L3 写半区直接放弃。错误成本是唯一不能靠工程手段补的维度延迟能优化幻觉能评测资金损失只能靠不让模型动手来防。我的理解是多数存量系统的正确姿势是顺着叠、跳着做、倒着验——顺序从 L1 起按业务需要直接跳到 L2 或 L3 只读但验收必须逐层补L1 的结构化输出不稳定L2 的检索质量就被模型抖动一起掩盖L2 没有分母L3 的工具选对了根本无从判断。一句话结论路线图不是多久能上完 AI而是在哪一层停下来以及停下来之前那层的数字达标没有。2. L1 能力接入一周能跑通也是被高估最多的一层对应专题第一篇第五篇结构化输出在第七篇前半会话记忆在第六篇。这层几乎所有团队都做出来了问题是把它当成了终点。2.1 这一层给的能力清单能力对应篇目存量系统里的典型用法模型调用与多供应商接入第一篇、第二篇一个ChatClient挂多家通道按环境或成本切换业务代码不感知多模型并存 流式输出第三篇抽取用小模型、生成用大模型长回答改 SSE首字延迟立刻好看起来提示词分层第四篇system / user / template 分开业务方改文案不用发版Advisor 链第五篇日志、脱敏、鉴权、检索都挂在拦截点上不动业务代码会话记忆第六篇严格说它是 L1 与 L3 的接缝多轮补槽没有它就不成立结构化输出第七篇前半稳定拿到 POJO / JSON——这是 L3 工具调用的前置条件2.2 这层的真实成本不在 SDK 上Demo 里挂个依赖半小时生产里这五件事才是账单隐性成本具体问题谁兜住对应篇目超时与重试模型 2 秒返回和 40 秒返回是同一种结果网关、线程池、SSE 三层超时值不一样重试还可能重复扣费超时预算显式写进配置只重试幂等调用退避 调用次数上限第三篇、第八篇痛点 6幂等帮我改一下备注这类请求重放一次就是两条数据或一次重复扣款请求级幂等键业务键不是 trace id写请求一律带第八篇成本核算框架给的只有模型与调用维度的 Token 指标没有成本这个指标单价是你自己的事每次调用把 token / 耗时 / 归因维度写进自己的表别只看厂商控制台第十三篇供应商替换换一家模型参数名不同、temperature 语义不同、思考链字段不同结构化输出失败率会先跳一下抽象层收敛差异替换演练当成验收项一次全链路跑通再上线第二篇、第七篇失败语义模型没答上来和服务挂了在监控里必须可区分否则告警全是噪声拒答 / 空结果 / 异常三条路径分别打点第十三篇2.3 L1 的独立验收指标不做上层也该交这三个数指标怎么取数建议门槛不达标先查什么结构化输出合格率不加人工修补即可反序列化成目标类型的比例稳定在一个高位我项目里的量级是从看着挺像 JSON起步补到九成以上才算能进生产经验值非官方指标schema 是否要求了模型给不出的字段失败后有没有一次带错误的重试P99 延迟 / 首字节端到端计时流式单独看首字节分档定同步接口和流式对话不是一个标准是不是偷偷多了一轮工具往返重试有没有计入用户等待单请求 Token 量级已落库的 usage 汇总按功能维度看趋势不追求绝对值只要求能按功能拆绝对值和单价、模型强相关上下文塞了什么记忆窗口、检索片段、错误重试各占多少供应商替换演练换一家跑一遍既有场景能跑通差异被抽象层吃掉哪些参数写死在业务代码里Q1L1 做到什么程度算完可以往下走三条同时满足结构化输出合格率稳定单请求成本有数注意是已落库不是我能去控制台看供应商替换演练过一次。缺第三条就往下叠等于把选型风险推迟到 L3——那时候要改的是工具契约不是换个 base-url。2.4 说清楚只做 L1 的团队多数不需要第 3、4 层L3 / L4这一条是我自己想跟同行说的。只做 L1 完全可以是终态而不是过渡态前提是你的判断落在这三条上价值来自把非结构化文本压成字段摘要、归类、抽取、改写不需要模型自己决定下一步做什么一次调用能出结果就别引入循环。一次调用的延迟、成本、失败面都是可预估的工具循环三项全部要乘轮次写操作收益说不清或者被合规卡在流程里——那停在 L1 比停在 L3 写半区体面得多。笔者后端 架构的用法是L1 L2 只读是我给自己团队的默认终态候选要不要往 L3 走永远由当前这一层的数字达标了没决定而不是由汇报需求决定。3. L2 数据可检索上限是文档质量不是模型能力对应第十篇第十二篇RAG 全链路、客服实战、评测与幻觉防线。条款/工单/手册 -- 清洗与分块 -- 向量化入库 -- 检索 TopK -- 重排 -- 带引用生成 -- 评测集回归 \______ 这一段决定上限 ______/ \______ 这几段只决定上限能被用出来多少 ______/3.1 盘点哪些内容该进知识库哪些不该这一层的坑不是检索算法是什么都往里塞。内容进不进理由替代做法政策条款、退改规则、SLA 说明进有版本、可引用、变更低频是 L2 的本金按条款粒度切metadata 留生效区间与来源操作手册、排障 SOP、历史工单结论进非结构化密度高规则穷举不动第 1 节第三问工单要先去重、把结论归并成一条再入库含凭证、密钥、内网地址的配置与文档绝不进入库即出网检索命中就是一条泄漏路径注释掉、加权限都救不回来先做脱敏 ETL位置选择参考第十八篇 6.4PII 出网高频变更的运营数据价格、库存、航班动态不进向量库重建永远慢于业务变更答一份旧数据比不答更糟结构化接口 L3 工具。第十一篇里条款走向量库、订单走工具就是按这条分的只存在于口头和群聊里的规则暂时进不去它没有真值来源写下来就变成某人以为的规则评测无法判对错让业务方先签一份必须答对清单再入库第二十篇的题源之一有版权或授权边界的外部资料看合同入库和出网是两件事都要单独确认与供应商授权范围一并核别在上线前一天问法务3.2 L2 的独立验收指标指标怎么取数建议门槛笔者经验值非官方指标不达标先查什么检索命中率 RecallK用带expectedDocIds的小集合看 TopK 是否含期望片段看环比相对上一次变更不掉两个点以上。绝对值没有可比性各家文档质量差一个量级很正常ETL 分块与 metadata不是模型引用可追溯率回答里的关键结论能否指回一条本次真正检索到的片段涉钱、涉时限的回答要求 100%其余看趋势上下文里到底放了什么第十三篇的 trace三类事实错误发生率第十二篇的分类有据不读 / 无中生有 / 张冠李戴门槛只有一个从偶尔会错变成有编号、有分母分别对应中间段丢失、空结果没拒答、噪声召回缺重排空结果行为检索为空时是否拒答必须拒答不能凭常识补检索阈值与拒答提示词3.3 没有评测集的 L2 等于裸奔这层最反直觉的一点做完知识库不等于有了质量只是有了可查询性。把分块从 800 调到 300、TopK 从 4 调到 20、加不加 rerank、换 embedding 模型——没有评测集的时候这些全是玄学改完只能说看起来准了。真实退化通常是两周后从工单和账单里发现的而 diff 里那句参数改动已经没人记得。所以 L2 的验收必须带一份能重跑的题集第十二篇给了评测流水线第二十篇把它变成 PR 门禁。这份东西不需要大——笔者项目里的量级是从几十条起步每条都能指名道姓说明它防哪类退化比几百条来路不明的题有用。Q1能不能不做 L2直接把文档塞进 prompt能而且文档量小的时候这样更好——少一层检索就少一类失败模式。真正的分界不在条数在两个问题一是上下文预算全塞进去会让成本随文档规模线性上涨第 2 节那笔账二是该找哪一段的责任被推给模型注意力长上下文中间段丢失会开始吃掉准确率。只要这两条还没痛就别为了架构好看建向量库。Q2L2 什么时候算撞到天花板当你发现答错的原因不是没检索到而是文档自己就矛盾 / 压根没写过。那是内容治理问题再叠 L3、L4 都不解决它只会被模型编得更像真的。此时正确的动作是回到 3.1 那张盘点表让业务方补文档或改口径。4. L3 能办事从答话到动手是风险跃迁点不是能力升级对应第七、八、九篇结构化输出、Tools / function-call、MCP 第十四、十五篇Agent 五种模式与 Agent Utils 工具箱。L3 只读半区 查订单 / 读条款 / 查状态 -- 出错代价 一次难看的答案可回滚 ---------------------------------------------------------------这条线不是能力线是责任线 L3 写半区 改签 / 退款 / 建工单 / 批量运维 -- 出错代价 真实资损与合规责任4.1 为什么说是跃迁而不是升级三件事同时断裂所以它不能靠再多做一点工程顺过去责任主体变了。一次工具调用链里选哪个工具、参数填什么由模型当场决定。第八篇 7 大痛点里的第 3、4、7 条强行适配参数、接口名不业务化、权限控制说的都是同一件事优化目标是完成请求的模型不会主动如实报告信息不足。失败形态变了。L1/L2 的失败是难看的答案L3 的失败是不该发生的状态变更而且往往不回滚就没人发现——用户不会投诉一次他没要求的改签。权限路径变了。模型代表用户执行身份必须从服务端透传而不是从模型参数里取第十八篇整篇在处理这件事凭证不能进模型视野异常堆栈不能原样回灌给模型。4.2 该不该开放写操作四级分级表级别例子前置条件缺一不许开确认形态错了谁兜只读查询查订单、读条款、查航班状态声明期工具白名单 执行期按用户过滤 归属校验单子是不是他的 异常不外泄无答错是产品问题可容忍低风险写建工单、加备注、设提醒、改偏好上述全部 幂等键 字段白名单模型只能填业务字段不能填 id / 金额 / 状态一次轻确认留可撤销窗口人审 可撤销资金级写改签、退款、赔付、下单上述全部 人工确认确认对象是改动 diff不是要不要执行 金额由服务端算 审计四要素必须人点且确认内容可回放真资损、合规责任批量运维批改签、批量通知、脚本化数据修复建议不要放进模型可达路径走工单审批 确定性任务系统AI 最多生成待执行清单线下流程事故面是乘出来的审计四要素资金级写的最低要求谁发起的真实用户身份不是模型、何时、依据哪些资料那一轮实际检索到的片段、确认后执行了什么参数。缺任何一条事后都还原不出当时为什么这么做。4.3 L3 的独立验收指标指标定义建议门槛经验值说明工具选择正确率该调对的工具、且不该调时没调只读场景先达标再谈写第八篇痛点 4接口名不业务化与description写法直接决定这条参数幻觉率缺失字段被编造的比例必须趋零靠 schema 给不知道留合法出路 后端二次校验这是写半区最贵的一条越权拦截率归属不符 / 身份缺失的请求被拒比例100%有例外就是洞需要有专门的边界用例来证明第二十篇三类题型里的第二类写操作确认完成率有确认记录的写请求 / 全部写请求100%缺一条就是审计缺口循环调用与成本上限单请求最大模型调用轮次、Token 上限有明确数字且能熔断没有上限的工具循环等于把账单交给模型4.4 多数团队的正确止步点L3 的只读半区说得更直接一点只读半区做完你在业务侧能拿到的价值通常已经超过一半而风险还停留在答案难看这一档。从只读跨到写收益的增长是业务动作数不是体验提升代价的增长是责任与审计——这条曲线不是平滑的。三条止损线任何一条成立就退回只读资金级写的前置条件里你没法凑齐金额由服务端算 人工确认 diff 审计四要素这三件幂等做不出来存量接口本来就不幂等且你改不动它无法构造越权必被拒的测试用例也就是说没有证据说明权限过滤真的生效。Q1Agent 模式第十四、十五篇算不算更高一层不算它还在 L3 里面。五种模式和工具箱只是把一次调用换成多轮、由模型决定下一步能力没跨层但延迟、成本、失败面全部按轮次放大。第十四篇里那句哪些需求根本不该用 Agent其实就是 L3 内部的止步建议。Q2MCP第九篇、第廿一篇是 L3 还是 L4取决于动机。只是想让模型多几个工具写Tool就够那是 L3要让别的团队和别的助手复用同一批存量接口才值得上协议层那是 L4 的复用投入。顺序反过来的常见结果是MCP Server 建好了只有作者自己一个人用。5. L4 工程化不是可选项而是有真实用户之后的一期还款对应第十三篇可观测、监控、Token 成本归因 第十七廿二篇对话式 UX、安全边界、多 Agent、CI 门禁、存量接口 MCP 化、架构取舍。这一层唯一要防的是把它当起点。先有真实用户 / 真实改动再做 L4 -- 每一项都有输入投入产出算得清 先建平台再找场景 -- 每一项都在等一个永远不会来的需求5.1 L4 六件事投入产出表#事对应篇目什么时候必须做什么时候是过度工程晚做的代价1trace 日志 Token 成本落库与归因第十三篇AI 入口超过两三个或者要向上汇报成本只有一个内部入口且量小到一张表格记得过来不可算账账单涨了不知道哪个功能、哪个用户贡献的2评估集与回归第十二篇 → 第二十篇有真实用户且答案会影响用户决策业务规则还在天天改真值不稳题集跟着崩质量退化靠工单发现晚两周到一个季度3把评估挂进 CI 当门禁第二十篇多人协作改 prompt / 参数 / 分块一个人维护且每次改动都自己过一遍我本地试过了变成唯一防线4安全边界与人工确认链路第十八篇只要碰 L3 写半区第一天就要全只读且不涉个人数据仍建议留最小审计不可逆资损、越权、泄漏5对话式 UX补槽、追问、中断、确认第十七篇入口字段多且用户是外部客户或一线操作员用户是内部熟练工——表单永远更快用户流失 误操作返工比首做贵6跨团队复用存量接口 MCP 化第九篇 → 第廿一篇同一批接口有两家以上要做 AI 入口只有一个使用方各团队重复包装五份描述五套漂移另外两件单独说一下**多 Agent 拆分第十九篇**不是 L4 必做项它是 L3 内部的重构判据是上下文预算、权限隔离、独立伸缩三条业务量不到就别拆**架构取舍第廿二篇**不是投入项是止步层选完之后回头算总账的位置。5.2 L4 的验收指标都是过程量这层没有准确率只有能不能被管理指标怎么取数说明成本可归因率能按用户 / 功能 / 租户拆开的 Token 成本占比笔者项目第一版只有总量勉强算清一半量级经验值非官方指标。注意别把 userId 塞成 Prometheus tag基数会打死监控门禁覆盖率命中该跑评估集的 PR 里实际跑过的比例分母要用第二十篇那五类触发条件定义清楚否则永远是 100%写操作确认完成率见 4.3必须 100%它同时是 L3 和 L4 的指标越权与注入用例通过率边界题、干扰题单独统计这一条掉了比整体通过率掉了更该停下来MTTR一次答得不一样从工单到定位根因的耗时没有 trace 和录播只能靠重跑复现那就不叫定位Q1为什么不第一天就把 L4 做完反正迟早要还因为 L4 每一项都需要真实流量或真实改动当输入没有真实提问你不知道评测集该出哪几十道题没有真实账单你不知道成本要归因到哪个维度才有意义没有真实用户操作你设计不出他看得懂的确认文案。第一天做 L4 的结果通常是做了一个没人用的平台 一套没人看的仪表盘还会顺手把团队士气用光。Q2那 L4 什么时候从晚做变成欠债三条信号出现两条就该排期① 有人开始用重跑一次来解释线上异常说明没有 trace② PR 里改 prompt 不需要任何人点头说明没有门禁③ 有用户投诉但你复现不出当时那一轮的上下文说明既没有留痕也没有录播。这三条都不是效率问题是会累积成事故的债。5.3 三个典型过度工程信号第二周就搭多 Agent 编排而 L2 的命中率还没有分母内部日调用量很小却要做全链路 A/B 评测平台——一份进版本库的题集就够第二十篇 3.1把 L4 当售前工程先建平台再找场景平台没有主人半年后交还给运维。一句话结论L4 六件事里成本归因和安全确认这两件的等待成本是不可逆的另外四件晚做只是麻烦不是危险。6. 存量系统的落地顺序与三条不要推荐顺序不是最快出效果而是每一步都能单独止损。第 1 步 L1 L2 只读 一个入口 一份能查的文档 12 个月笔者项目量级 ↓ 不达标就退回 L1 第 2 步 单点 L3 只读 只挂 35 个只读工具不建平台 ↓ 工具选择率不涨就退回 L2 第 3 步 内部灰度 只给客服 / 运维答案不直接对客 ↓ 两周没人用就停 第 4 步 L4 补齐 成本归因 评估门禁 安全边界 ↓ 没有真实用户就不做 第 5 步 才谈写操作与对话式入口步骤做什么为什么排在这验收止损条件做了但没成1L1 打通 L2 只读一个知识域只读、不改写路径出错面最小最容易拿到第一个用户结构化输出合格率 RecallK 环比 引用可追溯文档盘点做不动、没人愿意为口径签字 → 退回纯 L1或改成不依赖知识库的抽取场景2单点 L3 只读几个查询工具把答变成查完再答价值跳一档风险仍在答案层工具选择正确率、参数幻觉率、越权拦截率选择率涨不上去 → 不是模型问题回去改 name / description或减工具数量3内部灰度客服、运维先用拿真实提问喂评测集成本可控错误有人工兜底人工改写率、真实拒答率、单请求成本趋势两周没人主动用 → 停在这里别硬推对外多半是场景选错4L4 补齐归因、门禁、安全有了真实用户三项都有输入钱花得清楚第 5.2 节那五个过程量没有真实用户 / 没有多人协作 → 明确不做写进季度结论5才谈写操作与对话式 UX唯一不可逆的一步必须排在有审计之后确认完成率、审计四要素可回放前置条件凑不齐 → 永久停在第 3 步这不是失败6.1 三条不要不要先重构再上 AI。存量系统里等不到重构窗口而且不需要。L1 的抽象层第二篇、L2 的旁路读取不动写路径、L3 只读包一层查询接口——这三招本来就是为不重构也能叠设计的。判据如果你的第一步是先把某个域拆出来那多半是借 AI 之名做架构审美评审时会被问这跟 AI 有什么关系然后两头都黄。不要一上来全量。L2 的起点是一份文档盘点加几十条评测题不是一次全公司文档大入库。全量入库的三个必然结果噪声拉低命中率然后你去调 rerank 掩盖它、含凭证内容混进向量库、变更范围没人说得清。一个域先跑通比十个域都半死不活有用。不要直接对客户开写操作。次序只能是内部只读 → 内部写带确认→ 对外只读 → 对外写确认 审计 限额。跳步的典型事故不是模型乱写而是模型用对了工具、用错了归属——把 A 用户的单子改到 B 用户名下。这类错误的唯一防线是身份不从模型参数里取 执行期归属校验第八篇痛点 7、第十八篇的权限传递而不是更好的提示词。我见过一个完整的反面案例某团队第一周上了 Agent MCP 多模型路由第二周开放了改签工具第三周模型把 A 用户的订单改到了 B 用户名下——工具选对了、参数填对了但归属校验没做身份从模型参数里取。业务方叫停后整个项目再没人敢提 AI。这个案例的教训不是模型乱写而是用对了工具、用错了归属。。顺手把常见的错误顺序也列出来因为它看起来很合理错误顺序看起来合理的理由三个月后的真实状态先建平台再找场景“统一建设更省”平台没主人场景方各写各的脚本L2 没做就先做对话式 UX“聊天界面最讨领导喜欢”界面很顺但每句话都在编因为脚下没有可检索依据先上多 Agent 再补观测“架构要先进”一次提问十几次模型调用没人能解释哪一步该为账单负责先对客户开写操作拿效果“只读没人用”一次误改数据整个项目被停之后再没人敢提 AIQ如果老板要求下周就要看到 AI 效果怎么办三种能承诺的东西成本完全不同承诺实际成本风险我的建议L1 演示抽取 / 摘要 / 归类一周内能出复用既有接口低不碰线上写路径可以但要说清这是 L1不是AI 化完成内部小范围 RAG 试用一个域 几十条题几周到一个月中主要是文档质量被打脸推荐这个并且把评测题集当交付物一起交对客对话入口L1L2L3 只读UX 全链路高且几乎一定要返工不接受。改成先给内部客服用的同一套东西7. 一张决策总表 自检清单如果这一篇只留一页留这页。7.1 决策总表你的情形建议止步层必做篇目可以跳过立刻止损的信号第一次接 AI做内部客服 / 运维问答L1 L2一、二、三、四、五、七、十、十一、十二九、十四、十五、十七廿一评测题集凑不出来、文档没人签口径 → 退回 L1只做摘要 / 工单归类的批处理无对话L1一、二、四、五、七三流式后置、九十二结构化输出合格率上不去 → 改 schema 和提示词不是换模型有对客入口但只做只读咨询L3 只读半区八、十十三九、十四、十五、十九入口字段不多就跳过十七引用可追溯率上不去 / 越权用例过不了 → 停灰度扩量要让 AI 代表用户改数据改签、退款L3 写半区但先在只读停一季八、十三、十七、十八、二十九、十五、十九、廿一确认链路要人肉兜、幂等做不出来 → 退回只读一批存量接口要给两个以上团队复用L4复用项八、九、第廿一篇十四、十五、十九盘完只能核出 3 个可对外 → 先挂工具别建 Server公司要建AI 平台横向组L4 全套但先有主人九、十三、十七、十八、十九、二十—没人对通过率负责 → 不做先去做一个真场景小团队 内部工具 日调用量很小L1 L2L4 只做成本落库二、四、五、七、十、十二九、十四十九、廿一无这层够用很久强监管域资金、医疗、涉个人敏感信息L2 L3 只读写操作留人工十二、十三、十八、二十十四、十五、十七、十九审计四要素缺任一条 → 不给写要做 AI-Native 新产品不是改造存量本篇不适用只当作分层词汇表—见第廿二篇7.2 开工前自检清单#检查项没过关的表征1能说清本次要叠到哪一层且这一层有验收指标需求写的是上一套 AI 能力2错误成本 / 非结构化密度 / 规则可穷举三问落在有利侧至少两条只有别人都做了这一条理由3模型调用有超时预算、重试策略和调用次数上限Demo 里默认配置直连生产网关4Token 与耗时已落库能按功能维度算账不是登控制台看总量月底只知道这个月贵了5换一家模型的演练做过一次差异被抽象层吃掉参数名和字段语义散在业务代码里6知识库有一份能签口径的内容盘点凭证与高频数据被明确排除一次性把全公司文档推进向量库7有几十条带真值的评测题且带expectedDocIds“我手工问了几个都挺准”8改分块 / TopK / prompt 会触发评估集而不是凭手感这三类改动无人 review9工具分只读与写两级写操作有幂等键所有工具一律挂上去注解里没有任何风险标记10身份从服务端上下文透传不从模型可填参数取用户 id 出现在工具入参里让模型填11资金级写有确认链路 审计四要素只能靠事后从日志里拼当时发生了什么12有明确的不做清单和可对外说的止损线路线图只写要做什么这张表怎么用三条开工前对一遍止步层7.1每层叠完对一遍该层的验收表第 25 节每季度重跑一次 7.2看有没有条目从上季已过关掉回表征出现——L4 的债通常是这么开始累积的。一句话结论本篇的止步层是给 AI-Enhanced 用的如果你的产品定义本身就是没有 AI 就不成立那本篇的止损逻辑不再适用该看第廿二篇。最后总结问法要先改不是要不要上 AI而是这次叠到哪一层这层的数字是什么。四层里每一层都能独立验收也都能独立停下来——停在某一层是交付不是半途而废。判断标准我留在第 1 节那一句把 AI 拿掉这套流程还能不能跑。能跑是 AI-Enhanced本篇四层都在这条线以下不能跑你就已经在做 AI-Native那是另一种债务形态第廿二篇专门算这笔账。多数后端团队的性价比区间是L1 L2 L3 只读半区拿掉这三层里任何一层收益都会明显塌往前一步进写半区收益涨的是业务动作数代价涨的是责任和不可逆性。L4 不是可选项是有真实用户之后的一期还款。早做是在给不存在的需求做工程晚做才是欠债——但其中两件成本归因、写操作确认链路的等待成本不可逆别跟着另外四件一起延后。对后端 / 架构读者我认为最该盯的两件事一是成本核算的落库——框架只给到模型和调用维度的 Token 指标成本这个指标不存在单价和归因维度必须自己写进业务表否则你的 AI 功能永远没有报价能力二是写操作的确认链路——谁确认、确认的是哪份 diff、幂等键存哪、审计四要素齐不齐这条链路决定的是项目能不能活过第一次事故而不是模型好不好。顺序上“不要先重构再上 AI”、“不要一上来全量”、不要直接对客户开写操作这三条我见过的失败基本都能归到其中一条。参考资料 致谢[1] Spring AI Reference2.0.1[2] spring-projects/spring-ai - GitHub[3] [AI工程] Spring AI 第一篇2.0 到底升级了什么从 Prompt、RAG、MCP 到 Agent 应用实战[4] [AI工程] Spring AI 第二篇2.0 快速接入 DeepSeek、阿里百炼与 Ollama[5] [AI工程] Spring AI 第三篇2.0 实战多模型、流式输出与工具调用怎么写[6] [AI工程] Spring AI 第四篇提示词使用与设置技巧2.0[7] [AI工程] Spring AI 第五篇Advisor 对话拦截的使用和自定义 2.0[8] [AI工程] Spring AI 第六篇对话记忆——数据库和 Redis 不同的实现[9] [AI工程] Spring AI 第七篇结构化输出与初代 Tools 实现[10] [AI工程] Spring AI 第八篇Tools / function-call 使用 原理 7 大痛点[11] [AI工程] Spring AI 第九篇MCP 实现、原理、源码读与鉴权[12] [AI工程] Spring AI 第十篇RAG 全链路讲解——从 ETL、Modular RAG 到重排序[13] [AI工程] Spring AI 第十一篇基于航空智能客服的 RAG 实战[14] [AI工程] Spring AI 第十二篇RAG 评测与幻觉防线[15] [AI工程] Spring AI 第十三篇给 AI 应用装上仪表盘[16] [AI工程] Spring AI 第十四篇Agent 五种模式在 2.0 里怎么写[17] [AI工程] Spring AI 第十五篇Spring AI Agent UtilsClaude Code 的那套工具箱被人在 Java 里重写了一遍
