这是一个创建于 192 天前的主题，其中的信息可能已经有所发展或是发生改变。
今天看到 infoQ 一篇文章，观点是 AI 编程从定量的角度去衡量，实际是降低了研发效率（可能不是针对所有人和所有场景）
这个观点对于作为一个工作十多年的服务端开发来说，和我预想的比较一致。vibe coding 距离媒体宣传中预期的目标差距很远。曾经有一位大佬说过：每天新增的代码对于企业来说是每日新增的成本。如果是按照这样去思考，一个差评冲 0 到 1 到后续的持续迭代都是通过 vibe coding 去进行项目开发交付，会受到 context length 问题导致无法完全理解整个项目的内容（持续迭代的历史、系统链路关系、业务流程迭代等），那么这就带来一个问题，谁来维护整个系统的工程代码，比如业务模式需要升级，vibe coding 是否能够比较低成本的帮助我们做系统的重构？又比如，系统链路要做性能优化或者产品交互层面的优化，vibe coding 是否可以通过全局分析去进行问题发现和最佳的修复？经验丰富的人可能都知道，这些重构和优化，可能需要结合业务策略的配合，这部分 AI 并不感知，要做到它感知，成本是极大的。
我觉得 vibe coding 可能加快了想法的验证，降低胶水代码、工具代码的开发成本。但是当想法要去演变成一个体系化的商业模式，需要一系列的业务系统去支撑时，可能 vibe coding 就失效了。
第 1 条附言 · 2025 年 7 月 14 日
首先我并不是排斥 ai 能力，但是需要结合实际情况出发去理性的判断，至少现在还没达到外界吹嘘的那么厉害。当然这个观点都是来自当前的现状出发的，并不代表未来，但是这个未来还是需要很长时间的，至少算力就跟不上一个成熟的电商整体全链路系统通过 vibe coding 去迭代，如果量子计算规模化的时候，这一切将都不是问题。可能当前资本是有一些盲从，这或许也是未来无限可能得原因。
28 条回复 • 2025-07-15 10:36:42 +08:00
 |
1
craftsmanship 2025 年 7 月 14 日 via Android
只能说目前还不够成熟 但 vibe coding 一定是趋势 那些搞 AI 落地的也卷生卷死的 不可能会停止改进
|
 |
2
xingcy 2025 年 7 月 14 日
确实
|
 |
3
w568w 2025 年 7 月 14 日  3
选择你的回复：
- 暂时性的，AI 再发展一两年就好了 - 我用 Claude Code / Cursor / <其他 AI 编辑器>…… 写了 xxx 项目，挺好用的 - 工资几个钱啊，老板都不管可维护性你急什么 - 模型不行，我用 Gemini Pro / Claude 4 / <模型名字>…… 没遇到问题 - 屎山代码有啥好持续维护的 |
 |
4
yidinghe 2025 年 7 月 14 日 via Android
想象一下，老板认为程序员的效率增加了，于是当程序员辞职时不再招人，而是让现有程序员接手工作。可惜这时候 AI 帮不上一点忙。
|
 |
5
mumbler 2025 年 7 月 14 日 7
维护是因为代码生产成本高，如果重构成本很低，每次都重构不是更好吗，老代码可以作为上下文提供
人类还是穷的时间太久了，不习惯奢侈的生活 |
 |
6
sampeng 2025 年 7 月 14 日 via iPhone
1 ，那个文章是 openai 主导研究的，屁股就是歪的，不说这个怎么吹牛逼自己 codex 呢
2 ，研究的是 cursor pro 。你高低用 claude 的 api 我都不说什么还有点可信度。 |
 |
