看了一篇文章，非常有意思，分享给大家。

Anthropic 调研了自家的 132名工程师如何在日常工作里使用 Claude，并量化他们在不同任务上使用 Claude 的频率、感受和自评生产力。

同时还抽样分析了 20 万条 Claude Code 对话日志，看看工程师真正把 AI 用在了哪些任务上、复杂度多高、需要多少人类干预。

不是节省时间，而是“把更多事做完了”

1. Claude 已经进入60%的工作流

在问卷里，Anthropic 工程师平均反馈：

• 一年前，他们只有28%的工作会用到 Claude，自评提效约 20%；

• 到今年，同样的人已经在59%的工作里使用 Claude，自评提效来到50%左右；

• 约 14% 的重度用户认为自己的产出翻倍以上。

更有意思的是使用场景的排序，最常见的不是写新功能，而是debug和看懂旧代码：

• 55% 的人每天用 Claude 来查 bug；

• 42% 每天用 Claude 理解代码；

• 37% 每天用它实现新功能。

这说明，AI 先接管的是低价值但必须做的工作，而不是“造火箭”。

2. 27% 的工作原本是不会做的

有一个数字值得注意：

员工认为，自己用 Claude 完成的工作里，有 27% 原本是不会做的。

这些“从无到有”的任务包括：原来嫌麻烦的文档、测试、重构；不影响 KPI 的体验优化小工具；“做做看”的探索性项目和额外实验。

这直接解释了为什么很多团队感觉并没有明显更闲，却做完的事情变多了。

时间略有节省，但更关键的是，AI 把那些“永远排在 to-do 清单底部”的活，真正拉上了日程。

3. 不是“完全交给 AI”，而是“高频协同”

尽管大家用得很勤快，但超过一半的工程师认为，自己能 “完全不用再检查就交给 Claude” 的工作只占 0–20%。

这一点在行为数据里也被证实：

六个月时间里，Claude Code 的任务平均复杂度从 3.2提升到 3.8（满分5），单次任务里连续自动执行的工具调用数从9.8提升到 21.2，而人类插话的轮次反而从 6.2 次下降到 4.1 次。

简单来说就是：AI 接手的链路更长了，人类介入的频率变低了，但还远没有“不需要人”。

行为层面的规律：真正的差距在会不会用 AI

从访谈和日志里，可以看出一套很清晰的 AI 使用准则，这套准则，本质上就是未来工程师的核心技能。

1. 大家把什么活交给 AI？工程师普遍会把这些任务交给 Claude：

• 低背景 + 低复杂度：自己对领域不熟，但问题本身不难，比如简单的 Linux命令、Git 操作；

• 易验证：结果好不好，一眼就能看出来的任务，比如格式转换、小工具、简单 SQL 等；

• 可拆成独立模块：某个子模块跟主系统耦合度不高，写错了也不会拖垮全局；

• 质量要求不高：一次性调试脚本、研究用代码；

• 枯燥重复、自己不想干：重构、写文档、造图表等；

还有一个有趣的规律：“如果一件事自己 10 分钟能搞定，很多人就懒得打开 Claude 了。”这里的边界，其实就是调用 AI 的启动成本。

2. 大家自己又保留了什么活？大部分人会把这些事情留在自己手里：

• 产品和架构层面的关键设计；

• 带有组织文化属性、利益权衡的决策；

• 和“品味”、“风格”相关的工作，比如交互细节；

• 任何“一旦出错成本很高”的任务。

但这条边界并不稳定，随着模型能力提升，可以交给 AI 的范围在不断外扩。 

这一点在日志中同样可见：用 Claude 做新功能和代码设计/规划的占比，六个月内几乎翻了两三倍。

3. 能力结构在变化：更“全栈”，但也有“监督悖论”。

AI 让工程师明显变得更全栈：

• 后端工程师敢自己搞前端和数据可视化；

• 安全团队能迅速分析陌生模块的风险；

• 非技术岗位也能靠 Claude Code 解决网络和脚本问题。

但与此同时，很多人开始担心一个问题：当你把越来越多的实现交给 AI，自己写代码的机会在变少，那你未来还有能力看得懂 AI 写的东西吗？

报告里用了一个很好的说法：监督悖论

有效使用 AI，需要你具备监督它的能力；

但过度依赖 AI，又会让你逐渐失去这种能力。

一些工程师开始有意识地反其道而行：明明知道 Claude 能搞定，但还是偶尔坚持自己手写，就是为了保留那部分“肌肉记忆”。

我们可以得到哪三个认知升级？

认知一：AI 提效 ≠ 把原来的事做快 50%，而是把“没人做的 27%”也做了

从数据上看，Anthropic 的工程师并没有把节省下来的时间拿去摸鱼，而是填满了新的任务：更多实验、更多重构、更多探索性工作。

对任何一家公司，这意味着：

• 如果你只用 AI 去压缩原有工作的工时，顶多拿到 20–30% 的收益；

• 但如果你用 AI 去打开那 27% 原本没人碰的事情，比如体验优化、质量提升、风险排查，边际价值会更高。

对管理者来说：正确的问法不是“有了 AI，这个项目能省多久”，而是“有了 AI，我们可以多做哪些以前根本不做的事”。

认知二：真正的核心能力，是「拆任务 + 委托 AI + 验证结果」

从这份报告看，那些生产力翻倍的重度用户，有三个共同点：

1. 会拆任务，大问题拆成一串 AI 容易搞定的小模块；

2. 会选任务，只把易验证、影响可控的部分交给 AI；

3. 会验收，知道什么时候该自己重新实现，什么时候只要抽样检查就够。

这三件事，本质上是产品思维 + 技术判断 + 风险控制的组合，而不是单纯的会不会写 prompt。

未来工程师的竞争力，很可能不在于一个小时能写多少行代码，而在于一个小时能编排多少 AI 帮你干活，并且保证不出事。

认知三：职业路径在上移，低阶技能可能直接被跳过

以前学编程，有一条相对标准的路径：从手写基础语法、数据结构开始，一步步往抽象层走。

现在，新人很可能直接从用 AI 写代码起步。这会带来两个后果：

底层功夫的价值重新定价：不是人人都要会写底层代码，但总要有一部分人能看得懂、改得动，他们会成为 AI 时代真正稀缺的“审稿人”。

晋升通道从“写得多”变成“管得好”：很多工程师已经开始把自己定义为管理 1/5/100 个 Claude 的经理，而不是高级码农。

最后，这个调研的结果其实既符合我的预期，又不及我的想象。但我还是冒昧的想给你以下建议：

如果你做的是AI 开发工具，不妨问自己三个问题：

• 你能不能替用户解决那 27% 原本不会做的事情？

• 你能不能把 AI 接进他们真实的 CI/CD、监控、知识库，而不只是一个网页？

• 你能不能帮管理者看清“AI 帮他们做了哪些事、承担了哪些风险”？

对企业来说，现在更重要的问题已经不是要不要上 AI，而是：

• 你准备把哪些任务交给 AI？

• 谁来监督这群 AI？

• 当团队的学习路径、协作关系和职业预期都被改写时，你有没有新的组织设计和人才策略？

以上，祝你今天开心。