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是有帮助的，但真的限定在某些非常特定情况。

我觉得体感会声称增加生产力。来自于好像变轻松，不用动脑细胞，去刁那一个逻辑符号但有一情况是，速度快了之后剩下来的是更多的闲置时间或是更多的推倒重来的次数游戏产业发生过工具革新，结果都是更高更大更久的案子因为工具越强大，越轻松，规划的人反而越放松。如果应用在对于新创，本来就是不断pivot转向是好事。应用在一些大型案子难找的臭虫也应该很有帮助但大多数的“一般”状况，反复消耗的时间可能刚好抵销加速最后推论还是大PM全端时代，不只是工程师进化，而是连带需求端的人都得改变工作模式。

应该是，人都是乐观的，所以我们评估都是乐观的。看到ai产出程式码，我们就觉得很有生产力。但实际解决任务的时间，就整体开发时间，其实不但没变短反而变长。就我个人不科学的观察，整体来讲ai真的是帮倒忙。两，三年的实验经验下来，对ai短期能够大突破，没有信心。

一种猜测是，瓶颈不在生产就会跑到其他地方，结果还是卡在某个地方。（某个环节没有一起更新，整体还是快不起来）大PM全端，脑机接口赛博飞升，选我正解

和AI一起搞半天，什么都搞不出来，一怒之下自己写，结果一小时就完成惹

会不会其实根本不会用？或是没用过无上限Claude Code

我也觉得是不会用。Claude code 真的很强

楼上的图是真实使用经验, 目前对程式领域来讲会浪费时间

我觉得这跟prompt技巧和专案多大有很大关系有时得把东西讲得详细 再带商务逻辑下去慢慢雕code可能 直接写比较快...

参与的人，prompt水准都很高。有的人cursor经验很少，但screencast都有留下来研判，这不是问题。其实问题就是，需要一直reprompt，花太多时间在这。code复杂时，失败率高。其实paper讲很多，有兴趣可以判读

觉得这是做研究硬用吧，一般开发哪那么头铁跟ai 耗

看人，懂用 AI 的，会知道哪部份可以丢给 AI 处理效率更高，但一定有那种什么东西都喂 AI，这也就算了，出来的东西还不验证就想拿来用... 后面收尾就浪费一堆时间。

当然会 我不发表其它言论就是了

同VL大看法 要知道AI的优势跟劣势 尽量擅用AI的优点让它做一些重复的无聊杂事 把时间拿来思考规划如果什么都要让AI思考 那很容易只会得到一坨大便

如果IT越变越懒还是外包,歪包都大头说的算确实perf没多好AI又不见得会帮你拆解问题跟做实验 说能全取代是记者说的有问题请去问记者

最近才经历一个bug丢AI解不出来，但手动debug后20分钟就发现问题

我给AI产单元测试省我不少时间

用了一阵子 roo code 上 claude 4.5 真心觉得 Claude才是 AI 开发流的唯一解 但是实在是太贵了Cursor 用 Claude 到限流才会去使用Cursor 默认的128 k token 对于中小专案还堪用大专案 + 非 Claude 的model 会改出一些很奇怪的东西用 AI 开发流，要一直在成本跟效能之间找平衡

我觉得应该用今年五月开始的AI作为一个标准。那个时间点从开始每一家都进步非常多。 二三月时我给他开发不如自己写

这个来源怀疑他们不会用……就……

当初的期待是2x~20x的生产力，今天最好的状况是1.1x甚至

其实每种专案领域适用 AI 的程度也不一样有些部分我会用 AI，有些部分直接跳过对我来说自己肉身生产力的瓶颈是认知负荷AI 帮我干掉细节，我只需要 review，我当日的天花板就上升再来就是 AI 产出的内容总是要在某个地方 review如果你资深，看一眼就知道问题，那产出当下就 review 最好再往后退就是用其他手段 QA，也是有人这样做但要守得好也是要花很多心力建置测试体系如果都不 review 就是埋地雷，等它哪天炸给你看如果体感 AI 帮不上忙，那可能你工作内容真的 AI 扛不起来有听过不少公司 AI 专门拿来写 PoC / demo 的

推 lance , 我觉得也是进步迭代太快的缘故差一个月整个世界就不一样很多公司都在拼下一个世代的开发方法而且生怕别人抢先 所以有什么料就赶快推出来抢市占了

应该要细看：如果是复杂大系统，需求都没有规格书，AI 对使用者下的promot 通常都在通灵 ，AI 只能协助拼拼凑凑；如果是几乎从0写的，甚至有规格书，那AI 的帮助就会是倍数

AI真能省时 但只能省简单常写的复杂到用文字难以形容的逻辑 我自己写还快一点

我觉得是大家还在摸索新的协作模式，现在都还是在现有的工作流程硬套AI 辅助 效率的枷锁在人啊

叫AI写扣其实跟带小开发团队很像，下的指令与需求，会被怎么解读跟实作成跟规划者预期的一样，会是更优化，能够一次到位还是得反复调整，整个生产力差太多了。

每个人都觉得自己很会用 ai，事实就是一堆人不会用，反而靠ai制造技术债的速度提升了好几倍，你少数人再厉害根本解不掉ai现在最大的问题就是学不会偷懒 对它来说改十行跟改一行差不多 加上一段其实没用处的 code 也差不多 人不把关整个程式库的复杂度就不断上升

其实楼上这问题,也可以叫 AI 解决, 用 AI 去清理纯人工旧专案,那种"前人做的就不要动"的 code 还更多

光不用再写测试跟文件爽到有剩

ai还在进步

目前把ai当提示符号比较妥当，当解决方式会被牵着鼻子走