- name
- quant-architecture-review
- description
- 量化架构设计审查技能。当用户说"审查架构"、"检查设计"、"优化架构"、"架构有问题"、"XX环节有问题"时自动触发。提供架构设计检查清单、常见问题识别、优化建议。适用于量化项目的设计审查阶段。
量化架构设计审查技能
版本：1.0.0 适用项目：量化策略项目（A股、美股）
🎯 审查目标
确保架构设计合理、可扩展、可维护
📋 架构审查检查清单
1. 数据流程架构
1.1 数据源设计
检查项：
- [ ] 数据源是否可靠？（免费 vs 付费）
- [ ] 数据源是否有多重备份？（主数据源 + 备用数据源）
- [ ] 数据更新频率是否满足需求？（日线、分钟线、实时）
- [ ] 数据质量是否有保障？（完整性、准确性、时效性）
常见问题：
- ❌ 只依赖单一数据源，无备份
- ❌ 数据更新不及时，影响策略决策
- ❌ 数据质量差，包含大量缺失值/异常值
优化建议：
- ✅ 使用多个数据源交叉验证
- ✅ 建立数据质量检查机制
- ✅ 设置数据更新告警
1.2 数据流转路径
检查项：
- [ ] 数据流转路径是否清晰？（原始数据 → 因子 → 信号 → 持仓）
- [ ] 每个环节的数据格式是否标准？
- [ ] 数据存储是否合理？（数据库 vs 文件）
- [ ] 数据版本是否有管理？
常见问题：
- ❌ 数据流转路径不清晰，难以追溯
- ❌ 数据格式不统一，增加维护成本
- ❌ 没有数据版本管理，无法回滚
优化建议：
- ✅ 绘制数据流转图，明确每个环节
- ✅ 使用标准数据格式（Parquet、JSON）
- ✅ 使用Git管理数据版本
2. 模块划分架构
2.1 模块职责
检查项：
- [ ] 模块职责是否清晰？（单一职责原则）
- [ ] 模块之间是否低耦合？
- [ ] 模块接口是否清晰？
- [ ] 模块是否可测试？
常见问题：
- ❌ 模块职责不清晰，一个模块做多个事情
- ❌ 模块之间高度耦合，修改一处影响多处
- ❌ 模块接口不清晰，难以理解和使用
优化建议：
- ✅ 每个模块只做一件事
- ✅ 使用接口隔离模块依赖
- ✅ 为每个模块编写测试用例
2.2 模块分层
检查项：
- [ ] 是否有清晰的分层？（数据层、业务层、展示层）
- [ ] 层级之间是否单向依赖？
- [ ] 层级边界是否清晰？
常见问题：
- ❌ 没有分层，所有代码混在一起
- ❌ 层级之间双向依赖，形成循环
- ❌ 层级边界不清晰，职责混乱
优化建议：
- ✅ 明确分层：数据层（数据获取）→ 业务层（策略逻辑）→ 展示层（报告生成）
- ✅ 单向依赖：上层依赖下层，下层不依赖上层
- ✅ 使用依赖注入降低耦合
3. 接口设计架构
3.1 API设计
检查项：
- [ ] API接口是否RESTful？
- [ ] API是否版本化？
- [ ] API是否有错误处理？
- [ ] API是否有文档？
常见问题：
- ❌ API设计不规范，难以使用
- ❌ 没有API版本管理，升级困难
- ❌ 没有错误处理，调用失败难以排查
优化建议：
- ✅ 遵循RESTful API设计规范
- ✅ API版本化（/v1/、/v2/）
- ✅ 统一错误处理和日志记录
- ✅ 使用Swagger/OpenAPI生成文档
3.2 数据接口
检查项：
- [ ] 数据接口是否标准？（输入、输出格式）
- [ ] 数据接口是否可扩展？
- [ ] 数据接口是否有验证？
常见问题：
- ❌ 数据接口格式不统一
- ❌ 数据接口不可扩展，新增字段需要大改
- ❌ 没有数据验证，错误数据进入系统
优化建议：
- ✅ 使用标准数据格式（JSON、Parquet）
- ✅ 设计可扩展的数据结构
- ✅ 添加数据验证层
4. 性能架构
4.1 数据处理性能
检查项：
- [ ] 数据处理是否高效？（时间复杂度、空间复杂度）
- [ ] 是否有数据缓存机制？
- [ ] 是否有并发处理能力？
常见问题：
- ❌ 数据处理效率低，耗时过长
- ❌ 没有缓存，重复计算浪费资源
- ❌ 单线程处理，无法利用多核
优化建议：
- ✅ 使用高效的数据结构（Pandas、NumPy）
- ✅ 添加缓存机制（Redis、内存缓存）
- ✅ 使用多进程/多线程加速
4.2 回测性能
检查项：
- [ ] 回测速度是否可接受？（回测10年数据不超过5分钟）
- [ ] 是否有向量化优化？
- [ ] 是否有内存优化？
常见问题：
- ❌ 回测速度慢，调试周期长
- ❌ 使用循环而非向量化，效率低
- ❌ 内存占用大，容易OOM
优化建议：
- ✅ 使用向量化计算（Pandas、NumPy）
- ✅ 分批处理数据，减少内存占用
- ✅ 使用性能分析工具定位瓶颈
5. 扩展性架构
5.1 策略扩展性
检查项：
- [ ] 是否易于添加新策略？
- [ ] 策略参数是否可配置？
- [ ] 策略是否可组合？
常见问题：
- ❌ 添加新策略需要大量代码修改
- ❌ 策略参数硬编码，难以调整
- ❌ 策略不可组合，无法混合使用
优化建议：
- ✅ 使用策略模式，易于扩展
- ✅ 使用配置文件管理策略参数
- ✅ 设计策略组合框架
5.2 数据源扩展性
检查项：
- [ ] 是否易于添加新数据源？
- [ ] 数据源接口是否统一？
- [ ] 数据源切换是否无缝？
常见问题：
- ❌ 添加新数据源需要大量代码修改
- ❌ 数据源接口不统一，难以切换
- ❌ 数据源切换需要重启系统
优化建议：
- ✅ 使用适配器模式，统一数据源接口
- ✅ 配置化管理数据源
- ✅ 支持热切换数据源
6. 可维护性架构
6.1 代码规范
检查项：
- [ ] 是否有统一的代码风格？
- [ ] 是否有代码注释？
- [ ] 是否有文档？
常见问题：
- ❌ 代码风格不统一，难以阅读
- ❌ 没有注释，难以理解
- ❌ 没有文档，难以维护
优化建议：
- ✅ 使用代码格式化工具（Black、Prettier）
- ✅ 添加函数注释、模块注释
- ✅ 编写项目文档（README、API文档）
6.2 测试覆盖
检查项：
- [ ] 是否有单元测试？
- [ ] 测试覆盖率是否充分？（>80%）
- [ ] 是否有回归测试？
常见问题：
- ❌ 没有测试，修改代码容易引入BUG
- ❌ 测试覆盖率低，无法保证质量
- ❌ 没有回归测试，新功能破坏旧功能
优化建议：
- ✅ 为核心模块编写单元测试
- ✅ 使用测试覆盖率工具（pytest-cov）
- ✅ 建立回归测试套件
6.3 日志和监控
检查项：
- [ ] 是否有日志记录？
- [ ] 日志级别是否合理？（DEBUG、INFO、WARNING、ERROR）
- [ ] 是否有监控告警？
常见问题：
- ❌ 没有日志，问题难以排查
- ❌ 日志级别不合理，信息过多或过少
- ❌ 没有监控告警，问题发现不及时
优化建议：
- ✅ 使用标准日志库（logging）
- ✅ 设置合理的日志级别
- ✅ 建立监控告警机制（邮件、钉钉）
🎯 审查流程
步骤1：绘制架构图
要求：
- 数据流程图
- 模块关系图
- 接口调用图
步骤2：逐项检查
使用检查清单：
- 数据流程架构
- 模块划分架构
- 接口设计架构
- 性能架构
- 扩展性架构
- 可维护性架构
步骤3：识别问题
记录：
- 问题描述
- 影响范围
- 优先级
步骤4：提出优化建议
要求：
- 具体可操作
- 有优先级排序
- 有实施方案
📋 审查报告模板
# 架构审查报告
**项目名称**：XXX
**审查日期**：YYYY-MM-DD
**审查人**：XXX
---
## 一、架构概览
### 1. 数据流程
[数据流程图]
### 2. 模块划分
[模块关系图]
### 3. 接口设计
[接口调用图]
---
## 二、问题清单
| 编号 | 问题描述 | 影响范围 | 优先级 | 建议方案 |
|------|---------|---------|--------|---------|
| P1 | ... | ... | 高 | ... |
| P2 | ... | ... | 中 | ... |
---
## 三、优化建议
### 短期优化（本周）
1. ...
2. ...
### 中期优化（本月）
1. ...
2. ...
### 长期优化（本季度）
1. ...
2. ...
---
## 四、风险评估
| 风险 | 影响 | 概率 | 应对措施 |
|------|------|------|---------|
| ... | ... | ... | ... |
---
*审查人签名：XXX*
*日期：YYYY-MM-DD*🎯 成功标准
| 指标 | 标准 |
|---|---|
| 数据流程 | 清晰、可追溯 |
| 模块划分 | 低耦合、高内聚 |
| 接口设计 | 标准化、可扩展 |
| 性能 | 满足需求 |
| 扩展性 | 易于添加新功能 |
| 可维护性 | 有测试、有文档、有监控 |
*技能版本：1.0.0*