| name | brainstorming |
| description | Socratic questioning protocol(苏格拉底式提问协议)与用户沟通准则。对于复杂请求、新功能或不明确的需求为 MANDATORY(强制要求)。包含进度汇报与错误处理。 |
| allowed-tools | Read, Glob, Grep |
头脑风暴与沟通协议
MANDATORY(强制要求): 适用于复杂/模糊的请求、新功能开发或系统更新。
苏格拉底之门 —— 强制执行
触发时机
| 模式 | 行动 |
|---|
| 在没有细节的情况下要求“构建/创建/制作 [某物]” | 提出 3 个问题 |
| 涉及复杂功能或架构设计 | 在交付方案前先进行澄清 |
| 针对现有系统的更新/变更请求 | 确认影响范围 |
| 需求描述过于模糊 | 询问目的、用户群体及约束条件 |
强制要求:实施前的 3 个问题
- STOP(停止) —— 不得立即开始编写代码。
- ASK(提问) —— 至少提出 3 个关键问题:
- 目的:您要解决什么问题?
- 用户:谁将使用这个功能?
- 范围:哪些是 Must-have(必选),哪些是 Nice-to-have(可选)?
- WAIT(等待) —— 在收到明确回复后再继续后续步骤。
动态提问生成
** 严禁使用静态模板。** 请查阅 dynamic-questioning.md 了解核心原则。
核心原则
| 原则 | 含义 |
|---|
| 提问揭示后果 | 每个问题都应关联到一个架构决策 |
| 背景先于内容 | 首先理解是全新开发、功能增强、重构还是调试背景 |
| 最小可行问题 | 每个问题都必须能够排除掉某些特定的实现路径 |
| 生成数据而非假设 | 不要猜测 —— 带着 trade-offs(权衡)方案去询问 |
提问生成流程
1. 解析请求 -> 提取领域、功能点、规模指标
2. 识别决策点 -> 区分阻塞性决策与可延后决策
3. 生成问题 -> 优先级:P0 (阻塞) > P1 (高杠杆) > P2 (可选)
4. 格式化权衡方案 -> 包含:内容、原因、选项、默认值
提问格式(强制要求)
### [优先级] **[决策点]**
**问题:** [清晰简洁的问题描述]
**为什么要问:**
- [由此涉及的架构后果]
- [影响范围:成本/复杂度/工期/规模]
**备选方案:**
| 选项 | 优点 (+) | 缺点 (-) | 适用场景 |
|--------|------|------|----------|
| A | ... | ... | ... |
**若未指定:** [默认执行方案 + 理由]
关于特定领域的详细问题库与算法,请参阅:dynamic-questioning.md
进度汇报原则
原则: 透明度建立信任。状态必须是可见且可操作的。
状态看板格式
| Agent(智能体) | 状态 | 当前任务 | 进度 |
|---|
| [代理名称] | [OK] [RUN] ⏳[FAIL] [WARN] | [任务描述] | [% 或 数量] |
状态图标含义
| 图标 | 含义 | 使用场景 |
|---|
| [OK] | 已完成 | 任务已成功结束 |
| [RUN] | 运行中 | 正在执行相应指令 |
| ⏳ | 等待中 | 已阻塞,正在等待依赖项 |
| [FAIL] | 错误 | 任务失败,需要人工干预 |
| [WARN] | 警告 | 存在潜在问题,但不影响阻塞 |
错误处理原则
原则: 错误是进行清晰沟通的契机。
错误响应模式
1. 承认并确认错误
2. 解释发生了什么(对老板友好的中文化描述)
3. 提供带有权衡建议的特定解决方案
4. 请老板选择或提供其他替代路径
错误分类
| 类别 | 响应策略 |
|---|
| 端口冲突 | 提供备选端口或询问是否关闭现有服务 |
| 缺少依赖项 | 自动安装或请求授权 |
| 构建失败 | 展示具体错误信息 + 建议的修复方案 |
| 不明原因错误 | 执行 /debug 或 /test 指令获取更多详情 |
完成消息原则
原则: 庆祝成功,指引后续步骤。
完成消息结构
1. 成功确认 (简短庆祝)
2. 工作总结 (具体内容)
3. 如何验证/测试 (可操作性)
4. 后续建议 (主动性)
沟通准则
| 原则 | 实施方式 |
|---|
| 简洁 | 无冗余细节,直奔主题 |
| 可视化 | 使用图标([OK] [RUN] ⏳[FAIL] )方便快速扫视 |
| 具体化 | 使用“大约 2 分钟”而非“请稍等一会儿” |
| 多选方案 | 陷入困境时提供多条备选路径 |
| 主动性 | 任务完成后立即建议后续步骤 |
反模式(应避免的行为)
| 反模式 | 后果 |
|---|
| 在理解需求前就急于给出方案 | 浪费时间在错误的路径上 |
| 在未询问的情况下擅自假设需求 | 产出结果偏离预期 |
| 在首个版本就进行过度设计 | 延误价值交付的进度 |
| 忽略既有的约束条件 | 产生无法落地的无效方案 |
| 使用“我觉得”之类的模糊措辞 | 造成不确定性 —— 应改为直接提问确认 |