目录
- [一、AI 时代下的编程范式](#一、AI 时代下的编程范式)
-
- [1.Vibe Coding（氛围编程）的起源](#1.Vibe Coding（氛围编程）的起源)
- [2.Vibe Coding 的局限性](#2.Vibe Coding 的局限性)
-
- [1. 代码质量和架构容易变成"黑箱"](#1. 代码质量和架构容易变成“黑箱”)
- [2.上下文长度有限，AI 并不能真正"记住整个项目"](#2.上下文长度有限，AI 并不能真正“记住整个项目”)
- [3. 知识有截止，模型还会"幻觉"](#3. 知识有截止，模型还会“幻觉”)
- 4.安全性问题往往藏得最深
- [5.. 可靠性和工程化能力也不一定过关](#5.. 可靠性和工程化能力也不一定过关)
- [6.Vibe Coding 的正确定位不是替代，而是放大](#6.Vibe Coding 的正确定位不是替代，而是放大)
- [7. 一个更成熟的认识：不是等万能 AI，而是建立工具协作结构](#7. 一个更成熟的认识：不是等万能 AI，而是建立工具协作结构)
- [3，AI 开发框架：新战略高地？](#3，AI 开发框架：新战略高地？)
- 4.未来展望
一、AI 时代下的编程范式
1.Vibe Coding（氛围编程）的起源
过去十年里，低代码、无代码平台和各种 AI 代码助手，一直都在不断改变软件开发的方式。到了今天，编程这件事不再只是"手敲代码"，而开始变成"描述需求、组织思路、验证结果"。在这样的背景下，Vibe Coding 这个概念迅速走红。其实是在说明一个很关键的现实：AI 时代，开发者的工作重心正在发生变化。
所谓 Vibe Coding，可以理解成一种"用自然语言驱动开发"的编程方式。开发者不再一上来就自己写大量底层实现，而是先把需求、目标和约束告诉大语言模型，再由模型去生成代码、补齐实现、组织结构。也就是说，开发者逐渐从"代码的直接生产者"，转向"需求的表达者、结果的判断者、流程的掌控者"。
它的核心就是：开发者通过自然语言向针对代码优化的大模型描述问题，由模型生成软件。
**Vibe Coding 这一术语由 Andrej Karpathy 在 2025 年 2 月提出。**这个概念之所以传播得这么快，是因为它正好击中了很多人的真实体验：以前写一个功能，要自己搭结构、查文档、补细节；现在越来越多人是先把需求丢给 AI，看它先生成一个版本，再在这个基础上修修补补。对于很多初学者甚至业余开发者来说，这种方式门槛更低、上手更快，看起来也更"直觉化"。
需要说明的是：Vibe Coding 不是"完全不用懂代码"
用户往往会在并不完全理解底层机制的情况下先接受 AI 生成的代码 ；但这并不意味着开发者可以彻底放弃审查和测试。相反，开发者仍然要对生成结果进行检查、验证，必要时还要理解关键实现。换句话说，Vibe Coding 不是把"思考"删掉了，而是把"手工实现"大量外包给了 AI。
你可以把它想成这样：
以前做开发，像是自己一砖一瓦盖房子；
现在更像是你先告诉一个施工团队"我要什么样的房子"，它很快给你搭出雏形，但你仍然要验收、改图纸、盯质量。
所以，开发的重点从**"怎么一点点写出来"，变成了"我要什么、它写得对不对、结构能不能撑住以后迭代"。**
Karpathy 对这种方式的描述，大意就是"看看东西、说说东西、运行一下、复制粘贴一下，很多时候它就能工作"。这句话背后反映的，其实不是编程变简单了，而是编程的抽象层级变高了。开发者开始更多地用"意图"驱动系统，而不是总陷在每一行底层实现里。于是，软件开发的模式也从过去那种细致、手工、逐步展开的编码方式，逐渐转向一种更抽象、更偏结果导向的开发方式。
这种新方式至少带来了四个非常明显的转移,
第一，开发者要更会定义问题。
以前你代码写得好，可能就能把事情做成；现在如果你连问题都描述不清，AI 就很容易给你生成一堆看起来像样、实际上跑偏的东西。所以，如何把需求说清楚、把边界讲明白、把预期结果表达准确，会越来越重要。
第二，开发者要更会审查结果 。
AI 生成代码很快，但"快"不代表"对"，更不代表"适合当前项目"。你得判断这段代码能不能进项目、架构上是否合理、有没有副作用、后期是否好维护。所以开发者不再只是写代码的人，更像一个技术编辑 或者代码审稿人。
第三，开发者要更懂系统设计和架构。
因为当具体实现越来越容易被生成时，真正拉开差距的，就不是"会不会写一个函数"，而是"这个功能应该放在哪一层""模块之间怎么组织""以后扩展时会不会炸"。说白了，AI 能帮你写砖头，但房子的结构还得你定。
相比低层次编码，系统设计、架构理解、批判性思维和问题解决能力会变得更重要。
第四，开发者要学会和 AI 协作。
这不是简单地会不会提问，而是你得知道什么时候该让 AI 发挥，什么时候该自己接管；什么时候给它开放空间，什么时候加硬约束；什么时候让它快速起草，什么时候要求它严格按格式输出。提示词能力、反馈能力、迭代能力，都会逐渐变成开发者的新基本功。
编程基本原理仍然有价值，因为没有这些基础，你就很难真正指导 AI，也很难排查问题。
所以从这个角度看，Vibe Coding 真正改变的，不只是"怎么写代码"，而是"开发者在团队中的角色"。过去更像纯粹的代码编写者，现在越来越像架构师、方案制定者、产品理解者和 AI 协作者 。谁能把需求讲清楚、把结果验明白、把系统架好，谁就更有竞争力。
所依：
2025 年开始，像 Cursor、Trae、Claude Coding 这类工具迅速流行，很多人因此产生一种错觉------"既然 AI 都能直接写代码了，那我还有必要认真学框架吗？"这个问题非常关键，这个问题非常关键，因为它实际上就是后面 LangChain 和 LangGraph 为什么值得学的引子。也就是说，AI 能加速开发，但复杂应用依然需要框架、架构和工程化方法。
Vibe Coding 的出现，说明编程正在从"手工实现"走向"意图驱动"。
它让开发速度更快、试错成本更低，也让更多人有机会参与软件开发；但与此同时，它也对开发者提出了新的要求：不仅要会写，还要会问、会审、会架构、会判断。
所以，AI 不是让开发者失去价值，而是在倒逼开发者升级自己的价值。谁只会机械敲代码，谁的优势会被削弱；谁能驾驭 AI、理解系统、把控质量，谁就会更重要。
2.Vibe Coding 的局限性
AI 生成的代码，很多时候只是"能跑"，不一定"能长期维护"。"
这两者差别非常大。一个 demo 能运行，不代表它适合放进真实项目；一个功能今天能用，也不代表明天改需求时不会把整个系统拖垮。真正的问题，往往不出在"有没有生成代码"，而出在"生成出来的代码到底靠不靠谱"
1. 代码质量和架构容易变成"黑箱"
AI 的目标通常是根据你的提示，尽快生成"功能上可运行"的代码；但它并不真正理解什么叫"优雅"、什么叫"可维护"、什么叫"可扩展"。这些词对人类工程师来说，背后意味着模块边界、职责划分、依赖方向、后续扩展成本，但对模型来说，更多只是训练数据中的统计模式。
这就像什么呢？
你让一个装修队按你的描述立刻给你装一间房，它确实能很快装出来，表面看也挺像样；但电线有没有乱走、承重有没有问题、后面好不好修，你如果不懂，很难第一眼看出来。
AI 写代码也是一样：它很会"拼出一个答案"，但不一定真的给你设计了一个长期可用的结构。
所以很多人第一次用 AI 写代码时会觉得特别爽：
"哇，几分钟就出来了。"
可一到第二阶段，比如加功能、改字段、拆模块、联调接口，就会发现前面那份代码像一坨缠在一起的线。你越改越难受，最后甚至还不如自己从头梳理。
AI 可以产出代码，但架构质量仍然需要开发者自己负责。
2.上下文长度有限，AI 并不能真正"记住整个项目"
模型真的像鱼，而是说它虽然能看一段上下文，但它并不能像人一样，持续、完整地记住一个大型项目的全部历史、结构和设计意图。
一个真实项目不是几百行代码，而是很多模块、很多文件、很多历史决策叠起来的结果。
今天你让 AI 帮你写用户模块，明天让它改订单模块，后天再让它加日志、权限、缓存。它每一次看到的，可能都只是局部。这样一来，后期新增需求很容易和前面已有设计冲突，甚至写出重复逻辑、破坏原本结构。
AI 可能因为"忘记"之前的完整上下文，而生成与现有架构冲突的代码，导致系统逐渐腐化。
这件事在小项目里还不明显，一到稍微复杂一点的工程就特别致命。
比如你已经在项目里约定好了统一错误处理、统一日志格式、统一数据库访问层。结果 AI 因为只看到当前函数，就又给你单独造了一套。看起来功能实现了，实际上规范被打穿了。
久而久之，项目就会变成"每块都能跑，但整体很难管"。
3. 知识有截止，模型还会"幻觉"
除了记忆不完整，还有另一个大问题：知识滞后和幻觉。这个是十分致命的！！！！！！！！！！！！！！！！！
大模型不是实时全知的，它的训练数据有截止时间。也就是说，它未必知道最新的语言特性、最新的库版本、最新的最佳实践。更危险的是，它有时候会一本正经地给你编出并不存在的 API、参数甚至函数名，看上去很像真的，实际上根本跑不起来。
这个坑很多人都踩过。
比如它可能告诉你某个框架里有一个特别方便的方法，你一搜文档，根本没有；或者给你拼出一套"看起来很合理"的调用方式，结果编译直接报错。
这就是为什么会写代码的人和不会写代码的人，用 AI 的结果差别会非常大。
会的人能快速判断："这个接口不对，这个写法像幻觉，这个版本根本不支持。"
不会的人可能就会被它带着跑，越改越乱。
所以，AI 提高的是生成速度，不是正确率保证。
真正兜底的，还是开发者自己的基础能力和判断力。
4.安全性问题往往藏得最深
很多 AI 生成的代码，表面功能没问题，但内部可能悄悄埋了坑。
比如安全方面，AI 没有真正的"安全意识"。
它可能很自然地给你写出：
1.没有过滤的 SQL 拼接
2.没有校验的前端输入
3.硬编码账号密码
4.权限控制过于宽松
5.接口直接暴露内部实现
这些问题在 demo 里看不出来，但一旦上到真实环境，就可能变成 SQL 注入、XSS、越权访问、敏感信息泄漏。课件明确指出，对于金融、医疗这种高安全要求场景，这种风险是不可接受的。
说白了，AI 不懂"后果"。
它只是在补全"像答案的答案"，但生产系统面对的是恶意输入、异常流量、真实攻击，不是课堂练习。
所以你不能因为它写得快，就默认它写得安全。
5... 可靠性和工程化能力也不一定过关
除了安全，还有可靠性。
AI 生成的代码可能在小规模数据下没问题，但一旦上高并发 、大数据量或者边界场景，就容易出问题。因为它通常没有真正替你完成完整的工程化设计，比如日志、监控、熔断、异常处理、降级策略等。
这一点很像学生写作业和公司做系统的区别。
学生作业只要"结果对"就行；
公司系统必须考虑"出错怎么办、慢了怎么办、挂了怎么办、查不出来怎么办"。
AI 很擅长把主要流程写出来，但对这些"脏活累活"经常处理得不够扎实。
而偏偏真实项目里，最重要的常常不是"主流程能不能跑"，而是"出问题时能不能稳住"。
6.Vibe Coding 的正确定位不是替代，而是放大
这个判断很关键。
因为很多人一看到 AI 会写代码，就走向两个极端：
一种是盲目乐观，觉得以后不用学了，全部交给 AI；
另一种是完全排斥，觉得 AI 写的都不靠谱，没有价值。
其实这两种都不对。
真正一线开发里，AI 最有价值的，往往不是"帮你从 0 到 1 写一个完美系统"，而是：
1.帮你快速起草
2.帮你补重复逻辑
3.帮你写测试
4.帮你解释陌生代码
5.帮你搭一个原型
AI 最适合做"工程执行层面的提效"，不适合做"工程责任层面的拍板"。
7. 一个更成熟的认识：不是等万能 AI，而是建立工具协作结构
Karpathy 后来调整了说法，认为不要幻想有一个万能 AI 工具解决所有编程问题，更可行的是建立一个结构，让不同工具在不同场景各司其职，像接力赛一样完成开发任务。这个观点其实更成熟，也更接近真实工程。
什么意思呢？
就是以后开发很可能不是"一个 AI 包打天下"，而是：
一个工具负责生成代码
一个工具负责测试
一个工具负责文档
一个框架负责组织流程
开发者负责决策、审查和整合
这也正是后面为什么要学 LangChain 、LangGraph 的原因：
因为真正复杂的 AI 应用，不是靠一个聊天框就能做出来，而是要靠一套可组织、可控制、可维护的框架。
Vibe Coding 的价值，在于它极大提升了开发速度，让"写代码"这件事变得更轻、更快、更自然。
但它的局限也很明显：代码质量不透明、上下文记忆有限、知识会过时、容易产生幻觉，还可能埋下安全与可靠性问题。
所以，正确的态度不是迷信它，也不是拒绝它，而是把它放在合适的位置上：
让 AI 做高频、重复、可验证的执行工作；让人负责架构、判断、审查和最终责任。
3，AI 开发框架：新战略高地？
前面我们已经分析过，Vibe Coding 很强，但它更多解决的是"生成得快"的问题，并不能天然解决"系统怎么组织、流程怎么编排、结果怎么验证、风险怎么控制"这些工程问题。也正因为如此：
在 AI 时代，真正拉开差距的，不只是会不会用 AI 写代码，而是会不会用框架把 AI 能力组织成可落地的系统。
现在构建一个 AI 应用，早就不只是"调一下 API"这么简单。 真正的 AI 应用往往还要面对数据处理、模型交互、任务编排、状态管理等一整套复杂问题。也就是说，你做的已经不是"单次问答"，而是在做一个完整的软件系统，只不过这个系统里多了 LLM 这个核心能力。
所以，为什么还要学框架？
答案很简单：因为 AI 能帮你写局部代码，但复杂应用仍然需要整体组织能力。
这就像你手里有很强的零件加工机器，不代表你自动拥有装配整车的能力。真正难的地方，不在"某个零件能不能做出来"，而在"所有零件怎么拼在一起，才能稳定、安全、长期地跑起来"。
3.1框架原则
AI 开发框架和传统框架，本质上遵循的是同一套工程思想。
（1）抽象与封装
把复杂细节藏起来，把常用能力包装好，让开发者站在更高层做事。
比如：
1.Spring 会把 Java EE 开发里那些繁琐的东西封装起来，比如依赖注入、事务管理、MVC。这样开发者就不用每次都自己去手动管理对象生命周期，也不用陷进一堆底层 Servlet API 里。
2.libcurl 会把底层网络协议的复杂性封装起来，比如 HTTP、FTP、SMTP。对于开发者来说，你不需要直接拿 socket 一步步手搓 HTTP 请求，而是通过更高层的接口完成网络通信。
LangChain 做的事情，本质上和它们一样。它把不同大模型、向量数据库、工具调用这些复杂交互统一封装起来。这样你不需要为 OpenAI 写一套，为 Anthropic 再写一套，为 Pinecone、Chroma、各种 Tools 再各写一套适配逻辑。框架先帮你把底层差异抹平，你再在这个基础上开发自己的应用。
你写项目时不会希望业务层到处直接操作 socket、文件描述符、线程细节；你更希望这些底层能力被封装成类、模块或组件。
LangChain 对 LLM 世界做的，就是类似的事情：给混乱的底层接口加一层统一抽象。
（2）模块化与可组装性
框架不只是把功能"包起来"，还要让这些功能能够像积木一样灵活拼装。
在 Spring 里，依赖注入和控制反转容器会把程序组织成一堆可插拔的 Bean。数据库实现能换，服务实现也能换，系统整体不会因为某个零件变动而全盘推倒。
而在 LangChain 里，核心思路就是 Chain。它会把不同模块，比如：
LLM
Prompt
Tools
Memory
Output Parser
按流程拼起来，形成一个完整的 AI 工作流。也就是说，LangChain 不是只给你一个"调用模型"的函数，而是给你一个可以不断组装的工作流框架。
这点特别重要。
因为真实 AI 应用几乎都不是"输入一句话，输出一句话"这么简单。很多时候流程会变成：
用户输入
→ 先做提示词模板填充
→ 再调用模型
→ 再调用工具
→ 再解析输出
→ 再把结果送回系统
如果没有框架，这些步骤就会散落在代码的各个角落，后面越改越乱；
有了框架，你就能把它们变成结构化、可维护、可替换的流程。
LangChain 不是一个"AI 接口集合"，而是一个"把 AI 应用拆成标准零件再重新拼起来"的工程框架。
3.2超级武器
框架不是锦上添花，而是把 AI 从"能聊"变成"能做事"的关键桥梁。
这些 AI 开发框架很像智能时代的"操作系统"，负责把强大的模型能力和复杂的现实应用连接起来。也就是说，大模型本身很强，但如果没有框架组织，它更像一台性能很猛却没有系统环境的机器，能力存在，但难以稳定服务于真实业务。
你也可以把框架理解成一个万能工具箱。
那些复杂、底层、重复的技术细节，框架都先帮你封装了一层，给你一套现成模块。这样你不用从零造轮子，而是能更快把想法变成应用。框架知识至少会给我们四种关键能力：架构、质量、安全、集成。
1. 架构
框架让你知道，代码应该怎么组织。
这个能力很值钱，因为 AI 最容易搞出来的是"能跑的代码"，最难保证的是"清晰的系统结构"。而框架本身就内置了一种推荐的组织方式，它会帮你减少那种东一块西一块、后期难维护的混乱状态。
2. 质量
框架让你更容易判断 AI 生成的代码是不是合格。
因为一旦有了统一抽象和流程约束，你就不再只是看"它跑没跑"，而是会进一步看：它是不是符合这个框架下的最佳实践？是不是符合组件职责？是不是容易接入现有系统？
3. 安全
框架内置的一些最佳实践，可以帮你避开不少基础风险。
这并不是说只要用了框架就自动安全，而是说框架会让很多常见问题更容易被规范化处理，不至于每个人都按自己的理解乱写一套。
4. 集成
框架能把 AI 生成的零散"零件"，更高效地组装进一个可靠系统。
这点非常关键。因为真实开发不是只看单个模块，而是看它能不能接进已有数据库、API、前端、权限系统、监控链路。框架的价值，就在于它帮你把这些拼装成本降下来。
AI 代码工具解决的是"写得快"，AI 开发框架解决的是"做得成"。
Vibe Coding 让开发者更容易把局部代码写出来；
而 LangChain、LangGraph 这样的框架，负责把这些局部能力组织成真正能落地的应用系统。它们遵循的依然是经典的软件工程原则：抽象、封装、模块化、可组装。正因为如此，它们不是可有可无的辅助品，而是 AI 时代的核心基础设施。
4.未来展望
前面两部分其实已经把逻辑铺得很清楚了：
先讲 Vibe Coding，说明 AI 正在改变"写代码"的方式；
再讲 AI 开发框架，说明真正复杂的系统仍然需要工程化组织。
那么接下来最自然的问题就是：未来的程序员到底会变成什么样？
Vibe Coding 不会完全取代传统编程技能，而是会和传统开发形成互补
未来开发者会更多地把精力放在高层次的系统设计、架构决策和业务逻辑上，而把更多实现细节交给 AI 去完成。
也就是说，AI 会越来越像一个高效率的执行助手，它能帮你快速生成代码、补齐样板、改写函数、生成测试、整理文档；而人负责更上层的东西，比如需求理解、系统拆分、边界定义、风险控制、质量判断和最终责任。
未来被淘汰的，不一定是程序员，而是旧的工作方式更可能发生的，不是 AI 取代程序员，而是会用 AI 的开发者取代不会用 AI 的开发者。