1.2 Vibe Coding 全景——从「写代码」到「指挥 AI 做产品」的范式革命

少林码僧
16 阅读22分钟

模块一：认知重构与快速起步 | 第01讲：Vibe Coding 全景——从「写代码」到「指挥 AI 做产品」的范式革命

你好，欢迎回到专栏。这一讲我们要做一件很「底层」的事：把话说清楚。因为后面所有工具技巧、提示词模板、目录结构建议，都挂在这张「认知地图」上。地图错了，你会越学越忙；地图对了，你会越用越省。

我们从 Karpathy 提出的 Vibe Coding 说起。这个词在社交媒体里很容易被 caricature 成「闭着眼睛让 AI 写」，但如果我们回到讨论软件生产方式本身，它其实在描述一种更硬的现实：实现层正在被自动化强烈挤压，而决策层、规格层、验证层的相对价值在上升。你可以不喜欢「vibe」这个轻松的词根，但你很难否认工作流正在迁移。

本讲大量对齐仓库内整理的核心概念文章（reference/articles/01-core-concepts.md），尤其是 Addy Osmani 对 Agent、Agentic Engineering、工厂模型与质量底线的论述。下面我会把这些材料「翻译成你能用的行动指南」。

1. 先把定义钉死：Vibe Coding 不是什么、是什么

不是什么：

  • 不是「我不会也能做」的魔法。模型可以补全实现，但无法替你承担线上后果。
  • 不是「越放手越快」。无约束的放手通常换来短期爽感与长期债务。
  • 不是「自然语言取代编程语言」。自然语言是意图接口，编程语言仍是系统精确定义与协作的载体。

是什么：

更接近 Vercel 官方博客在讨论 Vibe Coding 时的核心表述：本质不是把代码外包给 AI，而是学会用更高层的意图与它协作完成实现。这意味着你必须仍然理解系统，只是理解的着力点从「每个符号怎么敲」迁移到「模块如何拆分、边界如何定义、结果如何验收」。

用一句更工程一点的话：Vibe Coding 是把「实现」部分大规模委托给模型，但把「定义问题与验证答案」牢牢留在人类一侧。

2. Agent 视角：为什么「Agent」不是聊天升级款

Addy Osmani 在谈 AI Agent 时给了一个很关键的切入点：不要把它当成更会聊天的模型，而要把它看成能维持上下文、调用工具并连续完成任务的工作系统。这个定义直接解释了为什么「同一个模型」在 IDE 里与在网页聊天里表现不同：工作系统变了，工具链变了，反馈回路变了。

把 Agent 当成工作系统，你会立刻少踩两个坑：

  1. 你不会迷信「一句话解决一切」，因为长链路任务需要分解、检查点与状态管理。
  2. 你不会忽略协议与生态（例如 MCP、A2A 等讨论里常见的「工具互操作」问题），因为 Agent 的强度很大程度取决于它能否稳定调用正确的工具。

下面这张图帮你建立「模型 vs 助手 vs Agent 工作系统」的分界（注意：这是教学示意，不是严格学术分类）。

flowchart TB
  M[大语言模型 概率生成文本]
  A[聊天助手 多轮对话]
  G[Agent 工作系统 上下文+工具+任务链]

  M --> A
  A --> G

  G --> T1[读文件/写文件]
  G --> T2[运行命令/测试]
  G --> T3[检索/浏览器/数据库]

3. Agentic Engineering：Vibe 的「成年人版本」

如果 Vibe Coding 描述的是一种松散的协作体感，那么 Agentic Engineering 描述的就是同一件事在严肃工程里的纪律版本。Addy Osmani 的核心判断很直白：重点不在于让 AI 干更多活，而在于把计划、审查、测试和责任重新拉回开发主线。

这句话翻译成一个可执行原则，就是「三件事不能外包给『 vibe 』」：

  1. 计划：你到底要解决什么问题，本期范围是什么，验收标准是什么。
  2. 审查：生成代码是否越权、是否引入不必要依赖、是否符合安全与性能底线。
  3. 测试与责任：哪些路径必须自动化验证，出问题谁负责回滚与修复。

