Getting Started with Conductor for Gemini CLI

KDnuggets

KDnuggets2026年7月14日

Getting Started with Conductor for Gemini CLI

8.5内容质量

TL;DR · AI 摘要

Conductor是Gemini CLI的扩展，通过Context-Driven Development解决AI生成代码的上下文问题，提升开发效率。

核心要点

Conductor GitHub仓库已获得3,600+星标和284次Fork
CDD方法将项目上下文存储在Markdown文件中而非临时聊天窗口
传统AI编码流程被描述为'短暂、健忘且有点野蛮

结构提纲

按章节快速跳转。

§引言
揭示Gemini CLI在代码生成中的上下文缺陷问题。
·Conductor是什么
介绍Conductor作为Gemini CLI扩展的核心定位。
›CDD方法论
解释Context-Driven Development的工作原理与文件存储机制。
›GitHub数据
展示Conductor开源项目的社区反响数据。

思维导图

用一张图看清主题之间的关系。

查看大纲文本（无障碍 / 无 JS 友好）

Conductor for Gemini CLI
- 核心特性
  - Context-Driven Development (CDD)
- GitHub数据
  - 3,600+ stars
- 与传统对比
  - 状态化上下文管理

金句 / Highlights

值得收藏与分享的关键句。

Conductor GitHub repository has accumulated over 3,600 stars and 284 forks.
— 第 2 段
⬇︎ 下载 PNG 𝕏 分享到 X
The agent reads those files every time it touches your project.
— 第 2 段
⬇︎ 下载 PNG 𝕏 分享到 X
the model is 'transient, forgetful, and a bit of a cowboy.'
— 第 3 段
⬇︎ 下载 PNG 𝕏 分享到 X

#AI#Gemini CLI#Conductor#开发工具

打开原文

通过 Conductor 为 Gemini CLI 入门 - KDnuggets

publ: 2026年7月14日

博客热门文章

主题 AI 职业建议计算机视觉数据工程数据科学语言模型机器学习 MLOps NLP 编程 Python SQL

数据集

活动

资源快速参考指南推荐技术简报

广告

加入新闻通讯

#header end

/ad_wrapper

通过 Conductor 为 Gemini CLI 入门

Conductor 是一个为 Gemini CLI 构建的扩展工具，旨在解决上下文问题。在这里了解所有相关信息。

作者：

Shittu Olumide，技术内容专家，2026年7月14日，编程

# 介绍

当你打开 Gemini CLI 并描述需要构建的功能时，代理会立即开始编写代码。没有提问，没有澄清，也没有计划。十分钟后，你已经在四个文件中有了上百行的实现代码，但这些代码与你的实际架构完全不符，因为代理从未了解过你的架构。它只是做了看似合理的猜测。其中一些是正确的，但大部分不是。现在你正试图理清这些由 AI 生成的代码，同时疑惑如果自己动手编写是否更快。

这不是 Gemini 的问题，而是上下文的问题。代理不知道你在构建什么，选择了哪些库，你的编码标准是什么，或者这个功能实际上应该实现什么。每次会话都从零开始。

Conductor 于 2025 年 12 月 17 日以预览版发布，是为了解决这个问题而构建的 Gemini CLI 扩展工具。它引入了一种名为基于上下文开发（CDD）的工作流程，这是一种结构化方法，将项目上下文、规格和实现计划存储在仓库中的 Markdown 文件中，而不是临时的聊天窗口中。每次代理接触你的项目时，都会读取这些文件。你的风格指南、技术栈决策、产品目标——所有内容都会持久保存并与代码一起传递。

自发布以来，Conductor 的 GitHub 仓库已获得超过 3,600 个星标和 284 个分支。2026 年 4 月，一篇 Google Codelab 文章详细介绍了如何使用 Conductor 完成一个完整的绿地项目。本文将涵盖你从零开始到运行第一个实现轨道所需的所有内容。

# Conductor 究竟是什么

