Vibe Coder vs. Software Engineer：AI 时代的工程伦理与责任边界

背景

近十年前，作者曾撰写过一篇关于“Java 开发者 vs. 软件工程师”的文章。当时，作者并未意识到人们将职业身份与特定编程语言（如 Java）绑定得如此紧密。那篇文章的核心目的是区分两种思维模式：一种是被特定语言定义的人，另一种则是从更宏观角度思考问题解决的人。

当时的讨论源于一个前提：Java 已成为行业标准，许多开发者开始从 Java 的视角向外看问题。工具成为了审视所有问题的透镜，当问题无法适配这个透镜时，人们往往强行扭曲问题以迎合工具。

虽然 AI 不仅仅是一门编程语言或框架，它从根本上改变了软件编写的经济学，但旧有的模式依然存在：当一种工具变得强大时，人们会将其包裹在职业身份中，最终导致技艺被简化为对工具的依赖。

如今，争论的焦点已不再是“AI 能否编写代码”（它显然可以，且日益精进），而是“这种过程产生的工作成果是什么”，以及当这些代码进入拥有真实用户、真实数据、合规要求和真实维护人员的生产环境时会发生什么。

核心内容

作者通过对比“Vibe Coder”（氛围程序员/直觉型程序员）与“Software Engineer”（软件工程师），深入剖析了 AI 辅助编程在工程实践中的本质差异。

错误的衡量指标

围绕 Vibe Coding 的许多讨论都在衡量错误的指标：人们展示从想法到应用的速度。这在验证想法时确实有价值，但在软件开发生态系统中，这只是冰山一角。

在团队环境中，代码进入代码库前需要经历一系列复杂环节：代码审查、理解意图、依赖关系评估、测试行为验证、模式变更、跨团队协调、回滚方案制定、运行手册编写以及故障响应。这些都不是个人玩具项目的一部分。

因此，作者提出衡量 AI 生成工作的正确指标应是 “安全合并时间”（Time to Safe Merge）。这不仅包括代码生成速度，还涵盖可审查性、风险、测试质量、所有权归属、回滚能力，以及作者能否解释变更中的关键决策。如果 AI 降低了代码生成的成本，却增加了安全合并的成本，团队并未获得预期的收益。

• Vibe Coder 衡量的是“首个可运行版本的时间”，适用于探索性发现阶段。
• 软件工程师 衡量的是“安全合并的时间”，适用于进入共享代码库的生产环境。后者包含了审查成本、测试成本、发布成本、回滚成本、协调成本以及未来的维护成本。演示只是证明“能展示”，而非证明“能被团队吸收”。

输出不等于进步

AI 辅助生成的代码应当更好，而不是更大。如果工具让你能生成更多内容，人类就必须施加更多约束。否则，你并没有节省工作，只是将工作转移到了下游，让维护成为他人的负担。

AI 生成的代码不能享有不同的标准，必须与手写代码遵循相同的规范：

1. 范围狭窄：只解决一个问题。
2. 无无关清理：不应包含与当前任务无关的代码清理。
3. 无随意格式化：不应因为模型“心情好”而重新格式化半个文件。
4. 明确依赖：不应添加没有清晰解释的包。

如果变更过大，必须拆分。作者指出，模型常为只需十行代码的功能生成大量样板代码。如果作者无法解释每个有意义文件的变更原因，该代码就不具备“所有权”（Ownership），也就不可合并。

• Vibe Coder 将生成的输出视为进步。
• 软件工程师 将任何变更视为责任单元。生成的输出可能是庞大、混乱且临时的，但真正的变更管理不能如此随意。变更必须足够狭窄以便于审查，足够可解释以建立信任，足够有边界以在不拖累整个系统的情况下合并。速度在此处要么成为助力，要么转化为“审查债务”。

AI 无法承担责任

审查 AI 生成的代码与审查人类代码不同。人类代码通常留有决策轨迹，即使有缺陷，作者也能解释为何使用某种抽象、为何放置某条规则或选择某个包。

