30a - AI辅助架构设计概览

┌─────────────────────────────────────────────────────────────────────┐
│                    AI 辅助架构设计端到端工作流                         │
├─────────────────────────────────────────────────────────────────────┤
│                                                                     │
│  ① 需求收集        ② 架构探索        ③ 方案设计        ④ 文档输出    │
│  ┌──────────┐    ┌──────────┐    ┌──────────┐    ┌──────────┐     │
│  │ 业务需求  │───→│ AI 生成   │───→│ 权衡分析  │───→│ C4 模型   │     │
│  │ 非功能需求│    │ 候选方案  │    │ ADR 编写  │    │ 序列图    │     │
│  │ 约束条件  │    │ 模式匹配  │    │ 技术选型  │    │ 部署图    │     │
│  └──────────┘    └──────────┘    └──────────┘    └──────────┘     │
│       │                │                │                │         │
│       ▼                ▼                ▼                ▼         │
│  ⑤ 架构审查        ⑥ 迭代优化        ⑦ 实现指导        ⑧ 持续同步  │
│  ┌──────────┐    ┌──────────┐    ┌──────────┐    ┌──────────┐     │
│  │ AI 审查   │───→│ 反馈整合  │───→│ 任务分解  │───→│ 代码→文档 │     │
│  │ 清单检查  │    │ 方案迭代  │    │ 实现规范  │    │ 自动同步  │     │
│  │ 安全评估  │    │ 风险缓解  │    │ Steering  │    │ 漂移检测  │     │
│  └──────────┘    └──────────┘    └──────────┘    └──────────┘     │
│                                                                     │
└─────────────────────────────────────────────────────────────────────┘

你是一位资深软件架构师。请帮我将以下业务需求转化为架构设计输入：

## 业务需求
[粘贴产品需求文档或用户故事]

请输出以下结构化信息：
1. **核心功能模块**：列出系统需要的主要功能模块
2. **用户角色**：识别所有用户类型和权限级别
3. **数据实体**：识别核心业务实体和关系
4. **集成需求**：需要对接的外部系统和 API
5. **非功能需求推断**：基于业务场景推断性能、可用性、安全性要求

基于以下业务场景，请帮我量化非功能需求：

## 业务场景
[描述业务场景，如"B2C 电商平台，目标用户 10 万 DAU"]

请为以下维度提供具体指标：
1. **性能**：响应时间（P50/P95/P99）、吞吐量（QPS/TPS）
2. **可用性**：SLA 目标、RTO/RPO
3. **可扩展性**：预期增长曲线、峰值倍数
4. **安全性**：合规要求、数据分类、加密需求
5. **成本约束**：月度基础设施预算范围
6. **团队约束**：团队规模、技术栈熟悉度

请帮我梳理以下项目的架构约束条件：

## 项目背景
- 团队规模：[人数]
- 技术栈偏好：[语言/框架]
- 现有基础设施：[云平台/自建]
- 预算范围：[月度预算]
- 上线时间：[截止日期]
- 合规要求：[GDPR/SOC2/HIPAA 等]

请输出：
1. **硬约束**（不可协商）
2. **软约束**（可以权衡）
3. **假设条件**（需要验证）
4. **风险因素**（可能影响架构决策）

基于以下需求和约束，请推荐 3 个候选架构方案：

## 需求摘要
[从阶段 1 的输出中提取]

## 约束条件
[从阶段 1 的输出中提取]

对于每个候选方案，请提供：
1. **架构模式**：采用的核心架构模式（单体/微服务/Serverless/事件驱动/混合）
2. **组件划分**：主要组件和职责
3. **通信模式**：组件间通信方式（同步/异步/事件）
4. **数据策略**：数据存储和一致性策略
5. **部署模型**：部署拓扑和基础设施需求
6. **优势**：该方案的核心优势
7. **劣势**：该方案的主要风险和不足
8. **适用条件**：在什么条件下该方案最优

请为以下架构方案生成 Mermaid C4 Context 图：

