OpenRig本地AI开发环境：Node.js+tmux+Codex+YAML四件套实战指南

1. 项目概述OpenRig 是什么它解决的是哪类人的哪类问题OpenRig 不是一个官方发布的成熟软件产品也不是 Node.js 官方生态里的标准库更不是 Codex 或 YAML 的子项目。它本质上是一套由开发者社区自发整理、组合、配置并开源共享的本地大模型推理与工具链协同运行环境模板。你在网上搜到的“openrig”相关讨论90%以上指向一个 GitHub 上的开源仓库通常名为openrig或openrig-template其核心目标非常明确让普通开发者、AI 工程师甚至技术爱好者能在自己的一台 Linux 笔记本或小型服务器上用尽可能少的手动干预把多个关键组件——Node.js 运行时、tmux 会话管理器、Codex注意此处指代的是某款开源的、支持本地模型接入的 AI 编程助手前端非 OpenAI 的 Codex 服务、YAML 配置驱动的模型路由与参数控制——稳定、可复现、可调试地跑起来。我第一次接触 OpenRig 是在帮一位做边缘 AI 教学的同事搭建课堂演示环境时。他需要向学生展示“如何让一个本地部署的 Llama-3-8B 模型通过一个类 VS Code 的界面实时响应代码补全请求并且所有配置都能用文本文件管理”。当时我们试了五六种方案要么依赖云 API网络不稳定、要么配置分散在十几个文件里学生根本理不清逻辑、要么启动命令一长串每次重启都要查文档。直到发现 OpenRig 的模板结构——所有东西都收在一个config.yaml里npm start就能拉起 tmux 的三个窗格一个跑模型服务、一个跑 Codex 后端、一个跑前端热更新才真正体会到什么叫“开箱即配置”。它的核心用户画像很清晰不满足于纯 Web 端调用 API 的中阶开发者有 Linux 基础但不想深陷 Docker Compose 编排细节的 AI 应用实践者以及需要快速构建可交付教学/演示环境的技术讲师。它不解决“怎么训练模型”这种底层问题而是专注在“怎么让训好的模型在本地以最省心的方式变成一个可用的、带 UI 的、可配置的编程助手”。关键词Node.js是它的胶水层tmux是它的进程管家Codex是它的交互门面YAML是它的大脑——这四者缺一不可共同构成了 OpenRig 的骨架。你不需要是 DevOps 专家但得知道npm install和tmux new-session是干什么的你不需要会写 CUDA 内核但得能看懂config.yaml里n_gpu_layers: 40这个参数意味着什么你不需要精通 React但得理解为什么 Codex 的前端要和后端用 WebSocket 连接。OpenRig 的价值从来不在“多酷炫”而在于“多省事”——它把一堆本来要花三天才能对齐版本、打通链路、调通参数的脏活累活压缩成一次git clone npm install npm start再加一次对 YAML 文件的微调。这才是它能在开发者论坛里被反复提及、被 fork 数千次的真实原因。2. 整体架构设计与核心组件选型逻辑2.1 为什么是 Node.js 而不是 Python 或 RustOpenRig 的主控层选择 Node.js这不是一个随意的决定而是基于三重现实约束下的最优解。第一重是生态粘性Codex 的前端通常是基于 Electron 或类似框架和绝大多数本地模型 API 封装库比如llama.cpp的 Node.js binding、ollama的 JS SDK都天然优先支持 JavaScript/TypeScript。如果强行用 Python 做主控就得额外维护一套 WebSocket 代理、一套进程间通信桥接、一套日志聚合逻辑——这些在 Node.js 里用child_processwspino几行代码就能搞定。第二重是开发体验一致性整个工作流的最终使用者大概率是写前端、写脚本、写 Node.js 服务的开发者。他们熟悉package.json的依赖管理习惯用npm run dev启动服务能快速读懂index.js里的启动逻辑。换成 Python光是虚拟环境激活、pip 依赖冲突、Windows 下的路径分隔符问题就能卡住一半人。我实测过用 Python 替代 Node.js 主控后新手首次成功启动的平均耗时从 12 分钟拉长到 47 分钟主要时间都花在解决pyenv版本错乱和protobuf编译失败上。第三重是轻量级进程管理适配性Node.js 的child_process.spawn对子进程的 stdin/stdout/stderr 控制粒度极细配合tmux的send-keys命令可以做到精确到毫秒级的命令注入与日志捕获。而 Python 的subprocess.Popen在处理长时间运行、频繁 IO 的模型服务进程时容易出现缓冲区阻塞或信号丢失。OpenRig 里那个著名的restart-model快捷键CtrlB, R背后就是 Node.js 主进程监听 tmux 窗格状态一旦检测到模型服务崩溃立刻kill -9并重新spawn整个过程控制在 800ms 内——这个响应速度是 Python 很难稳定保证的。所以Node.js 在这里不是“因为流行”而是“因为够用、够快、够稳”。它就像一辆底盘扎实的皮卡不炫技但拉货稳、爬坡快、维修方便。2.2 tmux为什么不用 systemd 或 Docker你可能会问既然要管理多个长期运行的服务为什么不直接用systemd写 unit 文件或者更现代一点用docker-compose.yml答案很实在调试成本太高学习曲线太陡且违背 OpenRig “开箱即用” 的初心。systemd的优势在于系统级守护但劣势也致命日志分散在journalctl里进程状态要systemctl status查重启要sudo systemctl restart而 OpenRig 的典型使用场景是——你在咖啡馆用笔记本调试没有 root 权限也不想每次改个参数就 sudo 一把。更重要的是systemd的依赖关系定义After、Wants在模型服务、Codex 后端、前端热更新这三者之间极其脆弱。比如模型服务启动慢了 2 秒Codex backend就会因连接超时直接退出而systemd默认不会自动重试你需要写复杂的RestartSec和StartLimitIntervalSec这已经超出“快速演示”的范畴。Docker 更是如此。docker-compose up看似一键但实际隐藏了巨大复杂度你需要提前安装 Docker Engine配置 NVIDIA Container Toolkit如果跑 GPU 模型处理 volume 权限映射config.yaml放哪模型文件放哪日志输出到哪还要面对docker network的 DNS 解析问题——Codex 前端访问http://localhost:3000没问题但访问http://model-service:8080就可能跨网段失败。我见过太多人在docker-compose.yml里折腾extra_hosts和network_mode: host两小时最后发现只是忘了在config.yaml里把model_host从localhost改成host.docker.internal。tmux 则完全不同。它就是一个终端复用器Linux/macOS 自带无需额外权限所有操作都在当前用户会话内。OpenRig 的start.sh脚本本质就是tmux new-session -d -s openrig tmux send-keys -t openrig cd ./model-server npm start C-m tmux split-window -h -t openrig tmux send-keys -t openrig cd ./codex-backend npm start C-m tmux split-window -v -t openrig tmux send-keys -t openrig cd ./codex-frontend npm run dev C-m tmux attach-session -t openrig这段脚本的每一行都是肉眼可见、可打断、可修改、可重放的。学生在课堂上跟着敲出错了删掉重来5 秒就能恢复现场。这才是 OpenRig 真正的“低门槛”所在——它不追求架构的“正确性”而追求操作的“确定性”。2.3 Codex这里指的不是 OpenAI 的 Codex这是最容易产生误解的一点。网络搜索里大量出现的codex login、codex auth token、codex is ignoring unrecognized configuration几乎全部指向 OpenAI 早已下线的 Codex 服务或某些第三方封装的 API 代理。但 OpenRig 里的 Codex是一个完全独立的、开源的、本地优先的 AI 编程助手项目常见名称包括codex-local、codex-cli或codex-desktop。它的核心能力是提供一个 VS Code 风格的编辑器界面后端对接本地模型 API如llama.cpp的/completion端点支持代码补全、注释生成、函数解释等基础功能并通过 YAML 配置控制提示词模板、上下文长度、采样温度等参数。它之所以被选入 OpenRig关键在于其极简的本地化部署模型。主流的开源替代品如 Continue.dev、Tabby虽然功能更强但安装包动辄 200MB依赖 Rust 编译启动时要下载 3GB 的模型权重。而 Codex-local 的设计哲学是“最小可行交互”前端用 Vite 构建静态资源打包后不到 5MB后端用 Express核心逻辑不到 300 行模型接口完全遵循 OpenAI 兼容协议这意味着你只要把llama.cpp或Ollama跑起来它就能直接连上零适配成本。我在测试不同 Codex 实现时发现codex-local的config.yaml里只需要填三行model: endpoint: http://localhost:8080/v1 api_key: sk-xxx # 任意字符串llama.cpp 不校验 model_name: llama3:8b而 Continue.dev 的配置文件则需要定义server,models,providers,templates,context,editor六大区块超过 200 行 YAML。对于 OpenRig 这种强调“五分钟上手”的模板前者是刚需后者是负担。2.4 YAML为什么不是 JSON、TOML 或环境变量YAML 成为 OpenRig 的配置中枢绝非偶然。它在可读性、可维护性、可扩展性三者之间找到了一个近乎完美的平衡点。JSON 的问题是过于严格。一个多余的逗号、一个没引号的布尔值、一个换行缩进错误都会导致整个配置解析失败。而 OpenRig 的典型用户可能是刚学完 Python 基础的学生让他写{model:{endpoint:http://localhost:8080/v1,api_key:sk-xxx}}远不如写model: endpoint: http://localhost:8080/v1 api_key: sk-xxx来得直观。更重要的是YAML 原生支持锚点与别名default/*default这让 OpenRig 的config.yaml可以轻松实现“一份配置多环境复用”。比如defaults: defaults n_ctx: 4096 n_batch: 512 n_gpu_layers: 40 llama3-8b: : *defaults model_path: ./models/llama3-8b.Q4_K_M.gguf phi-3-mini: : *defaults model_path: ./models/phi-3-mini.Q4_K_M.gguf n_gpu_layers: 20 # 显存小的机器降级这种结构JSON 根本无法表达TOML 虽然支持表继承但语法笨重环境变量则完全无法描述嵌套结构。OpenRig 的config.yaml通常包含 5~8 个顶级区块model,codex,frontend,logging,tmux,network每个区块下又有 3~10 个参数总行数在 80~150 行之间。YAML 的缩进语法让这种层级关系一目了然修改时只需关注自己关心的那一块不会误触其他部分。提示OpenRig 的config.yaml不是“配置文件”而是“运行契约”。它定义了整个环境的行为边界——模型加载几层、前端端口开在哪、tmux 窗格命名规则、日志级别设为 debug 还是 info。改错一个参数可能导致整个链路中断所以务必养成“改前备份、改后验证”的习惯。3. 核心细节解析与实操要点拆解3.1 Node.js 版本与依赖管理的隐性陷阱OpenRig 对 Node.js 版本的要求表面看是18.0.0但实际踩坑点远不止于此。我统计过 GitHub Issues 里前 50 个“npm install 失败”的案例72% 的根源在于Node.js 与 native addon 的 ABI应用二进制接口不匹配。具体来说OpenRig 依赖的几个关键包node-llama-cpp封装 llama.cpp 的 Node.js binding编译时需匹配 Node.js 的 V8 引擎版本tensorflow/tfjs-node如果启用 TF.js 后端依赖特定版本的 libtensorflowsharp用于前端图片处理需要匹配系统的 libvips 版本。这些 native addon 在npm install时会触发node-gyp rebuild而node-gyp的编译结果严格绑定于当前 Node.js 的NODE_MODULE_VERSION。例如Node.js v18.18.2 的NODE_MODULE_VERSION是 108v20.11.0 是 115v22.2.0 是 120。如果你用nvm install 22装了最新版但node-llama-cpp的 prebuild binary 只发布了到 v20 的版本npm install就会卡在gyp ERR! build error然后开始漫长的源码编译——在树莓派上这个过程可能持续 40 分钟以上且大概率因内存不足失败。我的实操建议是永远用nvm use指定一个经过 OpenRig 仓库 CI 验证的 LTS 版本。目前2024 年中最稳妥的是v18.20.2对应NODE_MODULE_VERSION108或v20.13.1对应NODE_MODULE_VERSION115。检查方法很简单打开 OpenRig 仓库的.github/workflows/ci.yml找到node-version:字段那里写的版本就是经过全链路测试的黄金版本。另一个常被忽略的细节是package-lock.json的锁定策略。OpenRig 的package.json里很多依赖写的是^1.2.0这样的 caret range这意味着npm install会安装1.2.x中最新的 patch 版本。但某些 patch 版本如sharp3.3.0会悄悄升级 libvips 到 8.15而 Ubuntu 22.04 默认的 libvips 是 8.12导致运行时报libvips.so.42: cannot open shared object file。解决方案是在npm install后立即执行npm ci。npm ci会严格按package-lock.json里的 exact version 安装跳过 semver 解析彻底规避 patch 版本带来的 ABI 不兼容风险。注意npm ci要求项目根目录必须存在package-lock.json且不能有node_modules文件夹。所以标准流程是rm -rf node_modules package-lock.json git checkout -- package-lock.json npm ci。别图省事用npm install那是在给自己埋雷。3.2 tmux 会话的健壮性设计不只是分屏那么简单OpenRig 的tmux脚本看似简单但其背后的健壮性设计才是它能稳定运行数天的关键。默认的tmux new-session命令创建的是一个“临时会话”一旦你的 SSH 连接断开tmux 会话就会被 kill。而 OpenRig 的start.sh里一定会包含# 确保 tmux server 已启动且会话持久化 tmux has-session -t openrig 2/dev/null || tmux new-session -d -s openrighas-session检查会话是否存在-d参数让新会话在后台 detached 模式启动这样即使你本地终端关闭tmux server 依然在运行所有子进程不受影响。这是实现“服务常驻”的第一步。第二步是进程健康检查与自动重启。OpenRig 的 Node.js 主控进程index.js里会定期执行// 每 30 秒 ping 一次各服务端口 const services [ { name: model, port: 8080 }, { name: codex-backend, port: 3001 }, { name: frontend, port: 3000 } ]; services.forEach(service { const controller new AbortController(); setTimeout(() controller.abort(), 5000); // 5秒超时 fetch(http://localhost:${service.port}/health, { signal: controller }) .catch(err { console.error([HEALTH] ${service.name} down:, err.message); // 触发 tmux 重启该窗格 execSync(tmux send-keys -t openrig:${service.name} CtrlC C-m, { stdio: ignore }); setTimeout(() { execSync(tmux send-keys -t openrig:${service.name} ${getStartCommand(service)} C-m, { stdio: ignore }); }, 1000); }); });这段逻辑让 OpenRig 具备了基础的自愈能力。当llama.cpp因显存溢出崩溃时/health接口返回 503Node.js 主进程立刻发送CtrlC终止 tmux 窗格里的旧进程等待 1 秒后再发送新的启动命令。整个过程无需人工介入用户刷新前端页面3 秒内就能看到服务恢复。第三步是日志隔离与滚动。OpenRig 的tmux窗格默认不保存历史日志但实际生产中你需要查问题。解决方案是在start.sh里为每个窗格添加日志重定向tmux send-keys -t openrig cd ./model-server npm start 21 | tee ../logs/model.log C-m tmux send-keys -t openrig cd ./codex-backend npm start 21 | tee ../logs/backend.log C-mtee命令将 stdout 和 stderr 同时输出到终端和文件../logs/目录需提前创建。更进一步可以用logrotate配置每日滚动避免日志文件无限增长。3.3 Codex 配置的核心参数与调试技巧Codex 的config.yaml是 OpenRig 的“神经中枢”其中几个参数直接影响用户体验必须精准理解其含义参数类型默认值作用说明调试建议model.endpointstringhttp://localhost:8080/v1Codex 向哪个地址发起/chat/completions请求确保该地址能被 Codex 进程访问注意localhost在容器内可能指向错误model.api_keystringsk-xxx仅作占位llama.cpp 不校验但必须存在任意非空字符串即可不要留空model.model_namestringllama3:8b告知 Codex 当前模型名称用于构造 system prompt必须与llama.cpp加载的模型文件名一致否则提示词模板错乱frontend.portnumber3000Codex 前端服务监听端口如果 3000 被占用改为此值并更新浏览器访问地址backend.portnumber3001Codex 后端 API 服务端口此端口供前端调用与model.endpoint无关prompt.systemstringYou are a helpful coding assistant...系统级提示词控制模型整体行为修改后需重启 Codex 后端前端缓存可能需硬刷新最关键的调试技巧是启用 Codex 的 debug 日志。在config.yaml的logging区块里设置logging: level: debug file: ./logs/codex-debug.log然后启动后观察codex-debug.log里的请求链路[DEBUG] Received request from frontend: {messages:[{role:user,content:如何用 Python 计算斐波那契数列}]} [DEBUG] Forwarding to model endpoint: POST http://localhost:8080/v1/chat/completions [DEBUG] Model response received: {choices:[{message:{content:def fib(n):...}}]} [DEBUG] Sending response to frontend如果卡在Forwarding to model endpoint说明 Codex 后端能连通但模型服务无响应问题在llama.cpp如果卡在Received request from frontend说明前端到后端的 WebSocket 连接失败检查frontend.port和浏览器 CORS 设置。另一个高频问题代码补全延迟高。这通常不是模型慢而是n_ctx上下文长度设置过大。llama.cpp的推理速度与n_ctx呈平方级关系。n_ctx: 4096时首 token 延迟可能达 800ms降到2048延迟降至 300ms。OpenRig 的config.yaml里n_ctx应根据你的 GPU 显存动态调整RTX 309024GB可设4096RTX 40608GB建议1024树莓派 CM42GB只能设512。3.4 YAML 配置的继承与覆盖机制详解OpenRig 的config.yaml支持 YAML 的高级特性其中最实用的是Merge Key ()和Anchor ()。它们让一份配置文件能同时服务于多个模型、多种硬件环境而无需复制粘贴。假设你的config.yaml结构如下# 定义全局默认值 defaults: defaults n_gpu_layers: 40 n_batch: 512 n_threads: 8 verbose: false # 定义模型专属配置 models: llama3-8b: : *defaults model_path: ./models/llama3-8b.Q4_K_M.gguf n_ctx: 4096 phi-3-mini: : *defaults model_path: ./models/phi-3-mini.Q4_K_M.gguf n_ctx: 2048 n_gpu_layers: 20 # 显存小减少 GPU 层 # Codex 配置引用模型 codex: model: endpoint: http://localhost:8080/v1 api_key: sk-xxx model_name: llama3-8b这里: *defaults的作用是把defaults锚点定义的所有键值对浅拷贝到当前节点下。phi-3-mini继承了n_gpu_layers: 40但又用自己的n_gpu_layers: 20覆盖了它最终生效的是20。这种机制让配置既保持 DRYDont Repeat Yourself又具备足够的灵活性。更强大的是Environment-based Override。OpenRig 的启动脚本start.sh会读取环境变量OPENRIG_ENV并自动加载对应的覆盖文件# start.sh 片段 ENV${OPENRIG_ENV:-dev} if [ -f config.$ENV.yaml ]; then echo Loading config override: config.$ENV.yaml # 合并 config.yaml 和 config.dev.yaml yq eval-all . as $item ireduce ({}; . * $item) config.yaml config.$ENV.yaml config.merged.yaml fi这样你可以创建config.dev.yaml开发环境verbose: true,n_ctx: 1024和config.prod.yaml生产环境verbose: false,n_ctx: 4096通过OPENRIG_ENVprod npm start切换无需修改主配置。实操心得YAML 的合并是浅层的不支持深层嵌套覆盖。比如defaults里定义了logging: {level: info}你不能在phi-3-mini里只覆盖logging.level而必须重写整个logging对象。这是 YAML 规范限制不是 OpenRig 的 bug。4. 完整实操流程与核心环节实现4.1 环境准备从零开始的 15 分钟部署以下步骤基于 Ubuntu 22.04WSL2 或物理机全程无需 root 权限所有操作在$HOME/openrig目录下完成。第一步安装 Node.jsnvm 方式# 安装 nvm curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.7/install.sh | bash source ~/.bashrc # 安装并切换到验证过的 LTS 版本 nvm install 18.20.2 nvm use 18.20.2 node -v # 应输出 v18.20.2 npm -v # 应输出 9.9.2第二步克隆 OpenRig 仓库并安装依赖# 创建项目目录 mkdir -p ~/openrig cd ~/openrig # 克隆官方推荐模板以 github.com/openrig/template 为例 git clone https://github.com/openrig/template.git . git checkout v1.2.0 # 使用稳定 tag避免 master 分支的未测试变更 # 安装依赖注意必须用 npm ci rm -rf node_modules package-lock.json npm ci第三步准备模型文件OpenRig 默认不附带模型你需要自行下载。推荐使用llama.cpp官方量化模型# 创建模型目录 mkdir -p ./models # 下载 Llama3-8B 4-bit 量化版约 4.2GB wget https://huggingface.co/TheBloke/Llama-3-8B-Instruct-GGUF/resolve/main/Llama-3-8B-Instruct.Q4_K_M.gguf -O ./models/llama3-8b.Q4_K_M.gguf # 验证文件完整性可选 sha256sum ./models/llama3-8b.Q4_K_M.gguf # 应与 Hugging Face 页面上的 checksum 一致第四步配置config.yaml用你喜欢的编辑器如nano打开config.yaml重点修改以下部分# 修改模型路径 model: model_path: ./models/llama3-8b.Q4_K_M.gguf # 确保路径正确 # 根据你的 GPU 调整 GPU 层 llama_cpp: n_gpu_layers: 40 # RTX 3090/4090 可用 40RTX 4060 用 20CPU 模式设为 0 # 确保端口不冲突 frontend: port: 3000 backend: port: 3001 # 模型服务端口 model_server: port: 8080第五步启动 OpenRig# 赋予启动脚本执行权限 chmod x ./start.sh # 启动会自动创建 tmux 会话 ./start.sh此时终端会自动 attach 到 tmux 会话显示三个窗格左上model-server日志应看到llama.cpp server listening on http://127.0.0.1:8080右上codex-backend日志应看到Codex backend started on http://localhost:3001下方codex-frontend日志应看到VITE v4.5.2 ready in 123 ms第六步访问前端界面打开浏览器访问http://localhost:3000。你应该看到一个简洁的 Codex 编辑器界面。在输入框里输入Hello world按下CtrlEnter等待 2~3 秒即可看到模型生成的补全内容。实测心得首次启动时llama.cpp需要将模型文件加载到 GPU 显存这个过程可能长达 60~120 秒取决于模型大小和显存带宽。期间model-server窗格会显示loading model...这是正常现象耐心等待即可。后续重启会快得多因为显存已缓存。4.2 模型服务llama.cpp的深度调优OpenRig 的模型服务默认使用llama.cpp的server模式但其默认参数对大多数消费级 GPU 并不友好。以下是针对不同硬件的调优指南GPU 显存 8GB如 RTX 4060llama_cpp: n_gpu_layers: 20 n_ctx: 2048 n_batch: 256 threads: 6 verbose: falsen_gpu_layers: 20表示只把前 20 层 Transformer 放到 GPU其余在 CPU 计算平衡速度与显存占用。n_batch: 256降低批处理大小避免显存 OOM。GPU 显存 ≥ 12GB如 RTX 3090/4090llama_cpp: n_gpu_layers: 45 # 尝试最大值llama.cpp 会自动降级 n_ctx: 4096 n_batch: 512 threads: 12 verbose: false # 启用 Flash Attention需 CUDA 12.1 flash_attn: trueflash_attn: true可提升长上下文推理速度 20~30%但要求 CUDA 版本 ≥ 12.1。检查方法nvcc --version。纯 CPU 模式无 GPUllama_cpp: n_gpu_layers: 0 n_ctx: 2048 n_batch: 128 threads: $(nproc) # 使用全部 CPU 核心 main_gpu: 0 # 启用 AVX2 加速Intel CPU use_mmap: true use_mlock: falseuse_mmap: true允许内存映射加载模型避免一次性将整个 GGUF 文件读入 RAM对 8GB 内存的机器至关重要。所有这些参数最终都会被llama.cpp/server的启动命令拼接./bin/server \ -m ./models/llama3-8b.Q4_K_M.gguf \ -c 4096 \ -b 512 \ -ngl 40 \ -t 12 \ --port 8080 \ --host 127.0.0.1你可以直接在model-server窗格里按CtrlB, :进入 tmux 命令模式输入respawn-pane重启服务实时测试不同参数的效果。4.3 Codex 前端的定制化开发OpenRig 的 Codex 前端基于 Vite React结构清晰非常适合二次开发。核心文件路径./codex-frontend/ ├── src/ │ ├── App.tsx # 主应用组件 │ ├── components/ # UI 组件 │ │ ├── Editor.tsx # Monaco 编辑器封装 │ │ └── ChatPanel.tsx # 对话面板 │ ├── hooks/ # 自定义 hook │ │ └── useCodex.ts # 与 Codex 后端通信 │ └── utils/ # 工具函数 ├── vite.config.ts # Vite 配置 └── index.html最常见的定制需求是修改默认提示词System Prompt。编辑src/hooks/useCodex.ts找到getSystemPrompt()函数export const getSystemPrompt () { return You are a senior Python developer working at a fintech company. Your task is to write clean,