AI 辅助架构设计：从审查到生成

敖正炀
0 阅读27分钟

概述

系列定位：本文是“AI 时代的架构决策”系列的第 1 篇，也是整个 Spring 知识体系中第五阶段“AI 原生与架构决策”关于“架构决策”部分的开篇。在此之前的软件架构哲学系列已系统建立了 ADR（Architecture Decision Record，架构决策记录） 框架与权衡分析方法，Spring AI 原生智能集成系列则提供了从模型接入到生产加固的完整工程工具链。本文正是在这两大基石之上，探索二者的融合——如何将 LLM（大语言模型） 引入架构设计工作流，构建一套可落地的 AI 辅助架构设计方法。

文章概述与核心要点

作为架构师，你可能经历过这样的场景：刚完成一份架构设计文档，心里没底——是否有遗漏的反模式？是不是还有更好的技术选型？要画出清晰的 C4 架构图，又要花费大半天时间。而团队里另一位架构师给你的审查意见，往往因为经验差异而质量波动。如果能有一位“永不疲倦的审查伙伴”，能在几秒内扫描你的文档，对照分布式系统设计原则，标记出缺少幂等设计的消息消费、未设置熔断的远程调用、缓存穿透风险，并给你一份结构化的审查报告和 ADR 草稿——这不再是科幻。利用 LLM 的强大推理能力，结合你已有的 ADR 决策框架和设计原则知识，你可以构建一套 AI 辅助的架构设计工作流：提交文档 → AI 审查 → 输出风险报告 → 提出选型建议 → 生成架构图代码。但这条流水线不是全自动的“黑箱”——AI 不理解你们公司的政治格局，不知道哪个团队正在裁员而无法维护某个中间件，也无法感受技术负责人的风险偏好。因此，正确姿势是“AI 提案，人类决策”。本文将以“电商系统重构”为场景，带你实操从架构审查、技术选型到生成架构图的完整 AI 辅助流程，让 AI 成为你架构决策中的超级辅助。

核心要点：

  • AI 架构审查：通过结构化审查 Prompt，LLM 自动检测反模式、违反设计原则之处以及与 ADR 的不一致，输出可转化为 ADR 的审查报告。
  • AI 辅助选型：输入业务需求与约束，LLM 结合多维权衡框架（CAP、性能/正确性、成本/弹性等）推荐技术栈并给出对比分析。
  • AI 生成架构图：从自然语言描述生成 C4 模型的 PlantUML / Mermaid 代码，加速文档化。
  • 人机协作模型：AI 提案 → 架构师评审 → 团队讨论 → 形成 ADR，强调人工终审的不可替代性。
  • 贯穿案例：电商系统架构审查与重构的全流程 AI 辅助，展示从审查到生成再到 ADR 记录的实际链路。

文章组织架构图

flowchart TD
    1[1. AI辅助架构设计全景与人机协作模型]
    2[2. AI架构审查: 从文档到结构化风险报告]
    3[3. AI辅助技术选型: 权衡推理与RAG增强]
    4[4. AI生成架构图: C4模型的自动化]
    5[5. 提示库建设与效能度量]
    6[6. 贯穿案例: 电商系统架构重构的AI辅助全流程]
    7[7. 面试高频专题]
    1 --> 2
    1 --> 3
    1 --> 4
    2 --> 6
    3 --> 6
    4 --> 6
    5 --> 6
    6 --> 7

图表说明：

  • 总览说明：全文7个模块从人机协作总览出发，依次深入审查、选型、生成图三个核心场景，再到提示库建设和综合案例，最后以面试题收尾。
  • 逐模块说明：模块1建立全局协作模型；模块2-4是三大AI辅助能力的深度拆解；模块5解决持续优化与度量问题；模块6用一个真实案例串联所有环节；模块7面试巩固。
  • 关键结论：AI辅助架构设计的核心不是替代架构师的思考，而是将架构师从重复性的审查、对比、绘图工作中解放出来，聚焦于更高层次的权衡与创新。将AI审查结果与ADR框架结合，是将AI能力制度化、可追溯的关键一步。

1. AI 辅助架构设计全景与人机协作模型

传统架构设计流程存在三大核心痛点：审查高度依赖个人经验，导致质量波动与知识盲区；技术选型对比耗时巨大，且容易陷入主观偏好；架构图绘制与文档维护消耗大量精力，往往滞后于实际演进。AI 的切入并非要取代架构师的决策角色，而是在信息检索、模式识别、初稿生成等认知辅助环节释放生产力。

我们提出 “AI 提案 → 架构师评审 → 团队讨论 → 形成 ADR” 的 人机协作架构决策模型。在此模型中，AI 充当**增强智能（Augmented Intelligence）**角色，负责：

  • 基于庞大的架构知识库识别反模式与设计原则冲突；
  • 根据结构化需求快速生成技术选型矩阵；
  • 将文字描述转换为标准化的架构图脚本。

架构师则专注于：

  • 审查 AI 输出，结合组织上下文（团队能力、政治因素、遗留系统限制）进行二次判断；
  • 主持团队讨论，将技术方案与业务战略对齐；
  • 做出最终决策并记录为 ADR，确保决策可追溯。

这一协作模型与软件架构哲学系列定义的 ADR 框架天然吻合：AI 负责加速“提案”与“发现”环节，而决策的“记录”“评审”“确认”环节仍由人类主导。

flowchart TD
    A[架构师提交架构文档/需求] --> B{AI辅助阶段}
    B --> C[AI架构审查]
    B --> D[AI辅助技术选型]
    B --> E[AI生成架构图]
    C --> F[结构化的审查报告]
    D --> G[技术选型建议与对比]
    E --> H[C4模型脚本]
    F --> I[架构师评审与筛选]
    G --> I
    H --> I
    I --> J[团队讨论与权衡]
    J --> K[形成ADR记录]
    K --> L[纳入知识库 提供RAG上下文]
    L --> B

图表说明：

  • 图表主旨概括：展示了人机协作架构设计的闭环流程，从 AI 辅助提案到架构师与团队的评审决策，最终沉淀为 ADR 并反哺知识库。
  • 逐元素分解：左侧为 AI 辅助阶段，产出审查报告、选型建议、架构图；中间是架构师主导的评审与讨论；右侧是最终决策记录与知识沉淀。
  • 设计原理映射：体现了软件架构哲学中 ADR 流程的“决策发现 → 选项分析 → 决策记录”三阶段，AI 主要强化了前两个阶段的效率。
  • 工程联系与关键结论：AI 的输出作为决策建议，而非最终决策；架构师的人工评审是保障质量与控制上下文风险的唯一屏障。

2. AI 架构审查：从文档到结构化风险报告

