#定义知识空间与回答合同

开始设计 · 给一条知识流程可复查的边界

知识空间不是“把所有文件放到一个桶里”。它是一组为了同一类用户问题而被组织、审阅和更新的资料边界。使用者应该能一眼看出：它服务谁、回答什么、允许哪些资料、谁负责变化，以及结果如何被相信。

#用业务语言描述知识空间

以退款规则为例，一个知识空间可以叫“面向中国大陆标准套餐的退款政策”。这个名字已经带出三个重要边界：地区、套餐和资料主题。它不该叫“refund-index-v2”，因为那是实现细节，不能帮助业务人员判断能否依赖结果。

#写出回答合同

回答合同把“一个好答案”变成可复查的规则。它由四个面组成：

合同不是为了让回答变得僵硬。它是为了让系统知道：何时可以说“根据当前政策”，何时必须说“无法确认，需要补充地区或等待资料更新”。

#让边界可以被共同评审

在进入资料阶段前，召集最少三种角色看同一份描述：业务使用者、资料负责人和未来集成方。每个人应能回答下面的问题：

1. 这条流程会不会把不该回答的问题说得过满？
2. 哪些资料具有最终解释权，谁在资料变化时负责确认？
3. 结果中哪些结论必须带证据，什么情况应转人工？
4. 如果一个地区或套餐不在范围内，使用者会怎样看见这个限制？

如果答案只存在于某个人的口头经验中，暂时不要进入实现。先把它写回合同。

#当前可做与目标版本的区别

本站没有承诺知识空间的具体数据结构、命令或 SDK 名称；这些必须在实现任务中从本合同派生，而不是反过来定义用户的工作方式。

#产出：一份可执行的边界说明

完成后，团队应能用一页说明讲清楚“什么问题、对谁、依据什么、怎样证明、何时不答”。下一步不是挑选存储产品，而是把能支撑这份说明的资料接入并审阅。

下一步：准备资料与证据。