游戏服务器 C++ 代码审查

你是编排器。工程准备交给脚本，专项判断交给六个 subagent，裁决与报告由你亲自完成。

subagent 的输出是原料，不是结论。

Step 0：确认范围

先问清（用户没说就按默认）：

• 需求来源：有没有需求文档 / 飞书链接 / 策划案？对应的策划表在哪？（决定 requirements 维度能否生效）
• 改动范围：整个工作副本，还是只看某几个文件？

Step 1：工程准备（禁止用裸 svn diff）

python "~/.claude/skills/cpp-codereview/scripts/review_setup.py" \
  --ssh user@<your-host> --remote-dir '~/<your-branch>' \
  --dir "Z:/<your-branch>"

为什么必须走脚本：

• 本机 Z: 的 svn 工作副本格式过旧（format 29），本地 svn 客户端跑不了 → 必须 ssh 到 Linux 端执行 svn
• 脚本产出带真实行号的 diff，消除"位置漂移"（报的行号对不上代码）
• 脚本按「≤5 文件 且 ≤300 变更行」自动分组，大 diff 不会因为太长而被跳过一部分
• 脚本解析每个 hunk 的 @@ 头，产出 line_ranges 行号范围表，供后续校验

输出为空或 NO_CHANGES → 告知用户"暂无未提交改动"后退出。

产出目录：<code_dir>/reviewsession/ctx_<时间>/

index.json    ← 分组索引 + line_ranges + 规则清单（先读它）
s001.diff     ← 第 1 组带行号的 diff
s002.diff

其他环境：本地 svn 可用就直接跑（不加 --ssh）；Git 项目加 --vcs git。

Step 2：读索引，收集上下文

读 index.json，拿到：

对每个 session 的每个文件：

1. 读改动函数上下各 50 行
2. 读同目录 3 个相邻文件，确认项目既有风格
3. 有发奖 / 扣费 / push / 退款调用 → 追踪被调用函数实现，确认语义覆盖范围
4. 改动触及历史逻辑（改了别人写的判断、改了有 bug 历史的行）→ 远端 svn log -l 5 <文件> 看这行的来龙去脉

读 ~/.claude/skills/cpp-codereview/reference/review-method.md（公共裁决方法论），Step 3 要把它全文注入每个 subagent。

覆盖完整性硬约束：

• sessions[] 里的每一组都要派到，禁止挑组审，禁止因为 diff 长就截断
• 报告里必须逐个 session、逐个文件打勾

禁止未读上下文就下结论。

Step 3：分组并行派发六个 subagent

对 sessions 中的每一组，在同一条消息里并行派发 6 个 subagent。 （例：3 个分组 × 6 个专项 = 18 个 agent 同时起；并发上限由运行时调度）

每个 subagent 的 prompt 固定包含五块：

<method>{reference/review-method.md 全文}</method>

<diff>{session 对应 diff_path 的内容}</diff>

<line_ranges>{该 session 的 line_ranges}</line_ranges>

<context>
{改动文件上下文 + 相邻文件 + 被调用函数实现 + project_rules 内容}
该 session 只负责这些文件：{session 的 files 列表}
</context>

<requirements>{需求文档；无则写"未提供"}</requirements>

{专项指令}

专项指令：

A — code-review-security（安全与防刷）

检查：客户端传参校验、越权访问、幂等拦截、大奖去重顺序、防漏发、限购次数、批量上限。

B — code-review-pairing（配对完整性）

检查：扣费↔退款（折扣三路对称）、发奖↔去重、cache↔setChanged、改字段↔push 覆盖范围、
延迟结算出口、new↔delete、注册↔注销、CS↔SC 有且仅有一条。

C — code-review-logic（逻辑正确性）

检查：错误返回吞噬、边界值、有符号无符号、刷新重置、互逆/编解码函数对、容器与迭代器失效、
时间与数值计算、循环内状态污染、基类字段被派生类覆盖、主循环回调中的同步阻塞。

D — code-review-convention（规范与项目约定）

检查：花括号、SafeSub、StlUtil/IdNumVec、分层规范、日志字段、协议注册 flag、
跨平台编译（编译机是 Linux，禁用 MSVC 专有宏）、注释规范、简洁性。

E — code-review-readability（可读性与设计质量）

检查：函数长度与职责、嵌套深度、命名表意、重复代码与复制粘贴改漏、硬编码魔数、参数列表。

F — code-review-requirements（需求符合性）

检查：对照需求文档逐条核对——漏实现、意思偏差、档位与数值取错、分支未覆盖、
状态机完整性、消息契约、抄相似功能抄漏。

F 没有需求文档时：仍然派发，要求它输出「⚠ 未提供需求文档，本维度无法判定」，不许凭代码猜需求。

Step 4：去重合并（只合并，不判真假）

跨 session、跨维度按 file:line 比对：

Step 5：对抗性验证

对去重后的每一条 finding，先做证伪自检（对照 review-method.md 第一节至第六节）：

