plan.service.ts
39.7 KB
-
feat(plan): 「机会识别不准确」补必填多选 —— 哪几类推荐治疗不准(仅统计) · e4ace755
落表:plan_executions 加一列 inaccurate_treatments TEXT[] NOT NULL DEFAULT '{}'。 · **加列不建表**:它是 abandon_reasons 里 'inaccurate' 那项的限定词,不是独立事实 —— 同一次提交、同一条 execution、基数 ≤8。单独建表只多一次 join。 · **存 code 不存中文**:这列唯一价值是可统计(哪类召回最容易被判不准 → 回去改规则)。 中文措辞两天内改过三轮(潜在种植→种植治疗→种植),存中文等于把当时措辞烤进历史数据。 (同类教训:原 abandon_other 自由文本列就是因为"只能取到字面量、统计不了"被删的。) · **不塞 notes**:自由文本统计不了,正好废掉这个字段的唯一价值。⚠ ️ 按业务口径明确两条,都写进 schema 注释免得后来人误解: ① **不参与抑制**。抑制仍是信号级、按 plan 全部 reason 一起压 —— 客服选"只有种植不准" 不会只放过根管那条。看到这列别以为闸接上了。 ② **跟「其他原因」不构成关联**。只在勾了 inaccurate 时收集/落库;后端落库时再判一次, 免得前端残留勾选污染统计口径。 必填校验前后端各一道。服务端那道不是冗余:这条反馈事后补不回来(没人会为已结案的单再来一遍), 收进来一批空的就等于白填。 候选项 = 本患者画像 potential_treatment.types(同召回池卡片那排标签的来源),所以每人不同; 中文在前端查 POTENTIAL_TREATMENT_CARD_LABEL(改措辞即时生效)。 患者没有潜在治疗标签时不卡必填 —— 理论上不该发生,真遇到宁可放行,不让客服卡在填不了的必填项上。 708 tests / 46 suites + 两端 typecheck 通过。 Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>luoqi committed