Vibe Coding：AI 编程革命与程序员的新时代

引言：2025 - AI 编程元年

2025 年 2 月，OpenAI 创始成员之一、前特斯拉人工智能总监 Andrej Karpathy 在 X（Twitter）上发布了一条看似随意的推文，却引爆了整个技术社区对编程未来的讨论。这条推文首次正式提出了 “Vibe Coding” 这个概念。

“There’s a new kind of coding I call ‘vibe coding’, where you fully give in to the vibes, embrace exponentials, and forget that the code even exists.” — Andrej Karpathy

短短几个月内，Vibe Coding 从一个模糊的概念发展成为程序员茶余饭后必谈的话题。根据 OpenRouter 和 a16z 的联合报告数据，2025 年编程相关请求从年初的 11% 飙升至年底的 50% 以上，2025 年初创公司的代码库中有 95% 是 AI 生成的。

这一切都在宣告一个事实：2025 年是 AI 编程元年，编程范式正在经历一场根本性的变革。

什么是 Vibe Coding

Karpathy 的原始定义

让我们回到 Karpathy 的原始推文，他对自己创造的 Vibe Coding 有几个关键描述：

忘记代码的存在 - “forget that the code even exists”
完全基于对话 - 通过与 LLM（如 Cursor Composer + Sonnet）对话来编程
几乎不手动干预 - 连最微小的错误也通过 AI 修复，而不是手动改代码
不审查代码差异 - “I don’t read the diffs anymore”
只看结果 - “Accept All” 是常态，只关注程序是否能运行
绕过 bug - 当 AI 修不好 bug 时，要么绕过它，要么随机尝试修改直到问题消失

Karpathy 坦言：“我正在构建一个项目或 web 应用，但这并不是真正的编程——我只是看到东西，说东西，运行东西，复制粘贴东西，而且大部分时候它都能工作。”

核心特征总结

基于 Karpathy 的定义，Vibe Coding 的核心特征可以归纳为：

完全 AI 驱动：从需求到代码，全程由 AI 生成，人类只提供自然语言描述
黑盒开发模式：不关注代码实现细节，不审查代码质量，只关注最终效果
快速迭代：通过对话快速修改和调整，效率极高但也容易产生技术债务
适合原型开发：对于一次性项目、周末项目、原型验证非常有效

与传统编程的本质差异

传统编程中，程序员是创意输出者和逻辑构建者，亲自编写每一行代码，理解每个模块的运作原理。而 Vibe Coding 中，人类更像是产品经理或指挥官，通过自然语言指挥 AI 完成具体的编码工作。

这种转变让编程从"如何做"（How）的关注点，转向了"做什么"（What）的描述。

  mindmap
  root((Vibe Coding))
    定义
      Karpathy原创
      完全AI对话
      忘记代码
    工具
      Cursor
      Claude Code
      Replit
      Copilot
    技巧
      Git管理
      设计先行
      模块化
      任务拆解
    风险
      技术债务
      安全漏洞
      维护困难
    影响
      职业变革
      独立开发
      效率提升

Vibe Coding vs Context Coding

在深入讨论之前，我们需要先澄清一个重要的概念混淆。目前所有通过 AI 辅助编程的方式都被统称为 “Vibe Coding”，但这其实是不准确的。我们应该区分两种截然不同的编程范式。

两种方式的本质区别

Vibe Coding（氛围编程）：

完全依赖 AI 对话生成代码
人类不审查或不深度审查 AI 生成的代码
重点关注"能不能用"，而不是"好不好"
适合快速原型、一次性项目、验证性开发

Context Coding（上下文编程）：

AI 辅助编程，但人类仍然是主导
人类会审查、优化、重构 AI 生成的代码
重点关注代码质量、可维护性、架构合理性
适合严肃的工程项目、长期维护的产品

为什么需要区分概念

区分这两个概念至关重要，因为它们代表了两种不同的开发哲学和适用场景。目前关于 Vibe Coding 的很多争论，本质上都是因为没有区分这两种方式。

Vibe Coding 代表了一种激进的 AI 优先哲学：相信 AI 的能力，接受代码质量的妥协，换取极致的开发速度。

