多彩编程 多彩编程MZPH · CODE BLOG
ARTICLE DETAIL

文章详情

深耕前端与后端开发技术的一线实战笔记与踩坑复盘。

Waza 技能路由机制全解析:从触发词匹配到歧义消解的完整工程实践

Waza 技能路由机制全解析:从触发词匹配到歧义消解的完整工程实践 【免费下载链接】Waza Engineering habits you already know, turned into skills Claude can run.项目地址https://gitcode.com/gh_mirrors/cl/Waza点击查看免费下载Waza 是一个把工程师既有习惯沉淀为 AI Agent 可执行技能的开源项目而 rules/waza-routing.md 正是这套技能体系的路由总纲它用一张 8 行路由表把用户说了什么映射到该调用哪个技能并规定了歧义出现时的消解纪律。本文以该路由文档为主体结合仓库内的 skills/RESOLVER.md完整路由索引、scripts/verify_skills.py路由一致性校验、scripts/setup-rule.sh路由规则安装器等源码从触发词设计、匹配机制、防漂移校验、歧义消解到安装落地给你一套可复制、可验证的技能路由实战方案。读完本文你将掌握Waza 八大技能的触发词边界与设计意图、路由表与 SKILL.md 元数据之间的绑定校验原理、多技能同时命中时的 11 条消解规则、技能串联的工作流编排方式以及如何在自己的 Agent 环境中安装并验证这条路由规则。为什么需要一张技能路由表Waza 定位为工程习惯而非编码脚手架——它交付的是/think、/ui、/check、/hunt、/write、/learn、/read、/health八个技能。问题在于用户并不会每次都说请调用 /think 技能他们说的是帮我看看这个方案值不值得做。路由表要解决的正是这个语义鸿沟把自然语言请求尤其是中英混合的日常表达映射到唯一且正确的技能。路由文档开宗明义地给出了两条铁律命中即优先当请求匹配某个触发词时优先使用对应技能而不是用一个通用实现从头重写工作流Do not reimplement the workflow from scratch禁止静默二选一两个技能都匹配时先读两个SKILL.md的 Not for 段来消解歧义仍然模糊就询问用户绝不悄悄选一个Never silently pick one。这两条纪律保证了路由不是概率猜谜而是一套有明确退出路径的决策流程。八大技能路由表触发词、适用场景与设计意图路由文档的核心是下面这张表。每个技能一行use when列混合了英文场景描述与中文用户原话引号内短语即用户可能逐字输入的触发词skilluse whenthinknew feature / architecture / 怎么设计 / 有没有必要 / 值不值得 / product judgmentuiUI / page / component / frontend / typography / screenshot says 丑/不清晰/不和谐checkreview / 看看代码 / pre-merge / release / push / close issue / project audithunterror / crash / regression / test failure / 以前是好的 / screenshot proves regressionwritedraft / rewrite / proofread / 去 AI 味 / tweet / launch copy / document reviewlearndeep dive into an unfamiliar domain / compile a batch of sources into one articlereadmessage contains an http(s) URL or PDF path / 看这个链接 / 读一下healthClaude/Codex/Pi ignores instructions / hook misfire / config drift / agent config audit / rot从触发词可以读出每个技能的设计意图这与各 SKILL.md 的 frontmatter 元数据一一对应think动手前new feature、architecture、product judgment属于要不要做、怎么做的判断类请求。对应 skills/think/SKILL.md 的when_to_use怎么设计, 用什么方案, 有没有必要, 值不值得, whats the best approach, plan this...与dispatch_intentNew feature, architecture, how should I design this, value judgment, executable plan, handoff。ui动手前页面、组件、前端、排版以及截图说丑/不清晰/不和谐这类审美校准请求。注意它与hunt的分工截图审美问题归ui截图证明以前好的现在坏了的回归归hunt。check交付前review、合并前检查、release、push、关闭 issue、项目审计——一切交付把关动作。hunt出问题error、crash、regression、测试失败、以前是好的。对应 skills/hunt/SKILL.md 的when_to_use排查, 报错, 崩溃, 回归, 截图回归, debug, regression, used to work, why broken...其核心纪律是定位根因之前不许动代码。write内容输出草稿、改写、校对、去 AI 味、推文、launch copy、文档审阅。learn内容输入深入陌生领域研究、把一批资料编译成一篇文章。read内容输入消息中含 http(s) URL 或 PDF 路径、看这个链接、读一下。health元层Agent 自身出问题——Claude/Codex/Pi 忽略指令、hook 失灵、配置漂移、Agent 配置审计、AI coding 腐化rot。它与hunt的关键区别agent 配置/维护性问题归health用户代码抛异常归hunt。这张表本身是给人看的浓缩版。更完整的分阶段路由表Pre-build / Post-build / Diagnostic / Content 四类场景含release、triage、audit等子模式位于 skills/RESOLVER.md并明确说明Claude Code 实际是通过每个 SKILL.md 的description自动匹配技能RESOLVER.md 是集中索引与校验依据——改 SKILL.md 的适用范围时同步改这里。路由的底层机制SKILL.md 元数据契约路由表不是凭空维护的文字它由每个 SKILL.md 的 YAML frontmatter 驱动。以 scripts/skill_frontmatter.py 的parse_frontmatter实现为准Waza 的 frontmatter 刻意保持精简只允许四个顶层标量name必须与技能目录名一致如think否则校验直接失败NAME MISMATCHdescriptionAgent 解析器首先看到的字段要求以动词/动作短语开头、长度在 40500 字符之间、必须包含 Use when 与 Not for 两段check_description_conformance强制因为部分 Agent 运行时在读到 when_to_use 之前先看 description、且公开元数据必须纯英文CJK 内容放在when_to_usewhen_to_use逗号分隔的中英触发词清单路由表的引号短语必须在这里落地生根dispatch_intent供 scripts/build_metadata.py 生成 dispatcher 路由表使用。为什么 description 里强制要求 Not for从 scripts/checks_content.py 的注释可以读出设计意图消歧不只在路由表层面发生description 本身就要教会解析器什么时候不该触发。这让check与hunt都是帮我看看、ui与hunt都涉及截图这类高危重叠对在元数据层面就有了第一道排除机制。触发词接地校验引号短语必须有技能认领路由表里最容易被忽略的细节是use when列中所有带引号的短语都被视为用户会逐字输入的断言。为此 scripts/checks_routing.py 实现了check_waza_routing_triggers其逻辑是用QUOTED_PHRASE_RE提取表格中的引号内容——这个正则同时覆盖直引号、弯引号U201C/D以及中文书名号「」『』保证中文短语被同等对待将引号短语按/切分、去除空白后逐一检查是否出现在对应技能的when_to_use中只要有一个短语缺失就报WAZA ROUTING UNGROUNDED TRIGGER提示只能引用用户真正会输入的短语要么对齐 when_to_use要么把它加进 when_to_use。这就是为什么路由文档中怎么设计有没有必要这类短语能在 skills/think/SKILL.md 的when_to_use里逐字找到——路由表永远不会宣传一个技能并未声明的触发词。而未加引号的英文场景词如architecture、review属于自由措辞有意不做此项校验保持路由表可读性。结构漂移校验路由表必须与技能集精确对齐触发词之外路由表还受到两层结构一致性保护第一层路由表 vs 技能目录。check_waza_routing_skills逐行解析rules/waza-routing.md的 Markdown 表格提取合法的技能名匹配[a-z][a-z0-9_-]*然后与skills/*/SKILL.md目录做集合差技能存在但路由表缺失 →WAZA ROUTING MISSING SKILLS路由表列出了不存在的技能 →WAZA ROUTING STALE SKILLS。也就是说新增或删除任何一个技能路由表必须同步增删行否则 scripts/verify_skills.py 会在python3 scripts/verify_skills.py时直接以非零码退出。这保证了人看的索引与模型看到的 SKILL.md永远锁步。第二层dispatcher 与 RESOLVER 对齐。scripts/check_routing_drift.py 额外要求 scripts/dispatcher.md 与 skills/RESOLVER.md 引用完全相同的技能名集合。dispatcher 是 Waza 以宿主插件方式安装时的统一入口其路由表由build_metadata.py从各技能的dispatch_intent自动生成!-- routing-table:start --与!-- routing-table:end --之间的表格即生成产物因此这个脚本被定位为生成逻辑旁边的廉价绊线sanity tripwire。值得一提的是verify_skills.py是纯驱动入口校验逻辑全部拆分到可导入的兄弟模块checks_content.py、checks_distribution.py、checks_routing.py从而可以被 tests/python/ 下的单元测试直接 import 测试。这是路由这种易腐化文档能长期保持可信的制度保障。歧义消解从二元冲突到 11 条决策规则路由文档给出了消解的第一原则两个技能都匹配时先读两个 SKILL.md 的 Not for 段仍模糊就问用户绝不静默二选一。而 skills/RESOLVER.md 在此基础上把常见冲突固化为 11 条可执行的消解规则按冲突类型可归纳为六组最具体优先/ui比/think更具体仅限 UI 决策帮我设计登录页优先/uiURL 二次分流消息含 URL → 先走/read取回 Markdown要总结/分析就继续是长文研究素材再接/learn改错 vs review代码已交付/走到 PR →/check代码跑不通/行为错了 →/hunt。两者都可能命中帮我看看按有没有具体错误现象判断Agent 配置异常 vs 代码错误Claude/Codex 不听话、hook 不触发、MCP 掉链子、AGENTS/CLAUDE/config.toml 漂移、/health消耗 token、AI coding 腐化 →/health用户代码抛异常 →/hunt发布动作 vs 发布文案写 release notes/changelog →/write提交、打 tag、publish、push、补 release reactions、回复/关闭 issue →/check截图审美 vs 截图回归说丑/不好看/不清晰且是审美校准 →/ui截图证明以前好的现在坏了、渲染错、状态错、生成物错 →/hunt从零成稿 vs 润色从零到成稿 →/learn已有稿子要改 →/write判断 vs 调试报错/异常/不工作 →/hunt有没有必要/该不该保留/值不值得 →/think的 Evaluation Mode质量改善 vs 调试有可审 diff、要改善质量且无报错 →/check有具体报错或回归 →/hunt需求包 vs issue 队列对象是未实施的一批诉求/截图判断接受与否→/thinkTriage Mode对象是仓库里已存在的 issue/PR处置、回复、关闭→/checkTriage Mode兜底两者都模糊时读两个 SKILL.md 的 Not for 段用排除法仍模糊就问用户。这些规则的共同特征是把表面相似的请求拆成可判断的维度有没有错误现象、是动作还是文案、是审美还是回归、是从零还是改稿每一维都有明确的归属。verify_skills.py里还有一道自动化防线check_trigger_overlap当两个技能的when_to_use关键词集合 Jaccard 相似度 ≥ 0.5 时直接失败——从源头阻止触发词大面积重叠把人工消解的工作量压到最低。技能串联路由之后的编排纪律路由决定用哪个技能而 skills/RESOLVER.md 的 Chaining 一节决定了多个技能如何接力。核心原则是技能边界用于分工不缩小用户已授权的任务——单项请求不自动扩大同一请求明确包含多个技能的工作时按对应技能继续完成、共用完成清单不在内部交接点再次索要授权但提交、发布等动作仍需其对应授权。最常见的四条工作流与 scripts/dispatcher.md 的 Chaining 一节完全一致规划功能/think出方案 → 用户说实现 → 实施 → 用户说/check→ 把关合并修复发布/hunt定位根因 → 用户说修 → 修复 → 用户说/check→ 发布前检查与收尾push / 关闭 issue研究与写作/read取回多篇 URL→ 用户说/learn综合成文→ 用户说/write去 AI 味调试与验证/hunt定位根因→ 修复 →/check确认无副作用/health发现配置问题 → 修复 → 再跑一次/health复验。每个技能只在自己的请求结果处停止/think交付决策完备的计划/hunt交付根因句 验证结果接力必须由用户显式授权触发而不是技能自行推断后续动作。把路由规则安装进你的 Agentrules/waza-routing.md有两个落地形态形态一随技能安装八技能之一。通过 README 中的安装命令npx skills add tw93/Waza -a claude-code codex cursor -g -y安装后八大技能以/check、/think等斜杠命令形式出现宿主插件形态/plugin marketplace add tw93/Waza则按命名空间waza:check调用。形态二作为常驻规则安装可选。路由提示需要写进 Agent 的持久指令才生效由 scripts/setup-rule.sh 完成bash $WAZA_RULE_SCRIPT waza-routing claude-codesetup-rule.sh的第二个参数支持三个目标落点各不相同目标落点形式claude-code~/.claude/rules/waza-routing.md独立规则文件codex~/.codex/AGENTS.md标记块!-- Waza Routing: start --…!-- Waza Routing: end --antigravity-cli~/.gemini/antigravity-cli/rules/waza-routing.md独立规则文件从源码看这个安装器有几个值得注意的工程细节标记块幂等Codex 目标用!-- Waza Routing: start --/!-- Waza Routing: end --包裹内容重复运行会替换旧块而不是叠加MARKER_LABEL对waza-routing有显式覆盖为Routing避免生成Waza Waza Routing这种重复标记原子下载先下载到临时文件完整后才mv覆盖中途失败含 Ctrl-C / kill绝不触碰已安装的规则下载失败时明确提示Existing Waza files were left untouched版本钉扎WAZA_REF默认钉在发布标签如v3.39.0可用WAZA_REFmain切换到主线脚本且会校验格式必须是main或vX.Y.Z。这个安装行为有专门的集成测试覆盖tests/test_routing-installer.sh 用桩 curl 验证了三条路径——Claude Code 目标把规则落进~/.claude/rules/waza-routing.md、Codex 目标用标记注入且重复执行后!-- Waza Routing: start --仍只有一处幂等性断言、内容正确写入AGENTS.md。卸载时按 README 删除对应规则文件即可rm -f ~/.claude/rules/waza-routing.mdCodex 则移除~/.codex/AGENTS.md中的 Waza 标记块删除后需开启新会话生效。从源码结构看路由体系的设计取向综合 skills/RESOLVER.md 的 Latent vs Deterministic 一节与上述校验脚本可以提炼出 Waza 路由设计的两个取向路由判断是fat skill而非硬编码触发词匹配、场景判断、追问用户都属于需要模型语义理解的潜变量latent因此放在 Markdown 技能文档与路由表中人工调优而同入同出、纯校验列举的约束如引号短语必须接地路由表必须与技能集对齐则下沉为脚本与规则verify_skills.py、checks_routing.py、rules/*.md用确定性代码兜底。新加能力时的决策问题是需要判断/适应场景/追问用户 → 做成 skill只是校验和列举 → 做成 script 或 rule。不要把 lint 检查写成 skill也不要把怎么研究一个陌生领域塞进脚本。路由表是被防漂移机制保护的可信文档rules/waza-routing.md浓缩版、skills/RESOLVER.md完整版、scripts/dispatcher.md自动生成版三份路由索引各自通过check_waza_routing_skills、check_waza_routing_triggers、check_resolver、check_routing_drift.py四道校验互锁插件分发形态下plugins/waza/rules/waza-routing.md是build_metadata.py从根目录规则生成的镜像同样纳入校验范围。这种文档即代码、变更必验证的做法正是 Waza 想通过rules/waza-routing.md示范的工程习惯——连 Agent 技能的路由规则本身也要像生产代码一样接受漂移检测。小结rules/waza-routing.md虽是一张 8 行的表格背后却是一套完整的技能路由工程frontmatter 元数据定义触发能力、引号短语接地校验保证路由表不撒谎、结构漂移检查保证三份路由索引与技能集锁步、11 条消解规则处理重叠、串联纪律约束接力授权最后通过setup-rule.sh以幂等、原子的方式落地到你的 Agent 常驻指令中。无论是为 Waza 扩展新技能还是在自己的 Agent 项目里建立类似的路由体系这张表与其配套校验脚本都值得直接借鉴。赞分享【免费下载链接】Waza Engineering habits you already know, turned into skills Claude can run.项目地址https://gitcode.com/gh_mirrors/cl/Waza点击查看免费下载相关推荐Waza Skill Resolver 路由机制全解析触发词路由表、歧义消解与技能串联实战指南Waza Skill Resolver 路由机制全解析触发词路由表、歧义消解与技能串联实战指南 Waza 是一个把工程师日常习惯沉淀为 Claude 可运行技Waza 技能路由指南八项工程技能的正确分发、歧义消解与串联执行Waza 技能路由指南八项工程技能的正确分发、歧义消解与串联执行 Waza 是一套把开发者早已熟悉的工程习惯固化为 Claude 等 Agent 可运行技能ANTLR4 C 语法中 type_ 规则的语义谓词消歧从符号表到解析树的完整实战解析ANTLR4 C 语法中 type_ 规则的语义谓词消歧从符号表到解析树的完整实战解析 本篇文章以 grammars v4 仓库中 C v8 语法 csha编程语言编译器开发工具上一篇抖音无水印下载工具实战指南从单条视频到主页批量备份下一篇Mac Mouse Fix 完整使用指南快速把普通鼠标变成准触控板创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考
返回列表