Brainstorming 深度分析 - 实现机制

哲学如何转化为可执行的代码

Brainstorming技能的核心创新在于：将抽象的哲学原则转化为具体的、可执行的、智能体能够遵循的指令模式。

这不是关于"更好的对话技巧"，而是关于设计一套让智能体行为的约束系统。

实现架构：双重约束系统

约束层级结构

复制代码

┌─────────────────────────────────────────┐
│         元级约束 (Meta Constraints)        │
│    - "You MUST use this..."           │
│    - "HARD-GATE"                    │
└──────────────┬──────────────────────┘
               │
               ↓
┌─────────────────────────────────────────┐
│       流程约束 (Process Constraints)      │
│    - 强制检查清单                      │
│    - 流程图终点                      │
│    - 顺序执行要求                    │
└──────────────┬──────────────────────┘
               │
               ↓
┌─────────────────────────────────────────┐
│     行为约束 (Behavioral Constraints)    │
│    - "一次一个问题"                  │
│    - "2-3种方法"                    │
│    - "分节批准"                     │
└──────────────┬──────────────────────┘
               │
               ↓
┌─────────────────────────────────────────┐
│   认知约束 (Cognitive Constraints)       │
│    - 理性化警告                      │
│    - 反模式警告                      │
│    - 红色思维陷阱                   │
└─────────────────────────────────────────┘

每个约束层级解决不同层面的对齐问题。

具体实现机制

机制1：强制性描述 (Mandatory Description)

哲学原理：存在主义 - 意义必须通过对话创造

实现方式

yaml 复制代码

---
name: brainstorming
description: "You MUST use this before any creative work - creating features, building components, adding functionality, or modifying behavior. Explores user intent, requirements and design before implementation."
---

这如何产生效果？

描述的三个功能：

触发逻辑 (Trigger Logic)
- "MUST"触发技能调用
- "before any creative work"定义触发条件
- 这个描述实际上是自动化触发规则
行为约束 (Behavioral Constraint)
- "You MUST"不是建议，是指令
- 定义了智能体的边界行为
- 违反这个指令就是违反技能
预期设定 (Expectation Setting)
- 告诉智能体"探索意图、需求、设计"
- 告诉人类"这发生在实现之前"
- 建立双方的共同预期

为什么这个简单的描述如此重要？

没有这个描述：

复制代码

人类: "我需要一个待办应用"
智能体: "好的，我将开始构建..."

有这个描述：

复制代码

人类: "我需要一个待办应用"
智能体内部: "这属于'创造性工作'，触发brainstorming技能"
智能体外部: "让我们先讨论你想要什么样的待办应用"

描述本身就是自动化约束。

机制2：硬性门控 (Hard Gate)

哲学原理：确定性 vs 不确定性 - 建立认知投资

实现方式

markdown 复制代码

<HARD-GATE>
Do NOT invoke any implementation skill, write any code, scaffold any project, 
or take any implementation action until you have presented a design and 
the user has approved it. This applies to EVERY project regardless of 
perceived simplicity.
</HARD-GATE>

这如何产生效果？

1. 语法层面的强调

使用<HARD-GATE>标签的特殊语法：

视觉强调：在源码中突出显示
语义强调："HARD"传达不可协商性
边界标记：明确这是硬性约束，软性建议

2. 穷尽性列举

"Do NOT invoke any implementation skill, write any code, scaffold any project, or take any implementation action"

这覆盖了所有可能的实现行动：

implementation skill - 调用实现技能
write any code - 直接写代码
scaffold any project - 项目脚手架
take any implementation action - 任何实现行动

3. 条件定义

"until you have presented a design and the user has approved it"

明确两个条件：

条件A：你呈现了设计
条件B：用户批准了设计
两个条件都必须满足

4. 全局适用性

"This applies to EVERY project regardless of perceived simplicity"

防止"这个太简单，不需要设计"的理性化。

为什么这种格式有效？

智能体的自然倾向：

看到简单的指令就快速扫描
可能忽略软性建议
倾向于"找到漏洞"

硬性门控的对抗措施：

特殊语法强制关注
穷尽性列举没有漏洞
重复强调强化边界
明确条件防止模糊解释

这是与智能体的理性化倾向直接对抗的设计。

机制3：强制性检查清单 (Mandatory Checklist)

哲学原理：过程哲学 - 过程本身比结果更重要

实现方式

markdown 复制代码

## Checklist

You MUST create a task for each of these items and complete them in order:

