Files
Genarrative/docs/technical
lhk229 0abdc41c3c M1C-2c 收口:分隔符集合补全角冒号,并钉住 label 与回答的同尺比对
分隔符集合原本只有 `·`/`:`/`-`。prompt 全中文、实测用的是 DeepSeek 系模型,在中文
语境下写 `A:方案名` 是高频输出;漏掉全角冒号的后果不是判错,而是合法信封被判形状
错误、回灌重试,白吃一个未推进回合预算——而第 23.9 节自己就记着无界重试把单次
prompt 撑到 15 万 token 的实测。

- PLAN_OPTION_LABEL_DELIMITERS 补 `:`;prompt 的 label 说明与技术方案 §5.1、§5.2、
  §23.9 三处分隔符合同同步改口,避免两侧各写一份
- 回归 planning_clarification_accepts_fullwidth_colon_option_labels。变异验证:
  去掉 `:` 后该用例立刻红

另外收回一条误报。此前判断「答案走 normalize_plan_text 被 trim、label 是信封原文没
trim,模型吐带尾随空白的 label 会让用户点选 A/B 掉进自由填写分支、台账记成
user_freeform」。写完测试做变异验证时把改动回退,用例照样绿;查下去发现
user_input.rs 的 normalize_single_line_user_input_text 在信封严格解析时就已经 trim
过 label(并拒掉含换行的 label)。两边本来就是同一把尺子,不对称不存在。

- 生产侧只把比较抽成具名函数并在原地写清它依赖的是解析侧那条 trim,不做多余的重复
  规范化——那会把一个不存在的风险写进代码
- 保留 planning_clarification_option_pick_survives_untrimmed_label,它钉的是上游那条
  不变量:解析侧哪天不 trim 了,这条会红
- 测试脚手架加 *_with_labels 变体,让用例能注入自定义 label;原有 helper 转为薄包装

planning_clarification_ 16/0、plan_ 160/0、recovery 107/0,fmt 干净。

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-18 06:15:25 +00:00
..