手艺会失传吗？
AI 时代，程序员的工⁠匠精神何以为继

程序员文化真正需要传承的，不是手工敲代码的仪式，而是与复杂性保持直接接触的能力。经典著作是被压缩的经验；AI 时代的任务，是重建一条能让这些经验重新展开的学习回路。

第一部分 · 经典保存的不是答案

01从“这些书还有用吗”说起

最近我问自己一个听起来很实际的问题：《代码大全》《重构》《设计模式》这些书，在 AI 时代还有多大作用？最顺手的回答是，它们当然有用，因为人仍要判断 AI 写出的代码好不好。这个回答没有错，却避开了更难的部分：一个没有亲手被坏代码折磨过的人，凭什么获得这种判断力？

我们这一代人对“坏味道”的认识，往往先于术语。那种不舒服，是身体先知道的。改一个几千行的方法，修好了 A，B 却在另一个文件里悄悄裂开；你盯着屏幕，隐约觉得这段代码“不对劲”，却一时说不出到底哪里不对。沿着十几层调用去追一个含义暧昧的字段，越往下越像走进一栋不断加盖的老楼，每一层都留着上一任住户的隔断和走线，谁也不敢先拆哪一堵墙。面对没有测试保护的共享状态，你在深夜按下发布键，手指会有一瞬间的迟疑——那点迟疑本身，其实已经是一种知识。等到后来翻开书，才知道那些说不清的别扭各有名字：职责混乱、发散式变化、隐式耦合。书没有凭空制造这些感觉，它只是把你身体里早已积攒的经验一一点名，让模糊的直觉第一次有了可以说出口、也可以传下去的词。

AI 时代的年轻程序员可能走上另一条路：描述需求，生成实现，运行测试；失败后把日志交给模型，修不好就再生成一版。问题仍然发生，复杂性仍在那里，但它不一定直接作用在人的手上。就像每天坐车经过崎岖山路的人，能熟记沿途每一处景色，却未必知道路基为什么会塌；等到某天山体真的滑下来，他既说不清成因，也找不到自己能下手的地方，只能站在原地，等另一个懂路的人来抢修。委派掉的不只是敲键盘的动作，还有“出事时我知道该往哪看”的那份底气。

所以问题已经从“经典是否过时”变成了“经典赖以生效的经验从哪里来”。

02一整面书架，其实保存着不同层次的手艺

把所有经典都归为“教人写好代码”会低估它们。它们覆盖的是从计算到组织的一整条链。

这些书里，有的厚得让人望而生畏，注定不适合从第一页读到最后一页；有的例子带着上个时代的包浆，讲的是早已退役的机器和语言；还有的观点，本就该被今天的类型系统、框架和工程实践大方地修正甚至推翻。承认这些，丝毫不影响它们的分量。它们至今重要，不是因为每一页都能原样搬进下一次提交，而是因为它们像地层一样，保存了整个行业“如何一步步学会思考”的那段历史——哪些坑是前人替我们踩过的，哪些教训是用真金白银、宕机和加班换来的。读它们，某种意义上是在和几代人对话，听他们说：这条路我走过，别再摔在同一个地方。

Donald Knuth 把编程称为“艺术”，强调的并非神秘天赋，而是把积累的知识、技巧和创造力用于真实世界。TAOCP 甚至用虚构机器的汇编语言逼读者看清算法在机器上如何付出成本。SICP 则让人反复经历另一种震动：同一个问题，因为求值模型、状态表示和抽象边界不同，会长成完全不同的程序。高级工具可以替我们完成实现，却无法取消这些差异。它只是把差异藏得更深——藏进一份看起来完美运行的输出里，然后在某个规模、某个边界条件上，把当初省下的代价一次性讨回去。

03模式是被压缩的事故史

今天让 AI “用 Strategy 模式优化代码”，几秒钟后就能得到接口、实现类、工厂和测试。形式太容易出现，以至于我们忘了模式原本从哪里来。

一个模式之所以成立，通常是因为人们在不同系统里反复遇到同一种张力：某个行为确实独立变化；某个外部依赖不断污染核心；一组条件分支本质上表达状态迁移。名称只是压缩后的索引。它背后还有适用上下文、冲突力量、已知后果，以及不用它会怎样。

