Vibe Coder 和软件工程师是两种人¶
Yusuf Aytas 近日发表一篇题为 " Vibe Coder vs Software Engineer " 的文章在开发者社区迅速传播。 Aytas 此前曾写过 Java 开发者与软件工程师的区别，这次他把分析框架应用到了 AI 辅助编程这个当前最热也最混乱的话题上。文章用六组核心差异定义了两类用 AI 写代码的人，但全文的根本判断只有一个： AI 改变的是代码生成的成本，而非代码质量的成本。如果你只衡量前者而忽略后者，你可能正在获得速度的同时失去软件。
Aytas 提出的第一个区分，也是全文的出发点，是用 "从想法到可用应用的耗时" 来度量 vibe coding 的效率是在量错误的东西。在团队环境中，代码不只是跑起来就算完成 —— 它必须经过审查、理解意图、检查依赖、验证测试、执行 schema 变更、跨团队协调、规划回滚、编写 runbook 、响应线上事故。他提出了替代指标："安全合并时间"（ time to safe merge ），涵盖可审查性、风险、测试质量、所有权、回滚能力以及作者能否解释有意义的决策。结论直白： demo 不是正确的终点线。如果 AI 让代码生成更便宜但让安全合并更昂贵，团队的净收益就比看上去更低。
第二个区分关于输出与责任。 AI 生成的代码必须与手写代码遵循相同标准，甚至更严格。改动应当窄而聚焦，有单一的修改理由，不夹带无关的清理，不重新格式化文件，不无故添加新包。 Aytas 指出，模型会 "愉快地为你生成大量样板代码，而这件事你用十行就能写出来"。如果作者不能解释每一个有意义的文件为何发生了变化，改动就不应该合入。软件工程师把每次改动视为一份责任单元 —— 足够窄以利审查，足够可解释以可信赖，足够受控以安全合并。
第三个区分是最为微妙的一个，涉及 AI 代码审查的核心困境。审查人类代码时，审查者可以通过代码推断作者的意图和权衡。但 AI 生成代码中的一些 "决策" 实际上只是概率分布下的 token 完成 —— 它们看起来像决策，但背后没有思考过程。 Aytas 的观点是，如果代码作者没有将生成输出转化为自己拥有的工作成果，审查者就得承担双重职责：既要审查代码质量，又要反向推测 "原作者" 的意图 —— 而这个意图在 AI 那里本来就不存在。
第四个区分关于约束的价值。模型可以读代码但不理解系统。关键工程上下文活在代码文件之外：历史事故中积累的经验、旧数据迁移留下的坑、客户行为中的边缘情况、运维团队的切身痛点、团队自定的编码惯例、安全合规的硬性要求。模型做局部优化，却可能全局破坏。 Aytas 的经验是，有经验的工程师从 AI 中获得最大价值的方式不是给模型更多自由，而是给它更少 —— 明确指定使用的接口、限制触碰的层次、约束变化的范围。他的原话：" vibe coder 给模型一个目标，软件工程师给它一个有约束的任务。"
第五个区分将问题放到了流程层面。 Aytas 将软件开发分为发现（ discovery ）和交付（ delivery ）两个阶段。发现阶段可以容忍混乱，因为目标是学习和验证假设 —— vibe coding 在这里是有效的。交付阶段不行，因为真实的业务结果面临风险 —— 需要工程纪律。同一个人可以在发现阶段用 vibe coding 快速试错，在交付阶段切换到软件工程模式。"关键技能是知道自己处于哪种模式，并防止习惯在两者之间渗透。"
第六个区分最为深层，涉及职业成长的本质。 Aytas 认为初级工程师应该用 AI 来解释代码、比较方案、生成示例，但如果用 AI 来回避理解系统本身，"他们可能交付更多但学到更少"—— 这在早期职业生涯中是极差的交易。他引用了 Zig 语言作者 Andrew Kelley 禁止 AI 贡献的决定作为注脚。 Kelley 将代码审查描述为 "贡献者扑克"—— 开源项目通过审查 PR 来发现值得培养为核心团队成员的人。 AI 生成的 PR 打破了这套机制，因为它们抹去了审查中的学习信号。
文章最终归结为一个实用框架：当主要产出是创意探路时， vibe coding 有价值 —— 它缩短了想法与可点击原型之间的距离。当主要成本是所有权时 —— 控制什么进入系统、如何审查、如何加固、如何测试、如何运维、如何在未来变更 —— 你需要的是软件工程师。这六组差异不是给开发者贴的固定标签，而是同一个工程师在不同阶段应该能自由切换的两种工作模式。但前提是，你得能分辨自己正在哪一个模式里。
Aytas 的这篇文章之所以引发共鸣，在于它拒绝了两极化的立场。他不是在反对 AI 辅助编程，也不是在鼓吹 AI 万能。他是在说：工具改变的是生产成本，但生产纪律是工具无法代劳的。在一个 AI 让 "看起来能工作" 越来越容易的时代，真正稀缺的已经不是代码，而是对代码进入生产后会发生什么的判断力。