做微服务拆分这件事我踩过的坑比很多人写过的代码都多。早些年拆一个交易系统光“订单到底算交易域还是履约域”就能吵两周后来学会了用领域驱动设计的限界上下文去切效率是高了但每次面对一个几千个类、几十张核心表的“大泥球”业务系统时脑子还是容易炸。直到我开始用AI辅助做这件事才真正体会到什么叫“一个人也能开架构评审会”。这篇文章我会把完整的思路、实操过程和可以直接复制的AI提示词都放出来。内容不玩虚的核心是讲清楚三件事为什么AI适合干微服务拆分的脏活累活、怎么设计一套能产出靠谱拆分方案的提示词、以及拿到AI输出之后怎么结合人工判断落地。如果你正在负责一个复杂业务系统的微服务改造或者在技术评审会上被“怎么拆、拆多细、为什么这么拆”这些问题反复折磨那这篇文章值得你花十分钟认真看完。1. 微服务划分为什么难又为什么偏偏适合用AI做1.1 微服务拆分的三大死穴先说一个扎心的事实大部分失败的微服务改造不是死在技术选型上而是死在“怎么划分服务边界”上。边界划不好后面全是连锁反应。我见过最典型的三个死穴第一业务边界模糊。业务系统不像技术组件它没有清晰的接口和依赖关系只有一堆散落在各处、互相调用、语义重叠的功能模块。比如“客户信息”这个概念可能在订单、风控、营销、客服里都有但每个系统的理解都不一样落到数据库里又是完全不同的表结构。这种模糊性导致不管怎么拆总有人不满意。第二依赖关系成环。老系统嘛历史包袱都在A模块调BB调CC又调A甚至还有反向依赖数据库的表。你以为拆成两个服务就能解耦结果一梳理发现消息队列、定时任务、共享缓存里全是隐式依赖根本切不断。第三团队协同失灵。服务拆完是给团队用的如果拆分方案不考虑团队人员规模、技能栈、发布节奏拆出来的服务必然造成“一个服务三个团队改”或者“一个团队维护八个服务”的极端情况协作效率反而比单体还低。这三个死穴有一个共同点它们都需要在大量信息之间做交叉分析、权衡取舍。而这恰恰是大语言模型最擅长的事情——AI不会累不会带有色眼镜给它足够的上下文它能在一分钟内整理出几十个维度的分析结果。1.2 AI在微服务划分里的真实定位先说清楚我不主张让AI直接拍板“订单服务、支付服务、库存服务”这种教科书答案那是自欺欺人。AI在这个场景里的真正价值是替代“初级架构师文档管理员”的工作把业务系统的碎片信息结构化、找出领域边界、列出候选方案、评估拆分的风险收益。一句话AI负责把决策所需的“食材”准备好最终烹饪的决定权还是要人来做。我自己的使用方式是三层递进第一层业务梳理用AI把杂乱的需求文档、模块说明、接口清单整理成统一的业务能力地图。第二层边界分析让AI基于领域事件、聚合根、限界上下文这些DDD概念推导出候选的服务边界。第三层方案评估让AI针对每一个候选方案从数据一致性、调用复杂度、团队协作、发布频率等维度打分并给出风险提示。这三层里AI的输出质量完全取决于提示词的质量和信息输入的质量。这也是为什么我后面要花大篇幅去讲提示词怎么设计——很多人在这一步就翻车了要么给AI的信息太少导致输出太泛要么提示词里全是“要仔细分析、要深入思考”这种正确的废话AI根本不知道你要它干什么。1.3 为什么提示词工程是这次改造的胜负手提示词就是我常说的“AI逗号”——喂进去的是垃圾出来的也是垃圾。你给AI一个系统名让它“给出拆分建议”它只会给你一份用烂了的微服务概念文章但你给它一份“当前模块列表、主要业务流程、核心数据表、现有调用关系”再配上角色设定和输出格式约束它就能给你一份可以直接进评审会的拆分草案。这背后的原理是大语言模型本质上是一个“高级的文本续写器”它输出的质量上限由两个因素决定——上下文里有多少有用的信息、以及你想要它输出的格式和逻辑是否够具体。提示词的价值就是把这两件事做到极致。所以我认为在AI辅助微服务划分这个场景里提示词设计比AI选型重要十倍。2. 完整提示词设计五个要素拆解2.1 提示词必须包含的五个核心要素我会把每次做微服务划分时用的提示词当作一个“模板工具”而不是随手写的一句话。一个合格的微服务拆分提示词要有五个固定模块角色设定告诉AI它是什么身份比如“你是一位拥有10年经验的微服务架构师精通领域驱动设计”。这一步能让AI调用更专业的知识体系来回答。业务上下文输入把系统的现状讲清楚包括模块清单、主要业务流程、核心数据实体、现有技术栈、团队情况。信息越具体输出越有针对性。任务目标明确告诉AI要完成什么是“识别限界上下文”还是“给出候选服务列表”还是“评估拆分优先级”。目标越单一输出越聚焦。输出格式约束规定AI的回答结构比如“请用Markdown表格输出”“每个服务必须包含职责说明、核心数据实体、主要依赖、风险提示”。这一步能防止AI输出大段你看不懂的散文。评判标准与约束条件告诉AI什么是对、什么是错。比如“拆分后的服务必须满足独立部署、独立扩展、数据不跨服务强一致”这些硬性约束以及“服务数量不要超过团队可维护范围”这类软性约束。2.2 微服务拆分完整AI提示词模板下面是我经过多次迭代之后稳定使用的一个完整提示词。这份提示词的核心设计思路是先让AI做业务梳理再做候选服务识别最后做方案评估。三个阶段通过同一个提示词里的多个步骤串联起来减少来回对话的次数。提示词正文可直接复制你是一位拥有10年以上经验的微服务架构师精通领域驱动设计、事件风暴、分布式系统设计。下面我会给你一个复杂业务系统的基本信息请基于这些信息完成微服务拆分方案的初步设计。一、系统现状业务目标与核心价值为中小型电商平台提供订单履约能力支撑从用户下单到收货完成的全流程。当前模块清单包括模块名和主要功能用户模块注册登录、用户资料、会员等级、收货地址商品模块商品SPU/SKU管理、类目属性、库存管理、价格管理订单模块购物车、订单创建、订单状态流转、订单查询支付模块支付单创建、支付回调、退款营销模块优惠券、满减活动、限时秒杀发票模块发票申请、抬头管理、开票状态查询物流模块发货、快递单号回填、物流轨迹同步售后模块退款申请、退货处理、售后原因记录核心业务流程描述用户浏览商品后将商品加入购物车提交订单时系统锁定库存并生成订单用户完成支付后通知仓储发货发货后用户可申请开票。若用户申请退款则进入售后流程售后完成后释放库存。核心数据实体非完整表结构仅关键实体用户、用户地址、会员等级商品、SKU、库存、价格、类目购物车项、订单、订单项、订单状态、支付单、退款单优惠券、活动、秒杀场次发票、发货单、物流轨迹、售后单现有技术栈Java 17、Spring Boot 3、Spring Cloud、MySQL、Redis、Kafka、Docker。团队情况4个后端开发小组每组4~5人各小组可独立维护2~3个微服务。二、任务要求请按以下步骤执行不要在未完成上一步时直接跳到下一步步骤1识别核心业务能力。基于上述信息列出系统的核心业务能力Business Capability每个能力需包含能力名称、能力描述、关联的核心数据实体、活跃度评估高/中/低说明判断理由。步骤2进行领域分析与限界上下文划分。基于业务能力、业务流程和数据实体识别领域事件和聚合根划分限界上下文。对每个限界上下文请说明上下文名称、核心职责、关键聚合根、与之交互的其他上下文、上下文之间的关系类型共享内核/防腐层/开放主机服务/发布语言等。步骤3输出候选微服务列表。基于限界上下文划分给出候选微服务列表。每个服务须包含服务名称、服务职责、核心数据实体注意标记哪些是自有数据、哪些是引用数据、对外提供的核心API或事件、依赖的其他服务、独立部署/扩展的可能性和瓶颈、建议的存储选型MySQL/Redis/自研等。步骤4给出拆分方案评估。结合团队规模和数据一致性要求评估每个候选服务拆分的优先级高/中/低并用表格说明拆分该服务带来的收益、需要付出的成本、主要风险点、应对措施。三、硬性约束与偏好必须遵守不允许因为技术便利而强行合并高内聚、低耦合的两个领域也不允许为了追求服务数量而把强聚合、强事务的模型拆散。优先考虑数据一致性要求高的场景避免跨服务强一致如果不能避免必须显式标出并给出补偿方案。服务的划分必须能映射到现有团队确保一个服务只由一个小组主导维护。所有分析必须基于我提供的系统信息如果信息不足请明确列出你缺失的信息而不是臆想。所有输出使用中文表格统一为Markdown格式保持排版清晰。这份提示词看着长但我实测下来有效信息密度很高。你把这份提示词里的“系统现状”换成自己项目的实际信息就能用。很多人问过我为啥不强用一个更短的版本因为微服务划分一旦信息不全AI就特别容易输出正确的废话——这是大模型最坑的地方。2.3 提示词里每个参数设计的隐藏心机我说一下这份提示词里几个容易被忽略、但实际效果非常大的设计细节。第一业务能力和限界上下文分成了两个步骤。很多拆分方案失败是因为直接把业务模块映射成服务比如把“用户模块”直接变“用户服务”这是典型的按表拆服务和按页面拆服务落地之后还是一堆耦合。让AI先梳理业务能力再划分限界上下文本质上是逼它做一次“从具体到抽象再到具体”的思维过程输出的服务边界会更接近业务本质。第二标注了“关联的核心数据实体”和“自有数据vs引用数据”。这一点至关重要。拆微服务最难的一个点就是数据库分离如果AI连每个服务该拥有哪些表都没想清楚后面全白搭。在提示词里明确要求区分“自有数据”和“引用数据”AI就会自动识别出例如“订单服务里的用户ID是引用数据用户服务里的用户基本信息才是自有数据”这种关键区别这会直接影响后续的表结构拆分。第三限制了“不允许跨服务强一致”不是绝对禁止而是必须显式标出。现实业务里总有例外比如下单顺带扣库存如果要求绝对不强一致很多方案会变得很拧巴。我给AI留了一个口子允许它识别出强一致场景并给出补偿方案。这样既避免了AI拍脑袋拆出分布式事务地狱又能保留必要的技术弹性。3. 实际演练拿一个订单系统把完整流程走一遍3.1 准备输入信息这一步决定了AI输出质量的80%我先说一个原则宁可多给信息不要少给。大语言模型有一个特点上下文信息越充分就越能发现你没问到但很关键的细节。我在实际操作时除了把模块清单、业务流程和数据实体给它还会把现有的接口调用关系、定时任务列表、消息队列topic清单、甚至数据库里的核心表关系都整理进去。这些“隐性上下文”往往决定了服务能不能彻底拆开。举个例子如果我只告诉AI“订单模块负责下单”它就只会输出“订单服务”和一个“用户服务”的浅层划分。但当我补充了“支付回调会更新订单状态”、“库存锁定是通过Kafka异步消息触发的”、“定时任务每5分钟扫描超时未支付订单”这些细节之后AI就能识别出订单状态机、支付回调处理、超时关闭、库存补偿这些经常被忽略的“隐性边界”从而给出更细、更合理、更容易落地的服务划分。这一步的产出是一份“业务信息抽取表”建议花一两个小时认真整理。整理过程本身就是一个很好的业务盘点很多人以为自己是熟悉系统的真往提示词里写才发现很多信息其实是“不知道具体在哪、也不知道跟谁交互”的。3.2 第一次交互看AI输出的意外惊喜和明显偏差拿着上面那份提示词跑一遍我得到的AI输出首先是一份“业务能力列表”包括用户生命周期管理、商品目录服务、价格策略管理、库存状态管理、订单状态机管理、支付流水处理、营销规则执行、发票开具追踪、履约物流追踪、售后工单处理。接着AI划分出的限界上下文是这些限界上下文核心职责关键聚合根与外部上下文的关系用户上下文用户注册、认证、资料、地址、会员等级用户、地址通过共享内核向订单、营销提供用户基础信息商品上下文类目、SPU/SKU、价格、库存商品、SKU、库存订单上下文通过开放主机服务获取商品信息订单上下文购物车、订单、订单状态机、超时处理订单、购物车通过领域事件通知支付、库存、物流支付上下文支付单、回调、退款流水支付单与订单通过防腐层交互营销上下文优惠券、活动、秒杀优惠券、活动订单通过规则引擎集成营销报价发票上下文发票申请、抬头、开票状态发票申请单接收订单已支付、已发货事件触发开票物流上下文发货、运单回填、轨迹发货单订阅订单支付完成事件和售后通知事件售后上下文退款申请、退货、原因售后单与订单、库存、支付上下文均有交互说实话第一次看到这个结果我是有点惊喜的因为它没有把“支付”和“订单”合并成一个“交易服务”而是分开处理并且明确给“营销”单独划了一个上下文——这两个判断单独拿给有经验的人做也是大概率会这么选的。但随后我仔细检查细节也发现了几个明显偏差。比如AI把“购物车”和“订单”都放进了订单上下文从业务上说可以接受但从高频访问和存储压力角度看“购物车”数据量极大、读写比极高完全可以拆成一个独立的低成本缓存服务。这个取舍AI不会替你想到因为它没有流量数据和运维数据。这就回到我前面强调的定位问题了——AI能给你一个相当靠谱的基线方案但流量、成本、团队情况这些“只有现场的人才知道”的信息AI永远是缺失的需要人手去补。3.3 第二轮提示词用追问机制把方案往深水区推第一次输出可以作为“草案”。我对这份草案只做了一件事——把AI没考虑到的“购物车高并发场景”和“价格频繁变动的营销策略”作为补充信息再让它重新评估。其实这就是提示词工程的迭代思维把AI的输出当作“初稿”把人的领域知识当作“修改意见”再让AI基于修改意见生成“二稿”来回揉两三次方案的深度会显著提升。我补充的内容是这样的补充信息购物车是高频访问场景读写比超过10:1期望使用Redis存储降低数据库压力。营销规则变化频繁运营团队每周都会有新的满减/折扣玩法需要支持热更新。库存的锁定操作在订单创建时需要确保不超卖你上一版把库存放在商品上下文里请重新评估是否要独立库存服务。请基于以上补充信息重新审视限界上下文划分和候选微服务列表重点说明哪些服务边界需要调整、为什么。这一轮AI输出的变化相当明显。它把购物车从订单上下文拆出来独立成“购物车上下文”存储选型直接从MySQL改成了Redis异步持久化。它把“库存状态管理”单独拆分成了“库存服务”因为库存扣减的下单场景强一致诉求太高不值得为了节省一个服务而引入分布式事务这样做仓库WMS对接也会更干净。更关键的是它重新调整了营销上下文的边界建议所有价格计算都先调用营销服务的“报价API”而不是由订单服务自己做规则判断这样规则热更新就能独立上线而不会影响订单主链路。这时候其实AI已经渐渐逼近了一个有经验的架构师会给出的方案。但你要记住每次迭代都要把AI输出的逻辑链复制下来存好这不仅是拆分方案还是以后跟团队过评审会时的底稿。3.4 把AI输出变成真正的方案目标服务列表与依赖矩阵经过两轮交互之后我最后会把AI输出的候选服务列表整理成一份统一的“目标服务蓝图”。以这个电商订单系统为例最终的核心服务列表长这样服务名职责核心数据对外API/事件依赖用户服务注册登录、资料、地址、会员等级用户表、地址表、会员表获取用户信息、地址校验、会员变更事件无商品服务SPU/SKU、类目、价格、商品详情商品表、SKU表、价格表商品详情查询、价格查询无库存服务库存扣减、预占、释放、库存查询库存表、库存流水表预占库存、释放库存、库存变更事件商品服务读SKU信息订单服务订单生命周期管理、状态机订单表、订单项表、购物车表创建订单、查询订单、订单状态事件商品服务、库存服务、营销服务支付服务支付单创建、回调处理、退款支付单表、退款表创建支付单、支付结果回调、退款事件订单服务读订单信息营销服务优惠券、活动、规则计算优惠券表、活动表、规则配置表报价计算、优惠券核销、活动事件无发票服务发票申请、抬头、开票发票申请表、抬头表申请开票、开票状态事件订单服务订阅事件物流服务发货、轨迹同步发货单、物流轨迹表发货、轨迹更新订单服务订阅事件售后服务退款/退货流程管理售后单、退货单申请售后、售后结果事件订单服务、支付服务、库存服务紧接着是一份依赖矩阵和事件清单比如“订单创建成功后会发布OrderCreatedEvent库存服务和物流服务都订阅这个事件”、“支付成功会发布PaymentSucceededEvent订单服务订阅后更新订单状态发票服务订阅后触发开票申请”。这些细节如果靠自己梳理至少得花三四天跟各模块的负责人逐个访谈而有了AI辅助大部分工作在一天内就能完成初稿剩下的时间用来验证和纠偏效率不可同日而语。4. 常见问题与排查技巧实录4.1 AI输出太泛泛而谈像个没做过架构的人这几乎是所有人第一次让AI拆微服务的共同体验。AI给了“订单服务、用户服务、商品服务”这种三岁小孩都能想到的答案而且每个服务的职责描述还没超过两行。遇到这种情况我的排查顺序是先看提示词里“系统现状”部分的信息量够不够再看“任务要求”里有没有分步骤执行。如果信息只有“一个电商系统”六个字那AI能输出什么高级东西巧妇难为无米之炊。解决方式把系统现状部分补到极致包括模块清单、核心流程步骤、数据实体、现有接口甚至团队人数。然后任务要求里明确写出“先识别业务能力再划分限界上下文再输出服务列表”这种结构化的步骤。AI一旦有了具体的分析路径输出质量会立刻上一个大台阶。4.2 AI不同次运行的结果不一致谁对谁错这是所有大语言模型的通病因为生成式模型本身就带随机性。处理办法有两个。第一在提示词开头加一句“请先对系统信息进行内部结构化整理再基于整理结果严格按照输出格式回答”这能显著降低随机性第二同一份输入跑三次然后人工合并三份结果的“最大共识”部分有分歧的部分单独拿出来和业务方确认。我实际使用的习惯是每轮迭代都保存完整的对话记录并给不同的候选方案打标。最后拿方案去对业务方评审时把“AI给的基线”“我调整后的方案”“为什么调整”这三个版本都讲清楚反而更容易说服团队。4.3 AI拆分结果和现有团队架构冲突经常出现的一种情况是按业务能力拆得很理想但团队现有的四个小组是按前后端或按模块划分的AI拆出来的服务根本没法映射到团队。这时候很多人的第一反应是“算了AI不懂我们团队”。其实解决办法不是让AI闭嘴而是把团队约束作为硬性约束写进提示词。比如在硬性约束第3条里写明“每个服务必须能由一个小组独立维护”AI就会在候选服务生成时自动做取舍——它可能把发票服务和物流服务合并成一个“履约支撑服务”只为了能适配团队人力。这本质上是把“技术最优”和“组织约束”的冲突提前到了AI生成阶段省得你后期推翻重来。4.4 AI引入根本不存在的“幻觉服务”大模型一个常见的坑是它会脑补一个看起来合理但不存在的服务。比如给我之前的电商系统拆出一个“推荐服务”但我压根没提任何推荐逻辑。这说明模型把自己对“电商系统应该有推荐”的常识注入了输出。发现这种幻觉的时机越早越好所以我通常会让AI严格遵守“所有分析必须基于我提供的系统信息如果信息不足请明确列出缺失信息”这条硬性约束。4.5 快速排查表现象可能原因解决办法输出全是概念和理论上下文信息太少补足系统现状信息细化到模块级输出服务边界和你想的完全不一样缺少业务语义约束在提示词里补充你已知的核心规则和约束每次运行结果不一致生成式模型随机性固定提示词并多次运行取共识输出内容过于理想、无法落地缺少团队/技术/成本约束增加团队人数、技术栈、部署环境等约束条件AI一直在用“灵活的、可扩展的”这类空话缺少输出格式约束强制用表格输出每个字段都有明确含义漏掉了很多你已知的领域细节上下文里没给到这些细节复盘已知信息把漏掉的补充进提示词5. 从AI拆解到真正落地还差这几步5.1 把AI候选服务映射到现有代码边界AI输出的是“理想的服务蓝图”但现有代码不会自己变成蓝图的样子。落地阶段你需要做一件很具体的事情把AI给出的每个候选服务映射回现有的模块、包名、数据库表、定时任务和消息Topic形成一张“现状到目标”的映射表。这个过程我一般叫“拆迁规划表”——哪块代码要搬到哪个新服务哪些表要跟着挪哪些接口要从RPC改成MQ每一步都要写到表格里不然拆到一半必然乱套。从实操效率看AI生成的限界上下文文档能直接作为“拆迁规划表”的需求文档你把每个上下文对应的代码路径、数据表整理进去就可以直接进入开发排期了。5.2 拆分优先级不能平均用力我见过很多团队拿到拆分方案后按从前往后的顺序开发结果拆到一半发现最核心的订单服务一拆所有下游全断了。我的建议是优先级看三个维度稳定度该业务变化频繁吗、耦合度它被多少其他模块依赖、独立收益拆出来能不能独立扩展或独立发布。以电商订单系统为例我会优先拆“发票服务”和“物流服务”因为它们依赖关系简单、都是订阅订单事件属于低风险高收益的“开刃小刀”中间拆“营销服务”因为规则变化频繁独立出来能提高运营响应速度最后啃“订单服务”和“支付服务”这两个硬骨头只有它们稳定了整个系统的微服务化才能算真正成功。这些都是可以从AI给出的“拆分优先级评估”里直接获取的重要参考你在评审时再结合业务战略做最终排序即可。5.3 结合DDD事件风暴做人工校准AI输出的限界上下文划分本质上是它对DDD知识的复现但业务真实世界往往比文本描述复杂得多。它有可能漏掉关键的领域事件比如对账、冻结、解冻这些低频但重要的流程也可能把两个不应该共存的状态机塞进一个服务里。我的习惯是拿AI生成的事件清单作为“事件风暴”的输入约上业务产品经理用白板把每个重要流程过一遍重点核对AI输出的领域事件覆盖度。如果发现有遗漏直接补进提示词重新生成一轮或者人工修正。这一步是人与AI协作里最不可替代的环节——领域专家的隐性知识AI永远学不到。5.4 演进式拆分而不是推倒重来最后说一个亲历的教训不要高估团队的并行开发能力也不要低估老系统的“胶水逻辑”。如果条件允许微服务改造采用“绞杀者模式”也就是在不改变现有系统对外行为的前提下逐步用新服务替换旧模块每替换一个模块就下线一部分旧代码。AI拆出来的服务清单正好可以作为“绞杀者模式”的路线图每次挑一个服务治理完成后通过开关或网关灰度切流验证稳定再切下一个。这样既能把AI辅助拆分的成果快速落地又不会把整个系统一次性推进火坑。我在几个项目里都是这么干的虽然前期节奏看起来慢但到后半程团队信心和系统稳定性都会给你巨大的正面反馈。5. 最后补充一点个人体会用了这么久的AI辅助微服务拆分我最深的感受是AI没有改变架构设计的本质它改变的是架构师的工作方式。以前我做一次拆分调研要拉着各模块负责人开四五轮会才能把信息凑齐现在AI可以在几十分钟内给我一份覆盖面极广的初稿让我有更多时间去思考那些真正需要人类智慧的问题——比如领域规则之间的冲突、组织架构的适配、长期演进的方向。不过我也要泼一盆冷水如果你的系统信息本来就是一团乱麻业务流程没人说得清连模块清单都要自己想半天那AI也救不了你。AI辅助微服务划分的第一前提是你要有一颗清醒的大脑和一套基本完成的信息盘点。工具只是放大器你手里的牌越完整放大出来的效果越好。如果你正准备用AI做微服务拆分我的建议是先花一个晚上把业务系统的基础信息整理成一份结构清晰的文档然后用我这套提示词跑一遍拿到初稿之后找两三个核心同事做半小时评审。你会发现那个让你愁了好几周的“服务边界问题”已经开始有眉目了。
