hunt

hunt skill 概览

hunt 是用来做什么的

hunt 是一个以调试为先的 skill，它会强制你在动手修复之前先做根因思考。它最适合处理错误、崩溃、回归、测试失败、缓存陈旧问题、截图 bug，以及那种“以前明明能用”的故障——你需要的是可验证的假设，而不是匆忙打补丁。

谁应该安装它

如果你经常在应用代码、测试、构建产物或运行时行为之间排查问题，并且希望有一套可重复的 hunt 指南，能快速缩小问题范围，那就应该安装 hunt skill。它在这些场景里尤其有用：症状很嘈杂、反复修复都失败，或者 bug 同时牵涉日志、UI 状态和生成结果。

它的不同之处

它的核心价值在于纪律性：先锁定一个具体的文件、函数、行号或条件，再持续收集证据，直到根因足够站得住脚。配套参考覆盖了日志、失败模式、IME/Unicode 边缘情况和渲染 bug，所以这个 skill 不只是“更努力地调试”；它会把你推向更正确的一类诊断路径。

如何使用 hunt skill

安装与上下文准备

按你环境里的标准 skill 安装流程完成安装，然后按这个顺序打开 skill 文件：SKILL.md、references/failure-patterns.md、references/logging-techniques.md、references/ime-unicode.md、references/rendering-debug.md。先从最贴近症状的参考文档开始；除非问题横跨多个领域，否则不要一口气全读完。

如何发起 hunt 使用请求

想把 hunt 用好，最好先要诊断、后要修复，并附上你手头最小可复现的症状。好的输入会像这样：hunt 这个回归问题：点击 Save 后刷新就不再持久化；最近改动碰了 src/hooks/user.ts；日志显示 cache hit。差的输入会像这样：save 坏了，请修。

这个 skill 预期的工作流

hunt 指南预期你先用一句话写出假设，再用证据验证，只有在原因可测试之后才开始打补丁。实际操作中就是：先复现，再缩小路径，收集一条能区分不同假设的日志或检查，确认传播链路，然后写最小修复；如果可能，再补一个回归测试。

实用阅读路径

如果 bug 像是 cache、queue、guard 或 build 边界问题，先看 references/failure-patterns.md。如果你需要带埋点的证据，就看 references/logging-techniques.md。如果是 CJK 输入或 composition 问题，就看 references/ime-unicode.md。如果涉及 PDF、打印、字体或布局失败，就看 references/rendering-debug.md。

hunt skill 常见问题

hunt 只适合代码 bug 吗？

不是。hunt skill 适用于任何具体故障模式的调试：运行时错误、测试失败、生成产物损坏、UI 回归以及输出不一致。它不适合纯代码评审或功能设计。

我需要先知道准确根因吗？

不需要，但你需要一个可以被证伪的假设。这个 skill 的目标就是帮你从“有问题”推进到“我认为根因是 X，因为 Y”。

hunt 比普通提示词更好吗？

通常是的，尤其当故障表现模糊或反复出现时。普通提示词可能直接给你一个补丁；hunt 会先尽量减少猜测，这样更不容易修好一条路径却把另一条路弄坏。

什么时候不该用 hunt？

当你在加新功能、在没有 bug 的情况下重构，或者已经拿到了确认过的最小修复、只需要实现帮助时，就跳过它。它也不是高层架构头脑风暴的最佳选择。

如何改进 hunt skill

先提供更强的证据

直接给出症状、最近的改动、准确环境，以及一两个具体观察结果。例如：“只在冷启动时失败”“清缓存后就通过”“在 macOS 上使用 CJK 输入时会坏”“本地 PDF 正常，但 CI 里不正常”。这样可以帮助 hunt 立刻选对失败模式。

避免常见失败方式

最大的错误，是在原因尚未收敛时就急着要修复方案。另一个常见问题是可观测性太弱：日志只显示错误信息，却没有能区分不同假设的分支、顺序或状态迁移。要补充能区分假设的证据，不要只是增加噪音。

在第一轮之后继续迭代

如果第一轮诊断不完整，就用新的观察结果继续回应，而不是把整个提示词推倒重来。hunt skill 最适合用缩小范围的循环来推进：假设、检查、反例、更强的假设。这样你才能从一次 hunt skill 安装，走到稳定可靠的 Debugging workflow hunt。