Context Coding 则代表了一种务实的 AI 辅助哲学：利用 AI 提升效率，但保持人类对代码质量和架构的把控。

  flowchart LR
    subgraph A[Vibe Coding]
        A1[完全AI对话]
        A2[不Review代码]
        A3[只看结果]
        A4[适合一次性项目]
    end

    subgraph B[Context Coding]
        B1[AI辅助编程]
        B2[人工Review]
        B3[关注过程]
        B4[适合严肃工程]
    end

    A1 -.->|对比| B1
    A2 -.->|对比| B2
    A3 -.->|对比| B3
    A4 -.->|对比| B4

适用场景分析

选择 Vibe Coding 的场景：

快速验证产品想法
创建一次性脚本或工具
构建原型演示
学习新技术栈（通过 AI 解释和实践）
个人项目或小型实验

选择 Context Coding 的场景：

企业级应用开发
需要长期维护的项目
对安全性要求高的系统
团队协作项目
需要高性能、高可维护性的代码

AI 编程工具的进化史

要理解 Vibe Coding 的兴起，我们需要回顾 AI 编程工具的进化历程。从 GitHub Copilot 到 Cursor，再到 Claude Code，每一个里程碑都代表了 AI 编程能力的质的飞跃。

GitHub Copilot（2023）：代码补全时代

核心创新：Copilot 是第一个将 IDE 上下文共享给 LLM 的集大成者。

关键能力：

窗口上下文共享：将当前 IDE 打开的窗口代码提供给 LLM
基于上下文的代码补全：根据光标位置的代码上下文提供智能补全建议
代码提问：可以针对当前窗口的代码进行提问并获得建议

局限性：

GPT 3.5 模型幻觉较大，编程能力有限
只能索引当前打开的文件，无法检索整个项目
上下文容量有限，无法处理大型项目
无法直接编辑文件，需要手动复制粘贴

影响：Copilot 改变了程序员的编码习惯，很多人开始先写方法注释，让 Copilot 基于注释生成方法体，然后再手动修改细节。

Cursor（2024）：编程智能体时代

核心创新：从"代码补全工具"进化为"编程智能体"。

关键技术突破：

RAG（检索增强生成）：
- 将整个代码库进行语义索引
- 使用 embedding 模型将代码向量化
- 通过语义搜索检索相关代码片段
- 支持跨文件的方法调用、bug 修复、模块重构
Claude 3.5 Sonnet + Tab 自动补全：
- 专有 Tab 模型：速度快、精准度高
- Claude 3.5 Sonnet：强大的编程能力
- 直接编辑文件能力：不再需要手动复制粘贴
上下文工程能力：
- @文件/文件夹：手动指定上下文范围
- 文档索引：集成最新技术文档
- Rules 功能：提供编程规范和项目架构指导

局限性：

商业平衡导致的使用次数限制和模型降级
RAG 在复杂任务下精度不足
代码索引同步延迟可能导致检索到过时代码

Claude Code（2025）：上下文工程时代

核心创新：命令行 CLI 形态的 AI 编程工具，采用完全不同的上下文工程策略。

关键特性：

Unix 风格的 grep 检索方案：
- 使用 grep、find、git、cat 等终端命令
- 而非 RAG 语义检索方案
- 符合程序员的自然搜索习惯
全局视角：
- 首先分析项目的整体结构和技术栈
- 然后再开始具体的开发任务
- 更加符合项目的原本开发模式和编码规范
上下文可视化：
- 内置 /context 命令
- 可以直观看到不同类型工具的上下文占比
- 显示剩余的上下文容量
- 帮助用户管理 token 使用

优势：

作为大模型基座提供商，没有使用次数和模型的商业顾虑
在大型编程任务中（涉及 10+ 文件）效果远超 Cursor
grep 方案在复杂任务中提供更精准的上下文

局限性：

token 消耗量大
速度不如 RAG 方案
需要多轮对话和检索才能找全上下文

  flowchart LR
    A[传统编程] -->|2023| B[Copilot]
    B -->|代码补全| C[2024]
    C -->|智能体| D[Cursor]
    D -->|RAG检索| E[2025]
    E -->|上下文工程| F[Claude Code]
    F -->|未来| G[RAG+Grep融合]

上下文工程的两种路径

随着 Cursor 和 Claude Code 的崛起，AI 编程领域出现了两种截然不同的上下文工程路径：RAG 派和 Grep 派。

