🏠

读这篇文章时想到了几点。

有趣的是你提到 Brooks¹ ——今天可以用稍微不同的形式来论证同样的事：给一个已经落后的项目增加 LLM（算力）只会让它更落后；因为我们在事实上已经同意用算力取代人。这疯狂吗？据我所知，在真正的商业项目（不是个人小项目）中，还没有人真正实践过这一点。项目中的沟通仍然是最重要的因素。我相信你也记得同一本书中"概念完整性"有多重要。在个人工作中实现概念完整性与在团队中实现非常不同，我认为 LLM 大多数时候实际上是在破坏团队协作，把英雄式的卓越个人程序员推为唯一可接受的规范，引发裁员，阴暗地重塑行业。这种达尔文主义让我想起原法西斯的想法，阴险且非常危险：

"Noi affermiamo che la magnificenza del mondo si è arricchita di una bellezza nuova: la bellezza della velocità"; "Noi siamo sul promontorio estremo dei secoli!.. Perché dovremmo guardarci alle spalle, se vogliamo sfondare le misteriose porte dell'Impossibile?"

（注：意大利语，引自菲利波·托马索·马里内蒂 1909 年《未来主义宣言》——"我们宣告，世界的壮丽因一种新的美而更加丰富：速度之美"；"我们处在世纪的极顶！……如果我们想要冲破那不可能的奥秘之门，为什么要回头看？"）

你问"为什么那些现在抗议 AI 的人过去十年没有被软件的状态吓到"？你怎么知道的？我不认为如此——他们确实被吓到了，但现在更担心的是垃圾代码以更不可控的方式被生成，或者因为速度太快、因为他们赖以判断的实践正在瓦解，他们无法分辨好代码和坏代码。所以"在 AI 出现之前的那几年我们触碰到的垃圾水平已经令人难以置信"——而现在它可能比以前增长得更快。

"你必须理解事物如何运作，什么是最好的设计，如何达到某种性能水平。"——正是如此。但如果一切都被加速了，哪里还有时间学习？学习发生在过程中，在试错、在失败和恢复中。那是你那一代人能享有的时间和学习奢侈，而新一代人无法享有。否定了时间，就否定了学习。

"那些抗拒多半不是意识形态驱动的吗？"人为什么要抗拒？我们是不是应该反过来问问：那些正面态度有多少只是纯粹的资本和多巴胺驱动的？我们是不是该多听听那些抗拒的声音？抗拒是好事——尤其是当对抗的是自上而下的私营公司，它们公开用一个人工的、集中的、昂贵的神经网络取代你生物性的、去中心化的、协作的神经网络，还要向你收费。想想吧。

归根结底，不看代码，怎么看到想法？如何排除语言本身来评估用那种特定语言表达的想法？对话在哪里呢？只在自然语言里？自然语言是不是太宽泛了，无法精确表达想法？这难道不也正是我们不用自然语言做数学、而是用另一种语言的原因吗？音乐也是同样的道理，对吗？如果你是对的，那我们早已生活在奇点之中。

如果你只用自然语言来把握想法，你只能评估最终效果，利用超音速迭代速度来看结果——这排除了人类过程中正常的尝试/失败/学习循环。反过来，这实际上迫使你无法真正把握想法——因为你从未参与过创造和实现的过程。

你也许已经掌握了一种新方法。时间会证明你的 LLM 塑造的项目是否像人类塑造的 Redis 一样成功、可维护和高效。这是一个完美的实验，值得关注。

除了你，我认为你没有考虑到的是：大多数人还没有成为你，或者永远不会成为你。他们在大团队中工作，需要工匠精神和时间——用来形成和巩固自己的想法、品味、判断。这同样要通过做事、通过把失败正常化、通过从不混淆语法和语义来实现。

归根结底，我不认为我们可以要求人类在不掌握实现的情况下掌握想法。这不是计算机科学问题——这是一个社会问题和存在性问题。

对于年轻程序员来说，仅仅 review LLM 生成的代码并不是有效的学习和提高方式。学习编程需要一个"顺应"（accommodation）的过程：通过试错、调试和独立解决问题，逐渐重塑自己的理解。

AI 让理解代码背后的"为什么"变得比以往任何时候都重要——而不是代码本身。过去，开发者常常通过数小时的实验和调试来达到这种理解。今天，一个 prompt 几秒钟就能给出答案。这虽然有用，但那些艰难的几小时并非浪费——它们是学习过程中不可或缺的一部分。

计算的历史就是一部抽象的历史。每一代人都向上移动一层，不再把低层作为主要的控制对象。代码现在正在成为那个低层。这感觉像是一个自然的延续，但很多程序员仍然难以接受。

