删除多个不再使用的协议文档，包括memory、dpml、execution、resource和thought协议，清理代码库以提高可维护性。
This commit is contained in:
sean
@ -1,251 +0,0 @@
|
||||
# DPML 模式协议
|
||||
|
||||
> **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适用于所有需要结构化表达提示词的场景，包括但不限于AI助手开发、复杂任务指令设计、自动化工作流程等。
|
||||
|
||||
### 相关协议
|
||||
|
||||
- **XML**: DPML的基本标签结构借鉴了XML
|
||||
- **Markdown**: DPML的内容部分采用Markdown格式
|
||||
|
||||
## 📝 语法规则
|
||||
|
||||
### 形式化定义
|
||||
|
||||
```ebnf
|
||||
document ::= element | (element document)
|
||||
element ::= '<' tag attributes '>' content '</' tag '>' | '<' tag attributes '/>'
|
||||
tag ::= [namespace ':'] name
|
||||
namespace ::= name
|
||||
name ::= [A-Za-z][A-Za-z0-9_-]*
|
||||
attributes ::= (attribute attributes) | ε
|
||||
attribute ::= name '="' value '"'
|
||||
value ::= [^"]*
|
||||
content ::= markdown_text | (element content) | ε
|
||||
markdown_text ::= (* 任何有效的Markdown文本 *)
|
||||
```
|
||||
|
||||
### 词法元素
|
||||
|
||||
| 元素 | 形式 | 描述 |
|
||||
|------|------|------|
|
||||
| 标签 | `<tag>...</tag>` | 定义语义单元，如`<thinking>`,`<executing>` |
|
||||
| 自闭合标签 | `<tag />` | 无内容的标签，如`<import />` |
|
||||
| 属性 | `property="value"` | 标签配置信息，如`type="analysis"` |
|
||||
| 内容 | Markdown格式文本 | 标签内的实际提示词文本 |
|
||||
| 注释 | `<!-- comment -->` | 协议注释，不作为提示词内容 |
|
||||
|
||||
### 组合规则
|
||||
|
||||
1. 标签可以嵌套，形成层次结构
|
||||
2. 一个标签可以有多个属性，属性名在同一标签中不能重复
|
||||
3. 标签必须正确闭合，要么是配对标签`<tag></tag>`，要么是自闭合标签`<tag/>`
|
||||
4. 内容部分可以是纯Markdown文本，也可以包含其他标签
|
||||
5. 根元素推荐使用`<prompt>`，但不强制要求
|
||||
|
||||
## 🧩 语义定义
|
||||
|
||||
### 核心概念
|
||||
|
||||
| 概念 | 定义 | 示例 |
|
||||
|------|------|------|
|
||||
| 提示单元 | 由标签定义的语义完整的提示组件 | `<thinking>分析问题...</thinking>` |
|
||||
| 属性修饰 | 通过属性细化提示单元的行为特性 | `<executing priority="high">` |
|
||||
| 内容表达 | 使用Markdown表达的实际提示文本 | `# 步骤\n1. 首先...` |
|
||||
| 组合提示 | 多个提示单元组合形成完整提示 | `<thinking>...</thinking><executing>...</executing>` |
|
||||
|
||||
### 命名空间绑定
|
||||
|
||||
命名空间是DPML的核心语义机制，用于表达标签间的语义继承和协议复用：
|
||||
|
||||
1. **协议实现绑定**：通过命名空间前缀表示一个标签通过特定协议实现
|
||||
```xml
|
||||
<store:execution>
|
||||
<!-- 表示store标签通过execution协议实现 -->
|
||||
</store:execution>
|
||||
```
|
||||
|
||||
在DPML中，`A:B`表示"A通过B实现"，读作"A implemented with B"。冒号左侧表示"做什么"(功能)，右侧表示"怎么做"(实现方式)。
|
||||
|
||||
2. **多协议组合**：一个标签可以通过不同命名空间的子标签组合多个协议
|
||||
```xml
|
||||
<memory>
|
||||
<store:execution>存储操作...</store:execution>
|
||||
<recall:resource>检索操作...</recall:resource>
|
||||
</memory>
|
||||
```
|
||||
|
||||
3. **协议继承关系**：命名空间前缀表示标签继承了指定协议的所有结构和规则
|
||||
```xml
|
||||
<!-- memory协议中的store子标签通过execution协议实现 -->
|
||||
<memory>
|
||||
<store:execution>
|
||||
<process>...</process>
|
||||
<rule>...</rule>
|
||||
</store:execution>
|
||||
</memory>
|
||||
```
|
||||
|
||||
### 解释规则
|
||||
|
||||
1. 标签名决定提示单元的主要语义类型（思考、执行等）
|
||||
2. 属性提供额外的控制和元数据，影响提示单元的解释方式
|
||||
3. 内容部分按Markdown语法解析，保留其格式特性（标题、列表、强调等）
|
||||
4. 嵌套标签表示包含关系，内层提示单元属于外层提示单元的组成部分
|
||||
5. 同级标签按顺序解释，表示提示流程的先后次序
|
||||
|
||||
|
||||
## 📋 使用示例
|
||||
|
||||
### 有效示例
|
||||
|
||||
**1. 基本思考-执行流程**
|
||||
```
|
||||
<prompt>
|
||||
<thinking type="analysis">
|
||||
# 问题分析
|
||||
这是一个**数据处理**问题，需要考虑：
|
||||
1. 数据格式转换
|
||||
2. 性能优化
|
||||
</thinking>
|
||||
|
||||
<executing>
|
||||
# 执行步骤
|
||||
1. 首先读取输入文件
|
||||
2. 应用转换算法
|
||||
3. 输出结果到目标位置
|
||||
|
||||
确保全程**记录日志**以便调试。
|
||||
</executing>
|
||||
</prompt>
|
||||
```
|
||||
|
||||
**2. 带属性的复杂结构**
|
||||
```
|
||||
<prompt>
|
||||
<context type="background">
|
||||
# 项目背景
|
||||
客户需要一个数据可视化dashboard。
|
||||
</context>
|
||||
|
||||
<thinking type="design" priority="high">
|
||||
# 设计思路
|
||||
采用模块化设计，分离数据层和视图层。
|
||||
|
||||
<concept id="arch" domain="frontend">
|
||||
## 架构概念
|
||||
使用React + D3.js组合
|
||||
</concept>
|
||||
</thinking>
|
||||
|
||||
<executing steps="3">
|
||||
# 实现步骤
|
||||
1. 搭建基础框架
|
||||
2. 实现数据连接器
|
||||
3. 开发可视化组件
|
||||
</executing>
|
||||
</prompt>
|
||||
```
|
||||
|
||||
**3. 资源引用**
|
||||
```
|
||||
<prompt>
|
||||
<resource type="reference" src="docs/api-spec.md">
|
||||
参考API规范文档
|
||||
|
||||
API端点定义在源码的25-35行
|
||||
</resource>
|
||||
|
||||
<thinking>
|
||||
基于API规范进行设计...
|
||||
</thinking>
|
||||
</prompt>
|
||||
```
|
||||
|
||||
**4. 跨协议组合示例**
|
||||
```
|
||||
<memory>
|
||||
<!-- 存储操作通过execution协议实现 -->
|
||||
<store:execution>
|
||||
<content>用户操作系统：MacOS 13.4</content>
|
||||
|
||||
<process>
|
||||
# 存储流程
|
||||
```mermaid
|
||||
flowchart TD
|
||||
A[接收内容] --> B[验证格式]
|
||||
B --> C[写入存储]
|
||||
```
|
||||
</process>
|
||||
|
||||
<rule>
|
||||
1. 记忆写入必须原子化
|
||||
2. 冲突时保留高置信度版本
|
||||
</rule>
|
||||
</store:execution>
|
||||
|
||||
<!-- 检索操作通过resource协议实现 -->
|
||||
<recall:resource>
|
||||
@memory://system/os_info?confidence=0.8
|
||||
</recall:resource>
|
||||
</memory>
|
||||
```
|
||||
|
||||
### 无效示例
|
||||
|
||||
**1. 标签未闭合**
|
||||
```
|
||||
<prompt>
|
||||
<thinking>
|
||||
思考内容...
|
||||
<!-- 缺少</thinking>标签 -->
|
||||
|
||||
<executing>
|
||||
执行步骤...
|
||||
</executing>
|
||||
</prompt>
|
||||
```
|
||||
错误原因：`<thinking>`标签未正确闭合
|
||||
|
||||
**2. 属性格式错误**
|
||||
```
|
||||
<prompt>
|
||||
<thinking type=analysis>
|
||||
思考内容...
|
||||
</thinking>
|
||||
</prompt>
|
||||
```
|
||||
错误原因：属性值缺少双引号，应为`type="analysis"`
|
||||
|
||||
## 💡 最佳实践
|
||||
|
||||
1. **标签命名自释义**：选择具有自解释性的标签名称，使其本身就能清晰表达逻辑语义，即使没有计算机处理，人和AI也能轻松理解标签结构的逻辑上下文
|
||||
2. **语义清晰度**：选择表意明确的标签名，让提示结构一目了然
|
||||
3. **适度分层**：合理使用嵌套结构，避免过深的层次导致可读性下降
|
||||
4. **内容聚焦**：每个标签内容应关注单一职责，避免功能混杂
|
||||
5. **属性合理性**：只使用必要的属性，避免过度配置
|
||||
6. **一致性**：在整个项目中保持一致的DPML结构风格
|
||||
7. **命名空间明确性**：使用命名空间时，确保左侧表示"做什么"(功能)，右侧表示"怎么做"(实现)
|
||||
|
||||
## 📌 总结
|
||||
|
||||
DPML通过结合标签语言的结构化能力和Markdown的内容表现力，为提示词工程提供了一种既规范又灵活的表达方式。其核心优势在于清晰的语义结构、协议复用机制和人类可读性，特别适合构建复杂、模块化的AI交互提示系统。
|
||||
|
||||
@ -1,22 +1,14 @@
|
||||
# execution 应用协议
|
||||
# DPML执行模式提示词框架
|
||||
|
||||
> **TL;DR:** execution标签用于定义结构化的执行框架，帮助AI系统完成任务，包含流程(Process)、指导原则(Guideline)、强制规则(Rule)、约束条件(Constraint)和评价标准(Criteria)五个核心子概念。
|
||||
|
||||
## 🔍 基本信息
|
||||
|
||||
**标签名:** `<execution>`
|
||||
**版本:** 1.0.0
|
||||
**类别:** 执行
|
||||
**状态:** 草稿
|
||||
**创建日期:** 2023-06-21
|
||||
> **TL;DR:** DPML执行模式提示词框架定义了结构化的执行类提示词模板，包含流程(Process)、指导原则(Guideline)、强制规则(Rule)、约束条件(Constraint)和评价标准(Criteria)五个核心子概念，用于指导AI系统完成具体任务。
|
||||
|
||||
### 目的与功能
|
||||
|
||||
execution标签定义了AI系统执行任务的完整框架，它的主要功能是：
|
||||
- 提供执行任务的结构化定义
|
||||
- 明确执行的流程步骤、指导原则、规则、约束和评价标准
|
||||
- 帮助AI系统进行精确、可靠的任务执行
|
||||
- 提供执行状态追踪和错误处理机制
|
||||
DPML执行模式提示词框架定义了AI系统执行任务的提示词模板，它的主要功能是：
|
||||
- 提供执行任务的结构化提示词定义
|
||||
- 通过标准化提示词明确执行的流程步骤、指导原则、规则、约束和评价标准
|
||||
- 帮助AI系统通过规范化提示词进行精确、可靠的任务执行
|
||||
- 提供执行状态追踪和错误处理的提示词模板
|
||||
|
||||
## 📝 语法定义
|
||||
|
||||
@ -50,176 +42,19 @@ execution标签表示一个完整的执行框架。标签内容可以包含五
|
||||
|
||||
这五个子概念构成了完整的执行框架，从不同维度定义了AI系统如何执行任务。
|
||||
|
||||
## 💡 最佳实践
|
||||
|
||||
以下是使用execution标签的一些建议做法，这些并非强制要求，仅作为参考：
|
||||
|
||||
### 优先级关系
|
||||
|
||||
execution框架内的子概念具有内在的优先级关系：
|
||||
execution框架内的子概念具有以下固定的优先级关系，这种关系定义了如何理解和解释这些概念：
|
||||
|
||||
1. **Constraint(约束)** - 最高优先级，不可违反
|
||||
2. **Rule(规则)** - 次高优先级，必须遵循
|
||||
3. **Guideline(指导原则)** - 较低优先级，推荐遵循但可灵活调整
|
||||
4. **Process(流程)** - 定义执行路径，需在约束、规则框架内实施
|
||||
5. **Criteria(标准)** - 评价依据，用于验证执行结果
|
||||
1. **Constraint(约束)** - 最高优先级，表示客观存在的限制，不可违反
|
||||
2. **Rule(规则)** - 次高优先级，表示必须遵循的行为准则
|
||||
3. **Guideline(指导原则)** - 较低优先级，表示可灵活调整的建议性原则
|
||||
4. **Process(流程)** - 在约束和规则的框架内定义执行路径
|
||||
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标签用于定义资源协议，提供统一的资源引用方式，支持通过`@协议名://路径`形式访问各类资源。
|
||||
|
||||
## 🔍 基本信息
|
||||
|
||||
**标签名:** `<resource>`
|
||||
**版本:** 1.0.0
|
||||
**类别:** 资源
|
||||
**状态:** 草稿
|
||||
**创建日期:** 2023-06-30
|
||||
> **TL;DR:** DPML资源模式提示词框架定义了统一的资源引用提示词模板，支持通过`@协议名://路径`形式在提示词中访问和操作各类资源。
|
||||
|
||||
### 目的与功能
|
||||
|
||||
resource标签用于定义特定类型的资源协议，使开发者能够以标准化的方式描述如何引用和处理各种资源。通过这个标签，可以明确资源的引用语法、路径规则和查询参数，确保资源引用在不同环境中的一致性和可靠性。此标签是PromptX中资源引用协议（RP）在应用层面的具体实现方式。
|
||||
DPML资源模式提示词框架用于定义特定类型的资源访问提示词，使开发者能够以标准化的方式在提示词中描述如何引用和处理各种资源。通过这个框架，可以明确资源提示词的引用语法、路径规则和查询参数，确保资源引用在不同环境中的一致性和可靠性。此框架是PromptX中资源引用协议（RP）在提示词层面的具体实现方式。
|
||||
|
||||
主要功能包括：
|
||||
- 定义资源协议的标识和引用方式
|
||||
- 规范资源路径的语法结构和解析规则
|
||||
- 指定资源支持的查询参数和格式
|
||||
- 提供资源使用的示例说明
|
||||
- 定义资源提示词的标识和引用方式
|
||||
- 规范化资源路径的提示词语法结构和解析规则
|
||||
- 指定资源提示词支持的查询参数和格式
|
||||
- 提供资源类提示词的标准化示例
|
||||
|
||||
### 默认支持的通用协议
|
||||
|
||||
@ -49,17 +41,7 @@ markdown_content ::= (* 任何有效的Markdown文本，包括代码块、表格
|
||||
|
||||
## 🧩 语义说明
|
||||
|
||||
resource标签定义了一个资源协议，指定了如何使用`@协议名://路径`的形式引用和访问特定类型的资源。
|
||||
|
||||
标签包含的主要子元素及其语义：
|
||||
|
||||
- **protocol属性**：定义资源协议的名称，如`file`、`http`、`context`等
|
||||
- **location子标签**：定义资源路径的格式和规则，指定如何定位资源
|
||||
- **params子标签**：定义资源支持的查询参数，指定如何处理资源的特定部分或格式
|
||||
|
||||
### 资源引用语法
|
||||
|
||||
资源引用使用`@`符号作为统一入口，遵循以下核心语法规则：
|
||||
resource标签定义了一个资源协议，指定了如何使用`@`符号作为统一入口，遵循以下核心语法规则：
|
||||
|
||||
```ebnf
|
||||
resource_reference ::= '@' protocol_name ':' resource_location [query_params]
|
||||
|
||||
@ -1,23 +1,15 @@
|
||||
# thought 应用协议
|
||||
# DPML思考模式提示词框架
|
||||
|
||||
> **TL;DR:** thought标签用于定义结构化的思考框架，帮助AI系统进行系统性分析和推理，支持四种思维模式：横向探索(exploration)、纵向推理(reasoning)、流程计划(plan)和批判挑战(challenge)。
|
||||
|
||||
## 🔍 基本信息
|
||||
|
||||
**标签名:** `<thought>`
|
||||
**版本:** 1.0.0
|
||||
**类别:** 思考
|
||||
**状态:** 草稿
|
||||
**创建日期:** 2023-06-20
|
||||
> **TL;DR:** DPML思考模式提示词框架定义了结构化的思考类提示词模板，支持四种核心思维模式的提示词构建：横向探索(exploration)、纵向推理(reasoning)、流程计划(plan)和批判挑战(challenge)，帮助AI系统进行系统性分析和推理。
|
||||
|
||||
### 目的与功能
|
||||
|
||||
thought标签定义了AI系统进行思考分析的框架和流程，它的主要功能是：
|
||||
- 提供结构化的思维分析模式
|
||||
- 组织和展示概念关系与逻辑推理
|
||||
- 支持可视化思维导图和决策树
|
||||
- 帮助AI系统进行系统性、全面性的问题分析
|
||||
- 区分不同类型的思维模式：探索、推理、计划和挑战
|
||||
DPML思考模式提示词框架定义了AI系统进行思考分析的提示词模板和结构，它的主要功能是：
|
||||
- 提供结构化的思维分析提示词模板
|
||||
- 规范化思考类提示词的组织方式
|
||||
- 支持可视化思维导图和决策树的提示词表达
|
||||
- 帮助AI系统通过标准化提示词进行系统性、全面性的问题分析
|
||||
- 区分不同类型的思维模式提示词：探索、推理、计划和挑战
|
||||
|
||||
## 📝 语法定义
|
||||
|
||||
@ -51,220 +43,18 @@ exploration和challenge是一对思维模式的正反两面：exploration向外
|
||||
|
||||
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>
|
||||
对于提示词的理解者来说，只需知道这些子标签不是必须全部出现，遇到哪些子标签就理解哪些即可，无需关心未出现的部分。
|
||||
|
||||
Reference in New Issue
Block a user