RAG 派（Cursor 代表）

工作原理：

项目打开时，将整个代码库拆分为小块内容
使用 embedding 模型将代码块向量化
存储到云向量数据库（如 Turbopuffer）
推理时对 prompt 进行嵌入，执行最近邻搜索
返回混淆后的文件路径和行范围
在客户端本地读取这些文件代码块

优点：

✅ 速度快
✅ token 消耗少
✅ 适合中小型项目和简单任务

缺点：

❌ 代码的语义相似度 ≠ 代码关联的上下文
❌ 在复杂任务下精度不足
❌ 基于文件哈希值的索引更新同步延迟
❌ 可能返回过时的代码

社区争议：

支持者认为：grep 方案召回率低，检索出大量不相关内容，效率慢
反对者认为：代码的语义相似度不等于业务上下文，RAG 的精度在复杂编程任务中表现不佳

Grep 派（Claude Code 代表）

工作原理：

基于用户的提问，使用 grep、find 等工具进行关键词搜索
一层一层地进行模糊搜索或正则搜索
直到找全业务相关的代码
然后才开始编程
或者是一轮一轮的对话、编程和检索，重复这个过程

优点：

✅ 在复杂编程任务中提供精准的上下文
✅ 更符合程序员的编程习惯
✅ 避免了代码索引同步延迟的问题
✅ 适合涉及多文件的复杂任务

缺点：

❌ 速度较慢
❌ token 消耗量大
❌ 需要多轮对话才能找全上下文

未来展望：RAG + Grep 融合

我的判断：在未来一段时间内，完整的 AI IDE 一定会提供 RAG + Grep 两种能力，在不同的情况下选择性使用。

Cursor 一定会在 grep 方案上发力，而不是全依靠 RAG
像 Claude Code、Gemini CLI 这样的 CLI 工具，可能没有必要集成 RAG，因为它们的设计目标是与 bash 环境集成、MCP 市场以及 CI/CD 自动化工作流协作，这些环境完全适应 grep 等检索方案

核心原则：在大语言模型能力没有溢出的时代，可以先不考虑速度和 token 消耗的事情，毕竟最终能否解决某个工程问题才是当前最重要的事情，也是所有 AI 编程工具的第一目标。

Vibe Coding 的行业影响

Vibe Coding 的兴起不仅仅是一个技术趋势，它正在深刻地改变整个软件行业的生态。让我们通过两个真实的案例来看看 Vibe Coding 在实际中的影响。

成功案例：Peter Levels 的飞行模拟器游戏

背景：Peter Levels 是一位知名的独立开发者，在 2025 年 3 月推出了一个完全通过 Vibe Coding 开发的实时飞行模拟器 MMO 游戏。

成果：

几乎 100% 的代码由 AI（Cursor + Grok 3）生成
从 0 到 100 万美元 ARR 仅用了 17 天
通过卖游戏内广告位赚取大量收入
产品成功验证了 Vibe Coding 的商业可行性

关键因素：

✅ Peter 本人有丰富的编程经验
✅ 有随时接管项目的能力
✅ 产品契合市场需求
✅ 快速迭代验证想法

启示：Vibe Coding 能够显著提升开发效率，特别是对于有编程经验的开发者，可以将 AI 作为强大的杠杆工具。

失败案例：Leo 的安全噩梦

背景：一位名叫 Leo 的开发者通过 Cursor 使用 Vibe Coding 方式开发了一个产品，并在 X 上分享了成功经验。

时间线：

3 月 15 日：发布产品并收获付费用户
3 月 17 日：产品遭遇攻击，API 密钥使用量达到最大值，有人绕过订阅在数据库上随意创建内容
3 月 20 日：Leo 不得不关闭产品，承认"不应该将不安全的代码部署到生产环境"

问题分析：

❌ Leo 对技术不熟悉，解决每个问题都比开发功能花费更长时间
❌ Vibe Coding 产生的安全漏洞无法被及时发现
❌ 非程序员缺乏代码审查和安全意识
❌ 生产环境的安全要求被忽视

教训：让一个非程序员通过 Vibe Coding 来编写一个他们打算维护的大型项目，就相当于在没有先解释债务概念的情况下就给孩子一张信用卡。构建新功能时犹如挥舞这张小小的塑料卡，想买什么就买什么；只有当你需要维护它时，它才会变成债务。