## 方案描述
[选择的候选方案描述]

要求：
1. 使用 Mermaid C4 扩展语法
2. 包含所有外部系统和用户角色
3. 标注主要数据流方向
4. 使用中文标签

┌─────────────────────────────────────────────────────┐
│              多模型架构设计工作流                       │
├─────────────────────────────────────────────────────┤
│                                                     │
│  阶段 1：调研          阶段 2：设计          阶段 3：审查  │
│  ┌──────────┐       ┌──────────┐       ┌──────────┐│
│  │ Gemini   │──────→│ Claude   │──────→│ Claude   ││
│  │ 2.5 Pro  │       │ Opus     │       │ Code     ││
│  │          │       │          │       │          ││
│  │ · 技术调研│       │ · 方案设计│       │ · 代码审查││
│  │ · 趋势分析│       │ · 权衡分析│       │ · 一致性  ││
│  │ · 竞品对比│       │ · ADR 生成│       │ · 安全审查││
│  └──────────┘       └──────────┘       └──────────┘│
│       │                   │                   │    │
│       ▼                   ▼                   ▼    │
│  GPT Deep Research   Mermaid/C4 图        Steering │
│  补充调研             架构文档              规则生成  │
│                                                     │
└─────────────────────────────────────────────────────┘

❌ 错误示例：
"帮我设计一个电商系统的架构"

✅ 正确示例：
"帮我设计一个 B2C 电商系统的架构，约束条件如下：
- 团队：3 名全栈开发者，熟悉 TypeScript/React/Node.js
- 预期规模：初期 1000 DAU，1 年内增长到 5 万 DAU
- 预算：月度基础设施预算 $500 以内
- 上线时间：3 个月内 MVP
- 合规：需要支持 GDPR
- 现有基础设施：AWS 账号，无现有服务"

❌ 错误示例：
"这个系统应该用微服务还是单体？"

✅ 正确示例：
"请为这个系统提供 3 个候选架构方案（单体优先、模块化单体、微服务），
对每个方案从以下维度进行对比分析：
1. 开发速度（MVP 阶段）
2. 运维复杂度
3. 团队学习成本
4. 扩展性（1 年后）
5. 月度基础设施成本估算
6. 风险因素
最后给出你的推荐和理由。"

✅ 好的 Prompt 补充：
"在设计方案中，请特别考虑以下'Day 2'运维问题：
- 如何监控和告警？
- 故障时如何排查和恢复？
- 如何进行零停机部署？
- 数据备份和灾难恢复策略？
- 日志聚合和追踪方案？"

✅ 好的 Prompt 模式：
"请设计一个可演进的架构方案，分三个阶段：
- Phase 1（MVP，0-3 个月）：最简可行架构
- Phase 2（增长期，3-12 个月）：应对用户增长的架构演进
- Phase 3（成熟期，12+ 个月）：长期目标架构
每个阶段说明：架构变化、触发条件、迁移策略、预估成本"

你是一位拥有 15 年经验的软件架构师。请为以下系统设计架构方案。

## 系统概述
[系统名称和一句话描述]

## 核心功能需求
1. [功能 1]
2. [功能 2]
3. [功能 3]

## 非功能需求
- 性能：[响应时间/吞吐量要求]
- 可用性：[SLA 目标]
- 安全性：[合规要求]
- 可扩展性：[增长预期]

## 约束条件
- 团队：[规模和技术栈]
- 预算：[基础设施预算]
- 时间：[上线截止日期]
- 现有系统：[需要集成的系统]

## 输出要求
请提供：
1. **架构概览**：一段话描述整体架构策略
2. **架构图**：使用 Mermaid C4 Context 图展示系统边界和外部交互
3. **组件设计**：主要组件、职责、技术选型
4. **数据架构**：数据存储策略、一致性模型
5. **通信设计**：组件间通信模式（同步/异步/事件）
6. **部署架构**：部署拓扑和基础设施需求
7. **安全设计**：认证、授权、数据保护策略
8. **演进路线**：从 MVP 到成熟期的架构演进计划

