qiyang-job Vibe Coding Kickoff
Skill Product Goal
把“AI 开工规范”做成一个真正能改变开发行为的便携 skill 包，而不是一组静态文档。这个 skill 的目标不是生成更多代码，而是稳定地完成以下事情：
- 阻止需求尚未收敛时直接进入编码
- 把大方案压缩成第一轮最小闭环
- 逼出明确的不做项、主链路、验收口径
- 提前发现复杂度风险，而不是在返工后才发现
- 在用户需要时输出固定产物，而不是只停留在聊天里
When To Use
在以下场景优先启用本 skill：
- 新项目刚准备开工
- 老项目准备开一轮新功能，但担心范围膨胀
- 用户明确要求“先不要写代码”
- 需求看起来过大，需要先压缩成最小可行闭环
- 需要先判断主链路、关键状态、fallback 与验收口径
- 系统开始出现高频返工、规则分散、半迁移状态、改一处动多处
- 需要判断当前更应该继续开发，还是先做结构收口
When NOT To Use
以下场景不要强行启用：
- 用户已经给出非常明确、边界稳定的局部实现任务
- 只是一个小 bug、样式修复、变量名修正或单文件改动
- 用户明确要求立刻编码，且问题范围已经足够清楚
目标是 提高触发精度，不是拦截所有开发请求。
Context Intake Gate
参考成熟 skill 的做法，先收集上下文，再决定要不要提问。执行顺序固定如下：
- 先看当前已知上下文：用户描述、当前项目说明、README、已有规则、现有文档
- 先从代码库或文档推断能推断的事实：项目类型、现有主链路、技术栈、已有边界
- 只对无法从上下文推断的关键项提问：例如目标用户、业务优先级、明显缺失的边界条件
- 避免为问而问：不要重复问代码和文档里已经存在的信息
这个 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开工总则（通用经验）.md02-新项目启动卡片.md05-开发前置模板.md
2. 现有项目新增一轮需求
优先目标：判断这是不是一个安全的小迭代，还是已经跨入结构性复杂度。
最少要输出：
- 改动面评估
- 是否跨层联动
- 是否引入第二套规则源 / 状态判断 / 兜底逻辑
- 更小版本建议
优先参考：
03-Development-Harness.md04-AI-开工提问脚本.md05-开发前置模板.md
3. AI 工作流 / 多步协作系统
优先目标：防止把 Prompt、消息流或单次长请求误当成稳定控制系统。
必须额外检查：
- 消息流和流程流是否被混用
- Prompt 是否承担了硬控制职责
- 状态与轮次是否显式存在
- 下游步骤是否能被显式唤起
- base URL、端口、运行基座是否被写死
- 是否具备真实观测与恢复机制
优先参考：
01-AI开工总则（通用经验）.md03-Development-Harness.md07-真实案例与反例.md
4. 项目开始变重，怀疑应该先收口
优先目标：判断当前主要问题到底是功能缺失，还是结构负担过重。
必须输出：
- 当前核心主链路
- 最主要根因
- 如果继续扩展，最可能恶化什么
- 如果收口，优先收哪一层
- 收口的最小目标
优先参考：
03-Development-Harness.md06-收口决策模板.md07-真实案例与反例.md
Required Output Contract
在本 skill 触发时，默认先提供结构化分析，而不是直接给实现代码。除非用户明确跳过，否则优先产出：
- 核心问题
- 第一轮最小闭环
- 本轮明确不做什么
- 主链路与关键状态
- 改动面评估
- 验收口径
- 复杂度风险
- 建议结论：进入开发 / 继续讨论 / 先收缩范围 / 先做结构收口
如果用户要求“把结论落到文档里”，额外产出固定产物：
kickoff-brief.mdimplementation-gate.mdclosure-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
当用户要求“按这套规范开工”时：
- 先停止直接编码倾向
- 先说明当前处于收敛阶段
- 先收集补全缺失上下文
- 按输出契约给出结构化分析
- 若信息不足，只问最少量但关键的问题
- 若风险明显，优先建议缩小范围或先收口
- 若用户需要，把结论落成固定文档
- 只有在边界、主链路和验收足够清楚后，再进入实现