写代码的活儿现在基本不难了，难的是怎么让代码在生产环境活下来

现在在公司里推 AI 编程，最明显的体感就是：写出能跑通的代码已经完全不是技术门槛了。只要 Prompt 写得清楚，AI 随手甩出 40 行干净的代码，跑一遍，没 Bug，直接提交。这种效率提升确实让很多初级开发觉得爽，但作为在团队里带人的，我反而觉得现在是区分“熟手”和“新手”最残酷的时候。

很多新人觉得只要 AI 能生成代码，学语法就没那么重要了。但我得说，语法没死，只是它从“核心竞争力”变成了“基础配置”。你依然得能一眼看出 AI 生成的代码在干什么，在它自信地胡说八道时能及时叫停，并在它把逻辑写死的时候能迅速 Debug。

在公司实际落地 AI 之后，我发现初级和资深开发者的分水岭其实被拉得更开了。

初级开发者习惯于关注“怎么让代码跑起来”，这正好是 AI 最擅长的部分。中级开发者关注模块化、可维护性和扩展性，这些 AI 也能做得相当不错。但真正决定一个项目能否在真实业务场景中存活的，是那种对“失败模式”的预判，这部分目前依然是人类的领地。

AI 本质上是一个极其强大的模式匹配机器，它读过几乎所有公开的代码库，能把这些模式重新组合得像魔法一样。但它的天花板在于：它只能在已经被想象过、被写出来、被建模过的数据范围内工作。

在实际的项目评审中，这种差异非常具体。一个资深开发者在面对一段 AI 生成的、看起来完美运行的代码时，他不会觉得“太棒了，省事了”，而是会产生一种生理性的“焦虑”和“偏执”：

• 他在想： “这个逻辑在 Happy Path（理想路径）下没问题，但如果默认参数在实际运行中变得不可行怎么办？”
• 他在想： “AI 知道这个功能一旦流量激增一千倍会发生什么吗？”
• 他在想： “这个所谓的安全漏洞，在我们的业务逻辑里可能根本不是代码 Bug，而是内部流程泄露，AI 能感知到这种非技术性的失效吗？”

你可以通过 Prompt 让 AI 列举出可能的竞态条件（Race Conditions）或级联故障（Cascading Failures），但 AI 无法告诉你，在你们公司这个具体的、混乱的业务环境下，到底哪一种故障才会真正发生。这种判断依赖于对业务深层的理解和对现实世界复杂性的认知，这些东西没被写进 GitHub 的 Readme 里，AI 也就学不到。

所以，现在我们在团队里推 AI，重点不再是鼓励大家用它来替代写代码，而是要求大家把精力从“实现功能”转移到“定义边界”和“预演失败”上。

真正值钱的技能其实没变，甚至更重要了：

• 识别隐藏假设： 在需求还没变成代码前，就发现其中潜伏的坑。
• 划定系统边界： 清楚地知道系统在哪里结束，而混乱的现实世界从哪里开始。
• 想象失败场景： 预判那些没被文档记录过、没在互联网上出现过的崩溃方式。

简单来说，AI 可以生成能工作的代码，但它无法生成那种在看着系统崩溃后才养成的、对不确定性的恐惧感。而这种恐惧感，恰恰是工程实践中最高级的竞争力。