一、为什么必须先拆

大部分人写技能是这么开始的：打开一个空白文件，想一句写一句。 写到一半发现「这里还要先做一件事」，于是回头补；补完发现前面那步的产出格式不对，再改。 这种写法最后也能写出来，但正文是乱的，因为你从来没在脑子里把顺序排清楚。 拆任务就是排顺序。排清楚了，技能正文只是把顺序抄下来。 反过来，顺序没排清楚，正文写得再漂亮也是糊的。

二、任何任务无非拆成三类操作

拆到底，每个动作都落在三类里的一类。 取：拿到原料。读文件、查库、调接口、翻日志、看聊天记录，全是这一类。 算：把原料变成结论。分组统计、比对差异、判断主次、找出异常。 写：把结论落成产出。写报告、改代码、生成图表、拟一封邮件。 这三类的划分标准不是「难不难」，是谁更擅长。 取和算，脚本擅长：有唯一答案，能跑出确定的结果。 写，模型擅长：没有唯一答案，要的是「说得像人话」。 所以拆完的第一步收获就有了：你能看出这个任务里有多少活可以交给脚本。

三、拆完看自然就出来了

拆完不用急着写技能。先横着看一眼这张表，三件事自己会浮出来。 第一件，哪几步是重复的。三个任务里都有「读 CSV」，那这一步就该抽成一个脚本，别写三遍。 第二件，哪几步最容易错。错得多的那一步，就是技能正文里要写死边界的那一步。 第三件，哪几步没法检查。「判断这个数算不算异常」——没法检查，那就要在技能里给出判据。 这三件事，比「怎么写」重要得多。它们决定了技能写出来能不能用。 写技能的顺序应该是：先拆、再看、最后写。跳过前两步，第三步就是抄一遍模糊的感觉。

四、拆得越清，后面越省力

拆得细的好处，在写正文的时候最明显。 粗拆成三步「读数据、分析、写报告」，写进技能只能是一句话，模型看了也不知道从哪下手。 细拆成五步「读 CSV、算环比、找异常、画图、写结论」，每一步都能对应一个动作或一个产出。 更关键的是：细拆之后，每一步都能被检查。 「读 CSV」做完，能检查行数对不对；「算环比」做完，能检查数算得对不对。 「分析」做完，你检查什么？无从下手。 所以拆的粒度有一个很硬的标准：拆到这一步做完，我能一眼看出对不对为止。 到了这个粒度就不用再往下拆。再细就变成写代码了，那是脚本的事。

五、一个反例：拆得太细

拆太细也有代价。把「读 CSV」拆成「打开文件、跳过表头、切分每行、转成整数」—— 这就已经不是技能该管的事了，这是脚本本身。 技能里写这种粒度，等于把代码抄进说明文档。改一处要改两处，而且两边会不同步。 判断标准还是那一条：能一眼看出对不对的，就停在那里。 「读 CSV 得到 12 行」能检查，「切分每行」检查不了——那是实现细节。

六、动手 Demo：把三个任务拆成操作，看三类各占多少

这一段拿三个日常任务真拆一遍：写周报、给函数补单测、出销售分析报告。 每个拆成五步，标上取、算、写，然后统计比例、比较粒度。

TASKS = [
    ('写一份周报', [
        ('翻这周的提交记录', '取'),
        ('归并成三到五件事', '算'),
        ('按三段式写出来', '写'),
    ]),
    # ...另外两个
]

实跑输出：

--------------------------------------------------------------------
把三个任务拆成操作，看三类各占多少
--------------------------------------------------------------------


  ① 三类操作：取、算、写
  --------------------------------------------------------------------
| 类别 | 干什么 | 典型动作 | 谁更合适 |
|---|---|---|---|
| 取 | 拿到原料 | 读文件、查库、调接口、看日志 | 脚本擅长 |
| 算 | 把原料变成结论 | 分组统计、比对差异、判断主次 | 看情况 |
| 写 | 把结论落成产出 | 写报告、改代码、生成图表 | 模型擅长 |

  任何任务拆到底，都会落到这三类里。拆不出来的，通常是还没想清楚要什么。
  ! 这个三分法是为了「分工」才这么切的，不是唯一的切法。

  ② 三个任务逐个拆
  --------------------------------------------------------------------
  写一份周报（5 步）
    1. [取] 翻这周的提交记录
    2. [取] 翻聊天记录里的待办
    3. [算] 归并成三到五件事
    4. [算] 判断哪件最值得说
    5. [写] 按三段式写出来
  给一个函数补单测（5 步）
    1. [取] 读函数签名与文档
    2. [算] 找出正常输入与边界输入
    3. [写] 写测试用例
    4. [取] 跑一遍看红绿
    5. [算] 补齐漏掉的分支
  出一份销售分析报告（5 步）
    1. [取] 读 CSV
    2. [算] 算同比环比
    3. [算] 找异常点
    4. [写] 画图
    5. [写] 写结论与建议

