工具栈与工作流
工程化的氛围编程，关键在于工具与方法论的协同，把灵感转化为可复用的交付流水线。
本节给出一套可复制的“氛围编程默认栈”，目标不是罗列工具，而是把意图驱动开发落实为稳定的工程流水线：IDE 负责工程体验，CLI Agent 负责吞吐，Promote Agent 负责对齐，Skills 负责复利，MCP 负责把外部能力协议化接入。本文推荐快照截至 2026 年 8 月。
默认工具选择：VS Code / Cursor + CLI Coding Agent
在实际工程实践中，集成开发环境（IDE, Integrated Development Environment）最核心的价值在于审阅、调试与定位，而不是“堆 AI 入口”。因此，建议将“大规模改动”交由 CLI 执行器完成，把 IDE 作为工程控制台。
编辑器（工作台）
以下是主流编辑器的推荐理由：
- VS Code：默认首选。适合工程化、可扩展、团队协作与多仓库并行。
- Cursor：强推荐的第二工作台。适合更紧耦合的一体化 AI 编程体验与快速探索。
执行器（主力在 CLI）
在氛围编程中，CLI Agent 是批量改动与自动化的主力：
- Claude Code：主力执行器，适合多文件重构、补测试、批量迁移、按计划分步提交。
- OpenCode：作为补充执行器，便于在不同工作流与模型之间切换。
- Codex（Cloud）：适合把任务“委派给云端 agent”并行推进，尤其是仓库级操作与重复性工程任务。
2026 年中的编程智能体格局
进入 2026 年，编程智能体的工具格局已明显收敛为“三极”：Claude Code 作为 CLI 智能体的事实标杆，凭借多文件重构与长任务的稳定性占据执行主力位置；Cursor 作为 AI 原生 IDE，以仓库级感知与 Composer/Agent 模式承包“边写边改”的交互体验；Google 的 Antigravity CLI 则在承接 Gemini CLI 的用户与生态后，成为低门槛入场与高吞吐探索的可选项。一个值得注意的结构性变化是：CLI 智能体已成为主流交付形态，而 IDE 正从“AI 入口”退回到“审阅与控制台”的角色——这正是本节默认栈把大规模改动交给 CLI 执行器的背景。
需要特别留意 Google 阵营的更替：曾以免费大额度流行的 Gemini CLI 已于 2026 年 6 月 18 日停止服务，Google 将个人版（免费/AI Pro/AI Ultra）用户整体迁移到 Antigravity CLI，仅 Enterprise 版继续独立支持。选型时应直接面向 Antigravity 生态，避免在新项目中接入 Gemini CLI。
在“三极”之外，云端委派已从可选项升级为标配。OpenAI Codex 把任务并行委派给云端 agent，适合仓库级批量操作与重复性工程任务；Antigravity（2025 年底发布的 Agent IDE，2026 年中与 CLI 线合并为统一的 Antigravity 体系）补齐了“委派与并行”场景。它们与本地 CLI 形成互补：本地负责高交互的精细改动，云端负责可以丢出去并行跑的长任务。
与此同时，Agent Skills 生态正在标准化。Anthropic 推动的 Skills 规范，被 Cursor、Goose、OpenCode 等主流工具快速适配，能力的封装方式正从“单工具私有格式”走向“跨工具可复用的标准”。这意味着同一个 Skill 可以在不同智能体之间迁移，而不是被锁死在某一家工具里（与本书 Skills 一节“把个人技能体系产品化”的主张直接呼应）。
最后是选型逻辑的变化：评估基准已趋于饱和。SWE-bench Verified 被主流模型做到约 95% 之后已难以分出高下，OpenAI 也已公开放弃将其作为前沿编码能力的评估指标。结论是：选型不能再依赖公开榜单，而要回到自有工作流的真实任务回归评测——用你自己的仓库、自己的重构与修 bug 任务，去做带回归的横向对比。
下表汇总了 2026 年中主流编程智能体的速览，便于快速对照：
| 工具 | 形态 | 主力模型 | 适合场景 |
|---|---|---|---|
| Claude Code | CLI 智能体 | Claude Sonnet/Opus 系列 | 多文件重构、长任务、批量迁移、按计划分步提交 |
| Cursor | AI 原生 IDE | 多模型可选 | 仓库级感知、Composer/Agent 模式、快速交互探索 |
| Antigravity CLI | CLI 智能体 | Gemini 3 系列 | 低门槛入场、大额度高吞吐探索（承接自 Gemini CLI） |
| OpenAI Codex | 云端并行 agent | GPT-Codex 系列 | 云端委派、仓库级批量与重复性工程任务 |
| Google Antigravity | Agent IDE | Gemini 系列 | 委派与并行场景、可视化任务编排 |
| OpenCode | CLI 智能体（开源） | 多模型可选 | 跨工作流/模型切换、自主可控的补充执行器 |
注：Gemini CLI 已于 2026 年 6 月 18 日停服（Enterprise 版除外），其定位由 Antigravity CLI 承接。
模型推荐：分层选型，而不是“一把梭”
模型选择应以工程交付的稳定性与可控性为核心，以下是截至 2026 年 8 月的推荐快照：
- 海外优先：Claude Sonnet 4.5 / Opus 4.6+、ChatGPT GPT-5.3-Codex
作为通用主力模型池，覆盖规划、重构、评审与复杂任务编排；编程与长时 Agent 任务可优先 GPT-5.3-Codex。 - 国产兜底：智谱 GLM-5.2（MIT 许可，兼容 Claude Code 等主流编程工具）、Kimi K2.7 Code
在国内环境的可用性、成本与合规约束下，作为可落地模型池的关键选项。
默认策略建议：主力用海外模型做“高吞吐与高质量”，国产模型承担“可用性兜底与成本平衡”。
VS Code 里需要一个 Promote Agent：把“你怎么做事”固化为控制面
在 IDE 工作流中，建议显式定义一个 Promote Agent（可以是自定义提示词/规则集合，也可以是工具内置的 persona 配置）。Promote Agent 的职责不是写代码，而是做三件事：
- 把需求压缩为可执行规格：明确目标、边界、验收与风险。
- 选择执行器与推进策略：如 Claude Code / OpenCode / Codex，确定分步执行方案。
- 强制工程护栏：确保产出可运行命令、回归用例、可回滚提交。
关键主张：在氛围编程中，应将任务编排为可验收的工程产物，而不是反复与模型对话直到满意。
Skills：把个人能力规范化，减少每次重新对齐的成本
Skill-first 是氛围编程进入工程化阶段的分水岭。将个人擅长的能力沉淀为可调用、可复用、可回归的技能单元，有助于提升协作效率与资产复利。
建议至少固化以下三类 Skills（以产出形态为划分）：
工程交付类（把改动做成可合并 PR）
工程交付类技能关注于任务拆解与规范交付：
spec-to-pr：从需求生成最小规格，拆解任务，给出 PR 计划与提交序列。refactor-with-tests：重构必须伴随测试与回归。repo-cleanup：依赖治理、目录整理、脚本统一、死代码清理。
评审与治理类（把不确定性锁进护栏）
评审与治理类技能用于提升代码质量与工程可控性：
code-review-hard-mode：从 reviewer 视角挑边界条件与风险。ci-fix-and-harden：补齐校验、消除 flaky、提升可重复性。
知识沉淀类（把经验写回工程资产与书）
知识沉淀类技能关注于经验复用与资产积累：
rule-extraction：从一次改动中抽取规则，写回 Rules/AGENTS/Checklist。doc-as-code：把工程经验沉淀为 Hugo 内容与可检索资产。
技能的验收标准建议统一为：输入（上下文/约束）—输出（文件/PR/测试）—验证（命令/CI 结果）。
MCP 推荐：把外部能力变成“协议化插件”
MCP（Model Context Protocol）不是简单地增加工具数量，而是将浏览器、文档、画图、测试等能力以统一协议挂载到智能体上，减少复制粘贴与上下文丢失。
下面是 MCP 的推荐组合：
最小集（优先接入高收益能力）
- Chrome DevTools MCP：用于前端调试与页面状态检查，适合“调试优先”的浏览器工作流。
- Context7：用于获取最新文档/接口信息，减少因模型知识滞后导致的返工。
- 测试类 MCP（优先一个即可）：用于测试执行、用例回归与结果汇总交由 agent 处理。
进阶集（系统化写作/产出与工程化复用）
- 画图类 MCP：用于生成架构图、流程图、时序图（建议优先支持 Mermaid 一类可版本化的图形 DSL）。
- 代码语义类 MCP：适用于大仓库重构，提供符号级导航与修改能力。
- 自研 MCP：针对高频重复的内部流程（如发布、巡检、依赖治理、环境一致性检查），自研 MCP 的 ROI 很高。
自研 MCP 的工程原则：接口小而清晰、输出可审计、写操作最小权限、默认只读优先；并与 Skills 绑定，把“能力”与“方法论”一起沉淀。
推荐组合：一套可复制的默认栈
如果你只想快速落地一套最稳的氛围编程组合，建议如下：
- 工作台：VS Code 或 Cursor
- 执行器：Claude Code + OpenCode（双执行器）
- 模型：Claude Sonnet 4.5 / Opus 4.6+、GPT-5.3-Codex（若可用）；国内环境用 GLM-5.2 或 Kimi K2.7 Code
- 方法论控制面：Promote Agent（任务对齐与分步策略）
- 资产化落点：Skills（把个人技能体系产品化）
- MCP：Chrome DevTools + Context7 + 测试类 + 画图类（按需扩展；服务端建议遵循 2026-07-28 新规范的无状态架构）
这套组合的核心目的，是将“氛围”转化为稳定交付的工程流水线，而非一次性灵感输出。
总结
氛围编程的工程化落地，离不开工具、方法论与能力资产的协同。通过合理选择 IDE、CLI Agent、Promote Agent、Skills 与 MCP，能够将个人与团队的开发意图转化为可复用、可回归的工程产物，持续提升交付效率与质量。