从编码者到策展人

# André Staltz — 从编码者到策展人 来源：https://staltz.com/from-coder-to-curator 去年我对大语言模型生成的代码持反对态度。坦率地说，这感觉适得其反。在年中 Opus 4 到来之前，模型还很弱，代码质量低且有 bug，通过模型修复也很令人沮丧，因为它常常无法理解我的指示。手动修复比通过聊天等待更快。 到了去年年底，我不得不修复输出的情况变少了。时间快进到今天，在大多数情况下我不再需要修复 AI 的拉取请求。这种变化发生得非常快。 现在关于 AI 编码的讨论很多，可以肯定它已经进入了大多数生产软件的公司。各地的开发者都能看到没有回头路可走。如果你在 2024 年还在手工编码，那可能就是你作为专业人士最后一年这么做了。未来，一切都会不同。 对一些人来说，这令人担忧或怀旧。感觉有些不对劲，你怀念过去的工作方式，或者担心你的工作会变成什么样。编写软件是许多工程师工作的核心部分。当这个核心被拿走时，还剩下什么？ 我想分享一些可能给你带来希望的想法。这篇文章特别献给那些有点困惑或恐惧的年轻开发者。 ## 灯神 我感到充满活力。我终于可以重拾那些我从未有时间做的项目，并且承担起我从未想过自己能做到的事。更新这个博客就是其中一个项目。在我做这些副项目时，我开始看到相同的模式： **AI 负责构建。我是策展人。** AI 最好的比喻不是有感知的机器人，而是神灯里的灯神。它有魔法般的几乎无所不能的能力，但**从设计上就服从**。像 Anthropic 和 OpenAI 这样的公司有动力构建完全按照用户要求行事的智能体。灯神既能实现你的好想法，也能实现你平庸的想法，而且它不会挡你的路。 这意味着 AI 工具把质量控制权交给了你。不是因为它们不能生产高质量的软件，而是因为人们想要不同的东西。既然现在各种东西都可以轻松构建，那么困难就不再是构建本身。 所以真正的问题是什么应该被构建？**你想要什么？**而更重要的、决定我们许多人职业生涯的问题是：“什么值得构建？” ## 角色的打包 我母亲曾经为程序员做过打字员。她不懂她在打什么。她从别人那里拿到代码，然后输入到大型机中。 那份工作消失了，因为打字被整合进了程序员的责任中。程序员应该设计算法，同时也把它们打出来。我们不再需要一个人设计程序，另一个人按键盘。 现在编码者的角色正在消失，我认为这完全可以。我们正在把这个责任打包到另一个角色中。那个角色可能是产品设计师、解决方案架构师、云架构师、创始人，或者还没有通用名称的角色。我们不再需要架构师和构建者之间有如此清晰的区分，因为构建可以打包进架构师的工具里。 澄清一下，理解代码仍然很重要，而且将来也会如此。今天那些从未学过编码的管理者和设计师终于有机会独立地将他们的想法赋予生命。然而，如果他们不做好一件事：在内部理解和塑造代码和架构，他们不可避免地会在软件质量上妥协。 质量是复杂的。我记得我曾工作过的一家咨询公司的 CEO 说过，质量是许多因素的组合。软件速度快还不够，还必须用户友好、可靠、正确并且在内部可维护。改进其中一项甚至可能使另一项变得更糟。没有一个单一的基准告诉灯神“把它做好”。 ## 质量势在必行 现在，2026 年，**我把我的工作看作是尽可能用多的 AI 标记和尽可能多的质量来填充我的软件**。 为什么质量现在成了势在必行？因为低质量的软件任何人都能构建。如果我所做的只是将用户需求复制粘贴到 LLM 提示中，那么我真的没有增加价值，也就没有工作留给我了。 所以我把思考转向了：我怎样才能让它*真正好*？ 而且我相信我们也有责任在人们表达的需求和被构建的软件之间增加价值。如果你只是把人们所说的需求复制粘贴到 AI 里，你得不到好的软件。你可能短期解决了局部问题，但在过程中很容易在其他地方增加混乱，呈现错误信息，或者过分强调一些不相关的东西。 程序员一直倾向于修复他们自己遇到的问题。我们抱怨 IDE 里的小麻烦、最喜欢的终端 shell、代码语法，或者让某件事快几毫秒。这些问题是存在的，但从大局来看它们根本不重要。我们职业的真正价值在于修复*其他人*遇到的问题，并提供出色的用户体验、性能和可靠性。 ## 在实践中 当然你不能只让 AI 简单地把它做高质量。在提示之前，做一点研究。做那件事的最佳方式是什么？如果你在构建 UI，研究解决相同问题的其他界面。找到存在的最佳示例，试用它们，注意它们的细节，理解它们为什么有效。然后你才准备好去提示。 一旦你得到结果，不要照单全收。观察细节，质疑它们。从完全不同的角度去想象整个东西，然后列出一系列改动。 我认为 2026 年编写软件最大的危险之一就是习惯于 LLM 给你的结果。你对软件的第一印象是宝贵的。它们揭示了所有需要后续工作的小 bug 和怪异之处。过一段时间后你开始绕过它们而不注意，坏行为就变成了常态。质量很棘手，因为它存在于许多细节之中。 内部也是同样的道理。以怀疑的态度阅读源代码。问为什么某个变量叫那个名字，为什么选择某个依赖，或者为什么某个模块知道另一个模块。最近一个 LLM 在我的项目里把某个东西命名为“apron”。我从未在编程中见过这种命名。质疑之后，我意识到那是个相当愚蠢的名字。 有时 AI 听起来比你聪明，人们通常会屈服于更聪明的人。和 AI 相处时也应该有同样的动力。不要让它超过你。努力了解它在做什么以及为什么，这样你才能保持在它之上。幸运的是现在我们也有学习工具，毫不奇怪它们也是由 AI 驱动的。如果你不知道如何用 AI 学习，只需问 AI 你该怎么用它学习。 ## 该学什么 这不是一个详尽或最终的列表。只是我个人对哪些事情变得更重要的看法。 - **发现质量的眼睛。**熟悉现有的最好的软件，也了解最差的。批判地思考，关注细节。阅读关于好的例子是如何构建的。如果你不知道质量长什么样，你就无法策划出有质量的东西。 - **清晰沟通。**和人们交谈时需要这个，和 AI 交谈时也需要。当用户要求功能时，退一步听他们的问题，而不是他们的要求。[五个为什么](https://en.wikipedia.org/wiki/Five_whys)可能会有所帮助。写博客可能有所帮助。在会议或 meetup 上做演讲可能有所帮助。读好书可能有所帮助。如果英语不是你的母语，学好英语，因为大多数软件世界和大多数 LLM 训练材料都使用它。 - **优先级排序。**我很感激我当过几次创始人，因为那和当开发者非常不同。我注意到，我所认识的大多数开发者可能非常不擅长优先级排序。一旦你需要照顾软件业务的方方面面，你就会看到什么对你谋生和为用户创造价值真正重要。大部分时候，这和过去十年程序员抱怨的事情毫无关系。也许最好的学习方法就是在野外实践。试着仅仅为了乐趣做一个创业公司。这是有史以来最容易的时候。 - **胡扯检测。**AI 不是人，我很高兴它不是。它也没有感觉，所以你永远不应该觉得有约束不对它喊胡扯。我不知道是否有课程可以提升你的胡扯检测能力。与此同时，对 LLM 的输出保持探究、好奇、怀疑和质疑。并习惯于关闭 AI 的拉取请求或撤销智能体构建的东西。 - **设计师、产品经理、创始人和架构师技能。**如果你是一名软件工程师，现在正是学习这些其他角色所需技能的时候。让 LLM 指导你并推荐好书，然后读那些书。你将不可避免地需要这些技能的一些组合。 - **代码仍然重要。**定期查看代码。你不需要全部阅读，但要持续尝试理解发生了什么。让 LLM 重构东西，最好是作为自动化。学习哪些重构是好的，哪些是坏的。让它为一致性和可读性重命名变量，然后质疑那些重命名。制作架构图。四处探索，问为什么东西存在。微小的代码细节通常不会转化为对用户更好的软件，但代码的许多方面确实有影响。干净的内部结构和一致的命名让 LLM 不容易混淆。如果未来的模型足够聪明能理解糟糕的代码，那么至少*你*在读它时不会困惑。 ## 新工作 仍然会有人手工写代码，就像有人（全部）自己种食物一样。但这将不再定义主流职业。 这不是软件开发的终结。我们有比以往更多的软件要制作，包括以前在经济上不可能的项目。结束的是一种特定的责任安排，即一个人主要因为将决策翻译成代码而获得报酬。 灯神几乎可以构建任何东西。我们的工作是想要一些值得构建的东西，并且足够在意去把它真正做好。