# Vibe Coding Kickoff

> 当用户准备开启新项目、收敛需求范围、定义最小闭环、明确不做项、评估改动面、制定验收口径，或判断项目是否应该先收口而不是继续扩展时使用。适用于“先不要写代码”“帮我先把项目开工方式收敛清楚”“按我的 vibe coding 规范来”“帮我判断该继续开发还是先收口”等场景。

- Skill: `qiyang-job/vibe-coding-kickoff` (Agent Skill, multi-file: 11 files)
- Install (CLI): `npx skillmds@latest add qiyang-job/vibe-coding-kickoff`
- Raw SKILL.md: https://api.skillmd.com/api/skills/qiyang-job/vibe-coding-kickoff/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: qiyang-job (https://skillmd.com/u/qiyang-job)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/qiyang-job/vibe-coding-kickoff

---


# Vibe Coding Kickoff

## Skill Product Goal

把“AI 开工规范”做成一个真正能改变开发行为的便携 skill 包，而不是一组静态文档。这个 skill 的目标不是生成更多代码，而是稳定地完成以下事情：

- 阻止需求尚未收敛时直接进入编码
- 把大方案压缩成第一轮最小闭环
- 逼出明确的不做项、主链路、验收口径
- 提前发现复杂度风险，而不是在返工后才发现
- 在用户需要时输出固定产物，而不是只停留在聊天里

## When To Use

在以下场景优先启用本 skill：

- 新项目刚准备开工
- 老项目准备开一轮新功能，但担心范围膨胀
- 用户明确要求“先不要写代码”
- 需求看起来过大，需要先压缩成最小可行闭环
- 需要先判断主链路、关键状态、fallback 与验收口径
- 系统开始出现高频返工、规则分散、半迁移状态、改一处动多处
- 需要判断当前更应该继续开发，还是先做结构收口

## When NOT To Use

以下场景不要强行启用：

- 用户已经给出非常明确、边界稳定的局部实现任务
- 只是一个小 bug、样式修复、变量名修正或单文件改动
- 用户明确要求立刻编码，且问题范围已经足够清楚

目标是 **提高触发精度**，不是拦截所有开发请求。

## Context Intake Gate

参考成熟 skill 的做法，先收集上下文，再决定要不要提问。执行顺序固定如下：

1. **先看当前已知上下文**：用户描述、当前项目说明、README、已有规则、现有文档
2. **先从代码库或文档推断能推断的事实**：项目类型、现有主链路、技术栈、已有边界
3. **只对无法从上下文推断的关键项提问**：例如目标用户、业务优先级、明显缺失的边界条件
4. **避免为问而问**：不要重复问代码和文档里已经存在的信息

这个 skill 的一个核心质量标准是：**问题少，但问题准。**

## Progressive Loading Rule

不要一触发就把所有参考资料全量灌进上下文。优先按场景最小化加载：

- 默认先读 `01-AI开工总则（通用经验）.md`
- 新项目开工时再补 `02-新项目启动卡片.md` 与 `05-开发前置模板.md`
- 需求收敛阶段再补 `04-AI-开工提问脚本.md`
- 判断是否收口时再补 `06-收口决策模板.md`
- 需要对照真实教训时再读 `07-真实案例与反例.md`
- 需要衡量 skill 是否有效时再读 `08-效果评估与验收.md`

保持 `SKILL.md` 本身聚焦工作流，详细材料按需读取。

## Task Router

### 1. 新项目开工

优先目标：判断“现在该不该开工”，并压出第一轮最小闭环。

最少要输出：

- 核心问题
- 最小闭环
- 本轮不做什么
- 主链路与关键状态
- 验收口径
- 是否进入开发

优先参考：

- `01-AI开工总则（通用经验）.md`
- `02-新项目启动卡片.md`
- `05-开发前置模板.md`

### 2. 现有项目新增一轮需求

优先目标：判断这是不是一个安全的小迭代，还是已经跨入结构性复杂度。

最少要输出：

- 改动面评估
- 是否跨层联动
- 是否引入第二套规则源 / 状态判断 / 兜底逻辑
- 更小版本建议

优先参考：

- `03-Development-Harness.md`
- `04-AI-开工提问脚本.md`
- `05-开发前置模板.md`

### 3. AI 工作流 / 多步协作系统

优先目标：防止把 Prompt、消息流或单次长请求误当成稳定控制系统。

必须额外检查：

- 消息流和流程流是否被混用
- Prompt 是否承担了硬控制职责
- 状态与轮次是否显式存在
- 下游步骤是否能被显式唤起
- base URL、端口、运行基座是否被写死
- 是否具备真实观测与恢复机制

优先参考：

- `01-AI开工总则（通用经验）.md`
- `03-Development-Harness.md`
- `07-真实案例与反例.md`

### 4. 项目开始变重，怀疑应该先收口

优先目标：判断当前主要问题到底是功能缺失，还是结构负担过重。

