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 等等功能模块，我现在需要审查他们的隔离性，复用性等等
我做的步骤是：
- 先起一个 agent，帮我区分好整个项目的模块
- 让 agent 起草一个审查的模板，并控制好每个模块的边界
- 对每一个模块单独开 subagent 来审查结果
- 让 agent 来为我总结，并将结果统一在一起
你可以发现 主 agent 的工作不包含任何的实际的代码审查工作，他只负责拆分模块，以及帮我撰写详细的汇报模板
同样的各个 subagent 之间的相互隔离，让上下文更加干净，也通过并行加快了审查的速度。
所以 subagent 特别适合做“分工明确”的任务，或者说相互隔离的子任务，然后让调用的 agent 来专注于任务分配，结果汇报等工作
3 Skill 与 SubAgent 的区别
这两个都是一个通用的解决问题的一套模板，他们之间最大的区别在于上下文的管理， skill 是可以拿到当前对话的上下文的，但是 subagent 是拿不到的，也不应该拿到的（因为我们需要他专注于当前的工作）
所以我 skill 里面经常会有 pr 这个工作，因为写 pr 的时候可以通过上下文来快速的拿到我这一个分支的工作，这就是 skill 的优势
另外就是我也经常会在 skill 中让他去调用 subagent，这其实是不冲突的。
4 工作流分享
我现在最看重的是“渐进式披露”：先给模型一层总规则，再按任务阶段逐步补充具体上下文
4.1 1. .ai_docs
我不会一上来塞一大段规则正文，而是先告诉它索引位置。
在 paper-tracker 里，我会明确这几份：
project_overview.md：告诉 agent 整个项目的架构，不用每一次都消耗大量的 上下文来读代码code_rules.md：写代码阶段的规则，包括函数的命名习惯等，这是项目代码风格的统一规则testing_rules.md：测试规范，怎么写单元测试，怎么在写完代码后自测一下有没有 bugcode_review_structure_rules.md：这是给审查的 subagent 看的，其中用链接引用了一部分code_rules.md，外加了一些可维护性的一些检查.ai_docs/rules/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读计划后在新分支实现，并先按.ai_docs/rules/code_rules.md自审修复。subagent2再按.ai_docs/rules/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 工作。