shape-up

Shape Up — 自顶向下设计规范

通过自顶向下的方式，将模糊的想法塑造成清晰的设计规范：从整体概览开始，在每一层确认方向一致后，再深入细节。这不是一场访谈，而是协作写作：由 Agent 起草，用户来完善。

适用场景

• 用户说“shape up”“设计规范”“我们来设计”“规划一个系统”“我需要理清思路”
• 用户有一个规模较大或含糊不清的项目，需要先了解整体概览
• 在使用 /grill-design 之前——当范围还不够明确，无法讨论细节时

核心原则

每次只处理一层。确认后再深入。绝不跳步。

如果用户无法回答当前层的问题，就标记为 [TBD] 并继续。不要深入探究未知事项——那会让人失去焦点。

工作流

第 1 层：愿景

请用户用通俗的语言描述他们正在构建什么。然后共同撰写一段简短的愿景说明：

• 是什么 — 用一句话描述要做的事
• 为什么 — 要解决什么问题，面向哪些人
• 成功的标准 — 如何判断它是否成功

起草一段简短说明（最多 5-8 行）。展示给用户，并根据反馈调整，直到他们认可为止。

此时不要询问技术栈、架构或实现方式。

第 2 层：范围

愿景明确后，共同撰写项目范围：

• 范围内 — 项目要做什么（项目符号列表）
• 范围外 — 明确不做什么（项目符号列表）
• 约束条件 — 时间线、技术、团队、预算、依赖项
• 用户 / 参与者 — 谁会与它交互

起草后展示给用户。用户可以删减、添加内容，也可以在范围内外之间调整条目。持续完善，直到范围足够明确。

如果范围变得太大，就指出来：“感觉范围在不断扩大——要不要拆分一下？”

第 3 层：构建模块

将范围内的工作拆分成 3-7 个大块。每块都是一个主要组件、功能领域或工作流。每个模块包括：

• 名称 — 简短标签
• 目的 — 一句话说明
• 依赖项 — 需要哪些其他模块

用简单列表或图表展示。用户可以重新排序、重命名、合并或拆分模块。这是整个设计的骨架——暂时不展开细节。

如果某个模块不明确，就标记为 [TBD] 并继续。不要因为一个未知事项就停下整个流程。

第 4 层：起草规范

按照用户选择的顺序，为每个模块共同撰写一份简短规范：

• 它的作用
• 关键决策或权衡
• 未解决的问题

每个模块的规范最多半页到一页。如果内容变得更长，很可能需要拆分成更小的模块——返回第 3 层。

用户可以随时停下并说“目前这样就够了”。请尊重这一点。第一轮不必为每个模块都撰写规范。

输出

将规范写入文件。由用户决定文件名和保存位置。如果用户没有指定，建议将其保存为当前目录下的 design-spec.md。

规范可以有多个草稿，例如 draft/phase-1.md、draft/final-spec.md。按照用户的意愿安排结构。

如何协作撰写（而非访谈）

• 先起草，再提问。 不要一上来就列出一串问题。根据已知信息写一个粗略版本，再让用户修改。
• 展示，而不是提问。 不要问“范围应该是什么？”，而是先写出一个范围，然后说“这是我理解的内容——有什么不对？”
• 保持推进。 如果用户的回答比较含糊，就写出你认为最合理的理解并继续。如果有误，用户会纠正你。
• 简短分块。 每一层的内容都应控制在一屏内。如果写得更多，就说明深入得太多了。

不要做什么

• 不要一开始就提出 10 个澄清问题（这是 grill-design 要做的事）
• 第 1-2 层不要讨论实现细节
• 除非用户提出要求，否则不要展开 [TBD] 项
• 不要一次性写完整份规范——应逐层完成
• 如果用户尚未确认当前层，就不要继续深入