第1791篇：用AI辅助系统架构设计——让Claude帮你评审架构方案的实践

架构评审这件事，我干了将近十年。从刚开始参加别人的评审会，到后来主持评审，再到现在用AI来辅助整个流程——说实话，变化挺大的。

今天想聊的不是什么「AI会取代架构师」的焦虑话题，而是非常具体的一件事：怎么让Claude帮你做架构评审，而且评审结果真的有用，不是废话连篇。

先说一个真实的踩坑经历

去年底，我们团队要做一个新的用户行为分析平台。我直接把需求文档扔给Claude，问它「帮我设计一个架构」。

结果Claude给了我一个「标准答案」：Kafka做消息队列、Flink做实时计算、ClickHouse做存储、Redis做缓存、SpringBoot做API层。

看着很美，全是大厂标配。但问题是，我们当时只有3个后端工程师，日活用户才5万，这套东西运维成本直接让项目在上线前就死了。

这不是Claude的问题，是我的问题——我没给它足够的上下文，没告诉它真正的约束条件。

AI辅助架构设计的核心不是让AI替你设计，而是给它足够的信息，让它帮你发现你没想到的问题。

架构评审的本质是什么

在讲怎么用AI之前，先对齐一下架构评审的目的。很多团队的架构评审变成了「技术炫耀大会」或者「过审走流程」，这两种都是在浪费时间。

架构评审真正要回答的问题：

1. 这个设计能满足业务需求吗？（功能性需求）
2. 在预期负载下能稳定运行吗？（非功能性需求）
3. 有没有单点故障？（可靠性）
4. 团队能维护得了吗？（可运维性）
5. 扩展成本是否合理？（演进性）
6. 有没有已知的反模式？（最佳实践）

这六个维度，AI其实可以帮你系统性地覆盖。人类评审容易漏掉某些维度，尤其是在会议室里大家都聚焦在技术亮点上的时候。

构建有效的架构评审Prompt

直接上我实际在用的方案。

第一步：定义架构描述模板

先让团队用统一的格式描述架构，这样AI才能有效分析。我们用的是一个结构化的Markdown模板：

## 系统架构描述

### 基本信息
- 系统名称：用户行为分析平台 v2
- 预计上线时间：2024-Q1
- 团队规模：3名后端工程师，1名运维
- 预算约束：云服务月费不超过8000元

### 业务背景
日活用户5万，需要实时分析用户点击、停留、转化行为，
支持运营人员查询过去30天的行为漏斗，响应时间<3秒。

### 技术选型
- 数据采集：前端埋点 -> Nginx日志 -> Filebeat
- 消息队列：RabbitMQ（已有运维经验）
- 数据处理：SpringBatch定时任务（每5分钟一次）
- 存储：MySQL分表 + Redis缓存
- API：SpringBoot RESTful

### 关键流程
用户行为 -> 前端SDK -> Nginx -> Filebeat -> RabbitMQ 
-> 消费者服务 -> MySQL -> Redis缓存 -> API -> 前端展示

### 已知约束
- 团队熟悉MySQL，不熟悉列存储数据库
- 现有RabbitMQ集群可以复用
- 不考虑Kafka，运维成本太高

第二步：构建评审Prompt

public class ArchitectureReviewPromptBuilder {
    
    private static final String REVIEW_SYSTEM_PROMPT = """
        你是一位资深系统架构师，有15年大型系统设计经验。
        你的评审风格是：务实、直接、关注实际落地，不追求技术时髦。
        
        评审架构时，你需要：
        1. 基于团队实际约束给建议，不推荐超出团队能力的技术
        2. 明确指出潜在风险，用具体场景说明（比如"当DAU超过50万时..."）
        3. 区分「必须修改」和「建议优化」两个级别
        4. 对每个问题给出2-3个备选解决方案，说明各自的权衡
        5. 最后给一个总体评分（1-10）和是否建议通过
        """;
    
    public String buildReviewPrompt(String architectureDoc) {
        return String.format("""
            %s
            
            请评审以下架构方案：
            
            ---
            %s
            ---
            
            请按以下维度评审：
            
            ## 1. 功能完整性
            描述的架构是否能覆盖所有业务需求？
            
            ## 2. 性能与容量
            在当前和未来3倍增长下，各组件是否能承载？
            给出关键路径的粗略延迟估算。
            
            ## 3. 可靠性与容错
            有哪些单点故障？宕机影响范围是什么？
            
            ## 4. 运维复杂度
            基于团队规模，这套架构是否可维护？
            
            ## 5. 安全性
            有哪些明显的安全风险？
            
            ## 6. 演进路径
            当业务增长10倍时，哪里会先出问题？如何演进？
            
            ## 必须修改项（P0）
            列出阻塞上线的问题
            
            ## 建议优化项（P1/P2）
            列出上线后可以改进的点
            
            ## 总体评分与建议
            """, REVIEW_SYSTEM_PROMPT, architectureDoc);
    }
}

