Back to Details

code-review

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

/code-review — MCP-Powered Code Review

/code-review — 基于MCP的代码评审

What

概述

Performs a multi-dimensional code review combining Roslyn MCP analysis with structured manual review. Effort follows the 80/20 rule: the 20% of code that causes 80% of incidents (data access, security, concurrency, integration boundaries) gets thorough review; style and formatting are left to tooling.
Review dimensions: Correctness (logic, edge cases, null handling, async pitfalls), Security (auth gaps, injection, secrets, CORS), Performance (N+1, allocations, missing cancellation), Architecture compliance (layer violations, boundary breaches), Test coverage (behavior tests for changed types).
结合Roslyn MCP分析与结构化人工评审，执行多维代码评审。评审工作遵循80/20法则：导致80%问题的20%代码（数据访问、安全、并发、集成边界）会得到全面评审；代码风格与格式则交由工具处理。
评审维度：正确性（逻辑、边界情况、空值处理、异步陷阱）、安全性（认证漏洞、注入攻击、密钥泄露、CORS问题）、性能（N+1查询、内存分配、缺失取消机制）、架构合规性（层级违规、边界突破）、测试覆盖率（变更类型的行为测试）。

When

适用场景

  • "Review this", "code review", "PR review", before merging a pull request
  • After a major refactor to verify no regressions or design drift
  • "What should I review?" — deciding where review effort goes on a large change
  • Onboarding to unfamiliar code and wanting a quality assessment
  • "Review this"、"code review"、"PR review"，即合并拉取请求之前
  • 重大重构后，验证是否存在回归或设计偏差
  • "What should I review?"——确定大型变更的评审重点
  • 接手陌生代码时，进行质量评估

How

评审流程

Step 1: Scope and Score Blast Radius

步骤1：确定范围并评分影响范围

Identify changed files (
git diff main...HEAD
, specified files, or module). Score each change to set review depth — blast radius determines depth, not line count. A one-line middleware change outranks a 300-line rename.
Blast RadiusExamplesDepth
CriticalMiddleware, auth, DB migrations, shared kernel, CI/CDThorough — every code path
HighPublic API changes, message consumers, EF configuration, new moduleFocused — consumers + behavior
MediumNew feature following existing patterns, bug fix, new endpointStandard — checklist pass
LowDocs, formatting, renames, logging statementsGlance — build + tests pass
识别变更文件（
git diff main...HEAD
、指定文件或模块）。为每个变更评分以确定评审深度——影响范围而非代码行数决定评审深度。一行中间件变更的优先级高于300行的重命名操作。
影响范围示例评审深度
关键中间件、认证、数据库迁移、共享核心模块、CI/CD全面——检查每个代码路径
高公共API变更、消息消费者、EF配置、新模块聚焦——检查消费者与行为逻辑
中遵循现有模式的新功能、Bug修复、新端点标准——按检查清单评审
低文档、格式调整、重命名、日志语句快速浏览——确保构建与测试通过

Step 2: MCP Analysis (before reading any file)

步骤2：MCP分析（在查看任何文件之前）

detect_antipatterns(projectFilter: "affected-project")   → async void, DateTime.Now, new HttpClient(), broad catch
get_diagnostics(scope: "project", path: "affected-project") → new warnings, nullability issues
Distinguish newly introduced findings from pre-existing ones — focus on new.
detect_antipatterns(projectFilter: "affected-project")   → async void, DateTime.Now, new HttpClient(), broad catch
get_diagnostics(scope: "project", path: "affected-project") → new warnings, nullability issues
区分新引入的问题与原有问题——重点关注新问题。

Step 3: Blast Radius Verification

步骤3：影响范围验证

For each modified public API:
find_references(symbolName: "ModifiedType")              → count consumers; high count = high risk
get_dependency_graph(symbolName: "ModifiedMethod", depth: 2) → ripple effects
Check whether callers handle changed return types and new error cases.
针对每个修改的公共API：
find_references(symbolName: "ModifiedType")              → count consumers; high count = high risk
get_dependency_graph(symbolName: "ModifiedMethod", depth: 2) → ripple effects
检查调用方是否处理了变更的返回类型和新的错误场景。

Step 4: Architecture Compliance

步骤4：架构合规性验证

Verify dependency direction (Domain → nothing; Infrastructure → Application → Domain) via 
get_project_graph
and 
detect_circular_dependencies
. Per architecture: VSA features don't cross-reference; Clean Architecture domain has zero project references; Modular Monolith modules communicate only via integration events — 
find_references
on a module's DbContext should resolve only inside that module.
通过
get_project_graph
和
detect_circular_dependencies
验证依赖方向（领域层 → 无依赖；基础设施层 → 应用层 → 领域层）。符合以下架构要求：VSA功能不交叉引用；整洁架构的领域层无项目引用；模块化单体应用的模块仅通过集成事件通信——模块DbContext的
find_references
应仅在该模块内部解析。

Step 5: Manual Review — Priority Order

步骤5：人工评审——优先级顺序