对职业的影响

水平一般的程序员面临淘汰

在工业机器的轰鸣下，没有人会真的在意那些古法手工制作者的声音。随着 LLM 能力的增长，水平一般的程序员正在被 AI 替代。

核心原因：

大部分程序员的工作本质上是"翻译者"：将自然语言需求转换成代码
Vibe Coding 和 Context Coding 让 AI 也能充当这个翻译者
纯粹的"码农"价值大幅降低

优秀程序员的价值放大

与此同时，优秀程序员的价值被前所未有地放大：

架构设计能力：AI 仍然不擅长复杂的系统架构和抽象设计
问题诊断能力：当 AI 陷入死胡同时，需要人类的经验来打破循环
代码审查能力：保证代码质量和安全性的最后一道防线
技术决策能力：选择合适的技术栈和工具

独立开发者和小团队成为主流

AI 编程工具降低了开发门槛，使得独立开发者和小团队能够完成过去需要大团队才能完成的工作：

效率提升：在某些特定场景下，AI 编程可能有 10 倍以上的效率提升
成本降低：减少了人力成本，小团队也能构建复杂产品
商业嗅觉变现：有商业嗅觉的人可以通过 AI 快速验证和实现想法
超级个体：一个人 + AI 工具 = 一个小团队

新的机会：

过去可能需要很多人相互协作才能完成的工作，现在利用 AI 的杠杆可以大大缩减工作时间和人员规模
未来的独立开发和小规模的团队协作一定会变得更加主流
编程水平一般的程序员，如果有不错的商业嗅觉和营销能力，创造的商业价值可能远比在社会分工中当个螺丝钉要大得多

核心实战技巧

虽然这篇文章的重点是概念和趋势，但为了帮助大家更好地实践 Vibe Coding 或 Context Coding，这里精选了 6 个最核心的实战技巧。

1. Git 是救命稻草

为什么重要： AI 改起代码来速度很快，并且可以一次修改一大片。虽然效率可以得到很大提升，但也容易带来隐藏问题。若没有及时保存历史版本，一旦出错代价巨大。

实践建议：

每当完成一个可运行阶段就提交（如模块接口完成、核心功能可手动测试通过、样式基础搭建完成等）
写清变更说明，标注：“这个提交中完成了 XXX 模块的基础功能／界面／测试"等
使用分支策略（feature/、bugfix/ 等）在本地／远程做实验，确认稳定再 merge

示例：

    # 完成用户认证模块后
git add .
git commit -m "feat: 完成用户认证模块基础功能

- 实现 JWT 登录
- 添加用户注册接口
- 完成基础的权限验证
- 可以手动测试通过"

2. 设计先行

为什么重要：虽然现在 AI 的规划能力已经很强，但是受制于上下文长度的限制，还是需要先有整体规划，再分解任务，这样才能让协作不会偏离主要轨道。

实践建议：

启动项目时，用 AI 产出一份产品设计文档，包括目标、用户故事、模块、里程碑、界面原型等
为每个模块定义验收标准（什么情况算完成／功能达标）
拆里程碑为具体任务，并设立时间表／优先级；定期检查里程碑是否达成

Prompt 示例：

    请帮我为这个项目编写一份产品设计文档，包括：
1. 项目目标和核心价值主张
2. 目标用户和使用场景
3. 核心功能模块划分
4. 功能优先级排序
5. 开发里程碑和时间表
6. 每个模块的验收标准

3. 模块化开发 + 阶段 Review

为什么重要：在每个需求做完后人工检查，可以及时纠正偏差，避免在后期需要修改整个系统，成本会越来越高。

实践建议：

对每个模块定义输入／输出／边界条件／依赖，AI 完成后由人工测试／评审
可以写自动化测试来验证接口或模块契约
每块模块完成以后，把代码放到主分支或一个共享分支进行集成，确认与已有模块的兼容性

4. 任务拆得小

为什么重要：对于大任务，AI 看似可以一次做完，效率非常高，但迭代反馈慢，很容易导致实际功能偏离预期。

实践建议：

给 AI 下任务需从微小模块开始／单页面开始
每完成一个小模块就 Review，再决定下一步；每个小模块都要能被测试／部署／验证
在任务拆解中写出清晰子任务列表，标明顺序及依赖

