# Automate Task

> 当用户想把某个岗位或流程自动化，需要把宏大目标拆解为具体可执行任务时使用。 用户在说"替代XX岗位"、"全自动"、"AI取代"、"把X工作交给AI"时激活。 不适用于: 岗位本身只有单一不可拆分的任务、需要整体流程自动化的场景、创意型工作。

- Skill: `kangarooking/automate-task` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add kangarooking/automate-task`
- Raw SKILL.md: https://api.skillmd.com/api/skills/kangarooking/automate-task/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Productivity
- Author: kangarooking (https://skillmd.com/u/kangarooking)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/kangarooking/automate-task

---


## Source Metadata

Original cangjie-skill frontmatter from the distillation run:

```yaml
name: automate-task
description: |
  当用户想把某个岗位或流程自动化，需要把宏大目标拆解为具体可执行任务时使用。
  用户在说"替代XX岗位"、"全自动"、"AI取代"、"把X工作交给AI"时激活。
  不适用于: 岗位本身只有单一不可拆分的任务、需要整体流程自动化的场景、创意型工作。
source_book: 《给所有人的AI入门课》 吴恩达 (Andrew Ng)
source_chapter: p14, p13
tags: [task-decomposition, automation, scope, project-selection]
related_skills:
  - slug: cross-functional-brainstorming
    relation: composes-with
  - slug: one-second-rule
    relation: depends-on
  - slug: ml-feasibility
    relation: depends-on
```

# 自动化任务而非岗位 — 任务分解框架

## R — 原文 (Reading)

> "我认为更应关注自动化任务而非岗位...通过分析员工执行的所有任务，并筛选出一项，可帮助选择近期最具潜力的自动化项目。"
>
> — 吴恩达, p14

---

## I — 方法论骨架 (Interpretation)

媒体叙事常说"AI会取代工作"——但这是错误的分析粒度。
任何岗位都不是单一任务，而是由多个任务组成的集合。有些任务容易自动化（分类、路由、检测），有些任务很难（共情、创意、复杂判断）。
试图"自动化一个岗位"是一个模糊且难以执行的目标；但"自动化岗位中的某一个具体任务"是清晰且可实现的。
这个框架的操作方式是：先列出某个岗位的所有任务，然后逐一评估哪些任务满足自动化条件（简单概念 + 有数据），最后挑出最有价值的一项作为项目切入点。
它把"AI取代人"的焦虑叙事，转化为"AI辅助具体任务"的建设性行动。

---

## A1 — 书中的应用 (Past Application)

### 案例 1: 呼叫中心客服
- **问题**: 如何用AI改进客服工作
- **方法论的使用**: 岗位 = 客服；任务 = 接听电话、分类邮件、处理退款、解答常见问题...选择"分类邮件"作为切入点
- **结论**: 邮件分类是简单任务且有历史数据，适合作为第一个自动化项目
- **结果**: 从"取代客服"的宏大目标，变成"自动分类邮件"的具体项目

### 案例 2: 放射科医生
- **问题**: 如何用AI帮助放射科
- **方法论的使用**: 岗位 = 放射科医生；任务 = X光片解读、与患者沟通、培训实习生、撰写报告...选择"X光片解读"作为切入点
- **结论**: 读片是核心任务且技术上可行，但不意味着AI能取代整个放射科医生岗位
- **结果**: 医学影像AI定位为"辅助读片工具"而非"替代医生"

---

## A2 — 触发场景 (Future Trigger) ★

### 用户会在什么情境下需要这个 skill?

1. 管理者说"我们想用AI取代X岗位"，需要引导到更具体、更可行的方向
2. 团队在讨论AI对某个角色的影响，需要结构化分析框架
3. 项目范围过大，需要拆解成可执行的小项目
4. 有人提出"全自动"目标，需要帮助设定更现实的期望

### 语言信号 (用户的话里出现这些就应激活)

- "替代XX岗位"
- "全自动"
- "AI取代"
- "把X工作交给AI"
- "让AI做X的工作"
- "不再需要X"

### 与相邻 skill 的区分

- 与 `cross-functional-brainstorming` 的区别: 跨职能头脑风暴是"谁来参与创意发现"，任务分解框架是"有了方向后如何具体拆解"。
- 与 `one-second-rule` 的区别: 一秒法则判断单个任务是否可行，任务分解是先把岗位拆成多个任务再逐一判断。
- 与 `ml-feasibility` 的区别: 双因素框架评估单个项目的可行性，任务分解是在评估之前先完成拆解。

---

## E — 可执行步骤 (Execution)

当 skill 被激活后, agent 应按以下步骤执行:

1. **列出目标岗位的所有任务**
   - 向用户提问："这个岗位/角色每天要做哪些事情？请列出所有能想到的任务。"
   - 完成标准: 用户能列出至少5-10个具体任务（如"回复客户邮件"、"审核发票"、"安排会议"）

2. **逐一评估每个任务**
   - 对每个任务提问：
     - "这个任务人类能做多快？一秒内能判断吗？"（参考 one-second-rule）
     - "有历史数据可以用于训练吗？"（参考 ml-feasibility）
     - "自动化这个任务能带来多大价值？"
   - 完成标准: 每个任务都有"概念简单性"、"数据可用性"、"业务价值"三个维度的评估

3. **选择最优任务作为项目范围**
   - 建议用户选择"简单 + 有数据 + 高价值"的任务作为第一个自动化项目
   - 完成标准: 用户明确了一个具体的、可执行的任务作为项目范围，而非整个岗位

---

## B — 边界 (Boundary) ★

### 不要在以下情况使用此 skill

- 岗位本身只有一个不可再拆分的任务（极少见，但存在）
- 所谓的"任务"实际上就是整个工作的全部内容
- 自动化单个任务不能创造独立价值（如只做半自动化，反而增加人工负担）
- 用户只是想了解AI对就业的影响，而非真的要做自动化项目

### 作者在书中警告的失败模式

- 选了一个技术上可行但业务价值很低的任务——自动化后省不了多少成本
- 忽略了任务之间的依赖关系——自动化一个任务可能导致下游流程断裂
- 过度简化任务定义——"回复邮件"可能包含多种完全不同的子类型

### 作者的盲点 / 时代局限

- 假设任务是独立的——现实中任务之间有大量上下文传递和依赖关系，拆解后可能丢失重要信息
- 未讨论"任务粒度"问题——同一个任务可以粗拆也可以细拆，粒度选择会影响可行性判断
- 方法论偏向"保守"（只选一个任务）——在资源充足的情况下，有时并行推进多个任务更高效
- LLM 时代，一些原本需要多任务协作的工作可能被端到端模型整体解决

### 容易混淆的邻近方法论

- 与"流程再造(BPR)"的区别: 流程再造是重新设计整个流程，任务分解是用AI替代流程中的某个环节
- 与"RPA(机器人流程自动化)"的区别: RPA 是规则驱动的任务自动化，本框架讨论的是AI/ML驱动的智能任务自动化

---

## 相关 skills
- **cross-functional-brainstorming** (composes-with): 头脑风暴确定方向后,用任务分解框架拆解具体任务
- **one-second-rule** (depends-on): 对每个拆解出的任务,用一秒法则判断可行性
- **ml-feasibility** (depends-on): 任务分解后,用双因素框架评估每个任务的数据可用性

---

## 审计信息

- **验证通过**: V1 ✓ / V2 ✓ / V3 ✓
- **测试通过率**: 待测试
- **蒸馏时间**: 2026-06-29