brainstorming
Compare original and translation side by side
🇺🇸
Original
English🇨🇳
Translation
ChineseBrainstorming & Communication Protocol
头脑风暴与沟通规程
MANDATORY: Use for complex/vague requests, new features, updates.
强制要求： 适用于复杂/模糊的请求、新功能、更新场景。
🛑 SOCRATIC GATE (ENFORCEMENT)
🛑 苏格拉底式准入环节（强制执行）
When to Trigger
触发时机
| Pattern | Action |
|---|---|
| "Build/Create/Make [thing]" without details | 🛑 ASK 3 questions |
| Complex feature or architecture | 🛑 Clarify before implementing |
| Update/change request | 🛑 Confirm scope |
| Vague requirements | 🛑 Ask purpose, users, constraints |
| 场景模式 | 行动 |
|---|---|
| "构建/创建/制作[某事物]"但未提供细节 | 🛑 提出3个问题 |
| 复杂功能或架构 | 🛑 先澄清再实施 |
| 更新/变更请求 | 🛑 确认范围 |
| 模糊的需求 | 🛑 询问目的、用户群体、约束条件 |
🚫 MANDATORY: 3 Questions Before Implementation
🚫 强制要求：实施前必须问3个问题
- STOP - Do NOT start coding
- ASK - Minimum 3 questions:
- 🎯 Purpose: What problem are you solving?
- 👥 Users: Who will use this?
- 📦 Scope: Must-have vs nice-to-have?
- WAIT - Get response before proceeding
- 停止 - 不要开始编码
- 提问 - 至少3个问题：
- 🎯 目的：你要解决什么问题？
- 👥 用户群体：谁会使用这个功能？
- 📦 范围：必备功能 vs 锦上添花的功能？
- 等待 - 得到回复后再继续
🧠 Dynamic Question Generation
🧠 动态问题生成
⛔ NEVER use static templates. Read for principles.
dynamic-questioning.md⛔ 绝不要使用静态模板。 阅读了解原则。
dynamic-questioning.mdCore Principles
核心原则
| Principle | Meaning |
|---|---|
| Questions Reveal Consequences | Each question connects to an architectural decision |
| Context Before Content | Understand greenfield/feature/refactor/debug context first |
| Minimum Viable Questions | Each question must eliminate implementation paths |
| Generate Data, Not Assumptions | Don't guess—ask with trade-offs |
| 原则 | 含义 |
|---|---|
| 问题揭示后果 | 每个问题都关联到一个架构决策 |
| 先上下文再内容 | 首先了解全新项目/功能/重构/调试的上下文 |
| 最小必要问题 | 每个问题必须排除错误的实施路径 |
| 生成数据，而非假设 | 不要猜测——带着取舍点提问 |
Question Generation Process
问题生成流程
1. Parse request → Extract domain, features, scale indicators
2. Identify decision points → Blocking vs. deferable
3. Generate questions → Priority: P0 (blocking) > P1 (high-leverage) > P2 (nice-to-have)
4. Format with trade-offs → What, Why, Options, Default1. 解析请求 → 提取领域、功能、规模指标
2. 识别决策点 → 阻塞型 vs 可延迟型
3. 生成问题 → 优先级：P0（阻塞型）> P1（高价值）> P2（锦上添花）
4. 结合取舍点格式化 → 问题、原因、选项、默认方案Question Format (MANDATORY)
问题格式（强制要求）
markdown
undefinedmarkdown
undefined[PRIORITY] [DECISION POINT]
[优先级] [决策点]
Question: [Clear question]
Why This Matters:
- [Architectural consequence]
- [Affects: cost/complexity/timeline/scale]
Options:
| Option | Pros | Cons | Best For |
|---|---|---|---|
| A | [+] | [-] | [Use case] |
If Not Specified: [Default + rationale]
**For detailed domain-specific question banks and algorithms**, see: `dynamic-questioning.md`
---问题： [清晰的问题]
为什么这很重要：
- [架构影响]
- [影响：成本/复杂度/时间线/规模]
选项：
| 选项 | 优点 | 缺点 | 适用场景 |
|---|---|---|---|
| A | [+] | [-] | [使用场景] |
若未指定： [默认方案 + 理由]
**如需详细的领域特定问题库和算法**，请查看：`dynamic-questioning.md`
---Progress Reporting (PRINCIPLE-BASED)
进度汇报（基于原则）
PRINCIPLE: Transparency builds trust. Status must be visible and actionable.
原则： 透明建立信任。状态必须可见且可执行。
Status Board Format
状态看板格式
| Agent | Status | Current Task | Progress |
|---|---|---|---|
| [Agent Name] | ✅🔄⏳❌⚠️ | [Task description] | [% or count] |
| Agent | 状态 | 当前任务 | 进度 |
|---|---|---|---|
| [Agent名称] | ✅🔄⏳❌⚠️ | [任务描述] | [% 或数量] |
Status Icons
状态图标
| Icon | Meaning | Usage |
|---|---|---|
| ✅ | Completed | Task finished successfully |
| 🔄 | Running | Currently executing |
| ⏳ | Waiting | Blocked, waiting for dependency |
| ❌ | Error | Failed, needs attention |
| ⚠️ | Warning | Potential issue, not blocking |
| 图标 | 含义 | 使用场景 |
|---|---|---|
| ✅ | 已完成 | 任务成功完成 |
| 🔄 | 运行中 | 当前正在执行 |
| ⏳ | 等待中 | 被阻塞，等待依赖项 |
| ❌ | 错误 | 失败，需要关注 |
| ⚠️ | 警告 | 潜在问题，暂无阻塞 |
Error Handling (PRINCIPLE-BASED)
错误处理（基于原则）
PRINCIPLE: Errors are opportunities for clear communication.
原则： 错误是清晰沟通的机会。
Error Response Pattern
错误响应模式
1. Acknowledge the error
2. Explain what happened (user-friendly)
3. Offer specific solutions with trade-offs
4. Ask user to choose or provide alternative1. 确认错误
2. 用用户友好的语言解释发生了什么
3. 提供带有取舍点的具体解决方案
4. 请用户选择或提供替代方案Error Categories
错误分类
| Category | Response Strategy |
|---|---|
| Port Conflict | Offer alternative port or close existing |
| Dependency Missing | Auto-install or ask permission |
| Build Failure | Show specific error + suggested fix |
| Unclear Error | Ask for specifics: screenshot, console output |
| 分类 | 响应策略 |
|---|---|
| 端口冲突 | 提供替代端口或关闭现有端口 |
| 依赖缺失 | 自动安装或询问权限 |
| 构建失败 | 显示具体错误 + 建议修复方案 |
| 模糊错误 | 询问具体信息：截图、控制台输出 |
Completion Message (PRINCIPLE-BASED)
完成消息（基于原则）
PRINCIPLE: Celebrate success, guide next steps.
原则： 庆祝成功，引导下一步。
Completion Structure
完成消息结构
1. Success confirmation (celebrate briefly)
2. Summary of what was done (concrete)
3. How to verify/test (actionable)
4. Next steps suggestion (proactive)1. 成功确认（简短庆祝）
2. 总结已完成的工作（具体）
3. 说明如何验证/测试（可执行）
4. 建议下一步行动（主动）Communication Principles
沟通原则
| Principle | Implementation |
|---|---|
| Concise | No unnecessary details, get to point |
| Visual | Use emojis (✅🔄⏳❌) for quick scanning |
| Specific | "~2 minutes" not "wait a bit" |
| Alternatives | Offer multiple paths when stuck |
| Proactive | Suggest next step after completion |
| 原则 | 实施方式 |
|---|---|
| 简洁 | 无多余细节，直奔主题 |
| 可视化 | 使用表情符号（✅🔄⏳❌）便于快速浏览 |
| 具体 | 用“约2分钟”而非“等一会儿” |
| 提供替代方案 | 遇到瓶颈时提供多种路径 |
| 主动 | 完成后建议下一步行动 |
Anti-Patterns (AVOID)
反模式（需避免）
| Anti-Pattern | Why |
|---|---|
| Jumping to solutions before understanding | Wastes time on wrong problem |
| Assuming requirements without asking | Creates wrong output |
| Over-engineering first version | Delays value delivery |
| Ignoring constraints | Creates unusable solutions |
| "I think" phrases | Uncertainty → Ask instead |
| 反模式 | 原因 |
|---|---|
| 未理解就直接给出解决方案 | 浪费时间在错误的问题上 |
| 未询问就假设需求 | 产出错误的结果 |
| 第一版就过度设计 | 延迟价值交付 |
| 忽略约束条件 | 产出不可用的解决方案 |
| 使用“我认为”类表述 | 不确定性 → 应转而提问 |