章节主旨
一套可复用的搭建流程:从 system prompt(agents.md)出发,把DOE 框架、Self-annealing 自退火、自主性三件事写进去;有 SOP 就把 SOP 转成 directive,没文档就用大白话口述起步。
核心论点
- 一切始于也终于 system prompt——agents.md 是每次都注入的「超长 prompt」,把框架、思路、边界一次写全,是当下的护城河。(→ 详解1)
- 解释框架的「为什么」能显著降错——不只告诉模型用什么框架,还要说服它接受(拿到模型的 buy-in),输出质量更高。(→ 详解2)
- 三样必写:框架、self-annealing、自主性——让 agent 能自修错、能自主循环到跑通,而非每步等你。(→ 详解3、4)
- 有 SOP 就已完成一半——SOP 本身就是 directive,搭建只是把人类可读文档翻译成 token 更省的另一种人类可读文档。(→ 详解5)
- 没文档也能起步——用给同事解释的大白话口述,agent 擅长格式化,不需要会写代码。(→ 详解6)
知识点详解
1. 一切以 system prompt 为锚 3:01:15
搭工作流的第一原则:一切始于也终于你的 system prompt。它在不同 IDE/agent 里叫 agents.md、claude.md、gemini.md、cursor.md,名字随工具约定,内容应当一致。
本质上它就是一个「超级加强版 prompt」。你在聊天窗口里发的指令很短;而这个 prompt 每次都被自动注入,超长、超密、覆盖你希望模型掌握的几乎所有边界情形与思路。
它要讲清你的框架、你的思考方式、每一步想让模型做什么。这是你把一个通用 agent「定制化」成专属工具的地方——当下它就是护城河。作者建议直接复制他的版本起步,但强调无论用谁的,下面三样都要有。
2. 解释框架 + 讲清「为什么」 3:02:38
第一样要写的是框架本身。用什么框架(DOE 框架 或 Claude Skills)就明确告诉模型,并指出资源在哪:directive 放 /directives、临时文件用 tmp 且用完删除。
作者的经验是:光说「你在用 DOE 框架」不够,把框架背后的道理也解释给模型,错误率会明显下降。做法是先承认「作为 LLM,你完全独立完成任务的概率其实不高,所以我用 DOE 来大幅降低你的出错率」。
这相当于说服模型、拿到它的 buy-in——获得认同后,产出的质量会高很多。这是把 prompt 从「命令」升级为「让模型理解并配合」的关键动作。
3. Self-annealing:让模型自己修错 3:03:19
第二样是 Self-annealing 自退火。它指模型在不先来问你的前提下,自行修复自己的错误:出错时把 error 喂回模型,模型推理、解决,并更新框架文档,让下次不再撞同一个坑。
它让工作流变得有韧性——不只是恢复到能跑,而是每次故障都成为「特性而非 bug」,因为它暴露了你原本都不知道的薄弱环节。
作者此处只给定义,声明后续章节会结合 system prompt 深入讲。此处知道概念即可。
4. 写入自主性(autonomy) 3:03:55
第三样是给模型一种「自主感」。明确告诉它:目标是让你无需我在场就能自主运行,你是一个 agentic workflow;你要自测每个系统、自己发现错误、反复循环直到跑通。
同时加护栏:发 API 调用或为测试消耗 token 时要谨慎;并立一条规则——只有 100% 确信没有我的人工输入就无法解决时,才来找我,而这种情况极少。
这样做能让模型显著更自主,把它从「陪你写代码的工具」变成「同事级的员工」。directive 与执行脚本都是活文档,一旦发现错误或约束,就指示 agent 自行更新它们。
5. 有 SOP:直接转成 directive 3:04:51
如果你已有 SOP,就等于完成了一半。做法:打开 IDE,把现有 SOP 文档拖进工作区,说「我上传了一个文件,把它变成 directive 并搭好执行脚本」。
简单的 SOP(纯 AI prompt、不需执行脚本)会被很快搞定;复杂的会先问你确认思路,再在 /directives 建 directive、在 executions 建脚本,缺 API token 就让你补进 .env。
之所以顺畅,是因为 SOP 本身就是 directive——已含目标、步骤、输入输出、边界。你只是把人类可读文档翻译成 token 更省的另一种人类可读格式,好比把菜谱转成「机器人厨师」能照做的形式,并没让 agent 凭空创造。
若你的 SOP 写得不好,反而是改进机会:agent 因缺信息会追问澄清,逼你这个「系统工程师」把人凭直觉略过的模糊点写明。很多公司「埋没关键信息」(「那事去问 Pete」),而 agent 会追问「Pete 是谁、为什么重要、这步为什么要等」——搭建过程本身就在升级你的业务。
6. 没文档:用大白话口述起步 3:07:11
完全没有文档也没问题。从描述你想法的几条基础 bullet points 开始,用最朴素的对话式语言,像给同事解释一样写下来——很多时候就是你本会发给团队的 Slack 消息,复制粘贴进 agent 即可。
不要纠结结构和格式,先把想法倒出来,agent 很擅长格式化;也可以用语音输入,之后边测边补细节。关键在于你根本不需要会写代码,只需会解释你想要什么——这是更可达成的技能。
作者给了个真实的线索生成 prompt 作范例 3:08:01:按我指定的行业和地点从 Apify 抓线索;全量抓取前先验证 80% 匹配目标市场;补全缺失邮箱用二级服务;结果汇总到可共享的 Google Sheet 并把链接发我。简单直白,却是一套完整工作流的规格。
术语
- system prompt / agents.md(每次注入的超长定制 prompt,不同 IDE 叫 claude.md/gemini.md/cursor.md,内容一致)
- self-annealing(自退火:模型出错时自行推理修复并更新框架文档,不先来问你)
- autonomy(自主性:让 agent 自测、自查错、循环到跑通,极少时候才请求人工介入)
- buy-in(认同:向模型解释框架背后的道理,换取它的配合以提升产出质量)
- directive(指令文档:DOE 中承载目标/步骤/输入输出/边界的活文档,由 SOP 翻译而来)
- SOP(标准作业程序:公司现成的流程文档,本质已是 directive)
- living document(活文档:directive 与执行脚本随发现的错误/约束由 agent 持续更新)
自检问题
- 为什么作者强调要向模型「解释框架背后的为什么」,而不只是告诉它用哪个框架? 答案:因为这相当于争取模型的 buy-in(认同)——先承认 LLM 独立完成任务的概率不高、再说明框架如何降低出错率,模型理解并配合后产出质量更高、错误率显著下降。见详解2 3:02:38
- self-annealing 与老式自动化在「出错」上的根本区别是什么? 答案:老式自动化出错就断掉;self-annealing 把 error 喂回模型,让它推理修复并更新框架文档,下次不再撞同一坑——故障成了暴露薄弱环节的「特性」,系统因此更有韧性。见详解3 3:03:19
- 已有 SOP 时,为什么说「转成 directive 只是翻译、不是创造」? 答案:因为 SOP 本身已含目标、步骤、输入输出、边界,等价于 directive;agent 只是把人类可读文档翻译成 token 更省的另一种人类可读格式,像把菜谱转成机器人厨师能执行的形式,并未凭空产出新内容。见详解5 3:04:51
- 完全没有任何文档时,作者建议如何起步? 答案:用最朴素的对话式语言、像给同事解释一样写下几条 bullet points(常常就是本会发的 Slack 消息),不纠结结构直接粘进 agent,之后边测边补;无需会写代码,只需会解释想要什么。见详解6 3:07:11