将近十年前，我写过关于 Java 开发者与软件工程师的文章。当时，我没有意识到人们是多么深刻地将他们的职业身份与 Java 绑定在一起。我的目标是区分由特定语言定义的人与更广泛地思考解决问题的人。整个讨论开始于一个前提：Java 已经成为了主流。许多开发者开始从 Java 的角度出发思考问题。这种工具成为了每个问题的透镜。当问题无法适应这种透镜时，它会被扭曲，直到适配为止。我不想过分地拉伸这个类比，因为 AI 不仅仅是另一种编程语言或框架。它改变了软件编写的经济学。然而，旧的模式依然存在：一种工具变得强大，人们围绕它构建自己的身份，然后这门技艺被简化为该工具。现在，问题不再是 AI 是否能写代码。它能，而且每天都在进步。问题在于这种过程会产生什么样的工作，当这些代码进入真实的代码库、面对真实的用户、真实的数据、真实的合规要求、真实的事件以及真正需要维护它的人时，会发生什么。这就是我看到的氛围编码者和软件工程师之间的区别。氛围编码者是通过生成软件原型来测试想法的人。而软件工程师则是考虑整个软件开发生命周期的人。所以区别不在于工具，而在于责任的开始和结束在哪里。能否合并？不当的衡量标准 关于氛围编码的讨论仍然测量着错误的东西。人们展示他们从想法到应用的速度。这是有价值的，特别是当目标是测试一个想法时。在一支软件开发团队中，有人需要对其进行审查。需要有人了解其背后的意图。需要有人决定依赖项是否合理。需要有人检查测试是否验证行为。需要有人申请模式更改。需要有人协调团队之间的变更。有人需要处理回滚。需要有人编写运行手册。需要有人回复警报。以上这些都不是任何玩具项目的一部分。因此，我会用不同的标准来衡量 AI 生成的工作：安全合并的时间。这包括可审查性、风险、测试质量、所有权、回滚，以及作者是否能够解释变更中的重要决策。如果 AI 使代码生成变得更便宜，但使安全合并的成本更高，那么团队所获得的价值远不如他们认为的那样。这是第一个区别。氛围编码者衡量从第一个工作版本的时间，而软件工程师则衡量安全合并的时间。第一个工作版本的时间在工作的发现阶段是有用的，而安全合并的时间在工作进入共享代码库时是必要的。它包括审查成本、测试成本、部署成本、回滚成本、协调成本和未来维护成本。这就是为什么演示是错误的终点。它只证明某样东西可以被展示，而不是它可以被团队吸收。输出不是进步 AI 辅助代码应该更好，而不是更多。如果工具让你生成更多，那么人类就要有更多的约束。否则，你就不是在节省工作，而是在把它推到下游，维护变成了其他人的琐事。AI 辅助代码不能被置于不同的标准下。它必须达到与人工编写代码相同的标准。因此，它应该是狭窄的。它应该有存在的一个理由。它不应该包含无关的清理。它不应该因为模型的感觉而重新格式化文件的一半。它不应该在没有明确解释的情况下添加包。如果变更很大是因为模型生成了太多，那么就分开处理。我在这方面经历过很多。它会愉快地为一个可以用十行代码完成的事情生成大量的模板代码。因此，如果作者无法解释每个有意义文件变化的原因，它就还不成熟。这是基本的所有权。第二个区别是工作单元。氛围编码者将生成的输出视为进步，而软件工程师将任何变更视为责任的单元。生成的输出可能很大、杂乱且临时。真正的变更管理无法那么随意。它必须足够狭窄以进行审查，可以解释以值得信任，并且足够有界以便合并而不会拖累半个系统。这就是速度变得有用或变为审查债务的地方。 AI 不能承担责任 审查生成的代码与审查正常代码不一样。当一个人编写代码时，通常会有一个决策的轨迹。它可能是有缺陷的，但至少有一个人可以解释这个过程。你可以问他们为什么使用那种抽象，为什么把规则放在那里，为什么选择那个包，为什么让测试看起来那样。对于 AI 生成的代码，其中一些决策不是决策，而是完成。如果作者没有将生成的输出转换为拥有的工作，那么审查人员将面临困境。