我们直接进入正题。前阵子帮朋友梳理一个老项目的架构他那个系统已经跑了六七年业务代码越堆越多一个单体应用里塞了几百张表、几十个定时任务、十几个消息消费者。每次发版都是生死时速测试一轮下来光是回归就要两三天。他想拆微服务但打开架构图对着那一团乱麻完全不知道从哪里下手。后来我给他出了一套AI辅助拆分的提示词方案配合我们手动做领域分析和依赖梳理前后花了两周时间就把拆分方案定了下来。今天把这套方法和完整提示词整理出来希望能帮到同样在拆分泥潭里挣扎的朋友。先说清楚一件事AI在微服务拆分里到底能干什么、不能干什么。我自己实践下来的结论是AI非常适合做信息整理、边界识别、依赖分析和方案初稿生成这类结构化工作但它没法替代架构师做真正的业务判断和战略决策。所以正确姿势是把AI当成一个极聪明的架构助理而不是把拆分决策直接丢给它。下面这套方法论就是把AI的能力和人的判断结合起来既快又稳。1. 为什么微服务拆分这么难核心矛盾与常见误区1.1 拆分的本质不是技术问题而是业务边界的识别问题很多人一上来就纠结该用Spring Cloud还是Dubbo、该上K8s还是用虚拟机、服务间该用Feign还是消息队列。这些当然是要考虑的事情但在我看过的大量拆分案例里真正让项目翻车的从来不是技术选型而是边界切错了。什么叫边界切错就是你辛辛苦苦拆出来的服务上线之后发现两个服务之间互相调来调去一个查询请求要跨五六个服务才能返回结果分布式事务满天飞数据一致性搞得头大。本质上是因为你在按技术实现或数据表归属来切分而不是按业务能力和业务边界来切分。这里最经典也最害人的误区有三个第一个误区是按数据库表拆。很多人觉得用户表相关的操作就归用户服务订单表相关的就归订单服务这样看似清爽但实际上业务逻辑根本不是按表组织的。一个订单创建动作可能同时要读用户信息、扣库存、算优惠、发通知你把表拆开了业务逻辑也被撕碎了。第二个误区是按组织架构拆。前端组对应的接口拆一个服务后端组对应的逻辑拆一个服务测试组关注的模块再拆一个服务。这纯粹是拿技术团队的管理边界去代替业务边界最后得到的是一堆互相依赖的分布式单体。第三个误区是拆得太细。刚拆分的时候兴奋得很恨不得一个类就是一个服务结果运维成本爆炸几百个服务每个都要配置、监控、协调发版一个小团队根本玩不转。那正确的做法是什么是从业务领域出发识别出清晰的业务能力边界再根据团队的运维能力决定拆分的粒度。这里面最有用的方法就是领域驱动设计DDD里的限界上下文Bounded Context概念。1.2 AI辅助拆分的整体思路让AI做信息整理让人做价值判断在介绍提示词之前先把我这套AI辅助拆分方法的整体流程摆出来。我把它分成五个阶段第一阶段是信息收集与结构化。把现有系统的模块清单、核心功能列表、数据表关系、接口文档喂给AI让AI帮你整理出一份结构化的系统现状说明书。这个阶段AI的输出质量很大程度上取决于你输入信息的完整度。第二阶段是业务能力识别。让AI基于你提供的功能列表和数据关系给出候选的业务能力分组建议。这一步AI给出的结果大概率不是最终答案但它的价值在于提供一个高质量的起点你只需要在这个基础上做调整比自己面对一张白纸苦想高效得多。第三阶段是依赖关系梳理。让AI识别出各个业务能力之间的数据依赖、接口依赖和事务依赖用AI生成依赖矩阵。这一步能让你直观地看到哪些业务能力是强耦合的哪些是天然独立的。第四阶段是拆分方案生成。基于前面几步的结果让AI生成多个候选的拆分方案。注意是多个方案而不是一个标准答案。因为方案没有绝对的对错只有不同场景下的取舍多方案对比才能做出更合理的决策。第五阶段是方案审查与迭代。把AI生成的方案拿给团队里的核心成员评审把评审意见反馈给AI让AI修订方案。经过两三轮这样的循环最后产出的方案基本就是可落地、经得起推敲的。这套流程里AI在每个阶段扮演的角色不一样提示词自然也不能一套吃遍天。下面我按阶段把提示词逐一拆开讲。2. 核心细节解析分阶段提示词的设计思路与实操要点2.1 阶段一用系统现状说明书提示词打好信息基础我见过很多人用AI辅助拆分上来就甩一句帮我拆微服务然后AI回了一堆正确的废话。问题出在哪出在你没给AI提供足够的上下文信息。AI不是算命的它没法凭空知道你的系统里到底有什么。所以在第一轮对话里要做的不是让AI给方案而是让AI帮你做信息结构化。这时候的提示词应该引导AI完成三件事整理模块清单、识别核心业务域、标注数据关系。我用过比较顺手的提示词是这样的你是一位资深的企业架构师拥有15年以上的大型系统微服务拆分经验精通领域驱动设计DDD、事件风暴Event Storming和复杂系统架构演进。 我现在有一个老旧的单体系统需要进行微服务拆分在正式讨论拆分方案之前我需要先对系统现状做一次全面的梳理。下面是我的系统的一些基础信息请你帮我整理出一份结构化的系统现状说明书。 系统名称XXX客户管理系统以下信息为业务同学和开发同学共同提供的概览 【核心业务功能列表】 1. 客户信息管理支持客户建档、编辑、查询、导入导出包含企业客户和个人客户两种类型。 2. 合同管理支持合同创建、审批流、电子签章、合同归档和到期提醒。 3. 订单管理支持订单创建、订单审核、订单发货、订单售后。 4. 财务结算支持应收应付管理、发票管理、回款核销、账龄分析。 5. 权限管理支持用户管理、角色管理、菜单权限分配、操作日志。 6. 通知中心支持站内信、邮件、短信三种渠道的通知发送和模板管理。 7. 报表中心提供销售报表、订单统计、回款统计等十余张固定报表。 【数据表概要】 系统共有数据库表136张主要包括客户表、客户联系人表、客户等级变更记录表、合同表、合同明细表、合同审批记录表、订单表、订单明细表、订单状态变更记录表、发票表、应收单、实收单、用户表、角色表、用户角色关系表、菜单表、通知模板表、通知发送记录表等。 【核心业务场景描述】 - 销售人员在系统中创建客户填写客户资料后提交审核审核通过后该客户成为正式客户。 - 销售针对正式客户创建合同合同需要经过销售主管、财务、法务三个节点的审批。 - 合同审批通过后可以关联创建订单订单发货后生成应收单客户回款后进行核销。 请你基于以上信息完成以下任务 1. 识别出系统的核心业务域并说明每个业务域包含的关键业务能力。 2. 对于每个业务域列出可能涉及的核心数据实体并标注实体之间的关系类型一对一、一对多、多对多。 3. 识别出当前信息中存在的模糊地带或缺失信息用提问的方式引导我补充。 4. 最后用表格形式输出一份系统现状说明书的骨架方便我后续继续填充细节。这个提示词的设计思路有几点值得展开讲讲第一我给了AI一个明确的角色设定。这很重要因为角色设定决定了AI的输出视角和语言风格。你需要的是一个懂架构、懂DDD的老架构师在跟你对话而不是一个只会列点的大语言模型。第二我把已知信息做了分类规整。功能列表、数据表、业务场景三类信息分开给方便AI分别建模。其中业务场景描述尤其重要因为它是连接静态的功能/表与动态的业务行为的桥梁AI能从中识别出事件流和状态流转这比单纯看表结构有用得多。第三我明确要求AI识别模糊地带并反过来提出问题。这一点很多人容易忽略。AI辅助方案设计的价值不只在于输出还在于帮你想清楚你没想清楚的问题。让AI主动问你要信息相当于一次免费的架构评审。实操下来这个阶段AI输出的质量如何我给你打个底如果信息给得充分AI整理出来的业务域划分和实体关系基本能达到一个中级架构师的水准准确率在七八成左右。剩下两三成需要你来纠偏特别是那些系统里有但你没写进输入里的隐藏逻辑。2.2 阶段二用业务能力地图提示词识别候选业务边界拿到结构化的系统现状说明书之后第二阶段就要开始真正的边界识别了。这一阶段的提示词核心目标是让AI基于DDD的思想给出候选的限界上下文划分。我推荐的提示词长这样你已经了解了我这个客户管理系统的现状说明书。接下来我们进入微服务拆分的关键环节识别限界上下文。 在DDD中限界上下文是业务的边界它定义了领域模型在特定上下文中的含义。请基于以下原则来帮我识别候选的限界上下文 1. 高内聚低耦合同一上下文内部的业务逻辑关联紧密不同上下文之间的依赖尽可能少。 2. 业务能力独立性每个上下文应该对应一组清晰的、可独立演进的业务能力。 3. 数据所有权每个上下文应该拥有自己独立的数据模型尽量避免跨上下文直接访问数据表。 4. 业务语言一致性同一上下文内部使用的业务术语应该保持一致避免歧义。 5. 事务边界考虑强一致性的需求应该尽量放在同一上下文内允许最终一致的场景才能跨上下文。 请基于以上原则完成以下任务 1. 识别出候选的限界上下文清单并为每个上下文命名。 2. 对每个上下文列出它包含的核心业务能力、核心实体和关键业务规则。 3. 分析上下文之间的依赖关系标注是同步调用还是异步事件依赖并说明理由。 4. 特别标注出你认为是困难决策点的地方比如哪些业务能力边界模糊、哪些实体被多个上下文引用等并给出你的倾向性建议。 5. 最后用mermaid格式画出这些上下文之间的关系图。注意上面第5点要求mermaid格式但我在这里要特别说一下生成博文时不能用mermaid图但你在实际和AI对话的时候让AI画依赖关系图是非常有用的。你可以在和AI对话时让它输出mermaid格式的图然后再用工具渲染查看这会大大提升你对方案的理解效率。我自己的习惯是让AI先把上下文清单用表格输出再生成关系图两相对照着看。说回提示词本身。这个阶段有几个输出质量的关键变量第一个变量是你对现状说明书的整理程度。如果阶段一的信息结构化做得扎实那么阶段二AI给出的限界上下文划分会相当靠谱。我实测下来大部分业务域的识别精度能达到九成以上因为它本质上是在做模式匹配——把一个完整的业务功能列表聚合成有限几个内聚的组这是大语言模型极为擅长的。第二个变量是你对业务规则的表达完整度。要注意提示词里强调的核心业务规则——比如合同审批必须经过三个节点、订单发货后自动生成应收单这类规则AI理解得越充分给出的边界判断就越准。因为微服务拆分本质上有一个隐藏约束强一致性的业务规则应该待在同一个服务里。第三个变量是AI的困难决策点标注质量。我要求AI主动指出模糊地带这一步很关键。因为拆分方案争议最大的往往就是那些两不管或两头都沾的业务能力。AI能提前把这些点标出来你后面评审的时候就有了讨论的焦点不会跑偏。2.3 阶段三用依赖矩阵提示词把隐性耦合挖出来如果说前两个阶段是在做分那第三阶段就是在做合的反向验证——检查哪些东西一旦拆开就会血流成河。我在实际项目中见过太多表面清爽、实则耦合严重的拆分方案两个服务看着职责清晰结果底层共用一张数据表或者业务逻辑里偷偷跨服务查了对方的数据。这些隐性依赖在方案评审时根本看不出来只有到了开发阶段才集中爆雷。所以阶段三的目标是让AI帮你做一次全面的依赖分析生成一份依赖矩阵。提示词如下基于我们前面确定的候选限界上下文清单现在请你对这些上下文之间的依赖关系做一次全面的分析目标是生成一份详细的依赖矩阵。这份矩阵将用于评估拆分方案的可行性和风险。 请从以下几个维度逐一分析每对上下文之间的依赖 1. 数据依赖这两个上下文是否共享或交叉访问对方的数据表是否存在A上下文直接读取B上下文的表的情况 2. 功能依赖A上下文的业务逻辑是否依赖B上下文提供的功能这种依赖是同步调用如RPC、HTTP还是异步事件如MQ 3. 事务依赖这两个上下文之间的业务操作是否需要强事务保证还是可以接受最终一致性 4. 流程依赖是否存在跨上下文的业务流程编排流程的发起方和参与方分别是谁 5. 实时性要求A上下文对B上下文的数据时效性要求是什么是强实时毫秒级、准实时秒级还是异步可接受分钟级延迟 输出的依赖矩阵请使用表格形式每一行描述一个依赖关系包含以下列依赖发起方、依赖目标方、依赖类型数据/功能/事务/流程、调用方式同步/异步、实时性要求、当前耦合程度的评估高/中/低、拆分后建议的解决方案共享API/消息事件/数据复制/合并上下文/其他。 如果发现两个上下文之间存在高耦合依赖无法通过合理的改造手段解耦请明确指出并建议在拆分方案中把这两个上下文合并为一个服务。这个提示词的巧妙之处在于它表面上让AI生成依赖矩阵实际上是在逼AI做一次拆分的可逆性测试。我给你打个比方微服务拆分就像重新装修一套老房子。你当然可以把每个房间都拆开重做但前提是水电管线要理清楚。如果两个房间共用一套水管你贸然拆墙就会导致整个屋子断水。依赖矩阵就是帮你提前发现共用水管的工具。实操中这个阶段会有两个高频发现一个是你发现某些看似独立的业务能力实际上共用了一张数据表这时候要么把表做垂直拆分要么把这两个业务能力合并成一个服务另一个是你发现有跨上下文的流程编排需求比如订单发货后要同时更新库存、生成应收单、通知客户这时候就要决定是采用分布式事务不推荐还是改为事件驱动的最终一致性架构。我强烈建议在这个阶段把AI输出的依赖矩阵打印出来约上核心开发一起过一遍。你会发现每个人都能补充出AI没发现的隐藏耦合点因为真正的耦合存在了开发者的脑子里而不在代码和文档里。让AI先起个头再用人类的经验去补全这是效率最高的协作模式。2.4 阶段四用多方案生成提示词做方案对比与取舍依赖矩阵梳理完之后就可以让AI生成真正的拆分方案了。这里我要强调一个原则永远不要让AI只给你一个方案。为什么因为一个方案没法做对比你自己也很难发现其中的问题。而当你要求AI给出多个方案时AI会分别从不同角度去思考你反而能通过对比看到每个方案的优劣和底层逻辑。我的提示词是这样的基于我们在前面几个阶段已经完成的系统现状梳理、限界上下文识别和依赖矩阵分析现在请你生成微服务拆分的候选方案。 要求请给出三个不同风格的拆分方案每个方案的文件大小、服务个数、适用场景都要不同。三个方案分别是 1. 稳妥保守方案在现有系统可落地性最强的方案优先考虑改造工作量小、风险可控允许部分服务暂时保持较大的粒度。 2. 平衡推荐方案在业务边界合理性和落地可行性之间取得平衡的方案符合DDD的分区原则同时考虑团队的运维能力。 3. 激进前瞻方案完全按照理想的业务边界来拆分服务粒度最细适合团队人员充足、运维能力强的场景。 对于每一个方案请都包含以下内容 - 服务划分清单每个服务的名称、职责描述、包含的核心实体。 - 服务间调用关系标注每个服务依赖哪些其他服务以及调用方式同步/异步。 - 数据拆分策略每个服务独立拥有哪些数据表哪些表需要做数据迁移或数据复制。 - 拆分实施顺序建议先拆哪个服务、后拆哪个服务以及每个阶段的可验证里程碑。 - 风险评估该方案的主要技术风险、业务风险和团队管理风险以及对应的缓解措施。 最后请用一个对比表格来总结三个方案的差异包含以下维度服务总数、改造工作量高/中/低、上线周期预估、团队运维压力、扩展性、适用团队规模、推荐指数。并在表格之后给出你个人的推荐选项和理由。让AI生成三个方案的价值不只是多条路可走更深层的作用是通过方案的对比让你看清自己系统的本质约束。比如你可能本来倾向于稳妥保守方案但当你看到平衡推荐方案的服务划分清晰太多只是多付出了两成工作量时你的决策可能就会改变。这种看到选项才明确偏好的体验是直接给一个方案很难带来的。再补充一个实操细节我通常会让AI在每个服务后面标注拆分的可逆性。什么叫可逆性就是这个服务如果拆分失败了能不能低成本地并回去。拆分里面有个重要的风险控制思路——宁可先合并后分离也不要先分离后合并。AI会帮你把这个排序逻辑融入方案比如它会建议先把通知中心这种低耦合、高复用的模块拆出来而不是一上来就动合同-订单-财务这个高耦合三角。2.5 阶段五用评审助手提示词做方案审查与迭代收尾方案初稿出来之后最关键的一步是评审。很多人拿到AI的方案觉得哇挺好的就直接拿去开发了这是很危险的做法。AI生成的方案再漂亮也是基于你给它输入的信息做的推演它不知道你的真实代码里有哪些历史遗留问题也不知道你的团队擅长什么、不擅长什么。所以我设计了评审环节的提示词用法是把AI生成的方案反馈回去让它以挑战者身份帮你看漏洞现在请你换一个角色你不再是架构方案的提供者而是一个专门负责找问题的微服务架构评审专家。你拥有丰富的微服务落地经验经手过多个大型系统的拆分和重构项目尤其擅长发现方案里的隐患和坑。 下面是一个候选的微服务拆分方案已附上服务清单、服务间依赖关系、数据拆分策略等信息。 请你从以下角度对方案进行批判性审查尽量找出其中可能存在的问题 1. 服务粒度是否合理有没有服务拆得过大、职责混杂有没有服务拆得过细、独立价值不充分 2. 数据一致性风险哪些调用链路上存在分布式事务风险如果中间宕机或消息丢失会产生什么结果如何补偿 3. 性能与延迟问题哪些核心业务链路会因为跨服务调用而显著变慢是否存在循环调用或深层调用链 4. 部署与运维复杂度该方案的服务数量对团队的运维能力要求如何有没有简化空间 5. 未来扩展性该方案是否考虑了后续业务的发展方向有哪些扩展点 6. 演进与回滚策略如果某个服务的拆分效果不理想有哪些回滚或调整的策略 请逐条列出你发现的问题每个问题标注严重程度高/中/低并给出具体的解决方案建议。最后请给出你对该方案的总体评价和修改建议。这个反向评审提示词的效果特别好。因为AI在生成方案时是顺着你的思路走的容易沿着同一个方向越走越远但当你让它反向找问题时它会努力发现方案里的不确定性、遗漏和风险。我实际用过之后AI找出的问题里最有价值的一类就是数据一致性问题的推演。比如它会指出某个跨服务的业务流程里存在一个竞态条件如果用户在下单的同时修改了收货地址那么订单服务拿到的地址可能是旧地址。这种问题靠人肉评审很难发现因为人的思维惯性会默认下单和改地址是同一时间发生的概率很低但AI不会放过这种逻辑漏洞。评审结束后你再把评审意见和问题清单反馈给AI让它对方案做修订。如此往复一般两到三轮之后方案就会从看起来合理进化为经得起推敲。我经验里这个迭代过程通常能把方案的隐含风险数量降低一半以上。3. 实操过程与核心环节实现从提示词到落地拆分的完整记录3.1 环境准备工具选型与AI对话管理的最佳实践在正式跑这套流程之前先花点时间说说工具准备。这决定了你后面跟AI协作的效率。我的建议是首选Claude系列模型其次GPT-4o或国产的DeepSeek/Kimi都可以。为什么首选Claude因为它在长文本理解、结构化输出、以及多轮对话的一致性方面做得比较出色。微服务拆分是一个非常吃上下文信息量的场景你得把完整的系统现状信息、依赖矩阵、评审意见都保持在对话窗口里模型的上下文容量和理解能力直接影响方案质量。如果你手头没有现成的AI工具用各家大厂的免费版本也完全够跑通这套流程。差别主要在于输出稳定性和上下文长度不影响你学方法论。另一个值得重视的点是对话的组织方式。我强烈建议你按阶段分多个对话窗口而不是在一个窗口里从头聊到尾。比如阶段一用一个窗口阶段二新建一个窗口并把上一轮的关键输出作为上下文粘过去。这样做的原因有两个一是避免对话太长导致AI前面信息遗忘或注意力漂移二是每个阶段的输出可以单独保存归档方便后续回看和复用。3.2 完整提示词串联五段式协作流程实战演示下面我用一个实际跑过的案例来演示整套提示词怎么串联起来用。这个案例尽量简化但保留了真实项目的关键特征。假设有一个电商后台系统核心功能包括商品管理、订单管理、库存管理、用户管理、营销活动、支付结算、物流管理、消息通知。数据库大约90张表。按我的流程第一轮我先把系统的功能清单、核心表清单和关键业务规则喂给AI让它输出系统现状说明书。AI跑出来的结果里业务域被分成了商品域、交易域、营销域、用户域、支付域、履约域、基础支撑域七个大块。其中它把库存管理放进了商品域而不是交易域理由是从数据归属看库存表与商品表的关系更紧密。这个判断我认为是合理的因为库存本质上是通过商品ID来组织的归属于商品域在拆分时数据迁移成本更低。第二轮让AI识别限界上下文并输出上下文关系图。AI给出的候选上下文包括商品上下文、库存上下文、价格上下文、订单上下文、支付上下文、营销上下文、用户上下文、通知上下文、权限上下文等十二个。每个上下文都标注了核心实体和与其他上下文的依赖关系。这里面有一个决策点被AI特别标注了出来价格上下文。因为在真实系统里价格可能是商品的一部分基础售价也可能跟营销活动强相关优惠价、活动价还可能跟用户等级相关会员价。到底把它归到哪个上下文里AI给出了倾向性建议拆成独立的价格服务。第三轮做依赖矩阵时AI给出了一个让我眼前一亮的分析结果。它识别出营销活动和订单之间存在优惠券使用依赖但当前系统里优惠券的核销逻辑是写在订单服务代码里的接口上又调用了营销服务的接口属于典型的代码逻辑归属和数据归属不一致。这种不一致如果不提前发现拆分时就会出现蛋鸡问题——订单服务拆出去后没有优惠券核销逻辑营销服务拆出去后又没有订单数据来核销。第四轮生成三个候选方案。稳妥方案是切成7个服务平衡方案切成11个激进方案切成16个。对比表格里AI给推荐的是平衡方案理由是团队规模约15人服务数量控制在11个左右每个服务有2-3名核心维护者既能保证业务隔离性又不会让运维压力过大。第五轮做方案评审时AI挑出了一个高严重度问题在平衡方案里支付服务与订单服务采用同步调用确认支付结果但支付这个概念包含发起支付和支付回调两个语义如果两者都走同步调用高并发抢购场景下会出现大量超时重试导致订单服务和支付服务互相拖垮。它建议把回调改成基于MQ的异步事件驱动配合幂等设计和本地消息表来实现最终一致性。把这几轮串起来看你会发现AI在整个过程中承担了大量繁琐但高价值的结构化工作信息整理、边界推演、依赖分析、方案生成、风险识别。我的角色则是确认它每一步的输出是否符合业务实际在关键决策点上拍板定案。3.3 关键环节拆解数据拆分策略与拆分顺序的决策逻辑在所有拆分环节中最需要人为介入判断的有两块数据拆分策略和拆分实施顺序。这两块AI能提供参考但最终决策必须靠人来拍板。先讲数据拆分。微服务拆分要求每个服务独立拥有自己的数据存储不能共库共表。但现实是老系统里A服务要用的数据经常散落在B服务的表里。这时候有三种处理方式方式一是数据迁移。把属于A服务的数据表从原库迁移到新库中应用层同时改造代码来适配新数据源。适合数据结构相对独立、不与其他服务产生高频跨服务查询的表。方式二是数据复制。在A服务和B服务各自维护一份数据副本通过消息队列保持同步。适合那些读多写少且一致性要求不苛刻的维度数据比如商品基础信息、用户基本信息在每个服务里都存一份缓存副本。方式三是API访问。不复制数据B服务需要数据时实时调用A服务的API获取。适合需要保证强一致性的核心数据比如订单数据只能订单服务自己持有支付服务需要订单详情时就调用订单服务的接口。我的经验法则是能合并上下文解决的就先合并能通过API访问解决的就不做数据复制最后才考虑数据迁移。因为数据迁移是风险最高、工作量最大的操作它能晚则晚。再讲拆分顺序。我给一个通用的优先级参考第一批拆出来的是基础支撑类服务比如权限认证、消息通知、文件存储。这些服务和核心业务相对解耦独立价值明显拆分风险最低。尽早拆它们还能积累微服务化的经验为后续攻坚核心业务域打基础。第二批拆的是业务边界清晰、依赖较少的服务比如商品服务、营销服务。这时候团队已经有一定的微服务开发经验了可以开始处理有业务价值的模块。第三批才动核心高耦合业务域比如订单、支付、库存这个三角区。因为这里的拆分牵一发动全身需要前面几批拆分积累的信心和技术沉淀来支撑。最后一步是去掉老的单体应用外壳把剩余业务全部迁移到微服务架构下。这一步虽然放在最后但它才是真正的收尾。3.4 把提示词工程化为团队资产建立可复用的提示词库如果你的团队后续还要拆多个系统或者团队里有多个人在参与拆分工作那一定不要把提示词只留在自己的聊天记录里。我强烈建议把提示词当成工程资产来管理。我是这么做的在公司的知识库里建一个架构工具目录把上面这套五阶段提示词整理成文档每个阶段一个文件文件开头注明用途、输入要求和输出物然后在文件末尾附上实际使用时的示例对话截图。这样团队里的任何成员拿到这套文档照着执行就能跑出质量不低的方案。而我自己的项目里这套提示词已经迭代了快半年每个版本都有更新记录新增的坑和心得都写在文档里。把提示词模板化的另一个好处是你可以针对不同行业、不同类型的系统准备不同的变体。比如电商类系统、SaaS类系统、传统企业内部系统它们的业务特征差异很大提示词里的示例和引导词都可以微调。有了模板库面对新项目时就不用从零开始设计了。4. 常见问题与排查技巧实录4.1 AI给出教科书式方案怎么办用约束条件逼出真实方案很多人在第一轮试用这套提示词时会遇到一个问题AI输出的方案看起来非常标准逻辑也对但就是感觉太教科书了好像套用在任何系统上都成立。这其实是AI的典型舒适区表现。因为缺少足够的约束条件时AI会倾向于输出最普通的答案也就是它在训练数据里见得最多的方案形态。你需要的不是这种泛泛的方案而是真正贴合你系统特征的具体方案。解决方案是在提示词里增加足够的约束条件。除了功能列表和数据表你可以继续补充团队人数和技术水平、当前系统的技术栈比如是接手了一个老PHP系统还是Java Spring系统、核心业务链路的性能要求、历史架构演进背景、甚至现有的代码质量问题。这些约束条件会逼着AI在标准方案和你这个系统的方案之间做调和。另外还有一个好用的技巧让AI显式说明它做了哪些假设。在提示词里加一句请列出你在这个方案中做出的所有假设条件你会发现AI输出里的未确定项一下子浮出水面。对这些假设逐条去验证就是最有效的方案打磨方式。4.2 AI输出不稳定、前后不一致用结构化上下文对抗幻觉AI对话有一个让人头疼的问题你问同一个问题换个说法它可能给出不同的答案甚至同一个对话里前后两轮它的输出口径都对不上。这个问题在微服务拆分这种大型方案设计场景里尤其致命因为拆分方案要求前后逻辑一致、各部分的约束条件统一。我的应对方法是把关键的中间产物一直保留在对话上下文里。比如在阶段二确定了限界上下文清单后后续每一轮对话都先把这份清单粘到提示词开头让AI基于这份约定继续工作而不是依赖它自己记住上一次的输出。这样做能显著减少AI的随意发挥空间让它像遵循一份合同一样遵循你定下的约束。用术语来说这叫结构化上下文注入。具体操作也很简单你为每个阶段准备一个对话简报内容包括上一阶段的结论性输出、本阶段要完成的任务、以及所有已知的硬性约束。每轮新对话先把简报粘进去再开始提问。实测下来这个习惯能把AI输出的前后一致性从看心情提升到基本稳定。4.3 如何判断AI方案的质量评审检查单速查表最后分享一个我在实际工作中一直在用的AI输出质量检查清单。每次拿到AI生成的方案我都会对照着过一遍帮大家快速识别AI方案里哪些是可用的哪些是垃圾。检查维度检查要点常见AI翻车场景服务粒度服务职责是否单一、粒度是否均匀拆得过于零碎或某些服务过胖数据归属每个服务的数据表是否独立、不交叉多个服务共用一张表但方案里没提改造计划调用关系同步调用链路是否过深出现A调B、B调C、C调A的循环调用一致性设计是否识别出分布式事务风险点把强一致性业务放到了跨服务链路中演进顺序拆分步骤是否可验证、可回滚一上来就让拆核心业务域没有铺垫运维成本服务数量与团队规模是否匹配15人的团队拆出50个服务不自量力术语统一上下文名称和业务术语是否准确AI自造术语与实际业务黑话脱节如果你按这个清单检查下来AI方案能在大多数维度上达到及格线那就可以进入评审迭代环节。如果有一项或多项明显不及格别急着让AI修先想想是不是你的输入信息不够充分。我的经验是AI方案的质量问题大约一半是你给的输入信息不够另一半才是AI本身能力不足。4.4 我踩过的一个坑过度依赖AI导致方案看着美、落地难说个真实教训。有一次我接手一个项目时间很紧我图省事直接把AI生成的方案拿去做技术评审了。当时觉得AI给出的服务划分、技术选型、数据拆分都很合理文档也写得很漂亮大概率能过。结果评审现场直接被团队里负责订单系统的老哥问住了某个服务依赖的数据表在另一个服务里但AI建议的数据复制方案没考虑到这个表还有触发器在同步更新第三张表。这种细节AI根本不知道因为这种隐藏的触发器逻辑写在十几年没人动过的存储过程里。这件事之后我给自己定了一条规矩AI生成的方案必须经过一次与真实代码的对照验证才能进入评审流程。具体做法是拿到AI的服务清单之后安排团队里的人按清单去代码库抽查关键的数据表归属和接口调用关系确认AI的依赖分析与真实代码一致。这一步通常需要半天到一天的时间但它能帮你拦住至少一半的隐性风险。说到底AI辅助拆分的最佳姿势不是AI出方案、我执行而是AI出草稿、团队验证、人拍板。AI帮你把80%的信息整理工作和60%的方案推导工作干完了剩下的20%靠经验补齐这就是这套方法论的效率天花板所在。我在实际项目中用过很多次这套流程最深的体会是好的提示词不是越复杂越好而是越能榨出你脑海里那些模糊信息越好。每一轮对话AI都在帮你把你心里想但没说出来的事变成白纸黑字的方案。到后面几轮对话的时候你会发现一个很有意思的现象你花在写提示词上的时间往往比跟AI对话的时间还长。你想把约束条件写得越清楚AI的产出就越接近你真正想要的东西。这不奇怪架构设计本来就是一个把模糊变清晰的过程AI只是把你的思考速度放大了。最后再分享一个小技巧这五阶段的提示词不需要一次全跑完。如果你的系统相对简单、服务边界也算清晰跑完前三个阶段就可以手动合并上下文、直接得方案了。只有遇到那种业务纠缠特别深、历史包袱特别重的系统才有必要把五个阶段完整走一遍。把这套工具当成你的架构放大镜——需要多高的倍数你自己说了算。