以 Strategy 为例。它很少诞生于“我想要一个优雅的接口”，更多是从一个不断膨胀的计费函数里长出来的：普通用户、VIP、限时促销、跨境税率、退款回滚逐项叠加，直到几百行分支没人敢动，改一处就可能破坏另一处。最终，有人把“如何计算价格”这个会独立变化的部分从主流程中分离出来。模式为这种反复出现的变化压力提供了名字。生成一个 Strategy 只需复刻它的结构；理解它，则要判断眼前的代码是否真的承受着同一种压力。

这也是为什么读懂模式和生成模式不是一回事。生成只需要复现形状；判断则要回答：这里真的存在稳定的变化轴吗？新增间接层带来的理解成本，是否小于未来变化的成本？这个抽象在什么条件下应该被删除？

这句话也解释了传承的困难。索引可以复制，索引指向的经验却不能靠下载获得。

第二部分 · AI 改变了经验形成的路径

04旧的反馈回路，既低效又有效

传统的成长路径并不优雅，甚至有点狼狈。程序员亲手写下代码，也亲手在里面埋下雷；过一阵，一个需求变更或者一次半夜的线上告警，让雷炸开。于是他被迫俯下身：追踪状态在哪一行被改写，翻阅一个自己从没打开过的模块，给一段裸奔的逻辑补上第一个测试，再用一系列小到几乎不出错的改动，把系统一点点拉回安全区。这样的循环走过几轮，他身上会长出一种东西——还没动手，指尖就先替他发凉，提前感到“这里危险”。代码评审借给他另一双眼睛，让他看见自己看不见的盲区；长期维护则像一张迟到的账单，让当初图省事的短期选择，连本带利地显出真实价格；经典著作最后出场，把这些零散的、带着体温的遭遇，整理成可以迁移、可以命名、可以传给下一个人的概念。这条回路很慢，却每一步都在往人身上刻东西。

Peter Naur 在 1985 年提出“编程即理论建构”：程序员真正建立的不只是一份文本，而是一套关于现实问题如何被程序解决的理论。当原团队离开，代码和文档可能还在，这套理论却会消失；接手者必须重新建构它。^[9]

这个观点在今天尤其刺眼。凡是接手过“文档齐全、代码尚在、写它的人却已离职”的系统的人，都懂那种无力：每个函数你都读得懂，合在一起却猜不透当初为什么要这样切分；改一个看似无害的默认值，三天后在一个毫不相干的角落引发事故——因为那套把种种权衡串起来的理论，已经随着某个人的离开一起蒸发了。AI 把这件事推到了新的极端。它可以比任何人都快地产出文本，还能对着每个文件侃侃而谈，却不等于团队真的拥有了一套能应对新问题的共同理论。解释，是模型面对当下这个问题、当场生成的一个答案；理论，是维护者在证据不足、约束互相打架时，依然能做出前后一致判断的那种底气。前者可以随时召唤，后者只能慢慢长成。

05“完成”与“理解”第一次可以大规模分离

AI 辅助编程的速度收益是真实的，也高度依赖任务。2022 年的一项受控实验中，使用早期 GitHub Copilot 的参与者完成一个标准化 JavaScript HTTP 服务器任务快了 55.8%；研究者同时明确说明，它没有测量大型项目中的协作和代码质量。^[11] 2025 年 METR 让熟悉自己仓库的资深开源开发者处理真实任务，却观察到早期工具让完成时间增加了 19%；到 2026 年，更新实验出现可能提速的信号，但研究团队认为选择偏差使结果不足以可靠估计幅度。^[16]

这些数字不必被拼成一场“AI 到底更快还是更慢”的擂台赛，那是个问错了的问题。把它们放在一起，真正有用的提醒是：答案高度取决于任务的边界、你对这个代码库有多熟，以及手里工具是哪一代；换任何一个前提，结论都可能改变。而比“快慢”更要紧的一点是，完成速度和理解深度，本就是量在两根不同轴上的东西。一个人可以在一小时内交付一个能跑的功能，同时对它为什么能跑、会在什么情况下不跑一无所知。过去这两根轴多少还绑在一起：你写得快，通常也意味着你想得清；如今 AI 让“又快又不懂”第一次成为一种寻常、甚至高效的状态。

一项对 21 名编程初学者的观察发现，20 人借助生成式 AI 完成了任务。但对原本就不善于判断自己是否真正理解问题的学生，AI 并没有自动补上这种能力；有些人甚至因为任务做完了，误以为自己已经掌握了方法。^[12]

