AI推动新就业增长
吴恩达：AI不会引发失业潮，反将激发就业新机遇。
为何“AI将导致失业”的言论广为流传？
部分炒作此话题的机构，倾向于夸大AI的颠覆性，以获取更多关注。
某些极端预测甚至渲染AI将主导世界并导致人类终结，这纯属无稽之谈。
如果某项技术能替代大量人力，那它本身就具备巨大价值！
（注：我记得曾读过一篇文章，描述了AI未来下的行业变化：“某项大事正在发生”｜这是一场温和而持久的变革。我们都是这场变革的参与者，而非旁观者。）
与这些观点相对，我更倾向于认为：
AI将激发大量新岗位！
AI将催生众多与AI工程相关的职位。
我对就业市场持积极态度。
AI工程师的工作将有别于传统软件工程师，且新岗位多出现在非传统大厂。
在其他非AI领域，AI也将改变技能需求。
因此，现在是鼓励更多人掌握AI技能的好时机，为未来工作做准备！
1979年，VisiCalc电子表格问世，几分钟完成过去一个会计团队数日的工作。
当时预测会计将大规模失业。
结果40年，会计师数量增长了4倍。
经济学称此为杰文斯悖论：技术使服务更便宜，反而刺激了总需求。
据脉脉数据：2026年1到4月，新经济行业新发岗位同比增长22.6%，AI岗位同比增长8.7倍。
AI岗位在所有新经济岗位中占比从2.29%跃升到26.23%。
即每4个新岗位中，有1个是AI相关。
数据显示，AI新岗位量同比增长超10倍，投递量也暴涨了11倍。
最新报告也印证了同一趋势：在大量采用计算机的职业中，就业增速高于未采用计算机的职业。
软件工程师受AI影响最大，但需求在大幅增长。
初级程序员、前端等通用开发岗在收缩，但AI工程师、Agent开发、大模型落地方向在爆发。
吴恩达说："使用AI的人，将取代不使用AI的人。"
我从使用AI之后，经历过的场景，包括：
量化策略验证。
看到一个策略想法，刷刷刷几分钟，在20年的历史日线数据上跑完回测。
当场知道收益率、夏普比率、最大回撤多少。
这个策略能不能用，不用猜，不用等，几分钟见分晓。
以前同样的操作，光写回测脚本就要大半天，还不算调试时间。
例如：智谱也出龙虾了，我养的第4只还让它炒股，还例如：让OpenClaw替你打工（五）：没花什么钱养了6只虾，还赚到了钱
快速出DEMO。
有什么需求找到我，问清楚要做什么，几分钟生成一个DEMO项目。
在线的网站直接打开就能看，不需要很正规的产品需求文档，产品设计，就可以根据这个版本，进入实质性讨论。
公众号写作效率翻倍。
AI在收集信息、生成草稿、排版诸多个方面极大的节省了我的时间。
有朋友说，他客户公司就直接拿着AI生成的第15版产品原型找他们直接开发，而以前需要多轮次的沟通，才有产品经理形成最终的产品文档。
所有"从想法到可运行产物"的成本变便宜了。
Anthropic上月发布《2026AgenticCoding趋势报告》，核心判断：软件开发生命周期正从"周/月"压缩到"小时/天"。
但是硬币有两面，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，或者以此为视角进行评估，感觉在这个环节，你没有进行主动思考，只是简单进行文字整理，未体现你最先进大模型的实力。
第四版方向对了，但文档结构调整不彻底，有些章节写对了原则，下面却还是旧结构。
到第五版才满意，但紧接着新问题：文档只写了主流程，具体字段、状态值、分支流程这些执行细节还不够。
而这些细节不写清楚，后面开发、测试、用户故事会自由发挥或者偏移。