🫧个人主页：小年糕是糕手
💫个人专栏：《C++》《数据结构》《Blender 修行笔记》《AI》
🎨你不能左右天气，但你可以改变心情；你不能改变过去，但你可以决定未来！
目录
一、AI 的发展，已经走进软件开发的工作流程
二、代码写得更快，软件就能更快交付吗？
三、程序员的工作，会怎样重新分配？
四、岗位会减少吗？这个问题需要正面回答
五、新人面对的难题，可能是怎样积累第一段经验
六、未来几年，我更关注这三种变化
1. 小团队有机会承担更完整的项目
2. 团队会重新寻找开发和审核之间的平衡
3. 编码会进入更多行业岗位
七、现在值得投入时间学习什么？
1. 读懂和修改真实系统
2. 把要求变成可检查的结果
3. 使用工具，同时保留自己的验证办法
八、技术变化，也需要团队和企业作出选择
今年1024，我想认真聊一件事：当 AI 已经能够生成代码、修改项目、执行测试，程序员未来的工作会是什么样？
这个问题很容易被讨论成两个极端。
一种声音认为，程序员很快就会被替代；另一种声音则认为，只要掌握 AI，就不用担心职业变化。
可真正面对学习、求职和日常开发时，这两种回答都不够用。
我们需要知道的，是哪些工作正在变化，哪些岗位可能承压，以及今天投入时间学习的东西，明天还能帮助自己做什么。
我的判断是，程序员这个职业会经历持续的任务重组。部分实现工作会进一步自动化，团队的人员配置、能力要求和培养方式也会随之改变。这个过程会带来机会，也会让一些人的处境变得更困难。
这篇文章想把这些变化拆开来看。
本文研究与统计资料核对至2026年10月21日。关于未来职业演变的部分，是基于现有证据的分析与判断。
一、AI 的发展，已经走进软件开发的工作流程
回看 AI 的发展，可以看到几条重要思路：把知识写成规则，让模型从数据中学习，再通过深度神经网络和大规模预训练，处理越来越复杂的输入与输出。
这些路线长期并行，发展也并非一条笔直的上升曲线。
2017年发表的《Attention Is All You Need》提出了 Transformer 架构，这是后来许多大语言模型采用的重要技术基础之一。论文原文
对程序员而言，更直观的变化发生在使用方式上。
| 代码补全 | 编写代码时，接收局部实现建议 |
| 对话式助手 | 描述需求、询问报错、生成函数，再把结果放进项目 |
| 代码代理 | 提供任务和项目环境，让工具读取文件、修改代码、执行检查，再返回改动供审核 |
这张表只是理解工具变化的一种简化划分。它们目前仍然共存，也适合不同任务。
值得关注的是，AI 开始接触开发工作的上下文：现有代码、项目约定、测试结果，以及修改后的反馈。
例如，GitHub 的官方说明已经列出了创建分支、生成改动、执行测试和发起代码合并请求等代理能力，同时也说明了这些能力的限制与审核要求。GitHub 官方说明
这意味着，讨论程序员未来时，不能只问“AI 能不能写出一个函数”。
还要继续观察：它能处理多大范围的任务，需要多少监督，失败能否被发现，以及最终结果是否值得采用。
二、代码写得更快，软件就能更快交付吗？
AI 能提高部分编码任务的完成速度，已经有研究支持。
2023年发表的一项受控实验，让开发者完成使用 JavaScript 实现 HTTP 服务器的任务，使用 GitHub Copilot 的一组更快完成了指定任务。研究论文
但这项结果对应的是特定任务和实验条件，不能直接换算成整个开发团队的交付收益。
METR 的研究提供了另一种观察。
其针对2025年早期工具的实验，曾在有经验的开源开发者任务中观察到耗时增加。到2026年2月，研究者更新说明：后续实验受到参与者和任务选择偏差等因素影响，难以可靠估计当前的提速幅度；他们倾向于认为工具带来的帮助已经增加，但证据不足以给出稳健的增幅。METR 研究更新
这些材料提醒我们：效率需要放回具体任务中衡量。
想象一个常见需求：
给管理系统增加一个“导出数据”的按钮。
生成按钮和接口，可能只是其中一部分工作。继续往下，会遇到：
- 哪些角色有权导出？
- 导出的字段是否包含不该暴露的信息？
- 数据量大时，系统是否会超时？
- 导出失败后，用户怎样重试？
- 修改是否影响原来的查询和权限规则？
AI 可以参与分析和实现这些问题，但问题仍然需要被明确提出、验证和处理。
如果生成代码节省的时间，被后续阅读、返工和排查消耗掉，最终交付未必更快。反过来，边界清楚、检查充分的任务，也可能获得明显收益。
因此，评价 AI 开发效果时，值得记录的包括任务总耗时、返工、缺陷和维护成本。屏幕上出现了多少代码，只能说明其中一部分情况。
三、程序员的工作，会怎样重新分配？
程序员的工作，本来就包括很多不同性质的任务。
有些任务边界清楚，例如按照明确规则转换数据、补充常规测试、修改重复结构。另一些任务需要处理含糊需求、历史兼容、系统故障和人员协作。
AI 对它们的影响，很难完全一致。
| 需求整理 | 汇总反馈、提出问题、形成草案 | 要解决谁的问题，投入是否值得 |
| 功能实现 | 生成代码、修改文件、解释接口 | 是否符合现有系统的约束 |
| 测试验证 | 提出用例、执行检查、分析失败 | 测试是否覆盖真实要求，结果是否可信 |
| 发布维护 | 整理日志、辅助定位、准备操作方案 | 发布条件、回退方式和处理负责人 |
这张表列的是交付过程中需要回答的问题。
AI 的参与范围会继续变化，哪些步骤可以交给工具完成，也需要持续验证。今天仍需大量人工参与的环节，不应直接被视为永久不变的职业边界。
但在实际组织中，总要有人决定接受什么结果、允许承担什么风险，以及出问题以后怎样处理。
所以，我认为程序员的工作内容会更频繁地涉及：
准备上下文、划分任务、检查改动、定位失败，以及把技术结果连接到实际用途。
这并不意味着今后只需要会审核代码。读不懂系统、无法定位问题，审核本身也很难做好。
四、岗位会减少吗？这个问题需要正面回答
部分任务自动化以后，一些团队可能减少原本需要的人力。这种可能性值得认真对待。
同时，成本下降也可能使过去做不起的软件需求变得可行，让小团队能够尝试更多产品。
最终会怎样，取决于需求是否增长、企业怎样使用效率收益，以及工具在具体业务中能够做到什么。岗位数量无法只凭“AI 又完成了一个演示”来推算。
已经出现的就业信号，也需要按范围阅读。
斯坦福数字经济实验室在2026年8月更新的一项研究中，使用覆盖至同年6月的美国 ADP 工资数据，发现 AI 暴露程度较高职业中的22—25岁劳动者，其就业水平相对低暴露同龄群体的参照趋势存在19%的差距。差异主要通过招聘减少体现。作者将这些结果界定为描述性信号，而非 AI 造成就业变化的因果估计。研究说明
另一边，美国劳工统计局当前预计，软件开发者、质量保障分析师和测试人员这一组合职业，在2025—2035年的就业总量增长10%。这是长期预测，也不保证每个细分方向和每一年都有同样的机会。BLS 职业展望
两项材料关注的时间跨度、人群和统计对象不同。总量预测增长与年轻人的入口承压，可以同时存在。
这些证据来自美国，也不能直接套用到国内某个城市、岗位或个人身上。
但有一个问题值得提前重视：职业变化可能首先表现为少招人，而不只是已经在职的人被裁掉。
对于正在准备第一份工作的新人，这两种变化都会影响机会。
五、新人面对的难题，可能是怎样积累第一段经验
过去，一些基础任务既是工作，也是训练。
在修改页面、整理脚本、排查简单报错的过程中，新人逐渐熟悉项目，学习怎样阅读代码、理解约定和判断错误。
如果这些任务越来越容易自动完成，企业可能调整初级岗位的配置。随之而来的问题是：新人从哪里获得足够的实践，成长为能够处理复杂问题的人？
这不能只靠一句“提升自己”解决。团队需要考虑培养路径，学习者也需要检查自己究竟掌握了什么。
Anthropic 在2026年1月发布的一项随机对照研究，让已有 Python 使用经验、但不熟悉特定新库的开发者完成学习任务。AI 组在后续掌握度测验中的平均表现较低，任务提速没有达到统计显著水平。研究还观察到，不同使用方式对应不同的学习表现。研究原文
这是一项特定条件下的实验，不能概括所有学习场景。但它提出了一个很实际的问题：
任务做完了以后，下一次遇到类似问题，自己还能完成多少？
学习时，可以定期检查：
- 能否解释这段代码的输入、输出和成立条件？
- 修改一个需求后，能否找到需要调整的位置？
- 程序失败时，能否根据日志和现象缩小问题范围？
- 暂时不看 AI 的解释，能否重新讲清楚关键概念？
AI 可以参与这些练习。重要的是，在使用过程中留下理解、判断和纠错的机会。
六、未来几年，我更关注这三种变化
下面是我的判断，需要随着工具能力和就业数据继续修正。
1. 小团队有机会承担更完整的项目
当部分实现、文档和测试工作更容易获得帮助，小团队可能以更低的初始成本尝试产品。
对个人开发者来说，这种变化有吸引力：一些原本停留在想法里的工具，有了更容易启动的条件。
同时，竞争也可能增加。做出原型之后，还要回答用户为什么需要它、是否愿意持续使用，以及产品怎样维护。
实现门槛下降，会让这些问题更加突出。
2. 团队会重新寻找开发和审核之间的平衡
如果生成改动的速度提高，阅读与验证这些改动就可能成为新的压力点。
团队需要决定任务一次做到多大，哪些检查可以自动执行，哪些改动需要更严格的评审。
未来的工作方式，可能包含更多小步提交、明确的验收条件，以及可追溯的运行结果。
这方面也会继续出现新的自动化工具。程序员需要学习怎样利用它们，同时检查它们有没有覆盖真正的问题。
3. 编码会进入更多行业岗位
当编写脚本、处理表格、连接接口变得更容易，一部分原本主要使用现成软件的人，也可能开始制作自己的工具。
这会让“会编程的人”与“程序员岗位”的边界变得更加复杂。
一个熟悉业务的人，能够用 AI 做出小工具；一个专业开发者，也可能需要更深入理解工具服务的行业。
软件能力会被更多人使用。专业开发者仍需证明，自己能够处理更复杂、更长期、要求更高的交付。
七、现在值得投入时间学习什么？
工具更新很快，学习也需要有所取舍。
我更倾向于优先积累下面几类能力。
1. 读懂和修改真实系统
除了写出新函数，还要练习阅读别人写的代码，追踪一次请求经过哪些模块，理解数据怎样变化。
数据库、网络、操作系统和数据结构等知识，能帮助解释许多具体问题：重复提交为什么造成脏数据，并发为什么引发冲突，超时为什么不能简单重试。
这些理解也能帮助你判断 AI 提出的修改是否合适。
2. 把要求变成可检查的结果
“帮我做好”很难验收。
“空文件能够处理，重复记录按照规则归并，原始数据保留，异常单独列出”，就有了检查路径。
前面几篇 AI 入门文章里，我们反复练习的任务范围、资料依据和统计口径，也可以延伸到开发工作中。
把模糊要求整理清楚，是推进项目的一项能力。
3. 使用工具，同时保留自己的验证办法
选择一套能够正常使用的 AI 工作方式，完成几个有输入、有输出、有失败情形的小项目。
记录它在哪些地方节省了时间，在哪些地方增加了阅读或返工。遇到重复错误，就调整任务说明和检查方式。
这比只比较模型榜单，更能帮助你形成适合自己的使用习惯。
作品展示也可以多保留一些过程证据：需求为什么这样定，某个方案为什么放弃，结果怎样验证，还有哪些限制。
这些内容能让别人看见你的判断。
八、技术变化，也需要团队和企业作出选择
谈程序员的未来，不能把全部责任都放在个人身上。
企业可以把效率收益用于探索新需求、改善质量、减少重复劳动，也可能选择压缩人力或提高交付要求。不同选择，会塑造不同的工作环境。
团队如果希望新人最终能够承担复杂工作，就需要提供适当的实践、反馈和指导。
如果希望 AI 带来可靠收益，就需要把返工、缺陷、评审和维护一起纳入评价，而不能只看生成了多少代码。
这些都是职业演变的一部分。程序员未来的工作体验，也会受到招聘、培养和管理方式的影响。
这个1024，我仍然觉得编程值得学习。
把一个模糊的想法变成可以使用的东西，理解它怎样运行，发现错误并把它修好，仍然是一件有吸引力的事。AI 正在改变我们完成这些事情的方法，也让我们更需要认真判断结果。
我希望技术进步能带来更多创造的机会、更少无意义的返工，也希望团队愿意给新人留下成长的位置。
下一次 AI 提交一份改动时，我更希望自己能够看懂它、验证它，并作出一个有依据的决定：这份结果，是否已经可以交给用户。
祝每一位仍在学习、调试和创造的人，1024快乐。