另一项实验让 15 名计算机专业研究生在已有代码库中修改功能。使用 Copilot 时，他们完成得更快，通过的测试更多，但对原有代码的整体理解没有相应提高。两项研究的样本都很小，不能据此下普遍结论。它们共同提示的风险更具体：完成任务，不等于理解系统。^[13]

这种分离过去也存在。复制 Stack Overflow 上的答案、套一个框架、调一次云服务，同样可能让人跳过底层。但那些跳跃都是短的、局部的——你至少还得自己把这块拼图嵌进整幅画里，接缝处的别扭会逼你多看两眼。AI 的不同在于跨度：理解需求、选择架构、落地实现、补齐测试、解释报错，整条认知链可以在一句提示里被一次性委派出去。抽象层不再是往上挪了一格，而是像一张幕布，可以临时把整条路径盖住。你按下回车，另一头递回来一份看似完成的东西，中间那段本该由你走一遍、也本该在你身上留下脚印的路，被悄悄跳过了。省下的是时间，隐形扣掉的，是你原本会在这段路上长出来的判断。

06三种能力会在无痛中变薄

第一种是因果地图。 亲手追踪故障的人会知道状态在哪里改变、异常如何传播、某个“多余判断”其实挡着三年前的一次线上事故。只看最终 diff 的人，会把这行判断当成噪声顺手删掉，代码更干净了，测试也照样通过——直到同一个故障在某个凌晨重新回来。他知道系统里有什么，却不知道每一样东西是被什么按住的；地图上画满了地名，却没有一条标着“此处水深”。

第二种是校准能力。 工程嗅觉不是列出“长方法、重复、耦合”这些词，而是判断坏味道是否值得现在处理；两段相似代码是真共性还是偶然相似；一层抽象是在隔离变化，还是提前设计。判断依赖预测与结果之间的多次对照：你先押一个注，“我猜这里改下去会崩”，再看它到底崩不崩。一次次对账，直觉才逐渐有了刻度。而 AI 恰恰最擅长替人跳过“押注”这一步：它直接端出一个看起来就对的结果，你来不及先判断，也就收不到“我判断错了”这条最有价值的反馈。

第三种是作者责任。 自己写下的错误会在心里刻一道印子：“这个坑是我挖的，下次手到这里会先停一下。”当模型生成、模型修复、模型解释，失败就很容易被记成“这次模型没写好”——一句话把自己摘干净。问题是解决了，可那道印子没有留在任何人身上；下一次，同样的坑会由同样放松的手，再挖一遍。

对 319 名知识工作者的调查，也捕捉到一种相似的张力：一个人对生成式 AI 越信任，他报告出来的批判性思考投入反而越少——仿佛把判断这件事，连同任务一起外包了出去。值得留意的是，研究并没有说思考就此凭空消失，它只是换了个地方发生：从“亲手把东西做出来”，转向了验证、整合和对结果的把关。这不是一项专门针对程序员的实验，也依赖参与者的自我报告，结论要留有余地；但它指出的方向很有用——AI 时代需要我们有意识地设计出新的思考动作，而不能想当然地以为，旧的那些动作会在工具更迭中自动幸存下来。不去主动保留的东西，往往就在无人察觉中悄悄流失了。^[14]

07当经典从实践智慧退化成提示词

最可能出现的未来，并不是没人再谈经典。相反，SOLID、DDD、Clean Architecture、Strategy、Repository 会充满提示词和代码库。每个名字都很专业，每一层也都能得到合理解释，却没有人说得清它正在抵抗哪一种真实变化。

于是，“请遵循 SOLID 并使用合适的设计模式重构”成为一句咒语。AI 可能把一个二十行的函数，端端正正地摊成 Factory、Manager、Provider、Handler、Resolver 五层结构；测试全绿，目录比以前整齐得多，评审时也挑不出错——每一层都能自圆其说，每个类名都写在教科书里。可等到真要改一个字段，你会发现自己得在五个文件之间来回跳转，才拼得出原来那二十行做的事。系统没有变简单，只是把复杂度换了个更体面的包装。过去的过度设计至少是人亲手堆的，堆的人多半会在日后的维护里，一点一点把学费交回来；如今抽象可以批量生产，账单却被推迟——推给另一个人、另一个季度、另一次没人记得起因的重构。

