《写给编程小白看的 Vibe Debugging 注意事项（1） 》
我认为我有资格谈论这个问题：
我在 Githuh 已经有 2 个超过 100 星标的开源项目。
截止文章开始写的时候，一个 267，一个 105。考虑到 Github 上绝大部分项目不超过 10 个星标，我的成绩自然是在水平线之上。
除了这 2 个破百星标的项目之外，我还有好几个 50 个星标的项目，一些 20 个星标的项目。
自从我 Vibe Coding 到现在，我一共开发了 12 个项目。没有一个项目低于 10 个星标。其中 2 个项目起码经历了大规模重构（几乎完全重写）。
*为什么标题不是 Vibe Coding 而是 Vibe Debugging？*
如果从生物学分类来看，Bug 是克鲁苏——不可名状，永恒存在，令人恐惧。
小白 Vibe Coding 到最后往往变成 Vibe Debugging，拼命打印调试日志，然后塞给大模型，祈求它这把能过。
抑或，在 Vibe Coding 爽撸一把之后，祈祷这把不会有 Bug。然而克鲁苏就是克鲁苏，Bug 不会因为你的诚意感天动地，就自动消失。曾经有科学家开玩笑， Bug 是唯一违反物理定律的东西，因为即便太阳系毁灭了，Bug 也会继续存在。
所以，我们在谈论小白 Vibe Coding 的时候，也是在讲 Vibe Debugging——请所有小白在尝试 Vibe Coding 之前，一定要清醒的明白一件事，很多时候你不是在编程，你只是在制造你无法解决的 Bug。这是我非常痛的领悟。
*想要减少 Bug 的出现，必须懂点软件工程*
小白之所以无法控制 Bug 的产生，我觉得原因和会不会编程语言的关系不大。
就我潜伏在 V2EX（中文最大的程序员线上社区）里观察，即使懂得编程语言，同样闯祸，很多时候还是一口大锅，搞得身边的同事恨不得给这种惹事精做开颅手术，瞧瞧脑袋里装的是啥。
就我的 Vibe Coding 经验而言，真正令 Bug 减少的，是软件工程里的常识。也是让我觉得 Vibe Coding 时，不再害怕 Bug 出现的关键飞跃。
Vibe Coding 领域的流行理论，从单纯的 Prompting 到 Context Prompting 再到现在的 Spec Programming，在我看来是毫不回头地朝着软件工程化的方向狂奔。
所以，你还觉得不必了解一点软件工程吗？
*想懂点软件工程，必须先拥有「组件化思维」*
想知道 Bug 发生在哪里，为什么发生，固然是可以将日志直接塞给大模型——这是 Vibe Coding 的标准做法。
但，难免会碰上大模型怎么改都改不好的克鲁苏级 Bug 出现。排查 Bug 的流程，首先肯定是定位问题。
此时，拥有组件化思维的小白，会尚未拥有的小白，差距会十分明显。因为，前者通过脑子里清晰的结构，很快地定位到问题发生的那一段代码，以及它的相关因素。而后者，往往只能看到一个函数报错，但他只能重复地把错误日志塞给大模型。
克鲁苏级 Bug 无法马上消灭，往往就藏在这个「相关因素」里。缺乏组件化思维，脑子里就缺了一张地图，无法找出这些个「相关因素」，那么，更不要说排查 Bug 了。这整个过程就好像排雷，雷通常是藏起来的，如果想全排除，只能用扫雷车一个地面都不放过地筛，但是如果连埋雷的地方都不知道，就谈不上排雷这件事了。
现在，问题来了，如何拥有「组件化思维」呢？别急，往下看。
*想懂「组件化思维」，必须了解基础概念「抽象*」
我们通常接触到「抽象」这个词，往往和「抽象思维」这个词组密不可分。抽象思维，说的是迅速寻找事物的共性，总结特征。
在计算机领域里，「抽象」也类似的含义，因为组件往往是由普通的代码抽象而来的，而这个抽象的过程，往往是因为代码当中存在着大量的重复。这些重复的部分，可以抽象成公共组件，为其它组件提供服务。
还有另外一种抽象，是明确代码的边界，比如说，这几个函数是为同一个目的服务的，那么它们只需要面向这个目的进行设计即可。你可以认为，软件其实是一个流水线，这个流水线由不同的工序组成，从原材料放进传送带开始，一直到变成成品从传送带离开，每一道工序都负责加工上一道工序所传递过来的半成品——在软件里，工厂流水线里每一道独立工序都可以视为「组件」。
实际上，现在的 Spec Programming 也不过是进化到，将软件里的所有组件也说清楚给大模型听，然后让大模型生成代码。
换言之，如果你有能力在文档里描述不同的组件的作用，以及它们相互之间的关系，如何配合，那么你已经具备 Spec Programming 的能力。
在设计组件的时候，软件开发领域的「DRY 原则」显得尤为重要，它有点像麦肯锡金字塔原理的「不重不漏」原则。每个组件必然不是重复的，而要让它们有机地写作，那么又缺一不可。
*请期待下一篇*
这一篇我已经说清楚非常基本的概念，这些概念对于小白来说是不可或缺的，必须掌握的背景知识。在这里我十分推荐《软件设计的哲学》这本书，它不长，但更好覆盖了必须了解的常识。
我认为我有资格谈论这个问题：
我在 Githuh 已经有 2 个超过 100 星标的开源项目。
截止文章开始写的时候，一个 267，一个 105。考虑到 Github 上绝大部分项目不超过 10 个星标，我的成绩自然是在水平线之上。
除了这 2 个破百星标的项目之外，我还有好几个 50 个星标的项目，一些 20 个星标的项目。
自从我 Vibe Coding 到现在，我一共开发了 12 个项目。没有一个项目低于 10 个星标。其中 2 个项目起码经历了大规模重构（几乎完全重写）。
*为什么标题不是 Vibe Coding 而是 Vibe Debugging？*
如果从生物学分类来看，Bug 是克鲁苏——不可名状，永恒存在，令人恐惧。
小白 Vibe Coding 到最后往往变成 Vibe Debugging，拼命打印调试日志，然后塞给大模型，祈求它这把能过。
抑或，在 Vibe Coding 爽撸一把之后，祈祷这把不会有 Bug。然而克鲁苏就是克鲁苏，Bug 不会因为你的诚意感天动地，就自动消失。曾经有科学家开玩笑， Bug 是唯一违反物理定律的东西，因为即便太阳系毁灭了，Bug 也会继续存在。
所以，我们在谈论小白 Vibe Coding 的时候，也是在讲 Vibe Debugging——请所有小白在尝试 Vibe Coding 之前，一定要清醒的明白一件事，很多时候你不是在编程，你只是在制造你无法解决的 Bug。这是我非常痛的领悟。
*想要减少 Bug 的出现，必须懂点软件工程*
小白之所以无法控制 Bug 的产生，我觉得原因和会不会编程语言的关系不大。
就我潜伏在 V2EX（中文最大的程序员线上社区）里观察，即使懂得编程语言，同样闯祸，很多时候还是一口大锅，搞得身边的同事恨不得给这种惹事精做开颅手术，瞧瞧脑袋里装的是啥。
就我的 Vibe Coding 经验而言，真正令 Bug 减少的，是软件工程里的常识。也是让我觉得 Vibe Coding 时，不再害怕 Bug 出现的关键飞跃。
Vibe Coding 领域的流行理论，从单纯的 Prompting 到 Context Prompting 再到现在的 Spec Programming，在我看来是毫不回头地朝着软件工程化的方向狂奔。
所以，你还觉得不必了解一点软件工程吗？
*想懂点软件工程，必须先拥有「组件化思维」*
想知道 Bug 发生在哪里，为什么发生，固然是可以将日志直接塞给大模型——这是 Vibe Coding 的标准做法。
但，难免会碰上大模型怎么改都改不好的克鲁苏级 Bug 出现。排查 Bug 的流程，首先肯定是定位问题。
此时，拥有组件化思维的小白，会尚未拥有的小白，差距会十分明显。因为，前者通过脑子里清晰的结构，很快地定位到问题发生的那一段代码，以及它的相关因素。而后者，往往只能看到一个函数报错，但他只能重复地把错误日志塞给大模型。
克鲁苏级 Bug 无法马上消灭，往往就藏在这个「相关因素」里。缺乏组件化思维，脑子里就缺了一张地图，无法找出这些个「相关因素」，那么，更不要说排查 Bug 了。这整个过程就好像排雷，雷通常是藏起来的，如果想全排除，只能用扫雷车一个地面都不放过地筛，但是如果连埋雷的地方都不知道，就谈不上排雷这件事了。
现在，问题来了，如何拥有「组件化思维」呢？别急，往下看。
*想懂「组件化思维」，必须了解基础概念「抽象*」
我们通常接触到「抽象」这个词，往往和「抽象思维」这个词组密不可分。抽象思维，说的是迅速寻找事物的共性，总结特征。
在计算机领域里，「抽象」也类似的含义，因为组件往往是由普通的代码抽象而来的，而这个抽象的过程，往往是因为代码当中存在着大量的重复。这些重复的部分，可以抽象成公共组件，为其它组件提供服务。
还有另外一种抽象，是明确代码的边界，比如说，这几个函数是为同一个目的服务的，那么它们只需要面向这个目的进行设计即可。你可以认为，软件其实是一个流水线，这个流水线由不同的工序组成，从原材料放进传送带开始，一直到变成成品从传送带离开，每一道工序都负责加工上一道工序所传递过来的半成品——在软件里，工厂流水线里每一道独立工序都可以视为「组件」。
实际上，现在的 Spec Programming 也不过是进化到，将软件里的所有组件也说清楚给大模型听，然后让大模型生成代码。
换言之，如果你有能力在文档里描述不同的组件的作用，以及它们相互之间的关系，如何配合，那么你已经具备 Spec Programming 的能力。
在设计组件的时候，软件开发领域的「DRY 原则」显得尤为重要，它有点像麦肯锡金字塔原理的「不重不漏」原则。每个组件必然不是重复的，而要让它们有机地写作，那么又缺一不可。
*请期待下一篇*
这一篇我已经说清楚非常基本的概念，这些概念对于小白来说是不可或缺的，必须掌握的背景知识。在这里我十分推荐《软件设计的哲学》这本书，它不长，但更好覆盖了必须了解的常识。
