L1 · 主粮知识文档
整篇进提示词，在字数预算内按相关度排。可单份停用。门店最常改的就是这一层。
93 份 · 整篇取用企业大脑
门店知识怎么出话
把一家门店会说的话沉下来，变成机器人每一轮回复里真的引用到的那几句。
// 架构与数据流口径 · 聚合运营数字 · 不含凭据、原文与门店身份
5 层资料结构
PGVECTOR 语义检索
人工启用不自动放行
逐次调用记「喂了什么」
每屏独立标数据真伪
门店自助维护
0
层资料，各管一段
主粮 / 话术 / 积木 / 素材 / 规则
0
份知识文档（主粮）整篇进提示词
0
条可审改知识元素拆自那 93 份
0
个向量检索块来自 500 条素材
SCROLL / 向下滚动
01
Five Layers
五层资料，各管一段
不是一个大向量库。五层各有各的取用方式——有的整篇进，有的按相关度排，有的必须人点过才算数。
L2 · 话术对话范例
按对话阶段先取候选，再按质量分挑前三条进提示词。甲方审定过的那部分才算金牌话术。
239 条 · 每轮取 3L3 · 积木知识元素
把整篇拆成一格一格可审改的小块，人能单独改一条而不动整篇。启用必须人点。
604 条 · 41 已启用L4 · 素材库向量检索
500 条素材切成 3,899 个块，走 pgvector 语义检索。这层管“客户问了个我们没预料到的问题”。
pgvector · 语义召回L5 · 规则与事实决策规则 · 门店事实
52 条决策规则 ＋ 155 条门店当日事实（价格、活动、库存）。这层管「今天这家店能说什么」。
规则直接进提示词
为什么要分层而不是一锅炖
五层的更新节奏完全不同：主粮按季度改，门店事实按天改，话术要甲方审。压成一层就意味着改一个价格要重跑整库。
02
Inventory ≠ In Use
存进来的，未必真被用上
知识库最容易骗人的地方是库存数字很好看。所以我们逐层查了一遍：到底有几份真的进过提示词。
各层「真正进过提示词」的比例
份数占库存 · 近 7 天 1,160 次回复 · 口径 2026-08-21
// 话术层低是设计如此：每轮只取前三条，不是把 239 条全灌进去。
// 积木层低是还没做完：601 条待人工逐条过闸，代码帮不上，只能人点。
// 素材库那一层此前根本查不出账——检索跑了，但没记「这次喂了哪几块」，2026-08-21 才补上。
这一节为什么放在最前面
「我们有 X 份文档」是最容易给的数字，也是最没用的一个。值得问的是：上一周真正被引用了几份。查不出来的，就该先去补记账，而不是先去扩库。
03
Document to Sentence
一份资料怎么变成机器人的一句话
人
上传 销售或店长在工作台传一份资料，选它进哪条路：老路整篇入库，或拆成积木
上传 销售或店长在工作台传一份资料，选它进哪条路：老路整篇入库，或拆成积木
服务端
抽事实 模型抽出结构化事实并归格；同时切块、算向量，写进检索库
抽事实 模型抽出结构化事实并归格；同时切块、算向量，写进检索库
融合
判重 与已有内容做第二次判定：一样的不新建，冲突的双方都停用、等人裁
判重 与已有内容做第二次判定：一样的不新建，冲突的双方都停用、等人裁
人
启用 拆出来的默认是草稿。必须人在工作台点过才启用——判官看的是摘录，证明不了摘录本身没拆错
启用 拆出来的默认是草稿。必须人在工作台点过才启用——判官看的是摘录，证明不了摘录本身没拆错
检索
组装 客户来消息时按相关度取各层，受每份资料的命中上限约束，拼进这一轮提示词
组装 客户来消息时按相关度取各层，受每份资料的命中上限约束，拼进这一轮提示词
记账
留痕 这一次喂进去了哪几条写成凭证落库——事后能回答「机器人为什么这么说」
留痕 这一次喂进去了哪几条写成凭证落库——事后能回答「机器人为什么这么说」
// 两处人在环都是刻意的：上传时选路，启用时逐条点。中间的机器步骤全部可重跑。
04
The Brick Layer
为什么要把整篇拆成积木
整篇文档改一个字要重传整份，也说不清“机器人引用的是这份里的哪一段”。积木让改动落到格子上。
01 · 人上传销售 / 店长传一份资料并选路
02 · LLM拆格按固定格位拆成可审改元素
03 · 判重融合同义不新建，冲突双停待裁
04 · 人启用逐条点，不许自动放行
05 · 开关过桥拨开后才进机器人话术
// 琥珀 = 人在环 · 蓝 = 服务端 · 青 = 生效。
// 03 与 04 之间是这条链最慢的一段：存量 93 份拆出 601 条草稿，覆盖 89 份，等人过。
冲突不合并，双方都停
两条说法打架时不选一条留下，而是两条都停用，在界面上点名要谁来裁。悄悄留一条，等于替门店做了它没授权的决定。
预审可以自动，启用不行
601 条草稿全部跑过一遍 AI 预审（通过 / 需人看 / 拦下三档），但状态只能人点——判官看的是摘录，证明不了摘录本身没把原文拆错。
启用 ≠ 已生效
元素要进机器人话术还得过一道总开关。开关没拨之前，界面上不许写「已经在用了」——这条由测试钉住，文案改早了 CI 会红。
拆不动的就承认拆不动
有几份资料正文只有六到十个字，标题即全文，没有可拆内容。不硬拆、不凑数——把覆盖率的分母改对，比把分子做大诚实。
05
Retrieval Guardrails
一份长文能把整个检索结果吃光
实测
问「某类窗户有什么坑」，语义检索前四条命中全是同一本书里连续的四段。相关度都很高，但读者拿到的信息只有一个来源——检索看起来在工作，实际退化成了摘抄。
每份资料的命中上限
检索函数加一个「同一份资料最多取几块」的参数，默认不设＝行为完全不变，调用方显式传值才生效，急停可一键设 0。
升级要能退回去
库里还是旧版函数时，调用方认得出那个特定错误码并退回旧调用重试再告警。数据库和应用不必同一秒上线。
分类是文件夹，不是业务维度
素材的分类字段其实是目录路径，54 个类里混了三套命名体系。它不参与检索过滤，只影响人工维护——写清楚，免得有人当成业务标签去用。
240 多个标签是死标签
运行时只认三个功能标签，其余语义标签没有任何读取点。标注的人以为在建索引，实际是在写备注——这类「看着有、其实没接线」的东西必须查出来讲明白。
06
Build vs Adopt
为什么没有直接上一个现成 RAG 平台
2026-08 认真评过腾讯开源的 WeKnora（两万余 star，RAG 问答 ＋ Wiki ＋ 多源同步 ＋ IM 集成）。三个候选场景都判为不引入。
OVERLAP卖点已有承担者
- 语义检索 → 已有本地向量 ＋ 关键词双路
- 向量存储 → pgvector 迁移路径已写好
- 文档解析 → 已自研装修行业结构化解析
- IM 集成 → 接待通道已有自建方案
RISK引入的代价
- License 主体是 MIT，但内含 MPL-2.0 与两个不明组件
- 内部自用无碍，塞进对外产品要单独审
- 多一套 PG ＋ Redis ＋ 对象存储要运维
- 行业解析这块它给不了
TAKE值得借鉴的那一条
- 多源同步的思路（从协作文档、笔记、订阅源持续拉）
- 这正是门店知识最容易断更的地方
- 已记录，作为后续增量
对接方可以直接用的一条
评开源项目别只看仓库首页的 License 标签。这次接口返回的是「无法判定」，拉下三千多行原文才确认主体是 MIT——标签是聚合器猜的，原文才算数。
07
Provenance & Labelling
喂进去了什么，与它到底有没有被用上
这两件事不是同一个数。我们记的是前者，并且在界面上把这个区别说出来。
凭证记的是「喂了什么」
每次回复落一行：模型、提示词版本、喂进去的资料 id、耗时、成本。它证明不了模型真的引用了——但没有它，连「为什么这么说」都无从查起。
验收只能看生产数据
测试证明不了记账在跑。判据是去生产库里查那一列有没有行——一行都没有，就说明线上开关是关的，无论代码写得多对。
每屏独立标数据真伪
不是整站一句免责声明。每一屏顶上标绿色「真实数据」或黄色「示例数据」，逐屏判断。企业大脑现有 17 屏，其中 10 屏接真实查询。
名单反着列是刻意的
维护的是「哪几屏还没接通」而不是「哪几屏接了」。因为接了的是绝大多数，正着列必然漏——而漏了的后果是页面标着「还没接通」、按钮却在真写库。标记出错比数据本身更要不得。
这块和另外两个板块的关系
企业大脑不直接面对客户。它的输出全部经企微接待那根桥才发得出去，也给短视频产线的出稿供事实。桥关着的时候，这里配得再全，客户也一个字收不到——所以界面上会把桥的状态直接画出来。
08
Stack & Interfaces
一页看全用了什么
| 层 | 技术 | 说明 / 口径 |
|---|---|---|
| 工作台 | Next.js 16 · React 19 · 全 SSR | 零浏览器直连、零 web 字体；部署在东京，国内可达 |
| 数据库 | 与另两个板块共用同一个 Postgres | 本层只读写不建表，DDL 统一从获客主仓下发 |
| 向量检索 | pgvector ＋ 关键词双路 | 500 条素材 / 3,899 块；带每份资料命中上限 |
| 拆分与融合 | 推理型模型 · 结构化输出 | 输出预算不够时对半拆两次进；不硬拆无内容的资料 |
| 原件存储 | 对象存储私桶 ＋ 服务端流式转发 | 不发签名直链；入库副本与原件分开存字段、分开展示 |
| 权限 | 手机号 ＋ 密码 · 四档角色 | 门店销售 / 门店店长 / 高层 / 我方；缺配置一律看不到而非看全部 |
| 出话通道 | 总开关控制的桥 | 拨开前元素不进机器人话术，界面文案由测试钉住 |
| 可观测 | 逐次调用凭证 ＋ 会话录屏 | 记「喂进去了哪几条」；录屏脚本只挂登录后布局 |
| 调度 / CI | 平台 Cron ＋ GitHub Actions | 9 条工作流 · 跨仓 DDL 漂移检查 · 高危路径闸 |
一句话总括：企业大脑要解决的不是「存得下」，是「用得上、说得清、改得动」——分五层是为了让更新节奏不同的知识各走各的路，人工启用与冲突双停是为了不替门店做决定，逐次记账是为了事后能回答「机器人为什么这么说」。库存数字谁都能做大，值得看的是上一周真正被引用了几份。