请帮我进行以下技术选型的对比分析：

## 选型场景
[描述需要做技术选型的具体场景，如"后端 API 框架选型"]

## 候选技术
1. [技术 A]
2. [技术 B]
3. [技术 C]

## 评估维度
请从以下维度进行对比（每个维度 1-5 分评分）：

| 维度 | [技术 A] | [技术 B] | [技术 C] |
|------|---------|---------|---------|
| 性能 | | | |
| 学习曲线 | | | |
| 生态成熟度 | | | |
| 社区活跃度 | | | |
| 企业采用率 | | | |
| AI 工具支持度 | | | |
| 长期维护前景 | | | |
| 招聘难度 | | | |

## 项目约束
- [约束 1]
- [约束 2]

## 输出要求
1. 对比评分表
2. 每个技术的核心优劣势（各 3 点）
3. 基于项目约束的推荐选择及理由
4. 风险提示和缓解措施

请为以下架构方案生成审查清单：

## 架构方案摘要
[粘贴架构方案描述]

请从以下维度生成审查问题：

### 功能完整性
- 所有核心功能是否都有对应的组件承载？
- 是否存在功能遗漏或重叠？

### 非功能需求
- 性能瓶颈在哪里？如何应对？
- 单点故障在哪里？如何消除？
- 安全攻击面有哪些？如何防护？

### 可维护性
- 组件边界是否清晰？耦合度如何？
- 新功能添加的典型路径是什么？
- 技术债务风险在哪里？

### 运维就绪
- 监控和告警策略是否完整？
- 部署和回滚流程是否明确？
- 灾难恢复方案是否可行？

### 成本效益
- 基础设施成本估算是否合理？
- 是否存在过度设计？
- 成本随规模增长的曲线如何？

请为每个维度提供 3-5 个具体的审查问题，并标注优先级（P0/P1/P2）。

请为以下系统生成 C4 模型的 [Context/Container/Component] 图，使用 Mermaid 语法：

## 系统描述
[系统名称和功能描述]

## 用户角色
1. [角色 1]：[描述]
2. [角色 2]：[描述]

## 外部系统
1. [系统 1]：[描述]
2. [系统 2]：[描述]

## 主要组件（仅 Container/Component 图需要）
1. [组件 1]：[技术栈] - [职责]
2. [组件 2]：[技术栈] - [职责]

## 输出要求
1. 使用 Mermaid C4 扩展语法
2. 所有标签使用中文
3. 标注主要数据流方向和协议
4. 包含图例说明

请帮我编写一份架构决策记录（ADR）：

## 决策标题
[简短描述决策内容，如"选择 PostgreSQL 作为主数据库"]

## 决策背景
[描述为什么需要做这个决策，当前面临的问题或机会]

## 请按以下 ADR 模板输出：

### 状态
[提议/已接受/已废弃/已替代]

### 背景
[详细描述决策的业务和技术背景]

### 决策驱动因素
[列出影响决策的关键因素]

### 考虑的选项
1. **[选项 A]**：[简述]
2. **[选项 B]**：[简述]
3. **[选项 C]**：[简述]

### 决策结果
选择 [选项 X]，因为 [核心理由]。

### 各选项优劣分析
[对每个选项进行详细的优劣分析]

### 后果
#### 正面
- [正面后果 1]
#### 负面
- [负面后果 1]
#### 风险
- [风险 1]：[缓解措施]

提示词模板：模块化单体设计

请为以下系统设计模块化单体架构：

## 系统需求
[需求描述]

## 设计要求
1. 采用模块化单体（Modular Monolith）模式
2. 每个模块有清晰的边界和公共 API
3. 模块间通过接口通信，禁止直接访问内部实现
4. 数据库 Schema 按模块隔离（Schema-per-module）
5. 为未来可能的微服务拆分预留接缝

