别再把业务写进 Prompt：Spring AI Alibaba Skills 企业级落地指南文章目标：把一篇“Prompt 不要乱堆”的观点文，升级成一篇能指导企业级 AI 应用落地的工程文章文章主线：Spring AI Alibaba Skills 不是一个“更方便写 Prompt”的工具，而是一种把语言能力、业务能力和系统治理重新拆开的工程方法一、先说结论：很多 AI 项目不是死在模型效果，而是死在架构边界过去两年，很多团队做企业 AI 应用时都走过一条几乎一样的路线：先做一个能跑的 Prompt Demo把退款、物流、推荐、投诉、知识问答逐步塞进去为了修复误答继续补规则、补 few-shot、补异常话术最后得到一份越来越长、谁都不敢动的超级 Prompt这条路在验证阶段没有问题，甚至可以说是成本最低、反馈最快的做法。真正出问题的时刻，通常不是第一天上线，而是业务开始持续演进之后：新业务域不断接入并发量开始抬升风险场景越来越多模型调用成本开始被财务盯上运维开始要求明确 SLA测试开始追问“这次改动到底影响了什么”这时你会发现，问题已经不是“Prompt 写得好不好”，而是：你把本该由系统负责的职责，提前让 Prompt 承担了。这篇文章要解决的不是“怎么写更复杂的 Prompt”，而是下面几个更本质的问题：企业系统里，哪些职责可以交给模型，哪些必须留在应用侧Spring AI Alibaba Skills 为什么适合承担 AI 能力拆分这一层在高并发和多业务域场景下，如何让这套架构可测、可控、可扩展生产环境里最容易踩到哪些坑，应该怎么提前治理如果你的系统已经出现这些信号，这篇文章基本就是写给你的：一份 Prompt 已经超过 2000 到 4000 token，还在继续增长同一条用户问题在不同时间可能返回不同结论业务逻辑、风控约束、异常分支都在 Prompt 里“描述性存在”想加一个新能力，总担心把老能力带崩模型调用慢、贵、不稳定，但你又说不清问题到底在模型还是在系统二、真实事故：把客服拖慢的不是模型，而是超级 Prompt我们先看一个很典型的事故现场。某电商客服系统在一次营销活动后出现明显抖动：过去平均响应 1 秒左右高峰期 P99 提升到 6 到 8 秒退款和投诉类问题错误率上升应用侧 CPU 打满，Full GC 频率增加最开始大家都怀疑是模型网关或上游配额异常，但把调用链拆开后会发现：网络 RTT 没明显恶化模型接口没有集中报错下游订单、物流服务也基本正常真正增长最快的指标，是单次请求输入 token 和平均处理时长根因最后定位到一份维护了半年的超级 Prompt。这份 Prompt 一开始只承担“话术约束”和“少量流程提示”，后来逐步演化为一个混合体：负责意图判断负责工具选择负责业务规则解释负责异常处理负责回复文案生成看起来它还只是一个 Prompt，实际上它已经变成了一个未经工程化治理的“业务运行时”。最危险的点在于，这种系统在前期往往不是“不能跑”，而是“还能跑”。正因为它还能跑，所以团队会不断往里面加东西，直到它失去可维护性。三、为什么疯狂堆 Prompt 一定会撞墙很多人把问题简单总结成一句话：“Prompt 太长，所以延迟高、成本高。”这句话没错，但还不够。真正让系统撞墙的，是超级 Prompt 同时放大了四种不同维度的复杂度。1. 推理复杂度和业务复杂度被强行耦合用户说“我要退款”，理论上只需要做三件事：理解用户诉求查询订单和退款资格返回确定性结果但如果退款、物流、推荐、活动、投诉、安抚全部放在一个大 Prompt 中，模型每次都必须先阅读完整上下文，判断当前问题属于哪个分支，再进入具体处理。这意味着很多请求即使很简单，也要先支付一轮无效决策成本。这类系统的延迟来源通常有三部分：输入上下文越来越长模型每次要在大量规则里做选择应用侧为了拼装 Prompt 产生额外对象创建、序列化和日志开销所以当业务继续增长时，系统不是“线性变慢”，而是会逐步进入抖动区间。对线上系统来说，高抖动比高平均值更可怕，因为它会直接引发线程池排队、超时重试和级联雪崩。2. 规则冲突会从“效果问题”演变成“线上事故”很多 Prompt 在早期都能跑通，是因为规则还少、分支还浅。当业务演化到多域并存时，规则冲突几乎不可避免。例如：售后规则要求先核对订单状态投诉规则要求先安抚情绪营销规则要求优先引导优惠方案风控规则要求敏感订单不能直接给出退款结论如果用户说：“我买的裤子破了，我要退款，不处理我就投诉。”在这种复合场景里，系统应该先做哪一步，不应该靠模型“临场发挥”。否则输出很容易随着上下文、措辞、few-shot 示例、模型版本而漂移。这类问题最麻烦的地方在于，它经常不会表现成 500 错误，而是表现成：没有报错，但用户投诉增加没有异常堆栈，但回答稳定性下降回归测试样例通过，线上边缘样例开始误路由3. 测试边界会变得极其模糊如果业务规则主要存在于 Prompt 中，测试会遇到几个天然困难：单元测试很难对某条业务规则做精确断言集成测试依赖模型输出稳定性，很难做强确定验证压测即使发现瓶颈，也难拆出到底是路由问题、Prompt 拼装问题还是模型耗时问题一条规则改动很可能影响多个域，但测试范围无法明确圈定工程团队最怕的不是复杂，而是复杂却不可分解。超级 Prompt 最大的问题，正是它把原本应该分层处理的复杂度压成了一个黑盒。4. 团队协作会失去版本治理能力当 Prompt 成为核心业务承载体，协作模式往往会退化为：产品改话术运营补规则开发补异常条件算法补 few-shot最后所有人都在改同一份文件，但没人能对整体后果负责。你很难回答这些本该很基本的问题：这次变更影响哪些业务域哪些规则是高优先级强约束，哪些只是表达偏好某次线上误答，到底是模型能力问题还是系统建模问题如果只想回滚退款逻辑，应该回滚哪一部分所以，问题并不是“Prompt 不能写很多”，而是：Prompt 不应该承担系统控制平面的职责。四、Spring AI Alibaba Skills 到底解决了什么问题很多人第一次接触 Skills，会把它理解成“把多个 Prompt 封装成几个能力”。这种理解不能说错，但太浅。从工程角度看，Skills 解决的是三个问题：能力边界拆分执行责任回收治理入口标准化1. 能力边界拆分退款、物流、投诉、推荐、知识问答，本质上不是一种任务。它们背后的依赖系统、异常分支、性能特征和风险等级都不同。把这些能力收敛成独立 Skill，有两个直接收益：每个能力可以按自己的业务边界演进每个能力可以按自己的风险等级治理例如：refund-skill是高风险、强幂等、强审计能力recommend-skill是低风险、偏效果优化能力faq-skill可能更依赖检索和知识库如果所有能力都挤在一个 Prompt 里，这三种差异很难被工程系统感知。2. 执行责任回收企业系统真正强约束的部分，不应该交给模型：权限校验幂等控制超时与重试调用降级风险兜底状态变更Skills 的价值之一，就是帮助团队把“业务执行责任”收回到 Java 和应用框架中。模型仍然很重要，但它更适合做两件事：语言理解语言生成这是一个非常关键的边界划分。很多 AI 系统不稳定，并不是模型太差，而是系统让模型承担了过多本不该承担的职责。3. 治理入口标准化当能力变成独立 Skill 之后，很多原来难做的事情就开始有抓手：可以按 Skill 统计调用量、成功率、P95、P99可以针对高风险 Skill 做独立限流和熔断可以按 Skill 维度做灰度发布可以把每个 Skill 的输出标准化成结构化结果可以用单测、集测和回放测试分别验证不同层次这意味着 AI 应用第一次开始具备类似微服务治理的能力。五、企业级落地不是“一把梭多 Agent”，而是先做职责收敛很多团队在意识到超级 Prompt 有问题后，第二个常见误区是直接冲向“多 Agent 架构”。但绝大多数企业项目在第一阶段并不需要那么重。更现实、也更容易落地的一种做法，是先把系统拆成三层。第一层：应用控制层应用控制层负责所有必须确定、必须可控的事情：鉴权会话装配traceId 生成租户隔离超时控制规则前置判断审计日志灰度开关这一层的原则很明确：凡是不能容忍随机漂移的逻辑，都不要交给模型。第二层：Skill 执行层Skill 层只负责一件事：在明确上下文下执行某个业务能力，并返回结构化结果。典型能力包括：退款申请物流查询商品推荐投诉建单常见问题答复每个 Skill 都应该满足四个要求：单一职责明确输入明确输出可独立治理第三层：回复聚合层聚合层负责把结构化结果变成适合用户阅读的回复。这一层仍然可以使用 Prompt，但 Prompt 应该被刻意压小。它的职责应该是：语言润色风格统一输出格式控制而不应该是：重新做业务判断补全缺失事实隐式触发额外动作如果聚合层又重新变成一个超级 Prompt，前面做的分层基本等于白做。六、核心原理：从用户一句话到最终回复，中间到底发生了什么如果要把这套架构真正跑稳，必须先讲清楚一条请求在系统里如何流动。下面给出一个更贴近生产环境的处理链路。AggregatorModel GatewayOrder ServiceSkill ExecutorRoute EngineChat ControllerAPI GatewayUserAggregatorModel GatewayOrder ServiceSkill ExecutorRoute EngineChat ControllerAPI GatewayUser
别再把业务写进 Prompt：Spring AI Alibaba Skills 企业级落地指南
别再把业务写进 Prompt：Spring AI Alibaba Skills 企业级落地指南文章目标：把一篇“Prompt 不要乱堆”的观点文，升级成一篇能指导企业级 AI 应用落地的工程文章文章主线：Spring AI Alibaba Skills 不是一个“更方便写 Prompt”的工具，而是一种把语言能力、业务能力和系统治理重新拆开的工程方法一、先说结论：很多 AI 项目不是死在模型效果，而是死在架构边界过去两年，很多团队做企业 AI 应用时都走过一条几乎一样的路线：先做一个能跑的 Prompt Demo把退款、物流、推荐、投诉、知识问答逐步塞进去为了修复误答继续补规则、补 few-shot、补异常话术最后得到一份越来越长、谁都不敢动的超级 Prompt这条路在验证阶段没有问题，甚至可以说是成本最低、反馈最快的做法。真正出问题的时刻，通常不是第一天上线，而是业务开始持续演进之后：新业务域不断接入并发量开始抬升风险场景越来越多模型调用成本开始被财务盯上运维开始要求明确 SLA测试开始追问“这次改动到底影响了什么”这时你会发现，问题已经不是“Prompt 写得好不好”，而是：你把本该由系统负责的职责，提前让 Prompt 承担了。这篇文章要解决的不是“怎么写更复杂的 Prompt”，而是下面几个更本质的问题：企业系统里，哪些职责可以交给模型，哪些必须留在应用侧Spring AI Alibaba Skills 为什么适合承担 AI 能力拆分这一层在高并发和多业务域场景下，如何让这套架构可测、可控、可扩展生产环境里最容易踩到哪些坑，应该怎么提前治理如果你的系统已经出现这些信号，这篇文章基本就是写给你的：一份 Prompt 已经超过 2000 到 4000 token，还在继续增长同一条用户问题在不同时间可能返回不同结论业务逻辑、风控约束、异常分支都在 Prompt 里“描述性存在”想加一个新能力，总担心把老能力带崩模型调用慢、贵、不稳定，但你又说不清问题到底在模型还是在系统二、真实事故：把客服拖慢的不是模型，而是超级 Prompt我们先看一个很典型的事故现场。某电商客服系统在一次营销活动后出现明显抖动：过去平均响应 1 秒左右高峰期 P99 提升到 6 到 8 秒退款和投诉类问题错误率上升应用侧 CPU 打满，Full GC 频率增加最开始大家都怀疑是模型网关或上游配额异常，但把调用链拆开后会发现：网络 RTT 没明显恶化模型接口没有集中报错下游订单、物流服务也基本正常真正增长最快的指标，是单次请求输入 token 和平均处理时长根因最后定位到一份维护了半年的超级 Prompt。这份 Prompt 一开始只承担“话术约束”和“少量流程提示”，后来逐步演化为一个混合体：负责意图判断负责工具选择负责业务规则解释负责异常处理负责回复文案生成看起来它还只是一个 Prompt，实际上它已经变成了一个未经工程化治理的“业务运行时”。最危险的点在于，这种系统在前期往往不是“不能跑”，而是“还能跑”。正因为它还能跑，所以团队会不断往里面加东西，直到它失去可维护性。三、为什么疯狂堆 Prompt 一定会撞墙很多人把问题简单总结成一句话：“Prompt 太长，所以延迟高、成本高。”这句话没错，但还不够。真正让系统撞墙的，是超级 Prompt 同时放大了四种不同维度的复杂度。1. 推理复杂度和业务复杂度被强行耦合用户说“我要退款”，理论上只需要做三件事：理解用户诉求查询订单和退款资格返回确定性结果但如果退款、物流、推荐、活动、投诉、安抚全部放在一个大 Prompt 中，模型每次都必须先阅读完整上下文，判断当前问题属于哪个分支，再进入具体处理。这意味着很多请求即使很简单，也要先支付一轮无效决策成本。这类系统的延迟来源通常有三部分：输入上下文越来越长模型每次要在大量规则里做选择应用侧为了拼装 Prompt 产生额外对象创建、序列化和日志开销所以当业务继续增长时，系统不是“线性变慢”，而是会逐步进入抖动区间。对线上系统来说，高抖动比高平均值更可怕，因为它会直接引发线程池排队、超时重试和级联雪崩。2. 规则冲突会从“效果问题”演变成“线上事故”很多 Prompt 在早期都能跑通，是因为规则还少、分支还浅。当业务演化到多域并存时，规则冲突几乎不可避免。例如：售后规则要求先核对订单状态投诉规则要求先安抚情绪营销规则要求优先引导优惠方案风控规则要求敏感订单不能直接给出退款结论如果用户说：“我买的裤子破了，我要退款，不处理我就投诉。”在这种复合场景里，系统应该先做哪一步，不应该靠模型“临场发挥”。否则输出很容易随着上下文、措辞、few-shot 示例、模型版本而漂移。这类问题最麻烦的地方在于，它经常不会表现成 500 错误，而是表现成：没有报错，但用户投诉增加没有异常堆栈，但回答稳定性下降回归测试样例通过，线上边缘样例开始误路由3. 测试边界会变得极其模糊如果业务规则主要存在于 Prompt 中，测试会遇到几个天然困难：单元测试很难对某条业务规则做精确断言集成测试依赖模型输出稳定性，很难做强确定验证压测即使发现瓶颈，也难拆出到底是路由问题、Prompt 拼装问题还是模型耗时问题一条规则改动很可能影响多个域，但测试范围无法明确圈定工程团队最怕的不是复杂，而是复杂却不可分解。超级 Prompt 最大的问题，正是它把原本应该分层处理的复杂度压成了一个黑盒。4. 团队协作会失去版本治理能力当 Prompt 成为核心业务承载体，协作模式往往会退化为：产品改话术运营补规则开发补异常条件算法补 few-shot最后所有人都在改同一份文件，但没人能对整体后果负责。你很难回答这些本该很基本的问题：这次变更影响哪些业务域哪些规则是高优先级强约束，哪些只是表达偏好某次线上误答，到底是模型能力问题还是系统建模问题如果只想回滚退款逻辑，应该回滚哪一部分所以，问题并不是“Prompt 不能写很多”，而是：Prompt 不应该承担系统控制平面的职责。四、Spring AI Alibaba Skills 到底解决了什么问题很多人第一次接触 Skills，会把它理解成“把多个 Prompt 封装成几个能力”。这种理解不能说错，但太浅。从工程角度看，Skills 解决的是三个问题：能力边界拆分执行责任回收治理入口标准化1. 能力边界拆分退款、物流、投诉、推荐、知识问答，本质上不是一种任务。它们背后的依赖系统、异常分支、性能特征和风险等级都不同。把这些能力收敛成独立 Skill，有两个直接收益：每个能力可以按自己的业务边界演进每个能力可以按自己的风险等级治理例如：refund-skill是高风险、强幂等、强审计能力recommend-skill是低风险、偏效果优化能力faq-skill可能更依赖检索和知识库如果所有能力都挤在一个 Prompt 里，这三种差异很难被工程系统感知。2. 执行责任回收企业系统真正强约束的部分，不应该交给模型：权限校验幂等控制超时与重试调用降级风险兜底状态变更Skills 的价值之一，就是帮助团队把“业务执行责任”收回到 Java 和应用框架中。模型仍然很重要，但它更适合做两件事：语言理解语言生成这是一个非常关键的边界划分。很多 AI 系统不稳定，并不是模型太差，而是系统让模型承担了过多本不该承担的职责。3. 治理入口标准化当能力变成独立 Skill 之后，很多原来难做的事情就开始有抓手：可以按 Skill 统计调用量、成功率、P95、P99可以针对高风险 Skill 做独立限流和熔断可以按 Skill 维度做灰度发布可以把每个 Skill 的输出标准化成结构化结果可以用单测、集测和回放测试分别验证不同层次这意味着 AI 应用第一次开始具备类似微服务治理的能力。五、企业级落地不是“一把梭多 Agent”，而是先做职责收敛很多团队在意识到超级 Prompt 有问题后，第二个常见误区是直接冲向“多 Agent 架构”。但绝大多数企业项目在第一阶段并不需要那么重。更现实、也更容易落地的一种做法，是先把系统拆成三层。第一层：应用控制层应用控制层负责所有必须确定、必须可控的事情：鉴权会话装配traceId 生成租户隔离超时控制规则前置判断审计日志灰度开关这一层的原则很明确：凡是不能容忍随机漂移的逻辑，都不要交给模型。第二层：Skill 执行层Skill 层只负责一件事：在明确上下文下执行某个业务能力，并返回结构化结果。典型能力包括：退款申请物流查询商品推荐投诉建单常见问题答复每个 Skill 都应该满足四个要求：单一职责明确输入明确输出可独立治理第三层：回复聚合层聚合层负责把结构化结果变成适合用户阅读的回复。这一层仍然可以使用 Prompt，但 Prompt 应该被刻意压小。它的职责应该是：语言润色风格统一输出格式控制而不应该是：重新做业务判断补全缺失事实隐式触发额外动作如果聚合层又重新变成一个超级 Prompt，前面做的分层基本等于白做。六、核心原理：从用户一句话到最终回复，中间到底发生了什么如果要把这套架构真正跑稳，必须先讲清楚一条请求在系统里如何流动。下面给出一个更贴近生产环境的处理链路。AggregatorModel GatewayOrder ServiceSkill ExecutorRoute EngineChat ControllerAPI GatewayUserAggregatorModel GatewayOrder ServiceSkill ExecutorRoute EngineChat ControllerAPI GatewayUser
