Fresh-Eyes Review 是一个用于代码提交前最终质量把关的技能，其核心原则是“没有经过新鲜眼光审查，就不允许提交”。它定位在实现完成、测试通过、同行评审之后，作为最后一道质量门禁，即使没有被显式激活，也应当普遍遵守这一纪律。
用途
该技能用于在 git commit、push、创建 PR 或宣布工作完成之前，对本次改动的文件进行一次刻意、带有心理距离的重新阅读。它与测试和代码评审有本质区别：测试验证的是预期行为，无法覆盖未知边界情况；代码评审关注模式和质量，评审者往往信任作者的意图；而新鲜眼光审查则通过重新阅读，捕捉那些“你以为正确”的地方。资料特别指出，100% 测试覆盖率和全部通过的场景，仍可能与等待被发现的关键缺陷共存。
主要能力
该技能提供一套分步骤的检查清单，覆盖四个维度：
-
安全漏洞检查：包括 SQL 注入（数据库查询必须使用参数化语句，禁止字符串拼接）、XSS（用户内容在渲染到 HTML 前必须转义）、路径遍历（文件路径需验证，拒绝或规范化 ../ 序列）、命令注入（Shell 命令不得包含未净化的用户输入）、IDOR（资源需有访问控制，不能仅靠不可猜测的 ID）、认证绕过（每个受保护端点都检查认证和授权）。
-
逻辑错误检查：包括差一错误（数组索引、循环边界、分页限制）、竞态条件（共享状态的并发访问、异步操作）、空值/未定义（每个 . 链都可能抛出异常，是否有防御性检查）、类型强制转换（== 与 ===、隐式转换）、状态突变（输入参数是否有意外副作用）、错误吞没（空 catch 块、被忽略的 promise 拒绝）。
-
业务规则检查：包括计算（公式是否与需求完全一致、货币舍入是否正确）、条件（AND 与 OR 逻辑是否正确、否定是否正确应用）、边界情况（空输入、单项、最大值、零值）、错误消息（是否用户友好、是否泄露敏感信息）、默认值（可选字段省略时是否有合理默认值）。
-
性能检查：包括 N+1 查询（循环中的数据库调用应批量处理）、无界循环（最大迭代次数、超时保护）、内存泄漏（事件监听器移除、流关闭、引用清理）、缺失索引（查询过滤/排序是否使用索引列）、大负载（是否实现分页、响应大小是否受限）。
使用方式
该技能要求按固定流程执行：
第一步，宣布承诺。明确声明：“开始对 [N] 个文件进行新鲜眼光审查，预计耗时 2-5 分钟。”这一声明建立责任感，并将心态从实现切换到审计。
第二步至第五步，依次执行安全漏洞、逻辑错误、业务规则和性能四份检查清单，逐项核对所有改动文件。
第六步，立即修复。在宣布完成前处理发现的问题：进行修复、为问题添加测试（如果尚未存在）、重新运行完整测试套件、重新运行 linter/类型检查器。
第七步，宣布结果。必须声明：“新鲜眼光审查完成。发现并修复了 [N] 个问题：- [每个问题及修复的简要描述]”。即使零发现也要包含此声明，以证明执行过。
时间承诺方面：1-3 个文件约 2 分钟，4-10 个文件约 3-4 分钟，10 个以上文件最多 5 分钟。警告信号：快于 2 分钟说明深度不足；超过 5 分钟说明范围蔓延，应专注于改动的代码。
适用场景
适用于任何代码提交前的最终检查，尤其是涉及认证、数据库查询、用户输入处理、分页、计算逻辑等容易引入安全或逻辑缺陷的改动。资料中给出了一个示例工作流：用户表示“认证功能实现完了，我来提交”，助手触发该技能，对 4 个文件进行审查，在 auth.ts 中发现邮箱字段缺少输入验证并修复，在 handler.ts 中发现分页差一错误并修复，db.ts 和 api.ts 未发现问题，重跑测试全部通过，最终宣布发现并修复了 2 个问题。
限制
该技能要求拒绝以下合理化借口：“测试很全面”（测试验证设计，不验证正确性）、“我很确定是对的”（信心与缺陷呈负相关）、“搭档在等”（现在 3 分钟省下之后 3 小时调试）、“生产被阻塞”（匆忙会导致正在急于修复的故障）、“资深开发已经批准”（他们评审的是意图，不是实现细节）、“只是个小改动”（小改动导致大故障）。资料强调，这些情况恰恰是关键缺陷逃逸到生产环境的时机。该技能不替代测试和代码评审，而是作为它们之后的补充关卡。