这就是我更担心的文化空心化：术语像潮水一样铺开，孕育这些术语的经验却在退潮。一个程序员可以在架构评审上谈边界、谈内聚、谈依赖倒置，讲得漂亮又自信；可一旦线上冒出一个并发竞争、一处数据对不上、一段莫名其妙变慢的接口，他却在栈的深处停住了脚——因为那些词他是从别人嘴里、从模型口中接过来的，而不是自己在某个凌晨、对着一屏日志一寸寸挣出来的。词还在，词背后那个会疼、会记事的身体，却空了。

第三部分 · 在 AI 时代重读经典

08大部头的价值，是训练对成本的敬畏

TAOCP 显然不是一本日常 Web 开发手册，也不该被当成入行的门槛——今天没有任何理由，要求每位工程师先用 MMIX 手写一遍排序，才有资格去调用一个标准库里的 sort。把大部头供成必须通读的圣经，恰恰误解了它。它真正持久的价值，是一种近乎生理的提醒：一个在你眼里“不就是排个序、查个表”的简单操作背后，其实压着一整套模型、证明、边界和代价，只是平时被库和硬件替你悄悄承担了。读过它的人，面对任何“看起来很简单”的东西时，心里会多一分本能的敬畏，而不是轻慢。

AI 会把“我能生成一个实现”变成极其廉价的能力，也因此更容易诱导人把“能生成”误认成“已理解”。屏幕上那段代码跑通了、测试也过了，人很自然地以为自己懂了；直到数据量翻了两个数量级，那个悄悄用了平方复杂度的实现，在某个周一早晨把整台机器拖垮。读算法、读计算模型，不是为了在脑子里和模型比谁记得多——那场比赛人从一开始就会输——而是为了给自己配一把尺：输入规模翻十倍、百倍时，会发生什么？正确性到底压在哪几条不变量上，抽掉一条会怎样？把随机性、精度、内存和并发换个前提，原来的结论还站得住吗？什么时候可以放心地信任一个成熟的库，什么时候又必须硬着头皮读进它的实现，甚至读到那篇原始论文？有了这把尺，AI 生成的东西才从“我猜它对”变成“我能说清它为什么对、又会在哪里错”。

同样，SICP 的意义也不只在 Scheme。它训练人穿过语法看见求值、组合、状态和解释器。一个能生成十种语言的 Agent，反而让这种穿透力更重要，因为表面差异越来越容易消失，语义差异仍会在运行时索要代价。

09《重构》应从“美化术”恢复成实验方法

在所有经典里，《重构》可能比过去更重要。Fowler 对重构的定义很精确：通过一系列保持外部行为的小变化改善内部结构。小步不是审美偏好，而是风险控制；测试也不只是最后验收，它是每一步仍处于已知世界的反馈。^[6]

AI 很擅长“重新生成一个更干净的版本”。你让它整理一个模块，它常常一并把接口换了、把依赖升了级、顺手改了某个异常的语义，再补上一组与新实现严丝合缝的测试——绿灯亮起，看起来一切安好。可是等到几周后，一个上游调用方突然报错，你回头翻提交记录，会发现根本分不清：到底是哪一步改动动了外部行为？测试为什么没拦住？因为那一次提交里，重写和重构被搅在了一起，而它们本该泾渭分明。重构的全部安全感，来自“外部行为不变”这个铁律：正因为行为不动，你才敢放心大胆地重排内部结构。一旦把“换个更好的实现”混进来，这条安全绳就断了，团队也随之失去了追溯变化来源的能力——出了事，谁也说不清是哪一刀划的。

《修改代码的艺术》进一步提醒我们，旧系统最先缺的通常不是漂亮结构，而是可以感知行为、隔离依赖的接缝。^[7] AI 时代可以把它变成一份明确契约：重构前列出可观察行为和未知区域；先建立特征测试；限制写入范围；每个小差异独立运行验证；只有证据允许，才进入下一步。Agent 可以执行大部分机械劳动，人仍需定义什么不能改变。

10把设计模式当作可证伪的假设

模式不应被禁用，也不应被默认启用。更好的用法，是把每个模式写成一项可以被现实推翻的设计假设：

