Tw93 (@HiTw93) “终于到了 Waza SKill 设计思路的第 4 部分，讲完这个就差不多了，因为其他两个是 /rea” — TopicDigg

终于到了 Waza SKill 设计思路的第 4 部分，讲完这个就差不多了，因为其他两个是 /read 和 /learn 之前已经简单聊过，这次继续聊工程师技能部分的 /hunt 技能，其实就是 debug 问题排查问题的技能。 其实证明 AICoding 是民科和专科的一个很大区别，可以来看用户是如何用 AI 来解决一些很久没有解决的问题的排查思路的，这个过程可以看到明显区别，其实这也是经验丰富的工程师其实用好AI远会比不那么懂技术的人可以解决更加复杂问题的原因。 之前经常碰到，Claude Code 遇到一个问题去解决，基本上就是是一个patch，你说不行，他给你是另外一个，你会发现4-5轮下面，又有新问题出来了，也即很容易出现在没有诊断出问题下不断去打补丁，很像之前没有AI时候刚刚写代码的小伙伴。 /hunt 的核心规则有意思，就是在 AI 能用一句话说出根因之前，不许碰代码。而且这句话有精度要求，需要明确的那种原因说明。 然后我设计了一张“自我欺骗检查表”，防止模型陷入几种典型的自我合理化的思维，每一种都配备了对应的规则，然后在 gotchas 里有真实案例，这里会根据我最近一个月排查问题时候出现的问题再次总结抽象一下。 假设验证阶段也有一些干活要求，比如加一个最新的观测手段，比如让AI学会打log，打断言，或者跑一个最小失败的测试case，修完之后还有问题应该是立马去更换方案，会把查了什么、排查了什么方向、还不知道什么整理成handoff交给用户来决定怎么继续，而非一直试下去。 输出也会建议到AI，根因在哪 file:line、改了什么 file:line、什么证据确认修好了、测试通过情况。最终状态三选一：resolved、resolved with caveats、blocked。 这样你会发现 /hunt 就很像一个经验丰富的技术专家了，遇到问题不是去猜，而是先沉下心去看问题在哪儿，诊断清楚原因，然后一把就过就解决的那种，往往这样会节约很多时间。 哈哈，假如你还有更好的 debug 方法，欢迎也告诉我，或者给 pr