vibe coding 可能忘记了代码是需要持续维护的

[MidCoder]

今天看到 infoQ 一篇文章，观点是 AI 编程从定量的角度去衡量，实际是降低了研发效率（可能不是针对所有人和所有场景）

这个观点对于作为一个工作十多年的服务端开发来说，和我预想的比较一致。vibe coding 距离媒体宣传中预期的目标差距很远。曾经有一位大佬说过：每天新增的代码对于企业来说是每日新增的成本。如果是按照这样去思考，一个差评冲 0 到 1 到后续的持续迭代都是通过 vibe coding 去进行项目开发交付，会受到 context length 问题导致无法完全理解整个项目的内容（持续迭代的历史、系统链路关系、业务流程迭代等），那么这就带来一个问题，谁来维护整个系统的工程代码，比如业务模式需要升级，vibe coding 是否能够比较低成本的帮助我们做系统的重构？又比如，系统链路要做性能优化或者产品交互层面的优化，vibe coding 是否可以通过全局分析去进行问题发现和最佳的修复？经验丰富的人可能都知道，这些重构和优化，可能需要结合业务策略的配合，这部分 AI 并不感知，要做到它感知，成本是极大的。

我觉得 vibe coding 可能加快了想法的验证，降低胶水代码、工具代码的开发成本。但是当想法要去演变成一个体系化的商业模式，需要一系列的业务系统去支撑时，可能 vibe coding 就失效了。

[craftsmanship]

只能说目前还不够成熟 但 vibe coding 一定是趋势 那些搞 AI 落地的也卷生卷死的 不可能会停止改进

[xingcy]

确实

[w568w]

选择你的回复：

- 暂时性的，AI 再发展一两年就好了

- 我用 Claude Code / Cursor / <其他 AI 编辑器>…… 写了 xxx 项目，挺好用的

- 工资几个钱啊，老板都不管可维护性你急什么

- 模型不行，我用 Gemini Pro / Claude 4 / <模型名字>…… 没遇到问题

- 屎山代码有啥好持续维护的

[yidinghe]

想象一下，老板认为程序员的效率增加了，于是当程序员辞职时不再招人，而是让现有程序员接手工作。可惜这时候 AI 帮不上一点忙。

[mumbler]

维护是因为代码生产成本高，如果重构成本很低，每次都重构不是更好吗，老代码可以作为上下文提供

人类还是穷的时间太久了，不习惯奢侈的生活

[sampeng]

1 ，那个文章是 openai 主导研究的，屁股就是歪的，不说这个怎么吹牛逼自己 codex 呢
2 ，研究的是 cursor pro 。你高低用 claude 的 api 我都不说什么还有点可信度。

[8355]

vibe coding 的前提一定是自身可以完全开发这个需求代码，并且对模型生产的代码有一定预期，这样才可以有比较高效的方式去描述代码产出的要求以及符合某些上下文和原有架构设计去进行迭代。

从 0 开始没有架构规划没有设计原则，那一定是失控的状态，后续模型还会参考某些垃圾产出来继续产出屎山，最终导致项目无法维护或继续生产出正确的代码。

vibe coding 应该起码是利好高级以上的开发者到架构师层级，对于初级开发者而言更好的方式应该是多轮对话，这样可以更好的侧重于解释代码辅助学习而不是更偏重于产出。

至于你说的随着业务架构的增长会受到 context length 问题导致无法完全理解整个项目的内容，其实这是暂时的，随着算力的增长会逐步改善一些。但以目前的情况来说算力膨胀情况下模型也达不到可以协调全局做分析和重构，人是灵活的，业务是灵活的，但模型是死的。

[streamrx]

ai 是越来越发展的，每一天每一次模型更新都会比之前更强。主动拥抱各种 ai 的新东西就行了

[Vegetable]

这个观点看起来是挺有道理的，但是我认为这么说是非常有局限性、时效性的。

