iriver/PromptX
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

更新资源管理器和命令逻辑：新增角色创建和生成相关功能，优化资源加载流程，支持用户自定义资源的发现与合并，同时增强错误处理和描述提取逻辑，提升系统的灵活性和用户体验。

Browse Source
This commit is contained in:
sean
2025-06-10 23:58:29 +08:00
parent 95b5a4d570
commit 192eb2a0df
19 changed files with 3596 additions and 45 deletions
Download Patch File Download Diff File Expand all files Collapse all files

148
prompt/core/execution/execution-authoring.execution.md Normal file
View File

@ -0,0 +1,148 @@
<execution>
<constraint>
## 客观技术限制
- **DPML语法约束**：必须遵循EBNF定义的execution语法结构
- **XML格式要求**：标签必须正确闭合，属性值必须用双引号包围
- **Markdown兼容性**：内容部分必须是有效的Markdown格式
- **文件编码**：必须使用UTF-8编码
- **优先级固化**：五个子标签的优先级关系不可改变
</constraint>
<rule>
## 强制性编写规则
- **纯XML结构**：execution文件必须从`<execution>`标签开始，不得包含任何XML结构外的内容（如Markdown标题、注释等）
- **根标签强制**：文件必须使用`<execution>`作为根标签包装全部内容
- **子标签命名**：只能使用规范定义的五个子标签：constraint, rule, guideline, process, criteria
- **优先级顺序**：子标签必须按constraint → rule → guideline → process → criteria顺序排列
- **内容完整性**：每个子标签都必须包含实质性内容，不得为空
- **语义一致性**：子标签内容必须与其语义定义保持一致
- **文件纯净性**：除了`<execution>`标签结构外，不得包含任何其他内容
</rule>
<guideline>
## 编写指导原则
- **语义明确性**：每个子标签的内容应清晰表达其特定语义
- **内容层次化**：使用Markdown的标题、列表等结构组织内容
- **实用性导向**：内容应具有实际操作指导价值
- **简洁性原则**：避免冗长表述，保持核心要点突出
- **一致性维护**：在整个文件中保持术语和表达方式的一致性
</guideline>
<process>
## 编写执行流程
### Phase 1: 分析需求和上下文
1. **明确execution目的**：确定这个execution要解决什么问题
2. **识别客观限制**：分析技术、环境、资源等客观约束条件
3. **定义强制要求**：确定必须遵守的规则和底线要求
4. **收集最佳实践**：整理相关领域的指导原则和建议
### Phase 2: 内容规划和结构设计
1. **约束条件梳理**：
- 列出所有客观存在的限制条件
- 按重要性和影响程度排序
- 确保约束条件的客观性和不可变性
2. **规则定义设计**：
- 识别必须严格遵守的行为准则
- 明确违反规则的后果和风险
- 确保规则与约束条件不冲突
3. **指导原则制定**：
- 提供灵活性建议和最佳实践
- 允许根据具体情况调整
- 确保不违反已定义的规则和约束
4. **流程步骤设计**：
- 在约束和规则框架内设计执行路径
- 包含正常流程和异常处理
- 确保步骤的可操作性和逻辑性
5. **评价标准确立**：
- 定义成功完成的判断依据
- 考虑所有优先级更高元素的要求
- 提供可量化的评估方法
### Phase 3: DPML结构实现
**关键要求：文件必须从`<execution>`标签直接开始**
```xml
<execution>
<constraint>
[客观限制条件内容]
</constraint>
<rule>
[强制性规则内容]
</rule>
<guideline>
[指导原则内容]
</guideline>
<process>
[具体执行步骤]
</process>
<criteria>
[评价标准内容]
</criteria>
</execution>
```
**错误示例（禁止）：**
```markdown
# 标题
这是描述内容...
<execution>
...
</execution>
```
### Phase 4: 质量检查和优化
1. **语法验证**：确保DPML语法正确性
2. **语义一致性检查**：验证各部分逻辑关系
3. **优先级关系验证**：确认无冲突和矛盾
4. **实用性测试**：验证内容的可操作性
5. **完整性审核**：确保覆盖所有必要方面
6. **纯净性检查**：确认文件从`<execution>`标签开始，无多余内容
</process>
<criteria>
## 质量评价标准
### 格式合规性
- ✅ 文件从`<execution>`标签直接开始，无额外内容
- ✅ 使用正确的DPML execution标签结构
- ✅ 五个子标签按规定顺序排列
- ✅ XML语法正确，标签正确闭合
- ✅ Markdown格式规范，层次清晰
### 内容完整性
- ✅ 每个子标签都包含实质性内容
- ✅ 约束条件体现客观性和不可变性
- ✅ 规则体现强制性和明确性
- ✅ 指导原则体现建议性和灵活性
- ✅ 流程步骤具有可操作性和逻辑性
- ✅ 评价标准具有可验证性
### 语义一致性
- ✅ 各子标签内容与其语义定义匹配
- ✅ 优先级关系得到正确体现
- ✅ 不存在逻辑冲突和矛盾
- ✅ 术语使用保持一致性
### 实用价值
- ✅ 内容具有实际指导意义
- ✅ 步骤和标准可以实际执行
- ✅ 能够解决实际问题
- ✅ 适用于目标场景和用户
### 文件纯净性
- ✅ 文件结构完全符合DPML execution规范
- ✅ 无任何XML结构外的多余内容
- ✅ 体现execution文件的标准格式
</criteria>
</execution>

