verify

/verify -- 7 阶段验证流水线

是什么

运行一个按顺序执行的 7 阶段验证流水线，在每个层面发现问题—— 从编译器错误到细微的反模式，再到格式偏差。每个阶段都会给出明确的 PASS、WARN 或 FAIL，并附上详细信息。“看起来没问题”不是验证 结果；状态表才是。关键失败（阶段 1 构建、阶段 4 测试）会使流水线提前终止，因为代码已损坏时，后续阶段无法得出有意义的结果。

流水线回答一个问题：“这段代码可以提交审核了吗？”

阶段	工具	检查内容	关键
1. 构建	dotnet build	编译错误、缺少引用	是
2. 诊断	get_diagnostics (MCP)	新增分析器警告、可空性问题	出现新错误时为 FAIL
3. 反模式	detect_antipatterns (MCP)	async void、同步调用异步、DateTime.Now 等	否
4. 测试	dotnet test	测试失败、回归	是
5. 安全	dotnet list package --vulnerable + 扫描	密钥、SQL 注入、缺少身份验证、易受攻击的包	出现严重/高危问题时为 FAIL
6. 格式	dotnet format --verify-no-changes	风格偏差、格式不一致	否
7. 差异审核	git diff 分析	意外更改、遗留调试代码、TODO	否

何时使用

• 完成一项功能、错误修复或重大重构后
• 创建拉取请求前——必须执行完整流水线，不容妥协
• 合并上游更改或更新依赖项后
• 用户说“验证”“检查所有内容”“准备好了吗”“运行所有检查”时
• 将任务标记为完成前的最后一步

运行哪些阶段

默认运行完整流水线。对于范围明确的更改，可运行部分阶段：

场景	阶段	备注
功能完成／提交 PR 前／新增端点	全部 7 个	不走捷径
错误修复	1、2、4	如果没有测试覆盖，先添加测试
重构后	1、2、3、4	重点关注正确性；涉及安全时增加第 5–7 阶段
依赖项更新	1、4、5	构建、测试、漏洞扫描
配置或仅测试更改	1、4	构建和测试
仅格式调整	6	格式检查已足够

有疑问时，运行全部 7 个阶段。额外阶段只需几分钟；漏掉安全问题可能导致数天的事故响应。绝不要因为更改“看起来安全”就挑选阶段执行。

如何操作

阶段 1：构建（关键——会使流水线提前终止）

dotnet build --no-restore --verbosity quiet

• 如果构建失败，立即停止。报告错误并修复后再继续——无法编译的代码，其后续检查都没有意义。
• 即使结果为 PASS，也要记录警告数量；新增警告会在阶段 2 跟踪。
• 输出：PASS（0 个错误）或 FAIL（附错误列表）

阶段 2：诊断

使用 Roslyn MCP 的 get_diagnostics 工具，范围限定为已更改的文件／项目 （跨多个部分的更改则检查整个解决方案）。与基线对比——只标记当前更改引入的新增警告。常见发现：CS8600/CS8602 （可空性）、CS0219（未使用的变量）。

输出：PASS（无新增）／WARN（有新增警告）／FAIL（有新增错误）。将新增 警告视为待处理工作——今天的 CS8600，可能会变成下个月生产环境中的 NullReferenceException。

阶段 3：反模式检测

对已更改的文件使用 Roslyn MCP 的 detect_antipatterns 工具（大范围更改则检查整个 项目）。可发现：async void、同步调用异步（.Result、 .GetAwaiter().GetResult()）、new HttpClient()、使用 DateTime.Now/UtcNow 而非 TimeProvider、宽泛的 catch (Exception)、日志中使用字符串插值、缺少 CancellationToken、未使用 AsNoTracking 的 EF 读取查询。

输出：PASS（无发现）／WARN（有发现）／FAIL（有严重反模式）

阶段 4：测试（关键——短路）

dotnet test --no-build --verbosity quiet

• 运行完整测试套件；对于大型解决方案，可限定为受影响的测试项目。
• 任何测试失败都视为失败——没有例外。停止后续阶段并先修复问题。
• 如果不存在测试项目：跳过，并建议添加测试。

输出：通过（全部通过）或失败（失败的测试名称 + 错误消息）

阶段 5：安全扫描

dotnet list package --vulnerable --include-transitive

然后检查已更改的文件，查找：硬编码的密钥／连接字符串／API 密钥、 SQL 注入（未使用参数化的原始 SQL）、需要授权的端点缺少 [Authorize]、 过于宽松的 CORS、缺少输入验证、禁用了 HTTPS 或证书验证。

输出：通过／警告（中低风险问题）／失败（严重／高危漏洞）

阶段 6：格式检查

dotnet format --verify-no-changes --verbosity quiet

报告格式偏差，但不自动修复。要解决问题，请运行 dotnet format，并将 更改纳入提交。如果不存在 .editorconfig，请将其作为建议指出。

输出：通过／警告（附文件列表）

阶段 7：差异审查

分析 git diff --stat 和 git diff（已暂存 + 未暂存），检查：

• 意外或无关的文件更改（.vs/、bin/、obj/、.env、密钥）
• 调试遗留内容（生产路径中的 Console.WriteLine、#if DEBUG）
• 尚未解决的 TODO/HACK/FIXME 标记
• 范围不匹配——更改必须符合任务／PR 描述

输出：通过（干净，符合预期）／警告（附问题）

修复并重试循环

单次运行很少能让所有检查全部通过。循环正是关键：

1. 识别——哪个阶段失败，以及具体错误
2. 修复——进行解决问题所需的最小更改
3. 重新运行——如果修复更改了代码，则从阶段 1 开始；否则从失败的阶段开始
4. 重复——直到所有阶段通过，或遇到需要用户输入的问题

最终总结

## Verification Results

| Phase | Result | Details |
|-------|--------|---------|
| 1. Build | PASS | 0 errors, 0 warnings |
| 2. Diagnostics | PASS | 0 new diagnostics |
| 3. Antipatterns | WARN | 1 missing CancellationToken |
| 4. Tests | PASS | 47 passed, 0 failed |
| 5. Security | PASS | No findings |
| 6. Format | PASS | Clean |
| 7. Diff Review | WARN | 1 TODO marker found |

**Verdict: READY FOR REVIEW** (with 2 non-blocking warnings)

判定结果：可供审查（全部通过，或仅有不阻塞的警告）或 需要修复（存在任何失败，并附具体修复步骤）。对于 PR 前的运行， 请将验证报告加入 PR 描述。

示例

User: /verify

Claude: Running 7-phase verification pipeline...

Phase 1: Build ............ PASS (0 errors)
Phase 2: Diagnostics ...... PASS (0 new warnings)
Phase 3: Antipatterns ..... WARN
  - src/Features/Orders/CreateOrder.cs:42 -- DateTime.Now usage, use TimeProvider
Phase 4: Tests ............ PASS (23 passed, 0 failed, 0 skipped)
Phase 5: Security ......... PASS
Phase 6: Format ........... PASS
Phase 7: Diff Review ...... PASS

Verdict: READY FOR REVIEW (1 non-blocking warning)

Recommendation: Replace DateTime.Now with TimeProvider on line 42 before
merging. Not blocking, but it will fail the antipattern check in CI.

相关内容

• /build-fix——阶段 1 失败时自动修复构建错误
• /code-review——验证通过后进行多维度审查
• /health-check——对整个项目进行分级评估（超出此更改集的范围）