所以本专栏在口语上可能会说「咱们 vibe 一下把页面搓出来」，但在质量标准上，我们默认你采用 Agentic Engineering 的底线：信任但验证。

flowchart LR
  subgraph Disciplined["Agentic Engineering 主线"]
    PL[计划 Plan] --> IM[实现 Implement]
    IM --> RV[审查 Review]
    RV --> TS[测试 Test]
    TS --> SH[发布 Ship]
    SH --> FB[反馈 Feedback]
    FB --> PL
  end

4. 开发者角色迁移：从实现者到编排者与审查者

「工厂模型」讨论里有一句很刺耳但很有用的话：当智能体承担更多实现工作，开发者的高杠杆价值会从「写代码的人」转向「设计生产系统的人」。对个人开发者而言，「生产系统」不必是巨型平台，它可以很小：

  • 你的仓库目录是不是可预测的？
  • 你的启动命令是不是可重复？
  • 你的环境变量与密钥是不是隔离清楚？
  • 你的每次发布是不是可回溯？

这些看起来「不性感」，但它们决定你能不能持续 ship。AI 会加速你在「实现层」的产出；如果你不在「系统层」同步升级，你会更快地把不可维护性规模化。

下面这张图是本讲最重要的产出之一：角色迁移。建议你把你的名字写在便利贴上，对照自己目前主要停在哪个环。

flowchart TB
  subgraph Old["传统高频角色"]
    C1[手写实现者]
    D1[调试匠人]
    O1[栈溢出拼图者]
  end

  subgraph New["AI 时代更高杠杆角色"]
    O2[目标编排者 Orchestrator]
    S2[规格写作者 Spec Owner]
    R2[质量审查者 Reviewer]
    A2[系统设计者 System Designer]
  end

  C1 -->|迁移| O2
  D1 -->|迁移| R2
  O1 -->|迁移| S2
  C1 -->|迁移| A2

迁移不是「以后不写代码了」。实际上，很多高手在 AI 时代写得更密、更狠，因为他们把重复劳动砍掉以后，把时间花在刀刃上：关键路径、关键抽象、关键风险点。

5. 「软件工厂」到底是什么意思（别被名词吓到）

工厂模型不是要把你做成人肉螺丝钉，而是在强调：交付越来越像一条流水线，而流水线的可靠来自规范、工具与质量控制。对独立开发者，这条流水线可能只有两个人：你和 AI。但即便如此，你依然需要：

  • 输入标准：需求怎么写，才能让 AI 少猜？
  • 过程标准：哪些改动必须跑哪些命令？
  • 输出标准：什么算 done？性能、可访问性、错误提示算不算？

Ravi Mehta 与 Danny Martinez 在「规范是新的源代码」里提过一个很 AI 时代的判断：当 AI 大规模承担实现，规范会越来越像真正驱动产出的源头文件。你听完可能会觉得「写文档好烦」，但你可以把它翻译成更接地气的动作：把规范写到 AI 每次都会读的地方（例如 AGENTS.md、项目 README 的约束段、Cursor Rules），让它成为「生成器的编译器」。

6. Vibe Coding 什么时候很香，什么时候会翻车

适合的场景（高概率划算）：

  • UI 与样板代码：表单、布局、组件拆分、样式细化。
  • 机械重构：重命名、抽函数、迁移目录、统一风格。
  • 测试与脚本：编写单元测试骨架、生成 mock、写一次性迁移脚本。
  • 学习与排错：解释报错、对比方案、给出最小复现建议。

不适合硬 vibe 的场景（你需要强管控）：

  • 安全与权限：鉴权、密钥、支付、敏感数据处理。
  • 强一致性与并发：资金、库存、幂等、分布式事务。
  • 性能关键路径：在没有 profiling 的情况下让模型「随意优化」。
  • 合规领域：医疗、金融、隐私、审计要求高的系统。

这不是吓你，而是帮你分配注意力：让 AI 做它擅长且便宜的，不让它做你付不起代价的。

