| name | automate-task |
| description | 当用户想把某个岗位或流程自动化，需要把宏大目标拆解为具体可执行任务时使用。
用户在说"替代XX岗位"、"全自动"、"AI取代"、"把X工作交给AI"时激活。
不适用于: 岗位本身只有单一不可拆分的任务、需要整体流程自动化的场景、创意型工作。
|
Source Metadata
Original cangjie-skill frontmatter from the distillation run:
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?
- 管理者说"我们想用AI取代X岗位"，需要引导到更具体、更可行的方向
- 团队在讨论AI对某个角色的影响，需要结构化分析框架
- 项目范围过大，需要拆解成可执行的小项目
- 有人提出"全自动"目标，需要帮助设定更现实的期望
语言信号 (用户的话里出现这些就应激活)
- "替代XX岗位"
- "全自动"
- "AI取代"
- "把X工作交给AI"
- "让AI做X的工作"
- "不再需要X"
与相邻 skill 的区分
- 与
cross-functional-brainstorming 的区别: 跨职能头脑风暴是"谁来参与创意发现"，任务分解框架是"有了方向后如何具体拆解"。
- 与
one-second-rule 的区别: 一秒法则判断单个任务是否可行，任务分解是先把岗位拆成多个任务再逐一判断。
- 与
ml-feasibility 的区别: 双因素框架评估单个项目的可行性，任务分解是在评估之前先完成拆解。
E — 可执行步骤 (Execution)
当 skill 被激活后, agent 应按以下步骤执行:
-
列出目标岗位的所有任务
- 向用户提问："这个岗位/角色每天要做哪些事情？请列出所有能想到的任务。"
- 完成标准: 用户能列出至少5-10个具体任务（如"回复客户邮件"、"审核发票"、"安排会议"）
-
逐一评估每个任务
- 对每个任务提问：
- "这个任务人类能做多快？一秒内能判断吗？"（参考 one-second-rule）
- "有历史数据可以用于训练吗？"（参考 ml-feasibility）
- "自动化这个任务能带来多大价值？"
- 完成标准: 每个任务都有"概念简单性"、"数据可用性"、"业务价值"三个维度的评估
-
选择最优任务作为项目范围
- 建议用户选择"简单 + 有数据 + 高价值"的任务作为第一个自动化项目
- 完成标准: 用户明确了一个具体的、可执行的任务作为项目范围，而非整个岗位
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
