#选择一个值得交给知识流程的问题

开始设计 · 先定义用户要相信什么

很多团队从“要不要建向量库”开始，最后得到了一套能检索文本、却无法解释答案依据的系统。lorebit 的起点相反：先选择一个真实、需要持续依据资料作答的问题，再为它设计知识流程。

本页以“客户成功团队根据最新产品规则回答客户问题”为例。它不是唯一场景，也不是 lorebit 当前已提供的应用；它是一条足够具体、能检验产品行为的用户任务。

#什么时候值得建立知识流程

下列问题不适合把 lorebit 当作首选：只需要一次性全文搜索、没有可信资料来源、必须立刻接入一个已发布 SDK，或真正诉求只是替换数据库产品。lorebit 不是数据库内核，也不是一个已经可下载安装的聊天应用。

#把模糊愿望改写成可评审的问题

不要写“做一个产品知识库”。请把它缩小为一张问题卡：

如果同一个问题需要同时服务不同地区、语言、套餐或权限等级，先分成多个问题卡。把冲突留给“模型理解”会让后续的资料准入、检索与更新都失去边界。

#先冻结回答合同

回答合同是使用者对结果的最低期待，不是配置文件或 API 字段。至少写清四件事：

1. 范围：哪些问题应该回答，哪些问题要拒绝或交给人处理。
2. 证据：回答最少需要返回什么来源、版本与原文位置。
3. 时效：资料变更后，多久前的结果仍可作为当前依据。
4. 不确定性：证据不足、状态未完成或能力缺失时，如何让用户看见限制。

例如，退款问题的合同可以是：“只基于已激活的、适用于该地区和套餐的政策作答；每项结论附上政策版本与段落；若条款冲突或政策正在重建，提示需要人工确认。”

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

“知识空间”“回答合同”等名称在本站是面向用户的概念，不是今日可导入的类名。公开 SDK 尚未发布。

#产出：一张问题卡

完成本页时，你应得到一张任何人都能评审的问题卡。它至少能回答：谁要做什么决定、能依据什么、何时不能回答、答案要怎样证明自己。这张卡随后会成为知识空间、资料准入和验收场景的共同输入。

#常见失败

下一步：定义知识空间与回答合同。