7. 世界级智能体工程师的共同特征（你可以对照自检）

01-core-concepts.md 里整理过一条线程式观点：决定产出的往往不是敲代码速度，而是组织上下文、拆解任务和约束执行的能力。把它变成日常动作，就是下面这套「硬技能组合」：

  1. 上下文工程：哪些信息必须常驻、哪些必须按需检索、哪些应该永远不进仓库。
  2. 任务分解：把「做一个笔记应用」拆成可独立验收的小块，而不是让模型一次吞大象。
  3. 约束执行：明确技术栈版本、代码风格、禁止事项（例如不要随便升级 major）。
  4. 验证闭环：每个小块都有运行命令或手动验收步骤。

8. 争议与边界：革命还是鲁莽？

同一份参考材料里也收录了很克制的提醒：真正值得警惕的不是 AI 让开发变快，而是人在速度上瘾后更容易放弃对质量、理解和边界的要求。你会在社区看到两种极端言论：一种把 AI 当万能，另一种把 AI 当骗局。更实用的立场是第三种：它是工具，工具需要流程。

这也是为什么本专栏坚持主线项目 + 渐进版本。项目会逼你面对现实：你的规格够不够、你的测试够不够、你的发布够不够。AI 不会替你承担这些现实，但会放大你在这些维度上的长处与短板。

9. 把认知落成一条工作流（今天就能用）

下面是一条「从意图到合并」的最小闭环，建议你在 VibeNote 的每一次迭代都照做：

  1. 写清楚目标与非目标（三条以内）。
  2. 列出验收标准（可勾选）。
  3. 让 AI 先给方案（不改代码也行），你只做一件事：挑刺。
  4. 让 AI 分步改代码，每步可运行。
  5. 你自己读 diff：安全、依赖、越权、愚蠢默认值。
  6. 运行与手动验收，再提交。

10. 本讲小结

  • Karpathy 的 Vibe Coding 是现象命名：实现委托变强，但责任不能委托。
  • Agent 应被理解为「工作系统」，不是「更会聊」。
  • Agentic Engineering 是纪律版协作：计划、审查、测试与责任回到主线。
  • 工厂模型对个人开发者同样成立：规范、工具、质量控制组成流水线。
  • 你知道什么时候该 vibe，什么时候该强管控，你就不会被工具牵着走。

11. 实操练习（不写代码也能做）

  1. 画出你自己的「角色饼图」：你上周多少时间在手写实现、多少在调试、多少在写规格、多少在审查 AI 产出？
  2. 选一次你最近的 AI 协作失败：失败更像「规格问题」还是「验证问题」？用一句话重新定义任务。
  3. 列出你项目中三类任务：A 适合 AI 大胆写，B 必须你主导，C 必须双人复核（你与 AI 各做什么）。

思考题

  1. 你认为「审查 AI 代码」与「审查同事代码」最大的不同是什么？这会导致你采用哪些不同的检查点？
  2. 如果你只能给团队（或给未来的自己）立一条 AI 使用纪律，你会选哪一条？为什么？
  3. VibeNote 的哪一个模块最不适合「先 vibe 再补」？你会怎么调整顺序？

下一讲预告

第02讲：工具选型。我们会把 Cursor、Copilot、Windsurf、Claude Code、Cline 以及 v0 / Bolt / Lovable 等原型工具放到同一张对比表里：它们各自擅长什么、浪费你时间的坑在哪里、预算怎么花才值。你会带走一棵决策树，以后换工具也不慌。

参考阅读：reference/articles/01-core-concepts.md（Agent、Agentic Engineering、工厂模型、规范驱动、质量边界相关条目）。

附录：三条「反 vibe」红线（建议打印）

  1. 密钥不进仓库、不进聊天、不进截图。需要举例就用占位符。
  2. 任何涉及用户数据的改动默认先问：最小权限在哪里？
  3. 任何「升级依赖大版本」默认先问：变更日志我读了吗？回滚路径有吗？

延伸阅读：从「会写」到「会交付」的同义词替换

