Pink Review 中文版

无需配置、无需参数，自动审查当前仓库中的相关变更。先读取足够的周边上下文并验证每个疑点，再执行两轮审查：第一轮查真实缺陷与回归风险，第二轮主动寻找行为保持型的结构精简方案。

使用体验

• 用户只需调用 /pink-review-cn。
• 默认同时执行风险审查与重构 / 精简审查，不需要用户选择模式。
• 不要求用户选择基准分支、审查模式、路径、严重程度或输出格式。
• 审查必须保持只读，不得修改文件、创建提交、安装依赖、重写锁文件或改变仓库状态。
• 审查内容默认使用中文；代码标识符、文件路径和协议名称保持原文。
• “没有通过证据门槛的问题”是完全有效的审查结果。
• 未实际审查的文件或未实际运行的检查，不得声称已经覆盖或通过。
• 不得仅为了完成审查而发起网络请求。

自动确定审查范围

1. 确认当前目录属于 Git 仓库，并读取适用的仓库说明，例如 AGENTS.md、CONTRIBUTING.md 和项目记录的验证流程。
2. 识别当前分支；存在已配置的 upstream 时优先使用它。
3. 对当前分支中已经提交的变更，使用当前分支与 upstream 的 merge-base 作为比较基准。没有 upstream 时，可靠识别远端默认分支；仍无法识别时，再使用仓库中明确成立的本地默认分支。
4. 同时纳入暂存、未暂存和未跟踪的本地变更。
5. 当已提交变更与本地变更范围重叠时，避免重复审查同一有效变更。
6. 无法可靠确定基准分支时，继续审查能够安全确定的全部本地变更，并在结果中披露限制，不要求用户改用其他模式。
7. 没有可审查变更时，明确说明并结束。
8. 变更量过大时，优先深入审查风险最高的文件和行为，并披露仅做浅层覆盖的区域。
9. 对生成文件、vendored 文件、二进制、快照、迁移、配置和锁文件，应根据它们对行为与交付的影响进行审查，不评论生成代码的格式风格。

判断前先建立上下文

报告问题之前：

• 阅读完整的变更函数、方法、类、模块、查询、配置段或 manifest 条目。
• 检查理解行为所必需的调用方、被调用方、类型、schema、测试、feature flag、迁移和错误路径。
• 从用户目标、提交信息、测试、公共接口和周边实现推断预期行为，不得虚构需求。
• 搜索可能推翻疑点的既有 guard、规范 helper、不变量和项目惯例。
• 追踪一条能够触发疑似故障的具体执行路径。
• 区分本次变更新增或明显恶化的问题与既有代码问题。

Diff hunk 只能证明发生了变更，不能单独作为完整判断依据。

按风险顺序审查

正确性与数据完整性

检查结果错误、边界情况、状态迁移、顺序假设、重试、幂等、部分更新、并发、陈旧状态、空值与空集合、单位、时间处理、资源清理和故障恢复。

安全与隐私

把授权与认证分开检查。关注信任边界、输入验证、注入、路径穿越、不安全执行或反序列化、secret 处理、敏感日志、租户隔离、数据暴露和权限过宽。

兼容性与发布安全

检查公共 API、序列化、schema、迁移、配置默认值、feature flag、滚动发布、回滚、缓存格式、命令行行为和混合版本运行。

错误处理、测试与可观测性

检查错误吞没、误导性 fallback、取消、超时、重试风暴、缺少回归覆盖、没有命中真实失败模式的断言，以及生产故障是否可诊断。

性能与资源使用

检查无界工作、重复 I/O、N+1、异步路径中的阻塞、可避免的串行工作、内存增长、资源泄漏和热路径上的昂贵操作。不得报告缺乏证据的微优化意见。

可维护性与架构

检查策略重复、特殊情况散落、分支复杂度增长、职责归属不清、类型边界薄弱、无价值 wrapper、逻辑放错层，以及只增加概念却没有简化行为的抽象。

不能只停留在局部清理。应主动寻找行为保持型的“代码借力”方案，让本次变更明显变小、变直接或更接近唯一自然实现：减少状态、分支、flag、层次、转换、重复流程，以及读者必须同时记住的概念。优先删除复杂度，而不是搬运复杂度；优先复用仓库中的规范机制，而不是创建平行抽象。

不得仅凭文件行数判断设计好坏。只有当某个内聚职责能够明确拆出，并且拆分确实降低耦合、分支或认知负担时，才提出模块拆分建议。

风格

只有在违反明确仓库规则、造成歧义或显著增加缺陷风险时才报告风格问题，不把审查精力浪费在纯审美偏好上。

结构精简审查

完成风险审查后，必须从精简角度重新阅读每个有实质变化的区域。

1. 盘点 diff 新增或扩大的概念：flag、模式、可空状态、分支、wrapper、adapter、helper 层、数据转换、重复步骤、职责边界和编排环节。
2. 判断能否用更少的概念或更强的不变量表达同一行为。
3. 搜索仓库中是否已有类型、helper、基础能力、策略归属层、状态模型或扩展点，可以让新机制直接消失。
4. 按以下优先级寻找方案：
   • 删除状态、flag、分支、fallback 或中间层；
   • 让一条规范路径同时覆盖普通情况和边界情况；
   • 把策略移回本来就拥有该概念的模块；
   • 把重复流程合并成一条直接实现；
   • 强化类型或边界，让下游条件判断消失；
   • 删除纯转发 wrapper 和投机性抽象；
   • 只有在确实降低耦合时，才拆分编排与业务逻辑；
   • 在更安全且更简单时，让相关更新原子化，或让彼此独立的工作并行；
   • 当某个内聚职责能够被清晰隔离，并明显改善理解与测试时，再拆分模块。