2.1 审查输入规范与文档分片策略

为让 LLM 有效审查，输入的架构文档需包含以下要素（基于分布式系统架构认知与设计系列中的“能力域×分层矩阵”）：

  • 系统上下文图（Context）：外部用户、外部系统、数据流方向。
  • 容器图（Container）：应用程序、数据存储、消息中间件及其交互。
  • 关键组件交互：核心业务流程的时序或协作描述。
  • 非功能需求描述：QPS、延迟、一致性要求、可用性级别等。
  • 已记录 ADR 编号列表：用于一致性检查。

由于 LLM 存在上下文窗口限制，需将大型文档按质量属性或架构模块拆分。例如：

  • 按质量属性拆分：抽取所有与“可用性”相关的设计（如集群部署、故障转移机制），提交审查，判断是否存在单点故障、缺少熔断等问题。
  • 按模块拆分：对订单服务、支付服务各自的组件图与数据流图分别审查。

利用 Spring AI 的 DocumentReader 和 TokenTextSplitter（详见 Spring AI 原生智能集成系列第 4 篇）可实现自动化分片。

2.2 审查提示工程

构建一个高精度的审查 Prompt 是核心。我们使用 Spring AI 的 PromptTemplate 管理模板（资源文件 arch-review.st），模板变量包括待审查内容与关注的质量属性。SystemMessage 定义审查角色、维度及输出格式，并嵌入 Few-shot 示例以校准模型。

SystemMessage 设计：

你是一位资深软件架构师，专长于分布式系统审查。
你的任务是审查提供的架构文档片段，严格依据以下设计原则（来自分布式系统架构认知系列）进行检查：
1. 故障隔离原则：服务间应使用熔断器、舱壁等模式；共享资源应有故障隔离机制。
2. 数据一致性原则：涉及状态的异步操作需具备幂等性；跨服务事务应明确补偿策略。
3. 高可用原则：无单点故障；关键路径应具备降级或兜底逻辑。
4. 缓存设计原则：缓存应有预热、穿透/击穿/雪崩防护。
5. CAP权衡原则：明确标注分区容忍性下的选择（CP/AP）及理由。
审查维度：反模式、违反原则、与已有ADR的不一致。
输出格式：严格的JSON，对应 ArchitectureReviewReport 结构。

Few-shot 示例嵌入（提示模板中硬编码典型反模式）：

示例输入：
“订单服务同步调用库存服务扣减库存，且无重试机制。”
示例输出：
{
  "risks": [{
    "severity": "HIGH",
    "pattern": "分布式同步调用无容错",
    "principle": "故障隔离原则",
    "description": "订单服务与库存服务间为同步RPC调用，若库存服务不可用，将导致订单服务线程阻塞，进而引发级联故障。缺少熔断和超时控制。",
    "suggestion": "引入Sentinel或Resilience4j实现熔断；考虑通过消息队列异步化解耦，并设计库存扣减的幂等消费。",
    "linkedAdr": null
  }]
}

通过 Spring AI 的 PromptTemplate 加载模板并填充变量：

// 模板文件 arch-review.st 包含上述SystemMessage和Few-shot
Resource resource = new ClassPathResource("prompts/arch-review.st");
PromptTemplate promptTemplate = new PromptTemplate(resource);
Prompt prompt = promptTemplate.create(Map.of("docSegment", segmentText, "qualityAttr", "availability"));
// 调用ChatClient
ChatResponse response = chatClient.call(prompt);

2.3 输出解析为 ArchitectureReviewReport 并与 ADR 联动

利用 Spring AI 的 BeanOutputParser 将 LLM 返回的 JSON 直接反序列化为 POJO：

public class ArchitectureReviewReport {
    private List<RiskItem> risks;
    // getters & setters
    public static class RiskItem {
        private String severity; // HIGH, MEDIUM, LOW
        private String pattern;
        private String principle;
        private String description;
        private String suggestion;
        private String linkedAdr; // 关联已有ADR编号，或null
    }
}

// 解析配置
BeanOutputParser<ArchitectureReviewReport> parser = 
    new BeanOutputParser<>(ArchitectureReviewReport.class);
ArchitectureReviewReport report = parser.parse(response.getResult().getOutput().getContent());

与 ADR 联动：

  • 一致性检查：若审查项检测到实现与已记录的 ADR（如 ADR-012 规定“订单支付超时采用TCC模式”）相悖，则 linkedAdr 自动填充“ADR-012”，提醒架构师关注漂移。
  • 新风险生成 ADR 草稿：对 HIGH 级别的新风险点，程序可自动构建 ADR 草稿：
public AdrDraft generateAdrDraft(RiskItem risk) {
    AdrDraft draft = new AdrDraft();
    draft.setTitle("ADR提案: " + risk.getPattern());
    draft.setContext("AI审查发现风险: " + risk.getDescription());
    draft.setOptions(List.of("方案A: " + risk.getSuggestion(), "方案B: 保持现状并增加监控"));
    draft.setRecommendation("方案A");
    return draft;
}

该草稿供架构师评审、修改后进入正式的 ADR 流程。软件架构哲学系列中定义的 ADR 标准模板（标题、背景、决策、后果）得以无缝集成。

2.4 边界与局限

LLM 审查存在误报（将合理设计判为反模式，如特定场景下有意使用的无重试快速失败）和漏报（隐蔽的并发 bug、模糊的边界条件）。它无法理解组织政治（某团队即将解散，不应再依赖其维护的组件）、团队技能储备（是否具备维护 Elixir 服务的能力）以及隐性历史决策（当年引入某个中间件是为了解决前 CT0 的偏好）。架构师必须对每条风险进行人工确认和上下文赋值。

AI 审查工作流图：

flowchart LR
    A[架构文档] --> B{文档拆分}
    B --> C[片段1: 可用性维度]
    B --> D[片段2: 性能维度]
    B --> E[...]
    C --> F[SystemMessage + Few-shot]
    D --> F
    E --> F
    F --> G[LLM 审查]
    G --> H[结构化报告 ArchitectureReviewReport]
    H --> I{风险级别}
    I -- HIGH --> J[生成ADR草稿]
    I -- MED/LOW --> K[人工标记]
    J --> L[架构师评审]
    K --> L
    L --> M[更新ADR知识库]

图表说明：

  • 主旨概括：描绘了从文档输入、智能拆分、携带设计原则的提示工程到产出可执行审查报告与ADR草稿的完整审查流水线。
  • 逐层分解：左侧是文档拆分策略，中间是注入分布式原则与Few-shot的LLM处理，右侧是依据风险等级分别处理的ADR联动。
  • 设计原理映射：体现了审查工作流将隐性架构知识（设计原则）显式化为Prompt工程，并将LLM的输出与正式决策框架（ADR）结构化的核心思想。
  • 工程联系：Spring AI 的 PromptTemplate 与 BeanOutputParser 是实现此流水线的关键技术基座；架构师在最后的评审节点保证了工程上下文的对齐。

