1.1 开篇词 | 为什么 Vibe Coding 是 2026 年最值得学的开发范式？第1章第1节：为什么你学了很多

开篇词 | 为什么 Vibe Coding 是 2026 年最值得学的开发范式？

你好，我是这门课的主讲人。接下来一段时间，我会像跟你喝咖啡聊天一样，把一件事讲透：怎样用 AI 工具（Cursor、Copilot 等）把完整产品从 0 做到上线，而不是永远停在「学了好多课、收藏了好多仓库、却从未 ship 过」的状态。

2025 年，Andrej Karpathy 提出了 Vibe Coding 这个说法。它不是又一个营销热词，而是一句挺扎心的总结：很多人写代码的方式，正在从「逐行推敲」变成「用自然语言描述意图，让模型去补全实现」，而开发者本人更像是在调频、验收、纠偏。你可以不喜欢这个词的「松弛感」，但你很难否认工作方式已经在变。

Stack Overflow 2025 年的开发者调查显示，约 84% 的开发者已在工作中使用 AI 工具。这个数字的意义不在于「AI 赢了」，而在于：协作界面已经换了。还在用 2018 年的「纯手写 + 栈溢出复制粘贴」路径的人，不是不能做产品，而是同样时间里，你的竞争对手多了一条杠杆。

你可能正在经历的两种痛

第一种痛很经典：技术学了不少，产品始终做不出来。你看得懂教程，甚至能跟着敲一遍，但一到「我想做一个自己的东西」，需求就发散、目录就乱、依赖就报错、部署就卡住。最后项目死在 localhost，简历上多不出一条可展示的链接。

第二种痛更隐蔽：AI 时而惊艳，时而让人想砸键盘。同一段描述，昨天生成得漂亮，今天就引入诡异依赖；模型信誓旦旦说「已修复」，你跑起来却是红灯一片。你会怀疑是不是自己不会提问——很多时候确实是，但也不全是。Vibe Coding 不是「把责任外包给 AI」，恰恰相反，它要求你建立新的质量边界：什么时候信任，什么时候验证，什么时候必须自己读懂关键路径。

参考我们整理的「核心概念」与「开课前说明」（见仓库 reference/articles/01-core-concepts.md、reference/basic/00-preface.md），有一条底线反复出现：快，不等于随便。AI 压低了实现门槛，也同步放大了规格不清、验证不足、纪律松动的代价。这门课从头到尾都会把「速度」和「纪律」绑在一起谈。

这门课到底教什么：一张地图

这门课不是语法大全，也不是「100 个 Prompt 模板背下来就能赢」。它是一条产品化路线：你会跟着主线项目 VibeNote 智能笔记，从最小可用版本一路演进到更接近真实上线的全栈形态。

技术栈我们选当下独立开发者最常用、也最容易和 AI 协同的组合：

Next.js + React + TypeScript：前后端同构、生态成熟，模型训练语料里出现频率高，「让 AI 写对」的概率更大。
Tailwind CSS：用约束换速度，特别适合你用自然语言描述「想要专业一点的排版」。
Drizzle ORM + PostgreSQL：类型友好的数据库层，后面做多用户、同步、搜索时不会推倒重来。
Vercel 部署：把「上线」从运维题变成流程题，让你尽早习惯可分享的 URL 才是进度条。

下面这张图，帮你建立整门课的「系统观感」：左边是你的人机协作方式，右边是 VibeNote 随模块成长的结构。

flowchart LR
  subgraph Human["你（人类开发者）"]
    I[意图与边界]
    S[规格与验收]
    R[审查与发布]
  end

  subgraph AI["AI 协作层"]
    P[提示与上下文]
    C[代码生成与重构]
    T[排错与解释]
  end

  subgraph Product["VibeNote 产品演进"]
    V1[V1 本地笔记]
    V2[V2 账号与云同步]
    V3[V3 AI 辅助写作]
    V4[V4 生产级质量]
  end

  I --> P
  S --> C
  R --> T
  P --> V1
  C --> V2
  T --> V3
  R --> V4

