06｜LLM如何辅助软件交付？
![](data:image/svg+xml,<svg xmlns="http://www.w3.org/2000/svg" width="46" height="20"><rect fill-opacity="0"/></svg>)
06｜LLM如何辅助软件交付？
徐昊 · 徐昊 · AI时代的软件工程
课程介绍
讲述：徐昊
时长09:05大小8.31M
你好，我是徐昊，今天我们来继续学习 AI 时代的软件工程。
上节课我们介绍了在不同的认知行为模式下与大语言模型（Large Language Model，LLM）不同的交互模式。我们可以通过提示词模版建立任务和流程，来应用显式知识和充分学习的不可言说知识；通过已经提取完成的思维链，指导知识生成、产生任务列表，以消费不可言说知识。
那么通过 LLM 辅助的不同认知模式，真的会带来效率的提升吗？这是我们今天讨论的问题。
通过自动化带来的效率提升
可以看到，在这个模板中 API 要求的部分与需求背景部分是正交的。也就是说，无论针对何种需求背景，都可以依照同样的 API 要求，进行任务的操作。那么，对于 API 要求这部分的知识提取，就是可复用的知识。
除此之外，API 虽然与任务内容相关，但也并不是完全仅仅针对当前任务。比如构造 API 客户端、功能测试，甚至编写实现，都可以使用同样的要求。比如，我们仅仅改变任务的部分，就能获得新的任务模板：
通过 LLM 的提示词模板，我们实现了类似自动化脚本的效果。不同的是，常规的自动化脚本是自动化一个任务，而有了 LLM 的帮助，我们通过提供相应的知识，即可完成对于一类任务的自动化。比如，在上面的例子中，围绕 API 有关的任务，都可以通过包含了 API 要求的模板达成。
清晰认知模式下的 LLM 交互所带来的效率提升是显而易见的，通过知识复用与任务模板实现一类任务的自动化。而且因为处在清晰认知模式，无论是知识的表达还是任务模板的定义，都不会 存在额外的认知负载，是投资回报率非常高的自动化方式。
通过知识传递带来效率的提高
对于庞杂行为模式，情况要稍微复杂一点。我们在使用 LLM 辅助庞杂认知模式的时候，通常会觉得 LLM 带来的效率提升很有限，完全不如自己直接处理来得快。
首先，这是由于庞杂行为模式是对于不可言说知识的应用。而将不可言说知识转化为文字性的描述，同样是一项复杂的工作。因而，我们会觉得与其通过 LLM 处理，那还不如自己动手来得容易。
其次，在庞杂模式下，自动化程度并不高。正如我们上节课所讲的，庞杂模式下首先要通过知识生成对齐思路。然后再根据思路（任务列表），指导 LLM 进行后续的任务。那么我们难以直接看到最终结果，因而感觉效率不高。
针对个人而言的确如此。因为在庞杂认知模式中，我们处理的是已经掌握的不可言说知识，因而对于如何解决当前问题，我们已经有明确的思路。那么再通过 LLM 获得类似的结果，实际上效率的确不高。但是，如果我们处在一个团队中，那情况就完全不同了。
在我们讲解认知模式的时候，我们特别强调过，五种认知行为模式是不同的行为模式，而不是对于问题的划分。借助 Cynefin 框架，主要帮助我们理解对于同样的问题，人们有什么样的响应方式，而不是对问题本身的划分。
在团队中，对于同一个问题，有的人处在庞杂认知模式，而另外一些人则处在复杂的认知模式中。我们还是以软件开发中的架构知识为例，对于架构师而言，应用某个架构实现功能，是处在庞杂认知模式。他可以按照架构的要求，对需求进行进一步分解，从而在架构的指导下，完成功能。而对于新加入团队的成员而言，可能处于复杂认知模式，也就是需要先实现功能，再根据组员或架构师的反馈，逐步修改代码以符合架构的要求。
对于团队而言，效率的根源在于知识传递的效率，即知识传递的准确性，一致性和及时性，这些极大地影响着团队的效率。
而通过 LLM 以思维链形式提取的不可言说知识，可以以复用的形式实现知识的高效传递。比如，在上一节课中，我们举的思维链的例子：
仔细查看思维链中的内容，你就会发现，这其实是对于架构的简要描述。同样与所处理的需求与 API 设计无关。而是从架构的角度出发，描述在当前架构模式下，拆分任务的方法。
只要我们在团队中，共享同样的思维链，那么团队对于架构就形成了一致的认知；而当架构修改时，只要更新所使用的模板，架构的改变就能准确且及时地传递。
因而哪怕对于个人而言，庞杂模式下的 LLM 交互模式并不能带来太多的效率提升，但考虑到团队中认知分布的不均衡，通过 LLM 依然可以对整个团队带来效率的巨大提升。
通过缩短反馈周期带来效率的提高
当处在复杂认知模式时，我们通过探测（Probe）- 感知（Sense）- 响应（Respond）构成一个反馈循环学习新的知识，并在学习中处理要解决的任务。其中，探测可能是最花费时间的环节，但真正发挥作用的是感知和响应环节。
比如，当我们尝试学习新的框架或语言时，我们需要阅读资料，并根据自己的理解编写代码（探索）。然后根据代码执行的结果，反思我们对于这个框架或语言的理解（感知），然后再进一步修改代码（响应）。我们能学得多快往往取决于反馈周期。反馈周期越短越迅速，我们学习的效率也就越高。
而由于探测环节费力费时，往往会成为整个反馈周期的瓶颈。而 LLM 在复杂认知模式下，主要负责在探测阶段帮助我们执行任务产生初始结果，或是根据反馈重新执行任务。
在 LLM 的帮助下，我们可以更快进入感知与响应的环节。在响应环节中，当我们提出反馈之后，LLM 也可以快速给出新的答案。因而 LLM 消除了反馈循环中的瓶颈，也就极大提高了我们在复杂认知模式下的行为效率。
比如，我们在上节课举的“查找所有计算机学院的学生，生成 MySQL 查询”的例子。假设，我们现在将数据库系统替换为不熟悉的 MongoDB。可以使用这样的提示词：
我们可以直接执行 ChatGPT 返回的结果，验证是否符合我们的预期。如果执行有错，可以将错误直接贴回，让 ChatGPT 继续改正。这就极大地缩短了反馈周期。
值得一提的是，通常我们认为复杂认知模式是一种低效的认知模式。因而在传统的管理方法中，我们会尽量地控制复杂认知模式的使用，转而追求以流程为核心，处于清晰认知模式的官僚机制，或是以专家为核心、处于庞杂认知模式的技术官僚机制。
然而在 LLM 的帮助下，对于某些场景而言，复杂认知模式的效率变得可以接受了。也就是只使用复杂认知模式而无需关注认知提升，依然可以高效地解决问题。
LLM 辅助的知识工程
至此我们已经窥见了 LLM 辅助下知识工程的全貌：
通过知识的传递与消费建模知识过程；
理解知识在知识过程中产生的不同的认知模式；
选择对应的 LLM 交互模式，在不同的认知模式下提高知识消费的效率。
这样我们就可以围绕需要传递的知识，在认知模式的指引下，评估什么样的 LLM 交互模式能够有效地辅助知识过程，从而全面地、结构性地将 LLM 引入到知识过程中去。这就是 LLM 辅助下的知识工程。
比如，在前面的章节中，我们将软件开发转化为了知识过程。那么对于 LLM 可以如何辅助软件交付，我们就有一个大致的思路了。
从宏观过程来看，软件研发的过程是一个对于业务知识学习的过程，是复杂认知行为模式。
我们可以利用 LLM 缩短反馈周期，提前验证对于业务知识的理解。
进入到交付过程之前，我们需要将业务知识转化为软件功能需求，这是目标解决方案的应用，是一个不可言说知识应用的过程，是庞杂认知行为模式。我们可以通过将目标解决方案转化为 CoT，辅助业务知识到软件功能的分解。
架构知识也可以看作是从技术视角出发的解决方案。按照架构构造软件的过程，是一个不可言说知识应用的过程，是庞杂认知行为模式。通过将架构转化为 CoT，辅助研发任务的分解。
在软件构造过程中，功能性和非功能性质量保障措施会带来不同的认知行为模式。和上面相同，需要我们依照不同的认知行为模式，引入 LLM。
当然，这个思路仍然非常粗略，我们需要在具体环节中，提取相关知识，并结合 LLM 交互模式，带来实质的效率提升。当然，这都是后续课程中，我们要讲解的内容。
小结
今天，我们讲解了 LLM 是如何帮助在知识过程中提效的。除了交互模式之外，不同的 prompting 技巧也会在具体交互时，带来不同的效率差异。
Prompting技术与认知模式
上图就是我在实践中尝试和采纳过的一些 Prompting 技术。比如处理庞杂问题时，除了 CoT 之外，像推理行动（Reasoning-Action，ReAct）也可以处理已经充分学习的不可言说知识。而除了 RAG 以外，自动推理与工具使用（Automatic Reasoning and Tool-use）也是学习新知识的标准模式之一了（ChatGPT plugin 的基本架构）。
一旦我们理解了认知模式与 LLM 发挥的作用，就可以很容易地采纳新的 Prompting 技术，帮助我们提高效率。
思考题
请根据不同的测试策略，构思引入 LLM 的方式。
欢迎在留言区分享你的想法，我会让编辑置顶一些优质回答供大家参考和学习。
本文探讨了如何利用大语言模型（LLM）辅助软件交付，以及其带来的效率提升。在清晰认知模式下，LLM通过知识复用与任务模板实现任务自动化，提高了效率。在庞杂认知模式下，LLM通过思维链形式提取不可言说知识，实现了知识的高效传递，对整个团队带来了效率的巨大提升。文章还探讨了LLM在复杂认知模式下的应用，以及LLM辅助的知识工程。通过缩短反馈周期，LLM消除了复杂认知模式中的瓶颈，极大提高了行为效率。此外，文章还介绍了LLM辅助下的知识工程，以及不同的prompting技巧在具体交互时带来的效率差异。总的来说，LLM在软件交付中不仅提高了个人的效率，更重要的是通过知识的高效传递，对团队的效率产生了积极影响。
分享给需要的人，Ta购买本课程，你将得29元
生成海报并分享2024-03-20
赞 6
提建议
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
上一篇
05｜使用LLM应用和提取不可言说知识
下一篇
直播专场（一）｜如何理解知识工程？
全部留言(7)
- 最新
- 精选
![](data:image/svg+xml,<svg xmlns="http://www.w3.org/2000/svg" width="30" height="30"><rect fill-opacity="0"/></svg>)
临风置顶2024-03-20 来自广东之前老师给我的留言回复LLM对复杂模式的帮助比庞杂模式大，还不是很理解，今天算是揭晓答案了。庞杂模式是对不可言说知识的提炼和拆分，直接自己写和让LLM帮忙效率是差不多的。但复杂模式不同，复杂模式之前的困难是在于探测-感知-响应的循环过慢，导致知识提取的效率过慢，而LLM因为已经掌握了大量知识，可以作为个人的一对一指导老师，效率自然就提高了不少。 不知道大家注意到了没有，我觉得今天这篇文章的核心词是“复用”。过去我经常感慨，上个世纪的程序员为什么这么厉害，一个人就能完成一个软件的开发，而现在的人就只会调接口，已经丧失了从零编写一个软件的能力 。除了这些大神本身天赋异禀之外，可能更大的原因就在于复用，我们这代人，必须要基于现有的框架体系内去拓展，现实已经证明重复造轮子是低效且缺乏价值的。但为了复用已有的框架，我们要学大量个人品味的东西，而不需要接触代码底层的更核心的东西，诸如为什么是用注解定义而不是xml定义，为什么这个地方实现用组合而不是继承，为什么用双引号而不是单引号，为什么是用Java而不是go等等。 复用本来是为了解决多人协作重复造轮子的低效，反而又增加了新的学习负担。但LLM可能会重新改变这一局面，当LLM可以通过更高效的方式对不可言说知识进行复用，我们就不用去学习每个人框架开发者的品味，不用去在意开发语言或框架，而这正是未来软件发展的方向。展开作者回复: 复用减少了编码成本 增加了学习成本 所以只有能提升认知的复用 才是真复用
共 2 条评论13
听水的湖置顶2024-03-20 来自北京第一章课程学习反馈收集链接，看完第一章内容的同学记得填写哦！https://jinshuju.net/f/YzTEQa
一只豆2024-03-22 来自广东二刷课程时又读到这里：清晰模式下的任务自动化；庞杂模式下的认知对齐；复杂模式下可以快速探索。。。忽然觉得这三条几乎已经是整个技术史和文明史的高度概括！工业革命是从自动纺纱机开始，现代组织的巨大能量是从战略共识启动的，整个互联网经济的核心就是建立更有效率的创新体系。。。 感觉课程聚焦在软件开发好像委屈了老师和 大模型与知识工程之间的化学反应～～6![](data:image/svg+xml,<svg xmlns="http://www.w3.org/2000/svg" width="72" height="72"><rect fill-opacity="0"/></svg>)
术子米德2024-03-23 来自浙江🤔☕️🤔☕️🤔 【Q】根据不同的测试策略，如何引入LLM？ 【A】测试策略，Test Strategy，在开发周期内，确定何时何地怎么测试的策略。 如果，我的开发周期里，存在发布这个节点，那么，至少存在端到端测试，所谓End-to-End Testing，或者叫接受测试，所谓Acceptance Testing或System Testing；如果，我的开发在代码提交前，进行模块级别独立验证，那么，大概率存在单元测试，所谓Unit Testing；如果，我们的开发体系庞大，模块会被集成到不同组件或产品，那么，大概率存在集成测试，所谓Integrated Testing。这么好，那么现在就假设，ST、IT、UT，它们都好好在那里。 最接近客户的是ST，最接近组织的是IT，最接近开发的是UT。 客户的想法，不容易全懂，要摸着石头过河；组织的战略，关注新机会，要多种选项组合；开发的交付，明确和具体，要清晰不要糊涂。 LLM跟ST在一起，大概率是复杂（Complex）认知模式；LLM跟IT在一起，大概率是庞杂（Complicated）认知模式；LLM跟UT在一起，大概率是清晰（Clear）认知模式。 — by 术子米德@2024年3月23日展开1- 术子米德2024-03-23 来自浙江🤔☕️🤔☕️🤔 【R】效率提升 = 知识外化带来的复用 团队效率的根源 = 知识传递的及时准确性 【.I.】原来，这些知识在我的肌肉记忆里，跟着我的手势，靠你的天赋和悟性，才能习得。如今，提炼为模板的提示词工程，可以拿来反复跟LLM聊天，肌肉记忆变成聊法。我是肌肉记忆的主角，我是提示词的提取者，我是反复跟LLM聊天人，我把自己的不可言说知识，以提示链或任务列表的形式，变成我的日常稳定可用显式知识，让自己从复杂降到庞杂、再进入清晰，我自己的收益显然无疑。 【Q】你拿到我的提示词，跟LLM聊出的东西，真的也会复杂到庞杂、再进入清晰嘛？你和我的哪些不同方面，会影响到这个过程的发生？ — by 术子米德@2024年3月20日展开1
aoe2024-03-20 来自浙江在学习 Android Jetpack Compose 时借助 Copilot AI 插件确实提升了知识传递的及时性、准确性 两周周学习过程： 1. 「无 AI 介入」在官网阅读入门文档、观看入门视频解了 Jetpack Compose 的基本概念：如何创建一个页面、页面布局有哪些主要控件、控件在页面的位置如何调整 2. 「无 AI 介入」运行了最先发现的示例代码 3. 「无 AI 介入」按自己的想法开始了一个项目：点击按钮随机生成卦象、数字、十二星座、十二生肖 4. 「AI 介入」通过和 AI 对话进行开发功能：添加一个 Jetpack Compose Button；选中 Button 代码后，要求将 Button 变成圆形、改个颜色；画一条线；添加一个 Drawer 控件等 5. 「AI 介入」通过和 AI 对话添加了一个 codecov 插件在 Github Workflows 中上报测试覆盖率 6. 「无 AI 介入」开发到一周时，发现因严重缺乏 Android 基础知识，导致开发进度缓慢，买了一本《Head First Android 开发（第三版）》准备学习，此时还没看，硬和 AI 聊天完成了第一版功能 7. 「AI 介入」和 AI 聊天也没能解决的问题：测试 Compose 布局，运行时需要借助 Android 模拟器，自己写的测试代码，运行后的报错信息 AI 也不能帮助解决 8. v1.0.0 版本已发布，源码地址 https://github.com/aoeai/aoeai-qigua-android展开1
止😊2024-03-20 来自新加坡精彩1