※ 引述《bxc (机率游戏)》之铭言：
: 如题 软件失业是迟早的事吧
: ㄧ堆都在流行vibe coding
: 最近都在玩这个
: 原本的技能树不是前后端 有点概念而已
: 要弄个sample真的很快
: https://i.imgur.com/wVeBdCK.jpeg
先来定义什么是vibe coding
Karpathy described it as "fully giving in to the vibes, embracing
exponentials, and forgetting that the code even exists".
"完全沉浸在氛围中，拥抱指数级成长，甚至忘记程式码的存在"
Wiki中的描述为:
Unlike traditional AI-assisted coding or pair programming, the human
developer avoids micromanaging the code, accepts AI-suggested completions
liberally, and focuses more on iterative experimentation than code
correctness or structure.
我自己透过七天的实验，分享一下个人的心得。
# 注重迭代而非规格
我不赞同AI开发时所谓"规格"驱动开发，也就是先写完整套规格，再请AI开发的模式
理由主要有两个：
1. AI内部的接力机制，假如一个AI 99%正确，迭代22次后会变成80%
2. 即使AI能够连续工作N小时最后完成整套规格，但若是涉及UI/UX相关的，会有许多
需要手动测试的地方
所以我认为Wiki对Vibe Coding的"重视迭代实验"的叙述，是比较符合现实场景的。
# 个人方法
1. 要求AI建立单元与整合测试，UI/UX方面的手动测试则由我负责
2. 针对epic任务，让AI自行建立文件纪录说明与更新进度
3. 以我不亲自更改程式码为首要原则
4. 每次任务结束时都需要确保测试完全通过，并且通过我手动测试功能
5. 每一个阶段都要进行lint与移除程式码中的legacy code
# 历程
虽然说一开始体验确实是不错，但我认为当产品迭代到某个阶段时，会开始产生痛点
一般迭代的流程如下：
POC -> 逐步增加feature -> MVP -> feature的增减与规格变更 -> 实作
POC到MVP这段，是目前AI的强项，特别是POC；沙士比亚后再无新故事，软件开发方
面其实99%的人都在做重复的事，只是不同的数据、不同的组合而已
所以AI对我来说，能够非常快看到可以操作的POC，并且快速迭代到MVP
但在MVP后，软件需要进入打磨与增减的阶段，这时AI的问题就特别明显
1. AI在每个Task结束后对他来说又是新的开始，所以之前的细节他不一定会记得
这导致AI的产出经常缺乏一致性，或是AI的注意力放在新功能的实现而忘记codebase
可能存在相应的模组可以承担部分职责，解决方法：
a. 新增记忆 (但记忆过多无效)
b. 你必须主动提示AI必须参考哪些module或文件
2. AI会把达成任务放在首要需求，意味着AI会不择手段并选择阻力最小的途径来
完成你的指示。这导致许多class过于臃肿，或function承担了他原本不应该承
担的职责，甚至是不停累积的legacy程式码。而这些legacy的程式码又会成为干
扰AI上下文的主因之一。
解决方法：
a. 指定AI建立特定的class并说明其职责
b. 在指示阶段直接指导重构的方法
3. 静默错误。 AI会为了确保程式码能够"成功"执行而非"正确"执行，经常会过度
地使用默认值、hardcode的数值作为回传值，这导致一些层层包装的模组在传递
数值时又会过度累积大量的hardcode数值，使得底层模组出现真正异常时往往无
法察觉
讲到这里，大家应该会发现，这些问题与问题的解决方法，都涉及程式码的结构与正
确性。那若是放任这些问题不管，是否可行？也就是说“如果我们完全忘记程式码”
这些问题是否可忽略，或是说程式码根本一点都不重要
很多公司的程式码也是烂到爆，说白了AI写的程式码可能还是某些公司的上限，那这
些公司还不是钱照赚、功能照加？但我没有这个勇气尝试，因为token的帐是算在我身
上
我看到网络上有些文章，确实会将设计模式、程式码的设计准则一并加入prompt中，但
这仍然是一种关注程式码结构与正确性的行为之一。所以，vibe coding目前“忘记程式
码的存在”、“不用再管程式码的结构与正确性”这样的体验至少我自己还无法感受到
有些公司codebase烂，可是讲的是一个产业know how、讲的是一个本多忠胜，反正bug
硬干、产品能跑就好，有洁癖的工程师要走请便，反正多的是其他工程师。
现在这些公司确实是有可能用转蛋的方式砸token砸出一个可以run又不会被用户弄出bug
赔钱的产品 (反正价格错误再反过来告消费者就好)
软件开发就跟AV女优一样，像我就觉得脸蛋漂亮很重要，奶小没关系，像希岛爱里这样
有人就觉得奶大很重要、假奶没关系，但一定要奶大，像楪可怜这样
也有人坚持一定要真奶、不要人造人，这种人去看楪可怜就只会看到楪可怜的缺点
祝大家在喜欢的女优引退后都能找到自己喜欢的新人女优

