我们如何使用 goose 来维护 goose
I’m happy to translate the article for you, but I’ll need the full text you’d like translated. Could you please paste the content (or the portion you want translated) here? I’ll keep the source line exactly as you provided and preserve all formatting, markdown, and technical terms.
Goose 🦆 待办事项求解器
随着 AI 代理能力的提升，越来越多的人有能力编写代码并为开源项目做贡献。上限似乎比以往任何时候都更高。这对生态系统来说是一个净正面影响，但它也改变了维护者的日常现实。
像 goose 团队这样的维护者面临着不断增长的拉取请求和 issue——往往比他们实际能够处理的速度更快。
我们接受了这种现实，并让 goose 为自己的待办事项工作。
注意： 我们实际上使用了 goose pre‑1.0 来帮助我们构建 goose 1.0。最初的 goose 是一个 Python CLI，但我们需要快速转向 Rust、Electron 和 MCP‑native 架构。Goose 帮助我们完成了这一转变。将其用于 triage issue 和审查更改感觉是自然而然的延伸，于是我们将 goose 直接嵌入到 GitHub Action 中。
致谢： 该 GitHub Action 工作流由 Tyler Longwell 构建，他把我们手动探索的想法转化为任何维护者只需一条评论即可触发的工具。
GitHub Action 之前
在 Action 出现之前，goose 团队已经在使用 goose 来加速我们的 issue 工作流。下面是一个真实案例。
- 有用户在 Discord 上询问为什么 Ollama 模型在聊天模式下会报错。
- 我没有自己去代码库里挖掘，而是让 goose 探索代码，找出根本原因，并向我解释。
- 然后我让 goose 使用 GitHub CLI 打开一个 issue。
在同一次会话中，goose 报告 95 % 的置信度，表示它知道如何解决问题。改动很小，于是我让 goose 打开一个 PR，该 PR 当天就被合并了。
goose 之前的工作流是怎样的
- 步骤碎片化——我会提出澄清性问题，在 GitHub 上搜索相关 issue，拉取最新代码，grep 文件，阅读逻辑，并形成假设。
- 两种可能的结果
- 编写详细的 issue 并加入开发者的待办列表（其他人以后需要切换上下文）。
- 自己尝试修复，往往会花费更多时间并在代码审查过程中产生来回讨论。
无论哪条路径，都可能跨越数小时甚至数天。低优先级的问题可能会被遗漏，停留在 Discord 或 GitHub 评论中，最终被遗忘。
有了 goose，整个过程就压缩成一次对话。
本地工作流是可行的，但当我在本地使用 goose 解决问题时，我仍然是驱动者：我会暂停手头的工作，打开会话，粘贴问题上下文，引导 goose 完成修复，运行测试，然后打开 PR。
扩展 GitHub Action
GitHub Action 会将整个流程压缩为一条评论。
- 团队成员看到 issue 并评论
/goose。 - Goose 在容器中启动，读取该 issue，探索代码库，执行验证，并打开一个 draft PR。
- 维护者得到的是一个已有提议的解决方案，而不是空白的起点。
真实案例 – Issue #6066
- 用户报告 goose 总是默认 2024，即使正确的日期时间已经在上下文中。
- 该 issue 维持了两天。
- Tyler 在凌晨 1:59 看到后，评论
/goose solve this minimally，随后回到自己的事务（大概是睡觉）。 - 14 分钟后，goose 打开了 PR #6101。
维护者的角色从 实现 转变为 审阅。开源项目的瓶颈很少是“有人能写这段代码”，而是“有人在拥有足够上下文的情况下抽出时间来写这段代码”。Action 将这两个约束解耦：任何维护者都可以在不深入了解代码库的情况下触发修复尝试。
好处
| 好处 | 描述 |
|---|---|
| 速度 | 积压中既有功能请求、复杂 bug，也有快速修复。Action 让你只需指向一个 issue 并说“试试这个”，而无需花整整一个下午。 |
| 成本 | 如果 goose 失败，你只会损失几分钟的计算资源；如果成功，你可以节省数小时的工作时间。 |
| 响应性 | 当用户提交 issue #6232 报告斜杠命令未处理可选参数时，维护者快速评论 /goose can you fix this。不到一小时就出现了包含修复和四个新测试的 draft PR。即使 PR 需要进一步调整，贡献者也能感受到项目的动能。 |
工作原理
维护者在 issue 下的评论中使用 /goose 加提示词来召唤 Goose。GitHub Actions 会启动一个已安装 Goose 的容器，将 issue 的元数据传入，并让 Goose 工作。如果 Goose 产生了更改且验证通过，工作流会打开一个 draft pull request（草稿拉取请求）。
工作流使用一个 recipe，该配方定义了多个阶段，以确保 Goose 真正完成任务且不超出我们的要求。
| 阶段 | Goose 的操作 | 为什么重要 |
|---|---|---|
| Understand（理解） | 读取 issue 并将所有需求提取到文件中 | 强制 AI 在编写代码前先明确“完成”应是什么样子 |
| Research（调研） | 使用搜索和分析工具探索代码库 | 防止对不熟悉的代码进行盲目编辑 |
| Plan（规划） | 决定实现方案 | 在实现前捕获架构错误 |
| Implement（实现） | 进行最小化改动 | 保持 diff 小且易于审查 |
| Verify（验证） | 运行测试 / 代码检查工具 | 确保更改不会破坏已有功能 |
| Report（报告） | 发布摘要并打开草稿 PR | 为维护者提供明确的交接点 |
TL;DR
- 之前：Issue → 手动分流 → 零散调试 → PR 速度慢。
- 现在：Issue → 评论
/goose→ 自动分流、修复并生成草稿 PR → 维护者审查。
由 Goose 驱动的 GitHub Action 让开源项目在不牺牲质量或响应速度的前提下，实现维护工作流的规模化。 🚀
概览
下面描述的工作流帮助 goose 在解决问题时安全且透明地运行。
关键步骤
| 阶段 | 目的 |
|---|---|
| Verify（验证） | 运行测试和代码检查，捕获明显的错误，避免在人工审查 PR 之前出现问题。 |
| Confirm（确认） | 重新阅读原始 issue 和需求，防止在完成一半任务后误报成功。 |
工作原理
- 工作流文件 为 goose 提供了 TODO 扩展 的访问权限（
https://block.github.io/goose/docs/mcp/todo-mcp）。 - 阶段 告诉 goose 要做什么。
- TODO 帮助 goose 记住 正在做的事情。随着 goose 阅读代码库并构建解决方案，它的上下文窗口会被填满，早期的指令可能会被压缩或丢失。TODO 则会持久保存，goose 随时可以检查已完成的工作和剩余任务。
安全防护
- 只有授权用户才能调用
/goose。 - 工作流限制了 goose 可以修改的文件范围。
- 每个 PR 必须经过维护者审查并批准后才能合并。
为什么使用 Goose 来维护 Goose？
- 这迫使我们诚实地面对工具的能力。
- 如果代理在此处无法生成可合并的 PR，我们会立刻发现。
愿景
我们的目标不是让 AI 替代维护者，而是希望形成一种工作流，使维护者能够：
- 指出一个问题。
- 说 “尝试这个”。
- 收到一个具体的方案（而不是空白编辑器）。
如果这种方式成为常态，开源项目就可以以一种根本不同的方式实现规模化。
公开访问
GitHub Action 工作流 是公开的，任何人都可以在自己的 CI 流水线中探索此模式。