导读：人工智能正在迅速改变软件的构建、测试和维护方式，但并非以“人工智能取代开发人员”这种简单粗暴、引人注目的方式。

在过去的几年里，我亲眼见证了人工智能如何开始改变人们的工作方式。这并非一场翻天覆地的变革，也不是无关紧要的炒作——而是一种颇为微妙的变化。

对一些软件工程师来说，人工智能正悄然成为日常工程工具包的一部分，出现在代码助手、测试生成工具、基础设施管理，甚至项目规划中。在我的工作以及与其他工程师的交流中，我注意到了这种转变。

这是好事还是坏事呢？

作为一名经验丰富的软件工程师，有人问我使用人工智能的体验。和你们中的许多人一样，人工智能正开始对我的日常工作和处理任务的方式产生影响。

先来简单介绍一下我的背景。

在大学时我学习的是化学和物理。短暂从事化学相关工作后，我转行做了程序员，主要在Windows操作系统上使用Visual Basic、Delphi、C/C++和C#等语言进行编程。偶尔也会接触Python，闲暇时喜欢听音乐和玩桌游。

上世纪90年代我刚入行做软件工程师的时候，搜索引擎还没有出现，信息检索非常困难。那时候，工程师们通常都是通过传统途径学习技能，比如参加面授课程、阅读书籍、浏览新闻组（你还记得吗？）、与其他工程师交流，以及亲身实践编写代码，后者我认为是最最重要的。

由于我大学时并没有主修“计算机科学”，直到后来攻读硕士学位才开始接触这门学科，所以我经常接触到新的理念，比如数据结构和编程语言、新的问题以及解决问题的新方法。

其中一个难忘的经历是，一位经验丰富的工程师向我介绍了循环列表——一种列表大小固定的数据结构，它的插入点会在一个循环中移动——当插入点到达列表末尾时，就循环回到起始位置。听起来很简单，但理解起来仍要花费心思，虽然这种东西并非每天都能接触到。

就编程和人工智能而言，我需要先说明，本人只是个轻度用户。

我主要依赖经验、肌肉记忆和传统搜索方式。我非常注重编写稳健、简洁且防御性强的代码，这些代码是我多年反复试验积累起来的成果。我的目标是编写易于他人阅读和维护的代码，以便在未来多年都能得到有效利用。虽然我并没有完全怀疑人工智能，但我确定认为，人工智能提供的结果往往参差不齐，不完整，而且就平均而言，它并不能节省时间。

当然，我也会使用人工智能工具（主要是 CoPilot）。对于简单直接的问题，它们给出的结果质量通常都非常好。而且，它们以对话式的风格总结技术和非技术主题，这意味着人工智能工具往往能提供比传统搜索引擎更好的答案。这两方面都是人工智能的优势所在。

不过，它们给出的代码有时比较粗糙，甚至是完全错误的。相信最狂热的人工智能爱好者也一定会同意，现在还不能把人完全排除在外。

根据人工智能的使用情况，我将开发者分为以下三类：

·第一组：轻度使用人工智能或完全不使用人工智能（言下之意是，这一组人错过了一场类似于 90 年代的互联网革命；爱好者们认为，随着技术的更迭和淘汰，这一组人最终会变得无关紧要；为了好玩，我们姑且称这一组人为“卢德分子”。）

·第二组：适量使用人工智能（这意味着这个群体，也就是人工智能爱好者自然所属的群体，既老练又高效——他们会审查人工智能的输出“以确保高质量”，同时“提高生产力”；我们称这个群体为“幸运儿”）。

·第三组：过度或盲目地使用人工智能（言下之意是，这一组人很懒惰，或者为了追求速度而制造了维护和安全方面的雷区；我们姑且称他们为“疯子”）。

这些分类假设大致上正确，作为人工智能的轻度用户，我想我应该属于第 1 组和第 2 组之间。

即便如此，我的怀疑还涉及其他问题：

·现代集成开发环境（IDE）都内置了人工智能工具。开发者已经无处可逃，它们如同以前的Office小助手一般，时刻注视着开发者。如果人工智能提供的大多是合理但通用的解决方案，那么新开发者还能认真钻研难题，学习如何打造稳健、高效且富有创意的解决方案吗？即便答案并非完全否定，这仍然令人担忧。

·人工智能工具总是自信满满地给出答案。即使是糟糕或不完整的答案，也不容置疑！稍有人生阅历的人都知道，即使是最好的计划有时也会失败，生活从来都不是那么确定。也许只有我这么觉得，但人工智能工具这种盲目自信的态度实在令人恼火……令人担忧。