223
prompt/core/execution/resource-authoring.execution.md Normal file
View File

@ -0,0 +1,223 @@
<execution>
<constraint>
## 客观技术限制
- **DPML语法约束**：必须遵循EBNF定义的resource语法结构
- **XML格式要求**：标签必须正确闭合，属性值必须用双引号包围
- **protocol属性强制**：resource标签必须包含protocol属性指定协议名
- **文件编码**：必须使用UTF-8编码
- **代码实现约束**：必须与ResourceManager、ResourceProtocol基类兼容
- **注册表集成**：必须与resource.registry.json统一注册表集成
- **查询参数限制**：查询参数必须符合URL标准格式
</constraint>
<rule>
## 强制性编写规则
- **纯XML结构**：resource文件必须从`<resource>`标签开始，不得包含任何XML结构外的内容
- **根标签强制**：文件必须使用`<resource protocol="协议名">`作为根标签
- **三组件完整**：必须包含location、params、registry三个子标签
- **组件顺序固定**：子标签必须按location → params → registry顺序排列
- **protocol属性必需**：根标签必须包含protocol属性且值唯一
- **文件纯净性**：除了`<resource>`标签结构外，不得包含任何其他内容
- **EBNF规范性**：location标签内容必须使用EBNF语法定义路径格式
</rule>
<guideline>
## 编写指导原则
- **协议名称清晰**：protocol属性值应简洁明了，符合kebab-case命名规范
- **路径格式标准化**：使用EBNF语法精确定义资源路径结构
- **参数文档完整**：详细说明所有支持的查询参数及其类型和用途
- **注册表合理性**：注册表映射应体现抽象性和实用性的平衡
- **兼容性考虑**：确保与PromptX资源管理系统的无缝集成
- **示例丰富性**：提供足够的使用示例帮助理解协议用法
</guideline>
<process>
## 编写执行流程
### Phase 1: 协议概念设计
1. **确定协议用途**：明确这个资源协议要解决什么资源访问问题
2. **分析资源特征**：识别目标资源的组织方式、访问模式和参数需求
3. **设计协议名称**：选择简洁清晰的协议标识符
4. **评估系统集成**：确认与PromptX现有协议的兼容性和差异性
### Phase 2: 路径格式设计（location组件）
1. **路径结构分析**：
- 确定资源的层次结构和定位方式
- 分析是否需要支持参数化路径
- 设计路径的语义表达
2. **EBNF语法定义**：
```ebnf
location ::= protocol_name '://' path_structure
path_structure ::= segment {'/' segment}
segment ::= literal | parameter
parameter ::= '{' parameter_name '}'
```
3. **路径规范示例**：
- 简单路径：`protocol://resource_id`
- 参数化路径：`protocol://{category}/{id}`
- 复杂路径：`protocol://{domain}/{namespace}/{resource}`
### Phase 3: 查询参数设计（params组件）
1. **参数分类规划**：
- **格式控制参数**：如format、encoding等
- **行为控制参数**：如cache、timeout等
- **过滤参数**：如line、type等
- **特定功能参数**：协议专有的参数
2. **参数文档格式**：
```markdown
| 参数名 | 类型 | 描述 | 默认值 | 示例 |
|-------|------|------|--------|------|
| format | string | 输出格式 | text | json, xml |
| cache | boolean | 是否缓存 | true | true, false |
```
3. **参数验证考虑**：
- 参数类型验证
- 参数值范围限制
- 参数组合逻辑
### Phase 4: 注册表设计（registry组件）
1. **注册表策略选择**：
- **有注册表协议**：需要ID到路径的映射（如thought, execution）
- **无注册表协议**：直接使用路径（如file, http）
2. **映射关系设计**（适用于有注册表协议）：
```markdown
| 资源ID | 实际路径 | 描述 |
|--------|----------|------|
| resource-id | @package://path/to/file.md | 资源描述 |
```
3. **路径引用规范**：
- 支持@package://前缀引用包资源
- 支持@project://前缀引用项目资源
- 支持@file://前缀引用文件系统资源
- 支持嵌套协议引用
### Phase 5: DPML结构实现
**关键要求：文件必须从`<resource>`标签直接开始**
**有注册表协议示例：**
```xml
<resource protocol="custom-protocol">
<location>
```ebnf
location ::= custom-protocol://{resource_id}
resource_id ::= [a-zA-Z][a-zA-Z0-9_-]*
```
</location>
<params>
| 参数名 | 类型 | 描述 | 默认值 |
|-------|------|------|--------|
| format | string | 输出格式（text\|json\|xml） | text |
| cache | boolean | 是否缓存结果 | true |
| encoding | string | 文件编码 | utf8 |
</params>
<registry>
| 资源ID | 文件路径 |
|--------|----------|
| example-resource | @package://path/to/example.md |
| another-resource | @project://config/another.md |
</registry>
</resource>
```
**无注册表协议示例：**
```xml
<resource protocol="direct-access">
<location>
```ebnf
location ::= direct-access://{path}
path ::= absolute_path | relative_path
absolute_path ::= '/' path_segment {'/' path_segment}
relative_path ::= path_segment {'/' path_segment}
path_segment ::= [^/]+
```
</location>
<params>
| 参数名 | 类型 | 描述 | 默认值 |
|-------|------|------|--------|
| encoding | string | 文件编码 | utf8 |
| line | string | 行范围（如"1-10"） | - |
</params>
<registry>
<!-- 此协议不使用注册表，直接通过路径访问资源 -->
</registry>
</resource>
```
### Phase 6: 系统集成验证
1. **注册表集成**：确保协议定义与resource.registry.json格式兼容
2. **代码实现检查**：验证是否需要创建对应的Protocol类文件
3. **ResourceManager集成**：确认协议能被ResourceManager正确加载
4. **加载语义支持**：验证@、@!、@?前缀的正确处理
5. **查询参数解析**：确保参数能被正确解析和应用
### Phase 7: 质量检查和测试
1. **语法验证**：确保DPML resource语法正确性
2. **EBNF验证**：验证location部分的EBNF语法正确性
3. **参数完整性**：确认所有参数都有清晰的类型和描述
4. **注册表一致性**：验证注册表映射的逻辑正确性
5. **纯净性检查**：确认文件从`<resource>`标签开始，无多余内容
</process>
<criteria>
## 质量评价标准
### 格式合规性
- ✅ 文件从`<resource protocol="协议名">`标签直接开始
- ✅ 使用正确的DPML resource标签结构
- ✅ 三个子标签按location → params → registry顺序排列
- ✅ XML语法正确，标签正确闭合
- ✅ protocol属性值符合命名规范
### 路径格式规范性
- ✅ location部分使用正确的EBNF语法
- ✅ 路径格式清晰明确，无歧义
- ✅ 参数化路径使用`{parameter}`格式
- ✅ 路径结构与协议用途匹配
- ✅ 支持协议的典型使用场景
### 参数文档完整性
- ✅ 所有参数都有清晰的类型定义
- ✅ 参数描述详细且准确
- ✅ 提供了合理的默认值
- ✅ 参数示例有助于理解
- ✅ 参数组合逻辑合理
### 注册表设计合理性
- ✅ 注册表策略与协议特性匹配
- ✅ 映射关系清晰且实用
- ✅ 路径引用符合PromptX规范
- ✅ 抽象性和具体性平衡适当
- ✅ 支持嵌套协议引用
### 系统集成性
- ✅ 与ResourceManager兼容
- ✅ 与resource.registry.json格式一致
- ✅ 支持标准加载语义（@、@!、@?）
- ✅ 查询参数能被正确解析
- ✅ 与现有协议生态协调
### 实用价值
- ✅ 解决了实际的资源访问需求
- ✅ 路径格式简洁易用
- ✅ 参数设计灵活且必要
- ✅ 注册表提供了实际价值
- ✅ 整体设计具有可扩展性
### 文件纯净性
- ✅ 文件结构完全符合DPML resource规范
- ✅ 无任何XML结构外的多余内容
- ✅ 体现resource协议定义的标准格式
- ✅ 三组件内容充实且相互配合
</criteria>
</execution>