3. AI 辅助技术选型：权衡推理与 RAG 增强

3.1 需求的结构化描述模板

技术选型的起点是将模糊的业务需求翻译为结构化的参数集。我们定义输入模板（同样使用 Spring AI 的 PromptTemplate）：

业务场景: {场景描述}
性能要求: QPS={qps}, P99延迟 < {latency}ms
数据规模: 存储量 {storage}TB, 日增长 {growth}GB
一致性要求: {强一致性/最终一致性/读己之写}
可用性级别: {99.9%/99.99%}
事务需求: {需要分布式事务, 无需分布式事务}
团队技能栈: {Java, Spring, Kafka, Redis...}
成本约束: 月度基础设施预算 < {budget}
已有基础设施: {现有中间件列表}

该模板确保了选型输入的可对比性与可复用性。

3.2 选型推理链与多维度权衡

LLM 基于输入参数进行多维度权衡，这些维度直接映射自分布式系统设计原则与权衡哲学的核心内容。选型 Prompt 的 SystemMessage 会明确要求模型从以下维度推理：

  • 一致性 vs 可用性（CAP 选择）：根据网络分区容忍需求，数据库应采用 CP（如 HBase、ZooKeeper）还是 AP（如 Cassandra、CockroachDB）。
  • 性能 vs 正确性：分布式事务选型时，是选择 TCC 的强一致性（性能开销大）还是 Saga 的最终一致性（需补偿），结合 P99 延迟要求权衡。
  • 复杂度 vs 可维护性：消息队列选型中，Kafka 的吞吐量优势是否抵消其运维复杂度，对于小规模团队，托管服务或更简单的 RabbitMQ 是否更合适。
  • 成本 vs 弹性：存储方案是否要冷热分离（热数据 Redis + 冷数据 MySQL），计算层是否采用 Serverless 达到成本弹性。

选型推理 Prompt 设计：

你是一个技术选型顾问。根据以下结构化需求，推荐一套技术组合。
你需要严格遵循多维权衡框架：
- 若一致性要求强，优先考虑CP系统；若可用性要求高于一致性，说明AP方案及补偿措施。
- 对消息中间件的选型，考虑性能/延迟与运维复杂度的平衡。
- 数据分层：热数据建议Redis，冷数据对象存储，并说明缓存策略。
- 结合团队的 Java + Spring 技能栈，避免引入无相关经验的异质技术。
输出格式为严格的JSON，包含：recommendedStack, alternativesComparison, riskMitigation。

LLM 输出片段示例：

{
  "recommendedStack": {
    "database": "MySQL (InnoDB) 分库分表 + Redis 缓存",
    "messageQueue": "Apache Kafka",
    "transaction": "Seata AT模式",
    "apiGateway": "Spring Cloud Gateway"
  },
  "alternativesComparison": [
    {"option": "TCC", "pros": "强一致性", "cons": "侵入性高，开发成本大"},
    {"option": "Saga", "pros": "松耦合", "cons": "需补偿逻辑，调试复杂"}
  ],
  "riskMitigation": "Redis 需配置集群哨兵+缓存预热；Kafka 需监控消费者lag；Seata AT 需注意全局锁冲突。"
}

3.3 结合 RAG 增强选型

企业内部的历史 ADR、性能测试报告、已有中间件列表是选型时至关重要的上下文。通过 Spring AI 的 RAG 能力（详见 Spring AI 原生智能集成系列第 7 篇），我们将这些文档存入向量数据库。在选型前，系统先检索与当前需求最相似的 ADR（例如“ADR-034: 采用 RocketMQ 替代 RabbitMQ 的决定”）和相关性能基准（“Kafka 集群在当前规格下吞吐上限 10w TPS”），将它们作为附加上下文注入 Prompt。这使得 LLM 的推荐不再是通识，而是企业环境感知的决策支持。

选型权衡推理链图：

flowchart TD
    A[结构化需求模板] --> B[需求解析与参数提取]
    B --> C[向量检索历史ADR与性能报告]
    C --> D[构建增强Prompt: 需求+历史上下文+权衡维度]
    D --> E[LLM多维度推理]
    E --> F[技术选型报告]
    F --> G[备选方案对比表]
    G --> H[架构师确认与团队讨论]
    H --> I[最终ADR记录]

图表说明：

  • 主旨概括：展示了从结构化需求出发，融合企业历史决策（RAG）和多维度设计原则的AI增强选型推理过程。
  • 逐元素分解：输入为参数化模板；中间通过检索增强注入企业特有的决策记忆与基准数据；LLM 按预设权衡维度推理，产出结构化报告；最终人工确认生成 ADR。
  • 设计原理映射：此流程将分布式系统原则（CAP、性能/正确性等）转化为可编程的评估维度，并通过RAG弥合了通用知识与组织特异性之间的鸿沟。
  • 工程联系：RAG 的集成使得 AI 选型从“理论最优”走向“环境匹配”，这是企业落地 AI 辅助决策的关键差异点。

4. AI 生成架构图：C4 模型的自动化

4.1 从自然语言到 C4 模型 PlantUML / Mermaid

架构师通常用点列表或简单描述勾勒系统轮廓：“一个电商系统，包含 Web 前端、API 网关、订单服务、库存服务、支付服务、MySQL、Redis 和 Kafka”。我们可以让 LLM 将其转换为标准的 C4 模型（Context, Container, Component）对应的 PlantUML 脚本。

生成 Container 图的 Prompt 设计：

你是一位架构图生成专家。根据以下系统容器描述，生成 C4 模型的 Container 图，使用 PlantUML 语法。
要求：
- 必须包含图例、容器边界（系统内外）。
- 标注关键通信协议（HTTP, gRPC, 异步消息）。
- 仅输出 PlantUML 代码，包裹在 @startuml 和 @enduml 之间。
容器描述：
- 前端应用: React SPA，部署于 Nginx。
- API 网关: Spring Cloud Gateway，负责鉴权与路由。
- 订单服务: Spring Boot 微服务，处理订单创建与查询。
- 库存服务: Spring Boot 微服务，扣减与恢复库存。
- 支付服务: Spring Boot 微服务，对接外部 Stripe。
- MySQL: 订单与库存数据存储。
- Redis: 缓存与分布式锁。
- Kafka: 订单事件消息总线。
交互：
- 前端 -> API 网关: HTTPS
- API 网关 -> 订单服务: HTTP REST
- 订单服务 -> Kafka: 发布 OrderCreated 事件
- Kafka -> 库存服务: 消费 OrderCreated 扣减库存
- 订单服务 -> Redis: 查询缓存

