章节主旨
讲一个工作流跑通之后如何长期迭代:把优化任务反复外包给模型、只做数量级级别的改进、把每个工作流沉淀为可复用资产,最终用「元指令」把工作流簇串成一个入口。
核心论点
- 改进的动作就是「反复问模型」——让它列 10/20 条更快/更省的方案,人只做选择,循环几十次。(→ 详解1)
- 数量级规则:非 10x 不做——只在时间/成本/准确率某项能提升约 10 倍时才动手,小幅优化用可靠性换边际收益,不划算。(→ 详解2)
- 每个工作流都是永久资产——指令与执行脚本是纯文本,可跨工作区、跨人、跨云无限复用,IDE 逐渐变成能随时部署的资产库。(→ 详解3)
- 元指令把工作流簇合并成一个入口——按「族」分离存储各工作流,再用一个上层指令按序串起来,一次调用跑完整条链。(→ 详解4)
知识点详解
1. 改进方法:把优化外包给模型 3:33:42
作者说他改进工作流的实际动作简单到近乎笨:直接问模型「能不能更快」「能不能更便宜」,并让它一次列出 10 到 20 条可行方向,如此反复几十次。
关键不在模型给的方案本身——大部分方案其实行不通——而在于人用判断力从这堆候选里挑一条最合理的落地,跑完再问下一轮。
这本质是一个「模型负责发散、人负责收敛」的循环:模型把搜索空间铺开,人做那个不可外包的取舍决策,靠迭代把工作流逐步压快、压省。
2. 数量级规则:非 10x 不做 3:34:08
作者给自己立了条「数量级规则」(order of magnitude rule):一个优化,除非能在某个关键指标(时间、成本或准确率)上带来至少 10 倍改进,否则不做。
原因是多数优化本质是拿一项换另一项——为了提速牺牲成本或准确率。一个流程从 3 分钟优化到 2 分钟只是 33% 的提升,算上你的实现工时,再乘以引入的出错风险,通常是净亏。而且很多时候这个环节根本不是瓶颈,15 分钟还是 20 分钟对下游毫无区别。
他举了抓线索的例子:串行方案抓 2000 条线索要 20 分钟,他把能换的算力、Apify actor、Google Sheets API 请求全试了一遍,也只压到 15 分钟(约 25% 提升),还把流程搅成一团不可靠的乱麻。真正有效的是换成批量并行:每次发 100 条、发 20 批,约 1 分钟跑完——这是 20 倍的改进,才值得做。3:35:55
能带来数量级跳变的典型手段包括:从软件编码换成硬件编码、并行化(多线程 / 多个 service worker 同时跑)、有时是根本性地改变工作流的操作顺序。判断信号很朴素:当你问模型、它回答里冒出这类词时,大概率值得试。3:36:27
3. 每个工作流都是永久资产 3:36:56
作者强调:你搭的每个工作流都成为资产库里的永久资产,既指指令(directives)也指执行脚本。因为它们本质只是「纸上的一堆文字」,极其可移植。
你可以在任何 IDE 或 agent 里打开任意工作区调用它,可以把指令和执行脚本拷给同事朋友,可以放上 GitHub(配 GitHub Codespaces)。这等于用自然语言复刻了 n8n / Make / Gumloop 这类拖拽式无代码工具的复用能力,只是载体换成了文字,比可视化蓝图更便携。日积月累,你的 IDE 会变成一个可随时随地部署的「宝箱」。
一个真实小例子:作者连续三周忘记发社群周会帖,退了一批人的款后,他问 Claude Opus 4.5 能否自动化。模型找到他此前搭的一套处理登录鉴权的系统,写了个简单抓取规格,三分钟就搞定,再配一个定时器(schedule timer,后面章节讲),从此自动执行。这类生活里的小问题都能被这类工具顺手解决。3:38:24
4. 元指令:把工作流簇合并成一个入口 3:39:19
当你已有一批各自跑得很好的独立工作流后,下一步是过渡到作者所称的metadirectives:一个把整族工作流捆在一起的「伞形」上层工作流。
比如一个「营销伞」下面挂着抓线索、写广告文案、投语音信箱等一串子工作流;又比如客户 onboarding,把欢迎邮件、工作区搭建、邮件文案三个独立工作流用一个「新客户工作流」按序串起来。以后每次来新客,只调这一个大工作流,而不是手动一二三跑子工作流。
作者特别建议:各工作流的指令要分开存储,不要塞进一个几百万行的巨型文件。因为模型每次只需按需加载当前用到的那部分进上下文,分离存储更易维护、也更省 context。3:40:03
这个能力叠加上「无限复用」就很强:新客户工作流可以直接发给团队里其他三个客户经理,每来新客各自跑一遍;或者(后续章节)挂到 schedule trigger 或 webhook 上,无人值守自动运行。
术语
- order of magnitude rule(数量级规则):只在关键指标能提升约 10 倍时才做优化的自律准则。
- serial vs. batch parallel(串行 vs 批量并行):逐条处理 vs 分批同时发出,后者常带来数量级提速。
- permanent asset / library(永久资产 / 资产库):由纯文本指令与执行脚本构成、可无限复用的工作流沉淀。
- metadirective(元指令):把一族独立工作流按序串起来的上层「伞形」工作流。
- schedule timer / trigger(定时器 / 定时触发):让工作流按计划自动执行的触发方式。
自检问题
- 作者的「数量级规则」具体是什么?为什么他不再做小幅优化? 答案:除非某关键指标(时间/成本/准确率)能提升至少 10 倍,否则不做。因为小优化通常拿一项指标换另一项,算上实现工时和引入的出错风险,边际收益往往是净亏,还会把流程搞得不可靠。锚定详解2。3:34:08
- 抓线索的例子里,串行优化和批量并行分别达到了什么效果? 答案:串行方案 20 分钟抓 2000 条,穷尽优化也只压到 15 分钟(约 25%,不值);换成每次 100 条发 20 批的批量并行后约 1 分钟跑完,20 倍提升,才是值得做的改进。锚定详解2。3:35:55
- 为什么作者建议把各工作流的指令分开存储,而不是合成一个巨型文件? 答案:因为模型每次只需按需加载当前用到的那部分进上下文,分离存储更易维护、更省 context;元指令再把它们按序串起来即可。锚定详解4。3:40:03