再看一张分层架构视角：你会反复听到「哪一层允许 AI 自由发挥，哪一层必须你亲自盯」。

flowchart TB
  UI[展示层 Next.js App Router]
  API[应用层 Server Actions / Route Handlers]
  DATA[数据层 Drizzle + PostgreSQL]
  AI2[智能层 后续接入 LLM API]

  UI --> API
  API --> DATA
  API --> AI2

VibeNote：为什么用「笔记」当主线

笔记类产品足够小，却能覆盖全栈大多数硬技能：列表与详情、表单与校验、权限与数据一致性、搜索与索引、富文本或 Markdown、异步任务、监控与日志、SEO 与分享。更关键的是，它足够个人化：你能立刻用自己的真实需求驱动迭代，而不是照抄一个与你无关的电商 Demo。

在后续模块里，VibeNote 会按版本递进：

V1.0：单页应用思路下的最小闭环——增删改查 + 本地持久化，先把「组件边界」和「状态管理」练熟。
再往后：登录、数据库、AI 补全、协作……每一步都保留可运行、可部署状态，避免「 big bang 集成」。

谁适合学：热情比背景更重要

官方一点的 prerequisites 可以写一长串，但我更愿意说实话：你需要的是愿意动手、愿意复盘、愿意在报错时把问题描述清楚。零基础读者也能跟，但你要接受一件事——你会在终端、Git、依赖版本这些「工程地板」上花点时间。这不是刁钻，而是现实世界的摩擦系数。

参考 reference/basic/00-preface.md 的立场：基础篇不是在训练你「像程序员那样背知识」，而是在训练你「像做东西的人那样把作品做出来」。什么时候你真的需要某个概念，我们就在那个时刻把它讲到够你继续推进的程度。

你会养成的三种习惯

第一，把规格当代码的一部分。模糊需求在 AI 时代不会被「聪明的模型」自动补齐，只会被放大成返工。你会学会写短而硬的验收标准：页面状态、边界条件、错误提示、性能底线。

第二，把运行当真理。能跑、能部署、能在手机里打开，比「看起来对了」重要一个数量级。你会习惯最小验证循环：改一点 → 跑一遍 → 记下来。

第三，把上下文当预算。上下文不是越多越好，它是注意力与成本的乘积。你会学会用规则文件、目录结构、提交粒度，把 AI 引导到正确的局部，而不是让它每次从头猜你的项目。

本讲小结

Karpathy 的 Vibe Coding 描述的是一种协作界面迁移：从手写实现到意图驱动，但你仍然对系统负责。
高比例开发者已使用 AI 工具；不学这种协作方式的机会成本正在变高。
课程用 VibeNote 串起 Next.js 全栈与工程化实践，目标是可上线的作品，不是「教程完成度」。
参考材料强调：Agent、Agentic Engineering、工厂模型与规范驱动，不是空话，而是后面每一讲的隐形评分标准。

思考题

你过去「做不出来」的主要断点在哪里：需求、实现、调试，还是部署？如果只能先修一个，你会选哪个，为什么？
你认为自己的项目里，哪些模块适合「大胆交给 AI」，哪些必须「人类强管控」？各写三条并写出理由。
如果 VibeNote 只做「一个功能」就必须上线，你会选哪一个功能作为 V1，验收标准是什么？

下一讲预告

模块一第 01 讲：Vibe Coding 全景。我们会把概念摊开来：Karpathy 的定义、Agentic Engineering 的纪律、开发者角色如何从实现者迁移为编排者与审查者，以及「工厂模型」到底改变了什么协作关系。你会带走一张角色迁移图，用来对照自己的日常。

延伸阅读（仓库内）：reference/articles/01-core-concepts.md、reference/basic/00-preface.md。

加餐：把「84%」放在正确的坐标系里