因为我们入这行就是为了写代码。我不想跟 AI 说话来得到代码。我要亲手写代码。

不读代码怎么 review PR？

你 review 结果：结果是否符合预期？

git diff。传给 AI，让它给个解释。

别听人说什么，看人做什么。

谢谢写这篇文章！如果我没理解错，你同时在说两件事：（1）开发者不应该费心读代码，（2）但你仍然在读。你用"这很快就没必要了"来解决这个矛盾。

所以问题变成了：什么时候你才会认为新模型（和编排工具）足够可靠，可以省掉 review？

有一个办法可以测试。你写道："Fable 和 GPT 5.6 对 sorted sets 内存节省的 review，能发现比我 review 更多的错误和细微竞态条件。"——你愿不愿意把三种 review 并行独立运行，然后公布对比结果？

你这篇文章显然也没校对就发了。

谢谢 Salvatore 分享经验和思考。这些观点来自一个既在"AI 之前"就已经真正开发多年、现在又在用 AI 做最高水平开发的人，分量极重。

所以我厚着脸皮、也有点惭愧地加入很多追随者的行列，请求你分享一下你现在的工作流程，你是怎样用 AI 做你做的事的。使用方式千差万别——从随机 prompt 到 vibe coding，到组织专用 agent，到循环……无论年轻与否，刚起步的人今天都在艰难地寻找自己的路。在这片广阔的海洋中，有一束指引的光——有点像当年的"C 语言课程"——会是极大的慰藉 ;)。

对于个人项目，这听起来很自然也很合理。

对于团队项目就更复杂了，因为链条是：开发者→想法→ prompt →代码 + PR 评论。你看到的是后者，从中推断想法并不直接。我仍然认为这是未来，我们应该更擅长定义清晰可验证的规格和测试，通过代码来证明想法。

对于个人项目，这非常自然也很合理。

对于团队项目，要掌控其他开发者的想法就更复杂一点，因为链条是：开发者→想法→ prompt →代码，但你只看到代码 + PR 评论。我仍然认为这是未来，我们应该更擅长通过可验证的规格和测试来定义想法。

如果你是"在监视"机器的代码，那还不如自己写。

听到 AI 写的代码比你好——哪怕你有 30 年经验和学习——确实会感到被欺骗。

但只从这个角度看问题太狭隘了：AI 是一个工具，每个工具在不同人手里效果都不一样。

如果一个蠢货²用它，结果会很差；如果 Linus Torvalds 用它，结果会非常出色。

就这么简单。

Salvatore，我认为这篇文章远远超出了编程的范畴。

"控制想法，而不是代码"描述的是每一门工程学科在其工具变得足够强大时都不得不面对的一个转变：人的价值没有消失，只是位置变了。

它不再必然存在于每个步骤的具体执行中，也不在对每一行的仪式感控制中。它向心智模型、架构、不变量、测试、开发方向移动。而且，更深处，向系统构建的意义和目的移动。

我来自系统工程领域，经验告诉我：模型不是地形，现实总会展示形式化表达遗漏的东西。在这个意义上，代码正在变成显示器：它仍然是不可或缺的，但它不再是理解的终极场所。显示器的背后是想法、假设、关系和系统的真实行为。

也正因如此，我感到你的 AI 理念与我相近。不是作为思想的替代，也不是逃避手艺的捷径——而是一个工具，它的力量迫使我们去承认判断力和责任感究竟在哪里。

因为工具越强大，我们就越不能用"执行的辛苦"作为借口。责任感不会稀释——它会更集中。机器可以生成、比较、纠正、极大放大手的能力。但仍然是人类的使命去识别什么有意义、什么应该被抛弃、哪个方向值得追随，以及——最终——什么我们愿意为之署名。

我在这篇文章中最欣赏的，还有伴随它的姿态。你利用自己作为代码深知者的可信度，去帮助尤其是更年轻的程序员理解：这种转变不是对他们学科的背叛。你并不是要求他们放弃严谨——你在展示，严谨必须被带到今天能产生更多质量、更多责任感和更多意义的地方。

才华，当它被充分认识和带到光明中时，就不再仅仅是个人的财产。它变成了可以归还给社区的东西。

这篇文章，在我看来，做到了。

谢谢。

在这个上下文中，我很难理解"年轻程序员"指的是谁……

我认为每个人都在解决两个问题：

1. 捕捉我的品味和手艺，然后把它们编成规则——像一个 `DESIGN.md` 文件。
2. 捕捉那些塑造品味和手艺的记忆。

一旦两者都存在，用定义良好的评分标准进行评测，就可以检测出与目标风格的偏差。系统可以迭代改进，直到产出接近我想象中的代码。

