虚拟智库：运用大语言模型获取多元视角

本文基于与大语言模型（LLM）的广泛互动。阅读 LLM 生成的内容可能会相当乏味，文中仅保留了简短的引述。无论如何，读者朋友们最好在自己的 LLM 上尝试下这些提示，你可能会发现一些令人惊讶的东西。

引言

自从 ChatGPT 和其他 LLM 席卷全球以来，我一直在阅读、推测、写作和讨论 LLM 可能如何改变我们设计软件的方式。我们都知道，LLM 正在戏剧性地改变软件开发的世界。

开发者在创建软件时越来越多地使用 LLM 以及越来越智能的工具。似乎这一领域的增长趋势可能会持续下去。

与此同时，像 Stack Overflow 这样的流行资源其使用率正在下降，因为开发者不再搜索社区或示例，而是直接要求 LLM 编写代码。许多这样的 LLM，如 GitHub Copilot，直接嵌入到了 IDE 中。

在很大程度上，LLM 创建的代码在语法和功能上都是正确的，而且通常非常清晰并符合公认的标准。

然而，软件开发不仅仅是编码，还包括设计和架构。我们知道，架构通常是权衡的艺术。

因此，当涉及到架构决策时，没有唯一正确的答案，而是需要考虑多种可能的答案并做出选择（通常是艰难的）。充分权衡，并做出正确的决定，通常被认为是构建软件的难点。

为了看一下如何将 LLM 用于架构和设计，我一直在探索和实验的一个想法是“虚拟智库”。本文描述了什么是虚拟智库，以及如何利用它，并重点介绍一个我观察到一些有趣结果的例子。

虚拟人 vs. 真人

在进行系统架构设计时，仅凭我的个人经验，无论在深度还是广度上都不足以应对所有问题与挑战。我所依赖的资源包括书籍、网络博客、专业文章以及他人智慧。（搜索引擎并非我眼中的“首要资源”，它只是帮助我发现并获取其他资源的工具。）在所有可用的资源中，我发现他人提供的帮助最为有效。他人经验丰富、见解多元、思维敏锐且乐于助人。当我向他人请教时，实质是在邀请对方运用其经验与直觉来解决我的问题或应对我的处境，而对方往往能出色地完成这项工作。

然而，他人的问题通常是“可及性”。当我需要他人时，他们并不总是能及时出现。所谓可及性，既指时间上的空闲，也指能否腾出精力和心力给予关注。他人有各自的生活与优先事项，如若他们精于本职工作，往往就会忙得不可开交，至少是无暇顾及我所希望的关注。

这就是 LLM 的用武之地。最近，我开始越来越多地将 LLM 作为一种可依赖的资源。尽管 LLM 并非真人，也不具备完整的人类经验或同理心，但它的优势是始终在线。（架构师最爱权衡取舍。）

使用 LLM 的一种方式是要求它扮演一个角色。这个角色可以是宽泛的，也可以是特定的，请看下面的提示示例。

提示>>“你是一位经验丰富的软件工程师。你关心的是代码清晰、易于编写和维护，并且执行速度尽可能快。请使用 C 语言编写一个 B 树的实现，并提供每一步的详细说明。”

以及

提示>>“你是 Donald Knuth。请提供 B 树的实现以及详细解释。”

我尝试了上述提示和多个 LLM（ChatGPT、Gemini、Claude）。在所有情况下，两个提示都产生了看起来正确的功能代码。（我并未对代码的功能正确性进行全面测试。永远不要假设 LLM 生成的代码是正确的。）然而，当我要求 LLM 扮演 Donald Knuth 的角色时，我发现了一些新东西。

• 深度和严谨性：Donald Knuth 以其对细节的一丝不苟而闻名，尤其在其开创性著作《计算机程序设计艺术》中体现得淋漓尽致。这似乎促使 LLM 创建了一个更全面的实现，详细的注释解释了算法的每个方面，包括错误处理和各种边缘情况。

• 学术方法：LLM 采用了更具学术性和教育性的语气进行解释，关注 B 树的理论基础，而不仅仅是提供一个可行的解决方案。

• 算法焦点：我发现，LLM 强调算法的正确性和清晰性，而非追求实现捷径，这与 Knuth 处理算法的方式如出一辙——以数学般的严谨性审慎考量边界情况。

