- 29 Jul, 2026 17 commits
-
-
业务口径(2026-07-29):回访挂医生的名义,患者更愿意接、也更贴事实(话术全程就是 以诊断医生的关怀为主线);"客服"听起来像销售,开场就掉信任。 改动收在两处口径源,三档共用: - agent-identity.ts:岗位称呼 staff/leader/admin 一律「助理」(患者不关心内部层级, 原来 leader 报"客服主管"),无姓名兜底也从"客服"改"助理"。 - prompt 里的自报家门句:`我是{clinicName}的【回访客服】` → `我是{诊断医生}医生的【回访客服】` (稳健档 prompt / 标准+深度档 fact-block / 稳健档 LLM 失败兜底文案,三处全改)。 医生姓取诊断医生,取不到时 deidentifyDoctor 给"您的主治" → "我是您的主治医生的助理X"。 占位符字面量 `【回访客服】` **故意不动** —— 线上 plan_scripts 已有正文都含这串, 改字面量等于老缓存回填不上、患者会看到光秃秃的占位符。它现在只是个 token, 回填出来已经是"助理X";老话术因此平滑变成「我是XX诊所的助理李倩」,不会出洋相。 诊所名不再进自报家门,但仍作为一行事实给 LLM(标注"只在需要提到诊所时用,别自己编 XX口腔")—— 原来它就是防编造用的,直接删会让 LLM 自己造诊所名。 三档 promptVersion 全 bump(inputHash 含 promptVersion → AI 缓存自然失效,新生成走新话术; 已生成的老话术不会自动重跑,要新措辞得点「重新生成」)。 657 tests / 42 suites 通过(agent-identity + script-facts 两个 spec 同步改口径)。 Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>luoqi committed -
业务要求(2026-07-29)。两处都做成**不传回调即不渲染**,抽屉本体 (kind='teeth' / 'return-visits')一行没动 —— 想恢复就是把 onOpenTeeth / onOpenDetail 传回去,注释里写好了原样。 顺带改了历史联系的兜底文案:原来是「N 条历史联系 · 点「详情」查看」, 详情入口一隐藏就成了指路指向不存在的东西,现在只留「N 条历史联系」。 web typecheck 通过;本地实测关键事实卡只剩「详情 →」。 (历史联系卡本地这个患者没有回访记录、不渲染,那处未实测。) Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
luoqi committed -
三处按业务意见调整: ① 顺序由业务定,写死在 PERSONA_KEY_FEATURE_KEYS 的数组序: 治疗史 → 潜在治疗 → 价值分群 → 生命周期 → 权益身份 → 折扣锚点 → 获客渠道 → 禁忌标签 → 特别关注 (原来跟抽屉共用 personaFeatureSortKey,那是按"跟进要点/价值与阶段/基础属性" 分组排的;首屏没有分组标题,照那个序排客服看不出章法) ② 急迫等级下首屏 —— 顶栏「优先级」条已经表达同一件事(急迫是它权重最大的一项), 同屏两处讲一件事会被当成两个指标。 ③ 去 hover,改点击:chip 变真 button,点了开画像详情抽屉并**滚到那张卡、加重描边**。 扫首屏时鼠标划过就弹浮层是干扰;真想知道"这标签怎么算的"的人,该看的是完整那张卡。 抽屉里十几张卡,要找的常在折叠线以下 —— 不定位的话点标签和点「详情 →」没区别。 走「详情 →」进仍是看全量,不定位。 滚动等一帧再执行:抽屉是本次渲染才挂上的,同步滚时容器还没布局,scrollIntoView 是空操作。 label 视觉上去掉了,button 补 aria-label(读屏仍念得出标签名)。 657 tests / 42 suites 通过;web typecheck 通过。 Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>luoqi committed -
按业务意见调整: ① 治疗史 / 折扣锚点 / 获客渠道 / 权益身份 进首屏(现 10 个,16 个里留 6 个不进: 时间偏好、治疗敏感 —— 通话中才用;年龄段、性别 —— 姓名行已有; 家庭构成、转介绍达人 —— 不改变开场)。 ② chip 去掉标签名,只留取值:「急迫等级 紧急」→「紧急」。 取值本身自解释(紧急 / 种植禁忌 / 储值会员),label 是冗余;十来颗标签 每颗都带名字会把身份卡撑满。要看标签名或口径 → hover / 进抽屉。 ③ 去掉按 tone 的多彩着色,统一素色,与左栏列表卡片的通用标签同一套 (rounded + slate 描边)。首屏十几颗各一种颜色 = 满屏彩条,反而看不出轻重。 新增 plain 模式挂在 PersonaTagCloud 上,画像标签卡兜底/抽屉仍是原来的带 label 彩色版 —— 那两处标签少、要的是辨识度,口径不同不强行统一。 657 tests / 42 suites 通过。本地实测张红渲染 潜在种植+1 / 紧急 / 低活跃 / 流失客 一行素色 chip。
⚠ ️ 本地库这个宿主没有治疗史/折扣锚点/权益/获客渠道的数据,这四颗的观感未实测。 Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>luoqi committed -
业务(2026-07-29):关键标签在完整客户名字下直接显示,可快速查看,要细看再进详情。 标签云组件(PersonaTagCloud)一直在,只是自从画像卡改成 LLM 一句话摘要后 被降级成"摘要生成失败"的兜底 —— 客服想看标签得点开抽屉。现在把**关键那几个** 提到身份卡姓名下方,复用同一套 chip(hover 仍能看「怎么算的」),不另起渲染。 关键 = PERSONA_KEY_FEATURE_KEYS(types 里定,附选取理由): 禁忌标签 / 特别关注 / 急迫等级 / 潜在治疗 / 价值分群 / 生命周期 按「能不能治 → 能不能打 → 多急 → 聊什么 → 给多大力度」排。 时间偏好、折扣锚点、治疗敏感是通话**中**才用的,基础属性姓名行已有,都不进首屏。 16 个标签一个不少,仍在画像详情抽屉全量可查 —— 取舍的是首屏不是信息。 排序沿用 personaFeatureSortKey(与抽屉同一套序),白名单只管"哪些进"。 加防漂移测试:白名单里的 key 必须还活着 —— 改 key 名不会报错, 只会静悄悄少一个 chip,而少的若是禁忌/免打扰就是事故。 657 tests / 42 suites 通过;本地实测张红渲染出 潜在治疗·急迫等级·价值分群·生命周期 四颗。 Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
luoqi committed -
业务约定:客户档案 / 病历 / 预约等宿主页面「打开新页,不在当前页面做跳转」。 原来四处槽位跳转全用 `_top` —— PAC 嵌在宿主 iframe 里时会把整个宿主页顶掉, 客服看完档案回不到刚才的工单(召回上下文、已填的通话结果全丢)。 四处统一收口到 action-url.ts 的两个出口,免得以后再各写各的 target: a 标签 → HOST_LINK_PROPS (target=_blank + rel=noopener noreferrer) JS 派发 → openHostUrl() 覆盖:VIEW_PATIENT(原始档案)、VIEW_MEDICAL_RECORD(原始病历)、 CREATE_APPOINTMENT(新建预约)、OPEN_POTENTIAL_TREATMENT / OPEN_RETURN_VISIT 的 URL 模式(postMessage 模式不涉及跳转,不动)。 本地实测:两个 a 标签渲染成 target="_blank" rel="noopener noreferrer"; 新建预约走 openHostUrl 打开宿主页。 Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
luoqi committed -
现象:上次时间已选后显示「18m_plus ×」「12_18m ×」而不是「18 个月以上 ×」「12-18 个月 ×」。 根因:消费方按 `d.key` 查维度,而 source='patient' 的三个维度(上次时间 / 上次医生 / 偏好医生) key 是空串、筛选串用的是 `id` —— 查不到维度 → 退回显示 value 本身。 加 `id` 时改了组装侧(plan.service)和面板渲染,漏了这两处消费点: - patient-picker-rail 的已选 chip:改用 personaTagDimId 查维度; 顺带把 `kv.split(':')` 改成按**首个冒号**拆(取值理论上可含冒号,如医生姓名)。 - mcp-server.factory 的 personaTags 说明:同样按 key 生成,会给 LLM 一个**空维度名**, 它照着发就永远筛不出人。改用 personaTagDimId;开集维度(医生)options 为空, 提示改成"自由文本 + 指向 GET /pac/v1/plans/doctors",免得 LLM 瞎猜姓名。 测试:persona-spec-drift 补一条 —— 闭集维度的每个取值都必须能按 **id** 查回中文, 锁住"用 id 一定查得回来"这个不变量。656 tests / 42 suites 全过。 本地实测:已选 chip 显示「0-3 个月 / 12-18 个月 / 18 个月以上」, hover 提示「上次时间:0-3 个月(点击移除)」;请求带 personaTags=last_visit_bucket:0_3m,… 返回 200。 Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>luoqi committed -
返工上一版:visit_recency 曾做成 persona 特征,当天被否 ——「上次到诊 2022-06-19」是 **原始事实**,而画像该是「重要价值 / 流失客 / 禁忌」这类判断。做成特征会混进患者详情的 画像标签抽屉、并喂给画像摘要 LLM。该特征一行都没写进生产就撤了。 【落在哪】patient_profiles(1:1 副表),不是 patients: profile 本来就装派生 / 摄入属性(获客渠道、转介绍统计),patients 是主数据。 派生的归派生,主表不被越搞越宽,也不用新建一张表。 【为什么必须物化】跨全池筛选没有不物化的:否则「上次到诊在 3-6 个月」要对 2,500 万行 patient_facts 做 GROUP BY … HAVING max(occurred_at),交互式扛不住。 画像筛选也一样物化了 —— 它的柱子就叫 persona_features,只是立得早、又用 JSONB 做成了 免 DDL 的扩展点,所以加维度时感觉不到成本。这三个字段不属于画像,没有现成柱子可搭。 【
⭐ 存日期不存分档 —— 零定时任务】 存 `0_3m` 这种分档,时间流逝自己就会错(今天 2 个月、下月变 3 个月)→ 得配到期重扫 (上一版为此实现了 nextBoundaryAt);存日期则**只有患者又来了才会变**,而"又来了"必然 先写到诊 fact → 推进事实水位 → 触发该患者画像重算 → 三列顺路刷新。触发时机与既有机制 天然重合,自洽。0-3 / 3-6 / … 的区间在**查询时**按 now 现算(visitRecencyRange)。 【⭐ 到诊口径 = encounter + 实际治疗 + 挂号 + 病历】 本地实测:17,637 个有事实的患者里 **8,586 个(48.7%)只有病历、没有 encounter/治疗/挂号** (宿主 appointment.in_time 缺失等)。只用 visitFactsOf 会让近一半患者「上次到诊」为空 —— 本轮实测正是如此(487 → 加病历后 2,408,近 5 倍)。医生写了病历,患者必然到过场; 详情页 lastVisit 早就是这个并集口径,这里与它对齐。⚠ ️ 顺带发现:rfm / lifecycle_stage / urgency_level 仍用窄口径 visitFactsOf, 同一批患者会因此少算就诊次数 —— 值得另开一件事核实,本次不动。 【卡片与筛选同源】两者都读这三列,不做"取不到就现算"的兜底 —— 那会让展示值与筛选口径再次分叉,正是本次返工要消灭的问题。 首次重算前为 NULL:卡片留空、筛选筛不到、医生名单为空,都是可接受的降级。 其余:PersonaTagFilterDim 加 source/patientField 分流查询;医生名单接口改查 patient_profiles; 写入挂在画像重算遍历上(顺路,失败只告警不中断 —— 它不是画像的一部分); persona-spec-drift 的 key 校验跳过 source='patient' 维度。 655 tests / 42 suites 全过;types / service / web typecheck 通过; 本地重算实测卡片显示「2022-06-19 · 张 敏」,与筛选同源。 Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>luoqi committed -
`<div key={dim.key}>` 在 visit_recency 出三个可筛字段(上次时间/上次医生/偏好医生)后 产生重复 key,React 报 "Encountered two children with the same key"。 改用 personaTagDimId(dim)(维度唯一标识,正是为这种情况加的),并就地注释说明。 Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>luoqi committed -
业务要「上次医生 / 偏好医生」筛选。医生是开集(单宿主几百个),chip 平铺放不下。
⭐ 核心取舍:**模糊只发生在前端**。 输入框在已加载的医生名单里做子串匹配,选中后发**精确姓名** → 后端仍是等值查询, 吃得到偏索引。若改成后端 ILIKE '%x%',这三条索引立刻失效、退回全分区扫 —— 就是 2026-07-29 那个「圈人 20 秒」。要真·后端模糊得先上 pg_trgm + GIN, 并确认托管 PG 允许装扩展(见迁移注释)。 附带好处:客服不用记全名、不会因打错字得到空结果还以为"真没人"。 改动: - PersonaTagFilterDim 加两个字段: · `id?` —— 筛选串 `id:value` 的维度标识。**同一特征出多个可筛字段时必填**: visit_recency 一个特征出 bucket / lastDoctor / preferredDoctor 三个,只靠 key 分不开。 不填回落 key,存量维度零影响。新增 personaTagDimId() 统一取值。 · `dynamic?` —— 取值是开集,跳过闭集校验(维度 id 仍校验,取值走参数化 equals,无注入面)。 - plan.service 的筛选组装改为**按维度 id 分组**(原按特征 key 分组,三个 visit_recency 维度会被串成一条 OR,筛出错的人)。 - 新增 GET /pac/v1/plans/doctors:本 scope 医生名单(visit_recency 的 lastDoctor ∪ preferredDoctor 去重),Redis 缓存 6h —— 医生变动以月计,不该每次开面板都跑 DISTINCT 聚合。⚠ ️ 路由声明在 @Get(':id') **之前**,否则 'doctors' 会被当成 planId。 - 前端 DoctorPicker:已选可点掉;输入为空**不铺全量名单**(几百个会把面板撑爆); 名单拉取失败则输入框仍可用,只是没候选。 - 迁移 20260729080000 补两条医生索引(与 bucket 同形态:btree(表达式, persona_id), 第二列让内层 EXISTS 走 index-only scan)。 测试:persona-spec-drift 补两条 —— · 开集维度 options 必须**空**(留样例值会让前端误以为是闭集,把没列出的医生筛没了); ·⭐ 维度 id 必须唯一(重复 id 会指向错的 dataPath,筛出错的人)。 655 tests / 42 suites 全过;types / service / web typecheck 通过; 本地 GET /plans/doctors 实测 200。 Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>luoqi committed -
按 2026-07-29 四点反馈做: 【1】下线的 5 个筛选项改成**隐藏**而非删除。 PersonaTagFilterDim 加 `hidden?: boolean`,面板 `.filter(d => !d.hidden)`。 这样 API / MCP 仍接受这些维度 —— 已保存的筛选链接、机器人调用不会突然失效; persona_features 照常写、偏索引照常在,复活只需删一行。 (上一版直接从字典摘掉,连 API 一起禁了,比"前端隐藏"狠。) 【2】【4】新增画像特征 visit_recency —— 一个特征喂三处: · 列表卡片的「2022-06-19 · 张敏」 · 圈人筛选的「上次时间」(0-3/3-6/6-12/12-18/18+ 月),已接面板 · 「上次医生 / 偏好医生」数据已就位,面板未接(医生是高基数,静态 options 的 chip 面板放不下,需可搜索下拉 —— 已在 persona-tag-filters 注释说明)⭐ 偏好医生用**主治医生**代替(病历里出现频次最高的医生)—— DW fact_client_out.favor_doctor_id 才是真值,PAC 尚未摄入;换成真值时消费方不用改。⭐ 到诊口径用 visitFactsOf(encounter + actual treatment + 挂号),与 rfm / lifecycle / urgency **同一口径**。我上一版卡片是现算 encounter ∪ emr —— 两套口径会算出两个"末诊", 卡片与筛选打架。本次把卡片改成读同一份画像行,fetchLastVisits 删除, 两条查询合并成 fetchCardFeatures 一条(顺带少一次往返)。⭐ lastDoctor 只认**末诊当天**那份病历的医生,跨天不认 —— 否则"日期是A次、医生是B次", 客服照着说就露馅,宁可留空。本地实测填充率:主治医生 1133/1133,上次医生 392/1133(34.6%) —— 因为末诊常落在没有当天病历的到诊上(挂号/治疗)。这是刻意的准确性取舍。⭐ 实现 nextBoundaryAt:纯时间流逝就会跨桶,不报的话水位闸永远不放行、分档停在算的那一刻。 【3】筛选字段加索引:迁移 20260729080000,visit_recency.bucket 的偏索引 (btree(表达式, persona_id),第二列让内层 EXISTS 走 index-only scan)。 这是 persona-tag-filters 顶部那条纪律的兑现 —— 加维度必须同时加索引, 漏了就是 2026-07-29 那个「圈人 20 秒」。新特征建索引时表里还没数据,故无需 CONCURRENTLY。 登记:PersonaFeatureKey / FeatureRegistry / PERSONA_FEATURE_SPECS / PERSONA_FEATURE_META 四处齐全(测试 persona-spec-drift 会卡漏登记,本次就被它卡住两次)。 654 tests / 42 suites 全过;types / service / web typecheck 通过; 本地重算实测特征写入正常。 Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>luoqi committed -
卡片(业务 2026-07-29): - rail 行序调换:「潜在治疗 + 上次到诊·医生」升到第二行,手机/诊所/操作按钮沉到第三行。 理由记在注释里:客服扫列表是先看「这人有什么可谈」(治疗项 + 多久没来), 决定要跟进了才看联系方式、按认领。 - 潜在治疗标签**不再折叠**(原 rail 封顶 2 个、卡片封顶 3 个 + N)。标签多的患者本来就该优先跟, 让它换行占地方是对的;折成 +N 等于逼客服多点一次。两处口径一致,过时注释一并订正。 筛选面板: - 文案「画像标签」→「筛选标签」,面板标题「按画像圈人」→「按标签圈人」(空态文案同步)。 - PERSONA_TAG_FILTER_DIMS 按业务 Tier 重排: Tier1 治疗维度:潜在治疗、治疗史 Tier3 属性维度:价值分群、紧迫度、年龄段、权益身份、转介绍达人、家庭构成、性别 - 下线 5 个维度:时间偏好、生命周期、治疗敏感、特殊关注、禁忌。 **注释保留而非删除** —— 业务口径反复过不止一次,留着比重写便宜;persona_features 仍在写 这些特征、偏索引(迁移 20260728020000)也还在,随时可复活。 - Tier2(偏好医生 / 上次医生 / 上次时间)留了位置和原因,未实现:三者都缺数据基础, 不是加个 option 能解决的(详见文件内注释与给用户的说明)。⚠ ️ 禁忌下线的**只是「圈人筛选」这一处**:它仍在患者详情画像卡展示、仍参与 persona 计算。 安全信号不因为不能拿来圈人就消失。这一条与 2026-07-27 用户「禁忌要做成四类筛选」的 指示相反,是本次业务文档要求,已在给用户的回复里单独点出待确认。 654 tests / 42 suites 全过;types / service / web 三处 typecheck 通过。 Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>luoqi committed -
- 措辞:潜在种植 → 种植治疗、潜在补牙 → **充填治疗**、潜在早矫 → **早期矫治**,余类推。 - 顺序:姓名 → 病历号 → 性别·年龄(原来病历号在最后),与详情页患者卡一致。
⭐ 中文改在**展示层字典**(POTENTIAL_TREATMENT_CARD_LABEL),不改画像 extractor 的 zh: 画像里的 labels 是算画像那一刻写死进 JSON 的,改措辞得**全量重算画像**(百万级,几小时) 才看得到。所以接口改成透 potential_treatment.**types**(code),中文由前端查表 → 改词即时生效、全站一处。未知 code 原样显示,不静默吞标签。 Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>luoqi committed -
业务给的调整方向:去掉诊所名,加病历号、上次时间、上次医生、潜在治疗标签。 诊所名改成**按登录数据权限判断** —— 单诊所权限的人每行都是同一家,是噪音;跨诊所才有区分价值。 改的是两个组件(你截图的 10457 人那个列表是 patient-picker-rail,不是 plans-list-app 的卡片, 两处都按同一套字段改了,保持一致): 后端 plan.service.list —— 两条**整页批量**查询,不逐行发(本页 ≤25 人,都走 patient_id 索引): - fetchLastVisits:DISTINCT ON 取每人最近一次 encounter_record ∪ emr_record。 · 并集是必须的 —— 部分宿主 appointment.in_time 缺失,只有 EMR 能证明到过场 (jvs-dw 实测有患者 0 encounter / 39 emr),口径与详情页 lastVisit 一致。 ·⭐ 医生取**同一次就诊**的医生,不是"历史最常见医生",否则会「日期是A次、医生是B次」错配, 客服照着说就露馅。doctor_name 只有 emr_record 带(encounter_record 实测两宿主都 0% 有名), 故同一时刻并列时优先取 emr;取不到名返 null,不拿 doctor_id 顶替(工号对客服无意义)。 测试服实测覆盖率:池内 2,990 个有就诊记录的患者里 2,966 拿得到医生名(99.2%)。 - fetchPotentialTreatments:取当前版画像 potential_treatment.labels。 它与卡片上的"召回理由"高度重叠但不等价:画像覆盖该患者**全部**潜在治疗, 召回理由只是其中"这次值得召回"的子集。业务要的是前者。 - patient select 补 medicalRecordNumber(jvs-dw 覆盖 91% / friday 63%,缺则前端不占位)。 前端: - 行1 追加病历号(mono,弱色);行2 的诊所名加 showClinic 闸; - rail 新增第三行:潜在治疗 chips(左)+ 上次到诊·医生(右),两者全缺则整行不渲染、不虚占行高; - 列表卡片:chips 接在场景/状态之后,上次到诊放底栏 meta 位。 - PotentialTreatmentChips 刻意比 ScenarioChip 弱一档(无底色、细描边):场景 chip 是 "这次为什么召"=主信息,潜在治疗是"这人还有哪些没做"=背景信息,抢色会让客服分不清主次。 卡片铺 3 个、rail 铺 2 个,其余折 +N(卡片是扫读用的,标签一多就不是信息是墙)。 -⚠ ️ showClinic 判据是 `visibleClinics(user).length !== 1` 而不是 `> 1`: 诊所字典未加载时 visibleClinics 返回 0(集团级用户 clinicIds 为空 → 回退全字典 → 字典空则 0), 按 `> 1` 会把集团级用户也误隐藏。只在**确知单诊所**时隐藏,未知一律显示。 验证(本地):rail 行实测渲染为 「张红 女·43 岁 WY0A007548 / 177****4845 / [潜在种植][潜在根管] 2022-06-19 · 张 敏」 诊所名「元和王永口腔」在该单诊所账号下已隐藏。654 tests / 42 suites 全过; @pac/service 与 @pac/web typecheck 通过。 Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>luoqi committed -
本地这一轮的两处展示层修复(同一批文件有重叠,合成一个提交)。 ━━ 一、排序键精度(真 bug)━━━━━━━━━━━━━━━━━━━━━━━━ 用户截图:召回池按优先级降序,看到的却是「3.12 → 3.12 → 3.10 → 3.10 → 3.10 → 3.12 → …」。 根因是两个数不同源: 排序:ORDER BY priority_score DESC, created_at ASC 而 score = Math.round(raw * 10) —— 0-100 的**整数** 展示:(raw ?? score/10).toFixed(2) —— 取 breakdown.priority.raw,0-10 的**两位小数** 排序精度比展示精度粗 10 倍 → 同一整数档里塞着一堆不同展示分,档内只能按 created_at 兜底排。测试服实测:priority_score=31 一档有 21 种展示分(3.20~2.59); 全池 126,073 张工单只有 93 个排序档位,却有 849 种展示分。 - priority-scorer:不再取整。raw 先定到展示精度(两位小数),score = 该值 × 10, breakdown.raw 复用同一变量 → **score === raw × 10** 成为不变量。 列本来就是 Float(schema 未动);量纲仍 0-100,queueStats 的 70/40 分档、 前端进度条 score/100 均不受影响。 - PriorityBar(列表页 + 患者轨):展示改用 score/10,删掉 raw 入参。 原来「优先读 breakdown.raw、否则 score/10」是双源,正是分叉起点;两处都加了注释。 - 迁移 20260729060000:一次性回填存量。plan-engine 的 unchanged 分支本来就会就地改 priorityScore,下一轮全量重算(每 2h)能自愈 —— 但在那之前页面所有分会显得"变整" (2.74 → 2.70),像精度倒退。用 numeric 运算避免 3.12*10=31.200000000000003 的 浮点噪声;带「值确实不同」判断,幂等。 ━━ 二、文案:应治未治 → 潜在治疗 ━━━━━━━━━━━━━━━━━━━━ 只改**展示层**,共 8 处:场景 chip(labels.ts)、话术段落标题(服务端 SECTION_META + 深度档兜底标题 + 前端流式/空态两处 label)、列表与详情的「其余 N 项…」、助手建议问句、mock。⚠ ️ SECTION_HEAD_TO_ID 那个 markdown 解析键**一个字没动**,仍是「告知应治未治」—— 它匹配的是已落库话术正文里 AI 写下的 `## 告知应治未治`,以及 prompt 当前仍在输出的标题。 改它 = 存量话术全部解析不出 informMissed 段,打开就空白。已在该常量上写了注释说明。 prompt 侧的 {应治未治项} 等约 60 处占位符同样未动(动了要 bump 版本 + 全量重生成)。 ━━ 验证(全部本地)━━━━━━━━━━━━━━━━━━━━━━━━━━━━ - 新增 priority-score-precision.spec:锁 score===raw×10;断言「按 score 排序」与 「按展示值排序」结果一致且单调不增;并在邻近分里自动找出一对「旧口径判等、展示不同」 的样本,证明新口径分得开。 - recall-suppression.spec 那条 toBe(45) 锁的是被丢掉的精度,改为 raw=4.49 / score=44.9。 - 本地重算 4 条 friday plan:score 31 → 31.2 / 31,与 breakdown.raw 1:1。 - 迁移本地试跑 13,473 reason + 7,923 plan;复跑 0 行(幂等); 「排序键 ≠ 展示值×10」的行数 0;页面分数从 2.70 恢复 2.74。 - 文案:特意找一条**正文仍是老标题**的存量话术挂到当前 plan 上验证 —— chip 显示 「潜在治疗」、段落标题「告知潜在治疗」、且段落内容完整渲染(老正文照样解析得出)。 - 654 tests / 42 suites 全过;@pac/service 与 @pac/web typecheck 通过。 Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>luoqi committed -
luoqi committed
-
2026-07-29 线上:FRIDAY 推 patient_settlement 反复 SocketTimeoutException。 查下来是一条链,三处都得补。 【事故链】 ① manifest 的退费识别只认两种表达:status=4、status=3 且 receivable_this<0。 FRIDAY 还有第三种 —— 应收不动、只把钱退回去(status=3 / 应收 0 或 6000 / 实收 -500~-6000), 测试服 57,939 条结算里 4 行。它们漏进 payment_rows → payment_record 的 amount_cents<0 撞 zod nonnegative。 ② 当时 FactWriter.bulkWrite 是**整批 zod 校验、一条不合格整批抛错**,ParserPipeline 捕获后降级 per-entry —— 而 per-entry 是**每 fact 一个 $transaction**。 单批 200 行:bulkWrite 3 秒 → 逐行事务 63.5 秒(实测 199 次事务累计 79 秒; 对照组:空事务 2.7ms、那条 findFirst 4.1ms —— 数据库不慢,慢在往返次数)。 ③ 63.5s 超过宿主 60s 读超时,对方收不到响应就重推同一批;而 PAC 侧回执是 status=success / failed=0,对方也看不出是自己哪一行的问题。 实测从 07-28 20:00 到 07-29 09:00,同一批 200 行推了 13 小时,一条没进。 【改动】 - data/friday/manifest.yaml: · payment_rows 加 net_receipts_this>=0(负实收不算消费) · 新增 _refund_neg_receipt(status∈{1,3} 且 应收>=0 且 实收<0)并入 refund_full_rows。 与既有两条零重叠(全库无 status=4、无应收<0),refund 的 amount 本就取 net_receipts_this。 - fact-writer.service.ts:bulkWrite 由「整批抛」改为「隔离违规条目」, 返回 { results, rejected };新增 FactReject / BulkWriteOutcome。 违规条目只带定位信息(type / subjectId / transactionId / 字段级 issues), **不带 content 原文** —— 回执会进对方日志,患者姓名金额不该顺着外流。 - parser-pipeline.service.ts:消费 rejected 计入 factsFailed + factRejects; 外层 catch 从此只兜真正的批级故障(DB 异常/事务超时),不再因一行脏数据降级。 - cold-import.service.ts / push.schema.ts / push-receiver.service.ts: factsFailed + factRejects 一路透到 push 回执(封顶 10 条,同种错整批同因)。 - channel-push.mdx §9.1:补 factsFailed / factRejects 字段说明与实例, 讲清 failed(行没进) vs factsFailed(行进了但派生不出事实)的区别。 【验证】新增 3 个回归用例锁住隔离语义(好行照常写 / 全违规不抛错 / 正常路径不受影响, 并断言回执不含 content 原文);650 tests / 41 suites 全过;typecheck 通过。 Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>luoqi committed
-
- 28 Jul, 2026 11 commits
-
-
luoqi committed
-
接入文档 channel-push.mdx §7.3 承诺「推送顺序无要求;业务数据先于患者主档到达时, PAC 先建档、主档到达后补全同一人」。实际做不到:push 是**单表**请求, ingestRawTables 只把被推那张表放进 tables const tables = { [opts.source]: opts.rows }; for (const tf of transforms) if (tf.input && !tables[tf.input]) tables[tf.input] = []; 只兜底了 input,没兜底 lookup 的 from。于是 transform-engine 拿不到 from 表, warn 一句就当空表、select 字段全填 null —— 换什么推送顺序都没用,单表请求里 from 表永远不在场。 2026-07-28 FRIDAY 开发推测试数据时踩到: customer_referee_circle 的规则要 lookup customer_basic_info 取**对方性别**, 用来把关系码 3(本人是对方子女)拆成 father / mother。拿不到性别 → rel_sex_key="3|" → patient_relation.yaml 里码 3 唯独没配缺性别兜底 → 掉 _default: other。 实测(测试服): friday 257 条关系边:father=0 mother=0 other=211 jvs-dw 76,999 条(走 cold-import,from 表齐全):father=6,837 mother=10,715(占 23%) 连带 family_structure 的「多代之家」系统性漏判 —— friday multigen 只剩 2 个, 且全靠 grandparent 撑,该识别成多代之家的都被压成 single。 改动: - transforms.schema.ts:lookup 新增可选 push_fallback { entity, select{column,map} }。 不配 = 保持旧行为,存量 host 零影响。 - push-lookup-fallback.ts(新):按 input 行的 left_key 去 PAC patients 捞实体, 拼成"长得像 from 表"的合成行 { [right_key]: external_id, ...select }。 · source_unit 消歧:external_id 在集团型宿主跨品牌撞号(FRIDAY 22 个 source_unit, 实测 310 个 id 撞号)→ 捞取按 input 行解析出的 source_unit 圈定;仍落到多个品牌 则**整条跳过**填 null 走 _default,不硬猜。 · map 把 PAC 归一值反写回宿主原编码(male→'1'),保证 push 与 cold-import 产出 **同一个** rel_sex_key —— 否则两条通道各配一套 enum_mapping,迟早漂移。 · map 未命中 / 空串性别 一律当"取不到",不把 PAC 归一值漏给只认宿主编码的下游。 · IN 列表按 5000 分批(bind-var 32767 上限,存量补摄踩过)。 - cold-import.service.ts:transform 前调 hydratePushLookupTables。 只在 tables[from] 缺席或为空时接管 → cold-import / reparse 不受影响。 - friday manifest:给那条 lookup 配上 push_fallback。 残留(有意为之):对方**从未进过 PAC** 时仍取不到性别,落 other。这是"不知道"而不是 "猜错",且存量首推收尾跑一次 reparse 即可补齐(重放时库已全)。 验证:新增 7 个用例连着 runLookup 一起断言最终值(中间对了下游错了没意义); 647 tests / 41 suites 全过;service typecheck 通过。 Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>luoqi committed -
luoqi committed
-
现象:测试服 deploy 挂在 migrate 步,pac-service 起不来,任何人往测试服部署 都会挂在同一处(跟部署内容无关)。 ERROR: CREATE INDEX CONCURRENTLY cannot run inside a transaction block (25001) 根因是我在 20260728020000 里写了 14 条 CREATE INDEX CONCURRENTLY。 Prisma 把整份 migration.sql 用**一次 simple query** 发给 Postgres,而 Postgres 只对 「一个查询串里多条语句」隐式开事务块 —— 分界线是**语句条数,不是 Prisma 版本**: 20260701060607 / 20260727070000 / 20260727110000 各 1 条语句 → 无隐式事务 → 跑得通 20260728020000 14 条语句 → 隐式事务 → 必挂 而 20260727070000 里那句「Prisma 6.19 已不成立(指事务包裹)」是**错的归因** —— 单条语句侥幸跑通被总结成了「新版没有事务包裹」,我照抄进 20260728020000,于是踩爆。 失败后果比失败本身更重:_prisma_migrations 留下一条 finished_at / rolled_back_at 全空、 applied_steps_count=0 的记录,Prisma 从此拒绝执行**任何**后续迁移(P3018), 整条部署流水线被堵死。同一颗雷已随 6333137a 合进 main,生产下次部署会撞一模一样的错。 改动: - 20260728020000:14 条改为**普通** CREATE INDEX IF NOT EXISTS(可在事务里跑)。 大表环境靠「部署前手工 CONCURRENTLY 先建」保证不锁表(两台机器 2026-07-28 已建完, 故本迁移在两台上都是 IF NOT EXISTS 空跑);从零建库时表为空,普通 CREATE INDEX 瞬间完成。 文件头补上完整复盘,明写"别再改回 CONCURRENTLY"。 - 20260727070000 / 20260727110000:订正那两处错误归因,改成"因为本文件只有 1 条语句"。 验证: - 把修好的整份文件用 `psql -1 -v ON_ERROR_STOP=1`(显式单事务,正是 Prisma 那种场景) 在测试服跑通,14 条全 skip,无 25001。 - 测试服已 `prisma migrate resolve --rolled-back 20260728020000_...` 解除 P3018 阻塞, 14 条索引仍在(pg_indexes 计数 14),库结构未被破坏。 Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
luoqi committed -
luoqi committed
-
背景:生产此前**完全统计不了 PV/UV** —— 前端无任何分析埋点(gtag/umami/plausible 全无),服务端无 request log,生产 ECS 上更没有 nginx(pac.friday.tech 走独立网关 lb1.friday.tech,访问日志不在我们这台机器上)。Sentry 只有 10% tracing 采样, 做 UV 会系统性偏低。 范围限定在 plan 详情页(切合 plan_event_logs 表名):plan_id / patient_id 本就是 该表的必填列,浏览事件天然填得上,不必为它放宽约束或另立新表。 三种入口按用户口径**全收**:直接进/刷新 · 患者列表 rail 切换 · /plans 落地自动跳转。 (自动跳转确实是系统行为,但业务侧确认要收 —— 它也代表这条 plan 被展示过。)
⭐ 唯一的雷:byHuman 不是"是不是人做的",是**口径开关** HUMAN_TOUCH_EVENTS 靠 filter(byHuman) 派生。view 按字面语义该写 true,但那会让 「客服处理过哪些患者」静默膨胀成"看一眼也算处理"——刚交付的 65 人统计与整张 客服明细 Excel 全部失真,**而且不会有任何编译错误或类型报错**。 故 view 写 byHuman:false,并把该字段注释从"是否人工动作"改写成明确的口径定义; spec 里用**精确相等**(非 arrayContaining)锁死 HUMAN_TOUCH_EVENTS 的四个成员, 以后新增事件必须显式决策要不要计入,改错即红。 改动: - enums: PlanEventType.VIEW + PLAN_EVENT_META 项(group 联合类型扩 'view') - controller: POST /pac/v1/plans/:id/view。**刻意不加认领闸**(区别于 recall-feedback)—— 浏览发生在认领之前,池子里任何一条都能点开;加闸则埋点只剩已认领的,PV/UV 直接废掉。 plan 不存在静默返回 not_found:埋点是旁路,不能因它失败而影响页面。 - 前端: 埋点挂在 use-plan-aggregate 现成的去重守卫里 —— 该守卫原为防 StrictMode 双调, 其语义恰好等于"每进入一次详情页";refresh() 直接调 load() 走不到这里,故手动刷新不重复计。 失败 .catch(()=>{}) 吞掉。 验证(本地起真实前后端 + 浏览器实操): /plans 自动跳转 → 记 1 条 ✓ 手动点刷新 → 仍 1 条(不重复计)✓ 重新进入页面 → 累计 2 条 ✓ 未认领查看 → 能记 ✓ plan 不存在 → not_found 不报错 ✓ 无 token → 401 ✓⭐ 只有 view 事件的患者,在「处理过」口径下计 0(全事件口径会误计 2)✓ 640 tests passed,service/web typecheck 通过。 无 DB 迁移(event 是既有 text 列,加的是取值不是列)。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>luoqi committed -
luoqi committed
-
luoqi committed
-
生产现象:召回池按「禁忌:手术禁忌」圈人,前端等 20+ 秒 GET /pac/v1/plans?view=pool&personaTags=contraindication:surgery 服务端复现:count 23,379ms + findMany 22,208ms(两句并发,墙钟 ≈23s)。 **不是禁忌特有** —— 测试服同口径按 rfm:重要价值 更慢,57s。14 个圈人维度全踩同一个坑, 禁忌只是这次先点到的那个。 根因:Prisma 把画像筛选编译成两层 EXISTS,最内层 persona_features.key = 'contraindication' AND (data #> '{domains}') @> '"surgery"' 而 persona_features 只有单列 key 索引,JSON 那半截没有索引可下推。 生产 EXPLAIN (ANALYZE, BUFFERS) 实测(7,657,944 行 / 5.4GB,堆 3.4GB): Index Scan using persona_features_key_idx actual time=3567..3954ms Index Cond: (key = 'contraindication') Filter: ((data #> '{domains}') @> '"surgery"') rows=2,156 Rows Removed by Filter: 188,054 ← 命中率 1.1% Buffers: shared read=162,830 ← 约 1.3GB 随机堆读 即为了捞 2,156 行,把该维度 190,210 行的 jsonb 全从磁盘搬了一遍。维度越大越惨: rfm / gender / lifecycle_stage 各 869,043 行,一次筛人搬 869k 行 data。 改动:每个可筛维度一条偏索引(WHERE key='<维度>'),表达式与 Prisma 生成的完全一致。 - 数组维度 7 条(array_contains → @>)→ GIN jsonb_path_ops - 标量维度 7 条(equals → =) → btree (表达式, persona_id) 第二列不是为了排序,是为了 index-only scan:内层 EXISTS 只 SELECT persona_id, 索引自带就不回堆。低选择性维度非它不可 —— 测试服实测 rfm 走上 btree 后 Bitmap Index Scan 只花 217ms,回堆 143,187 个块却花了 103s(work_mem 不够还退化成 lossy,Rows Removed by Index Recheck 1,564,553)。 Prisma schema 表达不了表达式/偏索引,只能落迁移 SQL;本地 migrate dev 会把它们报成 drift, 别按提示 reset(同类先例 20260727070000 / 20260727110000)。 persona-tag-filters.ts 加纪律注释:往 PERSONA_TAG_FILTER_DIMS 加维度必须同步补索引, 漏建就是 20 秒起步 —— 这次禁忌踩的正是这个。 上线(两台均已 CONCURRENTLY 手工建完,不锁表,业务无感;迁移全 IF NOT EXISTS 故 deploy 空跑): 生产 14 条 / 88s / 220MB,pg_index 无 invalid contraindication:surgery 23,379ms → 84ms(278×,1,347 单) contraindication:implant 842ms(25,900 单) rfm:important_value 1,558ms(61,300 单) treatment_history:implant_history 854ms(17,179 单) gender:female 2-4s (105,110 单) 测试服 14 条 / 238s / 195MB(盘慢,看倍数) rfm:important_value 57,299ms → 8,576ms contraindication:surgery 4,210ms → 344ms 剩下的耗时性质已经变了:不再是 JSON 过滤,而是结果集本身大(count(*) 要数完十万级 plan)。 gender 这类宽维度哪天嫌慢,方向是给 count 做近似/缓存,不是继续加索引。 Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>luoqi committed -
luoqi committed
-
线上(测试机)现象:FRIDAY 推 med_emr_info 每小时整点重试,连挂 25 次, 对面收到 http 500 body={"code":90000,"msg":"request entity too large"}。 根因两层: 1. main.ts 从未显式设 body limit → 吃 body-parser 出厂默认 100KB。 实测卡点 102,381B 过 / 103,405B 挂,正好 100KiB。 网关 client_max_body_size 是 50M,不是它拦的(对面收到的是 PAC 的 JSON 封装)。 2. body-parser 的 PayloadTooLargeError 是裸 Error(非 HttpException), 掉进过滤器的 500/90000 分支 → 对面按文档 §9.1 把 9xxxx 当"PAC 内部错误 → 退避重试",于是整点重试永远重试不好,也看不出是自己包太大。 为什么病历先踩到:测试机实测 friday 已入库 payload 单行大小 —— emr 均 1453B / 峰值 2218B,diagnosis 均 1647B(带主诉/检查/处置/医嘱自由文本) appointment、encounter 均 405B 接入文档 §10 只约束"≤500 条/请求",没约束字节:500 条病历 ≈ 710KB,超默认值 7 倍; 连 405B 的预约行 500 条(≈198KB)也超 —— 雷对所有表都埋着,病历只是先踩到。 改动: - main.ts: useBodyParser 显式设 10MB(json + urlencoded)。取 10MB 是因为它给 500 条病历留了十几倍余量,又远低于网关 50M —— 不把拦截点推到网关(那层返 HTML 413, 对面更难排查)。rawBody 仍由 create 选项保留,不影响 HMAC 验签。 - all-exceptions.filter.ts: 识别 PayloadTooLargeError(type=entity.too.large, 辅以 413 兜底)→ 归 10002 + HTTP 200,回执带上限与建议批量,且不上报 Sentry (对面发包过大不是 PAC 故障)。口径对齐文档 §9.1「字段校验失败/批量超限 → 修正后重发」。 - channel-push.mdx §10: 补字节上限,并给按表的分批建议(病历 50-100 行 / 结构化 500 行)。 验证(本地起真实服务,真 HMAC 签名): 146B / 300KB / 2MB / 8MB → 全部通过验签进入摄入流水线(证明 rawBody 未被破坏) 11MB → 10002 + HTTP 200,回执可指导动作 636 tests passed,service/web typecheck 通过。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>luoqi committed
-
- 27 Jul, 2026 12 commits
-
-
默认返回提示 JSON(不抛),避免公网裸 500;验收 Sentry 后端捕获用,关 flag 即停。 Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
luoqi committed -
merge: fix/k00-focus-category-and-ortho-mapping → main(K00 诊断词细分 + 低龄种植降位 + 二期正畸误吞 + reparse工具 + 历史联系摘要不判到诊) # Conflicts: # apps/pac-service/prisma/schema.prisma
luoqi committed -
luoqi committed
-
luoqi committed
-
四个提交: 469ef2c9 fix(ai): 历史联系摘要只讲回访事实,不再对到诊/失联下结论 6e7d1f60 feat(reparse): 加 --patients-file(按受影响患者收窄,实测最高 250 倍) 1c537ccb perf(reparse): patient_transactions 补 (host_id, subject_type, patient_id) 复合索引 cdad7db0 fix(plan): K00 按诊断词细分类目 + 低龄种植降位(≤18)+「二期」正畸误吞 + 早矫措辞 两条索引迁移(20260727070000 sync_log_id / 20260727110000 host+subject+patient)用 CONCURRENTLY,部署前先手动建(见各迁移注释),避免 pac-service 等 pac-migrate 白等停机。 # Conflicts: # apps/pac-service/prisma/schema.prisma
luoqi committed -
分支主题(K00 focus category + 正畸映射)的一批年龄/诊断适配。核心是把召回「目标·X」 标签和话术的类目排序,从"只看 K 码 + 年龄"细到"看诊断原文词",纠三类线上误标。 ── ① K00 大口袋按诊断词定方向(refineCategoriesForDiagnosis)── K00「牙发育和萌出障碍」混着语义完全不同的病:乳牙滞留(要拔)/ 乳牙早失(管间隙)/ 先天缺失(修复)/ 釉质发育不全(冠贴面)/ 萌出障碍(导萌),却共用固定序 [surgical,...] → focusCategory 恒为 surgical,给「乳牙早失」也打「目标·外科」(没牙可拔)。线上约 2800 条。 诊断码不动(还是 K00),只在同码内把最贴切类目提到首位。scenario 投影 name_zh、 signals 存 dxNameZh 快照,前端 ReasonLine 用同一函数复算,保证「目标·X」与本行首项一致。 ── ② 低龄种植降位,边界与全仓另三处种植年龄闸统一为 ≤18 ── recommendedCategoriesForAge 新增:age ≤ IMPLANT_LAST_AGE(18)时 implant 挪末位(只挪不删)。
⭐ 边界取 ≤18 而非 <18 —— 差一岁会自相矛盾:contraindication.feature.ts 是 age<=18 打 「种植禁忌」、potential-treatment 是 age>18 才产「潜在种植」。2026-07-27 生产实测: 恰好 18 岁有 1,299 条 plan、140 条 focusCategory=implant,若按 <18 判会在同一屏出现 「目标·种植」+ 画像「种植禁忌」。话术侧(fact-block / stable prompt)同步 ≤18。 ── ③ planned 规则裸「二期」不再误吞正畸 ── 「正畸二期矫治」被 implant 规则的裸「二期」吞成种植(线上 陈芃霖 BJ0A094257)。 actual 侧的修法是收紧成「种植二期」,但 planned 侧种植二期普遍不带"种植" (二期取模/二期手术/二期修复,prod 900+ 条),收紧会让它们掉进 _default 被丢。 改用位次:裸「二期」从 implant 主规则拆出、降到全表最末兜底 —— 带正畸词的先被 orthodontic 收走,其余纯「二期」仍落 implant,与修复前逐条一致。 ── ④ 替牙期正畸措辞说「早期矫治」── treatmentCategoryNameZhFor:age ≤ EARLY_ORTHO_MAX_AGE(12)时 orthodontic 显示「早期矫治」 (替牙期做的是一期干预,不是排齐恒牙列)。只改措辞不改类目,排除闸不受影响。 reason-signals schema 补 dxNameZh(nullable,旧 plan 无 → 回落原顺序,无回归)。 删 tests/tmp-jieya.spec.ts(纯 console.log 探针,无断言,不进仓库)。 测试 546 passed,两个 app tsc 干净。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>luoqi committed -
reparse 分批取源行那句: SELECT id, raw_payload, payload_hash FROM patient_transactions WHERE host_id = $1 AND subject_type IN ('emr','diagnosis') AND patient_id IN (3000 个) 没这条索引时 planner 只能走 (patient_id, occurred_at),把这 3000 个患者的**全部** transaction 连 raw_payload 一起捞进堆,再在堆上过滤 host_id / subject_type。 2026-07-27 测试服 EXPLAIN ANALYZE 实测(12,519,060 行 / 33GB): Bitmap Heap Scan 10,385 ms rows=14,578,Rows Removed by Filter: 39,305 ← 读进来 73% 是白读 Buffers: read=15,616(约 122MB 磁盘读) 全量 87 批,单这一句约占 15 分钟。本地建索引后 planner 已改走 Index Scan using patient_transactions_host_id_subject_type_patient_id_idx。⚠ ️ 收益如实说:每批总耗时 76–180s,这句只占 6–14%,对全程约 4%,**不是提速主手段**。 reparse 真正的杠杆是上一个提交的 --patients-file(按受影响患者收窄,实测最高 250 倍)。 本索引胜在一次性代价、之后每次 reparse / 每个 host 都受益。 体积:(uuid,text,uuid) × 千万行,测试服估 ~600MB、生产(2407 万行 / 64GB)估 ~1.2GB。 测试服建前 24G 空闲够用;生产上线前需先确认磁盘余量。 上线方式同 20260727070000:CONCURRENTLY(不锁写),推荐部署前手动先建 —— deploy 时 pac-service 要等 pac-migrate 退出才启动,几分钟索引构建 = 白等的停机; 手动建好后本迁移 IF NOT EXISTS 空跑。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>luoqi committed -
全量 reparse 的时间几乎全花在"证明没变"上。2026-07-27 测试服实测: 全量范围 260,434 患者 / 87 批 / ~4.5 小时 改 clinical-signals 字典 → 真正受影响 ~40,000 患者(15%) → 6.5 倍 改 planned「二期」规则 → 真正受影响 1,017 患者(0.4%) → 250 倍(2 分钟) 已有 --patient=<uuid>,... 但几千个 uuid 塞不进命令行(ARG_MAX),缺的就是文件入口。 用法:先用 SQL 圈出受影响患者,dump 成一行一个 id,再喂进来。 psql -tAc "SELECT DISTINCT patient_id FROM patient_facts WHERE type='treatment_record' AND kind='planned' AND content->>'subtype' LIKE '%二期%'" > /tmp/ids.txt pnpm reparse -- --host=jvs-dw --subject-type=treatment --patients-file=/tmp/ids.txt 文件格式刻意宽容(操作者多半是 psql 直接倒出来的):uuid 与 externalId 混写、 # 整行/行尾注释、空行、行尾逗号分号、CRLF 全收;但不做猜测性纠错 —— 认不出的 原样送去库里查,查不到就 WARN 报出前 5 个,不静默丢(否则"为什么少跑了几百人"是无头案)。⭐ 空结果必须硬失败,这是本次最要紧的一条: 服务侧 `if (!scopePatientIds?.length)` 把空数组当"不限定" —— 一个路径写错的收窄命令会静默变成 4.5 小时全量,且日志上完全看不出异常。 现在解析为 0 / 一个都对不上库,都直接报错退出。 ── 顺带修一个我自己踩出来的隐患 ── CLI 末尾是 `void main()`(全仓 CLI 通例),我最初把纯函数留在 CLI 里、测试直接 import, 结果测试跑起来对本地库真跑了一次 reparse(115 行 Nest 日志)。两道修: ① 纯函数拆到 src/cli/reparse-patients-file.ts,测试只碰这里 ② CLI 末尾加 `if (require.main === module)` 闸 —— 以后任何 import 都不会再误启动 实测(本地 friday): 空文件 → reparse 失败:解析后为 0 个患者(拒绝退化成全量) 混写清单 → 读到 4 token(uuid 1 / externalId 3 → 认领 2),WARN 1 个查不到, 最终限定 3 患者,ColdImportService 确认「范围 3 患者」 测试 547 passed(新增 13 例)。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>luoqi committed -
生产实例(陈芃霖 BJ0A094257): 摘要「上次**有效到诊**为2023年8月,已超一年未复诊」 实际 接诊记录末次 2025-12-20,画像也写着「末诊207天」—— 差 2 年 4 个月 同句另两处错:「已超一年未复诊」实为 7 个月;「近3个月涂氟邀约」那条回访实为 226 天前。 源头是这条回访记录: 2023-08-15 | 常规回访 | 已回访 | 已完成 | 内容:复查 | 结果:8月已就诊 诊所客服 2023 年写的一句备注,被模型升格成了患者当前的到诊状态。「有效到诊」这个词 源数据里没有,是模型自己造的。 ── 根因 ── 本 AiCall 的输入**只有回访记录,没有任何到诊数据**(见 input.types)。模型只能: ① 从回访备注文字里猜到诊 —— 「8月已就诊」被当成事实 ② 用"没有回访记录"推"没来过" —— 但回访是诊所主动打电话,患者自己来院不产生回访任务 两条路都错。而旧 prompt 不但没拦,关键要求 4 明写「优先突出…长期未到诊」, 示例里还有「此前半年 5 次回访无到诊」在**示范这个错法**。 ── 生产规模 ── 795 条 recall_history 摘要,162 条断言"失联/沉睡/未到诊", 其中 88 条(54%)患者实际 180 天内来过,18 条 90 天内来过。 最离谱一条:「自2018年至今无到诊或有效联系,属长期失联状态,建议优先核实联系方式」 —— 该患者 2026-06-24 刚到诊,上个月的事。客服照这个打电话会很尴尬。 ── 改法(按业务口径「这里只摘要回访事实」)── 不给它喂到诊数据,而是划清职责:到诊状态有专门的地方出(画像卡「末诊 N 天」按真实接诊算)。 1) prompt 加【职责边界】硬约束:输入里没有到诊数据,禁止判断是否到诊/失联/沉睡; 结果字段里的"已就诊"只能当那次回访的记录引述,不得当成到诊状态; 明确掐断"没有回访 ≠ 没来过"这条推理链 2) 修掉关键要求 4 和示例里示范错法的句子,新增反例段(把三条真实事故句列为 ✗) 3) 补程序算好的 daysAgo —— 相对时间不让模型自己减日期 4) 版本 @2026-07-26-f → @2026-07-27-g ── 这是同一个错误第三次以不同形式出现 ── 07-24 是"未来 vs 过去"(未来排程被说成漏做),今天是"回访 vs 到诊"和"距今多久"。 当初立的纪律是「能程序算的事实全算好、LLM 只润色」,但只补了一个轴, 于是同类错误换个轴又来。本次把职责边界和 daysAgo 都用测试锁住(新增 8 例)。 注:已生成的 795 条摘要是缓存,需另行重刷才会用新 prompt; 本次先删了陈芃霖那一条供业务观察重新生成效果。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>luoqi committed -
FRIDAY 对接增量 push 报 `SocketTimeoutException: Read timed out`,今天在测试服 按他们的路径(公网域名 + HMAC)模拟推 2 行患者主档定位到: 单次请求 74s,74s **全部**耗在这一条 SQL 上 (逐 6s 采 pg_stat_activity,同一条查询年龄从 6s 一路涨到 74s): SELECT id, patient_id, tenant_id FROM patient_transactions WHERE sync_log_id = $1 AND patient_id IS NOT NULL 来源 cold-import.service.ts `touchedRows`(push / cold-import / 增量共用这条路径)。 EXPLAIN:Parallel Seq Scan (cost=0.00..2150645.78) 外键约束不会自动建索引,这句从上线起就在全表扫: 测试服 patient_transactions 12,519,060 行 / 33 GB 生产 同表 24,074,031 行 / 64 GB ← 生产更慢,FRIDAY 真上生产会更糟 本地建索引后 plan 变 Index Scan(cost=0.29..4.31)。 ── 顺带更正一处仓库里的错误注释 ── 20260701060607 那份迁移写着「CONCURRENTLY 不能跑在事务里,Prisma migrate 对整份 migration.sql 有事务包裹,故不能靠 migrate deploy 直接跑」。**当前 Prisma 6.19 已不成立** —— 本地实测 migrate deploy 直接把 CONCURRENTLY 跑通、索引建出、plan 生效。 新迁移里写清了真实情况,并保留「推荐手动先建」的建议,但理由改成正确的那个: deploy 时 pac-service 要等 pac-migrate 退出才启动,33/64GB 建索引几分钟 = 白等的停机。 push 侧本身是好的:同一次模拟 accepted=2 / failed=0 / mappingMisses=0, canonical 映射(externalId/name/gender/birthDate/medicalRecordNumber/phone)全对。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>luoqi committed -
四个 commit: 99e01d42 禁忌能力落地 —— 摄入层抽 clinical_signals 写回源 fact,画像层裁决 51581f58 筛选改按治疗域四类;风险位露出真实原因 f85b7680 画像依据行改显命中信号,不再露 encounter 内部 ID 1171fb42 核查项不进画像;风险区先隐藏;挂号/接诊/接待依据行同样去 ID 上线还需两步(缺第二步则 7 万年龄型禁忌筛不到 —— 本地已实测): 1) pnpm reparse -- --host=jvs-dw --subject-type=emr,diagnosis 2) pnpm recompute-persona -- --host=jvs-dw --concurrency=8 --force (--force 必须带:水位闸只认'事实变了',本次变的是特征输出结构, 本地实测不带 --force 会被 noop 掉 13260/13268) 召回闸门未接,按预留处理。
luoqi committed
-