调查数据从不是用来制造焦虑的，而是用来校准策略的。当绝大多数开发者已经在工作流里接入 AI，你再坚持「完全不用」，并不是道德更高尚，而是协作接口与行业默认路径发生了偏移。这就像早年从纸质制图迁到 CAD：工具不会自动让你成为建筑师，但会改变团队的节奏与分工。

你要小心的，是把统计当成借口。84% 并不意味着每个人都用得好，更不意味着「用了就自动交付」。现实往往是两极：有人把 AI 当加速器，也有人把 AI 当抽奖机。这门课站在前者这一边——我们承认随机性，但用流程压缩随机性。

Karpathy 的「Vibe」到底在说什么（避免误读）

很多人第一次听到 Vibe Coding，会把它理解成「不认真」「不审查」「不负责」。这恰恰是误读。更接近原意的描述是：你把注意力从字符级别的编辑，转移到意图级别的编排；你仍然需要知道系统在做什么，只是「亲手敲下每一行」不再是唯一证明你理解的方式。

这也解释了一个常见现象：有经验的人用 AI 更顺手，不是因为他们更会「忽悠模型」，而是因为他们脑子里有清晰的模块边界、错误模型、验收路径。AI 像一台极快的车，老司机与新手差的不是油门，而是路况预判。

「能做出作品」的学习路径：四周节奏建议

你完全可以按自己的节奏学，但如果你需要一条可参考的推进方式，我建议把「可见进度」写进日历：

第 1 周：环境与第一次上线。目标不是炫技，而是你在手机里打开过自己的页面，URL 不是 localhost。
第 2 周：组件化与状态。把 UI 拆干净，把数据流画清楚；此时别贪多账号体系。
第 3 周：数据库与一致性。让数据真的「落在库里」，理解迁移、约束、最基本的查询性能意识。
第 4 周：质量与发布纪律。日志、错误边界、最基本的监控与回滚思路，让你敢改代码。

这条路径与「先啃完一大本书」相反：它是以可运行里程碑为单位的。你会发现自己的信心来自「我又部署了一次」，而不是「我又看完了一章」。

你可能会担心的五个问题（提前回答）

我是不是要先数学很好、英语很好？ 不需要。你需要的是能读错误信息、能搜索、能把问题描述清楚。英语好会更快读文档，但不是门槛。

我会不会被 AI 带偏，写出自己不懂的东西？ 会，如果你跳过审查。所以我们把 Code Review 的思维前置：每一讲都有「你必须亲自点过」的检查清单。

Windows 能不能学？ 能。终端差异我们会标注，但主线命令一致。

要不要买很贵的会员？ 不急着买全家桶。先确定你每周真的在 ship；工具预算应该服务于节奏，而不是反过来。

我会不会学完就过时？ 工具会变，但规格、验证、架构、数据、发布这些轴不会消失。我们教的是「换引擎也能开车」的东西。

课程结构：模块一览（你可以当目录用）

flowchart LR
  M1[模块一 认知与起步] --> M2[模块二 前端与交互]
  M2 --> M3[模块三 数据与后端]
  M3 --> M4[模块四 AI 能力接入]
  M4 --> M5[模块五 质量与上线]
  M5 --> M6[模块六 增长与迭代]

模块一会把心智模型与工具链地基打牢；从模块二开始，你会明显感觉到 VibeNote 的每一次升级都在逼迫你把「协作方式」升级一次——这正是刻意练习的设计。

写在最后：我对你唯一的「强硬要求」

请你至少上线一次。不是「几乎上线」，不是「本地完美」，而是互联网上有一个你能发给朋友的链接。很多能力只有在这一步之后才会被激活：你会开始在意加载速度、移动端排版、错误提示像不像人话、以及「我是否愿意每天用我自己的产品」。

如果你愿意，我们就从下一讲开始，把地图换成路线。

术语小抄（本专栏统一用法）