• 实现完整性：LLM 提供了一个完整、可运行的实现，而不是伪代码或经过简化的代码片段，这反映了 Knuth 对完整、可分析的算法的偏好。

• 历史背景：该 LLM 提到，B 树由 Bayer 和 McCreight 在 1971 年发明，展现出了对算法历史发展脉络的认知——这正是 Knuth 以系统阐述而闻名的领域。

举例来说，当扮演 Donald Knuth 的角色时，Claude 说：

B 树是自平衡的树数据结构，它维护排序数据，并能在对数时间内进行搜索、插入和删除。它是由 Rudolf Bayer 和 Edward M. McCreight 于 1971 年在波音研究实验室工作时发明的。

（读者朋友们最好在自己的 LLM 上尝试这些类似的提示。）

正如我们所看到的，这些回复不仅实用，而且远不止于提供正确高效的代码。它们所提供的上下文信息，非常像真人交流时所呈现的语境。

我注意到一个非常有趣的事情。尽管我没有要求它使用特定的编程语言，Claude 还是用 JavaScript 提供了 B 树代码。在各种论坛上，Knuth 发布的大部分代码都是用 C 语言编写的，所以将 Donald Knuth 的算法翻译成 JavaScript 是很出乎意料的。

利益相关者会议

在深入探讨虚拟智库之前，让我们讨论一下真正的智库。在讨论真正的智库之前，让我们首先讨论下利益相关者会议。

设计和架构决策会影响组织的许多部分，需要考虑许多因素。其中一种权衡各种因素的有效方式是召开“利益相关者会议”。

在利益相关者会议中，每位参与者都从不同的角度提出主张，都基于自身角色所代表的组织利益进行辩论。这种讨论往往复杂而微妙，却非常富有成效——每位利益相关者对系统有不同的观点，这源于其在组织中的角色定位与利益诉求（即“利益”）。有人体现了数据库视角，有人代表用户界面，有人代表后端系统，以此类推。这种决策方式往往非常有效，因为单凭一人很难全面考量所有因素，但代表多元利益、体现不同视角的成熟团队却能达成“优质”的决策。若运作得当，利益相关者会议可以实现高效决策。（如果想要深入理解利益相关者会议如何推动架构决策，可参阅 Andrew Harmel-Law 所著的《促进软件架构》）。

智库

现在我们来谈谈智库。

智库是由一群在组织或所讨论议题中不担任任何角色、不承担任何责任且没有任何既得利益的个人组成的团体。这些成员拥有不同的视角和人生经历，其价值观与偏好也可能存在差异。智库成员围绕当前议题展开讨论，提出兼顾多元视角与集体经验的解决方案。其核心运作机制之一是辩论：每位成员运用修辞技巧、假设案例和数据来论证捍卫自己的立场，同时保持开放的态度，接受其他成员提出的强有力的论据。智库成员不是从组织利益的角度进行争论或辩论，而是基于个人经历与世界观参与讨论。这种模式能催生出真正深刻的思想与分析，是一种极具价值的协作工具。

通常，当一个组织聘请智库时，他们不是提供解决方案，而是提供一份“报告”或“白皮书”，讨论一系列解决方案并比较它们各自的优势与取舍。随后，这份报告将用于在整个工作或项目的生命周期中提供指导和方向。

虽然智库是一个非常强大而且有用的工具，但它确实有一些缺点或挑战需要考虑。

首先，智库的运营成本高昂。在组建智库时，我们需要寻找那些经验丰富、见解深刻且视野开阔的人才，但他们既非利益相关者，也不隶属于我们的组织。因此，要让他们投入时间和精力参与其中，往往需要付出高昂的代价。

除了成本高昂之外，还有一个简单的问题是可及性。我们需要多样化的观点，但可能找不到我们需要的人并将他们聚集在一起。

虚拟智库

在过去的两年里，我一直在尝试使用 LLM 创建一个“虚拟智库”。基本想法是提示 LLM 从多个角度讨论一个想法或问题。虚拟智库不提出解决方案，而是评估一系列权衡，并帮助我找到对我来说最好的解决方案。

我发现，这种方法在许多类型的挑战和问题上都出奇地有效。在下一节中，我将通过一个例子来说明。

虚拟智库示例

这是一个我如何使用 Claude.ai 创建虚拟智库的例子。

