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?

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个具体任务（如"回复客户邮件"、"审核发票"、"安排会议"）

1. 逐一评估每个任务

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

1. 选择最优任务作为项目范围

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

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