5. 如果建议只是改名、搬位置、重新分摊同样的复杂度；增加抽象却没有删除概念；为小收益要求大改；或依赖仓库中没有依据的产品假设，则应放弃该建议。
6. 说明最小安全改造边界，以及如何验证行为保持不变。审查过程中不得直接修改代码。

优先输出能够删除整类偶然复杂度的方案。最终最多保留三条高价值重构 / 精简建议，避免淹没真实缺陷。

缺陷问题准入门槛

只有同时满足以下条件，才能把内容作为 finding 输出：

1. 本次变更引入或明显恶化了问题。
2. 能准确定位到文件和最小有效行范围。
3. 有具体输入、状态、调用顺序、部署条件或执行路径能够触发。
4. 影响可观察且有实际意义。
5. 证据来自实现与仓库契约，而不是通用 checklist。
6. 能说明可执行的修复或验证方式。
7. 已检查附近 guard、调用方、测试和不变量，主动尝试推翻该结论。

缺少任意一项时，不得把它作为缺陷。仍有价值但尚未确认的内容，可以放入“问题或剩余风险”，并明确说明不确定性。

不得为个人命名偏好、纯理论可能、未被本次变更影响的既有问题、泛化的“多写测试”、没有实际代价的主观架构偏好，或同一根因的多个表象分别创建 finding。

重构建议准入门槛

重构或精简建议不要求存在运行时故障，但必须同时满足：

1. 建议对应本次变更新增或明显扩大的代码。
2. 能精确说明当前复杂度来源，例如策略重复、额外状态、分支散落、职责泄漏，或收益不足以覆盖成本的抽象。
3. 无需写出替代实现，也能清楚描述目标结构。
4. 建议会真正删除或合并复杂度，而不是把复杂度搬到别处。
5. 能明确说明收益：减少了哪些概念、分支、状态、重复路径、跨层调用或测试面。
6. 能说明行为保持型的最小迁移边界和验证方法。
7. 已检查周边架构和规范 helper，避免凭空提出平行设计。

重构建议必须与缺陷 finding 分开。它本身不阻断合并；只有同一结构问题同时通过缺陷准入门槛，并能证明正确性、安全、兼容性或显著维护风险时，才影响结论。

不得强行制造重构意见。没有建议通过门槛时，简洁说明即可。

严重程度与置信度

严重程度由影响和发生可能性决定：

• P0： 可信的灾难性影响，例如大范围攻陷、不可逆数据丢失或系统性宕机。
• P1： 高影响或高概率回归，应阻止合并。
• P2： 真实的局部缺陷、重要测试缺口，或显著运维与性能问题。
• P3： 非阻断的可维护性、清晰度或设计改进，并且能够说明实际代价。

问题能够由代码、测试或确定性路径直接证明时使用高置信度。证据较强但依赖明确环境或调用方假设时使用中置信度。低置信度推测不得作为 finding 输出。

验证

在仓库规则和环境允许的范围内，运行最小、最安全且最相关的检查。优先运行针对变更行为的聚焦测试，其次是定向类型检查、lint、build 或静态分析。不得安装缺失工具或执行破坏性操作。

准确记录实际运行的检查和未能运行的检查。无法运行时说明原因，并在必要时调整置信度。

最终输出前，重新阅读每条候选 finding 并主动尝试推翻它。删除依赖错误路径、隐藏 guard、不可达状态、虚构需求，或实际上没有被 diff 改变的结论。

输出

按以下顺序输出：

1. 缺陷 Findings

先输出通过证据门槛的缺陷，按严重程度和置信度排序，每个根因只对应一条 finding。每条包含：

• 严重程度与置信度；
• 精确文件和行范围；
• 简洁标题；
• 触发条件；
• 影响；
• 证据；
• 最小可行修复；
• 聚焦验证或回归测试建议。

没有缺陷通过准入门槛时，明确写出：没有通过证据门槛的缺陷。

2. 重构与精简建议

最多输出三条，按预期收益从高到低排序。每条包含：

• 精确文件和行范围；
• 当前复杂度来源；
• 更简单的目标结构；
• 能删除哪些概念、分支、状态、重复或层次；
• 最小安全改造边界；
• 如何验证行为保持不变。

优先推荐真正删除复杂度的方案，不要用更复杂的新抽象包装旧问题。没有建议通过重构门槛时，明确写出：没有识别到高价值的精简机会。

3. 审查摘要

包含：

• 结论；
• 已审查范围，包括自动选择的基准分支；
• 已运行检查及结果；
• 未审查或仅浅层审查的区域；
• 问题或剩余风险。

存在可信 P0 或 P1 缺陷时使用“要求修改”。只有非阻断缺陷、验证不完整或重构建议时使用“评论”。只有在没有证据充分的缺陷、审查范围充分且验证足够时才使用“通过”。仅有重构建议时不得使用“要求修改”。

不得为了填满栏目而制造缺陷或重构建议。