「代码从来就不是难的那部分」这句话，为什么那么招人上火

• 会议上一冒出这句话，房间的温度就变了
• 原文抛出的那些问题
• 真正招人上火的原因是偷换概念
• 但这并不等于对面全对
• 把代码切成三层，争论就结束了
• 量一量我们团队把时间花在哪一层
• 每一层里，工具的价值都不一样
• 那么该练什么
• 参考资料

会议上一冒出这句话，房间的温度就变了

季度规划会上有人这么说：「现在写代码已经不是难的那部分了，所以我们可以更多地聚焦在做什么上。」

说话的人多半是好意。可工程师那一侧的表情僵住了。想反驳，却一时想不出合适的句子。说「代码也很难」听着像在自我辩护；就这么放过去，那条前提就会原封不动地进入下个季度的人力规划。

原文抛出的那些问题

在 2026 年 8 月 8 日发布、在 Hacker News 上引发大量讨论的那篇文章里，Senko Rašić 正面接住了这句话。他的方式不是论证，而是抛问题。

如果写代码很容易，为什么程序员的需求那么旺、薪资那么高？如果写代码很容易，为什么会存在 Clean Code、The Pragmatic Programmer 这样厚厚的书？如果写代码很容易，为什么人们会因为自己的代码被复制而生气？再把方向反过来：如果「决定做什么」才是难的那部分，为什么那么多产品负责人看上去像是找不着北？

结论是拒绝二选一。它必须两者都是；文章最后以一句话收尾：不要把理解、判断、共情和眼光外包给 AI。

真正招人上火的原因是偷换概念

我认同这份反驳，但那句话为何格外招人上火，可以有一个略微不同的解释。问题不在于它是真是假，而在于这个词在半路上换了意思。

在「代码不是难的那部分」这句话里，代码一开始是以狭义登场的：懂语法、查 API、把它敲出来。在这个意义上，这句话是对的。然后随着对话推进，同一个词悄悄变宽了。等走到结论时，代码指的已经是整个工程，于是「工程不是难的那部分」这个命题在没有任何人证明过的情况下通过了。

听的人上火，正是因为这次「通过」。要反驳，就得先把这个词拨回原位，而在会议中途做这件事需要说很长一段话，等你说着说着，讨论已经进到下一个议题了。

这套结构在别的职能上一模一样地运转。「设计现在很容易了」这句话里，设计起初指的是出方案，然后把问题定义也吞了进去；「写东西现在很容易了」里，写作起初指的是打磨句子，然后把论证的搭建也吞了进去。每次都在同一个地方以同样的方式跑偏，可跑偏点其实落在一个词上，这件事却很少被指出来。

但这并不等于对面全对

这里得把平衡拿住。原来那句话里确实有为真的部分。

决定做什么这件事，确实难。每个相关方想要的东西都不一样，他们嘴上说的和实际需要的不一样，需求还会在开发过程中改变。在这个领域上的失败，代码写得再好也补不回来。做得很好却没人需要的功能，只是做得很好的浪费。

所以，如果把这场争论拽成「代码难 vs 需求难」，它不会停在双方各对一半的位置上，而会在谁都不承认对方那一半的状态下反复上演。出路是把这个词拆开。

把代码切成三层，争论就结束了

我们笼统称作「写代码」的活动，至少可以分成三层。

把这个区分放进来之后，两种主张各自在哪里成立就一目了然了。「代码不是难的那部分」对第 1 层强烈成立，对第 2 层部分成立，对第 3 层则毫无依据。而原来那句话之所以招人上火，正是因为它把第 1 层的成立一路拽到了第 3 层。

量一量我们团队把时间花在哪一层

这个区分之所以有用，是因为它可以被度量。要让争论不靠感觉，就得知道自家团队的分布。

两周实验：给每个完成的任务只贴一个标签

L1  大部分时间花在语法、API、模式化的转换上
L2  大部分时间花在决定结构、边界与约束上
L3  大部分时间花在权衡不变量、失败形态与迁移上
RQ  大部分时间花在弄清楚该做什么上

两周后看这四个数字。用这份分布来谈，而不是继续争论。

真做起来，各团队的结果通常差别很大。做新服务的团队 L1 和 RQ 偏高，维护十年老系统的团队则是 L3 压倒性地高。正因为分布不同，两个团队听到同一句话的反应会完全不同：对其中一边那句话是事实，对另一边则像是自己的工作被整块抹掉了。

一个任务只贴一个标签这一点很关键。允许多选的话，所有任务都会被贴上三个，分布就消失了。让人只挑「时间花得最多的那一层」，还有个附带效果：任务越模糊，挑的过程越会逼着人自己把「我到底做了什么」理一遍。两周不够就延到四周，但必须先承诺结果不会被用于个人绩效评估，数字才会诚实。

每一层里，工具的价值都不一样

知道了分布，接下来的决定就好做了，因为 AI 工具的价值在每一层也不一样。

在第 1 层，价值很大。这一点争议不多，实际上大部分生产力提升的体感也来自这里。在第 2 层，价值是有条件的：能把约束明确说出来，就能拿到好几个不错的方案；说不清约束，回来的就是一份四平八稳的默认答案。在第 3 层，价值最小 —— 因为不变量和失败形态里相当大的一部分哪儿都没写，只存在于人的脑子里。

所以，在第 3 层很厚的组织里，如果按「代码现在很容易了」这条前提去做人力规划，受伤最重的恰恰就是这个组织。反过来，第 1 层很厚的组织迟迟不引入工具，也是在吃亏。同一句话，在不同组织里必须导向不同的处方。

那么该练什么

原文的结论是：不要把理解、判断、共情和眼光外包出去。加上分层之后，这条建议会变成更具体的行动。

第 3 层能挪进文档的部分，比想象中多。把不变量做成可执行的检查而不是代码注释，把已知的失败形态写进 runbook，在决定迁移路径时把被舍弃的备选方案记下来。这不是为了工具，而是为了人。只存在于脑子里的知识，会随着那个人离开团队而消失，而在那一刻，组织的第 3 层就真的空了。

第 2 层的练法有点不同。这一层的功力几乎等同于「把约束说成话」的能力，所以在动手实现之前先把必须守住的条件列成清单，这个习惯本身就是训练。如果写不出条件，说明你还没理解这个问题；在那种状态下产出的东西，不管是谁做的都没法评审。

再回到会议上：下次那句话又冒出来时，你只要反问一句就行 —— 您说的是哪一层？这一个问题就能把对话从情绪问题变成规划问题，房间里也没有人需要为自己的工作辩护了。

参考资料

• "Code was never the hard part" is an insult to all programmers — Senko Rašić, 2026-08-08 —— 正文中引用的那些问题与结论，都是这篇文章的内容。
• Hacker News 讨论 —— 反对意见相当多，那些反驳也值得一并读。
• 本博客的相关文章：摩擦消失后留下的不是眼光，而是养出眼光的那条路消失了
• 三层划分与两周实验并非出自原文，而是我自己整理出来的框架。