brainstorm

头脑风暴

通过自适应的结构化提问，将模糊想法转化为明确、可执行的成果。此技能会根据用户的实际需求调整深度和输出格式，从快速生成想法到全面的提示词工程。

快速开始

1. 用户提出请求（模糊想法、头脑风暴请求或需要改进的提示词）
2. 分流——将请求归类为三种模式之一：提示词、探索或聚焦
3. 运行相应的探索流程（根据模式提出 3–7 个问题）
4. 针对相应模式生成合适的输出
5. 提供后续步骤

工具

工具	用途
AskUserQuestion	每次只向用户提一个问题。Claude Code：使用带有 options 的原生 AskUserQuestion（参见下文的 AskUserQuestion 用法）。Copilot：使用带有 choices 的 ask_user。Kiro/其他：使用带编号选项的纯文本。
WebSearch	当用户没有参考资料，且参考资料确实有帮助时，查找相关资料。Claude Code：WebSearch。Copilot/Kiro：web_search。
Agent	委派给 Plan 子 Agent。Claude Code：Agent(subagent_type: "Plan")。Copilot：task(agent_type: "general-purpose") + # Role: Planner 代码块。Kiro：use_subagent。回退方案：直接创建计划。

AskUserQuestion 用法

即使 API 支持一次最多提 4 个问题，每次调用也只提 一个问题——提多个问题会让回答变得浅显。

每个问题都需要包含：

• question：清晰的问题文本，以 ? 结尾
• header：简短标签（最多 12 个字符），显示为小标签，例如 "Goal"、"Priority"、"Approach"
• options：包含 2–4 个选项的数组——每个选项均包含 label（1–5 个词）和 description（解释权衡取舍）。系统会自动添加 "Other"，请勿自行添加。
• multiSelect：仅当选项并非互斥时设为 true。否则省略（默认值为 false）。

将推荐选项放在第一位，并在其标签末尾附加 "(Recommended)"。

示例： {"questions": [{"question": "Which matters more?", "header": "Priority", "options": [{"label": "Speed (Recommended)", "description": "Ship fast, iterate later"}, {"label": "Quality", "description": "Get it right the first time"}]}]}

核心原则

1. 理解之前不要作答。 急于提供帮助会产出泛泛而谈的内容。但“理解”并不意味着“提 13 个问题”——而是指掌握足够的信息，能够给出具体的回答。
2. 通过工具一次提一个问题。 多个问题会让回答变得浅显。使用 AskUserQuestion（Claude Code）、ask_user（Copilot），或在最后不得已时使用纯文本——但始终一次只提一个问题。
3. 优先使用选择题。 当答案范围可预期时，提供选项。选择题回答更快、认知负担更低，也能体现用户偏好。只有在答案确实无法预判时才使用开放式问题。
4. 沿用用户的表达方式。 不要引入用户没有使用过的术语。
5. 询问生活层面的问题，而非领域知识。 了解限制、风险和不可接受的情况无需任何领域知识，却能果断排除错误方向。
6. 不要重复询问已知信息。 记录初始请求和所有回答中提供的信息。
7. 尊重用户的时间。 根据请求的复杂程度调整提问深度。随口说一句“帮我头脑风暴”不需要像“帮我撰写一份详细提示词”那样严谨。

分流——选择合适的模式

提问之前，先阅读用户的请求，并将其归类为三种模式之一。此过程在内部完成——不要询问用户想选择哪种模式。

提示词模式

适用情况： 用户明确想要创建或改进提示词，或需要为其他 AI、工具或人员准备全面的简报。 信号： “改进这段提示词”“帮我写一段提示词”“ช่วยคิด prompt”“我想让 Claude……”，或提到要将输出用于另一个 AI。 流程： 完整探索流程（围绕目标 → 方向 → 背景 → 标准提出 5–7 个问题） 输出： 改进后的提示词 + 探索摘要

探索模式

适用场景： 用户想集思广益、探索各种可能性，或深入思考开放式问题。 信号： “集思广益”“帮我想想”“ช่วยคิดหน่อย”“我想做点什么，但是……”“我该……？”“有什么点子吗？” 流程： 简单了解（3–5 个问题）——快速弄清目标和限制，然后生成点子 输出： 精选点子／选项及其利弊，然后提出可以进一步探讨用户选定的方案

聚焦模式

适用场景： 用户有具体问题和现有背景信息，希望获得策略或建议。 信号： 提示词中已有具体信息（数字、技术栈、当前情况）。用户说“集思广益，想想怎么……”“如何减少……”“最好的方法是什么……” 流程： 有针对性地了解（0–2 个问题）——只询问确实未知的信息，跳过已说明的内容 输出： 可执行的策略／建议，并注明优先级和预估影响

按模式划分的工作流

有关各阶段详细的提问模式、技巧和示例，请参阅 references/QUESTIONING-GUIDE.md

---

提示词模式 — 全面了解需求

最全面的路径。当用户需要精心设计的提示词时，使用所有阶段。

