大家好，我是江湖十年。

AI 编程流行之后，有一种说法越来越常见：大语言模型也许擅长写代码，但软件从来都不是难点，难的是想清楚要做什么。这篇文章的作者 Senko Rašić 对此提出了尖锐的反驳。原文在 Hacker News 上引发了大量讨论，本文是对这篇文章的中文翻译。

如下为译文：

原文地址：https://blog.senko.net/code-was-never-the-hard-part-is-an-insult-to-all-programmers

Senko Rašić

2026 年 8 月 8 日

软件开发行业正处于剧变之中。没有人知道 AI 革命最终会如何发展，但可以确定的是，工作和生活的许多方面都将被改变——包括编程。

我最近经常听到一种说法，大意是：“大语言模型也许擅长写代码，但软件从来都不是难点”，以及“写代码很简单，难的是想清楚要写什么”。

我认为，这是对全世界所有程序员的莫大侮辱。

如果写代码很简单……

如果写代码很简单，为什么程序员多年来一直供不应求，还能拿到高薪（甚至在零利率政策时代之前就是如此）？为什么在 AI 开始批量生成 5000 行 PR 之前，这个行业就已经充满了压力、加班和倦怠？为什么公司要寻找能以一当十的“摇滚明星”式程序员，还要让他们经受 LeetCode 面试的折磨——如果写代码真的那么简单，一个刚毕业的初级工程师不就能随便写出点什么吗？

如果写代码很简单，为什么会有《代码整洁之道》（Clean Code）和《程序员修炼之道》（The Pragmatic Programmer）这种砖头一样厚的大部头？《计算机程序设计艺术》（The Art of Computer Programming）是轻松的夏日读物吗？SICP 是咖啡桌上的摆设吗？为什么会有编程训练营，甚至还有专门的大学学位？

如果写代码很简单，约翰·卡马克（John Carmack）只是恰好在正确的时间出现在了正确的地点吗？为什么我们会把法布里斯·贝拉（Fabrice Bellard）视为天才？

如果写代码很简单，为什么人们会因为 AI（或任何人）复制他们的代码而愤怒？为什么他们会表现得像是把汗水、灵魂和大量时间都倾注在了一件如此微不足道的事情上？

如果写代码很简单，为什么现在有很多人觉得自己作为开发者的身份认同和职业意义正在被剥夺？

如果写代码很简单，为什么软件还是这么多该死的 bug？

如果难的是想清楚要做什么……

如果决定做什么才是难点，为什么那么多产品经理看起来毫无头绪？为什么没有针对他们的严格十轮面试？为什么他们的薪水不比开发者高？

如果决定做什么才是难点，为什么市场研究员、可用性专家，以及——见鬼，客户成功团队——没有被当成软件公司里的明星？如果“理解客户”更难，为什么业务分析师会被轻视，被当成只会抄抄写写的文员？

如果实现很简单，找到需求更难，那么当销售人员为了拿下订单而向客户承诺一个新功能时，程序员为什么会不满？他们可是找到了真正的需求，找到了人们愿意为之付费的东西！

如果写代码很简单，为什么不是每个人都直接做出十个变体，然后看看哪一个能成？

不存在“中位数程序员”

还有一种老生常谈的说法：“软件开发的大部分工作，是跟利益相关者沟通、理解客户需求，并把优先级理清楚。”

在我的职业生涯中，我遇到过很多程序员，但很少有人愿意跟利益相关者沟通，更别提直接面对客户了（自由职业者和创始人除外，尤其是软件开发公司的创始人）。而所谓“把优先级理清楚”，归根结底就是“直接告诉我该做什么，别每两天就变一次”。

有些开发者确实会说：“我不写代码，我解决客户的问题。”但转过头来，他们又开始对单子（monad）、内存安全和 DRY 原则高谈阔论，而他们对客户的理解只是一个虚构的“用户画像”，并且以为“affordance”（让人一看就知道怎么用）是父母以前周末给你出去玩的钱——他们把它听成了 allowance（零花钱）。

译注：affordance 指物品通过外观提示使用方法，比如门把手暗示“拉”，按钮暗示“按”。

还有一些人则说：“软件开发是理论构建。”程序实际上是证明（数学意义上的证明）。每一次提交都应该讲述一个故事。而通过 FTP 上传一个 PHP 文件来解决客户问题，则是大忌。

我并不是说，不存在既能深切关心软件开发这门手艺、又能真正共情客户的开发者。不过，我确实觉得他们或许该去找专业人士看看自己是不是有人格分裂。（后记补充：这句话说得太过火了；我本意是半开玩笑地表达“很少有人能同时做到这两点”，而且我在下一节里其实正是提倡这种做法。我认错）