最屌的还是看到开始有人做出了 H 奶 30kg，一边单眼皮一边双眼皮，然后说因为看习惯 30cm，所以也要加上 30cm，变成一个每个细节都很屌，但整体不知道到底在干嘛

前面一堆叫骂声势浩大认真讨论的文却乏人问津好啦话说回来，我同意这篇文的部分观点会出现很多冗余的参数跟没必要的流程

完全不管code太理想 但不追求什么良好设计这种方法倒是堪用了

我自己也认为“AI要好维护前提是人也好维护”毕竟正如大家的观察 Context大小就是很现实的技术极限

结论很赞

设计差 效能烂 实务上的确不是最重要的，能符合需求的产出才是真正有价值的地方

看起来不如自己写比较快...

刚刚试了vibe coding，连最简单的outlook 2007 pop3同步删掉Gmail的信件都在胡说八道，浪费我的时间，这是怎么vibe coding啦话说有人懂吗？我Gmail已经爆了,现在来跟你们vibe coding可能比较靠谱感觉vibe coding这词跟敏捷这词一样是个唬烂的同意词

蛮赞同这篇的过程跟感想的 对于有生命期的产品vibe codin终究会带来不可承受的负担 更别说要规格业务逻辑的一致性不过有人说要换个想法 对于每次功能的变动 干脆直接重新全部重头产生程式码 这也不大合理 最多只能部分codebase让AI完全重新产生码出来 但是就我的实际经验连个稍微长一点的算法或是处理程序 都没办法一次'功能'到位 觉得vibe coding只能用在小型专案上面 我现在也只是拿来产生script跟很简单的工作上的资料pipeline

vibe coding这词也才出来半年多 当然现主时没办法完全不看code很正常R 你给他再5年试试看中大型专案随着context window越来越大 迟早能整个吞下去

Llm目前就是当外部顾问 临时工用 他没办法了解专案或团队文化等等隐性知识 就像请一个外部技术专家来 也不可能三言两语就上手完成任务 所以别期待AI可以帮你完成一切理想情况是在请他做事时一边建立文件 建立测试 把隐形知识转成显性 但这就像带新人一样 短期没回报 长期也不一定利己 最后说不定是让自己失业

多少还是需要祖传md

推！很赞同这篇的过程和想法 最近刚好也一直在玩这块目前在想透过micro service+DDD开发手法，每个领域都用repository切开，减少AI每次需要学习和需要记忆的量目前是每个repository底下都放一个md在试试看～请问大大是用claude还是gemini啊？

YT搜寻Claude就好，已经开始有一堆人讲解怎么用。我用起来效率乘十倍不夸张

十倍 哈哈哈 你三天就做完以前一个月的专案进度了吗还是写扣的速度快了十倍但写扣只占工作的一小部分 其实整体产出根本也没提升多少 同时每天大量review AI的产出还消耗了不少脑力导致整体产出倒退

十倍是扯了点 那丢给你五人份的工作你应该非常轻松还可以偷懒囉?

已经很多人发现使用AI反而造成整体产出下降 你越仰赖 vibe coding 你对专案程式码的熟悉度就会越来越低 甚至你不会记得最近三天新加入的函数有哪些 你会感觉有个公用函数好像之前才写过但你不确定放在哪个档案 你跟AI一样有失忆现象最后造成专案里类似功能的函数到处都是

cursor+gpt5+大量project rules+FP应该算是目前vibe coding的最顶级combo，便宜好用又不会乱写

Claude现在还可以帮你执行命令，看build error，下gdb，callstack直接看，log印成档案后直接看档案，确实不太需要review AI产生的代码了。真要review再新开一个task叫AI review要预防失忆现象，要写MD档，甚至AI改完code后可以叫他改写MD档两边align

推实验精神

“类似功能的函数到处都是” 这是一个很大的问题吗？如果不影响专案进行，这问题根本没差。利大于弊，除非嵌入式斤斤计较空间，但嵌入式通常repo不会很大，AI更容易处理

