160 lines
5.8 KiB
Markdown
160 lines
5.8 KiB
Markdown
<execution domain="prompt-engineering">
|
||
<process>
|
||
# 资源模式提示词开发流程
|
||
|
||
```mermaid
|
||
flowchart TD
|
||
A[明确资源需求] --> B[设计资源路径结构]
|
||
B --> C[定义查询参数]
|
||
C --> D[建立资源注册表]
|
||
D --> E[验证资源协议]
|
||
E -->|通过| F[完成资源定义]
|
||
E -->|不通过| G[调整修正]
|
||
G --> B
|
||
```
|
||
|
||
## 核心步骤详解
|
||
|
||
1. **明确资源需求**
|
||
- 确定资源类型和用途
|
||
- 定义资源的生命周期和作用域
|
||
- 规划资源的访问模式
|
||
|
||
2. **设计资源路径结构**
|
||
- 使用`<location>`标签定义路径规则
|
||
- 通过EBNF形式描述路径结构
|
||
- 提供清晰的路径示例
|
||
|
||
3. **定义查询参数**
|
||
- 使用`<params>`标签定义参数
|
||
- 明确参数名称、类型和作用
|
||
- 设计参数组合规则和优先级
|
||
|
||
4. **建立资源注册表**
|
||
- 使用`<registry>`标签建立映射
|
||
- 将抽象ID映射到具体资源路径
|
||
- 确保映射关系清晰且无冲突
|
||
|
||
5. **验证资源协议**
|
||
- 测试资源引用的解析正确性
|
||
- 验证资源加载语义（@、@!、@?）
|
||
- 检查嵌套引用和查询参数功能
|
||
</process>
|
||
|
||
<guideline>
|
||
### 资源路径设计指南
|
||
|
||
- **简洁明确**：路径应当简洁但足够明确，避免歧义
|
||
```
|
||
@file://documents/report.md ✓
|
||
@file://docs/some-stuff/thing.md ✗
|
||
```
|
||
|
||
- **分层结构**：使用层级结构组织资源，增强可读性
|
||
```
|
||
@file://project/src/components/button.js ✓
|
||
@file://project_src_components_button.js ✗
|
||
```
|
||
|
||
- **命名规范**：使用一致的命名规则
|
||
```
|
||
@file://images/logo.png ✓
|
||
@file://Images/LOGO.png ✗
|
||
```
|
||
|
||
- **通配符合理使用**：
|
||
```
|
||
@file://src/**/*.js ✓ (递归查找所有JS文件)
|
||
@file://**/* ✗ (过于宽泛)
|
||
```
|
||
|
||
### 查询参数设计指南
|
||
|
||
- **参数命名**：使用描述性名称，遵循常见约定
|
||
```
|
||
?format=json ✓
|
||
?f=j ✗
|
||
```
|
||
|
||
- **参数分组**：相关参数应使用一致的前缀
|
||
```
|
||
?filter.type=user&filter.status=active ✓
|
||
?filter_type=user&status_filter=active ✗
|
||
```
|
||
|
||
- **默认值处理**：明确指定参数的默认行为
|
||
```
|
||
在<params>中说明: "format默认为'text'" ✓
|
||
不指定默认值 ✗
|
||
```
|
||
|
||
### 注册表设计指南
|
||
|
||
- **ID命名**：使用有意义的ID，体现资源内容
|
||
```
|
||
analytical (用于分析型思维) ✓
|
||
thought1, thought2 ✗
|
||
```
|
||
|
||
- **路径模板**：对于相似资源，使用一致的路径模板
|
||
```
|
||
@file://PromptX/domain/{domain}/{resource}.{type}.md ✓
|
||
混合不同路径风格 ✗
|
||
```
|
||
|
||
- **分类组织**：按功能或领域对注册表条目分组
|
||
```
|
||
<!-- 基础思维模式 -->
|
||
| analytical | ... |
|
||
| creative | ... |
|
||
|
||
<!-- 专业领域思维模式 -->
|
||
| medical | ... |
|
||
```
|
||
|
||
### 资源引用指南
|
||
|
||
- **加载语义选择**：
|
||
- `@`：一般资源，非关键，可延迟加载
|
||
- `@!`：关键资源，必须立即加载
|
||
- `@?`：大型资源，仅在需要时加载
|
||
|
||
- **嵌套引用建议**：
|
||
- 简单情况使用简写形式：`@execution:file://path.md`
|
||
- 复杂情况使用完整形式：`@execution:@file://path.md`
|
||
- 多重嵌套不超过3层：`@outer:middle:inner://path`
|
||
</guideline>
|
||
|
||
<rule>
|
||
1. **路径格式一致性** - 资源路径必须遵循EBNF中定义的语法规则
|
||
2. **三要素完整性** - 自定义协议必须包含location、params和registry三个核心组件
|
||
3. **加载语义明确性** - 资源引用必须明确其加载语义（@、@!、@?）的使用场景
|
||
4. **查询参数规范化** - 参数名称和值格式必须明确规范
|
||
5. **注册表唯一性** - 注册表中的ID必须唯一，不允许重复
|
||
6. **资源获取主动性** - AI必须主动使用工具调用获取资源，特别是@!前缀的资源
|
||
7. **路径解析完整性** - 必须正确处理嵌套引用，从内向外解析
|
||
8. **资源验证必要性** - 必须验证资源是否成功加载，并妥善处理加载失败情况
|
||
</rule>
|
||
|
||
<constraint>
|
||
1. **路径长度限制** - 资源路径不应过长，建议不超过255字符
|
||
2. **嵌套深度限制** - 嵌套引用不应超过3层，以保持可读性
|
||
3. **查询参数复杂度限制** - 单个资源引用的查询参数不宜过多
|
||
4. **注册表大小限制** - 单个注册表条目数量应控制在可管理范围内
|
||
5. **资源访问权限限制** - 需考虑环境对资源访问的权限限制
|
||
6. **解析环境限制** - 资源路径和参数需考虑在不同解析环境中的兼容性
|
||
</constraint>
|
||
|
||
<criteria>
|
||
| 指标 | 通过标准 | 不通过标准 |
|
||
|------|---------|-----------|
|
||
| 路径清晰度 | 路径结构直观易懂 | 路径结构混乱或难以理解 |
|
||
| 参数设计合理性 | 参数命名明确，功能清晰 | 参数命名模糊，功能重叠 |
|
||
| 注册表组织性 | 注册表条目分类合理，ID有意义 | 注册表混乱，ID无意义 |
|
||
| 加载语义正确性 | 正确使用@、@!、@?前缀 | 加载语义使用不当 |
|
||
| 嵌套引用可读性 | 嵌套结构清晰，不过度复杂 | 嵌套过深或结构混乱 |
|
||
| 资源获取可靠性 | 资源加载有验证和错误处理 | 缺少验证或错误处理 |
|
||
| 通配符使用合理性 | 通配符模式精确且高效 | 过于宽泛或低效的模式 |
|
||
| 整体一致性 | 资源协议设计风格统一 | 设计风格不一致或混乱 |
|
||
</criteria>
|
||
</execution> |