将瓶颈从实现转移到验证

测试与验证是我们现在都应该、也将会花费大部分时间的地方；那些曾经让我们望而生畏的事情，正是我们现在要去做的 :)

"重心"正在从实现转向验证。因此，我们现在需要决定如何应对这一转变——无论是在个人层面还是组织层面。

让我们先从经典的做法说起，然后再聊一个有趣的思路。

有些组织在以推理速度交付，相信模型已经足够好；而另一些组织则亲眼见过模型对同一任务产生截然不同的输出。这两种情况同时为真，这正是验证理应获得比现在更多关注的原因。

解决之道不是放慢生成速度，而是加快验证速度，并尽可能多地将其自动化。

凡是可以用代码表达的检查，就去做。Linter、类型检查、回归测试套件、测试覆盖率以及基于 CLI 的测试，都能在人类打开 diff 之前就捕获一类错误。

如果软件是通过浏览器使用的，就按照用户真实使用的方式去测试——点击真实流程、检查各种状态、失败情况、加载行为，以及那些单元测试永远无法捕捉到的细微 UX 细节。

目标应该是端到端的正确性，而不仅仅是代码层面的正确性。

然后还有一部分是更难自动化的：共情能力。

像真实用户一样使用这个产品。思考他们会误解什么，会在哪里卡住，当他们做出错误选择时会发生什么，以及在不了解系统是如何构建的情况下，这段体验是否说得通。

让自动化去捕获机械性的错误，这样我们人类就可以把注意力放在真正需要判断力的地方：意图、权衡、边界情况，以及这个改动到底是不是应该做的那一个。

瓶颈已经转移到验证，说实话，这是一个好的瓶颈。它让一个人类对真正交付出去的东西负责。

希望对你有帮助。