在介绍命令之前，理解 Conductor 所基于的模型会有所帮助，因为它会改变你对 AI 协助开发的看法。

标准的 AI 编码工作流程是无状态的。你打开一个会话，描述你的需求，代理开始工作，然后你关闭会话。下次打开时，代理对之前构建的内容、原因或下一步毫无记忆。正如一位 Google Cloud 开发人员所说，这个模型是“短暂的、健忘的，有点像牛仔。”

Conductor 通过将上下文作为托管工件来解决这个问题。你不需要每次会话都重新描述项目，而是维护一组永久执行此任务的 Markdown 文件。代理在每次运行时都会读取这些文件。你的编码标准始终处于加载状态，产品目标始终在范围内，功能计划始终可见。

Google 的公告文章引用了本杰明·富兰克林的名言“不规划即规划失败”来描述这一理念，这种定位依然适用。Conductor 的工作流程是：首先构建上下文，然后定义功能规格，规划实现，最后编写代码。每次都是按照这个顺序进行。

架构上，Conductor 由三个协同工作的层级组成。

命令层是您交互的部分 —— Gemini CLI 中包含六个斜杠命令。工件层是您仓库中的 conductor/ 目录，包含保存项目状态的 Markdown 和 JSON 文件。版本控制层是 Git，Conductor 使用 Git 创建每个任务的提交记录并支持回滚功能。

这适用于从零开始的新项目（greenfield projects）和已有代码库的项目（brownfield projects）。需要特别强调的是对已有项目的支持，因为大多数教程只演示全新项目。当您在现有仓库中运行 /conductor:setup 时，Conductor 会分析您的代码库，遵循您的 .gitignore 和 .geminiignore 规则，并推断出您的技术栈和架构 —— 您无需手动填写上下文信息，Conductor 可自行推断。

# 先决条件和安装

在安装 Conductor 之前，您需要准备三样东西。

必须安装并正常运行 Gemini CLI。使用 npm 全局安装：

code

# 全局安装 Gemini CLI
npm install -g @google/gemini-cli

# 验证安装
gemini --version

如果遇到权限错误，请使用 nvm 等 Node 版本管理器，而不是以 root 身份运行。安装完成后，重启终端以确保 gemini 可执行文件在 PATH 中。

Gemini CLI 认证需要 Google API 密钥或 Vertex AI 配置。首次运行 gemini 时，系统会提示您进行认证。选择 Vertex AI 并按照指南设置 GOOGLE_API_KEY 环境变量，或完成浏览器端的 OAuth 流程（用于个人使用）。

项目目录中必须初始化 Git。Conductor 创建每个任务的提交记录并依赖 Git 实现回滚功能。如果是新项目：

code

# 如果尚未初始化，创建新 Git 仓库
mkdir my-project && cd my-project
git init
git commit --allow-empty -m "Initial commit"

完成以上步骤后，安装 Conductor：

code

# 安装 Conductor 扩展
gemini extensions install https://github.com/gemini-cli-extensions/conductor

# --auto-update 标志可自动更新 Conductor 到新版本
# 推荐大多数用户使用
gemini extensions install https://github.com/gemini-cli-extensions/conductor --auto-update

安装过程会从 GitHub 仓库下载扩展，注册六个 Conductor 命令，配置 GEMINI.md 上下文文件作为入口点，并设置 /conductor 为计划目录。整个过程只需几秒钟。

通过启动 Gemini CLI 并输入 /conductor 验证是否安装成功：

code

gemini

在 Gemini CLI 会话中：

code

/conductor

您应该看到完整的子命令列表：setup、newTrack、implement、status、revert 和 review。如果看到这些命令，说明已准备就绪。

# 使用 /conductor:setup 初始化项目

每个项目只需运行一次。这是构建所有其他功能依赖基础的命令。在 Gemini CLI 会话中，从项目目录运行：

code

/conductor:setup

