我不知道 Vibe Coding 是谁发明的，不过在我经历了一些事情之后，我大概是这么理解它的： 就是用 AI 进行小作坊式的编程。

最近换了新的工作，在做 AI 相关的产品，算是稳定下来了。

那么就来聊聊这两年的一些想法吧。

纯人工内容居然成了稀罕物

我感觉现在简体中文互联网上的新内容，至少有 90% 都有 AI 参与了。

这一点反而让我有了写文章的冲动，为的就是让你们回忆一下人类写的文章读起来到底是什么感觉（笑）。

目前我的知识来源主要是 Hacker News 点赞超过 50 的文章列表和 Reddit 上我关注的一些技术论坛。

因为上面绝大部分内容都是人类产生的，而且是有一些见地和价值的。

不过讽刺的一点是，我主要通过 AI 来阅读这些内容。

我会用沉浸式翻译（配合 DeepSeek API）来将英文翻译为中文，

还会用 Perplexity.ai 来总结文章。

所以严格来说，我还是在阅读 AI 产生的内容（笑）。

音频播客又回来了

人类总是会寻求出口的，想要听鲜活内容的人们让音频播客又火起来了。

最让我印象深刻的几期播客是：

• 【杨迪的迪听】我和金靖是“八卦”之交~
• 影视飓风TIM×罗永浩！用影像打开世界的梦想家
• 下一个流量风口：视频类播客和访谈节目

以上内容都能在 Bilibili 搜索观看完整视频。

这种什么东西又回来了的感觉让我想起了我的本科专业：软件工程。

我们的话题一下就转到软件工程了，嗯，人类写文章，就是这么跳跃。

Vibe Coding（氛围编程）

我不知道 Vibe Coding 是谁发明的，不过在我经历了一些事情之后，我大概是这么理解它的：

Vibe Coding 就是用 AI 进行小作坊式的编程。

“小作坊”这个词实在是太传神了，一个人什么都不懂就把事情干出来了，这不就是 Vibe Coding 吗？

AI 是这么解释小作坊编程的：

“小作坊式”编程指缺乏规范流程、依赖个人能力、依靠手工打造的软件开发方式。其特点是开发周期短、沟通直接，但存在代码规范差、维护难等技术债务风险。它通常由小型团队或个人进行，多用于快速验证想法或初创项目，但在大型系统开发中被认为难以维护。

你可能会问，那人类是怎么改进小作坊式编程的呢？当时人类的改进思路是不是已经被 AI 采纳了呢？

最初，程序员发现有些代码最好不写，于是有了结构化编程：

20世纪60-70年代，Dijkstra 等先驱推动了结构化编程，通过引入循环、条件判断并废除 GOTO 语句，解决了代码像“意大利面”一样混乱的问题。

回想我们在用 AI 编程的初期，是不是也总是让 AI 不要做某些事，不要写某类代码？

当时的程序员发现自己根本记不住那么多细节，于是给每个模块起名字，这里面就有面向对象编程的诞生：

面向对象编程 (OOP)： 80年代 Smalltalk、C++ 以及后来的 Java 普及了类、对象和封装概念，使代码实现了模块化和可重用性，不再依赖单个开发者的记忆力。

而 AI 编程解决记忆力不足的办法目前是增加了上下文长度，并开始了上下文工程。

在后来，程序员发现写代码之前最好先写文档：

瀑布开发模型： 70年代引入的瀑布模型首次将开发分为需求、设计、实现、测试等固定阶段，强制要求文档化，告别了“边想边写”的随意性。

看到“告别了边想边想的随意性”，我都不知道这句话是在说人类还是在说 AI（笑）。

我感觉目前的 AI 编程差不多发展到了瀑布开发模型阶段，下一个阶段如果还想继续重蹈人类的覆辙的话，应该进入敏捷开发阶段：

敏捷开发 (Agile)： 2001年《敏捷宣言》发布，通过迭代、Sprint 和持续反馈，解决了瀑布模型过于僵化的问题，同时用团队协作（如结对编程、站会）取代了“孤胆英雄”模式。

最后的最后，使用 AI 编程的人们可能会遇到“软件危机”，并开始了解“软件工程”这门课了，以下是 AI 对软件工程的总结（有点长，你可以快速滑动只看我高亮的关键词）：

“软件工程”这一学科的建立，是为了解决 20 世纪 60 年代爆发的“软件危机”。

当时，由于硬件性能飞速提升，人类开始尝试构建极其复杂的软件系统（如阿波罗登月计划、大型操作系统），但传统的“小作坊式”开发方法完全失效了。

