AI没有拉平差距，它在放大差距

2026年，同样在用AI写代码，有人产出翻了5倍，有人还在原地踏步。

最近看到一个现象挺有意思：公司里不同工程师用AI的体验，已经出现了明显的撕裂。

A说："AI太厉害了，上周三天搞定了以前要两周的需求。" B说："AI生成的代码一半是错的，改起来比自己写还慢。" C说："我就用来查查文档，别的不太敢用。"

这三个人可能坐在同一个工位排，用的是同一套工具，但体验完全不同。

这不是"会不会用工具"的问题那么简单。Karpathy上周发了条推文，大意是：AI Voice Mode在简单问题上还会翻车，但Codex已经能独立工作一个小时重构整个代码库。这不是两个产品的差距，是同一家公司在不同场景下AI能力的分化。背后的原因他也说了——代码有单元测试，有可验证的reward function，AI在这里进步最快。

所以AI没有拉平工程师之间的差距——它在放大差距。

先说清楚：差距是怎么来的

有个数据可以作为参照系。ClawBench论文测试了7个前沿模型完成153个真实日常在线任务的能力，Claude Sonnet 4.6的完成率只有33.3%。注意，这是"真实任务"，不是benchmark游戏。

这意味着什么？AI在实际工作中的成功率远低于它在演示视频里看起来的水平。一个不理解这个基准的工程师，会把AI的每一次失败都当成自己的问题；一个理解这个数字的工程师，会把AI当成一个成功率约三成的助手，为它准备好验收标准，出错时接管，而不是等待。

差距的来源，我觉得主要在三层：

• 任务定义能力：你能把一个模糊需求拆解成AI能处理的清晰子任务吗？这决定了AI给你的第一个输出有多好用。

• 输出验收能力：你能判断AI生成的代码是否正确、是否有坑、是否可以直接用吗？没有这个能力，你要么全信（出问题），要么全不信（浪费）。

• 反馈迭代能力：AI给了一个不够好的结果，你能快速描述哪里不对、怎么改吗？还是只会"不对，重新来"？

这三层能力，本质上都是工程师的基本素养——清晰思考、严格验证、有效沟通。AI工具的出现，让这些能力的价值被放大了，因为它们现在能影响一个人能否高效调用"全球最强编程助手"。

分层测试：你在哪个层级？

我自己想了一个粗糙的分层框架，可以用来自测：

L1 工具使用层

用AI查文档、补全代码、生成boilerplate。这是大多数工程师现在的状态，AI是个更好的搜索引擎加上智能补全。

问题是：这个层级的效率提升是线性的，而且很容易见顶。

L2 任务分解层

能把一个功能需求拆解成一系列AI可执行的子任务，并为每个子任务写清楚约束条件（输入格式、输出格式、边界条件）。用AI的方式从"帮我写XX"变成"我有一个需求，背景是Y，约束是Z，目标是实现X，先分析可行性再给方案"。

这一层的工程师，AI给出的初稿质量会明显更高。

L3 验收主导层

不只是知道怎么问，还知道怎么验。对AI生成的代码，有一套系统的验收流程：逻辑正确性、边界条件、性能影响、安全隐患。遇到AI自信地给出一个"感觉对但说不清哪里不对"的答案，能找到那个不对的点。

Simon Willison用Claude Code在手机上完成了SQLite QRF库编译为WebAssembly的任务——这件事的关键不是"AI完成了一个复杂任务"，而是他知道这个任务应该有什么样的输出，能在AI走偏的时候纠正方向。

L4 框架设计层

用AI解决一个问题，和用AI构建一套解决这类问题的框架，是两回事。L4的工程师在做后者：他们搭的不是一次性的解决方案，而是可复用的提示词模板、工作流程、验证脚本。

举个具体的例子：

L2的工程师会这样写prompt来做代码review：

# 临时prompt，每次手动写
帮我review一下这段代码，找出问题：
[粘贴代码]

L4的工程师会构建这样的可复用框架：

# review_template.md（可复用，团队共享）
## Code Review Context
- Language: {language}
- Change type: {change_type}  # bugfix / feature / refactor / perf
- Risk level: {risk_level}    # low / medium / high
- Related systems: {systems}

## Review Checklist
1. Correctness: Focus on {focus_areas}
2. Edge cases: Consider {edge_cases}
3. Performance: Check {perf_concerns}
4. Security: Validate {security_checks}

## Code
{code}