术语	在本专栏中的含义
Vibe Coding	以意图协作为主的开发方式：人类负责目标、边界与验收，AI 承担大量实现与重构劳动
Agentic Engineering	强调计划、审查、测试与责任回到人类主线的 AI 工程方式
规格 / Spec	可验收的描述：不只有「要什么」，还包含「不要什么」与「怎样算完成」
Ship	把软件交付到可访问环境，让他人可用或可验证
上下文	模型在生成时「能看见的材料」：文件、规则、聊天记录、错误输出等

学习契约（建议你复制到笔记顶部）

我每天至少推进一个可验证的小步：运行通过、或部署成功、或修复一个具体报错。
我每次向 AI 求助都附带：目标、已做尝试、报错原文、相关文件路径。
我每周复盘一次：本周 ship 了什么、下周唯一最重要的里程碑是什么。

把契约写下来，是在保护你的注意力。AI 时代最贵的不是 token，而是你被无效尝试切碎的一周又一周。

和参考材料的对应关系（方便你自查）

reference/articles/01-core-concepts.md：Agent、Agentic Engineering、工厂模型、规范驱动——这些不是「课外阅读」，而是后面判断题与架构题的底层框架。
reference/basic/00-preface.md：学习边界与「卡住怎么办」的心态建设。若你焦虑于自己零基础，先读它，再回到课程主线。

当你把这两份材料与本讲放在一起，你会看到同一条结论反复出现：快与随便之间，没有必然联系；你真正要训练的是纪律。

深度阅读：为什么「软件工厂」不是冷冰冰的比喻

Addy Osmani 在讨论「Coding Agents 与软件工程」时，用一个很锋利的视角：当智能体承担更多实现工作，开发者的高杠杆价值会从「写代码的人」转向「设计生产系统的人」。这句话听起来像管理学术语，但你把它翻译到个人开发者场景，其实非常接地气：

你不再以「我今天敲了多少行」为骄傲，而以「我今天把系统推进到更可靠的状态」为骄傲。可靠的状态包括：更清楚的目录结构、更可重复的启动方式、更明确的接口边界、更可追踪的发布记录。AI 让「写」变快，但如果你不建设系统，你会更快地把混乱写进仓库。

这也是为什么本专栏坚持主线项目制。项目是最好的约束器：它会逼你处理状态、边界、错误与回归。你会发现很多「概念」不需要背，它们会在你第二次踩坑时自然长进你的直觉里。

VibeNote 的非目标（避免你学着学着跑偏）

为了让你学得更狠、更集中，我们先声明 VibeNote 一开始不做什么：

不做「大而全的 Notion 克隆」。那是另一个产品课题，会稀释你在工程主线上的练习密度。
不在前几讲就堆满微服务。我们要先拿到可维护的单体全栈，再谈拆分。
不鼓吹「零代码理解」。你会读生成的代码，而且会越来越快地读，因为那是你的质量防线。

非目标不是贬低那些方向，而是保护你的注意力预算。独立开发者最稀缺的从来不是想法，而是连续四周不被打断的深度推进。

三个「反直觉」建议（来自一线踩坑）

第一，越早接入 TypeScript 越省钱。你可能会觉得 TS 啰嗦，但在 AI 协作里，类型错误常常比运行时错误便宜一个数量级：它把问题拦在编辑器里，而不是拦在用户脸上。

第二，越小的提交越适合 AI。大提交会让模型与你都失忆。把变更切成可叙述的小步，你会神奇地发现：AI 的补丁更准，你的 review 也更轻松。

第三，越早上线越不怕改。很多人把上线当终点，于是前期无限拖延。反过来，把上线当「开始收集现实的起点」，你会更早建立对性能、路径、文案的体感。

你学完模块一后，应该能自信地说出这些话

