企业官网建设流程全解析

做微服务拆分这件事，我踩过的坑比很多人写过的代码都多。早些年拆一个交易系统，光“订单到底算交易域还是履约域”就能吵两周；后来学会了用领域驱动设计的限界上下文去切，效率是高了，但每次面对一个几千个类、几十张核心表的“大泥球”业务系统时，脑子还是容易炸。直到我开始用AI辅助做这件事，才真正体会到什么叫“一个人也能开架构评审会”。

这篇文章我会把完整的思路、实操过程和可以直接复制的AI提示词都放出来。内容不玩虚的，核心是讲清楚三件事：为什么AI适合干微服务拆分的脏活累活、怎么设计一套能产出靠谱拆分方案的提示词、以及拿到AI输出之后怎么结合人工判断落地。

如果你正在负责一个复杂业务系统的微服务改造，或者在技术评审会上被“怎么拆、拆多细、为什么这么拆”这些问题反复折磨，那这篇文章值得你花十分钟认真看完。

1. 微服务划分为什么难，又为什么偏偏适合用AI做

1.1 微服务拆分的三大死穴

先说一个扎心的事实：大部分失败的微服务改造，不是死在技术选型上，而是死在“怎么划分服务边界”上。边界划不好，后面全是连锁反应。我见过最典型的三个死穴：

第一，业务边界模糊。业务系统不像技术组件，它没有清晰的接口和依赖关系，只有一堆散落在各处、互相调用、语义重叠的功能模块。比如“客户信息”这个概念，可能在订单、风控、营销、客服里都有，但每个系统的理解都不一样，落到数据库里又是完全不同的表结构。这种模糊性导致不管怎么拆，总有人不满意。

第二，依赖关系成环。老系统嘛，历史包袱都在，A模块调B，B调C，C又调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年以上经验的微服务架构师，精通领域驱动设计、事件风暴、分布式系统设计。下面我会给你一个复杂业务系统的基本信息，请基于这些信息完成微服务拆分方案的初步设计。

一、系统现状

1. 业务目标与核心价值：为中小型电商平台提供订单履约能力，支撑从用户下单到收货完成的全流程。
2. 当前模块清单（包括模块名和主要功能）：
   • 用户模块：注册登录、用户资料、会员等级、收货地址
   • 商品模块：商品SPU/SKU管理、类目属性、库存管理、价格管理
   • 订单模块：购物车、订单创建、订单状态流转、订单查询
   • 支付模块：支付单创建、支付回调、退款
   • 营销模块：优惠券、满减活动、限时秒杀
   • 发票模块：发票申请、抬头管理、开票状态查询
   • 物流模块：发货、快递单号回填、物流轨迹同步
   • 售后模块：退款申请、退货处理、售后原因记录
3. 核心业务流程描述：
   • 用户浏览商品后将商品加入购物车，提交订单时系统锁定库存并生成订单，用户完成支付后通知仓储发货，发货后用户可申请开票。
   • 若用户申请退款，则进入售后流程，售后完成后释放库存。
4. 核心数据实体（非完整表结构，仅关键实体）：
   • 用户、用户地址、会员等级
   • 商品、SKU、库存、价格、类目
   • 购物车项、订单、订单项、订单状态、支付单、退款单
   • 优惠券、活动、秒杀场次
   • 发票、发货单、物流轨迹、售后单
5. 现有技术栈：Java 17、Spring Boot 3、Spring Cloud、MySQL、Redis、Kafka、Docker。
6. 团队情况：4个后端开发小组，每组4~5人，各小组可独立维护2~3个微服务。

二、任务要求

请按以下步骤执行，不要在未完成上一步时直接跳到下一步：

步骤1：识别核心业务能力。基于上述信息，列出系统的核心业务能力（Business Capability），每个能力需包含：能力名称、能力描述、关联的核心数据实体、活跃度评估（高/中/低，说明判断理由）。

步骤2：进行领域分析与限界上下文划分。基于业务能力、业务流程和数据实体，识别领域事件和聚合根，划分限界上下文。对每个限界上下文，请说明：上下文名称、核心职责、关键聚合根、与之交互的其他上下文、上下文之间的关系类型（共享内核/防腐层/开放主机服务/发布语言等）。

