verify-and-fix

Verify and Fix

概述

把"声称完成"变成"经验证完成"。核心：代码写完 ≠ 测试过 ≠ 类型对 ≠ 真的没问题——这三个"≠"是大多数返工和线上事故的源头。本 skill 的纪律是：交付前用工具实际跑一遍验证，修 bug 时找根因而非压症状，绝不为"通过"而弱化检查。

灵感来自 multi-agent "loop engineering"（写代码的 agent 与检查的 agent 分离、循环到全绿）。但本 skill 提炼的是纪律本身——无论单 agent 迭代还是多 agent loop，验证-修复的纪律不变。loop 是一种强制实现，纪律才是本质。

何时使用

• 刚写完代码，准备声称"完成"/"修好了"
• 修 bug，决定怎么修
• 测试/类型检查报错，要处理
• 来回改同一处反复出问题（怀疑在原地打转）

不该用：纯探索/原型阶段（本来就不要求正确，验证是负担）；明确无失败可能的确定性逻辑（过度验证也是负担）。

与相邻 skill 的衔接：verify-and-fix 在 task-breakdown 的下游——每个任务的"完成定义"就是它的验证目标。task 拆出"做完 X 后能验证 Y"，verify-and-fix 负责"实际去验证 Y、不通过就修"。它把 task-breakdown 里的"完成定义"从纸面标准变成实际跑过的证据。

核心内容

第一原则：未经运行的代码不算完成

"我看了一遍，应该没问题"——这是最危险的完成声明。代码审查（肉眼看）不能替代运行验证。肉眼能发现风格、明显逻辑错，但发现不了：实际运行时的类型不匹配、边界数据触发的分支、依赖交互、并发时序。

完成的标准必须是实际跑过的证据：

• 有测试 → 跑测试，全绿才算过
• 有类型系统（TS/带 type hint 的 Python/Rust）→ 跑类型检查
• 能跑 → 实际跑一遍目标场景
• 三者都要，不是任选其一（测试过不代表类型对，类型对不代表运行时分支都对）

重构场景尤其要防回归：把 for 循环换成 find、换库、提函数、改异步为同步——这类"等价改写"最易悄悄丢失原代码处理的边界（原循环在没找到时可能返回 null/抛业务错，find 改写后这个分支没了）。验证重构时，问自己：原代码处理过哪些情况？新写法每一条都覆盖了吗？ 尤其是边界——空集合、找不到、异常输入。重构的验证标准比新写更高：新写只验"能跑"，重构还要验"行为没变"。

反例：用户说"我把 for 循环改成 find，应该没问题"，你附和"嗯看着对"——但 find 可能返回 undefined，.name 就抛错。这种 bug 肉眼看不出来，跑一下立刻暴露。

修病因，不修症状

修 bug 最常见的错法：在报错末端兜底，把错误压住，而不查它为什么报错。

• 报错 Cannot read 'map' of undefined → 加可选链 data?.map(...) 压住。错误消失了，但 data 为什么是 undefined 的病因还在——换个场景又会炸。
• 测试报 result is 4, expected 5 → 把断言改成 toBe(4)。测试变绿了，但"为什么是 4 而不是 5"的问题被掩盖。

区分"合理兜底"和"掩盖 bug"：

• 合理兜底：值合法地可能为空（如可选字段、外部数据可能缺失），兜底是设计的一部分。例：user.nickname ?? user.name——昵称本来就可不填。
• 掩盖 bug：值本不该为空却空了——说明上游有 bug（数据源问题、初始化遗漏、路径没覆盖）。这时兜底只是把火盖住，火还在烧。

判断尺子：问"这个 undefined/null 在什么情况下出现？"——能说出一个合理的业务场景（"用户没填昵称"）→ 合理兜底；说不清、或答"反正运行时出现了"→ 是 bug，查源头。

修病因的路径：沿错误向上游追溯——报错点 ← 数据从哪来 ← 谁产生/传递的 ← 什么条件下变成这样。修在最上游的"产生"处，而不是最下游的"消费"处。

断言失败时的灰度——先确认期望值的权威性。测试报"实际 4，期望 5"时，别本能地认定"代码错了、断言对"。先问：期望值 5 从哪来？ 是规格文档/业务约定的硬需求 → 代码错了，修代码；还是开发者随手写的猜测（"我觉得应该是 5"）→ 可能断言本身错了。区分两种"改断言"：

• 错的改断言：期望值有权威来源（规格/约定），为了通过把它改成实际值——这是弱化检查。
• 对的改断言：发现期望值本身就是错的（规格已改、当初写错了），改成正确的期望值——这是修正错误期望，不是放水。