这是一个创建于 179 天前的主题，其中的信息可能已经有所发展或是发生改变。
请教一下各位大佬，使用 AI 编程工具，例如 cursor 、claude code 等，在实际工作中，帮助大家的工作效率提升了多少？
公司领导向其它公司调研的是 3-5 倍，最高 15 倍（具体场景未说明）
个人感觉提升 50%是有的
这个 3-5 倍，15 倍分别可能是哪种场景出现的？
请问这个效率提升是怎么计算的？
公司领导向其它公司调研的是 3-5 倍，最高 15 倍（具体场景未说明）
个人感觉提升 50%是有的
这个 3-5 倍，15 倍分别可能是哪种场景出现的？
请问这个效率提升是怎么计算的？
第 1 条附言 · 2025 年 7 月 22 日
看了一下大家的回复，效率提升百分比，3-5 倍，10 倍的都有
还有一个问题，各位大佬的公司，在个人效率提升几倍的基础上，有没有给大家增加工作量呢？
（我们领导调研之后，要求按照效率提升的比例，缩短工作量对应的完成时间）
还有一个问题，各位大佬的公司，在个人效率提升几倍的基础上，有没有给大家增加工作量呢？
（我们领导调研之后，要求按照效率提升的比例，缩短工作量对应的完成时间）
 |
1
sk217 2025 年 7 月 21 日
大概率是吹牛，AI 没那么神，LLM 你说穿了 也就是大数据算命，给你补足代码而已，能不能正确运行，运行了之后能不能不把屎山掀翻 是另外一回事了
|
 |
2
7gugu 2025 年 7 月 21 日
写小工具和写流水线的时候非常好用，能让 AI 快速帮你把框架搭建好。比如写 jenkins 的时候，不熟悉语法就可以把流程说给 AI ，让 AI 帮你实现，就可以剩下很多调试的时间。
|
 |
3
liuchenwei2000 2025 年 7 月 21 日
"他们搞了 AI 生成式代码，两个人弄得，开发项目又快又好，你们干的活，交给他们两个人比你们十个人都要好。"——我们领导说的
|
|
4
sk217 2025 年 7 月 21 日
个人感受以及案例
1. 小规模代码 AI 能运行的很好，特别是使用开源库方面， 昨天用 python + scapy 写了一个 mysql 的抓包分析工具，把包解析出来 sql ，然后 sql 格式化，第一版 AI 生成出来的很好用，但是很快发现 SQL 太长它就解析不出来，然后个人拿 wireshark 抓包折腾了一通，发现长 SQL 会被拆解成多个 TCP 包， 而最初 AI 写的代码是使用单个包做解析的，没有把 TCP 流重组串起来 发现原因之后写了提示词让 AI 把 TCP 抓的包，重新串起来，基本上 1 分钟完成，测试无 bug ，如果是人力完成的话，查资料调试代码可能需要 2-3 小时，因为我没有处理 TCP 流的经验 然后今天调试的时候 发现一些服务端发送过来的报文也会被莫名奇妙解析成 SQL ，写了提示词，让 cursor 把代码改成只解析本地 interface 发送出去的 TCP 数据包，1 分钟搞定，如果是我个人处理的话，需要大概 30 分钟去找 scapy 获取 interface ip 的 API ，然后加上一些逻辑处理 后续又想捕捉 redis 发送的命令，花了 1 分钟写提示词，大概 2 分钟就改好了，调试花了 20 分钟，如果是我个人开发的话，大概需要 2 个小时左右开发时间跟调试时间，关键是 API 跟 redis 的协议不熟悉 |
|
5
sk217 2025 年 7 月 21 日  5
@logic2 #4 AI 说到底还是一个能力放大器，如果你一开始不知道 tcp 是流的形式，可以在代码里面把 packet 重组，然后不会使用 wireshark 这种工具定位问题，你指望提示器帮你解决一切，跟指望大数据算命没啥区别，它讲到底还是基于数据驱动的概率模型，不是一个许愿机
|
 |