问题陈述：我正着手构建一个电子商务系统，想知道是否应该采用微服务架构，以及何时开始使用会比较合适。

在正式展开讨论之前，我发现以下做法颇有裨益。这些是一般性的指南，未必适用于特定的 LLM。

1. 为使上下文不受之前的提示污染，开启一个新会话。

2. “引导”。提供一些基本的提示，并询问一些基本问题来创建上下文。我发现，这非常有助于你从 LLM 获得更好的回应。

提示

以下六个提示用于设置并与虚拟智库就微服务话题展开互动。

提示 1：微服务的一些基础知识

Avraham>> 你能向我解释一下微服务架构的基本原则吗？

Claude>>

 

<Claude 就微服务给出了篇幅较长、基本符合标准且准确的回应，内容相当实用且精确。其回答汇总了所有关于微服务的优质文本。值得注意的是，回应中未包含任何具有争议性或强烈个人色彩的观点。>

读者朋友们可以用自己选用的大语言模型重新生成结果。

但如果我需要有人能以更个性化的方式向我解释微服务呢？也许有人对这个问题有强烈的立场或观点。

提示 2：找一个人

Avraham>> 你能推荐一位现实生活中真正擅长推广和解释微服务的人吗？

Claude>> 对于一个现实生活中能很好地推广和解释微服务的人，我建议 Martin Fowler。

 

Martin Fowler 是一位著名的软件架构师、作家和演讲者，在推广和解释微服务架构方面有着重要的影响。他之所以特别出色，是因为：

 

1、2014 年，他与 James Lewis 共同撰写了有助于普及微服务的开创性文章。

2、他用清晰的实例而不是抽象的理论来解释复杂的概念。

3、他很好地平衡了自己对微服务的热情与微服务何时适用的实用建议。

4、他在软件架构方面拥有数十年的经验，可以将微服务与其他方法进行比较。

5、他的写作风格让没有深厚技术背景的人也易于理解。

 

其他强有力的候选人包括 Sam Newman（《构建微服务》的作者）、Chris Richardson（microservices.io 网站的创建者）或 Adrian Cockcroft（领导 Netflix 迁移到微服务的人）。

所以，现在我知道有人可以推广微服务了。（在开始这个特定的案例之前，我就知道 Martin Fowler 的工作，但我发现，LLM 提供了很多我不了解的专家的名字，我有很多地方可以向他们学习。在 GPT 的早期，人们知道它的一个主要缺点是“幻觉”，即 LLM 会发明不存在的人的名字。虽然这个问题还没有完全解决，但已经有了很大的进展。）

提示 3：向“Martin Fowler”征求意见

Avraham>> 你是 Martin Fowler。你能向我解释一下微服务架构的基本原则吗？

Claude 提供了一个极好的总结。整个总结都是用第一人称写的。感兴趣的读者可以自己生成一个回应。

通过比较 LLM 生成的回应，我们可以注意到几个差异。

设定人物改变了“说话方式”。Martin Fowler 的版本是用第一人称谈论他有经验的话题。这几乎就像是在读一段对话的记录，而不是编辑过的文本。

他的版本没有项目符号列表。在优点与挑战部分，“Martin”采用一种相对不那么正式的方式谈论了可扩展性和灵活性。

值得注意的是两个开头之间的差异：

未设定人物>>（由 Claude 提供）

 

微服务架构是一种软件开发方法，应用程序被构建为一系列小型、独立的服务。下面是关键原则：

 

Martin Fowler>>（由 Claude 提供）

 

作为一名软件架构师，我发现微服务是一种在过去十年中非常有吸引力的强大架构风格。让我来说明一下定义这种方法的基本原则：

可以看出，一旦将人物设定为 Martin Fowler，我们便获得了更具个人色彩的表达。微服务不仅是一种方法论，更是一种极具影响力的方法论。

现在，我已经明白了微服务是什么，也知道了一些倡导这种方法的人。但要想进行富有成效的讨论，我需要找个观点稍有不同的人。

提示 4：找一个反对 Martin Fowler 观点的人

Avraham>> 你能推荐一个可能强烈反对 Martin Fowler 的人吗？

Claude>> 对于强烈反对 Martin Fowler 微服务观点的人，我推荐 David Heinemeier Hansson，缩写为 DHH。

 

