hotplex-arch-analyzer

name	hotplex-arch-analyzer
description	HotPlex 项目架构和代码健康深度审计 — **立即调用此 skill 进行**：架构分析、代码质量审查、SOLID/DRY 合规检查、并发/性能审计、安全扫描、非功能分析、代码健康度改进、模块质量评估。**专为 HotPlex Gateway 多层架构优化**（WebSocket/Session/Worker/Messaging），自动创建 GitHub Issue 和验收标准。增量式模块分析 + 跨会话进度追踪 + 优先级排序 = **最有效的 /loop 循环执行工具**，适用于大型 Go 代码库的系统性审计。

架构深度分析器

为什么使用此 skill？

架构分析是复杂且易出错的工作 — 容易遗漏重要问题、产生误报、或浪费时间在低价值发现上。此 skill 通过以下方式解决这些问题：

渐进式分析 — 每次 2-3 个方面，避免信息过载，让每个发现都经过深思熟虑 智能优先级 — 自动优先分析最少审计模块，确保覆盖均衡 置信度 + ROI 分诊 — 过滤误报和低价值发现，只创建高影响力 issue 持久化进度 — 跨会话追踪，支持 /loop 连续执行，不会丢失工作 HotPlex 专用优化 — 针对 Gateway 多层架构的特殊模式定制

核心设计：每次调用 = 一个分析周期在一个模块上覆盖2-3 个方面。专为 /loop 设计 — 重复调用在 4 个深度阶段中渐进覆盖所有模块 × 所有方面。

状态持久化在 .claude/arch-analysis/progress.json — 跨会话重启存活，启用 /loop 连续性。

为什么使用 /loop？

手动执行的问题：

• 需要记住调用 skill 数十次
• 容易丢失分析进度
• 难以跟踪覆盖哪些模块
• 容易过早停止

使用 /loop 的好处：

• 自动化：设置后无需干预，持续分析所有模块
• 持久化：进度文件保存状态，中断后可以恢复
• 可视化：每次调用显示覆盖矩阵，清楚看到进度
• 均衡覆盖：智能优先级确保最少分析的模块优先处理

推荐 /loop 设置：

/loop 10m /hotplex-arch-analyzer

这每 10 分钟运行一次分析，适合大型代码库的渐进式分析。调整间隔基于代码库大小和分析深度需求。

---

如何阅读本文档

本文档使用渐进式信息披露 — 快速开始只需阅读工作流概览和步骤 1-3。详细参考材料（模块发现、分析方面、进度文件模式）在后面供需要时查阅。

快速路径（新用户）：

1. 阅读工作流概览
2. 理解步骤 1-3（加载进度、选择模块、选择方面）
3. 跳到步骤 5（Issue 模板）开始使用

深度路径（经验用户）：

1. 完整阅读所有步骤
2. 参考常见陷阱故障排除
3. 自定义模块发现和方面选择逻辑

---

工作流概览

每次调用遵循 7 步流程，从加载进度到创建 GitHub issue：

加载进度 → 选择模块 → 选择方面 → 深度分析 → 分诊（置信度+ROI）→ 创建 Issue → 更新进度 → 报告

为什么这样设计：这种流程确保每次调用都产生可操作的结果，同时保持长期分析轨迹。分诊步骤防止创建低价值 issue，节省团队审查时间。

步骤 1：加载进度

读取 .claude/arch-analysis/progress.json。

如果未找到 — 运行初始化：

1. 发现模块（见下面的模块发现）
2. 创建进度文件，所有模块的所有 aspects 待处理
3. 输出发现的模块列表
4. 继续到步骤 2

步骤 2：选择目标模块

优先级（第一个匹配胜出）：

1. analysis_count == 0 — 从未分析，最高优先级
2. 最低 analysis_count — 最少覆盖
3. 在平局中：优先核心模块（gateway > session > messaging > worker > config > others）
4. 仍然平局：按字母顺序

步骤 3：选择方面

每个模块在 4 个阶段中有 12 个方面。从 aspects_pending 中选择 2-3 个：

• 如果阶段 1 方面仍存在 → 从阶段 1 中选择
• 如果阶段 1 完成，阶段 2 仍存在 → 从阶段 2 中选择
• 以此类推
• 如果所有方面都覆盖 → 重新分析最旧的阶段以获取更深入的见解（增量深度）

步骤 4：深度分析

