干了十几年架构我最怕的不是新技术学不会而是那种“看起来什么都能跑、一改需求就全线崩溃”的遗留系统。去年公司启动核心业务中台重构二十多个业务模块、三百多张表、四个后端团队同时维护我第一次尝试用 AI 来辅助微服务划分效果比我预期的要好很多。这篇文章把整个过程中沉淀下来的方法论、四套可以直接抄的微服务拆分 AI 提示词以及踩过的坑一次性整理出来献给正在做系统拆分、边界梳理或者准备做微服务迁移的架构师和资深开发。先说明一点我不是来吹“AI 取代架构师”的。AI 在微服务划分里的真实价值是帮你把原本需要两周才能摸清的隐藏依赖、数据耦合、事务边界压缩成几小时就能审阅的候选方案。它能大幅降低信息收集成本但最终拍板的还是人。下面我先把拆分这件事本身讲透再给你能直接用的工具。1. 为什么微服务拆分那么难先搞清楚问题再谈 AI1.1 我们拆的到底是什么很多人一提到微服务拆分第一反应是“把一个大的代码仓库切成几个小的代码仓库”。这是最普遍的误解。真正拆的不是代码目录而是变更边界也就是“一组未来会因为同一类业务原因同时变化、需要独立部署的能力集合”。举个例子用户下单这个动作表面上看只是“创建一条订单记录”但背后涉及库存预占、营销优惠计算、支付回调、消息通知。如果这些逻辑全都写在一个订单模块里物理上它们确实在一起但逻辑边界非常混乱。一个月后产品经理说“预售订单要支持不预占库存”你会发现改一个需求要动支付、库存、营销三块代码发布风险陡增。这种系统里最大的成本不是写代码而是需求从一个模块传导到另一个模块时的“协调成本”。微服务划分的核心目标就是把这种协调成本控制住。我们本质上是在回答两个问题哪些东西应该一起变哪些东西可以各自变AI 能做的恰恰是帮你快速找出“一起变”的那组依赖关系。1.2 最常见的三种拆分坏味道我参与过好几个拆分项目发现不管什么行业拆失败的系统里基本都能看到三种典型坏味道。第一种是“事务银河”。一个用户操作要跨五六个服务同步调用每个服务都有自己独立的事务最后还要搞分布式事务保证一致性。拆完之后系统变得极其脆弱任何一个服务抖动整个链路就断了。典型场景就是订单模块和库存模块频繁进行同步扣减拆完之后性能不升反降。第二种是“双向依赖”。服务 A 调用服务 B 的接口服务 B 又反过来调用服务 A 的接口。这种循环依赖在代码里看着不多但顺着调用链深挖几乎无处不在。拆完服务后两个服务互相调版本发布根本没法独立一升级就出兼容性问题。第三种是“隐性数据耦合”。几个模块表面上互相不依赖但共享同一张表或者同一个字段尤其是那种大家都要读写的“状态字段”。比如订单表里的“优惠金额”营销模块在改订单模块也在改拆完之后你不得不做数据双写或者跨服务查询非常痛苦。识别这三种坏味道靠人眼翻代码不是不行就是太慢。这时候 AI 的优势就体现出来了它能把依赖关系、调用链、表单关系集中归纳成一张清单让我一眼看到哪些地方是拆分时必然要处理的雷区。1.3 AI 适合做什么不适合做什么我用 AI 辅助拆分的次数越多越明白一个边界AI 适合做“侦察兵”不适合做“指挥官”。它特别擅长在短时间内吸收大量信息然后按照你给定的方法论模板输出结构化的候选方案。比如给它模块清单、表结构、调用链它能快速整理出一个“按业务能力划分”的服务边界草案。但 AI 有两个致命短板。第一它不了解你的团队组织结构。你团队只有五个人它给你拆出十五个微服务这种方案再漂亮也落不了地。第二它不具备真正的业务判断力。业务规则里的潜台词、数据的一致性痛点、运营活动的特殊要求这些不是写在文档里的地方AI 看不到。所以正确的姿势永远是AI 负责把“战场情况”摸清楚人负责“做决策”。2. AI 辅助拆分的整体工作流先设计好流程再动手2.1 我的五步工作流刚开始用 AI 辅助拆分时我犯过直接把整个代码仓库扔给 AI 的错误结果它给我生成了一堆看着合理但根本没法用的建议。后来我逐渐整理出一套稳定的五步工作流。第一步材料准备。把模块清单、数据库表关系、核心接口定义、典型业务流程整理成结构化文本。第二步初筛。用“业务域候选边界初筛”提示词让 AI 输出候选服务清单。第三步校验。用“依赖与耦合检测”提示词针对初筛结果做一轮耦合检查看哪些边界存在循环依赖或数据耦合。第四步事务复审。用“事务边界评审”提示词评估每个跨服务的业务操作到底是该做强一致还是最终一致。第五步落地方案。用“迁移计划”提示词把最终划分结果转换成阶段化、可回滚的版本执行计划。这套流程的关键不只是提示词本身而是“人机协作”的节奏每一步生成结果后我都会带着领域知识去审查、否定、调整。AI 的输出只是分析过程不是最终方案。2.2 输入材料的准备不要直接把整个仓库丢给模型很多团队用 AI 做架构分析时特别喜欢把 Git 仓库地址或者一堆源码直接贴进去。这种做法效率很低效果也不好。因为大模型在超长上下文里容易出现信息“稀释”真正关键的边界信息会被淹没在无关代码里。正确的做法是先做“信息浓缩”。我会让团队输出几份文档一是模块清单包含模块名、核心职责、负责人团队二是数据库表结构至少要把每张表的业务含义和关键外键关系列出来三是核心接口清单包含主要 API 的路径和传入传出参数四是关键业务流程图把“下单”“退款”“发货”这类核心流程写清楚。有时候业务系统没有完整文档我也会先用工具自动提取代码信息比如生成 OpenAPI 接口文档或者用脚本把 JPA 实体关系转成表格再把这些标准化产物作为提示词的输入。这套做法既能让 AI 的上下文更干净也能减少它胡编乱造的概率。2.3 上下文补全代码地图、调用链与数据字典如果系统里真的没有调用链信息我会额外做一个“代码地图”步骤。做法很简单先用 grep 或者 IDE 的全局搜索把核心接口被哪些地方调用找出来整理成调用关系文本然后把核心领域对象的字段变化历史拉出来看看哪些字段被多个模块频繁修改。这两类信息能非常有效地暴露隐性耦合。做完这些之后我会把信息喂给 AI 时明确告诉它“以下信息是从真实代码库提取的依赖关系不是完整的架构文档如果有缺失请明确指出而不是默认它不存在。”这个约束很重要它能避免 AI 一本正经地分析一个不存在的数据关系。3. 微服务拆分的完整 AI 提示词可直接复用的四套提示词不是随便写两句“帮我拆分微服务”就行的。要在架构分析场景里拿到高质量结果关键是给模型明确角色、输入信息格式、输出结构约束和不确定性兜底策略。下面四套提示词是我反复调优后留下的版本你可以直接复制替换成自己项目的信息。3.1 提示词一业务域候选边界初筛这是整个拆分流程的第一环目标是让 AI 基于业务能力和数据所有权给出候选服务划分清单。我把这个提示词设计成“先限定、再发散、最后收口”的结构避免 AI 天马行空。你是一名拥有10年以上经验的微服务架构师精通领域驱动设计和系统重构。现在需要你帮我为一个复杂业务系统做微服务候选边界的初筛。 【角色约束】 - 你只能基于我提供的信息进行分析不允许补充或臆测我没有提到的内容。 - 如果信息不足导致无法判断只能输出“信息不足”并列出需要补充的问题清单不能强行给出结论。 - 整个分析过程必须考虑业务能力、数据所有权、变更频率、团队组织边界、事务一致性要求、部署与扩展性要求。 【业务背景信息】 {在这里粘贴系统名称、业务目标、核心流程描述、当前模块清单、主要功能列表、团队规模与组织结构、当前系统痛点} 【分析要求】 1. 先按照业务能力划分出候选领域再合并过小的领域、拆分过大的领域给出最终候选服务清单。 2. 对每个候选服务输出以下字段 - 候选服务名称 - 核心业务职责 - 涉及的现有模块 - 归属的数据表或数据域 - 主要对外接口或领域事件 - 拆分依据为什么这样算一个合理边界 - 拆分置信度高/中/低以及依据 3. 如果有明显的“跨域共享需求”请在备注列说明比如需要共享用户信息、需要依赖某个公共字典等。 4. 最后单独输出一个“风险与待确认事项”列表。 【输出格式】 使用Markdown表格展示以上信息表格列候选服务名称 | 核心业务职责 | 涉及现有模块 | 数据归属 | 主要接口/事件 | 拆分依据 | 置信度这套提示词的关键在于把不确定性兜住。很多 AI 分析工具最大的问题就是“不懂装懂”明明没有数据也要硬给结论。所以我在提示词里专门加了“信息不足就报信息不足”这一条。实测下来加上这个约束之后AI 会主动向你追问缺失信息而不是直接给一个貌似周全的方案。这个行为对架构师来说其实更有价值因为很多团队对自身系统的理解本来就是模糊的能被 AI 问到盲区反而是一次免费体检。3.2 提示词二依赖与耦合检测初筛方案交付之后不要急着当最终结果。第二步要做依赖校验专门排查拆分后可能出现的循环依赖、数据耦合和调用链过深问题。你是一名精通代码分析和依赖分析的资深架构师。我会给你一个系统的模块描述、数据库表结构、接口定义和核心调用链信息你需要帮我识别出服务划分时的依赖与耦合风险。 【输入材料】 - 系统模块清单{粘贴} - 数据表结构或数据库ERD描述{粘贴} - API/接口依赖关系{粘贴} - 核心调用链样例{粘贴} 【检测与分析要求】 1. 输出所有我列出的模块之间存在依赖关系的地方。 2. 重点识别以下三类耦合 a. 数据库耦合多张表之间存在外键关系或共享字段拆分后可能带来跨服务查询。 b. 接口循环依赖A调用BB又调用A或者同步调用链超过3层。 c. 业务事件耦合一个业务动作需要同步调用多个模块才能完成无法异步化解耦。 3. 针对每个耦合点给出影响的服务候选边界并标注级别阻塞必须解决、警告需要讨论、提示可以接受。 4. 对每个“阻塞”级别的问题提出至少两种解决思路。 【输出格式】 先输出依赖清单表格依赖编号 | 涉及模块/服务 | 耦合类型 | 具体原因 | 影响级别 | 解决思路 再输出一段总结明确指出哪些依赖会影响现有候选服务边界并给出边界修正建议。这个提示词的巧妙之处是让 AI 用“影响级别”把问题做了优先级排序。架构评审最怕的不是发现问题而是问题太多不知道从哪个开始改。阻塞、警告、提示三层分级能让你直接把精力放在真正影响落地的问题上。我自己在实际使用时会额外加一句“如果某个耦合点可以通过引入消息队列解决请在解决思路里明确说明”。因为很多同步调用链看着吓人其实换成事件驱动后立刻就不是问题了。3.3 提示词三事务边界与最终一致性方案评审拆服务最容易忽略的坑就是事务边界。单体应用里的一个方法调用可以轻松保证事务拆成多个服务后事务不等于跨库事务性能和一致性立刻成了瓶颈。这个提示词帮助我把事务问题前置到设计阶段。你是一名资深分布式系统架构师擅长领域事务边界设计。下面我会给你一组候选微服务划分方案以及涉及的事务流程你需要帮助我评估每个跨服务业务操作的事务边界。 【输入信息】 - 候选微服务划分方案{粘贴} - 关键业务流程{粘贴包括每一步的实现方式和现有事务处理} - 数据一致性要求例如订单创建后库存一定要扣减不能出现超卖等场景 【评估要求】 1. 对每个涉及多个服务的业务用例分析是否真的需要引入分布式事务。 2. 如果可以用最终一致性解决请给出具体方案本地消息表、事务消息、SAGA、事件驱动等并说明为什么适合。 3. 如果必须使用强一致分布式事务例如XA或Seata AT模式请标注对性能、可用性、吞吐量的影响。 4. 对每个候选服务边界评估这个边界导致的“串行调用服务数量”一个用户动作需要串行调用超过3个服务才能完成时必须明确标记。 5. 输出内容包括调整服务边界的建议避免为了拆分而拆出一堆需要跨服务事务的方案。 【输出格式】 按用例输出以下Markdown结构 - 用例名称 - 涉及服务 - 当前处理方式 - 推荐方案强一致/最终一致 - 落地方案关键设计 - 对服务边界的影响这里我的经验是如果 AI 输出的候选方案里频繁出现“必须强一致”那就是拆分方案本身有问题的信号。好的服务边界应该天然让大部分业务操作落在单服务内只有少量真正跨域的流程才需要最终一致性设计。一楼和二楼之间可以有消防通道但每走一步都要过消防通道那这楼的格局一定有问题。3.4 提示词四拆分落地任务与迁移版本计划前面的提示词都聚焦在方案层面但方案最终要变成执行计划。尤其在国内很多场景里系统已经部署在容器化平台上了还要做到准不停服、不丢数据的迁移。这最后一步提示词就是把划分方案转成工程任务。你是一名具备一线落地经验的微服务架构师。我已经有了一份候选服务划分方案现在需要你把这份方案转化为可以执行的落地任务和迁移计划。 【输入信息】 - 最终服务划分方案{粘贴} - 当前代码库结构描述{粘贴} - 数据存储现状{粘贴} - 迁移环境信息例如使用Kubernetes编排当前为单体部署希望做到准不停服迁移数据库不能丢数据 - 现有CI/CD流程{粘贴} 【输出要求】 1. 将迁移拆分为多个阶段每个阶段必须做到可独立验证、可回滚。 2. 对每个阶段输出 - 阶段目标 - 前置条件 - 代码或配置变更点 - 数据迁移步骤新增表、双写策略、切读策略、回滚策略 - 验证标准 3. 数据迁移部分必须考虑三种典型风险数据丢失、数据不一致、发布期间超时。 4. 对于“不停服”目标给出双写、异步回放、开关切流的具体步骤并说明如何回滚。 5. 最终输出一个任务清单每项任务包含序号、负责人角色、任务描述、预计工时、依赖关系。在真实项目里这条提示词输出的计划我会再人工过一遍把依赖关系理顺后直接粘贴进项目管理工具。不要指望它给的时间估算特别精准但阶段划分和风险点提示非常有价值。尤其是数据迁移策略AI 对“双写”“异步回放”这类固定模式很熟悉生成出来的步骤比很多开发临时拍脑袋想出来的方案完整得多。4. 实操过程一个订单、库存、营销耦合系统的拆分全记录4.1 案例背景去年遇到的一个中型电商平台项目非常典型。系统还是单体应用Spring Boot 2.x MySQL Redis整体代码量六十万行出头。核心模块包括用户、商品、订单、库存、营销、支付。团队组织结构是分成用户组、订单组、营销组三个后端小组。痛点非常明确每年大促期间营销改一版活动规则订单和库存都要跟着发布因为一条优惠逻辑散落在好几个模块里。经常出现订单已经创建、但营销数据没更新导致对账不平的情况。当时定的拆分目标有三条一是大促期间订单和营销能够独立发布互不阻塞二是不能超卖库存变化必须准确三是迁移过程尽量不停服不能丢数据。4.2 我实际使用的输入信息我没有直接把代码库丢给 AI而是先整理了一份精简信息包。模块清单里写清楚每个模块的核心职责和对外接口表格结构重点列了订单表、库存表、优惠券表、营销活动表的主外键关系核心业务流程写了下单和促销两条主链路每条链路都标出涉及的数据表与模块。典型的下单流程在最开始整理出来时有七个同步调用环节用户校验、商品查询、库存扣减、优惠计算、订单创建、支付发起、消息通知。这一步信息整理本身就让团队自己吃了一惊原来一次简单的下单背后有这么多串行依赖。4.3 结果、决策与修正AI 基于这个输入给出的初筛方案并不复杂用户服务、商品服务、库存服务、订单服务、营销服务、支付服务外加一个消息中心。整体方向是对的但有两个点我们做了人工修正。第一个是营销和订单的边界。AI 建议把营销服务独立出来但同时标记这是一个阻塞级别的耦合点下单时既要去营销服务计算优惠又要扣库存涉及三个服务的同步调用。我们最终没有把营销塞回订单服务而是做了一个关键决策将促销优惠计算改成异步化订单服务先按基础价格创建订单营销服务异步计算出最终优惠金额后回写。这样下单链路从三个同步服务降到两个而营销规则再怎么改也不会阻塞订单主流程。这个决定好做好但需要营销侧接受“优惠计算不是实时的”这个约束。第二个是库存预占。AI 给的方案有两种一种是库存独立成服务所有扣减都走远程调用另一种是把库存内嵌到订单服务里。前者性能风险高后者又会导致库存服务名存实亡。最后的落地方案是库存服务保持独立但扣减操作改为“前置预占 异步确认”在下单时先锁定库存支付完成后再真正扣减。这个流程里最关键的其实是“超时释放”一旦用户不支付预占库存必须自动释放。AI 生成的方案里原本没有这一环是我在事务复审时发现后补上的。整个评审过程中AI 给我们最大的帮助不是那个候选清单而是让我们在动手之前就把所有跨服务事务、共享表、同步调用链全部列在了台面上。以前开架构评审会总有人临时想起“对了我们这里还有个隐藏依赖”现在这种“临时想起”已经没有生存空间了。5. 常见问题与排查技巧实录5.1 结果看起来合理但根本落不了地这是 AI 辅助拆分时遇到最多的问题。AI 输出的候选服务边界从业务角度完全合理但落不了地。典型场景是它把一个通用能力拆成一个独立服务而这个通用能力被其他好几个服务同时强依赖。比如某个系统有一个规则引擎商品、营销、价格三个模块都在用AI 会一本正经地说“建议将规则引擎独立成服务”结果三个核心服务全部强依赖它部署的先后顺序成了噩梦。我的对策是在提示词里显式加入一条约束如果多个领域共享某个通用能力请评估是否应该保留共享内核而不是强行拆开。同时我要求 AI 标注每个候选服务的“共享依赖方数量”一旦超过三就必须提供替代方案。能明显感觉到加了这条约束后AI 的输出从一个“理想架构”变得更像一个“可实施架构”。5.2 服务粒度忽大忽小另一个常见问题是 AI 有时候会把服务拆得过粗有时候又拆得过细。有一次它把“营销”拆成了“优惠券服务”“满减服务”“积分服务”。这在我这个项目里根本没有意义一个营销团队五个人维护三个微服务纯粹是折腾自己。针对这个问题我后来会在初筛提示词里补一句候选服务总数不得超过团队人数的一点五倍且不得少于三个。如果 AI 输出的服务数量超出这个范围一定要让它重新合并。在粒度把控上我还有一个经验如果两个服务在可预见的未来里需求和部署节奏总是同步的那就不要拆。拆服务的意义不是让代码变少而是让“各自独立发布”成为可能如果永远一起发版拆了十有八九是负担。5.3 提示词本身的维护与迭代提示词表面上是文本实际使用久了你就知道它跟代码一样需要维护。我自己的提示词文件放在团队知识库里加了版本号每次修改都记录原因。比如“提示词 v1.2 新增约束共享依赖方数量必须标注”“v1.3 修改输出格式增加置信度字段”。我也建议团队给提示词配三到五个“评测集”。拿一套已经拆完的经典系统作为测试样例每次更新提示词后先跑一遍看看输出是否稳定。这听起来有点工程化但只有这样才能保证你团队用的提示词不是“碰运气”。我自己从 AI 辅助拆分里吃到红利靠的就是把提示词当长期资产来经营。6. 用 AI 做拆分评审的额外技巧6.1 自动生成评审清单与质疑列表架构评审会上最尴尬的事情就是所有人对着 PPT 沉默没人提得出问题。AI 可以帮你打破沉默。在开评审会之前把候选拆分方案丢给 AI让它专门生成一份“评审质疑清单”问题越尖锐越好。比如“库存服务独立后如果订单服务频繁调用扣减接口性能瓶颈怎么解决”“营销服务异步计算优惠如何保证用户端看到的金额是一致的”我试过之后效果非常好。这份清单拿过去每个人都有话可说因为问题都是针对方案本身的不涉及任何面子问题。评审会从“走过场”变成了真正的方案推演。6.2 让 AI 扮演不同角色的反向质询这个技巧更进阶一点但你可能会喜欢让 AI 扮演不同的角色来对拆分方案发起质询。比如让它扮演“负责数据库的 DBA”、扮演“运维同学”、扮演“刚入职的新人开发”分别从各自视角指出方案中的隐患。DBA 视角关心的是跨服务查询多了之后怎么做数据同步运维视角关心的是拆完服务后监控链路和日志聚合怎么做新人开发视角关心的是“我接到一个需求第一行代码应该写在哪个服务里”。这几个问题其实是架构方案最容易忽略的角度AI 扮演角色后会自然而然地输出非常具体的问题对你的方案查漏补缺非常有用。6.3 不停服迁移场景中的 AI 辅助设计我最后想分享的是不停服迁移的 AI 辅助经验。很多团队对“迁移”的理解是“找个窗口停服跑脚本开服”理由是“系统太复杂了不停服根本动不了”。AI 对这个问题倒是没有偏见你只要在提示词里明确要求“不准停服、不丢数据”它就会自动去补双写、校验、灰度切流这些环节。我通常会先让 AI 识别所有需要双写的表以及每张表的写入方和消费方再让它输出一个双写开关和回滚策略的模板。这个过程要特别注意“写偏斜”问题双写时新老库的数据不一致需要有一套对账任务找到差异并自动修复。这部分是我人工补上的提示词约束之一加完之后 AI 的迁移方案明显更贴近真实生产环境。我个人在实际操作中的体会是AI 辅助微服务拆分最大的价值不是让你少动脑而是让你在动脑之前先把所有应该被考虑到的信息摆在桌面上。它把过去依赖“老师傅经验”的架构分析变成了一套可复制、可评审、可迭代的工程方法。所以别指望它替你做最终决定但完全可以把它当成一个记忆力极好、不知疲倦的分析助理。只要你把问题描述准确它反馈给你的东西往往比你想的要多得多。
