我们都知道传统的难题：缓存失效、命名、越界错误。配置是新的——甚至更令人头疼的——难题。
译自 How LLMs Guide Us to a Happy Path for Configuration and Coding，作者 Jon Udell。
我们都有不同的学习方式。不幸的是，我的学习方式是先尝试所有错误的方法，最后才能找到正确的方法。这并不总是坏事。通过探索所有不顺畅的路径，你可以对一个复杂的系统有更深入的了解，这种学习是有价值的。但很多时候，你只想走上幸福之路，尽快到达目的地。
随着我们的系统变得越来越复杂、分层和相互依赖，不顺畅的路径也随之增多。
在所有技术领域中，配置是最容易出现不顺畅路径的领域。随着我们的系统变得越来越复杂、分层和相互依赖，这些不顺畅的路径也随之增多。我们都知道传统的难题：缓存失效、命名、越界错误。我认为配置是新的——甚至更令人头疼的——难题。
这周，我需要扩展 人类洞察力 + 大语言模型的苦力 = 创意出版解决方案 中描述的解决方案。使用 Google Docs 来编写和协作审查文档，然后将其转换为为我们的网站提供支持的 Markdown，已经解决了一个大问题。但它也不可避免地带来了一个新问题。当我们审查这样创建的大量文档时，我们意识到我们对文件名和标题的约定需要改变。如果在 Google Docs 中手动进行，这将是一项痛苦的练习，而且我找到的任何插件都无法处理基于正则表达式的多文档搜索和替换。因此，除了读取和翻译 GDocs 的转换器之外，我还需要一个更新器来自动执行就地转换。
如何快速学习 Google Docs API 的必要知识来完成这项工作？
如果这些文档只是本地系统上的文本文件，那么这将是微不足道的，因为大语言模型具有强大的正则表达式能力。但它们是 Google 文档，这完全是另一回事。弄清楚如何对 Google 进行身份验证一直是我的一大难题。如果这是我必须定期做的事情，我会积累足够的经验来克服它，而不会有太多戏剧性。但就像很多这样的琐事一样，这不是我经常做的事情。两次遭遇之间可能会有几个月甚至几年的时间，所以每次遭遇都意味着要爬上一条痛苦的学习曲线。我需要创建什么样的 OAuth 应用程序？请再次提醒我关于那个同意屏幕。哦，对了，我必须弄清楚要启用哪些 API，然后显式地启用它们，对吧？然后确定哪些范围可供我的应用程序使用？以及如何持久化身份验证令牌？然后，请提醒我，当我更改范围时，是否需要删除令牌并重新进行身份验证？哦，我的转换器和更新器可以共享公共凭据吗？最后，如何快速学习 Google Docs API 的必要知识来完成这项工作？
你知道其他人以前也走过同样的路。
我一直讨厌以这种艰难的方式重新学习所有这些废话必要的但令人讨厌的仪式。你知道其他人以前也走过同样的路。如果你能拍拍其中一个人的肩膀，并与他们进行五分钟的交谈，你就可以避免这些陷阱。从历史上看，我们获取这些知识的最佳方式是进行网络搜索和阅读文档。与之前相比，这已经很了不起：阅读书籍、参加课程。但仍然不够好。网络搜索、文档、书籍和课程对你在学习时所处的特定环境没有很好的反应，如果有的话。大语言模型扩展了我们与知识渊博的人交流的机会。这是一种间接的访问方式，它是不个人的，如果我能及时找到合适的人，我不会选择它。但这很少可能，与大语言模型交谈是一个很好的替代方案。
我们应该花点时间思考这一点。在 重塑发现：网络科学的新时代 中，迈克尔·尼尔森写道：
“在创造性解决问题的过程中，在正确的时间获得正确专家的关注往往是最宝贵的资源。专家关注对于创造性解决问题就像沙漠中的水对于生命一样：它是基本稀缺资源。”
本书中一个重要的故事讲述了名为 InnoCentive 的组织（现已并入众包问题解决平台 Wazoku Crowd）如何帮助一个非营利组织——该组织需要在印度农村地区可靠运行的太阳能无线路由器——与 Zacary Brown 联系，Zacary Brown 是一位软件工程师和无线电爱好者，拥有必要的技能。尼尔森补充道：
“InnoCentive 通过重构专家关注度来创造价值，使 Zacary Brown 等人能够以高杠杆的方式运用他们的专业知识。”
我们绝对应该期望我们的协作工具（看看你，Slack！）能够帮助我们有效地利用专家关注度。我们如何帮助人们在组织中与专家联系，而不会让这些专家充斥着不必要的、会扼杀工作流程的干扰？这是一个重要的开放性问题。正如我 上次 提到的，像 Cody 和 Unblocked 这样的基于 LLM 的工具可以充当同事的代理，从而保护他们免受干扰。但我们不要忽视以最有效、最不具破坏性的方式将人们联系在一起的必要性。在这方面，还有很大的提升空间——或者与 Slack 竞争。
展示而不是讲述的能力是一个改变游戏规则的能力。
如果我能说服一位专家指导我完成 Google 的身份验证迷宫，我们就会进行一个带有屏幕共享的通话，这样我就可以展示我各种失败的尝试。令人高兴的是，现在使用 LLM 可以做到这一点。正如我之前多次提到的，将屏幕截图粘贴到 ChatGPT（现在也包括 Claude）中是一种非常有效的方法。以下是我在转录中看到的一张帮助我走出迷宫的图片。
这张图片值千言万语。它表明我们是在 Python 的 Google API 客户端的上下文中操作的，并且我们已经使用某种有效的凭据对服务进行了身份验证，但文档 ID 错误或没有授予必要的范围（或应用程序未请求），或者可能存在其他问题。用文字将这种上下文传达给另一个人会很乏味——这就是我们进行屏幕共享的原因。用相同的文字提示语言模型也会同样乏味。展示而不是讲述的能力是一个改变游戏规则的能力。
该转录中的其他屏幕截图显示：
- Google 文档本身，证明我拥有正确的文档 ID。
- Google 文档的共享对话框，证明作为已登录用户，我可以查看和编辑具有该 ID 的文档。
- 开发控制台的同意屏幕，证明我已授予必要的范围。
从我的屏幕上抓取一些内容并将其粘贴到 ChatGPT 中，使所有这些基本的故障排除工作变得轻而易举。
在这种情况下，问题出在其他地方。首先，在添加必要的范围后，我需要删除保存的令牌并重新进行身份验证。其次，我的脚本需要在其 API 请求中包含该添加的范围。这些错误已经反复出现，我最终会自己纠正。通过利用之前走过这条路的人们的经验，ChatGPT 加快了我识别和摆脱我遇到的陷阱的能力。
现在我让 LLM 以长格式编写正则表达式，并附上极其详细的注释。
从身份验证迷宫中出来后，一切都很顺利。以下是匹配模式列表并在其中替换替换项的核心函数。
这不是 Claude 生成的原始函数。在那个函数中，正则表达式看起来像调制解调器线路噪音。它们工作正常，但我没有信心能够理解、解释或修改它们。因此，现在我让 LLM 以长格式编写正则表达式，并附上极其详细的注释。它们不会主动这样做，但如果你坚持，它们会照办。
趁此机会，我要求快速复习一下 Python 的 re.sub 和其中匿名（lambda）函数的使用。我不再需要掌握这些习惯用法，这使我可以专注于我要解决的问题。但这只有在我能够快速轻松地恢复知识的情况下才是一种可行的策略，而 LLM 有力地使我能够做到这一点。
在 如何使用“AI” 中，Nicholas Carlini 提供了我在本专栏中一直在探索的策略的详尽列表。他写道：
“几乎所有事情都已经被其他人做过。你想要做的几乎没有什么真正是新颖的。语言模型在提供你之前见过的解决方案方面非常出色。”
有些人认为，通过聚合从人类经验中汲取的知识，大语言模型（LLM）并非如“生成式”一词所暗示的那样是创造力的来源，而是平庸的传播者。 既对又不对。 确实，真正新颖的想法和方法很少，我并不期望 LLM 能产生它们。 然而，大多数创造性行为都包含对已知想法和方法的新颖组合。 由于 LLM 极大地提高了我们进行这种组合的能力，因此它们是人类创造力的放大器，而不是威胁。