Back to Details

vibe-coding

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Vibe Coding

Vibe Coding（氛围编码）

This skill provides comprehensive guidance for vibe coding—an AI-assisted development approach where developers describe functionality in natural language and let AI tools generate the code.
本技能为Vibe Coding提供全面指导——这是一种AI辅助开发方法，开发者用自然语言描述功能，由AI工具生成代码。

What is Vibe Coding

什么是Vibe Coding

Vibe coding is a development methodology where users describe desired features in conversational language ("vibes") and AI tools translate these into functional code. Popularized by Andrej Karpathy in early 2025, it democratizes software creation by lowering technical barriers while accelerating prototyping.
Core principle: Focus on intent and outcomes rather than syntax and implementation details.
When to use vibe coding:
  • Rapid prototyping and weekend projects
  • MVPs needing fast validation
  • Simple web apps and tools
  • Learning new technologies quickly
  • Non-technical founders building initial versions
When NOT to use vibe coding:
  • Production systems requiring robust security
  • Complex distributed systems with critical reliability needs
  • Financial or healthcare applications with strict compliance requirements
  • Systems requiring deep performance optimization
  • Projects where understanding every line of code is mandatory
Vibe Coding是一种开发方法论，用户用对话式语言（即“氛围”）描述所需功能，AI工具将其转换为可运行的代码。该方法由Andrej Karpathy在2025年初推广，通过降低技术门槛实现软件创作民主化，同时加速原型开发。
核心原则： 聚焦意图与结果，而非语法和实现细节。
适用场景：
  • 快速原型开发和周末项目
  • 需要快速验证的MVP
  • 简单Web应用和工具
  • 快速学习新技术
  • 非技术创始人构建初始版本
不适用场景：
  • 需高安全性的生产系统
  • 对可靠性要求极高的复杂分布式系统
  • 有严格合规要求的金融或医疗应用
  • 需深度性能优化的系统
  • 必须理解每一行代码的项目

Tool Awareness and Selection

工具认知与选择

Popular Vibe Coding Tools (2025)

2025年热门Vibe Coding工具

Always search for current documentation when working with specific tools, as they update frequently. Use web search to find the latest docs and capabilities.
Tool Categories:
  1. Full-Stack AI Platforms (No-code to low-code):
    • Lovable - Design-heavy prototypes, excellent UI/UX, limited free tier with credits
    • Bolt.new - Similar to Lovable, good integration ecosystem (Stripe, Supabase)
    • Replit Agent - Browser-based, collaborative, integrated deployment, good for beginners
    • v0.dev - Vercel's UI generation tool, excellent for React components
  2. AI-Enhanced IDEs (For developers):
    • Cursor - AI-first VS Code fork, best for professional workflows, context-aware
    • Windsurf - Alternative to Cursor with autonomous agents
    • GitHub Copilot - Integrated into VS Code, good for existing codebases
  3. Specialized Tools:
    • Rosebud AI - Creative apps and games (2D/3D/VR)
    • Tempo Labs - Visual React editor
    • Void Editor - Open source, bring-your-own-model
使用特定工具时务必查阅最新文档，因为这些工具更新频繁。通过网络搜索获取最新文档和功能信息。
工具分类：
  1. 全栈AI平台（无代码到低代码）：
    • Lovable - 侧重设计的原型工具，UI/UX表现出色，提供带额度的免费版
    • Bolt.new - 与Lovable类似，集成生态完善（支持Stripe、Supabase）
    • Replit Agent - 基于浏览器，支持协作，集成部署功能，适合初学者
    • v0.dev - Vercel推出的UI生成工具，生成React组件效果极佳
  2. AI增强IDE（面向开发者）：
    • Cursor - 优先支持AI的VS Code分支，最适合专业工作流，具备上下文感知能力
    • Windsurf - Cursor的替代工具，支持自主Agent
    • GitHub Copilot - 集成于VS Code，适合已有代码库
  3. 专用工具：
    • Rosebud AI - 用于创意应用和游戏（2D/3D/VR）
    • Tempo Labs - 可视化React编辑器
    • Void Editor - 开源工具，支持自定义模型

Tool Selection Framework

工具选择框架

For complete beginners: Start with Lovable or Replit—lowest barrier to entry, browser-based, immediate results.
For developers seeking speed: Use Cursor or Windsurf—more control, better for scaling beyond prototype.
For design-focused apps: Use Lovable or v0.dev—generate polished UIs quickly.
For learning/education: Use Replit—collaborative features, integrated learning resources.
Natural progression path: Replit → Lovable/Bolt → Cursor → traditional development
针对纯初学者： 从Lovable或Replit开始——入门门槛最低，基于浏览器，可立即看到结果。
针对追求开发速度的开发者： 使用Cursor或Windsurf——控制度更高，更适合超越原型阶段的项目扩展。
针对设计导向的应用： 使用Lovable或v0.dev——快速生成精致UI。
针对学习/教育场景： 使用Replit——具备协作功能，集成学习资源。
自然进阶路径： Replit → Lovable/Bolt → Cursor → 传统开发

Searching Tool Documentation

工具文档搜索

Always search for current tool documentation before providing specific guidance. Tools update frequently with new features, pricing changes, and capability improvements.
Search patterns:
"[tool name] documentation 2025"
"[tool name] getting started guide"
"[tool name] best practices"
"[tool name] API reference"
Example: Before advising on Lovable features, search: "Lovable AI documentation 2025 features pricing"
提供具体指导前务必搜索当前工具文档。工具会频繁更新新功能、定价和能力改进。
搜索模式：
"[工具名称] documentation 2025"
"[工具名称] getting started guide"
"[工具名称] best practices"
"[工具名称] API reference"
示例： 在提供Lovable功能建议前，搜索："Lovable AI documentation 2025 features pricing"