6
sampeng 2025 年 7 月 21 日
个人感觉：0%
但这个 0 不是意味着没有效率提升。而是看不见的东西提升了。 为什么呢。你写代码不是只是为了实现功能，要设计，要考虑，要文档，光写代码那是嗖嗖的。但是如果所有这些边缘的都要做。说实话：程序员最不喜欢的就是写文档，最讨厌的就是别人的代码没注释。 但有 AI 就不一样了，我强制自己按工程化的要求去做。其实是整体时间和自己实现一个功能是差不多的。不过，代价是什么呢？ - 充分的单元测试，覆盖率轻轻松松 100% - 复杂和详细的设计和实现过程文档 - 重要的代码有行级注释 如果不考虑这些。你公司怎么调研的 15 倍？有种用法是开 5 个以上的终端，同时做 5 个需求。如果要求工程质量，这就是个玩笑，如果不需要工程质量。。简直是魔法。 |
|
7
sk217 2025 年 7 月 21 日
另外在屎山代码场景下，AI 基本上无效，一堆乱七八糟的表结构+落后了不知道多少个版本的注释，连我自己都搞不明白前人写的东西，
你指望 AI+mcp 上下文提示词就能出活，那跟做梦没啥区别，而且前人写的业务代码，一个表上百个字段，10 几个字段标识一个订单的状态，DDL 跟代码里面的注释落后了好几个版本，你指望写几句提示词就能出一个业务逻辑正确的查询接口，跟许愿没啥区别， 关键我老板还对这个东西狂吹，说怎么怎么提升效率，实际上真的很有限，因为屎山代码问题太多，经常人自己都看糊涂了，明明字段 A 你以为他是做什么业务标识用的，然后你一看，历史上一直都把它当做另一个字段在用，而且想改还改不动，因为太多地方在用 |
 |
8
iOCZS 2025 年 7 月 21 日
没有 UI ，没有产品，没有代码。。。。什么都没有的时候，AI 能提供你要的 N 倍效率。
|
 |
9
mudssky 2025 年 7 月 21 日
业务代码效率提升 20%左右，但是额外帮你执行了单元测试，写文档和脚本。
|
 |
10
leon0903 2025 年 7 月 21 日
个人感觉十倍
|
 |
11
COW 2025 年 7 月 21 日
你能读懂 AI 的代码，那你说个几倍不过分，你看起来吃力甚至不理解，那后面维护的时候就有你受的了
|
 |
12
novojo 2025 年 7 月 21 日
如果你觉得 AI 增加了你的心智负担，那么就没有提高效率，如果你觉得 AI 减少了你的心智负担，那么就说明提高了效率。
|
 |
13
raycool 2025 年 7 月 21 日
比如现在把 python 的某些耗时的模块改写为 cython
使用 claude 效率提升非常大 |
 |
14
ranley123 2025 年 7 月 22 日 via iPhone
写代码的话，个人感觉提效 40%吧。
看代码的话，提效 5 倍（ cursor ），至少我用来看强化学习和一些大模型训练的框架的时候，这种代码其实挺晦涩难懂的，尤其是各种维度张量的拼接转换，是真的牛逼。其中的语义给你娓娓道来。 |
 |
15
mumbler 2025 年 7 月 22 日
50%是因为你还要写代码，试试完全给 AI 写，你只负责提供上下文，检查作业，15 倍轻轻松松
|
 |
16
ota 2025 年 7 月 22 日
效率和你的 prompt 有关。现在更多的是解构业务需求，如果你是 SE 的话，那么 AI 时代就是 1000%的效率了。一人旅团。
|
 |
17
bodayw 2025 年 7 月 22 日
最近还真的有人做了实验来研究这个：
https://bsky.app/profile/metr.org/post/3ltn3t3amms2x 至少在这个实验里，虽然阅读和搜索、写代码、测试和 debug 的时间缩短了，但检查 AI 输出、写 prompt 、等待 AI 输出的时间增加了，最终总体效果反而是更慢了。 |
|
18
sk217 2025 年 7 月 22 日
@bodayw 没毛病，这些作者都是开源库作者，他们的东西本身就不在语料库训练里面，大部分人是使用开源库的开发者，这些开发者对接口或者 API 的不了解 会大幅度降低他们的开发效率，而 AI 对这些开源库的 API 信手拈来
|
 |
19
mkt 2025 年 7 月 22 日
取决于怎么用，如果是全脱手，完完全全让 ai 动手。效率-10000+%
取个例子，我和开发说有 2 行字字体大小不一样，改个 size 几秒的事情，他用 ai 干了 1 礼拜，虽然做好了，但是整个页面代码都变了。 注意这是个真实例子 |
 |
20
happytaoer 2025 年 7 月 22 日
还是要看人，如果你是一个擅于对功能拆分解耦模块化的程序员，那么对你的提效至少有 5 倍以上。 对于那种不会模块化分组代码的程序员，一个文件上万行，一个函数几百行的程序员，提效甚微，甚至是负提效。
|
 |
21
yb2313 2025 年 7 月 22 日
目前来看快不快不一定, 但我体力肯定是节省出来了, 主观感受上是轻松的
|
 |
22
Xalen 2025 年 7 月 22 日
 每人配个 AI 工资是不是可以降 3-5 倍了。 |
 |
