一家社区仓储合作社准备合入「批量导出领货清单」的改动。作者已经跑过普通导出，但审阅者需要回答四件事：本地差异究竟包含什么，远程 PR 是否还是同一版本，导出权限有没有扩大，以及这段实现以后是否容易维护。下面用两家虚构仓库、几条合成领货记录演练从 Diff 到 PR 的审查，最后交付能定位、复验和处理的发现记录。
审查任务卡先固定对象和业务规则
写明仓库、基础分支、待审提交、语言和框架，再说明改动要解决的业务问题。此例规定普通管理员只能导出自己仓库的记录，平台维护者可按批准范围处理多仓数据，导出文件按既有字段契约供排班工具读取。先由业务负责人确认角色和字段规则，记录正常账号与受限账号的预期行为。测试只使用合成数据和隔离环境，不把真实清单附到审查材料。
审阅者开始前检查工作区里哪些文件已暂存、哪些未暂存、是否有未跟踪文件。把作者请求审查的范围与实际状态对齐。只看暂存差异可能漏掉刚写的新测试；把全部工作区差异当成 PR 又可能混入别人的实验。为每份差异保留基础版本和目标版本，后续发现必须能回到同一份代码。若作者在审查中继续提交，先标明原结论对应哪个版本，再决定哪些部分需要复查。
让助手先列阅读计划和缺失信息。它需要变更说明、差异、相关调用方、数据与权限契约、现有测试入口。无法取得远程 PR 时，可以先审本地的确定版本，并标明远程状态未核对。不要让一个没有权限读取的链接被默认为已审。审查报告区分已读、未覆盖和待验证范围，避免用「没有发现问题」概括没读到的代码。
本地 Diff：沿改动追到实际行为
先按行为划分差异，而不是按文件大小分工。导出入口涉及请求参数与鉴权，查询层决定记录范围，序列化层决定输出字段，页面按钮决定谁能看到操作。对每个改动找调用方与返回值去向，阅读相邻的错误处理和旧测试。若新参数允许传仓库编号，追踪它是否覆盖了会话中的仓库范围。只看新增行可能看不到沿用的辅助函数会怎样解释参数。
做一份行集对照。甲仓有两条待领记录，乙仓有一条；甲仓管理员正常导出应只得到甲仓两条。改变请求里的仓库参数，观察服务是否仍按账号范围过滤。助手可以先提出测试和预期，再由有环境权限的维护者执行。记录具体请求编号、角色、输入与返回的匿名记录编号。若旧版已存在相同问题，要说明这是已有缺陷还是本次变更引入、扩大或暴露的风险。
检查删除与移动同样重要。代码移到公共函数后，确认所有调用方对缺省仓库、空结果与失败返回的理解一致。纯格式化差异可以在阅读时折叠，但不能因此忽略真实删除。生成文件若必须提交，核对生成来源和命令，避免审查者逐行评价无法手动维护的产物。遇到巨大混合差异，请作者给行为分组和明确边界，再逐组覆盖，记录暂未完成部分。
本地自检的产物是一份有限报告。每项写文件和位置、具体触发条件、观察到的结果、预期规则以及影响。比如「普通管理员可把请求参数改成乙仓编号，查询覆盖会话范围后返回乙仓记录」比「权限需要加强」更便于判断。没有实际执行时写出源码推断与建议验证，不将推测包装成已复现。代码风格建议与会导致错误结果的问题分别说明处理优先级。
远程 PR：核对版本、检查状态与评论落点
打开 PR 后确认仓库、目标分支和头提交，并与本地审查记录对照。阅读作者描述中的业务触发、变更后行为和验证说明，再查看关联讨论中是否已有确认过的限制。流水线绿灯只说明所配置检查在该提交上的结果，需要知道实际运行了哪些任务、哪些被跳过。头提交更新后，旧检查和旧发现不能自动代表当前状态。
为每个发现定位到当前差异里仍存在的位置。若代码已移动，重新打开相关文件和调用链，确认触发条件仍成立。重复发现合并成一项，给影响路径与最小复现。不要只因为评论标为已解决就认为代码修好；反过来，位置失效也不一定代表问题仍然存在。用当前版本复跑关键样本，并把结果更新到报告中。
评论草稿围绕问题写清条件与后果。例如导出权限问题说明哪个角色、哪个参数和哪类记录受影响，再提出保持账号范围约束的修复方向。避免把未经核实的安全推断写成确定事故。维护性建议说明后续改动会怎样困难，并区分必须处理和可选改进。若需要在 GitHub 公开评论，先确认任务确实授权对指定 PR 发言以及工具拥有的权限；只做审查时保留本地草稿即可。
提交最终审查前复核整体状态。对已修复的问题记录对应提交和回归结果，对无法复现的意见保留反例并撤回过时结论，对仍缺业务规则的问题列明决策人。审阅者的批准应遵循项目合入流程。助手给出审查报告、生成评论或看到检查通过，都不等于 PR 已合入，也不能代替代码所有者的决定。
安全与回归：从输入边界走到兼容消费者
导出场景先检查权限是否在服务端执行。隐藏按钮只是界面条件，接口仍需验证账号范围。用未登录、角色不足、同仓和跨仓输入分别对照，确认失败响应没有泄露其他仓库是否存在。查询参数要经过项目已有的安全绑定方式，字段选择与排序不能成为任意查询入口。材料里只保留合成编号和必要字段，不把完整真实导出交给外部分析服务。
接着核对文件字段和消费方。新增字段、空值表示、日期格式、编码和列顺序可能影响现有导入器。准备一份旧版消费方样本，将新导出送入同一解析路径，观察是否产生相同的领货记录。如果业务决定改变契约，要记录迁移版本、保留期和负责人，不能让审查者把破坏性变化当成格式调整。无消费方环境时明确这是未覆盖边界，并给出补测材料。
对批量导出再检查记录上限、分页、超时和重复请求。合成数据跨过一页边界，断言总行集无遗漏与重复；取消或失败时核对任务状态是否明确。并发更新可能让文件跨时间点读取，先确认业务需要固定快照还是接受某种一致性范围，再设计测试。性能意见要说明输入规模和观测条件，不能因循环出现在差异中就断定它导致生产故障。
质量与长期维护：让下一次修改可预测
阅读实现是否把角色范围、查询和输出格式分在清楚的责任边界。一个函数若同时读取账号、拼查询和写文件，检查错误路径是否可以独立验证。重复代码是否确实代表同一业务规则，需要通过调用方确认。抽公共函数也会增加耦合，审查建议应解释当前问题与收益，不要求为想象中的未来需求添加层次。
审查测试是否检测了本次风险。只断言文件存在，抓不住跨仓记录；只断言返回成功，抓不住旧消费方无法解析。让测试包含明确行集、字段契约和失败角色，并证明关键回归在错误实现上会失败。对不稳定的时间或异步等待，使用项目支持的可控条件与明确终止状态。文档应解释接口和操作前提，注释说明容易丢失的业务原因，避免把代码逐句翻译成注释。
若导出按钮或结果页面也有变化，可在修复后的界面回归使用 Webapp Testing。已核对条目支持 Python 与 Playwright 操作运行中的本地应用并保留脚本、截图和日志。给它练习站启动方式、合成账号和预期按钮状态，先观察渲染页面再操作。它只负责选定页面场景，服务端权限、文件兼容和并发仍由对应检查覆盖。准备浏览器依赖并核对目标与数据范围。
技能选择与一次完整实操
根据对象选择方法：本地差异审阅需要明确基础版本，远程 PR 方法需要当前提交与读取权限，风险检查需要业务边界与失败样本，质量检查需要调用方和现有约定。当前未能在 SkillPI 公开目录核实用途匹配的专用代码审查条目，因此这里不把原来源的九个名字替换成猜测的链接。上面的浏览器技能仅用于页面复验。核心代码审阅可先用现有工具按本文任务卡执行，并记录能力缺口。
需要发现候选时先检查是否已有 SkillPI Skill Finder。没有时阅读官方仓库说明，按宿主支持方式安装启用。让它针对语言、差异对象、权限和产物收集候选，再打开真实包核对来源、版本、脚本和依赖。对无法查看的来源、仅含合集介绍或不支持当前环境的候选，明确拒绝理由。技能增加后用相同的甲乙仓样本对照试用，通过再更新关联。
完整演练从保存基础与头提交开始，先做本地行集和权限对照，再核对远程 PR 版本与检查状态。作者修复范围覆盖后，重复跨仓失败样本、正常导出和旧消费方解析；页面变化另做浏览器复验。最终报告把发现分成已证实、待验证与已修复，逐项给位置、触发、后果和复跑方式。交给另一位开发者，仅凭报告应能判断哪些结论支持合入、哪些还需要业务或环境信息。
常见问题
只给 Diff，能做完整审查吗？
可以先检查明确差异，但权限、兼容和调用行为通常需要上下文。列出缺少的契约和调用方，先交付已覆盖范围，不把有限阅读宣称为完整仓库验收。
报告没有发现，是否就可以合入？
先看实际读了什么、哪些检查运行、当前头提交是否一致。没有发现可能说明这次有限范围未观察到问题；合入仍按业务规则、测试和项目审批完成。
审查意见太多，先处理什么？
优先复核能造成错误数据、越权或兼容破坏的具体发现，再处理维护成本与风格。每项说明触发和影响，合并重复项。没有证据的意见留待验证，不按数量评价审阅质量。
Skill 会自动修改或发布评论吗？
取决于具体包、宿主工具与任务授权。使用前读清动作和权限，审查任务可以只输出本地报告。建议、代码修改、远程评论和合入是不同结果，分别核对。
找不到当前语言的专用技能怎么办？
保留语言、框架、测试入口和风险任务卡，先用已有检索与运行工具完成可验证部分。新的候选出现后用同一小样比较，不把无法核实的名字写入关联。