brainstorming

头脑风暴

通过结构化对话，将粗略想法转化为经过验证的设计，然后再着手修改代码或配置。

在提出设计并获得用户批准之前，绝不要开始实现。 无论任务看起来多么简单，这条规则都适用——“简单”的任务最容易因未经检验的假设而浪费大量精力。

流程

1. 探索上下文

先检查项目状态：文件、配置、近期更改和现有模式。在提问前，先了解已有内容。

2. 提出澄清问题

• 一次只问一个问题。 不要一次列出一堆问题。
• 如果有已知选项，优先采用多选题。只有在问题范围确实开放时才使用开放式问题。
• 重点关注：目的、限制、成功标准，以及用户最看重的方面。

3. 提出方案

提出 2-3 种方案，并说明各自的权衡。先给出你的建议并解释原因。坦诚说明缺点。

如果只有一种合理方案，就明确说明并解释其他方案为何行不通——不要编造虚假的选项。

4. 展示设计

了解构建目标后，按复杂度分节展示设计：

• 简单部分用几句话说明
• 存在实际权衡的部分则详细说明
• 每节之后都要征求批准，让用户能尽早调整方向

涵盖：哪些内容会更改、哪些内容保持不变、用户需要验证什么，以及哪些决策留待实现阶段确定。

5. 转入实现

用户批准设计后，开始实现。对于迁移，进入相应的迁移阶段。对于其他工作，则开始执行。

适用场景

• 迁移——开始前先探索网站结构，并讨论可编辑性方面的权衡（页面构建器还是静态页面、哪些内容需要可编辑、内容重组决策）
• 添加功能——为现有网站添加代码片段、可视化编辑或配置之前
• 重组——重组内容、集合或配置之前
• 需求模糊——用户说“让它支持 CC”，但没有说明范围时

不适用场景

• 单一且定义明确、实现方式显而易见的任务（“在 _editables 中添加 snippet: true”）
• 问题和解决方案都很明确的 Bug 修复
• 用户明确说“直接做”，或提供了详细规格

内容

此技能只有一个文件——没有更深入的内容。设计获批后，实现在负责该工作的技能中继续进行：

接下来使用	适用于
migrate-to-cloudcannon	完整迁移，从第 1 阶段开始
cloudcannon-configuration	集合、输入项、结构、集合 URL
cloudcannon-visual-editing	可编辑区域
cloudcannon-snippets	MDX 组件或内容中的内联 HTML
make-site-multilingual	Rosey 和 CloudCannon 连接器

核心原则

• 一次只问一个问题——不要让用户应接不暇
• 优先采用多选题——选项已知时，多选题比开放式问题更容易回答
• YAGNI——从设计中去除不必要的复杂性
• 探索其他方案——始终考虑是否有更简单的方法
• 坦诚相告——如果某件事看起来过于复杂，就直说。及时制止范围蔓延。
• 逐步验证——分节展示设计，每节获得批准后再继续

常见误区

借口	现实
“这件事太简单，不需要设计”	简单任务最容易因假设而造成浪费。设计可以很简短。
“我已经知道该怎么做了”	你知道你自己会怎么做。用户可能有不同的优先事项或限制。
“提问会拖慢进度”	错误的假设更会拖慢进度。现在问一个问题，可以避免之后返工。
“如果哪里不对，用户会告诉我的”	用户往往要看到错误的结果后，才知道该指出什么。提前确认。
“我边做边想办法”	这样最终只会让你重做。先探索各种可能性。