对于每个选定的方面，读取目标模块中的所有源文件（包括 _test.go）。

为什么读取所有文件：架构问题往往跨文件显现 — 只看单个文件会遗漏耦合模式、重复逻辑、或不一致的错误处理。

分析特定方面时，读取 references/analysis-checklist.md 中的相应部分，以获取要检查的内容的详细清单。清单提供了要验证的具体项目 — 将其用作指南，而非强制性逐项清单。

分析产出标准：每个发现必须包含四个要素：

• 什么：具体问题描述
• 哪里：file.go:line_range 引用（通常 2-3 个文件位置提供充分上下文）
• 为什么：影响/风险量化（例如："影响 N 个调用点"，"每个请求持有锁约 ~200ms"）
• 如何：重构方向 + 代码片段显示 before/after 模式

为什么需要代码片段：没有代码示例的发现难以理解和实施。片段让问题立即可操作，无需审查者重新阅读源代码。

代码片段指南

每个发现必须包含一个最小的代码示例，演示问题和修复方向。这使得问题可立即操作，无需重新阅读源代码。

好的片段 — 显示问题模式和提议的替代方案：

// 当前：静默错误丢失
if err != nil {
    log.Error("failed", "err", err)
    return nil  // 调用者不知道这失败了
}

// 提议：带上下文传播
if err != nil {
    return fmt.Errorf("handleMessage: %w", err)
}

太冗长 — 不要粘贴整个函数。提取重要的 5-15 行模式。 太模糊 — 不要写"重构使用接口"而不显示接口签名。

对于结构/设计发现（SOLID、DRY），显示提议的接口或类型分解：

// 提议的提取
type MessagePipeline interface {
    Parse(ctx context.Context, raw any) (*ParsedMessage, error)
    Filter(ctx context.Context, msg *ParsedMessage) (bool, error)
    Route(ctx context.Context, msg *ParsedMessage) error
}

严重性级别：Critical（数据丢失 / 安全 / 死锁）> High（可靠性 / 性能）> Medium（可维护性 / DRY）> Low（风格 / 命名 / 次要）

如果方面没有产生真正的发现，则跳过 — 不要制造问题。

步骤 4.5：发现分诊（置信度 + ROI）

为什么分诊很重要：未经分诊的分析会产生大量误报和低价值发现，浪费审查时间并降低对架构分析的信任。通过评估置信度和 ROI，只创建真正重要的问题。

在创建 issue 之前，通过两个过滤器对每个发现进行分诊：

置信度评估

评估您对这是真正问题而非误报的确定性程度：

级别	标准	行动
高	多个代码引用确认问题；模式明确；可用具体示例轻松演示	创建 issue
中	单个实例但模式清晰；匹配众所周知的反模式；中等代码证据	创建 issue（在 issue 中注明置信度）
低	推测性；可能是有意的设计；代码证据不足；需要更深入的调查以确认	丢弃（在进度中记为"观察到但不可操作"）

为什么丢弃低置信度发现：它们浪费审查者时间，并降低对架构分析过程的信任。在进度中记录它们以便后续重新分析时重新评估。

ROI 评估

评估修复每个发现的投入产出比 — 这决定是否值得花费工程时间：

维度	问题要问
修复投入	要更改的代码行？回归风险？是否需要架构更改？
修复后影响	它会解锁其他改进吗？减少 bug 表面积吗？提高可测试性吗？
延迟影响	它会进一步衰减吗？阻止其他工作吗？导致生产问题吗？

ROI 分类和行动：

• 高 ROI → 小投入，大影响（快速获胜，解锁改进）→ 总是创建 issue
• 中 ROI → 中等投入，明确影响（重构模式，减少重复）→ 创建 issue
• 低 ROI → 大投入，边际影响（风格问题，过早抽象）→ 丢弃，除非是 Critical/High 严重性

为什么 ROI 比严重性更重要：一个 Low 严重性但高 ROI 的问题（如简单的 DRY 重构）比 High 严重性但低 ROI 的问题（如需要重写的大型重构）更值得优先处理。

分诊输出

分诊后，将发现组织到 issue 中：

• 以高置信度 + 高 ROI发现开头（最具影响力）
• 然后是中置信度或中 ROI发现
• 省略低置信度或低 ROI 发现（在进度文件中注明）

步骤 5：创建 GitHub Issue

