L2
和AI进行了头脑风暴，结合了一些对书籍的回忆，和AI搜索的结果。讨论了这个序到底应该从什么方面开始。
本人很菜，轻点喷。
这种风格不算教程，但是真的很不喜欢那种循规蹈矩的教程。
都 Vibe Coding了，还得按照“教学式”的教程来，那我 Vibe 个什么东西。
关于本系列写法的说明
我不太想从最基础的数据类型、运算符、条件语句、循环语句这些内容开始讲。
如果你对基础语法没有耐心，这里可能也不是最适合 从头开始 的地方。
我想强调的是：代码不只是代码，它反映了你的思考方式和解决问题的能力。
我也不只是想讲如何 Vibe Coding，更想讲述哪些软实力可以帮助我们更好地 Vibe Coding。
诸君共勉。2026/1/29
写在开头
我认为讲代码或者说讲 Vibe Coding，不需要从具体的语法细节开始。你也不会想听我从基本数据类型、运算符、条件控制和循环这些东西讲起。既然如此，我们直接开始 Vibe Coding。
我们可能是谁？
写代码一定要上计算机专业吗？我觉得并非如此，或者说我们将计算机这个学科与写代码的关系定义错了。计算机科学如果当成一门学科来看，它并非清晰。它只是由历史偶然，将多个领域强行拼装在一起的大杂烩。
可以把它想成一座天平。一端是数学系那类人：证明、模型、复杂度，他们在做的很抽象。中间是博物型的——路由、缓存、数据库，各种具体的问题，支撑着真正的实现。还有一端是 Hacker（黑客）：他们不太关心学科边界在哪里，只是想把东西做出来，把自己的想法变成能跑、能分享的作品。
如果要给这一端的我们找一个参照物，我们应当是画家或其他类型的创作者。
画家学习绘画的方法主要是动手去画，黑客学习编程的方法也理应如此。大多数黑客是从实践中学习的。即使在学校里，他们真正赖以生存的技艺，往往也来自那些“不务正业”的业余项目。
因为如果你不热爱一件事，你不可能把它做得真正优秀；而如果你热爱编程，你就不可避免地会去折腾自己的作品。
所以我不太想把自己说成“工程师”（至少不完全是）。工程当然重要：它关心“怎么做”，关心稳定性、性能、边界条件、可维护性。
但我更想聊的是另一件事：我们应该做什么。
代码 代码 代码
编程语言是用来帮助思考程序的，而不是用来表达你已经想好的程序。
观察一个画家的成长，你会发现他的作品是有连续性的——每一幅画所用的技巧，都建立在上一幅作品学到的东西之上。某幅作品如果有特别出色之处，你往往能够在更早的草稿里发现一个简陋的初期版本。
写代码也是一样的。我不从语法讲起，因为那些只是繁杂的说明书。我更在乎的是整个系统的架构，以及梳理，解决问题的逻辑。
所以很多时候，即使我们写的第一版也许不完美，但它会反过来告诉你——需求应该长什么样，接口应该怎么分，哪些功能其实是幻觉，哪些才是核心。
就像画家通过笔触来捕捉光影，我们通过代码来塑造结构。这种在实践中不断迭代、由直觉驱动并最终闭环的过程，就是我理解的 Vibe Coding。
也是草稿，也是成品
传统的软件工程在写代码之前被要求进行完好的设计，但后面又引入了 Agile（敏捷开发）这个循环持续更新的工作流。
在《黑客与画家》里，保罗·格雷厄姆提到了一个极具启发性的观点：油画之所以在 15 世纪引起轰动，是因为油彩这种媒介带来了一种全新的创作方式——它允许你“改变主意”。画家可以在画布上反复涂抹、覆盖、修正。
接受“不完美”的开端，这就是 Vibe Coding 的乐趣所在。
没有任何东西是一蹴而就的，没有什么东西是开始就完美的。我们不需要在第一天就设计出一个完美的架构。我们不需要过度的进行设计——我们的草图，应该是一个快速构建，能跑的，简陋的原型。
在这个过程中，代码既是草稿 ，帮助我们探索思路；也是成品 ，因为它每时每刻都能运行。
我们应该承认第一版代码往往是丑陋的。但正是通过不断的“再设计”和重构，移除多余的特性，找出可能的问题。
我们的持续更新，反馈，往往才是 Vibe Coding 创造的方式。
也是作者，也是读者
“程序必须写得能够供人们阅读，偶尔供计算机执行”
写代码时，我们也是作者，也是读者。这就是我所说的软实力之一：换位思考（Empathy）。
普通的代码只保证机器能跑通，而优秀的代码在保证能持续更新的同时，与观众达成共识。
你在代码中定义的每一个变量名、每一个函数名，本质上都是在与阅读者建立一种“共通的词义”。
如果你的命名模棱两可，模糊的词语，读者和你的沟通就会失败。
如果你的逻辑像一团乱麻，读者就不懂你真正的想法。
Vibe coding 要求我们在敲击键盘时，时刻保持对他人的关怀。
这种关怀不仅是对他人，还有对未来自己的怜悯——毕竟谁也不想三个月后看不懂自己写的屎山。
于是这种关怀最终产生了我们优雅、清晰且易于维护的代码。
透视骨架
既然我们不从语法细节讲起，那我们应该关注什么？我们关注骨架。
就像阅读一本好书时，我们不能迷失在细枝末节中，而要找出书的骨架。每一个优秀的软件项目，在那些花哨的界面和复杂的算法之下，都有一套支撑其存在的逻辑结构。
在这个系列中，我们将尽力回答关于代码的几个基本问题：
这到底是一个什么样的项目？是实用的工具，还是理论的探索？
你能用一句话说清楚这个程序是干什么的吗？
这些模块是如何组合在一起，服务于那个核心主旨的？
作为架构师，我们决定做什么（What）；
作为工程师，我们决定怎么做（How）；
作为我们，现在开始 （Do It Now）。
骨架（What）与血肉（How），构成了 Vibe Coding 的基石。
写在序的最后
阅读一本书，一篇文章，本质上是读者与作者之间的一场对话。
同样，写代码是你与机器、与未来的自己、与使用你软件的人之间的一场对话。
在这个系列里，我希望我们能跳过那些枯燥的说明书，直接拿起键盘。
我们可能会犯错，可能会写出丑陋的代码，但这没关系。
让我们现在开始 Vibe Coding 进行创造吧。
与君共勉
- 可以
- 一般
- 不行
