更新bootstrap.md文档,调整角色路径为提示词开发者,确保用户理解角色代入要求;更新prompt-developer.role.md文档,新增术语模式最佳实践,提升提示词开发的规范性;更新dpml.protocol.md文档,修正语义描述,确保一致性;更新多个标签文档,统一术语和格式,提升文档的清晰度和可读性。

This commit is contained in:
sean
2025-05-22 21:28:07 +08:00
parent 13b307c834
commit bbb5b55d77
17 changed files with 1112 additions and 204 deletions

View File

@ -4,7 +4,7 @@
1. 使用命令 `node PromptX/promptx.js protocols` 阅读并理解 DPML 提示词协议 1. 使用命令 `node PromptX/promptx.js protocols` 阅读并理解 DPML 提示词协议
2. 使用命令 `node PromptX/promptx.js core` 阅读并理解 核心 提示词,核心提示词大部分角色都会用到,必须仔细理解 2. 使用命令 `node PromptX/promptx.js core` 阅读并理解 核心 提示词,核心提示词大部分角色都会用到,必须仔细理解
3. 你需要代入的角色是 @file://PromptX/domain/scrum/role/product-owner.role.md 3. 你需要代入的角色是 @file://PromptX/domain/prompt/prompt-developer.role.md
4. 按照结合协议的标签定义,理解角色提示词,然后按照提示词执行 4. 按照结合协议的标签定义,理解角色提示词,然后按照提示词执行
5. 自检以下步骤 5. 自检以下步骤
- 是否理解 DPML 提示词协议 - 是否理解 DPML 提示词协议

View File

@ -0,0 +1,32 @@
<execution domain="prompt-engineering">
<guideline>
# 术语定义最佳实践
1. **术语原子化**:每个术语定义应聚焦单一概念,不包含多个关联但独立的概念
2. **术语命名**
- 中文名称应简洁明确,避免生僻词
- 英文名称使用专业术语,遵循行业惯例
- 保持中英文名称的语义一致性
3. **定义清晰性**
- 定义应精确、简洁,避免循环定义
- 可同时包含AI理解和系统实现两个层面
- 描述应独立自足,不依赖特定上下文即可理解
4. **示例具体化**
- 提供具体、有代表性的示例
- 示例应涵盖典型使用场景
- 复杂概念可提供多个示例说明不同方面
5. **引用规范**
- 术语后推荐使用空格与后续内容分隔,增强可读性
- 如果术语本身包含空格,仍可正常使用:`#用户故事`
- 在同一文档中保持术语引用的一致性
6. **维护更新**
- 修改文档时同步更新相关术语
- 保持术语定义与文档内容的一致性
- 术语变更时考虑向后兼容性
</guideline>
</execution>

View File

@ -54,6 +54,10 @@
提示词开发者在构建资源模式提示词时,应遵循以下最佳实践: 提示词开发者在构建资源模式提示词时,应遵循以下最佳实践:
@!execution://resource-best-practice @!execution://resource-best-practice
## 术语模式最佳实践
提示词开发者在构建术语提示词时,应遵循以下最佳实践:
@!execution://terminology-best-practice
</principle> </principle>
<action> <action>

View File

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

View File

@ -0,0 +1,167 @@
<terminologies>
<terminology>
<zh>DPML</zh>
<en>Deepractice Prompt Markup Language</en>
<definition>
一种专为提示词工程设计的标记语言结合XML结构和Markdown内容为各类提示词提供标准化的表达框架确保结构清晰和语义准确。
</definition>
<examples>
<example>DPML协议支持AI助手、自动化工作流等场景的提示词结构化表达。</example>
</examples>
</terminology>
<terminology>
<zh>提示词</zh>
<en>Prompt</en>
<definition>
用于引导AI系统行为或输出的自然语言片段DPML中以结构化方式组织和表达。
</definition>
<examples>
<example>"请分析以下数据..." 是一个典型的提示词。</example>
</examples>
</terminology>
<terminology>
<zh>标签</zh>
<en>Tag</en>
<definition>
用于界定提示词结构和语义边界的标记采用XML风格&lt;thinking&gt;&lt;executing&gt;等。
</definition>
<examples>
<example>&lt;thinking&gt;分析问题...&lt;/thinking&gt;</example>
</examples>
</terminology>
<terminology>
<zh>属性</zh>
<en>Attribute</en>
<definition>
附加在标签上的键值对用于细化提示单元的行为或元数据如type="analysis"。</definition>
<examples>
<example>&lt;executing priority="high"&gt;...</example>
</examples>
</terminology>
<terminology>
<zh>内容</zh>
<en>Content</en>
<definition>
标签内部的实际提示词文本通常采用Markdown格式表达。</definition>
<examples>
<example># 步骤\n1. 首先...</example>
</examples>
</terminology>
<terminology>
<zh>提示单元</zh>
<en>Prompt Unit</en>
<definition>
由标签定义的语义完整的提示组件是DPML结构的基本构成块。</definition>
<examples>
<example>&lt;thinking&gt;分析问题...&lt;/thinking&gt;</example>
</examples>
</terminology>
<terminology>
<zh>属性修饰</zh>
<en>Attribute Modifier</en>
<definition>
通过属性对提示单元进行行为或表现上的细化,如优先级、类型等。</definition>
<examples>
<example>&lt;executing priority="high"&gt;...</example>
</examples>
</terminology>
<terminology>
<zh>组合提示</zh>
<en>Composite Prompt</en>
<definition>
由多个提示单元组合形成的完整提示结构体现DPML的模块化和复用性。</definition>
<examples>
<example>&lt;thinking&gt;...&lt;/thinking&gt;&lt;executing&gt;...&lt;/executing&gt;</example>
</examples>
</terminology>
<terminology>
<zh>协议实现绑定</zh>
<en>Protocol Implementation Binding</en>
<definition>
通过冒号语法A:B表达标签间的实现关系A为功能B为实现方式。</definition>
<examples>
<example>&lt;store:execution&gt;...&lt;/store:execution&gt;</example>
</examples>
</terminology>
<terminology>
<zh>命名空间</zh>
<en>Namespace</en>
<definition>
用于区分不同协议或功能域的标签前缀如store:execution中的store。</definition>
<examples>
<example>&lt;store:execution&gt;...&lt;/store:execution&gt;</example>
</examples>
</terminology>
<terminology>
<zh>根元素</zh>
<en>Root Element</en>
<definition>
DPML文档的顶层标签推荐使用&lt;prompt&gt;,但不强制。</definition>
<examples>
<example>&lt;prompt&gt;...&lt;/prompt&gt;</example>
</examples>
</terminology>
<terminology>
<zh>自闭合标签</zh>
<en>Self-closing Tag</en>
<definition>
无内容的标签,采用/&gt;结尾,如&lt;import /&gt;</definition>
<examples>
<example>&lt;import /&gt;</example>
</examples>
</terminology>
<terminology>
<zh>嵌套标签</zh>
<en>Nested Tag</en>
<definition>
标签内部包含其他标签,形成层次结构。</definition>
<examples>
<example>&lt;thinking&gt;&lt;plan&gt;...&lt;/plan&gt;&lt;/thinking&gt;</example>
</examples>
</terminology>
<terminology>
<zh>属性约束</zh>
<en>Attribute Constraint</en>
<definition>
对属性的使用范围、类型和值的规范,确保一致性和合规性。</definition>
<examples>
<example>属性值必须用双引号包裹如type="analysis"。</example>
</examples>
</terminology>
<terminology>
<zh>语义透明性</zh>
<en>Semantic Transparency</en>
<definition>
标签和属性名称具有自解释性,使结构意图和功能直观可理解。</definition>
<examples>
<example>&lt;executing&gt;表示执行单元,&lt;plan&gt;表示计划内容。</example>
</examples>
</terminology>
<terminology>
<zh>释义即实现</zh>
<en>Definition-as-Implementation</en>
<definition>
对提示词的语义释义本身即构成实现,无需额外转换层。</definition>
<examples>
<example>AI理解"# 步骤\n1. 首先..."后直接执行,无需再转译。</example>
</examples>
</terminology>
<terminology>
<zh>组合复用</zh>
<en>Composable Reuse</en>
<definition>
通过协议组合和结构嵌套,实现提示词的模块化和复用。</definition>
<examples>
<example>&lt;memory&gt;&lt;store:execution&gt;...&lt;/store:execution&gt;&lt;/memory&gt;</example>
</examples>
</terminology>
<terminology>
<zh>一致性理解</zh>
<en>Consistent Understanding</en>
<definition>
同一DPML结构在不同AI系统中应产生一致的理解和行为。</definition>
<examples>
<example>不同平台解析同一DPML提示词行为一致。</example>
</examples>
</terminology>
</terminologies>

