AI辅助技术方案评审从架构图解析到风险识别的智能分析「这个方案你也帮我看一下」——技术 Leader 每天平均收到 5~8 份待评审方案真正能逐行看完的不到 3 份。AI 辅助评审不是要替代人的判断而是把人的精力聚焦在「AI 发现的可疑点上」。一、C4 模型让架构图可被机器解析AI 要理解架构图第一步是让架构图变成结构化数据。手绘的白板图、Visio 的方框箭头——这些对 AI 来说就是像素矩阵我们需要的是可解析的架构描述语言。C4 模型Context → Container → Component → Code是 Simon Brown 提出的架构可视化方法它的四级抽象恰好对应了从「系统全景」到「代码实现」的渐进式细化。在 AI 辅助评审场景中我们主要使用 C1~C3 级别graph TD subgraph C1[C1: 系统上下文图 (System Context)] User[用户] -- System[电商平台] System -- Payment[支付网关] System -- Logistics[物流系统] end subgraph C2[C2: 容器图 (Container Diagram)] WebApp[Web 应用] -- APIGW[API 网关] APIGW -- OrderSvc[订单服务] APIGW -- ProductSvc[商品服务] OrderSvc -- DB[(MySQL)] ProductSvc -- Cache[(Redis)] end subgraph C3[C3: 组件图 (Component Diagram)] OrderSvc -- CreateOrder[订单创建组件] OrderSvc -- PayCallback[支付回调组件] OrderSvc -- OrderQuery[订单查询组件] CreateOrder -- MQ[消息队列\n(异步通知)] end style C1 fill:#cfc,stroke:#333 style C2 fill:#fc6,stroke:#333 style C3 fill:#f96,stroke:#333对于 AI 解析我们使用Structurizr DSLC4 模型的代码化描述作为输入格式。它本质上是 YAML 或 JSON 描述的架构拓扑图每一条边都带有了明确的语义# C4 模型的结构化描述 —— 可直接被 AI 解析 model: people: - id: user name: 用户 description: 终端消费者 softwareSystems: - id: ecommerce name: 电商平台 containers: - id: api-gateway name: API 网关 technology: Spring Cloud Gateway - id: order-service name: 订单服务 technology: Spring Boot 3.2 MyBatis relationships: - source: user target: api-gateway protocol: HTTPS description: 用户请求 - source: api-gateway target: order-service protocol: gRPC description: 订单请求路由 - source: order-service target: mysql-orders protocol: JDBC description: 订单持久化 tags: [critical, persistent]二、AI 解析架构图的三个层次将结构化架构描述喂给 LLM 后AI 的分析分为三个递增层次第一层拓扑解析—— 识别组件、连接关系、协议类型。这是结构化数据可以直接回答的问题不需要 AI。但 AI 可以自动生成拓扑摘要「本方案包含 8 个微服务、3 个数据库实例、2 个消息队列 Topic服务间共 15 条依赖关系。」第二层模式匹配—— 将当前架构与已知的反模式库进行对比。这是一个典型的模式识别任务LLM 对此非常擅长 架构反模式检测引擎。 将 C4 结构化描述输入 LLM匹配已知风险模式库。 from dataclasses import dataclass, field from typing import List, Optional from enum import Enum class RiskSeverity(Enum): CRITICAL critical # 必须修复否则生产事故 HIGH high # 强烈建议修复 MEDIUM medium # 建议修复 LOW low # 可选优化 dataclass class RiskFinding: 单条风险发现 severity: RiskSeverity pattern: str # 匹配到的反模式名称 description: str # 人类可读的风险描述 affected_components: List[str] # 受影响的组件 suggestion: str # 修复建议 references: List[str] field(default_factorylist) # 参考文档链接 # 预定义的反模式库 —— 可通过 LLM 持续扩展 ANTI_PATTERN_LIBRARY [ { id: SINGLE_POINT_OF_FAILURE, name: 单点故障, severity: RiskSeverity.CRITICAL, pattern_desc: 关键路径上有且仅有一个服务实例、数据库实例或网络链路, prompt_for_llm: 在以下架构中是否存在单点故障风险请列出所有「如果该组件挂掉 整个系统将不可用」的组件或连接。 , fix_suggestion: 增加冗余实例 健康检查 自动故障转移, }, { id: CIRCULAR_DEPENDENCY, name: 循环依赖, severity: RiskSeverity.HIGH, pattern_desc: 服务 A 调用服务 B服务 B 又直接或间接调用服务 A, prompt_for_llm: 分析架构中的所有依赖关系找出循环依赖链路A→B→C→A 或 A→B→A。 如果一个微服务的启动或故障会影响另一个形成循环的服务请标注。 , fix_suggestion: 通过事件驱动解耦或引入中间层打破循环, }, { id: MISSING_CIRCUIT_BREAKER, name: 缺少熔断保护, severity: RiskSeverity.HIGH, pattern_desc: 服务间同步调用链路上未标注熔断/降级机制, prompt_for_llm: 检查所有服务间同步调用特别是跨网络边界的调用 是否在描述中提及了熔断、超时、重试、降级中的至少一种保护机制。 未提及的标注为风险点。 , fix_suggestion: 添加 Resilience4j / Sentinel 熔断配置, }, { id: DATABASE_AS_INTEGRATION, name: 数据库反模式——共享数据库集成, severity: RiskSeverity.MEDIUM, pattern_desc: 多个微服务直连同一个数据库/表绕过服务接口, prompt_for_llm: 检查是否有多个服务连接到同一个数据库 schema 或表。 如果存在这破坏了微服务的数据自治原则。 , fix_suggestion: 通过 API 暴露数据访问逐步拆分共享表为独立 schema, }, { id: CHATSY_SERVICES, name: 过度微服务化Chatty Services, severity: RiskSeverity.MEDIUM, pattern_desc: 完成一个业务操作需要 5 个服务间的链式同步调用, prompt_for_llm: 分析每个请求路径上涉及的同步调用数量。 标注所有超过 5 跳的调用链——它们存在延迟放大和故障域扩大的风险。 , fix_suggestion: 合并高频协作的服务或引入聚合层减少调用跳数, }, ] class ArchitectureReviewer: 基于 LLM 的架构方案评审引擎 def __init__(self, llm_client): self.llm llm_client self.findings: List[RiskFinding] [] def review(self, c4_model: dict) - List[RiskFinding]: 对 C4 结构化模型执行全量风险检测 self.findings.clear() for pattern in ANTI_PATTERN_LIBRARY: try: findings self._detect_pattern(c4_model, pattern) self.findings.extend(findings) except Exception as e: # 单个模式检测失败不影响其他检测 # logger.warning(Pattern detection failed for {}: {}, pattern[id], e) pass # 按严重程度排序CRITICAL → HIGH → MEDIUM → LOW self.findings.sort(keylambda f: ( [RiskSeverity.CRITICAL, RiskSeverity.HIGH, RiskSeverity.MEDIUM, RiskSeverity.LOW].index(f.severity) )) return self.findings def _detect_pattern( self, c4_model: dict, pattern: dict ) - List[RiskFinding]: 调用 LLM 检测单个反模式 system_prompt 你是一位资深后端架构师。请根据给定的架构 C4 模型描述 检测是否存在指定反模式。只列出确认存在的风险不要猜测。 对于每个风险给出受影响的组件名称和具体的修复建议。 user_prompt f ## 反模式{pattern[name]} ## 描述{pattern[pattern_desc]} {pattern[prompt_for_llm]} ## 架构 C4 模型 json {json.dumps(c4_model, ensure_asciiFalse, indent2)} 请以 JSON 数组格式输出检测结果每项包含 - is_found: bool - affected_components: string[] - description: string - suggestion: string response self.llm.chat( systemsystem_prompt, messages[{role: user, content: user_prompt}], response_format{type: json_object}, ) return self._parse_llm_response(response, pattern) def _parse_llm_response(self, response, pattern) - List[RiskFinding]: 解析 LLM 返回的 JSON 结果 # 实际项目中需要处理 JSON 解析异常、格式校验等 import json try: data json.loads(response) findings [] for item in data.get(findings, []): if item.get(is_found): findings.append(RiskFinding( severitypattern[severity], patternpattern[name], descriptionitem.get(description, ), affected_componentsitem.get(affected_components, []), suggestionpattern.get(fix_suggestion, ), )) return findings except json.JSONDecodeError: return []三、风险优先级排序不是所有风险都值得修复AI 列出了 15 个风险点技术 Leader 不可能全部处理。这里需要一个优先级排序算法综合风险严重程度、影响范围、修复成本三个维度。def prioritize_risks(findings: List[RiskFinding], c4_model: dict) - List[RiskFinding]: 风险优先级排序。 排序因子 1. 严重程度CRITICAL HIGH MEDIUM LOW 2. 影响范围受影响组件数 × 是否在关键路径上 3. LLM 给出的置信度避免假阳性排在前面浪费人力 # 构建关键路径上的组件集合 critical_path_components _identify_critical_path(c4_model) def score(finding: RiskFinding) - float: severity_weight { RiskSeverity.CRITICAL: 100, RiskSeverity.HIGH: 50, RiskSeverity.MEDIUM: 20, RiskSeverity.LOW: 5, }[finding.severity] # 关键路径上的风险加权 1.5 倍 on_critical_path any( comp in critical_path_components for comp in finding.affected_components ) path_multiplier 1.5 if on_critical_path else 1.0 # 影响组件数最小为 1 impact_scope max(len(finding.affected_components), 1) return severity_weight * path_multiplier * impact_scope return sorted(findings, keyscore, reverseTrue) def _identify_critical_path(c4_model: dict) - set: 识别关键路径——从入口到核心数据的调用链路。 简化实现标记所有数据库操作和支付/订单相关服务。 生产环境应使用 LLM 自动识别。 critical set() for rel in c4_model.get(relationships, []): if rel.get(tags) and critical in rel[tags]: critical.add(rel[source]) critical.add(rel[target]) return critical四、评审意见生成从风险列表到可操作的建议风险列表不能直接发给方案作者——那相当于「你的方案有 15 个问题自己改」。AI 需要将冷冰冰的风险列表转化为带上下文、带示例、带优先级的评审意见LLM 的 Prompt 设计在这里是关键。与其让 LLM 自由发挥不如给它一个结构化模板你是一位资深后端架构师。请根据以下风险发现生成一份技术方案评审意见。 ## 输入风险发现 {json.dumps(findings, indent2)} ## 评审意见模板严格按此格式输出 ### 一、总体评价 [2~3 句话概括方案整体质量] ### 二、必须修复CRITICAL - **风险点 1**[风险名称] - 影响[受影响的组件和后果] - 建议[具体修复方案含代码示例或配置示例] - 参考[相关文档或最佳实践链接] ### 三、强烈建议HIGH ... ### 四、可选优化MEDIUM / LOW ... ### 五、下一步行动 [建议的后续步骤重新评审 / 方案修订 / 技术讨论会]模板化的益处输出格式一致方案作者知道每一条评审意见的「要求等级」Leader 可以快速浏览「必须修复」部分做最终决策。五、总结AI 辅助技术方案评审的核心价值是将人的精力从「发现」转移到「决策」C4 模型是 AI 的「接口语言」没有结构化描述的架构图对 AI 来说只是一张像素图。投入时间学习 C4 建模回报是 AI 可以自动完成 80% 的基础评审工作。反模式库是 AI 的「知识库」预定义的反模式单点、循环依赖、缺少熔断、共享数据库覆盖了生产事故的常见根源。这个库可以通过每次事故复盘持续扩展。优先级排序比发现风险更重要15 个风险点只有 3 个值得立即修复。基于严重程度 × 关键路径 × 影响范围的排序公式把人引向最高价值项。评审意见需要结构化模板自由格式的 AI 输出是不可复用的。模板化输出确保 Leader 和方案作者用同一种语言讨论问题。这是一条正在快速演进的赛道——今天 AI 能做到的是「发现已知模式的已知风险」明天可能是「从历史事故中学习新的风险模式」。