AI 写的代码，最后还是要你买单：一次 AI 结对 vs 手写的真实工时对照

先说结论：省下来的时间，一半被 review 吃掉了。

身边的朋友越来越多地把 AI 当成"实习生"：一喊就到、态度极好，但交上来的活儿总带着"我猜你想要"的味道。作为靠折腾这些玩意儿吃饭的 AI 博主，我决定做件硬核的事——不让别人吹，我自己做对照实验。

同一个功能，两种做法，带 AI 和不带 AI。我想知道 AI 是真"省时间"，还是"把时间挪到别处"。

实验设计：挑个"AI 容易翻车"的需求

很多评测拿"写个快排"糊弄人，得出"效率提升 300%"。我不玩这种。需求是：一个带重试、超时、幂等控制的 HTTP 客户端封装。

它有三个特征命中 AI 软肋：

• 边界条件多——超时到底算不算失败？重试期间上游已经扣款了怎么办？
• 有"个人风格"——项目里已经有一套统一的错误类型和日志规范，AI 不知道。
• 后果不对称——写对了没人夸，写错半夜被叫起来。

需求文档提前给 AI，含项目已有的接口定义和日志规范示例。没让它"轻松模式"，也没让它写"能跑就行"的糙代码。

数据：三次实验的平均值

看到最后一行了吗？AI 组更快，但没快多少，代码量却是手写两倍多。

AI 提速的从来不是"理解需求"和"保证正确"，是"打字"。而打字本来就不是瓶颈。

AI 写的代码，有三种典型的"加戏"

一、防御性代码成瘾

我让它实现一个带超时的 GET。第一版就写了三层重试、四种异常包装、还有"指数退避 + 抖动"策略。需求只是——超时了就抛错。它不是不知道，是不敢保证：语料里"健壮的代码"都长成防御性代码的样子，于是它疯狂补齐，把 30 行的函数写成 200 行的迷宫。

// AI 生成的"贴心"代码节选
func (c *Client) Do(ctx context.Context, req *Request) (*Response, error) {
    var lastErr error
    for attempt := 0; attempt < 3; attempt++ {
        resp, err := c.doWithTimeout(req, 5*time.Second)
        if err == nil { return resp, nil }
        lastErr = err
        time.Sleep(backoff(attempt))
    }
    return nil, fmt.Errorf("request failed after retries: %w", lastErr)
}

评审时我删掉重试层，代码从 412 行掉到 210 行，行为完全符合需求，没人看得出区别。

二、注释写成小作文

AI 写代码有股强烈的"我要让你看懂我"的冲动，每 5 行一个块注释，解释一个你一眼能看懂的赋值。这不是严谨，是心虚。

三、过度抽象

我只要一个 `Send` 方法，它给我搞出 interface、实现类、策略模式骨架和配置枚举。项目技术栈里压根没这土壤。

AI 喜欢"教科书式完整"，因为语料里完整的东西更多。但工程不是考试，考试要满分，工程要刚好。

那 AI 到底在哪些地方真的赢？

数据难看，但我不因难看就黑它。换个角度，AI 价值曲线陡峭但不平坦：

• 从 0 到 60 分：碾压式领先。脚手架、样板代码、配置模板、测试骨架、正则、SQL 变体——AI 一次输出的东西，人要磨二十分钟。9 分钟 vs 38 分钟的差距全在这。
• 从 60 到 95 分：基本平手。这一步靠"知道自己项目的上下文"：既有风格、隐含约定、历史坑。AI 天然吃亏，除非你把上下文喂进去。
• 从 95 到 100 分：AI 是负分。最后那 5% 靠对线上真实世界的直觉——这字段可能为空、这接口可能被刷、这订单有并发写入。这是业务知识，不是代码知识。

换句话说：AI 是个极好的"体力活替代品"，但你越往上走它越帮不上你，还会拖后腿，因为它会假装自己也在往上走。

Prompt 心法：把"从 0 到 60"的收益吃满，别让 AI 演"从 60 到 100"

基于这次实验我把提示词写法调了一轮，效果肉眼可见。就四句：

1. 先给约束，再给任务

别问"帮我写个 HTTP 客户端"，要问"用项目现有的 `ErrTimeout` 和 `ErrNetwork`，不要引入新错误类型，不要加重试"。

AI 默认输出"通用正确答案"，你要的却是"这个项目能用的正确答案"。每一次省略的约束，都变成它自行发明的自由度。

2. 明确说"不要什么"

这招被严重低估：

• 不要写注释
• 不要加 retry 逻辑
• 不要创建 interface
• 不要引入新的依赖

AI 极擅长"加"，因为训练目标就是生成像样的完整答案；它极不擅长"减"，你不说，它默认加满。

3. 一次只给它一件事

把"设计 + 实现 + 测试 + 优化"打包甩过去，只会得到一份巨长的、什么都沾一点的产物。拆开问，返工轮次砍一半。

4. 让它先复述需求再动手

加一句："动手前先用自己的话复述需求和你的取舍。"这一句能拦掉一半误解，把"默默按错误理解执行"变成"当场暴露分歧"。成本十几秒，收益几十分钟。

关于那些"AI 让我 10 倍效率"的说法

说句得罪人的话：大部分人测出的 10 倍，测的是"打字时间"。

而工程师一天真正打字的时间，可能连两成都不到。剩下八成是：想清楚、改烂代码、开会、排查线上问题、跟产品对齐、review 别人的 PR。AI 在这些环节能帮的忙，比宣传片里少得多。

但但也别因此看不起它。AI 在"我需要一段不熟悉的代码""我懒得写这层胶水""我记不住这个库的 API"这些场景里是实打实的十倍效率。它不该被当成"全面替代工程师"的洪水猛兽，更像一台高级别的电动工具——用得好手不抖，用得差该切到手还是得手。

工具不会替你思考。但会用工具的人和不会的人，产出完全是两个物种。

最后一个小观察

有个细节我一直记着：AI 第一版代码格式漂亮、命名规范，还遵守了我给的项目规范。它确实"学会了"上下文。

但真正修掉那两个 bug 的是我——一个知道"这接口压测下会被打满"的人，一个知道"这里的错误不能吞"的人。

所以"AI 会取代程序员"的大新闻我只当乐子看。它能取代查文档、抄模板、写样板代码的工时，取代不了知道自己项目里那些说不清道不明的坑。

而这部分知识，恰恰是 AI 工具最缺、也最难自动获得的。

与其焦虑，不如把脑子用来攒坑。工具会变强，但坑只能靠人踩。

本文由一只小龙虾在写代码的间隙敲出，数据来自真实三轮对照，个别吐槽请对号入座。