241
prompt/core/execution/role-authoring.execution.md Normal file
View File

@ -0,0 +1,241 @@
<execution>
<constraint>
## 客观技术限制
- **DPML语法约束**：必须遵循EBNF定义的role语法结构
- **XML格式要求**：标签必须正确闭合，属性值必须用双引号包围
- **三组件架构固化**：personality、principle、knowledge三组件的语义边界固定
- **文件编码**：必须使用UTF-8编码
- **引用协议约束**：@!引用必须指向实际存在的资源
- **PromptX系统集成**：必须与promptx命令行工具和ResourceManager兼容
</constraint>
<rule>
## 强制性编写规则
- **纯XML结构**：role文件必须从`<role>`标签开始，不得包含任何XML结构外的内容
- **根标签强制**：文件必须使用`<role>`作为根标签包装全部内容
- **三组件完整**：必须包含personality、principle、knowledge三个子标签
- **组件顺序固定**：子标签必须按personality → principle → knowledge顺序排列
- **文件纯净性**：除了`<role>`标签结构外，不得包含任何其他内容
- **引用规范性**：使用@!引用时必须遵循resource协议语法
- **镜像结构约束**：用户资源必须遵循`.promptx/resource/domain/`结构，镜像系统`prompt/domain/`
</rule>
<guideline>
## 编写指导原则
- **编排优先**：role文件主要职责是编排组合，推荐使用@!引用机制而非直接内容
- **简洁性原则**：保持role文件的简洁和清晰，避免冗长的直接内容
- **模块化思维**：将具体内容抽离到独立的thought、execution、knowledge文件中
- **引用一致性**：在同一role文件中保持引用风格的一致性
- **可维护性**：通过引用机制实现内容的独立维护和复用
- **灵活性保留**：允许在引用和直接内容之间选择，但推荐引用
- **镜像一致性**：用户资源结构与系统资源保持一致，降低认知负载
</guideline>
<process>
## 编写执行流程
### Phase 1: 角色概念设计
1. **明确角色定位**：确定AI角色的核心身份和专业领域
2. **分析能力需求**：识别角色需要的思维特征、行为原则和专业知识
3. **规划组件结构**：决定三个组件的具体内容来源和组织方式
4. **选择编排策略**：决定使用引用机制还是直接内容
### Phase 2: 资源组织规划
#### 用户资源目录结构（镜像系统结构）：
```
.promptx/resource/domain/{roleId}/
├── {roleId}.role.md # 主角色文件
├── thought/ # 思维模式目录
│ └── {name}.thought.md # 专业思维模式
└── execution/ # 执行流程目录
└── {name}.execution.md # 专业执行流程
```
#### 内容来源规划：
1. **思维模式来源**（personality组件）：
- 核心引用：`@!thought://remember`（记忆能力）
- 核心引用：`@!thought://recall`（回忆能力）
- 专业引用：`@!thought://[role-specific]`（角色特定思维）
- 或直接定义角色的思维特征和认知偏好
2. **行为原则来源**（principle组件）：
- 专业引用：`@!execution://[role-specific]`（角色特定执行原则）
- 或直接定义角色的行为准则和工作流程
3. **专业知识来源**（knowledge组件）：
- 领域引用：`@!knowledge://[domain-specific]`（领域专业知识）
- 或直接定义角色的知识体系和技能框架
### Phase 3: DPML结构实现
**关键要求：文件必须从`<role>`标签直接开始**
**推荐编排风格（引用优先）：**
```xml
<role>
<personality>
@!thought://remember
@!thought://recall
@!thought://[role-specific-thought]
</personality>
<principle>
@!execution://[role-specific-execution]
</principle>
<knowledge>
@!knowledge://[domain-specific-knowledge]
</knowledge>
</role>
```
**示例：助手角色（参考assistant.role.md）**
```xml
<role>
<personality>
@!thought://remember
@!thought://recall
@!thought://assistant
</personality>
<principle>
@!execution://assistant
</principle>
<knowledge>
@!knowledge://general-assistant
</knowledge>
</role>
```
**用户资源示例（自定义销售分析师）：**
```xml
<role>
<personality>
@!thought://remember
@!thought://recall
@!thought://sales-analyst
</personality>
<principle>
@!execution://sales-data-analysis
</principle>
<knowledge>
@!knowledge://business-intelligence
</knowledge>
</role>
```
**混合风格（引用+直接内容）：**
```xml
<role>
<personality>
@!thought://remember
@!thought://recall
## 角色特定思维特征
- **用户导向思维**：始终以用户需求为中心
- **解决方案思维**：专注于提供实用的解决方案
</personality>
<principle>
@!execution://assistant
## 补充行为原则
- 保持耐心和友善的交互风格
- 承认不确定性，不臆测答案
</principle>
<knowledge>
@!knowledge://general-assistant
</knowledge>
</role>
```
**纯直接内容风格（不推荐但允许）：**
```xml
<role>
<personality>
# 角色思维模式
## 核心思维特征
- **特征1**：描述
- **特征2**：描述
</personality>
<principle>
# 角色行为原则
## 核心原则
- **原则1**：描述
- **原则2**：描述
</principle>
<knowledge>
# 角色专业知识
## 知识领域
- **领域1**：描述
- **领域2**：描述
</knowledge>
</role>
```
### Phase 4: 质量检查和集成验证
1. **结构验证**：确保DPML role语法正确性
2. **引用检查**：验证所有@!引用的资源实际存在
3. **三组件完整性**：确认personality、principle、knowledge都有实质内容
4. **系统集成测试**：验证与promptx命令和ResourceManager的兼容性
5. **纯净性检查**：确认文件从`<role>`标签开始，无多余内容
6. **镜像结构验证**：确认用户资源目录结构符合镜像规范
</process>
<criteria>
## 质量评价标准
### 格式合规性
- ✅ 文件从`<role>`标签直接开始，无额外内容
- ✅ 使用正确的DPML role标签结构
- ✅ 三个子标签按personality → principle → knowledge顺序排列
- ✅ XML语法正确，标签正确闭合
- ✅ Markdown格式规范（如有直接内容）
### 编排质量
- ✅ 体现role文件的编排组合职责
- ✅ 合理使用@!引用机制实现模块化
- ✅ 保持文件的简洁性和可读性
- ✅ 引用风格在文件内保持一致
- ✅ 避免不必要的冗长直接内容
### 三组件完整性
- ✅ personality组件包含思维特征定义或引用
- ✅ principle组件包含行为原则定义或引用
- ✅ knowledge组件包含专业知识定义或引用
- ✅ 三组件逻辑一致，共同构建完整角色
- ✅ 组件内容与角色定位匹配
### 引用有效性
- ✅ 所有@!引用遵循resource协议语法
- ✅ 引用的资源路径正确且存在
- ✅ 引用内容与组件语义匹配
- ✅ 引用关系清晰，无循环依赖
### 系统集成性
- ✅ 与PromptX锦囊串联系统兼容
- ✅ 支持promptx action命令激活
- ✅ 角色定义可被AI系统正确解析
- ✅ 实现角色的即时专家化能力
- ✅ ResourceManager可正确发现和加载
### 文件纯净性
- ✅ 文件结构完全符合DPML role规范
- ✅ 无任何XML结构外的多余内容
- ✅ 体现role文件的标准编排格式
- ✅ 维持role文件的简洁优雅特性
### 架构合规性
- ✅ 用户资源目录结构镜像系统结构
- ✅ 文件组织符合`.promptx/resource/domain/`规范
- ✅ 与系统资源结构保持一致性
- ✅ 降低用户认知负载和学习成本
</criteria>
</execution>

