25年经验的工程师不会告诉你的 AI 编程真相

Vibe Coding 和 Agentic Engineering：两个世界的碰撞

Vibe coding = 你告诉 AI 要什么，它给你什么，你不管代码。Agentic engineering = 你懂代码，AI 放大你的能力。但现在，Willison 发现两者正在融合。

这不是一个学术分类问题。这是一个关于责任归属的哲学问题。

什么是 Vibe Coding

Vibe coding 是 2026 年初爆火的一个词。它的定义很简单：

你可能完全不懂编程。你告诉 AI 要做一个什么东西，AI 做出来了，如果能用，你就用；如果不能用，你就告诉 AI 哪里不对，然后继续祈祷。

关键特征是：你从头到尾没有看过代码。你甚至可以不懂编程。

Simon Willison（知名技术博主，Datasette 和 sqlite-utils 的作者）对 vibe coding 的态度很明确：

它是 fantastic 的，前提是你理解什么时候能用、什么时候不能用。它是你个人的工具——如果出 bug，只伤害你自己，那就用吧。但如果你是给别人做软件，vibe coding 就是 grossly irresponsible，因为别人的信息会被你的愚蠢 bug 伤害。

什么是 Agentic Engineering

与 vibe coding 相对，agentic engineering 是 Willison 提出的另一个概念，用来描述专业软件工程师如何使用 AI 编程工具：

你是专业的软件工程师
你理解安全、可维护性、运营、性能
你在用这些工具最大化自己的能力
目标是建造高质量的生产系统

核心区别在于：agentic engineering 的从业者不会为了速度而牺牲质量。Willison 说他想要的是「更高质量的东西更快」，而不是「更低质量的东西更快」。

两者正在融合——Willison 的不安

事情起了变化。

Willison 在一次播客访谈中意识到：作为有 25 年经验的专业工程师，他已经不再 review AI 生成的每一行代码了。

他的原话是：

我已经不 review Claude Code 写的很多代码了，即使是生产级别的代码。我知道如果我让 Claude Code 写一个 JSON API 端点，运行 SQL 查询并输出 JSON，它就是会做对。它不会搞砸。你让它加自动化测试、加文档，它就是会做好。

但紧接着，他说了一句让所有 AI 编程者不安的话：

这个感觉仍然让我不舒服。如果我没有 review 代码，在生产环境用它算不算负责任？

责任归属的空白

为什么 Willison 会感到愧疚？

因为人类工程师是有职业声誉的。一个团队建立了信誉，你知道他们过去构建了好的软件，你信任他们。但 Claude Code 没有职业声誉——它不能为自己的代码负责。

然而，Claude Code 每次都在证明自己。简单的事情，它就是能做对，而且是按照 Willison 喜欢的风格做的。

这里出现了一个认知空白：

Claude Code 没有声誉，但有可靠性
没有声誉 = 无法被追责
有可靠性 = 实际上不需要 review

Willison 的解法是：用团队信任模型来理解 AI 编程。

用团队信任模型理解 AI

Willison 回忆他在大公司做工程经理时的情况：其他团队构建的软件，他的团队也会依赖。他不会去读另一个团队写的每一行代码——他会看文档，测试接口，然后开始构建自己的功能。只有出问题的时候，才会深入 Git 仓库看细节。

换句话说，他treating 那些团队为 semi-black box，直到需要为止。

Willison 开始用同样的方式对待 AI 编程工具。

但这仍然让他不舒服。为什么？

因为你永远不知道 AI 什么时候会在错误的地方信任自己，然后在那一刻被烧伤。

这就是「deviance 正常化」的风险——每次模型在没有严密监控的情况下写出正确代码，你对它的信任就多一分。而这份过度信任，终将让你在某个关键时刻失败。

怎么判断 AI 写的代码靠谱？

还有一个更基本的问题：如何评估 AI 生成的软件质量？

以前的判断标准很简单：

GitHub 仓库有 100 个 commit
有好的 README
有自动化测试

→ 这说明开发者在这个项目上投入了大量精力，项目靠谱。

但现在，AI 可以一天之内生成这样的仓库。这些信号失效了。

Willison 没有给出完整答案，但他的思考指向了一个方向：

也许我们需要像评估人类开发者一样评估 AI——看它的行为历史，而不是它的「出身」。

给 AI 编程者的行动指南

基于 Willison 的思考，我整理了以下框架，帮助你判断什么时候该 review、什么时候可以信任 AI：

1. 区分场景：私人 vs 给人用

私人工具：vibe coding 可以，接受 bug 的风险自负
给别人用的软件：至少做基本验证，不要完全依赖 AI

2. 评估 AI 的「经验」

简单、标准化的任务（CRUD API、简单脚本）：AI 可靠性高，可以少 review
复杂、业务逻辑强的任务：AI 可能在边界条件上出错，需要更多关注

3. 建立「信任分层」

完全信任层：标准库用法、简单查询、格式转换
验证层：业务逻辑、数据库操作、第三方集成
深度 review 层：安全相关、财务相关、用户数据处理

4. 保持对专业的敬畏

Willison 说得最好：

如果你 building 的是 lower quality stuff faster，我认为这是坏的。我想要的是更高 quality 的东西更快。我想要一切都在各方面变得更好。

AI 是工具，工具是放大器。你是好的，AI 放大你好；你是糙的，AI 放大你的糙。

结语

Vibe coding 和 agentic engineering 的边界正在模糊，这不是坏事。但模糊的边界不意味着责任也跟着模糊。

作为 AI 编程者，你需要问自己的问题是：

谁会为这个 bug 付出代价？
是我自己，还是我的用户？
如果 AI 写的代码出问题，我能向用户解释吗？

如果你能回答这些问题，你就知道该在什么时候 trust AI，该在什么时候 review 它的代码。

这不是关于 AI 能不能信任的问题。这是关于你愿意为多大程度的信任付出代价的问题。