那什么才重要？

我确实相信，与用户交流、理解他们的体验、共情他们、解决客户的问题，并让所有利益相关者达成共识，对软件项目的成功至关重要。

我也相信，写出好代码是一门手艺，需要技能、耐心、对细节的关注、经验和智慧，而且在未来，它仍然会很重要。

为什么不能两者都要？

只要能做到，我认为我们应该两者兼顾：既深入理解我们正在构建的系统，也深入理解我们为什么要构建它。

大声宣称“代码很简单”，或者走到另一个极端，宣称“代码是艺术，是人类创造性的表达，无法被自动化”，都只是在把头埋进沙子里。

这是一种自我安慰。而你想要的不是自我安慰，而是真正成长起来。

我这么说，并不是让你“赶紧搭上大语言模型的顺风车”。也不是让你“去当一支 AI 智能体舰队的经理”。更不是让你“把 AI 生成的代码当成偷来的垃圾泔水，拼死抵抗，反正泡沫迟早会破”。

但请认清，我们正处在一场全行业板块移动般的剧变之中。我们需要弄清楚如何适应。我们需要理解，什么很可能会改变，什么永远不会改变。

什么不会改变？

软件只会越来越复杂。软件永远需要维护：软件腐化（bit rot）是生活的一部分。熵增也是如此。技术（硬件和软件）会继续向前发展，无论好坏。抽象之塔（或者说摩天大楼？）会越建越高。

用户永远想要更多，而且准备花得更少。他们仍然不知道如何表达自己的需求和愿望。更糟的是，他们仍然不清楚自己到底想要什么。客户（真正为软件付费的人）与用户（实际使用软件的人）之间的脱节仍将存在，企业需求与客户需求之间的矛盾也同样存在。

另外：卖狗皮膏药的江湖骗子永远不会缺。当下的技术潮流来了又去（我还在等新一轮 VR 复兴呢！）

什么会改变？

从一开始，程序员就在干着颠覆自己行业的事。现在没人再用打孔卡了。很少有人还需要用汇编或 COBOL 写代码。那些在 C 或 C++ 里与内存 bug 搏斗的几十年，以及作为证明留下的伤疤，在 Rust、Go、Python 和 JavaScript 的时代已经毫无价值。

我年纪够大，所以会欣赏 valgrind，也记得 PHP4 时代的 mysql_real_escape_string()——这些东西我这辈子再也不会用到了。而这甚至不算多久以前！我刚好与 dBase、Clipper、HyperCard 和 Access 的时代擦肩而过；如今我还能在商店、咖啡馆，或者在某台落满灰尘、曾经是米色如今变成金棕色的旧台式机上，看到这些技术仍在愉快地运行着某些定制的业务解决方案（备份？什么备份？）

我们该如何成长？

接受变化会发生。对新事物保持同等分量的好奇与批判。

要明白其中有很多炒作，并试着分辨哪些是夸夸其谈，哪些是真正有效的（以及有效到什么程度）。同时也要留意不断移动的球门：退后一步，看看过去一年或五年，评估变革的速度（技术、经济、社会层面）。

你的角色和职责一定会发生变化。要愿意投入时间和精力，去更好地理解与你相邻的领域或角色。

如果你是一名资深开发者，不要只在加深专业能力中寻找慰藉。去了解用户体验、客户访谈，或者你所在领域公司的商业策略。无论你以后是否真的要做这些事，这都会帮助你更好地理解，为了让一款软件到达用户手中，究竟付出了哪些工作。

如果你刚刚入行，或者在团队中还是初级角色：请投入精力，加深对软件如何运作的理解。即使你是 JavaScript 开发者，理解指针、递归或内存层级也会对你有帮助。即使你只是在写 WordPress 插件，理解网络协议和 HTTP 的工作原理也会有用。即使你并不需要，也去做做 LeetCode，学学算法和数据结构。不要害怕追问为什么，以及到底怎么做。

作为灵感来源，下面这些书和其他资源可能会有所帮助：

还有一件事

无论你是谁，都不要把你的理解、判断、共情和品味外包给 AI。不要放弃你的责任。不要成为一个肉身代理（meat proxy）。

附：Hacker News 和 Lobsters 上有很多有趣而深刻的评论——这篇文章确实戳中了很多人的神经。人们对这段经历的理解如此不同，对写代码（coding）、编程（programming）、开发（development）和工程（engineering）的定义也各不相同，这很有意思。

原文完。

希望此文能对你有所启发。

延伸阅读

联系我