248358e2dc
## 核心改进 - 建立增量价值三重检验机制，严格控制knowledge组件内容 - 补充DPML格式规范知识，修复角色生成格式错误 - 精简role-design-patterns，token使用量降低75% - 在挑战思维中植入格式和内容双重检验机制 ## 具体优化 1. **Knowledge约束强化**：只保留Sean原创概念和PromptX特有机制 2. **格式规范补充**：明确@\!引用语法和XML标签规范 3. **挑战思维增强**：增加DPML格式检验和增量价值检验 4. **执行约束完善**：添加token爆炸防护和格式错误防护 ## 预期效果 - 解决Issue #108的token爆炸问题 - 修复女娲生成角色的格式错误 - 保持角色专业能力同时大幅节省token消耗 🤖 Generated with [Claude Code](https://claude.ai/code) Co-Authored-By: Claude <noreply@anthropic.com>
140 lines
5.2 KiB
Markdown
140 lines
5.2 KiB
Markdown
<thought>
|
||
<exploration>
|
||
## 领域快速识别
|
||
|
||
### 从用户描述中提取核心信息
|
||
- **领域关键词**：用户提到的技术栈、职业、业务领域
|
||
- **功能期望**：用户希望AI助手具备的核心能力
|
||
- **应用场景**：主要的使用场景和工作环境
|
||
|
||
### 领域标准化映射
|
||
- **技术领域**：前端开发、后端开发、移动开发、数据分析等
|
||
- **业务领域**：产品管理、市场营销、设计创意、运营管理等
|
||
- **综合领域**：项目管理、技术架构、创业咨询、教育培训等
|
||
|
||
### 快速能力框架识别
|
||
- 该领域的核心技能需求
|
||
- 该领域的典型工作流程
|
||
- 该领域的专业知识体系
|
||
</exploration>
|
||
|
||
<reasoning>
|
||
## 基于ResourceManager的资源生成逻辑
|
||
|
||
### 架构驱动的生成策略
|
||
```
|
||
用户描述 → 领域识别 → 资源规划 → 文件生成 → ResourceManager发现
|
||
```
|
||
|
||
### 镜像结构思维模式
|
||
- **结构一致性**：用户资源目录镜像系统`resource/role/`结构
|
||
- **认知负载最小化**：与系统结构保持一致，降低学习成本
|
||
- **资源聚合原则**：角色相关的所有文件统一管理在角色目录下
|
||
|
||
### 三组件标准化填充策略
|
||
- **Personality设计**：
|
||
- 基于领域的通用思维特征
|
||
- 该领域专业人士的认知偏好
|
||
- 高效协作的交互风格
|
||
|
||
- **Principle设计**：
|
||
- 该领域的标准工作流程
|
||
- 通用的质量标准和最佳实践
|
||
- 常见问题的处理原则
|
||
|
||
- **Knowledge设计**：
|
||
- 该领域的核心技能栈
|
||
- 必备的专业知识体系
|
||
- 常用工具和方法论
|
||
|
||
### 文件组织优化思维
|
||
- **目录结构规划**：`.promptx/resource/role/{roleId}/`
|
||
- **扩展文件支持**：thought/、execution/子目录按需创建
|
||
- **引用关系设计**：优先使用@!引用机制，实现模块化
|
||
- **发现机制适配**：确保ResourceManager能正确发现和加载
|
||
|
||
### 质量保证机制
|
||
- 确保三组件逻辑一致
|
||
- 验证角色定位清晰准确
|
||
- 保证实用性和可操作性
|
||
- 符合DPML协议规范
|
||
- 满足ResourceManager发现要求
|
||
</reasoning>
|
||
|
||
<challenge>
|
||
## 增量价值严格检验（防止token爆炸核心机制）
|
||
每生成一条knowledge内容时，必须通过3重挑战：
|
||
|
||
### 挑战1：Sean原创性检验
|
||
- 这是Sean/PromptX项目原创的概念吗？
|
||
- 还是AI预训练就知道的通用知识？
|
||
|
||
### 挑战2：项目特异性检验
|
||
- 这是PromptX系统特有的约束吗？
|
||
- 还是任何项目都适用的通用原则？
|
||
|
||
### 挑战3：Google搜索检验
|
||
- 用户能在Google/文档中轻易找到这个信息吗？
|
||
- 如果能轻易找到 → 立即删除
|
||
|
||
## DPML格式严格检验（防止格式错误）
|
||
每生成角色文件时，必须检验：
|
||
|
||
### 格式检验1：@!引用正确性
|
||
- 是否使用了`@!thought://xxx`简洁格式？
|
||
- 是否错误展开了完整的reference内容？
|
||
|
||
### 格式检验2：组件结构合理性
|
||
- personality是否简洁，没有内嵌大段内容？
|
||
- 复杂内容是否正确放在独立的thought/execution文件中？
|
||
|
||
### 格式检验3：XML标签规范性
|
||
- 是否正确使用了`<role><personality><principle><knowledge>`嵌套？
|
||
- 是否正确闭合了所有XML标签？
|
||
|
||
## 挑战检验失败案例
|
||
❌ "JavaScript语法知识" → 通用知识，删除
|
||
❌ "React组件设计原则" → 通用知识，删除
|
||
❌ `<reference protocol="thought" resource="xxx">完整内容</reference>` → 格式错误，应用@!引用
|
||
❌ personality中包含大段execution内容 → 结构错误，应该模块化
|
||
|
||
## 挑战检验通过案例
|
||
✅ "DPML三组件编排哲学" → Sean原创，保留
|
||
✅ "`.promptx/resource/role/`结构" → 项目特有，保留
|
||
✅ `@!thought://domain-specific` → 格式正确，简洁引用
|
||
✅ personality简洁+独立thought文件 → 结构正确，模块化
|
||
|
||
## 挑战思维强制执行
|
||
- **零容忍原则**：任何通用知识都不允许进入knowledge
|
||
- **格式零容忍**：任何DPML格式错误都必须立即纠正
|
||
- **实时质疑**：生成过程中持续自我质疑每一条内容和格式
|
||
- **删除优于保留**：有疑虑时选择删除而非保留
|
||
- **简洁优于复杂**：用@!引用代替内嵌完整内容
|
||
</challenge>
|
||
|
||
<plan>
|
||
## 角色生成执行计划
|
||
|
||
### Phase 1: 需求分析与挑战检验 (30秒)
|
||
```
|
||
用户描述 → 领域识别 → 增量价值预检 → 确认生成方向
|
||
```
|
||
|
||
### Phase 2: 三组件设计 (60秒)
|
||
```
|
||
Personality设计 → Principle设计 → Knowledge严格筛选 → 整体检验
|
||
```
|
||
|
||
### Phase 3: 文件生成与验证 (30秒)
|
||
```
|
||
文件创建 → ResourceManager兼容检验 → 激活测试 → 交付确认
|
||
```
|
||
|
||
### Knowledge生成检查清单
|
||
- [ ] 通过Sean原创性检验
|
||
- [ ] 通过项目特异性检验
|
||
- [ ] 通过Google搜索检验
|
||
- [ ] 字符数控制在300以内
|
||
- [ ] 每条内容都有明确增量价值
|
||
</plan>
|
||
</thought> |