## 输出
1. 模块划分和职责定义
2. 模块间依赖关系图（Mermaid）
3. 每个模块的公共 API 定义
4. 数据库 Schema 隔离策略
5. 未来拆分的预留接缝说明

提示词模板：微服务边界划分

请基于以下业务领域，使用 DDD（领域驱动设计）方法划分微服务边界：

## 业务领域描述
[描述业务领域和核心流程]

## 已识别的业务实体
[列出核心业务实体]

## 设计要求
1. 使用限界上下文（Bounded Context）划分服务边界
2. 识别聚合根（Aggregate Root）
3. 定义上下文映射（Context Map）
4. 确定服务间通信模式（同步 vs 异步）
5. 设计数据所有权（每个服务拥有自己的数据）

## 输出
1. 限界上下文图（Mermaid）
2. 每个微服务的职责、数据所有权、公共 API
3. 服务间通信模式和协议选择
4. 数据一致性策略（Saga/事件溯源/最终一致性）
5. 服务依赖关系和部署顺序

## 微服务架构 Steering 规则
 
### 服务划分
- 每个微服务应对应一个限界上下文，不要按技术层划分
- 初始服务数量不超过团队人数的 2 倍
- 如果两个服务总是一起部署，考虑合并
 
### 通信设计
- 同步调用链不超过 3 层
- 跨服务数据查询优先使用 CQRS 读模型，而非级联 API 调用
- 所有异步通信必须设计幂等性和重试策略
 
### 数据管理
- 每个服务拥有自己的数据库 Schema
- 禁止跨服务直接访问数据库
- 数据同步使用事件驱动，而非定时批量同步

提示词模板：Serverless 架构设计

请为以下系统设计 Serverless 架构方案：

## 系统需求
[需求描述]

## 云平台
[AWS Lambda / Google Cloud Functions / Azure Functions / Cloudflare Workers]

## 设计要求
1. 识别适合 Serverless 的功能和不适合的功能
2. 设计事件驱动的函数编排
3. 考虑冷启动优化策略
4. 设计状态管理方案（Serverless 是无状态的）
5. 估算成本（基于预期调用量）

## 输出
1. 函数清单（名称、触发器、运行时、内存、超时）
2. 事件流图（Mermaid）
3. 状态管理策略（DynamoDB/Redis/Step Functions）
4. 冷启动优化方案
5. 成本估算表
6. 不适合 Serverless 的部分及替代方案

提示词模板：事件驱动架构设计

请为以下系统设计事件驱动架构：

## 业务流程
[描述核心业务流程，包括步骤和参与者]

## 设计要求
1. 识别领域事件（Domain Events）
2. 设计事件 Schema（CloudEvents 格式）
3. 选择消息中间件（Kafka/RabbitMQ/AWS EventBridge/NATS）
4. 设计事件溯源（Event Sourcing）策略（如适用）
5. 处理事件顺序性和幂等性

## 输出
1. 领域事件清单（事件名、生产者、消费者、Schema）
2. 事件流图（Mermaid 序列图）
3. 消息中间件选型和配置建议
4. 事件 Schema 定义（JSON Schema）
5. 幂等性和重试策略
6. 事件存储和回放策略

提示词模板：混合架构与演进路线

请为以下系统设计混合架构方案和演进路线：

## 当前状态
[描述现有系统架构，如"Rails 单体应用，PostgreSQL 数据库"]

## 目标状态
[描述期望的目标架构]

## 约束条件
- 不能停机迁移
- 团队规模：[人数]
- 迁移预算：[时间和资金]

## 输出
1. **Phase 1（稳定期）**：最小改动，解决当前痛点
   - 具体改动清单
   - 预期效果
   - 风险和回滚方案

2. **Phase 2（演进期）**：逐步引入新架构元素
   - 拆分策略（Strangler Fig 模式）
   - 数据迁移方案
   - 双写/双读过渡策略

3. **Phase 3（目标期）**：达到目标架构
   - 最终架构图
   - 清理遗留代码的计划
   - 性能基准对比

