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