القائمة
Code architecture review. 当用户需要评审代码架构、讨论设计模式、检查代码质量或进行代码评审时使用此skill。
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف 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、渐进设计 |
| 缓存滥用 | 数据不一致 | 明确缓存策略、同步机制 |