必须输出：

- 当前核心主链路
- 最主要根因
- 如果继续扩展，最可能恶化什么
- 如果收口，优先收哪一层
- 收口的最小目标

优先参考：

- `03-Development-Harness.md`
- `06-收口决策模板.md`
- `07-真实案例与反例.md`

## Required Output Contract

在本 skill 触发时，默认先提供结构化分析，而不是直接给实现代码。除非用户明确跳过，否则优先产出：

1. **核心问题**
2. **第一轮最小闭环**
3. **本轮明确不做什么**
4. **主链路与关键状态**
5. **改动面评估**
6. **验收口径**
7. **复杂度风险**
8. **建议结论**：进入开发 / 继续讨论 / 先收缩范围 / 先做结构收口

如果用户要求“把结论落到文档里”，额外产出固定产物：

- `kickoff-brief.md`
- `implementation-gate.md`
- `closure-review.md`（仅在收口场景需要）

如果运行环境允许，优先使用 bundled script `scripts/generate_kickoff_bundle.py` 生成这些文件；否则按同样结构直接写文件。

## Exit Criteria: When To Switch To Implementation

只有在以下条件基本满足时，才从收敛阶段切到实现阶段：

- 核心问题足够明确
- 最小闭环能被一句话解释
- 不做项已经显式写出
- 主链路与 fallback 清楚
- 改动面不属于明显高风险
- 验收口径足够具体

如果其中两项以上不清楚，默认 **不进入编码**。

## High-Risk Pitfalls To Check Explicitly

每次分析时，显式检查以下高频坑：

- 是否把聊天消息误当成协作引擎本身
- 是否把 Prompt 当成硬控制手段
- 是否缺少显式状态与轮次隔离
- 是否默认长链路会自动续跑
- 是否每一跳都能显式唤起下一跳
- 是否把端口、base URL 或运行基座写死
- 是否只做了页面层验证，没有跑真实链路
- 是否缺少日志、状态查询与 watcher 等可观测性
- 是否存在旧变量、旧入口、旧规则残留导致的半迁移状态

## Examples

### Example 1: 新项目开工

用户说：

- “先不要写代码，帮我把这个 AI 协作产品怎么开工收敛清楚。”

正确行为：

- 不直接设计完整系统
- 先输出核心问题、最小闭环、不做项、主链路、验收口径
- 如果方案太大，再缩小一版

### Example 2: 协作链路看起来能跑，但不稳定

用户说：

- “我想让 agent 自动串起来继续往下跑。”

正确行为：

- 不把答案停在 Prompt 层
- 显式检查状态、轮次、续跑唤醒、base URL、可观测性
- 指出消息流与流程流是否混用

### Example 3: 项目越做越重

用户说：

- “我现在不确定该继续加功能，还是先收口。”

正确行为：

- 先梳理当前主链路和复杂度症状
- 明确最主要根因
- 给出“继续开发 / 边开发边收口 / 先暂停扩展”的判断

## Anti-Goals

这个 skill 不应该变成以下东西：

- 一上来就输出完整 PRD 或完整系统设计
- 每次都问很多泛问题，增加用户负担
- 在小任务上过度介入，影响效率
- 只会讲理念，不会落地成固定产物
- 只会建议“先讨论”，但没有明确退出条件

## Effectiveness Loop

把这个 skill 当成产品持续评估，而不是一次性写完。每次实际使用后，至少从三个维度回看：

- **触发精度**：该触发时是否触发，不该触发时是否克制
- **输出质量**：是否真的缩小范围，而不是只复述用户原话
- **结果质量**：后续实现是否更小、更稳、更少返工

详细评估标准见 `08-效果评估与验收.md`。

## Reference Files

根据场景按需加载以下参考资料：

- `00-先读我.md`：总入口与推荐阅读顺序
- `01-AI开工总则（通用经验）.md`：最核心的通用经验与踩坑总结
- `02-新项目启动卡片.md`：一页版开工判断标准
- `03-Development-Harness.md`：完整的方法论与复杂度治理原则
- `04-AI-开工提问脚本.md`：可直接复用的对话脚本
- `05-开发前置模板.md`：实现前的结构化模板
- `06-收口决策模板.md`：项目变重时的收口判断模板
- `07-真实案例与反例.md`：把真实踩坑沉淀成可复用判断样例
- `08-效果评估与验收.md`：如何判断这个 skill 是否真的有效
- `09-Skill结构说明.md`：这整个便携版资料包怎么组织、哪些必须保留

## Default Behavior

当用户要求“按这套规范开工”时：

1. 先停止直接编码倾向
2. 先说明当前处于收敛阶段
3. 先收集补全缺失上下文
4. 按输出契约给出结构化分析
5. 若信息不足，只问最少量但关键的问题
6. 若风险明显，优先建议缩小范围或先收口
7. 若用户需要，把结论落成固定文档
8. 只有在边界、主链路和验收足够清楚后，再进入实现