很多人学习路径里最大的隐形坑，是把「我会写」当成「我能交付」。在 AI 时代这两个词距离更远：写变得更容易，交付却更暴露系统能力。交付包括：可运行、可配置、可观测、可回滚、可对用户解释。你会发现本专栏后面每一讲都在偷偷训练这些词。

当你用 Vibe Coding 的方式推进时，建议你刻意改口：少说「我写出来了」，多说「我能演示、我能部署、我能复现、我能修」。语言会反向塑造行为，行为会塑造肌肉记忆。

案例速写：同一个需求，两种协作质量

需求：「做一个笔记列表，可以新增。」

低质量协作：一句话丢给模型，得到一坨能跑但结构混乱的代码，三天后加功能全崩。

高质量协作：先定义数据结构（标题、内容、创建时间）、定义交互（新增后焦点在哪）、定义持久化（本期 localStorage，下期数据库）、定义验收（刷新不丢）。然后让模型分文件实现，并要求它给出运行步骤。

这两种协作的差异不在模型，而在人类输入的规格强度。这也是「规范是新的源代码」的体感版本。

术语对照表（防止你被英文文章带着跑）

英文中文表述你在项目里要做什么
Orchestration编排拆分任务、安排顺序、定义检查点
Ownership所有权/责任明确谁对回滚、事故、数据负责
Spec规格可验收描述 + 非目标
Review审查读 diff、查安全、查依赖、跑关键路径
Agentic智能体式强调工具调用与连续任务的工程化

最后一句实话

范式革命听起来很大，但你的落地动作可以很小：下一次你用 AI 写代码前，先花五分钟写验收标准。这五分钟会比五小时「反复试提示词」更值钱。

加餐：把「Coding Agents」放进你的日常节奏（Devin 指南的落地版）

参考概念文章里 Cognition Team 的提醒：真正把 Coding Agents 用起来，靠的不是一句神奇提示词，而是任务委托、检查点与反馈机制。你可以把它简化成一张「日常表」：

环节你要问自己的话最小输出物
委托这件事能否拆成 3 步以内？分步任务列表
检查点哪一步必须先跑起来？可运行命令与期望现象
反馈失败时是规格不清还是实现越界？一段可复制的报错 + 目标描述

你会发现，这套表与 FAANG 匿名工程师文章里强调的东西是同一个方向：高标准环境反而更需要流程，不是更不需要。流程不是官僚，是你在高速迭代里防止「不可控变更」的护栏。

深度辨析：Vibe Coding 与「规范驱动开发」到底是什么关系

很多人把规范驱动开发（Spec-driven）理解成「写很长文档」。在 AI 时代更实用的理解是：规范是生成器的约束条件。这意味着好规范不是文学，而是可测试的陈述。举例：

  • 差：「笔记要好用。」
  • 好：「新增笔记后，标题输入框清空，光标回到标题框，列表立即出现新卡片，刷新页面后仍在。」

第二条仍然不完美，但它已经可以被逐项勾选。AI 最喜欢这种任务，因为「完成」可被判定；你也最喜欢这种任务，因为你能快速知道模型有没有糊弄。

你再看看这张「责任归属」图

flowchart TB
  U[用户可见结果] --> Q[质量责任]
  Q --> H[人类开发者]
  AI2[AI 生成实现] -.建议/草稿.-> H
  H -->|合并/发布/回滚| U

虚线与实线的区别很重要：AI 可以给你建议与草稿，但合并与发布按钮在你手里。只要你守住这条边界，你就不会在事故后陷入「都是模型的错」这种无效争论——你会回到有效问题：我哪条审查缺失？

练习升级版：用 200 字写「VibeNote V1 规格」

试着不写代码，只用 200 字描述 V1：数据结构、页面结构、交互、持久化、明确不做的事。写完后做两件事：

  1. 把其中任何形容词（好用、快速、美观）换成可验证描述。
  2. 让 AI 只基于这段规格先生成「文件结构建议」，你不要急着让它写实现。

你会第一次直观感受到：规格长度不决定质量，可验证性才决定质量。

