code-reviewlisted

# 代码审查 审查目标是发现真正会影响结果的问题，不是重新设计代码，也不是输出一份通用 Clean Code 建议清单。 ## 审查范围 默认从当前 `git diff` 和本次会话实际修改范围开始；用户指定文件、提交或模块时按用户范围审查。 先读取适用于目标文件的 `AGENTS.md`、正式 PRD / 规范和必要的项目上下文。涉及同类实现是否一致时，按 `.agents/skills/code-consistency/SKILL.md` 比较当前项目先例。 不要把本次改动之外的历史问题混入结果。发现无关旧问题可以忽略；只有它被本次改动直接放大或触发时才报告。 ## 重点检查 ### 1. 业务与逻辑正确性 - 条件、分支、循环、停��条件、状态更新是否与需求一致。 - 是否漏处理本次需求明确覆盖的场景。 - 是否改变原有业务口径、执行顺序、返回值或副作用。 - 边界值、空结果、重复数据等是否会在当前真实业务中产生错误结果。 ### 2. 项目规则与实现一致性 - 是否违反当前项目 `AGENTS.md`、PRD 或用户已确认规则。 - 同类问题已有成熟实现时，是否无理由改用了另一套 API、控制流、异常或日志方式。 - 是否为一个小改动引入无必要的新抽象、封装层或长期状态。 ### 3. xbot / 外部能力 - 不根据通用 Python、Selenium、Playwright 经验猜 xbot API。 - 当前项目已有相同用法时以项目成熟实现为先；现有用法存在疑问、冲突或本次新增 / 改变 API 时，再按项目 `AGENTS.md` 路由到知识库事实页核验。 - 检查 XPath、字段、请求响应结构、页面状态或 Profile 等是否被本次改动错误假设。 ### 4. 异常与失败语义 - 是否吞掉异常后继续把业务当作成功。 - fallback、默认值或空值是否把技术失败伪装成正常业务数据。 - 是否错误扩大 `try/except` 范围，吃掉不应捕获的失败。 - 补充业务上下文时是否仍保留原始异常链。 - 收尾、重试和日志是否会覆盖真正的主异常或误报最终结果。 ### 5. 实际副作用 - 是否重复提交、重复点击、重复写回、重复通知或漏执行必要动作。 - 是否因执行顺序变化导致页面、文件、数据库或外部状态与原行为不同。 - 是否修改了用户没有要求变化的接口、配置、持久化格式或长期业务规则。 ## 过滤低价值问题 不要报告： - 纯个人审美、可改可不改的写法。 - “另一种实现也不错”但当前代码没有问题的建议。 - 仅为了 DRY、SOLID、函数更短、抽象更多而提出的重构。 - 格式化、拼写或普通 lint 能直接处理且不影响当前任务的问题。 - 与本次改动无关的既有问题。 - 缺乏实际证据、只是��论上可能发生的低概率问题。 对每个候选问题先判断置信度。只有确定度高、影响明确的问题才输出；可以沿用 0-100 的判断方式，默认只报告 `>= 80` 的问题。 ## 输出要求 每个问题至少说明： - 严重程度与置信度。 - 文件和具体位置。 - 为什么这是实际问题，而不是偏好差异。 - 会造成什么业务或运行影响。 - 最小修复方向。 优先按 `P0 / P1 / P2` 或“严重 / 重要”排序。没有高置信问题时，直接说明未发现需要修改的问题，不为了让 Review 看起来有产出而硬找问题。 代码审查默认只给结论和修复建议；只有用户明确要求修复，或当前任务本身包含“审查并修复”时