requirement-translator

需求转译 (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. 中文输出: 始终用中文输出转译结果