读完“高级工程师会不会断档”，我更担心的是失去判断错误的机会

我曾整理过一篇围绕 Vibe Coding 和 Coding Agent 的长文讨论。它问的并不是“AI 会不会替代程序员”，而是：当 AI 几分钟就能产出像样的代码，新人还能从哪里获得建立工程判断所需的负反馈？

这篇是读后思考，不是声称自己做过大规模开发团队研究；原始观点来自外部讨论，我在此记录的是哪些部分和自己的学习经历发生了关联。

实现变便宜了，但验证没有消失

过去阅读一个没写过的业务模块，得沿着 Handler、Service、Repository 一层层追踪。现在先问模型，它就可能把流程讲得相当清楚，也能直接给修改方案。

效率确实高了。但我在阅读自己的 Go 项目时遇到一个问题：项目最初有不少代码是 AI 帮我生成的，如果我把这套代码又当成“正确的教材”，很可能只是学习了先前那轮 AI 的偏好。因此我后来找 ArdanLabs、Memos 等开源项目做架构对照。

这说明在 AI 帮助下，真正值得刻意保留下来的，是面对不同方案做判断、自己查证后推翻前提的过程。

Code Review 不能只是“再请一个模型确认一下”

原讨论里我很认同的一点是：模型往往能把用户提出的设计继续做下去，却未必主动质疑“这个东西应该这样设计吗”。

例如，问题不是“帮我把这个 Store 注入到 ApplicationService 中”，而可能是“ApplicationService 是否根本不应该直接写 UI Store”。对一个错误边界进行精致封装，也可能只是把错误固定得更牢。

我在 DailyUse 的相关思考另有 解耦方案记录。这里不以某次对话证明所有模型都只会附和，只提醒自己：Review 必须建立在需求、边界和可验证的运行结果上。

个人应该怎么练习

我给自己保留三条要求：

1. 先写自己的判断，再向模型要方案。哪怕只是一段简短的“不确定原因”。
2. 区分教程、候选实现与实际验收。没有跑过测试、没有看过真实日志，不能因为 AI 写了“已解决”就当成事实。
3. 定期回到源代码和独立资料。理解项目图、请求链、数据迁移或错误路径，不能永远交给同一个助手复述。

AI 不必然让人退化。用它提供实验方案、生成最小复现、协助测试与 Review，也可能让个人成长更快。风险来自把“代理跑通流程”误当成“自己已经知道为什么正确”。

最终我担心的不是每个人都要退回手写全部 CRUD，而是开发速度提高以后，团队或个人更不愿花时间证明代码为什么可信。