三个反例：探索性任务、高风险改动、需要人判断的任务。 判断标准只有一条：说不清怎么算做完，就不该直接委派。 Demo 里规则脚本对一个真慢函数命中零处——原因不在语法里。
这一章铺了一整张地图：四扇门、五个档位、值守、本地云端、三个工具。 最后这一节收口：地图上有边界，界外的事别直接委派。 三个反例分别对应三个维度：可验证性、影响面、判断密度。 这一节有点反高潮——前面都在讲「怎么用」，这一节讲「什么时候别用」。 但边界意识比技巧值钱，因为技巧会随工具变，边界不会。
一、探索性任务的反例
「为什么慢」「为什么偶发失败」「这个内存是谁吃的」——这类问题的答案不在已知模式里。
Demo 造了一个真慢的函数，用四条规则去查，命中零处。
四条规则查的是「嵌套循环」「循环里 sleep」「循环里 open」「循环里编译正则」——
全都是已知模式。
真正的原因是一个语义问题：r not in out 里的 out 是列表，一次成员判断要扫一遍，
循环里套一次全扫，就是平方。
换成集合之后，八千行从二百零五毫秒降到一点八毫秒。
这个对比不是「模型不行」的证据，是「规则不行」的证据。
十条规则查不出的东西，一个知道列表查找是线性的人一眼看出。
所以能委派的是「按已知模式找」，不是「找出未知原因」。
一个可操作的分法：先人找方向，再让它按方向找实例。
你判断「可能是判重那儿」，然后让它「把这个模块里所有成员判断列出来」——后半句它能干得很好。
二、高风险改动的反例
三条红线：删数据、改表结构、改权限。 共同点：做错了没有撤销键。
| 操作 | 为什么危险 | 替代做法 |
|---|---|---|
| 删一批文件 | 不进回收站 | 先移到临时目录 |
| 改表结构 | 数据可能已丢 | 先建新表灌一遍 |
| 改权限配置 | 当场生效、影响所有人 | 先在测试环境改 |
但高风险不等于不能委派，等于「要人盯着做」。 这两句话差别很大——前者是「别碰」，后者是「可以碰，但别放手」。 盯的方式很具体：让它先给方案，方案你点头了再动手。 方案里必须包含「出事了怎么恢复」这一条。 写不出恢复方案，就说明这次不该动手。
三、需要人判断的反例
判断密度高的活：设计接口、写对外文案、定取舍。 这类活的特点是没有唯一正确答案，而且错了要返工很久。 判断密度的另一种表现是「每个决定都依赖上一个决定」。 这种链式判断，交给它做会一路错到底——因为它每一步都在猜你想要什么。 Demo 里十五条任务分三堆：可以委派两条、人盯六条、自己做四条。 「自己做」的那四条，可验证性全是 1 分。 这不是巧合——说不清怎么算做完的活，就是不该委派的活。
四、本章小结
这一章铺的地图，收回成一张表：
| 问题 | 答案在哪一节 | 一句话 |
|---|---|---|
| 在哪跟它说话 | 4.1 | 四扇门，差的是上下文入口 |
| 该买哪一档 | 4.2 | 个人看额度，团队看合规 |
| 手机上能干什么 | 4.3 | 收通知、看结论、发任务 |
| 放本地还是云端 | 4.4 | 能不能、划不划算、要不要看 |
| 三个工具治什么病 | 4.5 | 记性、自觉、抢目录 |
| 什么不该委派 | 4.6 | 说不清做完的，别交 |
下一章进第二部分：Harness 四件套。 但在写 AGENTS.md 之前，还有一步更基础的事要做—— 先把仓库变成「能干活的样子」：能一键跑起来、能一键验证。
五、动手 Demo：边界：规则查不出「为什么慢」
这个 Demo 用一个真慢的函数，说明「探索性任务」为什么不能直接委派。 第一步造一个慢函数，真测三档数据量，看增长形状。 第二步用四条规则去查原因，一条都命中不了。 第三步换成集合，再测一遍，看形状变了没有。
SLOW = u'''def dup_count(rows):
out = []
for r in rows:
if r not in out: # out 是列表，一次判断扫一遍
out.append(r)
return len(out)
'''
for n in (1000, 2000, 4000):
rows = list(range(n)) + list(range(n))
t = time.perf_counter()
c = dup_count(rows)
实跑输出：
--------------------------------------------------------------------
边界：规则查不出「为什么慢」
--------------------------------------------------------------------
① 一个真慢的函数
--------------------------------------------------------------------
n= 2000 不重复 1000 用时 12.49 毫秒
n= 4000 不重复 2000 用时 46.62 毫秒
n= 8000 不重复 4000 用时 192.45 毫秒
数据量翻一倍，时间大约翻四倍——这是平方增长的形状。
② 用规则脚本去找原因
--------------------------------------------------------------------
[未发现] 嵌套 for 0 处
[未发现] 循环里 time.sleep 0 处
[未发现] 循环里 open 0 处
[未发现] 循环里 re.compile 0 处
四条规则，命中 0 处。规则脚本给不出任何线索。
! 原因不在语法里。
r not in out 这一句看着人畜无害，可 out 是列表，一次成员判断要扫一遍——循环里套一次全扫，
就是平方。要看出这一点，得懂「list 的 in 是 O(n)」这条语义，而语义不在任何正则里。
③ 换成集合，快多少
--------------------------------------------------------------------
n= 2000 不重复 1000 用时 0.44 毫秒
n= 4000 不重复 2000 用时 0.95 毫秒
n= 8000 不重复 4000 用时 1.88 毫秒
同样三档数据，形状从平方变成了线性。
这一句改动，任何规则脚本都给不出来——它需要先看懂「这里在判重」。
④ 十二条任务按三个维度分堆
--------------------------------------------------------------------
| 任务 | 可验证 | 影响面 | 判断密度 | 得分 | 结论 |
|---|:---:|:---:|:---:|:---:|---|
| 改一个函数名 | 3 | 1 | 1 | +4 | 可以委派 |
| 补一条单元测试 | 3 | 1 | 2 | +3 | 人盯 |
| 批量加版权头 | 3 | 2 | 1 | +3 | 人盯 |
| 升级依赖版本 | 3 | 2 | 2 | +2 | 人盯 |
| 重构一个模块的内部结构 | 1 | 2 | 3 | -3 | 自己做 |
| 改数据库表结构 | 3 | 3 | 2 | +1 | 人盯 |
| 查一个接口为什么变慢 | 1 | 2 | 3 | -3 | 自己做 |
| 设计新模块的接口 | 1 | 2 | 3 | -3 | 自己做 |
| 修一段没写清的报错文案 | 2 | 1 | 2 | +1 | 人盯 |
| 把日志从文本改成结构化 | 2 | 3 | 2 | -1 | 自己做 |
| 给已有代码补注释 | 3 | 1 | 1 | +4 | 可以委派 |
| 删掉确认无用的旧代码 | 2 | 2 | 2 | +0 | 人盯 |
可验证 2 条、要人盯 6 条、自己做 4 条。
! 三个维度里，可验证是第一位的。
一条任务如果没人能一句话说清「怎么算做完了」，它就不适合委派——不是模型不行，是验收不成立。
数据量翻一倍，时间大约翻四倍——这是平方增长的形状。
三档数据：十点四九、四十六点六六、二百零四点九一毫秒。
四条规则全部「未发现」。
原因不在语法里，在语义里：r not in out 这一句看着人畜无害，可 out 是列表。
换成集合之后：零点三六、零点七四、一点八零毫秒。
形状从平方变成了线性。
这一句改动，任何规则脚本都给不出来——它需要先看懂「这里在判重」。
最后那张三分类表要读一遍数字：
可以委派两条、人盯六条、自己做四条。
「自己做」的四条，可验证性全是 1 分——这不是巧合，是规律。
30 秒实验
- 找一段你觉得慢的代码，先问自己「慢在数据量还是慢在写法」。 答不出来，就说明这活不能直接交。
- 把你手上的任务按「说不说得清怎样算做完」分成两堆。 分不清的那些，先别委派——先想清楚验收，比换模型有用。
- 给它一个探索性任务，看它多久开始瞎猜。 猜的标志是「反复改同一个地方」——那时候该停下来，你先给方向。
常见误区
- 「让它先试试，试不出来再说。」 探索性任务上，试错的成本比人想十分钟高得多。 它会一直试，而且每次都「看起来有道理」。
- 「有测试就不怕。」 测试覆盖不到的地方，测试给的是假的安全感。 绿了不等于对了——它只说明测过的那几条对了。
- 「边界是死的。」 边界按任务变。 同一个仓库里，改注释和改表结构不在同一条线上。
自测三问（点开对答案）
1. 三个反例分别对应哪个维度？ —— **探索性任务对应「可验证性」，高风险改动对应「影响面」，需要人判断对应「判断密度」。** 2. 为什么「可验证性」比「影响面」更硬？ —— **因为影响面大的任务可以加人盯着做，可验证性差的任务盯着也没用**—— **你说不清怎样算做完，谁盯都一样。** 3. 高风险任务到底能不能委派？ —— **能，但要人盯着做。** **「别碰」和「可以碰但别放手」是两件事。** **盯的方式是：先给方案，方案里要有「出事了怎么恢复」。**第 4 章到这里收住。下一章进第二部分：Harness 四件套。 但在写 AGENTS.md 之前，还有一步更基础的事—— 先把仓库变成「能一键跑起来、能一键验证」的样子。
- ☐ （本篇完，下一篇 5.1 进入项目前的两个最小确认）