·多年来，权力一直在少数几家公司（主要是美国公司，例如微软和谷歌）手中不断积累。我们都曾为了诸如Gmail之类的“免费”工具而放弃自己的数据，甚至逐渐丧失了自由。人工智能公司通过攫取和吸收人类创造力总产出的相当一部分，肆意践踏人类隐私和版权。如果人工智能公司大肆宣传的承诺属实，我们或许已经错过了掌控自身未来、摆脱科技巨头控制的最佳时机。

·微软最近对Windows 11系统“漏洞”的修补，以及强制更新的普遍存在，都是令人担忧的趋势。这些漏洞允许用户创建本地账户。

或许读完这篇文章后，爱好者们会把我重新归入上面的第一组。

为了更生动地展现人工智能的魅力，以下是我近期的一些个人经历：

我曾就职于一家生产自动化设备的公司。其主要产品及其大部分代码库已存在多年，主要面向 Windows 平台。随着硬件、操作系统和开发工具的更新换代，该产品自然也进行了相应的现代化改造。其主要应用程序的前端使用 Delphi 语言，硬件和外设控制则使用 C/C++ 语言。

它的应用场景非常单一，用户不应离开软件提供的环境。我们需要一种方法来显示 PDF 用户手册。有很多方案可供选择，例如托管一个简单的 PDF 阅读器（或许可以用 C# 编写，并使用类似 WebBrowser 的组件），使用系统自带的、支持 PDF 功能的浏览器（例如 Microsoft Edge），或者依赖于 Windows 注册表中与 PDF 关联的应用程序。

所以我问 CoPilot 如何在 Delphi 中从注册表读取与 PDF 文件关联的应用程序。CoPilot 自信地建议我：

HKCU\Software\Classes\.pdf

这段代码在我的 Delphi 版本中无法编译，但真正的原因是缺少一些细节。最终，我在 StackOverflow 上找到了一个问题答案，其中涵盖了更多细节。

The open with associations are all stored inHKEY_CLASSES_ROOT.This is a special registry hive that combines the local user's associations inHKEY_CURRENT_USER\Software\Classes with the system's associations inHKEY_LOCAL_MACHINE\Software\Classes.

对于感兴趣的用户来说，一个问题是关联的应用程序可能会被“用户首选项”覆盖，例如 Windows 资源管理器中的“打开方式”更改。

人工智能并未给出任何提示，在 C#（比 Delphi 更常用）中也是如此。

有些人会耸耸肩——毕竟，这正是人类应该审核和测试人工智能建议的原因。但这至少表明盲目听从人工智能的局限性。如果我轻信了它最初自信的回答，快速测试可能就无法发现其中的细微问题。代码很可能就此发布，并被应用到工厂中。

另一个积极的例子，是我提出的关于如何在 C# WebBrowser 组件中加载 URI 时抑制警告的问题。人工智能指出了控件的“ScriptErrorsSuppressed”属性，解决了我的问题。这正是人工智能擅长的简单问题类型。

我和一位经验丰富的测试经理交流。我问他使用人工智能的经验，尤其是在编写单元测试方面时，他谈到结果并不理想。根据他的经验，通常需要反复修改提示语（这种技能有时被称为“提示工程”或“查询构建”），才能得到可用的答案。而要将这些代码集成到他们（规模庞大的）代码库中，则需要完全重写这些提示语。他认为人工智能完全是在浪费时间，尤其对于经验丰富的测试人员而言更是如此。

这里，我要说明的是需要考虑具体情况：对于全新的项目，将 AI 代码复制粘贴到（不断增长的）代码库中可能很有效。但对于规模更大、更复杂的实际代码库，则需要更加谨慎。通常情况下，AI 建议的代码难以直接使用，甚至完全错误。

总而言之，我对人工智能的体验喜忧参半。向人工智能询问一些简单直接的问题，然后将这些建议整合到现有应用程序中，有时确实有效。但尝试将代码整合到一个需要长期维护的代码库中则风险很大。

我们当中有些人从小就生活在智能手机无处不在的世界里。许多人可能难以想象没有智能手机的世界。我们越来越被这些设备束缚（有些人甚至会说是奴役），需要用它们来支付银行账单、取票等等……而且需要用到的东西还在不断增加。有多少人能在使用百度地图（或类似地图）多年之后，还能自信地使用纸质地图呢？当我们依赖的服务被付费表单挡住，或者干脆彻底停止运行时，又会发生什么呢？

我担心人工智能领域也会出现同样的问题。当然，偶尔使用这些工具来学习和提高效率是完全可以的。但也要意识到其中的风险。在你使用智能手机应用或人工智能工具之前，最好先尝试自己解决问题。

保持掌控，独立思考——你今天依赖的工具，明天可能就不存在了。

作者：行动的大雄