当前位置： 首页 > news >正文

为AI Agent打造精简NixOS网关：OpenClaw部署优化实战

news 2026/5/13 19:06:00

1. 项目概述：为AI Agent打造的精简NixOS网关

如果你正在NixOS上部署AI Agent，并且对官方OpenClaw仓库里那套动辄上万行、夹杂着桌面环境、macOS支持甚至Windows二进制文件的庞大构建感到头疼，那么openclaw-nixos这个项目可能就是为你量身定做的。我最近在为一套自主运行的Agent虚拟机集群寻找一个稳定、可复现的网关方案时，发现了这个由社区维护的精简发行版。它的核心目标非常明确：只做一件事，并且做到极致——提供一个纯粹的、面向服务器的OpenClaw网关NixOS模块，剥离所有与核心功能无关的“脂肪”。

简单来说，OpenClaw本身是一个功能强大的AI Agent网关，可以理解为AI应用的“路由器”或“调度中心”。但它的官方Nix构建（nix-openclaw）为了追求通用性，打包了海量的依赖，包括用于图形界面、跨平台开发的工具链，导致最终的Nix包体积臃肿，构建时间漫长，并且引入了不必要的安全暴露面。openclaw-nixos项目正是为了解决这个问题而生。它通过一系列定制化的“瘦身”手术，将构建复杂度降低了几个数量级，最终产出一个只包含Linux x86_64运行时必需组件的“纯净”版本。这对于追求部署效率、系统确定性和安全性的运维人员或开发者来说，无疑是一个福音。接下来，我将详细拆解这个项目的设计思路、具体实现方法，并分享在集成和使用过程中的一些实战经验与避坑指南。

2. 核心设计思路与架构解析

2.1 为何需要“瘦身”？从通用构建到专用部署的转变

在深入代码之前，理解“为什么”要这么做至关重要。OpenClaw作为一个活跃的AI项目，其依赖树非常庞大。标准的Nix构建流程会拉取整个pnpm锁文件（pnpm-lock.yaml）中定义的所有依赖，这通常包括：

  1. 开发依赖：如TypeScript编译器、代码检查工具、测试框架等，这些在生产运行时完全不需要。
  2. 平台特定二进制文件：许多NPM包会为Windows（.exe,.dll）、macOS（.dylib）甚至Android提供预编译的二进制文件。在纯Linux服务器上，这些文件不仅无用，还会占用宝贵的Nix存储空间，并可能因为文件哈希验证而增加构建失败的风险。
  3. 桌面环境相关模块：一些底层依赖可能关联到图形库（如electron的某些组件、node-gyp为GUI编译的本地模块），这些在无头服务器环境中纯属冗余。

openclaw-nixos的核心理念是面向部署而非开发。它假设用户的使用场景是在NixOS上运行一个服务，而不是在此环境上开发OpenClaw本身。因此，它大胆地移除了原构建中约18,000行与桌面和跨平台相关的配置代码。这种“减法”思维带来了几个直接好处：

  • 构建速度显著提升：需要下载和编译的包数量大幅减少。
  • 存储占用降低：生成的Nix包更小，部署到多台机器时能节省带宽和磁盘空间。
  • 安全性增强：更少的代码意味着更小的攻击面，去除了不必要的二进制文件也减少了潜在的安全风险。
  • 确定性更强：构建过程更加纯粹，只针对x86_64-linux，减少了因平台差异导致的不可预测问题。

2.2 架构拆解：三层精简策略

项目的精简并非粗暴删除，而是有一套清晰的策略，主要体现在三个层面：

2.2.1 构建流程定制（Flake层面）项目的flake.nix是入口。它没有直接引用庞大的nix-openclaw，而是基于上游的OpenClaw源码仓库，定义了一套自己的构建流水线。这个流水线核心是调用了项目内一个自定义的build.nix。这个文件的作用是接管从源码到成品的全过程，它明确指定了构建目标仅为x86_64-linux，并传递了一系列优化参数给底层的构建工具（如node2nix或pnpm2nix的变种），告诉它们：“我们只要运行时的、Linux的依赖”。

