反馈飞轮
原文：Feedback Flywheel 作者：Rahul Garg (Thoughtworks) 日期：2026-04-08 翻译方式：baoyu-translate skill (refined mode)
团队一直都有集体学习的机制：回顾会议、事故复盘、午间分享。这些机制中最有效的，都有一个共同特征：它们能把个人经验转化为团队共有的实践。一个人在调试过程中或生产事故中遇到的问题，会变成整个团队的知识。这些知识从个人头脑中释放出来，进入团队的基础设施——Wiki、运维手册（Runbook）、代码评审检查清单。
对于 AI 编码助手，大多数团队都会遇到一个瓶颈期。他们采用了工具，建立了一定的使用熟练度，然后就停在那里了。月复一月，同样的提示词习惯，同样的挫败感，同样的结果。这不是因为工具不再进步，而是因为团队围绕工具的实践不再进步。缺少一个让有效做法持续积累的机制。每个开发者都在积累个人直觉——好用的措辞、高效的工作流、对 AI 擅长什么和不擅长什么的深刻理解——但这些直觉始终停留在个人层面，无法传递。
我在之前的文章中描述的基础设施——知识预装（Knowledge Priming）、设计先行协作（Design-First Collaboration）、上下文锚定（Context Anchoring）和编码团队标准（Encoding Team Standards）——并不是一组静态的制品。它们是能够吸收学习成果的载体。缺失的那一环，是将学习成果回馈其中的实践：一个反馈循环（Feedback Loop），让每一次交互都成为改进下一次交互的机会。
复利问题
我的观察是，在差不多同一时间采用 AI 工具的团队，六个月后可能走到截然不同的位置。这种差异往往不在于人才或工具，而在于团队是否有一种捕获有效做法的实践。
如果没有学习系统，AI 的效能就会停滞不前。团队在使用工具，工具也确实有用。但团队使用工具的方式没有在进化。预装文档（Priming Document）中相同的空白导致相同的修正。同样模糊的指令产出同样平庸的输出。同样的失败模式反复出现，却没有人把它们串联起来。缺的不是努力——而是一个让努力得以积累的机制。
这些制品创造了学习的载体。但载体本身是被动的。当 AI 默认使用了一个已弃用的 API 时，预装文档不会自己更新。当一类 Bug 悄然通过时，Review 指令不会自己添加新的检查项。它们需要一种主动的实践，把学习成果反馈回去。
来看一个反馈循环运转起来后，单次会话（Session）可能是什么样子。一位开发者使用生成指令来实现一个新的服务端点。然后，一条 Review 指令对输出进行检查——发现缺少了授权检查，而这恰恰是生成指令中没有明确要求的那类疏漏。开发者修复了这个问题，并在关闭会话之前，往团队的学习日志中添加了一行：新端点的授权检查未被生成指令强制执行。 这个文件存放在代码仓库中，已经是后续会话预装上下文的一部分。下一个实现端点的开发者无需知道这次交互的发生，就能从中受益——授权检查现在已经成为 AI 首次生成时就会验证的内容。生成指令没有变。预装上下文变了。系统学会了。这就是飞轮（Flywheel）：循环的每一次转动，都让基础设施为下一次运转做好更充分的准备。
指令会进化：当一条 Review 指令遗漏了某些问题，它就是一条等待被更新的指令。同样的原则适用于团队 AI 基础设施中的每一个制品：每个制品都应该基于团队在实践中的观察而不断进化。问题在于，如何让这种进化变得系统化，而非偶然发生。
更新本身可以通过不同方式进行。有时候开发者会直接编辑共享制品，尤其是当改动需要判断力或精确措辞的时候。在另一些场景下，智能体可以在工作流中起草或应用更新，由开发者审核后再将其纳入团队的共享上下文。我不会把某一种机制定为强制要求。真正重要的是：学习成果被捕获、被验证、并反馈到团队实际使用的制品中。
四种信号
AI 交互会产生信号（Signal）：关于团队的制品哪些部分捕获得好、哪些部分存在遗漏的信息。我发现将这些信号分为四类很有用，每一类都映射到基础设施中的特定位置。
上下文信号。 AI 需要但不知道的信息：预装文档中的空白、缺失的约定、过时的版本号。开发者每次做出的修正，都是一个信号，说明预装文档不完整。当 AI 持续使用已弃用的 Prisma 4.x API 时，这不是模型的错误，而是预装的缺口。版本说明缺失了，所以 AI 回退到了训练数据。每一句”不，我们是这样做的”，都是一行本应写在预装文档中、但还没写进去的内容。
指令信号。 产生了显著好或差结果的提示词和措辞方式。当某种特定的请求表述方式持续产出更好的结果——某个阻止 AI 跳步的特定约束、某种能产生更清晰架构的分解方式——这种措辞就应该被放进共享指令中，而不是留在某个开发者的脑子里。指令信号（Instruction Signal）是个人熟练度与团队能力之间的差距。只要它停留在个人层面，团队的效能就取决于恰好是谁在写提示词。
工作流信号。 成功的交互序列：对话结构、任务拆解方法、能稳定产出好结果的工作流。这些是团队正在形成的手册（Playbook）。一位开发者发现在实现之前先设计 API 契约能持续产出更好的结果，这就找到了一种工作流模式。一位开发者发现让 AI 在继续之前先自我检视其输出，能更早发现问题，这就找到了另一种模式。这些工作流模式一旦被识别出来，是可以复制的——但前提是有人把它们记录下来。
失败信号。 AI 在哪里产出了错误的东西，以及为什么。根因比症状更重要。由缺失上下文导致的失败，是一个预装缺口。由指令不当导致的失败，是一个指令缺口。由模型能力限制导致的失败，是一个需要记录的边界。运用根因思维，每次失败都指向一个可以改进的特定制品。设想一位开发者让 AI 生成一个领域模型。输出可以编译——但在审查时发现，领域对象几乎是贫血的（Anemic）：纯粹的数据容器，所有行为都被推到了服务类中。这既不是上下文失败，也不是模型能力限制：AI 知道项目的限界上下文（Bounded Context），也有能力生成丰富的领域模型。这是一个指令缺口：生成指令从未指定行为应属于领域对象本身，而非周围的类。在生成指令中添加一条约束就是修复方案。
信号与制品之间的映射关系是具体的。上下文信号反馈到预装文档。指令信号反馈到共享指令。工作流信号反馈到团队手册。失败信号反馈到护栏（Guardrails）和已记录的反模式（Anti-pattern）。反馈循环有明确的输入和明确的去向；它不是一种”提升 AI 使用水平”的抽象愿望。并非每一个观察都值得记录：一次性的边缘情况和个人风格偏好属于个人范畴。值得捕获的信号，是那些反复出现的、或者团队中任何开发者在处理同一问题时都会遇到的问题。这是一种基于这些观察来更新特定制品的实践。
实践方法
反馈循环在四个节奏（Cadence）上运作，每个节奏匹配更新的权重。
每次会话之后：一个简短的反思，而非正式流程。只需一个问题：这次会话中是否发生了应该改变某个共享制品的事情？答案常常是否定的。会话顺利完成，预装文档提供了 AI 所需的信息，指令捕获了应该捕获的问题。当答案是肯定的时候，更新立即进行：在预装文档中加一行、在指令中加一条检查、在功能文档中加一条备注。纪律性体现在提出这个问题本身，而非流程开销。提问只需几秒。更新——在必要的时候——只需几分钟。建立这一习惯最简单的方式，是将它锚定到一个已有的检查点上：PR 模板中的一个字段、站会中的一句话、或者一天结束时关闭编辑器的那个动作。触发方式没有固定答案，关键是保持一致性。
在站会上：对于已经有每日站会的团队，这是一个快速传播有价值学习成果的天然场所。一个简单的问题，比如”昨天有人在使用 AI 时发现了什么值得大家知道的吗？“——就能将一个人的发现变成团队的共同实践，而不需要增加另一个会议。
在回顾会议上：在现有的冲刺回顾会议中加一个议题：这个冲刺中 AI 方面什么做得好？遇到了什么阻力？我们要更新什么？产出是具体的：一次预装文档修订、一条指令优化、一个新记录的反模式。这是个人观察转化为团队决策的场所。某位开发者发现某个特定约束能提升代码评审输出质量，这就变成了团队更新后的 Review 指令。技术负责人或指定的负责人对纳入共享制品的内容做最终决定；回顾会议的作用是呈现选项，而非对每一个细节达成共识。
定期审查：审视这些制品是否确实在被使用、是否仍然有效。哪些指令在被执行？哪些被忽视了？还有哪些剩余的空白？这是最轻量的节奏——每季度一次，或者在团队感觉制品已经偏离实践时进行。
这种实践的设计本身就是轻量的。最重的节奏也只是在一个已经存在的会议中加一个五分钟的议题。如果这个实践需要专门的会议，它将是团队忙碌时第一个被砍掉的东西——而那恰恰是学习最重要的时候。
知道实践在运行和知道它在起作用，是两件不同的事。
衡量变化
大多数试图衡量 AI 效能的团队，衡量的东西是错的。速度（生成的代码行数、首次输出的时间）衡量的是数量，而非价值。一个需要大量返工的快速输出并不是生产力的提升，它只是多了几个步骤的返工而已。
真正重要的东西更难衡量，但信息量更大：首次通过率（First-pass Acceptance Rate）——AI 首次输出无需大幅修改即可使用的频率；迭代轮次（Iteration Cycles）——一个任务需要多少轮来回；合并后返工（Post-merge Rework）——代码上线后发生了多少修复；以及原则对齐（Principle Alignment）——输出是否遵循团队的架构标准。这些才是反馈循环正在起作用的指标：团队的制品捕获了更多 AI 所需的信息，AI 的输出正在向团队期望的方向收敛。
对于已经在跟踪 DORA 指标的团队，这些指标可以作为有效的先行信号。更少的迭代轮次通常意味着每次变更的返工更少，进而有助于缩短交付周期。更高的原则对齐意味着架构漂移被更早发现——在它到达生产环境之前——这应该降低变更失败率。反馈循环与其说是一个独立的举措，不如说是一种改进团队已经关心的结果的方式。如果 DORA 指标尚未纳入实践，一个更简单的替代指标也足够：团队多久说一次”AI 完全知道该怎么做”？非正式地跟踪这个频率，就能在更宏观的交付指标发生变化之前，给出制品正在发挥作用的早期信号。
坦率地说：这些指标很难严格追踪。统计迭代轮次需要对”一轮”有一致的定义，而这个定义因任务复杂度而异。首次通过率是一个判断，不是一个二元值。实践中，信号往往是定性的。团队注意到 AI 会话更顺畅了，指令捕获的问题更多了，新成员借助预装文档和手册上手的速度比没有这些的时候更快了。挫败感的减少——“AI 为什么这样做？“这句话出现频率的下降——往往是最可靠的指标。我不建议搭建仪表盘。我建议保持关注。
校准
这种实践对那些已经建立了前几篇文章中描述的基础设施、想要从”我们在用 AI”进阶到”我们越来越擅长用 AI”的团队最为重要。对于仍处于初始采用阶段的团队，首要任务是先构建那些基础设施。改进它们的反馈循环排在后面。
权衡点在于纪律性而非官僚主义——这是一条窄路。太正式，实践就变成了一个季度内就会被抛弃的管理负担。太随意，它和什么都没做没有区别。会话后的自省、回顾会议的议题、定期审查——这些都是有意做到极简的。节奏比严谨性更重要。一个每两周问一次”我们应该更新什么？“并据此行动的团队，会比一个设计了精密收集流程但在截止日期逼近时就放弃的团队进步得更快。
这种实践有一种结构性的紧迫感。AI 生态系统（模型、工具、能力）的演进节奏，让传统文档的腐化速度看起来如同冰川消融。当团队采用一个模型版本时编写的预装文档，在新版本以不同方式处理上下文窗口（Context Window）时，可能会产生误导。围绕一个工具的优势设计的指令，可能会错过下一个版本引入的新能力。这和团队在依赖管理中已经理解的情况是一样的：一个从不更新的锁文件不会保持稳定，它会变成一个负债。这些制品值得同等对待：像测试套件一样定期审查、以同样的纪律性维护，而不是写一次就和入职文档一起归档。把它们当作活的基础设施的团队会获得复利效应。把它们当作初始设置文档的团队会停滞——不是因为他们起步错了，而是因为他们停止了维护。
反馈循环没有它所改进的制品就无处着力——从那些制品开始。
总结
区分一个仅仅在使用 AI 的团队和一个持续进步的团队的，不是模型。而是团队是否有一种方式，将每一次交互转化为对共享制品的一次小改进。这就是反馈循环的角色。它把原本只是个人直觉的东西——一个好用的提示词、一个反复出现的失败、一个缺失的约定、一个评审的盲区——变成团队基础设施的一部分。
这就是为什么我认为反馈飞轮（Feedback Flywheel）不是叠加在其他实践之上的额外实践，而是所有实践的维护机制。知识预装如果没有人更新就会漂移。设计先行协作只有在团队注意到什么结构有效时才会改进。上下文锚定在团队发现自己遗漏了什么时才会变得更好。编码团队标准在失败暴露出缺失的检查时才会变得更锐利。基础设施只有在实践反馈到其中时，才会产生复利。
综合来看，这些技术描述了一种与 AI 协作的方式，它映射了优秀团队彼此协作的方式：尽早共享上下文、先思考再编码、让标准显性化、将决策外化、从每次会话中学习。工具会不断变化。那些通过共享制品和轻量级仪式持续学习的团队，将是从中获取更多价值的团队。
我不建议一次性采用所有这些。我建议从一个共享制品和一个习惯开始：在会话结束时，问一问下一次应该改变什么。然后趁记忆还新鲜时，做出那个改变。这足够小，足以持续——而小步骤正是让飞轮转动起来的力量。