导读：大多数工程师使用人工智能是为了加快产品开发速度。而那些有品位的工程师则用它来提升产品质量。

我见过有人在发布时完全由人工智能生成的技术文档。他们提取一些数据，将其放入提示语输入框，然后让模型自动生成文档。他们没有调查，没有判断，没有迭代，只是简单地将数据转换成自然语言。

我在工作的间隙时看到了这份文件。

表面上看，它结构完整，语句还算流畅。但仔细阅读后，我感觉有些不对劲。论证肤浅，建议空泛，本应困难的部分反而写得最简单。

好像缺少了点什么，我一直在思考那个感受。

我和一群优秀的工程师共事，我们都感受到同样的压力，因此要借助人工智能工具更快地交付产品。但输出质量的关键不在于使用了哪种人工智能，而在于判断力。当我看到别人的作品时，我也开始在自己的作品中看到这一点：我匆忙提交的拉取请求、我点头附和的设计评审、以及那些让我们所有人都措手不及的生产事故。

这是大多数人对人工智能编程的误解所在。

实际上，人工智能的糟糕表现并非人工智能本身的问题，而是审美问题。模型的确在执行指令，问题在于按下回车键之前，负责编写代码的人是否清楚“正确”的定义。

在本文中，你将了解到：

• 软件工程中开发者的品味是什么？为什么它比过去十年中的任何时候都更加重要？

• 人工智能生成的粗糙代码如何在真实代码库中体现？以及品味错误究竟是什么样子？

• 为什么擅长使用人工智能的高级工程师品味更好，而不是打字速度更快？

• 如何培养一名开发者作为人工智能工具实践者的品味，并使其每天都能接触到人工智能工具

• 人工智能辅助编程的兴起对你的职业生涯意味着什么？哪些人将会被时代抛弃？

我们已经意识到的AI缺陷问题

如果你现在从事软件开发，你肯定见过人工智能领域的粗制滥造之作。

这类代码就像是能编译通过测试的拉取请求，但当你真正阅读时却发现它根本毫无意义。它就像是解决了一个根本没人问过的问题的函数。它就像是新建了一个文件，重复了三个文件夹之外已经存在的逻辑。

糟糕的代码并非指有问题的代码。这就是诀窍所在。有问题的代码会被发现。糟糕的代码是指今天运行正常，却会在接下来的六个月里悄无声息地让你的生活变得更糟的代码。它是那些没人会记得添加的额外抽象层。它是断言错误结果的测试。它是在测试环境中运行良好，却在生产环境中删除了数据的迁移，因为当时大家只关心运行正常的流程。

我记得曾经审查过一个变更，其中人工智能通过复制代码库其他地方的模式，将身份验证集成到了一个服务中。

这个模式是错误的。对其他服务来说没问题，但对我们的服务来说却不行。作者之所以相信输出结果，是因为它看起来和代码库的其他部分一样。没有人停下来思考一下，代码库的其他部分是否真的是正确的参考。这简直是粗制滥造。这是由某人（无论是人还是人工智能）编写的，但编写者却缺乏思考。

情况恶化的原因很简单。人工智能工具提高了代码编写速度的下限，却没有降低编写代码所需的思考深度。恰恰相反，由于人工智能的出现，企业面临着更大的交付压力，导致情况更加糟糕。大多数工程师并没有因此而改变他们的思维方式。他们仍然在敲代码，只不过现在输入的是提示信息。模型开始替他们敲代码，而思考的过程却被遗忘了。

开发者的品味究竟是什么？

“软件品味”，实际上它指的就是：你在编写第一行代码之前所做出的判断。

我来解释一下一直在思考的定义。

开发者的品味是指在编写任何一行代码之前，就能判断什么是正确的，并有毅力去追求它。仅此而已。它与美观无关。它与偏好使用制表符而不是空格无关。它与吹毛求疵无关。它与代码审查时差异的美观程度无关。

区分品味和技能至关重要。品味是你面对问题时所具备的特质，而技能则是你理解问题后如何运用它。很多工程师拥有技能却缺乏品味。他们可以写出你描述的任何东西，但却无法判断你描述的东西是否值得实现。他们会死守规范，最终交付的却是完全错误的解决方案，而且按时交付，测试也全部覆盖。这种情况现在比比皆是。

品味亦并非速度。

