作者SkankHunt42 (凯子爸)
看板Soft_Job
标题Re: [请益] 软体失业是迟早的事吧
时间Tue Aug 26 19:43:34 2025
※ 引述《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女优一样，像我就觉得脸蛋漂亮很重要，奶小没关系，像希岛爱里这样
有人就觉得奶大很重要、假奶没关系，但一定要奶大，像楪可怜这样
也有人坚持一定要真奶、不要人造人，这种人去看楪可怜就只会看到楪可怜的缺点
祝大家在喜欢的女优引退後都能找到自己喜欢的新人女优
--
※ 发信站: 批踢踢实业坊(ptt.cc), 来自: 146.70.205.94 (日本)
※ 文章网址: https://webptt.com/cn.aspx?n=bbs/Soft_Job/M.1756208616.A.A0E.html
1F：推 ayasedd: 最屌的还是看到开始有人做出了 H 奶 30kg，一边单眼皮一 08/26 19:50
2F：→ ayasedd: 边双眼皮，然後说因为看习惯 30cm，所以也要加上 30cm， 08/26 19:50
3F：→ ayasedd: 变成一个每个细节都很屌，但整体不知道到底在干嘛 08/26 19:50
4F：推 newhandfun: 前面一堆叫骂声势浩大 08/26 20:16
5F：→ newhandfun: 认真讨论的文却乏人问津 08/26 20:16
6F：→ newhandfun: 好啦话说回来，我同意这篇文的部分观点 08/26 20:20
7F：→ newhandfun: 会出现很多冗余的参数跟没必要的流程 08/26 20:20
8F：→ holebro: 完全不管code太理想 但不追求什麽良好设计这种方法倒是 08/26 21:46
9F：→ holebro: 堪用了 08/26 21:46
10F：→ ybite: 我自己也认为「AI要好维护前提是人也好维护」 08/26 22:29
11F：→ ybite: 毕竟正如大家的观察 Context大小就是很现实的技术极限 08/26 22:30
12F：推 leonardo0917: 结论很赞 08/26 22:54
13F：推 ikachann: 设计差 效能烂 实务上的确不是最重要的，能符合需求的产 08/27 01:00
14F：→ ikachann: 出才是真正有价值的地方 08/27 01:00
效能的好坏在实务上是不是最重要的，这点我认为因场景还有阶段而异。
我自己是做桌面应用程式+3D软体出身的，你光是一个button按下去卡顿QA就要来靠北了
这个道理也同样适用於後端，最後到商业上效能一样是用户体验与成本的处方
15F：推 viper9709: 看起来不如自己写比较快... 08/27 01:14
我自己写是不可能那麽快的，方方面面都是。
就算把AI犯的错误与修正指示、AI修改的时间算进去，还是远比我一个人开发快。
你要当成你在带好几个有时会懒惰会犯错的junior。
包含我自己与许多在网路上看到的感想，共同心得都是AI开发的瓶颈现在其实是在
人的量能不够。我一天要测试、review的量，其实资讯量是远比传统开发高的。
我Max 5x时段内额度用尽，我通常也很疲劳了。
当然素人现在vibe coding很爽，是因为他们也看不出(或是说不在乎也不知道有哪
些问题)，加上他们的专案规模都小或说规格都很常见，所以不会发生问题，过程当
然也很轻松愉悦
16F：推 sunsamy: 刚刚试了vibe coding，连最简单的outlook 2007 pop3 08/27 01:32
17F：→ sunsamy: 同步删掉Gmail的信件都在胡说八道， 08/27 01:33
18F：→ sunsamy: 浪费我的时间，这是怎麽vibe coding啦 08/27 01:33
19F：→ sunsamy: 话说有人懂吗？我Gmail已经爆了,现在来跟你们vibe coding 08/27 01:35
20F：→ sunsamy: 可能比较靠谱 08/27 01:35
21F：推 sunsamy: 感觉vibe coding这词跟敏捷这词一样是个唬烂的同意词 08/27 01:37
※ 编辑: SkankHunt42 (146.70.205.188 日本), 08/27/2025 02:07:40
22F：→ saladim: 蛮赞同这篇的过程跟感想的 对於有生命期的产品vibe codin 08/27 02:28
23F：→ saladim: 终究会带来不可承受的负担 更别说要规格业务逻辑的一致性 08/27 02:30
24F：→ saladim: 不过有人说要换个想法 对於每次功能的变动 乾脆直接重新 08/27 02:31
25F：→ saladim: 全部重头产生程式码 这也不大合理 最多只能部分codebase 08/27 02:33
26F：→ saladim: 让AI完全重新产生码出来 但是就我的实际经验连个稍微长一 08/27 02:34
27F：→ saladim: 点的演算法或是处理程序 都没办法一次'功能'到位 觉得 08/27 02:35
28F：→ saladim: vibe coding只能用在小型专案上面 我现在也只是拿来产生 08/27 02:36
29F：→ saladim: script跟很简单的工作上的资料pipeline 08/27 02:37
30F：推 strlen: vibe coding这词也才出来半年多 当然现主时没办法完全不看 08/27 02:56
31F：→ strlen: code很正常R 你给他再5年试试看 08/27 02:56
32F：→ strlen: 中大型专案随着context window越来越大 迟早能整个吞下去 08/27 02:57
我不对还没发生的改变做评论。
就跟Steam玩家不会因为你DLC、免费更新大饼画得很饱满就给你为了财报数字赶工上
架的半成品好评一样。
我抛砖引玉期望的是大神跳上来打脸我说：
「你根本不会用AI，用下面几个流程与方法我能达到完全不看程式码又稳健的开发」
这种交流才是对开发社群有助益的实质讨论。
33F：推 qqqlll666: Llm目前就是当外部顾问 临时工用 他没办法了解专案或 08/27 05:32
34F：→ qqqlll666: 团队文化等等隐性知识 就像请一个外部技术专家来 也不 08/27 05:32
35F：→ qqqlll666: 可能三言两语就上手完成任务 所以别期待AI可以帮你完 08/27 05:32
36F：→ qqqlll666: 成一切 08/27 05:32
37F：→ qqqlll666: 理想情况是在请他做事时一边建立文件 建立测试 把隐形 08/27 05:32
38F：→ qqqlll666: 知识转成显性 但这就像带新人一样 短期没回报 长期也 08/27 05:32
39F：→ qqqlll666: 不一定利己 最後说不定是让自己失业 08/27 05:32
他写文件跟测试是真的很方便。我现在连commit message都懒得自己写。
40F：→ Ekmund: 多少还是需要祖传md 08/27 09:23
我的观察，claude偶尔会做太high忘记CLAUDE.md的规则。
※ 编辑: SkankHunt42 (146.70.205.92 日本), 08/27/2025 10:45:26
41F：推 ZSZ1210: 推！很赞同这篇的过程和想法 最近刚好也一直在玩这块 08/27 10:43
42F：→ ZSZ1210: 目前在想透过micro service+DDD开发手法，每个领域都用 08/27 10:44
43F：→ ZSZ1210: repository切开，减少AI每次需要学习和需要记忆的量 08/27 10:46
44F：→ ZSZ1210: 目前是每个repository底下都放一个md在试试看～ 08/27 10:47
45F：→ ZSZ1210: 请问大大是用claude还是gemini啊？ 08/27 10:47
46F：推 yamakazi: YT搜寻Claude就好，已经开始有一堆人讲解怎麽用。我用起 08/27 11:26
47F：→ yamakazi: 来效率乘十倍不夸张 08/27 11:26
48F：推 brucetu: 十倍 哈哈哈 你三天就做完以前一个月的专案进度了吗 08/27 11:42
49F：→ brucetu: 还是写扣的速度快了十倍但写扣只占工作的一小部分 其实 08/27 11:44
50F：→ brucetu: 整体产出根本也没提升多少 同时每天大量review AI的产出 08/27 11:44
51F：→ brucetu: 还消耗了不少脑力导致整体产出倒退 08/27 11:44
52F：推 jamesho8743: 十倍是扯了点 那丢给你五人份的工作你应该非常轻松 08/27 11:46
53F：→ jamesho8743: 还可以偷懒罗? 08/27 11:46
54F：→ brucetu: 已经很多人发现使用AI反而造成整体产出下降 你越仰赖 vib 08/27 11:48
55F：→ brucetu: e coding 你对专案程式码的熟悉度就会越来越低 甚至你不 08/27 11:48
56F：→ brucetu: 会记得最近三天新加入的函数有哪些 你会感觉有个公用函 08/27 11:48
57F：→ brucetu: 数好像之前才写过但你不确定放在哪个档案 你跟AI一样有 08/27 11:48
58F：→ brucetu: 失忆现象最後造成专案里类似功能的函数到处都是 08/27 11:48
我没有做量化分析，加上样本数只有我自己，所以我也无意讨论到底是几倍，这都是
体感问题。
我原文的焦点其实只有一个问题「在
现阶段是否可以
完全忽略程式码进行开发」
如果你本身是一个经验丰富的工程师，当然可以透过各种工作流与指令的设计、对
codebase的理解加以推进这个过程。但我认为这并不符合宣传中所谓「理想中的vibe
coding」的模式
59F：推 Kasima: cursor+gpt5+大量project rules+FP应该算是目前vibe codi 08/27 12:17
60F：→ Kasima: ng的最顶级combo，便宜好用又不会乱写 08/27 12:17
61F：推 yamakazi: Claude现在还可以帮你执行命令，看build error，下gdb， 08/27 13:18
62F：→ yamakazi: callstack直接看，log印成档案後直接看档案，确实不太需 08/27 13:18
63F：→ yamakazi: 要review AI产生的代码了。真要review再新开一个task叫A 08/27 13:18
64F：→ yamakazi: I review 08/27 13:18
65F：→ yamakazi: 要预防失忆现象，要写MD档，甚至AI改完code後可以叫他改 08/27 13:19
66F：→ yamakazi: 写MD档两边align 08/27 13:19
67F：推 yamakazi: 直接改档案直接跑，你只要按确认就好，连复制贴上都不用 08/27 13:23
你说的似乎没有超出我的认知。
68F：推 duitub: 推实验精神 08/27 13:23
69F：→ yamakazi: 「类似功能的函数到处都是」 这是一个很大的问题吗？如 08/27 13:25
70F：→ yamakazi: 果不影响专案进行，这问题根本没差。利大於弊，除非嵌入 08/27 13:25
71F：→ yamakazi: 式斤斤计较空间，但嵌入式通常repo不会很大，AI更容易处 08/27 13:25
72F：→ yamakazi: 理 08/27 13:25
73F：→ Suleika: 可以在研究一下context engineering，启用一个agent去审 08/27 13:28
74F：→ Suleika: 有模板货文档，也不会有风格偏差太大的问题 08/27 13:29
你跟yamakazi说的方法其实我都试过，甚至写在内文。
这原则上就是指定AI去阅读某份module或文件，不管是全自动还是手动命令的形式。
AI自动循环更新文件→改程式→更新文件的模式我当也试过。
这种方法在一定规模内有用，但一旦内容太多对AI就会变成一种干扰。
当然如果你token额度很大可以整个context都塞进去也没问题。
75F：推 yamakazi: 要写README.md，写了就不太会失忆了 08/27 13:31
77F：→ strlen: 其实你这样的需求也不明确 也没定义清楚 虽然说中大型 要 08/27 13:33
78F：→ strlen: 多大才叫中大型？ 现在小型专案确实已经可以完全不看程式 08/27 13:34
79F：→ strlen: 码完成整个产品 但小型是多小型？会不会过阵子 其实已经可 08/27 13:34
80F：推 yamakazi: 十倍当然不夸张啊，原本一小时才能解完的bug，五分钟AI 08/27 13:34
81F：→ yamakazi: 就解完了？那不就十倍？ 08/27 13:34
82F：→ strlen: 以做到完全不看程式码开发一整个电商系统 但又会抱怨电商 08/27 13:35
83F：→ strlen: 根本就中小型专案 难道AI能让我Vibe Coding出google搜寻引 08/27 13:35
84F：→ strlen: 擎或整个脸书吗？我觉得喇 怎麽样都可以打脸的理由 没有讨 08/27 13:36
85F：→ strlen: 论的价值 08/27 13:36
86F：→ strlen: 等到哪天真的能vibe出一个搜寻引擎 又会说 啊是能让我vibe 08/27 13:36
87F：→ strlen: 出一个ChatGPT吗？如果不定义标准 AI永远不可能满足 08/27 13:37
88F：推 yamakazi: AI都拿了诺贝尔化学奖和数奥金牌了，写程式真的小菜一碟 08/27 13:38
89F：→ strlen: 专案的性质也差很多 vibe一个部落格 跟vibe一个3D游戏引擎 08/27 13:40
90F：→ strlen: 或跟vibe一个给客户用的SDK 是完全不一样的事 每一种类型 08/27 13:40
91F：→ strlen: 也都可大可小 不定义清楚很难说vibe没什麽用 08/27 13:41
欢迎你根据自己的定义、使用经验与观察与回文。
我可以补充一些我专案的数据：
程式码行数不含CSS一共有21000行，其中8700行是test。
commit数量110个。
专案是DSL专用的WYSIWYG风格的编辑器。
而对vibe的定义我在开头也引述了Wiki的写法。
92F：→ strlen: 实际上我就亲身遇过业主没有任何背景程式 vibe出一个演算 08/27 13:41
93F：→ strlen: 法系统来帮忙处理公司内数据 他一行程式码都看不懂 程式码 08/27 13:42
94F：→ strlen: 也没给任何工程师审查过 就他自己做的工具 但运作非常好 08/27 13:43
95F：推 yamakazi: 看不懂没差啦，llm的开发人员也说过他们也看不懂现在llm 08/27 13:43
96F：→ yamakazi: 的程式码了 08/27 13:43
97F：→ strlen: 整个系统大概一万多行 这算大 还是小 08/27 13:43
99F：→ yamakazi: AI开发者自己对AI模型都无法掌握了，看不懂正常 08/27 13:46
100F：→ brucetu: 不可解释性以及深度学习领域很多新方法难以解释，这跟你 08/27 14:13
101F：→ brucetu: 做资讯系统但不懂其中的程式码那是完全两回事 08/27 14:13
102F：→ brucetu: vibe coding 在你只需要一个蛋糕的时候没有任何问题，他 08/27 14:16
103F：→ brucetu: 是一个蛋糕而且还不错，当你的客户说我的蛋糕这边那边一 08/27 14:16
104F：→ brucetu: 定要如何如何的时候，就开始有问题了 08/27 14:16
105F：推 yamakazi: 其实我看不懂你的蛋糕比喻XD 08/27 14:24
106F：推 yamakazi: 「这边一定要如何如何」这对AI来说很难吗？ 08/27 14:25
107F：→ brucetu: 很难，因为你没办法在不提供明确指令的情况下让AI满足你 08/27 14:26
108F：→ brucetu: ，而你如果明确的给出所有需求，那你只是在换个语言codin 08/27 14:26
109F：→ brucetu: g 08/27 14:26
110F：推 yamakazi: www 08/27 14:28
111F：→ strlen: 程式的确就是对於现实的事物或概念进行描述 要越细致 就要 08/27 15:08
112F：→ strlen: 描述的越仔细 自然语言本身是很模糊的 要细节那自然语言也 08/27 15:09
113F：→ strlen: 要跟着写到很细 那还是在写程式 只是程式语言变成英文？ 08/27 15:10
※ 编辑: SkankHunt42 (154.47.23.114 日本), 08/27/2025 15:56:53
114F：推 NDark: 就像关键字 let 一样。就是个很英文式的程式语法 08/27 15:52
115F：→ NDark: foreach a in group 这个演化也很英文 08/27 15:53
※ 编辑: SkankHunt42 (154.47.23.114 日本), 08/27/2025 16:07:52
116F：推 viper9709: AI开发者都对AI无法掌握喔@@ 08/27 16:25
117F：→ brucetu: 给楼上, 模型研发并不像资讯系统, 你把需求跟规格列出来 08/27 16:35
118F：→ brucetu: 我们照着开发就会有进展 08/27 16:35
119F：→ brucetu: 就算你去读了论文告诉你 OO 机制有什麽效果 你也无法预期 08/27 16:36
120F：→ brucetu: 引入那个机制对你的模型表现能提升多少 甚至未必是提升 08/27 16:36
121F：→ brucetu: 当模型产出你不要的结果, 你没办法印出热力图然後就说 08/27 16:38
122F：→ brucetu: 啊, 这就是因为怎样怎样 所以我们只要这样改就可以解决 08/27 16:38
123F：→ brucetu: 不 没有办法 所以才需要每年烧数十亿美金但你不知道 08/27 16:39
124F：→ brucetu: 我们会不会有造出AGI的一天 你只能相信再给他几年他会 08/27 16:40
125F：→ brucetu: 更好 08/27 16:40
126F：→ Suleika: 要完全符合vibe那肯定没办法，现在搞的东西就是context 08/27 19:38
127F：→ Suleika: window太小，要用程式去另外解决，可以参考: 08/27 19:39
128F：→ Suleika: www.anthropic.com/engineering/multi-agent-research-sy 08/27 19:41
129F：→ Suleika: stem，可以参考 08/27 19:42
130F：推 Suleika: anthropic的做法，说实话也不是给小白去vibe 08/27 19:45
131F：推 jej: 可以理解现在的业主会想移除软体建置成本 08/27 20:22
132F：→ jej: 让AI自动生成，听起来快又有效 08/27 20:22
133F：→ jej: 但是就是那个但是 08/27 20:22
134F：→ jej: 没有程式背景的人根本分不出来AI唬烂 08/27 20:22
135F：→ jej: 所以.....就这样 08/27 20:22
136F：→ jej: 而到时候软体工程师早就进化成另类驯兽师 08/27 20:24
137F：→ jej: 变成只会有更多的驯兽师要养 08/27 20:24
138F：推 crazwade: 对我来说就是可以专注在逻辑和结构，末梢程式码可以快 08/27 20:51
139F：→ crazwade: 速tab解 08/27 20:51
140F：推 viper9709: 推jej 08/28 00:56
141F：推 nashmvp: 推 08/28 06:12
142F：推 cjtv: 推 08/28 09:12
143F：嘘 nacy204327: 前面都蛮正常的 最後一段的比喻很恶 08/28 09:34
144F：推 gofigure: 最大的问题是记忆力 过了几个问题就会忘了前面一些细节 08/28 10:28
145F：→ gofigure: 偏偏细节错人要花更多时间找出来 08/28 10:28
146F：→ gofigure: 当工具用可以 当夥伴用你会累死 08/28 10:29
147F：推 gino0717: 还好我同事的记忆力比AI还差 08/28 11:11
148F：→ hobnob: 你讲那麽多，那些外行一样看热闹啦 08/28 13:18
149F：推 s9041200: 跟我使用github copilot的感想一致，推 08/28 17:10
150F：推 darkMood: 推。 08/28 17:44
151F：推 tzouandy2818: 最後一段很到位了 08/28 18:16
152F：推 dani1992: 问题不是context window大小，而是context大了会有回弹 08/28 19:06
153F：推 inte629l: 推 08/28 21:37
154F：→ molopo: 拆分小小的 一步一步慢慢完成 08/29 05:19
155F：推 awenracious: ai 生成不确定可以多问几个比较 甚至把回答贴给另一 08/29 12:43
156F：→ awenracious: 个问 08/29 12:43
157F：推 freeloop: 哇 这篇含金量真不错 08/30 11:06
158F：推 youcanfindit: 推 09/02 13:08