Vibe Coding 经验分享

Vibe Coding 经验分享

最近沉迷于 Vibe Coding，并速通了一个小项目，这里分享一些日常开发中的工作流和经验

我常用的 Agent 是 Codex 和 Claude Code（使用 CLI）后文也主要写这些实践操作

我主要的工作就是围绕着 skill 和 subagent 展开的，后文也以这两个为主

1 Skill

1.1 简介

可以把 Skill 理解成一个可复用的流程模板。

也就是把一套稳定做法（输入、步骤、输出格式、约束）写进 SKILL.md，下次遇到类似任务直接复用，不用每次重写一大段 prompt 。

1.2 例子

• codebase-overview：快速梳理代码架构，输出模块边界、主调用链和 Mermaid 图。

• feat-plan-challenge：先出计划，再做挑战式审查，最后只汇报冲突点和待决策项。

• plan-implement-dual-review：按计划实现后先自审修复，再做独立结构审查。

• create-pr：根据当前分支提交，自动生成规范化 PR 标题和描述。（这里面我用到了 Github 的 MCP）

• …

2 SubAgent

2.1 简介

Subagent 就是专门干某一类活的 AI 角色，最大的特点就是独立的上下文，专注一个工作

假如有一个流程很复杂的工作，或者说相互之间关联不大的工作，可以通过 subagent 来完成

2.2 例子

假如我的代码文档中有 test, cli, web 等等功能模块，我现在需要审查他们的隔离性，复用性等等

我做的步骤是：

1. 先起一个 agent，帮我区分好整个项目的模块

2. 让 agent 起草一个审查的模板，并控制好每个模块的边界

3. 对每一个模块单独开 subagent 来审查结果

4. 让 agent 来为我总结，并将结果统一在一起

你可以发现 主 agent 的工作不包含任何的实际的代码审查工作，他只负责拆分模块，以及帮我撰写详细的汇报模板

同样的各个 subagent 之间的相互隔离，让上下文更加干净，也通过并行加快了审查的速度。

所以 subagent 特别适合做“分工明确”的任务，或者说相互隔离的子任务，然后让调用的 agent 来专注于任务分配，结果汇报等工作

3 Skill 与 SubAgent 的区别

这两个都是一个通用的解决问题的一套模板，他们之间最大的区别在于上下文的管理， skill 是可以拿到当前对话的上下文的，但是 subagent 是拿不到的，也不应该拿到的（因为我们需要他专注于当前的工作）

所以我 skill 里面经常会有 pr 这个工作，因为写 pr 的时候可以通过上下文来快速的拿到我这一个分支的工作，这就是 skill 的优势

另外就是我也经常会在 skill 中让他去调用 subagent，这其实是不冲突的。

4 工作流分享

我现在最看重的是“渐进式披露”：先给模型一层总规则，再按任务阶段逐步补充具体上下文

4.1 1. .ai_docs

我不会一上来塞一大段规则正文，而是先告诉它索引位置。

在 paper-tracker 里，我会明确这几份文件（都放在一个.ai_docs/文件夹下）：

• project_overview.md：告诉 agent 整个项目的架构，不用每一次都消耗大量的 上下文来读代码

• code_rules.md：写代码阶段的规则，包括函数的命名习惯等，这是项目代码风格的统一规则

• testing_rules.md：测试规范，怎么写单元测试，怎么在写完代码后自测一下有没有 bug

• code_review_structure_rules.md：这是给审查的 subagent 看的，其中用链接引用了一部分 code_rules.md ，外加了一些可维护性的一些检查

• git_rules.md：PR/commit 的统一格式

这样做的好处是，后续每一步都有统一标准，不会在对话里反复解释同一件事，同时如果修改起来也方便

4.2 AGENTS.md/ CLAUDE.md

这两份文件是 agent 的类似于入口文件，基本上所有命令都会看，但是也不可以在这里面赛太多的规则，这会把上下文撑满，所以我们之前写的就发挥了作用

比如说我会写

## code 规则
如果你需要撰写代码，或者对项目执行代码更改的时候，阅读文件 `code_rules.md`

这就是渐进式披露的核心，只在通用的上下文中放一个类似于 index 的文件，让模型知道什么时候该去调用，去哪里找，而具体的内容，不要放进上下文

4.3 Skill 举例

我这里介绍一下我的两个常用的 skill，经常是穿起来用的

先说计划阶段（feat-plan-challenge）：

• subagent1 先读 references/plan_feature_requirements.md 产出计划。

• subagent2 只做 challenge，专门找漏洞和遗漏。

• 再回给 subagent1 做 accept/reject/escalate。

• 主线程只汇报冲突点和待决策项。

然后是实现阶段（plan-implement-dual-review）：

• subagent1 读计划后在新分支实现，并先按 code_rules.md 自审修复。

• subagent2 再按 code_review_structure_rules.md 做独立结构审查。

• 主线程最终只汇报结构性问题，不展开实现细节。

这是提高 Agent 的一个很好用的方式，就有点像是 GAN 网络的架构一样，必须要反复复审，最后再交由人来决定，可以相对提升整体的质量，就相当于强制模型反复思考了两回

4.4 关键决策点

在我 vibe coding 中，是绝对不会让 ai 写直接复杂的逻辑的，也就是说，我个人一定要对项目的走向有控制，而不是让整个项目变成一个黑盒

我会在这些方面审查一下结果：

• feat-plan-challenge 产生了冲突的结果需要我来决定。

• 计划设计结构很差（经常用 ai 写功能都会发现，他很喜欢写高耦合的东西，这会导致写到后面都是史山）我需要直接推翻，或者给他一个设计的方向等等……

• 代码变量命名规则没有覆盖的一些内容

• 有的代码实现方案太过于零散了（为了解耦而解耦，很容易导致维护的时候到处跳转，可读性反而会变差）

这些都是需要我们人来控制的，而且也不存在一个很好的方式让 ai 来确定界限，因为他也是相对主观的。

而这种决策点，就是我们切分是用 subagent 还是手动调用分离，如果我们人不需要介入，那么可以交给 subagent 来串联工作，否则就需要停下，等人来审查，审查完人再调用另一个 agent

main agent 更像项目经理(pm)，subagent 更像不同岗位的执行工人。当 ai 不能够充当这个 pm 的职责的节点，我们就需要停下来审查，我们来充当那个 pm 审查完继续交给 agent 工作。