AI 辅助 C# 代码审查与重构（V10）

内容类型：Review / 重构方法难度：进阶适合：需要审查 Agent Diff、控制重构边界的 C# 上位机工程师阅读时间：约 10 分钟

Review 先回答：有没有超出任务边界？有没有改变用户没要求改变的行为？证据能不能支持它声称已经完成？ 最后才讨论代码是否漂亮。

1. 先看 Task Contract，再看代码风格

目标 / NonGoals
→ Git Diff
→ 行为语义变化
→ 风险边界
→ 验证证据
→ 代码质量

不要先花大量时间讨论命名和抽象，却漏掉一个“AlarmOnly 被实现成 Stop”。

2. 第一轮：找计划外改动

优先检查：

• 是否修改任务之外的文件；
• 是否顺手重构公共代码；
• 是否改 .csproj、依赖、部署脚本；
• 是否改变协议、数据库、序列化格式；
• 是否修改真实设备输出动作；
• 是否把 ExperimentalChange 写进正式业务规则；
• 是否出现大规模格式化噪声。

MicroPatch 的 Diff 如果扩到很多业务文件，应先解释为什么，而不是默认接受。

3. 第二轮：检查 Behavior Delta

对于行为修改，用六项对照：

Trigger
Condition
Action
Reset
Record
NonGoals

特别检查：

• “报警”后有没有意外 Stop；
• 连续 N 次逻辑是否正确 Reset；
• 一次窗口是否重复触发；
• 故障恢复后状态是否明确；
• 日志是否记录正确层级值和单位；
• UI 状态是否和后端真实动作一致。

详见 行为与告警语义。

4. 第三轮：C# 通用风险

维度	重点
Null	nullable、外部输入、未初始化状态
async	async void、未 await、取消、同步阻塞
生命周期	SerialPort、Socket、Timer、事件订阅、FileStream、Session owner
UI 线程	Dispatcher / Invoke / 高频刷新
异常	吞异常、丢堆栈、错误上下文不足
并发	锁顺序、竞态、共享缓存、重复启动
数据	兼容、迁移、旧文件/旧数据库读取
通信	超时、重连、会话状态、请求响应关联；帧边界/CRC 仅在当前协议相关时检查

不要把自定义 TCP 二进制协议的检查表机械套到 SCPI 文本或厂商 SDK。

5. Measurement Review

只要 Diff 涉及测量值，就快速检查：

RawValue
EngineeringValue
Conversion
ThresholdBasis
Aggregation
LoggedUnit

常见问题：变量名单位和实际值不一致、换算重复、阈值层级错误、UI/日志单位不一致、MES 与本地计算路径不同。

详见 测量值语义。

6. Regression Review：根因证据要有时间差异

如果 PR 声称修复“最近回归”，Review 必须问：

known-good 是什么？
当前与 known-good 的行为差异是什么？
修复针对的是哪个新增差异？

如果某段代码旧版本里就完全相同，单凭“看起来不合理”不能证明它是本次 regression cause。

回退到旧基线恢复时也要区分 RolledBackToKnownGood 和 RegressionFixed。

7. 验证证据按 V0–V4 Review

等级	Review 时看什么
V0	Diff/static 是否足够
V1	affected build，必要时 focused test
V2	fake/replay/focused test
V3	workflow/state/interlock smoke
V4	full/release checkpoint

Review 不统一要求 whole solution build + 全部测试，也不能只接受一句“编译通过”。验证必须匹配行为风险。

8. EnvironmentBlocked 和 HardwarePending 分开 Review

EnvironmentBlocked

例如：

• E-SafeNet；
• 缺 SDK；
• 构建权限问题；
• CI 环境缺依赖。

要求把已完成代码证据、环境阻断原因和缺失验证分开写。

HardwarePending

例如：

• 真机不在现场；
• 高压动作未授权；
• 需要客户现场设备/网络；
• 保护链尚未做 HITL。

Review 结果应类似：

AffectedBuild: Verified
FocusedParserTests: Verified
Replay: Verified
EnvironmentBlocked: None
HardwareVerification: HardwarePending

不要把真机未做写成 EnvironmentBlocked，更不能要求 Agent 为了“关掉 Review 缺口”自动操作危险设备。

详见 真实设备操作安全。

9. 性能修改的 Review

性能 PR 额外检查：

Scenario
Baseline
After
CorrectnessEvidence
LongRunDuration

只看到“换成更快的库”“加了缓存”“感觉不卡”不足以接受性能结论。

详见 性能与长稳诊断。

10. 什么时候适合重构

适合：

• 重复代码已反复造成维护成本；
• 长方法职责明显混乱；
• 稳定行为边界已有测试；
• 同一模块是长期 Git hot spot；
• 为当前目标做最小结构修正能明显降低风险。

谨慎：

• 正在查未知 Bug 时同时大改结构；
• 协议、数据库、线程模型没有基线测试；
• 为一个小改建立新框架；
• 用户只要求修复，不要求清理全部历史债务。

11. Architecture Hotspot Review 与普通重构分开

只有用户明确要求“为什么这个模块总返工”“架构是不是有问题”“找长期技术债”时，再做显式架构体检：

Git hot spots
→ repeated change clusters
→ responsibilities / coupling
→ stable seams
→ candidate refactors

不要每次普通 PR 都自动附带一次全仓库架构审查。

12. Review Prompt

$host-computer-dev
请审查当前 Diff。

优先级：
1. 任务范围外修改；
2. Behavior Contract 是否被实现错；
3. 协议/数据库/线程/设备动作变化；
4. Regression 是否有 known-good 证据；
5. Verification Level 和证据是否匹配；
6. EnvironmentBlocked / HardwarePending 是否被误报；
7. 最后再看代码质量和可维护性。

请按严重程度输出问题，不要只总结优点。

13. 一份好的 Review 结果

Blocking
- 必须修复的问题

High
- 高回归风险

Medium
- 应该改进但不阻断

Verification Gaps
- Unverified / EnvironmentBlocked / HardwarePending

No Issue
- 已核对的重要边界

“没有发现问题”也应该说明看过哪些关键边界。

下一步

• AI 辅助测试与回归
• AI 开发验证体系
• Bug / 回归定位
• 真实设备操作安全
• AI Agent 工程化开发

一句话原则

Review 先找行为偏差和证据缺口，再讨论代码是否漂亮；软件环境阻塞和真机待验证必须分开写。