7
8355 2025 年 7 月 14 日
vibe coding 的前提一定是自身可以完全开发这个需求代码，并且对模型生产的代码有一定预期，这样才可以有比较高效的方式去描述代码产出的要求以及符合某些上下文和原有架构设计去进行迭代。
从 0 开始没有架构规划没有设计原则，那一定是失控的状态，后续模型还会参考某些垃圾产出来继续产出屎山，最终导致项目无法维护或继续生产出正确的代码。 vibe coding 应该起码是利好高级以上的开发者到架构师层级，对于初级开发者而言更好的方式应该是多轮对话，这样可以更好的侧重于解释代码辅助学习而不是更偏重于产出。 至于你说的随着业务架构的增长会受到 context length 问题导致无法完全理解整个项目的内容，其实这是暂时的，随着算力的增长会逐步改善一些。但以目前的情况来说算力膨胀情况下模型也达不到可以协调全局做分析和重构，人是灵活的，业务是灵活的，但模型是死的。 |
 |
8
streamrx 2025 年 7 月 14 日 via iPhone
ai 是越来越发展的，每一天每一次模型更新都会比之前更强。主动拥抱各种 ai 的新东西就行了
|
 |
9
Vegetable 2025 年 7 月 14 日
这个观点看起来是挺有道理的，但是我认为这么说是非常有局限性、时效性的。
理想化的说，AI 是发展的，局限于当下 AI 的状态评价 AI 在未来的应用，是一种刻舟求剑的行为。 抛开发展不说，人们实际上还没学会怎么使用 AI 。在 vibe coding 一个项目时，有多少开发者想过“如何让 AI 编写一个容易被 AI 维护的系统”？现在处于比较原始的阶段，还没有形成广泛的，稳定的，高效的 vibe coding 编程方法，而这套方法慢慢就会演化出来。而“什么样的代码更容易被 AI 维护”只是一个方面，AI 全面介入工程领域还需要很多其他方面的方法论。 这也是我一直认为 AI 无法大规模取代开发人员的重要原因之一。哪怕 AI 变得比大部分程序员都聪明，也很难和产品经理顺畅沟通，这个位置上终究需要翻译的人。这套成熟的 vibe coding 方法，会成为一个新的开发门槛。 |
 |
10
HENQIGUAI 2025 年 7 月 14 日 1
vibe coding 有很多需求本身都是一次性的解决方案，现阶段天然就很合适。
|
 |
11
kera0a 2025 年 7 月 14 日 via iPhone
@mumbler
每次修改都全部重构，那整个系统都得完整测试，这测试的工作量得多大，还不如不用 AI 呢。 除非 AI 能完美理解需求，并全自动测试完毕，那这样的话已经是终极形态了，也就不需要重构了，更不需要任何人了。 |
 |
12
scnace 2025 年 7 月 14 日
所以 vibe coding 现在的场景可能会比较局限在一些 tools 相关的小工具
|
 |
13
svenzhao 2025 年 7 月 14 日 2
编程的真正难点 从来不在于代码。
编程的本质 是把一个模糊的人类想法 精确地翻译成计算机能懂的语言 这是一个工程问题。 大多数人未经训练 连清晰地表达自己的想法都做不到 最明显的例子 两个人通过电话来告知自己的位置 很多人甚至描述不清楚自己的精确位置 把需求讲明白 能让计算机和人理解 比编程本身难多了 |
|
15
mumbler 2025 年 7 月 14 日
@kera0a #11 测试，运维其实也是 AI 擅长的事，claude4 写完一个功能，自己就会做单元测试, 要完美理解需求，重点在于提供足够好的上下文，不能说一句话开发个淘宝，就让 AI 做，做出来不行，就说 AI 不行
不愿意花时间研究如何更好的提供上下文的人，愿意花时间去手写代码，这就是要被淘汰的那批人 |
 |
16
maolon 2025 年 7 月 14 日 via Android 2
维护？ 按 andrew ng 前些时候的演讲，他公司一个月内换了三次架构，有问题就重写重构，代价已经是历史上最低的时期了，而且以后还会更低
|
 |
17
cybort 2025 年 7 月 14 日 via Android
写代码的时间少了，考虑需求，架构的时间多了，还能做几套不同的对比测试，而且你以为 ai 实现的系统留不下中间过程吗？文档写的比你写的好信不信？
|
 |