示例：

    不要说："帮我开发一个电商网站"

要说："请按以下步骤开发：
1. 先创建商品列表页面，显示 10 个假数据商品
2. 完成后再开发商品详情页面
3. 然后实现购物车功能
4. 最后实现支付接口
每完成一步，等我确认后再进行下一步"

5. 及时干预 + 换思路

为什么重要：在使用 AI 作为主力进行编程时，如果 AI 在某个局部实现不断失败，用同一种方式调试没有成果，甚至进入死循环，要果断制止 AI，并且换种方式进行实现。

实践建议：

及时观测 AI 的思考行为和路径，当尝试某种实现方式若干次失败就换方案
把问题拆更细，例如先做最简单版本，再逐步扩展复杂性
或许先实现 “让它能工作"的最小可行版本（MVP），再补完细节

经验法则：如果 AI 连续 3 次尝试同一方案都失败，立即要求它换一个完全不同的实现方式。

6. 管理长对话

为什么重要：如果一直在一个会话中进行 Vibe Coding，对话历史太长，除了会因为上下文而耗费 token，也可能让 AI 依赖早前内容造成混淆，进而产生 Bug。在某些情况下，Claude Code 甚至会因为上下文太大而导致 CLI 整个卡死不动。

实践建议：

在对话达到一定长度时，整理一次当前状态＋进展，总结关键信息，再开启一个新的会话
在新会话中包含必要背景但不带冗余旧内容
做好变更日志或 Review 注释，方便追踪哪些地方从旧会话延续下来

总结并重新开始 Prompt 示例：

    # 项目总结
当前项目是一个基于 React + Node.js 的任务管理系统
已完成功能：
- 用户登录/注册
- 任务列表展示
- 任务创建/编辑/删除

当前技术栈：
- 前端：React + Tailwind CSS
- 后端：Node.js + Express
- 数据库：PostgreSQL

# 新任务
请继续开发任务提醒功能，具体需求如下：
...

局限性和风险

尽管 Vibe Coding 在某些场景下表现出色，但我们也不能忽视它带来的局限性和风险。

技术债务堆积

Vibe Coding 最大的问题之一是技术债务的快速累积。由于不审查代码质量，AI 生成的代码可能存在：

重复代码
不合理的抽象层次
缺乏错误处理
性能问题

短期内这些问题不明显，但随着项目的迭代和维护，技术债务会变得越来越沉重，最终可能需要重写整个项目。

安全漏洞引入

Leo 的案例已经清楚地展示了 Vibe Coding 的安全风险。非程序员通过 Vibe Coding 开发的产品可能包含：

SQL 注入漏洞
XSS（跨站脚本攻击）漏洞
CSRF（跨站请求伪造）漏洞
不安全的 API 设计
硬编码的密钥和密码

对于没有安全意识的开发者来说，这些漏洞可能在产品上线后才被发现，那时造成的损失可能无法挽回。

代码质量下降

AI 生成的代码虽然能工作，但往往不够优雅和健壮：

过度抽象：AI 喜欢创建过多的抽象层，增加理解难度
错误理解意图：AI 可能会实现一些你不需要的功能，或者遗漏关键逻辑
缺乏一致性：不同时间生成的代码风格可能不一致
难以调试：当你需要深入调试问题时，不熟悉的代码会让调试变得异常困难

维护成本高昂

最讽刺的是，Vibe Coding 快速开发的功能，在后期维护时可能需要花费数倍的时间：

你不熟悉代码的实现细节
AI 生成的代码可能没有清晰的注释和文档
每次修改都可能引入新的问题
最终可能需要从头重写，而不是维护

信用卡债务比喻

我看过最形象的一个解释是：

让一个非程序员通过 Vibe Coding 来编写一个他们打算维护的大型项目，就相当于在没有先解释债务概念的情况下就给孩子一张信用卡。

在构建新功能的时候，就犹如挥舞这张小小的塑料卡，想买什么就买什么，想要编写什么新功能都能很快实现。

只有当你需要维护它时，它才会变成债务。

