vibe-coding

name	vibe-coding
description	Vibe Coding 全流程技能：规划驱动的 AI 结对编程方法论。触发词：vibe、规划、plan、需求分析、架构设计、代码审查。

Vibe Coding 技能

规划驱动 + 上下文固定 + AI 结对执行，让「从想法到可维护代码」变成可审计的流水线。

When to Use This Skill

触发条件：

• 用户说「帮我规划」「先分析一下」「设计方案」
• 新功能开发（超过 3 个文件的改动）
• 需求不明确，需要澄清
• 代码审查或重构任务
• 用户显式调用 /vibe-coding

Not For / Boundaries

• 单文件小修改（直接改，不需要规划）
• 纯问答（不涉及代码实现）
• 已有明确实施步骤的任务

Quick Reference

核心理念（道）

1. 规划就是一切 — 谨慎让 AI 自主规划，否则代码库变乱麻
2. 上下文是第一性要素 — 垃圾进，垃圾出
3. 目的主导 — 一切动作围绕「目的」展开
4. 奥卡姆剃刀 — 如无必要，勿增代码
5. 逆向思考 — 从需求逆向构建代码

方法论（法）

1. 一句话目标 + 非目标 — 明确边界
2. 能抄不写 — 先问有没有现成轮子
3. 按职责拆模块 — 单一职责
4. 接口先行，实现后补
5. 一次只改一个模块
6. 文档即上下文 — 不是事后补

执行纪律（术）

1. 明确写清：能改什么，不能改什么
2. Debug 只给：预期 vs 实际 + 最小复现
3. 测试可交给 AI，断言人审
4. 代码一多就切会话（/clear 或 /compact）

八荣八耻

以瞎猜接口为耻，以认真查询为荣
以模糊执行为耻，以寻求确认为荣
以臆想业务为耻，以人类确认为荣
以创造接口为耻，以复用现有为荣
以跳过验证为耻，以主动测试为荣
以破坏架构为耻，以遵循规范为荣
以假装理解为耻，以诚实无知为荣
以盲目修改为耻，以谨慎重构为荣

任务分级

规模	判断标准	流程
S	单文件、<50行改动	直接改，无需规划
M	2-5 文件、明确需求	轻量计划 → 执行
L	>5 文件、需求模糊	完整计划 → 确认 → 执行

工作流程

Phase 1: 需求澄清（M/L 任务必做）

问清楚这 5 个问题：

1. 目标：核心功能是什么？解决什么问题？
2. 非目标：明确不做什么？
3. 输入输出：数据从哪来？到哪去？
4. 约束：技术栈限制？时间限制？
5. 验收标准：怎么算完成？

Phase 2: 计划生成

轻量计划（M 任务）：

## 目标
一句话描述

## 非目标
- 不做 X
- 不做 Y

## 步骤
1. [ ] 步骤1（预估 X 分钟）
2. [ ] 步骤2
3. [ ] 步骤3

## 验收
- [ ] 验收点1
- [ ] 验收点2

完整计划（L 任务）：见 references/plan-full.md

Phase 3: 执行

每个步骤执行前检查：

• 已查阅相关文档/代码
• 已确认接口规范
• 已检查可复用模块
• 已明确改动范围

每个步骤执行后：

• 功能验证通过
• 无明显副作用
• 更新进度记录

Phase 4: 收尾

• 代码符合规范
• 关键逻辑有注释
• 错误处理完善
• 测试覆盖关键路径

Examples

Example 1: 小任务（S）— 直接执行

用户：「把这个函数的返回值从 string 改成 number」

→ 直接改，不需要规划流程

Example 2: 中型任务（M）— 轻量计划

用户：「给用户列表加个搜索功能」

→ 输出轻量计划：

## 目标
用户列表页添加按名称搜索功能

## 非目标
- 不做模糊搜索
- 不做搜索历史

## 步骤
1. [ ] 添加搜索输入框组件
2. [ ] 实现过滤逻辑
3. [ ] 添加防抖处理

## 验收
- [ ] 输入关键词能过滤列表
- [ ] 清空输入恢复全部

Example 3: 大型任务（L）— 完整计划

用户：「重构整个认证模块」

→ 先问清需求 → 生成完整计划 → 等用户确认 → 分步执行

References

• references/plan-full.md — 完整计划模板
• references/code-quality.md — 代码质量规范
• references/file-header.md — 文件头模板
• references/git-rules.md — Git 操作规范

Maintenance

• 来源：vibecodingcn 精简整合
• 更新：2026-03-17
• 已知限制：计划模板偏向前端/全栈项目，其他领域可能需要调整