AI替代了代码，但替代不了你的判断——编程学习真正的价值

去年我做OpenShift项目的时候提过一个PR（openshift/release#71089），加了一段证书轮转后的验证逻辑。

PR 的代码本身非常"简单"：几条 oc get secret 命令取出证书信息，openssl x509 解析一下，循环等待新证书出现在 kube-root-ca.crt ConfigMap 中，确认后退出。总共不到一百行 shell 脚本。让 Claude 写，大概三十秒的事。

但这个 PR 真正值钱的部分，恰恰不是这些代码。

值钱的是：我知道在什么情况下、为什么会出这个问题。

OpenShift集群在做证书轮转时，service-network-serving-signer这个签发者证书被更新后，它的新证书需要被同步到 openshift-kube-apiserver 命名空间下的 kube-root-ca.crt ConfigMap 中。在某些条件下——取决于集群负载、Operator 的同步周期、甚至轮转的时间窗口——这个同步不会自动发生。结果就是新证书签发后，kube-apiserver 不认识它，集群出现 x509 证书错误，进入降级状态。

这个认知不是从文档里读来的，也不是AI能推理出来的。它来自：亲手在集群上跑过几十次证书轮转、看过 Operator 的同步逻辑、跟 SRE 一起排查过线上故障。

而这些经历沉淀成的心智模型——一个关于"证书轮转后什么会出问题"的内部思维地图——才是这个 PR 真正的产出。代码只是它的副产品。

这个经历让我重新想了一个问题：AI都能写代码了，学编程还有什么价值？

这篇文章，就是我的答案。

AI 能替代的，和替代不了的✅ AI 能替代：输出代码• 写 oc get secret 取证书• 用 openssl 解析 x509 内容• 写循环等待逻辑• 生成测试脚本和 CI 配置• 格式化代码 / 写注释❌ AI 替代不了：心智模型• 知道 cert 轮转后什么会出问题• 理解 kube-root-ca 同步的延迟• 定位 x509 错误的根因而非表面• 知道什么时候该加这个验证• 做出"轮转后是否稳定"的判断

一、编程的本质是建立心智模型

很多人学编程的误区在于：把"能写出代码"等同于"学会了编程"。

写出代码只是输出。编程学习的真正产物，是你在脑子里建立的一个内部模型——它描述了你眼前的系统是如何运作的。

拿那个 PR 来说。让我写那段 shell 脚本，AI 三十秒搞定。但让我决定"在证书轮转流程的哪个位置加这段验证"——这需要脑子里有一个完整的 OpenShift 证书体系地图：签发者证书（signer）和叶子证书（leaf）的区别是什么、kube-root-ca.crt 由谁负责同步、同步延迟有多长、什么条件下会失败。这些知识不在代码里，它们在我的脑子里。

这就是心智模型。

同样，一个有十年运维经验的人看到集群出现 x509 错误，不会只复制日志去问 AI。他会先想："是证书过期了，还是轮转没同步？是签发者证书的问题还是叶子证书的问题？是不是某台节点的时间不同步了？"——脑子里已经有一个证书体系的故障树在跑了。

而一个新手遇到同样的 x509 报错，可能连"签发者证书和叶子证书是两回事"都不知道。

编程和技术工作的价值，从来都不在生产代码本身，而在生产代码的人脑子里那个系统地图。

二、必要难度：Bug 是最好的老师

另一个 OpenShift 的 PR（openshift/origin#30307）更能说明什么叫"只有踩过坑才能理解"。

这个 PR 修复的是 kube-apiserver 内部负载均衡（Internal LB）的 disruption monitor test——字面上是在 ARO（Azure Red Hat OpenShift）和 Baremetal Hypershift 集群上的一个测试兼容性问题。

代码改动本身很直白：加了三个布尔字段判断集群类型

（
isHypershift
、
isAROHCPCluster
、
isBareMetalHypershift
）

修改了部署函数让它正确处理不同环境的 Internal LB 配置。让 AI 来写，几分钟的事。

但决定"为什么要加这些字段、在什么条件下触发、怎么验证"——这些问题的答案不在任何代码库里。