如果你尝试通过 Vibe Coding 去修复另一个 Vibe Coding 导致的问题，这就像用另一张信用卡偿还信用卡债务一样。

  flowchart TD
    A[需求描述] --> B{AI分析}
    B --> C[生成代码]
    C --> D{测试结果}
    D -->|成功| E[接受All]
    D -->|失败| F[复制错误信息]
    F --> B
    E --> G[下一个需求]
    G --> A

未来展望

站在 2026 年初的视角，让我们来展望一下 Vibe Coding 和 AI 编程的未来。

LLM 能力持续进化

从 GPT-3 到 Claude 3.5 Sonnet，再到即将到来的 GPT-5 和 Claude 4，大模型的编程能力正在以指数级速度提升：

上下文容量：从 4K 到 200K+ token，未来可能达到无限上下文
代码理解：更深入的代码语义理解和推理能力
抽象设计：目前 AI 最弱的能力，未来可能显著提升
多模态：能够理解设计稿、UI 截图，并直接生成对应代码

程序员角色的转变

在 AI 时代，程序员的角色正在从”代码翻译者“转变为”创意输出者"：

传统程序员：

需求 → 代码（手工编写每一行）
价值 = 编码速度和准确性

新时代程序员：

需求 → 架构设计 → AI 辅助实现 → 代码审查和优化
价值 = 问题抽象能力、系统设计能力、创意思维

核心能力重构：

从语法到语义：不再需要记忆 API 和语法，重点在于理解问题和设计解决方案
从实现到架构：从如何实现，转向设计什么样的架构和模块
从单一技能到综合能力：编程 + 产品思维 + 商业嗅觉 + 用户理解

持续学习是唯一护城河

在这个快速变化的时代，持续学习能力是程序员唯一的护城河：

学习新工具：Cursor、Claude Code、新的 AI 编程工具
学习新范式：Vibe Coding、Context Coding、Prompt Engineering
学习新领域：AI 时代降低了跨领域开发的门槛，程序员可以更容易地进入新领域
学习软技能：沟通、产品思维、商业理解、用户同理心

职业和岗位会消失，但需求和机会永远存在

虽然一些传统的编程岗位可能会消失，但这并不意味着程序员这个职业会消失：

历史告诉我们：计算机出现之前，售票员、电话接线员是庞大的群体。现在这些岗位几乎消失，但新的岗位不断涌现。
需求永远存在：人类社会对软件和数字化解决方案的需求只会增长不会减少
机会在转移：机会从传统的互联网大厂，转向 AI 原生应用、垂直领域解决方案、独立开发等新兴领域

在工业机器的轰鸣下，没有人会真的在意那些古法手工制作者的声音。但那些愿意拥抱变化、持续学习、掌握新工具的人，总能在新时代找到自己的位置。

总结

Vibe Coding 的出现标志着编程范式的根本性变革。从 Andrej Karpathy 的一条推文开始，它从一个模糊的概念发展成为影响整个行业的技术趋势。

核心要点回顾

Vibe Coding ≠ AI 编程的全部：我们需要区分 Vibe Coding（完全 AI 驱动）和 Context Coding（AI 辅助编程），两种方式有各自的适用场景。
工具的进化：从 GitHub Copilot 到 Cursor，再到 Claude Code，AI 编程工具的进化本质上是上下文工程的不断优化。
双刃剑效应：Vibe Coding 能够显著提升开发效率，但也带来了技术债务、安全风险、代码质量下降等问题。
职业影响：水平一般的程序员面临淘汰，优秀程序员的价值被放大，独立开发者和小团队成为主流。
未来已来：2025 年是 AI 编程元年，编程正在从"手艺"转变为"指挥艺术”。

给程序员的建议

不要做工具的信徒：好的工程师总是可以选择合适的工具来解决问题，而不是某个工具的信徒。Cursor 很好，但 Claude Code 也有它的优势；Vibe Coding 适合原型，但严肃工程需要 Context Coding。
拥抱变化：AI 编程工具不是你的敌人，而是你的杠杆。学会使用它们，让它们放大你的能力，而不是抗拒它们。
保持核心竞争力：虽然语法和 API 不再重要，但系统设计能力、问题抽象能力、架构思维变得越来越重要。
持续学习：这是唯一的护城河。学习新工具、新范式、新领域，保持好奇心和开放心态。
找到自己的道路：在这个新时代，没有人能告诉你正确的道路是什么。有人选择成为全栈独立开发者，有人选择专精于某个领域成为专家，有人选择转型做产品经理。找到你喜欢的道路，并坚定地走下去。

