AI 降低的是生成候选代码的成本，不是交付正确软件的复杂度。
这里所说的“入门”，不只是学会语法、完成练习或拿到第一份工作，而是从学习者走到能够在真实团队中独立交付低风险改动。
对这个阶段的程序员来说，AI 是一个少见的矛盾体：它能降低学习和实现的门槛，也可能悄悄拿走原本用来形成判断力的练习。它可以在几秒内补出一段像样的代码，却不会替你拥有需求、理解历史包袱、观察生产环境，更不会在数据丢失时替你承担责任。谁接受改动、谁部署系统、谁面对用户，最后仍然是人。
这会造成一种新的门槛错位：第一版实现变得更容易，“能写出来”不再足以证明工程能力；团队可能减少边界清楚的基础任务，或者更早要求新人理解上下文、验证结果并承担后果。前一段坡变缓了，后一段坡没有消失，反而可能被提前。
本文把这视为一个需要持续检验的机制判断，而不是已经由就业数据证明的单一因果关系。因此，真正值得讨论的不是“新人该不该用 AI”，而是两个更具体的问题：
- AI 究竟降低了哪一部分成本，又把哪些责任留给了人？
- 当写代码越来越便宜，新人应该如何形成并证明自己的能力？
1. AI 提速没有一个适用于所有任务的数字
关于 AI 编程效率，最容易犯的错误是寻找一个适用于所有工作的提速百分比。
GitHub 曾让 95 名开发者完成一个边界清楚的 JavaScript HTTP 服务任务。使用 Copilot 的一组平均完成得更快，用时约少 56%。另一边，METR 在 2025 年初让 16 名资深开发者处理自己长期维护的成熟开源仓库中的 246 个真实任务，允许使用当时的 AI 工具后，完成时间反而增加了约 19%；参与者事后却认为自己快了约 20%。
这两个结果并不冲突。前者的任务短、边界清楚、反馈直接；后者依赖大量隐含上下文、仓库历史和较高的质量标准。METR 后续使用更新工具收集的数据开始出现提速迹象，但研究者也明确说明，参与者选择、任务选择和并行 Agent 的计时方式让当前估计仍不稳定。
一项覆盖 4,867 名开发者、发表于 Management Science 的三项企业现场实验提供了另一种观察：使用 AI 后，完成任务数的合并估计提高约 26%。这说明 AI 确实可能提高开发活动，但“完成任务数”仍不是理解程度、长期可维护性或软件质量的同义词。
这些结果共同指向的不是一个统一的提速数字，而是一组条件：
任务越清楚、范围越小、反馈越快、验收越自动化，AI 越容易产生净收益；任务越依赖隐性需求、跨模块状态、历史包袱和高风险约束，人的理解与验证越重要。
也就是说，AI 首先降低的是候选方案的生成成本。接下来要问的是：当这一步变得便宜，新人的学习过程会发生什么变化？
2. AI 可以成为脚手架，也可以成为认知捷径
AI 对新人确实有价值：
- 补齐语法、样板代码和常见 API 示例；
- 把编译错误或陌生概念翻译成更容易理解的语言；
- 提供不怕重复追问的第一轮反馈；
- 快速搭原型、比较方案并生成测试思路；
- 降低尝试陌生领域的启动成本。
“用了 AI 就学不会”并不符合现有证据。2023 年一项包含 69 名青少年编程初学者的实验发现，AI 组完成了更多练习，代码得分也更高；在随后的无 AI 即时测试和一周后的保持测试中，研究没有发现显著差异。值得注意的是，AI 组并没有显著更快，因此这项研究支持的是“AI 可以成为学习脚手架”，而不是“AI 必然让所有学习更快”。
相反的风险也真实存在。2026 年一项尚未正式同行评审的预印本让 52 名有 Python 经验、但不熟悉 Trio 的参与者学习这个异步库。AI 组完成学习任务只快了约两分钟，差异并不显著；紧接着的无 AI 测验中，AI 组平均约 50 分，对照组约 67 分，调试题的差距尤其明显。
两项研究的方向不同，恰好说明问题不在“是否用了 AI”这一项开关，而在使用方式：
- AI 帮你解释概念、比较方案、暴露反例时，它更像脚手架；
- AI 直接接管理解、实现和判断时，它更像认知捷径；
- 如果验收只看“这次跑通了”，短期产出很容易掩盖学习缺口。
需要把两个指标分开：
- 当下表现：这次任务是否完成得更快；
- 可迁移能力：关掉原对话后，能否读懂、修改、调试并处理需求变体。
完成任务不等于形成能力。现有研究也不足以证明 AI 会让新人长期退化；能够确定的只是，高委托、低理解、低验证的工作方式更容易留下能力缺口。
3. 门槛从“写出来”移向“判断得了”
这种能力缺口之所以会抬高入门难度，是因为生成一段局部可运行的代码，只是软件交付链条中的一小步。真正昂贵的部分通常在别处：
- 需求是否完整，例外和优先级是什么；
- 数据、状态、并发、权限和失败恢复怎样组合；
- 改动会不会破坏其他模块、旧版本或隐含契约；
- 安全、性能、可观测性、成本和合规是否达标；
- 需求变化后，其他人能否继续维护；
- 出现故障时，能否定位、回滚并解释。
AI 能看到你交给它的文本和代码，却不天然拥有真实用户意图、生产流量、组织约束和历史事故。它可以快速生成一个局部正确的实现，但局部正确不等于系统正确。
当生成成本下降，团队还可能遇到一条新的放大链：
候选改动生成得更快
↓
改动数量和范围扩大
↓
验证、集成、评审和运行负担后移
↓
工程基础扎实：吞吐和质量一起改善
工程基础薄弱：返工、缺陷和维护债一起放大
DORA 2025 基于近 5,000 名技术人员的混合方法研究，把 AI 描述为组织能力的“放大器”。这不是一项严格的因果定律，却是一个有用的观察框架：工具会放大已有的反馈速度、测试能力和平台质量，也会放大混乱。
对新人来说，这种迁移尤其危险。过去，写出第一版代码本身就会迫使人接触语法、数据流和错误信息。现在，这一步可以被快速跳过，但后面的验证责任并没有随之消失。若没有读、改、测、调的能力，短期看不见的“能力债”会在需求变化和线上故障时集中暴露。
4. 最危险的不是 AI 犯错，而是你无法判断它何时犯错
流畅、完整、语气坚定的输出，很容易制造一种错觉：它看起来懂了，于是使用者也感觉自己懂了。
安全研究给出的结论并不单向。一项包含 47 名参与者、覆盖五个安全任务的研究中，AI 组在四项任务上方向性地写出了更多不安全代码，同时对结果更有信心；另一项包含 58 名参与者的 C 语言实验，则没有发现 AI 显著增加关键安全缺陷。模型、语言、任务和实验设计都可能改变结果。
因此，合理结论既不是“AI 代码一定不安全”，也不是“更强的新模型已经解决了正确性”。真正稳定的原则是：
模型输出不能成为安全证明，模型对自己输出的评价也不能成为验收。
同样的校准问题也出现在效率上。METR 实验中的开发者主观认为自己更快，计时结果却相反。体感可以帮助发现体验问题，却不能替代运行结果、测试、评审和故障数据。
新人最需要建立的不是对 AI 的盲目信任或条件反射式怀疑，而是校准能力：知道自己掌握了什么、不确定什么，以及需要什么证据才能继续。
5. 职业入口出现变化信号，但因果仍不清楚
前面讨论的是新人怎样完成一项任务。但“入门是否变难”还有组织端的一半：当边界清楚的基础实现更容易被 AI 加速，团队会不会减少这类岗位，或者更早要求新人承担上下文理解和结果验证？现有就业数据只能提供信号，还不能证明这条因果链。
关于“AI 是否正在取代初级程序员”，公开讨论中的确定性远高于证据本身。
国内能够按经验层级拆分、公开方法并控制行业周期的软件招聘数据仍然有限。翰德发布的《2026 人才趋势报告》观察到，传统软件开发需求下降约 25%，AI 应用开发需求增长超过 60%。这是一家人才机构看到的招聘结构变化，不是全国就业统计，也无法单独拆出 AI、宏观经济和招聘周期各自造成了多少影响。
美国数据可以提供对照。Stanford Digital Economy Lab 基于 ADP 数据的 2026 年修订研究发现，22—25 岁劳动者在高 AI 暴露职业中的就业路径，相对低暴露职业同步增长的基准约低 19%，差距更多来自招聘减少。作者同时强调，这是描述性信号，不是 AI 的因果估计。
与此同时，美国劳工统计局当前仍预计软件开发者就业在 2025—2035 年增长约 10%。职业总量增长、招聘周期走弱和入门任务发生变化可以同时存在。
所以，现阶段更诚实的判断是：
- 不能仅凭招聘变化断言 AI 已导致初级岗位收缩；
- 也不能因为职业总量预测仍增长，就认为新人入口不会改变；
- 例行、边界清楚的实现工作更容易被 AI 加速，可能迫使新人更早展示理解上下文、验证结果和承担模块责任的能力；
- 如果团队减少了入门任务和新人招聘，也需要重新设计培养未来资深工程师的练习场。
新人不必和 AI 比打字速度，但需要更早证明自己不只会打字。
6. 把 AI 使用变成一个可重复的工作闭环
下面不是研究已经验证过的最佳实践组合，而是针对前述能力缺口和校准风险设计的一套工作方法。四步应当循环发生：
先定义 → 小块委托 → 独立验证 → 脱离原对话复盘
↑ ↓
└──────── 把暴露出的理解缺口带回下一轮 ────────┘
6.1 先定义，再生成
打开 AI 前，先用自己的话写清楚：
- 目标和非目标；
- 输入、输出与状态变化；
- 不能破坏的约束；
- 需要处理的异常；
- 怎样证明结果正确。
如果这些问题还说不清，生成更多代码通常只会扩大待确认范围。此时可以先让 AI 提问、比较方案或寻找反例，而不是立即要求完整实现。
6.2 只委托能够解释和验证的小块
每次交给 AI 的任务，应小到你能够回答：
- 这段改动为什么存在？
- 它依赖哪些假设？
- 至少在哪两种条件下会失败？
- 需求变化时，应该改哪里？
如果准备合并的代码无法在没有原对话的情况下被解释和修改，它仍然是一个黑盒，而不是已经拥有的工程资产。
6.3 让输出进入证据闭环
最低限度的闭环可以是：
明确需求 → 小步改动 → 编译或静态检查 → 自动测试
→ 边界与反例 → 人工审查 → 观察运行结果 → 必要时回滚
不同风险需要不同强度的证据。语法补全和小范围重命名可以轻量验证；跨模块重构、并发、数据库设计和性能优化需要更强的测试与人工复核；认证、权限、加密、支付、生产数据迁移和删除操作，不应交给无人监督的端到端执行。
6.4 保留不依赖原对话的能力
可以定期安排无 AI 的读代码、修改需求和排错练习，或者在 AI 协助完成后，关掉对话重新复述数据流、假设和失败路径。具体频率不是已有研究证明的“最佳剂量”，只是一种练习设计。
目的不是证明人比 AI 写得快，而是保持监督 AI 所需的能力。真正的检查标准是：当工具不可用、答案错误或需求改变时，你能否继续推进。
复盘暴露出的理解缺口，不应停留在“下次注意”，而要成为下一轮定义任务时新增的约束、反例或验收条件。这样，AI 带来的速度才会同时转化为能力和可维护的结果。
7. 新人真正需要积累的职业资本
这套变化会重新排序新人需要积累的职业资本。更难被压缩的能力包括：
- 把含糊问题变成可执行的约束；
- 读懂并修改不是自己生成的代码；
- 用测试、反例和运行数据证明结果；
- 在系统失败时定位原因并恢复；
- 理解一项改动对用户、同事和长期维护的影响；
- 对自己接受并交付的结果负责。
所以，请大胆使用 AI，但保留三条底线：
不合并自己解释不了的代码。
不相信未经独立验证的结果。
不把完成任务误认为形成能力。
现有证据仍以短期实验、自报调查和特定任务为主，缺少跨越数年的职业成长追踪。模型和工作流也在快速变化。文中的具体效率数字会过时，但理解、验证和责任不会因为下一代模型出现而自动消失。
References
- GitHub Research：Quantifying GitHub Copilot’s impact on developer productivity
- Management Science：The Effects of Generative AI on High-Skilled Work
- METR：Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity
- METR：2026 Developer Productivity Experiment Update
- CHI 2023：Studying the Effect of AI Code Generators on Supporting Novice Learners in Introductory Programming
- Shen 与 Tamkin：How AI Impacts Skill Formation
- CCS 2023：Do Users Write More Insecure Code with AI Assistants?
- USENIX Security 2023：Lost at C
- DORA 2025 State of AI-assisted Software Development Report
- 翰德：2026 人才趋势报告
- Stanford Digital Economy Lab：Canaries in the Coal Mine? Six Facts about the Recent Employment Effects of Artificial Intelligence
- 美国劳工统计局：Software Developers, Quality Assurance Analysts, and Testers
Discussion
留言与讨论
想法、补充和不同意见都欢迎。