L0 — 氛围编程（Vibe Coding）

"Just vibe with the AI. Stop being a keyboard monkey."
—— Andrej Karpathy，2025年2月（"Vibe Coding" 概念提出者）

是什么

氛围编程（Vibe Coding）是 AI 辅助开发的起点形态——纯自然语言描述需求，让 AI 自由生成代码，不引入任何规范约束、工具接入或结构化流程。

简单说：你描述感觉，AI 写代码，出来啥算啥。

能力概览

氛围编程能力边界
│
├── 1. 快速原型与想法验证
│   ├── 用自然语言描述 UI，AI 直出 HTML/CSS/Vue 草稿
│   ├── 快速出一个"能跑起来"的 Demo，不追求规范
│   └── 探索技术可行性（"能不能用 Canvas 做这个效果"）
│
├── 2. 学习与知识探索
│   ├── 让 AI 解释代码逻辑，代替看文档
│   ├── "给我写一个 xxx 的例子"帮助理解 API 用法
│   └── 调试报错、理解错误原因（不用自己看 Stack Trace）
│
├── 3. 一次性脚本与工具
│   ├── 数据格式转换脚本（JSON → CSV）
│   ├── 批量文件处理、正则替换
│   └── 临时用完即弃的小工具，不需要维护
│
├── 4. 非工程任务
│   ├── 写邮件、写文档、写 Commit Message
│   ├── 翻译、总结、润色
│   └── SQL 查询辅助、Shell 命令查询
│
└── 5. 边界（L0 做不好的事）
    ├── ❌ 严格遵守团队命名规范（AI 不知道你的约定）
    ├── ❌ 生成可复现的稳定输出（每次结果不同）
    ├── ❌ 与后端接口精准对齐（AI 会凭空编字段名）
    └── ❌ 批量生成大量页面（无规范门控，质量离散）

为什么不够用？

L0 适合个人探索，但在企业级项目中有明显天花板：

问题	表现
不了解团队约定	AI 写出的组件名、目录结构、字段命名与团队规范不符
结果不稳定	同样的需求，今天生成的代码和昨天完全不同
规范违反	生成的代码常含 console.log、var、裸露 axios 调用
Code Review 负担重	每次都需要人工大量修改才能合并
知识不可沉淀	每次都要重新告诉 AI"我们项目的规范是..."，个人技巧无法成为团队资产

感知信号：当你发现 AI 生成的代码修改量超过 30%，或者你在一次会话里说了 3 次以上"不对，我们项目里要这样..."，说明你已经撞到了 L0 的天花板。

进阶路径

L0 氛围编程（你现在在这）
    │
    ├── 下一步：L1 提示词工程
    │   把"我们项目里要这样"沉淀到 copilot-instructions.md
    │   AI 每次都自动遵守，不用重复说
    │
    └── 快车道：直接用 @agile-team/wl-skills-kit
        npx @agile-team/wl-skills-kit
        一键导入 13 条规范 + 9 个 Skill + MCP 配置
        直接跳到 L2/L3 起手

参考资料

资源	说明
Andrej Karpathy — Vibe Coding 概念推文	"Vibe Coding" 概念出处，2025年2月
Simon Willison — What I learned about Vibe Coding	对氛围编程优缺点的深度分析
GitHub Copilot 官方文档	从 Vibe Coding 到结构化使用的官方指引

特征

特征	说明
输入	自然语言描述，无结构化要求
AI 行为	自由发挥，依赖训练数据中的通用模式
输出稳定性	低（相同描述可能产生不同结果）
还原度	低（无项目规范约束）
适用场景	快速探索、学习、原型验证

为什么不够用？

对于企业级项目，L0 存在明显局限：

• AI 不了解团队约定（命名规范、目录结构、组件用法）
• 每次生成结果差异大，Code Review 负担重
• 无法与后端接口规范对齐
• 生成的代码常违反安全/日志/权限等规范

进阶路径

当你发现 AI 生成的代码频繁需要大幅修改时，是时候升级到 L1 — 提示词工程：通过结构化 Prompt 注入项目规范，让 AI 的输出更可预测。

或者直接使用 L2 — Skill：通过 @agile-team/wl-skills-kit 一键导入 13 条编码规范 + 9 个触发词驱动的 Skill，将 L0 的随机性降到最低。