LLM 返回的 PlantUML 代码可直接放入在线渲染器验证。

4.2 生成质量保障与迭代优化

直接生成的代码可能缺漏组件或箭头方向错误。我们建立校验-反馈循环：

  1. 自动校验：使用 PlantUML 语法检查器判断生成代码是否可渲染；利用正则提取组件名并与输入描述对比，发现遗漏则自动生成修正提示。
  2. 人工校验：架构师在 PlantUML 在线工具中渲染，检查布局合理性与语义正确性。
  3. 迭代优化：架构师可将修改意见作为新 Prompt 反馈：“请在订单服务与支付服务之间增加同步调用关系” ，让 LLM 修改原脚本。

生成与校验循环图：

flowchart LR
    A[自然语言系统描述] --> B[LLM 生成 PlantUML]
    B --> C[自动语法检查]
    C -- 通过 --> D[人工渲染校验]
    C -- 失败 --> E[生成修正提示]
    E --> B
    D -- 有误 --> F[架构师修改反馈]
    F --> B
    D -- 确认无误 --> G[纳入文档]

图表说明：

  • 主旨概括：描绘了从文本到架构图代码、经过自动语法与人工语义双重校验、通过反馈实现迭代优化的闭合环。
  • 逐元素分解：输入为自然语言描述，LLM 一次生成；自动检查充当首道防线；人工校验处理语义与美观问题；反馈路径允许增量修改而非从头重绘。
  • 设计原理映射：该循环符合软件工程中的“生成-验证-修复”范式，AI 负责生成初稿，人类负责最终质量把关，确保了产出物的可信度。
  • 工程联系：这种半自动化绘图将架构师从繁琐的图形调整中解放出来，但架构师对布局和细节的最终控制是保证文档专业性的关键。

5. 提示库建设与效能度量

5.1 提示模板的版本管理

企业级应用中，审查、选型、生成图等场景的 Prompt 会持续调优。我们将这些 Prompt 模板以 .st (StringTemplate) 文件 存储在 Git 仓库中，与代码版本同步。Spring AI 的 PromptTemplate 能够从类路径或文件系统加载，天然适配此工作流。例如：

src/main/resources/prompts/
    arch-review.st
    tech-selection.st
    c4-container-gen.st

每次 Prompt 变更需走 PR 评审，团队可以通过 A/B 测试（同一需求发给两个版本 Prompt，对比输出质量）来评估修改效果。

5.2 效能度量指标

为衡量 AI 辅助的价值，我们定义以下指标：

  • 审查时间缩短比例：(人工审查平均耗时 - AI辅助后总耗时) / 人工审查平均耗时。总耗时包括 AI 调用与人工评审。
  • 反模式检出率提升：AI 辅助下发现的 HIGH 级别反模式数量对比纯人工审查。
  • 选型决策周期：从需求提出到 ADR 记录的日历天数变化。
  • 架构图生成时间：从文字描述到可用的渲染图耗时。
  • 选型返工率：ADR 确定后六个月内因选型不当导致重大重构的比例。

基于这些指标，可以客观评估 AI 辅助的 ROI，并指导后续优化。

6. 贯穿案例：电商系统架构重构的 AI 辅助全流程

场景：一个电商单体系统运行两年，出现性能瓶颈、数据库单点、同步调用链长等问题。架构师决定重构为微服务架构。下面展示 AI 如何辅助整个重构决策过程。

原始架构文档片段（Markdown）：

## 当前系统架构
- 单体 Spring Boot 应用，部署在单台云主机。
- 全部业务逻辑耦合在一个模块中：用户、订单、库存、支付。
- 数据库使用单机 MySQL 8.0，无读写分离，无缓存。
- 订单支付流程同步：Controller -> OrderService -> StockService（扣减库存）-> PaymentService（外部支付），无消息队列。
- 无熔断限流，流量高峰时常出现线程池满。

6.1 审查阶段

架构师提交上述文档（可按模块拆分为“订单支付流程”片段）到 AI 审查服务。Prompt 内嵌设计原则与 Few-shot，LLM 输出 ArchitectureReviewReport：

{
  "risks": [
    {
      "severity": "HIGH",
      "pattern": "单体架构中的单点故障",
      "principle": "高可用原则",
      "description": "单个 Spring Boot 实例和单机 MySQL 构成全系统单点，任何宕机导致整体不可用。",
      "suggestion": "拆分微服务，每个服务独立部署；MySQL 主从+哨兵或迁移至云RDS高可用版。",
      "linkedAdr": null
    },
    {
      "severity": "HIGH",
      "pattern": "分布式同步调用链无保护",
      "principle": "故障隔离原则",
      "description": "订单支付流程同步调用库存与支付服务，无熔断、超时、重试机制。",
      "suggestion": "引入异步消息队列解耦，或增加 Sentinel 熔断。库存扣减需实现幂等。",
      "linkedAdr": null
    },
    {
      "severity": "MEDIUM",
      "pattern": "缺少缓存",
      "principle": "缓存设计原则",
      "description": "热点数据直接访问数据库，存在性能瓶颈与缓存穿透风险。",
      "suggestion": "引入 Redis 缓存热门商品、库存信息，并实现缓存预热与防穿透。",
      "linkedAdr": null
    }
  ]
}

架构师确认所有 HIGH 级别风险，认为 MEDIUM 级别缓存问题在重构初期非最高优先，但记录在案。对两个 HIGH 风险，AI 分别生成了 ADR 草稿，如“ADR-045：引入消息队列解耦订单与库存”。

系统架构现状与目标对比图：

flowchart LR
    subgraph 当前架构 [当前单体架构]
        A1[浏览器] --> B1[单体应用]
        B1 --> C1[MySQL 单机]
    end
    subgraph 目标架构 [目标微服务架构]
        A2[浏览器] --> B2[API网关]
        B2 --> C2[订单服务]
        B2 --> D2[库存服务]
        C2 --> E2[Kafka]
        E2 --> D2
        C2 --> F2[Redis]
        D2 --> G2[MySQL集群]
        C2 --> H2[支付服务]
    end
    当前架构 -.->|AI审查驱动重构| 目标架构
    style B1 fill:#f96,stroke:#333
    style C1 fill:#f96,stroke:#333
    style E2 fill:#9f6,stroke:#333
    style F2 fill:#9f6,stroke:#333