速度指的是从构思到最终实现的转化速度，而品味则体现在构思本身是否值得最终实现。我曾与一些工程师共事，他们的产品交付量只有周围人的一半，却推动业务发展了两倍，因为他们交付的每一个产品都直指关键所在。他们会拒绝那些无法提升指标的工作，会质疑那些不合理的规格说明，会提出其他人忙得没空问的问题。正因如此，当这些工程师提出疑虑时，我们应该认真倾听，而不是因为他们拖慢了项目进度就置之不理。

我能想到描述“品味”的最简单方法是这样的：当你看到一段代码时，在你能够解释清楚之前，你会先感受到某种东西。这种感觉是你曾经搞砸过的每一个系统、凌晨两点追查过的每一个bug、以及眼睁睁看着在真实流量下腐朽的每一个设计方案的压缩记忆。人工智能可以近似地描绘出表面的模式，但它无法近似地描绘出那种痛楚。正是这种痛楚告诉你，这条捷径一个月后会让你付出多少代价；它告诉你，这种抽象还为时过早；它告诉你，这个测试测试错了层面。品味是你的伤疤，是你的直觉。人工智能没有这种能力。

人工智能工具在实践中如何呈现味觉

上个月我审核了一个变更，其中模型向一个服务模型中添加了一些新类型。变更编译通过了。这些类型单独来看是正确的。问题在于这些类型应该放在不同的文件中，因为该服务有两个独立的 API 接口，而这两个接口不应该共享定义。如果你不了解架构，你很可能会批准这个变更。我之所以能发现这个问题，是因为我参与了拆分过程，并且知道为什么需要设置这样的边界。

这就是实践中的品味，并非某种神奇的模式匹配，而是记住事物为何如此。这需要有人解读变化，亲历事件发生，完整地梳理过整个流程图，并保留了记录。模型可以查看文件，但无法了解历史。如果你不提供历史信息，就没人会了解，围栏也会在无人询问其原因的情况下被移动。即使你将历史信息输入人工智能，也会面临上下文信息不足的问题。你需要与人工智能协同工作才能获得最佳效果。

还有一次。

我开始开发一个新功能，结果自己差点就直接粘贴了一段AI生成的代码块，而没有打开任何其他文件。我停了下来，关掉编辑器，像给别人解释说明一样，把这个功能从头到尾完整地写下来。然后，我打开现有的集成测试，从我想要的外部行为入手，逐步深入到需要修改的代码。直到这时，我才回到AI那里，给它一个提示。第二次我写的提示语句比第一次长了五倍，但生成的代码修改量却只有第一次的四分之一。这就是提示语句的质量。答案质量取决于上下文的质量。

我一直注意着这个模式。有品味的工程师会利用人工智能不断迭代，最终得到他们已经认定为正确的结果。而没有品味的工程师则会利用人工智能猜测“正确”的模样，然后发布他们猜测的那个版本。这两种做法截然不同。从表面上看，它们似乎没什么区别。但一年下来，它们最终生成的代码库却完全不同。

很多非技术人员都忽略了这一点。人工智能能为我们所有人创造价值，但如果你具备一定的鉴赏力，它能创造更大的价值：

• 拥有人工智能技术的非技术人员比没有人工智能技术的非技术人员编写出更好的代码。

• 掌握人工智能技术的技术人员比不掌握人工智能技术的技术人员编写出更好的代码。

• 精通人工智能的技术人员比不精通人工智能的技术人员编写出更好的代码。

味觉失误是什么样子的

这些并非程序错误，而是代码中一些不易察觉的错误，虽然现在运行正常，但日后维护起来会更加困难。

以下是我经常遇到的五种错误。

1）将人工智能的输出视为最终结果。比如你让模型编写一个函数，它编写了一个函数，你粘贴进去，运行测试，测试通过，然后继续下一步。你忽略了阅读代码并思考这是否是你最终会写出来的代码这一步。不是逐字逐句地比较，而是要问自己代码是否正确。如果你从未问过这个问题，你就不是在使用人工智能，而是被人工智能所利用。人工智能的输出应该是初稿。“直觉式编码”（不加审查地接受模型生成的所有内容）正是这种模式的体现。

2）这是从次要来源而非主要来源复制。模型是从其他人的代码中学习得到的。其他人的代码不是规范。规范才是规范。当我看到工程师通过匹配同一个代码库中类似文件来实现某些功能时，我会感到不安。如果那个类似文件也是由模型生成的，我会更加不安。真正的原始数据源肯定存在。文档。RFC。设计评审。找到它。阅读它。在模型中引用它。然后再回来。