Review what tools can't catch, highest-risk areas first:
PriorityAreaCheck
1Data accessN+1 (missing 
Include
/projection), raw SQL with user input, missing 
CancellationToken
2SecurityEvery endpoint has explicit 
[Authorize]
/
[AllowAnonymous]
, input validated, no secrets in code, no PII in logs
3ConcurrencyToken propagated end-to-end, no 
.Result
/
.Wait()
, thread-safe shared state
4IntegrationRetry/timeout on external calls, consumer idempotency, no swallowed exceptions
5CorrectnessBusiness logic, edge cases (empty/null/concurrent), entities mapped to DTOs at the boundary
6TestsBehavior tested (not implementation); happy path + main error case covered
—Style/namingMention only after the above; formatters and analyzers own this
评审工具无法检测的内容，优先处理高风险区域：
优先级领域检查内容
1数据访问N+1查询（缺失
Include
/投影）、包含用户输入的原生SQL、缺失
CancellationToken
2安全性每个端点都有明确的
[Authorize]
/
[AllowAnonymous]
、输入已验证、代码中无密钥、日志中无PII（个人可识别信息）
3并发令牌端到端传递、无
.Result
/
.Wait()
、共享状态线程安全
4集成外部调用的重试/超时机制、消费者幂等性、无吞异常情况
5正确性业务逻辑、边界情况（空值/空集合/并发）、实体在边界处映射为DTO
6测试行为测试（而非实现测试）；覆盖正常路径与主要错误场景
—风格/命名仅在上述检查完成后提及；格式与命名由格式化工具和分析器处理

Step 6: Produce the Review

步骤6：生成评审报告

Every finding states what's wrong, why it matters, and how to fix it. Never bury a security bug under naming nits.
markdown
undefined
每个问题都需说明问题所在、影响原因及修复方案。绝不能将安全Bug隐藏在命名问题之下。
markdown
undefined

Code Review: [Scope]

代码评审：[范围]

Summary

摘要

[1-3 sentences: scope, risk level, recommendation]
[1-3句话：范围、风险等级、建议]

Critical (must fix before merge)

关键问题（合并前必须修复）

  • [Title] — [file:line] [What's wrong. Why it matters. How to fix.]
  • [标题] — [文件:行号] [问题描述。影响原因。修复方案。]

Warnings (should fix, creates tech debt)

警告（应修复，会产生技术债务）

  • [Title] — [file:line] [...]
  • [标题] — [文件:行号] [...]

Suggestions (nice to have)

建议（可选优化）

  • [Title] — [file:line] [...]
  • [标题] — [文件:行号] [...]

Architecture Compliance

架构合规性

[PASS/WARN with boundary-violation notes]
[通过/警告，附带边界违规说明]

Test Coverage

测试覆盖率

[Which changed types have tests; specific scenarios to add]
[哪些变更类型已有测试；需添加的特定场景]

What's Good

亮点

  • [Always include — reinforce good patterns]

**Quick review** (1-2 files, low blast radius): run `detect_antipatterns` +
`get_diagnostics`, read for correctness, output Summary + Issues + What's Good.
  • [务必包含——强化良好实践]

**快速评审**（1-2个文件，低影响范围）：运行`detect_antipatterns` + `get_diagnostics`，检查正确性，输出摘要 + 问题 + 亮点。

Example

示例

User: /code-review the changes in this PR

Claude: 7 changed files across 3 projects. CreateOrder touches data access
and a public endpoint — High blast radius. Running MCP analysis...
用户：/code-review 本次PR中的变更

Claude：涉及3个项目的7个变更文件。CreateOrder涉及数据访问和公共端点——高影响范围。正在运行MCP分析...

Code Review: Order Processing Feature

代码评审：订单处理功能

Summary

摘要

Adds CreateOrder/GetOrder endpoints with EF Core persistence. Well-structured VSA feature. Two issues need attention before merge.
新增了基于EF Core持久化的CreateOrder/GetOrder端点。是结构清晰的VSA功能。合并前需关注两个问题。

Critical (must fix before merge)

关键问题（合并前必须修复）

  • Missing CancellationToken propagation — CreateOrder.cs:38 SaveChangesAsync() called without the token. Client disconnects keep burning server resources. Pass 
    ct
    from the handler parameter.
  • 缺失CancellationToken传递 — CreateOrder.cs:38 调用SaveChangesAsync()时未传入令牌。客户端断开连接会持续消耗服务器资源。从处理器参数中传入
    ct
    。

Warnings (should fix, creates tech debt)

警告（应修复，会产生技术债务）

  • N+1 query in GetOrder — GetOrder.cs:25 Order loaded without 
    .Include(o => o.Items)
    ; one lazy load per item during serialization. Eager-load or use a projection.
  • GetOrder中存在N+1查询 — GetOrder.cs:25 加载Order时未使用
    .Include(o => o.Items)
    ；序列化时每个Item会触发一次懒加载。使用预加载或投影。

Suggestions (nice to have)

建议（可选优化）

  • Seal the handler — CreateOrderHandler.cs:10 Not designed for inheritance; 
    sealed
    enables devirtualization.
  • 密封处理器类 — CreateOrderHandler.cs:10 该类并非为继承设计；
    sealed
    可启用去虚拟化优化。

Architecture Compliance

架构合规性

PASS — all changes within Features/Orders/, no layer violations.
通过——所有变更均在Features/Orders/内，无层级违规。

Test Coverage

测试覆盖率

Happy path covered. Add tests for validation failure and not-found.
已覆盖正常路径。需添加验证失败和未找到资源的测试场景。

What's Good

亮点

  • Clean command/query separation; FluentValidation covers edge cases
  • Response DTOs are records, no entity leaks
undefined
  • 清晰的命令/查询分离；FluentValidation覆盖了边界情况
  • 响应DTO为记录类型，无实体泄露
undefined

Related

相关功能

  • /de-sloppify
    — Cleanup pass for the style/formatting issues review skips
  • /verify
    — Automated verification pipeline (complements manual review)
  • /health-check
    — Broader project health assessment beyond a single PR
  • /de-sloppify
    — 清理评审忽略的风格/格式问题
  • /verify
    — 自动化验证流水线（补充人工评审）
  • /health-check
    — 针对单个PR之外的更广泛项目健康评估