“写代码从来都不是难点”？25年开发者怒写3000字反驳：这句话是对所有程序员的一种侮辱！

编译 | 郑丽媛

出品 | CSDN（ID：CSDNnews）

这几年，身处技术圈的人大多都听过这样几句话：“AI 可能擅长写代码，但软件开发难的又不是写代码”，“编码本身很简单，难的是想清楚到底要写什么”……

在 AI 编程工具日新月异的 2026 年，这些话听起来像是一种安慰——告诉程序员们：别怕，AI 抢不走你最核心的价值，真正的难点在于“理解需求”和“产品思维”。

但有人不买账。

前几天，拥有 25 年从业经验的程序员兼技术创业者 Senko Rašić 在个人博客上发表了一篇火药味十足的文章，标题直截了当：《“写代码从来都不是难点”，这句话是对所有程序员的一种侮辱》。

这篇文章迅速引爆社区。在 Hacker News 上，截至发文，它拿下了 884 分和 539 条评论。在各大技术论坛、LinkedIn 和 X（原 Twitter）上，开发者们更是吵成了一锅粥。

这场争论的核心很简单：“写代码不难”这句话，到底是在安慰程序员，还是在侮辱程序员？

Senko Rašić 的反击：如果编码真那么简单……

以下为 Senko Rašić 的原文翻译：

软件开发行业正经历一场巨变。没人能准确预判 AI 革命最终会走向何方，但有一点很明确：工作和生活的方方面面都将被重塑——编程自然也不例外。

最近我经常听到一类论调，大意是：“LLM 也许擅长写代码，但软件开发难的从来都不是写代码”，或者“编码本身很简单，难的是搞清楚到底要编什么”。

恕我直言，这简直是在侮辱全世界的程序员。

如果编码真那么简单……

如果编码真那么简单，那为什么程序员多年来一直供不应求，薪酬居高不下？为什么在 AI 每天能吐出 5000 行 PR 之前，程序员就已经压力山大、加班成灾、 burnout 频发？为什么公司要苦苦寻觅所谓的“10 倍速程序员”，还要让他们刷 LeetCode 面试题——要是编码真那么容易，随便找个刚毕业的应届生不就能顶上了吗？

如果编码真那么简单，那为什么市面上会有《代码整洁之道》和《程序员修炼之道》这样的“砖头”巨著？《计算机程序设计艺术》是什么夏日消遣的轻读物吗？SICP（《计算机程序的构造和解释》）难道是摆在咖啡桌上的画册吗？为什么会有专门的编程培训班，甚至整个大学专业都围绕它来设置？

如果编码真那么简单，那卡马克（John Carmack）是不是只是赶上了好时代？为什么我们会把法布里斯·贝拉（Fabrice Bellard）奉为天才？

如果编码真那么简单，那为什么人们会因为 AI（或任何人）复制自己的代码而愤愤不平？为什么他们表现得像是把自己的汗水、灵魂和大把时间都倾注在了这件“微不足道”的小事上？

如果编码真那么简单，那为什么现在有那么多人感觉自己的身份认同和职业价值正在被剥夺？

如果编码真那么简单，那为什么软件还会有那么多该死的 Bug？

如果“弄清楚要做什么”才是难点……

如果决定做什么才是难点，那为什么那么多产品经理看起来一脸懵？为什么他们没有经过层层严苛的十轮面试？为什么他们的薪水不如开发者高？

如果决定做什么才是难点，那为什么市场研究员、可用性专家在软件公司里不被视为“明星员工”？如果“理解客户”更难，那为什么业务分析师会被看不起，觉得他们就是个“跑腿填表的”？

如果实现是容易的、找到需求是更难的，那为什么当销售人员为了拿下订单而向客户承诺新功能时，程序员会那么不爽？他们可是发现了真实需求啊，是有人愿意为之付费的需求啊！

如果编码真那么简单，为什么大家不直接做出十种不同的变体，然后看哪个能跑出来呢？

根本不存在“普通程序员”这回事

还有一种陈词滥调是：“软件开发的大部分工作就是跟利益相关者沟通、理解客户需求、厘清优先级”。

我职业生涯中见过很多程序员，但真心想跟利益相关者打交道的少之又少，更别提直接面对客户了（自由职业者和创始人算是例外，尤其是开软件外包公司的）。而且，“厘清优先级”往往最终会变成“直接告诉我该做什么，别隔两天就变一次”。