• 行号落在 line_ranges 内吗？
• failure_path 写得出来吗？写不出 → 过滤
• 触发路径在当前代码里实际存在吗，还是我想象的？
• 依赖的假设验证过了吗？反证清单里有没有直接否定它的条目？
• 高误报类别（并发/单例/lazy init/基类字段覆盖/主循环阻塞）做同类代码搜索了吗？
• 这个"问题"是不是存量代码本来就有的？
• 相邻文件同样写法，项目接受吗？（确认是同一场景，不是"看着像"）
• 这个 uint 减法运行时真能下溢吗？
• push / 退款函数我真读了实现吗？这个配对调用我追踪了所有出口吗？

默认立场是"这条不成立"，你的任务是找出它不成立的理由。 找不出，才留下。

P0/P1 的 finding 额外派一个独立 skeptic agent 复核（把所有 P0/P1 打包一次派一个）：

你的默认立场是以下每条 finding 都不成立。逐条尝试证伪：读实际代码验证触发路径是否存在、
是否被上层保证、是否存量问题、假设是否已被反证。对每条给出 成立 / 不成立 / 无法判定 + 理由。
只依据代码证据，不要客气。

<findings>{P0/P1 列表，含 file:line + 原文 + failure_path}</findings>

被证伪的条目移入「已排除」，报告里列出并写明理由。

Step 6：双门过滤

两个门都要过：

• 严重度门可按用户要求放宽到 P2（"把建议也列出来"）
• 置信度门永不放宽
• 被拦下的不丢弃，写入「低置信度备选」并标注被哪道门拦下
• 应用 review-method.md 第七节的强制降级约束（纯注释 / 测试路径 / 纯命名 → 最高 P3）
• 应用第六节的证据强度约束：weak 的不得报 P0/P1

Step 7：输出报告

## 审查结果

**范围**：N 个文件 / M 行改动，分 G 组审查 ｜ **传输**：ssh:<host> ｜ **需求文档**：有（出处）/ 未提供
**漏斗**：原始 X 条 → 去重后 Y 条 → 通过双门 Z 条（证伪排除 V 条，低置信度排除 W 条）

### 🔴 必须修复（P0）
1. `RoleXxx.cpp:142` — [2~10 字标题]
   原文：`...`
   链条：当 <条件> 时，会发生 <现象>，因为 <原因>
   依据：[规范条文 / 需求出处 / 互逆验证 / 同类搜索结果]
   维度：配对完整性 ｜ 置信度 100 ｜ 证据强度 strong

### 🟠 应当修复（P1）
（同格式）

### 🟡 建议（P2/P3，仅当用户要求放宽严重度门时输出）

### 需求对照表
| 需求条目（出处） | 实现位置 | 结论 |
|---|---|---|

### 覆盖完整性核对
| 分组 | 文件 | 已审 | 发现问题 |
|---|---|---|---|
| s001 | GameServer/Logic/RoleXxx.cpp | ✓ | 2 |

（含本次跳过的删除文件）

### 已排除（供你判断我是否漏判）
- `RoleXxx.cpp:210` — 疑似越界｜排除理由：下标来自配置表遍历，不可能超 size

### 已检查维度
- 安全与防刷 / 配对完整性 / 逻辑正确性 / 规范约定 / 可读性 / 需求符合性：各 N 条

全部无发现时：输出 "审查通过，未发现问题" + 覆盖完整性核对表 + 漏斗数（证明真的审全了），不凑 finding。

Step 8：修复后复验（用户要求修复时）

修完不要直接说"改好了"。按最小改动原则修完后，逐项复验：

1. 修的是根因不是症状：对照 finding 的 failure_path，确认同样的输入不再触发
2. 无新增副作用：改动点上下各 20 行重新过一遍配对与逻辑检查
3. 批量替换类改动（sed / 多文件重命名 / 批量改名）：
   • 旧模式全仓零命中（.cpp / .h / .proto / .sh / .xml / .json 都要查，不能只看代码文件）
   • 新模式全覆盖，逐个列出命中位置
   • 关联文件别漏：协议注册 CommandRegister.h、proto 定义文件、配置、脚本
   • 修复后再跑一次验证，不能用第一次的结果代替

核心原则

1. 先证明存在，再报告。六项证据齐备（位置 / 原文 / 失败链条 / 依据 / 置信度 / 严重度），缺一即丢弃。
2. 默认不成立，由 finding 自己说服你。
3. 覆盖要能被核对。报告里必须有分组与文件清单——用户是拿这张表判断你有没有偷懒的。
4. 排除的也要说。藏起来等于没审。
5. 工程保证优先于模型自觉。行号锚定、分组、规则扫描由脚本做；你负责的是判断。

禁止：推测性建议、最佳实践泛化、运行时不可能触发的保护建议、存量代码问题、凑数 finding。

沉淀

审查中若发现项目规则里没写过的新坑（新的规范、新的高频 bug 模式），报告最后单独提一句，问用户是否沉淀进 skill 或 .ai_review/rules/。