我能解释 Vibe Coding 与 Agentic Engineering 的差别，以及我为什么在严肃项目里更偏向后者。
我能根据自己的工作方式选择更合适的 AI 工具组合，而不是跟风。
我能在新机器上把 Node/Git/包管理/编辑器扩展配置到可复用状态。
我能独立把一个静态或简单动态页面部署到 Vercel，并把链接发给别人。
我能把 VibeNote V1 跑起来：列表、编辑、删除、刷新后仍在（本地持久化）。

这几句话不是为了「口嗨」，而是你拿去对照自己的真实 checklist。模块一结束如果你说不出来，别急着进模块二，回去补一次——后面所有内容都会默认你已经越过这些地板。

最后的提醒：别把学习当成「看完」

本专栏的默认节奏是：读完 → 照着做 → 记录差异 → 再问 AI。如果你只读不做，你会获得一种熟悉的幻觉：我懂了。动手之后你才会遇到真正的老师：报错信息、边界情况、以及你写不出来的验收标准。

如果你准备好了，下一讲我们进入范式革命的正文：从写代码到指挥系统做产品。你会第一次把「角色迁移」画成自己的版本——那张图以后可以贴在你显示器旁边。

附录：十分钟启动清单（现在就可以做）

你不需要等「整门课学完」才开始变强。今天你就可以用下面这份清单自检：

你是否能新建一个不含中文与空格的项目目录？（这是为了避免工具链里那些「只在中文路径复现」的玄学问题。）
你是否能解释：pnpm install 与 pnpm dev 分别解决什么问题？
你是否能说出：浏览器地址栏里的 localhost 与 127.0.0.1 是什么关系？
你是否能描述一次「最小求助」：你要什么、你试了什么、你现在卡在哪一句报错？

这四项看起来朴素，但它们决定你能不能稳定地「每天推进一点点」。本专栏后面所有炫酷内容，都建立在这层地板之上。别跳过地板去追天花板——我见过太多聪明人在天花板上学理论，在地板上摔跟头。

写给「已经很会写代码」的读者

如果你本来就会 React/Next.js，你可能会觉得模块一偏基础。建议你换一个收获目标：用更产品化的方式使用 AI。你会练习的是：如何把任务拆到模型稳定完成的粒度、如何写规范让生成结果可审查、如何用更小的 PR 节奏协作。你会很快发现，VibeNote 对你来说不是「学语法」，而是「练交付」。

写给「完全新手」的读者

你可能会害怕终端与报错。请记住：害怕是正常的，不正常的是把害怕当成停止的理由。本专栏会重复教你一套动作：复制完整报错、定位文件与行号、让 AI 解释、再用手动最小复现验证。你每成功一次，你的神经回路就会升级一次。到最后，你不是不怕了，而是你知道怕的时候该怎么走下一步。

这两类读者看似起点不同，但在 AI 时代会收敛到同一个高价值点：能把问题定义清楚，并把系统交付到可验证状态。这也是我希望你在结课时带走的「硬通货」。把每一讲当作一次小型交付，而不是一次被动阅读，你会进步得更快、更稳、也更像真正的 builder。我们下一讲见。

第1章第1节：为什么你学了很多技术，产品却始终做不出来？

章节主题：认知重构与学习路径
关键词：AI协作、产品交付、工程化、可持续迭代

一、开场：为什么这件事值得你现在就做

很多读者问过同一个问题：为什么你学了很多技术，产品却始终做不出来？。

在大量项目复盘中可以看到，真正拉开差距的不是“会不会写某个框架语法”，而是能否把业务问题拆成稳定可执行的步骤。你会发现很多团队并不缺工具，缺的是“方法的顺序”：先明确价值，再定义边界，再组织实现，最后用数据校准方向。如果顺序错了，团队会被动陷入不断返工；顺序对了，即便工具升级很快，产出也能保持稳定。本节采用“理论 + 实操 + 复盘”结构，帮助你既看懂原理，也能直接落地。

常见误区包括：