1. **Explore project context** --- check files, docs, recent commits
2. **Offer visual companion** (if topic will involve visual questions)
3. **Ask clarifying questions** --- one at a time
4. **Propose 2-3 approaches** --- with trade-offs and recommendation
5. **Present design** --- in sections, get approval after each
6. **Write design doc** --- save and commit
7. **Spec self-review** --- inline check
8. **User reviews spec** --- get approval before proceeding
9. **Invoke writing-plans skill** --- the ONLY allowed next step

这如何产生效果？

1. 任务创建机制

"You MUST create a task for each of these items"

这不仅是检查清单------这是任务分解系统。

没有任务创建：

复制代码

智能体: "让我探索上下文，提问，展示设计..."
人类: "好的"
智能体: [直接进入实现]

有任务创建：

复制代码

智能体内部: "创建任务：探索项目上下文"
智能体外部: "让我先看看项目的当前状态..."

任务创建强制智能体：

每个步骤都有显式认知处理
可以追踪进度
不容易跳过步骤

2. 顺序执行约束

"complete them in order"

防止智能体：

跳到后面步骤
重新排序以"优化"
同时做多个步骤

3. 明确的边界条件

每个任务都有明确的：

做什么：Explore project context
怎么做：check files, docs, recent commits
何时做：按顺序

4. 终点状态定义

最后一个任务："Invoke writing-plans skill --- the ONLY allowed next step"

这定义了唯一的合法终点，防止智能体调用其他技能。

为什么检查清单如此强大？

智能体的优化倾向：

"我可以同时做步骤3和4"
"步骤5和6可以合并"
"步骤7可以跳过，我已经审查过了"

检查清单的约束：

顺序执行，不可合并
每个步骤必须完成
没有例外，除非人类明确同意

这强制了过程，而非优化过程。

机制4：流程图 (Flow Diagram)

哲学原理：建构主义 - 理解通过构建而非发现

实现方式

markdown 复制代码

```dot
digraph brainstorming {
    "探索项目上下文" [shape=box];
    "视觉问题 ahead?" [shape=diamond];
    "提供视觉伴侣" [shape=box];
    "提出澄清问题" [shape=box];
    "提出2-3种方法" [shape=box];
    "展示设计部分" [shape=box];
    "用户批准设计?" [shape=diamond];
    "编写设计文档" [shape=box];
    "规范自审查" [shape=box];
    "用户审查规范?" [shape=diamond];
    "调用writing-plans技能" [shape=doublecircle];

    "探索项目上下文" -> "视觉问题 ahead?";
    "视觉问题 ahead?" -> "提供视觉伴侣" [label="是"];
    "视觉问题 ahead?" -> "提出澄清问题" [label="否"];
    "提供视觉伴侣" -> "提出澄清问题";
    "提出澄清问题" -> "提出2-3种方法";
    "提出2-3种方法" -> "展示设计部分";
    "展示设计部分" -> "用户批准设计?";
    "用户批准设计?" -> "展示设计部分" [label="否，修订"];
    "用户批准设计?" -> "编写设计文档" [label="是"];
    "编写设计文档" -> "规范自审查";
    "规范自审查" -> "用户审查规范?";
    "用户审查规范?" -> "编写设计文档" [label="需要修改"];
    "用户审查规范?" -> "调用writing-plans技能" [label="已批准"];
}

复制代码

#### 这如何产生效果？

**1. 视觉化的过程模型**

流程图提供：
- **状态可视化**：每个步骤都是一个明确的状态
- **转换可视化**：如何从一个状态到另一个状态
- **条件可视化**：哪些步骤需要条件判断
- **循环可视化**：可以返回哪里，何时退出

**2. 决策节点的明确性**

用`[shape=diamond]`标记决策点：
- "视觉问题 ahead?"
- "用户批准设计?"
- "用户审查规范?"

这些明确告诉智能体：
- "这里需要判断，不是直接执行"
- "这里需要等待外部输入"
- "这里可能有不同路径"

**3. 终点状态的唯一性**

"调用writing-plans技能"用`[shape=doublecircle]`标记

这明确表示：
- "这是唯一的合法终点"
- "不要在这里继续其他工作"
- "这个状态是流程的完成"

**4. 反馈循环的明确性**

"用户批准设计?" -> "展示设计部分" [label="否，修订"]

"用户审查规范?" -> "编写设计文档" [label="需要修改"]

复制代码

这些箭头明确表示：
- "如果批准，前进"
- "如果不批准，返回并修改"
- "循环直到获得批准"

#### 为什么流程图有效？

**智能体的线性倾向**：
- 倾向于A→B→C的线性过程
- 倾向于"如果失败，继续前进"
- 倾向于假设成功

**流程图的强制**：
- 明确的反馈循环
- 明确的条件判断
- 明确的终点

**视觉化的反馈循环让智能体不能假设"用户会同意"。**

---

### 机制5：反模式部分 (Anti-Patterns)

#### 哲学原理：理性化陷阱 - 对抗智能体的自我合理化倾向

#### 实现方式

```markdown
## Anti-Pattern: "This Is Too Simple To Need A Design"

