门店工作台 · 模块四 · wb.hzcytech.cn/wb#brain-overview
按 V6 设计稿（稿次 #6.1）改造企业大脑的进度盘点。四处已上线，三件卡住。
2026-08-21 去 wecom-chat 仓复查后结论反了：桥早就建好了，卡的不是工程，是没人采纳那批候选。（08-20 数到 594 条；08-24 复查：仍有 557 条是 draft，只采纳了 41 条，而且全在 08-21 一天里。）
这一页说清每件缺什么、谁来做、你能不能替。
2026-08-24 补：开头加了第 01 段
企业大脑板块组成——六块各是什么、内部那条
「文件 → 正文块 → 候选说法 → 人采纳 → 进提示词」的链与三道闸、当天查库的真实条数，
以及下一步五条提升点各要多久。
末尾两段是门店工作台的另外两条链路——第 08 段 短视频获客、
第 09 段 微信接待（那批候选的出口就在那儿）。
两段的写法一样：由什么组成、内部怎么分层、下一步做什么、各要多久。
先说清「企业大脑」这四个字在产品里到底指哪几屏、它们靠什么串起来。 下面每个数字都是 2026-08-24 直接查库数出来的，不是估的。
本段发出后跑了一遍独立审查（审查者拿不到我的推理过程，只拿产物 + 库的只读权限）， 判定不通过。逐条复核后九条全部成立，已在下文就地更正并保留原话， 因为「哪里错了」比「现在对了」对下一个写这类页面的人更有用：
· 把别页的旧数挂上「实测」二字——④ 那句「实测 601 行里 0 条」，分母是从 03 段搬来的
08-20 旧数，分子实际是 1。结论没错，唯一给出的证据错了，而且同一段上面就写着 604。
· 把设计意图当成现状——说 sw_facts 是「本店独有事实」，实测 155 条里 103 条
属总部、真正门店确认的只有 2 条，方向跟我警告的正相反。
· 把「有这个能力」当成「覆盖到位」——说「3,899 个正文块带位置」，实测只有 1,441 块（37%），
而且这一条被我写在「确认合理、不用动」里。
· 从表名推语义——把 kb_entries 说成「积木条目」（它在代码里的名字是「检索库」，
没有 brick_code 列，500 条里 362 条根本不属本店），把 kb_chunks 挂到
knowledge_documents 底下（它没有 document_id 这一列）。
· 同页数字打架却写「对上了」——03 / 07 段还是 601 / 1，本段是 604 / 41；「覆盖 42 格」
和「只盖 11 格」是两个口径没标。已全部同步。
· 把一条只读查询能结案的事排成 0.5 人天——原 ⑥「冲突检测是不是真在跑」，
判据是确定性的，查一次就知道「只检出 1 条」是正确输出，已移进「确认合理」。
· 另有 expired 不是「到期」（全库 valid_until 皆 NULL）、
② 的零假设不可证伪、③ 的样本只有 20 行三处，均已改。
| 这一块 | 回答的问题 | 东西存在哪 |
|---|---|---|
| 全景积木墙 E01–E08 八章、48 格 |
本店的知识哪几格有、哪几格空 | specs/bricks.ts 格子清单本身在代码里，不在库里——一家店改不动它 |
| 积木详情 | 这一格底下挂着哪些资料、代表性原文是哪一段、本店最终用哪个版本 | kb_elements |
| 原件目录与文档详情 | 这句话是从哪份文件的哪一段来的 | knowledge_documents kb_entries → kb_chunks ⚠️ kb_chunks 挂的是 kb_entries（检索库），不挂 knowledge_documents——它没有 document_id 这一列 |
| 待审知识元素 | 传上来的文档拆出了哪些候选说法，哪些被采纳 | kb_elements（draft → enabled） |
| 本店独有事实 | 设计上放地址、店长、本店活动、交期这类只属于这一家店的话。 ⚠️ 实测内容已经串了，见下方那条 note |
sw_facts · sw_fact_conflicts |
| 接待侧的消费面 | 大脑里的东西怎么变成机器人嘴里的话 | decision_rules · conversation_examples sw_faqs · sw_plugins · sw_bot_rules |
kb_elements 是总部口径（价格体系、配置单、工艺、流程、质保），org 级，一改所有门店都跟着变；
sw_facts 是这一家店自己的话（地址、店长、本店活动、交期），门店级。
界面上必须写清进哪个口——写不清的话，销售把「本店三月活动」传进总部口径，别的门店就开始对客户说一个不存在的活动。
⚠️ 但实测口径已经串过一次，而且方向跟上面担心的相反（2026-08-24 查库）：
155 条 sw_facts 里 103 条 owner_name 是「有大有小总部（甲方）」、
50 条为空，真正标「门店确认」的只有 2 条；category 以 price(55) / service_area(29) /
aftersale(18) / material(17) 为主——总部的价格体系正躺在门店级那张表里。
分层在 schema 上是真的（sw_facts 有 store_id、kb_elements 只有 org_id），
在内容上还没执行。
从一份文件到机器人嘴里的一句话，中间是固定的六步。
kb_chunks，留原文；能算出位置的才留位置——实测 3,899 块里只有 1,441 块（37%）带 locator，Word 来源结构性拿不到（代码注释原话：「Word 那部分永远是 NULL，写死一个百分比过两周就是假话」）。出处面板能点回原文那一段靠的是这一步，但只有那 37% 点得回去。kb_elements，状态 draft。这一步是机器做的，所以它不算数。enabled，并记下是谁点的。draft 不进机器人的提示词。llm_call_provenance.element_ids，事后查得到「这句话是哪块积木说的」。三道闸各拦一件事：
带正文的快照整体搬进只有服务端读得到的目录，从一个 server-only 的口往外给。判据是「字节发不发得出去」，不是「渲染不渲染」——静态 chunk 谁都能从 devtools 里读出来。
draft 一律不进提示词。机器抽出来的说法在没人点头之前，不代表这家店说过。
同一件事出现两种说法时进 sw_fact_conflicts，裁决之前暂停使用，不让两句打架的话同时出现在客户面前。
| 表 | 条数 | 怎么读这个数 |
|---|---|---|
| knowledge_documents | 93 | 进过大脑的文档行。⚠️ 不是「原件」：asset_url 实测全为 NULL，库里存的是正文不是文件 |
| kb_chunks | 3,899 | 切出来的正文块；其中 1,441 块（37%）带 locator、点得回原文位置，其余（主要是 Word 来源）只有正文没有位置 |
| kb_entries | 500 | 检索库条目（代码里的中文名就是这三个字），不是积木、也没有 brick_code 列。其中 362 条 org_id 为空（全行业公共行），属本 org 的实为 138 条 |
| kb_elements | 604 | draft 557 · enabled 41 · retired 6 |
| sw_facts | 155 | active 131 · expired 23 · superseded 1。⚠️ expired 不是「到期」：全库 valid_until 皆为 NULL，那 23 条是 08-04/05 人工停用的 |
| sw_fact_conflicts | 1 | 唯一那条 key=斗柜计价方式，已于 2026-08-04 裁决（status=resolved）；当前未裁决 0 条 |
| conversation_examples | 239 | 接待侧的例子 |
| decision_rules | 52 | 接待侧的规则 |
| client_material_submissions | 173 | ingested 168 · rejected 5 |
| sw_faqs / sw_plugins / sw_bot_rules | 8 / 8 / 11 | 接待侧的其余配置面 |
41 条的 updated_at 全是 2026-08-21，那之后三天一条都没有再采纳；
而 557 条 draft 里有 541 条是 2026-08-17 一次性抽出来的。
也就是说采纳不是「在缓慢推进」，是有人集中点了一批，然后停了。
这跟本页 03 段的结论对上了（03 段与 07 段的
601 / 1 是 08-20 那次的数，已同步更新成 604 / 41），而且把它说得更准：卡的不是工程，
工程早就通了（08-21 起 element_ids 已经有值）。卡的是没有一个理由让人天天来点。
「几格」这个数有两个口径，别混：全部 604 条候选覆盖 42 格（07 段那个 42 是这个口径）， 而已采纳的 41 条只覆盖 11 格。两个数都真，含义不同。 另外 48 格里有 6 格（E01-03 / E02-08 / E04-01 / E04-05 / E05-03 / E08-03） 一条候选都没有——它们不属于「躺着」，批量采纳补不上，要另外补资料。
口径：kb_elements 全表，未按 org 拆；采纳率 41 / 604 = 6.8%。
每条带一个 0–1 的置信度和一句零假设（如果这条其实不成问题，我应该看到什么）。
置信度低于 0.6 的一律不排进「该做」。人天按一个人全职算。
首发时这里还有一条「⑥ 冲突检测是不是真在跑 · 先查不做 · 0.45」——复审时一条只读查询就把它结案了，已移进下方「确认合理」。
| 提升点 | 为什么 | 预估 | 置信度 / 零假设 |
|---|---|---|---|
| ① 候选批量采纳 + 按章节筛 多选、全选本章、一次确认 |
557 条要一条条点开确认。这不是「效率低」，是一件没人会开始做的事——它已经停了三天。 | 1.5 天 | 0.90 零假设：若不成问题，enabled 应该逐日增长；实测 08-21 之后为 0。 |
| ② 先抽检 50 条候选的质量 人工标「能用 / 不能用 / 要改」 |
排在 ① 前面做。不知道这 557 条里有多少能用就上批量采纳，等于把噪音一次性灌进提示词——那比现在糟。 | 0.5 天 | 0.75 零假设：抽检 50 条里「能用」应 ≥70%；低于此则 ① 的批量采纳必须先加过滤。 （原来这里写的零假设是「看那批 41 条的分布」——那个证伪不了「剩下 557 条质量未知」，无论查出什么都不改变结论，等于没有零假设。已知事实：那 41 条由「温总（管理者）」在 08-21 一小时内点完，散在 6 章 11 格、E01-02 独占 21 条，是挑着点，所以那批不能代表整体。） |
| ③ 积木上的「被调取次数」 | 设计稿三件套里现在唯一还缺、但数据确实存在的一个（在 Akke 主仓的回话账本里）。口径只能叫「被调取」——账本记的是喂进 prompt 的，不是模型真用了的。 ⚠️ 样本极薄：截至 08-24，180,926 行回话账本里 element_ids 非空只有 20 行、覆盖 12 条元素（08-21 起共 3 天）。做出来短期内多数格子会显示 0，所以它排在 ① 之后。 |
2 天 | 0.85 零假设：若做不了， element_ids 应该恒空；实测 08-21 起已有值。 |
| ④ 「这块判错过」这本账 | 现在根本没有写入路径：聊天页那个「事实错误并更正」只写了更正后的说法，没留一笔「这块被判错过」。没有这笔账，「哪块积木不可靠」就永远答不上来。 | 1.5 天 | 0.80 零假设：若已经有账， kb_elements 里应出现由「聊天页更正」写入的行。实测 604 行里 fusion_mode='manual' 仅 1 条（2026-08-21，E01-01，来自积木详情的手工新建，不是聊天页更正）——该入口写入量为 0。（本页首发时这句写的是「实测 601 行里 0 条」，分母是从 03 段搬来的旧数、分子也不对，已更正。） |
| ⑤ 停用事实的回填出口 | 155 条里 23 条 status=expired。口径先说清：这不是「到期」——全库 valid_until 皆为 NULL，没有任何一条设过有效期；那 23 条是 2026-08-04/05 人工停用的（全仓唯一置 expired 的代码路径是 facts.ts:suspendBothInConflict），此后 19 天没动。停用之后没有「谁来补一条新的」的出口。 |
1 天 | 0.60 零假设：若不成问题，那 23 条上应有 superseded_by 指向后继——实测 0 / 23，全库 superseded 只有 1 条（那次冲突的败者）。（原写「expired 的应该多数已有 superseded 的后继」在数据模型上不成立：有后继的那条 status 就会是 superseded，两者互斥。换成看 expired 行上的 superseded_by，结论方向不变。） |
· 出处链路通，但覆盖只有 37%：1,441 / 3,899 块带位置、点得回原文那一段；其余（主要是 Word 来源）
结构性拿不到位置。链路是真的，覆盖率不是——这一条本页首发时写成了「3,899 个正文块带位置」，已更正。
· 租户隔离：带正文的快照已经收进 server-only 的读取口，判据落在字节而不是渲染，这个收法是对的。
· 采纳闸：draft 不进提示词（elements.ts 取消费面时硬钉 status:'enabled'）。
机器抽的东西默认不代表这家店，这条不要为了「让数字好看」放宽。
· 冲突闸确认在跑：判据是确定性的——同 store 同 key、两条都 active、value 不同
（facts.ts:detectConflicts）。实查 131 条 active 事实的 (store_id, key) 组合正好 131 个、
没有一个 key 带两个不同 value，所以「只检出 1 条」是判据的正确输出，不是漏检；
那 1 条还是 2026-08-04 生产真实命中（key=斗柜计价方式）并已裁决。
剩余风险只在「同一件事被写成两个不同的 key」，那是判据的已知边界，不是故障。
（本页首发时把这一条排成了「⑥ 先查不做 · 0.5 天 · 置信度 0.45」，暗示系统可能坏了——
实际一条只读查询就能结案，已改到这里。）
· 两套知识分表：sw_facts 有 store_id、kb_elements 只有 org_id，
schema 上的分层是真的。但内容上已经串了（见上面那条 note），别把「表分开了」读成「口径分开了」。
合计：该做的五条约 6.5 天。顺序：② → ① → ③ → ④ → ⑤。
有帮助，理由不是「多了一屏」，是它给采纳动作一个理由。 上面那个 6.8% 的真问题不是「点起来慢」，是点完之后没有出口—— 采纳一条积木，店长这个月的工作不会有任何变化，那就没人会天天来点。
04 段那份月度实战手册恰好是这个出口：它把「大脑里存了什么」变成 「这个月门店要按哪几句话去讲」。一旦手册每月真的要出，采纳就从一件对谁都没影响的整理工作 变成不做手册就出不来的前置。
所以排期建议是：手册的 Phase 1/2 与上面的 ② → ① 并排做，不要串行。 先做手册但没人采纳，手册就没米下锅；先做批量采纳但没有手册，557 条点完之后还是没人再点第 558 条。
都落在企业大脑自己那几屏里，不碰别的模块。三处都还没在真实登录态下肉眼验过。
| 改动 | 在哪看 | 来自 |
|---|---|---|
| 积木上「N 天没更新」 超过 30 天才显示，取一格底下最近那次更新 |
全景 · 积木墙 | 设计稿要的「引用 / 差评 / 更新时间」三件套里，唯一有数据的那个 |
| 全景顶部「N 格超过 30 天没更新」 | 全景 · 槽位分布下方 | 同上。它和「空槽位」不是一回事：空槽位是没资料，这个是有资料但很久没人动过——后者更隐蔽，界面上一直绿着「已核实」 |
| 「4.2 设置与工具」两屏进侧栏 本店可对外说什么 / 原始资料目录 |
侧栏 · 企业大脑 | 设计稿的 4.2.1 / 4.2.5 |
| 待办栏「594 条积木选项等你确认」 | 全景 · 需要你处理 | 不在设计稿里 查库查出来的断链 |
另外 6 屏——版本与发布 / 历史上传文件 / 文档处理详情 / 装修要知道什么 / 本店怎么交付 / AI 扩展模块—— 整屏是硬编码或 2026-08-04 的冻结快照。照设计稿提上去，等于把 6 个假屏摆到甲方眼前。
「版本与发布」尤其贵：它是一道假的发布闸，店长会以为机器人真按它走。
为此加了一条硬闸——侧栏一级的屏一屏都不许是示例数据，下次谁照设计稿删 parent 会直接红在 CI 上。
每件都重新查过一遍，不是凭印象。
182,730
llm_call_provenance 全量行数10,874
operation = chatReply已开始
08-21 上午起element_ids 开始有值（最近 300 条回话里 4 条）。08-20 那次抽样 0 行，是当时只有 1 条 enabled、命中不了这一条我连续三轮给了三个不同的错误归因，逐条撤回：
| 我说过 | 实际 |
|---|---|
| wecom-chat 没接 kb_elements | ❌ 接了，src/lib/kb-elements.ts 完整存在 |
| 桥建好了但开关没开，卡在覆盖率闸 | ❌ 线上 /api/status 实测 kb_elements: true，开着的 |
element_ids 全空是开关关着 | ❌ 是当时只有 1 条 enabled，命中不了 |
真实因果是两个时间点的对照，不是单点推断：
| 时点 | enabled | element_ids |
|---|---|---|
| 2026-08-20 | 1 条 | 抽样 1,000 行，非空 0 |
| 2026-08-21 | 41 条 | 开始有值（08-21 上午产生 4 条） |
所以这不是「卡住了」，是「刚开始转」。采纳 → 命中 → 攒出「被调取 / 差评」两个数， 这是个自我强化的循环，起点就是有人去采纳。1 条 enabled 时它转不起来；41 条时账就开始有了。
设计稿要的那两个数字，现在的状态是「数据太少，还算不出有意义的结果」， 不是「算不出来」。
0
fusion_mode = manual 604 行里 1 条（2026-08-21，E01-01，来自积木详情的手工新建，不是聊天页更正）——那个入口仍是零使用，但原写「601 行里 0 条」两个数都不对7
136 段会话里triage = maybe_wrong2
其余 134 段review_state = unreviewed第一层：会话级的「可能答错」信号是有的（7 段），但它回答不了「哪块积木在坑我」—— 标的是整段会话，不是某一条知识。
第二层：归因到积木的那条路径零使用。聊天页那个「这是事实错误，同时更正知识积木」的勾选， 从上线到今天一次都没被用过。
第三层（新）：那个勾选在绝大多数会话上根本不会出现——不是没人用，是看不见。
它的前置是「这句机器人回复查得到出处」，而出处面板按 conversation_id 查账。
实测 25 段最近会话、218 句 AI 回复，只有 16 句贴得上出处 = 7%。
先说结论：我上一版在这里写的归因是错的，已撤回。当时写的是
「首触那一刻会话还不存在，所以账挂不上 conversation_id」——
听起来合理，但一查就塌了。
| 最近 1000 条 chatReply 账 | 条数 | 真身 |
|---|---|---|
空 conversation_id · 首触 | 743 | 全部带 comment_id、prompt 是 dm.ice_break.system —— 这是抖音私信首触，归 Akke 仓。抖音首触本来就没有会话，它挂 comment_id，完全正确，不该改 |
空 conversation_id · 非首触 | 45 | wecom.nurture.rules —— 这才是企微真漏的，占企微 nurture 的 20% |
有 conversation_id | 212 | 企微 nurture 181 · decision 12 · 身份直答 6 · 抖音 nurture 9 |
企微首触早就传了 conversationId（route.ts:1983），四个
chatReply 调用点里只有抖音 opener 那个不传——而它本来就不该传。
所以「首触回填」这条改动取消，不做。
已知（实测）：25 段最近的企微会话（全部 channel=wecom_chat，
创建于 07-26 → 08-10），名下共 440 条账——但只覆盖 3 段会话，
另外 22 段一条账都没有，而它们各自有 7–8 句我方回复。
未知：那 22 段为什么没有账。可能是那些回复本来就是销售人工打的字
（messages.role='ai' 表示「我方发的」，不区分人发还是机器人发），
也可能是别的路径没写账。这一步没查完，不写结论。
但不管是哪一种，对「差评」这个数的影响是同一个：出处贴不上 → 「这是事实错误」的勾选不显示 → 没人产生负反馈信号。 下一步该查的是那 22 段的回复到底谁发的，而不是去改首触。
甲方传资料 ──▶ AI 拆成 604 条候选 ──▶ 人采纳（604 条里采了 41 条）
│
✗ 断在这里
│
桥通着、开关也开着（kb_elements: true）
缺的是 enabled 数量 —— 采纳越多，命中越多
│
┌─────────────┴─────────────┐
「被调取 N 次」算不出 「差评 N 次」归不到积木
设计稿要在每块积木上摆的那两个数，不是我们没写代码——代码两边都写好了。 断的是第 3 步：候选没人采纳，于是开关没有理由拨开（08-20 是 594 条；08-24 复查仍有 557 条 draft）。 桥一旦通电，两个数同时就有了——「机器人这轮用了哪几块积木」正是它们共同的分母。
所以这不是工程问题。全库 604 条候选只有 41 条处于启用状态（08-24 复查；08-20 那次是 601/1）； 即使今天就把开关拨开，可被调取的也只有那 1 条。要先有人去采纳。
设计稿里唯一标「新增」的整屏。把当月真实客户对话蒸馏成一份给人读的册子—— 积木墙是给机器人用的活知识，这一份给新销售和店长。
| 节 | 需要的信息 | 现状 |
|---|---|---|
| 业务速览 1 条 | 已确认的本店口径 | 现成 knowledge_documents 93 条 |
| 高频问答 28 条 | 当月对话 + 按频次聚类 | 勉强 136 段会话 / 961 轮（设计稿假设 431 段） |
| 异议处理 12 条 | 异议 + 当时怎么接的 | 可绕过 蒸馏时用模型识别，不必等企微加标注 |
| 话术禁区 9 条 | 哪些话说错了的记录 | 无米下锅 就是第 02 节那个零使用的入口 |
| 成交信号 7 条 | 结果标注（谁最后约上了） | 只能累计 成交案例累计 29 条、本月仅 2 条 |
| 标杆片段 6 条 | 同上 | 只能累计 同上 |
「实际到店」没有任何后台记录点——到店发生在线下，除非门店回填，否则谁也不知道。 这句话是线上代码里写死的，不是我们的选择。
所以不要去建到店自动回写，那件事物理上做不到。现实路径只有一条：沿用已有的人工入口 （企微自动接待的「金牌案例」屏，店长把到店成交的聊天记录贴进来），把它接到手册上。 代价是成交信号与标杆片段是「累计口径」不是「本月」，而这必须写在屏上—— 混在一起会让店长以为本月成交了 6 单。
┌──────────────────────────────────────────────────────────────┐ │ 把这个月的真实客户对话，蒸馏成一份能给人读的册子。 │ │ 新销售入职当天发一份；店长用它看团队打法。 │ │ │ │ ┌ 2026 年 8 月版 ───────────┐ ┌ 和积木墙的分工 ──────────┐ │ │ │ 状态：待你审核 │ │ 积木墙（4.1.5） │ │ │ │ 覆盖：136 段会话 · 961 轮 │ │ 机器人每天在用的活知识 │ │ │ │ 生成于 08-20 14:02 │ │ 月度实战手册（本屏） │ │ │ │ [重新生成] [审核并发布] │ │ 给人读的快照，月度一版 │ │ │ └────────────────────────────┘ └──────────────────────────┘ │ │ │ │ 节 这个月的内容 条 状态 │ │ 业务速览 30 秒说清我们卖什么、跟隔壁差在哪 1 ✓ │ │ 高频问答 客户这个月最常问的，按被问次数排 28 ✓ │ │ 异议处理 「太贵了」「再考虑考虑」怎么接 12 ✓ │ │ 话术禁区 说了就砸招牌 —— 含本月踩过的 3 条 9 ⚠必审 │ │ ────────── 下面两节口径不同，见说明 ────────────────────── │ │ 成交信号 客户说到哪几句就该约量房了 7 ✓ │ │ 标杆片段 成交对话里值得全员学的原话 6 ✓ │ │ │ │ ⚠ 后两节不是「本月的」：来自累计 29 条到店成交案例， │ │ 本月只新增 2 条。到店发生在线下、后台没有记录点。 │ └──────────────────────────────────────────────────────────────┘
1. 每一节都要显示「从哪来、覆盖多少」。不写来源的册子，读者没法判断可不可信；而这一屏最容易被当成「AI 编的」。
2. 后两节的「累计 ≠ 本月」必须写在屏上，不能藏在文档里。
3. 数据不够时那一节留空并写明原因，不许用别的内容填满装作完整。
4. 「审核并发布」之前，手册对新销售不可见。草稿态只有店长看得到。
这是验收标准，不是愿景。三条缺一不可——少任何一条，这功能都会变成「生成了、没人读」。
有固定消费时点
新人入职清单里有一条「读本月手册」；月度团队会有一节「过本月禁区」。没有时点的文档没人读。说得出知识库里没有的话
「本月踩过的禁区」和「成交对话原话」必须非空——它们是任何静态文档都给不了的，也正是前置工作的产物。读完改得动系统
看到一条禁区能一键变成机器人规则 / 更正那块积木。否则两张皮，人发现「看了也改不了」，第二个月就不看了。若结果标注迟迟打不通，先出四节版（业务速览 / 高频问答 / 异议处理 / 话术禁区）， 成交信号与标杆片段留空并写明原因。把缺口显性化，好过用别的内容填满装作完整—— 这类内部文档只有一次首因机会，第一版被判定为「没用」，第二版就没人打开了。
enterprise_sales_cases；成交信号从同一批里提取；在屏上明写累计口径；本月新增案例 < 3 时反向在金牌案例屏挂待办。按「这件事非谁不可」分，不按「谁比较闲」分。 一件事如果技术上谁都能点、但业务上只有一个人判得了，那它的责任人是后者。
| 要做的事 | 责任人 | PM 能不能替 | 解开之后 |
|---|---|---|---|
| 把那 557 条候选采纳掉 摊在 42 个积木格里，E03-03 一格 166 条 |
门店店长 / 甲方 | 不该替 技术上有 manager 权限就点得动，但采纳＝替门店确认对外口径，错了机器人照错的说。除非你本人清楚一筑的价格与工艺口径。 |
机器人可引用的知识从 1 条变成几十条；开关才有理由拨 |
| 给 4 份工艺文档补跑拆分 PUR 封边 / 多层板背板 / 9mm 卡槽 / 悍高五金 |
技术 | 不用你做 脚本可跑， ingestDocument() 支持传 sourceDocumentId。产出是 draft，不影响机器人。 |
采纳后覆盖率从 89/93 变 93/93，闸的第一条才可能过 |
| 决定 166 条怎么变得可处理 去重？按来源聚类？先推荐 3 条？还是允许整格批量采纳？ |
产品（你） | 这就是你的 一格 166 条、要读完才能选一个——这是产品形态问题，不是工程问题。不定这个，采纳率提不上来。 |
采纳这件事从「不可能完成」变成「一天能干完」 |
| 把候选采纳掉 08-20 只有 1 条 enabled，08-21 已到 41 条，还剩 557 条 draft |
门店店长 / 甲方 | 不该替 采纳＝替门店确认对外口径，错了机器人照错的说。这是唯一还卡着的一条——开关早就开着，桥也通着，缺的只是数量。 |
「被调取 / 差评」两个数开始有意义 |
| 查清 22/25 段企微会话为什么一条账都没有 原写「首触回填 conversation_id」——已撤回，那 743 条是抖音首触，不该改 |
技术 | 不用你做 先分清那些回复是销售人工打的还是机器人发的。是人工发的话，7% 就不是缺陷；是机器人发的，那才是漏写账。没查清之前不动代码。 |
知道「差评这个数拿不到」到底是不是个可修的问题 |
| 让「这是事实错误」那个勾选真的被用起来 上线至今零使用 |
用抽检聊天的人（销售 / 运营） | 只能定规矩 你能定「每周抽检 N 段、答错的必须勾」，但替不了他们点。前提是上一行先修好——现在 93% 的会话上那个勾选压根不显示，怪不到人头上。 |
话术禁区有料；差评能归因到具体积木 |
| 金牌案例持续投喂 累计 29 条，本月只进 2 条 |
店长 | 只能定规矩 你能定「每月至少 N 条到店成交聊天记录」。案例本身只有店里有。 |
手册的成交信号 / 标杆片段站得住 |
采纳和拨开关缺一不可：桥不通，采纳再多也统计不到；只拨开关不采纳， 可调取的仍然只有 1 条。任何一条单独做完，设计稿上那两个数字都还是出不来。
而这两条的共同前置是第三条——166 条候选摆在一格里没法处理，采纳就不会发生。 所以真正该先动的是产品决策，不是工程。
| 手册这一节 | 归哪个板块 | 那个板块要做什么 |
|---|---|---|
| 业务速览 / 高频问答 / 异议处理 | 企业大脑 | 技术自己能完成，不需要别人配合 |
| 话术禁区 | 企微自动接待 | 让抽检聊天的人真的用那个「这是事实错误」的勾选 |
| 成交信号 / 标杆片段 | 店长（不是任何技术板块） | 把到店成交的聊天记录贴进金牌案例屏 |
| 反向管道：高频问答 → 视频选题 | 短视频获客 | 选题候选池接收手册产出的「本月最常问 Top N」。做了手册就多一个「被用上」的证据 |
早前我把沉默客户跟进列成「结果标注的上游」。那是错的。 线上代码注释写死了：「实际到店没有任何后台记录点——到店发生在线下， 除非门店回填，否则谁也不知道」。
所以沉默客户跟进那边没有东西可给，它不是这件事的上游。 成交结果的唯一来源是店长手工贴的金牌案例。
| 数字 | 值 | 来源 |
|---|---|---|
| 知识候选总数 / 已启用 | 604 / 41 08-20 那次是 601 / 1 | kb_elements |
| 待确认（可启用 / 冲突行） | 594 / 6 08-24 复查：557（另 enabled 41 · retired 6） | kb_elements status=draft |
| 候选覆盖积木格数 | 42 口径是全部 604 条候选；已采纳的 41 条只覆盖 11 格。另有 6 格（E01-03 / E02-08 / E04-01 / E04-05 / E05-03 / E08-03）一条候选都没有，批量采纳补不上，要另补资料 | 同上 |
| 灌入批次 | 08-15：16 · 08-17：585 08-17 那批里 541 条至今仍是 draft | 同上 created_at |
| 回话账本总量 / 本月 chatReply | 182,730 / 10,874 | llm_call_provenance |
| 本月会话 / 对话轮次 | 136 / 961 | sw_conversations / sw_conv_turns |
| 会话判定 clean / watch / 可能答错 / 高意向 | 89 / 38 / 7 / 2 | sw_conversations.triage |
| 成交案例 累计 / 本月 | 29 / 2 | enterprise_sales_cases |
| 进过大脑的文档行 | 93 | knowledge_documents ⚠️ 原写「本店口径事实」不准： asset_url 全为 NULL，库里存的是正文不是文件；也不都属本店 |
| 冲突记录 / 其中待裁决 | 1 / 0 | sw_fact_conflicts 唯一那条 key=斗柜计价方式 已于 2026-08-04 裁决（status=resolved），原写「待裁决 1」是错的 |
| 出处贴上率（25 段最近会话） | 16 / 218 = 7% | messages × llm_call_provenance · 5 分钟窗 |
| chatReply 账缺 conversation_id | 788 / 1000 | 其中首触 743 |
1. 那 557 条 draft 是正常中间态还是采纳流程有摩擦——采纳动作本身可用（有真人 08-19 成功采纳过 1 条），但没测过一格 166 条时界面还好不好用。
2. 上面的数是用服务角色查的全库，没按门店拆——多门店时口径会变。
3. 那 29 条成交案例只数了行数，没读内容，质量未知。
4. 已上线那三处改动，没有在真实登录态下肉眼看过——需要一个真门店账号。
这一段是 2026-08-23/24 两轮实地走查之后补的。上面七段讲的是企业大脑； 短视频获客是门店工作台里另一条独立的链路——它不读企业大脑的知识， 也不往企微发东西，唯一的交叉点是「都跑在同一个门店 Workspace 里」。 数字为 2026-08-24 直查 Supabase 实测。
界面上看起来是并列的八屏，实际是两种完全不同的节奏。混在一起看是这个板块 最容易被误解的地方——所以 08-23 起设置区整片不再挂右侧「我的任务」栏： 配类目、传素材、登记出镜人跟「今天哪条片做到哪了」没有半点关系。
| 档 | 屏 | 它产出什么 | 现在库里有多少 |
|---|---|---|---|
| 配一次 | 业务类型 | 主营/兼营类目、服务城市 | — |
| 素材库 | 门店自己的视频 / 图片 / 音频 | 35 条（ready 25） | |
| 真人出镜 | 出镜人档案 + 肖像/声音授权 | 4 位（齐的 2 位） | |
| 抖音账号 | 发布用的登录态（Cookie） | 1 个 | |
| 每天动 | 批量剪辑（四步向导） | 今天要做的选题 → 提单 | 62 条任务累计 |
| 视频生成（拆解 / 制作中 / 成片） | 每条片子做到哪了、成片验收 | 36 条等人审 |
门店有什么可拍的、谁能出镜、发到哪个号。跟今天做不做片子无关，所以它不该跟着日常任务栏走。
业务类型 · 素材库 · 真人出镜 · 抖音账号从候选池挑参考片 → 定出镜人 → 写给产线的要求 → 核对后提单。提单那一刻才开始花钱。
批量剪辑四步：选题 · 出镜形象 · 文案要求 · 生成产线按状态机回写进度，做完停在「等你审」不会自己发出去。
video_jobs 状态：queued → running → script_review → review → done1. 素材归属只有一层。08-22 加过一张「文件夹」表，跟原有的「场景标签」并列成两排长得差不多的东西，用户第一眼就问「为什么要填两遍」。08-23 收成一层「类别」（预置 8 类 + 门店自建），归属仍写在 sw_assets.tags——不改成外键是因为 tags 是产线找 B-roll 的依据（提单时固化进 assets_snapshot.materialTags），改外键要同步改不在这两个仓里的产线。
2. 出镜人「四件套」齐了才能提单。形象照 + 出镜视频 + 声音确认 + 肖像/声音授权。缺一件的人在选择器里灰着并写明缺什么——不写的话店长会以为页面坏了。
3. 源片逐句口播这条链路上没有。上游 feed 只带标题、作者、互动数和热评，没有转写。逐镜口播要本机 douyin-deconstruct 跑 7–8 分钟。
4. 抖音号只能粘 Cookie，不能输主页链接。主页链接只说明「这个号是谁」，不给「以这个号的身份发东西」的权限；扫码那条路走不通（店长扫的是他自己的浏览器，服务器收不到回调）。
| 用户看到的 | 真因 | 改法 |
|---|---|---|
| 「工地现场」这些和上面的文件夹是一回事，为什么填两遍 | 两套并行分类，一套是我们加出来的 | 收成一层「类别」，8 类 + 自建，改单选 |
| 成片已出 100%，右边还写「拆解中」 | 无条件写「正在拆」；实测 62 条里 60 条从来没有拆解结果 | 按任务状态分说：已出成片直接讲「不会再有了」 |
| 上传时间要手填「从 xx 到 xx」，太费人力 | 把系统已知的事推给人猜 | 换成下拉，库里有哪几天就列哪几天（带条数） |
| 只有卡片式；不能一次处理很多条 | — | 卡片/列表真切换 + 批量选择 → 批量改类别 / 批量删除 |
| 点第 2/3/4 步只有一句「先去选题」 | 把「先看懂流程」和「已经开始干活」绑死了 | 每步各写各的说明，第 2 步直接渲染真实出镜人名单 |
| 添加账号：输主页链接就行吗 | 只改了称呼没回答那条链接为什么不管用 | 就地一份四步清单，先说不行再说为什么 |
| 页面还在说「扫码」 | 扫码时代的措辞残留 | 按钮/空态/占位全部改成导 Cookie |
| 「用哪个形象出镜」没法新增 | 它只是选择器，不是管理页，而名单非空时一个字没说 | 加一行指路到「设置与工具 → 真人出镜」 |
| 「用哪个形象出镜」标题出现两次 | Card 套 Card | 换成不带外壳的 HostControls |
每条带置信度（0–1）和零假设——如果这条其实不成问题，我应该观察到什么。 用时是单人工程时间，不含评审与等产线侧配合。
| # | 提升点 | 依据（实测） | 零假设 | 置信度 | 预估 |
|---|---|---|---|---|---|
| 1 | 失败任务归因面板：把 error_code 分档，让人知道 21 条到底死在哪一段 |
62 条里 21 条 failed（34%），且全部没有拆解产物 | 如果这些 failed 是同一个已知外因（例如某天产线停机）批量产生的，那不是产品问题，只要一句说明 | 0.85 | 1 天 |
| 2 | 拆解这一档要么接上、要么收起：现在它对多数任务永远是空的 | 62 条里只有 2 条真有拆解结果 | 如果云端产线本来就会回写拆解、只是这批任务早于该功能，那新任务应该开始有——观察 7 天新单即可证伪 | 0.9 | 0.5 天（收起） 2–3 天（接通，需产线侧） |
| 3 | 发布闭环：成片出来之后到「发到抖音」这一段界面还没有 | sw_publish_tasks 0 行，三张表 08-22/23 刚建；抖音号只登记了 1 个 |
如果门店本来就打算人工下载后手动发，那这段不做也不阻塞 | 0.8 | 3–4 天 |
| 4 | 素材类别脏数据归并 + 上传时类别必选 | 35 条里 15 条没有类别、6 条挂着多个标签；还有 迁移登记／公开桶外链 两类历史标签各 6 条 |
如果没类别的那 15 条都是出镜人专用素材（本来就不进素材库列表），那它不算脏 | 0.75 | 0.5 天 |
| 5 | 出镜人就绪率：补齐提醒 + 清掉测试数据 | 4 位里只有 小黄、小黑 四件套齐；「我本人」缺肖像与声音授权；「钢铁侠」疑似测试数据 | 如果「钢铁侠」是门店故意登记的虚拟形象，那它不该删，只是缺素材 | 0.7 | 0.5 天 |
| 6 | 选题阶段就能看到源片文案：抓视频时顺带跑一次转写（ASR） | 上游 feed 字段实测无 transcript／字幕／转写；现在只能提单后本机拆解 7–8 分钟 | 如果店长实际是靠封面和热评选题、并不看口播，那这条价值不大 | 0.6 | 2 天 属 Akke 仓，另一条链路 |
| 7 | 批量提单：列表式和批量选择已经做好，下一步是「勾一批直接提」 | 现在批量只能改类别/删除；提单仍是四步向导一次一批 | 如果门店每天就做 1–3 条，四步向导已经够用 | 0.55 | 1.5 天 |
合计：不含 #2 接通与 #6 的话约 6.5 天；全做约 11–12 天。
· 提单后停在「等你审」不自动发布——这是对的，不要为了「全自动」把它拿掉。
· 素材归属留在 tags 不改外键——改外键要同步改不在这两个仓里的产线，收益只是换一种存法。
· 出镜人四件套硬闸——授权缺失就出片是合规风险，灰掉并写明缺什么是正确做法。
· 素材类别用预置清单而不是自由建夹子——自由建三个月后会长出「展厅／展厅照片／新展厅」四个并列项，筛选器当场作废。
1. 上面所有数字是用服务角色查的全库，没按门店拆——多门店时口径会变。
2. 62 条任务里那 21 条 failed 没有逐条读 error，只数了行数。
3. 08-23/24 两轮的改动没有在真实登录态下肉眼回看——跟上面那三处已上线的改动是同一个缺口。
4. 预估用时是单人工程时间的直觉估计，没有按任务拆到子项，误差可能到 ±50%。
依据。屏名、字段、判据取自 Akke-AI/store-workbench 线上代码（origin/main）；
数字为 2026-08-20 直查 Supabase 实测。设计稿依据为门店工作台 V6 产品设计原型稿次 #6.1。
短视频获客那一段（07）。屏名、判据、状态机取自 Akke-AI/store-workbench origin/main；
数字为 2026-08-24 直查 Supabase（video_jobs 62 行、sw_assets 35 行、
sw_persons 4 行、sw_publish_tasks 0 行）。走查改动对应
PR #505 / #511 / #514 / #516。
相关。月度实战手册的完整执行契约落在仓内
docs/requirements/2026-08-20-月度实战手册.md；本页是它的对外摘要，两者不一致时以仓内那份为准。
内部评审用，含第三方产品调研信息，请勿外发。
模块二（wb.hzcytech.cn/wb#sales-overview）。 这一页原本只讲企业大脑，加这一节是因为两个模块吃的是同一批料—— 大脑那批没人采纳的候选（08-24 复查仍有 557 条），最终要在这里变成机器人嘴里的话。 下面每个数字都是 2026-08-24 直接查库得到的，样本是目前唯一一家门店。
| 编号 | 屏 | 节奏 | 产出 | 标称用时 |
|---|---|---|---|---|
| 2.1.1 | 填本店独有的信息 地址、店长电话、本店活动、交期、样板间；全国一套的口径不填 | 一次性 | 机器人介绍本店时用的信息 | 10 分钟 |
| 2.1.2 | 上传并检查 10 段金牌销售案例 只收「到店成交」的对话，逐句确认隐私与可借鉴 | 一次性 | 逐句核对过的案例 | 40 分钟 |
| 2.1.3 | 像带新人一样给机器人回答打分 听懂 / 答对 / 没乱承诺 / 有推进，四项各 1–5 分 | 一次性 | 逐组回答判断 | 30–60 分钟 |
| 2.1.4 | 确认机器人怎么说、哪些话不能说 | 一次性 | 机器人说话规则 | 10 分钟 |
| 2.2.1 | 设置机器人可以自动办理的服务 先试运行再放开 | 自动能力 | 经过试运行的自动接待服务 | 12 分钟 |
| 2.3.1 | 看今天微信接待效果 | 每天 | 今天的结果 + 待检查聊天入口 | 5 分钟 |
| 2.3.2 | 聚合聊天（店里所有销售） | 每天 | 聊天检查结果、真人跟进任务 | 15 分钟 |
| 2.3.3 | 修改客户常问问题的答案 | 每天 | 可直接用于回复的标准答案 | 15 分钟 |
| 2.3.4 | 看机器人的演练对话 | 每天 | 机器人在难问题上的表现 | 10 分钟 |
| 2.3.5 | 企业微信会话（旧通道） | 每天 | 旧通道会话原文 | 按需 |
| 层 | 这一层回答什么 | 落在哪张表 | 今天有多少 |
|---|---|---|---|
| ① 料 | 机器人说的话有没有依据 | sw_facts · sw_documents · sw_chat_examples | 事实 155 条（在用 131 / 已过期 23 / 被替换 1）；金牌案例 1 段 |
| ② 规矩 | 怎么说、什么不能说、能替人办哪些事 | sw_bot_rules · sw_plugins · sw_rubric_items | 说话规则 11 条；服务插件 8 个（在跑 3 / 暂停 3 / 草稿 2）；打分条目 97 条 |
| ③ 每天跑 | 昨天答得怎么样、哪几条要人接手 | sw_conversations · sw_faqs · sw_eval_fixtures | 会话 110 段；标准答案 8 条；演练题 66 道 |
其余九屏都是配置——填资料、写规则、开插件，改的是机器人的输入。
只有打分屏收的是「这句该怎么说才对」（corrected_answer），
它是把店长的判断变成训练信号的唯一入口。
所以这一屏的完成率不是一个进度条，是整个模块能不能变好的上限。
| 卡点 | 实测 | 为什么卡住 | 置信度 |
|---|---|---|---|
| 打分屏几乎没人做 | 已打分 2 / 97 | 标称「30–60 分钟」，实际是一次性摆 97 条在店长面前。他做完两条就走了——这不是懒，是任务被设计成一场考试，而不是每天几分钟的事 | 0.9 |
| 金牌案例只有 1 段 | 1 / 目标 10 | 传一段要「贴记录 → 选结果 → 核对遮敏 → 逐句标可不可借鉴」四步。门槛在核对，不在上传 | 0.85 |
| 会话检查基本没发生 | 未检查 107 / 110 | 系统已经分好档了（clean 71 / watch 30 / maybe_wrong 7 / high_intent 2），但界面仍要人从 110 条里自己翻——真正该看的只有 9 条（maybe_wrong + high_intent） | 0.85 |
| 23 条事实已经过期 | expired 23 / 155 | 有 valid_until 但没有到期提醒。过期事实照样在库里，界面上不刺眼 |
0.7 |
三层的切法本身是对的：料 / 规矩 / 每天跑各自有表、互不混用，加一条规则不会污染事实库。 会话自动分档已经在跑（110 段全部有 triage 值，不是空的）——上面第三条卡的是界面没用它，不是分档没做。 插件的三态是真的（active 3 / paused 3 / draft 2），不是摆设。 演练题 66 道已入库，2.3.4 那屏有真东西可看。
用时是工程实现的估计（一人，含自测），不含甲方评审与真机验证。 每条标了置信度：低于 0.6 的不算结论，只算方向。
| # | 做什么 | 为什么是它 | 预估 | 置信度 |
|---|---|---|---|---|
| P1 | 打分屏从「97 条一次做完」改成「每天 5 条」 按分歧度排序先推最值钱的那几条；做完 5 条就收工，不显示总进度条 |
它是唯一的回写通道，2/97 等于这个模块现在学不到任何东西 | 2–3 天 | 0.8 |
| P2 | 聚合聊天默认只显示该看的那几条 进屏就是 maybe_wrong + high_intent（今天 9 条），其余折起来 |
分档已经算好了，只差界面用它——这是投入产出比最高的一条 | 1 天 | 0.85 |
| P3 | 金牌案例降摩擦 遮敏结果默认折叠只提示「已遮 N 处」；销售回复默认可借鉴，只让他标不妥的那几句 |
1/10 的原因在核对环节，不在上传环节 | 2 天 | 0.7 |
| P4 | 事实到期提醒 过期的在「本店信息」屏顶部结集，一句「23 条过期了，还算数吗」 |
valid_until 已经在写，只是没人看 |
0.5 天 | 0.8 |
| P5 | 暂停的插件要写明为什么暂停 3 个 paused 现在跟 draft 长得一样 |
店长分不清「还没配好」和「配好了被关掉」 | 0.5 天 | 0.65 |
| P6 | 把大脑那 557 条候选接到这里 采纳后自动成为 2.3.3 的标准答案候选 |
这一页 §02 的断链，出口就在微信接待 | 不估阻塞 | 0.5 |
上面 10 屏是店长侧的界面（Akke-AI/store-workbench）。
真正读消息、生成回复、按住风控闸的执行侧在 Akke-AI/wecom-chat 加云电脑 GUI 自动化，
是另一条链路。「机器人答得好不好」这件事，这一页只能从店长这一侧的数据推——
端到端的回复率、时效、送达，要看 /akke/wecom-autoreply-journey 那张实时页。
P6 的用时不估，也是同样的原因：它跨两个仓，工期取决于对面仓的排期， 在这里给一个数字就是编的。