Vibe Coding 简介

Vibe 含义 n.（非正式）感应，氛围；

Vibe Coding，可以简理解为：用自然语言（人话）和 AI 聊天，让 AI 帮你生成代码、修改代码、优化代码的编程方式。但真正的 Vibe Coding 不仅仅是让 AI 写几行代码那么简单，而是一种全新的开发思维和工作流程。

Vibe Coding 用正式的语言来解释是：以自然语言提示驱动大型语言模型（LLM），由 AI 直接生成并迭代代码的意图驱动型开发模式。在这种模式下：

• 用户负责"想清楚要做什么"（表达意图）
• AI 负责"把它做出来"（实现逻辑）
• 用户与 AI 一起迭代优化（协作进化）

Vibe Coding 辅助工具

数据库服务

对于 Vibe Coding 开发者来说，开发小型项目或者练手的项目时，强烈推荐 Supabase 作为数据库。它是一个开源的数据库服务，提供了免费额度，而且功能非常强大：

• 提供 PostgreSQL 数据库（功能强大的关系型数据库）
• 内置用户认证功能（注册、登录、密码重置等）
• 提供文件存储功能，可以存图片、视频等
• 实时数据同步，数据变化时自动更新
• 友好的可视化界面，不用写 SQL 也能管理数据

并且 Supabase 的文档非常详细，配合 AI 工具使用特别方便。只需要“Supabase 做一个用户注册功能”一句话，AI 就能写代码完成开发。除了 Supabase，其他一些有免费额度的数据库服务选择：

• PlanetScale：MySQL 数据库
• MongoDBAtlas：NoSQL 数据库

代码小抄 - 代码片段管理

官网：https://www.codecopy.cn/

这是一个简单易用的代码分享工具，可以快速、跨设备地自由分享代码。完全免费，无论电脑或手机的都有不错的阅读体验。更多优点如下：

• 界面很像常用的代码编辑器，可以新增、删除代码片段
• 支持多种分享范围（公开、加密、仅个人可见）
• 支持多种分享方式（复制链接、QQ 分享、手机扫码、微信小程序等）
• 还有代码库功能，可以查看并学习其他人分享的优质代码
• 支持在线运行代码、AI 智能代码分析和纠错

Vibe Coding 经验心得

1. 规则文件并非写得越长越好。经测试，规则文件 400 行时遵循率跌到 71%。建议精心打磨 AGENTS.md 规则文件，尽量砍到 200 行内。
2. 上下文并非越多越好。当上下文超过窗口容量的 30% ~ 50% 时，模型的表现就开始明显下降了。信息越多，AI 反而越容易丢失重点。尽量精确引用需要的文件，或者让 AI 按需查找信息。如果对话已经很长了，用 /compact 命令把历史压缩成摘要。
3. 主流模型有提示缓存机制，同一会话里之前发过的内容会被缓存，后续每轮对话只需要付原价 1/10 的费用。如果频繁新开对话，前面积累的缓存会全部失效，所有内容重新按原价计费。所以同一个任务尽量在同一个会话里完成。切换任务时，如果需要复用之前的文档，可以压缩历史，比新开对话划算。
4. 规则文件本质上只是建议，不是 100% 生效的禁令。例如，代码格式化、危险命令拦截、提交前跑测试这些任务，应该用确定性的自动化脚本来执行，比如利用 Claude Code 的 Hooks 机制。
5. 多 Agent 模式的 token 消耗更高，建议只有「独立互不干扰的耗时任务」才开子 Agent。目前很多 AI 工具已经支持让自己判断什么时候需要拆分子任务并行执行，不需要自己处理。
6. 影响代码最终的效果不单只和模型有关。专业的 AI 编程工具在背后做了大量的工程优化。比如多层记忆系统、代码索引和按需检索、子 Agent 隔离，让 AI 记住该记的、运行更稳定。
7. Claude Code 中 Skill 描述的上下文预算有限。装过多 Skill 后，会导致丢失最少使用的那些 Skill 描述，也就基本不会通过关键词触发。MCP 同理，每个工具定义就要占成百上千 tokens。建议把项目专属的 Skill 放项目目录，不要什么都往全局装。
8. 使用 AI 开发功能时，能精准描述就不泛泛而谈，能按需加载就不要全量堆砌，能复用缓存就别频繁重开。