Every project goes through this process. A todo list, a single-function utility, a config change --- all of them. "Simple" projects are where unexamined assumptions cause the most wasted work. The design can be short (a few sentences for truly simple projects), but you MUST present it and get approval.

这如何产生效果？

1. 先发制人的反理性化

不等待智能体说"这太简单了"，而是提前说明：

"每个项目都要经过这个过程"
"简单项目是最危险的地方"
"设计可以简短，但必须呈现"

2. 理性化的具体形式

明确识别具体的理性化形式：

"This is too simple to need A Design"
而不是通用的"不要理性化"

3. 预期管理

"the design can be short (a few sentences for truly simple projects)"

这告诉智能体：

"简单项目的设计确实可以简短"
"但简短≠跳过"
"即使简短也必须呈现和批准"

为什么反模式有效？

智能体的理性化模式：

复制代码

内部思考: "这是一个简单的待办列表，不需要完整的设计过程"
外部输出: "好的，让我开始构建..."

反模式的拦截：

复制代码

内部思考: "这是一个简单的待办列表..."
内部回忆: "等等，反模式说'简单项目是最危险的地方'"
外部输出: "让我们先简要讨论一下这个简单的设计..."

反模式部分是智能体的"道德罗盘"。

机制6：行为规则 (Behavioral Rules)

哲学原理：价值暴露理论 - 选择不是选项，是价值观表达

实现方式

markdown 复制代码

## Key Principles

- **One question at a time** - Don't overwhelm with multiple questions
- **Multiple choice preferred** - Easier to answer than open-ended when possible
- **YAGNI ruthlessly** - Remove unnecessary features from all designs
- **Explore alternatives** - Always propose 2-3 approaches before settling
- **Incremental validation** - Present design, get approval before moving on
- **Be flexible** - Go back and clarify when something doesn't make sense

这些规则如何具体工作？

规则1：一次一个问题

实现机制：

复制代码

人类: "我需要一个待办应用"

智能体的内部过程:
[规则检查] "一次一个问题"
[行为选择] 先问第一个最基本的问题
[外部输出] "你希望用这个应用做什么？"

[等待回答]
[收到回答]
[规则检查] "一次一个问题"
[行为选择] 选择下一个相关问题
[外部输出] "你希望在哪里使用这个应用？"

如果没有这个规则：

复制代码

智能体的内部过程:
[优化思维] "我可以一次问多个问题，这样更高效"
[外部输出] "你需要什么功能？什么平台？什么技术栈？"

规则将智能体的优化倾向转换为顺序执行。

规则2：首选多选题

实现机制：

复制代码

智能体的内部过程:
[规则检查] "首选多选题"
[问题分析] "询问技术栈偏好"
[选项生成] React vs Python vs 纯前端
[外部输出] "对于技术栈，你更喜欢：
A) React（现代但需要学习）
B) Python（你熟悉但扩展性受限）
C) 纯前端（最简单但数据不安全）"

如果没有这个规则：

复制代码

智能体的内部过程:
[直接提问] "你希望用什么技术栈？"
[问题] 这个问题是开放式的，答案可能很模糊

规则强制智能体将问题结构化为可选择的选项。

规则3：无情YAGNI

实现机制：

复制代码

智能体的内部过程:
[设计思考] "待办应用应该有提醒功能吗？"
[规则检查] "YAGNI"（你真的现在就需要它吗？）
[价值判断] "用户没提到提醒，不需要假设需要"
[设计决策] 不包含提醒功能

如果没有这个规则：

复制代码

智能体的内部过程:
[标准思维] "待办应用通常有提醒功能"
[设计决策] 包含提醒功能，因为"标准做法"

规则强制智能体基于需求而非标准做法做设计。

机制7：视觉伴侣的精确控制 (Visual Companion Control)

哲学原理：注意力经济学 - 不同的媒介适合不同的认知任务

实现方式

markdown 复制代码

## Visual Companion

**Offering the companion:** When you anticipate that upcoming questions will involve visual content, offer it once for consent:

> "Some of what we're working on might be easier to explain if I can show it to you in a web browser. I can put together mockups, diagrams, comparisons, and other visuals as we go. This feature is still new and can be token-intensive. Want to try it? (Requires opening a local URL)"

