你好，我是徐昊，今天我们来继续学习 AI 时代的软件工程。
在上一节课，我们介绍了如何构建反馈循环，并使用大语言模型（Large Language Model，LLM）反馈模型的缺失，然后再使用 LLM 进行模型展开，完成对模型的验证。构造有效的反馈循环，并使用 LLM 对其加速，这是一种利用 LLM 加速知识学习的通用模式。
然而在实际的应用的过程中，很少会出现不提供业务上下文，仅仅通过 LLM 反馈辅助建模这样的情况，而且这样的做法实际效率也不高。今天，我们来讨论一下使用 LLM 辅助建模的其他方法。
通过概念字典辅助建模
我们知道在建模的过程中，最重要的就是发掘系统中的存在的概念，并建立概念与概念之间的关联。那么在实际建模的过程中，对于概念的提炼就是重中之重了。
通常在建模的过程中，我们会维护一个概念字典（Glossary），其中包含对于系统非常重要的业务概念，以及对于这些概念的基本解释。举个例子，在上节课中，当我们收到 LLM 给出的反馈后，我们对于建模任务给出了这样的调整：
这是一个教学学籍管理系统。系统中应该包含以下的核心概念：
- 教学计划：一系列相关课程和活动，这些课程和活动旨在培养特定领域的知识和技能。比如，计算机科学与技术学士学位教学计划，或是计算机科学与技术硕士学位教学计划
- 录取通知：学生需要根据录取通知注册学籍。录取通知应该包含学生被录取的信息，如录取的教学计划
- 学籍：当学生注册之后，学籍记录学生在校将按照哪个教学计划学习
- 学生
这实际就是一个概念字典。而在实际工作中，概念字典的构建并不需要完全依靠 LLM 的反馈。在建模的过程中，我们通过对领域或业务的理解、用户访谈，甚至是阅读用户故事，都不难发现其中涉及的一些概念，以及这些概念之间的关联。
因此，我们可以在建模开始就构造概念字典，并通过概念字典加速整个建模反馈的过程。那么我们可以修改我们的任务模版：
业务描述
=======
{context}
系统中涉及概念的glossary如下：
{glossary}
任务
====
根据业务描述，为系统建立模型。可以添加你认为必要的实体和关系。并将模型表示为mermaid的class diagram
同样，我们也可以使用 LLM 辅助我们提取这个概念字典。我们可以设计这样的任务模板：
用户故事
======
{story}
任务
===
请根据用户故事中描述的业务场景，提取其中的业务概念，并给出每个概念的定义。
结果以表格形式给出。
通过一部分用户故事，让 LLM 理解业务的上下文，并从中提取我们提及的业务概念。仍然以上节课中，学生注册的用户故事为例：
作为学校的教职员工
我希望学生可以根据录取通知将学籍注册到教学计划上
从而我可以跟踪他们的获取学位的进度
使用上面的任务模板，我们可以获得这样的概念字典：
当然这里有些概念并不十分准确，比如学籍注册，显然是个分词错误。这些错误在反馈中也不难修正。
在得到概念字典之后，我们就可以将概念字典与任务模板结合，完成建模。然后再使用模型检查和模型展开，帮助我们验证模型的适用性。过程与之前的过程类似，就不在此重复了。我们需要重点强调的是，这个辅助建模过程的转变。
在最开始的时候，我们完全使用复杂认知模式（Complex），依靠反馈循环辅助我们完成建模的过程。而当我们发现 LLM 给出的反馈，可以构成概念字典时。我们的关注点，就变成了如何有效地生成概念字典。也就是，我们从探测性的模型生成转向了有针对性的知识生成（Generated Knowledge）。这实际是一种认知提升的体现，我们也由此逐渐进入到庞杂认知模式（Complicated）。
围绕概念字典构造思维链
一旦进入到庞杂认知模式，那么通过构造思维链（Chain of Thought）提高效率就是一个很自然的选择了。而针对建模而言，就是把建模方法转化为思维链，以提高模型的质量。
让我们举一个例子，如果我们目前要以 Peter Coad 的四色法（4 Colors Modeling）对这个系统进行建模，那么我们需要为 LLM 讲解四色法的四个基本原型：
在使用四色法建模时，我们将使用 4 个基本原型（Archetype）：Moment-interval、role、party-place-thing 和 description。
在这四个原型中，最重要的原型是 moment-interval，也就是某个时间或是一段时间。它代表的是出于业务或法律原因需要记录和跟踪的事情，是在某个时间或时间段内发生的事情。它帮助提醒我们在问题领域中寻找重要的时刻或时间段。
比如，销售（Sale）是在某一时刻进行的（moment），这里重要的信息是销售的日期和时间；
比如，租赁（Rental）则发生在一段时间内，这个时间段就是从支付（checkout）到归还（return）；
比如，预订（Reservation）也是发生在一段时间内，这个时间段就是预订到使用、取消或过期。
第二个重要原型是 role，也就是角色。角色是人、地点或事物（party-place-thing）以何种方式参与到 moment-interval 中。
比如，在销售（Sale）中，就会存在买家 (buyer) 和卖家 (seller) 两种角色。
第三个原型是 party-place-thing，是扮演不同 role 的人（个人或组织）、地点或事物。
第四个原型是 description，它是一种类似于目录条目的值对象，用以描述 party-place-thing 的具体数据。
并提供建模思路的 CoT 描述：
使用四色法建模时，步骤如下：
首先需要寻找系统中的 moment-interval，并梳理与它前后关联的其他 moment-interval。比如，支付（payment）作为一个 moment-interval，可能存在前置的 moment-interval 对象订单（order）
然后寻找参与到 moment-interval 中的 role
之后再寻找可以扮演这些 role 的 party-place-thing
最后寻找 description 对象
然后，我们可以修改建模的任务模板：
用户故事
======
{story}
概念提取的方法
============
{modeling_method}
任务
===
请根据上面描述的业务场景，按照提取概念的方法，提取其中的业务概念。并给出每个概念的定义。并以表格形式给出Glossary，并标注对应的archtype
让 GPT 使用四色建模法得到的概念字典是这样的：
这次生成的结果就要比之前好了很多，因为我们让它明确标记了建模的类型到底是什么类型。
剩下的步骤就类似了，我们需要将找到的概念字典放入建模模板，然后进行模型的检查环节。这里就不再赘述了。
当然我们也可以使用其他的建模方法，比如催化剂方法（Catalysis）、实体目标法、事件风暴法（Event Storming） 等等。
关键在于寻找到合适的中间产物，利用知识生成让 LLM 辅助提取核心概念。比如，对于事件风暴法，除了实体外，可能还需要提取事件等。但整体思路上，与我们所举的例子，并没有什么不同。
小结
如果再看一下我们目前所用的流程，在提取领域字典时，需要用户故事作为业务上下文；在检查模型是否有概念遗漏时，也使用了用户故事作为业务上下文；最后在模型展开的时候，还是用的用户故事作为业务上下文。
在不同场景下，我们都使用了用户故事，但是目的不同。提取领域字典时，提供用户故事主要是为了建模，而做完备性检查和模型展开时，用户故事则用来验证模型的适用性。那么我们就能从机器学习的角度去理解我们现在所做的事情。也就是将用户故事划分为学习集合和测试集合。
LLM 先利用学习集合提取其中的模型，然后再用测试集合中的用户故事，验证模型的适用性。
在我们给出的例子中，我们并没有区分不同的用户故事，通篇都使用了相同的用户故事。但在实际工作中，我们通常使用 Epic 用户故事提取模型，然后再利用更细粒度的用户故事对模型加以验证。
如果已经存在相对完善的用户故事，那么我们可以相对容易地利用 LLM 提取模型。这就为遗留系统提供了很大便利。而如果是从头开始建设的系统，那么有效地通过用户故事捕捉业务需求，就成了能利用好 LLM 的关键，这也是我们接下来要讲解的内容。
思考题
请为其他建模方法构造 CoT，并对当前的例子建模。
欢迎你在留言区分享自己的思考或疑惑，我们会把精彩内容置顶供大家学习讨论。