近日，InfoWorld 资深撰稿人 Matt Asay 发表了一篇题为“Software development has a ‘996’ problem”的深度文章，揭示了在 AI 技术迅猛发展的背景下，软件开发行业正在陷入一种新型的效率迷思：将产出等同于成果。这种思维模式认为，只要投入更多时间或写出更多代码，就一定能带来更好的产品 —— 这与“996”工作制的核心逻辑如出一辙。
《The Pragmatic Engineer》创始人 Gergely Orosz 对此现象提出了强烈质疑。他直言不讳地批评“996”文化：“我几乎想不出任何一家坚持‘996’还能真正做出创新产品的公司。它们的产品大多是对已有优秀方案的模仿或翻版，缺乏真正的原创性。”
尽管一些企业试图用“极致拼搏”、“全情投入”或“奋斗者精神”来美化这种高压模式，但其本质并未改变：通过延长工时压榨人力，并幻想由此催生卓越成果。如今，随着大语言模型（LLM）的兴起，有人开始设想：如果能让 AI 每周“工作”上千小时，以惊人的速度生成海量代码，是否就能自动创造出高质量的软件？
Matt 明确指出，这种非人性化的节奏和思维方式只会适得其反。蛮力极少能带来差异化，更遑论真正的创新。“我们不会因此获得突破性的系统，反而只会不断复制已有的东西——衍生代码、冗余逻辑、膨胀的代码库，以及越来越难以维护的技术债务。”
正如互联网正被大量低质、高产的内容所充斥，软件行业也正面临相似危机。研究数据显示，“code churn”（即两周内被修改或废弃的代码行数）持续攀升。越来越多的代码是复制粘贴而来，而经过深思熟虑的重构却越来越少。
换句话说，AI 确实提升了编码速度——某些场景下效率提升高达 55%——但它并没有提升代码质量。我们写出了更多的代码，却对它们的理解越来越浅，修复频率也越来越高。AI 的真正风险并非在于它能写代码，而在于它诱使我们写出过多不必要的代码。庞大的代码库更难保障安全，更难推理行为，也更难由人类掌控。精简，始终优于繁复。
Matt 将这种现象称为“996 陷阱”在人工智能时代的变种。“996 思维”假设创新的瓶颈是时间投入不足；而“AI-native 思维”则误以为瓶颈在于输入字符太少。两者皆错。真正的瓶颈，始终是思维的清晰度——过去如此，未来亦然。
Honeycomb 创始人兼 CTO Charity Majors 曾强调，资深工程师的价值体现在“理解、维护、解释复杂生产系统的能力，以及将业务需求精准转化为技术实现的能力。”
每一行你发布的代码都是一份潜在的技术负债。它需要审查、测试、调试、维护，最终可能还要重构。当我们借助 AI 在“构建”阶段进行蛮力输出时，这份负债被急剧放大。我们制造了大量短期可用的解决方案，却牺牲了系统的长期稳定性。
真正的创新需要“留白时间”——一段不受干扰、可以沉静思考的间隙。也许就在这样的时刻，你会意识到某个功能本就不该存在。但如果开发者每天疲于应付 AI 自动生成的无数拉取请求，这种宝贵的思考空间便荡然无存。他们不再是架构师，而是沦为一台永不停歇的机器的清洁工。
当然，Matt 并非否定 AI 在开发中的价值。相反，他引用哈佛大学教授、开源领域权威 Karim Lakhani 的观点：“AI 不会取代人类，但使用 AI 的人将会取代不用 AI 的人。” AI 是强大的工具，关键在于如何使用——是用来解放创造力，还是继续延续“996”式的虚假承诺。
为了避免重蹈覆辙，Matt 建议停止把 AI 当作“程序员替代品”，而应将其视为一种手段，去弥补“996”文化所剥夺的东西：时间。
当 AI 承担起重复性任务时，这不应成为塞进更多功能的理由。相反，这正是放慢脚步、聚焦那些真正依赖“人”的环节的契机：
Orosz 批评“996”导致的是筋疲力尽的团队与平庸的产品。如果我们不对 AI 的应用保持警惕，同样的结局将再次上演：疲惫的开发者，维护着由机器批量生成、易碎且无人真正理解的代码。
我们不需要更多的代码，我们需要更好的代码。而优质代码只能来自清醒的人类大脑——它需要安静、专注、不受打扰的空间才能生长。让 AI 处理琐碎劳动，把人类从重复中解放出来，回归创造的本质。
源码地址：点击下载
以上就是开发者正掉入新 996 陷阱？AI 写得更快，代码却更差的详细内容，更多请关注php中文网其它相关文章！
每个人都需要一台速度更快、更稳定的 PC。随着时间的推移，垃圾文件、旧注册表数据和不必要的后台进程会占用资源并降低性能。幸运的是，许多工具可以让 Windows 保持平稳运行。
广告Copyright 2014-2025 https://www.php.cn/ All Rights Reserved | php.cn | 湘ICP备2023035733号
514
收藏