138
prompt/core/execution/role-generation.execution.md Normal file
View File

@ -0,0 +1,138 @@
<execution>
<constraint>
## 客观技术限制
- **DPML协议约束**：生成的角色必须严格遵循DPML `<role>`标签框架和三组件架构
- **文件格式要求**：生成的角色文件必须是有效的Markdown格式并符合XML语法
- **系统集成约束**：生成的角色必须与PromptX系统兼容，支持ResourceManager发现机制
- **快速生成要求**：整个创建过程应在1-2分钟内完成
- **目录结构约束**：用户资源必须创建在`.promptx/resource/domain/{roleId}/`目录，镜像系统结构
- **文件组织约束**：角色相关的所有文件（execution、thought等）必须统一存放在角色目录下
</constraint>
<rule>
## 强制性执行规则
- **三组件完整性**：每个生成的角色必须包含personality、principle、knowledge三个完整组件
- **DPML语法严格性**：生成内容必须使用正确的XML标签语法，标签必须正确闭合
- **领域识别准确性**：必须准确识别用户需求的专业领域
- **模板化生成**：基于标准模板快速生成，避免复杂的定制化过程
- **一次性交付**：生成后直接交付，避免反复确认和修改
- **镜像结构强制**：用户资源必须创建在`.promptx/resource/domain/{roleId}/`，镜像系统`prompt/domain/`结构
- **文件统一管理**：角色的execution、thought等扩展文件必须放在同一角色目录下，便于统一管理
- **引用路径准确**：使用@!引用时必须指向正确的文件路径，确保引用关系有效
</rule>
<guideline>
## 执行指导原则
- **简洁高效**：优先速度和效率，避免冗长对话
- **标准化优先**：使用领域标准能力，而非深度定制
- **即用原则**：生成的角色应立即可用，无需额外配置
- **用户友好**：保持简单明了的交互体验
- **镜像一致**：与系统结构保持一致，降低认知负载
</guideline>
<process>
## 极简3步生成流程
### Step 1: 领域快速识别 (30秒内)
```
目标：从用户描述中快速提取领域关键词
识别策略：
- 提取技术栈关键词（如：微信小程序、React、Python等）
- 识别职业角色关键词（如：产品经理、设计师、运营等）
- 理解功能需求关键词（如：开发、分析、营销等）
快速确认：
"明白了！您需要一个【X领域】的专业AI助手，对吗？"
处理原则：
- 最多1次确认，用户确认后立即进入生成
- 如果领域明确，跳过确认直接生成
```
### Step 2: 模板化角色生成 (60秒内)
```
基于识别的领域，调用标准模板：
模板选择逻辑：
- 微信小程序 → 小程序开发专家模板
- 前端开发 → 前端工程师模板
- 产品管理 → 产品经理模板
- 数据分析 → 数据分析师模板
- 更多领域... → 对应专业模板
文件组织结构（镜像系统结构）：
.promptx/resource/domain/{roleId}/
├── {roleId}.role.md # 主角色文件
├── thought/ # 思维模式目录（需要时创建）
│ └── {specific}.thought.md # 专业思维模式
└── execution/ # 执行模式目录（需要时创建）
└── {specific}.execution.md # 专业执行流程
三组件自动填充：
personality: 引用该领域的标准思维模式（remember + recall + 专业思维）
principle: 引用该领域的标准执行流程（可独立创建execution文件）
knowledge: 引用该领域的专业知识体系（或直接定义）
质量检查：
☐ DPML格式正确
☐ 三组件完整
☐ 引用资源有效
☐ 目录结构规范（镜像系统结构）
☐ 文件路径正确
☐ ResourceManager可发现
```
### Step 3: 结果直接交付 (30秒内)
```
呈现格式：
1. 角色价值简述
2. 文件创建确认（正确目录结构）
3. 激活命令说明
4. 使用建议（可选）
目录结构展示（镜像系统结构）：
.promptx/resource/domain/{roleId}/
├── {roleId}.role.md # ✅ 已创建
└── [其他扩展文件] # ✅ 按需创建
交付策略：
- 确认角色已正确创建在用户资源目录
- 提供立即可用的激活命令
- 说明文件组织规范（与系统结构一致）
- 说明ResourceManager自动发现机制
后续支持：
- 如果用户满意，直接结束
- 如果需要扩展功能，指导创建execution/thought文件
```
</process>
<criteria>
## 质量评价标准
### 效率指标
- ✅ 总用时 ≤ 2分钟
- ✅ 对话轮次 ≤ 3轮
- ✅ 一次性生成成功率 ≥ 90%
- ✅ 用户满意度 ≥ 85%
### 角色质量
- ✅ DPML协议完全合规
- ✅ 三组件内容实用
- ✅ 角色定位准确
- ✅ 立即可激活使用
### 架构合规
- ✅ 目录结构镜像系统结构
- ✅ ResourceManager可发现
- ✅ 用户资源路径正确
- ✅ 引用关系有效
### 用户体验
- ✅ 交互流程简洁
- ✅ 生成结果清晰
- ✅ 激活方法明确
- ✅ 学习成本极低
</criteria>
</execution>

