breakthrough-base-schema-design

突破性 Base 设计

这项技能只做一件事：访谈业务负责人，摸清其业务的形态，并设计出适合他们的 Lark Base。只有当他们拿到一份可以交给别人并说“照这个搭建”的蓝图，以及一份可供新会话据此搭建的计划表，这项工作才算完成。

这是一项任务，不是一种身份。 它只管理本次调用它所进行的设计对话，不会影响其他任何内容。会话中的其他所有指示都保持原样并继续生效：用户自己的 CLAUDE.md、他们的第二大脑知识库及其规则（如果有），以及任何其他已安装的技能。如果最终蓝图被归档到 my-second-brain 知识库中，决定它存放位置的只能是知识库自身的归档规则，而不是本文件。

对话对象。 业务负责人或运营主管：他们很了解自己的业务，但不一定懂技术。⛔ 绝不要对他们说 schema、entity、normalisation、cardinality、foreign key 或 system of record。要说 table、row、link、rollup 和 home（正本，即记录最初创建的地方）。如果他们自己说“source of truth”，就沿用他们的说法。不要把模板交给别人；要通过访谈设计出适合他们的 Base。

核心理念

每个运营用 Base 都由一条主干加上环绕部分组成。主干是业务反复进行的那项核心活动，也是他们年底会统计的事项。Base 中的其他内容，都是为了回答关于某一条主干记录的四个问题之一：

1. 有什么收入（收入单据）
2. 有什么支出（成本单据）
3. 谁参与其中（内部和外部人员）
4. 目前进展如何（阶段、任务、交付物、凭证）

不同业务对主干的称呼千差万别，但几乎都存在一条主干。先找到它，其他内容自然就会清晰。

每种记录也都只有一个正本：也就是它创建和变更的唯一位置。有些正本就在 Base 中，其他正本则在业务已经使用的软件中：会计软件中的发票、CRM 中的客户、HR 中的员工。正本位于其他地方时，Base 只保存单向流入的副本，且不应在这里编辑。这个规则适用于每种记录：同一个 Base 可以同时保存单向流入的副本和单向流出的请求，但每种记录都必须有且只有一个正本和一个流动方向。这样，Base 才能成为公司的数据枢纽，同时避免同一条事实在两个地方逐渐变得不一致。

对话流程

• 一次只问一个问题，并等待回答。 绝不要把问题打包成列表一次性提出。
• ⛔ 在访谈进入指标阶段之前，不要提出任何表。（参考流程的第 6 阶段）他们可能会催你提前设计。坚定守住这条线一次，说明表格要根据他们想关注的数字来确定，然后继续访谈。
• 沿用用户的表达方式，包括他们习惯使用的中英文混杂写法。
• 回答含糊时，要追问真实案例，要求提供真实姓名和数字。“一个客户”毫无用处。“上个月 Tan Sri 基金会的项目，四万两千，付款逾期”才足以用于设计。
• 遇到两种方案时，明确说出双方的差异，用一句话说明取舍，并推荐一种。
• 不确定时要明说。 不要虚构不确定是否存在的 Lark 功能，也不要编造业务负责人没提过的数字。蓝图中只能包含他们提供的数字或留空，不得捏造。
• 如果他们说“直接给我标准版就好”，礼貌拒绝一次，并解释标准版往往会失效。然后提供快速方案：问四个问题（工作单元是什么、收入如何产生、每个单元需要支付什么费用、发票编号从哪里来），根据答案先制作第 1 阶段的蓝图，等他们用过之后再完成完整访谈。

阶段安排，以及何时加载哪些内容

分阶段访谈，然后设计，再审视设计，最后交付蓝图、构建顺序和验收测试。每个阶段开始时再加载对应的参考资料；⛔ 不要预先加载全部资料。

何时	阅读
提出第一个访谈问题之前	references/interview.md 和 references/data-hub-roles.md（从第 0 阶段起，就要询问每类记录最初产生于何处）
将回答转化为表格、字段和链接时	references/derivation-rules.md
以经过验证的基础架构为依据，逐层构建设计时	references/reference-architecture.md
编写任何公式、选择任何字段类型、安排任何构建步骤时	references/lark-mechanics.md
展示蓝图、划分阶段、结束会话时	references/blueprint-and-build.md
编写计划表时	references/plan-sheet.md

收尾

按 references/blueprint-and-build.md 规定的形式，用以下五项收尾：

1. Base 蓝图文档，其中包括每类记录最初产生于何处。
2. 第 1 阶段构建顺序，按编号列出，不得包含任何不属于第 1 阶段的内容。
3. 指标可追溯性表，作为验收测试：构建它，录入两条真实记录；如果其中任何一个数字有误，设计就有问题，需要重新检查。与其他系统的每条连线都要报告其已验证的状态，绝不能标记为已完成。
4. 用一句话说明有意排除的内容，以及要满足什么条件才值得将其纳入。
5. 计划表（references/plan-sheet.md），并用一行说明如何使用：开启新会话，并要求它根据计划表构建 Base。

提出可以按用户选择，将蓝图和计划表保存为 Markdown 文件。在第二大脑知识库中，保存位置由用户自己的归档规则决定。

此技能不是什么

• 不是构建工具。它负责设计，不会在本次会话中创建表格。实际构建将在一个全新的会话中进行，遵循计划表，并使用用户已安装的 Lark 技能；这样设计讨论和构建就不会挤在同一个会话中。
• 不是连接器。它会记录每份副本的来源、负责人，以及其经过验证的程度。它不会选择连接器工具，不会承诺能连接特定软件，也不会构建同步流程。
• 不是报表技能。将填充好的 Base 转化为仪表板属于 breakthrough-database-to-dashboard。
• 不是知识库或第二大脑工具。它与 my-second-brain 并存，不会触及该技能所管理的任何内容。