图表说明：

  • 主旨概括：对比图直观展示了电商系统从单体架构到微服务目标架构的演进，标注了AI审查发现的关键痛点及改进点。
  • 逐层分解：左侧红色高亮单体应用和单机数据库（单点、无异步）；右侧绿色高亮新增的 Kafka、Redis 和微服务拆分，体现了审查建议的落地。
  • 设计原理映射：拆分体现了“故障隔离”与“高可用”原则，引入消息队列和缓存分别解决了耦合与性能瓶颈。
  • 工程联系：AI 审查的输出直接映射为架构改造的待办项，并形成了可追踪的 ADR，将问题发现与决策记录闭环。

6.2 辅助选型阶段

架构师输入结构化需求：

业务场景: 电商大促，QPS=5000, P99延迟<200ms, 数据规模 2TB, 最终一致性, 可用性99.99%, 需要分布式事务(订单创建与库存扣减), 团队 Java+Spring, 预算 $5000/月。

结合从历史 ADR 库中检索到的“消息队列选型：RocketMQ 在事务消息上的优势”和“Redis集群配置标准”，LLM 推荐：

  • 消息队列：RocketMQ（强事务消息支持，延迟低）。
  • 缓存：Redis Cluster + Redisson 分布式锁。
  • 分布式事务：Seata AT 模式（无侵入，团队接受度好）。
  • 数据库：MySQL 分库分表 + ShardingSphere-Proxy。 架构师结合团队对 RocketMQ 的运维经验不足，最终选择了 Kafka（公司已有运维支持），并在 ADR 中记录了该权衡（因运维成本放弃事务消息特性，采用最终一致性+Saga补偿）。

6.3 生成架构图与最终决策

选型确定后，架构师用一段描述生成目标 C4 Container 图 PlantUML，人工校验并调整布局。团队召开评审会议，基于 AI 审查报告、选型分析及生成的目标架构图，讨论并修订了 Saga 补偿回滚策略，最终形成了 ADR-046: 电商系统微服务重构技术方案，包含完整的 Context、Container 图引用和风险缓解措施。

贯穿案例完整操作时序图：

sequenceDiagram
    participant 架构师
    participant AI系统
    participant 团队
    participant ADR知识库

    架构师->>AI系统: 提交架构文档(片段)
    AI系统-->>架构师: 返回 ArchitectureReviewReport
    架构师->>架构师: 确认/筛选风险，生成ADR草稿
    架构师->>AI系统: 提交结构化选型需求
    AI系统->>ADR知识库: 检索历史ADR与基准
    ADR知识库-->>AI系统: 返回相关上下文
    AI系统-->>架构师: 返回技术选型建议与对比
    架构师->>AI系统: 提交目标系统描述
    AI系统-->>架构师: 返回 C4 PlantUML 脚本
    架构师->>架构师: 校验并调整架构图
    架构师->>团队: 发起评审会议(审查报告+选型+架构图)
    团队->>架构师: 讨论与反馈
    架构师->>ADR知识库: 记录最终 ADR

图表说明：

  • 主旨概括：时序图完整呈现了从文档提交、AI审查、选型、生成图到团队决策与ADR记录的端到端人机协作序列。
  • 逐线解读：架构师与 AI 系统多轮交互，AI 在审查、选型、生成图阶段输出提案；团队在最后协作评审；ADR 知识库既提供历史上下文，又吸收新决策。
  • 设计原理映射：体现了“AI 提案 → 架构师评审 → 团队讨论 → 形成 ADR”的模型，AI 始终作为辅助，决策权保持在人类架构师和团队手中。
  • 工程联系：这一时序是 AI 辅助架构设计的生产级操作范本，展示了如何在真实重构场景中标准化地编排 AI 能力与人类判断。

7. 面试高频专题

Q1: 如何利用 AI 辅助进行架构审查？其工作流程是怎样的？

  • 一句话回答：将架构文档分片后提交 LLM，通过携带设计原则与反模式示例的 Prompt 生成结构化的风险报告，再由架构师人工确认。
  • 详细解释：流程包括：①按质量属性或模块拆分文档以适应上下文窗口；②设计包含审查角色、原则（故障隔离、高可用等）和 Few-shot 反模式示例的 SystemMessage；③调用 LLM 输出 JSON 格式的审查报告（风险级别、违反原则、建议）；④利用 BeanOutputParser 解析并联动生成 ADR 草稿；⑤架构师逐条确认，剔除误报，补充上下文。
  • 多角度追问：如何处理大型文档的上下文限制？→ 通过智能拆分和多次提交，再合并结果。如何保证审查一致性？→ 固定审查维度与 Few-shot 示例，定期维护反模式库。LLM 审查的假阳性如何降低？→ 引入置信度阈值，结合人工确认。
  • 加分回答：可以将审查与 CI/CD 流水线集成，每次架构文档提交触发审查，作为架构门禁。

Q2: AI 架构审查能发现哪些类型的反模式？有哪些局限？

  • 一句话回答：能发现循环依赖、缺少熔断/幂等、单点故障、缓存穿透等代码和设计层面的反模式，但无法理解组织政治、隐性历史决策等社会技术因素。
  • 详细解释：LLM 擅长基于已知模式匹配缺陷，例如未加超时的远程调用、未处理的消息重入、无降级的核心链路。局限在于：无法评估团队能力（是否适合维护 Scala 服务）、无法感知预算政治（CTO 倾向采购 Oracle）、难以捕捉不合理的业务耦合（两个服务本应合并）。
  • 多角度追问：能否发现并发 bug？→ 很有限，静态文档无法呈现运行时交错。能否评估安全性？→ 可补充 OWASP 示例检查常见漏洞，但渗透测试仍必需。如何改善局限？→ 结合 RAG 注入组织上下文（如团队技能矩阵），但仍需人判断。
  • 加分回答：未来的多模态 AI 可能直接分析架构图图片，结合代码仓库的提交历史，给出更全面的腐化预测。

Q3: 如何设计架构审查的 Prompt？需要包含哪些要素？

  • 一句话回答：必须包含角色定义、审查维度（对应设计原则）、输出格式说明以及少量反模式示例（Few-shot）。
  • 详细解释：角色定义让 LLM 进入专家模式；审查维度将分布式系统设计原则（如“CAP权衡”“故障隔离”）显式化为 checklist；输出格式要求（如严格 JSON）保证可编程解析；Few-shot 示例提供正误对照，极大提升输出稳定性和准确度。
  • 多角度追问：Few-shot 示例应该放多少？→ 2-3 个代表性示例即可，过多会稀释注意力。如何处理设计原则的冲突？→ 在 Prompt 中说明优先级，如“可用性高于性能时，允许冗余”。如何迭代 Prompt？→ 与模型版本同步管理，A/B 测试输出质量。
  • 加分回答：可使用 Spring AI 的 PromptTemplate 将审查维度参数化，允许根据项目特征（金融 vs 社交）动态调整审查侧重点。

