企业官网建设流程全解析

1. Windows 下 Gemini CLI 跑 Jeecg skills 的波浪号路径血案

如果你正在 Windows PowerShell 里用 Gemini CLI 替代 Claude 驱动 JeecgBoot 的 skills，大概率会遇到一个非常隐蔽的坑：配置文件里写了~/.gemini/config.toml或者 skills 路径里带了~，结果 Gemini CLI 报「找不到文件」「skills 未加载」「config 解析失败」。表面看是路径写错了，实际上是 PowerShell 对波浪号~的展开规则和 Gemini CLI 内部的路径解析逻辑打架了。

这篇就围绕这个具体问题展开：先复现报错，再给出可复制的config.toml骨架和路径转义写法，最后一步步验证 Jeecg skills 能不能正常跑通。适合已经在 Windows 上装了 Gemini CLI、想把 JeecgBoot 的jeecg-codegen、jeecg-onlform、jimureport这类 skills 迁过来的人。核心检索词就三个：Gemini CLI、Jeecg skills、PowerShell 波浪号路径。下面所有命令和配置都可以直接抄。

2. 前置：TaoToken 接入与 Gemini CLI 环境确认

在动config.toml之前，先把模型接入这层理清楚。Gemini CLI 本身只是个壳，真正干活的是背后的模型服务。我这边用的是 TaoToken 的 API 来承接 Gemini 系列模型调用，好处是 key 管理和计费都在一个控制台里，切换模型不用改一堆环境变量。

你需要先去控制台拿一个 API Key，地址是 https://taotoken.net/api-keys ，登录后新建一个 key，复制出来。注意这个 key 只在创建时完整显示一次，丢了就重新建。

拿到 key 之后，Gemini CLI 侧一般通过环境变量注入。PowerShell 里临时设置（当前会话有效）：

$env:TAOTOKEN_API_KEY = "sk-你的key" $env:TAOTOKEN_BASE_URL = "https://taotoken.net/api"

如果你想让它在所有终端生效，用setx：

setx TAOTOKEN_API_KEY "sk-你的key" setx TAOTOKEN_BASE_URL "https://taotoken.net/api"

setx写的是用户级环境变量，新开的终端才会读到，当前窗口不会立即生效，这点别搞混。模型对话能力可以先在 https://taotoken.net/models 里点一下确认 key 能用，再回来配 CLI，能省掉一半排障时间。

环境确认部分，跑这三条：

node -v npm -v gemini --version

Node 建议 18 以上，Gemini CLI 对 Node 版本有要求，太低会直接启动失败。gemini --version能打印版本号，说明 CLI 装好了。如果这条报「无法将 gemini 项识别为 cmdlet」，那是 npm 全局 bin 目录没进 PATH，先解决这个再往下走。

3. 可复制配置：config.toml 骨架与波浪号转义

Gemini CLI 的配置文件默认位置在用户目录下的.gemini文件夹里。问题就出在这：很多教程让你写~/.gemini/config.toml，但在 PowerShell 里，~会被展开成$HOME，也就是C:\Users\你的用户名。而 Gemini CLI 内部读配置时，如果它自己再做一次路径拼接，就可能出现C:\Users\你的用户名\.gemini\C:\Users\你的用户名\.gemini\config.toml这种双重展开的鬼东西，或者干脆定位到一个不存在的路径。

先看一个会出问题的写法（反面教材，别抄）：

# 错误示范：波浪号在 PowerShell 下会被提前展开 [skills] path = "~/.gemini/skills" [model] api_key = "${TAOTOKEN_API_KEY}" base_url = "https://taotoken.net/api"

正确做法是全部用绝对路径，并且用正斜杠或者双反斜杠，避免 PowerShell 和 TOML 双重转义。下面是我实测能跑通的骨架：

# C:\Users\你的用户名\.gemini\config.toml # 全部使用绝对路径，禁止出现 ~ [model] provider = "openai-compatible" api_key = "${TAOTOKEN_API_KEY}" base_url = "https://taotoken.net/api" model = "gemini-2.5-pro" [skills] # 绝对路径，正斜杠写法，PowerShell 和 TOML 都不会二次展开 path = "C:/Users/你的用户名/.gemini/skills" enabled = true [skills.jeecg] # JeecgBoot 相关 skills 单独声明，方便排查 codegen = "C:/Users/你的用户名/.gemini/skills/jeecg-codegen" onlform = "C:/Users/你的用户名/.gemini/skills/jeecg-onlform" jimureport = "C:/Users/你的用户名/.gemini/skills/jimureport" [shell] # 关键：让 CLI 调用 PowerShell 时不要做路径展开 executor = "powershell" no_profile = true

几个要点解释一下。第一，path用正斜杠C:/Users/...，TOML 里反斜杠是转义字符，写C:\Users会被解析成C:Users，这是另一个高频坑。第二，no_profile = true让 PowerShell 跳过用户 profile，避免 profile 里自定义的~别名或者函数干扰路径解析。第三，skills 路径全部写死绝对路径，不要图省事用相对路径，Gemini CLI 的工作目录和 skills 目录经常不在一个盘。