## Expected output format
- Summary: 一句话总结变更
- Issues: [严重度] 问题描述 + 修复建议
- Suggestions: 可选优化（非阻塞）

差距不只是这段代码的质量，而是这个框架可以被团队复用、持续迭代、不断精化。

最难突破的瓶颈：从L2到L3

很多工程师卡在L2和L3之间，原因我观察下来基本是同一个：对自己领域的知识不够扎实，导致无法有效验收AI的输出。

这有点反直觉。你可能觉得AI工具用得好，是因为你会"提问"。但更深的限制是：你不知道一个好答案长什么样。

举个例子：让AI优化一段SQL查询，AI给了你一个"看起来更优雅"的版本，加了些索引提示、改了JOIN顺序。你能判断这个优化是对的吗？你知道在你的数据库版本和数据分布下，这个改动会加速还是拖慢查询吗？

如果你不知道，你就只能赌。有时候赌对了，有时候赌错了，但你其实无法学习——因为你不知道为什么对/为什么错。

所以从L2到L3，核心是扎实的领域知识，而不是更好的prompt技巧。

具体到数据库优化这个场景，你需要能读懂EXPLAIN ANALYZE的输出：

-- 让AI优化之前，先跑一次，记录基准
EXPLAIN (ANALYZE, BUFFERS, FORMAT JSON) 
SELECT u.name, COUNT(o.id) as order_count
FROM users u 
LEFT JOIN orders o ON u.id = o.user_id
WHERE u.created_at > '2025-01-01'
GROUP BY u.id, u.name;

-- 关注这些关键指标：
-- 1. Seq Scan vs Index Scan（全表扫描通常是问题）
-- 2. actual rows vs estimated rows（估算差距大 = 统计信息过时）
-- 3. Buffers: hit vs read（缓存命中率）
-- 4. 总 actual time（实际执行时间）

有了这个基准数据，再把AI的优化方案拿来对比——这才是验收，而不是看代码是否"看起来更好"。

工程师的护城河在哪里

聊到这里绕不开一个问题：如果AI越来越强，工程师的不可替代性在哪里？

ClawBench的数据给了一个角度：AI在"真实日常任务"里的完成率只有三成左右，而且它在哪些任务上失败是有规律的——长任务（long-horizon）、涉及多系统协调、需要真实环境反馈的任务，AI的表现明显下滑。

Meta Muse Spark刚发布，benchmark上追上了顶级模型，但"在长任务agentic系统和coding workflow上仍有明显差距"——这是他们自己承认的。

这不是AI不行，这是AI在当前阶段的结构性限制：它没有真实世界的反馈回路，没有对你们系统历史的深度上下文，没有"这个改动三个月后会出什么问题"的长期判断。

所以工程师的护城河，我认为有三类：

• 系统性上下文：你知道这个系统是怎么演化来的，为什么现在是这个样子，改了这里会影响哪里。这些信息没有写在任何文档里，但你有。AI没有，也很难有。

• 跨域协调能力：一个需求可能涉及前端、后端、数据库、运维、产品多个维度。AI可以分别给你每个维度的方案，但把这些方案整合在一起、识别冲突、做出取舍，是人的工作。

• 对"错误"的品味：什么是技术债，什么是可接受的妥协，什么是必须修的坑——这些判断需要在具体业务上下文里做，没有通用答案。AI会给你一个"最佳实践"，但你需要判断这个最佳实践是否适合你现在的处境。

这三类能力，都不是靠学AI工具学出来的，而是靠做项目、踩坑、复盘积累出来的。

一个真实工作流参考

说一些比较具体的。以下是我观察到的L3/L4工程师的典型工作节奏，基于真实使用，不是展望。

需求阶段：先人工框架，再AI填充

接到需求，先自己想清楚核心数据结构和系统边界，再让AI帮你填充实现细节。顺序反了会很痛苦——AI会给你一个看起来完整但结构错误的方案，改起来比自己写还难。

# 好的需求拆解方式
需求：实现用户订单的优惠券核销逻辑

先自己定义核心约束：
- 一个订单只能用一张优惠券
- 优惠券有使用期限和使用次数上限
- 并发场景下需要防止超用
- 核销失败需要明确的错误信息给前端

然后让AI：
"基于以上约束，用Go实现核销逻辑。
使用数据库乐观锁防并发，
错误类型需要区分：已使用/已过期/不适用/库存不足"

编码阶段：AI写初稿，人做架构决策

