删除多个不再使用的协议文档，包括命令执行思维框架、上下文协议、经验协议、角色协议、任务协议和资源引用协议，清理代码库以提高可维护性。
This commit is contained in:
sean
@ -33,10 +33,11 @@ DPML适用于所有需要结构化表达提示词的场景，包括但不限于A
|
||||
```ebnf
|
||||
document ::= element | (element document)
|
||||
element ::= '<' tag attributes '>' content '</' tag '>' | '<' tag attributes '/>'
|
||||
tag ::= name
|
||||
tag ::= [namespace ':'] name
|
||||
namespace ::= name
|
||||
name ::= [A-Za-z][A-Za-z0-9_-]*
|
||||
attributes ::= (attribute attributes) | ε
|
||||
attribute ::= name '="' value '"'
|
||||
name ::= [A-Za-z][A-Za-z0-9_-]*
|
||||
value ::= [^"]*
|
||||
content ::= markdown_text | (element content) | ε
|
||||
markdown_text ::= (* 任何有效的Markdown文本 *)
|
||||
@ -71,6 +72,38 @@ markdown_text ::= (* 任何有效的Markdown文本 *)
|
||||
| 内容表达 | 使用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. 标签名决定提示单元的主要语义类型（思考、执行等）
|
||||
@ -79,70 +112,6 @@ markdown_text ::= (* 任何有效的Markdown文本 *)
|
||||
4. 嵌套标签表示包含关系，内层提示单元属于外层提示单元的组成部分
|
||||
5. 同级标签按顺序解释，表示提示流程的先后次序
|
||||
|
||||
## ✅ 约束与验证
|
||||
|
||||
### 必要约束
|
||||
|
||||
1. 标签名必须符合命名规则：以字母开头，可包含字母、数字、下划线和连字符
|
||||
2. 属性值必须使用双引号包围
|
||||
3. 标签必须正确闭合，开闭标签名称必须一致
|
||||
4. 标签嵌套必须正确，不允许交叉嵌套
|
||||
5. Markdown内容必须是有效的Markdown语法
|
||||
|
||||
### 验证规则
|
||||
|
||||
DPML文档可通过以下步骤验证：
|
||||
1. 检查XML结构的有效性（标签配对、属性格式等）
|
||||
2. 验证标签名是否属于预定义集合或符合扩展规则
|
||||
3. 检查必需属性是否存在且值有效
|
||||
4. 验证Markdown内容的格式有效性
|
||||
5. 检查引用资源的可访问性
|
||||
|
||||
### 错误处理
|
||||
|
||||
遇到语法错误时的处理优先级：
|
||||
1. 标签结构错误（未闭合、交叉嵌套）：终止解析，报告错误位置
|
||||
2. 未知标签或属性：发出警告但继续解析，将其视为自定义扩展
|
||||
3. Markdown语法错误：尽可能宽容处理，按文本呈现
|
||||
4. 资源引用错误：报告无法访问的资源，但继续处理其他内容
|
||||
|
||||
## 🔄 扩展机制
|
||||
|
||||
### 扩展点
|
||||
|
||||
DPML提供以下扩展点：
|
||||
1. 自定义标签：通过命名空间机制创建新的语义标签
|
||||
2. 自定义属性：为现有标签添加新的控制属性
|
||||
3. 内容增强：在Markdown中嵌入特殊语法或命令
|
||||
4. 外部引用：导入和复用外部DPML组件
|
||||
|
||||
### 扩展规则
|
||||
|
||||
1. 自定义标签应使用命名空间前缀：`<ns:tag>`
|
||||
2. 自定义属性可直接添加，但建议使用命名空间：`ns:property="value"`
|
||||
3. 内容增强应使用明确的语法标记，避免与Markdown冲突
|
||||
4. 扩展必须向下兼容，标准解析器应能忽略无法理解的扩展而不中断处理
|
||||
|
||||
### 扩展示例
|
||||
|
||||
```xml
|
||||
<!-- 命名空间定义 -->
|
||||
<prompt xmlns:ai="https://promptx.ai/ns/ai">
|
||||
<!-- 自定义标签 -->
|
||||
<ai:model type="gpt4">
|
||||
<!-- 标准标签 -->
|
||||
<thinking>
|
||||
# 分析方法
|
||||
使用**系统思维**方法
|
||||
</thinking>
|
||||
|
||||
<!-- 自定义属性 -->
|
||||
<executing ai:temperature="0.7">
|
||||
执行步骤...
|
||||
</executing>
|
||||
</ai:model>
|
||||
</prompt>
|
||||
```
|
||||
|
||||
## 📋 使用示例
|
||||
|
||||
@ -211,6 +180,35 @@ DPML提供以下扩展点：
|
||||
</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. 标签未闭合**
|
||||
@ -239,19 +237,15 @@ DPML提供以下扩展点：
|
||||
|
||||
## 💡 最佳实践
|
||||
|
||||
1. **语义清晰度**：选择表意明确的标签名，让提示结构一目了然
|
||||
2. **适度分层**：合理使用嵌套结构，避免过深的层次导致可读性下降
|
||||
3. **内容聚焦**：每个标签内容应关注单一职责，避免功能混杂
|
||||
4. **属性合理性**：只使用必要的属性，避免过度配置
|
||||
5. **一致性**：在整个项目中保持一致的DPML结构风格
|
||||
1. **标签命名自释义**：选择具有自解释性的标签名称，使其本身就能清晰表达逻辑语义，即使没有计算机处理，人和AI也能轻松理解标签结构的逻辑上下文
|
||||
2. **语义清晰度**：选择表意明确的标签名，让提示结构一目了然
|
||||
3. **适度分层**：合理使用嵌套结构，避免过深的层次导致可读性下降
|
||||
4. **内容聚焦**：每个标签内容应关注单一职责，避免功能混杂
|
||||
5. **属性合理性**：只使用必要的属性，避免过度配置
|
||||
6. **一致性**：在整个项目中保持一致的DPML结构风格
|
||||
7. **命名空间明确性**：使用命名空间时，确保左侧表示"做什么"(功能)，右侧表示"怎么做"(实现)
|
||||
|
||||
### 常见问题
|
||||
## 📌 总结
|
||||
|
||||
**Q: DPML与纯Markdown相比有什么优势？**
|
||||
A: DPML提供了语义结构，使提示词的不同部分（思考、执行等）有明确区分，便于解析和处理，同时保留了Markdown的灵活性。
|
||||
DPML通过结合标签语言的结构化能力和Markdown的内容表现力，为提示词工程提供了一种既规范又灵活的表达方式。其核心优势在于清晰的语义结构、协议复用机制和人类可读性，特别适合构建复杂、模块化的AI交互提示系统。
|
||||
|
||||
**Q: 如何在DPML中引用外部资源？**
|
||||
A: 可以通过标签属性引用外部资源，如`<resource src="path/to/file">`，或使用特定的资源引用语法（参见资源引用协议）。
|
||||
|
||||
**Q: DPML的解析器需要特殊实现吗？**
|
||||
A: DPML可以通过组合现有的XML解析器和Markdown解析器实现，先解析XML结构，再处理各标签内的Markdown内容。
|
||||
Reference in New Issue
Block a user