用途
Wonder 用于扩展用户模糊请求中隐藏的含义。它的目标是围绕用户措辞中承载歧义的最小短语，持续追问该词或短语在当前语境下的含义，直到其边界足够清晰，并至少出现三个由用户确认的含义候选。
主要能力
- 一次只向用户提出一个问题。
- 在可用时使用 Codex Plan 模式中的 request_user_input，在 Claude 中可用时使用 AskUserQuestion，否则使用普通对话提问。
- 不为了填充内容而编造含义。
- 在生成多个选项后不立即完成 Wonder；选项只是探针，不是已收集的含义。只有用户选择、否定、修改或解释后，才算收集到一个含义候选。
- 进行词边界发现：关注用户词语的含义，持续追问用户的关键词或短语在当前语境下意味着什么，直到其边界清晰。
- 提问前先识别承载歧义的最小引用短语，询问该短语的含义，而不是实现选择或下一步行动。
- 第一个 Wonder 问题：围绕该词或短语推断若干可能的语义边界，然后询问哪个边界最接近。
- 不使用固定问题模板，而是根据用户措辞和该短语在语境中可能的含义生成边界候选，例如：该短语可能指代的最小具体产物、可能暗示的更大工作流/决策/运营模式、隐藏在短语背后的个人、组织或战略隐性知识。
- 选项之间的差异应在于含义的起点和终点，而不是同一含义的表面变体。表面变体、实现细节和分类子类型可在边界清晰后再问。
- 每个后续问题都必须围绕同一个词或短语，询问以下之一：这个词在这里包含什么？这个词在这里排除什么？哪个相近含义听起来相似但会是错的？什么未言明的假设让这个词对用户来说显而易见？
- 在仍处于 Wonder 阶段时，不切换到项目规划、功能选择、技术栈选择或验收标准。
使用方式
提问风格上，优先使用多项选择提示，以便用户快速回答，但将选项视为假设而非事实，并始终包含开放编辑选项。使用如下形式：
哪个隐藏含义最接近你的意思？ A. <候选含义> B. <候选含义> C. <候选含义> D. 其他 / 用自己的话编辑
如果用户选择 A-C，只记录他们选择或确认的含义。如果他们选择 D 或自由回答，记录他们的措辞。
访谈循环至少运行两个用户回合，除非用户明确表示第一个答案已经完整：
- 提出一个边界选择问题。
- 用户回答后，围绕同一个词的含义提出一个后续问题：它包含什么、排除什么、哪个相近含义是错的，或什么假设让这个词对用户来说显而易见。
- 将用户的回答记录为含义候选。
- 仅在至少三个由用户确认的候选出现后继续，然后交给 reflect。
绝不将模型生成的选项单独作为最终的 Wonder 输出。
输出
将至少三个由用户确认的含义候选写成 Markdown 列表：
- 含义 A — 一行解释
- 含义 B — 一行解释
- 含义 C — 一行解释
草稿契约
将列表写入 .symposium/scratch/socrates.md 中当前 ## Cycle N 下的 ### Wonder 部分。
如果没有活动循环，则创建：
User Input
<原始请求>
Cycle 1
Wonder
...
当至少三个由用户确认的含义候选被收集，且词边界足够清晰以便与用户意图比较时，停止并交给 reflect。
适用场景
适用于用户请求措辞模糊、需要先澄清关键词或短语含义再继续后续环节的场景，尤其是 Socrates 循环中的 Wonder 阶段。
限制
- 不编造含义来填充内容。
- 不将模型生成的选项单独作为最终输出。
- 在 Wonder 阶段不切换到项目规划、功能选择、技术栈选择或验收标准。
- 关于收费、价格、平台支持等具体信息，资料中暂未提供。