软件工程3.0
定义:软件的新形态: SaaM (Software as a Model): 软件即模型, Maas(Model as a Service):模型即服务
人机交互智能成为常态
提示工程能力
ICIO 框架
指令 Instruction
上下文 Context
输入数据或样本示例 Input Data
输出指标 Output Indicator
1 )指令（Instruction）：这是大模型执行具体任务的指示或说明，明确告诉大模型要完成 的任务，由用户显式输入。在软件工程领域，如代码生成、代码解释、测试生成等具体要 求，为大模型提供了相应的方向和重点。
2）上下文（Context）：这是对当前具体问题背景的描述，包括与大模型之前交互的内 容，不需要在提示词中说明，大模型具备一定的短记忆能力，可以视为隐式的上下文。在 软件工程领域，上下文可能包括代码调试时相关变量的值和状态、错误修复时控制台输入 的错误日志和堆栈信息等。
3）输入数据（Input Data）或少样本示例：提供输入、输出示例。通过提供若干具体的输 入和输出示例，可以让大模型更好地理解任务的要求和期望的输出形式，从而提高结果的 准确性和质量。
4）输出指标（Output Indicator）：对输出内容格式等的要求，例如要求以Markdown格式 或表格形式输出。
CRISPE 框架
CRISPE更注重大模型扮演的角色、背景和多样化输出，特别适用于挖掘用户使用场景， 生成用例图、用户故事及其验收标准等，因为用户行为需要基于明确且特定的角色，从而 获取更专业的答案。此外，通过模拟不同角色，可以拓宽思路，产生更多可能的结果（多 样化输出），有助于提升覆盖面和挖掘更多潜在信息。
技能和角色 Capacity and Role : 指定大模型要扮演的角色以进行互动,如架构师,开发人员,测试工程师或业务系统中的用户角色
背景 Insight : 大模型扮演该角色的背景,如扮演网上商城的买家,目的是从商城购买东西
任务陈述 Statement : 明确大模型要执行或完成的任务
个性化 : 指导大模型以何种风格、方式、格式回答
实验: 请求大模型提供多个输出结果或示例(可选)
ROSES框架
它适合于软件工程的其他场景应用，将交互细分为5个核心部分，以 确保清晰、有目的的交流。
角色 Role: 与CRISPE框架中的Capacity and Role相同。
目标 Objective: 描述想要实现的目标或大模型需要完成的任务
场景 Scenario: 提供与请求相关的背景信息或上下文。
预期与解决方案 Expected Solution: 描述期望的解决方案或结果。
步骤 Steps: 询问实现解决方案所需的具体步骤或操作。
示例:
Role：假设你是一位软件开发团队的架构师，负责系统的技术架构设计
Objective：完成某证券机构的私有云系统的架构设计
Scenario：这个私有云上要部署股票交易系统，要支持2000万用户的使用 Expected Solution：期望这个私有云具有良好的性能、韧性和可伸缩性 Steps：请给出完成这个私有云系统的架构设计具体步骤，包括每个步骤的注意事项和交 付成果
提示词的思维链和思维树
思维链 Chain of Thought (CoT) 是大语言模型提示工程中的一个重要概念，旨在通过引 导模型逐步推理和生成答案，提升其处理复杂任务的能力。CoT通过将问题分解为一系列 逻辑步骤或推理过程，帮助模型在生成最终答案前逐步思考和推导。这种方法模仿了人类 的思维过程，使模型能够更深入地理解问题的上下文和细节。具体应用时，主要关注以下 3个要点。
1）分解问题：将复杂问题拆解为多个简单的子问题，逐步引导模型进行思考。例如，在 解决数学问题时，可以先询问模型每一步的计算过程。
2）提供示例：在提示中包含示例，展示如何通过思维链进行推理。这有助于模型学习如 何处理类似问题。
3）使用明确的指令：在提示中使用清晰的语言，指示模型按照特定的步骤进行推理。例 如，可以使用“首先”“接下来”“最后”等词汇来引导模型的思考顺序。
示例:
计算24点扑克牌游戏：随机抽出4张牌（即4个数字），用加减乘除来计算出24点，但每张 牌都要用上且只能用一次。思维链（CoT）是：现在抽出的4张牌是（4,9,10,13）。首先 用其中两张牌（两个数字）做减法：13-9=4，再用另外两张牌做减法（10-4=6），最后我 们就能得出4×6=24，满足24点要求。但不同的数字，加减乘除的次序是不一样的。 现在给出新的4张牌（1,3,7,9），请计算出24。
RAG能力
检索增强生成（Retrieval-Augmented Generation，RAG）
智能体技术
多智能体
多智能体的4个关键要素
环境:
环境定义了LLM-MA（Large Language Model-Multi-Agent，大语言模型多智能体）系统部 署、交互和工作的特定上下文，如软件开发、算法竞赛、游戏等。LLM-MA感知和与环 境交互的方式（即环境接口）包括物理环境接口和沙盒环境接口等。
配置:
在LLM-MA系统中，各智能体由其特征、行为和技能定义，这些要素根据目标和角色量 身定制。例如，在游戏场景中，智能体可能扮演不同角色的玩家；在软件开发领域，智能 体可能承担项目经理、开发工程师、测试工程师等角色.
智能体的配置方法包括以下三种。
1）预定义（Predefined）：由系统设计者明确定义智能体的特征、行为和技能。在系统设 计初期，设计者会详细规划和设定智能体的配置。这种配置具有很强的控制力和适用性， 设计者完全掌控智能体的行为和特征，适用于特定任务或情境，能精确满足系统需求；但 智能体在运行时灵活性低，难以有效应对动态变化的环境。
2）模型生成（Model-Generated）：借助模型（如LLM）来创建智能体的配置。通过训练 和使用模型生成智能体的特征、行为和技能，使其具备良好的自主性和适应能力，而且能 生成多样化的智能体配置，探索更多可能性和解决方案，这种方法特别适合软件研发等复 杂环境，用于构建具有较强自主性和适应性的开发智能体、测试智能体等。但该方法的复 杂度较高，需要大量数据和计算资源支持，结果可能不完全可控。
3）数据驱动（Data-Driven）：基于预先存在的数据集构建智能体配置。通过分析和挖掘 数据，提取有用信息和模式，进而定义智能体的特征、行为和技能。这种方法适应性强， 因为智能体能从数据中学习和优化自身行为，但该方法同样复杂度较高，而且依赖大量的 高质量数据的支持。在客户服务系统中，通过分析大量客户交互数据，可构建客户服务智 能体，优化服务策略和响应方式，提高客户满意度。
通信
通信范式：可以是我们熟悉的同步通信、异步通信、批处理方式等，而目前LLM-MA系 统主要采用以下三种通信范式，即合作、辩论和竞争范式。
1）合作范式：智能体交换信息、建言献策，共同完成集体解决方案，实现共享目标。
2）辩论范式：智能体之间进行争论，提出并捍卫各自观点和解决方案，并批评其他智能 体的方案。
3）竞争范式：智能体努力实现与其他智能体目标可能冲突的自身目标。
通信结构:
典型通信结构有链式结构、分层（Layered）通信、去中心化（Decentralized） 通信、集中式（Centralized）通信和共享消息池（Shared Message Pool）
能力获取:
1）记忆：将先前互动和反馈的信息存储在记忆中，执行行动时检索相关有价值的记忆。
2）自我进化：通过改变初始目标和规划策略进行自我修改，根据反馈或通信日志自我训 练。
3）动态生成： 系统可在运行过程中动态生成新的智能体，处理当前的需求和挑战。
数据治理
跳过
模型工程能力
跳过
安全治理能力
跳过
UI 革命
对话式用户界面成为重点
尽管传统的 GUI（Graphical User Interface，图形用户界面）仍然是我们日常使用数字产品 的标准界面，但随着 AIGC的应用，GUI 正在向 CUI（Conversational User Interface，对话 式用户界面）演变。CUI 采用更自然、直观的语言交互方式，用户可以通过语音或文字与 系统对话，无须记住复杂的图标和操作。AI技术的发展使得语音识别、自然语言处理和 对话生成等方面取得了显著突破，CUI在多个领域得到广泛应用。