Q4: 如何用 AI 辅助技术选型？如何将权衡框架融入 Prompt？

  • 一句话回答：将业务需求参数化，并在 Prompt 中明确列出多个权衡维度（CAP、性能/正确性、成本/弹性等），要求 LLM 据此分析推荐。
  • 详细解释：首先构造结构化需求模板（QPS、延迟、数据量、一致性等级、技能栈等），然后 Prompt 的 SystemMessage 中嵌入权衡框架：“你需要按照以下维度逐一评估：一致性 vs 可用性、性能 vs 正确性、复杂度 vs 可维护性……”。如此 LLM 的输出自然带有对比分析和取舍理由，而非仅仅罗列技术名词。
  • 多角度追问：如何保证选型建议的时效性？→ 结合搜索引擎插件或 RAG 注入最新版本 release notes。如何处理 LLM 的偏好偏见？→ 要求输出备选方案对比表，明确每个方案的适用边界。如何让选型贴合公司现状？→ RAG 检索已有 ADR 和中间件列表作为约束条件。
  • 加分回答：可以结合 Spring AI 的 Function Calling 调用内部效能计算 API，对候选方案进行吞吐量或成本模拟，增强定量分析。

Q5: AI 生成的架构图（C4 模型）如何确保质量？校验流程是什么？

  • 一句话回答：通过自动化语法检查、组件完整性校验和人工渲染审核的三步校验流程，并借助迭代反馈修改优化。
  • 详细解释：第一步，对生成的 PlantUML 进行语法检查及关键字提取，对比输入描述发现遗漏；第二步，架构师在 PlantUML/Mermaid 渲染器中查看视觉效果，检查布局与关系正确性；第三步，若发现问题，将修正指令作为新 Prompt 反馈给 LLM，迭代直至满意。
  • 多角度追问：生成图不符合公司绘图规范怎么办？→ 在 Prompt 中加入样式规范示例（如颜色、图标）。如何处理大团队的多图一致性？→ 固定 Style 片段和模板，要求 LLM 参考。是否可以生成交互式的图？→ 目前仍以静态代码为主，未来可结合 D3.js 生成。
  • 加分回答：可以训练一个专用小模型对生成代码进行美学打分，筛选出符合布局美学的候选。

Q6: 人机协作的架构决策模型中，架构师的不可替代性体现在哪里？

  • 一句话回答：体现在对隐性上下文（组织政治、团队能力、遗留债务）的理解、最终价值权衡与责任承担。
  • 详细解释：AI 可以给出逻辑上最优的方案，但架构师必须回答：“这个方案在当前组织中能落地吗？”例如 AI 推荐使用 Akka Cluster 处理并发，但团队全是 Spring 技术栈且无 Scala 经验，架构师要否决该方案。架构师还要对不可量化的“战略适配性”做决断，并对最终后果负责，这是 AI 无法承担的。
  • 多角度追问：AI 能否模拟架构师的直觉？→ 基于大数据的模式识别可以接近，但无法感知办公室政治。未来 AI 是否能做决策？→ 可以作为投票成员，但最终决策权需保留在人手中，以保证可问责性。架构师角色会如何演变？→ 从“设计者+记录者”变成“AI 教练+评审者”。
  • 加分回答：架构师的核心竞争力将转向“提出正确问题的能力”和“校准 AI 输出的判断力”。

Q7: 如何将 AI 审查结果与企业 ADR 流程结合？

  • 一句话回答：审查发现的不一致可自动关联已有 ADR 编号，新的高风险项可生成 ADR 草稿，经架构师评审后进入正式决策流程。
  • 详细解释：在 ADR 记录中维护“受影响的组件”等元数据，审查时 LLM 识别出违反某 ADR 的设计即填上编号。对于新风险，系统按 ADR 模板填充标题、背景和备选方案，形成草稿。架构师在此基础上补充决策后果和审批信息，完成 ADR 流程。这保证了问题发现与决策记录的无缝衔接。
  • 多角度追问：如果有多个 ADR 冲突怎么办？→ 标记出来由架构师主持裁决，并记录为新的“ADR 修订”。如何跟踪 ADR 落地？→ 将 ADR 与代码架构约束（如 ArchUnit 规则）关联，CI 检查。ADR 知识库如何维护？→ 定期清理过时 ADR，用 AI 辅助找出可能漂移的决策。
  • 加分回答：可构建 ADR 的语义搜索，新决策时通过 RAG 精准检索历史相关的所有决策上下文。

Q8: AI 辅助架构设计如何度量效能？关键指标有哪些？

  • 一句话回答：通过审查时间缩短比例、反模式检出率提升、选型决策周期、架构图生成时间和选型返工率等指标度量。
  • 详细解释：审查时间缩短比例计算纯人工审查与 AI 辅助总耗时（含人工确认）的差。反模式检出率需设立基线（某次人工审查发现的严重问题数），然后比较引入 AI 后的提升。决策周期从需求提出到 ADR 记录的日历天数。架构图生成时间直接度量从描述到可用图的时间。选型返工率是后续六个月内因选型问题导致重构的比例，这是衡量建议质量的关键滞后指标。
  • 多角度追问：如何避免度量陷阱？→ 不单纯追求速度，必须结合质量指标（如返工率）。如何收集基线数据？→ 初期让团队记录审查和选型时间。是否需要评估 AI 建议的被采纳率？→ 是，高采纳率表明信任度，但也要分析未被采纳的原因。
  • 加分回答：效能度量数据本身可反馈到提示优化，形成“度量-改进”工程化循环。

好的，根据您的要求，我对面试高频专题中的 Q9 系统设计题进行了全面重写，提供了更详尽、可落地的完整方案。

系统设计

Q9:（系统设计题） 你作为架构师，需要为一个已有的电商系统进行架构升级评估。现有架构文档描述了系统采用单体架构，存在数据库单点、未做缓存、同步调用链长等问题。请设计一套 AI 辅助的评估与重构方案，要求：1）设计审查 Prompt 及输出报告结构；2）给出辅助选型策略（需考虑引入 Redis 缓存、消息队列、微服务拆分）；3）说明如何利用 AI 生成目标架构图；4）描述整个过程中的人机协作流程和 ADR 产出。

详细设计方案

背景与约束：

  • 现状：单体 Spring Boot 应用，单机 MySQL 数据库，订单支付同步阻塞调用链，无缓存、无消息队列。
  • 目标：支持大促峰值 QPS 5000，P99 延迟 < 200ms，高可用，支持横向扩展。
  • 团队：10 名 Java 后端，熟悉 Spring 生态，无分布式事务和消息队列深 运维经验。

