章节 15 / 37 · 课程总览 · 起始 2:10:03

章节主旨

手把手从空 IDE 起步,用 DOE 框架 搭第一个真实的 Agentic 工作流:建工作区、放 claude.md 系统提示,再用一句自然语言让 agent 生成一个客户 onboarding 邮件流;末尾拆解「好的 directive」由哪四要素构成。

核心论点

  1. 工具无关、模型无关——用 VS Code 还是别的 IDE、用哪个 coding agent 都可互换,示范只是选了最顺手的一套。(→ 详解1)
  2. 一句自然语言就能搭出可用工作流——把高层意图口述给 agent,由它读 claude.md 生成目录结构与 directive,非技术者也能落地。(→ 详解2、详解3)
  3. 一个好的 directive 有四个必填要素:目标陈述、输入规格、分步流程、完成定义;缺完成定义,概率系统会「优雅地失败」而无人察觉。(→ 详解4、详解5)

知识点详解

1. 从空 IDE 起步:工作区 + 系统提示文件 2:10:23

第一步是开 IDE 建一个新的 workspace(演示里叫 YouTube workspace)。Nick 特意强调选 VS Code 不代表它更好,而是想说明「这些工具如今都可互操作,你用什么都行」——不必被某个编辑器或某个模型绑死。

进工作区后要创建系统提示文件 claude.md,把一份现成模板粘进去保存。这个文件是后面所有行为的规矩来源:agent 会先读它,再据此理解整个项目怎么运作。

前提是已装好 coding agent(演示用 Claude Code,装法是在扩展里搜插件、安装、登录),并有自己的 API key 或一个 10–20 美元/月的账号。2:10:46

2. 用 claude.md 自举出目录结构 2:12:34

工作区此刻只有一个 claude.md,还没有真正的项目骨架。做法是开启 bypass permissions 模式,然后只丢一句:「按 claude.md 帮我把工作区搭起来」。

agent 会通读 claude.md、理解其运作方式,自动生成完整目录结构——期间会写出诸如 webhook.md 之类文件、铺陈 DOE 框架 里的确定性层与执行层,最后自我校验并给一段简短总结。

这一步的意义:项目脚手架不是手工搭的,而是由系统提示驱动 agent 生成的,人只下一句指令。

3. 一句话搭 onboarding 邮件流 2:11:42

演示目标是个最简单的三四步链:客户加入组织时,自动发一封欢迎邮件、附公司背景、再邀约一次 kickoff 通话的日历链接。Nick 选它只因它最能直观展示「怎么把几件事串起来」,后续章节会逐步加复杂度。

给 agent 的是高层自然语言:「我想搭个 onboarding 流程,我说 onboard 某邮箱,你就给这个新客户发一封介绍公司、给背景、并用日历链接邀约 kickoff 的邮件」。agent 会反问澄清:用什么发信(SMTP / resend / SendGrid)、公司信息、URL 是什么。

关键体验是你不必事先都懂:Nick 直接回「不知道那些是啥,我就想用自己的 Gmail 发」,并给出要点式公司信息、日历链接先用示例占位。agent 随后在 directives/ 里生成 onboard_client.md,把这些高层指令写成一份 directive。2:14:42

一次性凭据配置也由 agent 引导:新建一个 Google app-specific password(命名如 YouTube example),粘回去,agent 就用它更新 .env 文件并确认保存。整条流程只花几秒,展示的正是「连 app key、env token 都不懂的非技术者也能真正接入软件」。2:15:12

4. 好 directive 的四个必填要素 2:16:41

要写出真正好用的 Directive,需要四样东西。

  1. 清晰的目标陈述(objective statement):这份 directive 到底做什么。2:16:42
  2. 输入规格(input specification):agent 启动需要哪些数据。
  3. 分步流程(step-by-step process):一串操作、脚本与预期输出,用自然语言写。
  4. 完成定义(Definition of Done):质量判据——agent 怎么知道自己成功了,它要能根据自己的产出给自己打分。2:16:57

完成定义要具体到可自查,例如「当你拿到一个至少填了 100 行的 Google Sheet 链接时,就算成功」。

5. 边缘情况、fallback 与「优雅失败」 2:17:25

除四要素外,directive 还应写清边缘情况:已知异常、API 的怪癖、不该报错却报错的错误码、常见失败模式,全都提前写进去。

也要描述 fallback 行为,例如「如果 Apollo 抓取器失败了,就改用 instantly 的 lead 富化工具」。相比 n8n / make.com 这类可视化工具要专门搭一大套复杂的错误处理流,这里只加一行「如果发生 X 就做 Y」,简单得多。2:17:39

最需要防的是优雅失败(fail gracefully):很多系统失败时不报错、也不告诉你——你期望 100 条 lead,结果只回了几条,技术上「没出错」,模型没有内建办法察觉不对。

这正是完成定义不可省的原因:显式规定「若低于最低阈值(比如 100 条),就放宽筛选条件反复重跑,直到达标才把结果交回用户」。

术语

  • workspace(工作区,IDE 里承载一个项目的文件夹)
  • claude.md(系统提示文件,定义 agent 如何运作,项目行为的规矩来源)
  • bypass permissions(免确认模式,让 agent 自动执行文件/命令操作)
  • app-specific password(应用专用密码,Google 为第三方发信生成的凭据)
  • directive(指令文件,DOE 里描述一个任务「做什么、怎么做、何为完成」的规格)
  • objective statement(目标陈述,directive 四要素之一)
  • input specification(输入规格,agent 启动所需数据)
  • definition of done(完成定义,agent 自评是否成功的质量判据)
  • fail gracefully(优雅失败,系统未报错却未真正完成任务)

自检问题

  1. 一份好的 directive 必须包含哪四个要素? 答案:目标陈述(objective statement)、输入规格(input specification)、分步流程(step-by-step process)、完成定义(definition of done)。见详解4 2:16:41
  2. 为什么「完成定义」不可省?它防的是什么问题? 答案:防「优雅失败」——概率系统可能未报错却没真正完成(如只回了几条却期望 100 条),模型无内建方式察觉;完成定义给出可自查的阈值,不达标就放宽条件重跑直到达标。见详解5 2:17:25
  3. 相比 n8n / make.com,DOE 里处理失败与 fallback 有何不同? 答案:不用专门搭复杂的错误处理流,只在 directive 里加一行自然语言,如「若 Apollo 抓取器失败就改用 instantly」。见详解5 2:17:39
  4. 演示中非技术者怎样接入 Gmail 发信而无需懂 app key? 答案:由 agent 引导新建一个 Google app-specific password,粘回后 agent 自动写入 .env;用户全程不必理解 app key/env token。见详解3 2:15:12