TabithaFanny Vibe Coding 技能
规划驱动 + 上下文固定 + AI 结对执行，让「从想法到可维护代码」变成可审计的流水线。
When to Use This Skill
触发条件：
- 用户说「帮我规划」「先分析一下」「设计方案」
- 新功能开发（超过 3 个文件的改动）
- 需求不明确，需要澄清
- 代码审查或重构任务
- 用户显式调用
/vibe-coding
Not For / Boundaries
- 单文件小修改（直接改，不需要规划）
- 纯问答（不涉及代码实现）
- 已有明确实施步骤的任务
Quick Reference
核心理念（道）
- 规划就是一切 — 谨慎让 AI 自主规划，否则代码库变乱麻
- 上下文是第一性要素 — 垃圾进，垃圾出
- 目的主导 — 一切动作围绕「目的」展开
- 奥卡姆剃刀 — 如无必要，勿增代码
- 逆向思考 — 从需求逆向构建代码
方法论（法）
- 一句话目标 + 非目标 — 明确边界
- 能抄不写 — 先问有没有现成轮子
- 按职责拆模块 — 单一职责
- 接口先行，实现后补
- 一次只改一个模块
- 文档即上下文 — 不是事后补
执行纪律（术）
- 明确写清：能改什么，不能改什么
- Debug 只给：预期 vs 实际 + 最小复现
- 测试可交给 AI，断言人审
- 代码一多就切会话（
/clear或/compact）
八荣八耻
以瞎猜接口为耻，以认真查询为荣
以模糊执行为耻，以寻求确认为荣
以臆想业务为耻，以人类确认为荣
以创造接口为耻，以复用现有为荣
以跳过验证为耻，以主动测试为荣
以破坏架构为耻，以遵循规范为荣
以假装理解为耻，以诚实无知为荣
以盲目修改为耻，以谨慎重构为荣
任务分级
| 规模 | 判断标准 | 流程 |
|---|---|---|
| S | 单文件、<50行改动 | 直接改，无需规划 |
| M | 2-5 文件、明确需求 | 轻量计划 → 执行 |
| L | >5 文件、需求模糊 | 完整计划 → 确认 → 执行 |
工作流程
Phase 1: 需求澄清（M/L 任务必做）
问清楚这 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
- 已知限制：计划模板偏向前端/全栈项目，其他领域可能需要调整