Santa Augmentcode Intent 第4集
Source: Dev.to
问题
在早期的 Workshop 时期，所有精灵共享一张大桌子。它 看似 高效——直到并非如此。
- Jingle 正在打磨一个轮子，Jangle 正好伸手去拿。
- Twinkle 的油漆弄到了 Tinkle 的火车模型上。
- 那场伟大的 1889 年圣诞碰撞（我不想提起）。
事后看来，解决方案显而易见：给每个精灵一张自己的工作台——隔离、私有，但仍连接到同一份主礼物清单。
Augment Intent 做的事情相同，只是把它们称为 工作区。
当多个代理（或多个人类）同时在同一套文件上工作时，冲突是不可避免的。
Agent A modifies auth-middleware.ts at line 47
Agent B modifies the same file at line 52两个代理都不知道对方的存在，于是出现了合并冲突。
冲突并不是任一代理推理的错误；它是 协调失效——缺乏隔离。
为什么 Git 的经典工作流不足
Git 设计用于人类主要串行工作：
# Classic git workflow (one checkout)
git checkout feat/jwt-auth
# … work, commit, push一个分支被打开，工作数天或数周，然后合并。假设变更的节奏是人类节奏。
AI 代理不是人类节奏。它们可以在几分钟内修改数十个文件。在并行多代理执行下，冲突率上升得比任何团队手动管理的速度都快。
工作树：Git 的内置隔离
Intent 通过 Git 工作树 实现了这种隔离工作区。
工作树（worktree）是 Git 的一个不太为人所知的特性，允许你 同时检出同一仓库的多个分支，每个分支都有自己的目录。
- 它们共享仓库的对象存储（没有重复的数据）。
- 每个工作树都有自己的工作目录和索引。
# Git worktree (multiple simultaneous checkouts)
git worktree add ../api-gateway-worktree feat/jwt-auth
git worktree add ../auth-service-worktree feat/auth-service
# Both directories exist simultaneously, sharing one .git object storeIntent 会自动完成上述全部操作。当 Coordinator 启动一个 Specialist 时，Intent 会为该代理自动创建一个专用的工作树。精灵拥有自己的工作台；其他精灵看不到其进行中的文件。文件保持隔离，直到 Coordinator 将工作合并。
示例：三位专职精灵
Workshop Floor
├── Auth Token Elf → worktree: feat/auth-token-service
├── Gateway Middleware Elf → worktree: feat/gateway-middleware
└── Test Suite Elf → worktree: feat/integration-tests (waiting)每个 worktree 都包含在该精灵启动时对应文件的副本。
Auth Token Elf 在 auth-service/src/token-service.ts 中所做的更改对 Gateway Middleware Elf 是不可见的，除非显式集成——不存在意外覆盖，也没有文件写入的竞争条件。
协调者会跟踪每个 worktree 的状态。当两个实现精灵都完成后，它会协调合并——在 规范层面 解决任何冲突（因为接口契约在此声明），而不是在文件层面才发现冲突。
时间隔离
圣诞老人同样重视 时间隔离：能够在夜间关闭车间，并在早晨发现它正如你离开时的样子。
在大多数 AI 工具中，关闭窗口就结束会话——上下文会丢失，代理会忘记之前的内容。
Intent 的工作空间是可恢复的。当你关闭应用程序并在第二天早上重新打开时，每个代理都正好停留在之前的位置。规范保持不变，工作树完好无损，进行中的提交也安全无虞。
工作原理： Intent 使用 自动提交——当代理完成工作单元时，它们的更改会自动提交到各自的分支。持久化状态就是 Git 历史本身，它能够在任何重启后仍然存在。
Intent workspace state on close:
├── spec: JWT auth — 6/9 tasks complete
├── Auth Token Elf: feat/auth-token-service — all commits saved
├── Gateway Middleware Elf: feat/gateway-middleware — all commits saved
└── Test Suite Elf: feat/integration-tests — waiting to startIntent workspace state on reopen (next morning):
└── [identical to above — nothing lost]对圣诞老人而言，这意味着在 12 月 23 日离开，24 日返回时，仍能看到每个小精灵在工作台前，手中的礼物半包装好，正如离开时的状态。车间从不遗忘。
单窗口体验
Isolation 并不意味着碎片化。Intent 将所有内容显示在单个窗口中：
- 代码编辑器 – 显示活动代理的文件。
- 内置 Chrome 浏览器 – 实时预览
localhost的更改。 - 终端 – 运行构建、测试和脚本。
- Git 集成 – 处理暂存、提交和分支管理。
您无需在 VS Code、iTerm、Chrome 和 SourceTree 之间切换。Workshop 的工作区就是一个包含所有工具的房间。
这对代理工作很重要，因为代理需要立即看到结果。修改 React 组件的专家可以在同一窗口打开浏览器预览，验证渲染效果，然后直接提交或调整——无需交给人工检查。
SIPOC 概览
| S – 供应商 | I – 输入 | P – 过程 | O – 输出 | C – 客户 |
|---|---|---|---|---|
| 协调者、Git 仓库、文件系统 | 任务分配、分支名称、起始文件状态 | 协调者生成代理 → Intent 创建工作树 → 代理在隔离环境中工作 → 自动提交保存进度 → 完成后协调者进行集成 | 每个代理的独立分支，无冲突，可恢复的状态 | 协调者、开发者、CI/CD 流水线 |
车间类比
| 元素 | 类比 |
|---|---|
| 圣诞老人 | 主要玩具库 |
| 精灵任务 | 工作台材料 |
| 过程 | 圣诞老人分配工作台 → 精灵获取私人材料 → 无中断地工作 → 礼物安全存放 → 圣诞老人整合 |
At End
没有冲突，没有损坏的礼物，始终可恢复
Quality Control, Head Elf Pepper, the Sleight
Father Christmas 对工作台有一条铁规：精灵的工作必须留在他们的工作台上，直到完成并经过验证。过早的合并会导致半成品玩具出现在主库存中，令其他精灵困惑。
用 Intent 表述
协调者 不应 合并专家的分支，除非满足以下条件：
- 专家已报告完成。
- 验证代理已确认符合规范。
- 与其他精灵的接口约定已得到遵守。
规范即检查清单。当所有项目都勾选后，合并才是安全的。
在 第 5 集 中，Father Christmas 将解释 Spec‑Driven Development —— 这一哲学转变把活的规范置于工作流的中心，并利用它确保一切在圣诞节前完成。这就是我们迄今为止所构建一切的 why。
整洁的工作台是有序思维的标志，而有序的车间则意味着礼物准时送达。
Ho ho ho! 🎅
本篇是 Santa Augmentcode Intent 系列的一部分。发表于 dev.to 的 the‑software‑s‑journey 组织下。