View File

@ -1,14 +1,14 @@
# DPML执行模式提示词框架 # DPML#行为提示单元 框架
> **TL;DR:** DPML执行模式提示词框架定义了结构化的执行类提示词模板,包含流程(Process)、指导原则(Guideline)、强制规则(Rule)、约束条件(Constraint)和评价标准(Criteria)五个核心子概念用于指导AI系统完成具体任务。 > **TL;DR:** DPML#行为提示单元 框架定义了结构化的#行为单元 模板,包含#流程(Process)、#指导原则(Guideline)、#规则(Rule)、#约束(Constraint)和#标准(Criteria)五个核心子概念用于指导AI系统完成具体任务。
### 目的与功能 ### 目的与功能
DPML执行模式提示词框架定义了AI系统执行任务的提示词模板,它的主要功能是: DPML#行为提示单元 框架定义了AI系统执行任务的#行为单元 模板,它的主要功能是:
- 提供执行任务的结构化提示词定义 - 提供执行任务的结构化#行为单元 定义
- 通过标准化提示词明确执行的流程步骤、指导原则、规则、约束和评价标准 - 通过标准化#行为单元 明确#流程 步骤、#指导原则#规则#约束#标准
- 帮助AI系统通过规范化提示词进行精确、可靠的任务执行 - 帮助AI系统通过规范化#行为单元 进行精确、可靠的任务执行
- 提供执行状态追踪和错误处理的提示词模板 - 提供执行状态追踪和错误处理的#行为单元 模板
## 📝 语法定义 ## 📝 语法定义
@ -32,29 +32,29 @@ markdown_content ::= (* 任何有效的Markdown文本可包含特定语法元
## 🧩 语义说明 ## 🧩 语义说明
execution标签表示一个完整的执行框架。标签内容可以包含五种不同概念的子标签,每个子标签都有明确的语义: #行为提示单元 标签表示一个完整的#行为单元 框架。标签内容可以包含五种不同概念的子标签,每个子标签都有明确的语义:
- **process**: 表示执行的具体步骤,包含正常和异常路径,是执行的核心路径定义 - **#流程**: 表示执行的具体步骤,包含正常和异常路径,是#行为单元 的核心路径定义
- **guideline**: 表示建议性指导原则,具有灵活性和可变通性,用于推荐最佳实践 - **#指导原则**: 表示建议性指导原则,具有灵活性和可变通性,用于推荐最佳实践
- **rule**: 表示强制性行为准则,必须严格遵守,通常涉及安全、合规或核心质量要求 - **#规则**: 表示强制性行为准则,必须严格遵守,通常涉及安全、合规或核心质量要求
- **constraint**: 表示客观限制条件,客观存在且不可改变,需要被动适应 - **#约束**: 表示客观限制条件,客观存在且不可改变,需要被动适应
- **criteria**: 表示评价标准,用于判断执行结果是否满足要求 - **#标准**: 表示评价标准,用于判断执行结果是否满足要求
这五个子概念构成了完整的执行框架从不同维度定义了AI系统如何执行任务。 这五个子概念构成了完整的#行为单元 框架从不同维度定义了AI系统如何执行任务。
### 优先级关系 ### 优先级关系
execution框架内的子概念具有以下固定的优先级关系,这种关系定义了如何理解和解释这些概念: #行为提示单元 框架内的子概念具有以下固定的优先级关系,这种关系定义了如何理解和解释这些概念:
1. **Constraint(约束)** - 最高优先级,表示客观存在的限制,不可违反 1. **#约束** - 最高优先级,表示客观存在的限制,不可违反
2. **Rule(规则)** - 次高优先级,表示必须遵循的行为准则 2. **#规则** - 次高优先级,表示必须遵循的行为准则
3. **Guideline(指导原则)** - 较低优先级,表示可灵活调整的建议性原则 3. **#指导原则** - 较低优先级,表示可灵活调整的建议性原则
4. **Process(流程)** - 在约束和规则的框架内定义执行路径 4. **#流程** - 在#约束#规则 的框架内定义执行路径
5. **Criteria(标准)** - 作为评价依据,验证执行结果是否满足要求 5. **#标准** - 作为评价依据,验证执行结果是否满足要求
这种优先级关系是框架的核心语义特征: 这种优先级关系是框架的核心语义特征:
- 低优先级元素不能与高优先级元素产生冲突 - 低优先级元素不能与高优先级元素产生冲突
- Process必须在Constraint和Rule定义的边界内设计 - #流程 必须在#约束#规则 定义的边界内设计
- Guideline在不违反Rule和Constraint的前提下可以灵活调整 - #指导原则 在不违反#规则#约束 的前提下可以灵活调整
- Criteria需要考虑所有优先级更高的元素的要求 - #标准 需要考虑所有优先级更高的元素的要求

View File

@ -0,0 +1,83 @@
<terminologies>
<terminology>
<zh>行为提示单元</zh>
<en>Execution Prompt Unit</en>
<definition>
<execution>标签及其子标签如process、guideline、rule、constraint、criteria构成的、表达完整行为/执行过程的结构化提示词单元。常简称为"行为单元",两者等同。
</definition>
<examples>
<example>"所有操作流程都应以 #行为提示单元 组织。"</example>
<example>"每个 #行为单元 都可以独立复用。"</example>
</examples>
</terminology>
<terminology>
<zh>行为单元</zh>
<en>Execution Unit</en>
<definition>
"行为提示单元"的简称,含义完全等同。参见"行为提示单元"。
</definition>
<examples>
<example>"请将你的执行方案拆分为多个 #行为单元。"</example>
</examples>
</terminology>
<terminology>
<zh>流程</zh>
<en>Process</en>
<definition>
在本协议中,#流程 专指 <process> 标签及其结构单元,表示用于承载具体执行步骤、路径的提示词片段。
</definition>
<examples>
<example>"请将详细步骤写入 #流程 单元(即 <process> 标签)。"</example>
</examples>
</terminology>
<terminology>
<zh>指导原则</zh>
<en>Guideline</en>
<definition>
在本协议中,#指导原则 专指 <guideline> 标签及其结构单元,表示用于承载建议性、灵活调整的行为指导内容的提示词片段。
</definition>
<examples>
<example>"所有建议请归入 #指导原则 单元(即 <guideline> 标签)。"</example>
</examples>
</terminology>
<terminology>
<zh>规则</zh>
<en>Rule</en>
<definition>
在本协议中,#规则 专指 <rule> 标签及其结构单元,表示用于承载必须遵守的强制性行为准则的提示词片段。
</definition>
<examples>
<example>"合规要求请写入 #规则 单元(即 <rule> 标签)。"</example>
</examples>
</terminology>
<terminology>
<zh>约束</zh>
<en>Constraint</en>
<definition>
在本协议中,#约束 专指 <constraint> 标签及其结构单元,表示用于承载客观限制条件的提示词片段。
</definition>
<examples>
<example>"所有不可更改的限制请写入 #约束 单元(即 <constraint> 标签)。"</example>
</examples>
</terminology>
<terminology>
<zh>标准</zh>
<en>Criteria</en>
<definition>
在本协议中,#标准 专指 <criteria> 标签及其结构单元,表示用于承载评价标准、验收依据的提示词片段。
</definition>
<examples>
<example>"验收要求请写入 #标准 单元(即 <criteria> 标签)。"</example>
</examples>
</terminology>
<terminology>
<zh>行为模式</zh>
<en>Execution Mode</en>
<definition>
在本协议中,#行为模式 指不同类型的行为/执行方式,如 #流程#指导原则#规则#约束#标准 等,分别由 <process><guideline><rule><constraint><criteria> 标签实现。
</definition>
<examples>
<example>"复杂任务可组合多种 #行为模式。"</example>
</examples>
</terminology>
</terminologies>

View File

@ -1,17 +1,17 @@
# DPML记忆模式提示词框架 # DPML#记忆提示单元 框架
> **TL;DR:** DPML记忆模式提示词框架定义了AI系统的记忆管理提示词模板,支持运行时记忆管理,包含评估(evaluate)、存储(store)和回忆(recall)三个核心组件,实现完整的动态记忆能力。 > **TL;DR:** DPML#记忆提示单元 框架定义了AI系统的#记忆管理#记忆单元 模板,支持运行时#动态记忆 管理,包含#评估(evaluate)、#存储(store)和#回忆(recall)三个核心#记忆操作,实现完整的#记忆循环 能力。
### 目的与功能 ### 目的与功能
DPML记忆模式提示词框架为AI系统提供完整的记忆能力提示词模板,主要功能包括: DPML#记忆提示单元 框架为AI系统提供完整的#记忆单元 模板,主要功能包括:
- 提供运行时记忆的评估、存储和检索的标准化提示词机制 - 提供运行时#动态记忆#评估#存储#回忆 的标准化#记忆操作 机制
- 实现跨会话的信息持久化提示词模板 - 实现跨会话的信息持久化#记忆单元 模板
- 支持复杂的记忆关联和检索模式的提示词构建 - 支持复杂的#记忆关联#记忆检索 模式的#记忆提示单元 构建
## 🔍 基本信息 ## 🔍 基本信息
**框架名称:** `<memory>` (DPML记忆模式提示词框架) **框架名称:** `<memory>` (DPML#记忆提示单元 框架)
## 📝 语法定义 ## 📝 语法定义
@ -38,38 +38,42 @@ text ::= (* 任何文本内容 *)
## 🧩 语义说明 ## 🧩 语义说明
memory标签表示AI系统的记忆管理单元定义了动态记忆的结构和操作方式。它由运行时记忆管理的三个核心部分组成 #记忆提示单元 标签表示AI系统的#记忆管理 单元,定义了#动态记忆 的结构和#记忆操作 方式。它由运行时#记忆管理 的三个核心部分组成:
### 记忆操作 ### #记忆操作
memory标签包含三个核心子标签,分别对应记忆的三个操作阶段: #记忆提示单元 包含三个核心子标签,分别对应#记忆操作 的三个阶段:
1. **`<evaluate:thought>`**评估信息是否值得记忆 1. **`<evaluate:thought>`**#评估 信息是否值得记忆
- 通过thought协议实现评估过程 - 通过thought协议实现#评估 过程
- 判断信息的价值、相关性和可信度 - 判断信息的价值、相关性和可信度
- 决定是否将信息存入记忆系统 - 决定是否将信息存入#记忆系统
2. **`<store:execution>`**:将信息存入记忆系统 2. **`<store:execution>`**:将信息#存储#记忆系统
- 通过execution协议实现存储操作 - 通过execution协议实现#存储 操作
- 定义存储过程、规则和约束 - 定义#存储 过程、规则和约束
- 管理记忆的添加、更新和组织 - 管理#记忆单元 的添加、更新和组织
3. **`<recall:thought>`**:从记忆系统检索并应用信息 3. **`<recall:thought>`**:从#记忆系统 检索并应用信息
- 通过thought协议实现回忆过程 - 通过thought协议实现#回忆 过程
- 判断何时需要检索特定记忆 - 判断何时需要#回忆 特定记忆
- 规划如何检索和应用记忆内容 - 规划如何#回忆 和应用#记忆内容
- 可以使用多种实现方式,包括但不限于资源引用 - 可以使用多种实现方式,包括但不限于#资源引用
- **注意**recall标签中的资源引用默认是按需加载的 - **注意**#回忆 标签中的#资源引用 默认是按需加载的
### 组件关系 ### #记忆单元 关系
三个核心组件之间具有明确的逻辑关系: 三个核心组件之间具有明确的逻辑关系:
- evaluate-store-recall构成动态记忆的完整循环 - #评估-#存储-#回忆 构成#动态记忆 的完整#记忆循环
- evaluate决定什么值得记忆 - #评估 决定什么值得记忆
- store定义如何保存记忆 - #存储 定义如何保存记忆
- recall描述何时以及如何使用记忆 - #回忆 描述何时以及如何使用记忆
记忆系统的运行遵循"评估-存储-回忆"的循环模式,不断丰富和发展角色的记忆能力。 #记忆系统 的运行遵循"#评估-#存储-#回忆"的#记忆循环 模式,不断丰富和发展角色的#记忆能力。
> **注意**:先验知识库(knowledge)已经迁移至`<role>`标签下管理,`<memory>`标签专注于动态记忆的运行时管理。 > **注意**#先验知识库(knowledge)已经迁移至`<role>`标签下管理,`<memory>`标签专注于#动态记忆 的运行时管理。
### #记忆模式
#记忆提示单元 支持多种#记忆模式,如#工作记忆、#短期记忆、#长期记忆、#陈述性记忆、#程序性记忆、#情境性记忆 等,可根据场景灵活配置和切换。

View File

@ -0,0 +1,163 @@
<terminologies>
<terminology>
<zh>记忆提示单元</zh>
<en>Memory Prompt Unit</en>
<definition>
<memory>标签及其子标签如evaluate:thought、store:execution、recall:thought构成的、表达记忆管理与操作的结构化提示词单元。常简称为"记忆单元",两者等同。
</definition>
<examples>
<example>"所有运行时信息管理都应以 #记忆提示单元 组织。"</example>
<example>"每个 #记忆单元 都可以独立复用。"</example>
</examples>
</terminology>
<terminology>
<zh>记忆单元</zh>
<en>Memory Unit</en>
<definition>
"记忆提示单元"的简称,含义完全等同。参见"记忆提示单元"。
</definition>
<examples>
<example>"请将你的记忆操作拆分为多个 #记忆单元。"</example>
</examples>
</terminology>
<terminology>
<zh>评估</zh>
<en>Evaluate</en>
<definition>
在本协议中,#评估 专指 <evaluate:thought> 标签及其结构单元,表示用于判断信息是否值得记忆的提示词片段。
</definition>
<examples>
<example>"所有信息入库前需经过 #评估 单元(即 <evaluate:thought> 标签)。"</example>
</examples>
</terminology>
<terminology>
<zh>存储</zh>
<en>Store</en>
<definition>
在本协议中,#存储 专指 <store:execution> 标签及其结构单元,表示用于将信息写入记忆系统的提示词片段。
</definition>
<examples>
<example>"数据写入请归入 #存储 单元(即 <store:execution> 标签)。"</example>
</examples>
</terminology>
<terminology>
<zh>回忆</zh>
<en>Recall</en>
<definition>
在本协议中,#回忆 专指 <recall:thought> 标签及其结构单元,表示用于从记忆系统检索信息的提示词片段。
</definition>
<examples>
<example>"检索操作请写入 #回忆 单元(即 <recall:thought> 标签)。"</example>
</examples>
</terminology>
<terminology>
<zh>记忆操作</zh>
<en>Memory Operation</en>
<definition>
在本协议中,#记忆操作#评估-#存储-#回忆 的完整循环过程。
</definition>
<examples>
<example>"#记忆操作 需遵循评估-存储-回忆的顺序。"</example>
</examples>
</terminology>
<terminology>
<zh>动态记忆</zh>
<en>Dynamic Memory</en>
<definition>
在本协议中,#动态记忆 指运行时可变的记忆内容,与#先验知识库 区分。
</definition>
<examples>
<example>"#动态记忆 反映AI当前会话的上下文。"</example>
</examples>
</terminology>
<terminology>
<zh>先验知识库</zh>
<en>Prior Knowledge Base</en>
<definition>
在本协议中,#先验知识库 指角色固有的、初始化的知识体系,不属于#动态记忆 范畴。
</definition>
<examples>
<example>"#先验知识库<role>标签管理。"</example>
</examples>
</terminology>
<terminology>
<zh>记忆循环</zh>
<en>Memory Cycle</en>
<definition>
在本协议中,#记忆循环#评估-#存储-#回忆 的循环模式。
</definition>
<examples>
<example>"#记忆循环 有助于持续优化AI记忆。"</example>
</examples>
</terminology>
<terminology>
<zh>记忆模式</zh>
<en>Memory Mode</en>
<definition>
在本协议中,#记忆模式 指不同的#评估#存储#回忆 实现方式。
</definition>
<examples>
<example>"可根据场景切换不同 #记忆模式。"</example>
</examples>
</terminology>
<terminology>
<zh>工作记忆</zh>
<en>Working Memory</en>
<definition>
在本协议中,#工作记忆 指AI在当前任务或会话中临时存储和处理的信息具有短时性和高活跃度。
</definition>
<examples>
<example>"#工作记忆 主要用于当前推理和决策。"</example>
</examples>
</terminology>
<terminology>
<zh>短期记忆</zh>
<en>Short-term Memory</en>
<definition>
在本协议中,#短期记忆 指AI在较短时间内保留的信息支持跨轮对话和短时上下文。
</definition>
<examples>
<example>"#短期记忆 可用于多轮对话的上下文保持。"</example>
</examples>
</terminology>
<terminology>
<zh>长期记忆</zh>
<en>Long-term Memory</en>
<definition>
在本协议中,#长期记忆 指AI可持久保存、跨会话复用的重要信息。
</definition>
<examples>
<example>"用户偏好应存入 #长期记忆。"</example>
</examples>
</terminology>
<terminology>
<zh>陈述性记忆</zh>
<en>Declarative Memory</en>
<definition>
在本协议中,#陈述性记忆 指可被明确表达和检索的事实性知识,如事件、概念等。
</definition>
<examples>
<example>"知识库内容属于 #陈述性记忆。"</example>
</examples>
</terminology>
<terminology>
<zh>程序性记忆</zh>
<en>Procedural Memory</en>
<definition>
在本协议中,#程序性记忆 指AI掌握的操作流程、技能和执行规则。
</definition>
<examples>
<example>"常用操作流程应归入 #程序性记忆。"</example>
</examples>
</terminology>
<terminology>
<zh>情境性记忆</zh>
<en>Contextual Memory</en>
<definition>
在本协议中,#情境性记忆 指与特定场景、环境或上下文相关的记忆内容。
</definition>
<examples>
<example>"对话场景信息属于 #情境性记忆。"</example>
</examples>
</terminology>
</terminologies>

View File

@ -1,29 +1,29 @@
# DPML资源模式提示词框架 # DPML#资源提示单元 框架
> **TL;DR:** DPML资源模式提示词框架定义了统一的资源引用提示词模板,支持通过`@协议名://路径`形式在提示词中访问和操作各类资源。 > **TL;DR:** DPML#资源提示单元 框架定义了统一的#资源单元 模板,支持通过#资源引用(@协议名://路径形式在提示词中访问和操作各类资源。
### 目的与功能 ### 目的与功能
DPML资源模式提示词框架用于定义特定类型的资源访问提示词,使开发者能够以标准化的方式在提示词中描述如何引用和处理各种资源。通过这个框架,可以明确资源提示词的引用语法、路径规则和查询参数确保资源引用在不同环境中的一致性和可靠性。此框架是PromptX中资源引用协议RP在提示词层面的具体实现方式。 DPML#资源提示单元 框架用于定义特定类型的#资源单元,使开发者能够以标准化的方式在提示词中描述如何#定位 和处理各种资源。通过这个框架,可以明确#资源协议 的引用语法、#位置 规则和#查询参数,确保#资源引用 在不同环境中的一致性和可靠性。此框架是PromptX中#资源协议RP在提示词层面的具体实现方式。
主要功能包括: 主要功能包括:
- 定义资源提示词的标识和引用方式 - 定义#资源单元 的标识和#资源引用 方式
- 规范化资源路径的提示词语法结构和解析规则 - 规范化#位置 的提示词语法结构和#解析 规则
- 指定资源提示词支持的查询参数和格式 - 指定#资源单元 支持的#查询参数 和格式
- 提供资源类提示词的标准化示例 - 提供#资源单元 的标准化示例
### 默认支持的通用协议 ### 默认支持的通用#资源协议
PromptX默认支持以下通用且已有共识的协议这些协议符合`@协议名://路径`格式,遵循其业界标准语法和规则,无需在resource标签中重新定义: PromptX默认支持以下通用且已有共识的#资源协议,这些协议符合`@协议名://路径`格式,遵循其业界标准语法和规则,无需在#资源单元 中重新定义:
| 协议 | 描述 | 示例 | | #资源协议 | 描述 | 示例 |
|-------|------|------| |-------|------|------|
| file | 文件系统资源 | `@file://path/to/file.txt` | | file | 文件系统资源 | `@file://path/to/file.txt` |
| http/https | HTTP/HTTPS网络资源 | `@https://example.com/api/data` | | http/https | HTTP/HTTPS网络资源 | `@https://example.com/api/data` |
| ftp/sftp | 文件传输协议 | `@ftp://user:pass@host/path` | | ftp/sftp | 文件传输协议 | `@ftp://user:pass@host/path` |
| ssh | 安全Shell协议 | `@ssh://user@host/path` | | ssh | 安全Shell协议 | `@ssh://user@host/path` |
这些通用协议的路径格式和查询参数遵循它们的标准规范。对于特定领域或自定义的协议,才需要使用resource标签进行详细定义。 这些通用#资源协议 的路径格式和#查询参数 遵循它们的标准规范。对于特定领域或自定义的#资源协议,才需要使用#资源单元 进行详细定义。
## 📝 语法定义 ## 📝 语法定义
@ -44,17 +44,17 @@ markdown_content ::= (* 任何有效的Markdown文本包括代码块、表格
### 子标签语义 ### 子标签语义
resource标签包含三个核心子标签,用于定义资源协议的具体内容: #资源单元 包含三个核心子标签,用于定义#资源协议 的具体内容:
- **location**定义该资源协议的路径规则。通常采用EBNF形式化语法描述路径结构并可包含示例说明。 - **#位置**:定义该#资源协议 的路径规则。通常采用EBNF形式化语法描述路径结构并可包含示例说明。
- **params**:定义该资源协议支持的查询参数。通常采用表格形式列出参数名称、类型、描述和用法示例。 - **#参数**:定义该#资源协议 支持的#查询参数。通常采用表格形式列出参数名称、类型、描述和用法示例。
- **registry**根据location和params定义注册抽象参数与具体资源的映射关系。通常采用表格形式列出ID到实际资源路径的映射。 - **#注册表**:根据#位置#参数 定义注册抽象参数与具体资源的映射关系。通常采用表格形式列出ID到实际资源路径的映射。
这三个子标签共同构成资源协议的完整定义:location定义资源的定位格式params定义资源的访问选项,registry将抽象ID映射到具体资源路径。标签应按照location、params、registry的顺序定义确保registry可以基于前两个标签的内容建立正确的映射关系。 这三个子标签共同构成#资源协议 的完整定义:#位置 定义资源的#定位 格式,#参数 定义资源的访问选项,#注册表 将抽象ID映射到具体资源路径。标签应按照#位置#参数#注册表 的顺序定义,确保#注册表 可以基于前两个标签的内容建立正确的映射关系。
### `@` 引用协议 ### `@` #资源引用 协议
resource标签定义了一个资源协议,指定了如何使用`@`符号作为统一入口,遵循以下核心语法规则: #资源单元 定义了一个#资源协议,指定了如何使用`@`符号作为统一入口,遵循以下核心语法规则:
```ebnf ```ebnf
resource_reference ::= ('[@]' | '@!' | '@?') protocol_name ':' resource_location [query_params] resource_reference ::= ('[@]' | '@!' | '@?') protocol_name ':' resource_location [query_params]
@ -65,19 +65,19 @@ path ::= path_segment {'/' path_segment}
query_params ::= '?' param_name '=' param_value {'&' param_name '=' param_value} query_params ::= '?' param_name '=' param_value {'&' param_name '=' param_value}
``` ```
#### 资源加载语义 #### #加载语义
资源引用支持三种加载语义前缀: #资源引用 支持三种#加载语义 前缀:
| 前缀 | 语义 | 示例 | | 前缀 | 语义 | 示例 |
|-----|------|------| |-----|------|------|
| `@` | 默认模式由AI自行决定加载时机 | `@file://document.md` | | `@` | 默认模式由AI自行决定#加载 时机 | `@file://document.md` |
| `@!` | 强制立即加载AI看到引用时必须立即使用工具调用获取内容 | `@!https://example.com/data` | | `@!` | #热加载AI看到引用时必须立即#加载 | `@!https://example.com/data` |
| `@?` | 显式懒加载AI仅记录资源位置在实际需要使用时才获取内容 | `@?file://large-dataset.csv` | | `@?` | #懒加载AI仅记录资源位置在实际需要使用时才#加载 | `@?file://large-dataset.csv` |
#### 基础资源引用 #### 基础#资源引用
基础资源引用使用单一协议: 基础#资源引用 使用单一#资源协议
``` ```
@protocol://path @protocol://path
``` ```
@ -86,12 +86,12 @@ query_params ::= '?' param_name '=' param_value {'&' param_name '=' param_value}
- `@file://document.md` - 引用文件系统中的文档 - `@file://document.md` - 引用文件系统中的文档
- `@http://example.com/api/data.json` - 引用网络资源 - `@http://example.com/api/data.json` - 引用网络资源
- `@memory://user_preferences` - 引用内存中的数据 - `@memory://user_preferences` - 引用内存中的数据
- `@!file://important.md` - 立即加载重要文档 - `@!file://important.md` - #热加载 重要文档
- `@?file://large-dataset.csv` - 懒加载大型数据集 - `@?file://large-dataset.csv` - #懒加载 大型数据集
#### 嵌套资源引用 #### #嵌套引用
嵌套资源引用允许一个协议处理另一个协议的输出: #嵌套引用 允许一个#资源协议 处理另一个#资源协议 的输出:
**完整形式**(内部使用@符号 **完整形式**(内部使用@符号
``` ```
@ -103,29 +103,29 @@ query_params ::= '?' param_name '=' param_value {'&' param_name '=' param_value}
@outer:inner://path @outer:inner://path
``` ```
嵌套引用时也可以指定加载语义: #嵌套引用 时也可以指定#加载语义:
``` ```
@outer:@!inner://path // 内部资源立即加载 @outer:@!inner://path // 内部资源#热加载
@!outer:@?inner://path // 外部立即处理,内部懒加载 @!outer:@?inner://path // 外部#热加载,内部#懒加载
``` ```
例如: 例如:
- `@thinking:@file://method.md` - 对文件内容应用thinking协议处理 - `@thinking:@file://method.md` - 对文件内容应用thinking协议处理
- `@execution:file://workflow.md` - 对文件内容应用execution协议处理 - `@execution:file://workflow.md` - 对文件内容应用execution协议处理
- `@outer:middle:inner://resource` - 多层嵌套(从内向外处理) - `@outer:middle:inner://resource` - 多层#嵌套引用(从内向外处理)
- `@!thinking:@?file://large-file.md` - 立即应用thinking但文件内容懒加载 - `@!thinking:@?file://large-file.md` - 立即应用thinking但文件内容#懒加载
#### 路径通配符 #### #路径通配符
路径支持以下通配符模式: 路径支持以下#路径通配符 模式:
- `*` - 匹配单层中的任意文件或目录,如`@file://docs/*.md` - `*` - 匹配单层中的任意文件或目录,如`@file://docs/*.md`
- `**` - 匹配多层目录和文件,如`@file://src/**/*.js` - `**` - 匹配多层目录和文件,如`@file://src/**/*.js`
- `*.ext` - 匹配特定扩展名的文件,如`@file://docs/*.txt` - `*.ext` - 匹配特定扩展名的文件,如`@file://docs/*.txt`
- `*.{ext1,ext2}` - 匹配多种扩展名,如`@file://src/*.{js,ts}` - `*.{ext1,ext2}` - 匹配多种扩展名,如`@file://src/*.{js,ts}`
#### 查询参数 #### #查询参数
查询参数提供额外的资源处理指令: #查询参数 提供额外的资源处理指令:
``` ```
@protocol://path?param1=value1&param2=value2 @protocol://path?param1=value1&param2=value2
``` ```
@ -134,14 +134,14 @@ query_params ::= '?' param_name '=' param_value {'&' param_name '=' param_value}
- `@file://document.md?line=5-10` - 只获取文件的第5-10行 - `@file://document.md?line=5-10` - 只获取文件的第5-10行
- `@http://api.example.com/data?format=json&cache=false` - 指定返回格式并禁用缓存 - `@http://api.example.com/data?format=json&cache=false` - 指定返回格式并禁用缓存
#### 资源注册与抽象引用 #### #注册表 解析与抽象引用
使用registry定义的资源可以通过抽象ID引用无需知道具体路径 使用#注册表 定义的资源可以通过抽象ID引用无需知道具体路径
``` ```
@protocol://resource_id @protocol://resource_id
``` ```
例如定义了以下registry 例如定义了以下#注册表
```xml ```xml
<resource protocol="thought"> <resource protocol="thought">
<location> <location>
@ -162,25 +162,25 @@ query_params ::= '?' param_name '=' param_value {'&' param_name '=' param_value}
- `@thought://analytical` - 自动映射到对应文件 - `@thought://analytical` - 自动映射到对应文件
- `@thought://creative` - 自动映射到对应文件 - `@thought://creative` - 自动映射到对应文件
这种抽象引用机制提供了路由层,使资源引用与实际存储位置解耦,方便管理和移植。 这种抽象引用机制提供了路由层,使#资源引用 与实际存储位置解耦,方便管理和移植。
### 解析规则 ### #解析 规则
1. 资源引用解析从左至右进行,先识别协议名称,再解析资源位置和查询参数 1. #资源引用 解析从左至右进行,先识别#资源协议 名称,再#解析 资源位置和#查询参数
2. 嵌套引用从内向外解析,内层资源引用的结果作为外层引用的输入 2. #嵌套引用 从内向外#解析,内层#资源引用 的结果作为外层引用的输入
3. 查询参数应用于资源加载后的处理阶段,不影响资源的基本定位 3. #查询参数 应用于资源#加载 后的处理阶段,不影响资源的基本#定位
4. 相对路径解析基于当前上下文的工作目录或基础路径 4. 相对路径#定位 基于当前上下文的工作目录或基础路径
5. 资源加载语义前缀(@、@!、@?)优先于其他部分解析,决定资源的加载策略 5. #加载语义 前缀(@、@!、@?)优先于其他部分#解析,决定资源的#加载 策略
### 资源获取实现说明 ### #加载 实现说明
对于支持工具调用能力的AI系统: 对于支持工具调用能力的AI系统:
1. **主动获取责任**: AI需主动使用工具调用(例如read_file)获取@引用的资源,而非等待系统自动加载 1. **主动#加载 责任**: AI需主动使用工具调用(例如read_file)获取@引用的资源,而非等待系统自动#加载
2. **立即加载义务**: 特别是对于@!前缀资源AI必须立即执行工具调用获取内容 2. **#热加载 义务**: 特别是对于@!前缀资源AI必须立即执行工具调用#加载 内容
3. **自主判断懒加载**: 对于@?前缀资源AI应记录位置但暂不加载直到实际需要使用时 3. **自主判断#懒加载**: 对于@?前缀资源AI应记录位置但暂不#加载,直到实际需要使用时
4. **加载验证**: AI应验证资源是否成功加载并适当处理加载失败情况 4. **#加载 验证**: AI应验证资源是否成功#加载,并适当处理#加载 失败情况
5. **注册表解析**: 对于使用`registry`注册的资源引用AI应首先解析资源ID找到对应的实际资源路径然后再应用上述规则获取资源 5. **#注册表 解析**: 对于使用#注册表 注册的#资源引用AI应首先#解析 资源ID找到对应的实际资源路径然后再应用上述规则获取资源
这种主动获取模式确保AI能正确执行协议定义的资源加载语义,而不依赖系统层面的自动处理。registry机制则提供了资源引用的抽象层,使资源组织更加灵活和模块化。 这种主动#加载 模式确保AI能正确执行协议定义的#加载语义,而不依赖系统层面的自动处理。#注册表 机制则提供了#资源引用 的抽象层,使资源组织更加灵活和模块化。

View File

@ -0,0 +1,173 @@
<terminologies>
<terminology>
<zh>资源提示单元</zh>
<en>Resource Prompt Unit</en>
<definition>
<resource>标签及其子标签如location、params、registry构成的、表达资源访问与引用的结构化提示词单元。常简称为"资源单元",两者等同。
</definition>
<examples>
<example>"所有外部数据访问都应以 #资源提示单元 组织。"</example>
<example>"每个 #资源单元 都可以独立复用。"</example>
</examples>
</terminology>
<terminology>
<zh>资源单元</zh>
<en>Resource Unit</en>
<definition>
"资源提示单元"的简称,含义完全等同。参见"资源提示单元"。
</definition>
<examples>
<example>"请将你的引用方案拆分为多个 #资源单元。"</example>
</examples>
</terminology>
<terminology>
<zh>位置</zh>
<en>Location</en>
<definition>
在本协议中,#位置 专指 <location> 标签及其结构单元,表示用于定义资源路径规则的提示词片段。
</definition>
<examples>
<example>"请将路径规则写入 #位置 单元(即 <location> 标签)。"</example>
</examples>
</terminology>
<terminology>
<zh>参数</zh>
<en>Params</en>
<definition>
在本协议中,#参数 专指 <params> 标签及其结构单元,表示用于定义资源支持的查询参数的提示词片段。
</definition>
<examples>
<example>"所有可选参数请归入 #参数 单元(即 <params> 标签)。"</example>
</examples>
</terminology>
<terminology>
<zh>注册表</zh>
<en>Registry</en>
<definition>
在本协议中,#注册表 专指 <registry> 标签及其结构单元表示用于定义资源ID与实际路径映射关系的提示词片段。
</definition>
<examples>
<example>"资源ID映射请写入 #注册表 单元(即 <registry> 标签)。"</example>
</examples>
</terminology>
<terminology>
<zh>资源协议</zh>
<en>Resource Protocol</en>
<definition>
在本协议中,#资源协议 指 file、http、memory 等协议名部分,用于标识资源类型和访问方式。
</definition>
<examples>
<example>"#资源协议 支持 file、http、memory 等多种类型。"</example>
</examples>
</terminology>
<terminology>
<zh>资源引用</zh>
<en>Resource Reference</en>
<definition>
在本协议中,#资源引用@file://path@memory://id 等资源的引用表达式。
</definition>
<examples>
<example>"请用 #资源引用 方式标注外部依赖。"</example>
</examples>
</terminology>
<terminology>
<zh>加载语义</zh>
<en>Loading Semantics</en>
<definition>
在本协议中,#加载语义 指 @、@!、@? 前缀,决定资源的加载策略。
</definition>
<examples>
<example>"#加载语义 决定资源是立即加载还是懒加载。"</example>
</examples>
</terminology>
<terminology>
<zh>加载</zh>
<en>Load</en>
<definition>
在本协议中,#加载 指资源的实际获取、读取或载入过程。
</definition>
<examples>
<example>"#加载 过程由 AI 主动发起。"</example>
</examples>
</terminology>
<terminology>
<zh>懒加载</zh>
<en>Lazy Load</en>
<definition>
在本协议中,#懒加载 指资源仅在实际需要时才加载,通常与 @? 前缀相关。
</definition>
<examples>
<example>"大文件建议采用 #懒加载 策略。"</example>
</examples>
</terminology>
<terminology>
<zh>热加载</zh>
<en>Eager Load</en>
<definition>
在本协议中,#热加载(即立即加载)指资源在被引用时立即加载,通常与 @! 前缀相关。
</definition>
<examples>
<example>"关键依赖应采用 #热加载 策略。"</example>
</examples>
</terminology>
<terminology>
<zh>定位</zh>
<en>Locate</en>
<definition>
在本协议中,#定位 指通过协议和路径规则确定资源实际位置的过程。
</definition>
<examples>
<example>"#定位 过程依赖 #位置 单元的定义。"</example>
</examples>
</terminology>
<terminology>
<zh>解析</zh>
<en>Parse</en>
<definition>
在本协议中,#解析 指对资源引用表达式、路径、参数等进行语法和语义分析的过程。
</definition>
<examples>
<example>"#解析 资源引用时需处理嵌套结构。"</example>
</examples>
</terminology>
<terminology>
<zh>嵌套引用</zh>
<en>Nested Reference</en>
<definition>
在本协议中,#嵌套引用 指资源引用中包含另一个资源引用的结构,如 @outer:@inner://path
</definition>
<examples>
<example>"复杂场景可用 #嵌套引用 实现多层资源处理。"</example>
</examples>
</terminology>
<terminology>
<zh>路径通配符</zh>
<en>Path Wildcard</en>
<definition>
在本协议中,#路径通配符*、**、*.ext 等通配符用法,用于灵活匹配资源路径。
</definition>
<examples>
<example>"#路径通配符 支持批量引用资源。"</example>
</examples>
</terminology>
<terminology>
<zh>查询参数</zh>
<en>Query Parameter</en>
<definition>
在本协议中,#查询参数 指 ?param=value 结构,用于为资源引用提供额外指令。
</definition>
<examples>
<example>"#查询参数 可用于指定加载范围。"</example>
</examples>
</terminology>
<terminology>
<zh>资源模式</zh>
<en>Resource Mode</en>
<definition>
在本协议中,#资源模式 指不同类型的资源访问与引用方式,如 #位置#参数#注册表 等,分别由 <location><params><registry> 标签实现。
</definition>
<examples>
<example>"支持多种 #资源模式 灵活访问外部数据。"</example>
</examples>
</terminology>
</terminologies>

View File

@ -1,14 +1,14 @@
# DPML角色合成提示词框架 # DPML#角色提示单元 框架
> **TL;DR:** DPML角色合成提示词框架解释了如何通过组合思考模式、执行模式和记忆模式三大基础协议来构建完整的AI角色支持不同类型角色的构建和定制。 > **TL;DR:** DPML#角色提示单元 框架解释了如何通过组合#思维模式、#行为模式 和#记忆模式 三大基础协议来构建完整的#AI角色支持不同类型#角色模式 的构建和定制。
### 目的与功能 ### 目的与功能
DPML角色合成提示词框架说明了如何通过基础协议的组合构建AI角色它的主要功能是 DPML#角色提示单元 框架说明了如何通过基础协议的组合构建#AI角色,它的主要功能是:
- 提供角色构建的标准方法论 - 提供#角色合成 的标准方法论
- 指导如何将思考、执行和记忆协议组合以表达角色特性 - 指导如何将#思维模式#行为模式#记忆模式 组合以表达#角色特性
- 支持不同类型角色的灵活定制 - 支持不同类型#角色模式 的灵活定制
- 确保角色定义的一致性和完整性 - 确保#角色定义 的一致性和完整性
## 📝 语法定义 ## 📝 语法定义
@ -17,7 +17,7 @@ DPML角色合成提示词框架说明了如何通过基础协议的组合构建A
role_element ::= '<role' attributes? '>' role_content '</role>' role_element ::= '<role' attributes? '>' role_content '</role>'
role_content ::= (personality_element | principle_element | knowledge_element | experience_element | action_element)+ role_content ::= (personality_element | principle_element | knowledge_element | experience_element | action_element)+
(* 角色组织标签 *) (* #角色组织标签 *)
personality_element ::= '<personality' attributes? '>' personality_content '</personality>' personality_element ::= '<personality' attributes? '>' personality_content '</personality>'
principle_element ::= '<principle' attributes? '>' principle_content '</principle>' principle_element ::= '<principle' attributes? '>' principle_content '</principle>'
knowledge_element ::= '<knowledge' attributes? '>' knowledge_content '</knowledge>' knowledge_element ::= '<knowledge' attributes? '>' knowledge_content '</knowledge>'
@ -41,36 +41,36 @@ value ::= [^"]*
## 🧩 语义说明 ## 🧩 语义说明
`<role>`标签是DPML中定义AI角色的顶层标签,它封装了角色的人格特征、行为原则和知识记忆,共同构成一个完整的角色定义角色定义必须使用`<role>`作为根标签,而不应直接使用其他标签的组合。 `<role>`标签是DPML中定义#AI角色 的顶层#角色提示单元,它封装了#人格#原则#知识记忆,共同构成一个完整的#角色定义#角色定义 必须使用`<role>`作为根标签,而不应直接使用其他标签的组合。
### 角色的组成部分 ### #角色提示单元 的组成部分
- **personality(角色人格)**: 用于设置和编排多种思维模式的优先级 - **#人格(Personality)**: 用于设置和编排多种#思维模式 的优先级
- 思维模式为 `<thought>` 的语义功能 - #思维模式 `<thought>` 的语义功能
- 定义角色拥有的一种或多种思维模式 - 定义#角色 拥有的一种或多种#思维模式
- 设置不同思维模式的激活条件,组合方式和优先级 - 设置不同#思维模式 的激活条件,组合方式和优先级
- 确保角色思维的一致性和可预测性 - 确保#角色思维 的一致性和可预测性
- **principle(角色原则)**: 用于设置和编排多种行为模式的优先级 - **#原则(Principle)**: 用于设置和编排多种#行为模式 的优先级
- 行为模式为 `<execution>` 的语义功能 - #行为模式 `<execution>` 的语义功能
- 定义角色拥有的一种或多种行为模式 - 定义#角色 拥有的一种或多种#行为模式
- 设置不同行为模式的触发条件,执行顺序和优先级 - 设置不同#行为模式 的触发条件,执行顺序和优先级
- 确保角色行为的规范性和可控性 - 确保#角色行为 的规范性和可控性
- **knowledge(角色知识)**: 角色的预设知识库 - **#知识(Knowledge)**: #角色#先验知识库
- 定义角色固有的、初始化的知识体系 - 定义#角色 固有的、初始化的#知识体系
- 提供角色的专业背景和基础认知框架 - 提供#角色 的专业背景和基础认知框架
- 作为角色理解和决策的知识基础 - 作为#角色理解 和决策的#知识基础
- **experience(角色经验)**: 用于设置和编排多种记忆模式的优先级 - **#经验(Experience)**: 用于设置和编排多种#记忆模式 的优先级
- 记忆模式为 `<memory>` 的语义功能 - #记忆模式 `<memory>` 的语义功能
- 定义角色如何评估、存储和回忆信息 - 定义#角色 如何#评估#存储#回忆 信息
- 设置不同记忆模式的检索条件和优先级 - 设置不同#记忆模式 的检索条件和优先级
- 确保角色记忆处理的连贯性和适应性 - 确保#角色记忆处理 的连贯性和适应性
- **action(角色激活)**: 提供角色初始化和执行的入口 - **#激活(Action)**: 提供#角色初始化 和执行的入口
- 定义角色从"定义"到"执行"的转换机制 - 定义#角色 从"定义"到"执行"的转换机制
- 明确角色初始化序列和优先级 - 明确#角色初始化 序列和优先级
- 规定资源加载记忆系统启动等关键步骤 - 规定#资源加载#记忆系统 启动等关键步骤
- 确保角色能够正确地进入执行状态 - 确保#角色 能够正确地进入执行状态
- 建立角色定义与实际执行间的桥梁 - 建立#角色定义 与实际执行间的桥梁

View File

@ -0,0 +1,103 @@
<terminologies>
<terminology>
<zh>角色提示单元</zh>
<en>Role Prompt Unit</en>
<definition>
<role>标签及其子标签如personality、principle、knowledge、experience、action构成的、表达AI角色结构与行为的结构化提示词单元。常简称为"角色单元",两者等同。
</definition>
<examples>
<example>"所有AI角色定义都应以 #角色提示单元 组织。"</example>
<example>"每个 #角色单元 都可以独立复用。"</example>
</examples>
</terminology>
<terminology>
<zh>角色单元</zh>
<en>Role Unit</en>
<definition>
"角色提示单元"的简称,含义完全等同。参见"角色提示单元"。
</definition>
<examples>
<example>"请将你的角色设计拆分为多个 #角色单元。"</example>
</examples>
</terminology>
<terminology>
<zh>人格</zh>
<en>Personality</en>
<definition>
在本协议中,#人格 专指 <personality> 标签及其结构单元,定义角色的#思维模式
</definition>
<examples>
<example>"#人格 决定角色的思考风格。"</example>
</examples>
</terminology>
<terminology>
<zh>原则</zh>
<en>Principle</en>
<definition>
在本协议中,#原则 专指 <principle> 标签及其结构单元,定义角色的#行为模式
</definition>
<examples>
<example>"#原则 约束角色的行为边界。"</example>
</examples>
</terminology>
<terminology>
<zh>知识</zh>
<en>Knowledge</en>
<definition>
在本协议中,#知识 专指 <knowledge> 标签及其结构单元,定义角色的#先验知识库
</definition>
<examples>
<example>"#知识 提供角色的专业背景。"</example>
</examples>
</terminology>
<terminology>
<zh>经验</zh>
<en>Experience</en>
<definition>
在本协议中,#经验 专指 <experience> 标签及其结构单元,定义角色的#记忆模式
</definition>
<examples>
<example>"#经验 影响角色的记忆处理方式。"</example>
</examples>
</terminology>
<terminology>
<zh>激活</zh>
<en>Action</en>
<definition>
在本协议中,#激活 专指 <action> 标签及其结构单元,定义角色的初始化和执行入口。
</definition>
<examples>
<example>"#激活 决定角色的启动流程。"</example>
</examples>
</terminology>
<terminology>
<zh>角色合成</zh>
<en>Role Composition</en>
<definition>
在本协议中,#角色合成 指通过#思维模式#行为模式#记忆模式 三大协议组合构建角色的机制。
</definition>
<examples>
<example>"#角色合成 支持灵活定制AI能力。"</example>
</examples>
</terminology>
<terminology>
<zh>角色模式</zh>
<en>Role Mode</en>
<definition>
在本协议中,#角色模式 指角色内部多种模式(如#思维模式#行为模式#记忆模式)的组合。
</definition>
<examples>
<example>"不同AI可采用不同 #角色模式。"</example>
</examples>
</terminology>
<terminology>
<zh>角色初始化</zh>
<en>Role Initialization</en>
<definition>
在本协议中,#角色初始化 指角色从定义到执行的激活过程。
</definition>
<examples>
<example>"#角色初始化 包含资源加载、记忆系统启动等步骤。"</example>
</examples>
</terminology>
</terminologies>

View File

@ -0,0 +1,105 @@
# DPML术语定义协议 (Terminology Protocol)
> **TL;DR:** DPML术语定义协议提供统一的术语定义和引用框架支持通过`#术语`形式在提示词中引用明确定义的术语确保术语在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 的兼容性,同时提供了清晰的术语引用机制。
### 作用域规则
**隐式作用域**:术语自动具有其所在文档和上下文的作用域,这意味着:
- 术语的定义和使用范围由其所在的文档上下文决定
- 同一术语在不同上下文中可能有不同的定义
- 使用术语时应考虑当前所处的上下文环境

View File

@ -1,15 +1,15 @@
# DPML思考模式提示词框架 # DPML#思考提示单元 框架
> **TL;DR:** DPML思考模式提示词框架定义了结构化的思考类提示词模板,支持四种核心思维模式的提示词构建:横向探索(exploration)、纵向推理(reasoning)、流程计划(plan)和批判挑战(challenge)帮助AI系统进行系统性分析和推理。 > **TL;DR:** DPML#思考提示单元 框架定义了结构化的#思考单元 模板,支持四种核心#思维模式 的#思考提示单元 构建:#探索思维(exploration)、#推理思维(reasoning)、#计划思维plan和#挑战思维(challenge帮助AI系统进行系统性分析和推理。
### 目的与功能 ### 目的与功能
DPML思考模式提示词框架定义了AI系统进行思考分析的提示词模板和结构,它的主要功能是: DPML#思考提示单元 框架定义了AI系统进行思考分析的#思考单元 模板和结构,它的主要功能是:
- 提供结构化的思维分析提示词模板 - 提供结构化的#思维分析#思考提示单元 模板
- 规范化思考类提示词的组织方式 - 规范化#思考单元 的组织方式
- 支持可视化思维导图和决策树的提示词表达 - 支持可视化#思维导图#决策树#思考提示单元 表达
- 帮助AI系统通过标准化提示词进行系统性、全面性的问题分析 - 帮助AI系统通过标准化#思考提示单元 进行系统性、全面性的问题分析
- 区分不同类型的思维模式提示词:探索、推理、计划和挑战 - 区分不同类型的#思维模式#思考提示单元#探索思维#推理思维#计划思维#挑战思维
## 📝 语法定义 ## 📝 语法定义
@ -31,30 +31,30 @@ challenge_element ::= '<challenge' attributes? '>' markdown_content '</challenge
## 🧩 语义说明 ## 🧩 语义说明
thought标签表示一个完整的思考过程或思维框架。标签内容可以包含四种不同思维模式的子标签或直接使用Markdown格式表达思考内容。 #思考提示单元 标签表示一个完整的#思考单元 或#思维框架。标签内容可以包含四种不同#思维模式 的子标签或直接使用Markdown格式表达#思考内容。
子标签具有明确的语义: 子标签具有明确的语义:
- **exploration**: 表示跳跃思考,发散性思维,生成可能性,寻找多种可能性、创新点和关联性 - **#探索思维**: 表示跳跃思考,发散性思维,生成可能性,寻找多种可能性、创新点和关联性
- **reasoning**: 表示连续思考,收敛性思维,验证可能性,深入分析因果关系、逻辑链条 - **#推理思维**: 表示连续思考,收敛性思维,验证可能性,深入分析因果关系、逻辑链条
- **plan**: 表示秩序思考,结构性思维,固化可能性,设计行动步骤、决策路径、组织结构、系统架构 - **#计划思维**: 表示秩序思考,结构性思维,固化可能性,设计行动步骤、决策路径、组织结构、系统架构
- **challenge**: 表示逆向跳跃思考,批判性思维,质疑可能性,寻找假设漏洞、识别潜在风险、测试极限条件 - **#挑战思维**: 表示逆向跳跃思考,批判性思维,质疑可能性,寻找假设漏洞、识别潜在风险、测试极限条件
exploration和challenge是一对思维模式的正反两面:exploration向外发散寻找"可能是什么",而challenge向内批判探究"可能不是什么"。二者都采用跳跃式思考,但方向相反。reasoning负责系统验证而challenge主要提出问题点。 #探索思维 和#挑战思维 是一对#思维模式 的正反两面:#探索思维 向外发散寻找"可能是什么",而#挑战思维 向内批判探究"可能不是什么"。二者都采用跳跃式思考,但方向相反。#推理思维 负责系统验证,而#挑战思维 主要提出问题点。
thought标签特别适合表达概念关系、逻辑推理和系统性思考为AI提供思考分析的参考框架。 #思考提示单元 特别适合表达概念关系、逻辑推理和系统性思考为AI提供#思考分析 的参考框架。
### 推荐的思考顺序 ### 推荐的#思考顺序
在实际思考过程中,推荐遵循如下顺序以获得系统性和全面性的分析结果: 在实际思考过程中,推荐遵循如下顺序以获得系统性和全面性的分析结果:
1. **探索exploration**:首先发散思考,提出尽可能多的可能性和创新点; 1. **#探索思维**:首先发散思考,提出尽可能多的可能性和创新点;
2. **反思/批判challenge**:对探索阶段的内容进行批判性思考,识别潜在风险和假设漏洞; 2. **#挑战思维**:对#探索思维 阶段的内容进行批判性思考,识别潜在风险和假设漏洞;
3. **推理reasoning**:对经过反思筛选的内容进行系统性推理和因果分析; 3. **#推理思维**:对经过#挑战思维 筛选的内容进行系统性推理和因果分析;
4. **计划plan**:最后制定具体的行动方案和决策路径。 4. **#计划思维**:最后制定具体的行动方案和决策路径。
在复杂问题中,challenge和reasoning可多次交替plan阶段也可穿插challenge以确保方案稳健性。 在复杂问题中,#挑战思维#推理思维 可多次交替,#计划思维 阶段也可穿插#挑战思维 以确保方案稳健性。
### 子标签的可选性 ### 子标签的可选性
thought标签内的四种子标签exploration、challenge、reasoning、plan)均为可选。实际的思考提示可以只包含其中的一种、几种,或全部,具体内容由实际需求决定。 #思考提示单元 内的四种#思维模式 子标签(#探索思维、#挑战思维、#推理思维、#计划思维)均为可选。实际的#思考提示单元 可以只包含其中的一种、几种,或全部,具体内容由实际需求决定。
对于提示词的理解者来说,只需知道这些子标签不是必须全部出现,遇到哪些子标签就理解哪些即可,无需关心未出现的部分。 对于提示词的理解者来说,只需知道这些子标签不是必须全部出现,遇到哪些子标签就理解哪些即可,无需关心未出现的部分。

View File

@ -0,0 +1,73 @@
<terminologies>
<terminology>
<zh>思考提示单元</zh>
<en>Thought Prompt Unit</en>
<definition>
<thought>标签及其子标签如exploration、reasoning、plan、challenge构成的、表达完整思考过程的结构化提示词单元。常简称为"思考单元",两者等同。
</definition>
<examples>
<example>"本协议所有复杂推理均应以 #思考提示单元 为基本结构。"</example>
<example>"每个 #思考单元 都可以独立复用。"</example>
</examples>
</terminology>
<terminology>
<zh>思考单元</zh>
<en>Thought Unit</en>
<definition>
"思考提示单元"的简称,含义完全等同。参见"思考提示单元"。
</definition>
<examples>
<example>"请将你的分析拆分为多个 #思考单元。"</example>
</examples>
</terminology>
<terminology>
<zh>探索思维</zh>
<en>Exploration</en>
<definition>
在本协议中,#探索思维 专指 <exploration> 标签及其结构单元,表示用于承载发散性、创新性思考内容的提示词片段。
</definition>
<examples>
<example>"请将你的假设写入 #探索思维 单元(即 <exploration> 标签)。"</example>
</examples>
</terminology>
<terminology>
<zh>推理思维</zh>
<en>Reasoning</en>
<definition>
在本协议中,#推理思维 专指 <reasoning> 标签及其结构单元,表示用于承载因果分析、逻辑推理内容的提示词片段。
</definition>
<examples>
<example>"所有因果链条建议写入 #推理思维 单元(即 <reasoning> 标签)。"</example>
</examples>
</terminology>
<terminology>
<zh>计划思维</zh>
<en>Plan</en>
<definition>
在本协议中,#计划思维 专指 <plan> 标签及其结构单元,表示用于承载行动方案、结构规划内容的提示词片段。
</definition>
<examples>
<example>"最终方案请整理进 #计划思维 单元(即 <plan> 标签)。"</example>
</examples>
</terminology>
<terminology>
<zh>挑战思维</zh>
<en>Challenge</en>
<definition>
在本协议中,#挑战思维 专指 <challenge> 标签及其结构单元,表示用于承载批判性、风险识别内容的提示词片段。
</definition>
<examples>
<example>"请用 #挑战思维 单元(即 <challenge> 标签)补充反例和风险点。"</example>
</examples>
</terminology>
<terminology>
<zh>思维模式</zh>
<en>Thinking Mode</en>
<definition>
在本协议中,#思维模式 指不同类型的思考方式,如 #探索思维#推理思维#计划思维#挑战思维 等,分别由 <exploration><reasoning><plan><challenge> 标签实现。
</definition>
<examples>
<example>"可根据任务需要切换不同 #思维模式。"</example>
</examples>
</terminology>
</terminologies>

View File

@ -22,6 +22,7 @@
| memory-best-practice | @file://PromptX/domain/prompt/execution/memory-best-practice.execution.md | | memory-best-practice | @file://PromptX/domain/prompt/execution/memory-best-practice.execution.md |
| role-best-practice | @file://PromptX/domain/prompt/execution/role-best-practice.execution.md | | role-best-practice | @file://PromptX/domain/prompt/execution/role-best-practice.execution.md |
| resource-best-practice | @file://PromptX/domain/prompt/execution/resource-best-practice.execution.md | | resource-best-practice | @file://PromptX/domain/prompt/execution/resource-best-practice.execution.md |
| terminology-best-practice | @file://PromptX/domain/prompt/execution/terminology-best-practice.execution.md |
| product-owner | @file://PromptX/domain/scrum/execution/product-owner.execution.md | | product-owner | @file://PromptX/domain/scrum/execution/product-owner.execution.md |
</registry> </registry>
</resource> </resource>