谈谈工程师的反馈速度

有次和团队新人聊"怎么提高效率"，他问我："写得快和做得对，哪个更重要？"我想了想说："都不是，是反馈回路短。"这件事让我意识到，"反馈速度"是工程师最被低估的能力。本文是一些非典型的讨论。

反馈回路是什么

工程师的反馈回路是这样的：

1. 写下一段代码。
2. 等编译 / 测试 / 部署。
3. 看到结果（成功或失败）。
4. 根据结果调整。

这个循环越短，工程师进步越快、产出越好。"写得快"只是循环里某一环的速度，"反馈回路短"是整个循环的速度。

10 倍工程师不是"打字快 10 倍"，是"每个想法到验证的循环短 10 倍"。

短回路 vs 长回路

对比两种工作方式：

维度	短回路工程师	长回路工程师
写代码	边写边测	写完一大段才测
调试	立刻本地复现	等线上日志再排查
上线	小步灰度	大版本一次发
反馈	看指标立刻判	等周报才知道

短回路工程师一天能跑 50 个循环，长回路工程师一天跑 3 个。差距不是能力，是节奏。

如何缩短反馈回路

1. 本地能跑就不上服务器

很多团队的反馈回路长，是因为"本地跑不起来"。代码必须部署到 dev 环境才能测。这把每个循环从 30 秒拉长到 30 分钟。投资"本地能跑"是 ROI 最高的事。

2. 单元测试代替手动测试

手动测试的反馈是"分钟级"。单元测试是"秒级"。一个有单测覆盖的工程师，写代码的速度比没有单测的快 3 倍以上——因为他不需要"担心哪里会出错"，测试会告诉他。

3. 小提交代替大 PR

500 行的 PR review 周期 3 天。50 行的 PR review 周期 3 小时。把大 PR 拆成小 PR，每个 PR 反馈快，整体进度也快。

4. 看板代替周报

周报是"7 天反馈周期"。看板是"实时反馈"。任何卡住的环节立刻可见，不用等周会。

反馈回路与质量的关系

有人担心"短回路"会让人"不深思"。我观察到的相反——短回路让人"敢试错"。一个想法可以 5 分钟验证 vs 5 小时验证，前者会让你试 10 个想法，后者只试 1 个。试 10 个想法的工程师比试 1 个的进步快得多。

真正的"深思"不是"想很久才动手"，是"动手后快速验证再调整"。后者才是工程师真正的工作方式。

反馈回路与团队文化

团队的反馈回路同样重要。一个团队的"决策反馈回路"是这样的：

1. 有人提一个想法。
2. 团队讨论。
3. 决定是否做。
4. 试一下。
5. 看结果。

有些团队这个循环要 2 周（提案 → 评审会 → 架构会 → 排期 → 开发 → 上线）。有些团队 2 天。前者的创新能力远低于后者——不是没人有想法，是想法被流程磨掉了。

几个反直觉的经验

• 慢工出细活是错的。慢工经常出"想多了但没验证"的活。细活来自"反复试"。
• "先写测试再写代码"看起来慢，实际快。因为反馈回路短了。
• "写完一段就 commit"看起来碎，实际快。因为可以随时回滚到上一步。
• "快速 demo 看效果"看起来浪费，实际快。因为提前发现方向错了。

给团队的简短建议

• 投资"本地能跑"——这是反馈回路的地基。
• 鼓励小 PR、小提交、小灰度。
• 团队决策也要短回路——别让想法等两周才被讨论。
• 用看板替代周报，让反馈实时化。

工程师的真正速度，不是打字速度，是"从想法到验证"的速度。把这条回路缩到最短，效率自然就上来。这件事不需要天赋，需要纪律。