Conductor 会立即开始分析项目。对于已有项目，它会扫描代码库以推断当前使用的技术 —— 遵循 .gitignore 规则避免处理 node_modules 或 __pycache__ 等包含大量 token 的目录。对于新项目，它会询问您描述正在构建的内容。

无论哪种情况，它都会引导您完成问答流程，以填充在新创建的 conductor/ 目录中生成的六个工件：

code

conductor/
├── product.md                 # 产品愿景、用户群体、目标、关键特性、成功标准
├── product-guidelines.md      # UI 标准、语气规范、错误处理行为
├── tech-stack.md              # 使用语言、框架、数据库、基础设施
├── workflow.md                # TDD 优先级、提交策略、验证协议
├── code_styleguides/          # 按语言划分的样式指南（根据检测到的语言自动生成）
│   ├── python.md
│   ├── typescript.md
│   └── ...
└── tracks.md                  # 所有轨道的主注册表（初始为空）

每个文件都有特定作用。product.md 回答了“我们正在构建什么以及为谁构建”的问题。tech-stack.md 确保代理永远不会建议超出技术栈范围的库或模式。workflow.md 用于定义是否采用测试驱动开发（TDD）、提交策略的样式，以及在阶段推进前需要的验证步骤。code_styleguides/ 包含按语言划分的指南，Conductor 提供了预填充模板，你可以在此基础上进行自定义。

初始化完成后，你将在项目中看到 conductor/ 目录。提交它：

code

# 将 conductor 上下文提交到你的仓库
git add conductor/
git commit -m "chore: 初始化 Conductor 上下文驱动开发"

从这一刻起，任何克隆仓库并打开 Gemini CLI 的队友都能立即获得完整的项目上下文——无需任何入职对话。

# 通过 /conductor:newTrack 启动新功能

轨道是 Conductor 表示工作单元的方式。一个功能、一个错误修复、一个架构变更——对应一个轨道。轨道为代理提供了明确的工作范围，这是防止其偏离目标的核心机制。

通过描述你想要构建的内容来启动一个轨道：

code

/conductor:newTrack "在设置页面添加深色模式切换功能，并将偏好设置持久化到 localStorage"

你也可以不带参数调用 /conductor:newTrack，当 Conductor 提示时交互式描述功能。

Conductor 会读取你的描述，从 conductor/ 中读取完整的项目上下文，并在新创建的 conductor/tracks/<track_id>/ 目录中生成三个文件：

code

conductor/tracks/
└── dark_mode_20260614/
    ├── spec.md           # "是什么和为什么" —— 需求、目标、技术约束、不在范围内的内容
    ├── plan.md           # 按阶段划分的任务级实施清单
    └── metadata.json     # 轨道 ID、创建日期、当前状态

轨道 ID 的格式为 shortname_YYYYMMDD，例如 2026 年 6 月 14 日创建的深色模式轨道为 dark_mode_20260614。这使得轨道在文件系统中按时间顺序排列。

spec.md 包含规格说明：该功能解决的问题、目标、技术要求，以及明确排除的范围。排除范围部分比看起来更重要——它能防止代理在应该发布功能时过度完善功能。

plan.md 是实施清单，按阶段组织。一个深色模式功能可能如下所示：

code

# 实现计划 - 暗黑模式切换

## 第一阶段：基础构建
- [ ] 任务：在localStorage模式中添加`theme`键，并在项目README中进行文档说明
- [ ] 任务：创建`useTheme`钩子，用于读取/写入`theme`值并默认使用系统偏好设置
- [ ] 任务：为`useTheme`编写单元测试--验证默认行为、localStorage读取、localStorage写入
- [ ] 任务：执行者 - 用户手册验证'基础构建'（工作流中的协议在workflow.md中）

## 第二阶段：UI组件
- [ ] 任务：构建带有可访问切换按钮的`ThemeToggle`组件（包含aria-label、键盘支持）
- [ ] 任务：根据`useTheme`提供的当前主题值应用条件CSS类
- [ ] 任务：为`ThemeToggle`编写组件测试--验证正确渲染、点击时触发切换
- [ ] 任务：执行者 - 用户手册验证'UI组件'（工作流中的协议在workflow.md中）

