🧠 第二章 能力培养
📄 一句话概括

一句「让客服机器人更聪明一点」,拆完变成 6 个子任务、13.5 人日,每条都有量化验收标准。 拆不动,任务就变成「改到老板满意为止」。

📝 本节和前面几节的关系

上一节收尾在「AI 是什么」,这一节开始讲「每天干什么」。

一、模糊需求为什么拆不动

「更聪明」不是指标,「答非所问」不是定义。 两句话都没法直接执行,所以团队会陷入一个循环:改一版、老板说不像、再改一版。 拆解的目标是把这两句话换成四样东西:数据从哪来、指标叫什么、验收看哪个数、做多久。 四样齐了,任务才可执行、可结项。 Demo 把它拆成六步:定义「答非所问」、建评测集、定指标、补知识库、调检索、上线灰度。 总工时 13.5 人日,六条都有量化验收。

二、六步里哪一步最容易被跳过

第二步「建评测集」最容易被跳过,因为它是纯投入、看不见效果。 但没有固定的测试集,每次改动都无法比较——只能靠感觉。 第一步「定义答非所问」也一样:抽 200 条真实对话人工标对错,还要算标注一致性(≥ 0.8)。 一致性不达标,说明定义本身还模糊,得回去改定义,不是继续标。 这两步加起来 3 人日,占整个任务的 22%。看着「没产出」,但它们决定了后面所有工作有没有方向。 顺带说一个反直觉的:调检索只花 2 人日,补知识库花 3 人日。 很多团队一上来就调模型参数,其实大部分「答非所问」是知识库缺条目。

三、验收标准怎么写

要写「数」,不写「感觉」。 比如「答对率提升 ≥ 5 个点」「转人工率不升」「抽检 20 条全对」——这三条都能当场核。 还要写「不做什么」。比如「不改模型结构」「不动前端交互」——范围不划清,任务会无限膨胀。 最后要写「谁拍板」。灰度一周后数据出来了,谁说「可以全量」?这个角色不定,数据再好也发不出去。

四、动手 Demo:一句模糊需求拆成六条可验收任务

拿一句真实感很强的需求(「让客服机器人更聪明,客户老说它答非所问」),拆成六个子任务, 每个写清怎么做、多少工时、怎么算做完,最后合计工时并检查「有几条是可验收的」。

tasks = [
    (u'定义答非所问', u'抽 200 条对话人工标对错', u'2 人日', u'一致性 ≥ 0.8'),
    (u'建评测集',   u'分层抽 100 条做固定测试集', u'1 人日', u'覆盖 ≥ 8 个意图'),
    ...]

实跑输出:

--------------------------------------------------------------------
把一句模糊需求拆成能验收的任务
--------------------------------------------------------------------
  子任务             怎么做                                     工时       验收标准
  --------------------------------------------------------------------------------------------
  定义「答非所问」   抽 200 条真实对话,人工标「答对/答错」     2 人日     标注一致性 ≥ 0.8
  建评测集           从标注里分层抽 100 条做固定测试集          1 人日     覆盖 ≥ 8 个意图
  定指标             主指标用「答对率」,辅指标用「转人工率」   0.5 人日   两边都写进验收单
  补知识库           把答错的 60 条对应的知识条目补齐           3 人日     补齐后抽检 20 条全对
  调检索             相似度阈值从 0.75 扫到 0.55                2 人日     答对率提升 ≥ 5 个点
  上线灰度           10% 流量跑一周,对比转人工率               5 人日     转人工率不升

  原始需求                 让客服机器人更聪明一点,客户老说它答非所问
  拆成                     6 个子任务
  合计工时                 13.5 人日
  可验收的条数             6 / 6(每条都有量化标准)

  原始需求里没有一个词能直接执行:「更聪明」不是指标,「答非所问」不是定义。
  拆完才有四样东西:数据从哪来、指标叫什么、验收看哪个数、做多久。
  这四样缺一样,任务就会变成「改到老板满意为止」——那是无底洞。

  工时是我给的估算,不是报价。它在这里的作用是让「一个月能不能做完」有得算。

六条任务、合计 13.5 人日,六条全都有量化验收标准(6/6)。 工时是我给的估算,不是报价。 它的作用是让「一个月能不能做完」有得算——没有工时估算,排期就只能拍脑袋。 表里最容易被砍的是「建评测集」(1 人日),最容易被低估的是「补知识库」(3 人日, 还要抽检 20 条全对)。 「上线灰度 5 人日」看着不像技术活,但它是唯一能验证「真用户有没有变满意」的一步。 前面五步验的都是离线指标。

30 秒实验

  1. 把你手上一个模糊需求按这四样(数据、指标、验收、工时)拆一遍。
  2. 想一想:为什么「转人工率」比「答对率」更难造假?
  3. 给「补知识库」这一步补一条验收标准,要求能当场核。

常见误区

  1. 「先做起来再说」——没有评测集,改十版也说不清哪版好。
  2. 「指标定得越高越好」——定到做不到,团队会开始改口径。
  3. 「验收就是老板点头」——那是主观验收,会无限返工。
自测三问(点开对答案) 1. 模糊需求要拆成哪四样东西? —— 数据从哪来、指标叫什么、验收看哪个数、做多久。 2. 六步里哪一步最容易跳过、为什么不能跳? —— 建评测集;没有固定测试集,改动之间无法比较。 3. 验收标准要写成什么样? —— 写成能当场核的数,并写清不做什么、谁拍板。

职责清楚了,下一节看这些活分布在哪些行业里。

相关笔记