name: 代码审查 description: 使用通用最佳实践和仓库特定标准执行系统化代码审查。在重大代码更改后自动激活。用于审查代码、审计文件、检查PR、检查暂存更改，或当被要求“审查”、“检查”、“审计”或“检查”代码时。强制执行设计原则（SOLID、DRY、KISS）、安全（OWASP）、性能、并发安全、跨平台兼容性和代码库模式。 allowed-tools: Read, Grep, Glob, AskUserQuestion
代码审查
基于Google工程、OWASP和现代开发标准的行业最佳实践的系统化代码审查技能。通过结构化、清单驱动的分析，旨在捕捉随意审查可能遗漏的问题。
核心原则（Google）： 批准改善整体代码健康的代码，即使不完美。追求持续改进，而非完美。但绝不批准降低代码健康的代码。
何时使用此技能
自动激活触发：
- 完成重大实现任务后
- 提交更改前
- 审查PR或暂存文件时
显式激活触发：
- 用户要求“审查”、“检查”、“审计”或“检查”代码
- 用户提及“代码审查”、“PR审查”、“查看此代码”
- 用户询问代码质量或标准合规性
交互式审查范围确定
当未指定时，使用AskUserQuestion确定审查深度和风险概况：
# 问题1：审查深度（MCP: Google Engineering代码审查，OWASP）
question: "需要什么类型的代码审查？"
header: "审查类型"
options:
- label: "快速审查（推荐）"
description: "表面问题、样式、明显错误（约15分钟，约3.5K令牌）"
- label: "彻底审查"
description: "多遍：逻辑、设计、测试（约45分钟，约14K令牌）"
- label: "安全审查"
description: "威胁焦点：认证、验证、加密（约30分钟）"
- label: "架构审查"
description: "设计模式、依赖关系、耦合（约60分钟）"
# 问题2：风险概况（MCP: CLI最佳实践 - 范围选择）
question: "此更改的风险概况是什么？"
header: "风险"
options:
- label: "低风险（推荐）"
description: "孤立修复、充分测试区域、无用户影响"
- label: "中风险"
description: "功能更改、中等范围、可逆"
- label: "高风险"
description: "关键路径、安全敏感、广泛影响"
- label: "未知"
description: "我不确定 - 分析并推荐"
使用这些响应选择适当的审查配置文件（快速、彻底、安全、严格、性能）。
审查工作流
代码审查进度：
- [ ] 步骤0：研究阶段（强制 - 运行MCP查询技术栈）
- [ ] 步骤0b：加载仓库配置（检查.claude/code-review.md，回退到CLAUDE.md）
- [ ] 步骤0e：Git历史分析（耦合、热点、作者上下文 - 仅彻底/严格）
- [ ] 步骤1：计算要审查的文件（准确文件计数）
- [ ] 步骤1b：检测生成内容（扫描标记，识别生成器）
- [ ] 步骤2：确定范围（要审查的文件，排除生成文件）
- [ ] 步骤3：加载上下文（仓库标准 + MCP研究结果 + 仓库配置）
- [ ] 步骤4：运行通用检查（第1层） - 基于MCP研究
- [ ] 步骤5：运行仓库特定检查（第2层，应用仓库配置规则）
- [ ] 步骤5b：运行Claude代码验证（第4b层，如果检测到CC文件）
- [ ] 步骤6：报告所有发现，包括严重性、规则来源和MCP验证状态
- [ ] 步骤7：提出具体修复建议，带理由和MCP支持的推荐
步骤0：研究阶段（强制）
关键：此步骤在任何代码分析之前运行。不可选。
在审查代码之前，查询MCP服务器以理解当前模式和最佳实践。这防止基于过时训练数据做出声明。
加载参考： references/tier-0/research-phase.md
快速参考：
- 检测技术栈（从文件扩展名、导入、清单）
- 查询MCP服务器（基于检测技术的并行查询）：
- Microsoft技术（.NET、Azure、C#）→
microsoft-learn+perplexity（始终双重验证） - npm/PyPI包 →
context7+ref - 安全模式 →
perplexity（OWASP） - 版本声明 →
perplexity（始终验证）
- Microsoft技术（.NET、Azure、C#）→
- 构建当前真相上下文（存储已验证模式供分析时使用）
核心规则：
- 分析前研究 - 在做出声明前了解当前最佳实践
- 始终需要perplexity - 训练数据过时；始终交叉验证
- Microsoft技术双重验证 -
microsoft-learn可能过时，始终与perplexity配对 - 每个发现都需要来源 - 没有权威验证就没有发现
高风险技术（需要额外perplexity验证）：
- .NET 10、.NET Aspire、Azure AI Foundry、HybridCache、Microsoft.Extensions.AI
步骤0b：加载仓库配置
加载仓库特定规则以定制审查。
加载参考： references/tier-4/repo-config.md
配置优先级链：
1. .claude/code-review.md（主要）
├── 找到：解析配置，应用规则，停止
└── 未找到：继续回退
1.5. .claude/rules/*.md（原生 - 由Claude Code运行时自动加载）
始终在上下文中，补充其他配置，支持路径范围
2. CLAUDE.md + @imports（回退）
├── 找到：读取CLAUDE.md + 跟随@imports
│ └── 从## 关键规则、## 约定部分提取规则
└── 未找到：继续回退
3. 未找到配置
├── 交互模式：使用AskUserQuestion
│ └── "未找到审查配置。使用默认规则审查？"
└── 非交互模式：仅应用默认规则
加载内容：
| 来源 | 解析内容 |
|---|---|
.claude/code-review.md |
技术栈、排除规则、严重性覆盖、自定义检查 |
.claude/rules/*.md |
由运行时自动注入；视为额外审查规则 |
| CLAUDE.md + @imports | 来自## 关键规则、## 约定、## 代码审查部分的文本 |
配置效果：
| 配置部分 | 对审查的影响 |
|---|---|
| 技术栈 | 覆盖自动检测，提高MCP查询准确性 |
| 排除规则 | 完全跳过这些规则（不生成发现） |
| 严重性覆盖 | 更改特定规则的默认严重性 |
| 自定义检查 | 添加项目特定检查（文件模式、内容规则） |
快速参考：
# 检查配置是否存在
ls .claude/code-review.md 2>/dev/null || echo "无配置，将使用CLAUDE.md回退"
# 预览将加载的配置（通过审查命令）
/code-quality:review --show-rules
代理适用性：
所有加载代码审查技能的代理必须执行步骤0b。包括代码审查员、质量审查员和安全审查员。每个代理在其领域内独立加载和应用仓库配置。
安全排除咨询：
当仓库配置排除安全相关规则时，代理必须发出咨询说明："咨询：安全规则’{rule}'被仓库配置排除。确保是故意的。"这仅是信息性的——不是发现，不阻塞。
步骤0e：Git历史分析
触发条件： thorough 或 strict 配置文件（部分用于 security/performance）
加载参考： references/tier-1/git-history-context.md
提取Git历史上下文以通知审查优先级并捕捉耦合问题：
- 读取配置 - 检查
.claude/code-review.md的历史分析设置 - 耦合分析 - 查找频繁一起更改的文件
- 热点检测 - 识别高变更文件（可配置阈值，默认：3个月内10+次更改）
- 作者上下文 - 提取所有权模式（仅
strict配置文件） - 最近模式 - 检测错误修复、安全或重构历史
快速参考命令：
# 耦合分析 - 一起更改的文件
git log --name-only --pretty=format: -- <files> | sort | uniq -c | sort -rn | head -20
# 热点检测 - 变更频率
git log --since="3 months ago" --name-only --pretty=format: | sort | uniq -c | sort -rn | head -20
# 作者上下文 - 所有权
git shortlog -sn -- <files>
# 最近模式 - 提交消息
git log --oneline -10 -- <files>
配置文件行为：
| 配置文件 | 分析深度 |
|---|---|
| quick | 完全跳过 |
| security | 部分（仅安全相关提交） |
| thorough | 耦合 + 热点 + 最近模式 |
| strict | 完整分析包括作者上下文 |
| performance | 部分（仅性能相关历史） |
步骤1：计算文件（准确文件计数）
审查前，计算文件以确保准确报告：
| 审查范围 | 计数命令 |
|---|---|
| 暂存更改 | git diff --staged --name-only | wc -l |
| PR更改 | git diff --name-only main...HEAD | wc -l |
| 特定路径 | 使用Glob工具并计数结果 |
重要：
- 准确跟踪此计数 - 在已审查文件输出中报告它
- 从审查计数中排除二进制文件（图像、编译资产）
- 从审查计数中排除已删除文件（无可审查）
- 对于重命名文件：计为1个文件（新名称）
大型更改集警告：
- 50+文件：考虑批量审查或共识模式
- 100+文件：强烈建议拆分为较小块
步骤1b：检测生成内容
扫描更改文件以识别由脚本/工具创建的文件。审查生成器（真相来源）而非生成输出。
检测标记（扫描前20行 + 后10行）：
| 文件类型 | 标记 |
|---|---|
| Markdown | Generated: YYYY-MM-DD, <!-- Generated by ScriptName --> |
| JSON | 根 "timestamp" 或 "generator" 字段 |
| 脚本 | Auto-generated from, DO NOT EDIT, Generated by |
| 代码 | // <auto-generated>, @generated, *.g.cs, *.generated.ts |
工作流：
- 扫描更改文件寻找标记
- 如果找到标记：提取生成器名称，搜索脚本，添加到审查范围
- 标记生成文件以跳过/轻量审查
- 警告如果仅生成文件更改（可能表示陈旧再生）
边缘案例：
- 生成器也更改 → 仅审查生成器，跳过生成文件
- 仅生成文件更改 → 警告：陈旧再生或手动编辑
- 未找到生成器 → 仍审查生成文件
- 安全敏感生成文件 → 仍审查（凭据、配置）
加载 references/tier-5/generated-content-detection.md 以获取完整检测模式和算法。
步骤2：确定范围
- 显式请求：用户指定的文件或更改
- 暂存更改：
git diff --staged或git status - 最近工作：当前会话中修改的文件
- PR范围：拉取请求中的所有文件
步骤3：加载上下文
检查仓库特定标准。如果找到，加载供第2层检查。
审查配置文件
当指定 --profile <name> 时，将层级加载限制到配置文件特定子集。这支持对特定关注点的集中审查。
可用配置文件：
| 配置文件 | 加载层级 | 描述 | 使用案例 |
|---|---|---|---|
security |
0, 1.3, 3-security | OWASP、秘密、认证、加密 | 合并前快速安全扫描 |
quick |
1.1-1.6, 1.12 | 设计、逻辑、样式基础 | 提交前快速检查 |
thorough |
所有层级 + 1.30-1.32 | 完整分析 + 参考/模式检查 | PR审查（默认） |
strict |
所有彻底 + 深度模式 | 完整分析 + 架构模式执行 | 库发布、重大更改 |
performance |
0, 1.5, 2-backend, 3-concurrency | N+1、复杂性、内存、并发 | 性能审计 |
配置文件层级映射：
security:
- 层级0：研究阶段（始终 - 检测认证/加密库）
- 层级1.3：安全（基于OWASP）
- 层级3：安全模式.md（当检测到认证/加密模式时）
- 跳过：设计、可读性、测试、文档
quick:
- 层级1.1：设计和架构（基本结构）
- 层级1.2：功能和逻辑（明显错误）
- 层级1.3：安全（仅关键 - 硬编码秘密）
- 层级1.4：并发（明显竞争条件）
- 层级1.5：性能（N+1、明显低效）
- 层级1.6：复杂性（极端违规）
- 层级1.12：样式（一致性）
- 跳过：层级0 MCP研究、层级2+、Clean Code深度探讨
thorough:
- 基于文件类型/模式加载所有层级
- 完整分析（默认行为）
- 部分1.30：参考完整性（当检测到重命名/删除时始终加载）
- 部分1.31：破坏性更改（当公共API更改时始终加载）
- 部分1.32：模式合规性（基本模式检查）
- 部分1.33-1.36：Git历史上下文（耦合、热点、最近模式）
strict:
- 所有“彻底”检查
- 部分1.32模式合规性（完整分析）：
- 架构模式偏差（CQRS、中介、仓库）
- DI注册一致性
- 文件组织执行
- 部分1.35：作者上下文（所有权模式、总线因子）
- 导入/导出卫生（模块边界、桶污染）
- 测试相关性（孤儿测试检测）
- 依赖安全性（迁移验证）
performance:
- 层级0：研究阶段（通过MCP的性能最佳实践）
- 层级1.5：性能和效率
- 层级2：后端检查.md（数据库、API性能）
- 层级3：并发模式.md（异步、线程）
- 跳过：样式、文档、Clean Code深度探讨
配置文件令牌节省：
| 配置文件 | 估计令牌 | 节省 vs Strict |
|---|---|---|
| security | ~5,500 | 60%+ |
| quick | ~3,500 | 75%+ |
| thorough | ~14,000 | 15% |
| strict | ~17,000 | 0%（基线） |
| performance | ~6,000 | 65%+ |
基线模式（差异分析）
当指定 --baseline <branch> 时，将每个发现标记为NEW或PRE-EXISTING。
为何重要： 这是代码审查工具采用的头号障碍。有技术债务的团队在PR仅引入3个新问题时被100+发现淹没，从而放弃工具。
基线模式工作流：
-
从git diff构建归因映射：
git diff <baseline>...HEAD # 三点对称比较 -
解析diff 以识别每个文件的更改行范围
-
对于每个发现：检查
file:line是否在更改范围内 -
标记发现：NEW（添加/修改行）或PRE-EXISTING（未更改）
-
分离输出：新问题突出，预存在问题折叠
发现归因规则：
| 行状态 | 归因 | 输出部分 |
|---|---|---|
添加（diff中的+） |
NEW | “引入的新问题” |
| 修改（在hunk中，更改） | NEW | “引入的新问题” |
| 上下文（在hunk中，未更改） | PRE-EXISTING | “预存在问题”（折叠） |
| 不在任何hunk中 | PRE-EXISTING | “预存在问题”（折叠） |
删除（diff中的-） |
SKIP | 不审查（不存在） |
基线输出格式：
## 审查摘要（基线模式）
**基线**: `main`
**新问题（此更改集）**: 2 关键, 1 主要 ← 重点在此
**预存在问题**: 47（折叠）
**评估**: 仅基于新问题
## 引入的新问题
[带归因的详细发现：NEW]
<details>
<summary>预存在问题（47）</summary>
[简明发现]
</details>
质量门（CI/CD）：
--fail-on-new-critical：如果任何新关键问题，退出1--fail-on-new-major：如果任何新主要问题，退出1- 预存在问题不使构建失败
边缘案例：
- 基线不存在 → 错误，带有效分支建议
- 文件重命名 → 基于内容更改归因
- 合并提交 → 使用三点diff进行正确比较
复杂性阈值
使用这些具体阈值评估代码复杂性：
| 指标 | 警告 | 错误 | 测量 |
|---|---|---|---|
| 圈复杂度 | > 10 | > 20 | 计算决策点（if、while、for、case、&&、||、?） |
| 认知复杂度 | > 15 | > 30 | SonarQube指标（嵌套增加更多权重） |
| 函数行数 | > 30 | > 50 | 计算非空、非注释行 |
| 嵌套深度 | > 3 | > 5 | 计算嵌套大括号/缩进级别 |
| 参数计数 | > 4 | > 7 | 计算函数/方法参数 |
| 文件行数 | > 300 | > 500 | 计算文件总行数 |
当阈值超过时：
- 警告 → 轻微严重性发现
- 错误 → 主要严重性发现
建议修复模板：
### 复杂性阈值超过
**文件**: `src/services/order.ts:processOrder()`
**严重性**: 主要
**指标**: 圈复杂度 = 23（阈值：15，错误：20）
**问题**: 函数有23个通过代码的独立路径。
**影响**: 难以测试（需要23+测试用例）、维护困难、高错误风险。
**修复**: 提取逻辑分支的方法。考虑：
- 提取验证逻辑 → `validateOrder()`
- 提取定价逻辑 → `calculatePrice()`
- 提取通知逻辑 → `notifyCustomer()`
渐进加载（令牌优化）
此技能使用分层渐进披露以优化令牌使用。仅加载与审查文件相关的内容。
层级0（强制 - 始终第一）： 研究阶段（约2,000令牌）
- 始终在分析前加载: references/tier-0/research-phase.md
- 包含：技术检测矩阵、MCP查询模板、“构建真相上下文”工作流
- 目的：在做出任何声明前查询MCP服务器以了解当前模式
- 此层级不可选 - 仅在代码纯内部且无外部依赖时跳过
层级1（始终应用）： 本文件中的通用检查（约4,500令牌）
- 部分1.1-1.12：设计、逻辑、安全、并发、性能、可读性、测试、错误处理、文档、跨平台、反重复、样式
- 部分1.25-1.29：Clean Code（命名、函数、注释、条件、代码异味）
- 部分1.30：参考完整性 - references/tier-1/reference-integrity.md（当检测到重命名/删除时）
- 部分1.31：破坏性更改 - references/tier-1/breaking-changes.md（当公共API更改时）
- 部分1.33-1.36：Git历史上下文 - references/tier-1/git-history-context.md（彻底/严格配置文件，约1,500令牌）
层级2（文件类型触发）： 基于文件扩展名加载
| 文件 | 加载参考 |
|---|---|
| .tsx、.jsx、.vue、.svelte | references/tier-2/frontend-checks.md |
| .py、.java、.cs、.go、.rb | references/tier-2/backend-checks.md |
| .swift、.kt、.dart | references/tier-2/mobile-checks.md |
| .sql、migrations/* | references/tier-2/database-checks.md |
| .yaml、.json、.env、.toml | references/tier-2/config-checks.md |
| Dockerfile、.tf、k8s/ | references/tier-2/infrastructure-checks.md |
| .ipynb、model/、ml/ | references/tier-2/ai-ml-checks.md |
层级3（内容模式触发）： 当代码包含特定模式时加载
| 模式关键词 | 加载参考 |
|---|---|
| auth、crypto、password、secret、token、jwt | references/tier-3/security-patterns.md |
| async、await、thread、lock、mutex、concurrent | references/tier-3/concurrency-patterns.md |
| route、endpoint、@app、@Get、@Post、api/ | references/tier-3/api-patterns.md |
| PII、email、user、customer、gdpr、consent | references/tier-3/privacy-patterns.md |
Clean Code深度探讨： 加载以获取详细指导
- references/clean-code/naming-functions.md - 完整命名和函数原则
- references/clean-code/code-smells.md - 完整代码异味目录
- references/clean-code/refactoring-patterns.md - 重构技术
层级4（仓库特定）： 当仓库配置或CLAUDE.md存在时加载
| 上下文 | 加载参考 |
|---|---|
| .claude/code-review.md 存在 | references/tier-4/repo-config.md |
| CLAUDE.md 存在（始终） | references/tier-4/claude-md-core.md |
| *.md 文件 | references/tier-4/documentation-rules.md |
| 重复指示符 | references/tier-4/anti-duplication-rules.md |
| 路径模式检测 | references/tier-4/path-rules.md |
| *-{platform}.md 文件 | references/tier-4/platform-rules.md |
| .claude/skills/** | references/tier-4/skill-rules.md |
| .claude/memory/** | references/tier-4/memory-rules.md |
| .claude/temp/** | references/tier-4/temp-file-rules.md |
| 配置文件彻底/严格 | references/tier-4/pattern-compliance.md |
层级4b（Claude Code组件）： 当检测到CC文件时，委托给专业审计员
| 文件模式 | 组件类型 | 审计员代理 |
|---|---|---|
.claude/agents/**/*.md, agents/*.md |
代理 | claude-ecosystem:agent-auditor |
.claude/skills/**, skills/*/SKILL.md |
技能 | claude-ecosystem:skill-auditor |
.claude/hooks/**, hooks.json |
钩子 | claude-ecosystem:hook-auditor |
.claude/skills/** |
技能 | claude-ecosystem:skill-auditor |
CLAUDE.md, .claude/memory/** |
内存 | claude-ecosystem:memory-component-auditor |
output-styles/*.md |
输出样式 | claude-ecosystem:output-style-auditor |
.mcp.json, mcp.json |
MCP配置 | claude-ecosystem:mcp-auditor |
settings.json, .claude/settings.json |
设置 | claude-ecosystem:settings-auditor |
plugin.json, .claude-plugin/** |
插件 | claude-ecosystem:plugin-component-auditor |
| 状态行脚本 | 状态行 | claude-ecosystem:statusline-auditor |
加载参考以获取完整检测和委托模式： references/tier-4/claude-code-components.md
注意： 层级4b需要安装claude-ecosystem插件。如果未安装，记录警告并跳过CC特定验证（继续标准审查）。
审计员代理验证： 代理名称可能在插件版本间更改。运行
/claude-ecosystem:list skills以验证当前审计员代理名称，如果委托失败。上表反映了此文件最后更新时的已知代理。
层级5（生成内容 & MCP验证详情）： 基于更改集特征加载
| 触发 | 加载参考 |
|---|---|
| 大型更改集（50+文件） | references/tier-5/generated-content-detection.md |
| 生成标记找到 | references/tier-5/generated-content-detection.md |
| 需要高级MCP查询模式 | references/tier-5/mcp-validation.md |
| 复杂技术栈 | references/tier-5/mcp-validation.md |
| 安全模式需要OWASP验证 | references/tier-5/mcp-validation.md |
注意： 主要MCP验证发生在层级0（研究阶段），这是强制性的。层级5 mcp-validation.md 为复杂场景提供额外查询模板和高级模式。
令牌预算估计：
| 场景 | 令牌 |
|---|---|
| 层级0研究阶段（强制） | ~2,000（始终包含） |
| 简单Python文件 | ~8,500（层级0 + 中心 + 后端） |
| React组件 | ~8,000（层级0 + 中心 + 前端） |
| 认证服务 | ~10,000（层级0 + 中心 + 后端 + 安全） |
| 全栈PR | ~11,500（层级0 + 中心 + 前端 + 后端 + API） |
| 文档文件（CLAUDE.md仓库） | ~8,500（层级0 + 中心 + 核心规则 + 文档规则） |
| 技能修改 | ~8,000（层级0 + 中心 + 核心规则 + 技能规则） |
| 内存文件更新 | ~7,500（层级0 + 中心 + 核心规则 + 内存规则） |
| 带高级MCP模式 | +~1,200令牌（层级5 mcp-validation.md） |
| 带CC审计员委托 | +~1,500令牌（层级4b参考 + 审计员生成开销） |
| 带生成内容检测 | +~1,200令牌（层级5 generated-content-detection.md） |
| 带Git历史上下文（彻底/严格） | +~1,500令牌（层级1 git-history-context.md） |
注意： 令牌预算增加了约2,000令牌，由于强制层级0研究阶段。这种权衡通过MCP验证提供了显著更准确的审查。
第1层：通用代码审查清单
这些检查适用于任何代码库、任何语言。
1.1 设计和架构
- [ ] 整体设计合理 - 组件间交互逻辑
- [ ] 属于此代码库 - 不适合库或不同模块
- [ ] 良好集成 - 适合现有系统架构
- [ ] 此更改的适当时机 - 不早熟或不解决错误问题
- [ ] 不过度工程 - 解决当前问题，而非推测未来需求（YAGNI）
SOLID原则：
- [ ] 单一职责原则（SRP） - 每个类/函数只有一个更改原因
- [ ] 开闭原则（OCP） - 对扩展开放，对修改关闭（无需为类型重复if/else）
- [ ] 里氏替换原则（LSP） - 派生类可替代基类（无需显式类型转换）
- [ ] 接口隔离原则（ISP） - 客户端仅依赖于它们使用的方法
- [ ] 依赖倒置原则（DIP） - 依赖于抽象，而非具体实现
1.2 功能和逻辑
- [ ] 做它应该做的事 - 实现预期功能
- [ ] 对用户有益 - 既对最终用户也对将使用此代码的开发人员
- [ ] 处理边缘案例 - 边界条件、空输入、null
- [ ] 错误处理健壮 - 失败优雅处理，带可操作消息
- [ ] 无逻辑错误 - 差一错误、错误操作符、不正确条件
1.3 安全（基于OWASP）
- [ ] 输入验证 - 所有输入服务器端验证（允许列表，非阻止列表）
- [ ] 输出编码 - 上下文适当编码（HTML、JS、SQL、URL）
- [ ] 无注入漏洞 - SQL、命令、XSS、路径遍历
- [ ] 认证正确 - 通过POST登录、安全会话处理、适当MFA
- [ ] 授权强制执行 - 基于角色的访问、最小权限原则
- [ ] 秘密不硬编码 - 无API密钥、密码、令牌在代码中
- [ ] 秘密不记录 - 无敏感数据在日志、错误消息、URL中
- [ ] 加密现代 - bcrypt/Argon2用于密码、AES-GCM用于加密、无MD5/SHA1
- [ ] 依赖安全 - 第三方库中无已知漏洞
1.4 并发和线程安全
- [ ] 共享状态保护 - 共享数据的适当锁、互斥锁或原子操作
- [ ] 无竞争条件 - 分析并发访问模式
- [ ] 一致锁顺序 - 按相同顺序获取锁以防止死锁
- [ ] 无循环依赖 - 在不同锁保护的资源间
- [ ] 异步模式正确 - 正确使用await、异常传播
- [ ] 线程安全集合 - 需要时使用并发集合
- [ ] 无死锁可能 - 超时机制、持锁时无无限等待
1.5 性能和效率
- [ ] 无必要操作 - 高效算法、无冗余工作
- [ ] 适当数据结构 - 对访问模式的正确选择
- [ ] 无N+1查询 - 数据库查询优化
- [ ] 内存高效 - 无泄漏、适当缓存
- [ ] I/O优化 - I/O绑定时使用异步、适当批处理
- [ ] 异步上下文中无阻塞 - 同步操作不阻塞异步上下文
1.6 复杂性和可读性
- [ ] 不比需要更复杂 - 可快速理解
- [ ] 函数/类大小合理 - 单一职责、不过长
- [ ] 无深度嵌套 - 最大3-4级缩进
- [ ] 清晰命名 - 名称完全传达目的，不过长
- [ ] 注释解释为什么 - 非什么（代码应自文档化）
- [ ] 无代码重复 - 遵循DRY原则
1.7 测试
- [ ] 包含测试 - 单元/集成测试适合更改
- [ ] 测试正确 - 实际测试它们声称测试的内容
- [ ] 测试有用 - 代码破坏时将失败
- [ ] 边缘案例测试 - 边界条件、错误场景
- [ ] 测试可维护 - 不过度复杂、清晰断言
- [ ] 无脆弱测试 - 确定性、不依赖时间
测试异味检测：
审查测试代码以获取常见测试异味，这些异味降低测试质量和可维护性：
| 异味 | 检测 | 严重性 | 为何重要 |
|---|---|---|---|
| 空测试 | 测试方法无断言 | 关键 | 错误信心 - 测试始终通过 |
| 急切测试 | 一个测试中>5个断言 | 警告 | 失败时，不清楚哪个行为破坏 |
| 神秘客人 | 外部文件/网络访问无模拟 | 主要 | 脆弱、慢、环境依赖 |
| 断言轮盘 | 多个断言无描述性消息 | 轻微 | 难以识别哪个断言失败 |
| 测试中睡眠 | Thread.Sleep, await Task.Delay, setTimeout |
主要 | 慢、脆弱、隐藏时间错误 |
| 死测试 | 从不失败的测试（始终通过） | 警告 | 通常测试无意义内容 |
| 注释掉的测试 | 禁用测试用例（[Ignore], skip, xtest） |
警告 | 技术债务、可能隐藏真实问题 |
| 测试代码重复 | 多个测试中相同设置/清理 | 轻微 | 维护负担、使用固定装置 |
示例发现：
### 测试异味：急切测试
**文件**: `tests/UserService.test.ts:45`
**严重性**: 警告
**置信度**: 中
**问题**: 测试“应处理用户操作”有12个断言测试多个行为。
**影响**: 当此测试失败时，您将不知道哪个行为破坏，而无需调试。
**建议修复**:
```typescript
// 之前（急切测试 - 12个断言，多个行为）
test('应处理用户操作', () => {
const user = createUser();
expect(user.name).toBe('John');
expect(user.email).toContain('@');
// ... 10个更多关于不同行为的断言
});
// 之后（专注测试 - 每个行为一个）
test('应创建具有有效名称的用户', () => {
const user = createUser();
expect(user.name).toBe('John');
});
test('应验证电子邮件格式', () => {
const user = createUser();
expect(user.email).toContain('@');
});
```markdown
### 测试异味：测试中睡眠
**文件**: `tests/api.test.ts:78`
**严重性**: 主要
**置信度**: 高
**问题**: 测试使用 `await new Promise(r => setTimeout(r, 2000))` 等待异步操作。
**影响**: 测试慢（2秒）、脆弱（时间变化）、隐藏真实异步处理错误。
**建议修复**:
```typescript
// 之前（睡眠 - 慢且脆弱）
await new Promise(r => setTimeout(r, 2000));
expect(result).toBeDefined();
// 之后（适当异步处理）
await waitFor(() => expect(result).toBeDefined());
// 或
await expect(asyncOperation()).resolves.toBeDefined();
### 1.8 错误处理和日志记录
- [ ] **错误适当捕获** - 正确粒度级别
- [ ] **错误消息可操作** - 清晰什么出错及如何修复
- [ ] **日志记录存在** - 用于调试和故障排除
- [ ] **日志中无敏感数据** - 排除PII、密码、密钥
- [ ] **优雅降级** - 部分失败不使整个系统崩溃
### 1.9 文档
- [ ] **代码文档化** - 公共API、复杂逻辑解释
- [ ] **README更新** - 如果行为/设置更改
- [ ] **API文档更新** - 如果端点更改
- [ ] **需要时内联注释** - 对于非明显决策
### 1.10 跨平台兼容性
- [ ] **无硬编码平台路径**:
- `/mnt/c/Users/...` (WSL)
- `/c/Users/...` (Git Bash)
- `C:\Users\...` (Windows)
- `/home/username/...` (Linux)
- `/Users/username/...` (macOS)
- [ ] **便携工具检测** - `command -v tool` 非路径查找
- [ ] **平台回退** - 功能不可用时的优雅处理
- [ ] **脚本自定位** - 使用 `Path(__file__).resolve()`, `$PSScriptRoot`, `${BASH_SOURCE[0]}`
### 1.11 反重复
- [ ] **无重复内容** - 相同信息仅在一个地方
- [ ] **无相同文件** - `diff` 相似文件以验证
- [ ] **单一真相来源** - 链接而非复制粘贴
- [ ] **配置文件不同** - 每个服务于不同目的
### 1.12 样式和一致性
- [ ] **遵循样式指南** - 语言/项目约定
- [ ] **与代码库一致** - 匹配现有模式
- [ ] **无样式更改与逻辑混合** - 单独格式化PR
### 1.13 可访问性（WCAG 2.1 AA）
- [ ] **存在替代文本** - 所有图像有描述性替代文本；装饰性图像使用 `alt=""`
- [ ] **颜色对比足够** - 文本4.5:1，UI组件3:1
- [ ] **键盘可导航** - 所有交互元素通过Tab/Enter/Space；无键盘陷阱
- [ ] **焦点可见** - 所有交互元素上清晰焦点指示
- [ ] **语义HTML** - 适当标题层次；按钮非div；链接非span
- [ ] **ARIA正确** - 仅当语义HTML不足时使用；无冲突角色
### 1.14 国际化（i18n）
- [ ] **无硬编码字符串** - 所有用户面向文本外部化到资源文件
- [ ] **语言环境感知格式化** - 日期、数字、货币使用语言环境API
- [ ] **RTL考虑** - 适用时使用逻辑CSS属性
- [ ] **无字符串连接** - 使用参数化消息，非 `"Hello " + name`
- [ ] **复数处理** - 适当复数规则，非 `count + " items"`
### 1.15 可观测性
- [ ] **结构化日志记录** - JSON格式，带追踪ID、时间戳、上下文
- [ ] **存在指标** - 关键路径的延迟、错误率、吞吐量
- [ ] **追踪上下文传播** - 跨越服务边界的分布式追踪
- [ ] **健康检查实现** - 带依赖检查的活动/就绪探针
- [ ] **定义SLO** - 关键操作的可测量服务级别目标
### 1.16 数据隐私（GDPR/CCPA）
- [ ] **PII识别和保护** - 个人数据加密、访问控制
- [ ] **数据保留强制执行** - 清晰策略、自动清理
- [ ] **删除权** - 可能跨所有系统完全擦除
- [ ] **同意跟踪** - 带审计轨迹的明确选择加入
- [ ] **日志中无PII** - 个人标识符的编辑或哈希
### 1.17 API设计
- [ ] **版本化策略** - URL、头或媒体类型中的清晰版本
- [ ] **向后兼容** - 新字段可为空、无移除字段
- [ ] **弃用文档化** - 日落日期、迁移路径
- [ ] **一致命名** - 遵循REST/GraphQL约定
- [ ] **错误响应标准化** - 跨端点的一致错误格式
### 1.18 依赖管理
- [ ] **无已知漏洞** - CI/CD中的CVE扫描
- [ ] **许可证合规** - 专有代码中无GPL冲突
- [ ] **版本固定** - 存在锁定文件并最新
- [ ] **传递依赖审查** - 间接依赖也安全
- [ ] **可用SBOM** - 审计的软件材料清单
### 1.19 数据库模式
- [ ] **避免N+1查询** - 使用急切加载或批量查询
- [ ] **存在索引** - 用于外键、连接列、查询模式
- [ ] **迁移向后兼容** - 增量更改、无数据丢失
- [ ] **模式适当规范化** - 或带清晰理由的反规范化
- [ ] **查询优化** - 复杂查询的审查执行计划
### 1.20 配置管理
- [ ] **秘密在保险库中** - 从不硬编码，使用环境变量或秘密管理器
- [ ] **使用功能标志** - 用于逐步推出、A/B测试
- [ ] **12因素合规** - 配置通过环境，非文件
- [ ] **启动时验证** - 缺失/无效配置时快速失败
- [ ] **环境奇偶性** - 开发/暂存/生产的相同配置结构
### 1.21 云/基础设施（12因素）
- [ ] **无状态进程** - 无本地会话存储，使用外部存储
- [ ] **端口绑定** - 自包含，通过端口导出HTTP
- [ ] **可处置性** - 快速启动，优雅SIGTERM关闭
- [ ] **开发/生产奇偶性** - 环境间最小差距
- [ ] **容器最佳实践** - 多阶段构建、非root用户、资源限制
- [ ] **使用IaC** - 可重复性的Terraform/CloudFormation
### 1.22 前端模式
- [ ] **组件设计** - 小、可重用、组合优于继承
- [ ] **状态管理** - 适当工具（本地、上下文、Zustand、Redux）
- [ ] **包大小** - 代码分割、懒加载、< 500KB主包
- [ ] **记忆化** - 策略性使用memo/useMemo/useCallback
- [ ] **Web Vitals** - LCP < 2.5s、FID < 100ms、CLS < 0.1
### 1.23 移动模式
- [ ] **电池高效** - WorkManager/JobScheduler、批量操作
- [ ] **离线优先** - 带同步的本地缓存、离线队列
- [ ] **响应式布局** - 灵活尺寸（dp/sp）、旋转处理
- [ ] **内存高效** - 图像下采样、生命周期意识
- [ ] **网络高效** - 请求批处理、压缩、指数退避
### 1.24 AI/ML代码模式
- [ ] **模型版本化** - 用于模型和数据的MLflow/DVC
- [ ] **可重复性** - 随机种子、固定依赖、精确环境
- [ ] **偏见检测** - 跨人口统计的公平性指标
- [ ] **数据管道验证** - 模式验证、统计测试
- [ ] **模型监控** - 数据和性能的漂移检测
### 1.25 Clean Code：命名（Robert C. Martin）
- [ ] **意图揭示名称** - 名称告诉您为什么存在、做什么、如何使用
- [ ] **无误导名称** - `accountList` 应实际上是列表；避免错误线索
- [ ] **有意义的区别** - 非 `data1`、`data2`、`dataInfo`、`theData`
- [ ] **可发音名称** - 可口头讨论代码而无需拼写变量
- [ ] **可搜索名称** - 仅对小局部范围使用单字母名称
- [ ] **无编码** - 无匈牙利表示法、无类型前缀（strName、intCount）
- [ ] **无心智映射** - 读者不应将名称翻译为他们已知的概念
- [ ] **类名是名词** - Customer、Account、Parser（非动词）
- [ ] **方法名是动词** - postPayment、deletePage、save（非名词）
### 1.26 Clean Code：函数（Robert C. Martin）
- [ ] **小** - 5-20行理想；罕见超过30行
- [ ] **做一件事** - 单一抽象级别；一个更改原因
- [ ] **一个抽象级别** - 不要混合getHtml()与.append("
")
- [ ] **描述性名称** - 长描述性名称优于短神秘名称
- [ ] **少参数** - 零理想，一/二好，三可疑，永远不超过四
- [ ] **无标志参数** - 拆分函数为两个而非传递布尔值
- [ ] **无副作用** - 不修改意外状态；函数仅做名称所说
- [ ] **命令/查询分离** - 要么做某事要么回答某事，从不两者
- [ ] **偏好异常而非错误代码** - 不返回-1或null表示错误
- [ ] **提取try/catch块** - try/catch的主体应为单行函数调用
### 1.27 Clean Code：注释（Robert C. Martin）
- [ ] **代码首先自解释** - 如果需要注释，尝试重写代码
- [ ] **注释解释为什么** - 非什么（代码显示什么）或如何（代码显示如何）
- [ ] **法律注释可接受** - 版权、许可证头
- [ ] **信息性注释可接受** - 正则表达式解释、返回值含义
- [ ] **TODO注释有票据** - `// TODO: TICKET-123 - API v2后重构`
- [ ] **无冗余注释** - `// 构造函数`在构造函数上是噪音
- [ ] **无注释掉的代码** - 删除它；版本控制记得
- [ ] **无闭合大括号注释** - `} // 结束如果`意味着函数太长
- [ ] **无归因注释** - `// 由Bob添加` - 使用版本控制责任
- [ ] **无日志注释** - 更改日志属于VCS，非代码
### 1.28 Clean Code：条件（Pragmatic Programmer）
- [ ] **正面条件** - `if (isValid)` 非 `if (!isInvalid)`
- [ ] **无双重否定** - `if (!notFound)` 应为 `if (found)`
- [ ] **保护子句** - 边缘案例的早期返回；避免深度嵌套
- [ ] **解释性变量** - 提取复杂条件到命名布尔值
- [ ] **封装条件** - `if (shouldBeDeleted(timer))` 非 `if (timer.hasExpired() && !timer.isRecurrent())`
- [ ] **避免否定条件** - `if (buffer.shouldCompact())` 非 `if (!buffer.shouldNotCompact())`
- [ ] **多态性优于开关** - 基于类型的开关通常指示缺失多态性
- [ ] **无处不在无null检查** - 使用空对象模式或可选类型
### 1.29 代码异味快速参考
| 异味 | 检测 | 影响 | 修复 |
| --- | --- | --- | --- |
| **长方法** | > 30行 | 可维护性 | 提取方法 |
| **长参数列表** | > 4参数 | 可用性 | 引入参数对象 |
| **深度嵌套** | > 3-4缩进级别 | 可读性 | 保护子句、提取方法 |
| **魔法数字** | 硬编码值 | 可维护性 | 命名常量 |
| **上帝类** | 类做太多 | 可测试性、耦合 | 按职责提取类 |
| **特征嫉妒** | 方法使用其他类的数据 | 耦合 | 将方法移动到数据类 |
| **重复代码** | 相同逻辑重复 | DRY违规 | 提取到共享函数 |
| **死代码** | 未使用代码 | 杂乱、混淆 | 删除它 |
| **原始迷恋** | 过度使用原始类型 | 类型安全 | 值对象 |
| **霰弹枪手术** | 一个更改触及许多文件 | 脆弱性 | 整合相关代码 |
| **发散更改** | 一个类因多种原因更改 | SRP违规 | 按更改原因拆分 |
| **数据群** | 相同数据一起出现 | 缺失抽象 | 为数据组创建类 |
| **注释** | 解释坏代码 | 可读性 | 重写代码 |
| **推测性通用性** | 为“未来需求”的代码 | 复杂性 | 删除未使用的抽象 |
### 1.30 参考完整性（重命名/清理验证）
**触发条件：** Git diff显示重命名（R）或删除（D）
当文件、函数、类或变量重命名或删除时，验证所有引用已更新。
- [ ] **导入已更新** - 无引用旧路径/名称的损坏导入
- [ ] **文档链接有效** - 无指向重命名/删除文件的陈旧Markdown链接
- [ ] **配置引用当前** - tsconfig、package.json等中无孤立引用
- [ ] **字符串字面量检查** - 对旧名称的硬编码引用（低置信度，配置文件门控）
**检测：**
```bash
# 从git diff检测重命名和删除
git diff --name-status HEAD~1 | grep -E '^[RD]'
严重性：
| 检查 | 严重性 | 始终开启 |
|---|---|---|
| 重命名后损坏导入 | 关键 | 是 |
| 陈旧文档链接 | 主要 | 是 |
| 孤立配置引用 | 主要 | 是 |
| 硬编码字符串引用 | 轻微 | 配置文件（彻底+） |
加载参考： references/tier-1/reference-integrity.md 当检测到重命名/删除时。
1.31 破坏性更改检测
触发条件： 公共API表面更改
检测可能破坏公共API外部消费者的更改。
- [ ] 无公共成员移除 - 无弃用下公共方法/类被删除
- [ ] 签名保留 - 参数类型/计数未更改
- [ ] 返回类型兼容 - 返回类型未更改，无迁移路径
- [ ] 行为文档化 - 通过注释标记语义更改
检测：
# 标识移除的公共成员
git diff HEAD~1 | grep "^-.*public\s"
严重性：
| 检查 | 严重性 | 始终开启 |
|---|---|---|
| 公共API移除 | 关键 | 是 |
| 签名更改 | 关键 | 是 |
| 返回类型更改 | 主要 | 是 |
| 行为更改（手动） | 主要 | 标记 |
加载参考： references/tier-1/breaking-changes.md 用于公共API更改。
1.32 模式合规性
触发条件： thorough 或 strict 配置文件
验证新代码匹配代码库中建立的模式。
- [ ] 错误处理一致 - 匹配代码库模式（Result<T>、异常等）
- [ ] 命名约定遵循 - 类/方法/变量命名匹配建立样式
- [ ] 架构模式尊重 - 维护CQRS、仓库等模式
- [ ] 文件组织匹配 - 新文件在预期位置，根据项目结构
加载参考： references/tier-4/pattern-compliance.md 用于模式检测和比较。
1.33 缺失共同更改文件（Git历史）
触发条件： thorough 或 strict 配置文件
检测频繁一起更改但不在审查范围内的文件。
- [ ] 共同更改模式分析 - 标识>60%共同更改率的文件
- [ ] 缺失伴侣标记 - 相关文件不在审查范围
- [ ] 测试耦合验证 - 源更改包括相关测试文件
严重性： 主要（>60%共同更改率的文件缺失可能指示不完整更改）
加载参考： references/tier-1/git-history-context.md
1.34 审查中热点（Git历史）
触发条件： thorough 或 strict 配置文件
标识高变更文件，需要额外审查。
- [ ] 变更频率分析 - 在配置窗口内更改10+次的文件标记
- [ ] 提交模式分类 - 标识错误修复、功能、重构
- [ ] 应用额外审查 - 热点的更高审查优先级
严重性： 警告（高变更文件可能指示设计问题或脆弱代码）
加载参考： references/tier-1/git-history-context.md
1.35 单所有者文件（Git历史）
触发条件： strict 配置文件仅
标识所有权集中的文件（总线因子风险）。
- [ ] 所有权分析 - 标识主要作者（>90%提交）
- [ ] 总线因子注意 - 单所有者文件标记用于知识共享
- [ ] 新作者更改 - 当新作者修改建立文件时标记
严重性： 信息（意识项，非阻塞问题）
加载参考： references/tier-1/git-history-context.md
1.36 最近错误修复区域（Git历史）
触发条件： thorough 或 strict 配置文件
标识最近有错误修复活动可能脆弱的区域。
- [ ] 错误修复历史分析 - 最近提交带fix/bug/patch关键词
- [ ] 脆弱区域标记 - 配置窗口内3+错误修复
- [ ] 额外边缘案例审查 - 对错误路径的更高注意力
严重性： 警告（最近修复的区域可能需要额外注意）
加载参考： references/tier-1/git-history-context.md
第2层：仓库特定检查
仅当CLAUDE.md或仓库标准存在时。
2.1 模式合规性
- [ ] 遵循现有模式 - 类似于仓库中其他文件
- [ ] 命名约定匹配 - 与建立名称一致
- [ ] 文件结构正确 - 在正确位置，具有正确布局
2.2 CLAUDE.md反模式（如果适用）
- [ ] 无混合操作系统内容 - 每个文件为一个平台
- [ ] 无主题文件夹中的README.md - 仅在根目录
- [ ] 无编号文件名 -
git-setup.md非01-git-setup.md - [ ] 标题-文件名一致性 - 文件名匹配
# 标题
第3层：仓库规则（CLAUDE.md合规性）
仅用于根目录有CLAUDE.md的仓库。 基于审查的文件类型加载层级4参考。
3.1 检测和激活
- 检查仓库根目录中的
CLAUDE.md - 检查
.claude/memory/目录 - 如果两者存在，应用第3层检查
- 为每次审查加载 tier-4/claude-md-core.md
3.2 快速参考清单
- [ ] 无绝对路径 - 使用根相对或占位符（
<repo-root>,<skill-name>） - [ ] 标题-文件名匹配 -
git-setup-windows.md-># Git Setup Windows - [ ] 无平台混合 - 每个文件仅服务于一个平台
- [ ] 无主题文件夹中的README - 仅在根目录和中心级别
- [ ] 无编号文件 -
git-setup.md非01-git-setup.md - [ ] 临时文件在 .claude/temp/ - 无其他地方，正确命名约定
- [ ] 单一真相来源 - 链接，不重复内容
- [ ] UTF-8编码 - 仅ASCII标点（无智能引号）
- [ ] 官方来源 - 文档由官方文档支持，带最后验证日期
3.3 文档文件（*.md）
为以下加载 tier-4/documentation-rules.md：
- [ ] 官方文档链接 - 所有设置指南必需
- [ ] 版本信息 - 记录当前和最低版本
- [ ] 安装步骤 - 按依赖顺序
- [ ] 验证步骤 - 带预期输出
- [ ] 最后验证日期 - 存在且最近
3.4 平台特定文件（*-{platform}.md）
为以下加载 tier-4/platform-rules.md：
- [ ] 平台分离 - 无混合操作系统内容
- [ ] 正确后缀 -
-windows、-macos、-linux、-wsl - [ ] WSL重定向模式 - 适当时重定向到Linux
- [ ] 中心完整性 - 所有平台中心一起更新
3.5 反重复
当检测到重复指示符时，加载 tier-4/anti-duplication-rules.md：
- [ ] 无重复内容 - 每条信息在一个地方
- [ ] 版本仅在最后验证中 - 所有其他文件链接到它
- [ ] 中心链接到分支 - 中心和参考间无内容重复
- [ ] 每个任务一个报告 - 整合多个报告
3.6 路径约定
当检测到路径模式时，加载 tier-4/path-rules.md：
- [ ] 无绝对路径 - 平台特定绝对路径被禁止
- [ ] 根相对路径 - 从仓库根目录，非当前目录
- [ ] 通用占位符 -
<repo-root>、<skill-name>优于显式路径 - [ ] 脚本自定位 -
Path(__file__).resolve()、$PSScriptRoot
3.7 技能文件（.claude/skills/**）
为以下加载 tier-4/skill-rules.md：
- [ ] SKILL.md结构 - 必需部分存在
- [ ] YAML frontmatter - name、description、allowed-tools
- [ ] 渐进披露 - 分层参考加载
- [ ] 技能封装 - 无内部路径暴露外部
3.8 内存文件（.claude/memory/**）
为以下加载 tier-4/memory-rules.md：
- [ ] 导入语法 -
@.claude/memory/file.md - [ ] 令牌预算文档化 - 注意近似令牌计数
- [ ] 上下文指导 - 何时加载（始终 vs 上下文依赖）
- [ ] 最后更新日期 - 存在且准确
3.9 临时文件（.claude/temp/**）
为以下加载 tier-4/temp-file-rules.md：
- [ ] 正确位置 - 仅允许
.claude/temp/ - [ ] 命名约定 -
YYYY-MM-DD_HHmmss-{agent-type}-{topic}.md - [ ] 平面结构 - 无子目录
- [ ] UTC时间戳 - ISO 8601格式
严重性分类
关键（必须修复）
- 安全漏洞（注入、认证绕过、秘密暴露）
- 数据丢失或损坏潜在性
- 生产代码中的竞争条件
- 功能破坏
- 硬编码秘密或凭据
警告（应修复）
- 性能问题
- 缺失错误处理
- 不充分测试覆盖
- 代码重复
- 硬编码平台路径
- 糟糕命名
建议（考虑）
- 样式改进（前缀“Nit：”）
- 替代方法
- 文档增强
- 重构机会
报告格式
## 代码审查发现
### 配置摘要
**配置来源**: `.claude/code-review.md` | CLAUDE.md + @imports（回退） | 仅默认值
**技术栈**: .NET 10、ASP.NET Core 10（配置覆盖） | React 19（自动检测）
**排除规则**: [计数]（[如有列出]）
**严重性覆盖**: [计数]（[规则: 旧→新 如有]）
**自定义检查**: [计数]（[列出如有]）
### 技术研究摘要（来自步骤0）
| 类别 | 技术 | 版本 | MCP来源 | 检测 |
| --- | --- | --- | --- | --- |
| 运行时 | .NET | 10 | perplexity | 配置覆盖 |
| 框架 | ASP.NET Core | 10 | microsoft-learn + perplexity | 配置覆盖 |
| 前端 | React | 19 | context7 | package.json |
### 关键问题（必须修复）
1. **[问题标题]**
- **位置**: 文件:行
- **问题**: 什么出错及为何重要
- **置信度**: 高 | 中 | 低
- **修复**: 具体代码更改
- **建议修复**（当置信度高时）：
```语言
// 之前（有问题）
[原始代码]
// 之后（修复）
[更正代码]
```
- **规则来源**: 层级1（通用） - 1.3 安全 | 层级4（repo-config.md） - 自定义检查
- **已验证**: 是 - [来源] [mcp-server-name]
### 警告（应修复）
1. **[问题标题]**
- **位置**: 文件:行
- **问题**: 什么出错
- **置信度**: 高 | 中 | 低
- **修复**: 具体更改
- **建议修复**（当置信度高时）：
```语言
// 之前
[原始代码]
// 之后
[更正代码]
```
- **规则来源**: 层级1（通用） - 1.5 性能 | CLAUDE.md - 关键规则
- **已验证**: 是/否 - [如果已验证来源]
### 建议（Nit）
1. [带理由的建议]
- **置信度**: 低（样式）
- **规则来源**: 层级1（通用） - 1.12 样式
### MCP验证摘要
**咨询来源**: [计数]
**已验证发现**: [已验证/总数]
**已应用更正**: [计数]（基于MCP研究更正的发现）
| 发现 | 来源 | 状态 |
| --- | --- | --- |
| [发现] | [mcp-server] | 已确认/已更正/过时 |
规则来源值
规则来源字段指示哪个规则触发了发现：
| 来源类型 | 格式 | 示例 |
|---|---|---|
| 通用检查 | 层级1（通用） - {部分} |
层级1（通用） - 1.3 安全 |
| 文件类型检查 | 层级2（{类型}） - {部分} |
层级2（后端） - API设计 |
| 内容触发 | 层级3（{模式}） - {部分} |
层级3（安全） - OWASP认证 |
| 仓库配置 | 层级4（repo-config.md） - {部分} |
层级4（repo-config.md） - 自定义检查: PowerShell命名 |
| CLAUDE.md | CLAUDE.md - {部分} |
CLAUDE.md - 关键规则 |
| 自定义检查 | 自定义检查: {名称} |
自定义检查: 无Console.WriteLine |
验证状态选项：
- 是 - [来源] [mcp-server]: 发现针对权威来源验证
- 否（内部模式）: 无需外部参考（仓库特定约定）
- 否（MCP不可用）: MCP服务器不可用；推荐手动验证
置信度级别
置信度字段指示发现有多确定：
| 级别 | 标准 | 建议修复？ |
|---|---|---|
| 高 | 精确模式匹配 + MCP验证 | 是 - 生成可操作修复代码 |
| 中 | 语义分析、可识别的反模式 | 可选 - 如果清晰模式则提供代码片段 |
| 低 | 启发式/样式、可能是误报 | 否 - 仅描述问题 |
置信度分配逻辑：
1. 检测到模式匹配？
├── 是 + MCP验证模式 → 高
├── 是 + 无MCP验证 → 中
└── 否 → 继续启发式
2. 识别到反模式？
├── 是 + 清晰修复路径 → 中
└── 是 + 模糊修复 → 低
3. 样式/主观关注？
└── 始终 → 低
按置信度级别示例：
| 发现 | 置信度 | 原因 |
|---|---|---|
| 通过字符串连接进行SQL注入 | 高 | 精确模式、OWASP记录修复 |
| 缺失null检查 | 中 | 可识别模式、上下文依赖修复 |
| 方法太长（35行） | 低 | 启发式、可能在上下文中可接受 |
| 变量命名建议 | 低 | 样式偏好 |
建议修复指南
当以下时包含建议修复：
- 置信度高 - 模式匹配 + MCP验证
- 修复是确定性的 - 只有一种正确修复方式
- MCP提供代码模式 - 基于权威来源的修复
建议修复格式：
**建议修复**:
```csharp
// 之前（易受攻击）
var query = "SELECT * FROM Users WHERE Id = " + userId;
// 之后（参数化 - OWASP推荐）
var query = "SELECT * FROM Users WHERE Id = @userId";
cmd.Parameters.AddWithValue("@userId", userId);
**当以下时省略建议修复：**
1. **置信度低** - 可能是误报
2. **多个有效方法** - 用户应选择
3. **上下文依赖** - 需要理解更广泛系统
4. **MCP不可用** - 无法验证修复模式
## 反模式（不要做的事）
- **"总体看起来好"** - 未经系统化清单审查，绝不
- **怀疑的好处** - 如果有问题，它是一个发现
- **总结** - 批判性分析针对清单
- **缺失安全问题** - 始终检查OWASP基础
- **忽略并发** - 思考竞争条件
- **跳过相似文件** - 始终比较相似目的文件
- **模糊修复** - "修复此" 对比 "替换行X-Y为..."
- **部分表验证** - 从不仅验证参考表中的某些项；如果引用表，验证所有项，使用Glob或git状态
- **无Glob下结论文件缺失** - 不确定文件是否存在时，使用 `Glob pattern="path/**/*.md"` 验证，而非基于未读内容假设
## 行为规则
1. **保持怀疑，非慈善** - 假设有问题直到验证干净
2. **每行重要** - 审查所有分配代码，理解它
3. **像攻击者一样思考** - 可能出什么错？如何利用此？
4. **像用户一样思考** - 既最终用户也开发用户
5. **上下文重要** - 在整个文件/系统的上下文中查看更改
6. **报告一切** - 每个问题，带适当严重性
7. **提出具体修复** - 具体代码，非模糊建议
8. **承认好事物** - 称赞做得好的代码
## 快速参考卡
```text
始终检查：
[ ] 安全：输入验证、输出编码、无秘密
[ ] 并发：共享状态保护、无竞争条件
[ ] 设计：SOLID原则、适当复杂性
[ ] 测试：存在、正确、有用
[ ] 平台：无硬编码路径、便携检测
[ ] 重复：比较相似文件
[ ] 可访问性：替代文本、对比、键盘导航、语义HTML
[ ] i18n：无硬编码字符串、语言环境感知格式化
[ ] 可观测性：结构化日志、指标、追踪、健康检查
[ ] 隐私：PII保护、日志中无PII、同意跟踪
Clean Code（Robert C. Martin）：
[ ] 命名：意图揭示、可发音、可搜索、无编码
[ ] 函数：小（5-20行）、做一件事、少参数（0-2）、无副作用
[ ] 注释：解释为什么非什么、无注释掉的代码、无冗余
[ ] 条件：正面条件、保护子句、无双重否定
领域特定（当适用）：
[ ] API：版本化、向后兼容、错误格式
[ ] 数据库：避免N+1、索引、迁移安全
[ ] 配置：秘密在保险库中、功能标志、12因素
[ ] 前端：组件设计、包大小、Web Vitals
[ ] 移动：电池/内存/网络高效、离线优先
[ ] AI/ML：模型版本化、可重复性、偏见检测
代码异味（注意）：
- 长方法（> 30行）
- 长参数列表（> 4参数）
- 深度嵌套（> 3-4级别）
- 上帝类（太多职责）
- 特征嫉妒（方法使用其他类的数据）
- 原始迷恋（应使用值对象）
- 霰弹枪手术（一个更改触及许多文件）
红色标志：
- 长if/else链（OCP违规）
- 显式类型转换（LSP违规）
- new关键字过度使用（DIP违规）
- 查询中字符串连接（注入）
- 无锁共享状态（竞争条件）
- 捕获所有异常处理器（错误隐藏）
- 魔法数字/字符串（可维护性）
- 平台特定路径（便携性）
- 图像上缺失替代文本（可访问性）
- 硬编码用户面向字符串（i18n）
- console.log而非结构化日志（可观测性）
- 日志语句中的PII（隐私违规）
参考
- 详细清单 - 带检测模式的扩展清单
- Google工程实践
- OWASP安全代码审查
版本历史
- v9.0.0 (2025-12-31): 主要：增强验证差距 - 添加6个新验证能力：(1) 参考完整性（部分1.30） - 重命名/删除后验证导入、文档链接、配置；(2) 破坏性更改检测（部分1.31） - 检测公共API移除、签名更改；(3) 模式合规性（部分1.32） - 验证错误处理、命名、架构一致性；(4) 导入/导出卫生 - 未使用导入、循环依赖、模块边界；(5) 测试影响相关性 - 代码更改无测试更新；(6) 依赖更新安全性 - 主要版本升级、破坏性更改。添加新
strict配置文件用于库发布。令牌预算更新：彻底~14K，严格~17K。 - v8.0.0 (2025-12-29): 主要：研究优先MCP验证 - 添加强制步骤0（研究阶段），在任何代码分析前运行；添加层级0到渐进加载（始终第一）；MCP验证现在详尽且必需，非条件；所有发现必须包括验证状态；添加技术研究摘要和MCP验证摘要到报告格式；Microsoft技术始终需要perplexity（双重验证）；令牌预算增加~2,000令牌以换取准确性
- v7.0.0 (2025-12-29): 添加生成内容检测（步骤1b）；通过内容基础标记检测脚本/工具创建的文件；重定向审查到生成器脚本（真相来源）；减少大型更改集中的审查噪音；添加层级5参考用于检测模式和算法
- v6.0.0 (2025-12-29): 添加准确文件计数工作流（步骤1）；添加层级4b Claude Code组件检测，委托给claude-ecosystem审计员；文件计数确保大型更改集的准确已审查文件报告
- v5.0.0 (2025-12-24): 添加层级5 MCP验证阶段，用于使用MCP服务器（perplexity、context7、ref、microsoft-learn、firecrawl）验证发现当前最佳实践；包括技术检测、交叉验证和引用支持
- v4.0.0 (2025-11-28): 添加第3层（仓库规则）带层级4 CLAUDE.md特定检查；添加8个参考文件用于文档、反重复、路径、平台、技能、内存和临时文件；扩展渐进加载以支持仓库特定验证
- v3.0.0 (2025-11-28): 添加Clean Code原则（部分1.25-1.29）：来自Robert C. Martin和Pragmatic Programmer的命名、函数、注释、条件、代码异味；使用Clean Code和代码异味部分更新快速参考卡
- v2.1.0 (2025-11-28): 添加12个现代横切部分（1.13-1.24）：可访问性、i18n、可观测性、数据隐私、API设计、依赖管理、数据库模式、配置管理、云/基础设施、前端模式、移动模式、AI/ML代码模式
- v2.0.0 (2025-11-27): 主要扩展带SOLID、OWASP、并发、Google实践
- v1.0.0 (2025-11-27): 初始发布