## 第三阶段：设置页面集成
- [ ] 任务：将`ThemeToggle`导入设置页面组件
- [ ] 任务：验证偏好设置在页面刷新和新浏览器标签页中能持续生效
- [ ] 任务：为启用暗黑模式的完整设置页面编写集成测试
- [ ] 任务：执行者 - 用户手册验证'设置页面集成'（工作流中的协议在workflow.md中）

在运行/conductor:implement前请先阅读此计划。这是Conductor设计的人机协作关键时刻。如果阶段划分有误、任务缺失或范围超出预期，请立即编辑plan.md。一旦执行implement命令，Conductor将根据此计划进行代码提交。中途更改方向是可能的，但比在此处及时发现成本更高。

使用/conductor:implement进行实现

确认计划无误后：

code

/conductor:implement

这正是Conductor的价值所在。它会读取plan.md，选取第一个未勾选的任务开始执行。当任务开始时，会将方括号从[ ]改为[~]（进行中）。任务完成后，会将方括号改为[x]并创建Git提交——每个完成的任务对应一个提交，而非每个阶段或会话。

随着Conductor工作，你会看到提交记录逐渐累积：

code

git log --oneline

输出示例：

code

a3f9c12 feat(theme): 为设置页面暗黑模式编写集成测试
b7e2d45 feat(theme): 将ThemeToggle导入设置页面
c1a8f90 feat(theme): 添加带aria-label的可访问切换按钮
d4b3e21 feat(theme): 创建带条件CSS的ThemeToggle组件
e5c6d78 test(theme): 为useTheme钩子编写单元测试
f7d9a34 feat(theme): 创建带localStorage持久化的useTheme钩子

每个阶段结束时，Conductor会暂停等待人工验证。在确认当前阶段正常工作前，不会进入下一阶段。这正是工作流中"验证优于承诺"原则的体现--代理不会声称工作正常，必须在计划推进前由你亲自验证。

如果你使用的是TDD工作流（在workflow.md中配置），Conductor会自动遵循测试驱动开发的循环：先编写测试、确认失败、实现代码、确认通过，然后进入下一个任务。你无需告诉它这么做；工作流文件会自动处理这些步骤。

Conductor 的状态会在任务之间保存到磁盘，这意味着你可以在任何时间点停止工作，合上笔记本电脑，切换设备，第二天回来后再次运行 /conductor:implement。它会从第一个未检查的任务继续执行。实现过程并不保存在聊天记录中，而是保存在 plan.md 文件中。

如果需要在实现过程中更改方向，可以直接编辑 plan.md 文件。添加任务、删除任务、重新排序阶段。Conductor 在每次运行时都会重新读取该文件，因此你的修改会立即生效。

当所有阶段都经过验证且所有任务都标记完成时，Conductor 会提供归档轨迹的选项——将 conductor/tracks/dark_mode_20260614/ 移动到 conductor/tracks/archive/dark_mode_20260614/，并更新 tracks.md 以标记为完成。你的 Git 历史记录会保留完整的实现记录。

# 支持命令

三个核心命令——setup、newTrack、implement——涵盖了主要工作流程。这四个命令处理所有相关操作。

#### // /conductor:status

在任何时候运行此命令，可以查看所有活跃轨迹项目的当前状态：

code

/conductor:status

Conductor 会读取 conductor/tracks.md 和每个活跃轨迹的 plan.md 文件并返回摘要：

code

当前日期/时间：2026年6月14日，星期六
项目状态：🟡 活跃

活跃轨迹：
  * dark_mode_20260614 -- 3阶段中的第2阶段 | 7/12任务完成（58%）
  * api_auth_20260610  -- 4阶段中的第1阶段 | 3/5任务完成（60%）

