1. 16 Aug, 2026 31 commits
    • fix(助手留痕): 补上会话 id,并把多步文本拼全 —— 两处都是「看起来对、其实会丢」 · df0d263d
      ■ 会话 id(`workflowRunId`)
        上一版每轮各生成一个 run id,判断"哪几轮是一批"只能靠 `turnNo` 归 1 反推 ——
        那是启发式,️ 两位主管并发聊天时行是交错的,前端一旦裁剪历史 turnNo 还会错位。
        ⇒ 前端在**messages 为空**(= 一段新对话的第一句)时现生成 uuid,此后每轮原样带上;
          服务端落进 `workflow_run_id`,同一次对话各轮共用一个值。
        ️ 前端可改的入参:只用于归组, 不参与鉴权取数;非 uuid 一律丢弃(服务端另生成),
           别让它成为写库的注入面(该列是 uuid 类型)。
         这也正好落在产品设计上:没有"新建会话",会话跟着他此刻在做的那件事走 ——
          离开工作台、组件重挂,messages 归空,下一句就是新的一段。
      
      ■ outputText 只落了最后一步
        🔴 AI SDK 的 `OnFinishEvent` 继承的是**最后一步**的 `StepResult`,`ev.text` 只有末步那段。
        模型在工具之间穿插说的话(「我先查一下」)全在前面的步里,只取 ev.text 就永远不进记录 ——
        而排查"它当时到底说了什么"全靠这一列。
        ️ 线上实测那轮 5 次工具调用、6924 输出 token,落库只有 60 字 —— 那次凑巧没丢
          (它把话都留到了最后一步), 别指望每次都这样。
        ⇒ `joinStepTexts` 拼所有步,去重末步(它通常已在 steps 末项里)。
      
      验证:
        · tsc(service + web)通过;jest 85 套 1330 例全过(新增 5);eslint 干净
        · 真模型跑三轮:会话A 两轮共用 run=1cd20f63、会话B 独立 run=985bf1d3,
          按 run 分组正好 2 个会话 
      
      ️ 未做,留给产品定:界面 63 处写「时效」、0 处「时限」,而文档已改口径为「时限」。
        提示词的铁律是「使用者的词汇表 = 他在界面上见过的那些」⇒ 现在**该改的是文档或界面**,
         不能只把提示词单方面改成「时限」。
      luoqi committed
    • merge: 分配助手文档重排 + 助手调用留痕(agent_invocations) · fe79f0f3
      文档 25 个提交:《分配助手》按产品口径全面重排(决策树前置、意图分析、
      去内部黑话、编号撞车修正、代价三档)。
      功能 1 个提交:助手每轮往 agent_invocations 落一行(只存当轮, 不存上下文),
      外加保留期清理任务与成本计算共享化。
      luoqi committed
    • feat(助手): 每轮往 agent_invocations 落一行 —— 落「该调的工具调没调」,不落聊天记录 · ad264616
      助手是这条生产线上唯一**一次都没留过痕**的一层:验收判据写着「该调的工具
      调没调」,而线上没有任何地方记录模型实际调了什么,只能靠临时跑批。
      
      表和写入器都是现成的(`agent_invocations` + `InvocationRecorderService`),
      后台 `admin/ai-invocations` 也不写死 kind —— 落进去直接就能看。缺的只是接上。
      
      ■ 只存当轮, 不存上下文
        助手的 messages 里带着 propose_assignment 返回的整张确认单(几百人 ×
        十几个字段)。第 N 轮把前 N-1 轮全带上 ⇒ **落库量按平方涨**。
        实测口径:全量约 100 KB/行,只存当轮约 2.5 KB/行;按 1800 次/天算是
        65 GB/年 vs 1.6 GB/年 —— ️ 而测试机盘常年 90%+、PG 卷已占 75 G。
        ⇒ `slimInputSnapshot` 只取本轮用户原话 + 轮次 + 现场 id,
           不含历史、 不含任何工具返回值。同 agent-architecture「摘要 + 指针」:
          在源头就只给摘要, 不事后压缩(事后压缩要改历史,而改历史作废 KV 缓存)。
      
      ■ systemPrompt 一律不落
        主管那份 6.9 KB **每次一模一样**,逐行存等于把同一份东西抄一万遍。
        改用 `ASSISTANT_PROMPT_VERSION` 做锚 —— 🔴 改任意一层正文必须 bump,
        ️ 不 bump 这条审计链就断,而断了不会有任何报错。
      
      ■ 工具留痕装在一处
        在 tools 建好之后统一给**每个** execute 套计时包装(MCP 拉来的 + 本地那 7 个)。
         不在各自 execute 里写:漏一个,那个工具就永远不出现在验收数据里。
        落 output.toolCalls = [{name, ok, ms, args截200}], 不落工具返回值。
      
      ■ 落库绝不影响对话
        start/end 全程 try/catch 吞掉,只打日志;onFinish/onError 挂在 streamText 上。
        主管正等着一版方案, 不该因为审计写不进去而看不到结果。
        scope 缺失(内部入口)整条跳过 —— hostId/tenantId 是必填列。
      
      ■ 顺带补两个既有缺口
        1. 保留期清理任务(`InvocationRetentionService`,每天 04:00 沪)——
           schema 注释里写了一年「N 天后清 inputSnapshot 仅保留元数据」,任务一直不存在。
           清 inputSnapshot/prompt/systemPrompt/outputText 四样肥字段(占一行 95%+ 字节),
           留 token/成本/延迟/status/judge/userFeedback;失败行留 3 倍时长;
            不删行(成本与通过率曲线要长期可比,元数据行才 ~1 KB)。
           ️ 判据用 startedAt 不用 updatedAt —— 清理本身会刷新 updatedAt,
             用它当闸门的话清过的行永远追不上,每天全表重清一遍。
        2. 成本计算抽成共享纯函数 `ai/core/cost.ts` —— 它是**计价**逻辑,
           抄第二份必然漂(2026-08-13 栽过:换 qwen 旗舰后成本被低报约四倍)。
      
      本地验证(不只是单测):
        · tsc 通过;jest 85 套 1325 例全过(新增 27 例);eslint 干净
        · 真 AppModule 起容器 → recorder 注入成功、retention 服务已注册
        · 保留期在真库上跑通:60 天前成功行已清且元数据完好、2 天前未动、
          失败行未动、第二次跑幂等、185 行真实数据零误伤
        · **真模型跑通一轮**(deepseek-v4-flash):
          tokens 1720/158/1878 · cached 896 · ¥0.001169 · latency 23.9s ·
          finishReason "stop" · inputSnapshot 82 B( 无历史)· systemPrompt 未落
          ️ 先用 MockLanguageModelV3 试过,usage 拿不到 —— 是 mock 喂不进去,
            不是代码问题;真模型一次跑通。
      
      ️ 遗留:代码里 ASSIGNMENT_SCENE 仍写「时效」,产品口径已改「时限」,未统一。
      luoqi committed
    • docs(站点): 只删与图重复的,提示词和工具原样保留 —— 470 → 415 行 · edbbe4f5
      上一版(已回退)把 §2 提示词、§3 工具整节删掉了,那是砍错地方:
      产品要的是「能在图里说明的就不另开篇幅」,不是删掉这两节。
      
      删的全是与决策树图重复的表:
      - 《选人 = 主管初选 + 助手精选》整表 —— 图上 A1/A2 就是这个结构,
        只留下面那段「助手不等指令、先把方案做出来」
      - 《引导什么时候才冒出来》的「满足什么才出」列 —— 触发条件写在 G1/G2 节点上,
        表只留「为什么卡那个条件」(这一列图里没有)
      - 分人三趟表 —— 图上 B 节点已逐趟写清,只留水位公式和三条「为什么」
      - 「人手在两个地方摆给他看」两行表 → 一句话
      - 《③ 确认 · ④ 确认之后》表 → 两句话
      - §5「另有几位」的两局面表 → 一句话(该做的事正好相反)
      
      合并:
      - 《代价不对称》整节上提到图下 —— 它是读图的钥匙,本来就该紧跟着图,
        放章末等于让人看完全章再回头理解开头那两个环
      
      §2 §3 内容一句没删,只压掉工程细节的铺陈:
      - 四条硬规则的分条罗列 → 一行(判据那句引言保留,它才是要点)
      - 《只有主职责常驻》两段并一段
      
      八节结构不变。验证:pnpm --filter pac-docs build 通过。
      luoqi committed
    • docs(站点): 分配助手按「拿去讲」的标准全面校订 —— 修编号撞车、去内部黑话、拆代价三档 · af291464
      拿这份去做产品介绍前的一次完整审校,改动分三类:
      
      一、会当场被问住的(3 处)
      - 编号撞车:①②③④ 同时指四步、四个引导节点、五层提示词。
        原第 71 行「从②『这批多大』改」,而 ② 在同一页刚被定义成「分人」。
        ⇒ 圈码只留给四步;引导节点本来就有名字,一律改用「名字」引用。
      - 「格」仍在用且从未定义:产品早已定过不用这个说法。
        ⇒ 全部改为「候选人群 / 这批候选」,并在四问表之后补一句它是什么
          (治疗 × 多久没来 交叉出来的那批人)—— 后面所有平均、门槛都以它为准。
      - 代价表自相矛盾:表称「分人环 = 就地改」,下一句就承认「换无专属的补上」
        走重排。实际是三档(就地改 / 重排 / 重出),只写了两档。
        ⇒ 新表按三档写,并点明中间那档是唯一「长在分人环、代价却偏向选人环」的。
      
      二、结构与重复
      - §1 原「三处例外」摆在《召回策略》之前,却引用尚未定义的引导节点 ⇒ 下沉。
      - 原「两条闭合的环」与开篇「两个环的代价不一样」讲同一件事 ⇒ 合并,
        与「红色菱形」一起收成《代价不对称:什么时候重来,什么时候就地改》。
      - 原「后三步」里 ② 分人是上一节的重复 ⇒ 删节,唯一新信息(主管可微调)
        并入分人那节;该节改名《③ 确认 · ④ 确认之后》。
      - §2 原名「提示词怎么搭的」盖住了它更重要的第一节(登录时装配、无对象实例)
        ⇒ 改名《这个助手是怎么装出来的》,下分「装配」「提示词分层」。
      
      三、文风与用词(要拿出去讲)
      - 术语统一:「自由患者」⇒「无专属患者」(全文其余处一直用后者)。
      - 去口语/网络语:层层套娃、甩锅、白付上下文、旋钮、拖一下、桶名、一刀切光。
      - 去代码术语:「按客服 id 打破平局」⇒「按固定顺序打破平局」。
      - 代词歧义:开篇「助手…出确认单。他只要看一眼」的「他」紧跟「助手」;
        §5 标题「要他定的事」无先行词;§8 结句「他在做的那件事就是它存在的理由」。
      - 引号统一为「」;mermaid 标签内的半角标点改全角(已在浏览器验证可渲染)。
      -  由 40+ 降到 26 —— 只留红线表与真禁令,句中当「不」用的去掉。
      
      事实层复核(未改动,均与代码一致):
        DAILY_CALLS_PER_AGENT=15、NARROW.MIN_COHORT=50 / MIN_COUNT=10、
        工具 9 通用(MCP 8 + render_artifact)/ 12 主管(MCP 6 + 助手侧 6)= 21。
      
      验证:pnpm --filter pac-docs build 通过;本地 3102 实测两张 mermaid
      均渲染(680×1582、680×158),零 syntax error。
      luoqi committed
    • docs(站点): 新增 §8「跟一般的助手不一样在哪」—— 八条产品选择,不是技术选择 · 64f7f351
      产品提到「没有新建会话功能」这条设计考量,并让我补齐能想到的。核过代码确认:
      `messages` 就是组件状态、助手挂在 plans/layout 上、全仓找不到任何
      新建会话/清空/历史列表的代码 —— **它确实不是一个聊天产品**。
      
      八条(每条都配"如果按常规做会怎样"):
        · 会话:没有新建、没有历史 —— 让他管理"会话"等于给他一件本来不存在的活
        · 搞不清时:**不追问,直接出一版** —— 追问一轮=他等一轮,
          而**一版具体的方案本身就是最好的问题**
        · 让他选择:摆成按钮,且按钮和说话走同一套动作 —— 打字要过"理解→翻成动作"
        · 输出:**模型自己排版**,卡片落在正文哪一句之后由它调工具的位置决定
        · 与界面的关系:界面显示过的不再说 —— 读两遍他就开始跳读
        · 数字:一个都不许自己产生
        · 兜底:**默认永远安全** —— 一条不点直接确认,任何情况下都不出事
        · 验收:看多轮通过率, 不是"跑通一次"
      
      🔴 收在一句上:**助手是工作台的一部分,不是工作台旁边的一个聊天机器人。**
        它没有自己的"产品面"—— 没有会话管理、没有历史、没有设置。
        他在做的那件事就是它存在的全部理由。
      
      Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
      luoqi committed
    • docs(站点): 装配那节按 agent-architecture §六 的深度重写 —— 补上判据,不只描述现象 · bfd92b98
      产品指出我写的不如 `docs/design/agent-architecture.md` §六。对比之后确实:
      我只写了「按权限装出角色/现场/工具」这个**现象**,而那份写的是**判据** ——
      为什么必须这么装、不这么装会怎样。照它的骨架重写。
      
      补进来的四块:
        · **哪几维必须按身份分**:会话、工具清单(看不见比看见被拒更安全)、数据范围
          (下推到查询条件, 不是查全量再过滤)必须分;系统提示词分**但这是最不重要的一条**;
          模型和代码实现不用分
        · **为什么同一会话不能切换身份**:上下文是**单向**的,高权限会话里已载入的数据
          不会因为一句「你现在是低权限角色」而消失 ——
          **提示词不是删除操作,也从来不是安全边界**
        · **「两个 agent」要拆开**:同一套实现按身份参数化; 这不是「多 agent 编排」——
          编排指 agent 互相调用,而不同身份之间不需要通信,真要协作走业务对象
        · **四条硬规则**(身份随调用传递 / 授权在工具内部 / 数据范围下推 / 工具清单按身份下发),
          连同那条判据:**如果模型不传某个参数,越权就不可能发生 —— 那这个参数就不该是参数**
      
      ️ 保留我原来那个推论(它没有"记性" ⇒ 动过手之后必须重新看那张单),
        那条在原文里没有,而它正好解释了「看当前确认单」为什么存在。
      
      Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
      luoqi committed
    • docs(站点): 补上「助手是登录之后现装出来的」—— 它是理解整个 §2 的前提 · b2de3308
      产品指出文档没讲 agent 是怎么形成的。代码里 `buildSystemPrompt` 就是一个纯函数:
        权限位 → ④角色 / ⑤现场 / 工具清单,①②③ 与谁登录无关
        return [IDENTITY, EVIDENCE, voice, role, scene].join('\n\n')
      **没有 agent 对象、没有实例、没有状态** —— 每次请求现拼一份字符串,工具也按权限现注册。
      
      ⇒ 补一节讲清三个后果:
        · 换个账号登录**它就是另一个助手**, 不是"同一个助手换了套权限"
        · **不登录就是一块白板**(现在没这种场景,但结构上就是如此)
        · 加一条新业务线 = 多一个 ⑤,前四层一个字不动
      
      ️ 并点出一个平时容易忘的推论:**它没有"记性"** —— 不是存着状态的对象,
        所以主管在确认单上动过手之后,助手**必须重新去看那张单**,
         不能拿出方案那一版的数接着算(这正是「看当前确认单」那个工具存在的理由)。
      
      顺带删掉原来那条「一个开关驱动三样东西」的 Callout —— 新那节已经把它讲全了。
      
      Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
      luoqi committed
    • docs(站点): 把方法论和清单分开 —— 三问是「描述怎么写」,清单只做摘要 · d8b15e3c
      上一版我把方法论塞进了清单里(每个工具都写满三问),产品指出搞反了。
      
      **方法论**(描述该怎么写)—— 一条工具描述要答三件事:
        · **干什么**:一句话说清它回答哪个问题
        · **什么时候用、 什么时候别用**
        · **怎么用**:参数怎么填、跟哪个工具配套
        🔴 点明「什么时候别用」是最值钱的那条:**一个工具能干什么,看名字就猜得到;
          什么时候不该用,只能踩出来** —— 几乎每条背后都有一次实测事故。
        ️ 两条硬边界(都踩过):
          · 返回值只给事实、 不给成品句子 —— 某个返回值混了给模型的指令,
            模型照抄,内部指令原样贴进主管的对话框。护栏写成规范, 不写成台词。
          · 描述里 不留**正面举例** —— 写了「他会说『只要商保直付的』」,
            模型把这个例子逐字念给主管,而那版数据里根本没这一类。反例可留,正例不留。
      
      **清单**:21 个工具各一句话, 不再重复三问。
      
      MDX 编译通过。
      
      Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
      luoqi committed
    • docs(站点): 工具清单改成「干什么 / 什么时候用 / 什么时候别用」,不再只是目录 · 766a6075
      产品指出上一版是**目录不是解释**。⇒ 21 个工具逐条重写,每条三件事,
      内容全部从**真实工具描述**里提炼(不是我另编一套)。
      
      几条值得单独看的「别用」——它们背后都有实测事故:
        · 我是谁 ——「我能不能做某件事」 不用问它:做得了的事工具就在手上,
          做不了的那个工具压根不会出现
        · 看人手 ——  出方案**不需要**先调它(方案自己会取名册);
          曾抓到模型写字前白调一次、返回的数一个没用
        · 看当前确认单 —— 他在卡片上动过手之后**必须先调它再报数**:
          卡片改动助手看不见, 拿旧版的数去算就是错的
        · 摆确认单 ——  算出来了也别急着调:先讲怎么排的,明细是给他核对那几句用的
        · 摆引导 ——  别攒着一起调,前一类的按钮会落到后一类的说明后面
        · 撤销 —— ️ 唯一会改数据的工具,**试探性调一次没有"预览",那一次就是真撤**
        · 召回池名单/概览 —— 没有看全池权限的人拿到的只是自己名下那些, 别说成"整个池子"
      
      ️ 末尾点明:这些「别用」几乎每条背后都有一次实测事故 —— 它们是这套工具
        最值钱的部分, 不是凑数的注意事项。
      
      MDX 编译通过。
      
      Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
      luoqi committed
    • docs(站点): 工具那节前移到提示词之后,补设计思路 + 21 个工具逐条列出 · 8bf1fe0f
      按产品要求:位置移到 §3(提示词之后),补上**工具设计的思路**,并把工具**全部列出来**。
      
      **设计思路(从代码里的判定提炼,不是新造):**
        🔴 **能靠结构解决的, 不靠叮嘱。** 模型会说出 `cold_3y` `implant` 这类内部码,
          主管看到不认识的词第一反应是系统坏了。最初在提示词里写两页「 不许说码」——
          **拦不住**,因为它调工具时必须拿码当参数,回话自然带出来。
          真解法是**返回值里就给中文** ⇒ 它手里有话可说,就不会去说码。
          「能让它说不出来的,就别写成不许说」——提示词里的禁令只拦得住预想到的那些。
      
      **工具描述怎么写(四问,例子全取自真实描述):**
        它答什么问题 / ️ 哪里容易误读 /  什么时候不该用它 / 配套的那个工具是谁
        两条硬边界:返回值**只给事实不给成品句子**(否则模型照抄,内部指令原样贴进主管对话框 ——
        踩过);中文标签只有一处真源, 不在工具层另立一套。
      
      **全部工具**:两种人都有 9 个、只有主管 12 个,逐条一句话说清干什么。
      ️ 数字是从代码数出来的,不是抄旧文:MCP 通用 8 + render_artifact = 客服 9;
        MCP 全部 14 + 本地 7 = 主管 21。与文档原有的 21/9 一致。
      
      后续章节顺延(三者分工→四 / 引导→五)。MDX 编译通过。
      
      Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
      luoqi committed
    • docs(站点): 加载机制那段砍到一句话 —— 产品层面只有「主职责常驻,其余留一行索引」 · 44d4cfc6
      产品判断:三种加载方式属于实现细节,文档里说清"要不要在常驻里留索引"就够了。
      ⇒ 表格和「为什么必须分开」整段删掉,留三句:
        · 常驻的成本是**所有业务线常驻之后的总和**,而规则越多每条被遵守的概率越低
        · 所以只有主职责常驻;次要的活写成单独一篇,常驻里只留一行索引
        · 实测:问"前面那两批怎么样了",模型第一步就自己去取了做法
      
      ️ 自查:上一版我把 `_guide` / `open_playbook` 的机制差异写了满满一节 ——
        那是**实现**,不是产品设计。读者要知道的是"次要业务线不常驻",
         不是"它用哪种方式送到模型手上"。
      
      Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
      luoqi committed
    • docs(站点): 去掉 push/pull 这两个词,改用「什么时候用得上」讲清楚 · 528c4c72
      产品读不懂 push / pull —— 那说明这段没写好。那两个词是我从实现里搬来的
      (`_guide` 挂返回值 / `open_playbook` 让模型自己取),**不是产品语言**。
      
      差别其实只有一条:**这段知识是「看到数据之后」才用得上,还是「决定动手之前」就得有。**
        · 看到数据之后才用得上 → **跟着那份数据一起送**(查完批次详情,返回值里就带着读法:
          处理率≠成功率、退回率要给两个分母、样本不足 50 不给百分比)
        · 决定动手之前就得有 → **让它自己去取**(「分配追踪这活怎么干」——
          它得先知道查什么、按什么顺序查,才谈得上动手)
      
      为什么必须分开也写了:跟着数据走那种最便宜(不用主动要、必然看到、用不到零成本),
      但**只能在调完之后到达** ⇒ 凡是「要不要调、按什么顺序调」的知识跟着数据走就永远晚一步。
      这个边界在 `guides.ts` 里本来就写着,只是文档没讲出来。
      
      Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
      luoqi committed
    • docs(站点): 提示词那节按 artifact 重写并前移到决策树之后;按当前代码对齐 · ab00afda
      素材来自 artifact《主管侧助手系统提示词 · 分层校对》(2026-08-15,那份正文是跑
      `buildSystemPrompt()` 拼出来的真件)。产品要求:放决策树后面、去掉多余描述,
      **只留设计思路 + 分层**。
      
      留下的:
        · 分层判据 =「什么会让它变」,装配顺序 = 通用 → 特殊(就是模型的阅读顺序)
        · 五层表(装置 / 诚实 / 人设语气 / 角色 / 现场)+ 各自的变更原因与篇幅占比
        · **一个开关驱动三样东西**(④角色、⑤现场、工具清单)—— 换账号三样一起换,
           不会出现「给了主管的话术却没给主管的工具」
        · 三种加载方式(常驻 / push / pull)+ 为什么只有主职责常驻:
          常驻的成本是**每条业务线都常驻之后的总和**,而规则越多每条被遵守的概率越低
      去掉的:提示词全文、字数明细、待办清单 —— 那些属于校对稿,不属于产品设计文档。
      
      ️ **按当前代码重新对齐**(artifact 是昨天的快照,这两天改过):
        · 篇幅占比用今天的常量重算(9/20/32/7/32), 没照抄昨天那份
        · 「当前登录人」那行昨天已删,artifact 与代码一致,不再提
        · artifact 里的「无主」现在是「无专属」(见前一提交),文档统一用后者
      
      后续章节顺延重编号(三者分工→三 / 引导→四 / 工具→五)。MDX 编译通过。
      
      Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
      luoqi committed
    • docs(站点): ④ 同步「另有 N 位」,并写下「只给一个带数的选项」的理由 · 67947be0
      f8fd1ee5 的代码改动对齐:
        · 图里 ④ 补「报最忙那位 + 另有几位也超」
        · 表里补上那半句实际文案
        · 说明为什么要报这个数:只说最忙一个,主管分不出「只有他超」和「全队都超」——
          而这两种局面该做的事相反(前者给他少分点/改派,后者减量/延时效)
      
      ️ 顺带把**只给一个选项、且必须带数**这条纪律写进文档(产品这次再次确认):
        「整批时效改成 3 天」那个 3 是按最忙那位的量算出来的。
        曾经还有「改每人每天打几通」「减少本批人数」两个,删掉了 —— 它们一个数都不带,
        点下去等于替主管说了句「减少一些」。**一个不带数的按钮,严格弱于他自己开口说一句。**
      
      MDX 编译通过;mermaid 无悬空。
      
      Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
      luoqi committed
    • feat(引导): 「最忙的那位」补上「另有 N 位也超时效」;修一处注释与 SQL 打架 · f8fd1ee5
      **① 只报最忙一位,分不出两种相反的局面**(产品定):
        · 只有他一个人超 → 该给他少分点 / 改派几个
        · 全队都超       → 该减少这批 / 延长时效
        同一句话、相反的处置 —— 而本节点唯一的选项是「整批时效改成 N 天」,
        碰上第一种局面它本身就是错的(为一个人的负载去延长整批时效)。
      ⇒ why 里补「另有 N 位也超过 X 天;每位分完之后要打几天,确认单上逐位都写着」。
      ️ 只加一个数 + 一句引路, 不在引导里铺开每个人:确认单每行已经有「约 N 天」,
        分布本来就在眼皮底下(引导节点的职责是点出要他定的事,不是展示数据)。
      ️ 只有一个人超时那半句**不出现** ——  不制造无谓噪音。
      📌 加在**工具产出的数据**里(`daily_overload` 的 why), 没动提示词 ——
        模型从返回值里直接读,不需要被提醒(工具返回值 > 提示词)。
      
      **② 团队面板那段注释与 SQL 打架**:注释把「超期」和「在手」并列写成"与窗口无关",
        而 SQL 里是 `assignment_expires_at >= since` —— **SQL 是对的**:
        一年前过期的单报上来对主管没意义,他此刻能处置的只有近期这批。
        ⇒ 改注释、 别照注释去掉 SQL 的窗口,并把理由写在旁边。
      
      新增 2 条测试(多人超时 → 报数并引到确认单;只有一人超 → 那半句不出现),1298 全绿。
      
      Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
      luoqi committed
    • docs(站点): 补上「专属排满了」漏掉的第四个选项,并接回第三趟 · dac5e781
      产品指出图里那条引导缺一项。核了代码,`pending` 节点其实有**四个**选项,
      我只列了三个 —— 漏的正是代价不同的那一个:
      
        · 换无专属客服的患者补上   ← 漏了。️ `canRefill` 为真(池子里还有无专属的人)时才给,
                                      而且它换的是人 → 走 refill 重排, 不是就地改
        · 铺平给在岗 / 各自归专属客服 / 移出本批
      
      顺带把这条引导和落人第三趟接起来:**待分配那一组就是第三趟排不进去的人** ——
      原文两处各说各的,读者看不出是同一批人。
      
      Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
      luoqi committed
    • docs(站点): 分人写清楚 —— 目标水位 + 三趟,不是"谁空给谁" · 0f91e390
      产品指出图上那三行没说清分法。去 `placeAgents` 核了算法,原文漏掉的正是**最关键的水位**:
      
        目标水位 = ⌈(团队现有在手总量 + 本批人数) ÷ 在岗人数⌉,至少 1
      
       它**不是新旋钮**,完全由「这批多大」推出来;存在的唯一理由是**给第一趟封顶**。
      
      三趟(顺序本身就是设计):
        一趟 有专属的回自己人 —— 但到水位就不再给
        二趟 无专属的补给当前手上最少的(这一趟才是"最少优先")
        三趟 专属这轮排满的单列成一组, 不自动改派
      
      三条理由都写进去了,都是代码注释里记着的实测/判定:
        · **为什么必须三趟**:二、三趟都是水位法、总量一样,但**拆散的专属关系数不一样** ——
          先用无专属的补空手的人能少动一个有主患者;合成一趟就会随机改派。
        · **为什么第一趟封顶**:本地实测池子 1,081 人里 755 人(70%)挂同一个客服,
          不封顶他一批拿 248 条,而 17 位在岗里 10 位名下一个患者都没有。
        · **为什么第三趟不自动改派**:把患者从专属客服手里挪走是**关系层面的决定,
          助手没资格替主管做**;这些人不是被丢掉,是原地不动交他定。
        ️ 另补:同水位按客服 id 打破平局 —— 同样输入两次必须算出同样的分法,
          这是主管敢按确认键的前提。
      
      MDX 编译通过;mermaid 无悬空引用。
      
      Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
      luoqi committed
    • fix(站点): 多段 Callout 的开闭标签要各自独占一行,否则 MDX 编译失败 · 943336ff
      Build Error: `Expected a closing tag for <Callout> before the end of paragraph`。
      
      原因:写成 `<Callout type="info">正文…` 再跟空行时,MDX 把它当成**段落内的行内 JSX**,
      要求在同一段里闭合;而中间的空行已经结束了那个 paragraph ⇒ 报"缺闭合标签"。
      ️ 同文件另外两个 Callout **没**报错 —— 它们内部是软换行、没有空行,属于同一段,合法。
         所以这个坑只在"想写多段落 Callout"时才踩到。
      
      ⇒ 改成开闭标签各自独占一行、与正文之间留空行,并在文件里就地留一段注释说明。
      
      验证:用工作区的 @mdx-js/mdx 直接编译,本文件通过;顺手把 content/docs 下
      全部 36 个 mdx 都编了一遍,无一失败。
      
      Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
      luoqi committed
    • fix(引导)+docs: 撤掉「候选够不着 N 就不出这批多大」那道闸;四问补上深层理由 · 939a2fb8
      **① 代码:那道闸的理由只成立一半**(产品指出)。
        原判据 `candidateTotal > batchSize`,注释理由是「候选 312 / N 495 时往上调 target 还是 312,
        点了没反应,而 why 说人数会变 ⇒ 说谎」。️ **那只考虑了往上调** —— 主管同样可以往下调:
        把每天几通 15→5,N=165 < 312 ⇒ target 真的变成 165。他想少发一些,而这道闸把入口藏了。
        ⇒ 闸撤掉,改成**据实说明**:候选够不着 N 时 why 直接讲清方向
          「符合条件的只有 N 人,已经全在本批里了 —— 往上调不会更多,往下调可以少发一些」。
         别再拿"点了没反应"当不出的理由 —— 该修的是那句话,不是把节点藏起来。
        两条测试跟着反转:原来锁"不出",现在锁"两种局面都出且措辞据实";1296 全绿。
      
      **② 文档:四问补上深层理由**(产品指出"分析过的没写上,缺说服力")。
        1 治疗 —— 诊所这季度的经营重点,医生排期/设备耗材/话术都围着它转,**只有他知道**,
          系统里没有任何数据能推出来
        2 多久没来 —— **他能估出回来多少**,而这个估算往下游一步就是诊所排班:
          要不要给医生和科室提前留位。**捞回来了却没人接诊,比没捞更伤客户** ⇒ 必须他拍
        3 高价值 —— **他答不了**:不看数据不知道这批里有多少高价值,也不知道切完还剩几个
          (可能一刀下去只剩三个人)
        4 团队负载 —— 捞太多打不完、到期回池等于白发一轮;而"还吃得下多少"的数在系统里,
          不在他脑子里
        ⇒ 「1、2 问他就有;3、4 问他他也说不出」—— 选人要拆两半的理由,到这里才立得住。
      
      Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
      luoqi committed
    • docs(站点): 决策树的两个环只画引导节点,触发条件写进图里 · d253f173
      产品指出:边上那串「加条件 · 改这批多大 · 换治疗项 · 换多久没来」混了两类东西 ——
      **换治疗项 / 换多久没来 / 直接说改成 200 人是自由输入**,不走按钮、靠助手听懂 + 调工具,
       不该画在这张图上。图上只留**引导节点**,并把每条的触发条件写死。
      
      两个环现在各挂两个节点(全部去代码核过阈值):
        选人环(重出,几十秒)
          ① 能加个条件 —— 这一格 ≥50 人 · 他还没加过 · 切完还剩 ≥10 人
             消费高于本格平均 / 转介绍达人 / 权益身份 / 获客渠道
          ② 这批多大 —— 人数是系统估的 · 且候选 > 本批人数
             可改 **每人每天几通 · 时效几天**(此前图里完全没提这两个可调量)
        分人环(就地改,同步)
          ③ 专属排满了 —— 这一版真有人排不进去
          ④ 最忙的那位 —— 分完后的量 > 每天通数 × 时效
      
      🔴 顺带纠正两处我先前写错/漏写的:
        · **「改时效」有两条路,代价不一样**:从②改会连人数一起重估(重出);
          从④改只延长这一批的期限、人不变(就地改)。前端注释里 `basis.set` 走
          「让模型重出一版」而 `expiry.set` 是「局部改单、同步」,两者本就不同路。
        · **「换无专属客服的患者补上」挂在③下面,但它换的是人** —— 走 refill 重排(几秒),
          是四个节点里唯一"长在分人环、代价却在选人环"的选项。
      
      Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
      luoqi committed
    • docs(站点): 「加条件」如实写清四条 + 补上引导的出场规则 · 59ebef9c
      产品指出原边标签「换条件 · 改人数 · 换时间档」不如实。去代码核了一遍,三处要改:
      
      **① 是「加」不是「换」**,而且加完是**重新选一版**(assignment-signals 的 why 原话:
        「点哪一条都是重新选一版……不是在已经排好的那些人里再挑」)。按钮上那个数字是
        **换完之后这一格还剩多少**, 不是"从本批里筛掉几个"。
      
      **② 四条条件全列出来**(此前只写"换条件"三个字):
        · 只选消费高于**这一格自己的平均**的 ——  不是全库分位(全库 ¥4,442,某格实测 ¥0 起,
          用全库的数会一刀切光)
        · 只选转介绍达人 —— 推荐 ≥3 人且带来成交,家庭型/社交型合并成一条
        · 只选某个权益身份的 —— 取这一格里人最多的那一项
        · 只选某个获客渠道的 —— 同上
        + 兜底「按别的条件选」:助手把其余十几个维度各多少人报一遍,他再挑
      
      **③ 补上引导的出场规则**(整篇此前一个字都没有):
        · 专属排满了  —— 真有人排不进去才出(唯一"不处理就真漏人"的一条)
        · 能加个条件  —— 这一格 ≥50 人 · 他还没加过条件 · 切完至少还剩 10 人
        · 这批多大    —— 人数是系统估的 **且候选 > 这批人数**
        · 最忙的那位  —— 最忙的人分完后的量 > 每天通数 × 时效
      🔴 「这批多大」那条的门槛值得单独写:候选够不着 N 时,改时效/改通数点了**不会有任何反应**,
        而它的说明写着「人数会跟着变」—— 那就成了说谎。所以候选 > N 才出。
      
      Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
      luoqi committed
    • docs(站点): 助手精选把默认值摆进图里;两个判断点改口语,去掉内部行话 · e57d5a2a
      **① 默认值要写出来(产品指出)**:原图只说助手"出一版",没讲**它是拿什么默认值出的**。
        主管其实只说了 1、2 两问,剩下的全是默认:
          · 谁排前面 —— 没联系过的排前面,其余按优先级从高到低
          · 每人每天 15 通 · 时效 1 天
          · 这批多大 = 在岗人数 × 15 × 时效
        ⇒ 图里补一段,正文补一张「默认的是什么 / 取值 / 他想改说一句就行」的表。
      🔴 配一条纪律:**默认值一个都不许藏**。一个他看不见的默认值,等于系统替他做了一个
        他不知道的决定 —— 而这批人是真发下去了。摆出来他才有得改; 不摆,他连
        "原来还能改这个"都不知道。(出方案时那个式子摊开写,就是这条的落地。)
      
      **② 去掉内部行话(产品指出)**:两个判断点原来写「待定的都摆成了按钮」——
        「待定」「摆成按钮」是我们内部说法。改成主管视角的话:
          「这批人对吗?要改哪一项,点一下就行」
          「这么分行吗?要调谁,点一下就行」
      
      Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
      luoqi committed
    • docs(站点)+fix(措辞): 选人/分人画成两个各自闭合的环;「无主」统一改成「无专属」 · da078f8c
      **① 决策树的缺陷(产品指出)**:原图把两个阶段的调整并成了**一个环** ——
      「选人 → 分人 → 统一问一次要不要改」。这抹掉了两件事:
        · 「选人定下来」这个关口不见了 —— 图上看不出"人先定,才轮到怎么分";
        · **两种调整的代价被画成一样的** —— 实际上改选人是**整版重出、连已经排好的
          分法一并作废**,改分人只在这一版上动、人不变。
      ⇒ 改成两个各自闭合的环,中间用粗箭头标出「人定了 —— 这一关过了才谈怎么分」,
        并配一张表把代价差写死。顺序不能颠倒:先排分法再让他改人群,那趟排班就白做了。
      
      **② 用词统一(产品指出)**:「无主」→「无专属」。
      ️ 界面上的按钮文案**本来就是**「换无专属客服的患者补上」,而这三处模型会照着念给
        主管听的文本还写着「无主」—— 两处不一致,他会以为是两拨人:
          · assignment-facts 的「落人规则」(modelFacts,模型常原样引用)
          · assistant-prompts / lab.controller 的落人规则那一句
          · assignment.controller 里「换无主患者补上」的工具描述
         纯措辞替换,不动语义。代码注释里的「无主」没动(内部行话,不进主管视野)。
      
      1296 个测试全绿;mermaid 节点引用与 style 目标均无悬空。
      
      Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
      luoqi committed
    • docs(站点): 「选人」拆成召回策略 → 主管初选 → 助手精选(产品定的叙述框架) · 0b0acba4
      产品指出:选人不是一次动作,要**从主管的运营意图出发**拆开讲 —— 而且叙述该
      「先列出要回答的问题,再说谁答、凭什么答」,这才是产品思维。按这个重写 §1。
      
      **召回策略(在选人之前的一环)= 一批召回要回答的四个问题**
        1 做哪一类还没启动的治疗   → 主管答,凭这季度的经营重点
        2 找多久没来的人           → 主管答,凭经验
        3 要不要只挑高价值的       → 主管定,但**助手先摆数据**
        4 团队还吃得下多少         → 主管定,但**助手先摆数据**
      
      ⇒ 1、2 是运营意图,他张口就来;**3、4 他答不了** —— 不把全景摆在面前,
        「要不要只挑高价值的」根本没法回答:他不知道这批里有多少是高价值的,
        也不知道切完还剩几个。所以:
          **选人 = 主管初选(1、2)+ 助手精选(3、4,并顺手给出一版已经分好的方案)**
        助手在这一步 不是"等下一个指令",而是先把该看的摆出来、把方案做出来。
      
      🔴 **补上「多久没来」的真正分量**(产品点出,此前整篇都没写):
        它不只是筛选条件 —— **有经验的主管能从它估出这批大概能回来多少**
        (一两年没来的和三年以上的,回头率不是一个量级),而这个估算往下游一步
        就是**诊所的排班**:预计回来多少人、多少要做种植,医生和科室要不要提前留位。
        ⇒ 这一项必须由主管拍, 系统不代劳也不推荐。
      
      决策树相应改成 召回策略 → 主管初选 → 助手精选 → 分人 → 确认 → 确认之后;
      重跑那条环回到「主管初选」。mermaid 节点引用与 style 目标已校验无悬空。
      
      Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
      luoqi committed
    • docs(站点): ① 选人补上「团队还吃得下多少」;顺带修掉一处文档与产品的漂移 · 0ffc8d40
      产品指出:主管在 ① 里还有一项很实际的顾虑 —— **团队当前负载**。人捞太多客服打不完,
      到期回池等于白发一轮。原文只写「这批发多大 · 给几天」,既是术语,也漏了他真正的顾虑。
      
      ⇒ 改成「团队现在还吃得下多少 · 几天内打完」,并新增一节讲人手在**两个地方**主动摆给他看:
         · 出方案时:这批多大按「在岗人数 × 每人每天几通 × 时效」估,式子和每个数都摊开
         · 确认单上:每位客服一行「分完之后约几天打完」,算的是**分完后手上的总量**
           (在手 + 本批), 不只是本批那几条
      
      🔴 **顺带修掉一处文档与产品的漂移**:文档把那个引导节点叫「打不完」,而产品里它的
        真实措辞是「这批发下去,最忙的是王强:手上共 45 条,约 3 天的量」—— **只报数,不下判断**。
        文档那个名字自己就违反了它下一段在讲的纪律。四个节点全部按代码里的真实措辞重写:
        专属排满了 / 还能再收窄 / 这批多大 / 最忙的那位。
        ️ 并补一句点明: 不说「打不完」「人太多了」「建议减到 200」—— 那是替主管做决定。
      
      Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
      luoqi committed
    • docs(站点): 决策树改用运营语言 —— 「① 选人」讲的是主管的召回策略,不是界面操作 · 885152ea
      产品走查:原文写「主管在矩阵上点一格」「这一格还能再切」「就按整格来」——
      **这是界面操作术语,不是产品设计语言**。看这篇的人要知道的是主管在做什么决定,
      而不是他的鼠标落在哪。
      
      ⇒ ① 选人那一步改写成他真正在决定的四件事:
         · 做哪一类还没启动的治疗(种植 / 正畸 / 拔牙…)
         · 找多久没来的人(三个月内 … 三年以上)
         · 要不要再收窄到高价值的(消费额 / 商保 / 意向)
         · 这批发多大、给几天时效
         ② 分人相应改成「谁去打这些电话」。
      
      ️ 补一条 Callout 点破两步的性质:**①是运营策略,②是排班**。主管脑子里是
        「这个月主推种植,把一两年没来、消费额够的那批捞出来」, 不是在操作界面 ——
        界面只是把这句话变成可点的形状。
      
      ️ 主管的**引语保持口语**(「只要商保直付的」「换成一两年没来的」)—— 那是他真会说的话,
        正是助手要听懂的输入, 不该改成书面语。改的是叙述语言,不是他的语言。
      
      Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
      luoqi committed
    • docs(站点): 《分配助手》重排 —— 决策树提到第一位,按选人/分人/确认/确认后讲 · c2ef6ae9
      原来第一节是「三者分工」,决策树排在第二节里。但读者来这一页想知道的是
      **这条线怎么走**,分工是背景 —— 顺序反了。
      
      ⇒ 决策树提到 §1,并按四步重画:① 选人 → ② 分人 → ③ 确认 → ④ 确认之后。
        这四步不是新造的,就是助手讲这一版时被要求遵守的那个顺序 ——
        图和它嘴里说的话现在是同一个结构。
      
      ️ 那个红色菱形(他动的是①还是②)仍然是全文重心:它是助手在这条线上
        **唯一实质的判断**,而且代价不对称(误判成②=条件没生效且看不出来)。
      
      精简:269 → 198 行(-26%),6 张图 → 2 张。删掉的是"它由什么拼起来"整节
      (与五层提示词重复)、工具清单的两张长表(合成一张三行表)、引导节点的示意图
      (表格已经说清)。 没删任何一条纪律或红线 —— 那些是这篇的价值所在。
      
      ️ mermaid 节点标签里 不写 `**加粗**`(会被字面渲染成星号),已复查两张图都干净。
      
      Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
      luoqi committed
    • fix(摄入): 影像 AI 的诊所取自这张片自己那次病历, 不再"借"患者别处的诊所 · 217ca734
      `image_finding_rows` 原来用 `any(organization_id)` 按**患者**取诊所:随便挑该患者的
      一条病历,把那家诊所贴到片子上。两个毛病:
        ① `any()` 语义就是「随便挑一条」—— 患者跨诊所时挑中哪家是任意的,重跑还会变;
        ② 挑的维度根本不对 —— 要回答的是「**这张片在哪拍的**」,却按「这个人在哪看过」作答。
      影像表自己没有诊所列(19 个列全查过),但**有 `emr_id` 且 100% 有值**,指向这张片所属的
      那次病历 —— 真来源一直就在手边。
      
      ⇒ 改成按 `ia.emr_id` 精确 join 那条病历取 `organization_id`,并加 `e.patient_id = c.patient_id`
        (片子的病历必须属于同一个患者)。
      
      📊 全量实测(2026-08-16,测试服连的是真 DW):
        · 两版都能算出诊所的 160,436 行里,**24,849 行(15.5%)现在挂错**,牵涉 21,149 个患者。
        · 改后只少 879 行(0.5%)—— 那些片子挂着一个**在病历表里不存在**的 emr_id。
      🔴 少掉的那些是**故意不要**的(产品定):取不到诊所 → `transaction-synthesizer` 按
        「clinic 是立柱必填」跳过 → 不摄入。 宁可不要,也不拿别的诊所顶上去装作知道。
      
      🔍 抓到这条的现场:测试服上海世纪公园池子里三个"算不出档位"的患者,病历号前缀是
        **CQ / GZ**(重庆 / 广州),被贴成了上海 —— 而那家诊所在池患者 99.3% 是 SH 开头。
        顺着查:他们片子的 emr_id 在病历表里查不到,当年借来的那个诊所**今天也借不到了**
        (`po.org` 现在返回 NULL)⇒ 那三条事实的诊所是个**无法复现、无法验证**的值。
      
      ️ `GROUP BY` 里 `patient_id` 必须留着:cohort 注入是插到**首个 GROUP BY 前**的,
        改成只按 id 分组会让注入落空 → 每批全表扫 + 串批,而且不报错。
        已按 `injectCohortFilter` 的真实行为(已有 WHERE 时追加 `AND`)在 DW 上验过注入后可执行。
      
      Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
      luoqi committed
    • fix(备份): 先轮转再 dump + 空间预检 —— 这个脚本自己把测试库崩过两次 · 5d2a3d02
      测试机 47.251.104.47 的每日备份(`/root/pac-backup.sh`,cron 0 4 * * *)
      连着两次(08-11、08-15)在 04:30 前后失败,backup.err 里是
      「server closed the connection unexpectedly」。翻 postgres 容器日志才看清:
      
        PANIC: could not write to file "pg_logical/replorigin_checkpoint.tmp":
               No space left on device
        checkpointer process was terminated by signal 6: Aborted
      
      ⇒ **不是 PG 的毛病,是这个脚本撑爆的盘。** 轮转写在 dump 成功之后,
        于是写第 4 份(~12G)时旧 3 份 33G 全程占着 → 盘满 → PG 当场 PANIC、
        整个实例重启走 WAL 崩溃恢复 → pg_dump 连接跟着断。
      
      ️ 最难受的一点:脚本删掉 .partial 之后空间就回来了、库自己恢复完毕,
        **白天查什么都正常**,所以连崩两次都没人发现。
      ️ 崩溃恢复还清空了 pg_stat_*(统计文件不跨崩溃保留)——
        之后查到的死元组数只是崩溃后攒的, 别拿它判断表膨胀。
      
      两处结构性修改:
      ① **先轮转、再 dump**:留 KEEP-1 份进 dump,写完正好 KEEP 份。
         峰值从 (KEEP+1)×份 压到 KEEP×份 —— 不再需要凭空多出一份的余量。
         代价:dump 失败时手上只剩 KEEP-1 份;比起把库撑崩,可接受。
      ② **动手前先算够不够**,不够就不开工并大声记日志。
          不许为腾地方自动多删旧备份 —— 少留几天恢复窗口是人的决定,不是脚本的。
         预检在**删之前**算(用"轮转能腾出多少"做加数),不够时一份都不动。
      
      另外:KEEP 3→2(盘 197G / PG 卷已 75G / 一份 dump 12G,KEEP=3 两天就回到
      5G 余量,正是事故前的水位);加 --dry-run(只算不动手);backup.err 超 5M 自转。
      
      📌 顺带把它收进仓库:此前**只存在于服务器上**,而 scripts/backup-db.sh 是另一个
         本地临时用的脚本,两者早已各走各的。README 写清谁是谁。
      
      Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
      luoqi committed
    • fix(名册/矩阵): 在岗按「在这儿干活」判,不是「碰过一次」;算不出档位的人数去重 · 4b2dec7e
      测试服上海世纪公园显示「193 位在岗」,而同规模的其他诊所都是 32–43。产品指认
      康慧捧是别家诊所的人 —— 查下来正是如此,而且是普遍现象。
      
      ① **名册闸**(agent-roster.service.ts)
         拆开看这 193 人:19 个做了 15,476 条(95.8%),**98 个只有 1 条**、63 个 2–5 条;
         161 人(83%)全年合计 296 条,占 1.8%。按主场分:**160 人主场在别家诊所**,
         他们在这儿总共只有 330 条(康慧捧:主场 3,799 条在另一家,这儿 3 条)。
         医生/护士/前台偶尔被记成一次回访负责人,就进了名册。
         ️ 危害不止那张表不好看:`rosterCount` 直接进默认批次估算
           (在岗人数 × 每天几通 × 时效)—— 193 × 15 = 2,895,比真实规模大一个数量级。
         ⇒ 判据改成「本诊所回访量占个人总量 ≥20%,**或**本诊所 ≥20 条」。
         ️ 两条取或,缺一不可:只用占比会挡掉 13 个在某诊所做了 50+ 条但个人总量更大的
           真客服;只用绝对量对小诊所和新人不公平(那正是"名册不是白名单"要护的人)。
         ️ 分母是**跨诊所**总量, 不是本诊所的 —— 否则占比恒为 100%,整道闸失效(已锁测试)。
          实测:世纪公园 193 → 34(25 个靠量进、9 个靠占比进),康慧捧被挡掉;
           其余诊所各减 1–6 人,每家留下的名册仍覆盖本诊所 **98% 以上**的回访量。
         ️ 闸只改"建议给谁", 没改"能分给谁":被挡掉的人走 extraUserIds 照样能被点名,
           姓名由 namesAnywhere 兜底、inRoster=false。rosterNote 的措辞跟着判据一起改。
      
      ② **「另有 N 人算不出档位」数错了**(cohort-attributes.service.ts)
         界面写 50,去重只有 42 —— 50 是把 8 个治疗行的 unknown **竖着相加**得来的,
         一个患者有几个治疗项就被数几次,而那句话写的是「人」。
         本方法开头那条口径(「矩阵按患者去重」「 别让主管一对数就觉得系统在骗他」)
         讲的正是这件事,偏偏这行汇总自己踩了。
         ⇒ 改成 GROUPING SETS 多取一组跨标签去重行。️ 必须与各格**同一次查询**算:
           分两次就是两个 NOW(),边界人群会在两个时刻落进不同档,差额又对不上。
         ️ 话里补一句「那一列竖着加会大于这个数」—— 不写清楚,主管一相加还是对不上,
           那只是换了种方式让他不信任这个数。
      
      📌 顺带定案:**咨询不算到诊**(产品定)。那 42 人名下只有 diagnosis_record +
         consultation_record、**一条 encounter/病历都没有**,末诊为空是对的,不是漏算。
          不改末诊口径(schema 上写死的 encounter + 治疗 + 挂号 + 病历 并集)。
      
      Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
      luoqi committed
  2. 15 Aug, 2026 9 commits
    • chore: 删掉 docs/~/gitlab.md —— 波浪号没展开留下的空文件 · be90e662
      e6e079c2 带进来的 0 字节文件,路径里那个 ~ 是字面目录,不是家目录;没人引用。
      
      Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
      luoqi committed
    • fix(助手): 全角标点那条加一句「重点遵守」 · 1064a910
      VOICE 层里中文标点全角本来就写着,实际输出仍常混半角。 不新增规则、
      不改语义,只把这一条的语气加重(排版类里它最容易被顺手违反)。
      
      Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
      luoqi committed
    • docs(助手): 撤回「qwen 结构上做不到边写边调工具」—— 那是伪证据,且早被裸台验过 · 9818aa95
      产品指出后复核,8-14 写在 use-assistant-chat 里的那段"能力判断"两处推理都断:
      
      ① 「百炼文档示例里出 tool_calls 那轮 content 为空 ⇒ 那一步写不了字」——
         示例是一次示范、不是契约;"某个示例没写字"推不出"写不了"。
      ② 「一旦某步没有工具调用多步循环就结束 ⇒ 所以它只能先把工具全调完再一口气写完」——
         前半句对**任何模型都成立**(deepseek 也一样),而且恰恰不推出后半句:
         文字+工具、文字+工具、末步只有文字,循环照样结束、输出照样交错。这个「所以」是空的。
      
      🔴 **而且它早就被验过了,结论相反。** assistant-lab 就是为这件事建的裸台,
         里面专门开了 qwenThinking provider(只塞 enable_thinking, 不碰 response_format),
         目的写在那儿:「这一轮只是要验开了思考 qwen 会不会好起来」。
         产品实测:**开了思考的 qwen 能边写正文边调工具**。⇒ 那条结论已被推翻, 别再引用。
      
      ️ 更该记的是:反证**当时就摆在旁边**。同一天的注释写着"共用 provider 无条件给
         每个 qwen 请求塞 enable_thinking=false,连 agent 这条带工具的链路也塞 ⇒ 这几天
         拿 qwen 跟 DeepSeek 比要不要边写边调工具,其实是「便宜档+会思考」对「最高档+不许思考」,
         比较本身不成立" —— 而"这几天"正是那条结论的产出期。两份注释直接打架,日期都是 8-14。
          根子在:结论只留在人脑子里,被它推翻的旧结论却用硬语气写在代码里,
         下一个人(包括 AI)读到的必然是错的那份。
      
      顺带修正 assistant-chat 里那条退化保护的**归因**:原文写"实测 qwen 会把 tool-call
      全提到文本之前,deepseek 则正常交错",当成模型差别。不对 —— 当天在 **deepseek** 上
      抓到过同一形状(golden 的 guidance-opens-in-place,失败形状 [工具×3][文本]),
      是补了工具描述里「可动手的事**一件一件**开放」才稳住的,那是**提示词缺口**。
      ⇒ 那条保护**与模型无关,一直留着**:退化时主管看到的是一排没头没尾的按钮。
      
      现在只保留一句站得住的:**默认 deepseek,因为跑批基线都在它上面测的。**
       别写成"另一个不行"。要比就在裸台上开着思考比,或 GOLDEN_MODEL=qwen3.8-max
      跑 guidance-opens-in-place 比通过率。
      
      Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
      luoqi committed
    • fix(助手): 患者详情页把「当前开着谁」发给模型 —— 跑批抓到的那条,补上 · 5ce0ec6e
      a8c60f7c 跑批当场记下、标着**未修**的那个:患者详情页的助手**从来没把
      "当前是哪位患者"发给模型** —— current 里只有 planId + 姓名,姓名只被拿去
      预填例句文字。界面上那条不带姓名的例句「这通电话怎么开口比较好?给我两句开场」
      当第一句发出去,**模型不知道是谁**。
      
      ⇒ 走旁路,与 activeClinicId 同一条:store 的 current 补 patientId,
        前端每次请求带 activePatientId,服务端拼在**现场之后、渠道之前**。
      
      ️ 措辞两件事都要说:**默认落点**(没点名时指的是他)+ **可以被推翻**
        (他点了别人的名字就以他说的为准)—— 只写前半句会让它连"查另一个人"都不敢。
       **不注入到工具参数**:注入等于把"查另一位患者"这条路堵死,而他随时会问别人。
       不进 buildSystemPrompt 的五层:那五层按**什么会让它变**分,而这一行每次请求
        都不一样,是**此刻的现场状态**,不是规则。
      ️ 只发 id —— 姓名由工具返回, 别把界面上的显示名当事实喂给它。
      ️ 前端可改的入参,越权仍由各工具自己的 assertPatientInScope 挡,
         不因为"是我们自己发的"就当可信。
      
      Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
      luoqi committed
    • feat(分配): 确认单每位客服加负载天数;换算尺跟着提案一起下发 · a99f8eb8
      主管在确认单上看「每个人要打几天」——「约 N 天」落在每位客服那一行,
      超出本批时效只用**颜色**(琥珀)提示。
      
      ️ 算的是**分完之后手上的总量**(在手 + 本批), 不是本批那几条:
        他手上原本压着的也要打,只算增量这个数会系统性偏小。
      ️ 与 daily_overload 引导节点**同一个式子** ceil(总量 / 每天几通):
        那条只报最忙的一位,这一列把每个人都摆出来, 两处别算出不同的数。
       措辞不带「打不完 / 超了 / 过载」——它几乎每批都会有人超,说成故障
        主管就会开始怀疑系统而不是做决定(同引导节点那条纪律)。
        在**卡片里现算**:他拖一个人、点一个 ×,这个数当场就变;服务端那份是快照。
      
      做这个功能撞出两个真 bug:
      
      ① **换算尺根本没跟着提案回来。** dailyCalls 此前**只是 propose 的入参**,
         算完就丢 —— 主管说过「每人每天按 20 通算」之后,卡片和 modelFacts 里
         **仍然写死常量 15**:「按每天几通算: 15」和他刚说的 20 直接打架,**而且不报错**。
         与 rosterCount 同一条理由:**乘法用到的数必须跟着积一起发**。
         现在 daily_overload 的判定与措辞、batch_size_basis 的式子、那个输入框的预填值
         全读 p.dailyCalls, 不再引常量(顺带修掉:他填了 20,下次输入框还预填 15
         = 又把他的改动抹了)。
      
      ② **「重算丢东西」的第四个** —— 按自己写的通例一测就撞上:refill 那条路不收
         dailyCalls,主管改成 30 通再点一下「补上」,天数整列悄悄退回按 15 算。
         ️ 它**不影响人数**(targetCount 已显式带回),只改换算与呈现 ——
         正因为不影响人数,比前三个更难被发现。已补齐 schema / controller / 前端,
         并加进契约测试那条通例(注明这一点)。
      
      Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
      luoqi committed
    • test(golden): 补客服线 3 条 —— 此前 12 条全是主管,那条线一条没测过 · a8c60f7c
      用例格式加 who / asUser:主管和客服是两套工具清单(21 vs 9)、两份角色与现场,
      runner 按 who 取 token 并缓存;客服侧不传 activeClinicId(那是主管那一屏才有的)。
      asUser 用真实客服 id —— 通用 mock 身份名下没有单,「今天该联系谁」会退化成空队列,
      测出来的是另一件事。
      
      三条(都指得出真实风险, 不是设想的场景):
      - 今天该联系谁 → 必须真查队列(名单编错他会真打过去,与主管侧「数字必须有锚」同源)
      - 帮我捋一下某某 → 必须先找到人(话术编得越顺越危险,客服照着念患者当场听出不对)
      - 还有哪些人我可以联系 →  不许说得像替他领了活(客服结构上领不了,测的是"会不会说得像做到了")
      
      ️ 防腐测试拦下了我第一版的 mustNotSay(「已经给你」「已经加到」)——它是对的:
      那两个会误伤合法回答,是**措辞锁**不是损失锁。只留「已领取」,并把它加进允许集 + 写明理由。
      
      🔴 跑批当场又抓到一个真问题(**未修**,见用例注释):患者详情页的助手
      **从来没把"当前是哪位患者"发给模型** —— current.patientName 只用来预填例句文字。
      界面上那条不带姓名的例句「这通电话怎么开口比较好?给我两句开场」当第一句发出去,
      模型不知道是谁。与主管侧 activeClinicId 同类,那边走旁路解决了,这边没有。
      
      Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
      luoqi committed
    • docs(站点): 新增《分配助手》—— 给产品业务看的 agent 说明 · ee4aab23
      apps/pac-docs/content/docs/design/assignment-agent.mdx(6 张图):
      ① 三者分工:主管做决定 / 助手组织语言调工具 / 程序算数取数落库
      ② **分配决策树**:从"主管圈定"到"已确认"的完整走向,含两条闭合的环
         (改派法→回同一版 / 改人群→出新版旧版作废),以及助手在这条线上
         唯一实质的那次判断(动的是「怎么派」还是「这批人是谁」,代价不对称)
      ③ 它由什么拼起来:五层提示词 + 工具 + 每次出方案给它的事实与引导节点
      ④ 提示词五层(按「什么会让它变」分)+ 两种登录人看到的两份
      ⑤ 引导节点长什么样 + 三条设计原则
      ⑥ 三层验收:算法/交接用测试,助手行为用通过率
      
      ️ 与 batch-assignment.mdx 分工:那份讲**功能**,这份讲**那个助手**。
      ️ 工具数(主管 21 / 客服 9)按条件注册实点过, 不是估的。
      
      Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
      luoqi committed
    • test(golden): 接口错误 不算模型失败;样本太小时明说 · a142cb6f
      两条都来自 2026-08-15 自己踩的:
      
      ① 跑批跑到一半我改了服务端源码 → dev server 重启,请求全断(terminated /
         fetch failed),而 runner 把它算成"用例没通过" —— 输出读起来和模型退化一模一样。
         ⇒ 接口错误单列、不进通过率分母,并直接提示"服务是不是中途重启了"。
         一轮都没判成时退出码 1 并写明"本次结果作废"。
      
      ② 3 轮的 1/3 让我判成"模型判不准",干净重跑 10 轮是 9/10 —— 同一个行为。
         ⇒ rounds < 5 时输出一行:这个数分不出"判不准"和"运气差", 别据此改提示词。
      
      Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
      luoqi committed
    • fix(分配): 重排不再丢掉主管的按客服精调 —— 「重算丢东西」第三个 · f353f51b
      「李莉这周带教,这批最多给 5 条」只活在这一版的 agentOverrides 里,而 propose 的
      基线读的是**上一次已确认批次** —— 点一下「换无专属客服的患者补上」他刚设的那条就没了,
      李莉照常吃满,而且不报错。
      
      实测(上海世纪公园 · 拔牙 3 年以上):
        不带精调重排 → 胡婷 16 条
        带 maxThisBatch=5 → 胡婷 5 条, overridden=true, agentOverrides 原样回传
      
      三处补齐:RefillProposalRequestSchema 加 agentOverrides / 控制器透传 /
      前端发**当前这一版**的(已含基线合并结果, 不能只发本轮新加的,否则沿用下来的会被当成撤销)。
      
      契约测试加了一条**通例**断言:「他在这一版上做过的事」三样一样不能少
      (narrowedBy.personaTags / narrowedBy.minSpendYuan / agentOverrides)——
      这是同一形状的第三个 bug, 加第四个能触发重算的载体时先回来补一行。
      
      Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
      luoqi committed