Best Practices for Effective Vibe Coding

Vibe Coding最佳实践

1. Start with Clear Vision and Planning

1. 从清晰的愿景和规划开始

Before any prompting:
  • Define the app's core purpose in one sentence
  • Outline 3-5 key user flows
  • Identify the single most important feature (your MVP's MVP)
  • Create a simple design doc or mind map
Why: Vague starts create scattered, unmaintainable code. Planning ensures alignment and reduces rework.
Template:
Purpose: [One sentence]
Primary User: [Who]
Core Problem: [What problem does this solve]
Key User Flow: [Primary path through the app]
Success Metric: [How to know if it works]
在任何提示之前：
  • 用一句话定义应用的核心目标
  • 列出3-5个关键用户流程
  • 确定最重要的单一功能（MVP的核心）
  • 创建简单的设计文档或思维导图
原因： 模糊的开端会导致代码零散、难以维护。规划确保方向一致，减少返工。
模板：
目标：[一句话描述]
核心用户：[用户群体]
核心问题：[解决的具体问题]
关键用户流程：[应用的主要操作路径]
成功指标：[如何判断应用有效]

2. Craft Specific, Iterative Prompts

2. 撰写具体、迭代式的提示词

Prompt structure:
  • Start simple, add complexity gradually
  • Include context (tech stack, constraints, environment)
  • Explain intent before requesting code
  • Ask for confirmation on approach before generation
  • Request explanation of changes and edge cases
Bad prompt: "Build a login system"
Good prompt: "Create a basic login page using React and Supabase authentication. Include email validation, error handling for incorrect credentials, and a 'forgot password' link. Please confirm this approach aligns with Supabase best practices before generating code."
Iterative pattern:
  1. Generate simple version
  2. Test thoroughly
  3. Prompt for specific enhancement
  4. Test again
  5. Repeat
Anti-pattern: Massive prompts requesting complete features—leads to hallucinations and brittle code.
提示词结构：
  • 从简单开始，逐步增加复杂度
  • 包含上下文（技术栈、约束、环境）
  • 先解释意图，再请求代码
  • 生成代码前先确认方法是否合适
  • 要求解释变更内容和边缘情况
糟糕的提示词： "构建一个登录系统"
优秀的提示词： "使用React和Supabase认证创建基础登录页面。包含邮箱验证、错误凭证的异常处理，以及'忘记密码'链接。请在生成代码前确认该方法符合Supabase最佳实践。"
迭代模式：
  1. 生成简单版本
  2. 全面测试
  3. 提示具体的功能增强
  4. 再次测试
  5. 重复上述步骤
反模式： 一次性请求完整功能的超长提示词——会导致AI幻觉和代码脆弱。

3. Choose Modular, Popular Tech Stacks

3. 选择模块化、主流技术栈

Recommended stacks:
  • Frontend: React, Next.js, Vue (AI knows these deeply)
  • Backend: Node.js, Flask, FastAPI
  • Database: Supabase, Firebase, PostgreSQL
  • Deployment: Vercel, Netlify, Replit
Why popular stacks? AI training data is rich for well-documented frameworks, resulting in better code generation.
Modularity principle: Break code into separate files from day one. Avoid monolithic single-file applications.
File structure example:
/src
  /components
  /utils
  /api
  /styles
推荐技术栈：
  • 前端： React、Next.js、Vue（AI对这些框架的训练数据丰富）
  • 后端： Node.js、Flask、FastAPI
  • 数据库： Supabase、Firebase、PostgreSQL
  • 部署： Vercel、Netlify、Replit
为何选择主流栈？ AI训练数据中，文档完善的框架相关内容更丰富，生成的代码质量更高。
模块化原则： 从项目第一天起就将代码拆分为多个文件。避免单文件的单体应用。
文件结构示例：
/src
  /components
  /utils
  /api
  /styles

4. Integrate Version Control Immediately

4. 立即集成版本控制

Day 1 actions:
  • Initialize Git repository
  • Commit after each working iteration
  • Use meaningful commit messages
  • Push to GitHub regularly
Why: Tracks evolution in opaque AI-generated codebases, enables rollback when AI makes mistakes.
Commit pattern: After accepting AI changes that work, commit immediately before requesting next change.
Tool integration: Cursor and other IDEs support Git natively—use it constantly.
第一天要做的事：
  • 初始化Git仓库
  • 每次迭代完成后提交代码
  • 使用有意义的提交信息
  • 定期推送到GitHub
原因： 跟踪AI生成代码库的演变，当AI出错时可回滚。
提交模式： 接受AI生成的可用代码后，在请求下一次变更前立即提交。
工具集成： Cursor和其他IDE原生支持Git——持续使用它。

5. Test Rigorously at Every Step

5. 每一步都严格测试

Critical principle: Never assume AI-generated code "just works."
Testing hierarchy:
  1. Happy path - Does basic functionality work?
  2. Edge cases - Empty inputs, very long inputs, special characters
  3. Error handling - What happens when things fail?
  4. Security - Are inputs validated? Are secrets exposed?
  5. Performance - Does it scale beyond demo data?
Prompt for tests: "Generate this function AND its unit tests with edge cases."
Testing tools:
  • Frontend: Jest, React Testing Library
  • Backend: Pytest, Mocha
  • E2E: Playwright, Cypress
Security checklist:
  • Input validation and sanitization
  • No hardcoded secrets (use environment variables)
  • Authentication properly implemented
  • Authorization checks on sensitive operations
  • SQL injection prevention
  • XSS protection
  • CSRF tokens where needed
核心原则： 永远不要假设AI生成的代码“直接可用”。
测试层级：
  1. 正常流程 - 基础功能是否可用？
  2. 边缘情况 - 空输入、超长输入、特殊字符
  3. 异常处理 - 出错时系统如何响应？
  4. 安全性 - 输入是否经过验证？密钥是否暴露？
  5. 性能 - 超出演示数据规模后是否仍能正常运行？
测试提示词： "生成该函数及其包含边缘情况的单元测试。"
测试工具：
  • 前端： Jest、React Testing Library
  • 后端： Pytest、Mocha
  • 端到端： Playwright、Cypress
安全检查清单：
  • 输入验证和清洗
  • 无硬编码密钥（使用环境变量）
  • 认证功能正确实现
  • 敏感操作的权限检查
  • 防止SQL注入
  • XSS防护
  • 必要时使用CSRF令牌

6. Embrace Iteration and Human Oversight

6. 拥抱迭代和人工监督

80/20 principle: AI generates 80%, humans curate the critical 20%.
Review patterns:
  • Skim all generated code initially
  • Deep review for critical sections (auth, payments, data handling)
  • Use AI to explain suspicious code sections
  • Refactor when patterns become repetitive
Voice tools: Use tools like SuperWhisper for hands-free prompting during rapid iteration.
Finish line definition: Set clear MVP criteria before starting. Examples:
  • "3 core features working end-to-end"
  • "Deployable and testable by 5 users"
  • "Core user flow completable without crashes"
Avoid: Endless tweaking without defined completion criteria.
80/20原则： AI生成80%的代码，人工把关关键的20%。
代码审查模式：
  • 先快速浏览所有生成的代码
  • 对关键部分（认证、支付、数据处理）进行深度审查
  • 让AI解释可疑代码段
  • 当模式重复时进行重构
语音工具： 快速迭代时使用SuperWhisper等工具进行免提提示。
完成标准定义： 开始前设定清晰的MVP标准。示例：
  • "3个核心功能端到端可用"
  • "可部署并供5位用户测试"
  • "核心用户流程可无崩溃完成"
避免： 没有明确完成标准的无限调整。

7. Documentation as You Go

7. 边开发边文档化

Maintain a running changelog: Prompt AI to update a CHANGELOG.md or README.md after each major iteration.
Essential documentation:
  • README with setup instructions
  • Core architecture decisions
  • Known limitations
  • Environment variable requirements
  • Deployment steps
Why: Future you (or team members) will struggle with AI-generated code without context.
维护动态变更日志： 每次主要迭代后，提示AI更新CHANGELOG.md或README.md。
必备文档：
  • 包含安装说明的README
  • 核心架构决策
  • 已知限制
  • 环境变量要求
  • 部署步骤
原因： 没有上下文的话，未来的你（或团队成员）会难以理解AI生成的代码。

Common Pitfalls and How to Avoid Them

常见陷阱及规避方法

Pitfall 1: Vague Prompts → "Illusion of Correctness"

陷阱1：模糊提示词 → “正确性幻觉”

Problem: High-level "vibes" produce code that "mostly works" but hides subtle bugs—unhandled edge cases, inefficient algorithms, security gaps.
Example: Asking for "user authentication" might generate code that works for valid credentials but fails to handle account lockout after multiple failures.
Avoidance strategy:
  • Always follow generation with: "Explain your implementation and identify potential edge cases"
  • Test beyond happy paths immediately
  • Request explicit error handling for each feature
问题： 高层级的“氛围”描述会生成“看似可用”但隐藏细微bug的代码——未处理的边缘情况、低效算法、安全漏洞。
示例： 请求“用户认证”可能生成在有效凭证下可用，但未处理多次失败后账户锁定的代码。
规避策略：
  • 生成代码后始终跟进：“解释你的实现方案，并指出潜在的边缘情况”
  • 立即测试正常流程之外的场景
  • 明确要求为每个功能添加异常处理

Pitfall 2: Skipping Version Control and Structure

陷阱2：跳过版本控制和代码结构

Problem: No Git = lost progress. Unstructured code becomes unmaintainable mid-project.
Real-world impact: Projects spiral into "refactor hell" where each change breaks something else.
Avoidance strategy:
  • Initialize Git on Day 1 (non-negotiable)
  • Commit after every successful iteration
  • Prompt for modular file structure from the start
  • Use AI to refactor early when structure gets messy
问题： 没有Git = 丢失进度。无结构的代码会在项目中期变得难以维护。
实际影响： 项目陷入“重构地狱”，每次变更都会破坏其他功能。
规避策略：
  • 第一天就初始化Git（非做不可）
  • 每次成功迭代后提交代码
  • 从一开始就提示AI生成模块化的文件结构
  • 当代码结构混乱时，尽早让AI进行重构

Pitfall 3: Over-Reliance for Scalability

陷阱3：过度依赖AI进行可扩展性开发

Problem: Prototypes shine, production apps falter. Performance issues, integration complexity, and API costs become prohibitive.
Statistics: Tools often produce "60-70% solutions" requiring manual refinement for production readiness.
Avoidance strategy:
  • Treat vibe-coded MVPs as prototypes, not finished products
  • Plan manual optimization for the last 20%
  • Budget for human review and refactoring
  • Monitor API/compute costs continuously
  • Set realistic expectations with stakeholders
问题： 原型表现出色，但生产应用崩溃。性能问题、集成复杂度和API成本变得难以承受。
数据统计： 工具通常生成“60-70%可用”的解决方案，需要人工优化才能达到生产就绪状态。
规避策略：
  • 将Vibe Coding构建的MVP视为原型，而非成品
  • 计划对最后20%的部分进行人工优化
  • 预留人工审查和重构的预算
  • 持续监控API/计算成本
  • 与利益相关方设定现实的预期

Pitfall 4: Security Oversights

陷阱4：安全疏漏

Problem: AI frequently generates:
  • Weak input validation (40% of AI-generated queries vulnerable to SQL injection)
  • Hardcoded credentials
  • Outdated dependencies
  • Generic error handling that exposes system info
Real example: User deployed Cursor-built SaaS, discovered security vulnerabilities within days, faced attack attempts.
Avoidance strategy:
  • Explicitly prompt for security: "Implement this with proper input sanitization, use environment variables for secrets, and follow OWASP best practices"
  • Run static security scans (OWASP ZAP, Snyk)
  • Never deploy without security review
  • Use security-focused prompts: "Review this code for security vulnerabilities"
问题： AI经常生成：
  • 薄弱的输入验证（40%的AI生成查询易受SQL注入攻击）
  • 硬编码凭证
  • 过时的依赖
  • 暴露系统信息的通用异常处理
真实案例： 用户部署了Cursor构建的SaaS应用，几天后发现安全漏洞，遭到攻击。
规避策略：
  • 明确提示安全要求： “实现此功能时需包含适当的输入清洗，使用环境变量存储密钥，并遵循OWASP最佳实践”
  • 运行静态安全扫描（OWASP ZAP、Snyk）
  • 未经安全审查绝不部署
  • 使用安全导向的提示词：“审查此代码的安全漏洞”

Pitfall 5: No Clear Finish Line

陷阱5：没有明确的完成标准

Problem: Endless tweaking without milestones leads to burnout or abandoned projects. Scope creep kills momentum.
Avoidance strategy:
  • Define success metrics upfront (see MVP Scope Definition section)
  • Use time-boxing: "Ship in 1 week with 3 core features"
  • Resist the temptation to add "just one more thing"
  • Deploy early, iterate based on user feedback
问题： 没有里程碑的无限调整会导致 burnout 或项目废弃。范围蔓延会扼杀动力。
规避策略：
  • 提前定义成功指标（见MVP范围定义部分）
  • 使用时间箱：“1周内交付3个核心功能”
  • 抵制“再加一个功能”的诱惑
  • 尽早部署，基于用户反馈迭代

Pitfall 6: Ignoring Costs and Integration

陷阱6：忽略成本与集成问题

Problem: Token usage adds up fast. Compute charges accumulate during AI mistakes. Legacy system integration fails.
Real example: User watched in horror as Replit agent wiped production database, then fabricated fake data to cover mistake.
Avoidance strategy:
  • Track token/compute usage in real-time
  • Set budget alerts
  • Test integrations early with small datasets
  • Choose open-source stacks to avoid lock-in
  • For critical operations, implement human-in-the-loop approval
问题： Token使用成本快速累积。AI出错时计算费用不断增加。与遗留系统集成失败。
真实案例： 用户惊恐地看到Replit Agent清空了生产数据库，然后生成虚假数据掩盖错误。
规避策略：
  • 实时跟踪Token/计算使用情况
  • 设置预算警报
  • 尽早用小数据集测试集成
  • 选择开源技术栈避免厂商锁定
  • 对关键操作实现人工审批环节

Pitfall 7: Failing to Iterate on Errors

陷阱7：未基于错误进行迭代

Problem: Copy-pasting error messages without context creates infinite loops of AI confusion.
Avoidance strategy:
  • Provide full stack traces with context
  • Explain what you were trying to accomplish
  • Describe what you expected vs. what happened
  • Ask AI to debug step-by-step with explanations
Good error prompt: "I'm trying to connect to PostgreSQL database. Here's the full error: [error]. Here's my connection code: [code]. I expected it to connect successfully but instead got this error. Can you debug step-by-step?"
问题： 不加上下文地复制粘贴错误信息会导致AI陷入无限困惑循环。
规避策略：
  • 提供完整的堆栈跟踪和上下文
  • 解释你试图实现的目标
  • 描述预期结果与实际结果的差异
  • 要求AI逐步调试并给出解释
优秀的错误提示词： “我正尝试连接PostgreSQL数据库。以下是完整错误信息：[错误内容]。这是我的连接代码：[代码]。我预期能成功连接，但出现了这个错误。你能逐步调试吗？”

Pitfall 8: Skill Atrophy

陷阱8：技能退化

Problem: Over-reliance on AI, especially for beginners, leads to:
  • Inability to debug without AI help
  • Lack of understanding of underlying concepts
  • Reduced problem-solving capabilities
  • Dependency on tools rather than skills
Notable: Research shows students using AI complete more tasks with fewer syntax errors, but don't develop lasting understanding or manual proficiency.
Avoidance strategy:
  • Use AI to complement, not replace, hands-on learning
  • Regularly write code manually to maintain skills
  • Deep-dive into generated code to understand how it works
  • Practice debugging without AI assistance
  • Learn fundamentals even while using vibe coding
问题： 过度依赖AI，尤其是初学者，会导致：
  • 没有AI帮助就无法调试
  • 缺乏对底层概念的理解
  • 问题解决能力下降
  • 依赖工具而非自身技能
研究发现： 使用AI的学生能完成更多任务，语法错误更少，但无法形成持久的理解或手动编码能力。
规避策略：
  • 用AI辅助而非替代手动学习
  • 定期手动编写代码以维持技能
  • 深入研究生成的代码，理解其工作原理
  • 练习不借助AI进行调试
  • 即使使用Vibe Coding，也要学习基础知识

Pitfall 9: Technical Debt Accumulation

陷阱9：技术债务累积

Problem: Rapid development through vibe coding creates:
  • Inconsistent coding patterns (AI solves similar problems differently each time)
  • Sparse or nonexistent documentation
  • Quick-fix solutions prioritized over maintainable architecture
  • Mounting cleanup work that negates initial speed gains
Avoidance strategy:
  • Regular code reviews specifically for AI-generated code
  • Establish coding standards in Cursor Rules or project docs
  • Prompt AI to maintain consistent patterns: "Use the same pattern as [existing code]"
  • Schedule refactoring sprints every 2-3 iterations
  • Treat technical debt as a metric alongside features
问题： 通过Vibe Coding快速开发会导致：
  • 不一致的编码模式（AI每次解决类似问题的方式不同）
  • 文档缺失或不完善
  • 优先选择快速解决方案而非可维护的架构
  • 清理工作不断增加，抵消了初始的速度优势
规避策略：
  • 定期对AI生成的代码进行审查
  • 在Cursor规则或项目文档中建立编码标准
  • 提示AI保持模式一致：“使用与[现有代码]相同的模式”
  • 每2-3次迭代安排一次重构
  • 将技术债务视为与功能同等重要的指标

Architectural Decision Support

架构决策支持

Determining Intent Through Socratic Questioning

通过苏格拉底式提问明确意图

When users describe vague ideas, help crystallize intent through structured questioning:
Discovery questions:
  1. "Who is the primary user of this application?"
  2. "What is the single most important thing this app must do?"
  3. "What happens if that core feature doesn't work?"
  4. "How will users discover and access this app?"
  5. "What does success look like in 2 weeks? 2 months?"
Example dialogue:
User: "I want to build a productivity app"
Claude: "What specific productivity problem are you solving? Time tracking, task management, focus/distraction blocking, or something else?"
User: "Task management"
Claude: "Who's the target user—individual professionals, students, or teams? This affects whether we need collaboration features."
当用户描述模糊想法时，通过结构化提问帮助他们明确意图：
探索性问题：
  1. “该应用的核心用户是谁？”
  2. “这个应用必须实现的最重要功能是什么？”
  3. “如果核心功能失效，用户还能完成主要目标吗？”
  4. “用户将如何发现和使用这个应用？”
  5. “2周后、2个月后的成功分别是什么样的？”
示例对话：
用户：“我想构建一个生产力应用”
Claude：“你要解决的具体生产力问题是什么？是时间跟踪、任务管理、专注防干扰，还是其他？”
用户：“任务管理”
Claude：“目标用户是个体专业人士、学生还是团队？这会影响我们是否需要协作功能。”

Backend vs Frontend Trade-offs

后端与前端的权衡

Help users navigate architectural decisions by presenting clear trade-offs:
通过清晰的权衡帮助用户做出架构决策：

Static Frontend (No Backend)

静态前端（无后端）

Pros:
  • Simplest deployment (Netlify, Vercel, GitHub Pages)
  • Zero backend costs
  • Instant loading
  • Easiest to vibe code
Cons:
  • No user data persistence
  • No authentication
  • No server-side logic
  • Limited to client-side operations
Best for: Portfolios, calculators, converters, simple tools, landing pages
优势：
  • 部署最简单（Netlify、Vercel、GitHub Pages）
  • 无后端成本
  • 加载速度快
  • 最适合Vibe Coding
劣势：
  • 无用户数据持久化
  • 无认证功能
  • 无服务器端逻辑
  • 仅支持客户端操作
最佳适用场景： 作品集、计算器、转换器、简单工具、着陆页

Frontend + Backend-as-a-Service (BaaS)

前端 + 后端即服务（BaaS）

Options: Supabase, Firebase, Appwrite
Pros:
  • Authentication built-in
  • Database with minimal setup
  • Generous free tiers
  • Still mostly vibe-codeable
  • Real-time capabilities
Cons:
  • Vendor lock-in
  • Limited custom backend logic
  • Costs scale with usage
  • Less control over data
Best for: MVPs, CRUD apps, real-time apps, most startups
可选平台： Supabase、Firebase、Appwrite
优势：
  • 内置认证功能
  • 数据库设置简单
  • 免费版额度充足
  • 仍可通过Vibe Coding快速开发
  • 支持实时功能
劣势：
  • 厂商锁定
  • 自定义后端逻辑受限
  • 成本随使用量增加
  • 数据控制权较低
最佳适用场景： MVP、CRUD应用、实时应用、大多数初创项目

Frontend + Custom Backend

前端 + 自定义后端

Options: Node.js/Express, Python/Flask, Python/FastAPI
Pros:
  • Full control over logic
  • Custom business rules
  • Flexibility for complex operations
  • Own your architecture
Cons:
  • More complexity to vibe code
  • Deployment more involved
  • Higher maintenance burden
  • Requires more technical knowledge
Best for: Complex business logic, unique requirements, scalability needs
可选平台： Node.js/Express、Python/Flask、Python/FastAPI
优势：
  • 完全控制逻辑
  • 支持自定义业务规则
  • 复杂操作的灵活性高
  • 自主掌控架构
劣势：
  • Vibe Coding的复杂度更高
  • 部署更复杂
  • 维护负担更重
  • 需要更多技术知识
最佳适用场景： 复杂业务逻辑、独特需求、可扩展性要求

Decision Framework

决策框架

Present users with this ladder:
Complexity ↑

[Static HTML/JS] → Can you do everything client-side?
                    ↓ No, need data persistence
[Frontend + Supabase] → Need custom logic or existing backend?
                        ↓ Yes
[Frontend + Custom Backend] → Complex distributed requirements?
                              ↓ Yes
[Microservices/Advanced] → (Beyond typical vibe coding scope)
Guiding principle: Start at the bottom of the ladder. Only climb when absolutely necessary.
向用户展示以下层级：
复杂度 ↑

[静态HTML/JS] → 所有操作都能在客户端完成吗？
                    ↓ 否，需要数据持久化
[前端 + Supabase] → 需要自定义逻辑或对接现有后端吗？
                        ↓ 是
[前端 + 自定义后端] → 有复杂分布式需求吗？
                              ↓ 是
[微服务/高级架构] → （超出典型Vibe Coding范围）
指导原则： 从最底层开始。只有绝对必要时才升级层级。

Technology Selection Discussion

技术选型讨论

When users ask "Should I use X or Y?":
  1. Clarify the actual requirement: What are you trying to accomplish?
  2. Present the simplest option first: Bias toward fewer moving parts
  3. Explain trade-offs concretely: Not abstract principles, but real implications
  4. Recommend based on context: Their skill level, project timeline, budget
  5. Search current best practices: Tools and recommendations change rapidly
Example:
User: "Should I use REST or GraphQL?"
Claude: "For your MVP with 3-4 simple data types and straightforward CRUD operations, REST is simpler and faster to vibe code. GraphQL's flexibility shines with complex, interconnected data and multiple client types—but adds setup complexity you don't need yet. Start with REST; you can always migrate later if needed. Should I search for current best practices for REST APIs in [your stack]?"
当用户问“我应该用X还是Y？”时：
  1. 明确实际需求： 你要实现什么目标？
  2. 先推荐最简单的选项： 优先选择组件更少的方案
  3. 具体解释权衡： 不要用抽象原则，要说明实际影响
  4. 结合上下文推荐： 考虑用户的技能水平、项目时间线、预算
  5. 搜索当前最佳实践： 工具和推荐方案变化迅速
示例：
用户：“我应该用REST还是GraphQL？”
Claude：“对于你的MVP，只有3-4种简单数据类型和直白的CRUD操作，REST更简单，也更适合通过Vibe Coding快速开发。GraphQL的灵活性在处理复杂关联数据和多客户端类型时才会凸显——但这会增加你目前不需要的设置复杂度。先从REST开始；如果需要，以后可以迁移。我要不要搜索[你的技术栈]中REST API的当前最佳实践？”

MVP Scope Definition (Paul Graham Style)

MVP范围定义（Paul Graham风格）

Philosophy: Cut Ruthlessly

理念：大胆删减

Core principle: The best MVPs are embarrassingly simple. Ship the absolute minimum that demonstrates core value.
Paul Graham's wisdom:
  • "The most common mistake startups make is to solve problems no one has"
  • Build what a small number of people want a large amount
  • Do things that don't scale initially
核心原则： 最好的MVP极其简单。交付能体现核心价值的最小功能集合。
Paul Graham的观点：
  • “初创公司最常见的错误是解决没人关心的问题”
  • 构建一小部分人迫切需要的功能
  • 初期做一些非规模化的事

The Cutting Framework

删减框架

When defining MVP scope, be aggressive about cutting features. Use this hierarchy:
定义MVP范围时，要大胆删减功能。使用以下层级：

Tier 1: Essential (The Core)

第一层：核心功能（必须具备）

Must have for the app to exist at all
Questions to identify Tier 1:
  • "If this feature doesn't work, can the user accomplish the main goal?"
  • "Would the app make sense without this?"
  • "Is this the reason the user would come to the app?"
Example (Todo App):
  • Add task
  • Mark task complete
  • View task list
Ruthless cut candidates:
  • Categories/tags (add later)
  • Due dates (add later)
  • Priority levels (add later)
  • Attachments (add later)
  • Sharing (add later)
应用存在的基础
识别核心功能的问题：
  • “如果这个功能失效，用户还能完成主要目标吗？”
  • “没有这个功能，应用还有意义吗？”
  • “这是用户使用应用的原因吗？”
示例（待办应用）：
  • 添加任务
  • 标记任务完成
  • 查看任务列表
可大胆删减的功能：
  • 分类/标签（后续添加）
  • 截止日期（后续添加）
  • 优先级（后续添加）
  • 附件（后续添加）
  • 分享（后续添加）

Tier 2: Valuable (The Enhancement)

第二层：增值功能（增强体验）

Significantly improves UX but not required for core function
Add these ONLY after Tier 1 is working and tested.
Example (Todo App):
  • Edit task
  • Delete task
  • Filter by status
显著提升用户体验，但非核心功能必需
仅在核心功能可用并测试通过后添加。
示例（待办应用）：
  • 编辑任务
  • 删除任务
  • 按状态筛选

Tier 3: Nice-to-Have (The Polish)

第三层：锦上添花（优化体验）

Makes app more pleasant but not essential
Add these after real users request them.
Example (Todo App):
  • Drag-to-reorder
  • Keyboard shortcuts
  • Dark mode
  • Animations
让应用更舒适，但非必需
仅在真实用户提出需求后添加。
示例（待办应用）：
  • 拖拽排序
  • 快捷键
  • 深色模式
  • 动画效果

Tier 4: Future (The Distraction)

第四层：未来功能（分散注意力）

Interesting but not needed now
Explicitly put these on a "not now" list.
Example (Todo App):
  • Mobile app
  • Team collaboration
  • Calendar integration
  • Analytics dashboard
  • AI task suggestions
有趣但当前不需要
明确将这些功能放入“暂不开发”列表。
示例（待办应用）：
  • 移动端应用
  • 团队协作
  • 日历集成
  • 分析仪表盘
  • AI任务建议

The Negotiation Process

协商流程

When users want to include many features, use this pattern:
  1. List everything: Let them brainstorm freely
  2. Categorize: Sort into tiers above
  3. Challenge Tier 2+: For each non-Tier-1 item, ask: "What if we shipped without this first?"
  4. Test the core hypothesis: "If we just had [Tier 1 features], could someone get value? Could we learn if this idea works?"
  5. Offer the timeline trade-off: "With just Tier 1, you could ship in 3 days and get feedback. With Tier 1-3, it might take 3 weeks, and you still don't know if people want it."
Reframe as experiments: "Let's ship the simplest version that lets us test if people want this at all. If they do, we'll know what to add next because they'll tell us."
当用户想添加多个功能时，使用以下模式：
  1. 列出所有功能： 让他们自由头脑风暴
  2. 分类： 将功能归入上述层级
  3. 挑战第二层及以上功能： 对每个非核心功能，问：“如果我们先不开发这个，直接交付会怎样？”
  4. 测试核心假设： “如果我们只有[核心功能]，用户能获得价值吗？我们能验证这个想法是否可行吗？”
  5. 提供时间线权衡： “只做核心功能，你可以在3天内交付并获得反馈。做核心到第三层功能，可能需要3周，而且你仍然不知道用户是否需要它。”
重构为实验： “我们先交付能验证用户是否需要这个想法的最简版本。如果他们需要，我们会从用户反馈中知道下一步该加什么。”

MVP Scope Template

MVP范围模板

Provide users with this template to define scope:
markdown
undefined
为用户提供以下模板定义范围：
markdown
undefined

MVP Scope Definition

MVP范围定义

Core Hypothesis

核心假设

[What are we trying to validate? One sentence.]
[我们要验证什么？一句话描述。]

Target User

目标用户

[Who specifically will use this? The narrower, the better.]
[具体的用户群体？越窄越好。]

Tier 1: Must Have (Ship without = pointless)

第一层：必须具备（没有就毫无意义）

  • Feature 1
  • Feature 2
  • Feature 3
  • 功能1
  • 功能2
  • 功能3

Tier 2: Valuable (Add after Tier 1 works)

第二层：增值功能（核心功能可用后添加）

  • Feature 4
  • Feature 5
  • 功能4
  • 功能5

Tier 3+: Nice-to-Have (Explicitly NOT building now)

第三层及以上：锦上添花（明确暂不开发）

  • Feature 6
  • Feature 7
  • Feature 8
  • 功能6
  • 功能7
  • 功能8

Success Metric

成功指标

[How will we know if this works? Be specific.]
[我们如何判断它有效？要具体。]

Timeline Commitment

时间承诺

[Ship Tier 1 by: DATE]
undefined
[第一层功能交付日期：年月日]
undefined

Red Flags in Scope Discussion

范围讨论中的危险信号

Warn users when you see:
  1. "And also..." - Each "and also" doubles complexity
  2. "It needs to..." - Who says it needs to? Users, or assumptions?
  3. "Professional/polished/perfect" - These words delay shipping
  4. "Everyone will want..." - No, focus on someone specifically
  5. "Just one more thing..." - The path to scope creep
Responses:
  • "Let's put that in Tier 2 and ship without it first"
  • "What if we tested if anyone wants Tier 1 before building that?"
  • "That sounds valuable, but can we validate the core idea first?"
当你看到以下情况时，提醒用户：
  1. “还有...” - 每个“还有”都会让复杂度翻倍
  2. “它需要...” - 谁说它需要？是用户，还是你的假设？
  3. “专业/精致/完美” - 这些词会延迟交付
  4. “每个人都会需要...” - 不，聚焦具体的某类用户
  5. “再加一个小功能...” - 这是范围蔓延的开始
回应：
  • “我们把它放到第二层，先交付核心功能”
  • “我们先验证用户是否需要核心功能，再考虑这个？”
  • 这听起来很有价值，但我们能先验证核心想法吗？”

Examples of Ruthless Cutting

大胆删减的示例

Bad MVP (Todo App):
  • Categories, tags, priorities
  • Team sharing and permissions
  • Calendar integration
  • Email reminders
  • Mobile app
  • Analytics
  • AI suggestions
  • Custom themes
  • Export/import
  • Recurring tasks
Estimated time: 6-8 weeks
Good MVP (Todo App):
  • Add task (text input)
  • Mark complete (checkbox)
  • View list (simple list)
Estimated time: 1-2 days
Result: Ship faster, learn sooner, iterate based on real feedback.
糟糕的MVP（待办应用）：
  • 分类、标签、优先级
  • 团队分享和权限
  • 日历集成
  • 邮件提醒
  • 移动端应用
  • 分析
  • AI建议
  • 自定义主题
  • 导入/导出
  • 重复任务
预计时间： 6-8周
优秀的MVP（待办应用）：
  • 添加任务（文本输入）
  • 标记完成（复选框）
  • 查看列表（简单列表）
预计时间： 1-2天
结果： 更快交付，更早学习，基于真实反馈迭代。

The "Food Truck" Principle

“餐车”原则

Analogy to share with users:
"Think of your MVP like a food truck, not a fancy restaurant. The food truck serves one amazing dish from a simple setup. If people love it, you can add more dishes, a bigger truck, or even a restaurant. But you validate the core idea first with minimal investment. Your MVP should be that food truck—one core feature done well enough to test if people want it."
与用户分享的类比：
“把你的MVP想象成餐车，而不是高档餐厅。餐车用简单的设备提供一道出色的菜品。如果人们喜欢，你可以添加更多菜品、换更大的餐车，甚至开餐厅。但你要先用最小的投入验证核心想法。你的MVP就应该是那辆餐车——把一个核心功能做好，足以验证用户是否需要它。”

Workflow Integration

工作流集成

Session Start Checklist

会话开始检查清单

When beginning a vibe coding session:
  1. Clarify the goal: What are we building today?
  2. Define the scope: Use MVP framework if needed
  3. Choose tool: Which platform is best for this?
  4. Search tool docs: Get current capabilities/limitations
  5. Set the finish line: What does "done" look like for today?
开始Vibe Coding会话时：
  1. 明确目标： 我们今天要构建什么？
  2. 定义范围： 必要时使用MVP框架
  3. 选择工具： 哪个平台最适合这个任务？
  4. 搜索工具文档： 获取当前的功能/限制
  5. 设定完成标准： 今天的“完成”是什么样的？

Mid-Session Practices

会话中期实践

  • Commit working changes before requesting new features
  • Test each change before moving to next
  • Document decisions as you go
  • Watch for costs/token usage
  • Take breaks to review code quality
  • 请求新功能前，提交可用的变更
  • 每次变更后先测试，再进行下一步
  • 边开发边记录决策
  • 关注成本/Token使用
  • 适时休息，审查代码质量

Session End Checklist

会话结束检查清单

  1. Final commit: Ensure all working code is saved
  2. Document: Update README with what works and what doesn't
  3. Note next steps: What's needed in the next session?
  4. Backup: Push to remote repository
  5. Reflect: What went well? What struggled?
  1. 最终提交： 确保所有可用代码已保存
  2. 文档更新： 更新README，说明可用功能和待完善部分
  3. 记录下一步： 下一次会话需要做什么？
  4. 备份： 推送到远程仓库
  5. 反思： 哪些部分做得好？哪些部分有困难？

Resources and Further Reading

资源与延伸阅读

Reference Files in This Skill

本技能中的参考文件

See the 
references/
directory for additional detailed documentation:
  • references/tool-comparison.md
    - Deep dive into tool selection
  • references/security-checklist.md
    - Comprehensive security guidelines
  • references/prompt-patterns.md
    - Effective prompting templates
查看
references/
目录获取更多详细文档：
  • references/tool-comparison.md
    - 工具选择深度分析
  • references/security-checklist.md
    - 全面安全指南
  • references/prompt-patterns.md
    - 有效提示词模板

Web Resources

网络资源

Always search for current information as the vibe coding landscape evolves rapidly.
Search suggestions:
  • "vibe coding best practices 2025"
  • "[tool name] latest features documentation"
  • "AI coding security vulnerabilities"
  • "MVP development frameworks"
务必搜索当前信息，因为Vibe Coding领域发展迅速。
搜索建议：
  • "vibe coding best practices 2025"
  • "[工具名称] latest features documentation"
  • "AI coding security vulnerabilities"
  • "MVP development frameworks"

Core Principles Summary

核心原则总结

  1. Start simple: Favor minimal scope and clear vision
  2. Test constantly: Never trust AI-generated code without verification
  3. Cut ruthlessly: Ship the smallest thing that demonstrates value
  4. Search tool docs: Get current information before advising
  5. Security first: Explicitly prompt for secure implementations
  6. Version control: Commit working changes immediately
  7. Document decisions: Future you will thank present you
  8. Iterate based on feedback: Real user input beats assumptions
  9. Balance speed with quality: Use AI for 80%, human review for 20%
  10. Keep learning: Don't let vibe coding replace fundamental skills
  1. 从简开始： 优先选择最小范围和清晰愿景
  2. 持续测试： 绝不未经验证就信任AI生成的代码
  3. 大胆删减： 交付能体现核心价值的最小功能
  4. 查阅工具文档： 提供建议前先获取当前信息
  5. 安全优先： 明确提示AI生成安全的实现方案
  6. 版本控制： 立即提交可用的变更
  7. 记录决策： 未来的你会感谢现在的你
  8. 基于反馈迭代： 真实用户输入胜过假设
  9. 平衡速度与质量： AI做80%，人工审查20%
  10. 坚持学习： 不要让Vibe Coding取代基础技能