前言
最近开始使用 Claude 作为主要的编程工具，尝试一种全新的编程方式——vibe programming。我的目标是让所有的代码都由 AI 生成，自己只负责提出需求并反馈错误信息给 Claude，让它自己修复和改进。
这种方式的核心理念是：**把编程从”写代码”转变为”描述需求”**。不再需要逐行编写代码，而是通过自然语言与 AI 协作，让 AI 理解意图并生成实现。
为什么选择 Terminal 方式
Claude Code 我主要使用 terminal 的方式，虽然也尝试过 VS Code + Claude 插件的模式，但 terminal 方式才是我的主力。
为什么不用 IDE 方式（如 Cursor）
Auto Accept 的工作流
- 我一般都是 auto accept 的，基本不看 diff
- IDE 方式会显示大量 diff，但我并不需要这些中间状态
- Terminal 方式更直接，直接看到最终结果
Token 使用效率
- Terminal 方式感觉更省 token，context window 消耗更慢
- 可能是因为 IDE 会包含更多上下文信息（文件树、编辑器状态等）
- 对于我这种高频使用的场景，token 效率很重要
图片输入的权衡
- IDE 方式（如 VS Code）可以粘贴图片到对话窗口，这确实很方便
- 但对我来说，terminal 方式的简洁性更重要
Claude vs 其他工具
对比 Copilot 和 Cursor，Claude 的优势主要体现在：
模型能力
Sonnet 4.5 在代码能力方面确实更强，特别是在：
- 理解复杂需求和上下文
- 生成更符合项目风格的代码
- 处理多步骤的编程任务
框架偏好的有趣发现
我有个有趣的发现：Claude 在某些代码和框架方面比较擅长。
- ✅ 擅长：Node.js、React 相关的代码生成质量很高
- ⚠️ 一般：Java 代码的能力相对较弱
这可能与训练数据有关，也可能是我使用场景的差异。不过这个发现让我在分配任务时会更有针对性。
后续可以展开的内容
Vibe Programming 实践细节
核心理念：从”精确设计”到”模糊探索”
传统的软件开发往往遵循瀑布模型：需求文档 → 概要设计 → 详细设计 → 编码实现。这种方式隐含了一个假设：我们必须在开始时就尽量少犯错。但这是反人性的——很多时候，我们并不清楚自己到底想要什么，也没有明确的灵感。
Vibe Programming 提供了一种全新的思路：用模糊的需求开始，通过 AI 快速迭代来探索可能性。
为什么模糊的提示词也能工作？
我发现 AI 对于模糊提示词的交付质量往往不差，有时甚至能给出超越 60% 同类软件的设计。这背后有几个原因：
- 海量优秀项目的积累：AI 读过大量优秀的开源项目，具备了”最佳实践”的直觉
- 上下文理解能力：AI 会根据你的项目历史（语言、代码风格、架构选择）来推断你的需求
- 创造力的价值：人有自己的 “unknown unknowns”，AI 可以在宽度上给出意想不到的启发
实际工作流程
1. 起点：给出模糊的提示词
例如：
- “帮我做一个用户管理页面，能够实现信息的基本增删改”
- “创建一个任务看板，类似 Trello”
- “实现一个 Markdown 编辑器，支持实时预览”
这些提示词非常不具体，但 AI 会根据上下文”猜测”你的需求。
2. AI 响应：直接给出实现（而非设计）
注意：AI 不会问你”你想要什么样的 UI”或”需要哪些字段”，而是直接生成可运行的代码。这包括：
- 完整的组件结构
- 数据模型
- 交互逻辑
- 基本的样式
3. 人的角色：查看并反馈
这时人需要介入，扮演”产品经理 + 测试工程师”的角色：
情况 1：代码无法运行
- 编译错误、依赖缺失、启动失败等
- 直接把错误信息粘贴给 AI，让它修复
情况 2：功能与预期不符
- 例如：”我希望每个记录作为表格的一行，每行都有自己的 action buttons”
- 或者：”表单验证太弱了，需要加上邮箱格式检查”
- 提出具体的改进要求，进入新的迭代循环
情况 3：达到或超出预期
- 功能完成，进入下一个 feature
这种方式的优势
| 传统方式 | Vibe Programming |
|---|---|
| 需要提前想清楚所有细节 | 可以边做边想 |
| 设计错误成本高 | 试错成本极低 |
| 从零开始编写代码 | AI 直接生成可运行的版本 |
| 专注于”怎么实现” | 专注于”要什么效果” |
适用场景
这种方式特别适合：
- ✅ 探索性项目：不确定最终形态
- ✅ 快速原型：需要尽快看到效果
- ✅ 参考已有产品：如”做一个类似 XX 的功能”
- ✅ 标准功能：CRUD、表单、列表等
不太适合：
- ⚠️ 需要精细控制的场景（如性能关键代码）
- ⚠️ 完全创新的算法或架构（AI 没有先例可参考）
可视化流程图
下面的流程图展示了 Vibe Programming 的完整迭代循环：
进阶想法：Consolidation Train 模式
💡 发散思维
基于上面的快速迭代循环，我有一个更激进的设想：让 AI 自动化处理测试和修复的循环。
核心概念：双轨并行
想象一个场景：你有两个并行的 AI session：
主力开发 Session（Terminal 1）
- 你在这里不断提出新需求
- AI 实现功能，生成代码
- 专注于 “创造” 而非 “维护”
Consolidation Session（定时脚本）
- 每 5 分钟自动运行一次
- 自动执行：编译 → 部署 → 测试 → 修复
- 就像一列定期发车的 “巩固列车”
Consolidation Train 的任务
定时脚本会启动一个 Claude session，prompt 类似：
1 | 这个 app 的基本功能有：feature1、feature2... |
Train 比喻
把每个需求想象成一位乘客：
- 登车：需求被 AI 实现后，登上下一班 Train
- 发车：定时脚本启动（如每 5 分钟）
- 运行：Train 自动完成编译、测试、修复的循环
- 到站：功能进入稳定可用状态
- 顺序保证：上一班 Train 到站后，下一班才发车（避免需求冲突）
这种模式的优势
| 传统 Vibe Programming | Consolidation Train 模式 |
|---|---|
| 提需求 → 等待实现 → 手动测试 → 复制错误 → 等待修复 | 持续提需求 → AI 自动测试和修复 |
| 需要盯着 terminal 看错误日志 | 可以去喝咖啡 ☕️ |
| 一次只能做一件事 | 需求像流水线一样处理 |
| 重复劳动（复制日志、重启等） | 自动化处理重复任务 |
人的新角色
- 需求提出者：尽可能大胆地提需求，AI 不会抱怨
- 产品验收者：方便时打开 UI 点一点，看看哪些 Train 已到站
- 决策者：判断功能是否满意，决定下一步需求
挑战和解决方案
挑战 1：需求冲突
- 问题：需求 2 改了需求 1 的功能，需求 3 又把需求 2 的改动去掉
- 解决：严格保证 Train 的顺序到达
- 上一班 Train 到站后，下一班才发车
- 这样你可以基于最新状态进行推理和决策
- 人的思维本就是线性的，这种设计符合直觉
挑战 2：Token 成本
- 问题：定时脚本持续运行会消耗 token
- 解决：
- 只在有新提交时触发
- 调整发车间隔（5分钟 → 10分钟 → 按需）
- 使用更便宜的模型做测试，关键问题才升级
Consolidation Train 流程示意图
其他待展开内容
- 如何有效地描述需求（prompt 技巧）
- 错误反馈的最佳实践：如何让 Claude 快速理解问题并修复
- 实际案例：一个完整功能的开发过程
效率提升的量化
- 开发速度对比：传统方式 vs vibe programming
- 代码质量评估：AI 生成的代码质量如何
- 学习曲线：从传统编程到 vibe programming 的转变
遇到的挑战和解决方案
- 复杂逻辑的处理：AI 理解不了的场景怎么办
- 调试技巧：如何快速定位 AI 生成代码的问题
- 代码审查：如何确保 AI 生成的代码符合要求
- 上下文管理：如何保持对话的连贯性
不同场景的应用
- 新项目搭建：从零开始的体验
- 重构现有代码：如何描述重构需求
- Bug 修复：如何让 AI 理解并修复 bug
- 性能优化：AI 在优化方面的表现
工具和技巧
- Terminal 方式的具体配置和使用技巧
- 如何组织对话，提高效率
- 常用命令和快捷方式
- 与其他工具的集成（git、测试工具等）
深度思考
- 编程能力的边界：哪些能力仍然需要自己掌握
- 对编程思维的影响：是否改变了思考问题的方式
- 团队协作：如何在团队中推广这种工作方式
- 未来展望：AI 编程工具的发展方向
对比分析
- 不同 AI 工具（Claude、Copilot、Cursor）的详细对比
- 不同使用场景下的工具选择
- 成本效益分析：订阅费用 vs 效率提升