确实，有些开发者会说：“我不是在写代码，我是在解决客户的问题。”但随后，他们又开始讨论 Monad（单子）、内存安全、DRY（Don't Repeat Yourself，不重复造轮子）原则。与此同时，他们所谓的“客户理解”，可能只是一个虚构出来的“用户画像”。

还有另一类开发者会说：“软件开发是一种理论构建。”他们认为程序本质上就是证明（类似数学证明），每一次提交代码，都应该讲述一个完整故事。而用 FTP 传个 PHP 文件去解决客户问题，在他们眼里简直是十恶不赦。

我并不是说没有那种既热爱编程本身、又能真正共情客户的开发者，不过我觉得，这种人应该少之又少。

那到底什么才是重要的？

我确实认为，与用户交流、理解他们的体验、共情他们的处境、解决客户的难题，以及让所有利益相关者达成共识，对于一个软件项目的成功至关重要。

但同时我也坚信，写出优秀的代码是一门手艺，需要技巧、耐心、对细节的关注、经验以及智慧，并且在未来的日子里，它依然有其不可替代的价值。

为什么不能两者兼得呢？

在我看来，我们应该尽量朝着这个方向努力：既深入理解我们正在构建的系统，也深刻理解我们为什么要构建它。

大声嚷嚷“写代码很简单”，或者走到另一个极端说“代码是艺术，是人类创造性的表达，不可能被自动化”，都不过是在逃避现实——这叫“自我安慰”，我们需要的不是自我安慰，而是在变化中成长。

我不是说让你“赶紧跳上 AI 这趟快车”，也不是说“成为管理一大群 AI Agent 的管理员”，更不是说“AI 生成的代码都是偷来的垃圾，我们要死磕到底，反正泡沫很快会破灭”。

但请务必认识到：我们正身处一场全行业级别的板块运动中。我们需要想清楚如何适应变化，需要分辨出哪些东西可能会变、哪些东西永远不会变。

什么不会变？

软件会变得越来越复杂。软件永远需要维护：代码腐烂是铁律，熵增也是。技术（硬件和软件）会一直向前发展，无论好坏，抽象层的“高楼”也会越垒越高。

用户永远想用更少的钱要更多东西，也还是不知道如何准确传达自己的需求和愿望，甚至不清楚自己到底想要什么。客户（真正掏钱的人）和用户（实际使用的人）之间的脱节依然存在，业务需求和客户需求之间的张力也不会消失。

哦对了，“江湖骗子”也永远不会绝迹，各种“当红技术”来了又走。

什么在变？

程序员这个群体，从诞生之初就在干着“颠覆自身行业”的活儿。现在已经没人用打孔卡了，也很少有人需要写汇编或 COBOL 了。那些年花在 C/C++ 内存 Bug 上的无数个日夜，以及留下的伤疤，在 Rust、Go、Python 和 JavaScript 的时代已经不值一提了。

我年纪够大，还懂得欣赏 valgrind，也还记得 PHP4 时代那个著名的mysql_real_escape_string()函数——这些东西曾经非常重要，但未来的人可能永远不会再接触它们，而这其实并没有过去多久。

我勉强躲过了 dBase、Clipper、HyperCard 和 Access 的时代，但如今我还能在某些小店、咖啡馆里看到这些老技术的影子，比如一台曾经是米白色、如今已经泛黄的老式台式机还在运行着某个几十年前定制开发的业务系统。

怎样在变化中生存并发展？

接受变化必然发生。对新事物既要保持好奇，也要保持批判。

要明白“技术炒作”无处不在，学会分辨哪些是虚火，哪些是真正能用的。同时，要警惕评判标准的不断漂移：不妨退后一步，看看过去一年或五年，评估一下变化的速度（技术层面、经济层面、社会层面）。

你的角色和职责也一定会改变，尽量花时间和精力去了解与你相邻的领域或岗位。

如果你是一名资深开发者，不要只满足于深挖自己的技术专长。去学学用户体验、客户访谈，或者你所在领域的商业策略。这会帮你更全面地理解：一个软件产品从代码到真正交付给用户，中间经历了多少复杂工作。即使未来你永远不会亲自承担其中某些职责，理解它们依然会提升你的判断能力。

