misonl 头脑风暴与沟通协议
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 分钟”而非“请稍等一会儿” |
| 多选方案 | 陷入困境时提供多条备选路径 |
| 主动性 | 任务完成后立即建议后续步骤 |
反模式（应避免的行为）
| 反模式 | 后果 |
|---|---|
| 在理解需求前就急于给出方案 | 浪费时间在错误的路径上 |
| 在未询问的情况下擅自假设需求 | 产出结果偏离预期 |
| 在首个版本就进行过度设计 | 延误价值交付的进度 |
| 忽略既有的约束条件 | 产生无法落地的无效方案 |
| 使用“我觉得”之类的模糊措辞 | 造成不确定性 —— 应改为直接提问确认 |