干了十几年架构，我最怕的不是新技术学不会，而是那种“看起来什么都能跑、一改需求就全线崩溃”的遗留系统。去年公司启动核心业务中台重构，二十多个业务模块、三百多张表、四个后端团队同时维护，我第一次尝试用 AI 来辅助微服务划分，效果比我预期的要好很多。这篇文章把整个过程中沉淀下来的方法论、四套可以直接抄的微服务拆分 AI 提示词，以及踩过的坑一次性整理出来，献给正在做系统拆分、边界梳理或者准备做微服务迁移的架构师和资深开发。
先说明一点：我不是来吹“AI 取代架构师”的。AI 在微服务划分里的真实价值，是帮你把原本需要两周才能摸清的隐藏依赖、数据耦合、事务边界，压缩成几小时就能审阅的候选方案。它能大幅降低信息收集成本，但最终拍板的还是人。下面我先把拆分这件事本身讲透，再给你能直接用的工具。
1. 为什么微服务拆分那么难：先搞清楚问题，再谈 AI
1.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调用B，B又调用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 辅助微服务拆分最大的价值，不是让你少动脑，而是让你在动脑之前，先把所有应该被考虑到的信息摆在桌面上。它把过去依赖“老师傅经验”的架构分析，变成了一套可复制、可评审、可迭代的工程方法。所以别指望它替你做最终决定，但完全可以把它当成一个记忆力极好、不知疲倦的分析助理。只要你把问题描述准确，它反馈给你的东西，往往比你想的要多得多。