每个阶段包含：架构图（Mermaid）、时间估算、风险评估、回滚方案

                        ┌─────────────────┐
                        │  项目初始阶段？   │
                        └────────┬────────┘
                                 │
                    ┌────────────┴────────────┐
                    │ 是                       │ 否（已有系统）
                    ▼                          ▼
            ┌───────────────┐         ┌───────────────┐
            │ 团队 ≤ 5 人？  │         │ 使用混合架构   │
            └───────┬───────┘         │ + 演进路线     │
                    │                 └───────────────┘
           ┌───────┴───────┐
           │ 是             │ 否
           ▼               ▼
    ┌──────────────┐ ┌──────────────┐
    │ 模块化单体    │ │ 预期 DAU？    │
    │ (推荐起步)   │ └──────┬───────┘
    └──────────────┘        │
                    ┌───────┴───────┐
                    │ < 10 万        │ ≥ 10 万
                    ▼               ▼
             ┌──────────────┐ ┌──────────────┐
             │ 模块化单体    │ │ 核心业务      │
             │ + Serverless │ │ 微服务        │
             │ (异步任务)   │ │ + 事件驱动    │
             └──────────────┘ └──────────────┘

请帮我选择最适合的架构风格。以下是项目信息：

- 项目类型：[SaaS/电商/社交/内部工具/API 平台]
- 团队规模：[人数]
- 预期用户规模：[DAU]
- 上线时间要求：[月数]
- 预算级别：[低/中/高]
- 合规要求：[有/无，具体要求]
- 现有技术栈：[语言/框架/云平台]
- 最大技术风险：[描述]

请推荐架构风格，并解释：
1. 为什么选择这个风格
2. 这个风格在当前约束下的具体实现方案
3. 未来可能的演进方向
4. 需要特别注意的风险

┌──────────────────────────────────────────────────────────┐
│              Kiro Spec 驱动架构设计流程                     │
├──────────────────────────────────────────────────────────┤
│                                                          │
│  ① requirements.md          ② design.md                  │
│  ┌────────────────────┐    ┌────────────────────┐       │
│  │ 需求 1：用户认证     │    │ 架构概览            │       │
│  │   AC 1.1：JWT 认证  │───→│ 组件设计            │       │
│  │   AC 1.2：OAuth 2.0 │    │ 数据模型            │       │
│  │ 需求 2：订单管理     │    │ API 设计            │       │
│  │   AC 2.1：创建订单  │    │ 部署架构            │       │
│  └────────────────────┘    └─────────┬──────────┘       │
│                                       │                  │
│  ③ tasks.md                          │                  │
│  ┌────────────────────┐              │                  │
│  │ Task 1：实现认证模块 │◄─────────────┘                  │
│  │ Task 2：实现订单服务 │                                 │
│  │ Task 3：部署配置     │                                 │
│  └────────────────────┘                                 │
│                                                          │
│  ④ Steering 规则（.kiro/steering/）                       │
│  ┌────────────────────┐                                 │
│  │ 架构约束规则         │  ← 自动约束代码实现符合架构设计    │
│  │ 命名规范规则         │                                 │
│  │ 安全规则            │                                 │
│  └────────────────────┘                                 │
│                                                          │
└──────────────────────────────────────────────────────────┘

# 架构设计 Steering 规则
 
## 架构原则
- 优先选择简单方案，避免过度工程化
- 新功能必须先评估对现有架构的影响
- 所有架构决策必须记录 ADR
- 遵循 SOLID 原则和 12-Factor App 方法论
 
## 技术栈约束
- 后端：Node.js + TypeScript + Fastify
- 数据库：PostgreSQL（主库）+ Redis（缓存）
- 消息队列：仅在确认需要异步处理时引入
- 前端：React + Next.js
- 部署：AWS ECS Fargate
 
## 架构边界
- 模块间通过接口通信，禁止直接导入内部实现
- 数据库访问仅通过 Repository 层
- 外部 API 调用必须通过 Gateway 层，包含重试和熔断
- 配置通过环境变量注入，禁止硬编码
 