让AI快速生成实现代码，自己主要做两件事：判断架构选择是否合理（比如AI用了什么设计模式、是否适合当前场景）、找边界条件和错误处理。

具体检查项：

• 错误是否被适当处理而不是被吞掉

• 数据库操作是否有事务保护

• 外部调用是否有超时和重试

• 日志是否足够（出问题时能排查）

测试阶段：用AI生成测试用例，重点关注边界

让AI生成基础测试用例的框架，然后重点检查和补充边界条件。AI通常会给你happy path的测试，但关键的错误场景、边界值、并发场景往往需要你自己加。

// AI生成的测试通常覆盖这些
func TestApplyCoupon_Success(t *testing.T) {...}
func TestApplyCoupon_Expired(t *testing.T) {...}
func TestApplyCoupon_AlreadyUsed(t *testing.T) {...}

// 你需要额外加的
func TestApplyCoupon_ConcurrentUsage(t *testing.T) {
    // 模拟10个并发请求同时核销同一张只剩1次的优惠券
    // 验证只有一个成功，其他9个返回"库存不足"
    var wg sync.WaitGroup
    results := make(chan error, 10)
    for i := 0; i < 10; i++ {
        wg.Add(1)
        go func() {
            defer wg.Done()
            results <- applyCoupon(ctx, couponID, userID)
        }()
    }
    wg.Wait()
    close(results)
    
    successCount := 0
    for err := range results {
        if err == nil {
            successCount++
        }
    }
    assert.Equal(t, 1, successCount, "只能有一次成功核销")
}

怎么从L2往上走

这个问题没有捷径，但有方向。

首先，不要只学AI工具，要学AI失败的地方。

主动测试AI的边界——给它你工作中真实遇到的难题，观察它在哪里失败、为什么失败。这比看任何"AI最佳实践"文章都有用。

比如：让AI帮你排查一个你熟悉的bug，然后检查它找到的是不是真正的根因。让AI优化一段你写的算法，然后benchmark对比是否真的优了。这个过程会让你快速建立"AI在什么情况下可信、什么情况下要打折扣"的直觉。

其次，在你擅长的领域深化，而不是追AI的广度。

很多工程师的焦虑是"AI学的东西太多了，我跟不上"。但这个焦虑方向是错的。你不需要学会用AI做所有事，你需要在你最熟悉的2-3个领域里，把AI用到极致，建立起可复用的工作流。

深度 > 广度。在你最懂的地方用好AI，才能真正理解"用好AI是什么感觉"，然后把这个感觉迁移到其他领域。

最后，建立自己的"AI能力档案"。

不是只记录用了哪些工具，而是记录：在什么场景下AI帮了你什么、AI在什么地方让你踩坑了、你发现了哪些可复用的prompt模式。

# 我的AI协作日志（简单格式）
## 2026-04-10
场景：重构订单状态机
AI给的：基本状态流转逻辑 ✅，但漏了退款中间态
我补充：退款相关的状态转换，加了cancel→refunding→refunded
教训：状态机有业务特有状态，AI不知道你的历史债，要显式说清

## 2026-04-09  
场景：写Kafka消费者的幂等处理
AI给的：基础去重逻辑（基于消息ID）✅
AI没给的：Redis key过期策略（我们消息有时延长达48小时）
教训：涉及时间窗口的幂等，要把时间窗口作为约束显式传入

这个日志不需要很正式，每天花5分钟记一下。三个月后回头看，你会发现一个清晰的模式：哪类任务你已经能高效用AI，哪类还需要提升，以及你自己独特的"AI协作风格"。

写在最后

AI工具的普及，确实在降低某些门槛——入门编程、写CRUD、生成样板代码。但它同时在提高另一些门槛：清晰地定义问题、严格地验证结果、在复杂系统中做出判断。

差距不会消失，只会换一种形式存在。

以前你和同事的差距，可能是"谁的代码更熟练"。现在越来越变成"谁能用AI产出更高质量的结果"。后者需要的，其实还是那些老的工程师素养：深入理解、严格验证、清晰思考。

Karpathy说Codex能独立重构代码库，但他也是那个能判断重构结果好不好的人。工具再强，也需要一个知道"好"长什么样子的人来验收。

值得继续探索的方向：如果你在团队里，怎么设计一套让整个团队都能从L2升到L3的机制？单人提效容易，组织级的AI协作升级，才是下一个有意思的问题。

如果这篇文章对你有用，欢迎转发给同样在思考这个问题的工程师朋友。