将此周期的所有发现合并到一个 GitHub issue 中。

为什么合并而不是拆分：相关问题放在一个 issue 中提供上下文 — 审查者可以看到模式的完整图景，实施者可以在一次 PR 中解决相关问题，减少上下文切换。

重要的格式规则：

• 避免 # 数字：GitHub 将 #1 解释为 issue 引用。使用描述性标题或基于 bullet 的编号
• 使用 #### finding-name 或 - **Finding Name**: 作为子标题，永远不要用 #### 1. Title
• 写"cycle N"或"cycle number N" 而不是"cycle #N"

Issue 模板

Issue 遵循结构化格式，包含 6 个部分：Background → Finding Summary → Findings → Implementation Priority → Out of Scope → Verification。

gh issue create --title "<type>(<module>): <concise-scope-description>" \
  --label "architecture" --label "<severity-label>" \
  --body "$(cat <<'EOF'
## Background

<1-2 句话：模块的角色、当前规模（文件数、行数）、为什么进行此分析>

**Scope**: <aspect1>, <aspect2> — cycle N (模块分析通过 M)
**Key files**: `<file1.go>`, `<file2.go>`, `<file3.go>`

---

## Finding Summary

| Category | Critical | High | Medium | Low |
|----------|----------|------|--------|-----|
| <aspect1> | <n> | <n> | <n> | <n> |
| <aspect2> | <n> | <n> | <n> | <n> |
| **合计** | **<n>** | **<n>** | **<n>** | **<n>** |

---

## Findings

### <Aspect Name>

#### <descriptive-finding-name-without-numbers>

**Severity**: Critical | **Confidence**: High | **ROI**: High
**Location**: `file.go:123-145`, `file2.go:67-89`

**Problem**: <什么错了，为什么重要 — 量化："影响 N 个调用点"，"持有锁约 ~Xms">

