构建带所有权与淘汰机制的反馈棘轮
交付关闭一次构建循环，也打开学习循环。证据必须改变系统，否则它只是无人负责的遥测。
类型： Learn + Build 语言： Python（标准库） 前置要求： 阶段 14 第 46 和 53 课 预计时间： ~75 分钟
学习目标
- 将事故、评估、用户行为和纠正转为有人负责的行动。
- 将每个信号路由到上下文、评估、策略、运行时或待办列表。
- 按严重性和频率确定复发优先级。
- 给每项控制一个淘汰条件。
反馈是基础设施
团队可以收集追踪、评估、支持工单和事故日志，却没有从任何一项中学习。缺失的机制是提升：从观察到带负责人和证明的持久变更，要有明确路径。
循环是：
- 观察一个具体信号；
- 把它关联到结果、约束或假设；
- 找出拥有原因的最早系统层；
- 创建有界改动；
- 验证复发变得更不可能；
- 复审控制是否应继续保留。
路由到拥有的层
| 信号 | 归宿 |
|---|---|
| 误报、回归、错误结果 | 评估或测试 |
| 缺少上下文、重复工作、过时事实 | 上下文源或检索路径 |
| 不安全动作或权限缺口 | 策略或权限边界 |
| 超时、重试风暴、不可用依赖 | 运行时控制 |
| 新产品需求或未解决的取舍 | 已塑造的待办项 |
在最早的有效层修复原因。不要在测试或权限能让失败不可能时，再添一段 prompt。
mermaid
flowchart LR
S[信号] --> O[结果或约束]
O --> R[根因]
R --> D[负责层]
D --> C[持久控制措施]
C --> V[验证]
V --> N[下一轮]
N --> S所有权是控制的一部分
每项棘轮行动都需要：
- 一位负责人；
- 基于后果和复发的优先级；
- 要改的产物；
- 证明改动的验证；
- 复审或到期窗口；
- 淘汰条件。
无人负责的改进，不过是格式更好的观察。
淘汰过时控制
反馈系统会积累策略，而这些策略会变得矛盾且昂贵。出现以下情况时复审控制：
- 架构或工作流改变；
- 低层不变量取代高层说明；
- 在选定窗口中，受保护的失败没有出现；
- 控制阻碍合法工作的频率超过它防止伤害的频率。
淘汰也需要证据。不要只因感觉旧了就删除控制。
连接构建与编码 agent 反馈
同一棘轮服务两条路径：
- 产品证据改变结果框架、假设、切片或测量计划。
- 编码 agent 纠正改变测试、上下文、范围、自动化或交接。
- 事故能同时改变产品边界和 agent 工作台。
这就是为什么塑造构建不是编码前结束的阶段，它会延续到每次被接受的改动中。
动手构建
实验对信号分类，创建有负责人的棘轮行动，对其排序，并写入 outputs/feedback-backlog.json。
bash
python3 code/main.py
PYTHONPATH=code python3 -m unittest discover code/tests -v加入一个运行时超时信号，确认它被路由到运行时，而不是通用待办列表。
练习
- 将一起事故和一条用户投诉转为棘轮行动。
- 为每次复发写出能预防它的最早层。
- 向实验输出加入验证命令或观察。
- 为一条策略规则定义淘汰条件。
- 将一次被接受的纠正追溯回下一个任务框架。
延伸阅读
- Basili, Caldiera, and Rombach, The Goal Question Metric Approach，了解通过目标导向测量实现组织学习。
- Fagerholm et al., Building Blocks for Continuous Experimentation，了解将证据连到持续产品开发的技术与组织循环。
- Nuseibeh and Easterbrook, Requirements Engineering: A Roadmap，了解如何将需求视为在系统生命周期中演进。
拿去用
保留 outputs/feedback-backlog.json。它是产品判断与交付路径的收尾产物，也是下一个结果框架的输入。