wait-what 精读:为什么『简洁一点』永远失败,而『等一下』能成功
wait-what 只有一句祈使句,却解决了所有冗长技能解决不了的问题。本文讲清楚『命名听者而不是输出』为什么是机制本身,对照 grill-with-docs 说明事前预防与事后纠偏这一对的关系,并用一次 commit 说明它为什么把作用域从一封信放宽到整个语境。
(本文读的是 mattpocock/skills 快照 5beb35b,2026-10-19,引用原文都能按文中路径回仓库核对。这是「逐个技能精读」系列的第四篇,聚焦 wait-what。)
三行正文,一句祈使句
skills/productivity/wait-what/SKILL.md 全文:
---
name: wait-what
description: "Stop. That last message did not land: re-pitch it."
disable-model-invocation: true
---
Wait, I don't understand where you've got to here. Re-pitch that: give me a little bit of context, talk in ASD-STE100 Simplified Technical English, and use the ubiquitous language from `GLOSSARY.md` (follow `GLOSSARY-MAP.md` to the right one if the repo has more than one).
真实触发路径最短的一个:你在任何对话里、任何技能运行中,发现自己在跳读,敲 /wait-what;agent 把刚才那段重讲一遍——补上你缺的前提,换成 ASD-STE100 简化技术英语,名词换回 GLOSSARY.md 里的项目用词。产出就是同一段对话里的另一条消息。它不写文件,只读一份词表。
它是这一批技能里唯一事后纠偏的一个。其余技能都在事前把问题挡掉。
它和「一般技能」的差别:命名的是听者,不是输出
这是整篇的核心。文档里有一节标题就叫 The name is the mechanism(名字就是机制)。
所有主流的「反啰嗦」方案都在描述输出:/tldr、/no-fluff、/talk-normal,或者干脆写「回答不超过 200 字」。这类指令的失败方式是可预测的:模型会照做,然后把词砍短——你得到的是更短、更碎、更难懂的片段。文档给了个更狠的说法:“A four-hundred-line concision skill still leaves the model verbose, because the model copies the length of the skill, not its request.”
wait-what 描述的是听者的状态。它不是「你说太多」,而是「我在这里跟丢了」。模型听到前者会削减输出,听到后者会退回去解释。文档把这两个动作的差别点破了:“An agent that hears ‘be brief’ writes clipped fragments. An agent that hears ‘wait, you lost me’ backs up and explains.”
所以它一次要到了两样东西:更少的词,以及你缺的那部分前提。只写「简洁一点」永远只能拿到前一半,而且拿的是错的那一半。
它有意识摒弃了什么
一、摒弃了输出规格。 没有一个字提到长度、格式、字数、条目数。要的是「更短且更清楚」,而这个组合写不进任何字数限制——因为它的正确性取决于听者的状态,不取决于计数。
二、摒弃了触发词。 和 grill-me、grill-with-docs 一样,它是 user-invoked(disable-model-invocation: true 加上 agents/openai.yaml 里的 allow_implicit_invocation: false)。模型不该自己觉得「用户可能没听懂」然后重讲——只有你知道你什么时候跟丢了。文档的说法是 “Only you know when you stopped following.”
三、摒弃了作用域的硬边界。 最初的正文写的是 “Re-pitch that last message”。后来一次专门的重构把它改成了 “Re-pitch that”。提交 006ca05 的说明把理由写得很清楚:
“Re-pitch that last message” pinned the correction to one message. “Re-pitch that” leaves the agent to judge how much of what it said failed to land, and is shorter.
两句话的信息量看起来一样,但作用域差很多:让你跟丢的东西通常不在一条消息里,通常是你从头就没看过的那段前提。把边界放宽,等于把「回溯多远」这个判断交给了更清楚情况的那一方。
四、摒弃了自造术语。 它不发明新词,而是复用你已经在用的词:ASD-STE100 提供语域(register),GLOSSARY.md 提供名词。文档的说法是这些材料“use the same tokens”——技能、全局 CLAUDE.md、GLOSSARY.md 说的是同一套词,所以敲这个技能不是一条新指令,而是一次提醒。这是很关键的区别:一条新指令要模型重新理解,一次提醒只是让它回到已经同意过的东西上。
五、摒弃了容错分支。 没有 GLOSSARY.md 怎么办?文档没写「如果没有则跳过」,而是直接说技能照常工作:“If you have no GLOSSARY.md… the skill still works. You lose only the domain-vocabulary half.” 少一个输入就少一半效果,不值得在技能里写一段 if-else。
六、摒弃了多说一个字的余地。 正文一句话加一个括号,全句结束。这里有个自我指涉的闭环:一个治啰嗦的技能,自己必须极短,否则它就在示范它反对的东西。
它和 grill-with-docs 是一对
这是本批三篇里最值得单独讲的关系。两者都在处理同一件事——你和 agent 之间的语言对不上——但介入时点相反:
grill-with-docs是事前预防:刚开始聊的时候就把词定下来,写进GLOSSARY.md,让自造术语根本没有机会出现。wait-what是事后纠偏:词已经出现了,你已经被绕晕了,它把话重讲一遍。
文档把这对关系说得很直接:wait-what “repairs one message after the fact. The real fix is a shared language agreed upfront, and that is grill-with-docs.”
但它没有因此把自己写小。它是一个通用修理工:任何对话、任何技能内部、任何时刻都能用,而且能连用两次而不退化。原因是它没给自己加限定——重讲是幂等的,第二次只是把你仍然缺的部分补上。
原文证据
docs/productivity/wait-what.md 里关于机制的那两句(快照 5beb35b):
The leading word is wait. “Be concise” is an instruction about the agent’s output, and the model obeys it by clipping words and losing you further. Wait is about your state.
Naming the listener asks for both halves at once: fewer words and the context you were missing.
以及作用域那次改动的提交说明(commit 006ca05):
“Re-pitch that last message” pinned the correction to one message. “Re-pitch that” leaves the agent to judge how much of what it said failed to land — and is shorter.
可迁移结论
- 给技能起一个 leading word,把机制压进名字里。 「等一下」这个词在模型预训练里已经带着「退回去解释」的行为,你不用花 token 定义它。自造词要自己付定义成本,模型已有的词是白拿的。
- 指向听者的状态,别指向输出。 任何「更简洁」「别啰嗦」式的禁令,都会把禁止的行为拉进上下文里,而且只会拿到砍断的结果。说清楚「我卡在哪」比说「你写太长」有效得多。
- 复用已有的 token。 让新技能读起来像一条你早就同意过的约定,而不是一条新规矩。它调用
CLAUDE.md和GLOSSARY.md的说法,而不是另起一套。 - 别把作用域钉死。 「重讲那段」比「重讲上一条消息」更准,因为跟丢的原因常常不在最后一条消息里。把「回溯多远」交给掌握上下文的那一方判断。
- 治啰嗦的技能必须自己极短。 否则它就是在示范它反对的东西——模型会照着技能的长度写。
wait-what 是这三篇里最反直觉的一个:它用一句话解决了一个所有长篇规范都解决不了的问题,而它能解决的原因恰恰在于——它说的不是「你该输出什么」,而是「我在这里掉了」。
讨论
用 GitHub 账号留言;评论保存在公开仓库chengshu-blog-discussions的 Discussions 里。也可通过 RSS 订阅后续文章。