wait-what：一个极简却高效的 AI 沟通技能

Fen9Pi2026/8/11大约 10 分钟

前言：AI 沟通的常见困境

用过 AI 的人都遇到过这种情况：

你问了一个问题，AI 回了一大段。你看了半天，没看懂它到底想说什么。

你让它解释一下，它又来了一大段，还是没说到点子上。

核心问题：AI 的表达方式不符合你的理解习惯，信息没有有效传达。

今天介绍一个极简但高效的 AI 技能——wait-what，只有几行配置，却能显著改善 AI 的沟通质量。

一、项目概览

wait-what 是一个开源的 AI 技能（Skill），来自 mattpocock/skills 仓库。

一句话说清楚：

当上一条消息没有传达清楚时，让 AI 重新表达——使用简化技术英语，提供上下文，使用通用语言。

项目地址：https://github.com/mattpocock/skills 技能路径：skills/productivity/wait-what/SKILL.md 作者：mattpocock 开源协议：未明确（开源仓库）

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 `CONTEXT.md`.

就这么简单。

但这个极简的技能却解决了一个重要的问题：AI 表达不清时，如何让它重新说人话。

二、为什么需要 wait-what？

AI 沟通的常见问题

问题 1：表达冗长

AI: 基于您提供的查询，我进行了深入分析，并从多个维度
   考虑了各种可能性，最终得出结论……（还没说到点子上）

你: 能不能直接说结论？

问题 2：术语堆砌

AI: 根据神经网络的反向传播算法，通过梯度下降优化
   损失函数，在多层级结构中……（全是术语，听不懂）

你: 能不能用大白话说？

问题 3：缺少上下文

AI: 这个方案是可行的。

你: 哪个方案？解决什么问题？为什么可行？

传统解决方案的局限

方案 1：手动重新提问

你得想怎么问更清楚
可能要问好几次
效率低

方案 2：忍受看不懂的表达

勉强理解
可能误解
浪费时间

方案 3：放弃使用 AI

因噎废食
错失 AI 价值

wait-what 的解决方案

核心思想：

当 AI 表达不清时，触发一个技能，让它用更清晰的方式重新表达。

三个关键要求：

提供上下文：不要直接说结论，先说背景
使用简化技术英语：ASD-STE100，限制词汇和语法复杂度
使用通用语言：来自 CONTEXT.md 的统一术语

流程图1

三、ASD-STE100 简化技术英语

什么是 ASD-STE100？

ASD-STE100（Simplified Technical English）是一种受控语言，最初用于航空航天领域的技术文档。

核心规则：

词汇限制：只使用 approved 单词表中的词
语法限制：简单的句子结构
明确性：一个词只有一个意思
简洁性：去掉冗余表达

为什么用 ASD-STE100？

1. 降低理解成本

复杂表达："
> "Utilizing the aforementioned methodology, we endeavor
> to facilitate the optimization of the aforementioned
> parameters."

简化表达：
> "We use this method to improve the parameters."

2. 避免歧义

可能有歧义：
> "The button can be triggered."

明确表达：
> "Press the button to start."

3. 提高效率

词汇量少：约 1000 个核心词
语法简单：主谓宾结构
直接表达：不绕弯子

ASD-STE100 的核心规则

词汇规则：

只使用 approved 单词
每个词只有一个意思
不使用缩写（除非是标准缩写）

语法规则：

简单的句子结构
主动语态
清晰的时态

写作规则：

一个句子表达一个意思
使用列表分解复杂内容
添加必要的上下文

四、wait-what 的实现

技能配置解析

---
name: wait-what
description: Stop. That last message did not land — re-pitch it.
disable-model-invocation: true
---

配置说明：

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 `CONTEXT.md`.

内容解析：

1. 触发场景

"Wait — I don't understand where you've got to here."

当上一条消息没有传达清楚时触发。

2. 重新表达要求

"Re-pitch that: give me a little bit of context"

提供上下文：

不要直接说结论
先说背景信息
说明你理解的问题是什么

3. 语言要求

"talk in ASD-STE100 Simplified Technical English"

使用简化技术英语：

限制词汇复杂度
简化句子结构
避免术语堆砌

4. 术语统一

"use the ubiquitous language from CONTEXT.md"

使用通用语言：

参考项目/团队的 CONTEXT.md
使用统一的术语
保持一致性

五、实际应用场景

场景 1：技术讨论

对话：

你: 这个微服务架构怎么设计？

AI: 采用 Spring Cloud 微服务框架，通过 Eureka 实现服务注册
   与发现，使用 Ribbon 做负载均衡，集成 Hystrix 实现断路器
   模式，配置 Zuul 网关……（全是技术名词）

你: wait-what

AI: 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 `CONTEXT.md`.

