不会发生人工智能导致的就业危机

勇哥AI笔记

发布于 2026-05-20 21:42:50

1350

文章被收录于专栏：技术人生黄勇技术人生黄勇

吴恩达：AI 不会带来就业末日，会带来就业大爆发。

为什么关于人工智能会导致失业的论调如此流行？

一方面，那些处于人工智能研究前沿的实验室有强烈的动机去夸大人工智能技术的强大功能。

在极端情况下，他们甚至会描绘出人工智能“掌控一切”并导致人类灭绝的科幻场景。

如果某种技术能够取代许多人的工作，那它肯定具有极高的价值！

（注：我记得当时有这么一篇文章用穿越到未来，描述了一幅AI席卷之下，百业凋零的场景：“Something Big Is Happening”｜大事确实在发生，是一场漫长而温和的重构。我们每个人都将是参与者，而非旁观者。）

与那些预测人工智能会带来就业危机的观点相反，我预计情况恰恰相反：

人工智能将会创造大量新的就业机会！

人工智能将会催生出许多与人工智能工程相关的职位。

我对整个就业市场的未来也持乐观态度。

人工智能工程师的工作内容将与传统软件工程师有所不同，而且这些工作大多不会出现在那些传统上雇佣大量开发人员的公司里。

在非人工智能相关的领域，由于人工智能的影响，所需技能也会发生变化。

因此，现在正是鼓励更多人掌握人工智能相关技能的好时机，这样他们就能为未来各种不同的工作做好准备！

1979 年，电子表格 VisiCalc 问世，几分钟完成过去一个会计团队数日的工作。

当时所有人都预测会计师将大规模失业。

结果是此后 40 年，会计师数量增长了 4 倍。

经济学里管这叫杰文斯悖论：一项技术让某类服务变得更便宜，反而刺激了总需求大幅增长。

脉脉《2026 春招职场洞察报告》的数据：2026 年 1 到 4 月，新经济行业新发岗位量同比增长 22.6%，AI 领域岗位量同比增长 8.7 倍。

AI 岗位在全部新经济岗位中的占比，从去年同期的 2.29% 跃升到 26.23%。

也就是说现在每 4 个新岗位里，就有 1 个是 AI 相关的。

脉脉 2025 年的数据：1 到 7 月 AI 新发岗位量同比增长超 10 倍，简历投递量也暴涨了 11 倍。

a16z 最新报告也印证了同一趋势：在大量采用计算机的职业中，就业增速反而高于未采用计算机的职业。

软件工程师是公认受 AI 影响最大的岗位，但事实是需求在大幅增长。

初级程序员、前端等通用开发岗确实在收缩，但 AI 工程师、Agent 开发、大模型落地方向在爆发。

吴恩达说："使用 AI 的人，将取代不使用 AI 的人。"

我感受：尝试成本几乎为零

我从使用AI之后，经历过的场景，包括且不限于：

量化策略验证。

看到一个策略想法，刷刷刷几分钟，在 20 年的历史日线数据上跑完回测。

当场就知道收益率多少、夏普比率多少、最大回撤多少。

这个策略能不能用，不用猜，不用等，几分钟见分晓。

以前同样的操作，光写回测脚本就要大半天，还不算调试时间。

例如：智谱也出龙虾了，我养的第4只还让它炒股，又例如：让OpenClaw替你打工（五）：没花什么钱养了6只虾，还赚到了钱

快速出 DEMO。

有什么需求找到我，问清楚要做什么，几分钟生成一个 DEMO 项目。

在线的网站直接打开就能看，不需要很正规的产品需求文档，产品设计，就可以根据这个版本，进入实质性讨论。

公众号写作效率翻倍。

AI在收集信息、生成草稿、排版诸多个方面极大的节省了我的时间。

有朋友说，他客户公司就直接拿着AI生成的第15版产品原型找他们直接开发，而以前需要多轮次的沟通，才有产品经理形成最终的产品文档。

所有"从想法到可运行产物"的成本变便宜了。

Anthropic 上个月发布了《2026 Agentic Coding 趋势报告》，核心判断：软件开发生命周期正从"周/月"压缩到"小时/天"。

但是硬币有两面，AI 的另一面则是维护的成本相应的增加。

例如：当 AI 编程使得代码变得便宜......

Opsera 的报告：AI 让 Time-to-PR 最多缩短 58%，但 PR 审查等待时间延长了 4.6 倍。

AI 生成代码的流失率约 40%，合进去两周内就被回滚或重写。

技术债务增加 30% 到 41%。

代码像免费的小狗，领养不要钱，养起来才是真成本。

以我正在进行的一个复杂、大型的重构开发项目来说，

如何让 AI 生成产品规范文档，则是一件需要丰富的开发经验和调整大模型产出能力的难事。

这个重要的核心文档前后审了五版，还不包括之前根据各业务领域的现有各种格式文档（PDF/EXCEL/PPTX/DOC）统一整理成Markdown文档。

第一版是AI 只是针对各源文档文字上的拼接。

角色和职责部分不是简单的各系统文档中的相关描述叠加，应该审视合并之后，人员角色在源系统中的称呼和功能，如何迁移到重构系统中统一起来。

第二版审核我指出了三个问题：文档定位不对，部分业务域粒度不够，引用逻辑不统一。

”7.1 平台基础域” 没有像下面7.2-7.8描述那么细致，是否会影响后续流程？是否因为源文档是有足够细节内容？“

第三版暴露了更深的问题：它把各旧系统的基础配置功能单独列在各业务域下面，没有意识到这些应该统一收归到监管平台的基础维护底座。

必须以平台为主系统基线，统一角色、权限、空间、流程、移动端和数据对象，再把各专项系统能力融合到平台的业务域中。”。如果不是让你“7.1 平台基础域已按可执行粒度补强，”，还不容易发现这类问题，所以后续执行中，要避免这类文档、规范中粒度不一致导致隐藏问题和隐患。

我不得不提醒它一个核心原则：不能简单叠加旧系统的功能，必须以监管平台为主系统基线，统一角色、权限、空间、流程，再把各专项系统能力融合进去。

这个原则对，但是文档应该进行相应的调整：8-12的基础维护是不是应该是顶层都是基础维护，下面分业务领域各自维护？由此也带来后续实现的思考：如果某个业务功能，用户不需要，是否可以不开通此业务域，也不需要进行这部分的设置？请你在接收审核意见时，调用系统架构，产品经理的agent，或者以此为视角进行评估，感觉在这个环节，你没有进行主动思考，只是简单进行文字整理，未体现你最先进大模型的实力。

第四版方向对了，但文档结构调整不彻底，有些章节写对了原则，下面却还是旧结构。

我甚至用上了 PUA 大模型的鼓励词：”未体现你最先进大模型的实力“，你别说，确实管用。

到第五版才满意，但紧接着新问题：文档只写了主流程，具体字段、状态值、分支流程这些执行细节还不够。

而这些细节不写清楚，后面开发、测试、用户故事会自由发挥或者偏移。