refactor: 重构/prompt/目录为/resource/ - 更符合资源引用协议语义
- 重命名核心目录: /prompt/ → /resource/ - 更新PackageDiscovery中所有硬编码路径引用 - 重新生成package.registry.json，61个资源全部更新为@package://resource/路径 - 批量更新文档中的路径引用，保持一致性 - 目录结构保持不变：domain/, core/, protocol/, tool/子目录结构完全一致 重构原因: 随着tool协议的加入，prompt目录名称不再准确描述系统本质 重构价值: 为未来资源生态扩展奠定清晰的命名基础 🤖 Generated with [Claude Code](https://claude.ai/code) Co-Authored-By: Claude <noreply@anthropic.com>
This commit is contained in:
sean
306
resource/protocol/dpml.protocol.md
Normal file
306
resource/protocol/dpml.protocol.md
Normal file
@ -0,0 +1,306 @@
|
||||
# Deepractice提示词标记语言模式协议 (DPML)
|
||||
|
||||
> **TL;DR:** DPML(Deepractice Prompt Markup Language)是一种专为#提示词 工程设计的标记语言，结合了#标签（XML结构）和#内容（Markdown内容），为各类提示词提供标准化的表达框架，确保提示词的结构清晰性和语义准确性。
|
||||
|
||||
### 目的与范围
|
||||
|
||||
DPML旨在为提示词工程提供一种标准化的表达方式，解决以下关键问题：
|
||||
- 为不同类型的提示词提供清晰的#语义结构（思考类、执行类等）
|
||||
- 保持提示词的自然语言表达能力和灵活性
|
||||
- 支持提示词的模块化组织和复用
|
||||
- 确保提示词的机器可解析性和人类可读性
|
||||
|
||||
DPML适用于所有需要结构化表达提示词的场景，包括但不限于：
|
||||
- AI助手的提示词系统
|
||||
- 复杂任务的指令设计
|
||||
- 自动化工作流的提示词定义
|
||||
- 知识管理的提示词组织
|
||||
|
||||
### 设计思想
|
||||
|
||||
DPML的核心设计理念基于以下关键思想:
|
||||
|
||||
1. **自然语言驱动**: DPML认为提示词本质上是自然语言的结构化表达，而非传统编程语言。#标签结构仅用于提供#语义边界，#内容仍以自然语言为主。
|
||||
|
||||
2. **释义即实现**: DPML中，对提示词的#语义释义本身就构成了#实现。当AI系统理解一个提示词的语义后，无需额外的转换层，该理解过程即为执行过程。
|
||||
|
||||
3. **语义透明性**: #标签和#属性名称具有自解释性，使人类和AI都能直观理解结构的意图和功能。
|
||||
|
||||
4. **组合复用**: 通过协议实现绑定(`A:B`语法)，简单协议可组合构建复杂功能，实现"积木式"提示词工程。
|
||||
|
||||
5. **一致性理解**: 同一DPML结构应在不同AI系统中产生一致理解和行为，确保提示词的可移植性和稳定性。
|
||||
|
||||
这些设计思想指导DPML的所有协议设计，使提示词既具备结构化的机器可解析性，又保持自然语言的表达力和灵活性。
|
||||
|
||||
### 相关协议
|
||||
|
||||
- **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. **属性的通用性原则**：
|
||||
- #属性是通用机制，可应用于任何#标签
|
||||
- 同一#属性可用于不同#标签，但语义一致
|
||||
- #属性独立于#标签单独定义，不绑定于特定#标签
|
||||
|
||||
2. **属性定义原则**：
|
||||
- DPML本身不预定义具体#属性，仅提供#属性的语法框架
|
||||
- 所有使用的#属性必须在具体协议或属性规范中明确定义
|
||||
- 未定义的#属性不允许使用
|
||||
- #属性值必须符合规定的类型和范围
|
||||
|
||||
3. **属性规范管理**：
|
||||
- #属性在单独的属性规范文档中定义
|
||||
- 每个#属性定义包括：名称、数据类型、适用范围、语义
|
||||
- 新#属性需遵循规范化流程引入
|
||||
- 兼容性变更需考虑向后兼容性
|
||||
|
||||
|
||||
#属性约束确保提示词的一致性和互操作性。在使用DPML开发提示词时，开发者应遵循已定义的#属性规范，不得创建私有或未文档化的#属性。
|
||||
|
||||
### 协议实现绑定
|
||||
|
||||
DPML中的冒号(`:`)语法是核心语义机制，用于表达#标签间的实现关系：
|
||||
|
||||
1. **基本实现绑定**：通过冒号表示一个功能通过特定协议实现
|
||||
```xml
|
||||
<store:execution>
|
||||
<!-- 表示store功能通过execution协议实现 -->
|
||||
</store:execution>
|
||||
```
|
||||
|
||||
在DPML中，`A:B`表示"A通过B实现"，读作"A implemented with B"。冒号左侧表示"做什么"(功能)，右侧表示"怎么做"(实现方式)。
|
||||
|
||||
2. **实现继承行为**：当使用`<A:B>`形式时，A#标签继承B协议的全部结构规则和语义特征。例如：
|
||||
```xml
|
||||
<store:execution>
|
||||
<process>...</process> <!-- 来自execution协议的子标签 -->
|
||||
<rule>...</rule> <!-- 来自execution协议的子标签 -->
|
||||
</store:execution>
|
||||
```
|
||||
|
||||
3. **多协议组合**：不同功能可以通过不同协议实现，共同构建复杂系统
|
||||
```xml
|
||||
<memory>
|
||||
<store:execution>存储操作...</store:execution>
|
||||
<recall:resource>检索操作...</recall:resource>
|
||||
</memory>
|
||||
```
|
||||
|
||||
4. **实现层次结构**：
|
||||
```mermaid
|
||||
flowchart LR
|
||||
A["memory"] --> B["store:execution"]
|
||||
A --> C["recall:resource"]
|
||||
B --> D["process"]
|
||||
B --> E["rule"]
|
||||
C --> F["path引用"]
|
||||
```
|
||||
|
||||
每个实现绑定关系都明确表达了"这个功能使用那个协议来实现"，确保提示词组件的语义清晰性和交互一致性。
|
||||
|
||||
### 解释规则
|
||||
|
||||
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"`
|
||||
|
||||
**3. 使用未定义属性**
|
||||
```
|
||||
<prompt>
|
||||
<thinking color="blue" importance="9">
|
||||
思考内容...
|
||||
</thinking>
|
||||
</prompt>
|
||||
```
|
||||
错误原因：使用了未在属性规范中定义的`color`和`importance`属性
|
||||
|
||||
## 💡 最佳实践
|
||||
|
||||
1. **标签命名自释义**：选择具有自解释性的标签名称，使其本身就能清晰表达逻辑语义，即使没有计算机处理，人和AI也能轻松理解标签结构的逻辑上下文
|
||||
2. **语义清晰度**：选择表意明确的标签名，让提示结构一目了然
|
||||
3. **适度分层**：合理使用嵌套结构，避免过深的层次导致可读性下降
|
||||
4. **内容聚焦**：每个标签内容应关注单一职责，避免功能混杂
|
||||
5. **属性合理性**：只使用必要的属性，避免过度配置
|
||||
6. **一致性**：在整个项目中保持一致的DPML结构风格
|
||||
7. **命名空间明确性**：使用命名空间时，确保左侧表示"做什么"(功能)，右侧表示"怎么做"(实现)
|
||||
8. **属性合规性**：只使用已正式定义的属性，遵循属性规范中的类型和值约束
|
||||
|
||||
## 📌 总结
|
||||
|
||||
DPML通过结合标签语言的结构化能力和Markdown的内容表现力，为提示词工程提供了一种既规范又灵活的表达方式。其核心优势在于清晰的语义结构、协议复用机制和人类可读性，特别适合构建复杂、模块化的AI交互提示系统。
|
||||
|
||||
79
resource/protocol/pateoas.protocol.md
Normal file
79
resource/protocol/pateoas.protocol.md
Normal file
@ -0,0 +1,79 @@
|
||||
# PATEOAS 协议 - Prompt as the Engine of Application State
|
||||
|
||||
> **TL;DR:** PromptX = AI的诸葛锦囊，通过 PATEOAS 让 AI 无需记忆，仅凭 Prompt 引导完成专家级任务
|
||||
|
||||
## 🎯 核心理念
|
||||
|
||||
**AI use CLI get prompt for AI**
|
||||
|
||||
```
|
||||
通用AI → PromptX CLI → 获取专业提示词 → 变身专家AI → 提供专业服务
|
||||
```
|
||||
|
||||
### 三大解决方案
|
||||
- **上下文遗忘** → 锦囊自包含，每个命令独立执行
|
||||
- **注意力分散** → 分阶段专注，每锦囊专注单一任务
|
||||
- **能力局限** → 即时专家化，通过提示词获得专业能力
|
||||
|
||||
## 🎒 五大锦囊状态机
|
||||
|
||||
```
|
||||
🏗️init → 👋hello → ⚡action → 📚learn → 🔍recall → 循环
|
||||
```
|
||||
|
||||
| 锦囊 | 职责 | 输出 |
|
||||
|------|------|------|
|
||||
| `init` | 环境准备 + 理念传达 | 系统介绍 + PATEOAS导航 |
|
||||
| `hello` | 角色发现 | 专家角色清单 + 激活指引 |
|
||||
| `action` | 角色激活 | 专业提示词 + 学习建议 |
|
||||
| `learn` | 专家变身 | 领域知识 + 应用指引 |
|
||||
| `recall` | 经验检索 | 相关记忆 + 持续工作 |
|
||||
|
||||
## 📋 PATEOAS 实现要求
|
||||
|
||||
每个锦囊输出必须包含三层：
|
||||
|
||||
### 1. 锦囊目的 (Purpose)
|
||||
```
|
||||
🎯 锦囊目的：[功能描述]
|
||||
```
|
||||
|
||||
### 2. 锦囊内容 (Content)
|
||||
```
|
||||
📜 锦囊内容：
|
||||
[核心提示词/专业知识]
|
||||
```
|
||||
|
||||
### 3. PATEOAS导航 (Navigation)
|
||||
```
|
||||
🔄 下一步行动：
|
||||
- [操作名]: [描述]
|
||||
命令: promptx [command]
|
||||
|
||||
📍 当前状态：[state]
|
||||
```
|
||||
|
||||
## 🎨 设计原则
|
||||
|
||||
- **锦囊自包含**：每个命令包含完整执行信息
|
||||
- **串联无依赖**：即使AI忘记上文，也能继续执行
|
||||
- **分阶段专注**：每个锦囊只关注当前任务
|
||||
- **Prompt驱动**：每个输出引导AI发现下一步操作
|
||||
|
||||
## ⚡ 状态转换规则
|
||||
|
||||
```mermaid
|
||||
stateDiagram-v2
|
||||
[*] --> init
|
||||
init --> hello
|
||||
hello --> action
|
||||
action --> learn
|
||||
learn --> recall
|
||||
recall --> recall: 持续工作
|
||||
recall --> hello: 切换角色
|
||||
learn --> action: 重新激活
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
**核心价值：** 让AI既是工具使用者，也是被工具赋能者，实现"AI use CLI get prompt for AI"的革命性设计。
|
||||
60
resource/protocol/tag/execution.tag.md
Normal file
60
resource/protocol/tag/execution.tag.md
Normal file
@ -0,0 +1,60 @@
|
||||
# DPML#行为提示单元 框架
|
||||
|
||||
> **TL;DR:** DPML#行为提示单元 框架定义了结构化的#行为单元 模板，包含#流程(Process)、#指导原则(Guideline)、#规则(Rule)、#约束(Constraint)和#标准(Criteria)五个核心子概念，用于指导AI系统完成具体任务。
|
||||
|
||||
### 目的与功能
|
||||
|
||||
DPML#行为提示单元 框架定义了AI系统执行任务的#行为单元 模板，它的主要功能是：
|
||||
- 提供执行任务的结构化#行为单元 定义
|
||||
- 通过标准化#行为单元 明确#流程 步骤、#指导原则、#规则、#约束 和#标准
|
||||
- 帮助AI系统通过规范化#行为单元 进行精确、可靠的任务执行
|
||||
- 提供执行状态追踪和错误处理的#行为单元 模板
|
||||
|
||||
## 📝 语法定义
|
||||
|
||||
```ebnf
|
||||
(* EBNF形式化定义 *)
|
||||
execution_element ::= '<execution' attributes? '>' content '</execution>'
|
||||
attributes ::= (' ' attribute)+ | ''
|
||||
attribute ::= name '="' value '"'
|
||||
name ::= [a-zA-Z][a-zA-Z0-9_-]*
|
||||
value ::= [^"]*
|
||||
content ::= (markdown_content | process_element | guideline_element | rule_element | constraint_element | criteria_element)+
|
||||
|
||||
process_element ::= '<process' attributes? '>' markdown_content '</process>'
|
||||
guideline_element ::= '<guideline' attributes? '>' markdown_content '</guideline>'
|
||||
rule_element ::= '<rule' attributes? '>' markdown_content '</rule>'
|
||||
constraint_element ::= '<constraint' attributes? '>' markdown_content '</constraint>'
|
||||
criteria_element ::= '<criteria' attributes? '>' markdown_content '</criteria>'
|
||||
|
||||
markdown_content ::= (* 任何有效的Markdown文本，可包含特定语法元素 *)
|
||||
```
|
||||
|
||||
## 🧩 语义说明
|
||||
|
||||
#行为提示单元 标签表示一个完整的#行为单元 框架。标签内容可以包含五种不同概念的子标签，每个子标签都有明确的语义：
|
||||
|
||||
- **#流程**: 表示执行的具体步骤，包含正常和异常路径，是#行为单元 的核心路径定义
|
||||
- **#指导原则**: 表示建议性指导原则，具有灵活性和可变通性，用于推荐最佳实践
|
||||
- **#规则**: 表示强制性行为准则，必须严格遵守，通常涉及安全、合规或核心质量要求
|
||||
- **#约束**: 表示客观限制条件，客观存在且不可改变，需要被动适应
|
||||
- **#标准**: 表示评价标准，用于判断执行结果是否满足要求
|
||||
|
||||
这五个子概念构成了完整的#行为单元 框架，从不同维度定义了AI系统如何执行任务。
|
||||
|
||||
### 优先级关系
|
||||
|
||||
#行为提示单元 框架内的子概念具有以下固定的优先级关系，这种关系定义了如何理解和解释这些概念：
|
||||
|
||||
1. **#约束** - 最高优先级，表示客观存在的限制，不可违反
|
||||
2. **#规则** - 次高优先级，表示必须遵循的行为准则
|
||||
3. **#指导原则** - 较低优先级，表示可灵活调整的建议性原则
|
||||
4. **#流程** - 在#约束 和#规则 的框架内定义执行路径
|
||||
5. **#标准** - 作为评价依据，验证执行结果是否满足要求
|
||||
|
||||
这种优先级关系是框架的核心语义特征：
|
||||
- 低优先级元素不能与高优先级元素产生冲突
|
||||
- #流程 必须在#约束 和#规则 定义的边界内设计
|
||||
- #指导原则 在不违反#规则 和#约束 的前提下可以灵活调整
|
||||
- #标准 需要考虑所有优先级更高的元素的要求
|
||||
|
||||
186
resource/protocol/tag/resource.tag.md
Normal file
186
resource/protocol/tag/resource.tag.md
Normal file
@ -0,0 +1,186 @@
|
||||
# DPML#资源提示单元 框架
|
||||
|
||||
> **TL;DR:** DPML#资源提示单元 框架定义了统一的#资源单元 模板，支持通过#资源引用（@协议名://路径）形式在提示词中访问和操作各类资源。
|
||||
|
||||
### 目的与功能
|
||||
|
||||
DPML#资源提示单元 框架用于定义特定类型的#资源单元，使开发者能够以标准化的方式在提示词中描述如何#定位 和处理各种资源。通过这个框架，可以明确#资源协议 的引用语法、#位置 规则和#查询参数，确保#资源引用 在不同环境中的一致性和可靠性。此框架是PromptX中#资源协议（RP）在提示词层面的具体实现方式。
|
||||
|
||||
主要功能包括：
|
||||
- 定义#资源单元 的标识和#资源引用 方式
|
||||
- 规范化#位置 的提示词语法结构和#解析 规则
|
||||
- 指定#资源单元 支持的#查询参数 和格式
|
||||
- 提供#资源单元 的标准化示例
|
||||
|
||||
### 默认支持的通用#资源协议
|
||||
|
||||
PromptX默认支持以下通用且已有共识的#资源协议，这些协议符合`@协议名://路径`格式，遵循其业界标准语法和规则，无需在#资源单元 中重新定义：
|
||||
|
||||
| #资源协议 | 描述 | 示例 |
|
||||
|-------|------|------|
|
||||
| file | 文件系统资源 | `@file://path/to/file.txt` |
|
||||
| http/https | HTTP/HTTPS网络资源 | `@https://example.com/api/data` |
|
||||
| ftp/sftp | 文件传输协议 | `@ftp://user:pass@host/path` |
|
||||
| ssh | 安全Shell协议 | `@ssh://user@host/path` |
|
||||
|
||||
这些通用#资源协议 的路径格式和#查询参数 遵循它们的标准规范。对于特定领域或自定义的#资源协议，才需要使用#资源单元 进行详细定义。
|
||||
|
||||
## 📝 语法定义
|
||||
|
||||
```ebnf
|
||||
(* EBNF形式化定义 *)
|
||||
resource_element ::= '<resource' ' protocol="' protocol_name '"' '>' content '</resource>'
|
||||
protocol_name ::= [a-zA-Z][a-zA-Z0-9_-]*
|
||||
content ::= (markdown_content | location_element | params_element | registry_element)+
|
||||
|
||||
location_element ::= '<location>' markdown_content '</location>'
|
||||
params_element ::= '<params>' markdown_content '</params>'
|
||||
registry_element ::= '<registry>' markdown_content '</registry>'
|
||||
|
||||
markdown_content ::= (* 任何有效的Markdown文本，包括代码块、表格等 *)
|
||||
```
|
||||
|
||||
## 🧩 语义说明
|
||||
|
||||
### 子标签语义
|
||||
|
||||
#资源单元 包含三个核心子标签，用于定义#资源协议 的具体内容：
|
||||
|
||||
- **#位置**：定义该#资源协议 的路径规则。通常采用EBNF形式化语法描述路径结构，并可包含示例说明。
|
||||
- **#参数**：定义该#资源协议 支持的#查询参数。通常采用表格形式列出参数名称、类型、描述和用法示例。
|
||||
- **#注册表**：根据#位置 和#参数 定义注册抽象参数与具体资源的映射关系。通常采用表格形式列出ID到实际资源路径的映射。
|
||||
|
||||
这三个子标签共同构成#资源协议 的完整定义：#位置 定义资源的#定位 格式，#参数 定义资源的访问选项，#注册表 将抽象ID映射到具体资源路径。标签应按照#位置、#参数、#注册表 的顺序定义，确保#注册表 可以基于前两个标签的内容建立正确的映射关系。
|
||||
|
||||
### `@` #资源引用 协议
|
||||
|
||||
#资源单元 定义了一个#资源协议，指定了如何使用`@`符号作为统一入口，遵循以下核心语法规则：
|
||||
|
||||
```ebnf
|
||||
resource_reference ::= ('[@]' | '@!' | '@?') protocol_name ':' resource_location [query_params]
|
||||
resource_location ::= uri | nested_reference
|
||||
uri ::= protocol_name '://' path
|
||||
nested_reference ::= ['[@]' | '@!' | '@?'] protocol_name ':' resource_location
|
||||
path ::= path_segment {'/' path_segment}
|
||||
query_params ::= '?' param_name '=' param_value {'&' param_name '=' param_value}
|
||||
```
|
||||
|
||||
#### #加载语义
|
||||
|
||||
#资源引用 支持三种#加载语义 前缀：
|
||||
|
||||
| 前缀 | 语义 | 示例 |
|
||||
|-----|------|------|
|
||||
| `@` | 默认模式，由AI自行决定#加载 时机 | `@file://document.md` |
|
||||
| `@!` | #热加载，AI看到引用时必须立即#加载 | `@!https://example.com/data` |
|
||||
| `@?` | #懒加载，AI仅记录资源位置，在实际需要使用时才#加载 | `@?file://large-dataset.csv` |
|
||||
|
||||
#### 基础#资源引用
|
||||
|
||||
基础#资源引用 使用单一#资源协议：
|
||||
```
|
||||
@protocol://path
|
||||
```
|
||||
|
||||
例如：
|
||||
- `@file://document.md` - 引用文件系统中的文档
|
||||
- `@http://example.com/api/data.json` - 引用网络资源
|
||||
- `@memory://user_preferences` - 引用内存中的数据
|
||||
- `@!file://important.md` - #热加载 重要文档
|
||||
- `@?file://large-dataset.csv` - #懒加载 大型数据集
|
||||
|
||||
#### #嵌套引用
|
||||
|
||||
#嵌套引用 允许一个#资源协议 处理另一个#资源协议 的输出：
|
||||
|
||||
**完整形式**（内部使用@符号）：
|
||||
```
|
||||
@outer:@inner://path
|
||||
```
|
||||
|
||||
**简写形式**（内部省略@符号）：
|
||||
```
|
||||
@outer:inner://path
|
||||
```
|
||||
|
||||
#嵌套引用 时也可以指定#加载语义：
|
||||
```
|
||||
@outer:@!inner://path // 内部资源#热加载
|
||||
@!outer:@?inner://path // 外部#热加载，内部#懒加载
|
||||
```
|
||||
|
||||
例如：
|
||||
- `@thinking:@file://method.md` - 对文件内容应用thinking协议处理
|
||||
- `@execution:file://workflow.md` - 对文件内容应用execution协议处理
|
||||
- `@outer:middle:inner://resource` - 多层#嵌套引用（从内向外处理）
|
||||
- `@!thinking:@?file://large-file.md` - 立即应用thinking，但文件内容#懒加载
|
||||
|
||||
#### #路径通配符
|
||||
|
||||
路径支持以下#路径通配符 模式：
|
||||
- `*` - 匹配单层中的任意文件或目录，如`@file://docs/*.md`
|
||||
- `**` - 匹配多层目录和文件，如`@file://src/**/*.js`
|
||||
- `*.ext` - 匹配特定扩展名的文件，如`@file://docs/*.txt`
|
||||
- `*.{ext1,ext2}` - 匹配多种扩展名，如`@file://src/*.{js,ts}`
|
||||
|
||||
#### #查询参数
|
||||
|
||||
#查询参数 提供额外的资源处理指令：
|
||||
```
|
||||
@protocol://path?param1=value1¶m2=value2
|
||||
```
|
||||
|
||||
例如：
|
||||
- `@file://document.md?line=5-10` - 只获取文件的第5-10行
|
||||
- `@http://api.example.com/data?format=json&cache=false` - 指定返回格式并禁用缓存
|
||||
|
||||
#### #注册表 解析与抽象引用
|
||||
|
||||
使用#注册表 定义的资源可以通过抽象ID引用，无需知道具体路径：
|
||||
```
|
||||
@protocol://resource_id
|
||||
```
|
||||
|
||||
例如定义了以下#注册表：
|
||||
```xml
|
||||
<resource protocol="thought">
|
||||
<location>
|
||||
location ::= thought://{thought_id}
|
||||
thought_id ::= [a-zA-Z][a-zA-Z0-9_-]*
|
||||
</location>
|
||||
|
||||
<registry>
|
||||
| 思维ID | 文件路径 |
|
||||
|--------|---------|
|
||||
| analytical | @file://PromptX/core/thoughts/analytical.thought.md |
|
||||
| creative | @file://PromptX/core/thoughts/creative.thought.md |
|
||||
</registry>
|
||||
</resource>
|
||||
```
|
||||
|
||||
使用时可以简单引用：
|
||||
- `@thought://analytical` - 自动映射到对应文件
|
||||
- `@thought://creative` - 自动映射到对应文件
|
||||
|
||||
这种抽象引用机制提供了路由层，使#资源引用 与实际存储位置解耦，方便管理和移植。
|
||||
|
||||
### #解析 规则
|
||||
|
||||
1. #资源引用 解析从左至右进行，先识别#资源协议 名称，再#解析 资源位置和#查询参数
|
||||
2. #嵌套引用 从内向外#解析，内层#资源引用 的结果作为外层引用的输入
|
||||
3. #查询参数 应用于资源#加载 后的处理阶段，不影响资源的基本#定位
|
||||
4. 相对路径#定位 基于当前上下文的工作目录或基础路径
|
||||
5. #加载语义 前缀（@、@!、@?）优先于其他部分#解析，决定资源的#加载 策略
|
||||
|
||||
### #加载 实现说明
|
||||
|
||||
对于支持工具调用能力的AI系统:
|
||||
1. **主动#加载 责任**: AI需主动使用工具调用(例如read_file)获取@引用的资源，而非等待系统自动#加载
|
||||
2. **#热加载 义务**: 特别是对于@!前缀资源，AI必须立即执行工具调用#加载 内容
|
||||
3. **自主判断#懒加载**: 对于@?前缀资源，AI应记录位置但暂不#加载，直到实际需要使用时
|
||||
4. **#加载 验证**: AI应验证资源是否成功#加载，并适当处理#加载 失败情况
|
||||
5. **#注册表 解析**: 对于使用#注册表 注册的#资源引用，AI应首先#解析 资源ID，找到对应的实际资源路径，然后再应用上述规则获取资源
|
||||
|
||||
这种主动#加载 模式确保AI能正确执行协议定义的#加载语义，而不依赖系统层面的自动处理。#注册表 机制则提供了#资源引用 的抽象层，使资源组织更加灵活和模块化。
|
||||
|
||||
|
||||
87
resource/protocol/tag/role.tag.md
Normal file
87
resource/protocol/tag/role.tag.md
Normal file
@ -0,0 +1,87 @@
|
||||
# DPML#角色提示单元 框架
|
||||
|
||||
> **TL;DR:** DPML#角色提示单元 框架定义了基于三组件架构的完整#AI角色构建方法，通过#思维模式(personality)、#行为原则(principle) 和#专业知识(knowledge) 的组合来创建自包含的#AI角色。
|
||||
|
||||
### 目的与功能
|
||||
|
||||
DPML#角色提示单元 框架提供了构建#AI角色的标准化方法，主要功能包括：
|
||||
- 基于三组件架构构建完整的#AI角色定义
|
||||
- 确保#角色定义 的自包含性和完整性
|
||||
- 支持不同领域#AI角色 的灵活定制
|
||||
- 与PromptX锦囊串联系统完美集成
|
||||
|
||||
## 📝 语法定义
|
||||
|
||||
```ebnf
|
||||
(* EBNF形式化定义 *)
|
||||
role_element ::= '<role' attributes? '>' role_content '</role>'
|
||||
role_content ::= personality_element principle_element knowledge_element
|
||||
|
||||
(* 三大核心组件 *)
|
||||
personality_element ::= '<personality' attributes? '>' personality_content '</personality>'
|
||||
principle_element ::= '<principle' attributes? '>' principle_content '</principle>'
|
||||
knowledge_element ::= '<knowledge' attributes? '>' knowledge_content '</knowledge>'
|
||||
|
||||
(* 内容定义 *)
|
||||
personality_content ::= markdown_content
|
||||
principle_content ::= markdown_content
|
||||
knowledge_content ::= markdown_content
|
||||
|
||||
attributes ::= (' ' attribute)+ | ''
|
||||
attribute ::= name '="' value '"'
|
||||
name ::= [a-zA-Z][a-zA-Z0-9_-]*
|
||||
value ::= [^"]*
|
||||
|
||||
markdown_content ::= (* 符合Markdown语法的内容 *)
|
||||
```
|
||||
|
||||
## 🧩 语义说明
|
||||
|
||||
`<role>`标签是DPML中定义#AI角色 的核心#角色提示单元，基于三组件架构构建完整的#AI角色定义。每个#角色 都是自包含的，包含了AI变身为特定领域专家所需的全部信息。
|
||||
|
||||
### 三组件架构说明
|
||||
|
||||
#### 1. #思维模式(Personality)
|
||||
- **核心功能**：定义AI角色的思维特征和认知模式
|
||||
- **内容范围**：核心思维特征、认知偏好、思考方式、价值观倾向
|
||||
- **设计目标**：确保AI能够以角色特定的思维方式分析和理解问题
|
||||
- **实现方式**：通过`promptx learn personality://role-id`加载
|
||||
|
||||
#### 2. #行为原则(Principle)
|
||||
- **核心功能**：定义AI角色的行为准则和工作原则
|
||||
- **内容范围**：核心原则、行为规范、决策标准、工作流程
|
||||
- **设计目标**：确保AI能够按照角色特定的原则执行任务和做出决策
|
||||
- **实现方式**：通过`promptx learn principle://role-id`加载
|
||||
|
||||
#### 3. #专业知识(Knowledge)
|
||||
- **核心功能**：提供AI角色的领域知识和技能体系
|
||||
- **内容范围**：专业知识框架、技能清单、工具使用、最佳实践
|
||||
- **设计目标**：确保AI具备角色所需的专业能力和知识背景
|
||||
- **实现方式**：通过`promptx learn knowledge://role-id`加载
|
||||
|
||||
### #角色生命周期
|
||||
|
||||
#### 角色激活流程
|
||||
1. **发现角色** - `promptx hello` 浏览可用角色
|
||||
2. **制定计划** - `promptx action role-id` 生成学习计划
|
||||
3. **学习组件** - 按序学习personality、principle、knowledge
|
||||
4. **开始工作** - 运用角色能力解决实际问题
|
||||
|
||||
#### 系统级支持
|
||||
- **记忆管理** - `promptx remember` 存储经验
|
||||
- **经验回忆** - `promptx recall` 检索相关记忆
|
||||
- **角色切换** - 随时切换到其他专业角色
|
||||
|
||||
### 设计理念
|
||||
|
||||
#### 锦囊串联架构
|
||||
- 每个角色是一个完整的"智慧锦囊"
|
||||
- 支持"AI use CLI get prompt for AI"的核心理念
|
||||
- 实现AI即时专家化的能力获取
|
||||
|
||||
#### 简化原则
|
||||
- **三组件自包含** - 移除复杂的资源引用机制
|
||||
- **系统级操作** - 复杂功能通过CLI命令实现
|
||||
- **清晰分离** - 角色定义与系统功能明确分工
|
||||
|
||||
> **注意**：基于简化设计原则，`experience`和`action`组件已迁移为系统级命令（`promptx recall`和`promptx action`），角色文件专注于三个核心组件的定义。
|
||||
129
resource/protocol/tag/terminology.tag.md
Normal file
129
resource/protocol/tag/terminology.tag.md
Normal file
@ -0,0 +1,129 @@
|
||||
# DPML动态术语协议 (Dynamic Terminology Protocol)
|
||||
|
||||
> **TL;DR:** DPML采用动态术语理解机制，AI需根据`#术语`在当前协议和对话中的上下文自主理解其含义。
|
||||
|
||||
## 🎯 核心理念：上下文即定义
|
||||
|
||||
为极致精简和发挥AI的动态理解能力，PromptX不再提供预定义的术语表。所有以`#`标记的术语（如 `#标签`、`#协议绑定`），AI需要：
|
||||
|
||||
1. **依赖当前协议上下文**：术语的精确含义由其所在的协议文件内容决定。
|
||||
2. **结合对话历史**：根据当前对话的上下文动态推断和理解术语。
|
||||
3. **关联相关概念**：将遇到的`#术语`与协议中其他概念和机制关联。
|
||||
4. **主动澄清（可选）**：如遇模糊不清的术语，可主动提问或要求举例。
|
||||
|
||||
## 💡 设计原则
|
||||
|
||||
- **AI自主理解优先**：最大化信任和利用AI的上下文推理能力。
|
||||
- **协议自解释性**：协议内容本身应足够清晰，以支持AI正确理解术语。
|
||||
- **动态适应性**：术语含义可根据具体使用场景和对话历史灵活调整。
|
||||
|
||||
## 🚀 目标
|
||||
|
||||
通过此协议，实现：
|
||||
- **极致的Token效率**：去除所有预定义术语表。
|
||||
- **深度的AI参与**：AI不仅是使用者，更是意义的构建者。
|
||||
- **高度的上下文关联**：强化AI对当前情境的专注和理解。
|
||||
|
||||
**AI请注意：** 当你看到`#术语`时，请结合当前协议的整体内容和我们的对话历史，尽力理解其在当前语境下的具体含义。
|
||||
|
||||
### 目的与功能
|
||||
|
||||
DPML术语定义协议用于在协议文件中嵌入标准化的术语定义，并提供统一的引用方式，解决以下关键问题：
|
||||
- 为特定领域和上下文提供明确、原子化的术语定义
|
||||
- 确保术语与其适用的协议/上下文紧密绑定
|
||||
- 统一术语的引用方式，减少歧义
|
||||
- 便于维护和更新术语定义
|
||||
|
||||
### 设计思想
|
||||
|
||||
术语定义协议基于以下核心理念：
|
||||
|
||||
1. **上下文绑定**：术语与其适用的协议文件紧密结合，确保术语在特定上下文中的含义明确。
|
||||
2. **结构简洁**：采用最小必要的标签结构，便于维护和理解。
|
||||
3. **引用明确**：使用特定符号系统引用术语，确保人类和AI都能识别术语引用。
|
||||
4. **隐式作用域**：术语通过所在文件自动获得作用域，无需显式声明。
|
||||
5. **自包含性**：协议文件包含其相关术语定义，提高文档完整性。
|
||||
|
||||
## 📝 语法定义
|
||||
|
||||
```ebnf
|
||||
(* EBNF形式化定义 *)
|
||||
terminologies_element ::= '<terminologies>' terminology+ '</terminologies>'
|
||||
terminology_element ::= '<terminology>' terminology_content '</terminology>'
|
||||
terminology_content ::= zh_element en_element definition_element examples_element
|
||||
zh_element ::= '<zh>' text '</zh>'
|
||||
en_element ::= '<en>' text '</en>'
|
||||
definition_element ::= '<definition>' markdown_content '</definition>'
|
||||
examples_element ::= '<examples>' example+ '</examples>'
|
||||
example_element ::= '<example>' markdown_content '</example>'
|
||||
|
||||
text ::= (* 任何文本内容 *)
|
||||
markdown_content ::= (* 任何有效的Markdown文本 *)
|
||||
```
|
||||
|
||||
## 🧩 语义说明
|
||||
|
||||
### 术语定义结构
|
||||
|
||||
术语定义使用`<terminologies>`标签包含一组术语，每个术语使用`<terminology>`标签定义：
|
||||
|
||||
- **`<terminology>`**：单个术语的定义容器
|
||||
- **`<zh>`**：术语的中文名称
|
||||
- **`<en>`**：术语的英文名称
|
||||
- **`<definition>`**：术语的详细定义，可同时包含AI理解和系统实现层面的解释
|
||||
- **`<examples>`**：包含一个或多个`<example>`标签，提供使用示例
|
||||
|
||||
每个协议文件末尾使用标题"## 🔖 术语定义"引入术语定义部分，将术语定义与协议正文分隔。
|
||||
|
||||
### `#` 引用协议
|
||||
|
||||
术语定义协议规定了如何使用`#`符号作为统一的术语引用方式，遵循以下核心语法规则：
|
||||
|
||||
```ebnf
|
||||
term_reference ::= '#' term_name [' ']
|
||||
term_name ::= (* 术语的中文名称或英文名称 *)
|
||||
```
|
||||
|
||||
#### 术语引用
|
||||
|
||||
术语引用在术语名称前使用井号标记：
|
||||
|
||||
| 语法 | 描述 | 示例 |
|
||||
|------|------|------|
|
||||
| `#术语` | 引用上下文中定义的术语 | `#协议绑定` |
|
||||
|
||||
基本术语引用在术语名称前使用井号，引用当前文档上下文中定义的术语：
|
||||
```
|
||||
#术语名称
|
||||
```
|
||||
|
||||
例如：
|
||||
- `#协议绑定` - 引用当前上下文中定义的"协议绑定"术语
|
||||
- `#标签嵌套` - 引用当前上下文中定义的"标签嵌套"术语
|
||||
|
||||
推荐在术语后添加空格与其他内容分隔：`#术语 后续内容`，但这不是强制要求。
|
||||
|
||||
#### 与 Markdown 的兼容性
|
||||
|
||||
为了避免与 Markdown 的标题语法冲突，DPML 采用以下解析规则：
|
||||
|
||||
1. **行首 # 符号**：
|
||||
- 当 # 出现在行首时，按照 Markdown 语法解析为标题
|
||||
- 例如：`# 这是一个标题`
|
||||
|
||||
2. **非行首 # 符号**：
|
||||
- 当 # 出现在行中或词首时，解析为术语引用
|
||||
- 例如：`这里引用了一个 #术语`
|
||||
|
||||
3. **行首术语引用**：
|
||||
- 如果需要在行首使用术语引用，可以添加空格或其他字符
|
||||
- 例如：` #术语` 或 `文本 #术语`
|
||||
|
||||
这种设计保持了与 Markdown 的兼容性，同时提供了清晰的术语引用机制。
|
||||
|
||||
### 作用域规则
|
||||
|
||||
**隐式作用域**：术语自动具有其所在文档和上下文的作用域，这意味着：
|
||||
- 术语的定义和使用范围由其所在的文档上下文决定
|
||||
- 同一术语在不同上下文中可能有不同的定义
|
||||
- 使用术语时应考虑当前所处的上下文环境
|
||||
60
resource/protocol/tag/thought.tag.md
Normal file
60
resource/protocol/tag/thought.tag.md
Normal file
@ -0,0 +1,60 @@
|
||||
# DPML#思考提示单元 框架
|
||||
|
||||
> **TL;DR:** DPML#思考提示单元 框架定义了结构化的#思考单元 模板，支持四种核心#思维模式 的#思考提示单元 构建：#探索思维（exploration）、#推理思维（reasoning）、#计划思维（plan）和#挑战思维（challenge），帮助AI系统进行系统性分析和推理。
|
||||
|
||||
### 目的与功能
|
||||
|
||||
DPML#思考提示单元 框架定义了AI系统进行思考分析的#思考单元 模板和结构，它的主要功能是：
|
||||
- 提供结构化的#思维分析#思考提示单元 模板
|
||||
- 规范化#思考单元 的组织方式
|
||||
- 支持可视化#思维导图 和#决策树 的#思考提示单元 表达
|
||||
- 帮助AI系统通过标准化#思考提示单元 进行系统性、全面性的问题分析
|
||||
- 区分不同类型的#思维模式#思考提示单元：#探索思维、#推理思维、#计划思维 和#挑战思维
|
||||
|
||||
## 📝 语法定义
|
||||
|
||||
```ebnf
|
||||
(* EBNF形式化定义 *)
|
||||
thought_element ::= '<thought' attributes? '>' content '</thought>'
|
||||
attributes ::= (' ' attribute)+ | ''
|
||||
attribute ::= name '="' value '"'
|
||||
name ::= [a-zA-Z][a-zA-Z0-9_-]*
|
||||
value ::= [^"]*
|
||||
content ::= (markdown_content | exploration_element | reasoning_element | plan_element | challenge_element)+
|
||||
markdown_content ::= (* 任何有效的Markdown文本，包括Mermaid图表 *)
|
||||
|
||||
exploration_element ::= '<exploration' attributes? '>' markdown_content '</exploration>'
|
||||
reasoning_element ::= '<reasoning' attributes? '>' markdown_content '</reasoning>'
|
||||
plan_element ::= '<plan' attributes? '>' markdown_content '</plan>'
|
||||
challenge_element ::= '<challenge' attributes? '>' markdown_content '</challenge>'
|
||||
```
|
||||
|
||||
## 🧩 语义说明
|
||||
|
||||
#思考提示单元 标签表示一个完整的#思考单元 或#思维框架。标签内容可以包含四种不同#思维模式 的子标签，或直接使用Markdown格式表达#思考内容。
|
||||
|
||||
子标签具有明确的语义：
|
||||
- **#探索思维**: 表示跳跃思考，发散性思维，生成可能性，寻找多种可能性、创新点和关联性
|
||||
- **#推理思维**: 表示连续思考，收敛性思维，验证可能性，深入分析因果关系、逻辑链条
|
||||
- **#计划思维**: 表示秩序思考，结构性思维，固化可能性，设计行动步骤、决策路径、组织结构、系统架构
|
||||
- **#挑战思维**: 表示逆向跳跃思考，批判性思维，质疑可能性，寻找假设漏洞、识别潜在风险、测试极限条件
|
||||
|
||||
#探索思维 和#挑战思维 是一对#思维模式 的正反两面：#探索思维 向外发散寻找"可能是什么"，而#挑战思维 向内批判探究"可能不是什么"。二者都采用跳跃式思考，但方向相反。#推理思维 负责系统验证，而#挑战思维 主要提出问题点。
|
||||
|
||||
#思考提示单元 特别适合表达概念关系、逻辑推理和系统性思考，为AI提供#思考分析 的参考框架。
|
||||
|
||||
### 推荐的#思考顺序
|
||||
|
||||
在实际思考过程中，推荐遵循如下顺序以获得系统性和全面性的分析结果：
|
||||
1. **#探索思维**：首先发散思考，提出尽可能多的可能性和创新点；
|
||||
2. **#挑战思维**：对#探索思维 阶段的内容进行批判性思考，识别潜在风险和假设漏洞；
|
||||
3. **#推理思维**：对经过#挑战思维 筛选的内容进行系统性推理和因果分析；
|
||||
4. **#计划思维**：最后制定具体的行动方案和决策路径。
|
||||
|
||||
在复杂问题中，#挑战思维 和#推理思维 可多次交替，#计划思维 阶段也可穿插#挑战思维 以确保方案稳健性。
|
||||
|
||||
### 子标签的可选性
|
||||
|
||||
#思考提示单元 内的四种#思维模式 子标签（#探索思维、#挑战思维、#推理思维、#计划思维）均为可选。实际的#思考提示单元 可以只包含其中的一种、几种，或全部，具体内容由实际需求决定。
|
||||
|
||||
对于提示词的理解者来说，只需知道这些子标签不是必须全部出现，遇到哪些子标签就理解哪些即可，无需关心未出现的部分。
|
||||
Reference in New Issue
Block a user