23
ZDaYu 2025 年 7 月 22 日
之前用 cursor 的时候不停的跟他口干舌燥的说，我现在使用 claude code 感觉还可以，效率是有一定的提升的，有些之前想不到解决方案 ai 也能想到，可能是我太菜了， 我估计对我而言有 百分之 70-80 吧，因为我我得工作不管是要开发写代码，还需要测试部署，，，，还需要好几个项目直接协调修改
|
 |
24
MoozLee 2025 年 7 月 22 日
对前端的提效可能有 2 倍，至少我们公司不会前端的后端可以用 ai 来完成前端的一些需求了。对后端可能就是负提效了，需要花更多的时间去看 ai 生成的代码是不是真的正确。
|
|
25
sk217 2025 年 7 月 22 日
@li746224 主要还是后台摸不着，历史屎山多，前端页面上，你生成一下，鼠标点击一下，观察一下，就知道是不是正确的，而后台的业务逻辑给你改了之后，你根本不知道是不是正确的
|
 |
26
scegg 2025 年 7 月 22 日
体力活方面 AI 效果好，比如包含下列情况的时候：
1 高度相似的代码段，比如手工为多个表或者业务场景写的 CRUD ；尤其是在重构的时候，也就是需要逐个方法按照统一的要求修改的时候。 2 注释完善时候的常用技术代码，比如前端一般性的代码编写。 3 常见的数据处理逻辑。 如果做算法，那靠 AI 还不如靠自己。 |
 |
27
xsen 2025 年 7 月 22 日
@logic2 #7 那是你用法不对。你先叫 ai 分析当前的代码，包括不限于业务流程、实现、技术方案、接口等，然后提出需求要 ai 给解决方案；方案评估好，就可以叫 ai 改
|
|
28
sk217 2025 年 7 月 22 日
@xsen
 兄弟，注释都落后了好几个版本了，字段名称也是乱的，你真的以为 AI 是智能的啊，而且这种你自己都搞不明白的情况，就算 AI 给你生成了，你敢用么？要花大量的时间去测试 验证， |
|
29
sk217 2025 年 7 月 22 日
@xsen 兄弟，我现在领导已经在鼓吹 AI 时代，代码可以随便复制了，什么以前的工程最佳实践在 AI 时代下遵守已经毫无意义了，反正大模型可以一下子帮你把重复的所有地方 给你一下子改一遍，你信么？
|
 |
31
Fastmail 2025 年 7 月 22 日
你要对汇报上效率提升建议控制在 20%以下，不然是想被降本增效吗。。。
|
 |
32
yh7gdiaYW 2025 年 7 月 22 日
编程阶段提效不止翻倍，但自测阶段耗时略有增加（多了个 review 和修改）。
然后最重要的，写代码本身在总体开发过程中的时间占比有限，所以对于整个人来说提效没有到飞跃的程度 |
 |
34
digimoon 2025 年 7 月 22 日
ai 这么厉害，想必各种屎山已经被 ai 全改好了吧
|
 |
35
jayzhong 2025 年 7 月 22 日
这个东西很复杂，每个人使用的水平都不一样，千差万别，只能说这个东西将大家的水平和效率的差距越拉越大，对我来说 10 倍。
现在所有的时间都是在做产品的事儿，写文档，然后用 AI 将文档产品化，然后再变成编程需求，剩下的 AI 就帮你完成编码了。 |
 |
36
BortonJones 2025 年 7 月 22 日
根据一些文章 国外有人做过实验 让硅谷好像还是哪里的 20 个程序员 使用 AI 编码工具工作 10 个人用 10 个人不用
结果表示 用 ai 编码工具的人 开发速度慢了 10%-20% 但是 这部分人认为 ai 极大地提高了自己的工作效率 问题可能出在了 正常写代码都是连续性的 但是用 ai 编码工具是说了提示词再等 然后一次出不来还要来回修改 还得等 说句大白话就是 用 ai 可以方便你摸鱼 |
 |
37
HENQIGUAI 2025 年 7 月 22 日
做 demo 和玩具非常快，但是真做大活有点做不了，上下文不够。
|
 |
38
msg7086 2025 年 7 月 22 日
别的例子不说了，就拿 AI 开发工具本身举例好了，RooCode ，VS Code 上的 AI 开发插件本体。基本保持在每周发布 5 个左右版本的速度。就算这里面水分多，我们大砍一刀，算他每周一个新版本，速度也已经足够快了。这算是代表了「一群懂怎么用好 AI 的人」的开发效率。
|
|
39
xsen 2025 年 7 月 23 日
@logic2 #29 我最近一年都深度使用 ai 辅助编程，虽然没有你领导说的那么夸张——但是我本人是认同他的一些观点的
AI 只是将大家的水平、效率的差距越拉越大，简单点就是强者愈强 |
|
40
xsen 2025 年 7 月 23 日
@yidinghe #30 质量从来都是有测试（单元测试、集成测试、e2e 测试）、测试团队来保障的，依赖于开发人员的代码审核、手工测试本就是不靠谱的行为
|
 |
