alley-oop 这个词最早来自篮球里的“空中接力”：一名球员把球抛向篮筐附近，另一名球员在空中接住、完成得分。放在代码协作里，它描述的是一种非常具体的 PR 接力节奏——一个 pull request 被打开时并不是最终完成的代码，而是一个抛向半空、等着另一个人或另一个 AI Agent 接住并继续完成的起点。HumanLayer 的 Dex Horthy 展示的 alley-oop pull request 工作流，把这种“抛球、接球、扣篮”的节奏引入了 AI Agent 协作场景。
这个工作流值得关注的原因不是炫技，而是它补上了当前 AI 编程协作里最弱的一环：交接。单次让 Agent 从零开始生成完整 PR，经常出现上下文不够、改动超范围、review 轮次爆炸的问题。而 alley-oop 的核心变化是，人类先打开一个带骨架的 PR，Agent 在 PR 这个明确的上下文容器里完成剩余实现，再由人类收尾审查。PR 从“最终产物”变成了“协作接力棒”。
这篇文章会拆解这套工作流的角色分工、模式变体、GitHub 落地配置、一次完整实战流程，以及如何用 label、模板和自动化脚本把 alley-oop 变成团队规范。如果你正在用 Claude Code、Codex、Cursor、Copilot 等 AI 编程工具处理真实仓库，并且经常遇到“Agent 改着改着就跑偏”的问题，这篇可以直接收藏。
1. alley-oop PR 工作流核心概念
alley-oop PR 工作流强调的不只是“让 AI 提 PR”，而是把 pull request 当作一个异步交接单元。传统流程里，需求确认之后通常直接由开发者完成分支、提交、提 PR、等人 review。到了 AI Agent 场景，这种线性流程有两个明显问题：Agent 缺少长期记忆，长任务做一半容易丢失目标；Agent 在模糊宽泛的指令下容易产生大量额外改动。
alley-oop 的解法是引入“seed PR”概念。一个任务不再由一个 Agent 独立完成，而是被拆成几个阶段：人类先把任务的可验证骨架写出来，包括接口定义、模块边界、关键注释、测试桩和 TODO；然后 AI Agent 接过这个分支，在明确约束下完成实现；最后人类或规则化检查器做 review，确认质量后再合入。
| 能力项 | 说明 |
|---|---|
| 核心思想 | 用 PR 作为人类与 AI Agent 之间的交接单元 |
| 典型阶段 | seed 抛球 → agent 接球实现 → 人工收尾 review |
| 关键载体 | Draft PR、PR 描述、label、commit、代码注释 |
| 理想产出 | 上下文清晰、范围可控、可验证的分支与 PR |
| 对 AI Agent 的要求 | 能在既有分支上继续开发，能读取 PR 上下文和任务说明 |
| 对平台的要求 | 需要支持 PR、Draft、Label、Review 的代码托管平台 |
| 主要适用范围 | 功能开发、Bug 修复、重构、测试补充、文档更新 |
| 不适用范围 | 任务目标模糊、验收标准缺失、依赖大量隐性判断的改动 |
这套流程的关键判断很简单：单体 Agent 的长任务执行能力，可以用更小的接力单元来补偿。一次 PR 只完成一个目标，一个 Agent 只负责一段明确的工作，人类只在最容易出错的边界上介入。
2. 为什么要用 alley-oop：AI Agent 的协作困境
先看现在主流 AI 编程工具的典型工作方式。开发者把需求描述给 Agent，Agent 在本地仓库里读取代码、生成改动、运行测试并汇总结果。整个过程在人看来很顺，但放到真实协作场景里，问题立刻暴露。
第一个问题是“冷启动”。一个 Agent 面对一个新仓库时，需要先理解项目结构、代码风格、测试体系、部署约束和既有约定。这件事在小型 demo 仓库里还好，到了真实中大型项目里，Agent 很容易在仓促判断后开始修改，改完才发现自己理解错了方向。alley-oop 工作流里，人类或其他开发者先提供一条“带落点”的种子分支，Agent 不需要判断“这个项目整体怎么样”，只需要回答“这个模块里 TODO 怎么完成”。这显著降低了 Agent 的判断负担。
第二个问题是“长任务漂移”。Agent 在单个会话里处理越多的子任务，越容易丢失最初的目标约束。它不是故意跑偏，而是上下文被不断新增的文件内容覆盖，早期确定的范围边界逐渐模糊。alley-oop 的思路是把一个大需求拆成多个 PR 接力点，Agent 的任务窗口被缩短，每个窗口只处理一个相对内聚的改动，最终反而比让一个 Agent 从头做到尾更稳定。
第三个问题是“难以 review”。传统“一键生成大 PR”的问题在于，改动量一大，人没办法逐行看，Agent 在某个角落引入的问题很容易被忽略。seed PR 把实现过程拆开，每个阶段改动量都有上限，review 的人可以在每个接棒点及时介入，而不是最后面对一个几百个文件的大 diff 做一次性审查。
第四个问题是“多 Agent 协作缺少协议”。当团队尝试用多个 Agent 分别处理不同模块时，不同 Agent 之间几乎没有记忆同步机制。alley-oop 给出的迁移方式是：把分支、PR、label 和描述当成 Agent 与 Agent 之间的“消息队列”，前一个 Agent 以 commit 和 PR 文本的形式留下交接信息，后一个 Agent 读取这些信息继续执行。它不依赖某个 Agent 的高阶记忆能力，而是用一个代码托管平台已经具备的机制来补足。
3. 核心角色与协作边界
alley-oop 工作流不是单一开发者的操作流程，它涉及至少四类角色。理解每个角色的职责边界，是避免协作混乱的前提。
| 角色 | 典型身份 | 职责 | 交付物 |
|---|---|---|---|
| seed 发起者 | 项目维护者、技术 lead、熟悉上下文的人 | 创建种子分支，定义任务边界、接口和期望结果 | 一个可运行或半可运行的初始 PR |
| 执行 Agent | AI 编程 Agent | 读取 PR 上下文、分支代码和 TODO，按要求完成实现 | 若干提交和一份状态更新 |
| reviewer | 人类开发者、规则检查器 | 校验改动质量、测试覆盖、风格和业务正确性 | Review Comment、批准或拒绝 |
| 合入维护者 | 仓库 maintainer | 确保 PR 通过 CI 并完成 merge | Merge Commit |
seed 发起者不一定要写完所有代码，但必须写出“方向锚点”。这可以是一个接口签名、一张数据库表字段清单、一段空实现、一个测试文件里的预期行为，也可以是 PR 描述里的三段说明。锚点越清晰，执行 Agent 被评价的标准就越明确。
执行 Agent 的核心任务是“在约束下补齐”，不能随意扩大范围。它应当遵守 seed 里已经定义的模块边界，跑通已有测试，并修改 PR 描述中与实现状态不符的内容。它的输出不是“一个天马行空的方案”，而是“一份符合验收条件的实现”。
reviewer 是质量闸门。在依赖 Agent 完成的 PR 里，reviewer 不该只关注代码长什么样，还要关注 Agent 是否真正理解了任务边界。典型检查项包括：有没有改动无关文件，有没有漏掉 seed 中标出的 TODO，测试是否覆盖关键路径，PR 描述是否与最终实现一致。
合入维护者的职责更偏向工程保障：确认 CI 通过、确认 review 至少完成一轮、在 merge 前清理掉不必要的中间提交。必要时可以把多个 alley-oop PR 串联成一次大功能发布。
4. 工作流的典型模式变体
alley-oop 不只有“人类开球，Agent 接球”这一种形式。根据实际参与者和任务类型，可以组合出几种常见模式。
4.1 Human seed → AI finish → Human review
这是最标准的 alley-oop 形态。人类对任务有初步判断，但实现工作量大或偏重复，于是用 seed PR 给定接口和边界，Agent 负责把实现补齐，人类最后 review。适合 API 端点开发、数据库迁移、测试补齐、批量重构这类任务。
实际操作上，seed PR 可以是一个 Draft PR，里面先放接口定义、错误处理骨架和测试用例。Agent 拿到分支后，把类名、函数体、边界条件等需要填的地方补完。
4.2 AI seed → Human 扩展 → AI finish
有些场景里，Agent 可以先做一个非常粗略的原型，人类看后补充业务规则，再让 Agent 继续完成。这种模式适合功能定义不够清晰的探索期任务。
Agent 先抛出一个“模型理解的草稿”，包括模块拆分、数据结构和主流程。人类不一定亲自重写，而是以 review comment 的形式补充约束，例如“这个字段不能为空”“这里必须走异步队列”“错误码要统一到现有枚举”。Agent 读取评论后继续迭代。
4.3 AI start → AI finish → Human review
适合上下文相对完整、验收标准已经明确的内部模块改动。前一个 Agent 或同一 Agent 的新会话，从提交历史中找到上次进度，继续执行。
这种模式的重点是交接信息质量。前一个 Agent 的 commit message 和 branch 名称必须足够清晰，最好再留下一个单独的文件作为任务清单。否则后一个 Agent 需要重新推断上一步的意图，接力效率会打折扣。
4.4 Human seed → 多个 AI 并行 → Human merge
适合一个 PR 里存在多个可并行子任务的情况。发起者只开一个主分支，把不同模块分别标成几个子目录或子任务，不同 Agent 在各自工作目录里完成，最后合并到一个 PR 里统一审查。
这种模式对 seed 的要求最高：并发冲突必须在 seed 阶段就被接口边界隔离掉。如果两个 Agent 都在改同一个文件，alley-oop 的优势会立刻消失。
5. 在 GitHub 上落地 alley-oop：仓库配置方法
把 alley-oop 从想法变成可运行规范，第一步是在 GitHub 仓库里做四件基础配置：分支保护、label、PR 模板、Agent 指导文件。
5.1 分支保护规则
要让 Agent 产出可以安全合入，建议要求目标分支开启 PR 保护。在 GitHub 仓库的 Settings → Branches 中新增规则，然后针对 main 或 master 分支开启：
- Require a pull request before merging
- Require approvals，至少设置为 1
- Require status checks to pass before merging
- Require conversation resolution
这样即使 Agent 有仓库写权限，也无法直接推送到主分支。所有改动都必须经过 PR 和人工 review，这是 alley-oop 的安全底线。
5.2 label 约定
| label | 含义 | 状态 |
|---|---|---|
| alley-oop/seed | 当前 PR 只是种子，待执行 Agent 接球 | Draft PR |
| alley-oop/wip | Agent 正在实现，可审查但不能合入 | Draft PR |
| alley-oop/ready | Agent 已完成实现，等待人 review | Ready for Review |
| alley-oop/human-seed | 人类负责 seed，Agent 只补实现 | 任意 |
| alley-oop/needs-human-feedback | Agent 等待人的评审意见 | 阻塞中 |
Label 的价值不是可有可无。它让所有参与方一眼就能判断“这个 PR 现在到底卡在谁手上”。在 GitHub PR 列表里按 label 过滤，可以快速看到一组待接力的任务。
5.3 PR 模板
配合 alley-oop，建议准备一份专门的 PR 模板。模板要回答三个问题：这个 PR 的起点是什么、预期到达的目标是什么、当前还缺什么。示例内容如下：
## 状态 - [ ] seed 阶段 - [ ] Agent 实现阶段 - [ ] 人类 review 阶段 - [ ] 可合入 ## 任务来源 Closes #issue_number ## seed 抛球说明 （说明为什么从这个点开始，已经完成了哪些骨架工作） ## 执行 Agent 需要完成的部分 - [ ] 实现 xxx 模块 - [ ] 补充 xxx 测试 - [ ] 更新 xxx 文档 ## 验收标准 1. 运行 `pytest tests/xxx` 通过 2. API 返回字段符合 `docs/xxx.md` 3. 不修改与本任务无关的文件 ## 其他背景 （补充仓库约定、已知坑、注意事项）5.4 Agent 指导文件
很多 AI 编码工具支持读取仓库根目录下的规则文件，例如 AGENTS.md、CLAUDE.md、CONTRIBUTING.md。这份文件是 alley-oop 的“隐性交接协议”，建议包含以下要点：
# Repository Guide for AI Agents ## 通用原则 1. 只修改与当前任务直接相关的文件。 2. 新增代码必须匹配项目现有代码风格。 3. 不得为了通过测试而修改测试用例。 4. 任务完成前必须先运行最小验证命令。 ## alley-oop PR 约定 1. 如果 PR 带 label `alley-oop/seed`，说明这是人类 seed，需要你补齐实现。 2. 开始前先读取 PR 描述、diff 和所有 TODO 注释。 3. 每完成一个子任务更新 PR 描述状态。 4. 所有实现完成后将 label 改为 `alley-oop/ready`。不同工具的规则文件名可能不同，需要参考你实际使用的工具文档。关键是让规则文件成为 Agent 输入上下文的一部分。
6. 一次完整 alley-oop 实战演示
接下来用一个接近真实的任务走一遍。假设仓库里有一个 Python FastAPI 服务，用户要求新增“导出 CSV”的接口。任务不算难，但涉及路由、业务逻辑、文件输出和测试，是一个适合 Agent 接力的典型场景。
6.1 人类作为 seed 发起者
先从 main 分支拉一个新分支，只做基础骨架。
git checkout -b feat/csv-export-alleyoop然后创建或修改路由文件，只写下接口定义和函数签名，不写具体实现。
from fastapi import APIRouter from fastapi.responses import StreamingResponse router = APIRouter(prefix="/api/export", tags=["export"]) @router.get("/csv") async def export_csv(): """导出 CSV，由 AI Agent 完成实现。""" # TODO(agent): 从数据库读取数据并生成流式 CSV 响应 # TODO(agent): 列出允许的字段和错误处理条件 raise NotImplementedError同时补一个测试桩，描述接口的预期行为。
from fastapi.testclient import TestClient def test_export_csv_returns_200(client: TestClient): # TODO(agent): 构造测试数据，断言响应状态码为 200 # TODO(agent): 断言 Content-Type 为 text/csv pass提交并推送。这里刻意保留几个 TODO，让 Agent 有明确接球点。
git add . git commit -m "feat(export): scaffold CSV export endpoint for agent handoff" git push -u origin feat/csv-export-alleyoop然后创建 Draft PR，用 GH CLI 是最快的。
gh pr create --draft \ --label "alley-oop/seed" \ --title "feat(export): CSV 导出接口 seed PR" \ --body "seed 已给出路由和测试桩，等待 Agent 完成实现和单测。验收标准见 PR 描述。"6.2 Agent 接手实现
把分支和 PR 编号交给 Agent。无论使用哪种工具，Agent 的核心任务是：
- 读取目标分支代码和 PR 描述
- 查找所有 TODO(agent) 标记
- 完成 CSV 导出实现
- 补齐测试并运行验证
- 更新 PR 描述状态、调整 label
实现完成后的提交可以有清晰边界：
git add app/export.py tests/test_export.py git commit -m "feat(export): implement CSV streaming export with tests" git pushAgent 完成后，通过 GitHub CLI 将 PR 从 draft 转为 ready，并同步修改 label。
gh pr ready 123 gh pr edit 123 --add-label "alley-oop/ready"6.3 人类 reviewer 收尾
reviewer 拿到 PR 后重点看四件事：
- seed 锚点是否被正确继承，路由路径和返回结构是否与 PR 描述一致
- 测试是否有意义，不只是为了绿而绿
- 文件改动范围是否超出 export 模块
- TODO 是否全部清理干净，还是留了隐性未完成项
通过判断后，直接在 GitHub 页面 Approve。维护者再按普通节奏合入。
这段流程的价值在于：人类没有浪费时间去写大量重复代码，Agent 也没有机会在模糊指令下扩大改动范围。每一方都只在自己擅长且负责的环节里工作。
7. 与主流 AI 编程工具的接入方式
alley-oop 工作流并不绑定某一家 AI 工具。无论你使用 Claude Code、Codex CLI、Cursor、Copilot 还是其他能在本地仓库操作的 Agent，接入逻辑通用：先让 Agent 在指定分支上工作，给它提供足够明确的文本上下文。
接入前的两个准备工作：
- Agent 的 shell 环境要能正常执行 Git 命令
- 确认 Agent 使用的平台账号对目标仓库有对应权限
具体命令以 Cli 工具为示例，实际参数需要按你本机安装的版本确认。
模型本地服务或远程 API 的多 Agent 场景，通常需要一个轻量入口脚本，把“接受分支参数 → 读取 TODO → 执行特定测试”这个过程固化起来。这个脚本可以作为 CI 脚本的雏形，也可以被团队成员手动调用。
在仓库里建立统一的“任务入口”文件会有帮助。名称可以是 scripts/alleyoop_start.sh，它只做一件事：打印当前分支的 TODO 和验收标准。
#!/usr/bin/env bash set -euo pipefail echo "当前分支: $(git branch --show-current)" echo "===== PR 信息 =====" gh pr view --json number,title,body --jq '"PR #\(.number): \(.title)"' echo "===== TODO 列表 =====" grep -rn "TODO(agent)" --include="*.py" --include="*.ts" --include="*.go" . || echo "未发现 TODO(agent) 标记" echo "===== 最小验证命令 =====" echo "pytest tests/ 或 npm test"把这个脚本和执行命令一起作为提示词前缀提供给 Agent，比单纯说“看看代码”要可靠得多。
8. 把 alley-oop 固化到自动化：label 机器人与 GitHub API
人多的时候，靠手工打 label 很容易漏。alley-oop 可以配置一个非常轻量的 GitHub Actions，在 PR 状态变化时自动同步 label。
name: alley-oop label sync on: pull_request: types: [opened, converted_to_draft, ready_for_review, labeled, unlabeled] permissions: contents: read pull-requests: write jobs: sync-label: runs-on: ubuntu-latest steps: - name: 根据 draft 状态设置 label env: GH_TOKEN: ${{ secrets.GITHUB_TOKEN }} PR_NUMBER: ${{ github.event.pull_request.number }} run: | if gh pr view "$PR_NUMBER" --json isDraft --jq '.isDraft' | grep -q true; then gh pr edit "$PR_NUMBER" --remove-label "alley-oop/ready" >/dev/null 2>&1 || true gh pr edit "$PR_NUMBER" --add-label "alley-oop/wip" >/dev/null 2>&1 || true else gh pr edit "$PR_NUMBER" --remove-label "alley-oop/wip" >/dev/null 2>&1 || true gh pr edit "$PR_NUMBER" --add-label "alley-oop/ready" >/dev/null 2>&1 || true fi这段 YAML 的逻辑是：Draft PR 自动标记为 alley-oop/wip，转为 Ready 后自动标记为 alley-oop/ready。团队在 GitHub PR 列表里筛选“ready 但没有 review”的 PR，就能准确找出人类需要介入的任务。
如果你不想依赖 Actions，也可以通过 GitHub API 轮询。下面是一个 Python 调用示例，不依赖仓库内部配置：
import requests import os repo = "your-org/your-repo" token = os.environ["GH_TOKEN"] headers = {"Authorization": f"token {token}", "Accept": "application/vnd.github+json"} url = f"https://api.github.com/repos/{repo}/pulls" params = { "state": "open", "per_page": 100, } response = requests.get(url, headers=headers, params=params, timeout=30) for pr in response.json(): labels = [label["name"] for label in pr["labels"]] if "alley-oop/ready" in labels: print(f"PR #{pr['number']}: {pr['title']} 等待人类 review")自动化并不需要从一开始就做得很复杂。先用 label 同步解决“PR 状态不透明”的问题，再根据团队实际痛点增加检查项。
9. alley-oop 的效率观察点与风险控制
引入任何工作流之后，都要用数据而不是感觉来判断效果。alley-oop 场景可以重点观察四个指标：
| 指标 | 观察方式 | 说明 |
|---|---|---|
| seed 到第一次 agent commit 时间 | 从 seed PR 创建到 Agent 第一次提交 | 反映 Agent 对交接信息的理解速度 |
| Agent commit 到 ready 时间 | Agent 开始实现到标记 ready | 反映实现效率和稳定性 |
| Review 轮次 | 从 ready 到 approve 之间的评论轮数 | 轮次过多说明 seed 或任务约束质量差 |
| 改动文件数量 | 查看每个 PR 的 files changed | 如果频繁超过预期数量，说明边界约束失效 |
风险控制比指标更重要。第一个风险是 Agent 拿到过高的仓库权限，这会让 alley-oop 从协作工具变成事故隐患。正确的做法是给 Agent 使用专用机器人账号或临时 token，权限只覆盖需要改动的仓库和分支，不开放组织级全部权限。
第二个风险是 seed 质量不过关。如果人类在 seed 阶段只写了一句话“帮我实现这个功能”，那 alley-oop 本质上退回了传统 AI 编程，Agent 依然要在模糊信息里猜测。seed 至少要包含目标、范围、验收标准和测试命令，才能让后续接力有意义。
第三个风险是 PR 长时间停留在“Agent 已 ready”但无人 review。Reviewer 资源永远比 PR 数量稀缺。建议配合 label 机器人设置每日定时检查，比如每天下午四点列出所有 ready 超过四小时的 PR，提醒团队处理。
第四个风险涉及代码合规。AI Agent 生成的代码无论多快，都必须纳入现有 code review 和发布流程。涉及外部数据、用户隐私、版权素材或生产环境配置时，人类要对最终效果做复核。Agent 可以辅助生成，但不能替代授权和法律合规判断。
10. 常见问题与排查方法
| 问题现象 | 可能原因 | 排查方式 | 解决方案 |
|---|---|---|---|
| Agent 接手后没有动作 | Agent 没有收到足够上下文，或对任务理解存在阻塞 | 查看 PR 评论和 Agent 的 shell 输出 | 在 PR 中补充更明确的 TODO 和验收标准 |
| Agent 改了大量无关文件 | seed 边界不够清晰 | 查看 PR 的 files changed 列表 | 在提示词中强调“只修改指定目录”，必要时用 CODEOWNERS 约束 |
| CI 长时间未通过 | Agent 没有运行最小测试或本地依赖不完整 | 查看 CI 日志与测试失败位置 | 在 AGENTS.md 里写明本地验证命令 |
| PR 处于 alley-oop/wip 但 Agent 已提交 | label 同步规则未配置 | 查看 PR 状态和 label | 使用 GitHub Actions 自动同步 label |
| Agent 无法 push 分支 | 权限配置不全 | 查看 Git 远端报错 | 为 Agent 配置只包含目标仓库写权限的 token |
| PR 合并冲突 | 分支长时间未更新 | 切换分支后 rebase main | 在 seed 阶段要求 Agent 完成后同步主分支 |
| Agent 生成代码能跑但不符合项目风格 | 指导文件缺失或不够具体 | 检查 AGENTS.md、CONTRIBUTING.md | 补充风格规范和常见模式示例 |
| ready 的 PR 长期无人 review | 团队分工不明确 | 检查 PR 列表与 label | 设置定时通知和 review 轮值规则 |
| Agent 在 review comment 后无法继续迭代 | 新会话丢失上下文 | 检查 Agent 历史记录 | 把 review comment 合并进新的提示词再继续 |
遇到问题时不要急着怀疑 Agent 能力。alley-oop 工作流里，大部分失败都来自交接信息不足，而不是模型本身不行。先补齐交接信息，再考虑提高模型能力。
11. 最佳实践与团队推广建议
从个人实验到团队推广，alley-oop 的落地路径建议从最小闭环开始。
第一个建议是固定一套 PR 模板。不要每次让参与者自己临场写交接说明。模板内容可以短，但必须包含“当前完成了什么”“接下来交给谁”“完成标准是什么”。这套模板就是团队的协作记忆。
第二个建议是把 Agent 可见的规则文件纳入 code review。当 AGENTS.md 或 CLAUDE.md 发生变化时，它也应当走一次普通 PR，确保 Agent 的指导信息不会偏离项目现状。
第三个建议是在低风险任务上先验证。第一次尝试 alley-oop，尽量选没有复杂业务依赖的小任务，例如补充脚本测试、整理文档、重构一个无状态函数。跑通两三次后再放大到核心业务模块。
第四个建议是让 Agent 的交付可独立验证。每个 alley-oop PR 里，Agent 都应该在描述或提交中写明“我运行了哪条测试命令、结果是什么”。这样人类 review 时可以快速复现，而不是重新推导整个环境。
第五个建议是不要为了接力而接力。任务本身很小，比如只改一行配置，就不需要开 seed PR；Agent 在当前分支直接做也能控制风险。alley-oop 的收益在任务有足够复杂度时才成立。
第六个建议涉及权限与边界。给 Agent 的 token 应该只读优先，需要写入时再申请临时写权限。PR 合入永远保留人工确认环节，尤其是对生产代码的改动。AI Agent 可以承担大部分机械实现工作，但技术决策和发布责任仍然由人承担。
12. 总结
alley-oop pull request 工作流的精髓，不是某个新功能，而是一种更适应当前 AI 编程状态的协作协议：把一次复杂改动切割成多个可验证的小接力，用 PR 的既有机制承载上下文和交接状态。HumanLayer 的 Dex Horthy 展示这个思路，对于正在用 AI Agent 做真实开发的团队来说，与其说是“又一个 workflow 演示”，不如说是一套可以直接参考的工程协作范本。
建议你先找一个中等难度的内部功能分支，按上文的步骤建立 seed PR，创建 alley-oop 相关 label，在 AI 工具里把“读取 PR 描述、完成 TODO、保持改动边界”作为固定提示，跑完一轮再决定是否推广。最容易踩的坑是 seed 过于随便，把接口和边界写清楚之后，这套流程会比“让 Agent 自己猜需求”稳定得多。
