brainstorming

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Brainstorming

头脑风暴

Turn rough ideas into validated designs through structured dialogue before touching code or config.

Do NOT start implementation until a design is presented and the user approves it. This applies regardless of perceived simplicity — "simple" tasks are where unexamined assumptions cause the most wasted work.

在修改代码或 config 之前，通过结构化对话将粗略想法转化为经过验证的设计。

在展示设计并获得用户批准之前，不要开始实施。 无论任务看起来多么简单，都应遵循此原则——所谓的“简单”任务往往正是未经检验的假设造成最多返工的地方。

Process

流程

1. Explore context

1. 探索上下文

Check the project state first: files, config, recent changes, existing patterns. Understand what exists before asking questions.

首先检查项目状态：文件、config、最近变更和现有模式。先了解现有内容，再提出问题。

2. Ask clarifying questions

2. 提出澄清问题

One question at a time. Don't overwhelm with a list.
Prefer multiple choice when there are known options. Open-ended when the space is genuinely open.
Focus on: purpose, constraints, success criteria, what the user cares about most.

每次只问一个问题。 不要用一连串问题让用户不堪重负。
有已知选项时，优先使用多选题。当方案空间确实开放时，再使用开放式问题。
重点关注：目的、约束、成功标准，以及用户最看重的方面。

3. Propose approaches

3. 提出方案

Present 2-3 approaches with tradeoffs. Lead with your recommendation and explain why. Be honest about downsides.

If only one approach makes sense, say so and explain why alternatives don't work — don't invent fake options.

提出 2-3 种方案及其权衡。首选推荐方案并说明原因。诚实说明其缺点。

如果只有一种方案合理，请直接说明，并解释其他方案为何不可行——不要编造虚假选项。

4. Present design

4. 展示设计

Once you understand what to build, present the design in sections scaled to complexity:

A few sentences for straightforward sections
More detail for sections with genuine tradeoffs
Get approval after each section so the user can course-correct early

Cover: what changes, what stays the same, what the user needs to verify, and any decisions deferred to implementation.

一旦明确了要构建什么，按与复杂度相称的方式分节展示设计：

简单部分用几句话说明
对存在真实权衡的部分提供更多细节
每一节之后都获得批准，以便用户尽早调整方向

涵盖：哪些内容会变更、哪些保持不变、用户需要验证什么，以及哪些决策推迟到实施阶段处理。

5. Transition to implementation

5. 转入实施

Once the user approves the design, proceed to implementation. For migrations, this means entering the relevant migration phase. For other work, start executing.

设计获批后，继续实施。对于迁移，这意味着进入相应的迁移阶段。对于其他工作，则开始执行。

When to use

适用场景

Migrations — before starting, explore the site structure and discuss editability tradeoffs (page builder vs static pages, what to make editable, content restructuring decisions)
Adding features — before adding snippets, visual editing, or configuration to an existing site
Restructuring — before reorganizing content, collections, or config
Ambiguous requests — when the user says "make this work with CC" without specifying scope

迁移——开始前，探索站点结构并讨论可编辑性权衡（page builder 与静态页面、要开放编辑的内容、内容重组决策）
添加功能——在向现有站点添加 snippets、可视化编辑功能或配置之前
重组——在重新组织内容、collections 或 config 之前
含糊请求——当用户只说“让这个与 CC 兼容”而未说明范围时

When not to use

不适用场景

Single, well-defined tasks with an obvious implementation ("add
```
snippet: true
```
to
```
_editables
```
")
Bug fixes where the problem and solution are clear
The user explicitly says "just do it" or provides a detailed spec

单一且定义明确、具有明显实现方式的任务（“为
```
_editables
```
添加
```
snippet: true
```
”）
问题和解决方案都明确的 bug 修复
用户明确表示“直接做”或提供了详细 spec

Then go to	For
`migrate-to-cloudcannon`	A full migration, entering at Phase 1
`cloudcannon-configuration`	Collections, Inputs, Structures, Collection URLs
`cloudcannon-visual-editing`	Editable regions
`cloudcannon-snippets`	MDX components or inline HTML in content
`make-site-multilingual`	Rosey and the CloudCannon connector

此 skill 是单个文件——没有深入展开的内容。设计获批后，实施工作将在负责该工作的 skill 中继续：

接下来前往	用于
`migrate-to-cloudcannon`	完整迁移，从 Phase 1 开始
`cloudcannon-configuration`	Collections、Inputs、Structures、Collection URLs
`cloudcannon-visual-editing`	可编辑区域
`cloudcannon-snippets`	内容中的 MDX 组件或内联 HTML
`make-site-multilingual`	Rosey 与 CloudCannon connector

Key principles

核心原则

One question at a time — don't overwhelm
Multiple choice preferred — easier to answer than open-ended when options are known
YAGNI — remove unnecessary complexity from designs
Explore alternatives — always consider whether a different approach would be simpler
Be honest — if something seems overcomplicated, say so. Push back on scope creep.
Incremental validation — present design in sections, get approval before moving on

每次只问一个问题——不要让用户不堪重负
优先多选题——当选项已知时，比开放式问题更便于作答
YAGNI——从设计中移除不必要的复杂度
探索替代方案——始终考虑是否有更简单的不同方案
保持诚实——如果某件事看起来过于复杂，就直说。反对范围蔓延。
渐进式验证——分节展示设计，在继续之前获得批准

Common mistakes

常见错误

Excuse	Reality
"This is too simple to need a design"	Simple tasks are where assumptions cause the most waste. The design can be short.
"I already know what to do"	You know what YOU would do. The user may have different priorities or constraints.
"Asking questions slows things down"	Wrong assumptions slow things down more. One question now saves rework later.
"The user will tell me if something's wrong"	Users often don't know what to flag until they see the wrong result. Validate upfront.
"I'll figure it out as I go"	That's how you end up redoing work. Explore the space first.

借口	实际情况
“这太简单了，不需要做设计”	简单任务恰恰是假设最容易造成浪费的地方。设计可以很短。
“我已经知道该怎么做了”	你知道自己会怎么做，但用户可能有不同的优先级和约束。
“提问会拖慢进度”	错误的假设才会拖慢进度。现在提一个问题，可以省下之后的返工。
“用户会告诉我哪里有问题”	用户通常在看到错误结果之前都不知道该指出什么问题。提前验证。
“我会边做边想办法”	这样最终会导致重做。先探索整个方案空间。