**Current Pattern**:
```go
// file.go:123-145
<5-15 行摘录显示问题代码>

Proposed Fix:

<提议的代码显示修复方向 — 接口、类型分解或更正的逻辑>

Estimated Impact: <量化："~N 行减少"，"防止 X 类 bug"，"启用 Y">

Acceptance Criteria:

• <具体的、可验证的更改 — 文件 + 预期行为>
• <添加/更新测试以验证>
• <无回归：什么绝不能更改>

---

<重复每个发现，用 --- 分隔>

---

Implementation Priority

Finding	Priority	Effort	Risk	Impact
	P0	Small	Low	~N 行，解锁 X
	P1	Medium	Medium	防止 Y 类 bug
	P2	Large	Low	改进 Z

Recommended starting point: <首先解决哪个发现以及为什么 — 通常是 P0/High-ROI>

---

Out of Scope

以下区域有意不更改：

• : <原因 — 例如，"平台 API 差异使抽象适得其反">
• : <原因 — 例如，"已经通过现有接口很好地抽象">

---

Verification

• make test 通过，无回归
• make lint 不产生新警告
• <模块特定的行为验证> EOF )"

#### 标题格式

使用 conventional commit 风格：`<type>(<module>): <scope>`

| 类型 | 何时 |
|------|------|
| `refactor` | DRY/SOLID/耦合发现 |
| `fix` | 错误处理/并发/资源泄漏发现 |
| `perf` | 性能/可扩展性发现 |
| `security` | 安全发现 |
| `chore` | 可观测性/可测试性/代码质量发现 |

#### 标签映射

按所有发现的最大严重性：
- Critical → `P1`
- High → `P2`
- Medium/Low → `P3`

如果没有值得 issue 的发现（都低/信息性），跳过 issue 创建并在进度中注明。

### 步骤 6：更新进度

更新 `.claude/arch-analysis/progress.json`：
- 增加模块的 `analysis_count`
- 将分析的方面移至 `aspects_covered`
- 将 issue 号添加到 `issues_created`
- 将丢弃的发现添加到 `findings_dropped`（带原因）
- 更新 `last_analyzed` 时间戳
- 增加 `total_cycles`
- 添加到 `recent_activity` 日志（保留最后 20 个）

### 步骤 7：报告

输出包含进度矩阵的简洁摘要：

Analysis Cycle N Complete

Module: internal/<module> (分析通过 M) Aspects: , Findings: X Critical, Y High, Z Medium, W Low Issue: <issue URL 或"跳过 — 无可操作发现">

Coverage Matrix

Module	Ph1	Ph2	Ph3	Ph4	Issues	Status
gateway	3/3	2/3	—	—	2	进行中
session	3/3	3/3	2/2	—	3	Ph3 完成
messaging	1/3	—	—	—	1	Ph1 已开始
...

Stats

• 总周期：N
• 总 issues：M
• 完全覆盖的模块：A/总计
• 下一个目标：internal/<next-module> (analysis_count=N, Phase P 待处理)

覆盖矩阵给出了每个模块在 4 个阶段中位置的快速可视化。使用 `n/3`（或 Ph3/4 的 `n/2`）格式进行中的阶段，`—` 表示未开始，✓ 表示完成。

---

## 模块发现

**主要来源**：`CLAUDE.md` STRUCTURE 部分 — 如果存在，使用记录的模块边界。

**后备**：扫描 `internal/`、`pkg/`、`cmd/` 目录。每个带有 `.go` 文件的子目录 = 一个模块。

### 模块分组

分组紧密耦合的子包：
- `messaging/slack/` + `messaging/feishu/` → 作为子模块在 `messaging` 下分析
- `worker/claudecode/` + `worker/opencodeserver/` + `worker/pi/` → 在 `worker` 下的子模块
- `cli/checkers/` + `cli/onboard/` → 在 `cli` 下的子模块

父模块（`messaging`、`worker`、`cli`）获得自己的分析通过，涵盖共享代码（bridge、接口、基本类型）。

### 标准模块列表（HotPlex）

internal/gateway — WebSocket hub, conn, handler, bridge, API internal/session — 状态机, store, pool, key derivation internal/messaging — 平台适配器, bridge, interaction, STT internal/messaging/slack — Slack Socket Mode 适配器 internal/messaging/feishu — Feishu WS 适配器 internal/worker — 基础 worker, proc manager internal/worker/opencodeserver — OCS 单例 + worker internal/config — Viper 配置, 热重载 internal/agentconfig — Agent 个性/上下文加载器 internal/security — JWT, SSRF, 路径安全, 命令白名单 internal/admin — Admin API 处理器 internal/aep — AEP v1 编解码器 internal/cli — Checker 注册表, onboard 向导 internal/skills — Skills 发现 internal/metrics — Prometheus 计数器 internal/tracing — OpenTelemetry 设置 pkg/events — AEP 包络 + 事件类型 cmd/hotplex — Cobra CLI 入口点

---

## 分析方面

12 个方面跨 4 个阶段。每个阶段更深入 — 阶段 1 是结构性的，阶段 4 是细粒度的。

### 阶段 1：架构与设计
| # | 方面 | 重点 |
|---|--------|-------|
| 1 | **SOLID** | SRP 违规、接口隔离、依赖倒置、开/闭 |
| 2 | **DRY** | 模块内的重复逻辑、值得提取的跨模块模式 |
| 3 | **耦合** | 导入图、循环依赖、稳定依赖原则 |

### 阶段 2：可靠性
| # | 方面 | 重点 |
|---|--------|-------|
| 4 | **错误处理** | 静默失败、错误吞咽、哨兵错误、包装一致性 |
| 5 | **并发** | 竞争条件、互斥锁排序、goroutine 生命周期、通道泄漏 |
| 6 | **资源管理** | 连接/文件/goroutine 泄漏、defer 清理、关闭路径 |

### 阶段 3：性能与规模
| # | 方面 | 重点 |
|---|--------|-------|
| 7 | **性能** | 热路径、不必要的分配、N+1 模式、缓冲区重用 |
| 8 | **可扩展性** | 在 10x/100x 负载下的单点故障、瓶颈 |

### 阶段 4：安全与质量
| # | 方面 | 重点 |
|---|--------|-------|
| 9 | **安全** | 输入验证缺口、注入风险、认证/授权绕过 |
| 10 | **可观测性** | 结构化日志缺口、指标覆盖、跟踪跨度 |
| 11 | **可测试性** | DI 覆盖、可模拟性、错误路径的测试缺口 |
| 12 | **代码质量** | 圈复杂度、上帝对象、死代码、命名一致性 |

### 为什么这个顺序？

**阶段 1（架构与设计）优先**：因为结构性问题影响所有后续代码。在修复 SOLID/DRY 违规后再优化性能，避免在错误设计上浪费时间。

**阶段 2（可靠性）其次**：并发和错误处理问题是常见的生产故障根源。修复它们可以提高系统稳定性。

**阶段 3（性能与规模）第三**：只有在架构稳定和可靠性问题解决后才优化。过早优化是万恶之源。

**阶段 4（安全与质量）最后**：这些是"卫生因素" — 重要但通常不阻塞功能。在最后阶段确保代码库健康。

**为什么每次 2-3 个方面**：更多方面会导致表面分析。更少方面虽然深度更好，但需要更多调用才能覆盖。2-3 个方面是深度和速度的最佳平衡。

---

## 进度文件模式

```json
{
  "version": 1,
  "last_updated": "2026-04-29T21:36:00+08:00",
  "total_cycles": 0,
  "modules": {
    "internal/gateway": {
      "analysis_count": 0,
      "aspects_covered": [],
      "aspects_pending": [
        "solid", "dry", "coupling",
        "error-handling", "concurrency", "resource-mgmt",
        "performance", "scalability",
        "security", "observability", "testability", "code-quality"
      ],
      "issues_created": [],
      "findings_total": 0,
      "findings_dropped": [],
      "last_analyzed": null
    }
  },
  "issues": [],
  "recent_activity": []
}