我们将严格遵循“AI 提案 → 架构师评审 → 团队讨论 → 形成 ADR”的协作模型，分五个阶段推进。

阶段 1：AI 架构审查

1.1 文档分片与输入准备 将现有架构文档按“支付流程”、“数据存储”、“部署拓扑”三个片断提交审查。例如“支付流程”片断：

- 用户请求经 Controller -> OrderService.createOrder()
- OrderService 同步调用 StockService.deductStock()，若扣减成功则调用 PaymentService.pay()
- 整个流程无重试、无超时、无熔断配置
- MySQL 使用 MyISAM 引擎，不支持事务

1.2 审查 Prompt 设计 (Spring AI 模板 payment-flow-review.st)
该模板结合了本文定义的四项核心原则，并嵌入了针对支付流程的 Few-shot 示例。

你是一位资深分布式系统架构师。审查以下支付流程架构描述，严格依据原则检查：
1. 故障隔离：是否有熔断、超时、重试和降级机制？调用链是否具备弹性？
2. 数据一致性：跨服务数据操作是否具有幂等性？分布式事务策略是否明确？
3. 高可用：关键路径是否存在单点故障？
4. CAP权衡：选型是否明确了一致性与可用性的取舍？

审查维度：反模式、违反原则、与已有ADR冲突。
输出格式：严格JSON，对应 ArchitectureReviewReport 结构。

Few-shot 示例：
输入："订单服务同步调用库存服务扣减库存，无重试机制。"
输出：{
  "risks": [{
    "severity": "HIGH",
    "pattern": "无保护的同步远程调用",
    "principle": "故障隔离原则",
    "description": "同步调用库存服务，若其超时或不可用，将阻塞订单服务线程，造成级联故障。",
    "suggestion": "引入Hystrix/Sentinel熔断器，设置超时与线程池隔离；或改为异步消息驱动，由订单事件触发库存扣减。",
    "linkedAdr": null
  }]
}

待审查内容：
{paymentFlowDescription}

1.3 输出报告结构与解析 通过 Spring AI 的 BeanOutputParser 将 LLM 响应解析为 ArchitectureReviewReport POJO：

public class ArchitectureReviewReport {
    private List<RiskItem> risks;
    // ...
    public static class RiskItem {
        private String severity;
        private String pattern;
        private String principle;
        private String description;
        private String suggestion;
        private String linkedAdr;
    }
}

对于支付流程片断，AI 输出的报告示例：

{
  "risks": [
    {
      "severity": "HIGH",
      "pattern": "无事务的支付链路",
      "principle": "数据一致性原则",
      "description": "MyISAM引擎不支持事务，订单创建与库存扣减可能处于不一致状态。同步链路缺乏事务边界。",
      "suggestion": "迁移至InnoDB引擎；拆分服务后，考虑Seata AT模式或基于消息的最终一致性方案。",
      "linkedAdr": null
    },
    {
      "severity": "HIGH",
      "pattern": "无熔断的同步调用链",
      "principle": "故障隔离原则",
      "description": "支付流程中，库存服务或支付服务的任何故障都将直接阻塞订单服务。",
      "suggestion": "引入消息队列(RocketMQ/Kafka)解耦，实现异步化；库存扣减必须幂等。",
      "linkedAdr": null
    }
  ]
}

1.4 架构师确认与 ADR 草稿生成 架构师审阅报告，确认两个 HIGH 级别风险。系统自动为每个高风险项生成 ADR 草稿（使用 ADR 标准模板）：

### ADR-101: 支付链路异步化解耦与事务方案

*   **状态**: 草稿
*   **背景**: 当前支付同步调用导致级联故障风险，MyISAM无事务支持。需要支持高并发与最终一致性。
*   **决策**: 引入RocketMQ，订单创建成功后发送OrderCreated事件，库存服务异步消费扣减库存；采用Seata AT模式保证订单-库存的事务一致性。
*   **后果**: 增加系统复杂度，需处理消息重复消费与回滚；提升了吞吐量和可用性。
阶段 2：AI 辅助技术选型

2.1 结构化需求输入 我们将业务目标翻译为参数化需求，填入选型模板：

业务场景: 电商大促，峰值 QPS = 5000
P99延迟: < 200ms
数据规模: 订单表日增500万行，总数据量2TB
一致性要求: 最终一致性（下单与扣减库存允许短暂不一致，但需保证最终一致）
可用性级别: 99.99%
事务需求: 需要分布式事务能力 (订单创建与库存扣减)
团队技能栈: Java 11, Spring Boot 2.x, 熟悉Spring Cloud, 无消息队列运维经验
成本约束: 云资源月预算 $8000
已有基础设施: 公司已采购阿里云，内部有RocketMQ运维团队；禁止引入自建Kafka

2.2 选型推理 Prompt (Spring AI 模板 tech-selection.st)
Prompt 中嵌入了多维度权衡框架，并要求输出结构化对比：

你是一名技术选型专家。根据以下结构化需求，推荐技术栈组合。
你必须从以下维度进行权衡分析：
1. CAP：在分区容错前提下，一致性要求为“最终一致”，优先考虑AP方案，但需说明补偿措施。
2. 性能与正确性：分布式事务方案需在吞吐量(Seata AT)与业务耦合(Saga)之间权衡。
3. 复杂度 vs 可维护性：消息队列选型必须考虑团队技能与现有运维支持(RocketMQ已具备)。
4. 成本与弹性：缓存需考虑冷热分离，数据库分库分表建议基于ShardingSphere。

输出严格JSON格式：
{
  "recommendedStack": {
    "messageQueue": "...",
    "cache": "...",
    "transaction": "...",
    "database": "..."
  },
  "reasoning": { "cap": "...", "performance": "...", ... },
  "alternativeComparison": [ { "option": "...", "pros": "...", "cons": "..." } ],
  "risks": "..."
}

需求：{structuredRequirement}
历史ADR检索结果（RAG注入）：
- ADR-034: 消息中间件统一为RocketMQ，使用其事务消息特性。
- 性能基准：阿里云RocketMQ单实例TPS上限10w，满足需求。

2.3 选型报告输出（LLM 返回）

