你的 AI Agent 需要一个计划吗？

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 (excluding the source line you already provided) here? Once I have it, I’ll translate it into Simplified Chinese while preserving the original formatting, markdown, and any code blocks.

规划：一个光谱，而非二元选择

真正的问题不是 是否 进行规划，而是 如何 以符合当前任务和工作风格的方式进行规划。

• 不同的开发者，不同的做法 – 有些人会先写详细的伪代码，另一些人则实践测试驱动开发，让架构自然演化。
• 团队习惯各异 – 有的团队在白板上绘制复杂图示，另一些则快速搭建原型以实现 “快速失败”，随后再重构。

如果在手动编码时规划是一个光谱，为什么在使用 AI 编码代理时就不能是光谱呢？

关于 AI 代理的 “计划模式” 的争论

业界对于是否需要专门的计划模式存在健康的讨论——它是必需的还是仅仅是额外负担。

• 你随时可以告诉代理 “先制定一个计划”。
• 有人认为，一个持久的计划应该保存在一个文件中，你可以查看、编辑，并与代码一起进行版本控制。

事实是，计划模式的价值不仅在于计划本身——更在于它为开发者创建的 思维模型和工作流。有时你希望代理立即执行；而在另一些情况下，你希望先看到它的思考过程，提供反馈，并在任何代码更改发生之前进行协作。

goose 兼容这两种理念，因为不同的情境需要不同的方法。

选择你的策略

面向架构师 – /plan 模式

当你在 goose CLI 中进入计划模式时，goose 会转为交互式对话，而不是立即执行。它会就以下内容提出澄清性问题：

• 技术栈偏好
• 认证需求
• 部署目标
• 错误处理策略

这种来回的交流会持续，直到 goose 获得足够的上下文来生成完整、可操作的计划。

• 自定义计划器配置 – 通过环境变量设置 GOOSE_PLANNER_PROVIDER 和 GOOSE_PLANNER_MODEL，可以为战略规划使用一种模型，为执行使用另一种模型。
• 检查点 – 在你批准计划后，goose 可以清除消息历史并依据计划行动，为任何代码更改提供一个干净的起点。

示例：我使用此方法将一个静态 Vite/React 项目迁移到 Next.js。goose 生成了一个包含 11 个阶段的迁移计划，每个步骤都有复选框（依赖更新、路由更改、组件边界等）。我说“是的，开始”后，它会有条不紊地执行，在每个阶段后提交代码。

了解更多关于创建计划 →

面向导演 – 指令文件

当你已经明确知道需要做什么时，可以自行编写计划并交给 goose。

1. 创建一个 Markdown 文件（例如 plan.md），内容包括：

   • 关于代码库的上下文
   • 需要修改的具体文件
   • 预期结果和验证步骤

2. 运行它：

goose run -i plan.md

• 如果你已经绘制了架构草图、编写了设计文档，或对代码库足够熟悉以至于 goose 不需要再提澄清性问题，这种方式非常适用。
• 指令文件也可以在 无头模式 下执行，用于 CI/CD 流水线或自动化（参见教程）。

核心理念：计划由你拥有，执行由 goose 完成。

了解更多关于运行任务 →

面向探索者 – 对话式上下文构建

此方法结合了三个 goose 功能：

1. 对话式规划 – 将 goose 当作配对伙伴。让它分析、解释、探索。在进入执行阶段前共同构建共享的思维模型。

2. Todo 扩展 – todo 扩展 会监测复杂度。当任务涉及多个步骤、文件或范围不确定时，它会自动创建检查清单、更新进度并勾选已完成项。

3. 项目规则 – 使用 goosehints 或 agents.md 等文件来编码持久化偏好、提交策略、测试要求和项目约定。这些规则在不需要每次重复的情况下引导代理行为。

这些功能共同让你在保持结构的同时进行随意、探索性的对话：

• 有意地限定范围提示 – 保持对话聚焦。
• Todo 扩展在出现复杂度时创建组织结构。
• 项目规则提供隐形脚手架，帮助做出更好的决策。

没有哪一种哲学适用于所有情形。 请选择最符合当前工作流的模式，让 goose 适应你。

# 你的偏好始终有效

这通常是我的工作方式。当我将一个遗留的 LLM 信用发放应用迁移到 **Next.js** 时，许多人对我的方法表示质疑。然而，在当时的上下文中，我正返回到八个月前构建的代码库，而我对它记忆模糊。该应用分散在两个仓库，我并不清楚各自负责的功能。事先编写 `plan.md` 文件只能是猜测。

于是我让 **goose** 分析这两个项目并进行探索...

了解他们的沟通方式。我有意地限定了我的提示：“只做前端，不调用 API”。我启用了 todo 扩展，知道它会在范围明确后创建结构。我还配置了项目规则，以自动处理提交。

这种方法比预先制定的计划需要更多的来回沟通，但这些提示并非浪费。它们构建了使实际迁移成为可能的上下文。当 goose 创建检查清单时，我们都明白需要做什么。

• 了解更多关于 todo 扩展 →
• 使用 goosehints 配置你的项目规则 →

你的风格是什么？

Goose 支持多种规划哲学，因为开发者并非只用单一模式：

• 架构师 在写代码前需要清晰的方案。
• 导演 需要掌控全局。
• 探索者 通过实际工作来发现计划。

这些方法没有高低之分；它们适用于不同的情境。同一位开发者可能在周一对一个范围明确的迁移使用 /plan 模式，而在周二对陌生代码库进行对话式上下文构建。

问题不在于是否要规划——而是哪种规划方式适合你今天的情境。

准备好用 Goose 尝试不同的规划方法了吗？
从我们的快速入门指南开始，或浏览上下文工程文档来搭建你的脚手架。