---
title: '05 工作流管理与学习循环'
video_id: UPtmKh1vMN8
part: 5
---

> 章节 5 / 29 · [[00-总览|课程总览]] · 起始 [17:30](https://youtu.be/UPtmKh1vMN8?t=1050)


## 章节主旨

作者以自己的日常开发方式收尾:把上下文预先「烘焙」进紧凑的 workspace,让每次下指令都省去 agent 试错乱撞,直接进入高效执行循环。

## 核心论点

1. **预置上下文的紧凑 workspace,是把 vanilla agent 的试错成本换成一次性配置成本**——同样一句「去做 X/Y/Z」,裸 agent 会四处摸索烧掉大量 token 和钱,预置好的 workspace 则已内建这些信息、仍保留灵活性。([[#1-紧凑-workspace-与开发循环-1736|→ 详解1]])

## 知识点详解

### 1. 紧凑 workspace 与开发循环 [17:36](https://youtu.be/UPtmKh1vMN8?t=1056)

是什么:作者本人用 Claude Code 开发时,workspace 保持「super tight」——把频繁需要的上下文(项目约定、常用任务的做法)预先写进配置,而非每次现讲。

为什么:用 vanilla(未配置)的 agent 直接派活,它会「stumbles around」——四处摸索、消耗两万级 token、花掉不确定的钱。预置上下文把这份试错成本前移成一次性配置,后续每轮循环都省下来。

怎么用:同样下达「去 scrape 某个来源」这类指令时,紧凑 workspace「already has all that stuff baked in」,又保留足够灵活性应对变化(见 [17:51](https://youtu.be/UPtmKh1vMN8?t=1071))。这就是作者反复强调 CLAUDE.md / Workspace 上下文预置 价值的落点。

## 术语

- workspace(工作区,agent 运行的项目目录 + 其预置上下文)
- baked in(预烘焙,把上下文预先写入配置而非临场提供)

## 自检问题

1. 为什么作者坚持让 workspace 保持「紧凑(tight)」而不是用 vanilla agent 临场下指令?
   **答案**:vanilla agent 会四处摸索、消耗两万级 token 和不确定的花费;紧凑 workspace 把上下文预先 baked in,一次性配置换掉每轮的试错成本。锚定详解1,[17:36](https://youtu.be/UPtmKh1vMN8?t=1056)
2. 预置上下文会不会牺牲灵活性?
   **答案**:不会——作者强调预置的同时「still being flexible enough」,信息内建但仍能应对新指令。锚定详解1,[17:51](https://youtu.be/UPtmKh1vMN8?t=1071)