执行验证 (Exec & Verify)

改完不算完,跑起来证明它对。用 exec 跑 typecheck / 测试 / 构建 / 复现命令验证改动,并对破坏性操作保持谨慎。是「读-改-验」闭环里的「验」。

使用时机

✅ 使用此技能当: 改完代码要验证、要复现 bug、跑测试/构建/lint、查环境与依赖。 ❌ 不要用当: 纯讨论/规划阶段、或操作明显有破坏性且未确认时。

铁律

1. 改完必验 — 任何代码改动后,跑能证明它有效的最小命令(typecheck / 相关测试 / 构建)。绿了才算完成,禁止"我觉得对了"就收工。
2. 先窄后宽 — 先跑最相关的单测/类型检查,再视情况跑全量。别一上来全量测试浪费时间。
3. 破坏性操作要谨慎 — rm -rf、git reset --hard、git push --force、改数据库/生产、装卸全局依赖等:先确认目标、能不做就不做、必要时先备份;不确定就停下问。
4. 如实报告结果 — 失败就贴真实输出(报错原文),别粉饰;跳过的步骤要说明。
5. 读懂再下一步 — 命令失败先读完整错误,定位根因(配合检索),改(配合精确编辑),再重跑;不要盲目重试同一条。

标准流程

1. 选验证命令

• 改了什么 → 用什么证明?(改 TS → npm run typecheck + 相关测试;改 UI → 构建/预览;修 bug → 先写/找能复现的命令)

2. 先复现(修 bug 时)

• 改之前先跑出"红"(复现问题),改之后跑出"绿",才证明真修好了。

3. 由窄到宽跑

npm run typecheck            # 类型先过
npm test -- path/to/file     # 跑最相关的测试
npm run lint                 # 风格/静态检查
npm run build                # 构建验证(视情况)

4. 失败 → 定位 → 修 → 重跑

• 读完整报错 → 找根因 → 精确改 → 重跑该命令,直到绿。

5. 收尾报告

• 跑了什么、结果如何(绿/红)、还有什么没覆盖,如实说清。

破坏性操作清单(三思)

rm -rf · git reset --hard / clean -fd · git push -f · DROP / DELETE SQL · 改生产配置 · npm i -g / 卸载 · 覆盖用户文件。→ 确认目标路径、能否可逆、是否必要;不确定先问。

反模式(禁止)

• ❌ 改完不跑任何验证就宣称完成
• ❌ 报错只看一眼就盲目重试
• ❌ 对结果报喜不报忧
• ❌ 未确认就执行破坏性命令

核心原则

改完必验 · 先窄后宽 · 谨慎破坏性 · 如实报告。 让"绿色的测试/检查"替你背书,而不是嘴上说对。