[aide] impl: 子计划1完成:创建 task-parser skill
This commit is contained in:
@@ -1,7 +1,7 @@
|
||||
{
|
||||
"task_id": "2025-12-16T20-22-50",
|
||||
"current_phase": "flow-design",
|
||||
"current_step": 4,
|
||||
"current_phase": "impl",
|
||||
"current_step": 5,
|
||||
"started_at": "2025-12-16T20:22:50+08:00",
|
||||
"history": [
|
||||
{
|
||||
@@ -35,6 +35,14 @@
|
||||
"step": 4,
|
||||
"summary": "任务执行流程图设计完成",
|
||||
"git_commit": "d172e43e91327d050a1b1b782e1ad726fe63c406"
|
||||
},
|
||||
{
|
||||
"timestamp": "2025-12-16T20:25:20+08:00",
|
||||
"action": "next-part",
|
||||
"phase": "impl",
|
||||
"step": 5,
|
||||
"summary": "流程设计完成,进入实现环节",
|
||||
"git_commit": "dd3aba3c6ad5b6f94596f174b5b286c526107560"
|
||||
}
|
||||
]
|
||||
}
|
||||
|
||||
@@ -1 +1 @@
|
||||
76652
|
||||
77892
|
||||
279
aide-marketplace/aide-plugin/skills/task-parser/SKILL.md
Normal file
279
aide-marketplace/aide-plugin/skills/task-parser/SKILL.md
Normal file
@@ -0,0 +1,279 @@
|
||||
---
|
||||
name: task-parser
|
||||
description: 口语化任务内容解析器。当发现用户对话或任务文档具有明显口头语气时使用,用于深度理解内容、提取核心意图、进行批判性分析,并将口语化内容转化为结构化的任务描述。
|
||||
---
|
||||
|
||||
# 口语化任务内容解析指南
|
||||
|
||||
当任务文档或用户对话具有口语化特征时,使用本指南进行深度解析和规范化转换。
|
||||
|
||||
## 触发条件
|
||||
|
||||
当内容具有以下特征之一时应使用本 skill:
|
||||
|
||||
- 使用非正式的口头表达方式
|
||||
- 包含大量模糊表述("我觉得"、"好像"、"大概"、"应该"等)
|
||||
- 句子结构松散,缺乏条理性
|
||||
- 包含冗余或重复的表达
|
||||
- 思维跳跃,逻辑不连贯
|
||||
- 使用口头禅或语气词
|
||||
|
||||
---
|
||||
|
||||
## 解析流程
|
||||
|
||||
### 第一阶段:语义解析
|
||||
|
||||
#### 1.1 表层理解
|
||||
|
||||
- **直译内容**:逐句理解字面意思
|
||||
- **语境还原**:识别省略的主语、宾语、上下文
|
||||
- **口语转译**:将口语表达转换为书面语
|
||||
|
||||
#### 1.2 深层提取
|
||||
|
||||
- **核心意图**:用户真正想要实现什么?
|
||||
- **真实需求**:表面需求背后的实际需求是什么?
|
||||
- **隐含期望**:未明确说明但实际期望的内容
|
||||
|
||||
#### 1.3 结构重组
|
||||
|
||||
将散乱的内容重组为结构化描述:
|
||||
|
||||
```
|
||||
## 任务目标
|
||||
[一句话描述核心目标]
|
||||
|
||||
## 具体要求
|
||||
1. [要求1]
|
||||
2. [要求2]
|
||||
...
|
||||
|
||||
## 约束条件
|
||||
- [约束1]
|
||||
- [约束2]
|
||||
|
||||
## 期望产出
|
||||
- [产出1]
|
||||
- [产出2]
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### 第二阶段:批判性分析
|
||||
|
||||
#### 2.1 逻辑漏洞检测
|
||||
|
||||
- **推理断裂**:论证过程中缺失的逻辑环节
|
||||
- **因果混淆**:相关性被误认为因果性
|
||||
- **循环论证**:结论预设在前提中
|
||||
- **过度泛化**:从个例推导普遍规律
|
||||
|
||||
#### 2.2 盲点与不足识别
|
||||
|
||||
- **遗漏的边界条件**:未考虑的特殊情况
|
||||
- **依赖假设**:隐含但未声明的前提假设
|
||||
- **潜在风险**:可能导致问题的隐患
|
||||
- **技术债务**:可能引入的后续维护负担
|
||||
|
||||
#### 2.3 过度设计识别
|
||||
|
||||
- **不必要的抽象**:过早或过度的模块化
|
||||
- **冗余的功能**:超出实际需求的特性
|
||||
- **过度的灵活性**:为不存在的场景预留扩展
|
||||
|
||||
---
|
||||
|
||||
### 第三阶段:建设性优化
|
||||
|
||||
#### 3.1 优化方向建议
|
||||
|
||||
针对发现的问题,提出具体的优化方向:
|
||||
|
||||
| 问题类型 | 优化建议 |
|
||||
|----------|----------|
|
||||
| 表述模糊 | 明确具体指标或标准 |
|
||||
| 范围不清 | 界定边界和例外情况 |
|
||||
| 步骤缺失 | 补充必要的中间步骤 |
|
||||
| 依赖不明 | 明确前置条件和依赖 |
|
||||
|
||||
#### 3.2 替代方案对比
|
||||
|
||||
对于关键决策点,提供多种可行方案:
|
||||
|
||||
```
|
||||
### 方案对比
|
||||
|
||||
| 维度 | 方案A | 方案B | 方案C |
|
||||
|------|-------|-------|-------|
|
||||
| 优点 | ... | ... | ... |
|
||||
| 缺点 | ... | ... | ... |
|
||||
| 适用场景 | ... | ... | ... |
|
||||
| 推荐度 | ★★★ | ★★☆ | ★☆☆ |
|
||||
```
|
||||
|
||||
#### 3.3 风险与权衡
|
||||
|
||||
- 明确说明各方案的利弊
|
||||
- 指出选择某方案可能带来的后果
|
||||
- 提供风险缓解建议
|
||||
|
||||
---
|
||||
|
||||
### 第四阶段:上下文关联分析
|
||||
|
||||
#### 4.1 项目关联
|
||||
|
||||
- **现有模块**:任务与哪些现有模块相关?
|
||||
- **代码位置**:需要修改或新增哪些文件?
|
||||
- **依赖关系**:与其他功能的依赖和影响
|
||||
|
||||
#### 4.2 隐含需求挖掘
|
||||
|
||||
从上下文中推断未明确说明的需求:
|
||||
|
||||
- 基于项目惯例推断的规范要求
|
||||
- 基于技术栈推断的最佳实践
|
||||
- 基于用户习惯推断的使用方式
|
||||
|
||||
#### 4.3 复杂度预判
|
||||
|
||||
初步评估任务复杂度:
|
||||
|
||||
| 维度 | 评估 | 说明 |
|
||||
|------|------|------|
|
||||
| 结构复杂度 | 低/中/高 | 涉及模块数量、文件数量 |
|
||||
| 逻辑复杂度 | 低/中/高 | 业务逻辑、状态管理 |
|
||||
| 集成复杂度 | 低/中/高 | 外部依赖、数据格式 |
|
||||
| 风险等级 | 低/中/高 | 影响范围、回滚难度 |
|
||||
|
||||
---
|
||||
|
||||
## 输出格式
|
||||
|
||||
解析完成后,输出规范化的任务描述:
|
||||
|
||||
```markdown
|
||||
# 任务解析结果
|
||||
|
||||
## 原始内容概述
|
||||
[简述原始内容的主要信息]
|
||||
|
||||
## 核心意图
|
||||
[一句话描述用户真正想要实现的目标]
|
||||
|
||||
## 结构化任务描述
|
||||
|
||||
### 目标
|
||||
[清晰明确的任务目标]
|
||||
|
||||
### 具体要求
|
||||
1. [要求1 - 具体、可验证]
|
||||
2. [要求2 - 具体、可验证]
|
||||
...
|
||||
|
||||
### 约束条件
|
||||
- [约束1]
|
||||
- [约束2]
|
||||
|
||||
### 期望产出
|
||||
- [产出1]
|
||||
- [产出2]
|
||||
|
||||
## 分析发现
|
||||
|
||||
### 需要澄清的问题
|
||||
- [问题1]
|
||||
- [问题2]
|
||||
|
||||
### 识别的风险
|
||||
- [风险1]
|
||||
- [风险2]
|
||||
|
||||
### 优化建议
|
||||
- [建议1]
|
||||
- [建议2]
|
||||
|
||||
## 复杂度评估
|
||||
[简要说明任务复杂度和建议处理方式]
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 使用示例
|
||||
|
||||
### 输入示例
|
||||
|
||||
```
|
||||
我想给这个项目加个登录功能,就是那种用户名密码的,然后还要能记住登录状态,
|
||||
对了最好还能支持第三方登录,比如微信啊什么的,
|
||||
然后密码要加密存储,不能明文,安全很重要的,
|
||||
还有就是登录失败要有提示,成功了就跳转到首页
|
||||
```
|
||||
|
||||
### 解析输出
|
||||
|
||||
```markdown
|
||||
# 任务解析结果
|
||||
|
||||
## 原始内容概述
|
||||
用户希望为项目添加用户认证功能,包括基础登录、会话保持和第三方登录支持。
|
||||
|
||||
## 核心意图
|
||||
实现一套完整的用户认证系统,支持多种登录方式和安全的凭证管理。
|
||||
|
||||
## 结构化任务描述
|
||||
|
||||
### 目标
|
||||
为项目添加用户登录功能,支持本地账号和第三方账号登录。
|
||||
|
||||
### 具体要求
|
||||
1. 实现用户名密码登录
|
||||
2. 实现"记住我"功能(会话持久化)
|
||||
3. 支持第三方登录(微信等)
|
||||
4. 密码使用安全算法加密存储
|
||||
5. 登录失败显示错误提示
|
||||
6. 登录成功跳转首页
|
||||
|
||||
### 约束条件
|
||||
- 密码不能明文存储
|
||||
- 需要考虑安全性
|
||||
|
||||
### 期望产出
|
||||
- 登录页面
|
||||
- 认证接口
|
||||
- 会话管理机制
|
||||
- 第三方登录集成
|
||||
|
||||
## 分析发现
|
||||
|
||||
### 需要澄清的问题
|
||||
- 支持哪些第三方登录?(仅微信还是更多?)
|
||||
- 会话保持时长是多少?
|
||||
- 是否需要注册功能?
|
||||
- 是否需要密码找回功能?
|
||||
- 登录失败次数限制?
|
||||
|
||||
### 识别的风险
|
||||
- 第三方登录需要申请对应平台的开发者资质
|
||||
- 密码加密算法选择影响安全性
|
||||
- 会话管理实现不当可能导致安全漏洞
|
||||
|
||||
### 优化建议
|
||||
- 建议使用 bcrypt 或 Argon2 进行密码哈希
|
||||
- 建议实现登录失败次数限制防止暴力破解
|
||||
- 建议优先实现核心登录功能,第三方登录作为后续迭代
|
||||
|
||||
## 复杂度评估
|
||||
中等复杂度。建议拆分为:基础登录 → 会话管理 → 第三方登录 三个阶段实现。
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 注意事项
|
||||
|
||||
1. **保持客观**:分析时保持中立,不预设立场
|
||||
2. **尊重意图**:优化是为了更好地实现用户意图,而非改变意图
|
||||
3. **适度分析**:避免过度解读,关注明确可推断的内容
|
||||
4. **坦诚直接**:发现问题直接指出,不回避冲突
|
||||
5. **追问确认**:对于歧义内容,宁可追问也不猜测
|
||||
Reference in New Issue
Block a user