Demens Deum

如果您希望使用神经网络来帮助编写代码（所谓的 Vibe 编码），并且您有一台相当强大的计算机，例如配备 Nvidia RTX 显卡，那么您可以在您的计算机上完全免费地部署整个环境。这解决了付费订阅的问题，并允许您安全地处理 NDA 下的项目，因为您的代码不会发送到任何地方。在这篇文章中，我将描述如何组装 LM Studio、VS Code 和 Continue 扩展的本地包。

本地 Vibe 编码工具

为了舒适的工作，我们需要三个主要组件：
– LM ​​Studio： 一个用于下载和运行本地 LLM 的便捷应用程序。它承担了使用 GGUF 模型的所有复杂性，并建立了一个与 OpenAI API 兼容的本地服务器。
– VS Code： 流行且熟悉的代码编辑器。
– 继续： VS Code 扩展，将神经网络直接集成到工作环境中。允许您聊天、突出显示代码以进行重构，并支持自动完成。

硬件要求

本地语言模型是内存密集型的：
– 显卡 (GPU)： Nvidia，配备 8 GB VRAM 或更高（可轻松处理具有 7-80 亿个参数的模型）。较重的型号将需要 16 GB 的 VRAM。
– 磁盘空间：约500 GB用于存储各种下载的模型。

配置链接

设置过程非常简单，不需要在终端中进行复杂的操作：
1.下载并安装LM Studio。使用内置搜索查找轻量级模型，例如 Qwen Coder 或 gemma3:12b。
2. 在 LM Studio 中，转到“本地服务器”选项卡并单击“启动服务器”。默认情况下，它将从“http://localhost:1234/v1”启动。
3. 打开 VS Code 并从插件商店安装 Continue 扩展。
4. 打开“继续”配置文件并添加新模型，指定“openai”提供程序以及 LM Studio 中的本地服务器地址。

然后，您可以直接在“继续”侧栏中与当地的法学硕士进行交流，询问有关您的代码的问题，并生成新的组件。

为什么会这样？

正如我之前所写，法学硕士在扁平结构和 WET（将所有内容写入两次）代码方面做得更好。在设计复杂的架构时，局部参数模型可能不如 GPT-4 这样的巨头，但它们完全能够生成样板代码、重构简单功能和快速原型设计。

此外，通过本地 Vibe 编码，您的代码永远不会离开机器。这使得这种组合非常适合企业发展和处理敏感数据。

输出

局部神经网络无法完全取代程序员或设计复杂的系统。然而，LM Studio + VS Code +Continue 的组合提供了独立于云服务的能力并维护了隐私。如果您愿意忍受小模型的限制并独立控制项目架构，那么这是一个用于日常任务的完全可用的辅助工具。

链接

https://code.visualstudio.com/
https://lmstudio.ai/
https://continue.dev/

来源

https://youtu.be/IqqCwhG46jY
https://www.youtube.com/watch?v=7AImkA96mE8

在 Docker 中运行 macOS 是可能的，尽管有人反对说这是不可能的，而且据说 macOS 有某种保护系统可以抵抗这种情况。

历史上，在 PC 机上运行 macOS 的一些经典方法是：
*黑客塔
* 虚拟化，例如使用VMWare

Hackintosh 假设存在与原始 Mac 相似或非常接近的硬件。虚拟化对硬件有一定的要求，但通常不像 Hackintosh 那样严格。然而，在虚拟化的情况下，存在性能问题，因为 macOS 并未针对在虚拟环境中工作进行优化。

最近，在 Docker 中运行 macOS 已经成为可能。这是通过 Docker-OSX 项目实现的，该项目提供现成的 macOS 映像以在 Docker 上运行。值得注意的是，Docker-OSX 不是苹果官方项目，不受其支持。但是，它允许您在 Docker 上运行 macOS 并使用它来开发和测试应用程序。

首批在 Docker 中运行 macOS 的项目之一：
https://github.com/sickcodes/Docker-OSX

然而，我始终无法完全启动它；加载到 Recovery OS 后，我的键盘和鼠标直接掉落，无法继续安装。同时，在第一个启动菜单中，键盘起作用。也许事实是这个项目不再受到如此积极的支持，并且在 Windows 11 + WSL2 + Ubuntu 上运行时存在一些特定问题。

目前最活跃的项目之一：
https://github.com/dockur/macos

允许您在 Docker 中运行 macOS，界面通过 VNC(?) 转发通过浏览器工作。启动后，macOS 可访问 http://localhost:5900

我设法运行这个项目并在 Windows 11 + WSL2 + Ubuntu 上安装 macOS Big Sur（2020 分钟），但只能通过更改 compose 文件来实现，即：

environment:
    VERSION: "11"
    RAM_SIZE: "8G"
    CPU_CORES: "4"

版本：“11”是 macOS 的版本，在本例中为 Big Sur
RAM_SIZE：“8G”是为 macOS 分配的 RAM 量
CPU_CORES：“4”是分配给macOS的CPU核心数

