「哪些活能交给 Agent」，用「难不难」回答是错的。 两个可靠判据：可验证性 2 以上、影响面 2 以下。十条任务里六条能交。 交出去的是七成时间，不是七成责任；验收也要一起交出去。
边界守住之后的第二个问题：剩下的活怎么分。 这一节的答案不是「看难不难」，是两个能打分的判据。 Demo 给十项常见任务各打一次分，再真跑一件噪声工作：二十个文件统一表头和缩进， 看人手和脚本各漏几个。
一、什么算噪声工作
噪声工作的定义不是「简单」，是「重复且结果可判定」。 它可能很繁琐，但每次的判断标准都一样。
| 分值 | 可验证性 | 影响面 |
|---|---|---|
| 3 | 跑一条命令就知道对错 | 只影响本地 |
| 2 | 能看出大概，要人扫一眼 | 影响一个模块 |
| 1 | 要人逐行读才敢说对 | 影响线上 |
| 0 | 对错本身就没定义 | 影响数据和用户 |
Demo 真跑的那件噪声工作是：二十个文件，每个加统一表头、缩进从两空格改四空格。 模拟的「人手改」漏了三个文件，脚本全量跑一遍零漏。 「漏三个」是模拟出来的，不是我真去手改二十个。 但它反映的事是真的：重复动作的出错率跟次数正相关，跟难度几乎无关。 改第一个和改第二十个，难度一样，注意力不一样。 更要紧的是第二行：脚本跑完还得有一个 check。 没有 check，漏不漏你也不知道。 交出去的活儿，验收也要一起交出去。
二、什么必须人做
Demo 十项任务两维打分，六项可交、四项要人拿主意。 四项里三项影响面是 3：删无用代码、写迁移脚本、排查线上 500。 这三项的共同点不是「难」，是「错了要回滚数据」。 回滚数据这件事不能交给一个不会承担后果的东西。 第四项「拆分超大文件」不一样：它影响面只有 2，但可验证性是 0。 拆完好不好，没有命令能判——所以也不该交。 这两条判据各自能挡住一半，合起来才够用。 只看影响面，会漏掉「拆分文件」这种改坏了也看不出来的活； 只看可验证性，会漏掉「删代码」这种一跑就过、但删错了要回滚的活。 还有一类容易被忽略：需求本身没定义的活。 「这个接口该返回什么」不是可验证性问题，是「对错还没定义」。 这类要先人定，定完才谈得上交。
三、分工的比例
Demo 里那张比例表想说的是一件事：交出去的是七成时间，不是七成责任。
| 类别 | 项数 | 占用的时间 | 占用的责任 |
|---|---|---|---|
| 噪声工作 | 6 | 约七成 | 很小 |
| 关键判断 | 4 | 约三成 | 几乎全部 |
删代码、写迁移、排查线上，这几件事花的时间不多，但错了要人担。 所以「交出去多少」这个问法本身有问题——时间可以交，责任不能交。 时间占比七三开是我按常见后端项目估的，不同团队差别很大。 能看的是两列不成比例这件事：时间少的那一列，责任重得多。 分工比例怎么定？一个可用的起点是「噪声全交，判断全留」，然后按两个信号微调。
| 信号 | 往哪边调 |
|---|---|
| 同一件事这周做了第三次 | 往 Agent 那边挪 |
| 错了要回滚数据 | 往人这边挪，且加闸门 |
| 验收能写成一条命令 | 往 Agent 那边挪 |
| 验收要开会讨论 | 留在人这边 |
第一行最实用：一件事做到第三次，说明它不是偶发，该固化了。 这跟下一节的「固化三件事」是同一件事的两面——分工解决「谁做」，固化解决「怎么做才不靠人」。
四、动手 Demo：让 Agent 做噪声工作，让人做关键判断
十项常见任务，按可验证性和影响面各打一次分，看哪几项能交。 再真跑一件噪声工作：二十个文件统一表头和缩进。 打分是我打的，但那件噪声工作是真跑的。
TASKS = [
("批量调整 import 顺序", 3, 1),
("补单元测试骨架", 2, 2),
("删无用代码", 1, 3),
("写数据库迁移脚本", 1, 3),
("排查线上 500", 0, 3),
("拆分超大文件", 0, 2),
# …共十项，字段是「任务、可验证性、影响面」
]
for name, ver, imp in TASKS:
ok = ver >= 2 and imp <= 2
print(name, "可交" if ok else "人定")
实跑输出：
--------------------------------------------------------------------
让 Agent 做噪声工作，让人做关键判断
--------------------------------------------------------------------
「哪些活能交给 Agent」这个问题，用「难不难」回答是错的。
两个更可靠的判据：能不能自动验证，错了影响多大。
① 两个判据：可验证性、影响面
--------------------------------------------------------------------
| 分值 | 可验证性 | 影响面 |
|---|---|---|
| 3 | 跑一条命令就知道对错 | 只影响本地 |
| 2 | 能看出大概，要人扫一眼 | 影响一个模块 |
| 1 | 要人逐行读才敢说对 | 影响线上 |
| 0 | 对错本身就没定义 | 影响数据和用户 |
规则很简单：可验证性 2 以上、影响面 2 以下，可以交出去；影响面 3 的一律人来做决定。
② 十项任务各打一次分
--------------------------------------------------------------------
| 任务 | 可验证 | 影响面 | 归谁 |
|---|:---:|:---:|---|
| 批量调整 import 顺序 | 3 | 1 | 可交 |
| 补单元测试骨架 | 2 | 2 | 可交 |
| 删无用代码 | 1 | 3 | 人定 |
| 升级依赖小版本 | 2 | 2 | 可交 |
| 写数据库迁移脚本 | 1 | 3 | 人定 |
| 统一日志格式 | 3 | 1 | 可交 |
| 排查线上 500 | 0 | 3 | 人定 |
| 补 CHANGELOG | 3 | 0 | 可交 |
| 拆分超大文件 | 0 | 2 | 起草 |
| 生成接口文档 | 3 | 1 | 可交 |
十项里 6 项可以直接交，4 项要人拿主意。
注意「删无用代码」和「拆分超大文件」的分值：前者可验证性只有 1（删了才发现有人反射调用），
后者影响面 2 但可验证性 0（拆完好不好，没有命令能判）。这两项都不该交。
③ 噪声工作真跑一遍：二十个文件统一表头和缩进
--------------------------------------------------------------------
二十个文件，每个一行函数。任务是把表头统一加上、缩进从两空格改四空格。
| 做法 | 漏表头 | 漏缩进 | 结论 |
|---|---|---|---|
| 人手改二十个 | 3 个 | 3 个 | 改到第 12 个就开始走神 |
| 做法 | 漏表头 | 漏缩进 | 结论 |
|---|---|---|---|
| 脚本全量跑一遍 | 0 个 | 0 个 | 同一个动作重复二十次不掉精度 |
「人手改漏三个」是模拟出来的，不是我真去手改二十个文件。
但它反映的事是真的：重复动作的出错率跟次数正相关，跟难度几乎无关。
更要紧的是第二行——脚本跑完还是要有这个 check。没有 check，漏不漏你也不知道。
交出去的活儿，验收也要一起交出去。
④ 那件噪声工作到底值多少时间
--------------------------------------------------------------------
| 类别 | 项数 | 占用的时间 | 占用的责任 |
|---|:---:|:---:|:---:|
| 噪声工作 | 6 | 约七成 | 很小 |
| 关键判断 | 4 | 约三成 | 几乎全部 |
这张表想说的是：交出去的是七成的时间，不是七成的责任。
删代码、写迁移、排查线上，这几件事花的时间不多，但错了要人担。
! 时间占比七三开是我按常见后端项目估的，不同团队差别很大。能看的是两列不成比例这件事。
⑤ 分工比例怎么定
--------------------------------------------------------------------
一个可用的起点是「噪声全交，判断全留」，然后按两个信号微调。
| 信号 | 往哪边调 |
|---|---|
| 同一件事这周做了第三次 | 往 Agent 那边挪 |
| 错了要回滚数据 | 往人这边挪，且加闸门 |
| 验收能写成一条命令 | 往 Agent 那边挪 |
| 验收要开会讨论 | 留在人这边 |
第一行是最实用的：一件事做到第三次，说明它不是偶发，
该固化成流程了——这跟 14.4 的「固化三件事」是同一件事的两面。
表里最容易看错的不是「删无用代码」，是「拆分超大文件」。 前者影响面 3，一眼就知道不该交；后者影响面只有 2，看着像能交，但可验证性是 0—— 拆完好不好，没有命令能判。 「补单元测试骨架」和「升级依赖小版本」都是二二，落在可交这边。 它们的共同点是「能看出大概」：测试骨架跑一遍就知道有没有语法错，依赖升级跑一遍测试就知道坏没坏。 那段噪声工作的实测很干脆：人手漏三个，脚本零漏。 但真正值钱的是第二行——脚本跑完还有一个 check。 这个 check 才是「能交」的依据，不是「脚本很稳」这个感觉。 比例表里「占用的责任」一列是重点。 六项噪声工作占了七成时间，但责任很小；四项关键判断占三成时间，责任几乎全部。 所以「交出去七成」这个说法，交的是时间。 最后一列那个「这周做了第三次」是可以数的。 它把「该不该固化」从感觉变成了计数——数到三就固化，不用讨论。
30 秒实验
- 把你手上正在做的事列成十项，各打两个分。 打完你会发现「难」和「能交」几乎是两件不相干的事。
- 找一件你这周做了第三次的事，把它写成一条命令。 写不出来，说明它还没稳定到可以交。
- 给交出去的活配一个 check。 没有 check 的活，等于没交——因为你不知道它做对没有。
常见误区
- 「简单的活交给它，难的自己做。」 简单但不可验证的活（比如拆文件）交给它，比难但可验证的活更危险。 判据是「能不能验」，不是「难不难」。
- 「交出去了就不用管了。」 交出去的活还需要一个 check。 demo 里脚本零漏，但那个零是 check 数出来的，不是感觉出来的。
- 「影响面小就可以随便交。」 可验证性是另一半。 影响面 1 但不可验证的活，改坏了你也不知道。
自测三问（点开对答案）
1. 为什么「拆分超大文件」不该交？ —— **因为它可验证性是 0：拆完好不好，没有命令能判。** **影响面 2 看着不高，但没有验收标准，交出去等于放弃检查。** 2. 「交出去七成时间，不是七成责任」这句话的实际含义是什么？ —— **具体动作是：活可以交，验收和回滚方案不能交。** **所以你交出去的时候，要同时留下一个能判断对错的命令。** 3. 为什么「这周做了第三次」是个好信号？ —— **因为它可数，而且不依赖主观判断。** **做到第三次说明它不是偶发，值得固化成命令。**分工定完之后，接下来是固化。一次成功怎么变成长期可复用，下一节讲折旧。
- ☐ （本篇完，下一篇 14.4 从一次成功到长期可复用的工作流）