## 禁止事项
- 禁止在 MVP 阶段引入微服务架构
- 禁止使用未经团队评审的新技术
- 禁止跨模块直接访问数据库表
- 禁止在业务逻辑层直接调用外部 API

你是一位资深软件架构师。我们是一个 3 人全栈团队（熟悉 TypeScript/React/Node.js），
要在 4 个月内构建一个 SaaS 项目管理工具（类似简化版 Linear）。

目标用户：中小型开发团队（5-50 人）
核心功能：项目管理、Issue 追踪、看板视图、实时协作、GitHub 集成
预期规模：初期 500 个团队，1 年内增长到 5000 个团队
预算：月度基础设施 $300 以内（初期）

请帮我：
1. 结构化非功能需求（性能、可用性、安全性指标）
2. 识别核心架构约束
3. 推荐 3 个候选架构方案并对比

## 非功能需求
- 性能：API P95 < 200ms，WebSocket 消息延迟 < 100ms
- 可用性：99.9% SLA（月度停机 < 43 分钟）
- 安全性：SOC 2 Type I（6 个月内），数据加密（传输 + 静态）
- 可扩展性：支持 5000 团队 × 50 人 = 25 万用户

## 候选方案对比

| 维度 | 方案 A：模块化单体 | 方案 B：微服务 | 方案 C：Serverless |
|------|-----------------|-------------|-----------------|
| 开发速度 | ⭐⭐⭐⭐⭐ | ⭐⭐ | ⭐⭐⭐⭐ |
| 运维复杂度 | ⭐⭐⭐⭐⭐（低） | ⭐⭐（高） | ⭐⭐⭐（中） |
| 团队匹配度 | ⭐⭐⭐⭐⭐ | ⭐⭐ | ⭐⭐⭐ |
| 扩展性 | ⭐⭐⭐ | ⭐⭐⭐⭐⭐ | ⭐⭐⭐⭐ |
| 月度成本 | ~$150 | ~$500+ | ~$100-400（波动） |
| 实时协作支持 | ⭐⭐⭐⭐ | ⭐⭐⭐⭐⭐ | ⭐⭐（WebSocket 受限） |

推荐：方案 A（模块化单体），理由：
1. 3 人团队无法承受微服务的运维复杂度
2. 模块化单体可以在 1 年后按需拆分
3. 成本最低，符合预算约束
4. 开发速度最快，4 个月可交付 MVP

基于方案 A（模块化单体），请生成以下架构图：

1. C4 Context 图（系统边界和外部交互）
2. C4 Container 图（主要容器和技术栈）

使用 Mermaid 语法，标签使用中文。

请为"选择模块化单体架构"这个决策生成 ADR：

背景：3 人团队，4 个月 MVP，SaaS 项目管理工具
候选方案：模块化单体、微服务、Serverless
最终选择：模块化单体

# ADR-001：选择模块化单体架构
 
## 状态
已接受（2025-XX-XX）
 
## 背景
团队需要在 4 个月内交付 SaaS 项目管理工具的 MVP。
团队规模 3 人，技术栈为 TypeScript/React/Node.js。
 
## 决策
采用模块化单体架构，使用 Fastify + TypeScript 构建 API 服务。
 
## 理由
1. 3 人团队无法承受微服务的运维复杂度
2. 模块化设计为未来拆分预留接缝
3. 单一部署单元简化 CI/CD 和监控
4. 开发速度最快，符合 4 个月时间约束
 
## 后果
- 正面：开发速度快，运维简单，成本低
- 负面：单一进程的扩展性有限
- 风险：模块边界不清晰可能导致"大泥球"
- 缓解：通过 Steering 规则强制模块边界

请基于以下架构决策，生成 Kiro Steering 规则文件：

架构：模块化单体
模块：auth、project、issue、board、notification、integration
技术栈：Fastify + TypeScript + Prisma + PostgreSQL

请对以下代码仓库进行架构健康度审查：