可以在研究一下context engineering，启用一个agent去审有模板货文档，也不会有风格偏差太大的问题

要写README.md，写了就不太会失忆了https://youtu.be/sOvi9Iu1Dq8?si=ajHBx8JZe-eLYZ7_

其实你这样的需求也不明确 也没定义清楚 虽然说中大型 要多大才叫中大型？ 现在小型专案确实已经可以完全不看程式码完成整个产品 但小型是多小型？会不会过阵子 其实已经可

十倍当然不夸张啊，原本一小时才能解完的bug，五分钟AI就解完了？那不就十倍？

以做到完全不看程式码开发一整个电商系统 但又会抱怨电商根本就中小型专案 难道AI能让我Vibe Coding出google搜寻引擎或整个脸书吗？我觉得喇 怎么样都可以打脸的理由 没有讨论的价值等到哪天真的能vibe出一个搜寻引擎 又会说 啊是能让我vibe出一个ChatGPT吗？如果不定义标准 AI永远不可能满足

AI都拿了诺贝尔化学奖和数奥金牌了，写程式真的小菜一碟

专案的性质也差很多 vibe一个部落格 跟vibe一个3D游戏引擎或跟vibe一个给客户用的SDK 是完全不一样的事 每一种类型也都可大可小 不定义清楚很难说vibe没什么用实际上我就亲身遇过业主没有任何背景程式 vibe出一个算法系统来帮忙处理公司内数据 他一行程式码都看不懂 程式码也没给任何工程师审查过 就他自己做的工具 但运作非常好

看不懂没差啦，llm的开发人员也说过他们也看不懂现在llm的程式码了

整个系统大概一万多行 这算大 还是小

https://i.imgur.com/JTbzC9p.jpegAI开发者自己对AI模型都无法掌握了，看不懂正常

不可解释性以及深度学习领域很多新方法难以解释，这跟你做资讯系统但不懂其中的程式码那是完全两回事vibe coding 在你只需要一个蛋糕的时候没有任何问题，他是一个蛋糕而且还不错，当你的客户说我的蛋糕这边那边一定要如何如何的时候，就开始有问题了

其实我看不懂你的蛋糕比喻XD“这边一定要如何如何”这对AI来说很难吗？

很难，因为你没办法在不提供明确指令的情况下让AI满足你，而你如果明确的给出所有需求，那你只是在换个语言coding

www

程式的确就是对于现实的事物或概念进行描述 要越细致 就要描述的越仔细 自然语言本身是很模糊的 要细节那自然语言也要跟着写到很细 那还是在写程式 只是程式语言变成英文？

就像关键字 let 一样。就是个很英文式的程式语法foreach a in group 这个演化也很英文

AI开发者都对AI无法掌握喔@@

给楼上, 模型研发并不像资讯系统, 你把需求跟规格列出来我们照着开发就会有进展就算你去读了论文告诉你 OO 机制有什么效果 你也无法预期引入那个机制对你的模型表现能提升多少 甚至未必是提升当模型产出你不要的结果, 你没办法印出热力图然后就说啊, 这就是因为怎样怎样 所以我们只要这样改就可以解决不 没有办法 所以才需要每年烧数十亿美金但你不知道我们会不会有造出AGI的一天 你只能相信再给他几年他会更好

要完全符合vibe那肯定没办法，现在搞的东西就是contextwindow太小，要用程式去另外解决，可以参考:www.anthropic.com/engineering/multi-agent-research-system，可以参考anthropic的做法，说实话也不是给小白去vibe

可以理解现在的业主会想移除软件建置成本让AI自动生成，听起来快又有效但是就是那个但是没有程式背景的人根本分不出来AI唬烂所以.....就这样而到时候软件工程师早就进化成另类驯兽师变成只会有更多的驯兽师要养

对我来说就是可以专注在逻辑和结构，末梢程式码可以快速tab解

推jej

推

推

前面都蛮正常的 最后一段的比喻很恶

最大的问题是记忆力 过了几个问题就会忘了前面一些细节偏偏细节错人要花更多时间找出来当工具用可以 当伙伴用你会累死

还好我同事的记忆力比AI还差

你讲那么多，那些外行一样看热闹啦

跟我使用github copilot的感想一致，推

推。

最后一段很到位了

问题不是context window大小，而是context大了会有回弹

推

拆分小小的 一步一步慢慢完成

ai 生成不确定可以多问几个比较 甚至把回答贴给另一个问

哇 这篇含金量真不错

推