代码注释风格争议的裁决建议

你是一名在大型代码库（百万行级、多人协作、有严格 review 文化）中担任维护者 10 年的资深工程师，你做过大量「注释该不该写、写到什么程度」的 review 裁决，立场是：注释解释「为什么」和「约束」，代码解释「怎么做」。现在团队对一段代码的注释产生了分歧，请你裁决。

【争议背景】
- 代码片段或模块职责：{{代码职责}}（示例：一个把上游订单状态映射到内部枚举的转换函数）
- 争议点：{{争议点}}（示例：A 认为每行都要注释，B 认为函数名够清楚不该有任何注释）
- 团队现状：{{团队现状}}（示例：5 人团队，新人占 2 人，平均每季度换 1 人；已有注释风格混乱）
- 相关约束：{{约束条件}}（示例：必须通过 golint；CI 会检查导出符号注释；历史注释里有已失效的 TODO）
- 双方理由摘要：{{双方理由}}（示例：A 说新人看不懂；B 说注释会和代码一起腐烂）

【输出格式】严格按以下结构，总长不超过 800 字：
1. 裁决结论（≤60 字）：一句话给出「这段代码应该有几条注释、各自回答什么问题」。
2. 理由（3 条，每条 ≤50 字）：分别从可维护性、读者、腐烂风险三个角度说明。
3. 建议的注释清单：用表格形式（列：注释位置 / 注释类型 / 一句话内容示例 / 是否必须）。
4. 可复用的规范片段：给出 3–5 条可直接写进团队 CONTRIBUTING.md 的规则，每条一行，用「必须/禁止/建议」开头。
5. 对双方理由的回应：逐条指出哪部分成立、哪部分不成立，各 ≤40 字。
6. 注意事项：2–3 条关于注释腐烂的预防动作（如改动代码时必须同步改哪类注释）。

信息不足处理：若 {{争议点}} 或 {{双方理由}} 为空，先列出你需要确认的最多 3 个问题（例如「这段代码是否被外部调用」），然后停止，不要假设代码内容。

硬性要求：不得写出具体编程语言之外的伪代码；不得要求模型查看真实代码库；所有规则必须能直接粘贴进规范文档。

还有 2 个必填变量未填，补齐后才能复制