2.2.2 依赖锁文件手术（Lockfile Pruning）这是该项目最精妙的一环。它包含一个名为lockfile-pruner的工具或脚本。这个工具的工作流程如下：

  1. 读取原始锁文件：获取上游OpenClaw的pnpm-lock.yaml。
  2. 依赖关系分析：遍历锁文件中的每一个包条目，分析其声明的平台（os，cpu）要求以及它是否被标记为devDependencies。
  3. 精准剔除：将所有标记为devDependencies的包，以及所有非linux平台（如win32，darwin）的包条目从锁文件中移除。根据文档，这一下能去掉大约200个平台特定的二进制包。
  4. 生成精简锁文件：输出一个新的、干净的pnpm-lock.yaml，这个文件只包含生产环境在Linux上运行所必需的依赖。
  5. 完整性验证：在剔除后，脚本或后续构建步骤会确保剩下的依赖关系图仍然是完整且可解析的，避免因删除某个看似无关的包而导致运行时缺失模块。

这个步骤在Nix的“输入锁定”阶段之前完成，确保了从源头（锁文件）上就是精简的，而不是在构建过程中再去忽略某些依赖。

2.2.3 NixOS模块优化（Module Design）项目的nixosModules/default.nix提供了一个高度优化的NixOS服务模块。它的设计哲学是“开箱即用”和“安全默认值”。

  • 去繁就简：它不包含任何与home-manager（为用户环境配置的工具）集成的部分，因为服务器服务不需要用户桌面配置。
  • 强化安全：模块默认启用了多项安全强化设置。例如，它可能会为OpenClaw服务配置DynamicUser（动态用户）、PrivateTmp（私有临时目录）、ProtectSystem（保护系统目录）等systemd指令，遵循最小权限原则。
  • 灵活的配置注入：它提供了config（Nix属性集）和configFile（外部JSON文件）两种配置方式，并支持合并，优雅地解决了Nix中管理密钥等敏感信息的难题。
  • 状态管理：明确了服务的数据目录（如/var/lib/openclaw），并确保服务重启后状态得以保持，这基于真实线上部署的经验。

3. 实战部署：从零集成到服务上线

理解了原理，我们来动手把它跑起来。假设你已有一个基础的NixOS系统（物理机或虚拟机）。

3.1 环境准备与Flake集成

首先，你需要一个启用了Flakes的NixOS配置。如果你的/etc/nixos/configuration.nix是传统格式，建议先迁移。这里假设你使用Flakes。

在你的系统配置的Flake（通常是/etc/nixos/flake.nix）中，添加openclaw-nixos作为输入。

