向大家推荐我的最新播客，感谢关注～
[AI 评论] AI 时代的“草台班子”创业：为什么说糟糕的代码，可能是个好生意？
www.xiaoyuzhoufm.com/episode/68c5689e2c82c9dcca2ce6b1
当设计师、运营、甚至你的老板都能用 AI“凑”出一个 App…
工程师打开代码的瞬间，当场石化！😱
这究竟是在埋下一颗颗“技术地雷”，还是一种全新的“创新捷径”？
那些用铁丝绑起来的“手搓汽车”，虽然丑，但能跑赢市场吗？
先别急着下结论！
这可能不是技术的倒退，而是社会分工的一次超级进化。
收听本期《爱评论》，陈老师带你揭开 “Vibe Coding” 的神秘面纱。
看懂这场混乱背后，如何诞生最高效的创新范式，以及你——无论是创意者还是工程师——在其中的全新位置。
＃VibeCoding ＃氛围编程 ＃AI 改变世界 ＃技术债务 ＃商业模式

关键是几年的时间，从 gpt3.5 的三十行代码就有五行报错，到现在独立完成一个小项目报错都不超过十次，进步的速度实际上很快了
现在还能用可维护性作为护城河，可是 AI 一直在高速进步，且先不说它们什么时候能生产出高可维护性的代码，如果再过几年就算是屎山，人家照写不误，在屎山上面继续堆下去也能让整个产品安稳的过完一生，那可维护性对于它们来说有什么重要的呢？

都是怕被取代罢了

平心而论，AI 写的那些代码 你真有把握吗

会害怕被 ai 取代的人我不好说他是什么水平

说真的确实 接手的项目一团乱 但是 ai Claude4 就可以在原有的基础上修复 bug 并且优化 我不敢动但是 ai 能完美解决问题

很明显这个问题如果按照当下的时间来回答，那么答案是没有。
但是回顾三年前，我们再往后推三年，我是不敢说那时候我还会回答没有的

有 debug 能力的才适合 vibe coding ，至少得看懂 AI 在干嘛。

很正常，我觉得未来一个趋势就是大量的框架将会深度整合 LLM 的能力，让普通人也能快速开发应用原型，甚至部分专业领域的工程师本身就是最了解他们特定领域业务的专家，他们可以通过 LLM + python 这种大众化的胶水语言构建自己的原型应用，虽然有很多 bug ，也有很多屎山，但不妨碍它能大致 run 起来，最后交付给专业程序员来进行整合

拥有大量语料训练过的编程语言将占据全部的编程生态位，而那些历史代码仓库规模不够大的语言将彻底失去市场，低代码很快被丢进垃圾桶

另外可维护性并不是市场的首要需求，大部分公司的代码都是屎山，只要人力够便宜，你总能找到人维护这一坨

这一代 LLM 的上限已经在这里了，不存在替代程序员的可能性，但是程序员的工作内容真的会发生天翻地覆的变化，大部分 CRUD 的工作可能未来就真的就是 AI 在做了，程序员站在更高的层次把握系统逻辑，把控代码提交，以及测试用例的 case

是的，我好几个维护了十多年的客户放弃了和我的续约，转而使用初级程序员甚至设计师+AI 的方向。看起来是时候放弃售卖技术服务了，而做一个能卖的产品太难了😮‍💨

没事儿的，还会回来找你的

会写代码的用 llm 大概都是辅助，完全不会的才纯 vibe coding ，目前全靠 llm 生成出来的肯定是屎山，会写代码的看到了会崩溃的。

连变量/函数名都要斟酌很久的程序员，根本不可能接受 任何人/ai 随意动自己的代码。

纯粹的 CRUD 肯定是没有意义了
如何设计拆分逻辑，确保功能内聚解耦， 这才是短时间内人的价值。
毕竟 LLM 的上下文短时间内就那么多， 而且召回率（是这个名词吧）堪忧

再厉害也和使用人有关系的。
我一个离职同事，代码写的一泡污。
我叫他试试 AI 写，他让 AI 把代码写的一泡污。
配上电动螺丝刀，不代表就是好的技工

我在想，当初高级语言出来的时候，汇编高手们是不是想，你连有几个寄存器都搞不懂，怎么可能写出高效合理的代码；当垃圾回收机制出来的时候，C/c++er 们在想，内存分配都没想明白，不担心循环引用？

说实在话，可维护性并不是目的，目的是为了程序能够正常运行，ai 能够在屎山中轻松找到 bug 并修复，那么屎山又有什么问题呢？

我觉得现在的 AI Coding 就像是现在的 AI 美女一样，看起来好像挺漂亮的，有些甚至性感到爆炸，但是一旦细看就发现这里不和谐那里更诡异。
我相信 AI 未来会越变越好，但至少现在它还是差点劲。

时代的车轮不可改变，哪怕是走向毁灭，就算有不少先知看着有问题，天天疾呼，也没有用。就像这 20 年，全球的音乐、审美、价值观等，都在向下走，个人无力改变，甚至为了生活，还不得不迎合。

claude 生成的代码 出 bug 是真不好改

这种类比是不准确的

高级语言和垃圾回收机制都是有理论基础的，前者有类型系统与语义定理，编译原理作为基础，后者有可达性模型和分代的工程经验。而大模型有什么呢？涌现？ scale 定律？目前依然没有靠谱的理论基础，我们这样用只是 it just works

1. 把更高抽象和更脏实现混为一谈
   高级语言/GC 引入的是抽象与自动化，目标是减少偶然复杂度；而屎山是设计退化与耦合失控。前者通常降低出错率和变更成本，后者相反。
2. 把能修 bug 当成能演进系统
   sre benchmark 中的任务相对固定明确，而现实业务中有很多业务相关的知识，如何让大模型准确理解业务领域的知识，并不是一件成本低廉的事情。
3. 假设 AI 修复是稳定且无副作用的
   至少目前来看，ai 对代码的理解比 gpt3.5 时期刚出来的时候能力强了许多，但是依然不能保证没有问题。大模型的训练方式就天然决定了它的回答上限依赖于训练数据，无法解决新领域的问题，同时由于 token 输出依赖自然语言，同样无法解决自然语言相关的问题：概念描述和自我指代的悖论。