findings_dropped 数组跟踪分诊期间丢弃的低置信度或低 ROI 发现 — 便于重新分析通过中重新访问。每个条目：{"finding": "name", "reason": "Low confidence — may be intentional"}。

---

AC 撰写指南

好的 AC 是具体的、可验证的和可测试的。

为什么 AC 很重要：没有清晰 AC 的 issue 往往导致不完整的实现或需要多次返工。好的 AC 让实施者知道"完成"是什么样子，让审查者可以验证实现。

每个发现的 AC 应该：

1. 陈述更改：必须修改什么代码/文件
2. 定义成功：如何验证修复有效（测试用例、行为）
3. 指定约束：绝不能更改什么（向后兼容、性能预算）

模式：对于每个发现，写 2-4 个 AC 项目，涵盖更改、其验证和边界条件。

示例：

坏："修复错误处理" 好：

- [ ] `bridge.go:HandleMessage` 返回错误而不是记录并返回 nil
- [ ] 错误通过 SessionConn.Send 使用 AEP 错误事件传播到调用者
- [ ] 添加测试：`TestHandleMessage_ErrorPropagation` 验证错误到达客户端

坏："改进性能" 好：

- [ ] 在 `WritePump` 中用 sync.Pool 替换每个消息的 `bytes.Buffer` 分配
- [ ] 基准 `BenchmarkWritePump_Throughput` 显示 <10ns/op 改进
- [ ] 在 `go test -count=5 -bench=.` pprof 下无分配增加

坏："重构适配器以共享代码" 好（受 issue 65 风格启发）：

- [ ] 在 `messaging/platform_adapter.go` 中将共享适配器字段提取到 `PlatformAdapter` 基础结构
- [ ] Slack 和 Feishu 适配器嵌入 `*PlatformAdapter` 而不是重复字段
- [ ] `make test` 通过，两个适配器测试套件零回归
- [ ] 添加新平台适配器需要实现 3 个接口 + 1 个 StreamingAPI，而不是 15+ 文件

---

常见陷阱和故障排除

陷阱 1：过度分析

症状：每个模块产生 20+ 发现，issue 长达数千行，审查者不知所措

原因：没有应用置信度 + ROI 分诊，或设置了过低的分诊阈值

解决：

• 提高分诊阈值 — 只保留高置信度 + 高/中 ROI 的发现
• 专注于每个方面最重要的 2-3 个问题，而不是所有问题
• 记住：目标是可操作的改进，不是完整的代码审计报告

陷阱 2：误报

症状：创建的 issue 后来被标记为"有意设计"或"不会修复"

原因：低置信度发现被包含，或缺乏对模块设计意图的上下文

解决：

• 严格执行置信度评估 — 低置信度发现应该被丢弃，而不是创建 issue
• 在 issue 中注明"可能是设计选择" — 让审查者决定
• 查看模块的测试文件以理解预期行为

陷阱 3：低 ROI 发现

症状：issue 创建后数月无人处理，或被标记为"good first issue"但优先级低

原因：发现了真实问题，但修复投入太大或影响太小

解决：