{ # 你的flake输入部分 inputs = { # 你的nixpkgs引用，这里以稳定版23.11为例 nixpkgs.url = "github:NixOS/nixpkgs/nixos-23.11"; # 添加 openclaw-nixos 输入 openclaw-nixos.url = "github:noblepayne/openclaw-nixos"; # 可选：锁定到特定提交，确保部署一致性 # openclaw-nixos.url = "github:noblepayne/openclaw-nixos/a1b2c3d"; }; # 输出部分，定义你的NixOS配置 outputs = { self, nixpkgs, openclaw-nixos, ... }: { # 定义一个名为 my-server 的NixOS配置 nixosConfigurations.my-server = nixpkgs.lib.nixosSystem { system = "x86_64-linux"; # 必须指定此架构 modules = [ # 导入你的基础系统模块 ./configuration.nix # 导入 openclaw-nixos 提供的模块 openclaw-nixos.nixosModules.default # 在此处或你的 ./configuration.nix 中启用并配置服务 { services.openclaw = { enable = true; # 服务监听端口，确保不与现有服务冲突 port = 3000; # 可选：自动打开防火墙端口 openFirewall = true; # 关键：服务配置。这里用Nix属性集定义非敏感配置 config = { # 示例：配置CORS，允许你的控制面板访问 gateway.cors.origins = [ "https://my-agent-dashboard.internal" ]; # 示例：启用记忆功能 memory.enabled = true; # 你可以在这里定义LLM供应商、模型等非敏感配置 # llm.provider = "openai"; # llm.model = "gpt-4"; }; # 强烈建议：敏感配置（API密钥）通过外部文件引入 # configFile = "/etc/openclaw/secrets.json"; }; } ]; }; }; }

注意：将openFirewall = true;视为一个快速开发选项。在生产环境中，更推荐在专门的防火墙配置模块（如networking.firewall）中精确控制端口规则，而不是让每个服务模块自动操作。

3.2 敏感信息管理：安全第一的配置哲学

这是部署中最容易出错的一环。绝对不要将API密钥、数据库密码等敏感信息直接写在Nix配置里！因为Nix会将所有输入（包括你的配置）存储在/nix/store中，这些文件默认是全局可读的。

openclaw-nixos模块提供了两种安全的方式来处理秘密：

方案一：使用configFile指向外部JSON文件（推荐）这是最清晰、最安全的方式。你将所有配置（包括敏感信息）写在一个标准的OpenClaw JSON配置文件中，并将该文件放在Nix存储之外的安全位置。

  1. 创建秘密目录和文件：

    sudo mkdir -p /etc/openclaw sudo touch /etc/openclaw/config.json sudo chmod 600 /etc/openclaw/config.json # 限制权限 sudo chown openclaw:openclaw /etc/openclaw/config.json # 所有权给服务用户（如果动态用户，可能不需要）

  2. 编辑配置文件(/etc/openclaw/config.json)：

    { "gateway": { "cors": { "origins": ["https://my-dashboard.example.com"] } }, "memory": { "enabled": true }, "llm": { "provider": "openai", "apiKey": "sk-your-actual-openai-api-key-here", // 敏感信息在此 "model": "gpt-4-turbo" }, "database": { "url": "postgresql://user:password@localhost/openclaw" // 敏感信息在此 } }

  3. 在Nix配置中引用：

    services.openclaw = { enable = true; port = 3000; configFile = "/etc/openclaw/config.json"; # 关键行 # config 属性可以留空，或者只放一些不敏感的重写配置 };

方案二：使用EnvironmentFile配合环境变量OpenClaw通常支持通过环境变量覆盖配置。NixOS的systemd服务模块可以方便地加载环境文件。

  1. 创建环境文件：

    sudo mkdir -p /etc/openclaw echo "OPENAI_API_KEY=sk-your-key" | sudo tee -a /etc/openclaw/secrets.env echo "DATABASE_URL=postgresql://user:pass@localhost/db" | sudo tee -a /etc/openclaw/secrets.env sudo chmod 600 /etc/openclaw/secrets.env

  2. 在Nix配置中扩展服务定义（这需要稍微深入了解模块选项）：

    services.openclaw = { enable = true; port = 3000; config = { /* 你的非敏感配置 */ }; # 通过覆写 systemd service 配置来添加环境文件 serviceOverrides = { Service = { EnvironmentFile = "/etc/openclaw/secrets.env"; }; }; };

    你需要查阅openclaw-nixos模块的具体选项，看是否直接提供了environmentFile选项，或者像上面一样通过serviceOverrides传递。这种方式将秘密管理与应用配置解耦。

方案三：混合模式（Nix配置 + 外部秘密文件）模块支持合并config和configFile。你可以将静态的、非敏感的结构化配置写在Nix里，而将敏感值放在外部JSON文件中，并在外部文件中只定义需要覆盖的字段。

  • Nix配置 (config)：定义gateway，memory等结构。
  • 外部JSON (configFile)：只包含{ "llm": { "apiKey": "sk-xxx" } }。 模块启动时会深度合并两者，外部文件的优先级更高。这既保持了Nix配置的可声明性和版本控制优势，又保证了秘密的安全。

3.3 构建与切换系统配置

完成配置后，进入你存放flake.nix的目录（例如/etc/nixos），执行以下命令来构建并切换到新配置：

# 切换到root用户或使用sudo sudo su # 进入配置目录 cd /etc/nixos # 使用 nixos-rebuild 构建并切换。'my-server' 对应你 flake.nix 中定义的 nixosConfigurations 的名称。 nixos-rebuild switch --flake .#my-server # 或者，如果你想先测试构建而不实际切换（干跑） nixos-rebuild build --flake .#my-server # 构建结果会显示一个路径，你可以手动切换过去测试

如果一切顺利，OpenClaw服务应该已经以systemd服务（openclaw.service）的形式运行起来了。你可以检查其状态：

systemctl status openclaw.service # 查看日志 journalctl -u openclaw.service -f

服务默认会监听在你配置的端口（如3000）。你可以用curl或浏览器访问http://localhost:3000（如果配置了健康检查端点）来验证服务是否正常运行。

4. 高级技巧与深度定制

4.1 理解并更新上游依赖

openclaw-nixos项目通过一个“pin”（钉住）的机制来锁定它所依赖的原始OpenClaw源码版本。这通常记录在项目根目录的flake.lock文件或一个专门的pin.json文件中。

当你想升级OpenClaw版本时，不能简单地修改Nix输入，因为还需要重新生成精简后的锁文件。项目提供了脚本./scripts/update-pin.sh（在项目仓库内）来自动化这个过程。其内部逻辑大致是：

  1. 更新指向openclaw/openclaw仓库的提交哈希（SHA）。
  2. 拉取新版本对应的完整pnpm-lock.yaml。
  3. 运行自定义的锁文件修剪器（lockfile-pruner），生成新的、适用于Linux的精简锁文件。
  4. 更新本地的Nix表达式以引用新的源码和锁文件。

实操建议：如果你在自己的Flake中直接引用了github:noblepayne/openclaw-nixos，那么你依赖的是该项目发布的最新状态。如果你想严格控制版本，最好将其Fork到自己的Git仓库，然后在自己的仓库中执行更新脚本，最后在你的Flake中指向你自己仓库的特定提交。这为你提供了完整的版本控制权。

4.2 自定义构建参数与优化

你可能需要根据服务器资源调整构建过程。openclaw-nixos的构建逻辑封装在其内部的build.nix中。虽然作为使用者你通常不需要直接修改它，但了解其关键参数有助于排查问题。

通过Nixpkgs的覆盖（overlays）机制，你可以传递参数给构建过程。例如，如果你想在构建时使用本地的Node.js镜像源以加速下载，或者调整某些构建标志，可以在你的系统配置中尝试如下覆盖（具体参数需参考项目实际导出）：

{ nixpkgs.overlays = [ (final: prev: { # 假设 openclaw-nixos 包被命名为 openclaw-gateway openclaw-gateway = prev.openclaw-gateway.override { # 这里可以传递构建函数接受的参数 # 例如，设置网络超时或使用自定义的node2nix buildInputs = [ final.nodejs_20 ]; # 注意：这只是一个示例，实际参数名需查看项目源码 }; }) ]; }

更常见的定制是调整运行时的环境变量。除了之前提到的EnvironmentFile，你还可以直接在Nix配置中设置：

services.openclaw = { enable = true; # ... environment = { NODE_ENV = "production"; LOG_LEVEL = "info"; # 可以在这里设置一些不敏感的环境变量 }; };

4.3 集成到现有服务网格与监控

一个生产级的AI网关 rarely stands alone。你需要考虑如何将它融入现有的基础设施。

服务发现与负载均衡：如果部署多个OpenClaw实例，你需要在前端配置负载均衡器（如Nginx, Traefik, Caddy）。在NixOS中，你可以轻松地声明式配置Nginx作为反向代理：

services.nginx = { enable = true; virtualHosts."claw.my-domain.com" = { locations."/" = { proxyPass = "http://localhost:3000"; # 指向OpenClaw服务 proxyWebsockets = true; # 如果网关使用WebSocket }; # 配置SSL证书（例如使用Let's Encrypt） enableACME = true; forceSSL = true; }; };

日志与监控：OpenClaw服务的日志通过journalctl管理。你可以配置journald的转发，将日志发送到中央日志系统（如Loki, Elasticsearch）。对于监控，可以搭配prometheusexporter（如果OpenClaw提供）或者使用blackbox_exporter进行HTTP健康检查。

services.prometheus = { enable = true; scrapeConfigs = [ { job_name = "openclaw"; static_configs = [{ targets = [ "localhost:3000" ]; # 假设OpenClaw在3000端口提供/metrics端点 }]; } ]; }; services.grafana = { enable = true; # ... 配置数据源和仪表盘 };

数据库持久化：如果启用了memory（记忆）等功能，OpenClaw可能需要连接数据库（如PostgreSQL）。确保在NixOS中同时启用并正确配置数据库服务，并将连接字符串通过安全的方式（configFile）提供给OpenClaw。

services.postgresql = { enable = true; ensureDatabases = [ "openclaw" ]; ensureUsers = [ { name = "openclaw"; ensurePermissions = { "DATABASE openclaw" = "ALL PRIVILEGES"; }; } ]; };

5. 常见问题排查与经验实录

即使设计再精良，在实际部署中也会遇到各种问题。以下是我在集成和使用过程中遇到的一些典型情况及解决方法。

5.1 构建阶段失败

问题：构建时出现哈希不匹配（hash mismatch）错误。

  • 原因：这通常是因为上游OpenClaw的依赖（某个NPM包）更新了，但其在Nixpkgs中的固定输出推导（fetcher）使用的哈希值还是旧的。openclaw-nixos的锁文件修剪器可能改变了依赖树，但Nix用于下载某个源码包的哈希值未更新。
  • 排查：错误信息会明确指出是哪个包。前往openclaw-nixos项目仓库的flake.nix或build.nix中，查找该包的来源（可能是fetchFromGitHub，fetchNpmDeps等）。需要更新对应的sha256或hash字段。
  • 解决：
    1. 临时方案：在本地尝试构建时，Nix会报错并给出正确的哈希值（在got:后面）。你可以用这个新值替换配置中的旧值。
    2. 根本方案：向openclaw-nixos项目提交Issue或PR，维护者会运行更新脚本来修正所有依赖的哈希。

问题：构建时提示缺少某些原生模块（native addon）编译工具。

  • 原因：尽管项目尽力修剪，但OpenClaw的核心运行时可能仍依赖需要编译的Node.js原生模块（如某些数据库驱动、加密库）。构建环境缺少python，gcc，make等工具。
  • 排查：查看完整的构建错误日志，通常会有类似node-gyp rebuild failed的提示。
  • 解决：这需要在构建输入（buildInputs）中添加必要的编译工具。由于openclaw-nixos旨在精简，可能默认未包含。你需要在其Nix表达式层面添加。对于临时测试，可以尝试在nix-shell中带入一个完整的开发环境来构建。长期解决需要修改项目的build.nix，在nativeBuildInputs中添加python3，gcc等。

5.2 运行时问题

问题：服务启动失败，日志显示“Cannot find module ‘xxx’”。

  • 原因：依赖缺失。这可能是锁文件修剪过程过于激进，错误地移除了一个运行时必需的模块。也可能是模块的package.json中声明的依赖与锁文件中的版本不匹配。
  • 排查：确认缺失的模块名xxx。去原始的OpenClaw仓库查看其package.json，看xxx是dependencies还是devDependencies。如果是devDependencies却被运行时引用，可能是上游项目配置有误。如果是dependencies却缺失，则是lockfile-pruner的bug。
  • 解决：在openclaw-nixos项目的Issue中搜索该模块名。如果没有相关报告，可以手动修改本地的锁文件修剪逻辑，将该模块从剔除名单中豁免，然后重新生成锁文件并构建。

问题：服务能启动，但响应慢或内存占用高。

  • 原因：Node.js应用的内存和性能调优是个常见话题。OpenClaw作为网关，如果处理大量并发请求或使用了大语言模型，资源消耗会上升。
  • 排查：使用htop，journalctl --since "5 minutes ago” -u openclaw观察。检查OpenClaw自身的日志级别是否设置为debug（过于详细会影响性能）。监控LLM API调用的延迟。
  • 解决：
    1. 调整Node.js参数：通过services.openclaw.serviceOverrides设置NODE_OPTIONS环境变量，例如--max-old-space-size=4096限制最大堆内存为4GB。
    2. 优化配置：关闭不需要的插件或功能（如某些实验性记忆后端）。调整网关的请求超时和并发限制。
    3. 基础设施升级：确保服务器有足够的CPU和内存。对于IO密集型操作，使用更快的磁盘（如SSD）或数据库。

5.3 NixOS模块配置相关

问题：同时使用了config和configFile，但似乎configFile的配置没生效。

  • 原因：合并逻辑问题或文件路径权限问题。
  • 排查：首先检查configFile指向的文件是否存在且服务用户有读取权限。查看systemd服务的环境变量OPENCLAW_CONFIG_FILE是否被正确设置。查看OpenClaw启动日志，看它加载了哪个配置文件。
  • 解决：确保configFile的路径是绝对路径，并且在服务启动前就已存在。可以尝试先只使用configFile，确保它能独立工作，然后再逐步添加config中的覆盖项。阅读模块源码，理解其合并顺序（通常是configFile作为基础，config覆盖它）。

问题：更新NixOS配置后，服务使用的旧配置文件没有被刷新。

  • 原因：如果你将配置文件（如config.json）放在/etc/openclaw/下，并且这个文件不是由Nix直接管理的（即不在/nix/store中），那么NixOS重建不会自动覆盖它。
  • 解决：对于需要由Nix管理的重要配置文件，可以考虑使用environment.etc将其链接到/etc，或者使用systemd.tmpfiles规则在启动时从Nix存储库复制。对于纯秘密文件，手动管理更新流程更安全。

5.4 网络与安全

问题：防火墙已开放端口，但外部仍无法访问。

  • 原因：服务可能绑定到了127.0.0.1（localhost）而不是0.0.0.0（所有接口）。
  • 排查：检查OpenClaw的配置中是否有host或bind选项。默认情况下，许多Node.js应用在开发环境下监听localhost，在生产环境下需要显式配置。
  • 解决：在OpenClaw的配置中（无论是config还是configFile），确保网关监听地址设置为0.0.0.0。例如在JSON配置中："gateway": { "host": "0.0.0.0", "port": 3000 }。

问题：如何为OpenClaw网关配置HTTPS？

  • 原因：直接暴露HTTP服务不安全，且许多现代浏览器API要求HTTPS。
  • 解决：最佳实践是在OpenClaw前面放置一个反向代理（如Nginx, Caddy）来处理TLS终止。Nginx配置SSL证书（可以使用security.acme自动申请Let‘s Encrypt证书），然后以HTTP协议代理到本地的OpenClaw服务。这样既简化了OpenClaw本身的配置，又能利用Nginx强大的HTTP处理能力。

部署openclaw-nixos的过程，是一个将声明式配置、安全最佳实践和特定领域优化相结合的过程。它可能不像直接docker run那样一步到位，但带来的构建确定性、部署一致性和对系统整体的掌控力，在长期维护和规模化运营中价值巨大。当你看到经过精简后快速构建完成的服务，以及清晰可控的NixOS配置时，前期投入的学习和调试成本就显得非常值得了。

http://www.jsqmd.com/news/810520/

相关文章：

  • 河道水质监测站：给江河湖海装上“电子感官”
  • 14 从中序和后序遍历构造二叉树
  • FalcoClaw：为AI Agent与Linux工作负载构建自动化运行时安全响应引擎
  • 手把手教你为STM32F429的LTDC或大数组配置SDRAM：从硬件选型(W9825G6KH)到CubeMX参数详解
  • 基于比特币与IPFS构建去中心化身份锚点：原理、实现与应用
  • 北京手表回收哪家靠谱？2026 主流渠道实测对比，新手不踩坑 - 奢侈品回收测评
  • 多线程与并发编程
  • 在Windows上优雅处理PDF：Poppler工具包让你的文档工作更轻松
  • 嵌入式开发云端化：架构模式、实战评估与核心挑战解析
  • 风力叶片机器人喷涂轨迹规划仿真【附模型】
  • 利用Taotoken模型广场为不同项目选择合适大模型的策略
  • AI助手本地化办公：officecli-skills实现文档自动化生成
  • C/C++项目里stb_image库的‘multiple definition’报错，我用STB_IMAGE_STATIC宏解决了
  • 2026年金融AI投研炒股工具横评：五大主流平台深度对比推荐 - 品牌种草官
  • 【技术底稿 33】同机复用开发资源，搭建完整测试环境实战复盘一、核心背景
  • 基于Git工作流的OpenClaw状态备份工具clawsync设计与实践
  • 【仅限前500名】NotebookLM RAG私有化调优套件泄露版：含17个生产环境验证的prompt-sql混合检索模板+Latency-SLA监控看板
  • Python WebSocket 实时通信实战：构建实时Web应用
  • 告别答辩PPT焦虑：百考通AI一键生成，高效备战毕业答辩
  • AI时代的战神金刚——构建你的外部大脑与商业闭环@围巾哥萧尘
  • 【AI响应速度生死线】：Haiku在实时客服/编程助手/边缘设备的3大不可替代性验证
  • NotebookLM播客生成质量暴跌真相：训练数据污染率高达18.7%？我们逆向拆解了其RAG音频对齐层
  • LabVIEW主要设计特性与工程价值
  • STM32实战：BMP280气压模块IIC驱动与数据精准采集
  • 不靠感觉写代码：Matt Pocock 的 Skills 如何让 AI 写出你真正想要的代码
  • 半导体行业周期解析：从供需失衡到产业链博弈的生存指南
  • 终极音乐解锁指南：免费工具让你在任何设备播放加密音乐
  • 从底层逻辑了解AI
  • 基于SimpleX协议构建私有AI通信通道：OpenClaw插件部署指南
  • 氛围工程指南：如何量化与塑造技术团队的健康氛围