{
  "recommendedStack": {
    "messageQueue": "Apache RocketMQ（阿里云商用版）",
    "cache": "Redis Cluster 6.x + Redisson",
    "transaction": "Seata AT 模式（基于RocketMQ事务消息）",
    "database": "MySQL 8.0 InnoDB + ShardingSphere-Proxy 分库分表（按order_id哈希）"
  },
  "reasoning": {
    "cap": "RocketMQ可用性优先，消息持久化保证最终一致；Seata AT默认AP，通过全局锁协调。",
    "performance": "RocketMQ事务消息延迟在2ms内，满足P99延迟预算。Seata AT相比TCC侵入性低，开发成本低，适合快速上线。",
    "complexity": "公司已有RocketMQ运维，无需额外学习Kafka；Seata AT对代码基本无侵入，团队接受度高。",
    "cost": "Redis集群采用主从+哨兵，满足99.99%可用性；数据库分库分表初期4个节点，预算可控。"
  },
  "alternativeComparison": [
    { "option": "RabbitMQ", "pros": "轻量，管理方便", "cons": "无原生事务消息，需Seata AT手动补偿，延迟稍高" },
    { "option": "Saga 模式", "pros": "服务完全解耦", "cons": "需编写补偿逻辑，调试复杂，开发周期长" }
  ],
  "risks": "Seata AT在极高并发下全局锁可能成为瓶颈，需要压测验证；RocketMQ事务消息回查机制需业务方实现。"
}

2.4 架构师终审与 ADR 记录 架构师采纳推荐组合，并在 ADR-101 的决策部分补充具体版本和配置规格，形成正式记录。

阶段 3：AI 生成目标架构图

3.1 系统描述文本

系统上下文：外部用户通过移动App访问，存在第三方支付渠道Stripe。
容器列表：
- Nginx + React SPA (前端)
- Spring Cloud Gateway (API网关，鉴权与限流)
- 订单服务 (Spring Boot, 创建订单, 发布OrderCreated事件)
- 库存服务 (Spring Boot, 消费OrderCreated, 扣减/恢复库存，提供查询接口)
- 支付服务 (Spring Boot, 消费OrderPaid事件，调用Stripe，发送支付结果)
- MySQL 集群 (4节点ShardingSphere-Proxy分库分表)
- Redis Cluster (缓存热点商品、分布式锁)
- RocketMQ (订单、库存、支付主题)
关系：前端->网关:HTTPS；网关->订单服务:HTTP；订单服务->RocketMQ:发布事件；RocketMQ->库存服务:推送；库存服务->Redis:读写缓存；库存服务->MySQL:持久化；支付服务->Stripe:HTTPS；支付服务->RocketMQ:发布结果。

3.2 生成 C4 Container 图 Prompt

你是一个架构图生成器。基于以下系统描述，生成C4模型的Container图，使用PlantUML语法。包含图例，标注通信协议，不包含不必要的样式。仅输出PlantUML代码。

描述：{containerDescription}

3.3 生成代码与校验 LLM 返回的 PlantUML 片段（略），架构师将其粘贴至 PlantUML 在线编辑器，发现缺少“库存服务->RocketMQ”的回写关系，于是反馈：“请增加库存服务向RocketMQ发布InventoryUpdated事件的箭头”。二次生成后满足要求，最终定稿。

阶段 4：人机协作流程与 ADR 产出

整个过程遵循时序图（参见正文 6.3），具体活动如下：

  1. 架构师提交现状文档（分片）。
  2. AI 审查输出风险报告。架构师筛选确认后，系统生成两份 ADR 草稿：
    • ADR-101: 支付链路异步化与分布式事务方案。
    • ADR-102: 数据库高可用与分库分表改造。
  3. 架构师发起选型，AI 结合 RAG 返回推荐栈。架构师确认后，将选型信息合并入 ADR-101 和 ADR-102 的决策细节。
  4. 架构师提供新系统描述，AI 生成目标 Container 图 PlantUML。经过多轮反馈定稿。
  5. 架构师召集团队评审会议，展示审查报告、选型对比、目标架构图，围绕“Seata AT 潜在锁瓶颈”和“是否拆分支付服务”展开讨论。最终决定：先采用 Seata AT，加入锁监控；支付服务独立但暂时不拆分交付团队。
  6. 形成最终 ADR：架构师更新 ADR-101、102，并新增 ADR-103（服务拆分粒度与组织匹配）。所有 ADR 提交到企业 Git 仓库。

最终 ADR 清单示例：

  • ADR-101：引入 RocketMQ + Seata AT 实现异步解耦与分布式事务。
  • ADR-102：MySQL 迁移至 InnoDB，通过 ShardingSphere-Proxy 进行分库分表，配合 Redis Cluster 缓存。
  • ADR-103：订单、库存、支付拆分为独立微服务，但短期内由同一团队维护，降低沟通成本。

总结： 该方案完整实践了“AI 提案，人类决策”的模式。AI 负责快速扫描文档、生成反模式报告、根据约束给出选型建议并绘制架构图；而架构师在整个过程中负责上下文注入（团队技能、运维现状）、权衡终审（选择 Seata 而非 Saga）和最终的决策责任。所有关键节点均沉淀为 ADR，可追溯、可演进。

总结与速查表

本文构建了一套将 LLM 融入架构设计审查、选型与文档生成的人机协作方法论。核心思想是：AI 负责加速信息处理与模式匹配，人类架构师负责价值判断与责任承担。通过 Spring AI 的工程能力（Prompt模板、输出解析、RAG）和已有的 ADR 框架，我们能将这一工作流产品化，实现企业级落地。

AI 辅助架构设计速查表：

场景Prompt 核心要素输出格式人机协作关键节点
架构审查角色定义、审查维度（设计原则）、Few-shot反模式、输出JSON约束ArchitectureReviewReport (风险列表)架构师确认误报/漏报，关联ADR
技术选型结构化需求模板、多维度权衡指令、RAG注入约束结构化选型报告（推荐+对比表）架构师结合组织上下文最终权衡
生成架构图组件与交互描述、C4级别指定、PlantUML/Mermaid语法约束PlantUML/Mermaid 代码块人工渲染校验、样式调整、迭代修改
ADR 草稿风险描述+建议方案，要求按ADR模板输出ADR Markdown草稿（标题、背景、选项）补充决策后果、审批流程后正式化

延伸阅读：

  • ThoughtWorks 技术雷达最新一期关于“AI-assisted software engineering”的条目。
  • 《Architecture Decision Records in the Age of AI》——探讨 LLM 如何影响架构决策的记录与治理。
  • PlantUML 官方文档：C4 模型实现指南。
  • Spring AI 官方文档：提示管理、输出解析器与 RAG 支持。

本文是“AI 时代的架构决策”系列第 1 篇。下一篇将探讨“AI 驱动的自适应限流与容量预测”，展示如何将 AI 辅助架构设计产生的监控指标与选型决策，输入到动态流量治理与弹性扩缩容系统中。

avatar
文章
阅读
粉丝