第三步：调用Claude API

@Service
public class ArchitectureReviewService {
    
    @Value("${anthropic.api.key}")
    private String apiKey;
    
    private final RestTemplate restTemplate;
    private final ObjectMapper objectMapper;
    
    public ArchitectureReviewService() {
        this.restTemplate = new RestTemplate();
        this.objectMapper = new ObjectMapper();
    }
    
    public ArchitectureReviewResult reviewArchitecture(String architectureDoc) {
        ArchitectureReviewPromptBuilder promptBuilder = new ArchitectureReviewPromptBuilder();
        String prompt = promptBuilder.buildReviewPrompt(architectureDoc);
        
        HttpHeaders headers = new HttpHeaders();
        headers.set("x-api-key", apiKey);
        headers.set("anthropic-version", "2023-06-01");
        headers.setContentType(MediaType.APPLICATION_JSON);
        
        Map<String, Object> requestBody = new HashMap<>();
        requestBody.put("model", "claude-opus-4-5");
        requestBody.put("max_tokens", 4096);
        
        List<Map<String, String>> messages = new ArrayList<>();
        Map<String, String> userMessage = new HashMap<>();
        userMessage.put("role", "user");
        userMessage.put("content", prompt);
        messages.add(userMessage);
        requestBody.put("messages", messages);
        
        HttpEntity<Map<String, Object>> entity = new HttpEntity<>(requestBody, headers);
        
        try {
            ResponseEntity<Map> response = restTemplate.postForEntity(
                "https://api.anthropic.com/v1/messages",
                entity,
                Map.class
            );
            
            // 解析响应
            List<Map<String, Object>> content = (List<Map<String, Object>>) response.getBody().get("content");
            String reviewText = (String) content.get(0).get("text");
            
            return parseReviewResult(reviewText);
        } catch (Exception e) {
            throw new RuntimeException("架构评审调用失败: " + e.getMessage(), e);
        }
    }
    
    private ArchitectureReviewResult parseReviewResult(String reviewText) {
        // 解析AI返回的结构化评审结果
        ArchitectureReviewResult result = new ArchitectureReviewResult();
        result.setFullReview(reviewText);
        
        // 提取必须修改项
        result.setCriticalIssues(extractSection(reviewText, "必须修改项"));
        // 提取建议优化项
        result.setSuggestedImprovements(extractSection(reviewText, "建议优化项"));
        // 提取总体评分
        result.setOverallAssessment(extractSection(reviewText, "总体评分"));
        
        return result;
    }
    
    private String extractSection(String text, String sectionTitle) {
        int startIdx = text.indexOf("## " + sectionTitle);
        if (startIdx == -1) return "";
        
        int endIdx = text.indexOf("\n## ", startIdx + 1);
        if (endIdx == -1) endIdx = text.length();
        
        return text.substring(startIdx, endIdx).trim();
    }
}

实战演示：一次真实的AI架构评审

用上面那个用户行为分析平台的例子，我把实际的架构文档输入进去，Claude给出了这样的评审（节选关键部分）：

必须修改项（P0）：

RabbitMQ作为行为数据通道存在消息积压风险。当5分钟批处理任务执行期间，前端埋点产生的消息会在队列中堆积。按5万DAU、每用户每分钟10次行为事件计算，5分钟内积压量约250万条消息。需要评估RabbitMQ集群的内存配置是否足够，并设置队列长度限制和告警。

MySQL分表方案需要明确分表键。按用户ID还是时间分表对查询影响截然不同。漏斗查询需要聚合同一用户的多条记录，如果按时间分表，跨表查询会严重影响性能。

这两条我看了冷汗一下——消息积压这个问题我们真的没有做压测验证，分表键的选择也是拍脑袋定的用户ID。

建议优化项（P1）：

考虑在MySQL前加一层时序聚合：每5分钟的批处理不直接写明细数据，而是先聚合成按用户+行为类型+时间段的汇总，减少MySQL写入量约80%。代价是失去明细查询能力，需要根据业务需求确认是否可接受。

这条建议在评审会上没人提过，但实际上我们的运营同事确实只需要聚合数据，根本不需要明细。

架构评审的多轮对话策略

光是一轮评审还不够。我总结了一个三轮对话的策略：

第一轮：整体评审（发现问题）
第二轮：深挖具体问题（"针对你提到的消息积压问题，详细说明一下解决方案"）
第三轮：方案对比（"比较方案A和方案B，在我们团队约束下哪个更合适"）

第二轮对话的Prompt设计尤其重要：

