（7577期）Core Brainstorming – 协作对话，将灵感化为蓝图

协作对话，将灵感化为蓝图 通过协作对话将模糊需求转化为完整技术设计，支持架构决策、方案对比与增量验证，适用于任何创造性开发工作。 使用说明 核心用法 core-brainstorming 是一个结构化创意发散技能，专为软件开发中的设计阶段设计。它通过分阶段协作对话——理解想法→探索方案→呈现设计——将模糊的用户意图转化为可落地的技术规格。 启动时自动分析项目上下文（文件结构、近期提交、现有文档），随后采用「一次一问题」策略逐步澄清需求：优先使用选择题降低认知负荷，必要时辅以开放题深挖约束条件。理解目标后，主动提出 2-3 种架构方案并标注权衡，推荐最优路径并解释理由。 设计呈现阶段采用增量验证机制：将方案拆分为 200-300 字的独立小节，逐节确认正确性，覆盖架构、组件、数据流、错误处理与测试策略。验证通过后自动生成设计文档并存档，可无缝衔接 core-writing-plans 进入实施阶段。 显著优点 流程结构化：明确的「理解-探索-呈现」三段式降低沟通摩擦 认知友好：单问题交互、选择题优先、小节验证，符合人类工作记忆限制 决策透明：强制多方案对比避免过早收敛，推荐方案附理由增强可信度 上下文感知：自动读取项目状态，设计贴合实际代码基 领域扩展：通过条件钩子支持嵌入式、仿真等垂直领域的专业子技能调用 YAGNI 内置：设计阶段即过滤非必要功能，减少技术债务 潜在局限 同步阻塞：依赖人机回合制对话，不适合批量化或自动化场景 经验门槛：方案质量受用户技术视野制约，复杂领域需配合专业子技能 文档负担：强制要求存档设计文档，小型变更可能显得过重 无版本对比：未内置设计迭代的历史追踪与差异分析能力 适合人群 软件工程师、技术负责人、独立开发者在启动新功能、重构或复杂修改前的设计阶段；尤其适合偏好对话式协作、需要结构化决策记录的团队。 常规风险 过度设计：探索阶段若未严格执行 YAGNI，可能产生不必要的抽象层 确认偏差：增量验证环节若用户被动确认，可能遗漏关键缺陷 上下文遗漏：自动读取的项目状态若未覆盖关键隐式知识，设计可能偏离实际 子技能依赖：嵌入式/仿真场景若未触发推荐子技能，方案可能缺乏硬件/物理约束考量 原始说明 在任何创造性工作之前必须使用 - 创建功能、构建组件、添加新功能或修改行为。通过协作对话探索用户意图、需求和设计。