Vibe Coding 不是让 AI 替你理解细节
用 Python、Notebook 和 VS Code + CLI，把 AI 生成的方向跑成自己理解的细节。
借助 AI，现在要快速实现一个场景、验证一个方案，门槛确实低了很多。
过去进入一个陌生领域，尤其是一个比较复杂的技术场景，一般要先收集资料，再拆技术点，然后一边查文档一边写代码验证。中间任何一个细节卡住，都可能耗掉不少时间。
有了 AI 以后，这个过程被明显压缩了。很多资料整理、样例代码、环境说明、错误排查，AI 都可以很快给出一个可运行的方向。
但这里也有一个问题：AI 把时间压缩了，也把很多细节藏起来了。
如果只是一个简单功能，细节掌握得没那么深，问题不大。可一旦进入复杂场景，尤其是跨多种技术栈、跨多个系统边界的产品设计，如果自己没有亲自介入其中，不知道关键技术点在哪里，不知道方案的边界在哪里，后面推进时就很难把握方向。
最后很容易出现一种情况：Demo 看起来能跑，但真正往产品里放的时候，到处都是夹生的地方。
所以我现在做 Vibe Coding 时，会刻意给自己加一个环节：不要只让 AI 直接生成最终代码，而是先用 Python + Jupyter Notebook，把核心设计和关键细节跑一遍。
为什么是 Notebook
这里的重点不是 Python，也不是 Notebook 本身有多高级。
Python 只是一个适合快速验证思路的语言。它写起来快，生态全，很多技术点可以用很少的代码跑出结果。最终项目是不是用 Python 落地并不重要，Java、Go、Node、Rust 都可以。Python 在这里的角色更像是验证工具，不是最终架构选择。
Jupyter Notebook 的价值在于，它把说明、代码、执行结果放在一起。
这点很适合用来处理 AI 时代的学习和验证问题。你可以让 AI 按照你的目标，把一个技术方案拆成几个步骤：
- 先解释场景和目标。
- 再给出最小可运行代码。
- 然后展示运行结果。
- 最后补充边界条件和下一步验证点。
这样你不是在看一大段“看起来很对”的回答，而是在一格一格地跑。哪里跑不通，哪里结果不符合预期，就让 AI 继续调整。这个过程会逼着你把问题拆开，也会逼着 AI 回到具体细节里。
我觉得这比直接生成一套代码更靠谱。
直接生成代码时，很多东西是混在一起的。你可能不知道某个参数为什么这么设置，也不知道某个依赖到底解决了什么问题。Notebook 则会把这些东西摊开，让你看到每一步的输入、处理和输出。
它解决的不是“能不能让 AI 写出来”，而是“我有没有真的理解这个方案”。
它适合放在设计前期
在一个新方向刚开始的时候，我会把 Notebook 当成设计前期的演练场。
比如一个方案里有数据处理、协议解析、模型调用、缓存策略、权限控制、部署方式等多个部分，不需要一上来就搭一个完整工程。先把最不确定、最容易影响后续判断的部分拆出来，用 Notebook 跑一遍。
这个过程有几个好处。
第一，可以快速判断方案是不是可行。
很多想法在脑子里是通的，在文档里也是通的，但真正跑起来之后，会发现性能、数据格式、异常处理、依赖限制都不一样。早一点跑出来，就能早一点发现问题。
第二，可以把技术细节变成可复用的学习材料。
Notebook 不是一次性草稿。它可以沉淀成一个入门指引。后面有人加入项目，或者自己隔一段时间再回来看，不用重新翻聊天记录，也不用重新问 AI 一遍。
第三，可以让 AI 的能力用在更合适的位置。
AI 很擅长整理、拆解、生成样例、解释报错、补充边界条件。它不一定适合替你做最终判断。用 Notebook 的方式，等于把 AI 放在“陪你演练”的位置上，而不是直接交给它一个模糊任务，让它输出一坨结果。
这也是我现在对 Vibe Coding 的一个基本判断：AI 可以极大提升效率，但关键判断不能外包。
下面这张图就是一个很典型的例子。
当我想理解一个多 Agent 框架时，我不会只让 AI 解释概念，也不会一上来就让它生成完整项目。我会先让它把核心机制拆成 Notebook：前面用文字讲清楚角色分工，后面紧跟最小代码和运行结果。这样一边看，一边跑，一边改，很多抽象概念就会变成具体的执行过程。
这也是为什么我会把 Notebook 放在设计前期。它不负责把产品做完，而是先帮我确认：这个方向到底怎么工作，关键点在哪里，哪些地方需要后面重点验证。
VS Code 是我的工作台
除了 Notebook，我现在最常用的组合是 VS Code + Claude / Codex CLI。
VS Code 对我来说主要有几个好处。
一是浏览项目方便。文件结构、代码、文档、终端都在一起，不需要在多个窗口之间来回切。
二是终端好用。我经常会在 VS Code 里开多个 terminal，有时候同时跑 Claude 和 Codex。一个负责读项目、整理上下文，一个负责改文件或者跑命令。这样可以根据任务自由组合，不需要把所有事情都塞给一个工具。
三是跨环境比较稳定。我平时 Windows、Mac、Linux 都会用到，VS Code 能很大程度上保证工作方式一致。到了 Linux 机器上，一般直接用 Remote，连 SSH 的很多细节都省了。
这套组合没有什么神秘的地方，它的价值在于顺手。
Vibe Coding 不是坐在那里等 AI 把东西变出来。实际工作里，你还是要读文件、跑命令、看日志、改提示、拆任务、验证结果。工具越顺手，你越容易把注意力放在判断上，而不是被环境切换消耗掉。
对学生来说，轻设备加云主机更现实
如果是大学生，或者平时经常在图书馆、实验室、教室之间切换，我反而不建议一开始就追求很重的本地设备。
一个轻便笔记本，加上按量付费的云主机，可能更适合。
轻薄本的好处很直接：省电、轻、携带方便。很多轻薄本现在也能用高功率手机充电器，外出学习时压力小很多。日常写文档、看资料、连远程环境，基本够用。
真正重的工作，可以交给云主机。比如阿里无影这类云电脑，按量付费，用多少算多少。需要 Windows 就开 Windows，需要 Linux 就开 Linux。对工科学生来说，这也是一个快速熟悉 Linux 环境的方式。
本地设备负责输入和交互，云端负责算力和环境。这个分工比硬扛一台又贵又重的机器更灵活。
当然，这不是说所有人都应该这么选。如果你已经有稳定的高性能设备，也完全可以继续用。关键不是设备本身，而是要让环境服务于学习和验证，不要反过来被环境拖住。
关键还是把主动权拿回来
AI 出现以后，很多人会自然地把注意力放在“它能不能帮我写得更快”。
这当然重要，但我觉得更关键的问题是：它写得越快，我越要有办法确认自己真的懂了。
Notebook 是一个办法。它让方案从一段回答变成一组可执行的步骤。VS Code + CLI 是另一个办法。它让 AI 能够进入真实项目，但你仍然可以随时看文件、跑命令、检查结果。
Vibe Coding 最怕的不是 AI 写错，而是人不知道它错在哪里。
所以我的做法很简单：让 AI 多干整理、生成、解释、试错这些事情；但关键设计、边界判断、技术取舍，自己一定要介入。
效率可以交给 AI 放大，理解不能交给 AI 代替。