开发人员（包括我在内）通常偏好边学习边实践的方式。这不仅仅是我与LLM协作的核心准则之一，也是最关键的准则：因为你是在任务导向的学习过程中积累知识，这种学习方式不是预先的——它基于实时的、可感知的情境。

当资深开发者与LLM携手时，其机器的智能能够扩展和提升开发者自身的智慧。

对于我个人而言，优势非常明显。在LLM时代编写Steampipe的ODBC插件，与我之前未受此类辅助的时期相比，变得更为轻松。当然，这只是一个个人主观的评价。因此，当我在寻找机会与其他插件开发者交换心得时，詹姆斯·拉米雷兹在我们的社区Slack上宣布，他为Kolide API构建了一个全新插件。

我邀请他分享他构建插件的经历，他慷慨地与我分享了一次长时间的对话，是关于他与ChatGPT的交流。在这次对话中，他熟悉了三个新的技术领域：Kolide API、Go语言以及Steampipe插件框架。

作为额外的挑战：虽然插件开发者通常会寻找一个适合他们API目标的Go SDK，但这次情况并非如此。因此，需要创建一个Kolide API的Go包装器，并将其集成到插件中。

1、测试ChatGPT对Go语言的能力
詹姆斯开始了一些热身练习。首先，他测试了ChatGPT对Go语言的能力，他提供了几个他编写的Go函数，这些函数用于调用Kolide的/devices/和/devices/ID接口，并要求对其进行改写，以分离两个函数间共享的逻辑部分。

紧接着，他探讨了如何使用简单的可变参数与更复杂的函数选项模式来处理函数的可选参数。他发现，采用一个Search结构的切片来封装Kolide查询参数的字段/操作符/值的方法——已经足够应对需求。他要求一个函数来序列化这样的Search结构切片为REST URL，然后对ChatGPT提出的方案进行完善，创建了最终版的serializeSearches，添加了对友好名称映射到参数以及使用字符串构建器的支持。

其中一些改进，例如使用字符串构建器，是由名为CodeRabbit的AI驱动的机器人提出的，它提供了有益的代码审查。他提到，这种反馈有助于你和你的团队集中精力看大局，因为它负责处理细节，并且经常（尽管不总是）提供可操作的建议。

这个AI还从更广阔的视野总结拉取请求，并评估关闭的PR是否解决了其链接问题中陈述的目标。

2、映射操作符
詹姆斯继续研究如何将Steampipe操作符（如QualOperatorEqual）映射到Kolide操作符（如Equals）。这里，ChatGPT建议的方法最终被确认为应该摒弃的复杂方法，取而代之的是更为简洁明了的策略。

但正如詹姆斯在我们访谈中所确认的，即使是最终会被抛弃的版本，它们的生成也是有益的，因为它们允许进行合理的迭代，而不是手动编码。在这个过程中，他学习到了Go语言的基本惯用法。

詹姆斯问：

Go语言中有do-while循环吗？

ChatGPT回答：

没有，但是……

詹姆斯继续问：

Go语言有三元运算符吗？

ChatGPT回答：

没有，但是……

詹姆斯又问：

如何在map[string]string中添加内容？

ChatGPT解释道：

可以这样做……

3、借助反射增强的访问者模式
在掌握了基础知识并为Kolide API开发出Go客户端后，詹姆斯准备开始着手真正的插件开发：定义表格，将从API包装器返回的Go类型映射到Steampipe模型以管理这些表的SQL查询。

像所有插件开发者一样，他从一个能列出一系列资源的表开始，逐步通过添加过滤器和分页功能来增强它。在添加了第二个表后，他开始考虑如何抽象常见的模式和行为。最终成果是一种优雅的访问者模式实现。以下是与表kolide_device和kolide_issue相对应的Steampipe List函数：

以下是所有插件表都会使用的通用listAnything函数：

通过这种设置，为插件添加新表几乎完全是声明式的：你只需定义模式，以及建立SQL查询中where（或join）子句与API级别过滤器之间桥梁的KeyColumns及其关联操作符。

然后编写一个小型的List函数，定义一个访问者，并把它传递给通用的listAnything函数，该函数封装了查询参数的编组、建立API客户端连接、调用API、解包响应成集合，以及遍历集合将项目流式传递给Steampipe的外部数据包装器。

詹姆斯在ChatGPT的帮助下开始了Go中访问者模式的惯用实现。这意味着他学习了如何为访问者函数定义类型，并声明一个满足该类型的函数。

每个表的访问者封装了对API客户端的调用，并返回了一个接口。这一过程相当通用化，但访问者的响应是特定于包装的API响应的Go类型，因此需要为每个表编写不同的List函数。詹姆斯提出疑问：“在res变量上的字段引用需要在运行时指定为可变类型。你有解决方案吗？”

ChatGPT建议使用反射，以便调用如listAnything(ctx, d, h, "kolide_device.listDevices", visitor, "Devices")时，传递的名称（例如"Devices"）让listAnything能够不依赖类型地访问响应结构的字段。

有了这一点，listAnything真正成了一个完全通用的Steampipe List函数。这个解决方案减少了对反射的使用，并保持了Go在API层和Steampipe层的强类型检查。

 背景：免费AI问答交流-GPT

4、LLM协助意味着什么？
这并不意味着LLM可以直接回答像“请为Kolide API创建Steampipe插件”这样的提示，并编写出体现复杂设计模式的插件。

对我和詹姆斯来说，大型模型辅助编程意味着更有趣的事：“让我们探讨一下为Kolide API编写插件的过程。”这就像与橡皮鸭对话，大声思考需求和策略（编者注：“橡皮鸭调试法”指的是通过向一个假想的听众解释代码来寻找问题的解决方法）。LLM就是一个能给出回答的橡皮鸭。

有时，它的答案可以直接使用，有时则不行，但不管怎样，这些回答通常能帮助你清晰地思考。

作为一位经验丰富的资深软件工程师，詹姆斯原本可以独立解决问题，但这可能会花费更多时间。他原本会花费大量时间阅读文章和文档，而不是通过实际操作来学习。同时，没有那么多的时间可供他这样做！正如我现在从许多其他人那里听到的，LLM提供的加速经常是实现想法与能力执行之间的差别所在。

詹姆斯还提到了一个我未曾考虑过的开源角度。在LLM之前，他不会完全公开地进行这项工作。“我会一直保持私密，直到我感觉更有信心，”他说，“但这次从一开始就是公开的，我对此感到高兴。”这使得与Turbot团队的联系变得更早而不是更晚。

这不是自动化的故事，而是增强现实的故事。当像詹姆斯·拉米雷兹这样的资深开发者与LLM合作时，机器智能的支持和增强了他的人类智能。两者共同努力——不只是编写代码，更重要的是，共同思考架构和设计。