你好，我是徐昊，今天我们来继续学习 AI 时代的软件工程。
上节课我们介绍了在不同的认知行为模式下与大语言模型（Large Language Model，LLM）不同的交互模式。我们可以通过提示词模版建立任务和流程，来应用显式知识和充分学习的不可言说知识；通过已经提取完成的思维链，指导知识生成、产生任务列表，以消费不可言说知识。
那么通过 LLM 辅助的不同认知模式，真的会带来效率的提升吗？这是我们今天讨论的问题。
通过自动化带来的效率提升
通过 LLM 辅助不同的认知模式，一个显而易见的效率提升是由于知识外化带来的复用。比如，上节课我们提到的清晰认知模式中的任务模板：
需求背景
=======
{requirements}
API要求
=====
API返回的结果是json格式；
当查找的SKU不存在时，返回404；
按关键搜索功能使用POST而不是GET；
任务
===
按照API要求为需求设计RESTful API接口。使用RAML描述。
可以看到，在这个模板中 API 要求的部分与需求背景部分是正交的。也就是说，无论针对何种需求背景，都可以依照同样的 API 要求，进行任务的操作。那么，对于 API 要求这部分的知识提取，就是可复用的知识。
除此之外，API 虽然与任务内容相关，但也并不是完全仅仅针对当前任务。比如构造 API 客户端、功能测试，甚至编写实现，都可以使用同样的要求。比如，我们仅仅改变任务的部分，就能获得新的任务模板：
需求背景
=======
{requirements}
API要求
=====
API返回的结果是json格式；
当查找的SKU不存在时，返回404；
按关键搜索功能使用POST而不是GET；
任务
===
按照API要求为当前需求设计API客户端。
通过 LLM 的提示词模板，我们实现了类似自动化脚本的效果。不同的是，常规的自动化脚本是自动化一个任务，而有了 LLM 的帮助，我们通过提供相应的知识，即可完成对于一类任务的自动化。比如，在上面的例子中，围绕 API 有关的任务，都可以通过包含了 API 要求的模板达成。
清晰认知模式下的 LLM 交互所带来的效率提升是显而易见的，通过知识复用与任务模板实现一类任务的自动化。而且因为处在清晰认知模式，无论是知识的表达还是任务模板的定义，都不会 存在额外的认知负载，是投资回报率非常高的自动化方式。
通过知识传递带来效率的提高
对于庞杂行为模式，情况要稍微复杂一点。我们在使用 LLM 辅助庞杂认知模式的时候，通常会觉得 LLM 带来的效率提升很有限，完全不如自己直接处理来得快。
首先，这是由于庞杂行为模式是对于不可言说知识的应用。而将不可言说知识转化为文字性的描述，同样是一项复杂的工作。因而，我们会觉得与其通过 LLM 处理，那还不如自己动手来得容易。
其次，在庞杂模式下，自动化程度并不高。正如我们上节课所讲的，庞杂模式下首先要通过知识生成对齐思路。然后再根据思路（任务列表），指导 LLM 进行后续的任务。那么我们难以直接看到最终结果，因而感觉效率不高。
针对个人而言的确如此。因为在庞杂认知模式中，我们处理的是已经掌握的不可言说知识，因而对于如何解决当前问题，我们已经有明确的思路。那么再通过 LLM 获得类似的结果，实际上效率的确不高。但是，如果我们处在一个团队中，那情况就完全不同了。
在我们讲解认知模式的时候，我们特别强调过，五种认知行为模式是不同的行为模式，而不是对于问题的划分。借助 Cynefin 框架，主要帮助我们理解对于同样的问题，人们有什么样的响应方式，而不是对问题本身的划分。
在团队中，对于同一个问题，有的人处在庞杂认知模式，而另外一些人则处在复杂的认知模式中。我们还是以软件开发中的架构知识为例，对于架构师而言，应用某个架构实现功能，是处在庞杂认知模式。他可以按照架构的要求，对需求进行进一步分解，从而在架构的指导下，完成功能。而对于新加入团队的成员而言，可能处于复杂认知模式，也就是需要先实现功能，再根据组员或架构师的反馈，逐步修改代码以符合架构的要求。
对于团队而言，效率的根源在于知识传递的效率，即知识传递的准确性，一致性和及时性，这些极大地影响着团队的效率。
而通过 LLM 以思维链形式提取的不可言说知识，可以以复用的形式实现知识的高效传递。比如，在上一节课中，我们举的思维链的例子：
需求背景
=======
{requirements}
API
===
{API}
要求
===
1. 使用JAX-RS框架实现API接口
2. 对于数据库的访问通过repository接口
3. 针对每一个领域对象，构造representation model表示其返回的json数据
4. 在API接口中，通过repository访问数据库，并将数据转化为对应的representation model
5. 划分任务时，按照repository，representation model和API的顺序梳理任务
任务
===
现在我们要按照要求，根据需求实现API中提及的RESTful API。
请先生成任务列表。
仔细查看思维链中的内容，你就会发现，这其实是对于架构的简要描述。同样与所处理的需求与 API 设计无关。而是从架构的角度出发，描述在当前架构模式下，拆分任务的方法。
只要我们在团队中，共享同样的思维链，那么团队对于架构就形成了一致的认知；而当架构修改时，只要更新所使用的模板，架构的改变就能准确且及时地传递。
因而哪怕对于个人而言，庞杂模式下的 LLM 交互模式并不能带来太多的效率提升，但考虑到团队中认知分布的不均衡，通过 LLM 依然可以对整个团队带来效率的巨大提升。
通过缩短反馈周期带来效率的提高
当处在复杂认知模式时，我们通过探测（Probe）- 感知（Sense）- 响应（Respond）构成一个反馈循环学习新的知识，并在学习中处理要解决的任务。其中，探测可能是最花费时间的环节，但真正发挥作用的是感知和响应环节。
比如，当我们尝试学习新的框架或语言时，我们需要阅读资料，并根据自己的理解编写代码（探索）。然后根据代码执行的结果，反思我们对于这个框架或语言的理解（感知），然后再进一步修改代码（响应）。我们能学得多快往往取决于反馈周期。反馈周期越短越迅速，我们学习的效率也就越高。
而由于探测环节费力费时，往往会成为整个反馈周期的瓶颈。而 LLM 在复杂认知模式下，主要负责在探测阶段帮助我们执行任务产生初始结果，或是根据反馈重新执行任务。
在 LLM 的帮助下，我们可以更快进入感知与响应的环节。在响应环节中，当我们提出反馈之后，LLM 也可以快速给出新的答案。因而 LLM 消除了反馈循环中的瓶颈，也就极大提高了我们在复杂认知模式下的行为效率。
比如，我们在上节课举的“查找所有计算机学院的学生，生成 MySQL 查询”的例子。假设，我们现在将数据库系统替换为不熟悉的 MongoDB。可以使用这样的提示词：
在关系数据库中存在
-表departments，字段为[DepartmentId, DepartmentName],
-表students，字段为[DepartmentId, StudentId, StudentName]
请参照这个关系，给出MongoDB的解决方案。
提供准备测试数据的代码。
并为"查找所有计算机学院的学生"生成MongoDB的查询语句
我们可以直接执行 ChatGPT 返回的结果，验证是否符合我们的预期。如果执行有错，可以将错误直接贴回，让 ChatGPT 继续改正。这就极大地缩短了反馈周期。
值得一提的是，通常我们认为复杂认知模式是一种低效的认知模式。因而在传统的管理方法中，我们会尽量地控制复杂认知模式的使用，转而追求以流程为核心，处于清晰认知模式的官僚机制，或是以专家为核心、处于庞杂认知模式的技术官僚机制。
然而在 LLM 的帮助下，对于某些场景而言，复杂认知模式的效率变得可以接受了。也就是只使用复杂认知模式而无需关注认知提升，依然可以高效地解决问题。
LLM 辅助的知识工程
至此我们已经窥见了 LLM 辅助下知识工程的全貌：
通过知识的传递与消费建模知识过程；
理解知识在知识过程中产生的不同的认知模式；
选择对应的 LLM 交互模式，在不同的认知模式下提高知识消费的效率。
这样我们就可以围绕需要传递的知识，在认知模式的指引下，评估什么样的 LLM 交互模式能够有效地辅助知识过程，从而全面地、结构性地将 LLM 引入到知识过程中去。这就是 LLM 辅助下的知识工程。
比如，在前面的章节中，我们将软件开发转化为了知识过程。那么对于 LLM 可以如何辅助软件交付，我们就有一个大致的思路了。
从宏观过程来看，软件研发的过程是一个对于业务知识学习的过程，是复杂认知行为模式。
我们可以利用 LLM 缩短反馈周期，提前验证对于业务知识的理解。
进入到交付过程之前，我们需要将业务知识转化为软件功能需求，这是目标解决方案的应用，是一个不可言说知识应用的过程，是庞杂认知行为模式。我们可以通过将目标解决方案转化为 CoT，辅助业务知识到软件功能的分解。
架构知识也可以看作是从技术视角出发的解决方案。按照架构构造软件的过程，是一个不可言说知识应用的过程，是庞杂认知行为模式。通过将架构转化为 CoT，辅助研发任务的分解。
在软件构造过程中，功能性和非功能性质量保障措施会带来不同的认知行为模式。和上面相同，需要我们依照不同的认知行为模式，引入 LLM。
当然，这个思路仍然非常粗略，我们需要在具体环节中，提取相关知识，并结合 LLM 交互模式，带来实质的效率提升。当然，这都是后续课程中，我们要讲解的内容。
小结
今天，我们讲解了 LLM 是如何帮助在知识过程中提效的。除了交互模式之外，不同的 prompting 技巧也会在具体交互时，带来不同的效率差异。
上图就是我在实践中尝试和采纳过的一些 Prompting 技术。比如处理庞杂问题时，除了 CoT 之外，像推理行动（Reasoning-Action，ReAct）也可以处理已经充分学习的不可言说知识。而除了 RAG 以外，自动推理与工具使用（Automatic Reasoning and Tool-use）也是学习新知识的标准模式之一了（ChatGPT plugin 的基本架构）。
一旦我们理解了认知模式与 LLM 发挥的作用，就可以很容易地采纳新的 Prompting 技术，帮助我们提高效率。
思考题
请根据不同的测试策略，构思引入 LLM 的方式。
欢迎在留言区分享你的想法，我会让编辑置顶一些优质回答供大家参考和学习。