技术是一个由设置和依赖项组成的迷宫。人工智能有强大的方法来应对这种复杂性，但这是否解决了根本问题？
译自 The Configuration Crisis and Developer Dependency on AI，作者 Jon Udell。
我们一直说计算机科学中有三个难题；或者如果你喜欢“差一错误”的笑话，那就是两个。但是命名和缓存失效与当今真正的难题相比相形见绌：配置。随着我们的IT基础设施变得越来越模块化、分层和互联，我们处理着无数的可配置部分——每一个部分都由密集的设置丛林控制。我们所有的计算机——无论是在我们的口袋里、桌子上还是云端——都拥有令人眼花缭乱的组件迷宫，需要发现和调整设置，无论是单独的还是组合的。我们将这些计算机连接起来，形成一个由更多设置控制的难以理解的复杂网络。
如果你的日常工作是在IT行业，你也是朋友和家人的技术支持提供者，而这项工作也越来越不容易了。上个月，当我妻子问到她手机上奇怪的短信行为时，我有了那种你可能熟悉的沉重感觉。果然，它变成了一个耗时数小时的令人抓狂的折磨。在那之前，我一直幸福地不知道RCS（富通信服务）的整个惨状。我认为发生的事情是谷歌说服我的妻子在她的安卓手机上安装其支持RCS的Messages应用程序，此外还有已经存在的原生三星Messages应用程序。近年来我一直是iPhone用户，所以我对安卓的通用配置不太熟悉，更不用说当两个已安装的短信应用程序相互冲突时出现的特定病理了。
将无辜的人置于互操作地狱的行业恶作剧让我怒火中烧。
我将省去细节，说实话，我宁愿忘记。将无辜的人置于互操作地狱的行业恶作剧让我怒火中烧。普通人如何应对这种疯狂？我的妻子喜欢说，没有我解救她，她会迷路的。但是现在，反过来，没有AI帮助我应对复杂性，我也会迷路。我越来越不懂技术了，就像我妻子仍然想象的那样。相反，我知道如何驾驭AI系统，这些系统（不可靠且不完美地！）体现了技术的知识。
与此同时，在我的职业生活中，同样的事情正在发生。我的任务是记录如何在三大云平台上安装和配置企业软件产品。我已经接触过AWS、GCP和Azure的表面，但我并没有深入或定期使用它们。现在，作为安装的先决条件，我需要学习并解释（除其他事项外）如何在所有三个平台上创建自定义角色。因此，有三个GUI控制台在运行，每个控制台都有自己复杂的层次，以及三个相应的CLI，每个CLI都有自己的一组命令和参数。
几年前，仅仅弄清楚其中一个云平台就已经是一个挑战了，更不用说所有三个了。信息不会缺乏——这些都是已经被许多人以多种方式标记过的道路。但是魔鬼总是在细节中。如果我在UX流程的这个特定位置，并且在屏幕上看到这个特定视图，我的下一步是什么？我点击哪里？文档和在线讨论通常不会传达你在那一刻所需的细粒度情境感知。一位了解情况的同事看着你的肩膀可以做到，但这个人的注意力是一种稀缺而宝贵的资源。AI体现了许多这样的人的知识：同样，不可靠且不完美，但仍然足以提供前所未有的按需帮助。
AI以一种有用的方式是健忘的。每次你开始新的聊天时都会发生重置，这有效地抵消了人类掩盖隐性知识的倾向。
我之前提到过的一些策略值得重复。一个是使用屏幕截图，它现在是综合知识语料库中一个强大的索引。与所有形式的网络软件一样，云平台的GUI控制台呈现出杂乱无章的UX习惯用法。在不同平台上概念上相同的操作，通常会使用非常不同的功能来表达。AI是模式识别器，可以帮助我们看到和使用共同的底层模式。
人们很难描述如何使用体现这些模式的UX affordances，因为一旦学会了，它们就会退化为潜意识的认知。最初看起来难以理解的工作流程变得如此显而易见，以至于你忘记了它曾经并非如此，你失去了初学者的心态，而这种心态能够帮助你帮助其他初学者。但AI在某种有用的程度上是健忘的。每次你开始新的聊天时都会发生重置，这有效地抵消了人类将隐性知识埋没的倾向。
另一个持续带来回报的策略是大型语言模型最佳实践中的规则#4：向几个不同的LLM提出相同的问题。你必须始终保持你的BS检测器高速运转，而一致性并不能保证准确性，但模型的馈送和训练方式的差异有助于减轻单一使用易受攻击的错误。
关于系统复杂性的潜移默化的增长，我们就像在慢慢煮沸的水中的青蛙。例如，就在今天，我发现自己处于一种新情况。我正在使用一个从容器注册表下载模块的工具。这些模块不是容器镜像；它们只是使用相同的基础设施（OCI（开放容器接口）分发机制）管理的二进制文件。通常情况下，下载是透明的，我甚至没有意识到它正在发生。但是今天，在使用未发布的私有模块时，我遇到了以前从未见过的身份验证错误。注册表是ghcr.io，因此需要一种GitHub身份验证。但是尽管拥有具有必要范围（read:package）的个人访问令牌，我还是不断遇到错误。在与ChatGPT的对话中，我们找到了违反直觉的解决方案。即使工具本身不使用docker，也必须执行docker login才能将GitHub令牌放入我无数不断增长的配置文件中的另一个配置文件中，这是我从未知道的一个配置文件：~/.docker/config.json。
配置复杂性的爆炸式增长影响了我们人类跟踪所有这些内容并有效管理系统的能力。
我们都经历过这些依赖关系的级联，这些依赖关系增加了我们互连系统中活动部件的数量，并增加了配置开销。现在我们发现自己处于一种奇怪的境地。配置复杂性的爆炸式增长影响了我们人类跟踪所有这些内容并有效管理系统的能力。但我们拥有一批具有超能力的新型助手来帮助我们做到这一点。我很感激他们，也不想回到过去。但我确实担心不正当的激励。当我们可以将对系统的理解外包时，为什么要设计易于理解的系统呢？
Ward Cunningham曾经向我展示了一个想法的实现，他将其归功于Brian Marick，称为可见的工作。他们都设想了一种能够按需揭示其内部工作原理的自描述系统。应用于我的docker相关示例，这意味着当系统说：
“响应状态代码401：未授权：需要身份验证。”
我可以问：
“为什么？怎么做？”
系统的设计目的是知道这个问题的答案。它将理解它自己的依赖关系，并指导我完成解决这些依赖关系的过程。除非你把它写下来，否则你永远不会真正理解它。“为什么？”和“怎么做？”如果配置的编码从一开始就编码在系统的DNA中，那么它们将更难构建，但更容易使用和维护。
当然，这是一个很难推销的东西，而且随着AI提高我们反向工程“为什么”和“怎么做”的能力，它变得更加困难。也许，即使它们本身并不可解释，AI也可以帮助我们设计可解释的系统。但我并不乐观。感觉我们正在走一条路，让系统对人类来说越来越难配置，我们越来越依赖超人的智慧来为我们做到这一点。