目前，运行 macOS tahoe (16) 也是可能的，但项目开发人员正在努力解决许多问题。

这种启动 macOS 的原始方式允许您在非 Mac 硬件上尝试它，并在受够了痛苦后，再给自己买一台 Mac。但是，它对于在旧系统上测试软件和一般开发很有用。

Swift 生态系统正在 Apple 平台之外积极开发，如今在 Windows 下使用 Windows Subsystem for Linux (WSL2) 进行编写已经相当方便。值得考虑的是，对于 Linux/WSL 下的程序集，可以使用 Swift 的轻量级版本 – 无需专有的 Apple 框架（例如 SwiftUI、UIKit、AppKit、CoreData、CoreML、ARKit、SpriteKit 和其他 iOS/macOS 特定的库），但对于控制台实用程序和后端来说，这已经足够了。在这篇文章中，我们将逐步介绍准备环境并从 WSL2 中的源代码构建 Swift 编译器的过程（以 Ubuntu/Debian 为例）。

我们更新软件包列表和系统本身：

sudo apt update && sudo apt upgrade -y

安装构建所需的依赖项：

sudo apt install -y \
  git cmake ninja-build clang python3 python3-pip \
  libicu-dev libxml2-dev libcurl4-openssl-dev \
  libedit-dev libsqlite3-dev swig libncurses5-dev \
  pkg-config tzdata rsync

安装编译器和链接器（LLVM 和 LLD）：

sudo apt install -y llvm lld

克隆包含所有依赖项的 Swift 存储库：

git clone https://github.com/apple/swift.git
cd swift
utils/update-checkout --clone

用 swiftc 安装 `swiftly` 和现成的 swift

curl -O https://download.swift.org/swiftly/linux/swiftly-$(uname -m).tar.gz && \
tar zxf swiftly-$(uname -m).tar.gz && \
./swiftly init --quiet-shell-followup && \
. "${SWIFTLY_HOME_DIR:-$HOME/.local/share/swiftly}/env.sh" && \
hash -r

让我们开始构建（这将需要很长时间）：

utils/build-script \
  --release-debuginfo \
  --swift-darwin-supported-archs="x86_64" \
  --llvm-targets-to-build="X86" \
  --skip-build-benchmarks \
  --skip-test-cmark \
  --skip-test-swift \
  --skip-ios \
  --skip-tvos \
  --skip-watchos \
  --skip-build-libdispatch=false \
  --skip-build-cmark=false \
  --skip-build-foundation \
  --skip-build-lldb \
  --skip-build-xctest \
  --skip-test-swift

构建完成后，将编译器的路径添加到PATH（指定构建文件夹的路径）：

export PATH=/root/Sources/3rdparty/build/Ninja-RelWithDebInfoAssert/swift-linux-x86_64/bin/swiftc:$PATH

我们检查已安装的 Swift 版本是否正常工作：

swift --version

创建一个测试文件并运行它：

echo "print(\"Hello, World!\")" > hello.swift
swift hello.swift

您还可以编译二进制文件并运行它：

swiftc hello.swift
./hello

来源

• Windows 上的 Swift 入门
• Swiftly（版本控制工具）
• 从源代码构建 Swift

在上一篇文章中，我们研究了解释器模式的理论，了解了 AST 树是什么以及如何抽象终结符和非终结符表达式。这次，让我们抛开理论，看看如何将这种模式应用到我们每天都在使用的严肃商业项目中！

剧透：您现在可能正在使用解释器模式，只需在浏览器中阅读此文本即可！

业界使用此模式的最引人注目、也许也是最重要的示例之一是 JavaScript。这种语言最初是“在膝盖上”创建的，如今，由于解释的概念，它可以在数十亿台设备上运行。

改变互联网的 10 天

JavaScript 的历史充满了传奇。 1995 年，Brendan Eich 在 Netscape Communications 工作时，接到的任务是创建一种可以直接在浏览器 (Netscape Navigator) 中运行的简单脚本语言，以使网页具有交互性。管理层想要一种类似于当时超级流行的 Java 语法的东西，但不是针对专业工程师，而是针对网页设计师。

Eich 仅用了10 天来编写该语言的第一个原型，该语言当时被称为 Mocha（然后是 LiveScript，出于营销原因才称为 JavaScript）。这种热潮并非偶然：微软紧随其后，同时也在积极准备自己的脚本语言 VBScript，以便嵌入 Internet Explorer 浏览器中。 Netscape 迫切需要发布回应，以免在迫在眉睫的浏览器战争中落败。

根本没有时间将复杂的编译器编写成机器代码。对于 Eich 来说，显而易见且最快的解决方案是经典解释器的架构。

第一个解释器（SpiderMonkey）的工作方式如下：

1. 它从页面读取脚本的文本源代码。
2. 词法分析器将文本分解为标记。
3. 解析器构建了一个抽象语法树（AST）。就解释器模式而言，这棵树由终端表达式（字符串，数字如42）和非终端（函数调用，语句如If、While）组成。
4. 然后虚拟机一步步“遍历”这棵树，在每个节点执行嵌入其中的指令（调用类似于 Interpret() 的方法）。

