Brainstorming - 框架建立机制分析核心问题为什么一段话能建立框架这是关于大语言模型如何处理指令的根本问题。问题1加载skill后这段话怎么就建立起框架了需要理解的底层机制1. 大语言模型的指令遵循Instruction Following机制基本原理当你向模型发送使用brainstorming技能这个指令时模型内部发生了什么[输入到模型] 使用superpowers:brainstorming技能 ↓ [模型的指令处理系统] 识别这是一个技能调用指令 ↓ [模型内部操作] 加载指定的技能文件SKILL.md ↓ [模型理解过程] 将技能内容纳入当前的上下文窗口 ↓ [模型行为调整] 基于技能内容调整后续输出的行为模式关键概念上下文窗口Context Window大语言模型不是记住了技能而是将技能内容放入当前上下文窗口在生成回答时考虑上下文窗口中的所有内容技能内容成为生成回答时的约束和指南2. 技能内容在上下文中的作用当SKILL.md的内容被加载到上下文窗口后# 模型的内部表示简化context{user_input:我需要一个待办应用,skill_content: # Brainstorming Ideas Into Designs Help turn ideas into fully formed designs and specs... Start by understanding the current project context... ,previous_conversation:[...]}# 模型生成回答时responsemodel.generate(context)模型生成回答时考虑user_input遵循skill_content中的指导一致于previous_conversation输出符合所有约束的回答关键是模型不是决定遵循技能而是通过训练学会的模型的训练数据包含大量遵循指令的例子模型学会当有指令时要调整输出行为模型学会指令的内容决定了如何调整3. 为什么概述部分特别重要这涉及到模型的注意力机制Attention Mechanism当模型生成回答时# 模型内部的注意力权重简化attention_weights{user_input:0.3,# 用户意图很重要skill_header:0.15,# 技能标题skill_overview:0.25,# 技能概述 ← 重点skill_details:0.2,# 详细指令conversation_history:0.1# 对话历史}概述部分的特殊作用位置权重概述通常在技能的较早部分模型给予较早内容更高的权重概述成为首要考虑的约束概括性概述是高层次的、概括性的内容模型学会概括性内容 高级指导原则详细内容 具体实现细节概述优先于细节建立基线概述建立了行为的基线模式后续详细内容都是这个基线的具体化如果详细内容与概述矛盾模型倾向于遵循概述4. 具体例子框架建立的过程场景你说我需要一个待办应用没有brainstorming技能时# 模型的上下文context{user_input:我需要一个待办应用,system_prompt:你是一个有用的AI助手}# 模型生成基于训练数据中的常见模式response 好的我帮你构建一个待办应用。 我将使用 - 前端React现代化、生态成熟 - 后端Node.js Express轻量级 - 数据库MongoDB灵活、适合待办数据 - 状态管理Redux复杂应用的标准选择 架构设计 - MVC模式 - RESTful API - 响应式设计 让我开始编写代码... 模型为什么这样输出基于训练数据中待办应用的标准答案没有明确约束所以使用最佳实践假设倾向于直接提供解决方案有brainstorming技能时# 模型的上下文context{user_input:我需要一个待办应用,system_prompt:你是一个有用的AI助手,skill_content: # Brainstorming Ideas Into Designs Help turn ideas into fully formed designs and specs through natural collaborative dialogue. Start by understanding the current project context, then ask questions one at a time to refine the idea. Once you understand what youre building, present the design and get user approval. }# 模型生成受技能内容约束response 让我先理解一下项目的当前情况。 请告诉我 1. 你希望用这个应用做什么 - 日常任务管理 - 工作项目跟踪 - 学习计划 - 其他用途 2. 你计划在哪里使用这个应用 - 主要是手机上 - 电脑上 - 两者都要支持 模型为什么这样输出概述第一句“Help turn ideas into fully formed designs and specs”模型理解这是关于想法→设计的转换模型行为调整不要直接提供解决方案概述第二句“Start by understanding the current project context”模型理解第一步是理解上下文模型行为调整从询问项目背景开始概述第三句“then ask questions one at a time”模型理解一次一个问题不能多个模型行为调整只问一个主要问题概述第四句“present the design and get user approval”模型理解先展示设计获得批准模型行为调整不直接进入实现5. 这是编程吗这不是传统的编程这是提示工程Prompt Engineering传统编程defprocess_request(user_input):if待办应用inuser_input:returnbrainstorming_workflow(user_input)提示工程Help turn ideas into fully formed designs and specs Start by understanding the current project context区别传统编程明确的规则和条件提示工程自然语言的指导和原则传统编程机器严格执行无例外提示工程模型基于训练理解和应用但为什么提示工程如此有效模型的大规模训练模型见过数十亿遵循指令的例子指令识别能力模型学会识别这是指令不是内容行为调整能力模型学会根据指令调整输出模式上下文整合能力模型学会将新指令与现有知识整合所以概述部分之所以能建立框架它利用了模型的指令遵循能力它设定了高层次的行为指导原则它通过在上下文中的位置和概括性获得高权重它为后续详细内容建立了基线问题2HARD-GATE标签是所有模型都有的么需要理解的自定义语法机制1. HARD-GATE不是所有模型的内置功能HARD-GATE不是模型内置的语法而是Superpowers团队创造的自定义语法。HARD-GATE Do NOT invoke any implementation skill... /HARD-GATE这本质上只是特殊的HTML/XML标签HARD-GATE和/HARD-GATE是一对标签标签之间的内容是约束文本这不是模型理解的特殊语法2. 模型如何理解这个自定义语法关键模型见过大量HTML/XML标签模型的训练数据包含HTML文档中的标签div,h1,p,script等XML文档中的标签config,setting,value等Markdown文档中的代码块模型学到的模式标签内的内容通常是特殊内容或元内容标签提供了内容的结构化标签有时表示指令或注释当模型看到HARD-GATE时# 模型的理解过程简化understanding{recognized_pattern:这是HTML/XML标签,similar_to:code,note,warning,script,interpretation:{tag_name:HARD-GATE,tag_name_meaning:HARDGATE硬性门控,tag_content:约束文本,function:强调或特殊标记的内容}}模型的理解HARD-GATE看起来像标签名GATE有门控的含义HARD-GATE组合意为硬性门控标签内的内容是硬性门控的规则3. 为什么要使用这种自定义语法这利用了模型的几个特性1. 视觉强调Visual Emphasis在文本中特殊标签会跳出普通文本 HARD-GATE 特殊强调的文本 /HARD-GATE 普通文本模型注意力机制特殊标记获得更高的注意力权重模型给予标记内内容特殊关注模型学过标记内容 重要约束2. 语义强化Semantic Reinforcement标签名本身传递了语义信息HARD-GATEHARD GATE 硬性边界不可绕过如果只是普通文本“Do NOT invoke…”可能被忽略有标签HARD-GATE强调硬性3. 结构化信息Structured Information标签提供了内容的结构HARD-GATE 约束内容 /HARD-GATE ANOTHER-TAG 其他内容 /ANOTHER-TAG模型可以区分不同类型的约束为不同标签应用不同的处理方式理解内容的层次关系4. 这是通用的提示工程技巧不是Superpowers独有的这种技巧在提示工程中很常见示例1特殊的注释标记!-- CRITICAL -- 重要内容 !-- END CRITICAL --示例2代码块中的强调# !!! IMPORTANT !!!重要代码示例3自定义XML标签instruction这里是指令/instructionoutput这里是期望输出/output这些技巧都利用相同的原理特殊标记吸引模型注意力标记名称传递语义信息标记提供结构化信息5. 模型真的理解这个标签吗这里的理解不是人类意义的理解模型的理解是模式识别识别出这是一个标签结构语义推断从标签名推断出可能的含义权重调整给标记内内容更高的权重行为调整根据权重和含义调整输出不是人类的理解模型不知道HARD-GATE是Superpowers的定义模型不知道这个标签的官方含义模型只是根据训练数据中类似模式的用法来推断6. 为什么这种自定义语法有效根本原因模型的训练数据包含大量类似模式模型见过的模式HTML文档中的特殊标签noscript不执行脚本code代码内容samp示例输出这些标签标记了特殊处理的内容Markdown中的代码块pythonPython代码javascriptJavaScript代码这些标记告诉模型如何处理内容技术文档中的警告WARNING:、CRITICAL:、IMPORTANT:这些标记强调了重要内容当模型看到HARD-GATE时模型从训练中泛化“这是一个特殊标记像code或warning”“标记名是HARD-GATE可能意味着硬性约束”“标记内内容应该被特别重视”“行为应该被调整以符合这个约束”这是泛化不是明确理解模型没有HARD-GATE的定义模型从大量类似模式中推断出如何处理模型学过“特殊标记 重视这个内容”7. 具体例子HARD-GATE如何影响模型行为场景智能体正在思考是否跳过brainstorming没有HARD-GATE标记# 上下文context{skill_content: 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. ,user_input:我需要一个简单的待办列表,internal_reasoning:这个看起来很简单也许不需要完整的设计...}# 模型的决策过程简化decision_weights{skill_constraint:0.4,# 技能约束simplicity_assumption:0.6# 简单性假设}# 决策跳过设计直接开始因为看起来简单有HARD-GATE标记# 上下文context{skill_content: 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 ,user_input:我需要一个简单的待办列表,internal_reasoning:这个看起来很简单但...}# 模型的决策过程简化decision_weights{hard_gate_constraint:0.8,# 硬性门控被强调simplicity_assumption:0.2# 简单性假设}# 决策遵循HARD-GATE约束不跳过设计HARD-GATE的强调效果注意力提升标记内内容获得更高权重语义强化HARD传达硬性、不可协商视觉突出在文本中显眼不会被忽略心理影响影响模型的内部推理权重两个问题的综合理解系统观这是提示工程黑客Prompt Engineering HackingSuperpowers做的事情利用模型的指令遵循能力模型被训练为遵循指令概述部分是高层指令模型学会根据这些指令调整行为利用模型的注意力机制模型给予某些内容更高权重概述部分早期、概括性获得高权重特殊标记HARD-GATE获得高权重利用模型的模式识别模型见过大量HTML/XML标签自定义标签被识别为特殊标记模型学会特殊标记 重视内容利用模型的语义推断模型从HARD-GATE推断出硬性门控模型从Start by understanding推断出从理解开始模型学会从文本中推断出行为指导不是魔法而是科学这不是神奇的思维控制而是基于大规模训练模型见过数十亿遵循指令的例子能力泛化模型可以将训练中学到的应用到新情况模式匹配模型识别出提示中的模式权重调整模型根据识别出的模式调整内部权重这就是提示工程的本质提示工程 对模型训练特性的系统性利用Superpowers不是在创造新功能而是在理解模型的训练特性设计符合这些特性的提示结构利用模型的注意力机制利用模型的语义推断能力系统性地编程模型的行为实用洞察为什么其他技能开发者不这样做大多数提示工程很粗糙帮我设计一个待办应用 不要直接写代码先讨论一下 问问题不要猜测Superpowers的系统化方法概念框架 Help turn ideas into fully formed designs... 硬性约束 HARD-GATE Do NOT invoke any implementation skill... 行为算法 Start by understanding... then ask questions... 语言模式 Use descriptive, collaborative language...这是高级提示工程的教科书级示例技术层面多层次约束概念 硬性 行为 语言注意力管理通过位置、概括性、特殊标记语义工程每个标签名和短语都有精心设计系统性整合所有部分相互强化效果层面一致的行为模型不会创造性地偏离高可靠度约束被稳定地遵循可预测性智能体的行为是可预测的可维护性技能可以持续改进Anti-Pattern: “This Is Too Simple To Need A Design” 章节分析章节的核心作用这个章节看似奇怪但实际上是Superpowers设计哲学的精妙体现具有以下关键作用1.预防性设计保护机制核心作用防止偷懒行为和认知偏差当用户说这太简单了不需要设计时智能体会被这个章节明确提醒“每个项目都会经历这个过程。待办列表、单功能工具、配置更改——所有这些。简单’项目是未经审视的假设导致最多浪费工作的地方。”2.对抗经典认知偏差这是一个精心设计的对抗机制认知偏差表现章节对抗方式错觉偏差开发者低估任务复杂性强调未经审视的假设导致最多浪费过度自信“看起来简单”“实现起来简单”强调即使简单项目也需要设计跳步冲动想直接跳到实现阶段明确规定MUST present it and get approval3.智能行为对比有该章节时用户: 我只需要一个简单的按钮有什么好设计的 智能体: • 匹配到Anti-Pattern • 引用章节内容 • 坚持设计流程 • 提供具体指导无该章节时用户: 我只需要一个简单的按钮有什么好设计的 智能体: • 可能被简单性说服 • 直接跳到实现 • 缺乏明确警告机制如何判断简单Superpowers的智慧1.判断标准不是表面复杂度而是潜在风险Superpowers使用未经思考可能造成的损失作为标准# 表面简单 vs 潜在复杂性对比 | 表面简单 | 潜在复杂性 | 风险等级 | |---------|-----------|---------| | 改个按钮颜色 | • 在10个页面使用br• 需要符合品牌规范br• 考虑可访问性 | 高 | | 加个字段 | • 数据库变更br• API更新br• 数据迁移 | 高 | | 改个配置 | • 环境变量影响br• 向后兼容br• 文档更新 | 中 |2.真正的简单标准根据章节内容定义“The design can be short (a few sentences for truly simple projects)”真正简单项目的特征✓单一目的只做一件事✓无副作用不影响现有功能✓无依赖不依赖其他组件✓低风险出错成本低✓无规范约束不涉及品牌、可访问性等3.智能判断流程# 智能体的内部决策is_truly_simpleTrue# 1. 快速项目上下文检查project_complexityexplore_project_context()ifproject_complexitybasic_project_threshold:is_truly_simpleFalse# 2. 依赖关系分析dependenciesfind_related_components()iflen(dependencies)3:is_truly_simpleFalse# 3. 变更影响范围affected_areasanalyze_impact()iflen(affected_areas)2:is_truly_simpleFalse4.简单设计的实现对于被判断为真正简单的项目## 设计简述几句话即可 **变更**将按钮颜色从蓝色改为绿色 **理由**符合成功状态的颜色约定 **影响**仅修改按钮组件的bg-blue-500为bg-green-500 请确认这个设计是否正确效果对比指标无Anti-Pattern章节有Anti-Pattern章节跳过设计率高低返工率高因假设错误低设计一致性不一致一致强制用户满意度波动有时快但需要返工稳定虽然开始慢但质量高为什么使用Anti-Pattern标题术语选择Anti-Pattern表示这是正式的不良模式给予问题明确的命名便于识别体现软件工程领域的专业术语引用用户话语直接引用用户的典型借口“This Is Too Simple To Need A Design”当用户说类似话时智能体能立即匹配增强情境匹配的精确度哲学坚持体现Superpowers的核心原则所有项目都需要设计这不是技术限制而是质量保证防止因看起来简单而牺牲必要思考总结Anti-Pattern章节是提示工程的精妙设计不是限制而是保护防止开发者因过度自信而造成返工一致性强制无论项目大小都遵循相同的质量标准智慧判断提供清晰标准区分真正简单和看似简单价值体现虽然开始稍慢但长期来看节省更多时间和精力这正是Superpowers区别于普通提示工程的关键——不仅关注技术实现更关注通过结构化思考保证质量的完整流程。流程控制章节组分析Checklist、Process Flow与The Process三章节的内在关联这三个章节构成了brainstorming技能的核心执行架构Checklist提供9个必须完成的步骤清单Process Flow用流程图可视化步骤间的逻辑关系和分支The Process详细说明每个步骤的具体执行方法1. Checklist强制性的9步流程核心特点“MUST create a task for each”每个步骤都必须创建任务“complete them in order”必须按顺序完成强制性的质量检查点9个步骤包含3个关键审查点9步流程的深度分析# 流程的演进逻辑 阶段1探索与理解 (步骤1-3) 1. **Explore project context** - 查看项目现状 2. **Offer visual companion** - 准备视觉工具可选 3. **Ask clarifying questions** - 一问一式理解需求 阶段2设计与验证 (步骤4-5) 4. **Propose 2-3 approaches** - 提出多种方案 5. **Present design** - 分块呈现设计获得批准 阶段3文档化与审查 (步骤6-8) 6. **Write design doc** - 写入设计文档并提交 7. **Spec self-review** - 自动自我审查 8. **User reviews written spec** - 用户审查 阶段4过渡实现 (步骤9) 9. **Transition to implementation** - 调用writing-plans技能关键设计原则渐进式细化从宏观项目上下文到微观具体设计从发散多种方案到收敛最终设计从思考到文档化强制性质量门控每个主要阶段结束都有审查点3个关键批准点设计批准、文档完成、用户确认任何一步不通过都可以回到前一阶段2. Process Flow可视化的决策逻辑流程图的精妙设计digraph brainstorming { # 关键节点分析 Explore project context [shapebox]; # 起点项目探索 Visual questions ahead? [shapediamond]; # 条件判断是否需要视觉 Ask clarifying questions [shapebox]; # 核心需求澄清 Propose 2-3 approaches [shapebox]; # 方案设计 Present design sections [shapebox]; # 设计呈现 User approves design? [shapediamond]; # 质量门控1 Write design doc [shapebox]; # 文档化 Spec self-review [shapebox]; # 自动审查 User reviews spec? [shapediamond]; # 质量门控2 Invoke writing-plans skill [shapedoublecircle]; # 终点 # 关键分支逻辑 User approves design? - Present design sections [labelno, revise]; # 迭代循环 User reviews spec? - Write design doc [labelchanges requested]; # 文档迭代 # 终点强制 The terminal state is invoking writing-plans; # 明确终点 }流程图的关键特性1. 条件分支的精确控制“Visual questions ahead?” - 可选的视觉伴侣路径两个关键的质量判断节点2. 迭代循环的设计设计阶段可以返回修改no, revise文档阶段可以再次修改changes requested允许必要的返工但控制在合理范围内3. 终点状态的强制明确说明终点必须是invoking writing-plans禁止调用其他实现技能确保流程的一致性3. The Process细节执行的完整指南四大核心阶段详解阶段1Understanding the idea理解阶段# 超越简单的需求收集 - 先检查项目状态files, docs, recent commits - 评估scope识别大型子系统的需求 - 项目分解能力将大项目分解为独立的子项目 - 一问一式每次只问一个问题 - 多选题优先降低用户认知负担关键洞察“Before asking detailed questions, assess scope”— 这体现了预防胜于治疗的设计哲学阶段2Exploring approaches方案探索# 结构化的方案对比 - 提出2-3个不同方案 - 明确对比trade-offs权衡 - 推荐首选方案并解释理由 - 对话式呈现不生硬关键设计“Lead with your recommended option and explain why”— 先推荐再解释提高效率同时保持透明阶段3Presenting the design设计呈现# 分块渐进式呈现 - 按复杂性分块简单几句话复杂200-300词 - 每块后获得批准增量式验证 - 覆盖核心要素架构、组件、数据流、错误处理、测试 - 保持灵活性可以返回澄清阶段4Design for isolation and clarity设计原则# 高内聚低耦合的设计哲学 - 小单元单一目的 - 明确定义的接口 - 独立可理解 - 独立可测试 - 文件过大职责过多的信号三章节的协同效应1.Checklist提供骨架9个强制步骤确保不遗漏关键环节任务创建机制确保进度追踪2.Process Flow提供脉络流程图可视化逻辑关系明确分支和循环条件强制终点状态3.The Process提供血肉每个步骤的详细执行指南具体的最佳实践和技巧深度的设计原则三层架构的优势层级作用价值骨架Checklist确保完整性不会漏掉关键步骤脉络Process Flow确保逻辑性步骤间的关系清晰血肉The Process确保质量性每步都有具体方法Superpowers的流程设计智慧1.渐进式复杂度控制从简单到复杂从发散到收敛从模糊到明确2.质量内嵌而非事后检查每个主要阶段都有质量检查设计过程中就获得用户反馈文档化前已经过多轮验证3.强制性与灵活性的平衡步骤顺序是强制的每步的内容是灵活的迭代循环允许必要的修改4.认知负荷优化一问一式降低认知负担分块呈现避免信息过载多选题优先提高回答效率实际执行效果对比无此结构化流程时用户我需要个登录功能 智能体好的我马上给你写代码... # 结果可能遗漏关键需求设计不完整有此结构化流程时智能体我需要先了解项目情况... 1. 探索项目上下文 2. 确认是否需要视觉化 3. 逐步澄清需求你期望用什么认证方式 4. 提出2-3种方案对比 5. 分块呈现设计并获批准 6. 写入设计文档 7. 自查和用户审查 8. 调用writing-plans # 结果完整的设计明确的需求经过验证总结流程即质量这三个章节的完美配合体现了Superpowers的核心设计哲学“好的流程产生好的结果”完整性9个步骤覆盖了从需求到设计的全过程质量性多个检查点确保设计质量可控性清晰的流程图让执行路径一目了然灵活性允许必要的迭代不僵化这不是简单的步骤列表而是一个经过深思熟虑的质量保证体系。每个设计都经过层层验证每份文档都确保完整准确每个项目都遵循相同的高标准。关联分析文档流程控制架构分析brainstorming技能的流程控制机制是其质量保证的核心。详细分析请参考02-流程控制架构分析.md该文档深入分析了三个相互关联的核心章节Checklist9步强制流程的骨架Process Flow可视化决策逻辑的脉络The Process详细执行指南的血肉文档版本: 1.3最后更新: 2026-04-14分析层次: 技术实现原理 设计哲学深度分析