另一半是有可靠的静态和动态验证来建立对代码库的信心：

• Linting
• 基准测试
• 内存泄漏检测
• 单元测试
• 集成测试
• 在不同计算平台上跨 Redis HA 集群的自动化端到端测试

每一个偏差都成为反馈。系统利用这些反馈不断改进。

我觉得 Leslie Lamport 的很多想法——从数学角度出发——会与你有共鸣。他把"编码"视为编程中越来越不重要的部分。编程真正的智力工作，是构建一个对程序应该做什么、在重要想法真正所在的层面如何做到这件事的精确数学描述——这样你就真正有了一个工具来描述、检查、推理程序的性质。

要求描述精确（数学化）这个软约束暴露了歧义，让不必要的复杂性比在一堆代码中更容易被看到。做对了，你会发现写这种描述对于深入理解程序是不可或缺的。数学不是银弹，但它是一个非常强大的思考程序的工具，在编程社区中被严重低估了。尤其是因为描述大多数程序重要部分所需的数学非常简单，远远简单于试图从代码中恢复精确理解。

现在，我用 GPT-5.6 用得非常好，因为它的数学能力很强。难怪很多数学家发现这些模型在研究中有用。我大部分注意力花在抽象/具体规格上，然后 agent 大大加快了将具体规格非正式地转换为 C 的速度。我写具体规格的时候，力求它们能被相对干净地转换为有边界的系统代码。显然，最终的 C 仍然需要测试，但把自己和模型都锚定在程序的数学描述中帮助极大。规格通常能更清楚地说明系统代码实际上需要针对什么性质进行测试。

可以想见，在未来 5-10 年，当 agent 越来越减轻代码负担时，要最有效地理解和操作程序，数学素养将是必需的。

Lamport 自己的话表达了类似的感受

有了好的品味和对问题的理解，AI 生成的代码用人类 + AI 很容易 review。

也许会像汇编语言和高级语言的关系一样，对吧？某一天，可能几年后，只需要好的规格或需求就能在幕后完成出色的工作。至少在某些领域是这样。谢谢 Salvatore。

我想读更多。最好能看一个实际的例子——"不读代码而是控制想法"在实践中是什么样的。

不读（和写）代码，你怎么期望去理解事物如何运作、什么是最好的设计、如何达到某种性能水平？

我做软件 QA 超过 13 年了。过去 5-6 年里我看到一个趋势：很多公司正在远离手工 QA，感觉这像是一个正在消亡的领域——当然仍然需要，但工作机会少了很多。它走上了自动化的道路。

但最近我看到 QA 的需求在大幅上升，因为代码产出量大大提高，而且如你所说，代码越来越多由 AI 编写，很多问题会从缝隙中漏掉。

所以总的来说，我认为这波 AI 浪潮对 QA 人员和有这种思维模式的人来说是好事。我猜我们最终会有两种 QA：逻辑 QA（前开发者）来理解和优先处理代码使用的模式，以及"用户"QA——传统 QA，他们懂业务规则和前端交互。未来 5-10 年会如何发展，值得关注。

我理解，但在一定程度上我不得不——呃——不同意。

我确实相信：有好的实现思维模型、可靠的测试来验证正确性、以及其他加固 LLM 生成代码的措施，会使其更可靠。我们广泛使用这些实践，我公司的每个人都在用，它们确实帮助我们更快地写出更好的代码。

即便如此，我仍然会碰到一些奇怪的东西（然后加进知识库，避免重复出现）。但如果我先没有 review 代码，那些问题可能会无限期地留在那里……或者至少直到它们导致一个 bug。实际上，上周就发生了一次。

我们一个工程师在处理问题，我在 review merge request 时注意到用了 Atomics。在 JavaScript 中使用 Atomics.wait() 阻塞执行通常是一个警告，因为某些条件下它会暂停事件循环。我检查了测试，全部通过，覆盖率 100%。但测试覆盖率本身不能保证每一条边界情况或用户场景都被覆盖了。

我们做了一点实验，果然找到一种方法绕过了一项校验。事件循环被阻塞，整个应用停止响应。

这对最终用户会不会发生？很难说。会不会可能发生？绝对可能。我们的应用部署在有严格安全许可的环境中，打补丁很不方便。这些系统通常没有网络访问，更新必须手动下载、通过全面的安全审查，然后安装。有些情况下，这个流程可能需要数天甚至数周。

所以，是的，我认为 LLM 很出色。我们大量使用它们。但我们还没有足够的信心跳过代码 review。review AI 生成的代码会不会拖慢我们？当然。但它也能帮我们省掉一些非常昂贵的头痛。