AI 原本该让初级发光，为什么反而让资深更强？

背景与问题

“AI 会取代程序员吗？”这个问题已经被问烂了。更具体的一个叙事是：企业将减少对资深工程师的依赖，由“AI + 初级”组合承担更多产出。然而，落地后的真实世界反馈显示：在可交付价值、稳定性与演进能力上，AI 反而更像是资深开发者的“增幅器”。

原因并不神秘。AI 非常擅长快速产出样例、搭建脚手架、拼装常见套路、尝试多种实现并进行快速迭代。这些能力若落在具备系统化建模、边界掌控与风险意识的工程师手中，会直接转化为可维护的增量；若落在尚未建立工程判断与抽象能力的开发者身上，往往会放大不可见风险，制造更多后续成本。

核心概念与原理

首先要承认 AI 的优势：它让“重复劳动最小化”和“探索路径并行化”变得触手可及。只要目标清晰、边界明确、验收标准确定，AI 带来的加速是真实的。然而软件开发的价值密度并不在代码行数，而在“问题定义、约束设计、架构划分、抽象取舍、质量与安全闭环”等环节。这里的人类经验与上下文洞察仍然不可替代。

其次是非确定性的根问题。模型输出受提示工程、上下文质量、温度参数、语料覆盖等多因素影响，同一任务多次运行可能产生不同结果。非确定性的代价，需要通过“确定性”的工程手段来兜底，包括面向行为的测试、代码审查、静态分析、运行观测与回滚机制等。真正能把 AI 结果变为可交付价值的，是那套“把不确定变确定”的工程化体系，而这正是资深开发者的长项。

再次看“认知负荷”的转移。写好提示词并非语言技巧，而是架构化表述能力——目标、约束、输入输出契约、边界条件、质量标准与验收方式，必须清清楚楚。具备系统思维的人写出的提示，能把 AI 引导到正确的搜索空间；缺乏该能力时，即便生成了“看似可用”的代码，也往往隐藏逻辑漏洞、性能隐患与安全缺口。

实战与代码示例

把 AI 当作“加速器”，而不是“代理人”，是更稳妥的定位。一个常见、但容易做错的场景，是让 AI 既写实现又写测试，然后据此宣告“通过验证”。更可靠的方式，是保持职责分离：

• 使用 AI 生成样例实现与替代性实现，人工确立契约与验收标准；
• 测试用例由人主导设计（尤其是边界与逆向场景），必要时让 AI 补充样例数据；
• 通过快速原型验证可行性，再将成熟实现重构进既有架构与分层边界。

下面是一个最小示意，展示如何将“契约优先”的思路落到代码与测试上。示例以伪代码表达要点：

# 契约优先：先定义输入/输出与不变量
spec CalculatePrice(
  input: { items: List<Item>, currency: string, userTier: string },
  output: { total: decimal, tax: decimal, discounts: List<Discount> }
) requires items not empty and currency in ISO4217
  ensures total >= 0 and tax >= 0

# 让 AI 先给出若干实现雏形（不同策略），人来评审并合成最终版本
impl_v1 = AI.generate("basic price calc with tiered discounts and VAT")
impl_v2 = AI.generate("same behavior but with promotion rules separated")

# 人为制定覆盖关键边界的测试（可让 AI 生成数据样例，但用例意图由人定义）
tests = [
  { name: "empty items -> invalid", expect: Error(InvalidInput) },
  { name: "mixed tiers", input: ..., expect: { total≈..., discounts contain ... } },
  { name: "currency not supported -> invalid", expect: Error(UnsupportedCurrency) },
  { name: "precision rounding", input: ..., expect: { total has 2 decimals } }
]

# 在 CI 中对 impl_v1/impl_v2 执行同一组测试，观察行为差异；
# 决定取舍并重构进当前架构的定价模块（边界清晰、依赖可替换）。

这个流程的关键不在“谁写出了更多代码”，而在于“谁定义并守住了契约与质量红线”。当目标足够清晰、反馈足够快速、边界足够稳固时，AI 的速度优势就会被放大；反之，它会把不确定性传播到系统的更深层。

常见陷阱与最佳实践

最常见的误区，是把 AI 当作“资深替身”，让其输出绕开必要的评审、测试与安全校验。这样做短期看似“省时省钱”，中长期却会形成技术债务与信任赤字，表现为抽象错位、耦合失控、跨域边界被随意穿透、权限与数据保护不足等。另一类误区，是“以 AI 代替学习”：当开发者缺乏对产出质量的判断力时，很容易被“可运行”所迷惑，忽略了可演进与可维护。

更稳妥的实践路径是：

• 先架构后编码：在清晰的模块边界、依赖方向与数据契约之上使用 AI；
• 先规范后协作：建立提示工程模板、代码风格、日志与错误模型、异常与重试策略等共同语言；
• 先校验后合入：单测/契约测试/静态分析/安全扫描/基准测试，多维度兜底；
• 先培养后赋能：让资深主导评审与知识萃取，用 AI 作为“放大镜”而非“挡箭牌”。

这些做法并不会降低 AI 的效率收益，反而将其限定在“可控增益”的范围之内，使其与工程化能力形成正向耦合。

总结与参考资料

短期内，AI 并不是资深工程师的替代者；相反，它把资深的系统思维、抽象能力与质量意识成倍放大。对于初级开发者而言，最值得投入的仍然是扎实的工程基本功，以及在实践中不断校准对“好代码”的判断。组织层面，应该重塑期望：把 AI 作为加速器、不是代理人；把资深与 AI 结合，产出稳定、可演进、有安全与质量边界的成果；把培养与复盘纳入流程，让“AI + 工程化”形成合力，而非彼此对冲。

参考资料：

• 原文：AI Was Supposed to Help Juniors Shine. Why Does It Mostly Make Seniors Stronger?（https://elma.dev/notes/ai-makes-seniors-stronger/）