理想化的说，AI 是发展的，局限于当下 AI 的状态评价 AI 在未来的应用，是一种刻舟求剑的行为。

抛开发展不说，人们实际上还没学会怎么使用 AI 。在 vibe coding 一个项目时，有多少开发者想过“如何让 AI 编写一个容易被 AI 维护的系统”？现在处于比较原始的阶段，还没有形成广泛的，稳定的，高效的 vibe coding 编程方法，而这套方法慢慢就会演化出来。而“什么样的代码更容易被 AI 维护”只是一个方面，AI 全面介入工程领域还需要很多其他方面的方法论。

这也是我一直认为 AI 无法大规模取代开发人员的重要原因之一。哪怕 AI 变得比大部分程序员都聪明，也很难和产品经理顺畅沟通，这个位置上终究需要翻译的人。这套成熟的 vibe coding 方法，会成为一个新的开发门槛。

[HENQIGUAI]

vibe coding 有很多需求本身都是一次性的解决方案，现阶段天然就很合适。

[kera0a]

@mumbler
每次修改都全部重构，那整个系统都得完整测试，这测试的工作量得多大，还不如不用 AI 呢。

除非 AI 能完美理解需求，并全自动测试完毕，那这样的话已经是终极形态了，也就不需要重构了，更不需要任何人了。

[scnace]

所以 vibe coding 现在的场景可能会比较局限在一些 tools 相关的小工具

[svenzhao]

编程的真正难点 从来不在于代码。
编程的本质 是把一个模糊的人类想法 精确地翻译成计算机能懂的语言 这是一个工程问题。
大多数人未经训练 连清晰地表达自己的想法都做不到
最明显的例子 两个人通过电话来告知自己的位置 很多人甚至描述不清楚自己的精确位置
把需求讲明白 能让计算机和人理解 比编程本身难多了

[nbndco]

@mumbler 连让 ai 现改几句都要一行一行 review 半天最后自己重写，每次都重构的话是要每次都全部 review 整个项目吗

[mumbler]

@kera0a #11 测试，运维其实也是 AI 擅长的事，claude4 写完一个功能，自己就会做单元测试, 要完美理解需求，重点在于提供足够好的上下文，不能说一句话开发个淘宝，就让 AI 做，做出来不行，就说 AI 不行

不愿意花时间研究如何更好的提供上下文的人，愿意花时间去手写代码，这就是要被淘汰的那批人

[maolon]

维护？ 按 andrew ng 前些时候的演讲，他公司一个月内换了三次架构，有问题就重写重构，代价已经是历史上最低的时期了，而且以后还会更低

[cybort]

写代码的时间少了，考虑需求，架构的时间多了，还能做几套不同的对比测试，而且你以为 ai 实现的系统留不下中间过程吗？文档写的比你写的好信不信？

[livin2]

之前水过一帖试图讨论 vibe coding 的工程化范式 https://global.v2ex.com/t/1119929 。别的地方也水过，有意义的不多。
LLM 幻觉是结构性的必然，这和业务 QA 天然对立，落地过程中就是要想办法去做风险控制的。但一些人完全把 LLM 当作了一个魔法黑盒通通装进 AI 这个概念里战未来。如果在更强的 LLM 面前，工程化没有意义。那在更强的模型架构面前，prompt 和上下文也没有意义。长期来看，我们都死了。
从这种思潮来看，都不需要 LLM 有什么质变就能劣币驱逐良币了，能抛弃测试和 QA 的团队自然也可以抛弃产品和技术。

[uxstone]

现阶段的 AI 编程能干死低代码和传统的模版化代码生成就很不错了。

[1zh3n]

1. 持续维护也用 AI
2. AI 提高了代码上限，可能降低维护成本
3. vibe coding 变相让工程师熟悉业务逻辑，毕竟描述准确才能生成准确

这一切的前提是理解你生成的代码，直接使用不理解的代码是不负责任的——前端 UI 部分除外。