讨厌 AI 编程的五个理由，哪些站得住

一篇标题叫《讨厌 AI 编程的理由》的文章，读到最后你会发现，作者并不讨厌 AI 编程。

他讨厌的是那些经不起追问的理由。

一、发生了什么

10 月 6 日，开发者 Graham 在自己那档老牌编程博客上写了这篇文章。他的写法很特别：先把每种反对意见按最强的版本陈述一遍，再指出它站不住的地方。

他列了五条。

第一条，代码是艺术。如果软件是创作，机器生成的东西就没有那种说不清的灵光，因此不算真作品。他的回应是：买软件的人通常不是在买艺术品，是在买结果；同一个结果，谁做出来的差别不大。但他也承认，这条既无法反驳也无法证明，除非你先接受「只有人能创作」这个前提。

第二条，AI 偷走了工作。如果你认为自己拿工资是因为会敲代码，那机器会敲了，工作就被偷了。他的回应是：这份工作从来不是敲代码，是交付有用的软件。能交付的人仍然能被雇用；而且应用变便宜之后，需求反而会增加。

第三条，人变成了机器的转接头。把软件生成的任务描述，再翻译成提示词喂给软件，是一种降格。他的回应引了马克思 1857 到 1858 年的《机器论片段》：知识和技术被吸收进资本，劳动者被当成机器的连接件。这不是新技术带来的，是生产方式的长期趋势。

第四条，软件工程是一套规则。如果这行靠的是 SOLID、组合优于继承、迪米特法则这些经验规则，那 AI 不可能写软件，因为它只是生成能编译的文本。他的回应很实在：编程史本来就是试错史。从 Stack Overflow 复制一段改到能跑，从《Numerical Recipes》抄一段改到能跑，和今天让模型生成再改，差别没有想象中大。

第五条，AI 公司是坏角色。如果这些公司不在乎人类利益，用它们的工具就是在支持它们。他的回应是：这个论证忽略了一种可能——换公司、用学术或社区模型。

二、跟你有什么关系

如果你是开发者：这五条里，只有第二条和你的收入直接相关，而它恰好是最容易被验证的。看你所在团队的任务量、交付周期和招聘计划，比看观点有用。

如果你是管理者：第三条值得认真对待。同样是用 AI，有人保住了判断权，有人只剩下复制粘贴。差别不在工具，在流程设计。

如果你在学习编程：第四条最危险。如果学校只教规则，不教怎么读别人的代码、怎么验证生成的结果，你会成为那个「转接头」。

三、把情绪拆成五个可验证的问题

1. 「这不是艺术」→ 问客户买的是什么。如果合同写的是交付时间和功能，这条不成立；如果客户买的是作者身份和风格，它成立。先看合同，再看价值观。

1. 「抢了工作」→ 问岗位的交付物是什么。把岗位描述拆成「输入、处理、输出」，看 AI 替代的是哪一段。多数岗位被替代的是中间一段，不是整份工作。

1. 「人被降级」→ 问决策权在谁手里。谁定需求、谁验收、谁有权说「这个不对，重做」。这三项还在你手里，你就不是转接头。

1. 「不符合工程规范」→ 问规范能不能被测试。能被 lint、类型检查、单元测试抓住的问题，AI 也会被抓住；抓不住的，才是人的价值所在。

1. 「在支持坏公司」→ 问有没有替代供给。本地模型、开源权重、其他供应商，是否真的可用。如果可用而不用，那是选择；如果不可用，那是约束。

四、三个别信的说法

「讨厌 AI 编程的人都不懂技术。」 这篇文章的作者显然懂。他能准确复述每种反对意见的最强版本，也能指出它们各自的前提。真正的反对往往来自对工程细节的理解，不是无知。

「作者在替 AI 公司说话。」 他拆的是论证，不是立场。拆掉一个坏论证，不等于支持相反结论。事实上，他保留了第五条的部分合理性：如果你认定这些公司是坏角色，那么换供应商确实是一个选项，只是不能假装没有选项。

「工具再好一点，反对声就会消失。」 反对里有相当一部分不是关于能力，是关于分配：谁获益、谁承担风险、谁失去议价权。工具变强不会自动解决这些问题，有时会加剧。

五、一句话结论

反对 AI 编程的理由，有些是关于品味的，有些是关于饭碗的；只有后者能用数据回答。

信息来源

• Graham，《Reasons to dislike AI coding》，2026 年 10 月 6 日：原文

功能与价格以官方公告为准。本文写于 2026 年 10 月 18 日。