用AI写代码的程序员，3个月后集体失忆了

GitHub Copilot用户突破1500万那天，某独角兽CTO在内部群发了一句话：「我们现在招的初级工程师，代码写得比三年前快3倍，但问他们为什么这样设计，10个里有7个答不上来。」

这不是AI的锅。是流程崩了。

01｜"任务完成了，但人没学会"

CTO圈子有个经典 onboarding 流程：新人读文档、翻仓库、做小型任务——通常是 senior 故意设计的，用来暴露系统核心逻辑怎么运转。API怎么组织的？状态存在哪？数据流怎么连？

开发者通过犯错、试错、反思来学习。

AI没杀死这个过程。但草率的AI adoption 让它变得极其困难。当开发者把所有事丢给AI助手、从不反思，当AI直接实现了onboarding任务——代码提交了，PR合并了，但onboarding根本没发生。

没有错误可学，没有东西可发现。开发者不再从错误中学习，也不再通过探索理解系统。

一位带过200+工程师的CTO告诉我：「以前新人第一周会踩三个坑，现在AI帮他们绕过了所有坑。三个月后，他们还是不知道坑在哪。」

02｜效率数字背后的分层真相

AI确实让开发者更快。但 headline 里的数字没告诉你后半句。

经验较少的开发者 raw productivity 提升最大——他们能产出能跑的代码，速度史无前例。但质量和可持续性，几乎完全取决于 surrounding process。

有好的onboarding、清晰的 guardrails（防护机制）、能访问公司上下文，用AI的开发者表现显著优于不用AI的。流程不成熟的环境？结果会快速失控。还没建立强工程直觉的开发者，会接受任何AI建议而不反思——因为他们没经验去质疑"看起来对但实际错"的东西。

Senior工程师则不同。无论流程成熟度如何，他们都能获得稳定的 productivity uplift。他们已经有判断力去验证、拒绝或重塑AI输出。

差距不在工具。在组织是否投资了支撑它的流程。

03｜"复制错误→等补丁→再复制"的死循环

AI生成的代码出问题，人的本能反应是什么？把错误复制回聊天框。补丁来了。又一个错误。重复。

这是心理学问题——当被反复投喂解决方案时，人会关闭思考，持续刷新。如果实现后出问题，通常 signal 的是项目理解有 gap，而不是缺一个补丁。

正确的回应是后退一步：trace数据流、读相关测试、理解问题周边的代码。没有这种 comprehension，AI和开发者都只能产出 shallow fixes，掩盖真正的 issue。

一位架构师描述过这种场景：「团队用AI两周重构了一个模块，benchmark 数字很漂亮。半年后一个边缘 case 暴露，才发现AI把两个不该耦合的概念缝在一起了——当时没人 review 出来，因为大家都只看AI给的结果，没追到底层设计。」

04｜没有上下文的AI，把代码库变成碎片

AI能辅助架构工作，但前提是它有 proper project context。没有的话，开发者会把代码库当成独立 prompt 的集合，而非 coherent whole。库的版本冲突、隐含的 domain 约束、历史技术债——这些不会出现在AI的训练数据里，除非你显式喂给它。

更隐蔽的问题是 knowledge fragmentation。以前代码 review 是知识传递的枢纽，senior 会在 PR 里解释"为什么不用另一种方案"。现在AI生成的代码往往直接通过——因为"看起来对"，而且"能跑"。

组织层面的应对正在分化。Netflix 和 Spotify 被曝在内部推行 "AI-assisted, human-validated" 的强制流程：AI可以写初稿，但必须附设计决策日志，reviewer 必须追问"为什么选这个方案"。另一些公司则完全放开，结果六个月后不得不回滚——因为关键模块的维护者离职，没人知道某段核心逻辑的存在理由。

那位CTO在1500万用户日的另一条消息是：「我们正在把onboarding任务重新设计为'AI禁用区'，强制新人手写前三周。听起来像开倒车，但测试组的理解深度确实回来了。」

工具永远中性。但组织怎么设计人与工具的交互界面，决定了你是获得杠杆，还是制造债务。

你的团队现在是什么状态——AI生成的代码，有人追问过"为什么"吗？