在 GitHub 查看原文

L04 练习

改 code.py 或 research_assistant/proactivity.py，运行观察变化。零联网、零等待。

练习 1：把「信任账户」算成数字（理解类）

假设用户的行为模型：连续收到 3 次「不值得」的打扰后，会把通知静音 7 天；静音期间 major 也看不到。

1. 用 Part 3 的三政策数字外推 30 天（假设每 5 天重复一次时间线的分布：1 major / 2 minor / 1 none / 1 故障）。
2. 算 all 政策下：第几天触发静音？30 天里有几个 major 因静音被错过？
3. 对比 threshold：30 天打扰几次？触发静音吗？

验收：两个政策的「错过 major 数」对比——你会发现 all 政策的零漏报是假的：它把漏报推迟到了用户静音之后，且一漏就是连续 7 天。

练习 2：设计实验——判级器的一致性（设计实验类）

LLM 判级是不确定的：同一份简报判三次可能得两个级别。

1. 假设：温度>0 时判级有抖动；抖动主要发生在 minor/none 边界（major 特征明显，较稳定）。
2. 实验设计（有 API key 可做真实版，没有可用「随机翻转 mock」模拟）： - 对 Day2/Day3/Day4 三份简报各判 10 次，统计每份的级别分布。 - 计算「多数票级别」与「单次判级」的不一致率。
3. 预期：Day4（✏️ 反转）10/10 major；Day3 可能 7 minor / 3 none 抖动。
4. 思考：抖动的工程解法按成本排序——降温度（免费）、多数票（3 倍成本）、往上兜（判不稳时取更高级别，宁扰勿漏？还是宁攒勿丢？）。你的场景选哪个，为什么？

验收：抖动率数字 + 一个带理由的工程选择。

练习 3：反转降级方向（取舍类）

本课「宁攒勿丢」把解析失败降到 minor。现在换场景：你盯的是生产服务的安全公告（CVE 通报），晚 6 小时看到的代价可能是被打穿。

1. 改 classify_change：加一个 fail_direction 参数（"digest" | "notify"），解析失败时按方向降级。
2. 写一个测试：fail_direction="notify" 时，解析失败返回 major + degraded。
3. 思考：这个参数属于「判级器配置」还是「每个调度各自的属性」？（提示：同一个 daemon 可能同时盯资讯主题和安全公告——降级方向应该跟着调度/主题走，落在 schedules 表还是 config 全局？）

验收：测试绿 + 一句话回答参数归属（配置层级判断是生产系统的常见考点）。

练习 4：思考题——为什么配额记账不放进判级 prompt（架构类）

一个诱人的偷懒设计：把「今天已打扰 2 次、配额还剩 0」写进判级 prompt，让 LLM 自己决定要不要降级。

1. 思考：这违反了本课哪条核心认知？（判断交给模型，纪律交给代码。）
2. 思考：具体会坏在哪？至少找三处。（提示：① LLM 可能「求情」——觉得特别重要就无视配额；② 配额执行变成不可测试的概率行为；③ 审计断了——quota_exhausted 再也不是可靠字段，日报没法回答「今天漏了几条 major」。）
3. 反方向思考：那判级 prompt 里该不该告诉 LLM「用户今天已经被打扰过 2 次」？（这不是纪律执行，是判级上下文——「今天已经扰过两次，这条 minor 就更不值得升格」是合理的判断依据。界线在哪：信息可以进 prompt，执法权不能。）

验收：用「信息可进 prompt，执法权不能」造一个你自己领域的例子（如代码审查 Agent、客服 Agent）。