41
jimbray 2025 年 7 月 23 日
最近有看到一个： https://www.53ai.com/news/neirongchuangzuo/2025071157164.html
用 AI 写代码效率反降 19%！ 246 项任务实测，16 位资深程序员参与。 时间维度下的 AI 编程的真实成本： 1. 需求沟通时长 2. AI 执行时长 3. 验证修改时长 4. 上下文切换成本 5. 长期维护成本 有兴趣可以看一下。 我主要是等 AI 的时间，我一般会摸鱼，摸着摸着就摸过头回不来了，这属于降效了😂 |
 |
42
blackmirror 2025 年 7 月 23 日
领导问就说测试时间要多花 10 倍 等真上了 你们就没用了
|
 |
43
BlueSkyXN 2025 年 7 月 23 日 via iPhone
不同场景、不同用户差异很大，对我来说大概能提升 30 倍吧
|
 |
44
wnpllrzodiac 2025 年 7 月 23 日 via Android
15 倍，就是一个大 team 的人都要裁了。出点钱买模型套餐就行了。
|
 |
45
jukanntenn 2025 年 7 月 23 日
AI 现阶段只是降低心智负担，效率反而可能降低。
程序员是个脑力+体力劳动，写代码的时候大脑需要高强度工作，往往 4 个小时工作后就饱和干不动了，只能摸鱼。而有了 AI ，大脑工作强度降低很多，等 AI 写代码的时候还能休息一下，干 8 个小时都不觉得累。 |
 |
46
jmliang 2025 年 7 月 23 日
小公司，App 开发。用了 ai 有 1 年了。目前感觉效率提升最少 1 倍吧
|
 |
47
micean 2025 年 7 月 23 日
前端可以，后端效率还是比不上。
不过 AI 可以把一些工作规范化，这个是我觉得很好的点 |
|
48
sk217 2025 年 7 月 24 日
@xsen #39 这个观点是我的，不是他的，他已经把 AI 当做许愿机了，现在大模型为什么这么有效？说白了，大家都是在重复自己罢了，写个电商页面 写个购物车，写个博客，LLM 并不是在思考 解构你的需求，并帮你细化实现，而是从成千上万的代码里么 帮你预测，像我写一个 TCP 的包捕捉器，去分析 MySQL 协议，这种代码在 github 上开源的有数千个或者数万个仓库 搞过这种事情。
但是 LLM 并不知道你要的是哪一段，甚至直接随便找了点代码 拼接就给你上了，你一跑起来，还真没问题，短的 SQL 解析没啥问题，因为都在一个 ip packet 里面，mtu 1500 ，一般够装一个短的 SQL 了，但是长的呢？立马出问题，你如果自己都不了解协议，或者对网络协议一概不知，根本不可能做出完整的解析器来，因为 AI 它并不理解网络协议，也不知道 TCP 是流的形式，你只能不断的去提示，它才能组织好代码，而且就算提示完了，很多生成出来的代码并不一定是可用的， LLM 只是从开源库里面 随便抓一点代码，解析一个包，然后抄一下别人解析 mysql 的代码给你，从你第一步使用库开始捕捉 packet 到你做出一个完整的 Mysql 协议的 SQL 解析器，中间不知道要踩多少个坑 我更倾向于 LLM 是一种能力放大器，它可以解放你对知识细节的记忆，例如我了解网络是分层的，每一层有哪些职责，IP 包是可以重复的，TCP 协议是通过重复发包 以及退让策略等等，你可以在脑子里面建立一个简易的心智模型，至于细节你可以交给 LLM ，因为它的记忆能力比你强，但是这并不代表你完全不用学习，或者建立知识网络心智图谱，否则你连提示词怎么写都不知道 |
|
49
sk217 2025 年 7 月 24 日
@jukanntenn 其实说实话并没有，只是减少了查资料的强度罢了，大部分时候 AI 生成的并不是有效的代码，上面提到的 44%的 AI 生成代码 都被删除了，说明程序猿真的是不喜欢查资料 去查看别人的文档
|
 |
50
xomix 2025 年 7 月 24 日
3 到 5 倍 甚至 15 倍这种东西，肯定是极限情况。
举个例子你写好一套后端 api ，没有写任何文档，你想写个文档，你跟 ai 说我的 api 在这里，你帮我写个文档。 ai5 分钟内给你一份完整文档，非常完善。 你自己写要多久？ |
 |
53
yunv2 OP |
Select Language