在 AI 辅助编程的赛道上，我们经历了从"Chat 窗口复制粘贴"到"IDE 内联补全（Copilot/Cursor）"的演变。而在 2026 年的今天，焦点已经转移到了 Agentic Workflow（代理工作流）------即 AI 不仅仅是写代码，而是接管整个从需求到交付的链路。
最近，我在项目中从老牌的 Spec Kit 迁移到了 Google 的 Gemini CLI Conductor。这次迁移给我的感觉，就像是从开手动挡汽车换到了搭载 FSD 的自动驾驶座驾。
Spec Kit 曾是我心中的架构神器，但 Conductor 的出现让我意识到：我们可能正在告别繁琐的 Prompt Engineering，真正进入"意图驱动"的时代。
1. 交互模式：从"小心翼翼写作文"到"与其聊需求"
这是我上手 Conductor 后最强烈的体感差异。
在使用 Spec Kit 时： 这更像是一场严格的"考试"。你需要非常清楚地知道自己想要什么。流程通常是：
Spec Kit 流程： Spec -> Plan -> Task -> Code
在这个链条中，如果你的 Spec（需求描述）写得不够完美，漏掉了边界条件或技术约束，后续生成的 Plan 和 Code 就会出错（经典的 Garbage In, Garbage Out）。你必须像个律师一样，把 Prompt 写得滴水不漏。
在使用 Conductor 时： 它像是一个经验丰富的产品经理（PM）。它具备极强的**"模糊容忍度"**。
你不需要一次性把需求描述得 100% 完美。当你给出一个模糊指令时，Conductor 不会像传统 LLM 那样瞎猜，而是主动反问。
场景还原： 我： "帮我给后台加一个导出 Excel 的功能。" Conductor： "收到。为了生成准确的方案，我有几个细节需要确认：
- 是导出全部数据，还是基于当前筛选条件？
- 数据量可能较大，是否需要采用异步任务 + 邮件通知的形式？
- 文件名格式有要求吗？"
这种**主动提问（Proactive Questioning）**的能力，直接将开发的心理负担降到了最低。它允许我不完美，因为它会帮我补全思考。
2. 启动成本：手写"宪法" vs 智能扫描
Spec Kit 是一个"重规则"的工具。在开始写代码前，你往往需要维护一份 constitution（宪法）或详细的技术规范文档。每次开启新项目，光是配置这些上下文就需要不少热身时间。
Conductor 则展示了什么叫"零配置入场"。 在初始化时，它会自动扫描你的项目代码库，智能分析出你的技术栈，并生成 tech-stack.md 和 product.md。它自己"看"得懂你用的是 Tailwind 还是 Bootstrap，是 MySQL 还是 MongoDB。你不需要告诉它规则，它从代码里学习规则。
3. 流程与文档：死板的模版 vs "活体"记忆
Spec Kit 的流程（Spec -> Plan -> Task -> Code）虽然严谨，但在处理小需求时显得过于冗长。有时候我只是想改个按钮颜色或加个简单的 API，却要被迫走完这一整套仪式感。
更致命的是文档腐烂。在 Spec Kit 模式下，代码改完了，Spec 文档往往就被遗忘了。久而久之，文档和代码通过两张皮。
Conductor 引入了"活体文档（Living Documentation）"的概念：
在我完成代码变更后，Conductor 会反向 提议更新 product.md 和 tech-stack.md。这意味着 Conductor 维护的是项目实时的记忆。
比如，当我让它添加了一个 SSE 实时通讯功能后，它在提交代码前，主动向我确认更新技术栈文档：
Based on the completed track, I propose the following updates to tech-stack.md:
--- a/conductor/tech-stack.md
+++ b/conductor/tech-stack.md
@@ -10,6 +10,10 @@
* **Tailwind CSS:** Utility-first CSS framework for rapid and consistent UI styling...
+
+## Communication & Real-time
++ **Server-Sent Events (SSE):** Standard browser API used for real-time one-way message streaming from the server to the client.
Do you approve these changes? (yes/no)
> yes紧接着，它还会同步更新产品文档，确保业务逻辑也被记录在案：
Based on the completed track, I propose the following updates to product.md:
--- a/conductor/product.md
+++ b/conductor/product.md
@@ -23,10 +23,10 @@
* **Agent Workspace (Unified Inbox):** A centralized dashboard...
- * **Intelligent Auto-Refresh:** The "Todo" list automatically refreshes every 5 seconds...
+ * **Intelligent Sorting & Refresh:** The "Todo" list is sorted by longest wait time to prioritize urgent needs...
+ * **Real-time Message Streaming (SSE):** Instant message delivery for the active session...这种机制保证了下一次任务开始时，AI 依据的是最新的上下文，而不是我上个月写下的旧文档。
4. 交付闭环：只管写代码 vs 手把手教验收
这是 Conductor 最让我惊喜的"Agent 特质"。
绝大多数 AI 编程工具（包括 Spec Kit）的终点是**"生成代码"**。代码生成完了，任务就结束了。至于代码能不能跑、怎么测，那是人类的事。
但 Conductor 关注的是**"交付"** 。它不仅生成代码，还会理解这个功能该如何被验证。在它的 Plan 执行完毕后，它会在终端里直接列出 Manual Verification Steps（手动验证步骤），手把手教我验收。
以下是我在做完一个即时通讯功能后的真实截图内容：
Tests passed. Now for manual verification: start the dev server, select a session...
Manual Verification Steps:
1. Start the development server: npm run dev
2. Open the application and select a session.
3. Simulate an incoming message (or wait for a real one if connected to backend).
4. Confirm that:
- If you are at the bottom of the chat, the view scrolls smoothly to show the new message.
- If you are scrolled up reading old messages, the view stays put (doesn't jump to bottom).
Does this meet your expectations? Please confirm with yes or provide feedback.
> yes, proceed.它甚至能感知到 npm run dev 这样的具体命令，并给出了"如果在底部就滚动，如果在看历史消息就不动"这样细腻的交互逻辑验证点。这种从"Coder"到"QA 工程师"的角色跨越，是传统工具不具备的。
总结：进入 Context-Driven Development (CDD) 时代
Spec Kit 依然是学习 DDD（领域驱动设计）和培养系统化思维的绝佳工具，它教会了我们"先思考，再编码"。
但在实战的效率战场上，Gemini CLI Conductor 代表了未来的方向。
它不再是一个冷冰冰的"代码生成器"，而是一个能够理解意图、主动澄清需求、自动维护记忆、并协助验收的智能体（Agent）。
- Spec Kit 适合： 从 0 到 1 构建复杂系统，需要极度严谨的架构控制时。
- Conductor 适合： 绝大多数日常开发，追求"心流"和极致效率时。
如果你厌倦了在 Prompt 里小心翼翼地"填空"，不妨试试 Conductor，体验一下把大脑从繁琐流程中解放出来的快感。
本文由mdnice多平台发布