这样一来，Strategy 就不再是四个整整齐齐的类名，而是一句需要被证据支持的断言——“这里确实有一根会独立变化的轴”；Adapter 也不再是随手套上的统一外壳，而是一道边界，专门拦住外部的语义，不让它渗进核心；Observer 更不是天生就比一次直接调用高级，它只是拿“调用链变得不那么一目了然”这个代价，去换时间和依赖上的松绑，值不值得，要看具体处境。在这套用法里，AI 反而如虎添翼：它可以在几秒内生成好几种候选结构，摆出对照方案，甚至主动造出让某个模式露馅的反例。人不必再亲手敲这些样板，人要做的是那件机器做不了的事——当那个把模式拉上被告席、逼它拿证据说话的法官。

11组织类经典提醒我们：代码之外还有共同理论

《人月神话》《人件》和 Naur 的文章，讨论的范围各不相同，却共享一个常被忽略的前提：软件从来不是一份孤立的文本。它同时是一套概念、一张人与人之间的沟通网、一种工作环境，以及一个说得清“谁对什么负责”的结构。当 AI 把局部实现的速度拉高之后，这些因素非但不会随之缩小，反而会因为对比更悬殊而浮上水面，成为真正卡住整体的那道瓶颈——代码几分钟就生成好了，可到底该不该合、由谁拍板、出了事找谁，这些老问题一个都没被自动回答，只是被衬托得更刺眼。布鲁克斯当年那句“没有银弹”，说的正是这件事：真正的难，从来不在造出代码，而在想清楚要造什么、以及一群人如何就此达成共识。

DORA 2025 把 AI 描述成组织能力的一个放大器：它会放大既有的优势，也会同样忠实地放大既有的毛病；真正的收益不在工具本身，而藏在它接入的那套组织系统里。^[15] 这与经典的判断并不冲突，反而像隔了几十年的一次互相印证。一个概念完整、边界清楚的仓库，会给 Agent 一批稳定可依的范例，让它照着既有的纹理往下写；一个测试快、反馈紧的团队，能安全地吸收比过去多得多的变更；一个责任清晰的组织，遇到风险时知道该由谁点头。反过来，边界含混、知识过期、谁也说不清系统为什么长成这样的团队，只会更快地量产出一堆彼此矛盾的“局部正确”——每一块单独看都对，拼在一起却谁也接不上谁。AI 不创造这些差距，它只是把差距拉得更快、更明显。

所以，AI 时代的经典阅读不能停在个人修养。它必须进入代码评审、任务设计、事故复盘、架构决策和团队培养，否则读完的知识仍然找不到附着点。

第四部分 · 建立 AI 时代的新学徒制

12不要恢复稀缺，要恢复反馈

要求年轻程序员放弃 AI、先老老实实手写几年代码，听上去像是在守护基本功，其实既不现实，也犯了一个更根本的错误：把手工劳动本身当成了学习。可过去那些痛苦，很多只是在纯粹地消耗时间——翻文档查一个记不住的语法，一行行抄写千篇一律的样板，把同一段逻辑机械地从旧框架搬到新框架，对着进度条等编译。这些苦从没让谁变得更聪明，它们消失，一点都不可惜，该庆幸才对。

但不是所有摩擦都该被抹平。真正值得留下的，是那些能改变“下一次判断”的经历：动手前先预测结果，再观察它是否兑现；亲自追踪一次关键的状态变化；向别人解释为什么选择这个抽象；几个月后再回来维护自己曾经接受的代码。它们的价值不在于制造痛苦，而在于把判断与后果连接起来。我们要去掉的是消耗，保留的是反馈。

认知学徒制的经典模型讲究一整套动作：先示范，再辅导，搭起脚手架，让学徒把思路说出来、回头反思、放手探索，然后随着他越来越稳，一根一根地把脚手架抽走。^[10] 这套模型天然适合 AI，甚至 AI 可能是它有史以来最理想的脚手架：它可以当着你的面演示一位专家会怎样追一个故障，可以按你卡住的程度一级一级地给提示，可以随手造出一个反例逼你重新想，可以把三种方案摊在一起让你比较取舍。问题在于，最省事、也最危险的用法恰好把这套顺序整个倒了过来——在学徒连问题的模样都还没看清时，就把一份完整、漂亮、可直接运行的答案塞到他手里。脚手架本该最后才撤，这里却让人的参与第一个消失；扶手还在，学步的人却已经被抱到了终点，从来没有真正自己走过一步。

13把学习模式与生产模式分开