## 仓库信息
- 语言：[TypeScript/Python/Go/Java]
- 框架：[框架名称]
- 目录结构：
[粘贴 tree 命令输出或目录结构]

## 审查维度
请从以下维度评估架构健康度（每个维度 1-5 分）：

1. **模块边界清晰度**
   - 模块间是否有清晰的接口？
   - 是否存在循环依赖？
   - 是否有模块职责过大（"上帝模块"）？

2. **依赖管理**
   - 依赖方向是否正确（高层不依赖低层实现）？
   - 外部依赖是否通过适配器隔离？
   - 是否存在不必要的依赖？

3. **数据流合理性**
   - 数据是否在正确的层级处理？
   - 是否存在数据穿透（跨层直接访问）？
   - 数据转换是否在边界处完成？

4. **错误处理一致性**
   - 错误处理模式是否统一？
   - 是否有未处理的异常路径？
   - 错误信息是否对调试有帮助？

5. **可扩展性预留**
   - 是否有明确的扩展点？
   - 新功能添加是否需要修改核心代码？
   - 配置是否外部化？

## 输出要求
1. 每个维度的评分和具体发现
2. Top 5 架构改进建议（按优先级排序）
3. 架构漂移风险评估
4. 建议的 Steering 规则（防止进一步退化）

┌─────────────────────────────────────────────────────┐
│              AI 驱动的架构漂移检测                      │
├─────────────────────────────────────────────────────┤
│                                                     │
│  ① 架构基线                ② 代码分析                │
│  ┌──────────────┐        ┌──────────────┐          │
│  │ 设计文档      │        │ 实际代码      │          │
│  │ C4 模型      │        │ 依赖关系      │          │
│  │ ADR 记录     │        │ 模块边界      │          │
│  │ Steering 规则│        │ API 接口      │          │
│  └──────┬───────┘        └──────┬───────┘          │
│         │                       │                   │
│         └───────────┬───────────┘                   │
│                     ▼                               │
│  ③ AI 对比分析                                      │
│  ┌──────────────────────────────┐                  │
│  │ · 设计依赖 vs 实际依赖        │                  │
│  │ · 模块边界是否被突破          │                  │
│  │ · API 契约是否变更            │                  │
│  │ · 新增组件是否符合架构模式     │                  │
│  └──────────────┬───────────────┘                  │
│                  ▼                                  │
│  ④ 漂移报告                                        │
│  ┌──────────────────────────────┐                  │
│  │ · 漂移严重度评分              │                  │
│  │ · 具体漂移点列表              │                  │
│  │ · 修复建议和优先级            │                  │
│  │ · 更新的 Steering 规则建议    │                  │
│  └──────────────────────────────┘                  │
│                                                     │
└─────────────────────────────────────────────────────┘

请对比以下架构设计文档和实际代码结构，检测架构漂移：

## 设计文档中的架构规则
[粘贴架构设计文档中的关键规则，如模块边界、依赖方向、通信模式等]

## 实际代码结构
[粘贴 tree 命令输出或关键文件的 import 语句]

## 检测要求
1. 识别所有违反架构规则的代码
2. 评估每个违规的严重程度（高/中/低）
3. 分析违规的可能原因（紧急修复？需求变更？理解偏差？）
4. 提供修复建议
5. 建议新增或更新的 Steering 规则以防止再次漂移

# 在项目根目录启动 Claude Code
claude
 
# 输入架构分析 Prompt
> 请分析这个项目的架构：
> 1. 识别主要模块和它们的职责
> 2. 绘制模块间依赖关系图（Mermaid）
> 3. 识别架构问题（循环依赖、过度耦合、职责不清）
> 4. 提供改进建议

// .claude/mcp.json 或 .kiro/mcp.json
{
  "mcpServers": {
    "filesystem": {
      "command": "npx",
      "args": ["-y", "@anthropic/mcp-filesystem", "/path/to/project"]
    },
    "github": {
      "command": "npx",
      "args": ["-y", "@anthropic/mcp-github"],
      "env": {
        "GITHUB_TOKEN": "your-token"
      }
    }
  }
}

