---
name: requirement-translator
description: |
  需求转译 - 将主观、模糊、口语化的用户需求翻译为结构化、精确的AI可执行规格。
  This skill should be used when the user gives a vague, subjective, or ambiguous requirement,
  or when the user explicitly requests requirement translation.
  Triggers: 需求转译, 翻译需求, 明确需求, 细化需求, "帮我分析一下这个需求", "这个需求不够清楚"
---

# 需求转译 (Requirement Translator)

将主观模糊的用户需求翻译为结构化、精确的 AI 可执行规格。

## 触发条件

以下任一情况触发本 Skill：
- 用户输入的需求存在歧义、模糊描述或纯主观判断（如"好看""好用""快一点"）
- 用户明确要求"需求转译""翻译需求""明确需求""细化需求"
- 用户给出需求但缺少关键细节（技术栈、范围、验收标准、边界条件）
- 用户说出类似"做一个好看的 XX""帮我优化一下 YY""实现一个 ZZ 功能"等目标不明确但可推断的指令

## 工作流程

### Phase 1 — 需求分析

从原始需求中提取：
1. **核心目标**: 用户真正想达成什么？
2. **模糊点**: 哪些表述存在歧义或可多解？
3. **缺失信息**: 缺少哪些关键参数（技术栈、范围、约束等）？
4. **隐含假设**: 用户可能默认了什么但没有明说？

### Phase 2 — 翻译输出

将需求转译为以下结构化格式。若某章节无内容，注明「无」而非省略。

```
## 需求规格书

### 1. 目标概述
[一句话描述核心目标，点明要解决的问题和预期结果]

### 2. 功能需求
- F1: [具体可执行的功能描述]
- F2: [具体可执行的功能描述]

### 3. 技术约束
- T1: [技术栈 / 平台 / 兼容性要求]
- T2: [性能 / 安全 / 规模约束]

### 4. 设计约束
- D1: [视觉风格 / 交互模式 / 品牌约束]
- D2: [布局 / 响应式 / 无障碍要求]

### 5. 验收标准
- AC1: [可客观验证的完成标准，含具体数值或状态]
- AC2: [可客观验证的完成标准]

### 6. 边界条件与异常处理
- E1: [异常场景及预期处理方式]
- E2: [极端输入 / 空状态 / 错误状态处理]

### 7. 优先级
- P0 必须: [核心不可妥协的需求]
- P1 应该: [重要但可后续迭代]
- P2 可选: [锦上添花，可省略]
```

### Phase 3 — 执行建议

在转译结果后附加：
- **推荐方案**: 推荐的技术路线及理由（1-2 句）
- **风险提示**: 潜在坑点、技术难点或不确定因素
- **实施顺序**: 建议的分步执行路径

## 工作原则

1. **不全知则问**: 关键信息缺失且无法合理推断时，列出待确认问题列表，不猜测
2. **合理推断**: 可基于上下文和行业惯例推断的非关键信息，直接采用并标注 `[推断]`
3. **可执行性优先**: 每个需求项必须是可执行、可验证的，避免"做好""做对"等不可验证表述
4. **保持意图**: 不强行改变用户原始意图，只做精确化和结构化
5. **推断标注**: 所有推断内容用 `[推断]` 标记，方便用户审查和纠正
6. **中文输出**: 始终用中文输出转译结果