而在 AI 生成的代码中，许多决策并非“决策”，而是“补全”（completions）。如果作者未将生成输出转化为“拥有”的工作，审查者实际上在做两份工作：审查和“作者身份恢复”。

• Vibe Coder 可以说：“是模型生成的。”
• 软件工程师 必须说：“我拥有它。”

这意味着作者必须在请求审查前，将生成的输出转化为工程决策。代码可能始于模型，但问责权不能停留于此。

上下文不仅仅是文件

模型现在可以阅读大量代码，但这不等于它理解系统。许多工程上下文存在于代码之外：事故记录、旧版迁移、用户行为、运营痛点、团队惯例、安全要求、合规规则以及过去的奇怪决策。

除非提供这些信息，否则模型并不具备这些上下文。即使提供了，模型也无法像工程师那样承载上下文，它仅在上下文窗口内工作。任务越大，模型越容易优化局部而损害全局。

因此，“直接让它修复整个东西”是一个坏习惯且往往无效。更好的模式是在请求代码前缩小决策空间。当作者更具指导性（prescriptive）时，模型的表现更好。但这要求作者深刻理解自己究竟想做什么。这也是资深工程师从 AI 中获得最大价值的地方：不是给模型更多自由，而是给模型更多约束。自由适合周末黑客松，生产环境需要约束。

• Vibe Coder 给模型一个目标。
• 软件工程师 给模型一个有边界的任务（Bounded Task）。例如：“使用这个接口，不要触碰这一层。”好的提示词在这里不是魔法，而是工程师已理解边界的证据。

Vibe Coding 应位于交付流程中的特定位置

Zig 语言创始人 Andrew Kelley 在采访中表示禁止 AI 贡献，称其为垃圾。这种观点反映了维护者面临的困境：大型 AI 生成的 Pull Request 常包含无关变更、破坏遗留行为、添加奇怪依赖，且贡献者无法解释代码。

但这并非对 AI 的判决，而是 Vibe Coding 跨越了界限后的产物。作者主张不禁止，而是“定位”。

这条界限是 “发现”（Discovery）与“交付”（Delivery） 的区别：

• 发现阶段：原型验证是无害的，没人拥有这些一次性代码。发现阶段可以容忍混乱，因为目标是学习或快速迭代。
• 交付阶段：不能容忍无法解释的混乱，因为目标是真实的业务结果。在交付中，你不能说“我们 99.9% 正确”，有时它必须完全正确。

这条界限是动态的，随着工具变得更好而移动，但其核心逻辑不变：Vibe Coding 属于交付流程中的特定环节，而非 everywhere。

关键要点

• 身份与工具的剥离：警惕将职业身份绑定在 AI 工具上，避免技艺被简化为对工具的依赖。
• 重新定义效率指标：从关注“首个可运行版本的时间”转向关注“安全合并的时间”，后者涵盖审查、测试、回滚及维护等全生命周期成本。
• 代码所有权（Ownership）：AI 生成的代码必须由人类作者完全理解并承担责任，作者需能将生成内容转化为工程决策，而非简单甩锅给模型。
• 约束优于自由：在工程实践中，给模型提供有边界的任务（Bounded Task）和明确的约束，比给予模糊的目标和自由发挥更能产生高质量结果。
• 上下文的重要性：模型缺乏对事故历史、团队惯例、合规要求等非代码上下文的理解，工程师需主动提供这些背景信息。
• 场景隔离：Vibe Coding 适用于“发现”阶段的原型验证，而不适用于“交付”阶段的生产代码。生产环境要求绝对的准确性和可解释性，不能容忍“差不多正确”。

意义与影响

这篇文章深刻揭示了 AI 辅助编程在软件工程领域的核心矛盾：生成速度与工程严谨性之间的张力。

1. 对招聘与团队管理的启示：企业不应仅看重开发者使用 AI 生成代码的速度，而应考察其“安全合并”的能力、代码审查意识以及对生成内容的掌控力。资深工程师的价值在于其定义边界和约束模型的能力，而非仅仅作为提示词工程师。
2. 对开发流程的重构：传统的 CI/CD 流程需要适应 AI 生成的代码