希望我们都能在新的时代找到自己更喜欢的道路。

参考资源：

基于 claude code 的实战

当需要从头开启一个项目的时候可以使用下面的prompt提供给cluade code.

    Act as an elite Senior Software Architect and Product Manager. I am planning to build a new software project from scratch.

Here is the high-level idea:
"""
[INSERT YOUR PROJECT IDEA HERE]
"""

Your goal is to design the absolute best architecture and plan for this specific product, **ignoring my personal background or current skill set.** Assume I have the capacity to learn or hire for any technology you recommend.

Please guide me through the setup process strictly following these steps:

### Step 1: Deep Dive Discovery (The most important step)
Do not assume anything. Before proposing any solutions, you must fully understand the problem space. Ask me a comprehensive set of clarifying questions covering the following domains:
1.  **Core Product Logic:** (User flows, edge cases, role permissions, "must-have" vs "nice-to-have" features)
2.  **Data & Complexity:** (Data volume, relationship complexity, read/write ratio, consistency requirements)
3.  **Non-Functional Requirements:** (Expected traffic/scale, latency limits, security/compliance needs, offline capabilities)
4.  **Integration & Environment:** (Third-party APIs, target platforms, hosting preferences)
5.  **Business Constraints:** (Timeline urgency, budget for infrastructure, long-term maintenance goals)

*Group your questions logically and wait for my answers.*

### Step 2: Objective Tech Stack Analysis
Once I answer the questions in Step 1, analyze the requirements objectively.
1.  Propose **3 distinct technology stack options**.
    * *Option A (The "MVP/Velocity" Stack):* Best for getting to market fast.
    * *Option B (The "Scale/Performance" Stack):* Best for high concurrency and robustness.
    * *Option C (The "Specialized" Stack):* A stack specifically tailored to the unique nature of this product (e.g., specific AI libs, real-time frameworks).
2.  For each option, explain **WHY** it is objectively better for the specific requirements we discussed, listing clear Pros & Cons.
3.  **Do not** ask about my preferred languages. Recommend what is best for the *product*.

### Step 3: Architecture & Implementation Plan
After I select a stack from Step 2:
1.  Generate a detailed `SPEC.md` including directory structure.
2.  Create a step-by-step implementation plan (Phase 1, Phase 2, etc.).

Let's begin with **Step 1**. Please ask your comprehensive list of clarifying questions.

全自动执行prompt

    Great. We have the Tech Stack and the SPEC.md. Now, I want you to enter **"Autonomous Execution Mode"**.

Your goal is to build, test, and ship the entire project with minimal human intervention. You must follow this strict **Sequential Workflow**:

### Phase 1: Planning & Setup
1.  Initialize the git repository.
2.  Create a file named `MASTER_PLAN.md`.
    * List **every single file** that needs to be created.
    * Group them into logical **Modules**.
    * Mark every item as `[ ]` (Pending).
3.  Set up the base project structure and install necessary dependencies (package.json, go.mod, etc.).

### Phase 2: The Coding Loop (Repeat for each module)
**Do not stop to ask me questions. Read `MASTER_PLAN.md` to see what is next.**
For each module in the plan:
1.  **Implement:** Write the source code for the module.
2.  **Test:** Immediately write a Unit Test for this specific module.
3.  **Verify:** Run the test.
    * *If Pass:* Mark the item as `[x]` in `MASTER_PLAN.md`.
    * *If Fail:* **Self-Correct.** Read the error, fix the code, and re-run the test. Do not ask me unless you fail 3 times in a row.
4.  **Commit:** Git commit with a descriptive message (e.g., "feat: implement auth module").

### Phase 3: Finalization
1.  **Integration Test:** Once all modules are `[x]`, run the full test suite to ensure no regressions.
2.  **Audit:** Read `SPEC.md` again. Verify line-by-line that all requirements are met.
3.  **Documentation:** Generate a `README.md` containing:
    * Project setup instructions.
    * How to run tests.
    * Architecture overview.
4.  **Delivery:**
    * Add the remote repository URL: `[INSERT_YOUR_GIT_REPO_URL_HERE]`
    * Push the code to the `main` branch.

