观察票：drive-tick/私聊即刻追问的门控结果按渐进解锁档位打点（不改行为） #140

New issue

Closed

opened 2026-08-14 08:29:13 +00:00 by KumaAgent · 0 comments

KumaAgent commented

2026-08-14 08:29:13 +00:00

Member

Parent

#133 最新评论（评估侧 2026-08-14 评估后拍板：先打点，不直接补门槛）

What to build

issue #112 论证"渐进解锁连续缩放不该叠加进 gate_threshold_base"时，level1_threshold 的消费者只有
事件触发（天然免疫）与 tier-2（已有独立解锁门槛 is_relationship_network_unlocked）——issue #133 让
drive-tick/私聊即刻追问也成了真实消费者后，这条论证的前提不再完全成立，但尚无真实数据支撑"要不要
补一道类似 tier-2 的独立解锁门槛"这个产品判断。

本票不做任何裁决行为改动，只把判断需要的数据存下来：给决策快照补一个字段，让"这次门控评估发生
时，该 chat 处于渐进解锁的哪个档位"变得可查询——积累足够样本后，能够回答"冷启动期 drive-tick/即刻
追问候选的 level1 通过率、以及最终 hit-rate（#133 已接入的反思闭环样本），相对非冷启动期是否有显著
差异"，用真实分布而不是理论判断决定后续要不要开票补门槛。

Acceptance criteria

一、决策快照补 unlock_level 字段（纯打点，不改裁决）

GateEvaluation（gating.py）、GateSnapshot（decision_snapshot.py:42）、gate_snapshot_of()
（decision_snapshot.py:60）三处加 unlock_level: float 字段（GateEvaluation 自己的 docstring
已经点名这个机械改动清单："加字段要改三处（本类 + GateSnapshot + 搬运函数），再加
DecisionSnapshotModel 的列与两个行映射"）
DecisionSnapshotModel（storage.py:525）加对应列，两处行映射（写入/读出）同步
记的是这次评估实际使用的 unlock_level（_evaluate_unified_gate 内部算出的那个值，
gate_pipeline.py:197 附近），不是重新算一次——同 affective_state"门控当时看的那一份"既有原则
（issue #79 教训，见 entry_drive_tick.py 注释"情感态用门控当时看的那一份，不在这里重新读一次"）

二、顺手收敛一处重复计算（同一次评估里 unlock_level 被算两次）

_evaluate_drive_tick_chat（entry_drive_tick.py）调 _evaluate_unified_gate 时没有传
unlock_level=，导致该函数内部自己算一次；而 _evaluate_drive_tick_chat 自己在后面（渐进解锁
档位供自发目标/熟人重连提示用那段）又独立算了一次——两次输入相同、结果必然相同，属于纯浪费的
重复 DB 读。上提第二次计算到 _evaluate_unified_gate 调用之前，把结果通过既有的 unlock_level=
覆盖参数传进去（_evaluate_unified_gate 本来就支持这个覆盖，entry_reactive._debounced_flush
已经这么用了，见 gate_pipeline.py 该参数文档："调用方已经算好就别再读一次"）。这不是本票的主线，
但既然要碰 unlock_level 在这条路径上的传递，顺手做掉比留着不管更省事。

三、不做的事

不新建任何门槛机制（不碰 progressive_unlock_scale/gate_threshold_base 的现有裁决逻辑）
不产出任何分析/报表——本票只保证数据存在，"冷启动期 hit-rate 是否显著更差"这个分析本身
留给看到足够样本后的人工判断（或后续独立票），不在本票范围
全量测试通过，不新增/不改写任何既有裁决类断言——本票只加一个只读维度的存档字段

Not in scope

是否要给 drive-tick/私聊即刻追问补独立解锁门槛（评估侧已判断这是待真实数据支撑的产品决策，本票
只负责让数据存在，不是那个决策本身）
ADR-0011/0014 更新节的补录（评估侧已处理，见 project_arise_adr_audit_batch 记忆，commit
6fe7af8 待合并进共享 docs 分支）

