反馈闭环与团队学习

决定一个团队把 AI 用得好不好的，往往不是模型选得对不对，而是他们多快能发现自己选错了。这条讲的循环和《评估闭环》形状相同、对象不同：那一条被评的是系统的输出，这一条被评的是团队自己的产出节奏。

学习速度是可以被设计的，不是天赋

它由三个时间决定：一次改动多久能到用户面前、多久能拿回反馈、拿到之后多久能改回来。三个都缩短，团队就学得快——这与团队是否聪明无关，只与循环长度有关。反过来，一个每季度才发一次的流程，无论多认真，一年也只有四次学习机会。

小而可见，胜过大而模糊

GitHub 重写 Copilot 代码审查那次是最好的例子：他们换上了维护更好的共享 CLI 工具，基准反而更差——审查成本更高、抓到的问题更少。真正翻转局面的是把「审查者实际怎么读一个 PR」写进指令，成本降约 20%、质量不变。

值得学的不是「指令比工具重要」这个结论，而是他们能够分辨出是哪一个改动起了作用。一次只动一件事、每次都量，才可能得到这种因果结论；把两件事一起上线，你能拿到的只有一句含糊的「好像变好了」。

失败必须留下可检索的理由

Ai2 的 Shippy 复盘交付的是四条工程经验加三件开源工件——它把一次内部尝试变成了别人可以复用的东西，而不是一个只有当事人记得的教训。

反面更常见：一次被否掉的试点如果没有写下「为什么不做」，六个月后同一个想法会被原样重提，而且没有人记得上次为什么否掉。这是团队学习最容易漏掉的一处，因为它不像故障那样会自己冒出来提醒你。

三种让团队学不动的情况

• 反馈太慢。 改动和结果之间隔得太久，因果已经无法归因，于是每次讨论都退回到各说各的经验。
• 只在出事时复盘。 于是「为什么这次成了」永远没人写，成功变成运气，无法被复制。
• 学习没有归属。 和评估闭环断在同一个地方：没有人负责把这次学到的东西变成下一次的默认做法。

与相邻条目的分工

《评估闭环》评的是系统的输出，这一条评的是团队的节奏；判断任务里某一步做完没有是《完成判定与验收信号》；某个决定值不值得占用一个人，是《人在回路的审查》；而在动手之前把范围框好、让一次尝试能便宜地失败，是技能《AI 试点范围界定》——那是这条概念在项目起点处的具体做法。