public String buildDeepDivePrompt(String originalArch, String reviewResult, String specificIssue) {
    return String.format("""
        基于以下架构：
        %s
        
        你的评审发现了这个问题：
        %s
        
        现在请深入分析这个具体问题：%s
        
        请提供：
        1. 问题根因分析（从数据流和系统行为角度）
        2. 至少3个解决方案，各有利弊
        3. 针对我们团队（3人后端，熟悉MySQL/RabbitMQ）的推荐方案
        4. 推荐方案的实施步骤（能在2周内完成）
        5. 验证方案有效性的测试方法
        """, originalArch, reviewResult, specificIssue);
}

让AI帮你画架构图

文字评审之外，我发现让AI生成Mermaid架构图也非常有用，可以快速验证自己对架构的理解。

public String generateArchitectureDiagram(String architectureDoc) {
    String prompt = String.format("""
        基于以下架构描述，生成一个Mermaid graph TD图，展示核心数据流。
        
        要求：
        - 节点用英文ID，标签用中文
        - 只展示主要组件和数据流，不超过15个节点
        - 用不同箭头类型区分同步调用（-->）和异步消息（-.->）
        - 对有风险的链路添加注释
        
        架构描述：
        %s
        """, architectureDoc);
    
    // 调用API...
    return callClaudeApi(prompt);
}

生成的Mermaid图示例：

架构评审Checklist自动生成

我还做了一个功能：根据架构类型自动生成针对性的评审Checklist。

@Service
public class ChecklistGeneratorService {
    
    public List<ChecklistItem> generateChecklist(ArchitectureType type, String archDoc) {
        String prompt = String.format("""
            这是一个%s类型的系统架构。
            
            架构描述：
            %s
            
            请生成一个专门针对这类架构的评审Checklist，格式为JSON数组：
            [
              {
                "category": "分类名",
                "item": "具体检查项",
                "severity": "CRITICAL/HIGH/MEDIUM/LOW",
                "question": "需要确认的具体问题"
              }
            ]
            
            只返回JSON，不要其他内容。
            """, type.getDescription(), archDoc);
        
        String jsonResponse = callClaudeApi(prompt);
        
        try {
            return objectMapper.readValue(jsonResponse, 
                new TypeReference<List<ChecklistItem>>() {});
        } catch (JsonProcessingException e) {
            log.error("解析Checklist失败", e);
            return Collections.emptyList();
        }
    }
}

坑位说明：AI评审的局限性

讲了这么多好的，说说真正的坑：

坑一：AI不了解你的团队文化

AI会给出「理论最优解」，但有些时候「能落地的次优解」才是正确答案。比如它推荐引入Service Mesh，但你的团队对Istio一无所知，这条建议就是噪音。

解法：在Prompt里把「团队技术栈熟练度」说清楚，强调「推荐必须在团队现有能力范围内」。

坑二：AI对性能数字的估算不可靠

它说「这个架构能支撑100万QPS」，这种数字不可信。性能必须用真实压测数据说话。

解法：让AI帮你列出需要压测的场景和指标，而不是直接给你性能结论。

坑三：连续对话时AI会「顺着你说」

如果你在第二轮对话中表现出倾向某个方案，AI容易强化你的选择而不是客观评估。

解法：多轮对话时明确说「请客观评估，包括这个方案的缺点，不要偏向我之前提到的想法」。

坑四：AI可能编造不存在的最佳实践

它有时候会引用一些「业界标准」，但这些标准可能是它的幻觉。

解法：对于重要的技术建议，要求AI给出具体的参考来源，然后自己去验证。

在团队中推广AI架构评审

最后说说怎么把这套东西推广到团队里。我的经验：

不要把它包装成「AI替代架构师」，而是包装成「评审前的预检工具」。让开发同学在提交架构方案之前，先跑一遍AI评审，把低级问题过滤掉，让正式评审会议聚焦在真正复杂的决策上。

这样做的效果是：评审会从1.5小时缩短到45分钟，而且发现的问题质量更高。

评审之后，把AI的评审报告连同最终决策一起存档，形成架构决策记录（ADR）。这对后来者理解系统演进历程非常有价值。

架构决策记录（ADR）模板
---
标题：用户行为分析平台 - 消息队列选型
日期：2024-01-15
状态：已采纳

背景：
[业务需求描述]

AI评审发现的问题：
[粘贴AI评审相关部分]

讨论的选项：
- 选项A：保持RabbitMQ，增加消费者数量和队列监控
- 选项B：迁移到Kafka
- 选项C：用数据库队列替代消息中间件

决策：
选择选项A。理由：团队熟悉RabbitMQ，改造成本低；当前规模不需要Kafka级别的吞吐量；
数据库队列对MySQL造成额外压力不可接受。

后果：
需要添加队列深度监控，设置积压告警阈值。

这套AI辅助架构评审的方法，我们团队用了大半年，整体感受是：AI最大的价值不是给你答案，而是帮你把问题问得更全面。一个人的经验再丰富，也有盲区；AI提供的是一种「系统性检查」的能力，弥补的是人类注意力不够全面的短板。