peer-pr-review

代码改动第一性审查

目标不是替改动者证明方案正确，也不是为了显得严格而强行找问题。先把自己放在“需求交给我实现”的位置，独立形成一份开发方案，再让这份方案和改动者方案互相补漏、互相证伪。无论审查同事还是自己的代码，都要在有限时间内回答七件事：这块功能负责什么、实际出了什么问题、根因是什么、如果由我开发会怎样解决、改动者怎样解决、两套方案谁遗漏了什么、最终代码是否合理。

默认把读者视为第一次接触该项目的新手。报告主体只保留会影响理解、提交、合并决定或后续验证方式的信息；不要用一串术语和方法名代替解释。具体 Case 走读不设机械字数上限，以读者能沿真实输入、判断、状态变化和下游结果完整听懂为准，但不要重复粘贴同一份图、表和代码。

输入与边界

最低输入是一个可定位的审查对象，例如：

• CodeUp PR 链接；
• 当前仓库的 staged、unstaged 和 untracked 改动；
• 指定 worktree 路径或本地分支；
• 明确的 commit、patch 或比较范围。

需求背景通常应提供，但若当前对话、关联工作项、提交说明或代码能可靠恢复，就先自行整理；无法恢复时仍可做实现质量审查，但要明确“需求符合性未验证”。可选输入包括 OA 需求/缺陷 ID、project ID、Chat ID、环境、复现步骤、日志、改动者判断的根因和修复方案。

缺少可选输入时继续做能完成的静态审查，不把可自行检查的问题反问用户。只有审查对象无法访问、仓库或 worktree 无法定位、比较基线存在多个合理选择，或某个缺失选择会实质改变审查范围时才请求补充。

本 Skill 默认只读：

• 不修改代码、配置、数据库或文档；
• 不在 CodeUp 上评论、通过、关闭或合并 PR；
• 不 commit、push 或部署；
• 数据库只允许 SELECT；日志和配置只读取与当前假设有关的最小范围；
• 不在报告中回显 Token、Cookie、凭据、完整 Prompt 或未脱敏业务数据。

事实获取顺序

按成本从低到高取证，证据足够支撑结论就停止，不为低风险改动制造不成比例的调查。

1. 固定审查对象

先识别审查模式并在报告顶部写明“审查对象、基线、终点和包含范围”：

• CodeUp PR：解析仓库、源分支、目标分支、当前 patch set 和 commit。优先通过已登录页面、只读 OpenAPI 或对应 Git 远端锁定不可变 diff；先只记录范围和需求入口，把 patch hunk、改动者方案、讨论结论和测试结论留到独立方案冻结后再读。
• 当前未提交改动：默认审查 HEAD → 当前工作区。分别读取 git diff --cached、git diff 和 git ls-files --others --exclude-standard；相关 untracked 文件必须读取，不能因普通 git diff 看不到就漏审。生成物、二进制或明确无关文件可以排除，但要在范围中说明。
• worktree 或本地分支：先用 git worktree list、git status、当前分支、HEAD 和远端信息确认实际路径。默认以用户指定目标分支为基线；未指定时只在仓库默认分支明确时使用其最新远端引用，并以 merge-base 为起点，审查 merge-base → HEAD，再叠加该 worktree 的 staged、unstaged 和相关 untracked 改动。基线不唯一时不要擅自选择。
• commit 或 patch：按用户明确给出的不可变范围审查，并记录两端 commit 或 patch 来源。

若 PR 与本地改动同时存在，默认把 PR 作为主审查对象；检查本地分支是否还有未进入 PR 的提交或工作区改动，并单独标为“PR 外本地改动”，不要混入 PR 结论。用户明确要求审查发布前全部内容时，再合并两部分范围。

涉及远端基线或 PR 时，先检查 git status、分支和 worktree，再 git fetch，使用最新远端引用判断；只审查当前工作区相对 HEAD 的未提交内容时不必为了形式强制 fetch。全程不得切换分支、改 index、stash、commit 或清理文件。

记录审查开始时的 HEAD、状态和 diff 范围；交付前重新检查。若用户或其他会话在审查中改变了 HEAD、index 或工作区，重新读取受影响 diff，或者明确报告审查基于哪个快照。无法取得真实 diff 时，不根据标题或描述假装完成代码审查。锁定 diff 不等于提前研究改法；同事 Review 和自审都应尽量避免用目标版本的实现反推“自己本来会怎样设计”。