添加初始文件结构
This commit is contained in:
sean
81
protocol/application/context.protocol.md
Normal file
81
protocol/application/context.protocol.md
Normal file
@ -0,0 +1,81 @@
|
||||
# context 应用协议
|
||||
|
||||
> **TL;DR:** context标签用于定义AI系统中各类上下文信息的结构和语义，采用简单直观的HTML风格属性标记，专注于"什么是上下文"，是实现CAP(情境感知提示模式)的核心表达机制。
|
||||
|
||||
## 🔍 基本信息
|
||||
|
||||
**标签名:** `<context>`
|
||||
|
||||
### 目的与功能
|
||||
|
||||
context标签在提示工程中提供了情境信息的标准定义方式，主要功能包括：
|
||||
- 定义上下文信息的名称和分类
|
||||
- 提供简洁明了的上下文描述
|
||||
- 支持基本的元数据标注
|
||||
- 为其他模式提供情境依赖的决策支持
|
||||
|
||||
## 📝 语法定义
|
||||
|
||||
```ebnf
|
||||
(* EBNF形式化定义 *)
|
||||
context_element ::= '<context' attributes? '>' content '</context>'
|
||||
attributes ::= (' ' attribute)+ | ''
|
||||
attribute ::= name '="' value '"'
|
||||
name ::= [a-zA-Z][a-zA-Z0-9_-]*
|
||||
value ::= [^"]*
|
||||
content ::= text
|
||||
text ::= (* 任何文本内容，用于简要描述上下文 *)
|
||||
```
|
||||
|
||||
## 🧩 语义说明
|
||||
|
||||
context标签用于在提示词中定义上下文信息。采用简洁的HTML风格属性标记方式，通过id指定唯一标识符，通过class指定分类，标签内容直接描述该上下文的含义。它作为CAP模式的具体实现，为AI系统提供了清晰简洁的上下文定义能力。实际的上下文感知执行逻辑由executing协议负责实现。
|
||||
|
||||
## 💡 最佳实践
|
||||
|
||||
### 核心属性
|
||||
|
||||
context标签主要使用以下属性：
|
||||
|
||||
- **id**: 定义上下文的唯一标识符，如`id="rootDir"`, `id="userName"`
|
||||
- **class**: 定义上下文的分类/维度，如`class="project"`, `class="user"`, `class="system"`
|
||||
|
||||
|
||||
### 内容组织
|
||||
|
||||
context标签内容应简洁明了，直接描述该上下文的含义和用途，无需复杂的结构和格式。
|
||||
|
||||
### 维度分类指南
|
||||
|
||||
使用class属性定义context维度时，建议遵循以下标准分类：
|
||||
|
||||
- **project**: 项目相关上下文，如根目录、语言、框架等
|
||||
- **user**: 用户相关上下文，如用户名、偏好、技能水平等
|
||||
- **system**: 系统相关上下文，如操作系统、硬件资源等
|
||||
- **environment**: 环境相关上下文，如IDE、终端、网络状况等
|
||||
- **task**: 任务相关上下文，如当前目标、进度、限制条件等
|
||||
|
||||
## 📋 使用示例
|
||||
|
||||
```html
|
||||
<!-- 项目根目录 -->
|
||||
<context id="rootDir" class="project">项目根目录路径</context>
|
||||
|
||||
<!-- 项目编程语言 -->
|
||||
<context id="language" class="project">项目主要编程语言</context>
|
||||
|
||||
<!-- 项目框架 -->
|
||||
<context id="frameworks" class="project">项目使用的框架列表</context>
|
||||
|
||||
<!-- 操作系统类型 -->
|
||||
<context id="osType" class="system">操作系统类型</context>
|
||||
|
||||
<!-- 用户名称 -->
|
||||
<context id="userName" class="user">用户名称</context>
|
||||
|
||||
<!-- IDE类型 -->
|
||||
<context id="ideType" class="environment">集成开发环境类型</context>
|
||||
|
||||
<!-- 任务目标 -->
|
||||
<context id="taskGoal" class="task">当前任务的主要目标</context>
|
||||
```
|
||||
128
protocol/application/executing.protocol.md
Normal file
128
protocol/application/executing.protocol.md
Normal file
@ -0,0 +1,128 @@
|
||||
# executing 应用协议
|
||||
|
||||
> **TL;DR:** executing标签用于定义结构化的执行流程，帮助AI系统按步骤完成任务，支持线性、条件和循环等流程控制。
|
||||
|
||||
## 🔍 基本信息
|
||||
|
||||
**标签名:** `<executing>`
|
||||
**版本:** 1.0.0
|
||||
**类别:** 执行
|
||||
**状态:** 草稿
|
||||
**创建日期:** 2023-06-21
|
||||
|
||||
### 目的与功能
|
||||
|
||||
executing标签定义了AI系统执行任务的流程和步骤，它的主要功能是：
|
||||
- 提供线性、有序的执行步骤
|
||||
- 支持条件分支和循环结构
|
||||
- 明确每个步骤的输入、处理和输出
|
||||
- 帮助AI系统进行精确、可靠的任务执行
|
||||
- 提供执行状态追踪和错误处理机制
|
||||
|
||||
## 📝 语法定义
|
||||
|
||||
```ebnf
|
||||
(* EBNF形式化定义 *)
|
||||
executing_element ::= '<executing' attributes? '>' content '</executing>'
|
||||
attributes ::= (' ' attribute)+ | ''
|
||||
attribute ::= name '="' value '"'
|
||||
name ::= [a-zA-Z][a-zA-Z0-9_-]*
|
||||
value ::= [^"]*
|
||||
content ::= markdown_content
|
||||
markdown_content ::= (* 任何有效的Markdown文本，可包含特定语法元素 *)
|
||||
```
|
||||
|
||||
## 🧩 语义说明
|
||||
|
||||
executing标签表示一个完整的执行流程或任务处理过程。标签内容采用Markdown格式，通常包含有序步骤、条件判断、循环结构以及状态跟踪等元素，用于表达严谨的执行逻辑。executing标签特别适合表达算法实现、工作流程和任务执行计划，为AI提供明确的操作指导。
|
||||
|
||||
## 💡 最佳实践
|
||||
|
||||
以下是使用executing标签的一些建议做法，这些并非强制要求，仅作为参考：
|
||||
|
||||
### 推荐属性
|
||||
|
||||
可以考虑使用以下属性来增强executing标签的语义：
|
||||
|
||||
- **mode**: 指定执行模式，如`mode="sequential"`, `mode="conditional"`, `mode="iterative"`, `mode="parallel"`
|
||||
- **context**: 指定执行上下文，如`context="local"`, `context="remote"`, `context="system"`, `context="user"`
|
||||
- **priority**: 指定执行优先级，如`priority="high"`, `priority="normal"`, `priority="low"`
|
||||
- **timeout**: 指定执行超时时间，如`timeout="30s"`, `timeout="5m"`
|
||||
|
||||
### 内容组织
|
||||
|
||||
推荐在executing标签内使用以下结构组织内容：
|
||||
|
||||
1. 以一级标题(`#`)定义执行任务的名称和目标
|
||||
2. 使用二级标题(`##`)标识主要执行阶段
|
||||
3. 使用有序列表表示执行步骤的精确顺序
|
||||
4. 使用代码块表示具体的命令或代码片段
|
||||
5. 使用表格记录输入参数和输出结果
|
||||
6. 使用引用块表示状态检查点和异常处理逻辑
|
||||
|
||||
### 可视化表达
|
||||
|
||||
不同类型的执行流程适合使用不同的Mermaid图表类型：
|
||||
|
||||
- **流程图(flowchart)**: 适合表示执行步骤和条件分支
|
||||
```mermaid
|
||||
flowchart TD
|
||||
A[开始] --> B{条件判断}
|
||||
B -->|条件成立| C[执行步骤1]
|
||||
B -->|条件不成立| D[执行步骤2]
|
||||
C --> E[下一步]
|
||||
D --> E
|
||||
E --> F[结束]
|
||||
```
|
||||
|
||||
- **时序图(sequenceDiagram)**: 适合表示组件间的交互过程
|
||||
```mermaid
|
||||
sequenceDiagram
|
||||
参与者A->>参与者B: 请求数据
|
||||
参与者B->>参与者C: 转发请求
|
||||
参与者C-->>参与者B: 返回数据
|
||||
参与者B-->>参与者A: 处理后返回
|
||||
```
|
||||
|
||||
- **状态图(stateDiagram)**: 适合表示状态转换和执行阶段
|
||||
```mermaid
|
||||
stateDiagram-v2
|
||||
[*] --> 准备
|
||||
准备 --> 执行中: 开始执行
|
||||
执行中 --> 完成: 成功
|
||||
执行中 --> 失败: 出错
|
||||
失败 --> 重试: 可恢复
|
||||
重试 --> 执行中
|
||||
失败 --> [*]: 不可恢复
|
||||
完成 --> [*]
|
||||
```
|
||||
|
||||
## 📋 使用示例
|
||||
|
||||
<executing mode="sequential" context="system">
|
||||
|
||||
# 文件批量处理流程
|
||||
|
||||
## 初始化阶段
|
||||
1. 检查工作目录权限
|
||||
2. 验证输入文件格式
|
||||
3. 准备输出目录
|
||||
|
||||
## 处理阶段
|
||||
```bash
|
||||
for file in $(ls *.txt); do
|
||||
echo "处理文件: $file"
|
||||
process_file "$file" >> log.txt
|
||||
done
|
||||
```
|
||||
|
||||
## 验证阶段
|
||||
| 检查项 | 预期结果 | 异常处理 |
|
||||
|-------|---------|---------|
|
||||
| 输出文件数量 | 等于输入文件数量 | 记录差异并重试 |
|
||||
| 处理日志 | 无错误记录 | 分析错误类型并修复 |
|
||||
|
||||
## 完成阶段
|
||||
> 状态检查点：所有文件已处理并验证通过
|
||||
> 执行清理临时文件并生成处理报告
|
||||
</executing>
|
||||
75
protocol/application/experience.protocol.md
Normal file
75
protocol/application/experience.protocol.md
Normal file
@ -0,0 +1,75 @@
|
||||
# experience 应用协议
|
||||
|
||||
> **TL;DR:** experience标签用于定义AI系统中经验知识的结构和语义，采用简单直观的HTML风格属性标记，专注于"什么是经验"，是实现系统自我优化和经验积累的核心表达机制。
|
||||
|
||||
## 🔍 基本信息
|
||||
|
||||
**标签名:** `<experience>`
|
||||
|
||||
### 目的与功能
|
||||
|
||||
experience标签在提示工程中提供了经验知识的标准定义方式，主要功能包括：
|
||||
- 定义经验信息的名称和分类
|
||||
- 提供简洁明了的经验描述
|
||||
- 支持基本的元数据标注
|
||||
- 为系统提供可复用的问题解决知识
|
||||
|
||||
## 📝 语法定义
|
||||
|
||||
```ebnf
|
||||
(* EBNF形式化定义 *)
|
||||
experience_element ::= '<experience' attributes? '>' content '</experience>'
|
||||
attributes ::= (' ' attribute)+ | ''
|
||||
attribute ::= name '="' value '"'
|
||||
name ::= [a-zA-Z][a-zA-Z0-9_-]*
|
||||
value ::= [^"]*
|
||||
content ::= text
|
||||
text ::= (* 任何文本内容，用于简要描述经验 *)
|
||||
```
|
||||
|
||||
## 🧩 语义说明
|
||||
|
||||
experience标签用于在提示词中定义经验知识。采用简洁的HTML风格属性标记方式，通过id指定唯一标识符，通过class指定经验的分类维度，标签内容直接描述该经验的含义。它作为系统知识积累的具体实现，为AI系统提供了清晰简洁的经验定义能力。
|
||||
|
||||
## 💡 最佳实践
|
||||
|
||||
### 核心属性
|
||||
|
||||
experience标签主要使用以下属性：
|
||||
|
||||
- **id**: 定义经验的唯一标识符，如`id="solution_pattern"`，`id="error_response"`
|
||||
- **class**: 定义经验的分类/维度，如`class="problem_solving"`，`class="system"`，`class="user"`
|
||||
|
||||
### 内容组织
|
||||
|
||||
experience标签内容应简洁明了，直接描述该经验的含义和用途，无需复杂的结构和格式。
|
||||
|
||||
### 维度分类指南
|
||||
|
||||
使用class属性定义experience维度时，建议遵循以下标准分类：
|
||||
|
||||
- **problem_solving**: 问题解决相关经验，如常见问题的解决方案和策略
|
||||
- **system**: 系统相关经验，如系统行为模式、限制和最佳实践
|
||||
- **user**: 用户相关经验，如用户交互模式和偏好
|
||||
- **domain**: 领域相关经验，如特定专业领域的知识和最佳实践
|
||||
- **optimization**: 优化相关经验，如性能提升和效率改进的方法
|
||||
|
||||
## 📋 使用示例
|
||||
|
||||
```html
|
||||
<!-- 问题解决经验 -->
|
||||
<experience id="error_handling_strategy" class="problem_solving">处理错误的最佳策略</experience>
|
||||
|
||||
<!-- 系统经验 -->
|
||||
<experience id="resource_limitation" class="system">系统资源限制与应对策略</experience>
|
||||
|
||||
<!-- 用户经验 -->
|
||||
<experience id="user_interaction_pattern" class="user">用户交互偏好与行为模式</experience>
|
||||
|
||||
<!-- 领域经验 -->
|
||||
<experience id="code_optimization_approach" class="domain">代码优化方法论</experience>
|
||||
|
||||
<!-- 优化经验 -->
|
||||
<experience id="performance_tuning" class="optimization">系统性能调优技巧</experience>
|
||||
```
|
||||
|
||||
72
protocol/application/memory.protocol.md
Normal file
72
protocol/application/memory.protocol.md
Normal file
@ -0,0 +1,72 @@
|
||||
# memory 应用协议
|
||||
|
||||
> **TL;DR:** memory标签用于定义AI系统的记忆持久化能力，支持跨会话知识存储和检索，采用简单直观的方式表达记忆内容。
|
||||
|
||||
## 🔍 基本信息
|
||||
|
||||
**标签名:** `<memory>`
|
||||
|
||||
### 目的与功能
|
||||
|
||||
memory标签定义了AI系统记忆的内容与标识，主要功能包括：
|
||||
- 提供简洁的记忆内容定义方式
|
||||
- 通过唯一标识符区分不同记忆
|
||||
- 实现跨会话的信息传递能力
|
||||
- 支持记忆内容的简明描述
|
||||
|
||||
## 📝 语法定义
|
||||
|
||||
```ebnf
|
||||
(* EBNF形式化定义 *)
|
||||
memory_element ::= '<memory' attributes? '>' content '</memory>'
|
||||
attributes ::= (' ' attribute)+ | ''
|
||||
attribute ::= name '="' value '"'
|
||||
name ::= [a-zA-Z][a-zA-Z0-9_-]*
|
||||
value ::= [^"]*
|
||||
content ::= text
|
||||
text ::= (* 任何文本内容，用于描述记忆 *)
|
||||
```
|
||||
|
||||
## 🧩 语义说明
|
||||
|
||||
memory标签用于在提示词中定义需要持久化的记忆内容。通过id属性提供唯一标识，标签内容直接描述该记忆的含义。它使系统能够保存和利用过去的交互经验和知识，从而增强系统在长期交互中的连续性和一致性。
|
||||
|
||||
## 💡 最佳实践
|
||||
|
||||
### 核心属性
|
||||
|
||||
memory标签主要使用以下属性：
|
||||
|
||||
- **id**: 记忆的唯一标识符，如`id="context"`, `id="history"`, `id="preferences"`
|
||||
|
||||
### 可选属性
|
||||
|
||||
在特定场景下，也可以使用以下可选属性：
|
||||
|
||||
- **type**: 记忆类型，如`type="session"`, `type="long-term"`, `type="episodic"`
|
||||
- **priority**: 记忆优先级，如`priority="high"`, `priority="normal"`, `priority="low"`
|
||||
|
||||
### 内容组织
|
||||
|
||||
memory标签内容应简洁明了，直接描述该记忆的含义和用途，无需复杂的结构和格式。
|
||||
|
||||
## 📋 使用示例
|
||||
|
||||
```html
|
||||
<!-- 上下文感知记忆 -->
|
||||
<memory id="context">上下文感知记忆</memory>
|
||||
|
||||
<!-- 对话历史记忆 -->
|
||||
<memory id="history">用户对话历史记录</memory>
|
||||
|
||||
<!-- 用户偏好记忆 -->
|
||||
<memory id="preferences">用户个性化偏好设置</memory>
|
||||
|
||||
<!-- 项目信息记忆 -->
|
||||
<memory id="project">项目相关信息和配置</memory>
|
||||
|
||||
<!-- 决策历史记忆 -->
|
||||
<memory id="decisions">重要决策历史记录</memory>
|
||||
```
|
||||
|
||||
> **注意**: 实际的记忆存储和检索逻辑应由系统底层实现，memory标签专注于定义记忆的标识和基本含义。
|
||||
93
protocol/application/protocol-application-template.md
Normal file
93
protocol/application/protocol-application-template.md
Normal file
@ -0,0 +1,93 @@
|
||||
# [标签名] 应用协议
|
||||
|
||||
> **TL;DR:** [一句话描述此标签的核心用途与价值]
|
||||
|
||||
## 🔍 基本信息
|
||||
|
||||
**标签名:** `<标签名>`
|
||||
|
||||
|
||||
### 目的与功能
|
||||
|
||||
[详细描述此标签的目的、解决的问题和提供的功能]
|
||||
|
||||
## 🧰 设计原则
|
||||
|
||||
定义应用协议时，应当遵循以下核心设计原则：
|
||||
|
||||
1. **约定大于配置**：减少明确的配置需求，优先使用合理的默认约定
|
||||
2. **职责单一**：每个协议应专注于单一功能或目的，避免过度复杂
|
||||
3. **最小可行产品(MVP)**：从最核心功能开始，确保基础用例能够正常工作
|
||||
4. **奥卡姆剃刀原则**：在同等条件下，应选择最简单的设计方案
|
||||
5. **一致性**：保持与其他协议的设计风格和使用模式一致
|
||||
|
||||
这些原则有助于确保协议设计的简洁性、可用性和可维护性。
|
||||
|
||||
## 📝 语法定义
|
||||
|
||||
```ebnf
|
||||
(* EBNF形式化定义 *)
|
||||
tag_element ::= '<标签名' attributes? '>' content '</标签名>'
|
||||
attributes ::= (' ' attribute)+ | ''
|
||||
attribute ::= name '="' value '"'
|
||||
name ::= [a-zA-Z][a-zA-Z0-9_-]*
|
||||
value ::= [^"]*
|
||||
content ::= markdown_content
|
||||
markdown_content ::= (* 任何有效的Markdown文本，可包含特定语法元素 *)
|
||||
```
|
||||
|
||||
## 🧩 语义说明
|
||||
|
||||
此标签用于[描述标签的主要用途和语义]。在提示词中，它表示[...]并协助AI[...]。
|
||||
|
||||
## 💡 最佳实践
|
||||
|
||||
以下是使用此标签的一些建议做法，这些并非强制要求，仅作为参考：
|
||||
|
||||
### 推荐属性
|
||||
|
||||
可以考虑使用以下属性来增强标签的语义：
|
||||
|
||||
- **属性1**: [属性说明和示例值]
|
||||
- **属性2**: [属性说明和示例值]
|
||||
- **属性3**: [属性说明和示例值]
|
||||
|
||||
### 内容组织
|
||||
|
||||
推荐在标签内使用以下结构组织内容：
|
||||
|
||||
1. [内容组织建议1]
|
||||
2. [内容组织建议2]
|
||||
3. [内容组织建议3]
|
||||
|
||||
### 可视化表达（如适用）
|
||||
|
||||
[如适用，描述此标签内容的可视化表达方式，如图表类型、格式建议等]
|
||||
|
||||
### 扩展选项
|
||||
|
||||
根据MVP原则，标签应先实现核心功能。当核心功能稳定后，可考虑以下扩展方向：
|
||||
|
||||
1. **高级属性**：添加可选的高级配置属性，但确保基本功能不依赖这些属性
|
||||
2. **集成能力**：提供与其他标签或协议的集成接口
|
||||
3. **专业化变体**：为特定场景开发的专门版本或扩展
|
||||
4. **性能优化**：针对高频使用场景的性能改进
|
||||
|
||||
扩展时应保持向后兼容性，并避免增加不必要的复杂度。
|
||||
|
||||
## 📋 使用示例
|
||||
|
||||
<标签名 属性1="值1" 属性2="值2">
|
||||
# 示例内容标题
|
||||
|
||||
## 内容部分1
|
||||
示例内容描述
|
||||
|
||||
## 内容部分2
|
||||
- 要点1
|
||||
- 要点2
|
||||
|
||||
```
|
||||
代码或特殊格式示例（如适用）
|
||||
```
|
||||
</标签名>
|
||||
37
protocol/application/resource.protocol.md
Normal file
37
protocol/application/resource.protocol.md
Normal file
@ -0,0 +1,37 @@
|
||||
# resource 应用协议
|
||||
|
||||
> **TL;DR:** resource标签用于定义资源协议，提供统一的引用方式。
|
||||
|
||||
## 🔍 基本信息
|
||||
|
||||
**标签名:** `<resource>`
|
||||
**版本:** 1.0.0
|
||||
**类别:** 资源
|
||||
**状态:** 草稿
|
||||
**创建日期:** 2023-06-30
|
||||
|
||||
### 目的与功能
|
||||
|
||||
resource标签用于定义特定类型的资源协议，使开发者能够以标准化的方式描述如何引用和处理各种资源。通过这个标签，可以明确资源的引用语法、处理规则和使用方式，确保资源引用在不同环境中的一致性和可靠性。此标签是PromptX中资源引用协议（RP）在应用层面的具体实现方式。
|
||||
|
||||
## 📝 语法定义
|
||||
|
||||
```
|
||||
<resource protocol="协议名">内容</resource>
|
||||
```
|
||||
|
||||
## 📝 语义说明
|
||||
|
||||
resource标签定义资源协议，使其可以使用`@协议名://路径`形式在提示词中引用。标签内容应包含协议的基本描述和用法。
|
||||
|
||||
## 使用示例
|
||||
|
||||
<resource protocol="context">
|
||||
# Context 协议
|
||||
|
||||
## 语法
|
||||
@context://[scope]/[path]
|
||||
|
||||
## 说明
|
||||
用于引用和设置上下文环境。
|
||||
</resource>
|
||||
121
protocol/application/role.protocol.md
Normal file
121
protocol/application/role.protocol.md
Normal file
@ -0,0 +1,121 @@
|
||||
# role 应用协议
|
||||
|
||||
> **TL;DR:** role标签定义AI系统在响应过程中扮演的单一专业角色，提供明确的职责、专业知识和行为准则，是实现RRP(角色响应协议)的核心表达机制。
|
||||
|
||||
## 🔍 基本信息
|
||||
|
||||
**标签名:** `<role>`
|
||||
|
||||
### 目的与功能
|
||||
|
||||
role标签为AI系统提供清晰的角色定义框架，主要功能包括：
|
||||
- 定义AI需要扮演的专业角色特性和领域知识
|
||||
- 提供角色专有的行为准则和响应原则
|
||||
- 设置角色视角下的专业知识体系和术语
|
||||
- 明确角色的职责范围和响应边界
|
||||
|
||||
## 🧰 设计原则
|
||||
|
||||
定义role应用协议时，特别强调以下核心设计原则：
|
||||
|
||||
1. **职责单一**：每个role专注于定义单一专业角色，不包含角色切换机制
|
||||
2. **约定大于配置**：使用合理的默认角色结构，减少复杂配置
|
||||
3. **最小可行产品**：专注于角色的核心定义要素，确保基础使用场景
|
||||
4. **奥卡姆剃刀原则**：保持角色定义的简洁性，避免不必要的复杂属性
|
||||
5. **一致性**：与其他协议保持一致的设计风格
|
||||
|
||||
## 📝 语法定义
|
||||
|
||||
```ebnf
|
||||
(* EBNF形式化定义 *)
|
||||
role_element ::= '<role' attributes? '>' content '</role>'
|
||||
attributes ::= (' ' attribute)+ | ''
|
||||
attribute ::= name '="' value '"'
|
||||
name ::= [a-zA-Z][a-zA-Z0-9_-]*
|
||||
value ::= [^"]*
|
||||
content ::= markdown_content
|
||||
markdown_content ::= (* 任何有效的Markdown文本，描述角色特性 *)
|
||||
```
|
||||
|
||||
## 🧩 语义说明
|
||||
|
||||
role标签用于明确定义AI系统在特定场景中需要扮演的专业角色。它提供了角色的专业背景、知识领域、行为准则和预期输出格式等信息，使AI能够从特定专业角色的视角生成更加专业、一致和符合预期的响应。
|
||||
|
||||
## 💡 最佳实践
|
||||
|
||||
### 推荐属性
|
||||
|
||||
可以考虑使用以下属性来增强role标签的语义：
|
||||
|
||||
- **name**: 角色名称，如`name="软件架构师"`
|
||||
- **domain**: 专业领域，如`domain="系统设计"`
|
||||
- **expertise**: 专业水平，如`expertise="expert"`
|
||||
- **tone**: 沟通风格，如`tone="professional"`
|
||||
- **perspective**: 思考视角，如`perspective="systems-thinking"`
|
||||
|
||||
### 内容组织
|
||||
|
||||
推荐在标签内使用以下结构组织内容：
|
||||
|
||||
1. **职责范围**: 明确定义角色的职责边界
|
||||
2. **专业知识**: 列出角色所具备的专业知识体系
|
||||
3. **行为准则**: 描述角色的专业行为标准
|
||||
4. **术语表**: 角色常用的专业术语定义
|
||||
5. **输出格式**: 角色回应的标准格式要求
|
||||
|
||||
### 可视化表达
|
||||
|
||||
角色知识结构可使用mermaid图表表示：
|
||||
|
||||
```mermaid
|
||||
mindmap
|
||||
root((软件架构师))
|
||||
系统设计
|
||||
高可用性
|
||||
可扩展性
|
||||
性能优化
|
||||
技术选型
|
||||
框架评估
|
||||
技术栈兼容性
|
||||
架构模式
|
||||
微服务
|
||||
事件驱动
|
||||
领域驱动
|
||||
```
|
||||
|
||||
## 📋 使用示例
|
||||
|
||||
```xml
|
||||
<role name="软件架构师" domain="系统设计" expertise="expert" tone="professional">
|
||||
## 职责范围
|
||||
- 分析系统需求并转化为技术架构设计
|
||||
- 评估并选择适合项目的技术栈和架构模式
|
||||
- 设计系统组件结构和交互关系
|
||||
- 确定非功能性需求的技术实现方案
|
||||
|
||||
## 专业知识
|
||||
- 分布式系统架构设计原则
|
||||
- 微服务架构模式与实践
|
||||
- API设计与版本控制策略
|
||||
- 系统性能优化与可扩展性保障
|
||||
|
||||
## 行为准则
|
||||
- 始终从整体系统视角思考问题
|
||||
- 关注架构决策对可维护性和未来扩展的影响
|
||||
- 使用准确的技术术语和清晰的图示表达设计思路
|
||||
- 平衡技术理想与实际约束，提供务实可行的方案
|
||||
|
||||
## 术语表
|
||||
- **解耦**: 降低系统组件间的依赖程度
|
||||
- **服务边界**: 微服务架构中的职责划分边界
|
||||
- **技术债**: 设计或实现中的妥协导致的未来额外工作
|
||||
|
||||
## 输出格式
|
||||
架构设计文档应包含：
|
||||
1. 架构概述
|
||||
2. 组件设计
|
||||
3. 接口规范
|
||||
4. 部署模型
|
||||
5. 关键技术决策说明
|
||||
</role>
|
||||
```
|
||||
190
protocol/application/task.protocol.md
Normal file
190
protocol/application/task.protocol.md
Normal file
@ -0,0 +1,190 @@
|
||||
# task 应用协议
|
||||
|
||||
> **TL;DR:** task标签用于定义可重用的任务模板，支持任务的静态描述和动态执行，是实现任务模板化和标准化执行的核心机制。
|
||||
|
||||
## 🔍 基本信息
|
||||
|
||||
**标签名:** `<task>`
|
||||
|
||||
### 目的与功能
|
||||
|
||||
task标签提供了任务模板化的框架，主要功能包括：
|
||||
- 定义标准化的任务结构和执行流程
|
||||
- 支持任务的参数化配置和动态绑定
|
||||
- 提供任务执行的验证和约束条件
|
||||
- 实现任务模板的复用和组合
|
||||
- 容器化封装任务执行环境和上下文
|
||||
|
||||
## 🧰 设计原则
|
||||
|
||||
定义task应用协议时，特别强调以下核心设计原则：
|
||||
|
||||
1. **职责单一**：每个task专注于定义单一完整的任务流程
|
||||
2. **约定大于配置**：使用合理的默认任务结构，减少不必要的配置
|
||||
3. **最小可行产品**：专注于任务定义的核心要素，确保基础执行场景
|
||||
4. **奥卡姆剃刀原则**：保持任务定义的简洁性，避免过度复杂的结构
|
||||
5. **一致性**：与其他协议保持一致的设计风格
|
||||
|
||||
## 📝 语法定义
|
||||
|
||||
```ebnf
|
||||
(* EBNF形式化定义 *)
|
||||
task_element ::= '<task' attributes? '>' content '</task>'
|
||||
attributes ::= (' ' attribute)+ | ''
|
||||
attribute ::= name '="' value '"'
|
||||
name ::= [a-zA-Z][a-zA-Z0-9_-]*
|
||||
value ::= [^"]*
|
||||
content ::= markdown_content
|
||||
markdown_content ::= (* 任何有效的Markdown文本，描述任务结构 *)
|
||||
```
|
||||
|
||||
## 🧩 语义说明
|
||||
|
||||
task标签用于定义可重用的任务模板。它提供了任务的结构化描述，包括目标定义、执行环境和成功标准，使任务可以被标准化执行和重复使用。通过与role标签的配合，可以实现特定角色执行特定任务的精确控制。
|
||||
|
||||
## 💡 最佳实践
|
||||
|
||||
### 核心设计原则
|
||||
|
||||
在设计task标签时，建议遵循以下核心原则：
|
||||
|
||||
1. **职责单一**：每个task专注于定义单一完整的任务流程
|
||||
2. **约定大于配置**：使用合理的默认任务结构，减少不必要的配置
|
||||
3. **最小可行产品**：专注于任务定义的核心要素，确保基础执行场景
|
||||
4. **奥卡姆剃刀原则**：保持任务定义的简洁性，避免过度复杂的结构
|
||||
5. **一致性**：与其他协议保持一致的设计风格
|
||||
|
||||
### 推荐属性
|
||||
|
||||
可以考虑使用以下属性来增强task标签的语义：
|
||||
|
||||
- **id**: 任务唯一标识，如`id="code-review-task"`
|
||||
- **type**: 任务类型，如`type="analysis"`
|
||||
- **priority**: 任务优先级，如`priority="high"`
|
||||
- **timeout**: 执行超时时间，如`timeout="30m"`
|
||||
- **requires**: 依赖的角色或资源，如`requires="architect"`
|
||||
|
||||
### OES框架内容组织
|
||||
|
||||
强烈推荐使用OES框架组织任务内容，这种结构借鉴了容器化思想，使任务更加清晰和可执行：
|
||||
|
||||
1. **目标(Objective)**
|
||||
- 明确定义任务的具体预期结果
|
||||
- 设定任务边界和约束
|
||||
- 说明任务的价值和意义
|
||||
|
||||
2. **环境(Environment)**
|
||||
- **背景信息**：任务相关的上下文和背景
|
||||
- **资源需求**：执行任务所需的数据、工具和参考资料
|
||||
- **约束条件**：技术、业务和资源限制
|
||||
- **执行规范**：风格指南、质量标准和工作流程
|
||||
- **上下文关联**：与其他任务的关系和依赖
|
||||
|
||||
3. **成功标准(Success Criteria)**
|
||||
- **基础达标**：最低要求和基本功能
|
||||
- **预期品质**：符合项目整体质量标准的指标
|
||||
- **验证方法**：如何验证任务是否成功完成
|
||||
- **结果格式**：交付物的具体格式和内容要求
|
||||
|
||||
### 任务网络构建
|
||||
|
||||
对于复杂项目，推荐构建任务网络，通过以下方式连接多个任务：
|
||||
|
||||
1. **垂直连接**：上级任务的成功标准成为下级任务的目标
|
||||
2. **水平连接**：前序任务的产物成为后续任务的环境组成部分
|
||||
|
||||
### 可视化表达
|
||||
|
||||
任务执行流程可使用mermaid图表表示：
|
||||
|
||||
```mermaid
|
||||
graph TD
|
||||
A[输入验证] --> B{参数检查}
|
||||
B -->|通过| C[执行准备]
|
||||
B -->|失败| H[错误处理]
|
||||
C --> D[主要步骤]
|
||||
D --> E[结果验证]
|
||||
E -->|成功| F[输出结果]
|
||||
E -->|失败| G[回滚处理]
|
||||
H --> I[任务终止]
|
||||
G --> I
|
||||
```
|
||||
|
||||
## 📋 使用示例
|
||||
|
||||
```xml
|
||||
<task id="code-review" type="analysis" requires="senior-developer" timeout="30m">
|
||||
## 目标(Objective)
|
||||
对提交的代码变更进行全面的代码审查，确保代码质量和一致性，并提供具体改进建议。
|
||||
目标范围包括代码风格、性能、安全性和业务逻辑正确性评估。
|
||||
|
||||
## 环境(Environment)
|
||||
### 背景信息
|
||||
- 项目使用Git流程管理代码
|
||||
- 团队遵循Google代码风格指南
|
||||
- 代码审查是合并请求流程的必要环节
|
||||
|
||||
### 资源需求
|
||||
- **diff_files**: 需要审查的文件列表
|
||||
- **base_branch**: 基准分支名称
|
||||
- **review_focus**: 重点关注的方面
|
||||
|
||||
### 约束条件
|
||||
- 审查必须在30分钟内完成
|
||||
- 必须使用团队标准的代码审查清单
|
||||
- 严重安全问题需立即上报
|
||||
|
||||
### 执行规范
|
||||
1. **预检查**
|
||||
- 验证文件可访问性
|
||||
- 检查diff格式正确性
|
||||
- 确认审查权限
|
||||
|
||||
2. **静态分析**
|
||||
- 代码风格检查
|
||||
- 潜在问题扫描
|
||||
- 复杂度评估
|
||||
|
||||
3. **逻辑审查**
|
||||
- 业务逻辑正确性
|
||||
- 异常处理完整性
|
||||
- 性能影响评估
|
||||
|
||||
4. **安全审查**
|
||||
- 安全漏洞检查
|
||||
- 敏感信息扫描
|
||||
- 权限控制审查
|
||||
|
||||
## 成功标准(Success Criteria)
|
||||
### 基础达标
|
||||
- 所有必要的检查项已完成
|
||||
- 没有严重或阻塞性问题
|
||||
- 代码符合团队编码标准
|
||||
|
||||
### 预期品质
|
||||
- 提供至少3个有价值的改进建议
|
||||
- 验证测试覆盖率达到团队标准
|
||||
- 确认新代码没有引入性能退化
|
||||
|
||||
### 结果格式
|
||||
```json
|
||||
{
|
||||
"status": "approved|rejected|needs_revision",
|
||||
"summary": "审查总结",
|
||||
"issues": [
|
||||
{
|
||||
"type": "security|performance|style",
|
||||
"severity": "high|medium|low",
|
||||
"description": "问题描述",
|
||||
"suggestion": "改进建议"
|
||||
}
|
||||
],
|
||||
"metrics": {
|
||||
"files_reviewed": 10,
|
||||
"issues_found": 5,
|
||||
"review_time": "25m"
|
||||
}
|
||||
}
|
||||
```
|
||||
</task>
|
||||
```
|
||||
147
protocol/application/thinking.protocol.md
Normal file
147
protocol/application/thinking.protocol.md
Normal file
@ -0,0 +1,147 @@
|
||||
# thinking 应用协议
|
||||
|
||||
> **TL;DR:** thinking标签用于定义结构化的思考框架，帮助AI系统进行系统性分析和推理，支持Markdown和Mermaid图表表达思维过程。
|
||||
|
||||
## 🔍 基本信息
|
||||
|
||||
**标签名:** `<thinking>`
|
||||
**版本:** 1.0.0
|
||||
**类别:** 思考
|
||||
**状态:** 草稿
|
||||
**创建日期:** 2023-06-20
|
||||
|
||||
### 目的与功能
|
||||
|
||||
thinking标签定义了AI系统进行思考分析的框架和流程，它的主要功能是：
|
||||
- 提供结构化的思维分析模式
|
||||
- 组织和展示概念关系与逻辑推理
|
||||
- 支持可视化思维导图和决策树
|
||||
- 帮助AI系统进行系统性、全面性的问题分析
|
||||
|
||||
## 📝 语法定义
|
||||
|
||||
```ebnf
|
||||
(* EBNF形式化定义 *)
|
||||
thinking_element ::= '<thinking' attributes? '>' content '</thinking>'
|
||||
attributes ::= (' ' attribute)+ | ''
|
||||
attribute ::= name '="' value '"'
|
||||
name ::= [a-zA-Z][a-zA-Z0-9_-]*
|
||||
value ::= [^"]*
|
||||
content ::= markdown_content
|
||||
markdown_content ::= (* 任何有效的Markdown文本，包括Mermaid图表 *)
|
||||
```
|
||||
|
||||
## 🧩 语义说明
|
||||
|
||||
thinking标签表示一个完整的思考过程或思维框架。标签内容采用Markdown格式，可以包含文本段落、列表、标题以及Mermaid图表等元素，用于表达结构化的思考方式。thinking标签特别适合表达概念关系、逻辑推理和系统性思考，为AI提供思考分析的参考框架。
|
||||
|
||||
## 💡 最佳实践
|
||||
|
||||
以下是使用thinking标签的一些建议做法，这些并非强制要求，仅作为参考：
|
||||
|
||||
### 推荐属性
|
||||
|
||||
可以考虑使用以下属性来增强thinking标签的语义：
|
||||
|
||||
- **type**: 指定思考类型，如`type="analysis"`, `type="design"`, `type="evaluation"`, `type="brainstorm"`, `type="problem-solving"`
|
||||
- **domain**: 指定思考领域，如`domain="software"`, `domain="business"`, `domain="science"`
|
||||
- **method**: 指定思维方法，如`method="systematic"`, `method="lateral"`, `method="critical"`
|
||||
|
||||
### 内容组织
|
||||
|
||||
推荐在thinking标签内使用以下结构组织内容：
|
||||
|
||||
1. 以一级标题(`#`)定义核心问题或思考主题
|
||||
2. 使用二级标题(`##`)划分思考的主要部分（如问题分析、方案设计、评估等）
|
||||
3. 使用列表、表格等方式组织关键点和因素
|
||||
4. 使用Mermaid图表可视化思维过程（见下方推荐）
|
||||
5. 在结尾提供结论或决策建议
|
||||
|
||||
### Mermaid图表选择
|
||||
|
||||
不同类型的思考场景适合使用不同的Mermaid图表类型：
|
||||
|
||||
- **思维导图(mindmap)**: 适合概念分解、头脑风暴和关联分析
|
||||
```mermaid
|
||||
mindmap
|
||||
root((核心问题))
|
||||
因素A
|
||||
子因素A1
|
||||
子因素A2
|
||||
因素B
|
||||
子因素B1
|
||||
因素C
|
||||
```
|
||||
|
||||
- **流程图(flowchart)**: 适合步骤分析、决策流程和算法思路
|
||||
```mermaid
|
||||
flowchart TD
|
||||
A[起点] --> B{判断条件}
|
||||
B -->|条件1| C[路径1]
|
||||
B -->|条件2| D[路径2]
|
||||
C --> E[结果1]
|
||||
D --> F[结果2]
|
||||
```
|
||||
|
||||
- **类图(classDiagram)**: 适合概念关系和抽象模型设计
|
||||
```mermaid
|
||||
classDiagram
|
||||
概念A <|-- 子概念B
|
||||
概念A <|-- 子概念C
|
||||
概念A : 属性1
|
||||
概念A : 属性2
|
||||
```
|
||||
|
||||
- **甘特图(gantt)**: 适合项目规划和时间线分析
|
||||
```mermaid
|
||||
gantt
|
||||
title 项目计划
|
||||
section 阶段1
|
||||
任务1 :a1, 2023-01-01, 30d
|
||||
任务2 :after a1, 20d
|
||||
section 阶段2
|
||||
任务3 :2023-02-15, 28d
|
||||
```
|
||||
|
||||
- **状态图(stateDiagram)**: 适合状态转换和系统行为分析
|
||||
```mermaid
|
||||
stateDiagram-v2
|
||||
[*] --> 状态A
|
||||
状态A --> 状态B: 事件1
|
||||
状态B --> 状态C: 事件2
|
||||
状态C --> [*]
|
||||
```
|
||||
|
||||
## 📋 使用示例
|
||||
|
||||
<thinking>
|
||||
|
||||
# 问题分析框架
|
||||
|
||||
## 核心问题
|
||||
如何优化系统性能并保持代码可维护性
|
||||
|
||||
## 因素分析
|
||||
影响因素包括：
|
||||
- 算法效率
|
||||
- 数据结构选择
|
||||
- 并发处理
|
||||
- 代码组织
|
||||
|
||||
```mermaid
|
||||
mindmap
|
||||
root((性能优化))
|
||||
算法层面
|
||||
时间复杂度
|
||||
空间复杂度
|
||||
数据结构
|
||||
查询效率
|
||||
内存占用
|
||||
系统架构
|
||||
并发模型
|
||||
资源管理
|
||||
```
|
||||
|
||||
## 结论
|
||||
应优先考虑数据结构优化和并发处理模型调整
|
||||
</thinking>
|
||||
Reference in New Issue
Block a user