## Parent #133 最新评论（评估侧 2026-08-14 评估后拍板：先打点，不直接补门槛） ## What to build issue #112 论证"渐进解锁连续缩放不该叠加进 `gate_threshold_base`"时，`level1_threshold` 的消费者只有事件触发（天然免疫）与 tier-2（已有独立解锁门槛 `is_relationship_network_unlocked`）——issue #133 让 drive-tick/私聊即刻追问也成了真实消费者后，这条论证的前提不再完全成立，但**尚无真实数据**支撑"要不要补一道类似 tier-2 的独立解锁门槛"这个产品判断。 **本票不做任何裁决行为改动，只把判断需要的数据存下来**：给决策快照补一个字段，让"这次门控评估发生时，该 chat 处于渐进解锁的哪个档位"变得可查询——积累足够样本后，能够回答"冷启动期 drive-tick/即刻追问候选的 level1 通过率、以及最终 hit-rate（#133 已接入的反思闭环样本），相对非冷启动期是否有显著差异"，用真实分布而不是理论判断决定后续要不要开票补门槛。 ## Acceptance criteria **一、决策快照补 `unlock_level` 字段（纯打点，不改裁决）** - [ ] `GateEvaluation`（`gating.py`）、`GateSnapshot`（`decision_snapshot.py:42`）、`gate_snapshot_of()` （`decision_snapshot.py:60`）三处加 `unlock_level: float` 字段（`GateEvaluation` 自己的 docstring 已经点名这个机械改动清单："加字段要改三处（本类 + `GateSnapshot` + 搬运函数），再加 `DecisionSnapshotModel` 的列与两个行映射"） - [ ] `DecisionSnapshotModel`（`storage.py:525`）加对应列，两处行映射（写入/读出）同步 - [ ] 记的是**这次评估实际使用的** `unlock_level`（`_evaluate_unified_gate` 内部算出的那个值， `gate_pipeline.py:197` 附近），不是重新算一次——同 `affective_state`"门控当时看的那一份"既有原则（issue #79 教训，见 `entry_drive_tick.py` 注释"情感态用门控当时看的那一份，不在这里重新读一次"） **二、顺手收敛一处重复计算（同一次评估里 `unlock_level` 被算两次）** - [ ] `_evaluate_drive_tick_chat`（`entry_drive_tick.py`）调 `_evaluate_unified_gate` 时没有传 `unlock_level=`，导致该函数内部自己算一次；而 `_evaluate_drive_tick_chat` 自己在**后面**（渐进解锁档位供自发目标/熟人重连提示用那段）又独立算了一次——两次输入相同、结果必然相同，属于纯浪费的重复 DB 读。**上提第二次计算到 `_evaluate_unified_gate` 调用之前，把结果通过既有的 `unlock_level=` 覆盖参数传进去**（`_evaluate_unified_gate` 本来就支持这个覆盖，`entry_reactive._debounced_flush` 已经这么用了，见 `gate_pipeline.py` 该参数文档："调用方已经算好就别再读一次"）。这不是本票的主线，但既然要碰 `unlock_level` 在这条路径上的传递，顺手做掉比留着不管更省事。 **三、不做的事** - [ ] **不新建任何门槛机制**（不碰 `progressive_unlock_scale`/`gate_threshold_base` 的现有裁决逻辑） - [ ] **不产出任何分析/报表**——本票只保证数据存在，"冷启动期 hit-rate 是否显著更差"这个分析本身留给看到足够样本后的人工判断（或后续独立票），不在本票范围 - [ ] 全量测试通过，不新增/不改写任何既有裁决类断言——本票只加一个只读维度的存档字段 ## Not in scope - 是否要给 drive-tick/私聊即刻追问补独立解锁门槛（评估侧已判断这是待真实数据支撑的产品决策，本票只负责让数据存在，不是那个决策本身） - ADR-0011/0014 更新节的补录（评估侧已处理，见 [[project_arise_adr_audit_batch]] 记忆，commit `6fe7af8` 待合并进共享 `docs` 分支）

KumaAgent added the

状态：智能体就绪

label

2026-08-14 08:29:49 +00:00

KumaAgent referenced this issue

2026-08-14 08:30:11 +00:00

反思闭环样本补全：周期触发级一打分+群聊追问结局登记 #133

KumaAgent referenced this issue from a pull request that will close it,

2026-08-17 07:41:34 +00:00

决策快照补unlock_level打点，收敛drive-tick重复计算（issue #140） #147