• 在创建 issue 前问："这值得花费工程时间吗？"
• 大投入 + 小影响 = 丢弃，除非是安全/数据丢失问题
• 专注于"快速获胜" — 小改动产生大影响的发现

陷阱 4：缺少代码示例

症状：issue 中只有描述性文字，审查者要求"请展示代码示例"

原因：跳过了代码片段指南，或示例太冗长/太模糊

解决：

• 每个发现必须包含 before/after 代码片段（5-15 行）
• 显示具体问题模式，不只是"重构使用接口"
• 对于设计问题，显示提议的接口签名

陷阱 5：进度文件损坏

症状：.claude/arch-analysis/progress.json 格式错误，skill 无法加载

原因：手动编辑或并发写入冲突

解决：

• 不要手动编辑进度文件 — skill 会管理它
• 如果损坏，删除文件让 skill 重新初始化
• 使用 jq 验证 JSON：jq . .claude/arch-analysis/progress.json

陷阱 6：模块边界不清

症状：分析覆盖了不该包含的代码，或遗漏了相关文件

原因：模块发现逻辑与实际代码结构不匹配

解决：

• 优先使用 CLAUDE.md 中的 STRUCTURE 部分
• 对于大型模块（>1500 行），拆分为子模块
• 在进度文件中手动调整模块列表

陷阱 7：/loop 执行中断

症状：/loop 在中途停止，或重复分析同一模块

原因：未处理的错误或进度文件更新失败

解决：

• 检查最近的 recent_activity 日志以查找失败模式
• 确保每次调用都更新 last_analyzed 时间戳
• 如果卡住，手动增加模块的 analysis_count 以跳过它

陷阱 8：Issue 格式错误

症状：GitHub 错误渲染 issue，或数字变成链接

原因：使用了 # 数字或违反了其他格式规则

解决：

• 严格遵循 issue 模板
• 使用"cycle N"而不是"cycle #N"
• 验证：创建测试 issue 检查渲染

---

边缘情况处理

无发现

场景：分析完成后没有产生可操作的结果

推荐处理：更新进度（将方面标记为已覆盖）并跳过 issue 创建。在进度中注明"无重要发现"。

为什么这是好事：说明模块在这方面很健康。不需要强制创建 issue。

跨模块发现

场景：分析揭示跨越多个模块的问题

推荐处理：在 issue 中注明所有受影响的模块，但标记主模块。添加 cross-cutting 注释以便后续跟踪。

为什么标记主模块：保持进度文件简单，同时确保问题不会在裂缝中遗漏。

模块太大（>1500 行）

场景：单个模块过大，难以在一次分析中覆盖

推荐处理：将拆分为子模块进行分析（例如，gateway → gateway/core + gateway/bridge + gateway/api）。独立跟踪子模块。

为什么拆分：大型模块的分析质量下降。拆分后可以更深入地关注每个部分。

重新分析

场景：模块的所有方面都已覆盖，需要重新分析

推荐处理：重新分析会更深入 — 查找首次通过中遗漏的问题，检查以前的发现是否已解决，识别新模式。

为什么重新分析有价值：代码库在演化，以前的发现可能已解决，新问题可能出现。重新分析是健康检查。

---

成功指标

如何判断架构分析是否有效？

好的信号

• Issue 创建率：60-80% 的分析周期创建 issue（不过多，也不过少）
• Issue 解决率：创建的 issue 在 2-4 周内解决或纳入路线图
• 发现质量：审查者反馈"有用的发现"、"可操作的问题"
• 重复分析价值：第二次分析发现新问题或确认旧问题已解决
• 覆盖进展：覆盖矩阵显示持续进展，没有模块被遗漏

需要调整的信号

• 太多低质量 issue：收紧置信度 + ROI 分诊阈值
• 太少 issue：放宽分诊阈值，或检查是否过于保守
• 重复的误报：提高置信度要求，添加更多上下文检查
• 模块分析卡住：检查进度文件，可能需要手动调整模块边界
• Issue 长期未解决：重新评估 ROI 评估，可能创建的优先级错误

持续改进

定期回顾（建议每 2-4 周）：

• 检查创建的 issue 的状态
• 收集审查者和实施者的反馈
• 调整分诊阈值和方面选择逻辑
• 更新模块边界和分组

为什么需要持续改进：架构分析不是一劳永逸的过程。代码库演化，团队标准变化，分析技能应该随之调整。