作者oopFoo (3d)
看板Soft_Job
标题[讨论] 2025初的AI工具实际上会降生产力
时间Fri Jul 11 15:04:05 2025
https://secondthoughts.ai/p/ai-coding-slowdown
ycombinator 的讨论
https://news.ycombinator.com/item?id=44526912
其实都是讨论这篇，"衡量 2025 年初人工智慧对经验丰富的开源开发人员生产力的影响 "。
https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/
ycombinator 的讨论
https://news.ycombinator.com/item?id=44522772
full paper
https://metr.org/Early_2025_AI_Experienced_OS_Devs_Study.pdf
看讨论，蛮有趣，各种理由解释或不信。
但这研究还蛮紮实的。16个人，246个任务。
https://i.meee.com.tw/dkmxs57.png
很有趣的是，每个人都预估生产力有增加，包含开发者本身。开发者写完後还是认为生产力有增加，但实际生产力是下降的。
个人是ai是有帮助的，但真的限定在某些非常特定情况。
--
※ 发信站: 批踢踢实业坊(ptt.cc), 来自: 36.224.192.162 (台湾)
※ 文章网址: https://webptt.com/cn.aspx?n=bbs/Soft_Job/M.1752217454.A.82F.html
※ 编辑: oopFoo (36.224.192.162 台湾), 07/11/2025 15:05:56
1F：推 NDark: 我觉得体感会声称增加生产力。 07/11 16:25
2F：→ NDark: 来自於好像变轻松，不用动脑细胞，去刁那一个逻辑符号 07/11 16:27
3F：→ NDark: 但有一情况是，速度快了之後剩下来的是更多的闲置时间 07/11 16:28
4F：→ NDark: 或是更多的推倒重来的次数 07/11 16:28
5F：→ NDark: 游戏产业发生过工具革新，结果都是更高更大更久的案子 07/11 16:30
6F：→ NDark: 因为工具越强大，越轻松，规划的人反而越放松。 07/11 16:31
7F：→ NDark: 如果应用在对於新创，本来就是不断pivot转向是好事。 07/11 16:32
8F：推 NDark: 应用在一些大型案子难找的臭虫也应该很有帮助 07/11 16:34
9F：→ NDark: 但大多数的“一般”状况，反覆消耗的时间可能刚好抵销加速 07/11 16:35
10F：推 NDark: 最後推论还是大PM全端时代，不只是工程师进化，而是连带需 07/11 16:40
11F：→ NDark: 求端的人都得改变工作模式。 07/11 16:40
12F：→ oopFoo: 应该是，人都是乐观的，所以我们评估都是乐观的。看到ai 07/11 16:51
13F：→ oopFoo: 产出程式码，我们就觉得很有生产力。但实际解决任务的时间 07/11 16:51
14F：→ oopFoo: ，就整体开发时间，其实不但没变短反而变长。 07/11 16:52
15F：→ oopFoo: 就我个人不科学的观察，整体来讲ai真的是帮倒忙。两，三 07/11 16:55
16F：→ oopFoo: 年的实验经验下来，对ai短期能够大突破，没有信心。 07/11 16:56
17F：推 NDark: 一种猜测是，瓶颈不在生产就会跑到其他地方，结果还是卡在 07/11 17:00
18F：→ NDark: 某个地方。（某个环节没有一起更新，整体还是快不起来） 07/11 17:00
19F：→ NDark: 大PM全端，脑机介面赛博飞升，选我正解 07/11 17:02
20F：推 wei115: 和AI一起搞半天，什麽都搞不出来，一怒之下自己写，结果 07/11 17:19
21F：→ wei115: 一小时就完成惹 07/11 17:19
22F：推 jack529: 会不会其实根本不会用？或是没用过无上限Claude Code 07/11 18:08
23F：→ FrAnKw: 我也觉得是不会用。Claude code 真的很强 07/11 18:27
25F：推 sunsamy: 楼上的图是真实使用经验, 目前对程式领域来讲会浪费时间 07/11 18:41
26F：推 Ekmund: 我觉得这跟prompt技巧和专案多大有很大关系 07/11 19:00
27F：→ Ekmund: 有时得把东西讲得详细 再带商务逻辑下去慢慢雕code 07/11 19:00
28F：→ Ekmund: 可能 直接写比较快... 07/11 19:00
29F：→ oopFoo: 参与的人，prompt水准都很高。有的人cursor经验很少，但 07/11 20:53
30F：→ oopFoo: screencast都有留下来研判，这不是问题。其实问题就是，需 07/11 21:00
31F：→ oopFoo: 要一直reprompt，花太多时间在这。 07/11 21:02
32F：→ oopFoo: code复杂时，失败率高。其实paper讲很多，有兴趣可以判读 07/11 21:05
33F：→ twistfist: 觉得这是做研究硬用吧，一般开发哪那麽头铁跟ai 耗 07/11 21:30
34F：→ VL1003: 看人，懂用 AI 的，会知道哪部份可以丢给 AI 处理效率更高 07/11 23:43
35F：→ VL1003: ，但一定有那种什麽东西都喂 AI，这也就算了，出来的东西 07/11 23:44
36F：→ VL1003: 还不验证就想拿来用... 後面收尾就浪费一堆时间。 07/11 23:44
37F：→ superpandal: 当然会 我不发表其它言论就是了 07/12 00:42
38F：→ VScode: 同VL大看法 要知道AI的优势跟劣势 尽量擅用AI的优点 07/12 00:58
39F：→ VScode: 让它做一些重覆的无聊杂事 把时间拿来思考规划 07/12 00:59
40F：→ VScode: 如果什麽都要让AI思考 那很容易只会得到一坨大便 07/12 00:59
41F：→ dildoe: 如果IT越变越懒还是外包,歪包都大头说的算确实perf没多好 07/12 03:56
42F：→ dildoe: AI又不见得会帮你拆解问题跟做实验 说能全取代是记者说的 07/12 03:58
43F：→ dildoe: 有问题请去问记者 07/12 03:58
44F：推 windmagic: 最近才经历一个bug丢AI解不出来，但手动debug後20分钟 07/12 05:28
45F：→ windmagic: 就发现问题 07/12 05:28
46F：推 devilkool: 我给AI产单元测试省我不少时间 07/12 23:29
47F：推 acgotaku: 用了一阵子 roo code 上 claude 4.5 真心觉得 Claude 07/12 23:47
48F：→ acgotaku: 才是 AI 开发流的唯一解 但是实在是太贵了 07/12 23:48
49F：→ acgotaku: Cursor 用 Claude 到限流才会去使用 07/12 23:49
50F：→ acgotaku: Cursor 预设的128 k token 对於中小专案还堪用 07/12 23:51
51F：→ acgotaku: 大专案 + 非 Claude 的model 会改出一些很奇怪的东西 07/12 23:52
52F：→ acgotaku: 用 AI 开发流，要一直在成本跟效能之间找平衡 07/12 23:56
53F：推 lance70176: 我觉得应该用今年五月开始的AI作为一个标准。 07/13 06:04
54F：→ lance70176: 那个时间点从开始每一家都进步非常多。 二三月时我给 07/13 06:04
55F：→ lance70176: 他开发不如自己写 07/13 06:04
56F：推 Romulus: 这个来源怀疑他们不会用……就…… 07/13 06:27
57F：→ oopFoo: 当初的期待是2x~20x的生产力，今天最好的状况是1.1x甚至 07/13 08:10
58F：→ oopFoo: 倒退。让agent自己在我电脑胡搞，这个红线我踩的很死，NO 07/13 08:12
59F：→ oopFoo: prompt，context engineering，各种best practices都试了 07/13 08:14
60F：→ oopFoo: 这两年，所谓的突破，我是没看到，有进步，但实在有限，最 07/13 08:15
61F：→ oopFoo: 大的进步是context window大很多真的是比较好做事。 07/13 08:17
62F：推 CRPKT: 其实每种专案领域适用 AI 的程度也不一样 07/13 09:00
63F：→ CRPKT: 有些部分我会用 AI，有些部分直接跳过 07/13 09:01
64F：→ CRPKT: 对我来说自己肉身生产力的瓶颈是认知负荷 07/13 09:02
65F：→ CRPKT: AI 帮我干掉细节，我只需要 review，我当日的天花板就上升 07/13 09:03
66F：→ CRPKT: 再来就是 AI 产出的内容总是要在某个地方 review 07/13 09:04
67F：→ CRPKT: 如果你资深，看一眼就知道问题，那产出当下就 review 最好 07/13 09:05
68F：→ CRPKT: 再往後退就是用其他手段 QA，也是有人这样做 07/13 09:06
69F：→ CRPKT: 但要守得好也是要花很多心力建置测试体系 07/13 09:06
70F：→ CRPKT: 如果都不 review 就是埋地雷，等它哪天炸给你看 07/13 09:07
71F：推 CRPKT: 如果体感 AI 帮不上忙，那可能你工作内容真的 AI 扛不起来 07/13 09:09
72F：→ CRPKT: 有听过不少公司 AI 专门拿来写 PoC / demo 的 07/13 09:10
73F：推 NDark: 推 lance , 我觉得也是进步迭代太快的缘故 07/13 10:51
74F：→ NDark: 差一个月整个世界就不一样 07/13 10:51
75F：→ NDark: 很多公司都在拚下一个世代的开发方法 07/13 10:52
76F：→ NDark: 而且生怕别人抢先 所以有甚麽料就赶快推出来抢市占了 07/13 10:52
77F：推 alihue: 应该要细看：如果是复杂大系统，需求都没有规格书，AI 对 07/13 10:54
78F：→ alihue: 使用者下的promot 通常都在通灵 ，AI 只能协助拼拼凑凑； 07/13 10:54
79F：→ alihue: 如果是几乎从0写的，甚至有规格书，那AI 的帮助就会是倍 07/13 10:54
80F：→ alihue: 数 07/13 10:54
81F：推 O187: AI真能省时 但只能省简单常写的 07/13 11:33
82F：→ O187: 复杂到用文字难以形容的逻辑 我自己写还快一点 07/13 11:33
83F：推 hooll111: 我觉得是大家还在摸索新的协作模式，现在都还是在现有的 07/13 13:20
84F：→ hooll111: 工作流程硬套AI 辅助 效率的枷锁在人啊 07/13 13:20
85F：推 TAKADO: 叫AI写扣其实跟带小开发团队很像，下的指令与需求，会被怎 07/13 14:57
86F：→ TAKADO: 麽解读跟实作成跟规划者预期的一样，会是更优化，能够一次 07/13 14:57
87F：→ TAKADO: 到位还是得反覆调整，整个生产力差太多了。 07/13 14:57
88F：推 lturtsamuel: 每个人都觉得自己很会用 ai，事实就是一堆人不会用， 07/13 20:13
89F：→ lturtsamuel: 反而靠ai制造技术债的速度提升了好几倍，你少数人再 07/13 20:14
90F：→ lturtsamuel: 厉害根本解不掉 07/13 20:14
91F：推 lturtsamuel: ai现在最大的问题就是学不会偷懒 对它来说改十行跟改 07/13 20:18
92F：→ lturtsamuel: 一行差不多 加上一段其实没用处的 code 也差不多 人 07/13 20:18
93F：→ lturtsamuel: 不把关整个程式库的复杂度就不断上升 07/13 20:18
94F：→ acgotaku: 其实楼上这问题,也可以叫 AI 解决, 用 AI 去清理纯人工 07/14 02:26
95F：→ acgotaku: 旧专案,那种"前人做的就不要动"的 code 还更多 07/14 02:27
96F：推 Boska: 光不用再写测试跟文件爽到有剩 07/14 03:20
97F：→ greenx: ai还在进步 07/14 09:40
98F：→ jen1121: 目前把ai当提示符号比较妥当，当解决方式会被牵着鼻子走 07/24 23:46