本讲自测（答不上来就重读第二节与第五节）

  1. 用你自己的话解释：为什么 Agent 更应被理解为「系统」而不是「模型」？
  2. 说出三种「不适合硬 vibe」的任务类型，并各给一个你自己的项目例子（可虚构但要具体）。
  3. Agentic Engineering 与「想到什么就让 AI 做什么」的本质差别是什么？用一条流程差异说明。

与下一讲的衔接：工具不是立场，工具是工作流的一部分

当你把角色迁移想清楚，你就会更容易理解下一讲的结论：选工具是在选工作流。Cursor 强项在仓库级上下文与迭代速度；Copilot 强项在 IDE 内联与团队渗透；CLI 类工具强项在自动化与脚本化。没有唯一正确答案，只有你当前阶段最缺的杠杆在哪里。

把本讲记住的一句话带到下一讲：工具解决的是路径问题，规格解决的是方向问题。方向错了，再强的工具只会让你更快走错。

尾声：我愿意把「Vibe」留给你自己定义

我不喜欢替你做价值判断。你可以继续讨厌这个词，也可以把它当成轻松的记忆锚点。重要的是你是否开始用更工程化的方法使用 AI：更快，但更可控；更省力，但更负责。

如果你愿意，从现在开始把你的学习笔记改成一种格式：今天我的规格有没有变清楚？今天我的验证有没有变便宜？这两个问题比「我今天用了几次 AI」更能预测你一年后的上限。

补充：从「个人作坊」到「一人工厂」的五个开关

你不需要等公司变大才开始像工厂一样思考。下面五个开关，独立开发者也能立刻启用：

  1. 模板化：同类页面用同一种状态管理模式，别每个页面发明一次宇宙。
  2. 脚本化：安装、启动、检查环境都尽量变成一条命令，减少「我忘了怎么做」。
  3. 清单化：发布前检查项固定下来：环境变量、数据库迁移、回滚方式。
  4. 日志化：关键路径至少知道去哪里看错误，而不是靠猜。
  5. 版本化：依赖升级有记录，功能变更有记录，事故复盘有记录。

这五个开关与 AI 无关，但会让 AI 更不容易把你的项目拖进泥潭。原因很简单：模型最擅长在「有约束的棋盘」里下棋；棋盘越乱，它越会给出看似合理、实则不可维护的走法。

再谈「快」：快的定义应该是「单位风险的交付速度」

很多人喜欢把快理解成「更少时间写完」。更贴近工程现实的理解是：在可控风险下，把可用增量交付出去的速度。这意味着测试、审查、回滚不是拖慢，而是在降低每一次「快」的副作用。

当你用这种方式重新定义快，你会自然接受一件事：有些提交看起来慢，但它让下周的你更快。VibeNote 的渐进版本就是按这个逻辑设计的——我们宁可少做功能，也不做一锤子买卖。

场景演练（口头即可）：线上事故时你怎么解释责任？

假设用户数据出现异常，你怀疑与某次 AI 生成补丁有关。有效的复盘不会停留在「模型错了」，而会追问：

  • 这次变更有没有 code review？
  • 有没有针对关键路径的自动化测试？
  • 数据库迁移是否可回滚？
  • 是否违反了最小权限？

这些问题会把讨论从「情绪」拉回「系统」。这也是 Agentic Engineering 为什么强调责任回归人类：不是道德高调，而是只有人类能把系统改到更不容易再犯。

本讲最后一页：请你写下的三句话

  1. 我的项目里，AI 最适合承担的三件事是：___
  2. 我绝对不让 AI 独自完成的三件事是：___
  3. 我本周要改进的一条协作纪律是：___

写完后贴到显眼位置。下一讲你会用工具选择来服务这三句话，而不是被广告文案服务。

第1章 第2节：零基础到上线作品：一条少走弯路的学习主线

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

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

很多读者问过同一个问题：零基础到上线作品：一条少走弯路的学习主线。

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

常见误区包括：

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

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

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个真实场景中的风险点与应对策略。
  • 能把本节能力迁移到你自己的项目中。

八、延伸阅读与练习题

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