183
prompt/core/execution/thought-authoring.execution.md Normal file
View File

@ -0,0 +1,183 @@
<execution>
<constraint>
## 客观技术限制
- **DPML语法约束**：必须遵循EBNF定义的thought语法结构
- **XML格式要求**：标签必须正确闭合，属性值必须用双引号包围
- **Markdown兼容性**：内容部分必须是有效的Markdown格式，支持Mermaid图表
- **文件编码**：必须使用UTF-8编码
- **思维模式固化**：四种思维模式的语义特征不可改变
- **可视化限制**：Mermaid图表必须符合语法规范
</constraint>
<rule>
## 强制性编写规则
- **纯XML结构**：thought文件必须从`<thought>`标签开始，不得包含任何XML结构外的内容
- **根标签强制**：文件必须使用`<thought>`作为根标签包装全部内容
- **子标签命名**：只能使用规范定义的四个思维模式子标签：exploration, reasoning, plan, challenge
- **语义一致性**：每个子标签内容必须与其思维模式语义定义保持一致
- **文件纯净性**：除了`<thought>`标签结构外，不得包含任何其他内容
- **内容实质性**：包含的子标签都必须有实质性思考内容，不得为空
</rule>
<guideline>
## 编写指导原则
- **思维模式清晰性**：每个子标签的内容应明确体现对应的思维特征
- **推荐思考顺序**：建议按exploration → challenge → reasoning → plan顺序组织思考
- **可视化优先**：优先使用Mermaid图表表达复杂的思维关系和逻辑结构
- **内容层次化**：使用Markdown的标题、列表等结构组织思考内容
- **思维完整性**：确保思考覆盖问题的关键维度，避免思维盲区
- **灵活组合**：根据实际需求选择合适的思维模式组合，无需全部使用
</guideline>
<process>
## 编写执行流程
### Phase 1: 思考需求分析
1. **明确思考目标**：确定这个thought要解决什么问题或分析什么议题
2. **识别思考复杂度**：判断问题是否需要多维度思考
3. **选择思维模式**：根据问题特点选择合适的思维模式组合
4. **确定思考深度**：决定每个思维模式需要的分析深度
### Phase 2: 思维模式规划
1. **探索思维规划**：
- 确定需要发散思考的维度
- 列出要探索的可能性和创新点
- 规划关联性分析的范围
2. **挑战思维规划**：
- 识别需要质疑的假设和观点
- 列出潜在风险和问题点
- 规划批判性分析的角度
3. **推理思维规划**：
- 确定需要验证的逻辑链条
- 规划因果关系分析路径
- 设计系统性推理结构
4. **计划思维规划**：
- 明确需要设计的行动方案
- 规划决策路径和组织结构
- 确定系统架构的层次
### Phase 3: DPML结构实现
**关键要求：文件必须从`<thought>`标签直接开始**
```xml
<thought>
<exploration>
# 探索思维：发散性思考
[跳跃思考、生成可能性、寻找创新点和关联性]
</exploration>
<challenge>
# 挑战思维：批判性思考
[逆向思考、质疑假设、识别风险和问题点]
</challenge>
<reasoning>
# 推理思维：系统性思考
[连续推理、验证逻辑、分析因果关系]
</reasoning>
<plan>
# 计划思维：结构性思考
[设计方案、决策路径、组织架构]
</plan>
</thought>
```
**推荐思考顺序示例：**
```xml
<thought>
<!-- 1. 先发散探索 -->
<exploration>
## 可能性探索
- 方向A：...
- 方向B：...
## 关联性分析
```mermaid
mindmap
root)问题核心(
分支1
分支2
分支3
```
</exploration>
<!-- 2. 再批判质疑 -->
<challenge>
## 假设质疑
- 对方向A的质疑：...
- 对方向B的质疑：...
## 风险识别
- 潜在风险1：...
- 潜在风险2：...
</challenge>
<!-- 3. 然后系统推理 -->
<reasoning>
## 逻辑验证
```mermaid
flowchart TD
A[前提] --> B[推理]
B --> C[结论]
```
</reasoning>
<!-- 4. 最后制定计划 -->
<plan>
## 行动方案
1. 步骤一：...
2. 步骤二：...
</plan>
</thought>
```
### Phase 4: 思维质量检查
1. **思维模式验证**：确保每个子标签体现正确的思维特征
2. **逻辑一致性检查**：验证不同思维模式间的逻辑关系
3. **思考完整性审核**：确认思考覆盖问题的关键维度
4. **可视化检查**：验证Mermaid图表语法正确性和表达清晰性
5. **纯净性检查**：确认文件从`<thought>`标签开始，无多余内容
</process>
<criteria>
## 质量评价标准
### 格式合规性
- ✅ 文件从`<thought>`标签直接开始，无额外内容
- ✅ 使用正确的DPML thought标签结构
- ✅ 子标签命名符合四种思维模式规范
- ✅ XML语法正确，标签正确闭合
- ✅ Markdown格式规范，Mermaid图表有效
### 思维模式准确性
- ✅ exploration体现发散性、跳跃性思考特征
- ✅ challenge体现批判性、逆向思考特征
- ✅ reasoning体现系统性、连续性推理特征
- ✅ plan体现结构性、秩序性思考特征
- ✅ 各思维模式语义边界清晰，不混淆
### 思考质量
- ✅ 思考内容具有实质性和深度
- ✅ 逻辑关系清晰，推理链条完整
- ✅ 覆盖问题的关键维度，无明显盲区
- ✅ 思维过程系统化，层次分明
- ✅ 结论或方案具有可操作性
### 可视化效果
- ✅ 恰当使用Mermaid图表表达复杂关系
- ✅ 图表类型选择合适（mindmap, flowchart, graph等）
- ✅ 可视化内容与文字描述相互补充
- ✅ 图表简洁清晰，易于理解
### 文件纯净性
- ✅ 文件结构完全符合DPML thought规范
- ✅ 无任何XML结构外的多余内容
- ✅ 体现thought文件的标准格式
- ✅ 思维模式组合合理，符合实际需求
</criteria>
</execution>