Hello，我是Niko。16年程序员老兵，专注分享 AI编程实战经验、宝藏工具资源、前沿技术动态。不玩套路，多讲干货。
有没有发现，SKILL装了很多个，并没有什么质的改变。后来刷到 tw93 做的 Waza，GitHub 上 3.3k star，我才反应过来一个事：Skill 装多了会互相打架，真正管用的不是功能堆叠，是把几个关键的工程习惯做到位。
Waza 这个词来自日语"技"（わざ），武术里的概念，一个招式练到变成本能。tw93 的想法很直接：AI 让你写代码更快了，但它不帮你想得更清楚、查得更仔细、debug 得更系统。这些"本该有但容易偷懒"的习惯，Waza 把它们变成 Claude Code 能跑的 Skill。
一共 8 个，不多。
先说说 tw93 是谁
可能不少人知道 tw93，但未必知道他最近在折腾什么。他之前在蚂蚁做前端，后来做了妙言（macOS 上一个口碑不错的 Markdown 编辑器）和 Pake（用 Rust/Tauri 把网页打包成桌面应用），一贯是"小而精"的路子。
Waza 延续了这个风格。他说过，Superpowers、gstack 这些 Skill 合集确实厉害，但太重，配置项多，学习成本高。还有一个更微妙的问题：规则写得越多，模型能发挥的空间越小。每一条规则都是一个天花板。
Waza 反着来。每个 Skill 只定目标和约束，剩下的交给模型自己发挥。tw93 原话："随着模型变强，这种克制会带来复利。"
8 个 Skill 一览
先看全貌：
| Skill | 触发时机 | 做什么 |
|---|---|---|
| /think | 写代码之前 | 方案设计，压力测试架构 |
| /design | 做前端界面时 | 产出有审美方向的 UI，不是千篇一律的默认样式 |
| /check | 任务完成后、合并前 | 审查 diff，自动修安全问题，验证通过才算完 |
| /hunt | 任何 bug 或异常行为 | 系统化调试，确认根因后才动手修 |
| /write | 写文章或编辑文字时 | 改写文字，去掉生硬模板感 |
| /learn | 进入陌生领域时 | 六阶段研究流程：收集、消化、提纲、填充、打磨、自审 |
| /read | 读网页或 PDF | 转成干净的 Markdown，不同平台不同处理 |
| /health | 审查 Claude Code 配置 | 检查 CLAUDE.md、规则、Skill、Hook、MCP 健康度 |
看着每个都不复杂？往下看就知道了。我挑了三个最值得细说的：
/think、/check、/hunt。
/think：写代码之前，先把退路堵死
让 Claude Code 直接上手做功能，做到一半发现方向不对推倒重来，这种事我干过不止一次。tw93 做 /think 的出发点是："我更喜欢能表态给你最优方案的工程师。"
所以 /think 第一件事就是要求模型有立场。不许说"There are many ways to think about this"。给 2-3 个选项可以，但必须有明确推荐，必须包含一个最小化选项。
我翻了它的 SKILL.md 原文，比我想象的严格。
先验证前提再想方案。首先确认你在对的目录里（tw93 真遇到过 Claude Code 拿着错误路径出方案），然后查有没有现成的技术方案文档，再去 GitHub 搜有没有人处理过类似问题。三步做完才开始想办法。防的就是一上来就建立在错误前提上。
方案出来后要自己攻击自己。四个角度：依赖挂了怎么办、数据量放大 10 倍哪个环节先崩、方向错了回滚成本多高、最脆弱的假设是什么。攻击成立能修就修，修不了直接告诉你这个方案在什么情况下行不通。
有一条硬性规定我很喜欢：方案里不许出现 TBD、TODO、"以后再说"。tw93 的解释是，给了 AI 这些退路，执行的时候它要么少做要么瞎想。不给任何含糊空间，每一步都得是具体的。
复杂性也分级。超过 8 个文件或新增服务会明确告知规模，超 3 个组件交换数据画 ASCII 图找环，API key 和第三方依赖在方案阶段就列清楚。
/think 有一条死规矩：决不写代码，用户批准后再进行。纯粹的方案设计工具。
/check：不是一个大 reviewer，是一个编排系统
做代码审查 Skill，大部分人的思路是写一个巨大的 prompt 把审查规则全塞进去。tw93 没这么做。
/check 是分工编排。SKILL.md 当主审，管分级和流程控制。agents/ 目录下有独立的安全审查员和架构审查员，各管各的。什么时候拉谁进来，靠一份激活规则判断，不是关键词匹配。
分级逻辑：
- 100 行以下：快速 review，基础检查
- 100-500 行：按需加专家审查员
- 500 行以上：全拉满，再加一轮对抗性测试
对抗性测试这个环节我觉得有意思。从四个角度找漏洞：违反假设条件、组合失败、上下级串联错误、滥用场景。就是在模拟"如果有人想通过这个 diff 搞破坏，能怎么搞？"
发现的问题分 4 级：
safe_auto：明确无风险的（拼写错误、缺少 import），直接修gated_auto：大概率对的（空值检查、错误处理），打包让你确认一次manual：需要你判断的（架构变更、行为变化），问你advisory：仅供参考，不来烦你
我之前用过一些代码审查工具，要么什么都自动改搞出新问题，要么什么都问你一遍。/check 的处理是：能修的直接修，该问的才问，参考的说一声就完了。
还有一个硬要求：验证没跑完不算完。/check 带了测试探测脚本，能识别 Cargo、TypeScript、Python 等项目去跑测试。探测不到就报错，不假装通过。推理过程中出现了"should work now""probably correct"这种话，直接拦住，要求先跑验证。
/hunt：不确诊根因，不许碰代码
用 Claude Code 调 bug，你说"这里有问题"，它打个补丁；你说"还是不对"，换个补丁。四五轮下来，原来的问题没解决，新问题倒是冒出来了。没有诊断就不断打补丁，跟刚学编程的人一个样。
/hunt 的核心规则就一条：AI 能用一句话说出根因之前，不许碰代码。
这句话有精度要求。"状态管理有问题"不算，"useUser hook 在 src/hooks/user.ts:42 行的依赖数组缺少 userId 导致缓存不刷新"才算。说不到这个精度，说明还没搞清楚。
tw93 设计了一张"自我欺骗检查表"，防模型陷入自我合理化：
| 你在想什么 | 实际意味着什么 | 应该做什么 |
|---|---|---|
| "我试试这个" | 没有假设，在瞎撞 | 停下来，先写假设 |
| "我确信是 X" | 信心不是证据 | 跑一个能证明的验证 |
| "跟上次一样的问题" | 把新症状当旧模式 | 从头看执行路径 |
| "再重启一次应该就好了" | 在逃避错误信息 | 先把最后一条报错逐字看完 |
这些 gotchas 都是他最近一个月排查问题时踩过的真坑，每条配了对应规则和实际案例。
假设验证阶段要求加最小观测手段：打 log、打断言、跑一个最小失败测试。修完之后问题还在，立马换方向，不在同一个方向死磕。
三次假设失败后有 Handoff 机制。不是一直试下去，而是把查了什么、排查了哪些方向、还不知道什么整理成交接文档，交给你决定怎么继续。
最终输出：根因在哪（file:line）、改了什么（file:line）、什么证据确认修好了、测试通过情况。状态三选一：resolved、resolved with caveats、blocked。
顺便说说 /design
前面我写过一篇《AI 写前端能跑但丑？这个文件让 Claude Code 瞬间有了审美》，聊的是 DESIGN.md 怎么给 AI 注入设计系统。Waza 的 /design 走的是类似但更进一步的路子。
tw93 说他非常讨厌 AI 生成的那种千篇一律的蓝紫色渐变网站。于是他把自己做过的所有带 UI 的项目让 Claude Code 学习调教记录，提炼出最佳实践和反模式。从 pbakaus/impeccable 拿到具体审美规则：禁用字体清单、色彩系统、CSS 模式禁止项、动画规范。再从 getdesign 吸收了一个源自 Google Stitch 的九段式脚手架结构。
/design 跑起来会先问几个问题：谁用、美学方向、页面想让用户记住什么、你最不喜欢什么、微交互怎么做。有了这些上下文再基于知识体系去做，出来的东西就不是"能用但丑"了。
怎么装，怎么用
一行命令：
npx skills add tw93/Waza -a claude-code -g -y
装完在 Claude Code 里输 /think、/check、/hunt 直接用。
卸载：
npx skills remove tw93/Waza -g
tw93 还做了一个 statusline，在 Claude Code 底部显示上下文窗口用量、5 小时配额、7 天配额，颜色编码，一眼能看明白。
不足和提醒
几个需要注意的地方。
Skill 之间没有编排。8 个 Skill 各自独立，你得自己判断什么时候用哪个。没有一个总调度说"先 /think 再写代码再 /check"。这是有意为之，但对新手来说要花一段时间形成节奏。
/health 只支持 Claude Code。其他 7 个跨平台，Claude Code 和 Codex 都行，/health 只能在 Claude Code 跑。
适合有一定经验的开发者。这些 Skill 是教 AI 按老工程师的方式做事。如果你自己还不太清楚"好的技术方案长什么样"，用起来可能觉得流程太重。
我觉得最值得看的不是 Skill 本身
Waza 给我最大的收获是 tw93 设计 Skill 的思路。
他不是在给 AI 加功能。他是在把老工程师的工作习惯编码化。/think 背后是"一个靠谱的技术专家怎么做方案"：调研充分、决策果断、不留尾巴。/hunt 背后是"一个老手怎么排查问题"：不猜，先看，诊断清楚再动手。/check 则是把一个严格 reviewer 的审查逻辑拆成了可执行的分级流程。
参考大佬的设计思路，你也可以做出更适合你的 Skill。
参考资料：
