AI辅助技术方案评审：从架构图解析到风险识别的智能分析

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 DSL（C4 模型的代码化描述）作为输入格式。它本质上是 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_factory=list) # 参考文档链接 # 预定义的反模式库 —— 可通过 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(key=lambda 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_ascii=False, indent=2)} ``` 请以 JSON 数组格式输出检测结果，每项包含： - is_found: bool - affected_components: string[] - description: string - suggestion: string """ response = self.llm.chat( system=system_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( severity=pattern["severity"], pattern=pattern["name"], description=item.get("description", ""), affected_components=item.get("affected_components", []), suggestion=pattern.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, key=score, reverse=True) 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, indent=2)} ## 评审意见模板（严格按此格式输出）： ### 一、总体评价 [2~3 句话概括方案整体质量] ### 二、必须修复（CRITICAL） - **风险点 1**：[风险名称] - 影响：[受影响的组件和后果] - 建议：[具体修复方案，含代码示例或配置示例] - 参考：[相关文档或最佳实践链接] ### 三、强烈建议（HIGH） ... ### 四、可选优化（MEDIUM / LOW） ... ### 五、下一步行动 [建议的后续步骤：重新评审 / 方案修订 / 技术讨论会]

模板化的益处：输出格式一致，方案作者知道每一条评审意见的「要求等级」，Leader 可以快速浏览「必须修复」部分做最终决策。

五、总结

AI 辅助技术方案评审的核心价值是将人的精力从「发现」转移到「决策」：

• C4 模型是 AI 的「接口语言」：没有结构化描述的架构图，对 AI 来说只是一张像素图。投入时间学习 C4 建模，回报是 AI 可以自动完成 80% 的基础评审工作。
• 反模式库是 AI 的「知识库」：预定义的反模式（单点、循环依赖、缺少熔断、共享数据库）覆盖了生产事故的常见根源。这个库可以通过每次事故复盘持续扩展。
• 优先级排序比发现风险更重要：15 个风险点只有 3 个值得立即修复。基于严重程度 × 关键路径 × 影响范围的排序公式，把人引向最高价值项。
• 评审意见需要结构化模板：自由格式的 AI 输出是不可复用的。模板化输出确保 Leader 和方案作者用同一种语言讨论问题。

这是一条正在快速演进的赛道——今天 AI 能做到的是「发现已知模式的已知风险」，明天可能是「从历史事故中学习新的风险模式」。