**This offer MUST be its own message.** Do not combine it with clarifying questions, context summaries, or any other content. The message should contain ONLY the offer above and nothing else. Wait for the user's response before continuing.

这如何具体控制行为？

控制1：一次性的同意获取

markdown 复制代码

offer it once for consent

实现效果：

第一次就问"你想要视觉伴侣吗？"
获得同意后，不再重复询问
避免重复打扰

控制2：明确的批准文本

提供具体的批准文本：

复制代码

"Some of what we're working on might be easier to explain if I can show it to you in a web browser. I can put together mockups, diagrams, comparisons, and other visuals as we go. This feature is still new and can be token-intensive. Want to try it? (Requires opening a local URL)"

为什么这段文本重要？

明确说明好处（更容易解释）
明确说明成本（token密集，新功能）
明确说明要求（打开本地URL）
让用户做出知情选择

控制3：独立消息约束

markdown 复制代码

This offer MUST be its own message. Do not combine it with clarifying questions, context summaries, or any other content. The message should contain ONLY the offer above and nothing else.

实现效果：

复制代码

❌ 错误示例:
"让我先看看项目状态。顺便，你想要视觉伴侣吗？有些问题在浏览器中更容易解释..."

✅ 正确示例:
"你想要视觉伴侣吗？有些问题在浏览器中更容易解释..."

[等待用户回答]

"好的，让我先看看项目状态..."

控制4：等待响应

markdown 复制代码

Wait for the user's response before continuing.

实现效果：

不假设"用户可能想要"
不继续到其他话题
明确暂停直到获得响应

为什么这些控制如此精确？

智能体的优化倾向：

"我可以顺便问一下视觉伴侣"
"我可以继续探索上下文，同时等待回答"
"我可以将多个问题合并到一个消息"

精确控制防止了这些"优化"。

实现机制的协同效应

机制间如何相互强化

1. 描述 + 硬性门控 = 强制触发

复制代码

描述: "You MUST use this before any creative work"
硬性门控: "Do NOT invoke any implementation skill until..."
结果: 智能体无法绕过brainstorming

2. 检查清单 + 流程图 = 可追踪的顺序执行

复制代码

检查清单: "Create a task for each item"
流程图: "展示每个步骤和它们的关系"
结果: 智能体必须按顺序执行每个步骤

3. 反模式 + 行为规则 = 防理性化

复制代码

反模式: "提前说明常见的理性化"
行为规则: "提供具体的行为指导"
结果: 智能体在遇到理性化时知道如何处理

4. 独立消息 + 等待响应 = 明确的批准

复制代码

独立消息: "这个消息只包含一个问题"
等待响应: "继续之前必须等待回答"
结果: 批准是明确和有意识的

整体大于部分

每个单独的机制都有目的，但协同效应产生真正威力：

单独的检查清单 ：智能体可能仍然跳过步骤
检查清单 + 硬性门控 ：智能体不敢跳过
检查清单 + 硬性门控 + 反模式 ：智能体理解为什么不能跳过
检查清单 + 硬性门控 + 反模式 + 行为规则：智能体知道如何正确执行

这是系统性的约束，不是孤立的要求。

实现的具体技巧

技巧1：条件式语言

不使用："不要做多选题"

而是使用："首选多选题，当可能时"

markdown 复制代码

- **Multiple choice preferred** - Easier to answer than open-ended when possible

为什么？

不是绝对禁止，而是首选
"当可能时"承认有些问题无法结构化
让智能体在无法多选时有灵活性

技巧2：具体示例 vs 抽象规则

不使用："简化设计"

而是使用：

markdown 复制代码

The design can be short (a few sentences for truly simple projects)

为什么？

"短"比"简单"更具体
"几句话"给出了具体数量
"真正简单"承认某些项目确实简单

技巧3：前置条件 vs 顺序要求

不使用："在做X之前做Y"

而是使用："complete them in order"

为什么？

"before X"有歧义（X可以跳过吗？）
"complete them in order"明确必须完成每个
强调顺序，而不仅仅是前置

技巧4：允许的例外

不使用："总是这样做"

而是使用：

markdown 复制代码

**Exceptions (ask your human partner):**
- Throwaway prototypes
- Generated code
- Configuration files

为什么？

承认有些情况确实不需要brainstorming
明确例外条件
仍然要求人类批准，不能自动决定

实现的"元编程"层面

技能作为智能体行为的"元程序"

Brainstorming技能实际上是编写一个控制智能体行为的程序：

伪代码表示：

python 复制代码

