看到一些挺有意思的新东西，先放个原视频链接在这
Why AI Didn’t Actually Make You Ship Faster — Gabriel Spencer-Harper, Meticulous，
这里不讨论它的价值，这篇文章主要是做一些简单的文字总结和延申思考
背景
如今的vibe coding时代，AI写代码的速度已经远超人工，看起来效率提升了一大截，但是会带来一个问题：我们如何保障AI生成代码的质量？
原本人工写的代码，review起来是匹配人工速度的，并且自己写的代码哪里出了bug相对来说是好定位的，但是现在AI生成的速度非常快，给出需求，定好边界，喝杯水的功夫跑完了，可是代码细节对我们来说实际上是更陌生的。
生产速度提升上去了，验证速度如何提升？
AI的自主性不可忽视，他会不会带来新的潜在的回归场景？
我们前置的工程约束是否足够全面？
这些不解决，我们不可能说就这样把代码push上去，那就必然会涉及到一个问题：如何高效review这部分产物？
这里包含两个子问题：
- 如何详尽全面地验证代码？
- 如何保障验证速度？
Meticulous给出的前端侧解决方案
先从效果侧来直观理解一下他们的方案：
Meticulous监控非生产环境浏览器中所有用户工作流动作，比如点击、输入、页面跳转、网络请求及响应等信息。
它录制diff代码对应的动作并在每个原子时刻截图，这样就得到了对应工作流的一系列截图，将代码变更前后的截图逐一比对。这样开发人员可以直观看到差别。
具体流程：建立测试基线（记录用户操作过程）-> 修改代码 ->自动回放之前记录的操作，分别在新旧版本上运行
这样做的好处是，我们不必预先基于业务逻辑等编写测试用例，而是在审查阶段直接拿到一份足够详尽的diff报告。
并且这里回放的时候会采用mock数据，能够保证幂等性
可能存在的问题
- 之前没有被录制到的业务场景，不一定能被测试覆盖，比如，没有人触发过上传失败后的重试逻辑，那么仅依靠历史用户行为就可能遗漏这个场景。
- 差异过于全面，详细到一个像素这种，可能有点冗余
- 如果新版本的交互结构发生了很大的变化，旧会话可能无法正确回放，Meticulous理解不了，需要新的会话来替换。
一点思考
AI或许已经或者即将改变软件生命周期的某些比重。
开发阶段的技术门槛正在下降，对于研发人员来说，自身能力或许要朝着前期的规划和后期的验证倾斜。
前期的规划像是怎么写spec、skill、prompt，建立清晰的架构这些，在2026年之前，还是非常重要的，当然不是说现在就不重要，但是以现在的模型能力来说，可能过度干预才是代码结构差的原因，有时候会感觉自己像个什么都不懂的领导再妄图干涉我的天才员工（）
但是审查仍然是必须的，信任神的前提是神扛得住质疑。如果生产出来的代码不够好，我们其实还谈不上有更多的时间去创造伟大的设想，只能说创造出一个“伟大的”的空壳，然后在后续疯狂排查故障、创造不必要的高耦合扩展场景、堆叠过量的复杂边界排查。
市面上有很多很棒的观测工具，能告诉我们哪里出了故障以及一些关联问题，但是对于问题的排查如何做到精准定位，可能仍然是一个问题，这里有另外一个工具也许可以借鉴（自称可以自动生成跨多跳链路的根因报告，并实施修复措施，并验证修复效果）The 5 Levels of Self-Driving Production — Eric Schwartz, Traversal
可能持续记录