AI（重新表达）:
   这个系统有多个小服务。每个小服务做一件事。服务之间
   可以互相调用。我们用 Eureka 来发现服务。用 Ribbon 来
   分配请求。用 Hystrix 来防止故障扩散。用 Zuul 作为入口。

价值：

从技术名词堆砌 → 清晰的功能描述
从复杂句子 → 简单的主谓宾结构
提供了上下文（"这个系统有多个小服务"）

场景 2：产品需求

对话：

你: 这个功能怎么实现？

AI: 基于用户行为分析模型，结合协同过滤算法，整合实时
   数据流，构建个性化推荐引擎……（没说清楚为什么）

你: wait-what

AI（重新表达）:
   我们要给用户推荐他们喜欢的内容。

   首先，我们收集用户的行为数据。比如，用户看了什么、
   点了什么、买了什么。

   然后，我们用这些数据找规律。比如，喜欢 A 的人也喜欢 B。

   最后，根据这些规律，给用户推荐内容。

价值：

说明了背景（"我们要给用户推荐他们喜欢的内容"）
分步骤说明（"首先……然后……最后……"）
避免了术语（"协同过滤算法" → "找规律"）

场景 3：问题排查

对话：

你: 为什么接口响应慢？

AI: 经过性能分析，发现数据库连接池配置不当，导致高并发
   场景下连接等待时间过长，同时存在 N+1 查询问题……
   （技术细节，没说清楚影响）

你: wait-what

AI（重新表达）:
   接口慢是因为两个问题。

   第一个问题：数据库连接不够用。很多请求要等连接。
   这增加了等待时间。

   第二个问题：我们查询数据的方式低效。我们先查一次主表，
   然后对每条记录再查关联表。这叫 N+1 查询。如果有 100
   条记录，我们要查 101 次数据库。

   要修复这个问题，我们可以增加连接池大小，或者改用批量查询。

价值：

说明了两个具体问题
解释了为什么慢（"请求要等连接"、"要查 101 次数据库"）
提供了解决方案

六、设计理念

为什么这么简单？

wait-what 只有 6 行配置，不到 100 字的提示词。

为什么这么简单？

1. 只做一件事

不试图解决所有沟通问题
只解决"表达不清"这个问题
单一职责

2. 不调用模型

disable-model-invocation: true
纯文本替换，不需要模型推理
快速、高效、可控

3. 可组合

可以和其他技能组合使用
不和其他功能冲突
模块化设计

核心思想

这个技能的核心思想：

当沟通出现问题时，不要继续往下说，停下来，重新说清楚。

三个关键点：

1. 提供上下文

先说背景
说明你理解的问题
再说结论

2. 使用简化语言

限制词汇复杂度
简化句子结构
避免术语堆砌

3. 保持一致性

使用统一的术语
参考共同的上下文
保持语言风格一致

七、最佳实践

何时使用 wait-what？

使用场景：

AI 的表达太冗长
AI 的术语太多
AI 缺少上下文
AI 的逻辑不清晰

不使用场景：

AI 的表达已经很清晰
你只是想要更详细的解释
你在闲聊，不在工作

如何配置 CONTEXT.md？

CONTEXT.md 应该包含：

项目的核心术语
常用概念的统一定义
团队达成共识的词汇

示例：

# CONTEXT.md

## 核心术语

- 服务：独立的软件单元，提供特定功能
- 网关：系统的入口，处理所有外部请求
- 断路器：防止故障扩散的保护机制

## 常用概念

- 微服务：将一个大应用拆分成多个小服务
- 负载均衡：将请求分配到多个服务器
- 服务发现：自动找到可用的服务

如何集成到你的工作流？

步骤 1：创建 SKILL.md

# 在你的项目中创建 skills/productivity/wait-what/SKILL.md
mkdir -p skills/productivity/wait-what
cp <上面的内容> skills/productivity/wait-what/SKILL.md

步骤 2：配置 CONTEXT.md

# 在项目根目录创建 CONTEXT.md
# 添加核心术语和概念

步骤 3：触发技能

当 AI 表达不清时，说 "wait-what"
或者根据你的 Agent 配置触发

步骤 4：验证效果

检查 AI 的重新表达是否更清晰
提供反馈，优化技能

八、扩展与变体

变体 1：技术版本

---
name: wait-what-technical
description: Re-explain with more technical details.
disable-model-invocation: true
---

Wait — I don't understand the technical details here. Re-pitch
that: explain the technical implementation, use precise technical
terms, and include code examples if applicable.

变体 2：非技术版本

---
name: wait-what-non-technical
description: Re-explain for non-technical audience.
disable-model-invocation: true
---

Wait — I don't understand. Re-pitch that: explain it like I'm
five, avoid technical jargon, and use everyday examples.

变体 3：详细版本

---
name: wait-what-detailed
description: Re-explain with more context and details.
disable-model-invocation: true
---

Wait — I need more context. Re-pitch that: provide the background,
explain why this matters, break it down into steps, and give me
concrete examples.