kickoff-doc

根据会议记录编写启动文档

将启动会议的文字记录转化为面向构建者的参考文档，用于一个已确定范围的项目。

---

开始之前

询问用户：

1. 主要读者是谁？（通常是负责实施工作的构建者。）
2. 还有哪些输入资料？（视觉素材、屏幕截图、模型图，或会议中绘制的草图。）

文字记录是你的资料来源。本文档不是会议摘要，而是对已确定项目范围的领域地图。

---

组织原则：领域，而非时间线

启动会议的文字记录是按时间顺序排列的——人们按话题出现的顺序讨论，回头补充内容、跑题，或被浏览器问题打断。你的工作是重建他们所描述的领域，而不是复述对话。

**按正在构建的对象组织内容。**每个章节都应完整描述系统的一个领域，以便构建者查找“Criteria 选项卡如何运作？”时，能在一处找到所有相关信息。

**不要按构建顺序组织内容。**如果团队确定了多个切片（按顺序构建的一系列纵向切片），应单独管理，不要放在本文档中。

---

结构

文档有两个顶级章节：Frame 和 Shape。两者均使用 ## 标题。其子章节使用 ### 标题。

1. Frame（## Frame）

战略背景和边界条件。这不是可有可无的内容——遇到模糊情况时，构建者需要这些信息来做判断。

• ### Problem — 为什么要做这个项目，为什么是现在。有哪些问题或缺失。
• ### Outcome — 预期的具体成果。成功是什么样的。

2. Shape（## Shape）

系统的每个领域各设一个 ### 章节。每个领域都要说明：

• 它是什么，以及屏幕上显示什么（可操作元素、组件、展示的数据）
• 它与其他领域的关系
• 属于该领域的设计决策——放在正文中，不要另设章节
• 被提及的边界情况或注意事项
• 哪些是临时内容或占位内容，哪些是真正确定下来的事项

**不要添加 Build Sequence 章节。**切片应与本文档分开跟踪。

---

语气：使用他们的原话

本文档记录的是启动会议上达成的共识。

应做的事

• 使用与会者在会议中实际使用的词语和短语
• 综合分散在各处的讨论，使表述更清晰（将多轮对话中提到的内容整合成清楚的描述）
• 记录人们对决策给出的理由（“我们之所以做 X，是因为 Y”）

不应做的事

• 不要把新的想法或结论强加给与会者
• 不要添加他们没有表达过的激励性说辞（“每个部分都是基础，而不是一次性成果”）
• 不要超出已表达的内容，自行评判重要性或质量

检验标准

对于每个句子，你都应该能在文字记录中找到某个时刻，证明有人说过这句话或明确表达过这个意思。如果找不到，就删除该句，或标明这是你自己的综合归纳。

**例外情况：**如果编辑性表述能澄清或综合已表达的内容，就可以使用。“criteria 页面体现了新模式下的筛选方式”——虽然没人逐字说过这句话，但它准确概括了多轮讨论中的观点。这正是你的工作：让分散的讨论变得清晰易懂，同时不添加自己的结论。

---

设计决策：纵向归类，而非横向归类

不要创建一个囊括各种内容的“Design Decisions”章节。应将每项决策直接放在相关领域的章节中。

• “匹配项存储在数据库中，而不是 Redis 中” → 放在匹配相关的章节中
• “附加之前必须先将候选项实体化” → 放在附加相关的章节中
• “每个 ICP 的匹配数据采用值对象” → 放在匹配结果相关的章节中

如果某项决策只与构建某个特定领域有关，就应放在该领域的章节中。构建者处理特定页面时，不应还得去单独的决策列表中查找相关信息。

---

流程

1. 通读完整的文字记录。 不要只读了一部分就开始撰写。
2. 确定讨论过的系统领域——这些领域将成为 ## Shape 下的 ### 章节。
3. 起草 Frame（包含 ### Problem 和 ### Outcome 的 ## Frame），内容取自关于问题背景和预期结果的讨论（通常在通话开始时）。
4. 撰写各个 Shape 章节（### ...），从文字记录中涉及该领域的所有部分提取内容。一个章节可能需要综合整场通话中分散在各处的讨论。
5. 将设计决策放在所属章节中。
6. 对照文字记录进行检查——每项陈述都能指出其出处吗？