【免费下载链接】Waza Engineering habits you already know, turned into skills Claude can run.项目地址https://gitcode.com/gh_mirrors/cl/Waza点击查看免费下载导读本文围绕 Waza 项目中的hunt技能plugins/waza/skills/hunt/SKILL.md展开讲解其「先诊断、后修复」的核心方法论如何在一行代码都不碰之前用一句话写出可检验的根因假设如何借助 Bisect、截图对照、Scope Blast、运行时证据阶梯等模式把报错、崩溃、回归与以前是好的类问题收敛到具体文件与行号以及如何用统一的输出格式与回归守卫规则收尾。读完本文你将掌握一套可以直接复用到任何项目里的结构化排障流程并理解 Waza 仓库如何用脚本与测试约束这套流程的可执行性。一、hunt 在 Waza 技能体系中的定位Waza技日本武道术语把工程师已有的工程习惯沉淀为 Agent 可执行的技能。hunt是其中负责「诊断」的那一个其前导声明非常明确Finds root cause before any fix. Use when something errors, crashes, regresses, or used to work. Not for code review or new features.也就是说hunt 只管找出为什么坏不管审代码那是/check也不管写新功能那是/think 实现。从 plugins/waza/plugin.json 可以看到整个 Waza 插件只注册了waza一个名字hunt 与其他技能以命名空间形式/waza:hunt随插件分发。而在 README.md 的技能表中/hunt被描述为 Systematic debugging. Root cause confirmed before any fix is applied, especially when something used to work与本文档核心一致。触发词与分发意图hunt/SKILL.md的 frontmatter 定义了何时使用when_to_use与分发意图dispatch_intent这些字段不仅是给人看的说明也是 Agent 自动匹配技能的输入when_to_use排查, 报错, 崩溃, 回归, 截图回归, 判断错误原因, 判断为什么报错, 反复修不好, debug, regression, used to work, broke after update, why broken, not working, whats wrong, fix error, stack trace, 以前是好的dispatch_intentError, crash, regression, screenshot-reported defect, test failure, stale cache, runtime boundary, why broken可见触发面覆盖三类典型场景显式报错错误、崩溃、堆栈、测试失败、回归以前是好的、更新后坏了、截图回归、隐式行为异常stale cache、runtime boundary、为什么坏了。与相邻技能的消歧规则plugins/waza/skills/RESOLVER.md 的 Disambiguation 一节给出了 hunt 与/check、/ui、/health的边界实操中非常关键改错 vs review代码已经交付或走到 PR →/check代码跑不通或行为错了 →/hunt。两者都可能匹配帮我看看按有没有具体错误现象判断。配置/维护性异常 vs 代码错误Agent 本身不听话、hook 不触发、MCP 掉链子、配置漂移、验证命令失真 →/health用户写的代码抛异常 →/hunt。截图审美 vs 截图回归截图里说丑/不好看且是审美校准 →/ui截图证明以前好的现在坏了、渲染错、状态错、生成物错 →/hunt。质量改善 vs 调试已有可审 diff、要改善代码质量且没有报错 →/check有具体报错或回归 →/hunt。同时 RESOLVER.md 的 Chaining 给出了典型串联/hunt定位根因 → 用户说修 → 修完 → 用户说/check确认没副作用/hunt修复 issue → 用户说发布/push/关闭 issue →/check做发布前检查和收尾。二、结果契约Outcome Contracthunt 开篇用四元组定义了什么叫完成任何一次调用都必须能回答这四个问题维度要求Outcome在任何修复落地之前根因已被识别Done when一句话能解释原因每一个观察到的症状都能被该原因覆盖修复或交接已通过一个可复现的检查验证Evidence源码追踪、可复现命令或 UI 路径、日志或状态、针对性的测试/构建输出以及 UI 或原生缺陷的运行时证据Output根因、修复或交接、验证结果、以及任何未被清扫的同类风险sibling risks授权边界Authorization这是全文中最重要的行为红线之一diagnose、investigate、why、look into、排查、看看 等表达默认只报告不改。只有当前请求明确要求 fix / change / implement / optimize或同一未完成任务中存在仍然有效的授权action、scope、goal 均未变时才可以动手修。修复授权永不附带commit、push、publish 或任何破坏性动作。这解决了 Agent 排障时最常见的越权问题用户说帮我看看为什么报错不等于授权你改代码改完也不等于授权你提交。修复授权与提交授权是两笔独立的账。一句话根因的可检验标准hunt 明确要求在你把代码之前必须能用一句话说出根因格式为I believe the root cause is [X] because [evidence].而且这句话必须命名具体的文件、函数、行号或条件。文档给出了正反两个例子❌ 不可检验A state management issue状态管理问题——太笼统。✅ 可检验Stale cache inuseUseratsrc/hooks/user.ts:42because the dependency array is missinguserId——精确到文件、函数、行号、机制。规则很硬如果你做不到这个具体程度说明你还没有假设只有模糊印象。三、诊断信号Diagnosis Signals假设质量门槛与自欺信号hunt 给出了两套用来审查自己思考过程的信号。假设质量门槛Hypothesis quality gate假设必须能解释每一个观察到的症状而不仅仅是用户先报告的那一个只覆盖部分症状的是症状级猜测不是根因。三条推论报告者轻描淡写说不相关的症状仍然是你假设必须覆盖的症状对于时间相关的问题闪烁、间歇性失败、竞态先可靠复现再诊断——复现不了的间歇问题任何假设都无法验证覆盖率不足 症状级猜测意味着你要么修正假设要么还没到根因。自欺信号Rationalization smells文档总结了五种典型的自我合理化话术每种都配了一个对应的反制动作话术反制动作Ill just try this我先试试没有假设先把假设写下来Im confident我很确定运行能证明它的那个探针Probably the same issue可能是同一个问题从头重读执行路径不要套用旧结论It works on my machine我机器上是好的先逐项枚举环境差异再 dismissOne more restart再重启一次逐字重读最后一次报错没有新证据就不允许重启超过两次四、Durable Context Preflight记忆只当燃料不当证据hunt 引用 plugins/waza/skills/hunt/references/durable-context.md 作为共享前置章节并加上技能特化说明范围只有当用户点名记忆、先前决策或记忆路径或项目有明显本地记忆摘要MEMORY.md或已文档化的记忆目录时才读取先列标题最多打开一两份摘要不读原始 transcript跨项目条目当作可迁移模式而非本项目事实。当前状态优先当前代码、diff、截图、日志、测试、文档、CI、远端状态、实时探针永远覆盖记忆——包括运行时自动注入的记忆。被记住的事实只是待复核的线索永远不是证据冲突时明确命名冲突并跟随当前状态。记忆不是授权记忆可以解释偏好但绝不能授予或扩大写、提交、推送、发布、公开回复、删除等动作的授权。脱敏门Redaction Gate把先前的对话、持久记忆或跨项目笔记沉淀为可复用规则时只提升工作流规则必须剥离原始 transcript、截图、本地路径、项目专属命令、issue/PR 编号、release tag、commit hash、私有产品边界、付费/许可细节、支持路由、用户名、单机状态。需要示例时用中性占位符ExampleCLI、ExampleApp、issue、command。对/hunt而言durable context 只是假设的燃料当前代码、日志和复现证据优先于记忆它永远不能替代一句新鲜的根因陈述或一份可复现的症状清单。五、八大诊断模式详解hunt 的核心是可切换的诊断模式每种模式有明确的激活条件与操作步骤。5.1 Bisect Mode二分定位回归激活条件用户说以前是好的 / 之前是好的 / used to work / 上一次提交还是对的 / broke after update或能记得一个具体的 good commit / version。执行流程分三步先保护用户工作区运行git status --short --branch -uall。只要有任何 modified / staged / untracked 文件就不在当前 checkout 里做 bisect——改在临时 detached worktree 中进行结束即删除若临时 worktree 不可行停下来请求明确的 cleanup/stash 授权。优先读 diff 而非直接 bisect如果最后正常版本只差几个 release先git diff last-good..HEAD -- suspect path读 delta。回归点通常在这个 diff 里一眼可见成本只是 bisect 的一个零头只有 diff 太大或凶手不明显时才落到 bisect。bisect 纪律只用预先定义好的非交互 pass/fail 命令账目记在 git 里git bisect good/bad直接测试嫌疑 commit 时也一样记账。bisect 指名凶手后只读该 diff 直到具体那一行然后先git bisect reset再删除临时 worktree。5.2 Repeated Regression / Screenshot Reference Mode重复回归 / 截图对照激活条件用户说同一个问题修完还错或提供了好的截图/版本/文件或把某个视觉结果描述为以前是正确的。把参考物当证据而非装饰按固定顺序执行用用户的原话逐条列出所有已报告与可见的症状识别参考 oraclelast-good commit、旧构建、fixture、截图、描述出的期望状态在动手编辑之前定义 pass/fail 检查命名当前 vs 参考的精确 delta。并强调证据指向坏渲染、竞态、字体管线或状态路径时不要把一个视觉缺陷泛化成风格打磨。如果纯属主观 UI 审美路由到/ui如果是渲染、状态、时序、构建输出、字体生成或从已知良好版本回归留在/hunt。5.3 Scope Blast Mode同类问题清扫举一反三激活条件修完一个根因模式后、宣布 bug 结束之前或用户说举一反三、举一反三深入看看、其他地方有没有同样问题。文档给了一个冷峻的提醒同样的形状往往藏在 N 个其他地方一个只修局部的 fix 会把 N-1 个 bug 留在树里。操作步骤提取模式签名——产生该 bug 的具体函数、正则、API 调用、CSS 选择器、锁获取、校验跳过或输入边界grep -rn全仓扫描排除生成目录、构建输出、vendor 依赖对某类 bug 模式如任何 handler 缺锁要 grep 周围形状而非只搜字面文本对每个匹配书面回答same bug / safe to leave说明理由/ unsure问用户不得静默跳过任何匹配blast 报告没写进 Output 块之前不得声称fixed清扫中撞见的无关 bug 先列出不并入本次修复除非用户同意。5.4 Confirm or Discard确认或推翻运行唯一那个假设为假则必失败的探针然后读它。证据与假设矛盾时彻底丢弃假设根据探针刚展示的事实重新定向。不要把一个 fix 堆在已被证伪的假设上也不要因为代码看起来像原因就保留假设。这是整个方法论中最反直觉也最重要的一条被证伪的假设不是还需要微调而是已经死了。5.5 Native App Freeze Mode原生应用卡死模式激活条件beachball彩虹风火轮、not responding、tab 切换卡死、首开延迟、空闲唤醒停滞、overlay 锁死、或冻结应用的截图。此时必须先加载 plugins/waza/skills/hunt/references/logging-techniques.md 的 Native App Freeze Mode 一节再改代码。改码前要收集的证据详见 reference确切的用户路径与版本首启 vs 热启、tab/窗口切换、空闲时长、权限、显示器数量、任何能让卡死消失的设置冻结时的运行时抓取sample process、近期应用日志、CPU 与内存占用、线程数、主线程是否阻塞/空转/分配首帧表面view body 工作、第一个.task、同步图标/元数据查找、文件系统扫描、URL 父级遍历、通知回调、app/window 唤醒处理器修复后的 blast 搜索全仓 grep 同一 API 形状尤其是路径父级遍历、同步图标加载、渲染路径里的元数据读取、主线程回调。reference 还列出常见原生卡死陷阱启动/终止/权限/音频/显示/工作区通知在主线程做路径遍历或图标查找首绘先 hydration 整个应用列表、目录树、缩略图集再显示交互壳输入锁或全屏 overlay 缺少 Escape、应用失活、权限拒绝、进程终止、窗口关闭的保证 teardown 路径以及跨越隐藏窗口、长空闲、睡眠/唤醒、应用重新激活存活的定时器。关键结论该模式下编译通过、只看源码都不够结果必须包含运行时抓取、根因帧或状态转换、聚焦的回归守卫、以及已修或明确判定安全的同类匹配。5.6 Targeted Logging定向日志hunt 对日志的定义极其苛刻每条日志都是一个 yes/no 问题如果它在 Y 之前打印了 X假设 A 存活否则 A 死了。一条无法证伪或证实假设的日志就是噪音。配套规则收尾前删除临时日志需要长期保留的诊断输出用项目 debug flag 门控如果加日志改变了行为这本身就是时序、生命周期或并发问题的证据——不能当日志副作用一笑了之。logging-techniques.md 进一步给出两个实操补充Discriminating Content有判别力的内容日志应记录能区分假设的东西——顺序序号或时间戳、输入身份 key、走的分支、旧→新状态转换、错误码加上下文放在行为应当可预测的边界handler 进出、带 key 的缓存命中/未命中、带旧值与调用者的状态 setter、异步回调进入、外部 API 结果而不是放在 tight-loop 内部。对竞态、闪烁、间歇失败还要抓事件身份、单调顺序、起止不是它跑过、线程/任务/队列身份。永远不记凭证、PII、完整请求/响应体。Runner-Only Failures只在特定 runner 下失败脚本只在某个 runnermake target、CI 任务、测试 harness、cron下失败、单独跑却通过时不要往脚本里塞容易忘记删的调试 hack而是从外部注入追踪# xtrace-env.sh: sourced by every non-interactive bash via BASH_ENV exec 19/path/to/persistent/xtrace.log export BASH_XTRACEFD19 export PS4 [$0:$LINENO] set -x然后以BASH_ENV/path/to/xtrace-env.sh make test或 runner 等价方式运行失败流水线runner 每次 spawn 的 bash 都会把带file:line的追踪追加到同一个持久文件逃过 runner 临时目录的清理用哨兵变量防止嵌套 shell 重复 source结束后删除该 env 文件。5.7 Rendering Bug Mode渲染缺陷模式激活条件PDF 输出不对、分页错误、字体渲染问题、打印布局错。先加载 plugins/waza/skills/hunt/references/rendering-debug.md原则是静态分析先行CSS 审查必要时再复现。reference 里的检查清单包括WeasyPrintrgba()会导致双矩形 bug用纯 hex 颜色page-break-inside: avoid经常被忽略改用显式分页float 布局常在页面边界崩坏优先 flexbox 或 block外部字体 URL 在渲染时被拦截应内嵌 base64 或本地托管。字体加载检查font-facesrc 路径相对 vs 绝对外部字体需要 CORS 允许渲染源WeasyPrint 偏好 WOFF/TTFWOFF2 支持看版本缺字体 fallback 隐形文本或系统 fallback 字形。页面溢出先算内容高度 vs 页面高度再逐行调试减小line-height/padding/margin回收空间pagebody 规则里加orphans: 3; widows: 3。浏览器打印 CSS确认media print存在且未被覆盖pagemargin 要为打印机不可打印区留出约 6mm 以上section 分隔用break-before: page/break-after: page在 DevTools 里用window.print()实测而不是只看视觉预览。5.8 IME / Unicode Issues输入法与字符编码问题激活条件输入法、字符渲染或文本编码 bugIME 状态、光标漂移、emoji 拆分、composition 事件。先查 plugins/waza/skills/hunt/references/ime-unicode.md 再形成假设。该 reference 覆盖 webview 托管与原生 macOS 应用的高频模式IME 状态失步拉丁字符正常但 CJK 输入丢失/重复/错时提交。候选原因包括composition 中途切换输入法导致 stale target 重复处理按键keydownhandler 在 composition 期间消费事件应在确认事件上抑制绑定动作且不要把该动作排到compositionend后Tauri 中 webview 与原生标题栏同时持焦composition 期间点击原生控件触发 focus-out 提交不完整 preedit。仪器记录compositionstart/update/end序列确认无缺口记录每次compositionupdate的data突然的空串 强制提交。光标位置漂移composition 期间 DOM 变更React/Svelte/Vue 在isComposing为 true 时重渲染会重置选区应批量状态更新、只在compositionendflush同时警惕 UTF-16 code unit 与 grapheme cluster 的混用[...str].length替换str.length本身也可能造成漂移。Emoji ZWJ 序列拆分如被拆开或U200D可见字符串在 UTF-16 code unit 偏移处被 slice字体不支持该序列序列化剥掉 ZWJ。测试基线[...].length是 3 个 code point而[...new Intl.Segmenter(undefined, {granularity: grapheme}).segment()].length是 1 个 grapheme cluster。compositionend/keydown顺序compositionend可能先于确认keydown此时isComposing已为 false也可能后于必须在受影响 IME 与宿主上实测顺序不能从 OS 推断验证目标是IME 确认提交文字但不提交表单随后一次刻意 Enter 只提交一次。不要用任意 timeout 替代该证据。macOS 文本系统 vs webview 冲突WKWebView 自带文本系统与 NSTextView 惯例部分重叠检查宿主 key-handling 配置Tauri 的preventDefaultFor是否存在过宽的preventDefault规则。reference 还附了一张快速检查清单isComposing检查、composition 期间不做 DOM 变更、偏移单位匹配、ZWJ 用Intl.Segmenter验证、确认键守卫测试两种顺序加一次正常 Enter、preventDefaultFor不过宽可直接作为 IME bug 的排查模板。六、运行时证据阶梯Runtime Evidence Ladder在声称bug 已修复之前必须爬完这条 5 级证据阶梯越往上证据越硬源码追踪Source trace指出能产生该症状的确切函数、状态转换、文件、行号或条件。确定性复现Deterministic repro运行或写出能产生它的最小命令、fixture、UI 路径或场景。日志/状态/缓存Logs/state/cache检查证明该路径确实被走到过的运行时状态——队列、DB 行、缓存、临时文件、生成产物、外部工具日志。构建/测试Build/test运行触及该修复的窄测试或构建。真实运行时检查Real runtime check对 UI、原生应用、浏览器、渲染或视觉 bug打开应用/页面/产物用截图或具体清单验证可见结果。两条硬约束编译通过对 UI、原生、视觉、渲染、生成物 bug 来说不够。如果环境中无法做运行时检查要说清原因并把需要验证的确切屏幕、命令或产物交接出去。当报告者环境缺失且本地无法复现时下一件产物不是一个新假设而是一个只读探针read-only probe——让用户粘贴运行即可打印环境、有争议的测量值、以及假设所依赖的状态且不能携带任何 secret 或私有路径。不要假设对方布局与你相同安装方式、目录约定、locale、shell、版本都不同要发现而不是硬编码以纯可复制文本交付一条命令运行一个块粘贴回来。另外对于反复出现的失败类别在打第二个补丁之前要加载 plugins/waza/skills/hunt/references/failure-patterns.md。七、硬规则Hard Ruleshunt 用 7 条硬规则划定不可逾越的边界其中前两条是无条件硬停修完症状仍在 硬停let me just try this 硬停。两者都意味着假设未完成碰代码之前从头重读执行路径。连续三个假设失败就停下。用下面的 Handoff 格式列出检查过什么、排除了什么、未知的是什么询问如何继续。外部工具失败先诊断再切换。MCP 工具或 API 失败时先确定原因server 在跑吗API key 有效吗配置对吗再考虑换方案。系统/工具链症状需要更低层基线。在怪罪可见应用、生成文件或顶层功能之前先测量原始低层OS 捕获 vs 后处理、运行时服务 vs UI、编译器/工具链 vs 测试断言、网络/API vs 客户端处理。被基线证伪的假设直接退役不要反复兜圈。视觉/渲染 bug先静态分析。在加 console.log 或可视化调试 overlay 之前先用 DevTools 追踪 paint layers、stacking contexts 和层序。日志抓不到 compositor 干的事静态分析失败后才允许加 instrumentation。行为/生命周期/异步 bug在形成假设的同时就上仪器。窗口生命周期、事件投递、导航、焦点、定时器、状态机、异步顺序类 bug 几乎不可能靠静态阅读解决。一旦假设涉及这个回调在另一个之前/之后触发、这个状态应该在某时刻是 X、这个对象到这里应该还活着就要在写任何 fix 之前先加日志连续猜两次就是硬停信号。compositor 行为需要 DevTools 而非日志纯逻辑 bug公式错、off-by-one只需要静态分析。性能类抱怨必须要有数字。对慢/卡/内存增长Native App Freeze Mode 之外先测基线墙钟时间、profile 采样、内存占用修复后再测报告前后数字。Feels faster不是证据。修复要在授权范围内必要修复包括共享接口变更这类前置重构只要说明为何需要可以继续只有修复扩大范围或需要未决行为权衡时才询问文件数量本身不是批准边界。无关重构保持分离明确请求的特性在诊断后走自己的工作流、挂在同一完成清单下——bug 修复授权不授权未请求的特性。注原文Fix the cause within the authorized scope一条本身含前置重构与特性边界此处为忠实转述并与其他硬规则并列编号第 2 条三个假设失败即停与第 5、6 条共同构成 hunt 的三大硬停信号。八、Gotchas来自真实失败的陷阱速查表hunt 把反复踩过的坑整理成一张 12 行的表格每一行都是一个发生了什么 → 规则的浓缩经验直接决定了排查方向发生了什么规则Patch 了重复表面的错误副本在碰任何文件之前沿执行路径回溯到实际渲染的那个实例Orchestrator 报 RUNNING 而下游 stage 配错多阶段流水线中逐阶段隔离测试竞态被误诊为 stale-state bug时序敏感问题先检查事件时间戳与顺序再查状态本地能复现、CI 失败先对齐环境运行时版本、env vars、时区再追代码从应用内启动正常、从文件关联/拖放/深链/外部代理打开就坏用用户描述的确切入口复现app 内初始化不同于带文件冷启动文档到达时状态可能还没就绪fix 符合报告者环境但没帮到别人或回归了默认缺陷报告是证据不是全量范围说明 fix 改变的是所有人的默认体验还是仅报告者配置优先修默认路径切换主题/模式/locale 后坏了、重启就好状态没在 toggle 路径上重新应用先追踪 toggle 的重算或失效路径不要在状态路径坏着的时候逐像素调样式改了算法输出还是错的读取方可能命中旧代码写入的持久化输出扫描结果、分析缓存、带 TTL 的 snapshot改生成后持久化数据必须在同一变更里失效或版本化旧缓存再诊断前先确认运行时没在读 stale 数据修好并发布了唯一能复现的 cause同一个 gate 却因另一个原因挡住下一个用户一个会拒绝的 guard 有一组原因而非一个发布前枚举每个拒绝分支给每个分支可区分的 code、一句话理由、一条后续命令用户观察与日志不符且日志赢了相信观察把差距当作未插桩路径happy path 上通过的探针说明不了失败路径无法复现的探针是无效探针不是没有缺陷在从不提供该能力的表面上修了 capability-gated 功能写 fix 前确认运行表面simulator、device、sandbox、受限 entitlement支持它不支持就直接说明并停止——没有源码变更能让它出现九、输出格式成功格式、回归守卫与交接格式hunt 要求收尾不是流水账而是结构化证据块。成功格式Success Format开头先用一句平实的 prose 声明结果与是否已提交下面的代码块支撑这一句不替代它Root cause: [what was wrong, file:line] Fix: [what changed, file:line] Sibling sweep: [N same-shape sites checked, N fixed / none found / not run, why] Confirmed: [evidence or test that proves the fix] Tests: [pass/fail count, regression test location] Regression guard: [test file:line] or [none, reason]状态行必须是三者之一resolved、resolved with caveats须说明 caveat、blocked须说明未知项。回归守卫规则Regression Guard Rule对任何**复发过或之前修过**的 bug修复不算完成直到满足全部 4 条存在一个回归测试在未修复代码上失败、在修复后代码上通过测试位于项目测试套件中不是临时文件提交信息说明该 bug 为何复发、此修复为何能阻止它Red-green 是跑过而非假定在隔离的临时 checkout 或 fixture 里对未修复代码跑新测试再对修复跑。不要用 revert 或 stash 共享 worktree 来做这个对比。一个只被观察到绿过的回归测试 pin 不住任何东西——red 运行必须写进输出。规则还特别点出两种会让红色运行静默失效的形状框架/语法陷阱失败断言在测试中途不使测试失败只有最后一条断言把关shell 套件里可能只靠 bracket 形式决定成败一个关键字被吞掉另一个被抓住——用两行最小复现去运行确认而不是推理错误的反向断言断言输出不得包含 X可能永远通过因为任何代码版本下 X 都没被发出过。任何反向断言must not contain X都必须在同一测试里配一个正向用例证明该断言确实可能失败。交接格式Handoff Format三次假设失败后状态写blocked然后按序给出一句话症状每个假设及其测试方法、为何被排除已收集证据日志或 stack 摘录、复现步骤、版本、配置、运行时仍然未知或缺失的部分下一步点名需要用户提供的工具、权限或上下文。十、仓库层面的落地与校验这套方法论如何被机器约束hunt 是 fat skillMarkdown 判断型但 Waza 仓库用脚本和测试把其中可确定的部分变成确定性约束这体现了 RESOLVER.md 里需要判断 → skill同入同出、只是校验和列举 → script 或 rule的分工原则。scripts/verify_skills.py 是校验驱动入口把验证逻辑拆到可单测的模块skill_frontmatter.py、skill_checks.py及各checks_*.py其中check_outcome_contract、check_references、check_description_conformance、check_table_pipes等检查项直接约束了 hunt 这类 SKILL.md 的骨架质量——包括文档中那张 12 行 Gotchas 表格的管道符规范、frontmatter description 的引号与格式、以及文档内引用 reference 文件是否真实存在且路径正确。tests/python/conftest.py 把scripts/放入sys.path让单元测试直接 import 校验模块这意味着hunt 文档里的每个链接都指向存在的文件frontmatter 描述符合规范这类不变量可以被 CI 反复验证。hunt 与/check存在双向引用check/SKILL.md 在 Verification 一节直接引用了 hunt 的 Regression guard rulea regression test that fails on the old code must exist before the fix is done, run red on that code在 Pattern-Fix Completeness 一节引用 Scope Blast Modegrep the repo for the same shape (hunts Scope Blast Mode)。这说明两个技能是同一完成清单上的前后工序hunt 负责把根因与回归守卫做对check 负责在合并/发布前确认没有副作用。结语把先诊断后修复变成可执行的习惯hunt 的价值不在于教人认真一点而在于把排障流程拆成可判定真伪的步骤一句话可检验的根因假设、被证伪就丢弃的纪律、五级运行时证据阶梯、三大硬停信号同症状复发、连猜两次、三个假设失败、以及一个必须包含回归守卫的结构化输出。配合 Bisect、截图对照、Scope Blast 与针对 IME/渲染/原生卡死的专项 reference它覆盖了从用户报了一个错到修复被证明、同类风险被清扫的全链路。无论你是在 Claude Code、Codex 还是其他 Agent 里调用/hunt这套方法的骨架都值得直接移植进自己的调试习惯。赞分享【免费下载链接】Waza Engineering habits you already know, turned into skills Claude can run.项目地址https://gitcode.com/gh_mirrors/cl/Waza点击查看免费下载相关推荐想从 GKI 切回 LKM 又怕变砖KernelSU 模式切换与内核更新避坑实操想从 GKI 切回 LKM 又怕变砖KernelSU 模式切换与内核更新避坑实操 想把 KernelSU 从 GKI 切到 LKM又怕刷坏救不回来这篇把两基于 Cline Skill 的系统化调试方法论从复现到根因修复的可执行流程基于 Cline Skill 的系统化调试方法论从复现到根因修复的可执行流程 本文聚焦 Cline 仓库中内置的 debugging 技能指令位于 sdk/人工智能AI Agent代码智能体AI 应用开发工具MCP ClientsPostHog 稳定化 Flaky 测试完整指南复现、根因定位、修复与 N 轮验证方法论PostHog 稳定化 Flaky 测试完整指南复现、根因定位、修复与 N 轮验证方法论 本文基于 .agents/skills/fixing flaky t数据分析后端前端数据可视化大数据上一篇如何快速部署微信机器人5分钟打造专属智能助手完整指南下一篇Common Test 内部机制深度解析时间统计、CT_LOGS 日志页面、CTH 执行顺序与 test_server 架构创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