下一步所需操作：
  * 运行 /conductor:implement 继续 dark_mode_20260614（当前轨迹）

当你在休息后重新开始工作时，需要记住自己之前的位置，就运行这个命令。

#### // /conductor:revert

当出现问题需要撤销工作时：

code

/conductor:revert

Conductor 对 Git 的理解方式与原始 git revert 不同。它理解工作逻辑单元——轨迹、阶段、单个任务——而不是提交哈希。如果你想撤销某个轨迹的最后一个阶段，Conductor 会识别属于该阶段的提交（使用其按任务的提交结构），并干净地撤销这些提交。它还会更新 plan.md 以取消勾选受影响的任务，这样你可以重新运行 /conductor:implement 来重新执行工作。

从实际操作角度看，当代理在三个阶段的14次提交中修改了11个文件时，通过提交哈希回滚是一个痛苦的手动过程。Conductor 会为你处理这些考古工作。

#### // /conductor:review

在实现完成后、打开拉取请求之前：

code

/conductor:review

Conductor 会读取你完成的 plan.md 和 conductor/product-guidelines.md，并执行质量检查。它会检查计划中指定的内容与实际实现之间的偏差，以及产品指南的违规情况——不一致的错误处理、缺失的可访问性属性、样式指南违规等。

可以把它看作一个AI代码审查者，它已经阅读了你完整的的产品规格，并确切知道该功能应该实现什么。输出结果是一个审查报告，你可以在代码合并前进行处理。

#### // 检查令牌使用情况

Conductor 的上下文驱动方法会在每次命令中读取项目文件，这会增加令牌消耗——特别是在设置和规划阶段的大型项目中。使用以下命令检查当前会话使用情况：

code

/stats model

# Conductor 如何为团队工作

Conductor 工作流程中最常被低估的部分是当你提交 conductor/ 目录时会发生的事情。

Conductor 创建的每个文件 —— product.md、tech-stack.md、workflow.md、样式指南、每条轨道的规范和计划 —— 都会像其他文件一样存储在你的代码仓库中。当同事拉取仓库时，他们可以立即获得完整的项目上下文。当他们打开 Gemini CLI 并运行 /conductor:status 时，可以查看所有活跃的轨道以及每个轨道在实施计划中的具体位置。

这改变了新成员的入职体验。新加入项目的开发者不需要花两小时了解技术栈选择、编码标准或正在开发的功能。他们只需阅读 conductor/product.md 和 conductor/tech-stack.md，运行 /conductor:status，就能立刻掌握项目全貌。

一致性带来的好处同样显著。每个 AI 协助的项目贡献都遵循相同标准，因为每个代理会话都会读取相同的上下文文件。一个开发者的 Conductor 会话生成的代码风格与另一个开发者的完全一致，因为两个会话都锚定在相同的 code_styleguides/ 目录中。这种“团队和谐”特性在项目规模扩大时更难维持 —— Conductor 通过结构性的工作流程设计，而非依赖开发者手动执行，来实现这一特性。

# 完整操作流程：添加暗黑模式切换功能

以下是 Conductor 在具体功能上的完整工作流程示例。请将其作为你第一个真实项目轨道的参考模板。

#### // 步骤 1：从项目目录打开 Gemini CLI

code

cd your-project
gemini

#### // 步骤 2：如果尚未为该项目设置 Conductor，请先运行初始化

回答引导式问题。完成设置后，提交 conductor/ 目录。

#### // 步骤 3：创建轨道

code

/conductor:newTrack "为设置页面添加暗黑模式切换功能，将用户偏好持久化存储到 localStorage，并在首次访问时默认使用系统偏好"

Conductor 会在 conductor/tracks/dark_mode_20260614/ 目录下生成 spec.md 和 plan.md 文件。

#### // 步骤 4：在执行任何操作前阅读计划