阶段 1 — 接收： 确认用户的请求。可以这样说：“我来帮你完善这个提示词。先问几个问题，让它更符合你的情况。”

阶段 2 — 目标： 用户希望提示词实现什么目标？用一句话概括目标，并至少包含一个可衡量的指标。（1–2 个问题）

阶段 3 — 方向： 哪些事情绝对不能发生？有哪些可选方法？了解限制条件后，提出 2–3 种可行方法及其利弊。先给出你的推荐。（1–2 个问题 + 方案）

阶段 4 — 参考资料（可选）： 仅当参考资料确实有帮助时（例如风格／设计请求）才询问。问问用户是否有示例。如果没有且参考资料会有帮助，请使用 WebSearch。如果搜索结果不理想或没有结果，请告知用户，并询问是继续不使用参考资料，还是尝试其他搜索词。对于直接明了的请求，完全跳过此阶段。（0–1 个问题）

阶段 5 — 背景： 了解实际限制：时间、预算、技能、团队、环境。若与目标存在矛盾，委婉指出。（1–2 个问题）

阶段 6 — 标准： 明确“做好”的标准。如果标准超过 3 项，按优先级排序。（1 个问题）

阶段 7 — 综合： 按以下结构起草改进后的提示词：

## Improved Prompt

[The refined, specific prompt incorporating all discovered information]

---

### Discovery Summary

**Goal:** [One sentence with measurable indicator]
**Direction:** [Chosen approach and key constraints]
**Context:** [Practical constraints: time, budget, skills, environment]
**Criteria:** [Ranked evaluation criteria]

改进后的提示词必须完整自包含，包含所有内联限制条件，并且足够具体，让任何 AI 都能给出有针对性的回答。

展示提示词并询问：“这符合你的需求吗？有什么需要调整的吗？” 如有需要，继续迭代。

---

探索模式 — 简单了解需求

适用于用户想要点子，而不是提示词的开放式头脑风暴。

阶段 1 — 接收 + 快速了解目标： 先确认请求，然后通过提问工具（见“工具”表）提出一个问题，同时了解目标和动机，并提供“学习／赚钱／解决问题／构建作品集”等选项。（1 个问题）

阶段 2 — 限制条件： 用 1–2 个问题了解不可妥协的要求和实际限制。适合时，将相关限制（时间 + 预算，或技能 + 工具）合并为一个问题。（1–2 个问题）

阶段 3 — 生成： 根据已了解的信息，提出 5–8 个具体点子，按主题分类。每个点子都应包含：

• 点子的内容（一句话）
• 为什么符合该用户的限制条件
• 一个潜在挑战

阶段 4 — 缩小范围： 询问用户对哪些点子感兴趣。然后提供以下选项：

1. 深入探讨 一个点子（切换到提示词模式或制定计划）
2. 生成更多 特定方向的点子
3. 完成 — 带着这些点子开始行动

---

聚焦模式 — 定向发现

适用于用户已提供充分背景的具体问题。

阶段 1 — 确认背景： 总结你已从提示词中了解到的信息。明确列出已确定的内容，让用户知道你不会重复询问。

阶段 2 — 补充信息： 只询问会影响建议的真正未知事项。如果提示词提供的信息足够，你可以只问 1 个问题，甚至不问问题，直接给出建议。（0–2 个问题）

阶段 3 — 制定策略： 提供可执行的建议：

• 按优先级列出（先列快速见效的，再列需要更多投入的）
• 每项说明：要做什么、预期影响、所需投入、风险
• 明确建议从哪里着手

阶段 4 — 优化： 询问是否需要调整。提供通过 Plan 子 Agent 制定实施计划的选项。

---

下一步

无论采用哪种模式，在给出结果后，都使用 AskUserQuestion（或在不可用时使用 ask_user / 纯文本）提供后续选项：

• 制定计划 — 委托给 Plan 子 Agent：Agent(subagent_type: "Plan")（Claude Code）、使用 task(agent_type: "general-purpose") 并添加 # Role: Planner 内容块（Copilot）、使用 use_subagent（Kiro），或者在没有可用子 Agent 时直接制定计划
• 深入探讨 — 继续探索某个具体方面
• 结束 — 结束工作流

边界情况处理

用户希望跳过提问： 尊重这一选择。根据现有信息给出最佳结果。简要说明缺少的信息：“由于不了解 [X]，内容可能会比较笼统，但这是我目前的建议。”

用户表示“不知道”： 提供 2–3 个具体选项，供用户选择。用户的反应可以揭示偏好，无需具备专业知识。

用户的回答存在矛盾： 中立地指出：“你之前提到了 X，但 Y 似乎有所不同。我们应该优先考虑哪一个？”

范围过广，无法在一次会话中完成： 建议拆分问题，并分别处理每个部分。

对话中途发现模式不合适： 进行切换。如果你从探索模式开始，但用户显然需要详细提示词，就切换到提示词模式。无需重新开始，沿用已有信息即可。