DHH 是 Ruby on Rails 的创始人，同时也是 Basecamp（和 Hey）的联合创始人/首席技术官（CTO）。他以观点鲜明而著称，曾公开批评微服务趋势，并倡导他所说的“宏伟单体”（majestic monolith）方法。

 

之所以说 DHH 是 Fowler 的一个很好的对立面，是因为：

 

1、他认为大多数公司都没有达到需要使用微服务的规模。

2、他认为微服务经常带来不必要的复杂性，并且存在过早优化问题。

3、他认为结构良好的单体可以有效地扩展，适合于大多数企业。

4、他批评企业采用微服务是出于跟随潮流而不是实际需要。

5、他认为微服务的运维开销对许多组织来说都超过了好处。

 

其他可能表达类似怀疑的人还有 Greg Young（虽然他帮助创建了事件源，但他警告不要过度使用微服务）和 Kelsey Hightower（他强调单体在许多情况下完全够用）。

我听说过，David Heinemeier Hansson 是 Ruby on Rails 的创始人，但我不知道他写过很多关于微服务的文章。这对我来说是新知识。我也从未听说过“宏伟单体”方法。（为了排除幻觉，我快速搜索了一下，找到了DHH探讨“宏伟单体”博文。）所以现在，我有两个人物可以就微服务进行富有成效的讨论。那么，有没有不那么强烈反对的人呢？

提示 5：找一个中间派

Avraham>> 你能推荐一个处于中间立场的人吗？

Claude>> 对于对微服务持中立观点的人，我推荐 Thoughtworks 的 Rebecca Parsons。

 

Parsons 博士曾担任 Thoughtworks 首席技术官多年，她之所以能够代表务实的中间派，原因如下：

 

1、她承认微服务的好处，但强调它们并不适合每个组织。

2、她主张在做出架构决策之前，先了解自己特定的业务环境。

3、她提倡渐进式方法：从设计良好的单体开始，只在有充分的理由时才提取微服务。

4、她关注团队结构和组织准备情况，将其作为架构决策的关键因素。

5、她强调架构应该反映业务领域，而不是追随潮流。

 

其他平衡两种观点的声音包括：

 

· Gregor Hohpe（《企业集成模式》的作者）讨论了根据特定需求恰当设定服务的大小。

· Michael Feathers 承认，两种架构风格都有其适用之处，这取决于组织的成熟度。

· Camille Fournier 主张在技术考量、团队动态和组织现实之间取得平衡。

 

这些架构师通常主张基于业务需求做出深思熟虑的决策，而不是教条地坚持任何一种方法。

现在，我已经组建好了团队。我有经常主张使用微服务的 Martin Fowler，经常反对使用微服务的 David Heinemeier Hansson，以及 LLM 认为是中间派的 Rebecca Parsons。

让我们组建一个虚拟智库。

提示 6 ：组建智库并分配任务

Avraham>

 

我正在创建一个新的电子商务业务应用。我不知道会有多少流量，或者可能的流量模式是什么。我在两种方法之间犹豫不决。

 

1、使用单体方法来启动项目。如果发现我们的流量模式适合使用微服务方法，那么我们将进行重构。

2、从微服务方法入手。

 

你能组建一个智库来讨论每种方法的优缺点，并提供可能的建议甚至达成一致吗？

 

该智库应该包括以下人员：

 

一个中立且知识渊博的主持人、Martin Fowler、DHH、Rebecca Parsons、Peter Drucker 和《阿特拉斯耸耸肩》中的 John Galt。

以下是对那场讨论的一些讨论和分析。

智库分析

你肯定已经注意到，我增加了 Peter Drucker 和 John Galt。我这样做的原因是，我发现，LLM 创建的人物非常具有可预测性，经常会按我们期望的方式说话。增加那些没有很多直接经验但具有“可转移智慧”的角色，实际上增添了相当程度的多样性。

需要注意的是，Claude 选择了 Adrian Cockcroft 作为主持人。我认为这是一个很棒的选择。在整个讨论中，Claude 都能够真正地以 Adrian Cockcroft 的风格说话。

尽管 Martin Fowler 是作为微服务倡导者的代表人物参与讨论，但实际上，他让我感到惊讶，因为他并没有完全拥抱微服务，而是发出了更平衡的声音。