以为功能越多价值越大，结果产品复杂度上升、核心价值反而被稀释；
以为AI会自动理解业务上下文，忽略了输入质量和约束条件；
以为上线就是终点，没有建立指标和反馈闭环，导致无法持续改进。正确做法是建立一条可重复路径：问题定义 -> 方案设计 -> 最小实现 -> 验证数据 -> 迭代优化。当你把这条路径走顺之后，每新增一个项目，速度都会明显提高。

二、核心框架：先搭脑图，再做落地

flowchart TD
    A[识别真实问题] --> B[定义目标与边界]
    B --> C[拆解最小可交付版本]
    C --> D[实现与验证]
    D --> E[上线与监控]
    E --> F[反馈驱动迭代]

上面的流程并不复杂，但关键在执行纪律：每一步都要有明确输出物，避免“感觉差不多”。

三、实操步骤：可直接照做

步骤1：定义一个单点痛点，不要同时解决多个方向。
步骤2：写出最小需求清单，列出本期不做项。
步骤3：让AI基于文档先输出方案，再输出实现。
步骤4：优先打通一条完整链路，再补细节。
步骤5：上线后马上看数据，按证据决定下一步。

四、对照表：优秀实践 vs 常见踩坑

维度	常见做法	推荐做法	预期收益
需求定义	先做功能再看反馈	先定义用户与场景	返工率下降
AI协作	模糊指令反复试	结构化指令+验收标准	产出稳定
工程质量	只在本地点点看	最小自动化测试	回归问题减少
发布上线	手工部署无记录	CI/CD+日志排障	可追溯可回滚
迭代策略	凭感觉加需求	指标+反馈双驱动	增长更可控

五、代码示例：最小可运行范例

下面示例演示“任务拆解 -> 风险打分 -> 生成周计划”的可运行脚本。

# filename: plan_generator.py
# run: python plan_generator.py

from datetime import date

items = [
    {"task": "梳理本周核心需求", "owner": "产品", "deadline": "2026-03-06", "risk": 2},
    {"task": "完成接口参数校验", "owner": "后端", "deadline": "2026-03-07", "risk": 3},
    {"task": "补齐空状态与错误态", "owner": "前端", "deadline": "2026-03-08", "risk": 1},
]

def risk_level(score: int) -> str:
    if score >= 3:
        return "高"
    if score == 2:
        return "中"
    return "低"

print(f"今日日期: {date.today()}\n")
print("本周执行计划")
print("=" * 36)
for i, item in enumerate(items, start=1):
    print(f"{i}. {item['task']}")
    print(f"   负责人: {item['owner']}")
    print(f"   截止时间: {item['deadline']}")
    print(f"   风险等级: {risk_level(item['risk'])}")
    print("-" * 36)

print("建议：先处理高风险任务，并在每日站会确认阻塞项。")

六、项目化思考：把知识点转成业务结果

围绕“为什么你学了很多技术，产品却始终做不出来？”这个主题，你可以把学习任务映射到真实业务：先拿一个最小场景做验证，再将能力迁移到更复杂场景。例如先完成单人流程，再扩展到多人协作；先完成单数据源，再扩展到多数据源；先手工触发，再自动化触发。这类渐进式策略能有效降低失败成本，同时快速积累可复用资产。

七、复盘清单：学完本节你应当做到

能说清本节核心概念，不依赖模糊描述。
能写出最小可执行方案，并明确验收标准。
能运行示例代码并改造成自己的版本。
能列出至少3个真实场景中的风险点与应对策略。
能把本节能力迁移到你自己的项目中。

八、延伸阅读与练习题

请将本节流程改造成你当前项目的执行看板。
请把代码示例扩展为可读取JSON文件的版本。
请设计一个最小指标面板，用于衡量本节方法是否有效。在实践中，最重要的是持续复盘：每次迭代都记录假设、动作、结果和下一步计划。当你把复盘变成习惯，项目质量会出现长期复利。

1.1 开篇词 | 为什么 Vibe Coding 是 2026 年最值得学的开发范式？