在编辑器中打开 plan.md。阅读所有任务。确认各阶段逻辑合理。如果发现任何问题 —— 缺失任务、不应该存在的阶段、范围过广 —— 现在就修改文件并保存。Conductor 在每次运行时都会重新读取该文件，因此你的修改会立即生效。

#### // 步骤 5：执行实现

观察 Conductor 如何逐步完成任务并创建提交记录。当它完成第一阶段后，会暂停并要求你手动验证。测试工作成果。确认通过后，Conductor 会进入第二阶段。

#### // 步骤 6：随时查看进度

#### // 步骤 7：审查已完成的实现

处理审查中发现的任何问题。然后创建拉取请求，包含整洁的实现代码、完整的测试套件、按功能任务组织的 Git 历史记录，以及明确记录所构建功能及其原因的规范文档。

从初始化到审查的完整流程对后续每个功能都可重复使用。conductor/ 目录会作为活生生的记录持续增长，记录已构建的内容、每个决策的原因以及项目遵循的标准。

# 开始前需要了解的几个要点

令牌消耗是真实存在的。Conductor 在每次命令执行时都会读取你的项目上下文文件。对于小型项目，这可以忽略不计。但对于包含大量 tracks 的大型遗留项目，尤其是在设置和规划阶段，这种消耗会显著增加。使用 /stats 模型来监控使用情况，并定期归档已完成的 tracks，有助于保持 active tracks.md 的精简性。

--auto-update 标志值得使用。Conductor 处于预览阶段，自 2025 年 12 月以来频繁发布更新。启用 --auto-update 标志后，你可以自动获得改进功能，无需手动重新安装。

上下文的质量决定了输出的质量。这是上下文驱动开发的另一面。模糊的 product.md 会导致规划模糊，未指定测试框架的 tech-stack.md 会产生猜测性计划。你在设置工件上投入的时间，会在后续每个 tracks 中获得回报。

Conductor 不会取代代码审查。/conductor:review 能有效捕捉明显的偏离和风格问题，但它不能替代代码合并前的人工审查。请将其视为初步检查，而非最终审核关卡。

# 结论

Conductor 所代表的转变并不主要关乎速度。在编码前先编写规范和计划，第一小时确实比直接进入实现更慢。但其回报在于第一小时之后发生的一切——能够跨会话保持进度的代理，可以接续你工作进度的队友，以及因所有贡献者基于相同上下文工作而显得连贯的代码库。

Google 对 Conductor 的定位是“将文档视为真实来源”并“赋予 Gemini 作为工程团队真正延伸的能力”。这个描述准确，但更实际的思考方式是：Conductor 使代理的行为变得可预测。当代理编写可部署代码时，可预测性正是你所需要的。

设置过程只需一次会话。它创建的上下文将超越之后的所有会话。对于一个仅需一次安装命令即可尝试的工具，这种投入产出比非常可观。

立即安装，下次项目中运行 /conductor:setup，看看在编写第一行代码之前，计划会是什么样子。

#### // 资源

Conductor GitHub 仓库

Google 开发者博客 — Conductor 宣布

Google Codelab — 使用 Gemini CLI Conductor 规划和构建应用

Shittu Olumide 是一位软件工程师和技术作家，热衷于利用前沿技术创作引人入胜的叙述，注重细节并擅长简化复杂概念。你也可以在 Twitter 上找到 Shittu。

Getting Started with Conductor for Gemini CLI

TL;DR · AI 摘要

核心要点

结构提纲

思维导图

金句 / Highlights

通过 Conductor 为 Gemini CLI 入门 - KDnuggets

通过 Conductor 为 Gemini CLI 入门

# 介绍

# Conductor 究竟是什么

# 先决条件和安装

# 使用 /conductor:setup 初始化项目

# 通过 /conductor:newTrack 启动新功能

使用/conductor:implement进行实现

# 支持命令

# Conductor 如何为团队工作

# 完整操作流程：添加暗黑模式切换功能

# 开始前需要了解的几个要点

# 结论

更多相关内容

最新文章

热门文章