**Constraint:**
* **Do not ask for permission for every file creation.** Assume you have authorization to proceed as long as you are following the `MASTER_PLAN.md`.
* Start Phase 1 immediately.

当需要根据当前存在的仓库做修改的时候, 需要先使用"/init"让cluade code 先理解明生成关于该项目的文档. 之后再使用下面的prompt

    Act as an expert Senior Code Maintainer and Refactoring Specialist. I have an existing codebase here, and I need you to perform a specific task.

**The Task:**
"""
[INSERT YOUR FEATURE REQUEST, BUG FIX, OR REFACTOR GOAL HERE]
"""

You must operate in **Autonomous Execution Mode**. To ensure safety, style consistency, and stability, strictly follow this **4-Phase Protocol**:

### Phase 1: Diagnostic & Context Mapping (Read-Only)
1.  **Environment Safety Check:** 
    - Run `git status` to ensure the working directory is clean. If it is not dirty, proceed. If dirty, ask the user for confirmation or stash changes.
2.  **Explore & Locate:** 
    - Run commands to understand the project structure (e.g., `find . -type f -name "*.json" | head -20`, `ls -R`).
    - Locate files relevant to the Task.
3.  **Style & Config Analysis:** 
    - **Crucial:** Look for explicit configuration files defining style (e.g., `.editorconfig`, `.eslintrc`, `.prettierrc`, `pyproject.toml`, `rustfmt.toml`).
    - If found, read these configs. If not, infer style from existing code (indentation, quotes, naming patterns).
    - You must strictly adhere to these rules.
4.  **Test Baseline:** 
    - Determine the test command (check `package.json`, `Makefile`, or `pytest.ini`).
    - Run the **existing test suite** to establish a baseline. Confirm they pass before touching anything.

### Phase 2: Surgical Planning & Risk Assessment
1.  Create a file named `TASK_PLAN.md`.
2.  **Outline Changes:** List specific files to edit and functions to modify.
3.  **Impact Analysis:** List dependent files that might break.
4.  **Dependency Check:** Identify if new libraries are needed. If yes, list them. (Note: Prefer existing libs. Do not install without explicit plan).
5.  **Rollback Strategy:** Define the Git command to undo changes if execution fails catastrophically (e.g., `git checkout -- .`).
6.  **Success Criteria:** Defined as "New test X passes", "Existing tests pass", AND "Linting passes".

### Phase 3: The Execution Loop (Atomic & Iterative)
**Read `TASK_PLAN.md` and execute step-by-step.**
1.  **Atomic Edit:** 
    - Modify **one file at a time**. 
    - Constraint: Do not reformat unrelated code.
    - Immediately run syntax/linting on that file (e.g., `eslint file.js`, `python -m py_compile file.py`) before moving to the next.
2.  **Test Strategy:**
    - **If Bug Fix:** Write a reproduction test *first* that fails (Red), then apply fix (Green).
    - **If Feature:** Write the test for the new behavior immediately after the code change.
3.  **Regression Test:** Run the relevant subset of tests after every significant change.
4.  **Self-Correction:** 
    - If tests fail: Analyze the log. If logic is wrong, do not patch blindly. Use the rollback strategy defined in Phase 2 if the state is irrecoverable, then re-plan.

### Phase 4: Final Verification & Delivery
1.  **Quality Gate:** Run the **Full Test Suite**.
2.  **Style Gate:** Run the project's linter/formatter (e.g., `npm run lint`, `cargo fmt --check`) to ensure zero style violations.
3.  **Cleanup:** If all green, delete `TASK_PLAN.md`.
4.  **Commit:** Generate a Commit Message following the repo's convention (e.g., Conventional Commits).
5.  **Report:** Summarize changes made, tests passed, and any potential remaining technical debt.

**Hard Constraints:**
* **Safety First:** If `git status` shows untracked binaries or messy state, pause and ask.
* **No Rewrites:** Only touch what is necessary. Do not refactor "just because" unless it's the specific task.
* **Stack Consistency:** Do not introduce new frameworks or build tools (e.g., don't add webpack if using vite).
* **Auto-Fix:** If a linter error occurs, fix the code style immediately, do not ignore it.

Start Phase 1 immediately.