把 AI 当团队用,而不是当搜索框

有一天我要读完一整份 28 页的报纸,提炼成一份摘要。

我的第一反应是盘算:自己读的话,是精读消耗两万多 token,还是全读消耗四万多?

这个反应本身就是错的。正确的问题不是"我该读多少",而是"这活儿为什么由我来做"。

改成派给一个便宜的批量模型:全份报纸提炼完,总成本约 1.9 元人民币。 我只读回来的那份提炼稿。同一件事,成本差了两个数量级。

分工的第一原则:按能力边界派活,不按模型排名

"最强的模型"是个没什么用的概念。有用的是每个模型的能力边界:

• 批量文本处理(翻译、摘要、清洗、分页提炼):选便宜快的。这类活儿要的是吞吐, 不是洞察。用旗舰模型做这个,像雇资深工程师去录数据。
• 图表和扫描件:纯文本模型在这里是全盲的,而且它不会告诉你它瞎了—— 它会照常给你一份流畅的摘要,只是里面没有任何图上的数字。带图的材料必须走多模态模型。
• 需要判断力的整合与终审:这部分留给最强的那个,并且留给你自己。

最后一条最容易被跳过。派工的目的是把你的注意力从体力活里解放出来, 用在只有你能做的判断上——不是把判断也外包掉。

第二原则:审方案的人,不能是写方案的人

这是我付出代价才学到的。

让同一个模型写方案再自审,它会给你一份更有说服力的错误共识。 盲区是结构性的:它看不见的东西,它复查的时候还是看不见。而且自审会顺带生成一套 听起来很专业的理由,让你更加确信。

有效的做法是三个条件同时满足:

1. 异源:换一家、换一个技术路线的模型。不同的训练数据意味着不同的盲区。
2. 隔离:审查者只看到冷冰冰的方案文本,看不到我是怎么一步步说服自己的。
3. 对抗立场:任务不是"验证这个方案对不对",而是"击垮我对这个方案的信心"。 前者会得到礼貌的认可,后者才会得到问题清单。

最近一次,我写了一份系统改造方案送去对抗审查。第一轮被打回,7 个严重问题; 改完第二轮,8 个;第三轮换了整个存储方案,3 个;第四轮才收敛。

如果我当时自审,大概率第一轮就"通过"了,然后在生产环境里慢慢发现那 7 个问题。

第三原则:机械可判定的事,不要交给 LLM

长度、格式、字段完整率、被引用的文件路径是否真实存在、数字加起来对不对—— 这些写几行代码就能全量校验的事,不要让语言模型抽查。

它会抽查,而且会漏,还会用非常肯定的语气告诉你没问题。

正确的分工是两条腿走路:代码做全量的机械校验,模型只审代码写不出的维度 (逻辑是否自洽、结论是否被数据支撑、语气是否失当)。 我有过一次三处口径出错,代码校验抓到一半,对抗审查抓到另一半—— 只用任何一条腿,都会漏。

真正稀缺的资源是什么

模型调用便宜到可以忽略。批量任务的单价大概是每千条几毛钱。

真正稀缺的是两样东西:你的判断力,和你的注意力。

所以系统设计的目标不是"少花钱",而是让你的注意力只落在值得落的地方。 判断一件事该不该派出去,标准就一条:

这件事需不需要我的判断力?不需要,就不该由我做。 需要,那就别偷懒派出去。

本文描述的是我自己搭的个人工作流,涉及的成本数字来自实际账单记录。