如果你刚入行或还是初级岗位：请投入精力去深入理解软件的工作原理。理解指针、递归或内存层次结构，即使你是 JavaScript 开发者也会大有裨益。理解网络协议和 HTTP 工作原理，即使你在写 WordPress 插件也会有用。刷 LeetCode，学习算法和数据结构，即使你现在用不上——永远不要害怕问“为什么”和“到底是怎么实现的”。

这里有些书籍和资源，或许能给你一些灵感：《计算机程序的构造与解释》、《程序员面试金典》、《人月神话》、《逆向工作法》、《团队拓扑学》、《七大力量》、《新机器的灵魂》、《显然很棒》、《设计心理学》、《别让我思考》、《持续发现习惯》、《妈妈测试》。

最后还有一件事：无论你是谁，请不要把你的理解力、判断力、共情力和品味外包给 AI。不要放弃你的责任，不要当变成 AI 的“人肉代理”。保持清醒，保持思考。时代在变，但真正的价值，永远属于那些既能写代码、又能懂人心的人。

开发者社区炸了：“写代码不是难点”到底对不对？

Senko Rašić 的这篇文章发布后，开发者社区的反应几乎和文章本身一样精彩。

有部分网友认为：Rašić 可能误解了这句话的本意，“写代码不是难点”并不是在贬低程序员。

很多开发者真正想表达的是：在企业环境里，写代码只是整个软件生产流程中的一个环节，真正困难的是理解需求、协调团队、建立共识、推动执行。 正如一位开发者所说：

“编程语言都有文档，数据结构都有资料，框架几乎无处不在。写代码本身是一个可以学习和解决的问题。但让一个组织真正做好软件，才是困难的部分。”

对此，也有人补充道：“我觉得确实有些编程岗位里，代码绝对是相对容易的部分。并不是所有人都在搞信号处理、集成系统，或者因为公司数据中心急需优化内存分配就得往 Linux 内核上游推代码。”

所以“写代码不难”是有语境的——它可能适用于某些特定岗位、特定场景，但不能一概而论。

而另一部分开发者则反驳：如果谁认为写代码简单，很可能只是因为没有接触真正复杂的软件工程。

“所有说‘代码从来不是难点’的人，其实恰恰暴露了他们自己。代码之所以‘不难’，是因为大多数组织压根就不愿意承接任何真正硬核的技术工作。这反映的是商业战略和文化，而不是编程或技术工作的本质。”

这位开发者认为，编程就是一项高杠杆活动——即使技术含量低、质量一般的代码，在经济上也有巨大价值，“这一点不会变”。与此同时。“仍有大量编程工作本质上是困难的，AI 即使有用，但目前也远不足以取代从事新颖、非平凡技术工作所需的专业能力。”

这场争论，或许并没有绝对答案，因为双方其实讨论的是两个不同的问题：

● 一个问题是：“软件开发过程中，最困难的事情是什么？”

● 另一个问题是：“写代码这项能力本身，是否还重要？”

诚然，AI 确实正在降低编写代码的门槛。未来，一个普通人可能借助 AI 完成过去需要程序员完成的工作，但这并不意味着软件工程变简单了。因为代码数量增加，并不代表软件质量提升；生成一个功能很容易，但维护一个运行十年的复杂系统，还是很困难。

那么，你认为“写代码从来都不是难点”这句话，又到底是对是错呢？

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

最后，说一件事

2026 奇点智能大会 ，终于要和大家见面了。

11 月 20-21 日·北京，奇点智能研究院联合 CSDN，把两场技术大会放在了同一个时空里：

• 奇点智能技术大会（始于 2016）——聊大模型、AI Native、企业级 AI 落地、多模态与世界模型；

• C++ 及系统软件技术大会（始于 2005）——聊现代 C++ 演进、AI 算力与推理优化、高性能低时延系统。

为什么要放在一起？因为我们越来越相信——上层 AI 应用的爆发，离不开底层系统软件的支撑；而底层技术的演进方向，也正在被 AI 重新定义。

这次大会汇聚 70+ 位技术专家、18 个主题、1000+ 同行到场。

如果你也在这些方向上做研究、做产品、做工程，别错过。

if like:

click("分享", "点赞", "在看")