Windows 上玩转终端 AI 编程其实没有想象中那么折腾。OpenCode 这款终端 AI 编程助手加上 oh-my-opencode 这个配置增强层再接入 GLM 系列模型三样东西拼在一起就能在本地跑出一套完整可控、中文友好、token 成本又不高的 AI 辅助开发环境。我最近用了挺长一段时间这套组合帮我解决了一个很实际的问题不想被 IDE 插件绑架又想要一个能直接读写项目文件、能跑命令、能看懂 git diff 的助手。GLM 的优势在于国内网络环境访问快中文理解和代码生成都属于第一梯队新手注册后还能拿到赠送的 token 额度特别适合拿来当日常主力模型。折腾完这套环境之后它在 Windows 上其实还有一些独有需要注意的坑比如终端权限、环境变量、Node 版本这些我会在下面把一个一个细节拆开讲清楚也顺便聊聊我实操下来的取舍。1. 先把三个角色认清楚1.1 OpenCode 解决什么问题OpenCode 本质上是一个跑在终端里的 AI 编程助手英文圈喜欢管它叫 terminal AI coding agent。它可以和你进行多轮对话但真正强的地方不是聊天而是它能看到当前目录下的文件结构能读写文件内容还能执行终端命令。也就是说你可以直接对它说“帮我把 src 目录下所有 fetch 请求改成统一的封装”它会自己去翻阅相关文件、改代码、然后给你一份 diff。这和 IDE 里的 AI 插件是完全不同的使用习惯。IDE 插件通常只在你当前打开的文件上下文里做补全和行内建议而 OpenCode 更像一个坐在终端旁边的结对程序员你说需求它自己去翻代码。相比之下OpenCode 不占用编辑器里的视觉空间不依赖特定 IDE用一套终端工具就能覆盖前后端、脚本、配置文件等所有场景。它在 Windows 上跑起来没有任何问题核心依赖就是 Node.js。启动方式非常简单在任意目录下敲一个opencode命令就会进入交互式终端界面。在交互界面里输入需求它就开始干活。如果要跑自动化任务也可以用opencode run 需求描述这种非交互模式这条命令很适合在脚本里批量调用。1.2 oh-my-opencode 到底装了些什么如果你用过 Zsh那你一定知道 oh-my-zsh 是什么它是对 shell 本体的配置增强和功能扩展集合。oh-my-opencode 干的也是同一件事不过对象换成了 OpenCode。装完 oh-my-opencode 之后它会在你的用户目录下生成一套结构化的配置目录里面分门别类地放了供应商配置、模型配置、工作流模板、提示词模板还有斜杠命令定义。它的初始化向导会引导你选择要启用哪些功能选择模型供应商填入 API Key。整个过程走完你的 OpenCode 不再是一张白纸而是自带了一批现成的高质量工作流和命令例如项目规划、代码审查、生成提交信息这些高频场景都有预设。我特别看重的一点是它把配置沉淀成了文件这意味着不同机器之间可以同步同一团队也能用同一套规则。开发机上配置好了拿到家里电脑直接克隆一份就继续干不需要重新点一遍设置界面。1.3 为什么偏偏选 GLM 接入选择 GLM 倒不是因为它是最强的模型而是因为它在当前这套组合里综合得分最高。首先是网络访问GLM 的 API 服务在国内部署直连稳定不像折腾境外模型还要考虑网络问题。其次是模型能力GLM-4.5、GLM-4.6 这些新版本在代码生成、代码理解、复杂指令遵循上和我实际用的体验已经很接近国际一线模型了中文自然语言指令的理解甚至更顺因为它在中文语料上的训练更充分。还有一个现实因素是成本。GLM 开放平台对开发者比较友好注册会赠送 token 试用额度日常轻中度使用很长时间都不用付费。即使超过免费额度按量的价格也比多数海外主流模型便宜一截。对于想在本地终端里高频使用 AI 辅助开发的人GLM 是性价比非常合适的选择。2. Windows 环境准备与安装实操2.1 先把运行时补齐Node.js 与 GitWindows 上安装 OpenCode 之前需要确认 Node.js 已经装好。OpenCode 是基于 Node.js 开发的标准 CLI 工具建议使用 Node.js 18 及以上版本实测在 Node 20、22 上都运行稳定。我见过不少人在老版本 Node 上装完启动直接报错就是版本太低导致的。Node.js 的版本管理推荐用 nvm-windows这是一款专为 Windows 设计的 Node 版本管理工具支持在多个 Node 版本之间自由切换。装好之后执行nvm install 20 nvm use 20然后确认版本号node -v npm -v打印出版本号就说明运行时没问题。Git 在 Windows 上属于强烈建议安装的组件虽然 OpenCode 本身不依赖 Git但 oh-my-opencode 的安装过程需要从仓库拉取代码日常配合 AI 改代码也离不开 git diff 和 git commit 这类操作。装 Git 的时候选默认选项就行有个别版本会让用户选分支名和 PATH 方式保持默认即可。还需要注意 PowerShell 默认会限制脚本执行。Windows 的命令行环境中未经签名的本地脚本默认是被阻止运行的不设置的话后面运行安装脚本会直接抛异常。用管理员权限打开 PowerShell 执行Set-ExecutionPolicy RemoteSigned -Scope CurrentUser这样本机未签名的脚本可以运行但从网络下载的脚本仍然需要签名安全性上能接受。2.2 安装 OpenCode 主程序OpenCode 通过 npm 全局安装npm install -g opencode-ai/opencode安装完成后验证一下opencode --version如果提示“opencode 不是内部或外部命令也不是可运行的程序”那说明 npm 的全局目录没有加入系统 PATH。可以先用这个命令查看全局安装路径npm config get prefix拿到路径后把路径里的npm文件夹Windows 常见为C:\Users\你的用户名\AppData\Roaming\npm加入用户环境变量 PATH然后重新打开终端就生效了。这一步完成后你可以先在任意空目录里敲opencode启动一次。初次启动会要求选择模型供应商这一步不用急先按 CtrlC 退出去准备把 GLM 的配置放进去。2.3 拉取 oh-my-opencode 并完成初始化获取 oh-my-opencode 的方式是直接克隆它的仓库到本地。我在 Windows 上习惯把它放在用户目录下一个专门的文件夹方便统一管理git clone https://github.com/你的来源仓库/oh-my-opencode.git ~/oh-my-opencode进入目录之后当前仓库的 Windows 安装脚本是setup.ps1直接执行cd ~/oh-my-opencode .\setup.ps1这个脚本会进入交互式流程它的大致逻辑是检查 OpenCode 是否已安装询问你要安装哪些功能模块在选择模型供应商时找一下 GLM 对应的选项界面上可能显示为 zhipu-ai 或 GLM 系列视仓库版本而定。选择之后它会引导你填写 API Key。这里有个小细节值得说一下初始化脚本不只是把 API Key 写进配置它还会创建 OpenCode 项目级配置目录.opencode并在其中放入预设的规则文件和命令文件。如果你打开项目根目录应该能看到一个隐藏目录.opencode里面是分门别类的 Markdown 文件和工作流定义这才是 oh-my-opencode 真正发挥作用的载体。3. 把 GLM 接入 OpenCode 的完整配置3.1 获取 API Key 并管理额度GLM 的 API Key 需要到 GLM 开放平台注册账号后在控制台生成。登录后找到 API Key 管理页创建一个新密钥复制保存好。这个密钥是一长串字符长得像两段句点拼接的格式复制时注意别漏掉字符。开放平台通常会给新用户赠送一笔初始 token用完之后试用是按量计费模式。我建议你在控制台的费用管理里设置一个月度消费上限防止某次批量任务跑飞了产生意外账单。设置上限这个习惯长期用任何大模型 API 都应该养成。3.2 方式一通过环境变量配置环境变量方式最干净而且和 oh-my-opencode 的初始化向导兼容因为很多配置模块在读取 API Key 时会优先读环境变量。在 PowerShell 里临时设置只对当前会话生效适合先做连通性测试$env:ZHIPU_API_KEY 你的密钥临时设置有个问题重开终端就没了。要永久写入用户环境变量用 setxsetx ZHIPU_API_KEY 你的密钥执行完 setx 后需要重开终端才会加载到新环境变量这点经常有人忽略。检查一下环境变量是否生效echo $env:ZHIPU_API_KEY能完整打印出密钥字符串就说明环境变量没问题。3.3 方式二通过 OpenCode 配置文件配置如果更习惯把 AI 相关的配置统一放在配置文件里也可以直接修改 OpenCode 的全局配置。配置文件默认位置在 Windows 上是C:\Users\你的用户名\.config\opencode\opencode.json在这个文件里加入 provider 段落并指定 GLM 模型。具体配置结构在不同版本里略有差异但大体思路一致{ provider: { zhipu-ai: { models: { glm-4.6: { name: GLM-4.6 }, glm-4.5: { name: GLM-4.5 } } } } }如果你是通过 oh-my-opencode 的交互式向导完成的初始化生成出来的配置结构可能比我这里写的更完整会有 model 的上下文长度、工具调用开关等参数。无论哪种结构核心目标都是让 OpenCode 在启动时能够识别出可用的 GLM 模型。配置完成后启动 OpenCode按/models快捷键查看模型列表选中你刚配置的 GLM 模型然后输入一句简单的话测试帮我用 Python 写一个读取 CSV 并统计每列空值数量的函数看返回结果和代码质量就说明整条链路已经通了。3.4 关键参数的选择逻辑很多人拿到 API Key 后直接默认模型就开跑其实 GLM 开放平台提供了好几个档位的模型选型是有讲究的。旗舰模型如 GLM-4.6在复杂代码生成、多文件重构、工具调用稳定性上表现最好适合放在 OpenCode 里做核心任务轻量级模型如 GLM-4.5-Flash速度快成本低适合大量文本处理、简单问答、生成 commit message 这类不算复杂的任务。你可以一个作为主力模型另一个作为备用哪个贵用哪个这种想法在 AI 辅助编程里多数时候不划算因为简单任务用大模型也没什么质的提升倒不如省下 token 给复杂任务用。4. 日常使用从改一个小函数到跑完整工作流4.1 让 AI 实际动手改代码安装配置好之后用一个真实项目去做一次完整的改动能直观感受到这套组合的价值。这里我以一个 Python 脚本为例假设里面有一段重复的计算逻辑total 0 for item in data: if item[price] 0: total item[price] * item[count]在项目根目录启动 OpenCode输入把这段计算逻辑提取成一个函数函数名自己定要加类型注解并把返回值命名得更清晰OpenCode 会先读取当前文件内容然后给出修改后的代码块同时说明它做了哪些修改。确认满意后它会把改动应用到文件里。这种多步操作读取文件、理解上下文、修改文件对模型能力要求不低实测 GLM-4.6 在这个流程里表现得相当稳定尤其是中文描述的需求它能比较准确地对应到代码层面。如果你担心 AI 在多个文件之间跳跃会改错地方OpenCode 的工作区/tabs 模式很有用。你可以显式地把涉及的文件加入工作区这样它的修改范围就被限定在你指定的文件里不会擅自去动其他目录的文件。这在改大型项目时是一个非常重要的安全边界。4.2 用好 oh-my-opencode 的高频命令oh-my-opencode 安装后自带了一批斜杠命令每个斜杠命令本质上是封装好的一段提示词和工作流。我日常用得最多的是这三个/plan先理解需求并把影响面列出来生成分步实施计划不直接改代码。这个命令适合接需求任务时先用让 AI 把思路亮出来人确认了再往下一步走。/review对当前工作区里的改动做代码审查它会把 diff 列出来然后逐条扫描找出潜在 bug 和风格问题。/commit自动分析当前 git diff生成符合规范的提交信息同时带上文件变更摘要。这套东西真正好用的点在哪里它把团队规范直接沉淀成了配置。如果你所在团队有代码风格要求或提交信息规范可以修改 oh-my-opencode 里对应的模板文件以后所有人在同一个环境里调 AI产出的风格就是统一的不需要每人在对话里反复强调。4.3 结合 Git 的完整闭环我日常用得最顺的一个流程是这样的。接到一个改动需求后先在终端里看清现状git status git diff然后启动 OpenCode直接说把这段逻辑改成异步方式保持对外接口不变先给我一个修改计划它会通过/plan给出计划确认后继续往下走进入实际操作。改完后我不急着提交先在终端里看一次git diff确认 AI 的改动是否符合预期有不对的地方直接在对话里纠正让它基于 diff 结果再调整。最后跑一遍测试没问题就执行git add . opencode run 根据当前改动生成一份标准的 commit message把 AI 生成的提交信息稍微润色一下就可以提交了。整体下来的感受是OpenCode 不是一个替你决策的工具而是一个帮你节省大量机械操作的执行器从“看懂当前状态”到“生成改动”再到“产出提交信息”它都能参与但每个环节的关键判断点仍然掌握在你自己手里。5. 常见问题与 Windows 专属避坑指南5.1 安装与启动阶段的问题opencode 命令找不到刚安装完就提示“不是内部或外部命令”九成是 npm 全局目录没在 PATH 里。按前面说的npm config get prefix找到路径手动加入用户环境变量即可。这个坑在 Windows 上极其常见因为它不像 macOS/Linux 那样默认把用户级 bin 目录加入 PATH。npm 安装时报 EPERM 错误权限不足导致常见于公司电脑上默认用户不是管理员的情况。不用想复杂直接以管理员身份重新打开 PowerShell 再执行安装命令。要避免长期用管理员权限跑日常命令装完工具之后就把窗口关掉回到普通权限会话里继续工作。执行 setup.ps1 提示禁止运行脚本未调整 PowerShell 执行策略导致的。解决办法在环境准备部分已经提过运行Set-ExecutionPolicy RemoteSigned -Scope CurrentUser后再试。Node 版本不匹配导致 OpenCode 启动闪退直接检查node -v如果主版本低于 18建议升级后重试。OpenCode 对 Node 版本的依赖比一般 CLI 工具更敏感版本过低时会在启动阶段报各种看不懂的运行时错误。用 nvm-windows 切到 Node 20 是最省心的选择。5.2 模型调用与 GLM 接入的问题提示找不到 API key环境变量没生效常见原因是不是没重开终端导致新设置的变量没加载另一个原因是 setx 之后当前会话不会自动变量更新必须开新窗口验证。另外检查一下拼写准确的环境变量名是ZHIPU_API_KEY多一个下划线或者大小写差异都会导致读不到。返回 401 或 403 错误API Key 错误或者被停用。去开放平台控制台重新复制一遍 Key确认没有多余空格再检查账户是否欠费或触发风控。返回 429 或限流提示请求频率太高。免费额度的并发限制比较低如果遇到批量任务并发跑可以直接降低任务并发数或者在 OpenCode 配置里调长请求间隙。日常交互式使用基本不会触发这个限制大多都是脚本批量调用时才会撞上。终端中文乱码Windows 终端处理 UTF-8 输出偶尔会乱码尤其是在旧版控制台里。推荐直接用 Windows Terminal然后在执行 OpenCode 前把代码页切到 UTF-8chcp 65001如果还需要更彻底一点可以设置控制台编码[Console]::OutputEncoding [System.Text.Encoding]::UTF8实测用 Windows Terminal 的场景下大多不需要额外设置这个问题在旧控制台上更明显。5.3 实在的经验建议不要把 API Key 写进项目文件夹里的配置文件再提交到 git。我见过有同事把 OpenCode 的配置整个提交进仓库结果 API Key 直接暴露。正确做法是把项目级的.opencode加入.gitignore公共规范另外放到独立仓库管理私人的 Key 统一走环境变量。Windows 上默认的终端和 PowerShell 对 OpenCode 的交互体验有一定差异。我实际用下来Windows Terminal 的体验是明显优于默认控制台的不仅仅是界面美观的问题渲染速度、字体清晰度还有多标签管理都更舒服。建议花十分钟把 Windows Terminal 装好并设置为默认终端对后续所有终端下的 AI 使用体验都有提升。6. 这套组合还能往哪些方向继续延伸6.1 接入自有工具链OpenCode 支持 MCP 服务端接入你可以通过 MCP 把内部文档、公司私有服务、测试平台这类东西暴露给 AI 调用。在 Windows 上用 MCP 服务器需要注意路径里的反斜杠问题MCP 配置一般要求绝对路径建议统一使用规范格式的路径字符串避免某些解析器把反斜杠当转义符处理。配置完成之后AI 就能在对话中直接查询内部系统实现更深度的人机协作。6.2 把同一个配置扩展到 IDE 和自动化流水线不要以为这套配置只属于终端。OpenCode 的配置文件是标准 JSONoh-my-opencode 里的工作流是 Markdown 模板这些都可以归档到团队的仓库里作为团队内部的 AI 协作规范。在 CI 环境里也可以调用 OpenCode 的非交互模式例如每次合并请求前自动跑一轮代码审查把问题列表输出到评论里达到“轻量 AI 门禁”的效果。6.3 多模型并存与动态切换oh-my-opencode 的核心思路就是管理多样性它不限制你只用一个供应商。GLM 作为日常主力之外你完全可以继续在配置文件里加其他模型供应商不同任务走不同模型核心的复杂任务用能力更强的模型简单重复任务用轻量模型省成本。这些切换在 OpenCode 交互界面里只需要几步按键操作配置上也没有额外负担。我自己的习惯是日常开发互动用 GLM-4.6批量生成和简单重构用轻量的 GLM 版本这样既保证质量也控制住了成本。Windows 下终端和模型配置之间其实没有太大沟壑跳过去之后会觉得整个开发流程顺畅了很多。