如果你确实想保留波浪号的可读性，那就在 PowerShell 里先手动展开再传给 CLI，比如：

$skillsPath = Join-Path $HOME ".gemini\skills" $env:GEMINI_SKILLS_PATH = $skillsPath

然后在config.toml里引用环境变量：

[skills] path = "${GEMINI_SKILLS_PATH}"

这样波浪号在进入 CLI 之前就已经被 PowerShell 正确展开成绝对路径了，CLI 拿到的就是干净的C:\Users\...，不会再二次处理。

4. 验证请求：复现报错、替换写法、重跑 skills

先复现报错，确认你踩的是同一个坑。在 PowerShell 里直接跑：

gemini skills list

如果输出里出现Skill path not found: ~/.gemini/skills或者Failed to resolve path，那就是波浪号没展开。再跑一条更直接的：

gemini run "使用 jeecg-codegen 生成一个用户表实体"

报错大概率是Cannot locate skill jeecg-codegen，因为 CLI 在~/.gemini/skills下找，而 PowerShell 传过去的路径已经乱了。

替换写法，把config.toml改成第 3 节里的绝对路径版本。改完先验证配置能被正确解析：

gemini config show

这条会打印当前生效的配置。重点看skills.path这一行，如果显示的是C:/Users/你的用户名/.gemini/skills而不是带~的字符串，说明路径这层通了。

接着确认 skills 目录真实存在：

Test-Path "C:/Users/你的用户名/.gemini/skills/jeecg-codegen"

返回True才算数。如果返回False，说明 skills 文件根本没放对地方，先把 Jeecg 的 skills 目录拷过去。

然后重跑 skills 列表：

gemini skills list

正常输出应该类似：

Loaded skills: - jeecg-codegen - jeecg-onlform - jeecg-desform - jimureport - jimubi-bigscreen

看到 Jeecg 相关的 skill 都列出来了，说明加载成功。最后跑一次真实任务验证端到端：

gemini run "使用 jeecg-onlform 创建一个请假申请表单，字段包括姓名、开始时间、结束时间、事由"

如果 CLI 能识别 skill、调用模型、返回表单配置的生成结果，整条链路就通了。我实测下来，路径修对之后，Jeecg 的 codegen 和 onlform 这两个 skill 基本一次过，jimureport 偶尔需要补一句上下文，但不会再报路径错误。

5. 本篇常见错排查

第一个错：config.toml里写了~但没报错，skills 却静默不加载。这种情况最坑，因为 CLI 不报错，你以为加载了其实没有。排查方法是gemini config show看实际解析出的路径，只要不是绝对路径就有问题。

第二个错：路径用了反斜杠C:\Users\...，TOML 解析后变成C:Users...。表现是Test-Path返回False，但你在资源管理器里明明能看到文件夹。改成正斜杠即可。

第三个错：环境变量没生效。setx之后没开新终端，或者config.toml里引用的变量名和实际设置的不一致。用echo $env:TAOTOKEN_API_KEY确认当前会话能读到。

第四个错：skills 目录权限问题。Windows 下如果.gemini文件夹是从别处拷来的，可能带了只读属性，CLI 读取时失败。用attrib -r "C:\Users\你的用户名\.gemini\skills" /s去掉只读。

第五个错：Gemini CLI 版本太老，不支持[skills.jeecg]这种嵌套声明。跑gemini --version确认，低于 0.1.x 的建议升级。

第六个错：PowerShell 执行策略限制。如果 CLI 调用 PowerShell 执行 skill 里的脚本时报「禁止运行脚本」，用Set-ExecutionPolicy -Scope CurrentUser RemoteSigned放开当前用户级别。

6. 接入与排障：API Keys 与文档入口

路径问题解决之后，如果你还想把 Gemini CLI 长期用在 Jeecg 的编码工作流里，建议把 key 和接入配置固定下来。API Key 管理入口在 https://taotoken.net/api-keys ，接入文档在 https://taotoken.net/doc ，里面有 OpenAI 兼容接口的完整参数说明，base_url、model名称这些都能对着查。

模型验证阶段可以直接用 https://taotoken.net/models 里的对话界面测一下gemini-2.5-pro的返回是否符合预期，确认没问题再写进config.toml。如果你打算把 Gemini CLI 当成日常 coding agent 长期跑 Jeecg skills，Coding Plan 页面 https://taotoken.net/coding-plan 里有针对长任务和 Agent 场景的额度方案，比按次调用更适合高频使用。

最后提醒一句：Windows 下所有涉及路径的配置，能写绝对路径就别写波浪号，能用正斜杠就别用反斜杠。这个原则不只适用于 Gemini CLI，任何在 PowerShell 里跑的 Agent 工具都吃这一套。