先说结论： 当 AI 能生成 46% 的代码时，"写代码"本身的价值在下降——但"验证代码是否正确"的价值反而在上升。这篇文章会告诉你为什么，以及作为测试从业者该如何应对。
本文目录：
- Karpathy 说了什么？为什么重要？
- 代码变成消耗品的数据证据
- 被忽略的核心问题：AI 写的是你要的吗？
- 什么是可丢弃的 vs 不可丢弃的
- 测试平台的价值重定位
- 给测试从业者的建议
正文约 3500 字，阅读约 8 分钟。
一、Karpathy 说了什么？为什么重要？
Andrej Karpathy——前 Tesla AI 总监、OpenAI 联合创始人。如果你关注 AI 领域，这个名字不需要多介绍。
2025 年 12 月，Karpathy 在他的年度回顾博客中写道：
"Code is suddenly free, ephemeral, malleable, discardable after single use."
（代码突然变成了免费的、短暂的、可塑的、用完即弃的东西。）
他还提出了一个概念叫 "Vibe Coding"：
"完全沉浸在 vibes 里，拥抱指数增长，忘记代码的存在。"
Karpathy 自己的实践是这样的：
"我永远点'全部接受'，我不再看 diff 了。遇到报错就直接复制粘贴进去，通常这样就能修复。代码增长到我自己都理解不了的程度。"
他还提到自己 "vibe coded 了一整个临时应用，就为了找一个 bug，why not"。
这不是边缘观点。当 Karpathy 这个级别的人公开说"代码变成了消耗品"，你得认真想想这对测试行业意味着什么。
二、代码变成消耗品的数据证据
Karpathy 不是在夸张。数据说明一切：
| 指标 | 数据 | 来源 |
|---|---|---|
| GitHub Copilot 用户数 | 1500 万+（一年增长 4 倍） | GitHub 官方 |
| AI 生成代码占比 | 46%（Java 项目高达 61%） | GitHub/Medium |
| 新开发者 Copilot 使用率 | 80% 在第一周就开始用 | GitHub Octoverse |
| 开发者每周使用 AI 辅助编程 | 67% 每周至少 5 天使用 | Accenture |
| YC W25 初创公司 AI 代码占比 | 25% 的公司代码库 95% 由 AI 生成 | Y Combinator |
这些数字说明一件事：AI 辅助编程不是未来，是现在。
当代码生成速度比阅读速度还快，软件开发的经济学就变了。花几个小时打磨完美的抽象？没必要了——几分钟就能重新生成整个模块。
代码正在变成消耗品。事实，不是炒作。
三、被忽略的核心问题：AI 写的是你要的吗？
但 Karpathy 没提的是：AI 生成的代码，真的是你想要的吗？
很多人讨论 AI 代码的安全漏洞问题——这确实存在。但这不是核心问题。
核心问题是：需求符合性。
你想啊，你让 AI 写一个"用户登录"功能。它写出来了，能跑。但你怎么知道：
- 它做的是你要的吗？ 你要的是邮箱登录，它给你加了手机号登录，你要吗？
- 它多做了什么？ 你没要求"记住我"功能，但它加了，还默认开启，这符合你的隐私政策吗？
- 它漏做了什么？ 你需要登录失败后锁定账户，它没做，你发现了吗？
- 做了的功能完全符合需求吗？ 你要求密码至少 8 位，它实现成了至少 6 位，你知道吗？
这才是问题的本质：AI 生成的代码能跑，但"能跑"不等于"对"。
以前开发者自己写代码，他知道自己写了什么。现在 AI 写代码，开发者只知道自己想要什么——但不一定知道 AI 给了什么。
Karpathy 自己说的：
"代码增长到我自己都理解不了的程度。"
如果你都不理解代码做了什么，你怎么确定它做对了？
悖论来了：
代码生成越容易，确认代码正确越难。
换句话说：
AI 没有减少测试的需求。它增加了对"确认需求是否被正确实现"的需求。
这不是在测试代码有没有 bug。这是在测试：AI 给你的，是不是你要的。
四、什么是可丢弃的 vs 不可丢弃的
代码变成消耗品了，那什么东西不能丢？
我琢磨出了一个框架：
可丢弃的（Disposable）：
- 测试脚本代码本身
- 具体的实现细节
- 样板代码
- 语法和格式
这些东西可以被 AI 重新生成，成本趋近于零。
不可丢弃的（Durable）：
1. 意图（Intent）
- "验证用户能成功下单" 是持久的
- 具体检查按钮点击的 Selenium 脚本不是
2. 编排（Orchestration）
- 测试之间的关系是什么？
- 什么时候运行？什么条件触发？
- 失败时怎么处理？
- 这些逻辑比任何单个测试脚本都长寿
3. 持续性数据（Persistent Data）
- 测试执行历史
- 趋势分析
- Flaky Test 检测
- 这些数据无法用 prompt 重新生成
4. 集成点（Integration Points）
- 测试如何与 CI/CD 连接？
- 如何与监控系统、告警系统、ChatOps 集成？
- 这些连接是基础设施，不是代码
关键洞察：
Pipeline YAML 不是"可丢弃的代码"。它是业务逻辑的表达——描述的是"你要验证什么、什么时候验证"。这不会因为 AI 能重新生成单个测试脚本就过时。
同样，当监控系统发现异常并自动触发回归测试——这个能力不是可丢弃的。Webhook 集成、条件逻辑、升级规则——这些代表的是超越任何具体实现的架构决策。
五、测试平台的价值重定位
作为 Testany 的联合创始人，我一直在想：在这个新格局下，我们的价值到底在哪？
想清楚了：
我们拥抱生成式测试
Testany 的 OpenAPI Test Generator 可以从 API 规范自动生成测试用例。代码生成不是护城河——是基础能力。AI 能写测试脚本，这是事实，抗拒没意义。
但我们的核心价值不在生成的代码
而在于：
1. Pipeline 定义
- 基于 YAML 的流水线语言
- 表达测试意图和编排逻辑
- 描述的是"你要验证什么"，而不是"如何实现"
- 这是持久的
2. Gatekeeper 集成
- Webhook 连接测试与 CI/CD、监控系统、聊天平台
- 当 PagerDuty 告警时，测试自动运行
- 当测试失败时，Slack 通知正确的人
- 这些集成点代表的是超越单个测试的基础设施决策
3. 执行历史
- 每次测试运行都产生数据：通过率、耗时趋势、flaky 模式、失败关联
- LLM 无法生成你的历史执行数据
- 这是不可替代的组织知识
4. 凭证管理
- API 密钥、认证令牌、环境配置
- 这些需要安全、持久地管理——不是每次会话重新生成
价值重定位总结：
我们不是一个"管理你的测试代码资产"的平台。
我们是一个管理你的测试意图、编排和执行历史的平台。
代码可以丢弃。系统不可以。
六、给测试从业者的建议
如果你也在想 AI 时代怎么做测试，这是我的建议：
1. 重新理解"测试"的意义
以前测试是找 bug。现在测试更重要的是：确认 AI 给的是不是你要的。
这意味着测试用例要从需求出发，不是从代码出发。先想清楚"这个功能应该做什么"，再验证"它是不是真的这样做了"。
2. 投资编排层
Pipeline 定义——什么时候运行、依赖什么、失败怎么办——比单个测试实现活得久。
花时间把编排做对。它会比好几代测试代码都活得长。
3. 从"一次性验证"转向"持续验证"
旧模式：写测试、运行、绿了就发布。
新模式：有意义的测试持续运行，短间隔，把它们当作监控。
当 AI 生成代码比你审查代码还快，安全网必须是自动化的、始终开着的。
4. 把测试基础设施当生产基础设施
同样的可观测性。同样的可靠性要求。同样的投资优先级。
如果你的测试环境是个只有出问题才看的黑盒，你还没准备好迎接 Vibe Coding 时代。
5. 维护组织知识
执行历史、趋势数据、失败模式——这些是时间积累出来的资产。它们为未来决策提供信息，提供 LLM 没有的上下文。
这些东西，别丢。
写在最后
Karpathy 说得对：代码正在变得 free、ephemeral、malleable、discardable。
但他还说了一句：
"尽管进展迅速，行业只实现了不到 10% 的 LLM 潜力。"
如果我们才刚开始——如果代码生成会变得更容易、更快——那验证代码的能力会变得相应更有价值。
想想看：当谁都能用几个 prompt 生成一个能跑的应用，什么区分了那些在生产环境真正能用的应用？
不是代码能不能跑。是代码做的是不是你要的。
代码可以是一次性的。
对"这就是我要的"的确信？不行。
作者是 Testany 的联合创始人，Testany 是一个企业级端到端测试平台。本文观点基于测试基础设施的工作经验，但适用于整个行业。
参考资料：
