> ## Content Index > Fetch the complete content index at: https://www.hubwiz.com/blog/llms.txt > Use this file to discover other available public pages before exploring further. # 即使有 AI 工具，编程仍然很难！ - URL: https://www.hubwiz.com/blog/coding-with-ai-tools-is-still-hard/ - Published: 2026-06-01T02:24:26.000Z - Updated: 2026-06-01T02:24:26.000Z - Description: 即使有 AI 编程工具，你仍然需要资深工程师来处理那些困难的部分。 - Author: admin - Tags: JOB MARKET, #Import 2026-10-14 14:41 上周，我漫谈了一点软件工程的历史，得出的结论是：自时间伊始，人们一直在拼命寻找[某种东西](https://en.wikipedia.org/wiki/COBOL?ref=hubwiz.com)、[任何东西](https://en.wikipedia.org/wiki/Fourth-generation%5Fprogramming%5Flanguage?ref=hubwiz.com)，以允许[普通人](https://en.wikipedia.org/wiki/Normie%5F%28slang%29?ref=hubwiz.com)来开发软件，希望能够借此解决[软件开发危机](https://en.wikipedia.org/wiki/Software%5Fcrisis?ref=hubwiz.com)。到目前为止，这些努力都失败了。实际发生的是，该领域的其他改进使得软件工程师的生产力更高。 然而，尽管软件工程师比以往任何时候都更具生产力，而且软件工程师的数量也比以往任何时候都多，软件开发仍然很昂贵。为什么？ 简单来说：因为我们也需要比以往任何时候*更多*的软件，而且因为，**尽管有所有的改进，软件开发仍然很困难**！ 信息技术领域是一个从非常小的原点向外扩展的[圆盘](https://commons.wikimedia.org/wiki/Circles,%5Fdisc%5Fand%5Fannulus?ref=hubwiz.com)，大约在 60 多年前发生了大爆炸。我的第一份工作是在一家银行，那时圆盘还很小，我们使用*三台*大型机来进行核心账户处理，其中大部分以夜间批处理作业的方式运行。 问：为什么是夜间？ 答：因为人们白天会创建交易 🙂。然后，到了傍晚，这些交易通过"柴油网"传输到我们的数据中心：一支车队在下午晚些时候开车去银行的所有分支机构，收集打在穿孔卡片、软盘等各种介质上的交易。在数据中心，我们将这些交易读入大型机并启动批处理作业。批处理运行结束后，我们打印对账单，然后"柴油网"将这些对账单分发到全国各地。客户将这些打印的对账单装订成小册子，作为账户变动和余额的凭证。如果这听起来很繁琐，欢迎来到互联网之前的世界 🙂 随着时间的推移，经过多次圆盘扩展，我们现在生活在这样一个世界：每个消费者口袋里都有一台便携式电脑，比我在第一份工作中使用的大型机更强大。这些电脑还持续连接着地球上所有其他电脑，所以不再需要"柴油网"和打印对账单，因为你口袋里电脑上的银行软件可以让你[随时随地](https://www.youtube.com/watch?v=weRHyjj34ZE&ref=hubwiz.com)输入交易、查看账户和检查余额。 > 事实上，据我所知，如果你现在*确实*想要一份打印的对账单，你要么运气不好，要么需要为此付出高昂的代价。 不断扩展的信息技术圆盘代表着更多的计算机落入更多人手中，以及这些计算机进行通信和呈现信息的新方式。所有这些都需要软件，而且因为圆盘的表面积以[二次方](https://en.wikipedia.org/wiki/Quadratic%5Fgrowth?ref=hubwiz.com)增长，需要创建和维护的新软件量也是如此。在我的职业生涯中，圆盘扩展到了包括小型机、个人电脑、互联网，以及最终的移动设备、可穿戴设备和物联网。 为了编写和维护这些新软件，我们总是需要更多的软件工程师，尽管有各种改进，他们仍然跟不上不断增长的需求。因此，软件危机持续存在…… 软件开发仍然昂贵的*另一个*原因是，尽管过去几十年有各种改进，**软件开发仍然很困难**。 几年前，我写了一篇题为"[为什么编程很难](https://medium.com/@josvisser/why-programming-is-hard-90cb7ff06dcf?ref=hubwiz.com)"的文章，试图通过概述软件开发的认识和机械两个方面来解释这个事实。*认知*方面涉及这样一个事实：几乎不可能事先知道要构建什么以及如何最好地构建它。*机械*方面描述了编程语言和库的内在复杂性。这些共同解释了为什么构建一段可工作的代码很困难，因此需要深厚的专业知识。而通常来说，深厚的专业知识是昂贵的。 > 顺便说一句：我在这个故事中省略的一件事是，与此同时，被认为可用软件的标准也在提高。 AI 编程工具登场。 现在我们可能都知道了，[使用 AI 编程工具编程](https://josvisser.substack.com/p/the-one-about-codex)是惊人的。就我自己而言，在 2026 年迄今为止，我没有手写过五行代码。 > 考虑到现在已经是将近六月了，这也许有点令人担忧。如果我忘了怎么写怎么办？但这大概是留给另一篇周三智慧文章的话题了。 我想，由于我在一个 AI 前沿实验室工作，我处于发展的前沿，但我在科技公司的同行们告诉我，他们有很大的压力去使用 AI 编程工具。显然，有些公司甚至在部署指标系统，以查明他们雇佣的软件工程师是否在偷偷手写代码，从而在"偷"股东的钱（大概是这样，我真的不太理解这种想法的逻辑）。 所有人都在期待 AI 编程工具带来奇迹，这种期待是有道理的，但我觉得他们可能把注意力放错了奇迹上，因为 AI 编程工具会提高软件开发的速度，但*不会*使软件开发整体变得更容易。**即使有 AI 编程工具，编程仍然很难**！ 要理解这一点，我们首先需要认识到软件开发*不是*制造过程。制造过程的本质是开始时需要大量的脑力，但随后复杂设备的生产被简化，使其可以由机器人和技能和知识不如原始设计者的人来执行。软件开发不是这样的。 每一段软件都是独特的、定制的、独一无二的东西，是为它所解决的*确切*问题量身定制的。当然我们有库和可复用的基础设施组件，而且幸运的是确实如此，否则我们完全没机会。但建立在其上的实际应用程序是一次性的。这意味着对于每一段软件，在设计和实现方面我们都需要或多或少地从零开始。就好像航空公司为他们机队中的每架飞机都为预期的乘客、航线和机场进行定制设计和建造，包括发动机和航空电子设备。这可能使飞行更加舒适，但成本将是天文数字，而且绝对会更不安全。 软件开发的大问题是确切知道需要构建*什么*（需求）以及它需要如何运作（架构/设计）。一旦你脑海中有了所有这些细节的清晰画面，输入语句就（相对来说）容易了。由于各种原因，输入语句非常耗时，因为需要输入大量语句，而且在输入过程中你会犯很多错误，但总体来说并不困难。 然而，由于编程的晦涩特性，以及因为（正如我们后面将看到的）当我们输入语句时，我们实际上仍在脑中设计软件，非工程师通常认为项目中的*编码*部分是有问题的部分。软件工程师知道得更清楚。如果编码部分实际上困难和繁琐，那通常表明你还不太清楚你要解决什么问题或如何解决它。 输入语句*正是*AI 编程工具大放异彩的地方。当你给 AI 编程工具一个指令时，它从不会对需要产生什么产生疑问，而且它通常很快就能弄清楚需要哪些语句。然后它以极快的速度输入这些语句。换句话说，AI 编程工具在最不是问题的地方运作得最好：当你知道需要做什么时，编写代码！ > 这绝不是试图贬低 AI 编程工具的天才之处。我仍然惊叹于 AI 编程工具生成复杂代码的速度，这些代码将算法、数据结构、库和 API 组合在一起以实现复杂服务。但它们本质上并不比我做得更好，只是更快。 但 AI 编程工具还不能做的是：弄清楚*什么*需要被构建，以及*哪些*功能和非功能需求是重要的关注点。 这里有一个例子：在过去的六个月里，我一直在为一个将操作系统镜像部署到 OpenAI GPU 机器集群的解决方案而工作。这是一个不平凡的问题，因为集群的规模、多样性和复杂性，以及我们还希望在继续服务 ChatGPT 和其他产品的同时进行部署。显然，我们使用的云提供商在处理虚拟机方面有不同的原语，以及在分组虚拟机和模板化配置方面有不同的数据模型，这使得创建一个在所有数据中心合作伙伴中都能良好运行的通用解决方案变得相当困难。 除此之外，NVIDIA 的 GPU 系列也有其独特性。例如，GB200 和 GB300（即[Blackwell](https://www.nvidia.com/en-us/data-center/technologies/blackwell-architecture/?ref=hubwiz.com)）域中的所有机器必须运行相同版本的 NVIDIA 驱动程序，这使得升级更加困难。在*这之上*，部署还有速度要求，因为我们的漏洞管理计划规定特定严重程度的已知漏洞需要在一定天数内得到解决。 对于这种形状的问题，几乎不可能（在大多数情况下也不可取）事先弄清所有需求，做出详细设计，然后让 Codex 工作来输入语句。因此，正如现在的标准做法一样，我们正在迭代地开发这个软件。我们的第一个解决方案忽略了 Blackwell 的要求，只针对 Azure 中的机器。我们让 Codex 根据我们所知道的来开发这个版本，运行它产生的任何东西，然后了解现实的种种特殊性。所以我们迭代了：运行 Codex 给我们的最新版本，观察发生了什么，从中学习，然后用增强的指令让 Codex 工作，告诉它我们*真正*想要什么，以及根据我们现在所知道和理解的，我们*真正*希望事情如何运作。一旦 Codex 准备好，我们重复这个循环。 在这个项目中，Codex 在软件开发的所有阶段都非常有帮助。在设计阶段，它通过告诉我们 Azure 规模集实际如何工作来帮助我们；在编码阶段，它输入了所有语句；在调试阶段，它分析日志并推理可能发生了什么，修复 bug 并适应我们不断变化的需求。使用 AI 编程工具的软件开发，归根结底就是与工具进行持续对话，逐步明确真正需要构建什么，并尝试各种解决方案路径。 问：好的，我明白了，但这为什么仍然很难？ 答：因为 AI 工具可以编写代码，但它们不承担后果。 AI 可以输入语句，但*你*必须决定什么重要并适当地引导工具。如果我告诉 Codex："嘿，给我写一个工具，用新操作系统重新镜像这个 GPU 集群中的所有节点"，它很有可能会给我写一个同时对所有机器执行此操作的工具，这显然*不是*我想要的。Codex 不知道我们关于金丝雀发布、增量部署、故障检测等方面的要求，所以*我*需要告诉它事情需要如何实现，然后*我*需要检查在所有 [57 种方式](https://en.wikipedia.org/wiki/Heinz%5F57?ref=hubwiz.com)中，它选择了适合我们环境的一种。这需要**知识、经验和判断力**。这些都不体现在模型中，或者即使体现了，如果没有适当的指令也不一定会被激活。 大多数真实的系统有不完全可见的上下文，比如未记录的不变量、奇怪的遗留假设、部署约束、部分迁移的 API、人们现在依赖的旧 bug，以及性能要求。这些大多没有写下来，因此超出了模型的范围。AI 编程工具在局部上下文中的代码生成方面非常出色，但在理解完整系统方面要弱得多。这些整体上下文的片段往往是模糊的、表达不清楚的、不一定被广泛认同的，或者可能只是半成熟的。这是软件工程中*困难*的部分，而这是 AI 编程工具还做不到的，所以这就是*你*上场的地方。 除此之外，AI 工具在"品味"方面也不行。它们不一定知道什么时候该抽象，什么时候不该抽象，什么时候应该保持无聊的简单，什么时候一个解决方案过于聪明，或者什么时候需要给任何人类审查者添加注释（假设人类[代码审查仍然必要](https://josvisser.substack.com/p/does-code-review-still-matter)）。AI 提供*一个*解决方案，但人类工程师仍然需要根据他们对整个上下文的了解来决定它是否是一个*好的*解决方案。 当然，模型和工具一直在变得更好，所以明天的 AI 编程工具是否会在这些方面好得多，从而真正使整个软件开发过程变得更容易，这是一个开放的问题。但我不这么认为，原因如下：使软件开发变得困难的东西，恰恰是初级和资深工程师之间的差异所在。 在过去的二十年左右里，我一直说，把我与初级工程师区分开的*不是*我能更好地编写代码。恰恰相反：一个刚毕业的 L3 或 L4 在算法方面可能比我更好，毕竟我已经有很多年没有上过算法课了。当我在谷歌面试时，我被问到[快速排序](https://en.wikipedia.org/wiki/Quicksort?ref=hubwiz.com)的运行时间，而那时我已经大概 20 年没有想过这个问题了，尽管我一直用大多数编程语言附带的方便库函数来排序很多东西。将资深工程师与初级工程师区分开来的是我在这篇文章后半部分一直在谈论的东西：上下文知识、更深层次地理解需求、品味和经验。这些是困难的部分，而这些是 AI 还做不到的部分。 所有这些让我思考这对初级工程师的就业机会会产生什么影响。如果这也让你思考了，那你运气不错，因为那将是下周三智慧的主题…… 🙂 --- 原文链接：[Coding with AI tools is still hard!](https://josvisser.substack.com/p/coding-with-ai-tools-is-still-hard) 汇智网翻译整理，转载请标明出处