# Work Skill 分析 Prompt

## 任务

你将收到 **{name}** 的原材料（文档、消息、邮件等）。
从中提取他的工作能力与方法，用于构建 Work Skill。

**原则：只提取工作相关内容，忽略闲聊。不要推断，有依据才写，没有就标注"原材料不足"。**

---

## 通用提取维度（所有职位适用）

### 1. 负责范围

从原材料中识别：
- 他负责的系统/模块/业务线/产品
- 他维护的文档（接口文档、wiki、runbook...）
- 他的职责边界（哪些是他的，哪些不是）
- 他频繁提到的项目代号、业务术语

```
输出格式：
负责领域：[描述]
核心系统：[列表]
维护文档：[列表]
边界：[他管什么/不管什么]
```

### 2. 工作流程

从任务描述、会议纪要中提取：
- 接到任务的处理步骤
- 写方案/文档的结构习惯
- 如何做进度管理和 deadline 处理
- 如何处理异常/紧急情况

```
输出格式：
接任务：[步骤]
写方案：[结构描述]
异常处理：[流程]
```

### 3. 输出格式偏好

- 用表格/列表/流程图/纯文字
- 结论前置还是娓娓道来
- 文档详细程度（极简/适中/详尽）
- 回复/邮件风格

```
输出格式：
文档风格：[描述]
详细程度：[极简/适中/详尽]
```

### 4. 经验知识库

他明确表达的经验判断、踩过的坑、技术观点（直接引用原话）：

```
- "[原话或总结]"
- "[原话或总结]"
```

---

## 职位专项提取

根据 {name} 的职位，重点提取对应维度：

---

### 🖥️ 后端工程师 / 服务端工程师

**技术规范**：
- 技术栈（语言、框架、中间件）
- 命名规范（接口路径风格、变量/函数命名）
- 接口设计（返回结构、错误码、分页、幂等）
- 数据库操作偏好（ORM vs 原生 SQL，事务边界）
- 异常处理风格

**Code Review 重点**：
- 他反复提到的 CR 问题（N+1、事务、并发安全...）
- 他的 CR 评论风格（直接/委婉，[block]/[suggest] 分级...）

**部署与运维**：
- 他关注的监控指标
- 线上问题排查步骤
- 变更发布流程

---

### 🌐 前端工程师

**技术规范**：
- 技术栈（框架、状态管理、样式方案）
- 组件拆分原则（什么时候拆，什么时候不拆）
- 性能关注点（首屏、懒加载、bundle 大小...）
- 接口调用和错误处理方式

**工程实践**：
- 代码规范工具（ESLint 规则、Prettier 配置偏好）
- 测试覆盖要求（单测/集成测试态度）
- CR 重点（可访问性/响应式/兼容性关注度）

---

### 🤖 算法工程师 / ML 工程师

**研究与实验**：
- 问题定义方式（如何拆解 ML 问题）
- 实验设计习惯（基线选择、ablation 设计）
- 指标定义偏好（离线指标 vs 在线指标的态度）
- 他常用的模型/方法论

**工程落地**：
- 训练框架偏好
- 模型上线流程
- 数据处理规范

**文档与结论**：
- 实验报告的写法（重结论/重过程）
- 他引用的 paper 或方法论

---

### 📱 产品经理 / 技术产品经理

**需求处理**：
- PRD 结构和详细程度
- 用户故事/需求边界的定义方式
- 如何与研发对齐（评审方式、修改流程）

**决策框架**：
- 优先级排序方法（RICE/MoSCoW/自定义）
- 数据驱动 vs 直觉的比例
- 如何处理需求冲突

**输出物**：
- 他交付的文档类型（PRD/MRD/原型/竞品分析）
- 原型工具偏好
- 数据埋点的参与程度

---

### 🎨 设计师

**设计规范**：
- 使用的设计系统/组件库
- 标注方式和交付规范
- 对 pixel-perfect 的要求程度

**工作流程**：
- 从需求到方案的步骤
- 走查/验收的方式
- 如何处理开发侧的还原度问题

---

### 📊 数据分析师

**分析方法**：
- 常用分析框架（漏斗/同期群/A/B 测试...）
- SQL 风格（简洁/注释详尽）
- 数据可视化偏好（图表类型选择）

**报告风格**：
- 结论 vs 数据的比例
- 对"数据说话"的执行程度
- 如何处理数据异常/口径争议

---

## 输出要求

- 语言：中文
- 没有信息的维度：标注 `（原材料不足，建议追加相关文档）`
- 有原文依据的结论：加引号标注原话
- 输出结果直接用于生成 work.md，要求具体可执行，不要写"可能""倾向于"这类模糊表述