Token 使用技巧心得

要控制 Token 成本，不能只靠临时节流，关键是先把这四件事看清楚：

真正的问题是浪费不可见

很多 token 不是花在难题上，而是花在黑盒里的绕路上。尤其在 IDE vibe 里，外部只看到结果，却看不到 agent 有没有选错模型、反复读旧上下文、工具失败后重试，或因为环境问题绕远路。先把浪费看清楚，常见的四类浪费：

• 任务和模型不匹配：低复杂度任务也默认上顶级模型。
• 上下文越来越厚：长对话里旧信息、工具输出、历史判断不断累积。
• 工具和 MCP 太吵：日志、测试、命令输出里大量噪音被原样塞进上下文。
• 失败反复重来：依赖缺失、参数错误、工具失败导致 agent 一轮轮尝试。

值得花和该治理要分开

• 需要用 token 的内容有：复杂设计、关键判断、疑难排障、探索新 workflow ……
• 需要治理的是：模型错配、上下文膨胀、工具噪音和失败重试这些低质量消耗。

个人经验&平台能力

现在很多节省方式都靠个人经验：谁知道该用便宜模型，谁记得哪个 prompt 稳，谁的机器工具链更顺。但换个人、换机器、换一轮会话，经验就容易归零。团队不能长期靠个人自觉控成本。长期看，省 token 应该从个人技巧变成系统能力。平台至少要做到：

• 过程可见，能看到 tool call、失败重试和 token 花费位置；
• 经验可沉淀，记录任务适合什么模型、prompt、skill；
• 实验可回放，在同一状态下比较不同方案；
• 环境可统一，减少本地差异带来的绕路。

两个启发

• caveman 说明输出也是上下文，少寒暄、少复述、结论优先，可以减少后续语言垃圾。
• RTK 说明工具输出不该原样喂给模型，而应先过滤、聚合、截断和去重。

它们共同证明：真正有效的 token 优化，不靠人临场克制，而要做进 workflow。

小结

先把不同浪费拆开看，再承认只靠个人兜底不可持续，最后再把可观测、经验沉淀、模型分层和工具治理做成平台能力。这样，Token 成本管理才不是一场临时省钱运动，而是一次真正的工程化治理。

AI 编程规范（待整理、移动）

Spring Boot 项目 CLAUDE.md 模板

CLAUDE.md 是每次对话都加载的项目级上下文，配合 Skills 使用效果最佳。

# 项目名称

## 技术栈

- Spring Boot 4.x / Java 25
- PostgreSQL + JPA/Hibernate
- Spring Security + JWT
- Redis 缓存
- Docker + Kubernetes

## 关键命令

-`./mvnw spring-boot:run` — 启动开发服务器
-`./mvnw test` — 运行测试
-`./mvnw clean package -DskipTests` — 打包

## 代码规范

- 构造器注入（不用 @Autowired 字段注入）
- Service 层不加 @Transactional（只在需要的方法上加）
- Entity 不直接暴露给 API（用 DTO 转换）
- 日志用 SLF4J，不用 System.out

## Skills

本项目已安装以下 Skills：

- spring-boot-rest-api：REST API 开发
- spring-boot-testing：测试编写
- code-reviewer：代码审查

推荐的 Spring Boot + Agent Skills 工作流

标准工作流

1. 探索阶段：让 Agent 读取代码库，理解架构  
2. 规划阶段：使用 /plan 模式，Agent 输出实现方案  
3. 编码阶段：Agent 按规划逐步实现（自动加载匹配的 Skills）  
4. 验证阶段：运行测试，确认通过  
5. 提交阶段：Git commit + push

多 Agent 协作模式

对于复杂 Spring Boot 项目，可以按角色分配不同 Skills：

Agent 角色	职责	推荐 Skill
架构师	设计微服务架构、模块拆分	Java Architect
开发者	编写具体代码	Spring Boot Engineer / Dr JSkill
测试工程师	编写和运行测试	TDD Mastery
安全审计	安全漏洞扫描	Security Hardening
代码审查	代码质量把关	Code Reviewer