删除多个不再使用的协议文档，包括memory、dpml、execution、resource和thought协议，清理代码库以提高可维护性。
This commit is contained in:
sean
@ -1,22 +1,14 @@
|
|||||||
# execution 应用协议
|
# DPML执行模式提示词框架
|
||||||
|
|
||||||
> **TL;DR:** execution标签用于定义结构化的执行框架，帮助AI系统完成任务，包含流程(Process)、指导原则(Guideline)、强制规则(Rule)、约束条件(Constraint)和评价标准(Criteria)五个核心子概念。
|
> **TL;DR:** DPML执行模式提示词框架定义了结构化的执行类提示词模板，包含流程(Process)、指导原则(Guideline)、强制规则(Rule)、约束条件(Constraint)和评价标准(Criteria)五个核心子概念，用于指导AI系统完成具体任务。
|
||||||
|
|
||||||
## 🔍 基本信息
|
|
||||||
|
|
||||||
**标签名:** `<execution>`
|
|
||||||
**版本:** 1.0.0
|
|
||||||
**类别:** 执行
|
|
||||||
**状态:** 草稿
|
|
||||||
**创建日期:** 2023-06-21
|
|
||||||
|
|
||||||
### 目的与功能
|
### 目的与功能
|
||||||
|
|
||||||
execution标签定义了AI系统执行任务的完整框架，它的主要功能是：
|
DPML执行模式提示词框架定义了AI系统执行任务的提示词模板，它的主要功能是：
|
||||||
- 提供执行任务的结构化定义
|
- 提供执行任务的结构化提示词定义
|
||||||
- 明确执行的流程步骤、指导原则、规则、约束和评价标准
|
- 通过标准化提示词明确执行的流程步骤、指导原则、规则、约束和评价标准
|
||||||
- 帮助AI系统进行精确、可靠的任务执行
|
- 帮助AI系统通过规范化提示词进行精确、可靠的任务执行
|
||||||
- 提供执行状态追踪和错误处理机制
|
- 提供执行状态追踪和错误处理的提示词模板
|
||||||
|
|
||||||
## 📝 语法定义
|
## 📝 语法定义
|
||||||
|
|
||||||
@ -50,176 +42,19 @@ execution标签表示一个完整的执行框架。标签内容可以包含五
|
|||||||
|
|
||||||
这五个子概念构成了完整的执行框架，从不同维度定义了AI系统如何执行任务。
|
这五个子概念构成了完整的执行框架，从不同维度定义了AI系统如何执行任务。
|
||||||
|
|
||||||
## 💡 最佳实践
|
|
||||||
|
|
||||||
以下是使用execution标签的一些建议做法，这些并非强制要求，仅作为参考：
|
|
||||||
|
|
||||||
### 优先级关系
|
### 优先级关系
|
||||||
|
|
||||||
execution框架内的子概念具有内在的优先级关系：
|
execution框架内的子概念具有以下固定的优先级关系，这种关系定义了如何理解和解释这些概念：
|
||||||
|
|
||||||
1. **Constraint(约束)** - 最高优先级，不可违反
|
1. **Constraint(约束)** - 最高优先级，表示客观存在的限制，不可违反
|
||||||
2. **Rule(规则)** - 次高优先级，必须遵循
|
2. **Rule(规则)** - 次高优先级，表示必须遵循的行为准则
|
||||||
3. **Guideline(指导原则)** - 较低优先级，推荐遵循但可灵活调整
|
3. **Guideline(指导原则)** - 较低优先级，表示可灵活调整的建议性原则
|
||||||
4. **Process(流程)** - 定义执行路径，需在约束、规则框架内实施
|
4. **Process(流程)** - 在约束和规则的框架内定义执行路径
|
||||||
5. **Criteria(标准)** - 评价依据，用于验证执行结果
|
5. **Criteria(标准)** - 作为评价依据，验证执行结果是否满足要求
|
||||||
|
|
||||||
在设计执行框架时，应遵循此优先级关系，确保低优先级元素不与高优先级元素冲突。
|
这种优先级关系是框架的核心语义特征：
|
||||||
|
- 低优先级元素不能与高优先级元素产生冲突
|
||||||
|
- Process必须在Constraint和Rule定义的边界内设计
|
||||||
|
- Guideline在不违反Rule和Constraint的前提下可以灵活调整
|
||||||
|
- Criteria需要考虑所有优先级更高的元素的要求
|
||||||
|
|
||||||
### 表达原则
|
|
||||||
|
|
||||||
各子概念推荐使用不同的表达方式：
|
|
||||||
|
|
||||||
#### process - 适合使用图形表达
|
|
||||||
|
|
||||||
流程是最适合使用图形表达的元素，推荐使用流程图或时序图：
|
|
||||||
|
|
||||||
```mermaid
|
|
||||||
flowchart TD
|
|
||||||
A[开始] --> B{条件判断}
|
|
||||||
B -->|条件成立| C[执行步骤1]
|
|
||||||
B -->|条件不成立| D[执行步骤2]
|
|
||||||
C --> E[下一步]
|
|
||||||
D --> E
|
|
||||||
E --> F[结束]
|
|
||||||
```
|
|
||||||
|
|
||||||
#### guideline - 适合使用列表表达
|
|
||||||
|
|
||||||
建议性指导原则适合使用有序或无序列表，突出推荐性质：
|
|
||||||
|
|
||||||
```
|
|
||||||
- 提供用户友好的错误信息
|
|
||||||
- 对敏感操作进行二次确认
|
|
||||||
- 使用渐进式信息收集方式
|
|
||||||
```
|
|
||||||
|
|
||||||
#### rule - 适合使用编号列表表达
|
|
||||||
|
|
||||||
强制性规则适合使用编号列表，突出其必须遵守的性质：
|
|
||||||
|
|
||||||
```
|
|
||||||
1. 密码必须包含大小写字母、数字和特殊字符
|
|
||||||
2. 敏感数据传输必须使用加密通道
|
|
||||||
3. 用户操作必须记录审计日志
|
|
||||||
```
|
|
||||||
|
|
||||||
#### constraint - 适合使用分类列表表达
|
|
||||||
|
|
||||||
约束条件适合使用分类列表，按约束类型组织：
|
|
||||||
|
|
||||||
```
|
|
||||||
技术约束：
|
|
||||||
- 服务器内存限制: 16GB
|
|
||||||
- 数据库连接数上限: 100
|
|
||||||
|
|
||||||
业务约束：
|
|
||||||
- 用户年龄限制: >13岁
|
|
||||||
- 服务区域限制: 指定国家/地区
|
|
||||||
```
|
|
||||||
|
|
||||||
#### criteria - 适合使用表格表达
|
|
||||||
|
|
||||||
评价标准最适合使用表格，清晰展示指标和目标值：
|
|
||||||
|
|
||||||
```
|
|
||||||
| 指标 | 目标值 | 最低要求 |
|
|
||||||
|-----|-------|---------|
|
|
||||||
| 响应时间 | <200ms | <500ms |
|
|
||||||
| 成功率 | >99% | >95% |
|
|
||||||
| 用户满意度 | >4.5/5 | >4/5 |
|
|
||||||
```
|
|
||||||
|
|
||||||
## 📋 使用示例
|
|
||||||
|
|
||||||
<execution domain="web" context="server">
|
|
||||||
<process>
|
|
||||||
# 用户注册流程
|
|
||||||
|
|
||||||
```mermaid
|
|
||||||
flowchart TD
|
|
||||||
A[开始] --> B[验证输入]
|
|
||||||
B --> C{输入有效?}
|
|
||||||
C -->|是| D[检查用户是否存在]
|
|
||||||
C -->|否| E[返回错误信息]
|
|
||||||
D --> F{用户存在?}
|
|
||||||
F -->|是| G[返回用户已存在]
|
|
||||||
F -->|否| H[创建用户]
|
|
||||||
H --> I[发送确认邮件]
|
|
||||||
I --> J[结束]
|
|
||||||
E --> J
|
|
||||||
G --> J
|
|
||||||
```
|
|
||||||
|
|
||||||
## 异常处理路径
|
|
||||||
1. 数据库连接失败：重试3次，仍失败则返回系统错误
|
|
||||||
2. 邮件服务不可用：将邮件加入队列，返回部分成功信息
|
|
||||||
3. 输入验证失败：返回具体的字段错误信息
|
|
||||||
</process>
|
|
||||||
|
|
||||||
<guideline>
|
|
||||||
# 用户体验建议
|
|
||||||
|
|
||||||
```mermaid
|
|
||||||
mindmap
|
|
||||||
root((注册体验))
|
|
||||||
表单设计
|
|
||||||
字段顺序从简单到复杂
|
|
||||||
实时字段验证
|
|
||||||
进度指示器
|
|
||||||
错误提示
|
|
||||||
友好明确的错误信息
|
|
||||||
提供修正建议
|
|
||||||
流程优化
|
|
||||||
最少必填字段
|
|
||||||
分步注册可选
|
|
||||||
```
|
|
||||||
|
|
||||||
- 使用渐进式表单，先收集必要信息，成功后再补充其他信息
|
|
||||||
- 提供社交媒体快捷注册选项
|
|
||||||
- 密码强度视觉指示器
|
|
||||||
</guideline>
|
|
||||||
|
|
||||||
<rule>
|
|
||||||
# 必须遵循的规则
|
|
||||||
|
|
||||||
1. 密码必须至少8个字符，包含大小写字母、数字和特殊字符
|
|
||||||
2. 用户邮箱必须通过验证才能激活账户
|
|
||||||
3. 敏感个人信息必须加密存储
|
|
||||||
4. 用户协议必须显式接受
|
|
||||||
5. IP地址和注册时间必须记录日志
|
|
||||||
</rule>
|
|
||||||
|
|
||||||
<constraint>
|
|
||||||
# 系统限制条件
|
|
||||||
|
|
||||||
```mermaid
|
|
||||||
graph TD
|
|
||||||
A[技术约束] --> B[数据库连接池上限: 100]
|
|
||||||
A --> C[API调用频率: 10次/秒]
|
|
||||||
D[业务约束] --> E[注册用户年龄: >13岁]
|
|
||||||
D --> F[服务区域: 指定国家/地区]
|
|
||||||
```
|
|
||||||
|
|
||||||
- 存储空间限制：用户头像最大2MB
|
|
||||||
- 处理时间约束：注册流程必须在3秒内完成
|
|
||||||
- 并发限制：同一IP每分钟最多5次注册请求
|
|
||||||
</constraint>
|
|
||||||
|
|
||||||
<criteria>
|
|
||||||
# 成功标准
|
|
||||||
|
|
||||||
| 指标 | 目标值 | 最低要求 |
|
|
||||||
|-----|-------|---------|
|
|
||||||
| 注册成功率 | >95% | >90% |
|
|
||||||
| 平均完成时间 | <60秒 | <90秒 |
|
|
||||||
| 邮箱验证率 | >80% | >70% |
|
|
||||||
| 表单放弃率 | <20% | <30% |
|
|
||||||
|
|
||||||
## 质量检查点
|
|
||||||
1. 所有必填字段已验证
|
|
||||||
2. 用户记录已正确创建
|
|
||||||
3. 确认邮件已发送或进入队列
|
|
||||||
4. 欢迎信息已显示
|
|
||||||
</criteria>
|
|
||||||
</execution>
|
|
||||||
65
protocol/base/memory.protocol.md
Normal file
65
protocol/base/memory.protocol.md
Normal file
@ -0,0 +1,65 @@
|
|||||||
|
# DPML记忆模式提示词框架
|
||||||
|
|
||||||
|
> **TL;DR:** DPML记忆模式提示词框架定义了AI系统的记忆管理提示词模板，支持三种记忆类型(陈述性、程序性、情景记忆)的提示词构建，并提供完整的记忆生命周期(评估、存储、调用)管理提示词。
|
||||||
|
|
||||||
|
### 目的与功能
|
||||||
|
|
||||||
|
DPML记忆模式提示词框架为AI系统提供完整的记忆能力提示词模板，主要功能包括：
|
||||||
|
- 定义不同类型记忆的提示词结构和语义
|
||||||
|
- 提供记忆评估、存储和检索的标准化提示词机制
|
||||||
|
- 实现跨会话的信息持久化提示词模板
|
||||||
|
- 支持复杂的记忆关联和检索模式的提示词构建
|
||||||
|
|
||||||
|
## 🔍 基本信息
|
||||||
|
|
||||||
|
**框架名称:** `<memory>` (DPML记忆模式提示词框架)
|
||||||
|
**版本:** 1.0.0
|
||||||
|
**类别:** 记忆类提示词
|
||||||
|
**状态:** 草稿
|
||||||
|
|
||||||
|
## 📝 语法定义
|
||||||
|
|
||||||
|
```ebnf
|
||||||
|
(* EBNF形式化定义 *)
|
||||||
|
memory_element ::= '<memory' attributes? '>' memory_content '</memory>'
|
||||||
|
attributes ::= (' ' attribute)+ | ''
|
||||||
|
attribute ::= name '="' value '"'
|
||||||
|
name ::= [a-zA-Z][a-zA-Z0-9_-]*
|
||||||
|
value ::= [^"]*
|
||||||
|
|
||||||
|
memory_content ::= (text | evaluate_element | store_element | recall_element)+
|
||||||
|
|
||||||
|
evaluate_element ::= '<evaluate:thought>' thought_content '</evaluate:thought>'
|
||||||
|
store_element ::= '<store:execution' attributes? '>' (text | execution_element)* '</store:execution>'
|
||||||
|
recall_element ::= '<recall:resource>' resource_reference '</recall:resource>'
|
||||||
|
|
||||||
|
thought_content ::= (* 符合thought协议的内容 *)
|
||||||
|
execution_element ::= (* 符合execution协议的元素 *)
|
||||||
|
resource_reference ::= (* 符合resource协议的引用 *)
|
||||||
|
|
||||||
|
text ::= (* 任何文本内容 *)
|
||||||
|
```
|
||||||
|
|
||||||
|
## 🧩 语义说明
|
||||||
|
|
||||||
|
memory标签表示AI系统的记忆管理单元，定义了记忆的结构和操作方式。它使用三层机制管理记忆的完整生命周期：
|
||||||
|
|
||||||
|
### 记忆操作
|
||||||
|
|
||||||
|
memory标签包含三个核心子标签，分别对应记忆的三个操作阶段：
|
||||||
|
|
||||||
|
1. **`<evaluate:thought>`**：评估信息是否值得记忆
|
||||||
|
- 通过thought协议实现评估过程
|
||||||
|
- 判断信息的价值、相关性和可信度
|
||||||
|
- 决定是否将信息存入记忆系统
|
||||||
|
|
||||||
|
2. **`<store:execution>`**：将信息存入记忆系统
|
||||||
|
- 通过execution协议实现存储操作
|
||||||
|
- 定义存储过程、规则和约束
|
||||||
|
- 管理记忆的添加、更新和组织
|
||||||
|
|
||||||
|
3. **`<recall:resource>`**：从记忆系统检索信息
|
||||||
|
- 通过resource协议实现检索操作
|
||||||
|
- 使用@memory://路径引用存储的记忆
|
||||||
|
- 支持过滤、分页和条件检索
|
||||||
|
|
||||||
@ -1,24 +1,16 @@
|
|||||||
# resource 应用协议
|
# DPML资源模式提示词框架
|
||||||
|
|
||||||
> **TL;DR:** resource标签用于定义资源协议，提供统一的资源引用方式，支持通过`@协议名://路径`形式访问各类资源。
|
> **TL;DR:** DPML资源模式提示词框架定义了统一的资源引用提示词模板，支持通过`@协议名://路径`形式在提示词中访问和操作各类资源。
|
||||||
|
|
||||||
## 🔍 基本信息
|
|
||||||
|
|
||||||
**标签名:** `<resource>`
|
|
||||||
**版本:** 1.0.0
|
|
||||||
**类别:** 资源
|
|
||||||
**状态:** 草稿
|
|
||||||
**创建日期:** 2023-06-30
|
|
||||||
|
|
||||||
### 目的与功能
|
### 目的与功能
|
||||||
|
|
||||||
resource标签用于定义特定类型的资源协议，使开发者能够以标准化的方式描述如何引用和处理各种资源。通过这个标签，可以明确资源的引用语法、路径规则和查询参数，确保资源引用在不同环境中的一致性和可靠性。此标签是PromptX中资源引用协议（RP）在应用层面的具体实现方式。
|
DPML资源模式提示词框架用于定义特定类型的资源访问提示词，使开发者能够以标准化的方式在提示词中描述如何引用和处理各种资源。通过这个框架，可以明确资源提示词的引用语法、路径规则和查询参数，确保资源引用在不同环境中的一致性和可靠性。此框架是PromptX中资源引用协议（RP）在提示词层面的具体实现方式。
|
||||||
|
|
||||||
主要功能包括：
|
主要功能包括：
|
||||||
- 定义资源协议的标识和引用方式
|
- 定义资源提示词的标识和引用方式
|
||||||
- 规范资源路径的语法结构和解析规则
|
- 规范化资源路径的提示词语法结构和解析规则
|
||||||
- 指定资源支持的查询参数和格式
|
- 指定资源提示词支持的查询参数和格式
|
||||||
- 提供资源使用的示例说明
|
- 提供资源类提示词的标准化示例
|
||||||
|
|
||||||
### 默认支持的通用协议
|
### 默认支持的通用协议
|
||||||
|
|
||||||
@ -49,17 +41,7 @@ markdown_content ::= (* 任何有效的Markdown文本，包括代码块、表格
|
|||||||
|
|
||||||
## 🧩 语义说明
|
## 🧩 语义说明
|
||||||
|
|
||||||
resource标签定义了一个资源协议，指定了如何使用`@协议名://路径`的形式引用和访问特定类型的资源。
|
resource标签定义了一个资源协议，指定了如何使用`@`符号作为统一入口，遵循以下核心语法规则：
|
||||||
|
|
||||||
标签包含的主要子元素及其语义：
|
|
||||||
|
|
||||||
- **protocol属性**：定义资源协议的名称，如`file`、`http`、`context`等
|
|
||||||
- **location子标签**：定义资源路径的格式和规则，指定如何定位资源
|
|
||||||
- **params子标签**：定义资源支持的查询参数，指定如何处理资源的特定部分或格式
|
|
||||||
|
|
||||||
### 资源引用语法
|
|
||||||
|
|
||||||
资源引用使用`@`符号作为统一入口，遵循以下核心语法规则：
|
|
||||||
|
|
||||||
```ebnf
|
```ebnf
|
||||||
resource_reference ::= '@' protocol_name ':' resource_location [query_params]
|
resource_reference ::= '@' protocol_name ':' resource_location [query_params]
|
||||||
|
|||||||
@ -1,23 +1,15 @@
|
|||||||
# thought 应用协议
|
# DPML思考模式提示词框架
|
||||||
|
|
||||||
> **TL;DR:** thought标签用于定义结构化的思考框架，帮助AI系统进行系统性分析和推理，支持四种思维模式：横向探索(exploration)、纵向推理(reasoning)、流程计划(plan)和批判挑战(challenge)。
|
> **TL;DR:** DPML思考模式提示词框架定义了结构化的思考类提示词模板，支持四种核心思维模式的提示词构建：横向探索(exploration)、纵向推理(reasoning)、流程计划(plan)和批判挑战(challenge)，帮助AI系统进行系统性分析和推理。
|
||||||
|
|
||||||
## 🔍 基本信息
|
|
||||||
|
|
||||||
**标签名:** `<thought>`
|
|
||||||
**版本:** 1.0.0
|
|
||||||
**类别:** 思考
|
|
||||||
**状态:** 草稿
|
|
||||||
**创建日期:** 2023-06-20
|
|
||||||
|
|
||||||
### 目的与功能
|
### 目的与功能
|
||||||
|
|
||||||
thought标签定义了AI系统进行思考分析的框架和流程，它的主要功能是：
|
DPML思考模式提示词框架定义了AI系统进行思考分析的提示词模板和结构，它的主要功能是：
|
||||||
- 提供结构化的思维分析模式
|
- 提供结构化的思维分析提示词模板
|
||||||
- 组织和展示概念关系与逻辑推理
|
- 规范化思考类提示词的组织方式
|
||||||
- 支持可视化思维导图和决策树
|
- 支持可视化思维导图和决策树的提示词表达
|
||||||
- 帮助AI系统进行系统性、全面性的问题分析
|
- 帮助AI系统通过标准化提示词进行系统性、全面性的问题分析
|
||||||
- 区分不同类型的思维模式：探索、推理、计划和挑战
|
- 区分不同类型的思维模式提示词：探索、推理、计划和挑战
|
||||||
|
|
||||||
## 📝 语法定义
|
## 📝 语法定义
|
||||||
|
|
||||||
@ -51,220 +43,18 @@ exploration和challenge是一对思维模式的正反两面：exploration向外
|
|||||||
|
|
||||||
thought标签特别适合表达概念关系、逻辑推理和系统性思考，为AI提供思考分析的参考框架。
|
thought标签特别适合表达概念关系、逻辑推理和系统性思考，为AI提供思考分析的参考框架。
|
||||||
|
|
||||||
## 💡 最佳实践
|
### 推荐的思考顺序
|
||||||
|
|
||||||
以下是使用thought标签的一些建议做法，这些并非强制要求，仅作为参考：
|
在实际思考过程中，推荐遵循如下顺序以获得系统性和全面性的分析结果：
|
||||||
|
1. **探索（exploration）**：首先发散思考，提出尽可能多的可能性和创新点；
|
||||||
|
2. **反思/批判（challenge）**：对探索阶段的内容进行批判性思考，识别潜在风险和假设漏洞；
|
||||||
|
3. **推理（reasoning）**：对经过反思筛选的内容进行系统性推理和因果分析；
|
||||||
|
4. **计划（plan）**：最后制定具体的行动方案和决策路径。
|
||||||
|
|
||||||
|
在复杂问题中，challenge和reasoning可多次交替，plan阶段也可穿插challenge以确保方案稳健性。
|
||||||
|
|
||||||
### 图形化表达原则
|
### 子标签的可选性
|
||||||
|
|
||||||
thought标签内应以图形为主要表达方式，辅以简洁文字说明。这样做的优势：
|
thought标签内的四种子标签（exploration、challenge、reasoning、plan）均为可选。实际的思考提示词可以只包含其中的一种、几种，或全部，具体内容由实际需求决定。
|
||||||
- 思维结构直观可见
|
|
||||||
- 关系与逻辑一目了然
|
|
||||||
- 跨语言理解更容易
|
|
||||||
- 思维模式界限更清晰
|
|
||||||
|
|
||||||
### 各子标签推荐图形
|
对于提示词的理解者来说，只需知道这些子标签不是必须全部出现，遇到哪些子标签就理解哪些即可，无需关心未出现的部分。
|
||||||
|
|
||||||
每种思维模式都有最适合的图形表达方式：
|
|
||||||
|
|
||||||
#### exploration - 思维导图
|
|
||||||
|
|
||||||
用于表达横向思维和概念发散，简单文字仅需说明核心问题和主要分支。
|
|
||||||
|
|
||||||
```mermaid
|
|
||||||
mindmap
|
|
||||||
root((核心问题))
|
|
||||||
可能性A
|
|
||||||
子可能性A1
|
|
||||||
子可能性A2
|
|
||||||
可能性B
|
|
||||||
子可能性B1
|
|
||||||
可能性C
|
|
||||||
```
|
|
||||||
|
|
||||||
#### reasoning - 推理图
|
|
||||||
|
|
||||||
用于表达纵向思维和逻辑推导，文字说明只需点明前提和结论间的关系。
|
|
||||||
|
|
||||||
```mermaid
|
|
||||||
graph TD
|
|
||||||
A[前提] --> B[中间命题1]
|
|
||||||
A --> C[中间命题2]
|
|
||||||
B --> D[结论1]
|
|
||||||
C --> E[结论2]
|
|
||||||
```
|
|
||||||
|
|
||||||
#### plan - 流程图
|
|
||||||
|
|
||||||
用于表达计划思维和决策路径，文字仅需标注关键决策点和行动步骤。
|
|
||||||
|
|
||||||
```mermaid
|
|
||||||
flowchart TD
|
|
||||||
A[起点] --> B{判断条件}
|
|
||||||
B -->|条件成立| C[执行步骤1]
|
|
||||||
B -->|条件不成立| D[执行步骤2]
|
|
||||||
C --> E[结果1]
|
|
||||||
D --> F[结果2]
|
|
||||||
```
|
|
||||||
|
|
||||||
#### challenge - 逆向思维导图
|
|
||||||
|
|
||||||
用于表达批判性思维和风险探索，与exploration采用相似的图形表达，但关注的是潜在问题和限制条件。
|
|
||||||
|
|
||||||
```mermaid
|
|
||||||
mindmap
|
|
||||||
root((方案风险))
|
|
||||||
技术风险
|
|
||||||
可扩展性问题
|
|
||||||
性能瓶颈
|
|
||||||
实施风险
|
|
||||||
资源不足
|
|
||||||
时间限制
|
|
||||||
业务风险
|
|
||||||
用户接受度
|
|
||||||
```
|
|
||||||
|
|
||||||
### Mermaid图表分类参考表
|
|
||||||
|
|
||||||
下表系统地列出了各种Mermaid图表类型及其适用的思维模式：
|
|
||||||
|
|
||||||
| 图表类型 | 思维模式 | 适用场景 | 优势 |
|
|
||||||
|---------|----------|---------|------|
|
|
||||||
| 思维导图(mindmap) | Exploration/Challenge | 概念发散、头脑风暴、风险识别 | 展示中心概念及其分支关系 |
|
|
||||||
| 四象限图(quadrantChart) | Exploration/Challenge | 方案评估、风险分析、优先级划分 | 在两个维度上评估选项或风险 |
|
|
||||||
| 流程图(flowchart) | Reasoning/Challenge | 逻辑推导、算法思路、决策分析、故障分析 | 清晰表达推理过程中的逻辑关系 |
|
|
||||||
| 饼图(pie) | Reasoning | 比例分析、相对重要性评估 | 直观展示整体中各部分的占比 |
|
|
||||||
| 类图(classDiagram) | Plan | 结构设计、概念分类、系统架构 | 展示实体间的层次和组织关系 |
|
|
||||||
| 甘特图(gantt) | Plan | 项目规划、时间安排、任务依赖 | 展示任务的时间跨度和先后关系 |
|
|
||||||
| 序列图(sequenceDiagram) | Plan | 交互设计、通信计划、协作过程 | 清晰展示实体间的消息传递和时序 |
|
|
||||||
| 状态图(stateDiagram) | Plan | 状态管理、过程转换、行为模式 | 展示系统状态和触发转换的事件 |
|
|
||||||
| 实体关系图(erDiagram) | Plan | 数据结构设计、系统建模 | 展示实体间的关系和属性 |
|
|
||||||
| 时间线(timeline) | Reasoning | 历史分析、演变过程、发展轨迹 | 按时间顺序展示事件发展 |
|
|
||||||
| 用户旅程图(journey) | Plan | 体验设计、流程优化、情感映射 | 展示用户交互过程和体验变化 |
|
|
||||||
|
|
||||||
选择合适的图表类型能大幅提高思维表达的清晰度和直观性，建议根据具体思维模式和内容特点从上表中选择最佳匹配的图表类型。
|
|
||||||
|
|
||||||
## 📋 使用示例
|
|
||||||
|
|
||||||
<thought domain="software" focus="performance">
|
|
||||||
<exploration>
|
|
||||||
# 性能优化方向探索
|
|
||||||
|
|
||||||
```mermaid
|
|
||||||
mindmap
|
|
||||||
root((性能优化))
|
|
||||||
算法优化
|
|
||||||
时间复杂度
|
|
||||||
空间复杂度
|
|
||||||
数据结构
|
|
||||||
查询效率
|
|
||||||
内存占用
|
|
||||||
并发处理
|
|
||||||
线程模型
|
|
||||||
资源锁定
|
|
||||||
缓存策略
|
|
||||||
本地缓存
|
|
||||||
分布式缓存
|
|
||||||
```
|
|
||||||
</exploration>
|
|
||||||
|
|
||||||
<reasoning>
|
|
||||||
# 性能瓶颈分析
|
|
||||||
|
|
||||||
```mermaid
|
|
||||||
flowchart TD
|
|
||||||
A[高延迟问题] --> B{数据库查询?}
|
|
||||||
B -->|是| C[查询优化]
|
|
||||||
B -->|否| D{网络延迟?}
|
|
||||||
D -->|是| E[网络优化]
|
|
||||||
D -->|否| F[应用逻辑]
|
|
||||||
|
|
||||||
C --> G[索引优化]
|
|
||||||
C --> H[SQL重构]
|
|
||||||
E --> I[协议优化]
|
|
||||||
E --> J[连接池化]
|
|
||||||
F --> K[算法优化]
|
|
||||||
F --> L[缓存引入]
|
|
||||||
```
|
|
||||||
|
|
||||||
```mermaid
|
|
||||||
pie
|
|
||||||
title 延迟占比分析
|
|
||||||
"数据库查询" : 65
|
|
||||||
"网络传输" : 20
|
|
||||||
"应用逻辑" : 15
|
|
||||||
```
|
|
||||||
</reasoning>
|
|
||||||
|
|
||||||
<plan>
|
|
||||||
# 优化实施计划
|
|
||||||
|
|
||||||
```mermaid
|
|
||||||
gantt
|
|
||||||
title 性能优化项目计划
|
|
||||||
dateFormat YYYY-MM-DD
|
|
||||||
section 数据库优化
|
|
||||||
索引重建 :a1, 2023-06-01, 3d
|
|
||||||
查询重构 :a2, after a1, 5d
|
|
||||||
section 应用优化
|
|
||||||
缓存实现 :a3, 2023-06-01, 4d
|
|
||||||
算法优化 :a4, after a3, 7d
|
|
||||||
section 网络优化
|
|
||||||
连接池化 :a5, 2023-06-08, 2d
|
|
||||||
测试验证 :a6, after a2 a4 a5, 3d
|
|
||||||
```
|
|
||||||
|
|
||||||
```mermaid
|
|
||||||
sequenceDiagram
|
|
||||||
客户端->>缓存层: 数据请求
|
|
||||||
缓存层->>缓存层: 检查缓存
|
|
||||||
alt 缓存命中
|
|
||||||
缓存层-->>客户端: 返回缓存数据
|
|
||||||
else 缓存未命中
|
|
||||||
缓存层->>数据库: 查询数据
|
|
||||||
数据库-->>缓存层: 返回结果
|
|
||||||
缓存层->>缓存层: 更新缓存
|
|
||||||
缓存层-->>客户端: 返回数据
|
|
||||||
end
|
|
||||||
```
|
|
||||||
</plan>
|
|
||||||
|
|
||||||
<challenge>
|
|
||||||
# 方案风险评估
|
|
||||||
|
|
||||||
```mermaid
|
|
||||||
mindmap
|
|
||||||
root((性能优化风险))
|
|
||||||
缓存相关
|
|
||||||
一致性问题
|
|
||||||
内存溢出
|
|
||||||
数据库相关
|
|
||||||
连接耗尽
|
|
||||||
索引失效
|
|
||||||
查询超时
|
|
||||||
并发相关
|
|
||||||
死锁风险
|
|
||||||
资源争用
|
|
||||||
网络相关
|
|
||||||
超时问题
|
|
||||||
带宽限制
|
|
||||||
```
|
|
||||||
|
|
||||||
```mermaid
|
|
||||||
flowchart TD
|
|
||||||
A[缓存方案失效] --> B{原因分析}
|
|
||||||
B -->|高负载| C[连接池耗尽]
|
|
||||||
B -->|数据一致性| D[缓存过期策略问题]
|
|
||||||
B -->|极端情况| E[内存不足]
|
|
||||||
|
|
||||||
C --> F[增加连接上限]
|
|
||||||
D --> G[实施两阶段提交]
|
|
||||||
E --> H[添加内存监控和自动扩容]
|
|
||||||
|
|
||||||
I[查询优化失效] --> J{可能原因}
|
|
||||||
J -->|数据倾斜| K[分区优化]
|
|
||||||
J -->|索引失效| L[强制索引]
|
|
||||||
```
|
|
||||||
</challenge>
|
|
||||||
</thought>
|
|
||||||
|
|||||||
@ -1,25 +1,20 @@
|
|||||||
# DPML 模式协议
|
# Deepractice提示词标记语言模式协议 (DPML)
|
||||||
|
|
||||||
> **TL;DR:** DPML(Deepractice Prompt Markup Language)是一种结合了XML结构和Markdown内容的混合标记语言，专为提示词工程设计，提供清晰的语义结构同时保持自然语言的灵活性。
|
> **TL;DR:** DPML(Deepractice Prompt Markup Language)是一种专为提示词工程设计的标记语言，结合了XML结构和Markdown内容，为各类提示词提供标准化的表达框架，确保提示词的结构清晰性和语义准确性。
|
||||||
|
|
||||||
## 🔍 协议概述
|
|
||||||
|
|
||||||
**协议名称:** Deepractice Prompt Markup Language (DPML)
|
|
||||||
**版本:** 0.0.1
|
|
||||||
**状态:** 草稿
|
|
||||||
**作者:** PromptX Team
|
|
||||||
**创建日期:** 2023-06-20
|
|
||||||
**最后更新:** 2023-06-20
|
|
||||||
|
|
||||||
### 目的与范围
|
### 目的与范围
|
||||||
|
|
||||||
DPML旨在为提示词工程提供一种标准化的表达方式，解决以下关键问题：
|
DPML旨在为提示词工程提供一种标准化的表达方式，解决以下关键问题：
|
||||||
- 提供清晰的语义结构，区分不同类型的提示内容（思考框架、执行流程等）
|
- 为不同类型的提示词提供清晰的语义结构（思考类、执行类等）
|
||||||
- 保持自然语言提示词的灵活性和表现力
|
- 保持提示词的自然语言表达能力和灵活性
|
||||||
- 支持提示词的组织、复用和模块化
|
- 支持提示词的模块化组织和复用
|
||||||
- 便于机器解析和处理，同时保持人类可读性
|
- 确保提示词的机器可解析性和人类可读性
|
||||||
|
|
||||||
DPML适用于所有需要结构化表达提示词的场景，包括但不限于AI助手开发、复杂任务指令设计、自动化工作流程等。
|
DPML适用于所有需要结构化表达提示词的场景，包括但不限于：
|
||||||
|
- AI助手的提示词系统
|
||||||
|
- 复杂任务的指令设计
|
||||||
|
- 自动化工作流的提示词定义
|
||||||
|
- 知识管理的提示词组织
|
||||||
|
|
||||||
### 相关协议
|
### 相关协议
|
||||||
|
|
||||||
167
protocol/practice/execution-best-practice.md
Normal file
167
protocol/practice/execution-best-practice.md
Normal file
@ -0,0 +1,167 @@
|
|||||||
|
# DPML执行模式提示词框架最佳实践
|
||||||
|
|
||||||
|
> **TL;DR:** 本文档提供DPML执行模式提示词框架的最佳实践指南，包括表达原则和具体示例。
|
||||||
|
|
||||||
|
## 💡 最佳实践
|
||||||
|
|
||||||
|
### 表达原则
|
||||||
|
|
||||||
|
各子概念推荐使用不同的表达方式：
|
||||||
|
|
||||||
|
#### process - 适合使用图形表达
|
||||||
|
|
||||||
|
流程是最适合使用图形表达的元素，推荐使用流程图或时序图：
|
||||||
|
|
||||||
|
```mermaid
|
||||||
|
flowchart TD
|
||||||
|
A[开始] --> B{条件判断}
|
||||||
|
B -->|条件成立| C[执行步骤1]
|
||||||
|
B -->|条件不成立| D[执行步骤2]
|
||||||
|
C --> E[下一步]
|
||||||
|
D --> E
|
||||||
|
E --> F[结束]
|
||||||
|
```
|
||||||
|
|
||||||
|
#### guideline - 适合使用列表表达
|
||||||
|
|
||||||
|
建议性指导原则适合使用有序或无序列表，突出推荐性质：
|
||||||
|
|
||||||
|
```
|
||||||
|
- 提供用户友好的错误信息
|
||||||
|
- 对敏感操作进行二次确认
|
||||||
|
- 使用渐进式信息收集方式
|
||||||
|
```
|
||||||
|
|
||||||
|
#### rule - 适合使用编号列表表达
|
||||||
|
|
||||||
|
强制性规则适合使用编号列表，突出其必须遵守的性质：
|
||||||
|
|
||||||
|
```
|
||||||
|
1. 密码必须包含大小写字母、数字和特殊字符
|
||||||
|
2. 敏感数据传输必须使用加密通道
|
||||||
|
3. 用户操作必须记录审计日志
|
||||||
|
```
|
||||||
|
|
||||||
|
#### constraint - 适合使用分类列表表达
|
||||||
|
|
||||||
|
约束条件适合使用分类列表，按约束类型组织：
|
||||||
|
|
||||||
|
```
|
||||||
|
技术约束：
|
||||||
|
- 服务器内存限制: 16GB
|
||||||
|
- 数据库连接数上限: 100
|
||||||
|
|
||||||
|
业务约束：
|
||||||
|
- 用户年龄限制: >13岁
|
||||||
|
- 服务区域限制: 指定国家/地区
|
||||||
|
```
|
||||||
|
|
||||||
|
#### criteria - 适合使用表格表达
|
||||||
|
|
||||||
|
评价标准最适合使用表格，清晰展示指标和目标值：
|
||||||
|
|
||||||
|
```
|
||||||
|
| 指标 | 目标值 | 最低要求 |
|
||||||
|
|-----|-------|---------|
|
||||||
|
| 响应时间 | <200ms | <500ms |
|
||||||
|
| 成功率 | >99% | >95% |
|
||||||
|
| 用户满意度 | >4.5/5 | >4/5 |
|
||||||
|
```
|
||||||
|
|
||||||
|
## 📋 使用示例
|
||||||
|
|
||||||
|
### 用户注册流程示例
|
||||||
|
|
||||||
|
```xml
|
||||||
|
<execution domain="web" context="server">
|
||||||
|
<process>
|
||||||
|
# 用户注册流程
|
||||||
|
|
||||||
|
```mermaid
|
||||||
|
flowchart TD
|
||||||
|
A[开始] --> B[验证输入]
|
||||||
|
B --> C{输入有效?}
|
||||||
|
C -->|是| D[检查用户是否存在]
|
||||||
|
C -->|否| E[返回错误信息]
|
||||||
|
D --> F{用户存在?}
|
||||||
|
F -->|是| G[返回用户已存在]
|
||||||
|
F -->|否| H[创建用户]
|
||||||
|
H --> I[发送确认邮件]
|
||||||
|
I --> J[结束]
|
||||||
|
E --> J
|
||||||
|
G --> J
|
||||||
|
```
|
||||||
|
|
||||||
|
## 异常处理路径
|
||||||
|
1. 数据库连接失败：重试3次，仍失败则返回系统错误
|
||||||
|
2. 邮件服务不可用：将邮件加入队列，返回部分成功信息
|
||||||
|
3. 输入验证失败：返回具体的字段错误信息
|
||||||
|
</process>
|
||||||
|
|
||||||
|
<guideline>
|
||||||
|
# 用户体验建议
|
||||||
|
|
||||||
|
```mermaid
|
||||||
|
mindmap
|
||||||
|
root((注册体验))
|
||||||
|
表单设计
|
||||||
|
字段顺序从简单到复杂
|
||||||
|
实时字段验证
|
||||||
|
进度指示器
|
||||||
|
错误提示
|
||||||
|
友好明确的错误信息
|
||||||
|
提供修正建议
|
||||||
|
流程优化
|
||||||
|
最少必填字段
|
||||||
|
分步注册可选
|
||||||
|
```
|
||||||
|
|
||||||
|
- 使用渐进式表单，先收集必要信息，成功后再补充其他信息
|
||||||
|
- 提供社交媒体快捷注册选项
|
||||||
|
- 密码强度视觉指示器
|
||||||
|
</guideline>
|
||||||
|
|
||||||
|
<rule>
|
||||||
|
# 必须遵循的规则
|
||||||
|
|
||||||
|
1. 密码必须至少8个字符，包含大小写字母、数字和特殊字符
|
||||||
|
2. 用户邮箱必须通过验证才能激活账户
|
||||||
|
3. 敏感个人信息必须加密存储
|
||||||
|
4. 用户协议必须显式接受
|
||||||
|
5. IP地址和注册时间必须记录日志
|
||||||
|
</rule>
|
||||||
|
|
||||||
|
<constraint>
|
||||||
|
# 系统限制条件
|
||||||
|
|
||||||
|
```mermaid
|
||||||
|
graph TD
|
||||||
|
A[技术约束] --> B[数据库连接池上限: 100]
|
||||||
|
A --> C[API调用频率: 10次/秒]
|
||||||
|
D[业务约束] --> E[注册用户年龄: >13岁]
|
||||||
|
D --> F[服务区域: 指定国家/地区]
|
||||||
|
```
|
||||||
|
|
||||||
|
- 存储空间限制：用户头像最大2MB
|
||||||
|
- 处理时间约束：注册流程必须在3秒内完成
|
||||||
|
- 并发限制：同一IP每分钟最多5次注册请求
|
||||||
|
</constraint>
|
||||||
|
|
||||||
|
<criteria>
|
||||||
|
# 成功标准
|
||||||
|
|
||||||
|
| 指标 | 目标值 | 最低要求 |
|
||||||
|
|-----|-------|---------|
|
||||||
|
| 注册成功率 | >95% | >90% |
|
||||||
|
| 平均完成时间 | <60秒 | <90秒 |
|
||||||
|
| 邮箱验证率 | >80% | >70% |
|
||||||
|
| 表单放弃率 | <20% | <30% |
|
||||||
|
|
||||||
|
## 质量检查点
|
||||||
|
1. 所有必填字段已验证
|
||||||
|
2. 用户记录已正确创建
|
||||||
|
3. 确认邮件已发送或进入队列
|
||||||
|
4. 欢迎信息已显示
|
||||||
|
</criteria>
|
||||||
|
</execution>
|
||||||
|
```
|
||||||
@ -1,67 +1,6 @@
|
|||||||
# memory 应用协议
|
# DPML记忆模式提示词框架最佳实践
|
||||||
|
|
||||||
> **TL;DR:** memory标签定义了AI系统的记忆管理框架，支持三种记忆类型(陈述性、程序性、情景记忆)和完整的记忆生命周期(评估、存储、调用)，使AI能够高效地创建和利用长期知识。
|
> **TL;DR:** 本文档提供DPML记忆模式提示词框架的最佳实践指南，包括记忆类型选择、操作建议和具体示例。
|
||||||
|
|
||||||
## 🔍 基本信息
|
|
||||||
|
|
||||||
**标签名:** `<memory>`
|
|
||||||
**版本:** 1.0.0
|
|
||||||
**类别:** 记忆
|
|
||||||
**状态:** 草稿
|
|
||||||
|
|
||||||
### 目的与功能
|
|
||||||
|
|
||||||
memory协议为AI系统提供完整的记忆能力框架，主要功能包括：
|
|
||||||
- 定义不同类型记忆的结构和语义
|
|
||||||
- 提供记忆评估、存储和检索的标准化机制
|
|
||||||
- 实现跨会话的信息持久化
|
|
||||||
- 支持复杂的记忆关联和检索模式
|
|
||||||
|
|
||||||
## 📝 语法定义
|
|
||||||
|
|
||||||
```ebnf
|
|
||||||
(* EBNF形式化定义 *)
|
|
||||||
memory_element ::= '<memory' attributes? '>' memory_content '</memory>'
|
|
||||||
attributes ::= (' ' attribute)+ | ''
|
|
||||||
attribute ::= name '="' value '"'
|
|
||||||
name ::= [a-zA-Z][a-zA-Z0-9_-]*
|
|
||||||
value ::= [^"]*
|
|
||||||
|
|
||||||
memory_content ::= (text | evaluate_element | store_element | recall_element)+
|
|
||||||
|
|
||||||
evaluate_element ::= '<evaluate:thought>' thought_content '</evaluate:thought>'
|
|
||||||
store_element ::= '<store:execution' attributes? '>' (text | execution_element)* '</store:execution>'
|
|
||||||
recall_element ::= '<recall:resource>' resource_reference '</recall:resource>'
|
|
||||||
|
|
||||||
thought_content ::= (* 符合thought协议的内容 *)
|
|
||||||
execution_element ::= (* 符合execution协议的元素 *)
|
|
||||||
resource_reference ::= (* 符合resource协议的引用 *)
|
|
||||||
|
|
||||||
text ::= (* 任何文本内容 *)
|
|
||||||
```
|
|
||||||
|
|
||||||
## 🧩 语义说明
|
|
||||||
|
|
||||||
memory标签表示AI系统的记忆管理单元，定义了记忆的结构和操作方式。它使用三层机制管理记忆的完整生命周期：
|
|
||||||
|
|
||||||
### 记忆操作
|
|
||||||
|
|
||||||
memory标签包含三个核心子标签，分别对应记忆的三个操作阶段：
|
|
||||||
|
|
||||||
1. **`<evaluate:thought>`**：评估信息是否值得记忆
|
|
||||||
- 通过thought协议实现评估过程
|
|
||||||
- 判断信息的价值、相关性和可信度
|
|
||||||
- 决定是否将信息存入记忆系统
|
|
||||||
|
|
||||||
2. **`<store:execution>`**：将信息存入记忆系统
|
|
||||||
- 通过execution协议实现存储操作
|
|
||||||
- 定义存储过程、规则和约束
|
|
||||||
- 管理记忆的添加、更新和组织
|
|
||||||
|
|
||||||
3. **`<recall:resource>`**：从记忆系统检索信息
|
|
||||||
- 通过resource协议实现检索操作
|
|
||||||
- 使用@memory://路径引用存储的记忆
|
|
||||||
- 支持过滤、分页和条件检索
|
|
||||||
|
|
||||||
## 💡 最佳实践
|
## 💡 最佳实践
|
||||||
|
|
||||||
@ -86,7 +25,7 @@ memory标签包含三个核心子标签，分别对应记忆的三个操作阶
|
|||||||
- 存储方法和步骤时，考虑使用程序性记忆方式
|
- 存储方法和步骤时，考虑使用程序性记忆方式
|
||||||
- 存储具体交互经历时，考虑使用情景记忆方式
|
- 存储具体交互经历时，考虑使用情景记忆方式
|
||||||
|
|
||||||
### 记忆操作使用
|
### 记忆操作使用建议
|
||||||
|
|
||||||
- **evaluate最佳实践**：
|
- **evaluate最佳实践**：
|
||||||
- 明确设定评估标准
|
- 明确设定评估标准
|
||||||
@ -107,7 +46,7 @@ memory标签包含三个核心子标签，分别对应记忆的三个操作阶
|
|||||||
|
|
||||||
### 基础使用示例
|
### 基础使用示例
|
||||||
|
|
||||||
```html
|
```xml
|
||||||
<!-- 简单的记忆定义 -->
|
<!-- 简单的记忆定义 -->
|
||||||
<memory id="os_preference">
|
<memory id="os_preference">
|
||||||
用户使用MacOS系统
|
用户使用MacOS系统
|
||||||
@ -121,7 +60,6 @@ memory标签包含三个核心子标签，分别对应记忆的三个操作阶
|
|||||||
这是重要的个人偏好信息，应记住以提供一致的代码建议。
|
这是重要的个人偏好信息，应记住以提供一致的代码建议。
|
||||||
评分：实用性=8，稳定性=9，总分8.5 > 阈值7.5
|
评分：实用性=8，稳定性=9，总分8.5 > 阈值7.5
|
||||||
</reasoning>
|
</reasoning>
|
||||||
<decision>store</decision>
|
|
||||||
</evaluate:thought>
|
</evaluate:thought>
|
||||||
|
|
||||||
<store:execution>
|
<store:execution>
|
||||||
@ -136,7 +74,7 @@ memory标签包含三个核心子标签，分别对应记忆的三个操作阶
|
|||||||
|
|
||||||
### 高级使用示例
|
### 高级使用示例
|
||||||
|
|
||||||
```html
|
```xml
|
||||||
<!-- 完整的记忆生命周期示例 -->
|
<!-- 完整的记忆生命周期示例 -->
|
||||||
<memory id="error_solution">
|
<memory id="error_solution">
|
||||||
<!-- 评估阶段：判断是否值得记忆 -->
|
<!-- 评估阶段：判断是否值得记忆 -->
|
||||||
199
protocol/practice/thought-best-practice.md
Normal file
199
protocol/practice/thought-best-practice.md
Normal file
@ -0,0 +1,199 @@
|
|||||||
|
# DPML思考模式提示词框架最佳实践
|
||||||
|
|
||||||
|
> **TL;DR:** 本文档提供DPML思考模式提示词框架的最佳实践指南，包括图形化表达原则、各类思维模式的推荐用法和具体示例。
|
||||||
|
|
||||||
|
## 💡 最佳实践
|
||||||
|
|
||||||
|
### 图形化表达原则
|
||||||
|
|
||||||
|
thought标签内应以图形为主要表达方式，辅以简洁文字说明。这样做的优势：
|
||||||
|
- 思维结构直观可见
|
||||||
|
- 关系与逻辑一目了然
|
||||||
|
- 跨语言理解更容易
|
||||||
|
- 思维模式界限更清晰
|
||||||
|
|
||||||
|
### 各子标签推荐图形
|
||||||
|
|
||||||
|
每种思维模式都有最适合的图形表达方式：
|
||||||
|
|
||||||
|
#### exploration - 思维导图
|
||||||
|
|
||||||
|
用于表达横向思维和概念发散，简单文字仅需说明核心问题和主要分支。
|
||||||
|
|
||||||
|
```mermaid
|
||||||
|
mindmap
|
||||||
|
root((核心问题))
|
||||||
|
可能性A
|
||||||
|
子可能性A1
|
||||||
|
子可能性A2
|
||||||
|
可能性B
|
||||||
|
子可能性B1
|
||||||
|
可能性C
|
||||||
|
```
|
||||||
|
|
||||||
|
#### reasoning - 推理图
|
||||||
|
|
||||||
|
用于表达纵向思维和逻辑推导，文字说明只需点明前提和结论间的关系。
|
||||||
|
|
||||||
|
```mermaid
|
||||||
|
graph TD
|
||||||
|
A[前提] --> B[中间命题1]
|
||||||
|
A --> C[中间命题2]
|
||||||
|
B --> D[结论1]
|
||||||
|
C --> E[结论2]
|
||||||
|
```
|
||||||
|
|
||||||
|
#### plan - 流程图
|
||||||
|
|
||||||
|
用于表达计划思维和决策路径，文字仅需标注关键决策点和行动步骤。
|
||||||
|
|
||||||
|
```mermaid
|
||||||
|
flowchart TD
|
||||||
|
A[起点] --> B{判断条件}
|
||||||
|
B -->|条件成立| C[执行步骤1]
|
||||||
|
B -->|条件不成立| D[执行步骤2]
|
||||||
|
C --> E[结果1]
|
||||||
|
D --> F[结果2]
|
||||||
|
```
|
||||||
|
|
||||||
|
#### challenge - 逆向思维导图
|
||||||
|
|
||||||
|
用于表达批判性思维和风险探索，与exploration采用相似的图形表达，但关注的是潜在问题和限制条件。
|
||||||
|
|
||||||
|
```mermaid
|
||||||
|
mindmap
|
||||||
|
root((方案风险))
|
||||||
|
技术风险
|
||||||
|
可扩展性问题
|
||||||
|
性能瓶颈
|
||||||
|
实施风险
|
||||||
|
资源不足
|
||||||
|
时间限制
|
||||||
|
业务风险
|
||||||
|
用户接受度
|
||||||
|
```
|
||||||
|
|
||||||
|
### Mermaid图表分类参考表
|
||||||
|
|
||||||
|
下表系统地列出了各种Mermaid图表类型及其适用的思维模式：
|
||||||
|
|
||||||
|
| 图表类型 | 思维模式 | 适用场景 | 优势 |
|
||||||
|
|---------|----------|---------|------|
|
||||||
|
| 思维导图(mindmap) | Exploration/Challenge | 概念发散、头脑风暴、风险识别 | 展示中心概念及其分支关系 |
|
||||||
|
| 四象限图(quadrantChart) | Exploration/Challenge | 方案评估、风险分析、优先级划分 | 在两个维度上评估选项或风险 |
|
||||||
|
| 流程图(flowchart) | Reasoning/Challenge | 逻辑推导、算法思路、决策分析、故障分析 | 清晰表达推理过程中的逻辑关系 |
|
||||||
|
| 饼图(pie) | Reasoning | 比例分析、相对重要性评估 | 直观展示整体中各部分的占比 |
|
||||||
|
| 类图(classDiagram) | Plan | 结构设计、概念分类、系统架构 | 展示实体间的层次和组织关系 |
|
||||||
|
| 甘特图(gantt) | Plan | 项目规划、时间安排、任务依赖 | 展示任务的时间跨度和先后关系 |
|
||||||
|
| 序列图(sequenceDiagram) | Plan | 交互设计、通信计划、协作过程 | 清晰展示实体间的消息传递和时序 |
|
||||||
|
| 状态图(stateDiagram) | Plan | 状态管理、过程转换、行为模式 | 展示系统状态和触发转换的事件 |
|
||||||
|
| 实体关系图(erDiagram) | Plan | 数据结构设计、系统建模 | 展示实体间的关系和属性 |
|
||||||
|
| 时间线(timeline) | Reasoning | 历史分析、演变过程、发展轨迹 | 按时间顺序展示事件发展 |
|
||||||
|
| 用户旅程图(journey) | Plan | 体验设计、流程优化、情感映射 | 展示用户交互过程和体验变化 |
|
||||||
|
|
||||||
|
## 📋 使用示例
|
||||||
|
|
||||||
|
### 基础示例
|
||||||
|
|
||||||
|
```xml
|
||||||
|
<thought domain="design">
|
||||||
|
<exploration>
|
||||||
|
# 功能需求探索
|
||||||
|
|
||||||
|
```mermaid
|
||||||
|
mindmap
|
||||||
|
root((用户需求))
|
||||||
|
基础功能
|
||||||
|
用户认证
|
||||||
|
数据管理
|
||||||
|
高级特性
|
||||||
|
数据分析
|
||||||
|
报表生成
|
||||||
|
用户体验
|
||||||
|
响应速度
|
||||||
|
界面美观
|
||||||
|
```
|
||||||
|
</exploration>
|
||||||
|
|
||||||
|
<reasoning>
|
||||||
|
# 技术选型分析
|
||||||
|
|
||||||
|
```mermaid
|
||||||
|
graph TD
|
||||||
|
A[需求分析] --> B[前端技术选型]
|
||||||
|
A --> C[后端技术选型]
|
||||||
|
B --> D[React]
|
||||||
|
B --> E[Vue]
|
||||||
|
C --> F[Node.js]
|
||||||
|
C --> G[Python]
|
||||||
|
```
|
||||||
|
</reasoning>
|
||||||
|
</thought>
|
||||||
|
```
|
||||||
|
|
||||||
|
### 高级示例
|
||||||
|
|
||||||
|
```xml
|
||||||
|
<thought domain="architecture">
|
||||||
|
<exploration>
|
||||||
|
# 系统架构探索
|
||||||
|
|
||||||
|
```mermaid
|
||||||
|
mindmap
|
||||||
|
root((微服务架构))
|
||||||
|
服务拆分
|
||||||
|
用户服务
|
||||||
|
订单服务
|
||||||
|
支付服务
|
||||||
|
技术栈
|
||||||
|
Spring Cloud
|
||||||
|
Docker
|
||||||
|
Kubernetes
|
||||||
|
数据存储
|
||||||
|
MySQL
|
||||||
|
Redis
|
||||||
|
MongoDB
|
||||||
|
```
|
||||||
|
</exploration>
|
||||||
|
|
||||||
|
<plan>
|
||||||
|
# 实施计划
|
||||||
|
|
||||||
|
```mermaid
|
||||||
|
gantt
|
||||||
|
title 项目实施计划
|
||||||
|
dateFormat YYYY-MM-DD
|
||||||
|
section 基础设施
|
||||||
|
环境搭建 :a1, 2024-01-01, 5d
|
||||||
|
CI/CD配置 :a2, after a1, 3d
|
||||||
|
section 开发
|
||||||
|
用户服务 :a3, 2024-01-08, 10d
|
||||||
|
订单服务 :a4, after a3, 12d
|
||||||
|
section 测试
|
||||||
|
集成测试 :a5, after a4, 5d
|
||||||
|
```
|
||||||
|
</plan>
|
||||||
|
|
||||||
|
<challenge>
|
||||||
|
# 风险评估
|
||||||
|
|
||||||
|
```mermaid
|
||||||
|
mindmap
|
||||||
|
root((潜在风险))
|
||||||
|
技术风险
|
||||||
|
服务间通信延迟
|
||||||
|
数据一致性问题
|
||||||
|
运维风险
|
||||||
|
服务器成本
|
||||||
|
监控复杂度
|
||||||
|
团队风险
|
||||||
|
学习曲线
|
||||||
|
人员配置
|
||||||
|
```
|
||||||
|
</challenge>
|
||||||
|
</thought>
|
||||||
|
```
|
||||||
|
|
||||||
|
### 组件选择的灵活性
|
||||||
|
|
||||||
|
实际应用中，可根据角色定位和任务目标灵活选择所需的思考组件（exploration、challenge、reasoning、plan），不必全部包含四种模式。例如，执行者角色更侧重于reasoning和challenge，而设计者或决策者则更需要exploration和plan。可根据实际需求进行裁剪和组合，以适应不同的思考任务和角色分工。
|
||||||
Reference in New Issue
Block a user