---
title: "“写代码从不是难点”，是对程序员最大的误解 | 行开心的颠倒世界"
description: "“写代码从不是难点”是当下最大的误解。AI 抹平了敲键盘和背 API 的门槛，但代码的核心是对并发锁顺序、连接池极限与异常状态机的精密控制。当打字变廉价，能看懂链路和死锁排错的人，才是系统真正的兜底者。"
canonical: "https://xingkaixin.me/posts/code-was-never-the-easy-part/"
language: "zh-CN"
---

# “写代码从不是难点”，是对程序员最大的误解

“写代码从不是难点”是当下最大的误解。AI 抹平了敲键盘和背 API 的门槛，但代码的核心是对并发锁顺序、连接池极限与异常状态机的精密控制。当打字变廉价，能看懂链路和死锁排错的人，才是系统真正的兜底者。

2026年9月21日·1,402 字·4 分钟

[AI编程](https://xingkaixin.me/tags/AI%E7%BC%96%E7%A8%8B/)[软件工程](https://xingkaixin.me/tags/%E8%BD%AF%E4%BB%B6%E5%B7%A5%E7%A8%8B/)故障排查

![“写代码从不是难点”，是对程序员最大的误解](https://xingkaixin.me/cover/code-was-never-the-easy-part.webp)

上个月帮一个朋友看他们线上服务偶发卡死的问题。

出问题的接口逻辑极其简单：用户支付成功后，核销一张优惠券，更新订单状态，然后发一条通知。这段代码是他们用 Agent 一键生成的，PR 里附带了八个单测，本地用 SQLite 跑得飞快，覆盖率 100%。

但在预发环境一压测，并发稍微上到三四百，整个服务就陷入死锁，数据库连接池瞬间被抽干。

排查进去才发现，Agent 生成的代码里，先查了用户券表加了排他锁，再去查订单状态；而另一个异步对账任务里的锁顺序刚好相反。不仅如此，网络超时重试被随手配了三次立即重试，一旦下游网关稍微抖一下，重试流量直接把底层的连接池彻底打死。

![优惠券表和订单表反向拿锁，重试继续挤占连接池](https://xingkaixin.me/posts/images/code-was-never-the-easy-part/code-was-never-the-easy-part-01.webp)

这几个月技术圈到处充斥着一种论调：“写代码从来不是难点，想清楚需求才难。”

仿佛敲键盘和写逻辑已经变成了随手可得的廉价体力活，未来的程序员只需要懂产品、懂业务，张嘴说两句需求，剩下的丢给 AI 就大功告成了。

这种话听起来很轻巧，但只要在线上经历过几次真实故障，就会发现这完全是不切实际的幻觉。

## 需求是愿望，代码是对物理世界的严密计算

很多人以为“想清楚需求”是最高阶的能力，因为他们把需求理解成了一句大白话： “做一个用户支付超时自动退款、支持高并发秒杀的商城系统。”

说出这句话确实只要两秒钟，但在工程实现上，这句话里面每一个词都在向底层的物理硬件索要代价：

-   下游支付网关返回 504 超时的时候，这笔钱到底扣没扣？本地状态机停在哪个中间态？
-   消息队列重放一条半小时前的扣款事件，你的幂等键是挂在 Redis 还是靠数据库唯一索引拦截？
-   在只有 20 个连接的 PgBouncer 连接池后面，一个长事务卡住 500 毫秒，会不会把整个服务的健康检查探针直接拖超时导致容器被 Kubelet 连环重启？

这些藏在状态机、并发竞争、异常回滚和连接池配置里的具体细节，才是一个软件系统真正活着的部分。

把自然语言意图翻译成一段看似工整的语法，AI 确实几秒钟就能搞定。

但 AI 根本不知道你在生产环境用的是什么版本的 PostgreSQL，不知道你的网络在跨可用区调用时会有 15ms 的抖动，更不知道你配置的垃圾回收器在短对象激增时会触发几百毫秒的 Stop-the-World。

把这些极其苛刻的物理约束，严丝合缝地固化进每一行代码和异常处理里，这从来就不是廉价的体力劳动，而是整个研发链路里最硬的一道坎。

## 以为省了事，其实全转成了排错的脏活

打字和搬运样板代码的门槛确实归零了。

以前写一个带重试的 HTTP 客户端，你得查文档、配退避算法、处理连接复用，手写半小时；现在 Agent 敲个回车就能吐出来。

但这并没有让写出好代码这件事变容易，反而把问题变得更隐蔽了。

以前手写代码，每一行从你脑子里流过去，你会下意识考虑这个指针会不会为空、这个 Map 在多线程下有没有加锁保护。

现在 Agent 一次性倾倒出两百行语法毫无破绽的代码，单测全绿，你扫了一眼觉得挺工整就合进了主干。直到某个周末凌晨两点，监控大盘突然报警，你在十几个微服务的调用链路里翻找日志，才发现某个隐藏在第三方 SDK 内部的 channel 没有关闭，正在一点一点把内存吃光。

![两百行生成代码快速过测，未关闭的 channel 一直漏到凌晨两点](https://xingkaixin.me/posts/images/code-was-never-the-easy-part/code-was-never-the-easy-part-02.webp)

这时候，那个把需求挂在嘴边、宣称“只要想清楚逻辑就行”的人往往束手无策。

能把系统救回来的，依然是那个知道 Linux 进程状态、能看懂 CPU Flame Graph、能在 GDB 或堆栈 Dump 里面定位到死锁内存地址的工程师。

## 谁在真正兜底

如果写代码真的不难，过去几十年计算机行业就不会为并发模型、内存安全、事务隔离级别写出几千篇论文；如果写代码只是简单的意图翻译，全世界的生产系统就不会有每天都在复盘的事故报告。

AI 抹平的，只是按键打字和背诵 API 的机械成本。

它把写代码这门手艺里的杂质洗掉了，但留下的那部分——对系统边界的洞察、对异常路径的防守、对真实物理资源的敬畏——反而变得前所未有的昂贵。

别被那些轻飘飘的断言带偏了。

**能把宏大愿景说得动听的人到处都是；但当系统遭遇真实流量拷打时，能守住底线、让每一行代码在物理世界里站得住脚的，永远是那个真正清楚指令如何跑在机器里的人。**

## 版权声明

作者

XingKaiXin

标题

“写代码从不是难点”，是对程序员最大的误解

发布时间

2026年9月21日

文章链接

[https://xingkaixin.me/posts/code-was-never-the-easy-part/](https://xingkaixin.me/posts/code-was-never-the-easy-part/)

本作品采用[CC BY-NC-ND 4.0 DEED](https://creativecommons.org/licenses/by-nc-nd/4.0/deed.zh-hans)许可。

导览

展开导览