3）跳过问题分解。这是一个经典错误，而人工智能让情况变得更糟。你接到一个任务，其任务包含三个部分。你让模型同时处理这三个部分。它给出的答案看似合理，但其中一个部分却存在你无法察觉的错误，因为你从未将这三个部分分开列出来。明智之举是停止处理，将问题分解成你可以推理的部分。在脑海中预先确定每个部分的答案。然后让模型来处理这些部分。你仍然需要掌控人工智能工具的思考和执行过程。

4）只发布正常运行的情况就完事了。我见过太多人工智能生成的代码，它们只处理一切正常的情况，却对不正常的情况只字不提。没有错误处理，没有边界情况，也没有针对那些棘手问题的测试。如果你要求，模型当然可以做到这些。工程师之所以没有要求，是因为他们根本没考虑过。品味是一种无需询问就能让你思考的本能。只有当你思考问题时，才能发现那些边界情况。

5）让代码运行起来，而不是让它正确，这是我跟团队约定的五五开原则。让代码运行起来只是成功的一半。另一半则是要在六个月内让代码正确、简洁、精简、易于审查、可发布且易于理解。人工智能在前半部分非常有效。它在后半部分也同样有效，但前提是必须掌控全局，人不能推卸责任。

如何培养开发者的品味

我将分享一些对我有效的方法。这些方法也都不花哨，你可以选择最适合自己的。

1）从外向内思考。在编写任何代码之前，先编写一个测试，从外部描述该功能应该做什么。或者至少用人类可理解的语言来描述。这不是单元测试，而是集成测试，它模拟用户、其他服务或 API 调用者的角色。这迫使你在开始之前就确定“完成”的含义。它还能为你提供一个真值函数，以便稍后用于检验 AI 的输出。从外向内思考是我所知的最有效的提升效率的方法。

2）尽量保持提交内容小且单一。一次提交，一个职责。这听起来像是一种风格偏好，但并非如此。小的提交会迫使你思考每次更改的真正目的，从而迫使你对更改本身形成观点，而这正是品味的体现。如果你的差异代码有 800 行，却只涉及三个问题，那么你已经把决定权拱手让给了下一个审查它的人。

3）在分配编码之前，先在代码审查界面中阅读一遍自己的代码。假设这段代码不是你写的，而是一位初级工程师提交给你审批。你会问他/她什么问题？你会留下什么评论？我希望更多工程师都能这样做。这也是发现自己代码审查中人工智能缺陷的最佳方法，因为当你不再是作者而是读者时，人工智能缺陷的解读方式截然不同。

4）查阅原始资料、文档、标准以及库所依据的论文。包括代码库中的 ADR。当你不懂的时候，不要问模型它自身的训练知识，而要问原始资料。

5）自己定义框架，让AI填充细节。我称之为“数据结构驱动开发”。你必须考虑数据流。我决定类型、函数签名、模块边界和名称。然后让模型实现具体功能。这颠覆了默认的AI工作流程。默认流程是模型勾勒轮廓，你负责完善细节。更好的模式是你勾勒轮廓，模型填充细节。

6）多审阅代码，多写代码。阅读他人的代码，尤其是那些你认为“糟糕”的代码，能让你培养出辨别错误的能力。如果你只看自己的代码，你的标准只能和自己比较。如果你看遍所有人的代码，你的标准就能和整个代码库进行比较。你会明白自己的代码并非最佳，但也绝非最差。这便是我所知的最接近“品味”的捷径。

软件工程师的品味对职业生涯的影响

人工智能并不会像新闻标题所说的那样抢走你的饭碗，它只是取代了你原本就能自动完成的那部分工作。如果那部分工作占据了你工作的大部分，那你就麻烦了。但如果你的工作主要是判断，那你现在就拥有了更强大的能力，可以完成更多的工作。

缺乏品味的工程师正在沦为执行者。他们会交付大量代码，他们看起来很忙，也能完成冲刺指标。但随着时间的推移，他们会被视为可替代的资源，因为他们所做的工作，任何人只要有提示框就能做到。因为打字的市场价格正在迅速下降，但知道该写什么的市场价格却并未下降。

有品位的工程师正在成为统筹者。他们界定问题，设计方案，审核结果，并决定哪些问题需要提交公关稿。他们以清晰的目标和坚定的信念运用人工智能。随着工具的不断改进，他们的影响力也随之提升，因为工具能够更快地放大他们的判断力。

我真心认为，未来五年对第一组人来说会很艰难，而对第二组来说则会精彩纷呈。区分他们的关键不在于天赋、资历或就职公司，而在于他们是否选择专注于培养自己的品味，还是假装自己天生就具备这种品味。

你可以不断地训练它，只需要现在开始。

作者：洛逸