18
livin2 2025 年 7 月 14 日 1
之前水过一帖试图讨论 vibe coding 的工程化范式 https://global.v2ex.com/t/1119929 。别的地方也水过，有意义的不多。
LLM 幻觉是结构性的必然，这和业务 QA 天然对立，落地过程中就是要想办法去做风险控制的。但一些人完全把 LLM 当作了一个魔法黑盒通通装进 AI 这个概念里战未来。如果在更强的 LLM 面前，工程化没有意义。那在更强的模型架构面前，prompt 和上下文也没有意义。长期来看，我们都死了。 从这种思潮来看，都不需要 LLM 有什么质变就能劣币驱逐良币了，能抛弃测试和 QA 的团队自然也可以抛弃产品和技术。 |
 |
19
uxstone 2025 年 7 月 14 日
现阶段的 AI 编程能干死低代码和传统的模版化代码生成就很不错了。
|
 |
20
1zh3n 2025 年 7 月 14 日 via Android
1. 持续维护也用 AI
2. AI 提高了代码上限，可能降低维护成本 3. vibe coding 变相让工程师熟悉业务逻辑，毕竟描述准确才能生成准确 这一切的前提是理解你生成的代码，直接使用不理解的代码是不负责任的——前端 UI 部分除外。 |
 |
22
leelotov2er 2025 年 7 月 15 日
vibe coding ，不愿意用的人能找出千百个理由不用，好像这些人每天在公司都写的高深的代码，AI 处理不了一样，自己写的不是屎山一样
|
 |
23
charlie21 2025 年 7 月 15 日
你的人类同事 vs 你的 AI 同事
1. 无论听者是 AI 同事还是人类同事，人类作为说者 对于复杂问题的描述能力其实是非常有限的，这里必须要求听者机灵一点 2. 如果描述都错误了，那么这是 GIGO (Garbage in, garbage out)。诚然，这是说者的责任。但一个说者对此是不会认错的，原因就是 “对于复杂问题的描述能力其实是非常有限的”，这是人类的通病 3. 输入的是垃圾，输出的是垃圾，这是客观存在的 4. 同样是 GIGO, 人类听者的纠错性远远大于 AI 的纠错性：假设你是说者，你的同事 / 你的 AI 同事是听者 - 你的同事可以告诉你，你说的前后矛盾，你说错了，即 你的同事能仅仅从不完整的业务描述里直接反推出业务的不可理性。AI 能吗？ AI 努力的方向是 “理解人类的需求”（将错就错） - 你的同事甚至可以告诉你正确的需求应该是什么 - 虽然 AI 同事擅长找到正确的答案，但人类同事擅长找到正确的问题 5. 问出正确的问题比找到正确的答案更重要 综上，你的人类同事打败了你的 AI 同事 |
 |
24
zmcity 2025 年 7 月 15 日
AI 不是在持续集成方面比人更强吗，而且重构还快
|
 |
25
msg7086 2025 年 7 月 15 日
@nbndco #14 这就体现出程序员 vibe coding 和非程序员（或者不聪明的程序员） vibe coding 的区别了。聪明的程序员让 AI 写测试用例覆盖业务逻辑，跑通以后既不需要复杂的 debug 也不用担心重构出现问题。而剩下的一些人则在那空喊着 AI 写的代码 debugging 要老命 review 要老命重构要老命。
|
 |
26
XTTX 2025 年 7 月 15 日
Cursor 会自动写一大堆 .md, 还会自动出 svg 架构图。 复杂一点的代码我会让几个 AI 全部撸一遍， 挑一个最容易读懂的
|
 |
27
nbndco 2025 年 7 月 15 日
@msg7086 这就是写过程序的程序员和没写过程序的程序员的区别了。先不说测试本身就高度绑定代码的设计，怎么样的 test coverage 可以保证只凭借 test 就可以确定程序的正确性呢？都不说正确性了，现实中有几个框架的 testability 真的可以满足这种需求？空想只要 ai 生成了 test 就可以随心所欲让 ai 写代码的人，真的写过代码吗？
|
 |
28
gorira 2025 年 7 月 15 日
看着自己天天都在用，用了两年多的东西，在网上天天被别人质疑，有种听我爸妈唠叨我「别一天到晚玩盯着电脑了，眼睛会瞎的」的感觉😂
|
Select Language