这个 Bug 是在特定真实环境测试中才暴露的：标准 OpenShift 集群的 Internal LB Monitor 正常，但到了 ARO 和 Baremetal Hypershift 的环境下就失败了。不是代码写错了，是这些环境的负载均衡架构跟标准集群不一样。而且你无法从文档中预判——因为文档根本不会告诉你"ARO的 Internal LB 在这个场景下会怎样"。

验证也依赖三个不同环境的测试：AWS、ARO、Baremetal。每个环境跑一遍，全部通过才确认修复正确。

这些知识，在遇到它们之前，你觉得自己不需要；在遇到它们之后，你再也不会忘。

叫它"必要难度"也好，"有价值的挣扎"也罢——被这类 Bug 卡住不是学习的失败，是学习的核心机制。你花时间摸清不同 OpenShift 环境之间的架构差异，这个过程形成的理解，是看一万遍教程也换不来的。AI可以在两分钟内写出那段修复代码，但 AI 不可能知道"什么时候需要写这段代码"。

同样道理，我解决前面那个证书轮转同步问题的过程中，最"有价值"的部分不是写那几十行验证代码，而是在排查过程中形成的理解：Operator 的同步周期有多长、ConfigMap 更新在什么条件下会被跳过、证书轮转的时间窗口选择有什么讲究。这些理解，只可能在踩坑中获得。

AI 让人不卡了，但也让人不生长了。

三、技能退化 vs 从未形成

有人会问：我自己有多年编程经验，现在靠 AI 写代码，停掉 AI 我还能写吗？

大概率能。这叫技能退化，思想框架还在，恢复只是时间问题。

就像你学会了骑自行车，十年不骑再上车虽然摇摇晃晃，但不会摔倒。因为那个平衡感的大脑回路已经形成了。

但一个初学者如果从第一天就用 AI 生成一切——需求理解靠 AI、代码实现靠 AI、Debug 也靠 AI——三年后他"用"了三年 AI，但编程的心智模型从来没有建立过。

这不是技能退化，是技能从未形成。

退化的技能可以恢复，从未形成的能力需要从头开始。这是本质区别。

我团队之前招过一个自称"写了两年 Python"的候选人。问了一个很基础的问题：一个函数参数是可变对象，多次调用会有什么效果？他答不上来。他说平时都让 AI 写，没注意这些细节。

这不是他的错——是环境让他绕过了所有"必要难度"。但问题在于，当 AI 写出的代码出现深层 Bug 时（比如引用混乱、并发竞态、资源泄漏），他没有能力诊断。因为这些不是语法错误，是需要心智模型去定位的逻辑问题。

就像如果有人丢给 AI 一个 OpenShift 证书轮转问题，AI 可以写一堆 oc 命令去排查。但如果 AI 根本不知道 kube-root-ca.crt 的同步延迟可能会达到 10 分钟——它怎么可能告诉你在哪里加超时等待？

两种完全不同的处境有经验者技能退化（可恢复）停用 AI 后：· 写代码变慢但不卡壳· 知道从哪下手排查问题· 框架还在，练习就能恢复· 思维通路已固化初学者从未形成（重头开始）停用 AI 后：· 无从下手，甚至看不懂报错· 不知道问题可能出在哪里· 脑子里没有系统的认知架构· 需要从零开始建立心智模型

四、人才管线危机：Junior 少了，但通往 Senior 的路没变短

这两年行业的招聘趋势很清晰：初级岗位在缩减，但高级岗位需求不减反增。

逻辑很简单——AI 提高了生产率。一个 Senior 配上 AI，能干以前三个人的活。所以公司不再需要那么多 Junior，但需要更多 Senior。

问题在哪？

Junior变成Senior，不是靠时间熬出来的，是靠处理足够多的"认知挑战"积累出来的。而这些认知挑战，正在被 AI 大量屏蔽。

我回想自己提升最快的阶段，恰恰是做那些"AI 帮不了"的事情的时候：