团队不需要在每个任务上牺牲交付速度。更实际的做法，是承认“完成工作”和“培养能力”是两种不同模式，并为后者保留明确预算。

对新人，与其划一片笼统的“禁用 AI 区”（既难执行，也容易被当成惩罚），不如设一份更精确的 困难预算：明确规定哪些地方必须先由人尝试。关键练习中，AI 不应一开始就给出完整方案；调试时，先由人画出调用链，写下状态假设，再去验证；算法题则先写清复杂度和不变量，让 AI 按需逐级提供提示。等这些基础真正建立起来，再逐步放开生成能力。让自动化程度适应人的能力，而不是让人被工具为交付设计的默认设置牵着走。

对资深工程师，学习同样没有到站。他们要练的，是一批手工时代根本不存在的新手艺：怎样把一个大任务切成 Agent 接得住、也交得清的小块；怎样在一片看起来无比整洁的代码里，嗅出那种正在悄悄发生的架构漂移——它不报错，只是让系统一点点偏离原本的构想；怎样设计出信息量足够高的验证，让一次通过真的说明点什么，而不只是让灯变绿；以及怎样审阅比过去多出数倍、且不再由人逐字写下的代码产出，还不被它的体量冲垮判断。经典在这里提供的是一套判断的坐标系，新实践要做的，是把这套坐标重新焊到已经变样的生产方式上。老手也在重新当学徒，只是这一次，没有前人趟过完全一样的路。

14六个可以进入团队日常的反馈装置

15未来的高级程序员，仍然要能闻到味道

团队也得改一改自己丈量事情的尺子。如果考核只盯着关掉多少工单、写了多少行、合并得有多快，那么最聪明的做法，就是把理解的成本悄悄推给未来——反正账不会记在这个季度、这个人头上。人会诚实地朝着被测量的方向生长。所以除了交付指标，还值得盯住另外几件更难量化、却更接近真相的事：返工总是扎堆出现在哪几个模块？一个关键模块，全队到底有几个人能不看文档、不问 AI 就把它讲清楚？三个月前那批 AI 生成的改动，如今想动一动要付多大代价？一次事故过后，除了关掉告警，有没有沉淀出一条可复用的测试或规则？代码评审里，人究竟是在挑出真正的语义问题，还是只是把变量名和缩进抹得更顺眼？这些问题没有漂亮的仪表盘，却比任何速度曲线都更早地告诉你，一支团队是在积累理解，还是在借未来的债。

这并不意味着人人都得啃完整套 TAOCP，也不意味着资深工程师就该逞能手写每一个函数。一种健康的工程文化，从来不是全体成员背诵同一份书单、说同一套黑话。它更像一组心照不宣的共同习惯：对复杂度保持敬畏，不把“测试通过”轻易当成“我已经理解”；发现一个抽象错了，愿意亲手把它删掉，而不是再糊一层上去；动系统之前，先把“哪些行为绝对不能破坏”摆到台面上说清楚；故障来临时，第一反应是走进现场，而不是转身甩锅给模型；以及最朴素、也最难的一条——真心接受“上线之后的结果，我有份”。这些习惯不写在任何书里，却是一本本经典真正想教会人的东西。

经典著作仍会参与这套文化，但读法会改变。《计算机程序设计艺术》可以和性能剖析、模型生成的算法对照着读；《重构》可以变成 Agent 修改协议；《设计模式》可以变成设计假设的审查表；《人月神话》和《人件》则帮助团队抵抗“更多 Agent 自然等于更多产出”的简单想象。书不再等待某一天从头读完，而是在人遇到真实问题时，提供更长的历史和更准确的语言。

AI 正在让“写出来”变得越来越便宜，也因此让另一些能力更加重要：知道为什么这样写，知道什么不该写，知道出了问题由谁负责。手艺不会因为键盘敲得少了就自然消失，也不会因为经典仍在书架上，就自动传到下一个人手里。它能否延续，取决于我们是否把“理解”重新设计进工作流程，把“反馈”留在回路里，并把“责任”交给具体的人。

一个没有经历过所有旧式苦役的程序员，仍然可以形成可靠的工程判断。但有一个前提不能少：他不能始终被隔在系统之外，只做结果的旁观者。他需要亲自进入现场，追踪故障，解释原因，作出修复，并继续承担修复后的结果。把人留在因果回路里，或许就是 AI 时代传承这门手艺最重要的事。