Menu
Code architecture review. 当用户需要评审代码架构、讨论设计模式、检查代码质量或进行代码评审时使用此skill。
Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.
Baseado na classificação ocupacional SOC
季度竞品分析技能。每季度系统化收集市场竞品情报、构建竞争全景图、深度画像竞品、分析市场格局演变、提炼战略洞察，输出完整季度竞品分析报告。适用于产品战略规划、年度路线图制定、投融资汇报、高管决策支持等场景。当用户需要每季度深入了解竞争格局、识别战略机会、形成完整竞品分析报告时使用此 skill。
Git 标准操作流程 SOP，包含 init、add、commit、push、status、log、pull 等常用操作及自动检查验证。使用场景：用户要求执行 git 操作时。
API design specifications. 当用户需要设计 API、讨论 RESTful 规范、设计 GraphQL schema 或制定 API 规范时使用此skill。
Architecture quality assessment. 当用户需要评估架构质量、检查系统性能、分析安全风险或评估可扩展性时使用此skill。
System architecture design. 当用户需要设计系统架构、画架构图、讨论微服务拆分、CQRS、事件驱动、DDD等架构模式时使用此skill。
Technical decision making. 当用户需要做技术选型、讨论方案优劣、评估技术风险或做架构决策时使用此skill。
| name | code-review |
| description | Code architecture review. 当用户需要评审代码架构、讨论设计模式、检查代码质量或进行代码评审时使用此skill。 |
代码架构评审技能，从架构角度审查代码质量和设计。
正面模式（应采用）
| 模式 | 适用场景 | 检查点 |
|---|---|---|
| Factory Method | 对象创建逻辑复杂 | 是否隐藏创建细节 |
| Strategy | 多种算法/策略 | 是否支持运行时切换 |
| Observer | 事件通知 | 是否解耦观察者和被观察者 |
| Decorator | 动态扩展功能 | 是否避免继承层次过深 |
| Repository | 数据访问抽象 | 是否隔离持久化逻辑 |
| Command | 请求封装 | 是否支持撤销/重做 |
反面模式（应避免）
| 模式 | 问题 | 解决方案 |
|---|---|---|
| God Object | 职责过多 | 拆分为单一职责类 |
| Circular Dependency | 循环依赖 | 引入接口解耦 |
| Shotgun Surgery | 修改扩散 | 合并相关职责 |
| Speculative Generality | 过度设计 | YAGNI 原则 |
| Primitive Obsession | 基础类型堆砌 | 引入 Value Object |
□ S - Single Responsibility (单一职责)
- 类是否只有一个变化原因？
- 方法是否保持简短？
□ O - Open/Closed (开闭原则)
- 对扩展开放，对修改封闭？
- 使用继承还是组合？
□ L - Liskov Substitution (里氏替换)
- 子类能否替换父类？
- 是否违反继承契约？
□ I - Interface Segregation (接口隔离)
- 接口是否臃肿？
- 客户端是否被迫依赖未使用的方法？
□ D - Dependency Inversion (依赖反转)
- 依赖抽象而非具体？
- 是否使用依赖注入？
| 指标 | 可接受 | 警告 | 不可接受 |
|---|---|---|---|
| 方法行数 | < 20 | 20-40 | > 40 |
| 类行数 | < 200 | 200-500 | > 500 |
| 圈复杂度 | < 10 | 10-20 | > 20 |
| 嵌套深度 | < 3 | 3-5 | > 5 |
| 参数个数 | < 3 | 3-5 | > 5 |
□ 是否遵循确定的分层架构？
□ 依赖方向是否正确（外层依赖内层）？
□ 是否有跨层直接调用？
□ 核心业务逻辑是否在正确的层？
□ 是否有统一的异常处理机制？
□ 异常是否被适当捕获和记录？
□ 是否避免了吞掉异常（空 catch）？
□ 自定义异常是否有意义？
□ 是否使用 Repository 模式？
□ 是否存在 N+1 查询问题？
□ 事务边界是否清晰？
□ 是否考虑缓存策略？
# 代码架构评审报告
## 1. 评审概要
- **评审范围**：[文件/模块列表]
- **评审时间**：[日期]
- **整体评级**：[A/B/C/D]
## 2. 主要发现
### 严重问题 (必须修复)
| 问题 | 位置 | 描述 | 建议 |
|------|------|------|------|
| | | | |
### 中等问题 (建议修复)
| 问题 | 位置 | 描述 | 建议 |
|------|------|------|------|
| | | | |
### 轻微问题 (可选修复)
| 问题 | 位置 | 描述 | 建议 |
|------|------|------|------|
| | | | |
## 3. 架构亮点
[做得好的设计决策]
## 4. 改进建议优先级
1. [最优先]
2. [次优先]
3. [后续]
## 5. 总结
[总体评价]
评审前
□ 理解需求和业务背景
□ 了解技术栈和约束
□ 确定评审重点
评审中
□ 从整体到局部，从粗到细
□ 记录所有发现（不只是问题，也包括亮点）
□ 标注问题优先级
评审后
□ 整理评审报告
□ 与开发者对齐问题
□ 确认后续行动计划
| 问题 | 症状 | 解决方案 |
|---|---|---|
| 循环依赖 | 编译/测试顺序敏感 | 引入接口、依赖倒置 |
| 分散耦合 | 修改一个模块影响多个 | 提取抽象、降低耦合 |
| 逻辑泄漏 | 业务规则散布多处 | 提取到 Domain 层 |
| 过度预判 | 从不使用的基础设施 | YAGNI、渐进设计 |
| 缓存滥用 | 数据不一致 | 明确缓存策略、同步机制 |