在公司用 RTX 4090 跑 Qwen 3.5 27B 模型推理，需要理解显存怎么分配、KV 缓存吃多少、并发数开几个合适——这些没有 AI 能帮你做判断，因为每台机器的硬件、每个模型的量化方式都不一样。只有理解了底层原理（显存 ≈ 模型大小 × 2.5~3.0，KV 缓存和上下文长度成正比），才能在每次换模型或换硬件时做出正确的部署决策。

同样，那个证书轮转 PR 的核心洞察——"kube-root-ca.crt 的同步可能有 10 分钟延迟"——不是在哪个文档里写着的，是我在反复踩坑后内化的经验。AI可以帮我把这段验证写得完美无缺，但如果没有那个心智模型，我根本不知道需要写这段代码。

AI 压缩了信息获取的成本，但认知积累的"量"没有变。达到 Senior 需要的判断力、系统理解力、风险感知力，依旧需要数百次独立解决复杂问题的经历来堆砌。AI缩短了"找到答案"的时间，但缩短不了"内化经验"的过程。

所以中级岗位的断层，可能是未来两三年最严重的结构性风险。

五、区分"纯摩擦"和"有价值挣扎"

到这里，你可能觉得我在反对用 AI。不是的。

我每天都在大量用AI。写这个公众号也是用 AI 辅助完成。关键不在于"用不用 AI"，而在于区分两种不同类型的困难：

🔧 纯摩擦（交给 AI） 写 shell 脚本的语法细节、查 API 调用方式、格式化代码、写 CI 配置——这些事情没有认知增益，交给 AI 最高效。那个 PR 里把 oc get secret ... | base64 -d | openssl x509 写好，完全可以交给 AI。 

🧠 有价值挣扎（必须亲历） 判断"证书轮转后到底需不需要加同步验证"、理解为什么同步会延迟、定位 x509 错误的根因——这些事情的心智产出与"你亲历的深度"成正比。那个 PR 的真正价值不在代码，而在决定"在这里加验证"的判断。 

花时间摸清 ARO 和 Baremetal Hypershift 的架构差异、反复在多个环境上验证修复属于"有价值挣扎"——它让我理解了 OpenShift 在不同基础设施上的差异。而写那段加字段、改部署函数的代码属于纯摩擦——交给 AI 就行。

这个区别，只有自己实践过才能判断。因为"什么是有价值的挣扎"本身，就是心智模型的一部分。

知道了这些，对你有什么用？

认知层面：编程学习的价值不在"写出代码"这个结果，而在"建立心智模型"这个过程中。AI 替代了输出，但替代不了你在脑子里构建的系统认知。那个 PR 值钱的不是那几十行 shell，是决定"在这里加什么验证"的判断力——这种判断力只来自经验和心智模型，不来自代码生成能力。 

能力层面：四条可操作的行动建议—— 

① 先拆解，再让 AI 写。面对一个任务，先自己想清楚逻辑、判断哪些地方可能出问题，再让 AI 实现。别一上来就让 AI 给方案——那等于把判断权也交了。

② 每周留半天，零 AI 写代码。不是为了效率，是为了维持你的思维通路。就像跑步机不是通勤方式，但能保持你的运动能力。

③ 学会区分"纯摩擦"和"有价值挣扎"。写代码交 AI，定位问题自己来。能区分这二者的能力本身，就是最值钱的能力——因为当你还在纠结"要不要查这个 API"时，别人已经在思考"这个功能到底有没有边界条件没处理"。

④ 如果你是团队 Leader，给初级成员保留核心问题。不要所有难题都自己扛或全丢给 AI。留一些"他们暂时搞不定但努力一下能搞定"的问题，这是他们成长真正需要的土壤。

判断层面：不是所有挣扎都值得保留。选择硬件、配置环境、解决特定的框架 Bug 可能已经过时了——如果一项技能在未来两年内完全没有应用场景，那它的"有价值挣扎"也会随着时间变成纯摩擦。判断标准很简单：你正在解决的困难，是你成长路径上必经的关卡，还是只是路径本身太烂？ 

代码可以被 AI 高效生成，但思维无法被替代。

在一切都能"一键生成"的时代，刻意保留一些"不那么容易"的学习方式，不是保守，而是对自己未来竞争力的长期投资。

守护你的"必要难度"，就是守护未来竞争力。