图片来源：yucelyilmaz / Shutterstock

让人工智能源源不断地生成劣质代码，然后由人类进行调试和维护，这对任何人的业务发展都没有帮助。

软件开发领域正存在一种根深蒂固且危险的误区，即认为产出等于结果。这种观点认为，只要人们投入更多的时间或更多的代码行数，就一定能解决问题。

《实践工程师》（The Pragmatic Engineer）杂志的创始人格尔盖伊·奥罗斯（Gergely Orosz）最近以精准的论证驳斥了这一“迷思”。

奥罗斯对“996”工作文化：即每周六天、每天朝九晚九的工作模式，这种模式由中国科技企业推广开来的方法论提出了尖锐的批评：

“我很难举出一个真正值得关注的‘996’公司，它们的产品要么是抄袭，要么是炒冷饭，都是对其他地方已经推出的更优秀产品的简单复制。”这种工作时间和节奏不仅不人道，而且适得其反。

“蛮力可以带来销量，但很少能带来差异化，而且（或许）永远无法带来创新。”

现在，在我们开始对中国这种“996”模式嗤之以鼻之前，不妨先反思一下我们自身的模式。创始人将其包装成“硬核”、“全力以赴”或“苦读文化”，但本质上却是一样的：用大量时间压榨员工，然后期待最终能产出惊世之作。而现在，我们正试图将这种理念付诸实践，更确切地说，是运用GPU来实现。有些人认为，只要我们能让大语言模型（LLM）每周工作相当于上千小时，以超人的速度生成代码，就能神奇地获得更优秀的软件。

而我们不会。我们只会得到更多我们已经拥有的东西：衍生代码、臃肿的代码，以及越来越难以管理的代码。

代码频繁变更的高昂成本

有专家指出，互联网正被低价值、高数量的内容所淹没，因为我们让内容生产变得轻而易举。同样的情况也正在我们的软件行业发生。

我们有数据可以佐证这一点。正如我在报道GitClear 对 1.53 亿行代码的 2024 年分析报告时所指出的，“代码变更”（即两周内被修改或丢弃的代码行）正在激增。研究表明，复制粘贴的代码越来越多，而重构的代码则显著减少。

换句话说，人工智能确实能帮助我们更快地编写代码（根据GitHub 的分析，速度提升高达 55% ），但它并没有帮助我们构建更好的代码。我们生成的代码更多了，对代码的理解却更少了，而且需要更频繁地修复。人工智能真正的风险不在于它编写代码，而在于它鼓励我们编写过多的代码。臃肿的代码库更难维护，更难理解，也更难由人来管理。代码越少越好。

这就是将“996陷阱”转移到机器上的体现。

“996思维”认为创新的制约因素是工作时长。“人工智能原生”思维则认为制约因素是输入的字符数。两者都是错误的。真正的制约因素始终是思维的清晰度。

代码是一种负担，而非资产。

让我们回归基本原理。任何资深工程师都知道，软件开发并非一场打字比赛，而是一个决策过程。这项工作与其说是编写代码，不如说是思考哪些代码不该写。

Honeycomb 的创始人兼首席技术官 Charity Majors 指出，资深软件工程师“更看重的是你理解、维护、解释和管理大量生产环境中运行的软件的能力，以及将业务需求转化为技术实现的能力。”

工程师发布的每一行代码都是一种隐患。每一行代码都必须经过安全检查、调试、维护，最终还要进行重构。当我们使用人工智能来蛮力推进软件的“构建”阶段时，这种隐患就被无限放大。我们制造了大量的复杂性，这些复杂性或许能解决眼前的 Jira 问题，但却会损害平台的未来稳定性。

Orosz关于996家公司都在生产复制品的观点很有启发性。

创新需要“闲暇时间”，才能在不受会议不断干扰的情况下进行思考。如果能抽出一点时间安静下来，你可能会意识到你原本打算开发的功能其实是不必要的。如果开发者每天都在审查人工智能生成的海量拉取请求，他们就没有闲暇时间。他们不再是架构师，而是成为为一个永远不眠的机器人打扫卫生的清洁工。

这并非说人工智能对软件开发有害。恰恰相反。哈佛大学教授（也是开源领域的长期领军人物）卡里姆·拉卡尼强调说，“人工智能不会取代人类”，但我们将越来越看到“拥有人工智能的人类将取代没有人工智能的人类”。人工智能是一种有效的工具，但前提是我们必须将其作为工具而非工具来复制996文化的虚假承诺。

技术堆栈中的人类部分

那么，我们如何避免在硅芯片上建立起一种996文化呢？我们需要停止将人工智能视为“开发人员的替代品”，而应将其视为一种工具，用来弥补996文化所摧毁的那样重要东西：时间。

如果人工智能能够处理繁琐的工作——单元测试、样板代码、文档更新——这不应该成为在迭代周期内塞入更多功能的借口。相反，这应该是一个放慢脚步、专注于技术栈中“人为因素”的机会，例如：

• 明确问题。 “我们究竟想做什么？”听起来很简单，但这却是大多数软件项目失败的原因。选择正确的问题是一项需要高度理解和同理心的任务。一个精通软件开发的人可以给你五种构建组件的方法；但他无法告诉你，这个组件是否适合客户的工作流程。
• 无情地进行编辑。如果人工智能让编写代码几乎无需成本，那么最有价值的技能就变成了删除代码。人类必须掌握“拒绝”的主动权。我们应该奖励开发者的不是提交代码的速度，而是他们设计的简洁性。我们应该赞扬那些“负面代码”的提交：那些消除复杂性而不是增加复杂性的代码。
• 掌控事故责任范围。一旦系统出现故障（而且故障肯定会发生！），事故报告上署的是你的名字，而不是LLM（生命周期管理）的名字。如果你从未亲自编写过代码，那么深入理解系统并在故障期间进行调试的能力就会退化。我们需要确保“AI辅助”不会变成“脱离人类”。我一直强调，必须确保初级开发人员不会盲目接受LLM提供的任何指令。我们需要确保提供充分的培训，使所有技能水平的工程师都能有效地使用AI。

反对机器人胡言乱语的运动并非出于卢德主义，而是为了追求质量。

奥罗斯对996的批评在于，它制造出疲惫不堪的人和容易被遗忘的产品。如果我们再不谨慎，我们对人工智能的应用也会产生同样的结果：疲惫不堪的人类维护着机器生成的大量容易被遗忘且脆弱的代码。

我们不需要更多的代码，而是需要更好的代码。而更好的代码源于人类的头脑，他们需要安静、不受干扰的环境来创造它。让人工智能来处理繁琐的工作，从而解放人们，让他们专注于创新。

作者：场长

参考：

https://www.infoworld.com/article/4094801/software-development-has-a-996-problem.html

https://hbr.org/2023/08/ai-wont-replace-humans-but-humans-with-ai-will-replace-humans-without-ai

https://www.gitclear.com/coding_on_copilot_data_shows_ais_downward_pressure_on_code_quality