步骤3：输出候选微服务列表。基于限界上下文划分，给出候选微服务列表。每个服务须包含：服务名称、服务职责、核心数据实体（注意标记哪些是自有数据、哪些是引用数据）、对外提供的核心API或事件、依赖的其他服务、独立部署/扩展的可能性和瓶颈、建议的存储选型（MySQL/Redis/自研等）。

步骤4：给出拆分方案评估。结合团队规模和数据一致性要求，评估每个候选服务拆分的优先级（高/中/低），并用表格说明：拆分该服务带来的收益、需要付出的成本、主要风险点、应对措施。

三、硬性约束与偏好（必须遵守）

1. 不允许因为技术便利而强行合并高内聚、低耦合的两个领域；也不允许为了追求服务数量而把强聚合、强事务的模型拆散。
2. 优先考虑数据一致性要求高的场景，避免跨服务强一致，如果不能避免，必须显式标出并给出补偿方案。
3. 服务的划分必须能映射到现有团队，确保一个服务只由一个小组主导维护。
4. 所有分析必须基于我提供的系统信息，如果信息不足，请明确列出你缺失的信息，而不是臆想。
5. 所有输出使用中文，表格统一为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划分出的限界上下文是这些：

说实话，第一次看到这个结果我是有点惊喜的，因为它没有把“支付”和“订单”合并成一个“交易服务”，而是分开处理，并且明确给“营销”单独划了一个上下文——这两个判断单独拿给有经验的人做，也是大概率会这么选的。但随后我仔细检查细节，也发现了几个明显偏差。比如AI把“购物车”和“订单”都放进了订单上下文，从业务上说可以接受，但从高频访问和存储压力角度看，“购物车”数据量极大、读写比极高，完全可以拆成一个独立的低成本缓存服务。这个取舍AI不会替你想到，因为它没有流量数据和运维数据。

这就回到我前面强调的定位问题了——AI能给你一个相当靠谱的基线方案，但流量、成本、团队情况这些“只有现场的人才知道”的信息，AI永远是缺失的，需要人手去补。

3.3 第二轮提示词：用追问机制把方案往深水区推

第一次输出可以作为“草案”。我对这份草案只做了一件事——把AI没考虑到的“购物车高并发场景”和“价格频繁变动的营销策略”作为补充信息，再让它重新评估。其实这就是提示词工程的迭代思维：把AI的输出当作“初稿”，把人的领域知识当作“修改意见”，再让AI基于修改意见生成“二稿”，来回揉两三次，方案的深度会显著提升。

我补充的内容是这样的：

补充信息：

1. 购物车是高频访问场景，读写比超过10:1，期望使用Redis存储降低数据库压力。
2. 营销规则变化频繁，运营团队每周都会有新的满减/折扣玩法，需要支持热更新。
3. 库存的锁定操作在订单创建时需要确保不超卖，你上一版把库存放在商品上下文里，请重新评估是否要独立库存服务。

请基于以上补充信息，重新审视限界上下文划分和候选微服务列表，重点说明哪些服务边界需要调整、为什么。

这一轮AI输出的变化相当明显。它把购物车从订单上下文拆出来，独立成“购物车上下文”，存储选型直接从MySQL改成了Redis+异步持久化。它把“库存状态管理”单独拆分成了“库存服务”，因为库存扣减的下单场景强一致诉求太高，不值得为了节省一个服务而引入分布式事务，这样做仓库WMS对接也会更干净。更关键的是，它重新调整了营销上下文的边界，建议所有价格计算都先调用营销服务的“报价API”，而不是由订单服务自己做规则判断，这样规则热更新就能独立上线而不会影响订单主链路。

这时候其实AI已经渐渐逼近了一个有经验的架构师会给出的方案。但你要记住，每次迭代都要把AI输出的逻辑链复制下来存好，这不仅是拆分方案，还是以后跟团队过评审会时的底稿。

3.4 把AI输出变成真正的方案：目标服务列表与依赖矩阵

经过两轮交互之后，我最后会把AI输出的候选服务列表整理成一份统一的“目标服务蓝图”。以这个电商订单系统为例，最终的核心服务列表长这样：

紧接着是一份依赖矩阵和事件清单，比如“订单创建成功后会发布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 快速排查表

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做微服务拆分，我的建议是：先花一个晚上把业务系统的基础信息整理成一份结构清晰的文档，然后用我这套提示词跑一遍，拿到初稿之后找两三个核心同事做半小时评审。你会发现，那个让你愁了好几周的“服务边界问题”，已经开始有眉目了。