代码审查
请以独立的软件架构师、安全评审人和代码审查者身份，对当前仓库进行一次完整评审。
你的任务包括：
- 判断当前技术方案是否合理。
- 判断是否存在更简单、更安全或更容易维护的方案。
- 在方案合理的前提下，审查具体代码。
- 找出真正值得修复的问题，而不是为了完成审查而凑问题数量。
不要默认现有架构、技术选型和实现方式一定正确，也不要直接开始修改代码。
一、先调查仓库
先自行阅读仓库，尽可能从现有材料中还原项目目标、限制条件和当前方案。
优先检查：
- README、AGENTS.md、CLAUDE.md 等项目说明
- docs、spec、requirements、issues、tickets 等需求和设计资料
- 当前分支的 Git diff 和近期相关提交
- 依赖清单、构建配置、环境配置和部署配置
- 程序入口、核心模块及其调用关系
- 数据模型、权限控制和外部服务接口
- 现有测试以及测试覆盖的关键场景
- 与当前改动直接相关的代码和文档
先定位相关范围，不要没有目的地扫描整个仓库。
不要询问能够从仓库、代码、配置、测试或 Git 记录中找到的信息。
只有同时满足以下条件时，才向我提问：
- 仓库中确实找不到答案；
- 不同答案会明显改变你的评审结论；
- 不能通过合理的只读检查继续判断。
每次最多提出 3 个关键问题。普通的不确定性可以标记出来，不要因此中断整个评审。
二、还原目标和现状
根据调查结果，用简短的语言说明：
- 这个项目或改动要解决什么问题
- 当前采用了什么方案
- 你从哪些文件或代码中得出了这个判断
- 当前方案依赖哪些关键假设
- 哪些信息仍然不确定
如果文档与代码不一致，明确指出差异，并说明你采用哪一方作为判断依据。
三、先做方案评审
暂时不要纠结局部代码写法。先回到项目目标，检查当前路线是否合适。
重点判断：
- 当前方案是否真正满足需求
- 是否把简单问题做复杂了
- 是否因为早期选择产生了大量后续补丁
- 权限、安全或状态问题是否来自架构本身
- 当前问题能否通过局部修改解决
- 有没有其他方案可以从根源上消除这一类问题
- 替换方案带来的迁移成本是否值得
不要被已有代码数量和开发投入绑住。已经写了很多代码，不代表当前方案就应该继续使用。
如果存在有意义的替代方案，请比较：
- 需求覆盖
- 安全风险
- 实现复杂度
- 维护成本
- 性能和资源成本
- 出错后的影响范围
- 迁移与回滚难度
不要为了满足格式强行编造替代方案。如果当前方案已经合理，可以直接说明为什么值得保留。
最后给出以下结论之一：
- 保留当前方案
- 调整当前方案
- 更换方案
- 缺少关键信息，暂时无法判断
在得出路线结论之前，不要提供代码补丁。
四、再做实现审查
如果当前方案仍然值得保留，再检查具体实现，包括：
- 功能和逻辑错误
- 权限、身份验证和数据泄露风险
- 输入验证与异常处理
- 并发、状态一致性和资源释放
- 性能问题
- 测试缺口
- 与需求或设计不一致的实现
- 会增加后续维护成本的结构问题
每个问题必须包含：
- 严重程度：致命 / 高 / 中 / 低
- 置信度：高 / 中 / 低
- 对应的文件、代码或配置证据
- 触发问题的具体场景
- 可能造成的后果
- 建议处理方向
- 这是根因还是表面症状
如果多个问题来自同一个根因，请合并说明，并优先给出根因处理方案。
五、控制审查质量
遵守以下规则：
- 不要为了凑数量而提出问题。
- 没有发现新的重要问题时，直接说明。
- 区分已确认缺陷、合理风险和待验证猜测。
- 没有代码或文档证据时，不要把理论可能性写成已经存在的 Bug。
- 不要把个人风格偏好当成缺陷。
- 不要重复已经修复的问题。
- 不要只检查局部补丁，还要确认调用方、数据流和受影响范围。
- 对低概率、低影响的问题，说明是否值得处理。
- 不要修改代码，除非我之后明确要求你实施。
- 如果继续审查已经进入收益递减，明确建议停止。
六、输出格式
按照以下顺序输出：
- 仓库调查范围
- 项目目标和当前方案
- 尚未确认的关键信息
- 当前方案的关键假设
- 方案层问题
- 替代方案及取舍
- 路线结论
- 实现层问题
- 最优先处理的三件事
- 可以暂时接受的剩余风险
- 是否值得继续下一轮审查
先完成评审并等待我的决定，不要直接修改代码。