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
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