软件工程主要解决以下四大核心难题：

1. 软件开发的“不可控性”

在没有工程化方法之前，软件开发就像黑盒：

• 进度失控： 项目几乎总是延期。
• 成本超支： 实际预算往往是预期的数倍。
• 交付失败： 许多耗资巨大的软件最终根本无法运行或无法交付。

2. 软件质量的“不可靠性”

“小作坊”出的软件往往逻辑漏洞百出，且缺乏系统性测试。

• 缺陷频发： 在医疗、航空等关键领域，软件 Bug 甚至会造成人员伤亡（如 Therac-25 放射治疗机事故）。
• 不符合需求： 开发者写出的功能往往不是用户真正想要的。

3. 软件维护的“噩梦”

早期软件缺乏文档和规范，导致维护成本极高：

• 难以读懂： 除了代码作者，没人能看懂复杂的逻辑。
• 维护成本超过开发： 历史上曾出现过维护现有软件的开销占到总成本 80% 以上的情况。

4. 软件复杂度的“规模化”问题

当代码量从几千行激增到几百万行时，个人英雄主义宣告破产。

• 协作障碍： 多人参与时，沟通成本呈指数级上升，导致效率反而下降（即 布鲁克斯法则）。
• 管理缺失： 缺乏科学的管理方法来组织大规模的团队协作。

简而言之，软件工程是为了让软件开发从“碰运气的手工艺”变成“可预测、可重复、高质量的现代工业”。

我并不是在这里装先知，只是发现自己在大学里学到的一些知识，可能真的有用，这还真是一种奇妙的感觉。

这就像是我在十年前甩出一记回旋镖，十年后这记回旋镖才飞回来砸中了我的后脑勺。

并且我相信 AI 未来真的会顺着人类已经走过的路再走一遍，然后再超越人类。

不过软件工程有一句著名的话在等着 AI，这句话是：没有银弹。

这句话出自 IBM 大型机之父 Fred Brooks 在 1987 年发表的经典论文 《没有银弹：软件工程中的根本困难与次要困难》

这句话的核心含义是：没有任何一种技术或管理手段，能像传说中杀死狼人的银弹一样，让软件生产率在十年内提高一个数量级。

Fred 认为开发软件的根本困难是：

• 复杂度： 软件各部分之间存在无数种状态组合，规模翻倍，复杂度呈指数级上升。
• 一致性： 软件必须遵循各种人为制定的接口、法律和遗留系统。
• 可变性： 软件比硬件更容易被要求修改，且修改频率极高。
• 不可见性： 软件没有物理实体，难以通过直观的图形完全描述其逻辑。

另外有一个次要困难，那就是，实现软件过程中遇到的阻碍。

这个困难是由落后的生产工具导致的，我们可以通过工程化手段解决。

例如，写汇编很困难，我们可以写 C++/Java。如果你觉得写 C++/Java 也困难，那么可以借助 AI 用中文或者英文来编程。

也就是说，AI 只是在解决软件开发中的次要困难。

你看，人类在很多年前就已经知道 AI 编程有什么优缺点了，为什么现在大部分人认为只要买足够贵的 AI，就能创造成功出任何软件呢？

因为现在自媒体太卷了。

我们的话题又一次切换了。

自媒体真的别看了

每次有 AI 大升级的时候，自媒体就会让它做一个静态页面，并声称任何人都能用 AI 赚大钱了。

目前国内自媒体行业的主要矛盾就是“新闻内容本身不够炸裂”和“自媒体希望自己发布的内容必须炸裂出圈”之间的矛盾。

AI 初期我会看一些自媒体的评测文章来了解 AI，现在这类自媒体我一律不看了。这导致我不得不看 Hacker News 上的英文文章（用 AI 翻译成中文）。

最后我发现，大部分编程圈的自媒体从业者，只是在搬运 Hacker News 上的文章而已。

如果你真的想了解 AI 的一切，你能做的只有自己动手用 AI，别无他法。

目前我在编程时会采用的 AI 有 Kimi K2.5、智谱 GLM 4.7、MiniMax M2、小米 mimo-v2-flash 和 DeepSeek。当然还有 GPT 5.2 Codex 和 Claude 4.5。

由于我用 AI 辅助编程时，自己会提供精准的上下文，所以这些 AI 我用起来都没什么问题，其中 Kimi K2.5 和 Claude 4.5 的效果尤其好一点，但也没有好很多。

不知不觉写了好多，这篇文章也没有什么明确的目的，也没有广告，仅仅是总结了一些想法而已，期待你的回复。