开发者分享个人Vibe Coding工作流:多Agent协同与规范探索
速览
该帖分享了开发者在Vibe Coding场景下的个人工作流,涉及Claude Code、Codex、OpenCode等多个AI Agent的协同使用。作者针对日常闲聊、小项目及正式开发等不同场景,提出了区分使用不同模型和Agent的策略,并尝试建立统一规范以提升效率。此外,还分析了为何未采用Claude Code+oh my claude组合,以及出于成本考虑对主力开发模型的选择逻辑。
AI 深度解读
背景
随着 AI 辅助编程(Vibe Coding)的普及,开发者不再局限于单一的工具或模型,而是倾向于构建由多个 Agent(智能体)组成的混合工作流。然而,这种多工具并用的模式也带来了显著的痛点:频繁在不同 Agent 之间切换不仅打断心流,还导致工作流缺乏统一标准,变得混乱且难以维护。
本文基于 LINUX DO 社区的一篇讨论,深入解析了一位资深开发者目前的个人 Vibe Coding 工作流。该开发者目前同时使用 Claude Code、Codex、OpenCode + oh my openagent、KIMI、Reasonix 以及 Hermes Agent 等多个工具,并面临“自建 code-assistant”与“OpenSpec 规范”两套开发规范的冲突。其核心诉求在于如何整合这些碎片化的工具,建立一套区分日常闲聊、小项目开发及正式项目开发的标准化工作流,以解决“工具包袱”问题。
核心内容
当前工作流的现状与痛点
作者目前处于一种“多 Agent 混用”的状态,主要使用的工具包括:
- Claude Code
- Codex
- OpenCode + oh my openagent
- KIMI
- Reasonix
- Hermes Agent
在开发规范层面,作者同时存在两套体系:
- 自建规范:自行搭建的
code-assistant。 - 遵循规范:采用
OpenSpec标准。
这种多工具、多规范并存的现状导致在“Vibe Coding”(即依靠直觉和氛围进行快速编码)过程中体验割裂,频繁切换 Agent 成为了一种负担。
拟议的标准化工作流框架
为了解上述问题,作者计划试行一套新的规范,旨在根据项目性质区分工作流:
1. 正式项目开发与迭代
此类场景对代码质量和架构稳定性要求最高,因此采用“强模型规划 + 强工具实现”的组合:
- 规划阶段:使用 Claude Code 配合 Claude 模型。利用其强大的逻辑推理能力建立初步认知和顶层框架规划。
- 实现阶段:使用 OpenCode 配合 OpenSpec 规范,调用 Codex 或 DS (DeepSeek) 模型进行具体代码实现。
2. 小项目开发
此类场景追求效率与成本的平衡,倾向于使用性价比更高的国产模型:
- 规划阶段:使用 Claude Code 建立初步规划,但底层模型可替换为国产模型(国模)。
- 实现阶段:使用 OpenCode 配合个人编写的 Skill 进行实现,模型同样使用国产模型。
3. 日常闲聊与轻量交互
此类场景对模型能力要求较低,核心诉求是响应速度和成本:
- 首选:Hermes Agent,配合量大管饱的低成本模型。作者目前个人配置为 KIMI Code Plan。
- 备选:千问客户端(通义千问)。
选型逻辑与成本考量
作者在工具选型上展现了极强的实用主义和成本意识:
-
为何未采用 Claude Code + oh my claude 组合? 作者早期未使用此组合,转而尝试了
OpenCode + oh my openagent并发现效果尚可,因此未做迁移。除非迁移能带来显著的性能提升,否则维持现状。 -
为何不将 Claude 或 GPT 作为主力开发模型?
- GPT:如果稳定性足够高,作者表示可以使用,但隐含了对当前稳定性的保留态度。
- Claude Code:主要障碍是成本。作者认为 Claude 模型价格过高,仅适合用于制定计划等对逻辑要求极高但代码量较小的环节。若将其作为主力开发模型,投入产出比(ROI)极低,因为实现需求本身无法带来与之匹配的收益。
关键要点
- 多 Agent 切换成本高:频繁在 Claude Code、Codex、OpenCode 等不同工具间切换会破坏开发心流,形成“工具包袱”。
- 分层工作流策略:
- 正式项目:Claude Code (规划) + OpenCode/OpenSpec/Codex (实现)。
- 小项目:Claude Code (规划) + OpenCode/个人 Skill (实现),模型均倾向国产。
- 日常闲聊:Hermes Agent (KIMI Code Plan) 或 千问客户端。
- 成本驱动选型:Claude 模型因价格昂贵,仅用于高价值的顶层规划;Codex、DS 及国产模型因性价比高,被用于具体的代码实现环节。
- 规范统一的需求:目前自建规范与 OpenSpec 并存导致混乱,亟需统一标准以优化体验。
- 迁移门槛:只有当新组合(如 oh my claude)能带来显著提升时,才会替换现有的 OpenCode 组合。
意义与影响
这篇分享揭示了当前 AI 编程领域的一个典型趋势:从“单一大模型依赖”向“混合专家系统(Mixture of Experts)”演变。
- 工具链的碎片化与专业化:开发者不再迷信单一平台,而是根据任务类型(规划 vs 实现 vs 闲聊)和成本敏感度,组合不同厂商和类型的工具。Claude 负责“大脑”(逻辑与架构),Codex/国产模型负责“双手”(代码生成),Hermes/Kimi 负责“嘴”(交互与轻量任务)。
- 成本优化的极致追求:在 Vibe Coding 模式下,开发者开始精细化计算 Token 成本。将昂贵的 Claude 限制在规划阶段,将大量的代码生成任务分配给更便宜的模型,是提升个人开发 ROI 的关键策略。
- 标准化工作的紧迫性:随着工具数量的增加,缺乏统一规范(如 OpenSpec)会导致维护噩梦。未来的 AI 编程工作流竞争,不仅是模型能力的竞争,更是工作流标准化、自动化和可复用性(如个人 Skill 库)的竞争。
- 国产模型的崛起:在小项目和日常场景中,国产模型(如 KIMI、通义千问)因其性价比和可用性,正在成为主力开发模型的重要替代方案,打破了欧美大模型在 AI 编程领域的绝对垄断。