| 类别 | 步数 | 占比 |
|---|---:|---:|
| 取 | 5 | 33% |
| 算 | 6 | 40% |
| 写 | 4 | 27% |

  三个任务一共 15 步，取 5、算 6、写 4。
  「写」的占比看着不高，但它是唯一一类必须由模型做的——
  另外两类都能写成脚本，只有「把结论说成人话」这件事没法硬编码。

  ③ 拆得粗和拆得细，差在哪
  --------------------------------------------------------------------
| 粒度 | 步数 | 每步长什么样 |
|---|---:|---|
| 粗 | 3 | 读数据 / 分析 / 写报告 |
| 细 | 5 | 读 CSV / 算同比环比 / 找异常点 / 画图 / 写结论与建议 |

  粗的三步，每一步里面都藏着好几件事，写进技能就是一句含糊的话。
  细的五步，每一步都能对应一个动作或一个产出，写进技能才能被检查。
  ! 拆到「这一步做完，我能看出对不对」为止，就不用再往下拆了。

  ④ 拆完看一件事：哪几步能交给别人
  --------------------------------------------------------------------
| 任务 | 取 | 算 | 写 |
|---|:---:|:---:|:---:|
| 写一份周报 | 2 步 | 2 步 | 1 步 |
| 给一个函数补单测 | 2 步 | 2 步 | 1 步 |
| 出一份销售分析报告 | 1 步 | 2 步 | 2 步 |

  这三个任务里，「取」只占两到四成——大部分步骤要判断，不是搬运。
  所以它们的技能正文，重点不在「怎么读文件」，在「怎么判断」。
  反过来，批量裁图那种任务，取和算能占到九成，正文写成一张命令表就够。
  ! 看这个比例，就知道技能正文该长什么样：搬运多就写命令，判断多就写判据。

第一张表是三类操作的定义：取是拿原料，算是变结论，写是落产出。 「谁更合适」那一列是全篇的重点：取和算归脚本，写归模型。 第二段把三个任务逐个拆开，一共 15 步：取 5、算 6、写 4。 算占了四成，是最大的一块——这符合直觉，日常任务里「判断」总是最多的。 第三段比粒度：粗拆 3 步（读数据、分析、写报告），细拆 5 步。 第四段看「取」占多少：三个任务里都只占两到四成，说明大部分步骤要判断，不是搬运。 所以它们的技能正文重点不在「怎么读文件」，在「怎么判断」。 这个结论直接决定正文该写什么——搬运多就写命令，判断多就写判据。

30 秒实验

1. 挑一件你每周都做的事，拆成五步以内，标上取算写。标不出来的步骤，说明你还没想清楚。
2. 把拆出来的步骤横着看一遍：哪一步最容易错？那一步就是技能正文要写死边界的地方。
3. 找出一个「做完没法检查」的步骤。它要么该拆细，要么该在技能里给出判据。

常见误区

1. 不拆直接写。想到哪写到哪，最后正文顺序是乱的，读的人（和模型）都不知道该先做哪一步。
2. 拆到实现细节。「打开文件、跳过表头、切分每行」——这是代码，不是技能。 技能管到「读出一个 12 行的表」这一层就够。
3. 只拆「做什么」，不标「谁来做」。 不标的话，你就会把「算环比」这种活也交给模型，然后每次都要自己核一遍数。

下一篇回答拆完之后的下一个问题：这件事到底该不该做成技能。三个问题加四个限制。

• ☐ （本篇完，下一篇 3.2 要不要做成技能）

相关笔记

• description：技能被选中的关键机制
• 要不要做成技能
• 编程原理 · 索引
• 🧩 Skill提效实战 · 索引