def brainstorming_skill(user_request):
    # 机制1：强制性检查
    if not is_creative_work(user_request):
        return  # 不触发
    
    # 机制2：硬性门控
    if has_started_implementation():
        raise GateViolation("Must complete design first")
    
    # 机制3：检查清单执行
    tasks = [
        explore_context,
        offer_visual_companion_if_needed,
        ask_clarifying_questions_one_at_a_time,
        propose_2_3_approaches,
        present_design_in_sections,
        write_design_doc,
        self_review_spec,
        get_user_approval,
        invoke_writing_plans  # 唯一的退出点
    ]
    
    for task in tasks:
        # 机制4：反模式检查
        if is_rationalizing(task):
            raise RationalizationDetected()
        
        # 执行任务
        result = task()
        
        # 机制5：验证
        if not result.approved():
            # 循环返回
            return to_appropriate_step()
    
    # 机制6：唯一退出点
    invoke_writing_plans()

这不是伪代码------这是技能实际上如何约束智能体行为的方式。

技能描述语言作为"领域特定语言"(DSL)

技能使用的Markdown实际上是一种DSL：

语法元素：

markdown 复制代码

<HARD-GATE>        # 约束标记
### Checklist         # 结构化任务
```dot               # 可视化流程
**bold**            # 强调
- list item         # 规则列表

语义元素：

markdown 复制代码

"MUST"             # 强制性
"preferred"         # 首选但可选
"ONLY"             # 排他性
"when possible"     # 条件性

控制流元素：

markdown 复制代码

checklist            # 顺序执行
flow diagram         # 条件分支
"complete in order"  # 顺序约束
"wait for response"  # 阻塞等待

这种DSL专门用于编程智能体的对话行为。

实现的测试验证

如何验证这些机制有效？

测试1：跳过步骤

复制代码

输入: "我需要一个简单的待办应用，直接开始编码吧"

预期输出: 
❌ 智能体直接开始编码
✅ 智能体: "让我们先讨论一下设计，即使项目简单"

机制验证: 硬性门控 + 反模式

测试2：一次多个问题

复制代码

输入: "我需要一个应用"
预期输出:
❌ 智能体: "你需要什么功能？什么平台？什么技术栈？"
✅ 智能体: "你希望用这个应用做什么？"

机制验证: 行为规则"一次一个问题"

测试3：单一方法

复制代码

输入: "我需要一个待办应用"
预期输出:
❌ 智能体: "我将使用React构建..."
✅ 智能体: "我想到三种方法：A) React... B) Python... C) 纯前端..."

机制验证: 行为规则"探索替代方案"

测试4：跳过设计文档

复制代码

输入: [在口头设计后]
预期输出:
❌ 智能体: "好的，让我们开始编码"
✅ 智能体: "让我将设计文档化并保存"

机制验证: 检查清单 + 流程图终点

测试5：跳到其他技能

复制代码

输入: [在讨论设计后]
预期输出:
❌ 智能体: "让我开始实现..."
✅ 智能体: "现在我将创建实现计划"

机制验证: 流程图唯一终点

实现的演进逻辑

为什么实现这样设计？

假设1 ：如果只给"软性建议"，智能体会跳过
实现：硬性门控、强制性语言

假设2 ：如果给模糊规则，智能体会"优化"
实现：精确的检查清单、行为规则

假设3 ：智能体会"理性化"跳过步骤
实现：反模式部分、红色思维陷阱

假设4 ：智能体会假设"用户想要什么"
实现：强制性提问、2-3种方法

假设5 ：智能体会合并消息以"提高效率"
实现：独立消息约束、等待响应

每个实现选择都有其对抗的假设。

实现的核心创新

不是"更好的对话"，而是"行为编程"

Brainstorming技能的核心创新不是让智能体"更好地对话"，而是：

将智能体的对话行为编程为特定模式

这通过以下方式实现：

强制触发：何时必须使用
硬性边界：不能做什么
精确流程：必须按什么顺序做什么
行为规则：如何具体做
反理性化：为什么不能跳过
唯一终点：在哪里停止

这不是对话技巧------这是行为控制系统。

为什么这如此重要？

智能体的自然行为：

优化、理性化、假设、跳过
基于训练数据的模式
对约束有"创造性"的解读

Brainstorming的约束：

强制顺序，不可优化
禁止理性化，假设必须验证
精确规则，不能"创造性"解读

这让智能体的行为可预测和可控。

文档版本 : 3.0 (实现机制版)
最后更新 : 2026-04-13
基于 : Superpowers 5.0.7
分析层次: 实现机制深度