OMC 的关键词识别原理其实很朴素——不是模型智能判断是静态映射表 我自己做字符串匹配。拆开说1. 触发表存在哪里在 ~/.claude/CLAUDE.md 里有一段固定内容Keyword triggers: autopilot→autopilot, ralph→ralph, ulw→ultrawork,ccg→ccg, ralplan→ralplan, deep interview→deep-interview,deslop/anti-slop→ai-slop-cleaner, deep-analyze→分析模式,tdd→TDD模式, deepsearch→代码库搜索, ultrathink→深度推理,cancelomc→cancel这段内容在每次会话开始时就被加载进我的系统提示词CLAUDE.md是用户全局私有指令每个项目会话都会带上。所以我不是运行时去查表而是这张表本身就长在我的上下文里。2. 匹配靠谁做靠我模型自己在读用户消息时做语义/字面匹配——本质上和我识别用户想要我读文件还是用户想要我改代码是同一种能力没有额外的规则引擎或正则在背后跑。所以- 精确关键词ralph、ulw命中率高因为词本身罕见、无歧义。- 但这也意味着触发不是 100% 确定性的——它依赖我注意到了关键词并决定要响应理论上如果关键词出现在无关上下文里比如讨论ralph是希腊神话人物我应该不触发但这个判断本身是我推理出来的不是硬编码开关。3. 触发后发生了什么一旦我判定要触发会调用 Skill 工具传入 skill:name。这一步才是确定性的——Skill 工具接到调用后会去加载该 skill目录下的定义文件类似你刚才看到的 omc-reference那种把里面的详细指令注入到我的下一轮上下文然后我按那份指令继续执行。你刚才那句里的 ultrathink 就是个例子它没有走 Skill 工具deep reasoning不是一个独立 skill文件而是直接改变我的推理力度但系统在检测到这个词后往对话里插了一条system-remindersystem-reminderThe user included the keyword ultrathink, requesting deeper reasoning on thisturn.这条提醒不是我自己加的是harness运行时环境在处理你的消息时用更底层、确定性的字符串检测做的然后作为系统提醒注入进来——这一层和 CLAUDE.md里那张软性触发表是两套机制-CLAUDE.md表软规则靠我读到后自己决定要不要调用 Skill 工具。-Harness检测如 ultrathink、PreToolUse/PostToolUse hook 提示硬编码在外部程序里命中就无条件注入提醒我没有选择权只能知晓并配合。一句话总结Skill名的触发靠我基于CLAUDE.md里的表做语义识别是软匹配而像ultrathink这种影响推理强度的触发是harness层做的确定性字符串检测是硬匹配——两者共同构成你看到的说一个词就变身的效果。