# 使用 Plan Mode 先规划重构方案
claude --plan
 
> 我想将 auth 模块从 monolith 中提取为独立的服务层。
> 请先分析影响范围，然后制定分步重构计划。
> 不要直接修改代码，先给我看计划。
 
# 审查计划后，切换到 Act Mode 执行
claude
 
> 请按照刚才的计划，执行第 1 步：提取 auth 接口定义。
> 每步完成后暂停，等我确认再继续。

# 在 Kiro 中使用 Spec Mode
"请帮我为 [项目名称] 创建架构设计 Spec"

// .kiro/hooks/architecture-check.json
{
  "name": "架构一致性检查",
  "trigger": "on-file-save",
  "pattern": "src/**/*.ts",
  "action": "检查新增的 import 是否违反模块边界规则"
}

┌─────────────────────────────────────────────────────┐
│              多 Agent 架构设计协作                      │
├─────────────────────────────────────────────────────┤
│                                                     │
│  Agent 1：需求分析师        Agent 2：架构师           │
│  ┌──────────────┐        ┌──────────────┐          │
│  │ · 需求结构化   │───────→│ · 方案设计    │          │
│  │ · 约束识别    │        │ · 权衡分析    │          │
│  │ · 优先级排序   │        │ · 图表生成    │          │
│  └──────────────┘        └──────┬───────┘          │
│                                  │                  │
│  Agent 3：安全审查员       Agent 4：成本分析师        │
│  ┌──────────────┐        ┌──────────────┐          │
│  │ · 威胁建模    │◄───────│ · 成本估算    │          │
│  │ · 安全审查    │        │ · 资源规划    │          │
│  │ · 合规检查    │        │ · ROI 分析    │          │
│  └──────┬───────┘        └──────┬───────┘          │
│         │                       │                   │
│         └───────────┬───────────┘                   │
│                     ▼                               │
│  人工架构师：最终决策                                  │
│  ┌──────────────────────────────┐                  │
│  │ · 综合各 Agent 输出           │                  │
│  │ · 做出最终架构决策             │                  │
│  │ · 记录 ADR                   │                  │
│  │ · 制定实施计划                │                  │
│  └──────────────────────────────┘                  │
│                                                     │
└─────────────────────────────────────────────────────┘

# 主 Agent 协调多个 Subagent
claude
 
> 请使用以下工作流完成架构设计：
>
> 1. 先作为"需求分析师"角色，结构化以下需求：[需求描述]
> 2. 然后切换为"架构师"角色，基于结构化需求设计 3 个候选方案
> 3. 再切换为"安全审查员"角色，审查每个方案的安全风险
> 4. 最后切换为"成本分析师"角色，估算每个方案的基础设施成本
>
> 每个角色完成后，汇总输出综合评估报告。

┌─────────────────────────────────────────────────────┐
│              架构设计中的人机协作模式                    │
├─────────────────────────────────────────────────────┤
│                                                     │
│  AI 负责（效率层）          人工负责（判断层）          │
│  ┌──────────────┐        ┌──────────────┐          │
│  │ · 信息收集    │        │ · 业务优先级   │          │
│  │ · 方案生成    │        │ · 最终决策    │          │
│  │ · 图表绘制    │        │ · 风险判断    │          │
│  │ · 文档编写    │        │ · 团队匹配    │          │
│  │ · 代码审查    │        │ · 利益相关者   │          │
│  │ · 漂移检测    │        │   沟通        │          │
│  └──────────────┘        └──────────────┘          │
│                                                     │
│  协作原则：                                          │
│  1. AI 提供选项，人工做决策                            │
│  2. AI 生成草稿，人工审查和修正                        │
│  3. AI 执行检查，人工解读结果                          │
│  4. AI 维护文档，人工确保准确性                        │
│                                                     │
└─────────────────────────────────────────────────────┘