更新bootstrap.md文档，调整角色路径为提示词开发者，确保用户理解角色代入要求；更新prompt-developer.role.md文档，新增术语模式最佳实践，提升提示词开发的规范性；更新dpml.protocol.md文档，修正语义描述，确保一致性；更新多个标签文档，统一术语和格式，提升文档的清晰度和可读性。
This commit is contained in:
sean
@ -1,11 +1,11 @@
|
||||
# Deepractice提示词标记语言模式协议 (DPML)
|
||||
|
||||
> **TL;DR:** DPML(Deepractice Prompt Markup Language)是一种专为提示词工程设计的标记语言，结合了XML结构和Markdown内容，为各类提示词提供标准化的表达框架，确保提示词的结构清晰性和语义准确性。
|
||||
> **TL;DR:** DPML(Deepractice Prompt Markup Language)是一种专为#提示词 工程设计的标记语言，结合了#标签（XML结构）和#内容（Markdown内容），为各类提示词提供标准化的表达框架，确保提示词的结构清晰性和语义准确性。
|
||||
|
||||
### 目的与范围
|
||||
|
||||
DPML旨在为提示词工程提供一种标准化的表达方式，解决以下关键问题：
|
||||
- 为不同类型的提示词提供清晰的语义结构（思考类、执行类等）
|
||||
- 为不同类型的提示词提供清晰的#语义结构（思考类、执行类等）
|
||||
- 保持提示词的自然语言表达能力和灵活性
|
||||
- 支持提示词的模块化组织和复用
|
||||
- 确保提示词的机器可解析性和人类可读性
|
||||
@ -20,11 +20,11 @@ DPML适用于所有需要结构化表达提示词的场景，包括但不限于
|
||||
|
||||
DPML的核心设计理念基于以下关键思想:
|
||||
|
||||
1. **自然语言驱动**: DPML认为提示词本质上是自然语言的结构化表达，而非传统编程语言。标记结构仅用于提供语义边界，内容仍以自然语言为主。
|
||||
1. **自然语言驱动**: DPML认为提示词本质上是自然语言的结构化表达，而非传统编程语言。#标签结构仅用于提供#语义边界，#内容仍以自然语言为主。
|
||||
|
||||
2. **释义即实现**: DPML中，对提示词的语义释义本身就构成了实现。当AI系统理解一个提示词的语义后，无需额外的转换层，该理解过程即为执行过程。
|
||||
2. **释义即实现**: DPML中，对提示词的#语义释义本身就构成了#实现。当AI系统理解一个提示词的语义后，无需额外的转换层，该理解过程即为执行过程。
|
||||
|
||||
3. **语义透明性**: 标签和属性名称具有自解释性，使人类和AI都能直观理解结构的意图和功能。
|
||||
3. **语义透明性**: #标签和#属性名称具有自解释性，使人类和AI都能直观理解结构的意图和功能。
|
||||
|
||||
4. **组合复用**: 通过协议实现绑定(`A:B`语法)，简单协议可组合构建复杂功能，实现"积木式"提示词工程。
|
||||
|
||||
@ -34,8 +34,8 @@ DPML的核心设计理念基于以下关键思想:
|
||||
|
||||
### 相关协议
|
||||
|
||||
- **XML**: DPML的基本标签结构借鉴了XML
|
||||
- **Markdown**: DPML的内容部分采用Markdown格式
|
||||
- **XML**: DPML的基本#标签结构借鉴了XML
|
||||
- **Markdown**: DPML的#内容部分采用Markdown格式
|
||||
|
||||
## 📝 语法规则
|
||||
|
||||
@ -58,18 +58,18 @@ markdown_text ::= (* 任何有效的Markdown文本 *)
|
||||
|
||||
| 元素 | 形式 | 描述 |
|
||||
|------|------|------|
|
||||
| 标签 | `<tag>...</tag>` | 定义语义单元，如`<thinking>`,`<executing>` |
|
||||
| 自闭合标签 | `<tag />` | 无内容的标签，如`<import />` |
|
||||
| 属性 | `property="value"` | 标签配置信息，如`type="analysis"` |
|
||||
| 内容 | Markdown格式文本 | 标签内的实际提示词文本 |
|
||||
| #标签 | `<tag>...</tag>` | 定义#语义单元，如`<thinking>`,`<executing>` |
|
||||
| #自闭合标签 | `<tag />` | 无内容的标签，如`<import />` |
|
||||
| #属性 | `property="value"` | #标签配置信息，如`type="analysis"` |
|
||||
| #内容 | Markdown格式文本 | #标签内的实际提示词文本 |
|
||||
| 注释 | `<!-- comment -->` | 协议注释，不作为提示词内容 |
|
||||
|
||||
### 组合规则
|
||||
|
||||
1. 标签可以嵌套，形成层次结构
|
||||
2. 一个标签可以有多个属性，属性名在同一标签中不能重复
|
||||
3. 标签必须正确闭合，要么是配对标签`<tag></tag>`，要么是自闭合标签`<tag/>`
|
||||
4. 内容部分可以是纯Markdown文本，也可以包含其他标签
|
||||
1. #标签可以嵌套，形成层次结构
|
||||
2. 一个#标签可以有多个#属性，属性名在同一标签中不能重复
|
||||
3. #标签必须正确闭合，要么是配对标签`<tag></tag>`，要么是#自闭合标签`<tag/>`
|
||||
4. #内容部分可以是纯Markdown文本，也可以包含其他#标签
|
||||
5. 根元素推荐使用`<prompt>`，但不强制要求
|
||||
|
||||
## 🧩 语义定义
|
||||
@ -78,38 +78,38 @@ markdown_text ::= (* 任何有效的Markdown文本 *)
|
||||
|
||||
| 概念 | 定义 | 示例 |
|
||||
|------|------|------|
|
||||
| 提示单元 | 由标签定义的语义完整的提示组件 | `<thinking>分析问题...</thinking>` |
|
||||
| 属性修饰 | 通过属性细化提示单元的行为特性 | `<executing priority="high">` |
|
||||
| 内容表达 | 使用Markdown表达的实际提示文本 | `# 步骤\n1. 首先...` |
|
||||
| 组合提示 | 多个提示单元组合形成完整提示 | `<thinking>...</thinking><executing>...</executing>` |
|
||||
| #提示单元 | 由#标签定义的语义完整的提示组件 | `<thinking>分析问题...</thinking>` |
|
||||
| #属性修饰 | 通过#属性细化#提示单元的行为特性 | `<executing priority="high">` |
|
||||
| #内容表达 | 使用Markdown表达的实际提示文本 | `# 步骤\n1. 首先...` |
|
||||
| #组合提示 | 多个#提示单元组合形成完整提示 | `<thinking>...</thinking><executing>...</executing>` |
|
||||
|
||||
### 属性约束
|
||||
|
||||
DPML对属性采用以下约束和规范：
|
||||
DPML对#属性采用以下约束和规范：
|
||||
|
||||
1. **属性的通用性原则**：
|
||||
- 属性是通用机制，可应用于任何标签
|
||||
- 同一属性可用于不同标签，但语义一致
|
||||
- 属性独立于标签单独定义，不绑定于特定标签
|
||||
- #属性是通用机制，可应用于任何#标签
|
||||
- 同一#属性可用于不同#标签，但语义一致
|
||||
- #属性独立于#标签单独定义，不绑定于特定#标签
|
||||
|
||||
2. **属性定义原则**：
|
||||
- DPML本身不预定义具体属性，仅提供属性的语法框架
|
||||
- 所有使用的属性必须在具体协议或属性规范中明确定义
|
||||
- 未定义的属性不允许使用
|
||||
- 属性值必须符合规定的类型和范围
|
||||
- DPML本身不预定义具体#属性，仅提供#属性的语法框架
|
||||
- 所有使用的#属性必须在具体协议或属性规范中明确定义
|
||||
- 未定义的#属性不允许使用
|
||||
- #属性值必须符合规定的类型和范围
|
||||
|
||||
3. **属性规范管理**：
|
||||
- 属性在单独的属性规范文档中定义
|
||||
- 每个属性定义包括：名称、数据类型、适用范围、语义
|
||||
- 新属性需遵循规范化流程引入
|
||||
- #属性在单独的属性规范文档中定义
|
||||
- 每个#属性定义包括：名称、数据类型、适用范围、语义
|
||||
- 新#属性需遵循规范化流程引入
|
||||
- 兼容性变更需考虑向后兼容性
|
||||
|
||||
|
||||
属性约束确保提示词的一致性和互操作性。在使用DPML开发提示词时，开发者应遵循已定义的属性规范，不得创建私有或未文档化的属性。
|
||||
#属性约束确保提示词的一致性和互操作性。在使用DPML开发提示词时，开发者应遵循已定义的#属性规范，不得创建私有或未文档化的#属性。
|
||||
|
||||
### 协议实现绑定
|
||||
|
||||
DPML中的冒号(`:`)语法是核心语义机制，用于表达标签间的实现关系：
|
||||
DPML中的冒号(`:`)语法是核心语义机制，用于表达#标签间的实现关系：
|
||||
|
||||
1. **基本实现绑定**：通过冒号表示一个功能通过特定协议实现
|
||||
```xml
|
||||
@ -120,7 +120,7 @@ DPML中的冒号(`:`)语法是核心语义机制，用于表达标签间的实
|
||||
|
||||
在DPML中，`A:B`表示"A通过B实现"，读作"A implemented with B"。冒号左侧表示"做什么"(功能)，右侧表示"怎么做"(实现方式)。
|
||||
|
||||
2. **实现继承行为**：当使用`<A:B>`形式时，A标签继承B协议的全部结构规则和语义特征。例如：
|
||||
2. **实现继承行为**：当使用`<A:B>`形式时，A#标签继承B协议的全部结构规则和语义特征。例如：
|
||||
```xml
|
||||
<store:execution>
|
||||
<process>...</process> <!-- 来自execution协议的子标签 -->
|
||||
@ -150,11 +150,11 @@ DPML中的冒号(`:`)语法是核心语义机制，用于表达标签间的实
|
||||
|
||||
### 解释规则
|
||||
|
||||
1. 标签名决定提示单元的主要语义类型（思考、执行等）
|
||||
2. 属性提供额外的控制和元数据，影响提示单元的解释方式
|
||||
3. 内容部分按Markdown语法解析，保留其格式特性（标题、列表、强调等）
|
||||
4. 嵌套标签表示包含关系，内层提示单元属于外层提示单元的组成部分
|
||||
5. 同级标签按顺序解释，表示提示流程的先后次序
|
||||
1. #标签名决定#提示单元的主要语义类型（思考、执行等）
|
||||
2. #属性提供额外的控制和元数据，影响#提示单元的解释方式
|
||||
3. #内容部分按Markdown语法解析，保留其格式特性（标题、列表、强调等）
|
||||
4. #嵌套标签表示包含关系，内层#提示单元属于外层#提示单元的组成部分
|
||||
5. 同级#标签按顺序解释，表示提示流程的先后次序
|
||||
|
||||
|
||||
## 📋 使用示例
|
||||
|
||||
Reference in New Issue
Block a user