上下文和对象

还记得在经典实现中我们必须传递给 Interpret(Context context) 方法的 Context 对象吗？解释器需要它来存储当前的内存状态。

就 JavaScript 而言，顶层上下文的角色由全局对象（例如浏览器中的窗口）扮演。例如，当您的 AST 节点尝试通过 document.write(“Hello”) 将文本写入屏幕时，解释器会访问其上下文（文档对象）并调用所需的内部浏览器 API。

多亏了解释器，JavaScript 才能够如此轻松地与 DOM（文档对象模型）进行交互 – 这些都只是上下文中可由树节点访问的对象。

解释器的演变：JIT 编译

从历史上看，浏览器中的 JS 长期以来一直是“纯粹”的解释器。而这有一个很大的缺点——速度慢。每次执行脚本时解析树并缓慢遍历每个节点会减慢复杂的 Web 应用程序的速度。

随着 2008 年 Google V8 引擎（内置于 Chrome 中）的出现，一场革命发生了。工程师们意识到，对于现代网络来说，一个解释器是不够的。引擎变得更加复杂：它仍然构建 AST 树，但现在使用 JIT（即时）编译。

现代 JS 引擎（V8、SpiderMonkey）的工作方式就像一个复杂的管道：

1. 快速而愚蠢的基本解释器立即开始执行您的 JS 代码，甚至无需等待它编译（经典模式在这里仍然有效）。
2. 同时，引擎会监控代码的“热门”部分（被调用数千次的循环或函数）。
3. 这些部分由 JIT 编译器直接编译为优化的机器代码，绕过缓慢的解释器。

正是解释器的即时启动和编译的计算能力的结合让 JavaScript 占领了世界，成为服务器 (Node.js) 和移动应用程序 (React Native) 的语言。

游戏行业的翻译

尽管 C++ 在重型计算领域占据主导地位，但解释器模式仍然是游戏开发中用于创建游戏逻辑的行业标准。为了什么？这样游戏设计师就可以制作游戏，而无需“放弃”引擎或需要不断重新编译引擎的风险。

一个很好的历史例子是UnrealScript – 虚幻竞技场和战争机器游戏的逻辑是在虚幻引擎1、2和3中编写的语言。文本被编译成紧凑的抽象机器字节码，然后由引擎的虚拟机逐步（解释）。

可视化图形脚本（蓝图）

如今，文本已被可视化编程所取代 – 虚幻引擎 4 和 5 中的蓝图系统。

如果您曾经在虚幻引擎中打开过蓝图，您就会看到很多通过电线连接的节点。从架构上来说，整个蓝图图是绘制在屏幕上的巨大抽象语法树 (AST)：

1. 终端表达式：常量节点。例如，仅存储数字 42 或字符串的节点。它们在解释时返回特定值。
2. 非终止表达式：计算节点（添加）或流控制节点（分支）。它们具有参数输入，解释器首先对其进行递归计算，然后将结果作为输出引脚生成。

而上下文在这里的作用是由特定游戏对象（Actor）实例的记忆来扮演的。解释器机器安全地“行走”通过该图，请求数据并执行转换。

解释器还用在什么地方？

解释器模式几乎可以在任何需要执行动态指令的复杂系统中找到。以下只是商业软件中的一些示例：

• 解释型编程语言（Python、Ruby、PHP）。它们的整个运行时基于经典模式。例如，CPython 参考实现首先将您的 .py 脚本解析为 AST，将其编译为字节码，然后一个巨大的虚拟机（计算循环）逐步解释该字节码。
• Java 虚拟机 (JVM)。 最初，Java 代码不是编译成机器指令，而是编译成字节码。当您运行应用程序时，JVM 充当解释器（尽管使用积极的 JIT 编译，就像在 V8 中一样）。
• 数据库和 SQL 当您在 PostgreSQL 或 MySQL 中发出 SQL 查询（SELECT * FROM users）时，数据库引擎充当解释器。它执行词法分析，构建 AST 查询树，生成执行计划，然后通过迭代表的行来逐字“解释”该计划。
• 正则表达式 (RegEx)。任何正则表达式引擎都会在内部将字符串模式（例如 ^\d{3}-\d{2}$）解析为状态图 (NFA/DFA 自动机)，然后内部解释器会通过该状态图，将每个输入字符与该图的顶点进行匹配。
• Unity Shader Graph / 虚幻材质编辑器 – 将视觉节点解释为模块化着色器代码 (GLSL/HLSL)。
• Blender 几何节点 – 解释数学和几何运算以按程序实时生成 3D 模型。

总计

解释器模式早已超出了“编写自己的计算器”的范围。这是最有力的行业标准。从每天在浏览器幕后执行数十亿字节代码的 JavaScript 引擎，到无需 C++ 知识即可构建复杂逻辑的游戏设计者，解释器仍然是现代 IT 开发中最重要的架构概念之一。