ZZZZEALER的博客

Vibe coding 误区：AI 写完代码能跑就结束了
但在真实项目里，能跑只是第一步，还要看有没有破坏原有逻辑，有没有留下隐性问题，有没有让后期维护变难
所以写完代码要进行 review，而不是直接下一个需求
Review 一般要做 5 件事

1. 改动范围是否超出指令
2. 是否改了不该改的文件
3. 接口和数据结构是否保持兼容
4. 异常状态有没有处理
5. 有没有新增难维护的重复逻辑
   可以让 code agent 输出一份改动摘要，包括：

• 这次改动改了哪些文件
• 每个文件改了什么
• 为什么要这样改
• 有哪些潜在风险
• 建议怎么测试
  工程交付不知看结果，也要看可解释性，如果改动说不清影响范围，后面出问题我们很难去定位维护
  开发闭环应该是：
• 先分析需求
• 判断影响范围
• 生成执行指令
• 让 code agent 修改
• Review
• 验收
  让 code agent 从能写代码到能稳定交付，把需求、开发、审核、验收这条链路跑稳
  #学习

谷歌Chrome负责人揭开Vibe Coding幻觉：AI只能帮你写出70%的代码！未来开发者培养方式将变化成三人编程

• 真正的 AI 驱动开发不是“快”，而是有意图的构建
• 如果只是"跟着 vibe 走"，我觉得在创意阶段、原型阶段是可以的，这个阶段更需要发散；但在工程阶段肯定不行，在工程阶段更需要“规范驱动开发”
• 在尝试之前先问自己：“如果把这个问题交给 AI，它会帮我更快解决吗？还是会拖慢我？”即使只是思考这个问题，也能帮助我们更好理解 AI 的边界与潜力
• 大模型的上下文窗口是有限的，这就意味着我们需要：将任务拆解成小的、可验证的块；保持需求清晰，反复迭代；

Medium 上有好多文章都在说公司大规模引入AI编码工具后，会出现软件架构漂移问题，甚至会导致重大生产事故，比如 AWS。去年12月份 AWS 内部 Kiro 在处理 Cost Explorer 服务问题的时候，自主决定“删除并重建”整个生产环境，导致服务中断 13 小时，国内一大堆订单处理受影响。
AI 确实能给开发效率带来显著的提升，但是不是也会带来飞速的架构漂移？OpenClaw 就是一个典型的“几乎全靠 AI 维护”开源项目，它的代码规模也在 AI 快速迭代的情况下快速膨胀，社区也反馈了其很多“局部正确、全局崩坏”的情况。

所以判断力是不是应该成为程序员最核心的能力？

在 AI 时代，比起自己动手写代码，更重要的是能准确判断 AI 做的“对不对”——是不是符合长期架构、业务逻辑、全生命周期成本以及潜在风险
而判断力本质上是大量隐性知识的积累

• 过去踩的坑
• 团队沟通、博弈和权衡的一些实战经验
• 对业务真实痛点、因为成本、扩展性、合规性等的理解

代码可以外包给 AI，但判断没办法外包

#linuxdo