一个真正有用的东西在一开始就出现了，那就是，尽管我选择了一个多元化的团队，但大家一致认为我们不应该从微服务开始。我认为这特别有用，因为有一种趋势是一开始就使用微服务，而在这里我们看到，几乎整个智库都认为这不是一个好主意。

在辩论的某个时刻，Fowler 说：“微服务提前增加了复杂性”。这是一个非常精辟的陈述（我想知道 Fowler 本人是否真的说过这句话）。它表达了一个观点，现在就引入复杂性来解决未来的问题一般都不值得。

后来的讨论似乎倾向于构建一个单体应用，同时针对未来的模块化进行设计，这种方法确实是提前增加了一些复杂性，但总的来说，它似乎达到了一个很好的平衡。尽管我的初衷是探索权衡之道，但虚拟智库最终却聚焦于解决方案本身。

继续利用智库

我们看到，现在上下文已经创建好了，智库已经在工作。我们可以通过这次会话继续利用智库来探讨手头其他方面的问题。我将这作为一个练习留给读者。

建议的提示

下面列出了我发现有帮助的一些提示，我分享出来是希望对读者有所帮助。

提示 1：

{系统}：可以是一长串文件或产出物

{当前行为}：可以是一长串文件或产出物

{所需行为}：可以是一长串文件或产出物

{问题陈述}

我是一名软件架构师，负责设计一个可以被描述为{系统}的系统。目前，系统执行{当前行为}，但需要做些改变，我们现在需要定义一个执行{所需行为}的系统。我们面临的一个主要问题是{问题陈述}。在开始之前，你能告诉我你是否同意{问题陈述}确实是一个大问题。另外，由于我将使用 LLM 来帮助解决这个问题，请至少就以下每个方面向我提出两个问题：当前系统、当前行为、所需行为、问题陈述。使用我的回答来重新表述问题陈述，以便我可以确定我在问正确的问题。

提示 2：

我想组建一个智库来讨论{重新表述的问题陈述}。请概要介绍至少两种可能的方法。一种方法可以是技术性的、管理性的或程序性的。如果有已知的人物或学派支持或推广这些方法。请告诉我他们是谁。

请按照以下格式提供列表：

{ "方法 1": { "姓名": "约翰", "方法": "协作" }, "方法 2": { "姓名": "简", "方法": "分析" } }

提示 3：

你能推荐一个可能没有直接写过这个特定问题的思考者或学派，为讨论增加一个重要或有帮助的视角吗？结果应该以以下格式呈现：{ "外部思考者": { "姓名": "约翰" } }

提示 4：

请组建一个智库来讨论{重新表述的问题陈述}。智库的参与者包括来自方法 1 的某人、来自方法 2 的某人、外部思考者，以及一个非常了解这个领域但大家都认为没有强烈偏好或意见的主持人。

让智库以开放的心态讨论{重新表述的问题陈述}。请不要回避争论或争议。每个人物角色都应该为他们的观点辩护，但要愿意听取其他人的观点。

如果有不清楚或模糊的地方，智库可以问我一个问题。

提示 5：

激进的方法。我被{重新表述的问题陈述}这个问题给难住了。我需要智库更有创造力。让每个成员提出一个可能违反常规思维和实践的激进决定。每个成员都应该解释清楚，为什么在这种情况下，他们的激进方法可能奏效。

提示 6：

发布一份 3 页的智库活动总结以及后续可能的研究方向。

总结

在这个特定的例子中，虽然智库没有提出什么新颖的东西，但它能利用现有的知识，以有用的方式讨论和评估微服务。我还没有找到一个例子，智库真的提出了什么激进的新东西。但谁知道呢，LLM 肯定会继续让我们惊讶。

作为架构师，我们总是在做权衡。我们总是试图打破我们的偏见和传统思维。我们总是在寻找新的视角和新的思考方式以及看待手头问题的新方法。我们总是在寻找新的工具和方法来帮助我们实现这一点。虚拟智库是一种可能帮助我们拓宽视野的方法。

我们要继续寻找有趣和创新的方式来使用 LLM。我认为，使用 LLM 来组建一个虚拟智库真的可以帮助我们挖掘各种人物（包括真实的和虚构的）的创造力，并得出有用且有趣的结论。

声明：本文为 InfoQ 翻译，未经许可禁止转载。

原文链接：

https://www.infoq.com/articles/virtual-think-tank/