1. 内网无 Git 托管时，JAR 部署 Jenkins 到底卡在哪
内网离线开发最典型的场景是这样的：代码只存在本地 IDEA 或 Cursor 工程目录里，没有 GitLab、没有 Gitee、也没有 SVN，团队约定“谁开发谁打包”。但服务端又确实需要一套自动化的部署入口，于是 Jenkins 被拉来当“中转站”——它不编译代码，只负责把本地打好的 JAR 推到业务服务器并重启进程。
这个链路听起来简单，真正落地时会撞上三个硬问题。第一，Jenkins 默认的“源码管理 + Maven 构建”流程完全用不上，因为源码根本不在仓库里，任务里必须把 Git 和 Maven 步骤全部删掉，否则 Build Now 会重新编译，把你本地辛苦打好的 JAR 覆盖成一份旧代码产物。第二，内网没有外网，Jenkins 插件市场打不开，Publish Over SSH 这类必需插件得提前离线下载 hpi 文件手动安装。第三，本地 IDE 到 Jenkins 的上传、触发、结果回读，全靠 HTTP 接口和 Token 鉴权，一旦 CSRF 没关或 Token 权限不对，就会收到 403 或 401。
我试过在一个完全断网的机房里搭这套东西，最深的体会是：Jenkins 在这里的角色不是 CI，而是“带鉴权的文件分发 + 远程命令执行器”。理解这一点，后面三套方案（自研 IDEA 插件、IDEA External Tool、Cursor Skill）本质上都只是“谁来触发本地打包并调用 Jenkins 接口”的差异，后端链路完全一致。
先把统一链路说清楚，三套方案共用：
本地 IDE 打包 JAR → HTTP 上传 JAR 到 Jenkins 任务工作区 → 触发远程构建（带 Token）→ Jenkins 通过 Publish Over SSH 推送 JAR 到业务服务器 → 执行启停脚本（停旧进程、起新 JAR、健康自检）。
这条链路里，Jenkins 任务必须是“空部署任务”：无源码管理、无构建步骤，只保留构建后 SSH 动作。下面先把 Jenkins 侧的一次性前置配置做扎实，再分别讲三套触发方案。
前置配置清单（只做一次）：
安装 Publish Over SSH 插件（离线 hpi 手动上传）；系统配置里录入业务服务器 SSH 账号密码并点“Test Configuration”确认连通；新建自由风格任务，删除源码管理和 Maven 步骤；开启“触发远程构建”并设置 Token，内网环境关闭 CSRF；生成 API Token 用于上传和接口调用；配置后置 SSH 启停脚本。
启停脚本建议直接放在 Jenkins 的 SSH 配置里，内容如下：
# 停止旧 Java 进程 PID=$(ps -ef | grep 'java -jar /opt/app/*.jar' | grep -v grep | awk '{print $2}') if [ -n "$PID" ]; then kill -9 $PID fi # 后台启动新 JAR nohup java -jar /opt/app/*.jar --spring.profiles.active=prod > /opt/app/app.log 2>&1 & sleep 3 # 健康自检 curl -s http://127.0.0.1:8080/actuator/health注意/opt/app目录必须提前在业务服务器上创建好，且与脚本路径一致，否则 SSH 推送会失败。这一步踩过的坑最多，很多人卡在“构建成功但服务没起来”，八成是目录不存在或权限不对。
2. TaoToken 统一 Key 通道：让 IDEA 与 Cursor 的模型调用一次配好
内网离线开发还有一个容易被忽略的痛点：IDEA 和 Cursor 里的 AI 辅助编码、代码补全、对话能力，需要模型 API 通道。如果每个工具各自填一套 Base URL 和 Key，换工具、换人、换机器都要重配，非常碎。TaoToken 在这里的作用就是提供统一的 Key 与 API 通道，把 IDEA、Cursor 等工具的模型调用收敛到一处配置。
它的定位是统一模型调用入口，官网地址是 https://taotoken.net/?utm_source=taotoken_aicg_blog_end&utm_medium=csdn&utm_campaign=rewrite&utm_content= ，API 入口是 https://taotoken.net/api （这个不加 UTM）。你需要先在控制台创建 API Key，控制台地址 https://taotoken.net/console?utm_source=taotoken_aicg_blog_end&utm_medium=csdn&utm_campaign=rewrite&utm_content= ，Key 管理页 https://taotoken.net/api-keys?utm_source=taotoken_aicg_blog_end&utm_medium=csdn&utm_campaign=rewrite&utm_content= 。
配置时三个要素必须齐全：Base URL、API Key、Model ID。缺任何一个都会报鉴权或模型不存在。Base URL 统一填https://taotoken.net/api，Key 填控制台生成的令牌，Model ID 按你实际要用的模型名填。
对于 Cursor，可以在设置里找到模型配置区域，把 OpenAI 兼容的 Base URL 指向 TaoToken，填入 Key 和 Model ID。对于 IDEA 里的 AI 插件（比如 Continue、CodeGPT 这类支持自定义 OpenAI 兼容端点的），同样填这三个值。这样 IDEA 和 Cursor 共用同一个 Key 通道，换机器时只改一处。
如果你用的是 Claude Code 这类工具，接入文档在 https://taotoken.net/doc?utm_source=taotoken_aicg_blog_end&utm_medium=csdn&utm_campaign=rewrite&utm_content= ，里面有对应的 Base URL 和 Key 填写示例。需要说明的是，TaoToken 是合规的模型调用通道，不是任何形式的非法中转，配置时按官方文档填写即可。
统一 Key 通道的价值在内网场景下尤其明显：离线环境里工具装好之后，模型调用配置只需要维护一份，团队里谁换电脑、谁加新工具，照着同一套 Base URL + Key + Model ID 填就行，不用每个工具单独申请。
3. 三套 JAR 一键部署方案的可复制配置
这一节给出三套方案里最关键的配置文件片段，路径和原文保持一致，方便直接复制。
3.1 方案一：自研 IDEA 插件（团队长期最优）
适用团队固定用 IDEA、高频发布、多环境切换。插件基于 IntelliJ Platform SDK，内置配置面板，封装本地 Maven 打包、HTTP 上传 JAR、调用 Jenkins 远程构建 API 三件事。配置持久化用 IDEA 的PersistentStateComponent，存成 XML，路径在项目.idea/下。核心配置结构如下：
{ "jenkinsHost": "http://192.168.1.100:8080", "jenkinsUser": "admin", "jenkinsToken": "你的API令牌", "jobName": "jar-deploy-empty", "buildToken": "deploy666", "env": "prod" }插件里调用 Jenkins 上传和触发的逻辑与脚本方案一致，只是用 Java HTTP Client 实现。优点是集成度最高、零命令、多环境可视化切换；缺点是首次有开发成本，需要打包分发。
3.2 方案二：IDEA External Tool（零开发，免费即用）
单人开发、单环境、想快速落地，用这个。菜单 File → Settings → Tools → External Tools，点“+”新增：
Name 填“一键Jar部署Jenkins”，Program 填sh，Arguments 填$ProjectFileDir$/deploy-jenkins.sh，Working directory 填$ProjectFileDir$。
项目根目录新建deploy-jenkins.sh：
#!/bin/bash # ========== 使用者仅修改以下配置 ========== JENKINS_HOST="http://192.168.1.100:8080" JENKINS_USER="admin" JENKINS_TOKEN="你的API令牌" JOB_NAME="jar-deploy-empty" BUILD_TOKEN="deploy666" # ======================================== # 1. 本地 Maven 打包 mvn clean package -DskipTests JAR_FILE=$(find target -maxdepth 1 -name "*.jar" | head -n1) if [ -z "$JAR_FILE" ]; then echo "打包失败，未找到JAR包！" exit 1 fi # 2. 上传 JAR 到 Jenkins 工作目录 curl -X POST -u ${JENKINS_USER}:${JENKINS_TOKEN} \ -F "file=@${JAR_FILE}" \ ${JENKINS_HOST}/job/${JOB_NAME}/ws/upload.jar # 3. 触发 Jenkins 构建 curl -u ${JENKINS_USER}:${JENKINS_TOKEN} \ ${JENKINS_HOST}/job/${JOB_NAME}/build?token=${BUILD_TOKEN} echo "打包上传完成，Jenkins 将自动下发至业务服务器"使用方式：项目右键 → External Tools → 点“一键Jar部署Jenkins”。优点是零开发、原生支持、配置一次永久用；缺点是换电脑要重配，多环境要手动改脚本参数。
3.3 方案三：Cursor Skill（云端保存，跨设备复用）
用 Cursor、多设备办公、想云端同步脚本，选这个。Cursor 左侧边栏 → Skills → Create New Skill，类型选 Shell Script，命名“内网JAR一键部署Jenkins”，粘贴：
#!/bin/bash # Cursor Skill：一键部署，支持环境切换 ENV=$1 if [ "$ENV" = "test" ]; then JENKINS_HOST="http://192.168.1.100:8080" JOB_NAME="test-jar-deploy" else JENKINS_HOST="http://192.168.1.200:8080" JOB_NAME="prod-jar-deploy" fi JENKINS_USER="admin" JENKINS_API_TOKEN="你的API令牌" BUILD_TRIGGER_TOKEN="deploy888" echo "===== 开始本地 Maven 打包 =====" mvn clean package -DskipTests JAR_FILE=$(find target -name "*.jar" | head -n1) [ -z "$JAR_FILE" ] && echo "JAR不存在，打包终止" && exit 1 echo "===== 上传 JAR 至 Jenkins =====" curl -s -X POST -u ${JENKINS_USER}:${JENKINS_API_TOKEN} \ -F "file=@${JAR_FILE}" \ ${JENKINS_HOST}/job/${JOB_NAME}/ws/upload.jar echo "===== 触发远程构建 =====" curl -s ${JENKINS_HOST}/job/${JOB_NAME}/build?token=${BUILD_TRIGGER_TOKEN} sleep 4 BUILD_RESULT=$(curl -s -u ${JENKINS_USER}:${JENKINS_API_TOKEN} \ ${JENKINS_HOST}/job/${JOB_NAME}/lastBuild/api/json | jq -r '.result') if [ "$BUILD_RESULT" = "SUCCESS" ]; then echo "远端服务部署启动成功" else echo "部署失败，请查看 Jenkins 控制台日志" fi使用方式：打开项目 → 选中 Skill → 输入环境参数（test/prod）→ 运行。优点是脚本云端存储、跨设备免重配、支持参数切换环境；缺点是必须用 Cursor，团队要统一编辑器。
三套方案横向对比：
| 方案 | 开发成本 | 跨设备复用 | 多环境适配 | 适用场景 |
|---|---|---|---|---|
| 自研 IDEA 插件 | 高 | 支持（分发） | 极佳（可视化切换） | 团队长期迭代，IDEA 统一 |
| IDEA External Tool | 零 | 需手动导出配置 | 一般（改脚本） | 单人开发，固定单环境 |
| Cursor Skill | 零 | 云端自动同步 | 优秀（入参切换） | 团队统一 Cursor，多环境频繁发布 |
4. 验证请求与成功结果：连通性怎么确认
配置完不等于能用，必须做连通性验证。分三层：本地打包、Jenkins 上传触发、远端服务健康。
第一层，本地打包验证。在项目根目录执行mvn clean package -DskipTests，确认target/下生成了 JAR。如果这一步失败，后面全免谈。
第二层，Jenkins 接口验证。先用 curl 单独测上传和触发，排除脚本封装带来的干扰：
# 测试上传 curl -v -X POST -u admin:你的API令牌 \ -F "file=@target/app.jar" \ http://192.168.1.100:8080/job/jar-deploy-empty/ws/upload.jar # 测试触发 curl -v -u admin:你的API令牌 \ http://192.168.1.100:8080/job/jar-deploy-empty/build?token=deploy666上传成功会返回 200 或 201，触发成功返回 201 或 302。如果返回 403，检查 CSRF 是否关闭；返回 401，检查 Token 是否正确。
第三层，远端服务健康。Jenkins 构建完成后，在业务服务器上执行：
curl -s http://127.0.0.1:8080/actuator/health返回{"status":"UP"}说明新 JAR 已正常启动。同时可以看 Jenkins 控制台日志，确认 SSH 推送和启停脚本执行没有报错。
对于 TaoToken 的模型调用通道，验证方式是发一个最小请求。以 OpenAI 兼容接口为例：
curl -s https://taotoken.net/api/v1/chat/completions \ -H "Authorization: Bearer 你的Key" \ -H "Content-Type: application/json" \ -d '{"model":"你的ModelID","messages":[{"role":"user","content":"ping"}]}'返回正常 JSON 说明 Base URL、Key、Model ID 三要素都对。如果报 401，检查 Key；报模型不存在，检查 Model ID 拼写。
5. 本篇常见错排查：401、403、local proxy failed 与 OAuth
实际部署时，报错集中在几个固定位置，逐个对照。
401 Unauthorized：出现在 Jenkins 接口或 TaoToken 调用。Jenkins 侧多半是 API Token 填错或用了登录密码代替 Token；TaoToken 侧是 Key 无效或没带Bearer前缀。检查-u user:token里的 token 是不是控制台生成的 API Token，而不是登录密码。
403 Forbidden：内网 Jenkins 最常见。原因是 CSRF 跨站校验没关，接口调用和文件上传被拦。解决方式是在 Jenkins 全局安全配置里关闭“防止跨站点请求伪造”，内网环境可以这么做。另外检查 Token 权限是否最小化到只开放上传和构建。
local proxy failed：这个报错通常出现在工具侧配置了本地代理但代理不可达。内网离线环境里，如果 IDE 或 Cursor 的模型调用配置里残留了本地代理地址，就会报这个。解决方式是清掉代理设置，Base URL 直接指向https://taotoken.net/api，不要经过任何本地转发。
reading choices 相关报错：一般是模型返回结构不符合预期，常见于 Model ID 填错或接口路径不对。确认 Base URL 是https://taotoken.net/api，请求路径是/v1/chat/completions，Model ID 与控制台一致。
OAuth 报错：如果工具走的是 OAuth 授权流程而不是 API Key，会提示 OAuth 失败。内网场景建议统一用 API Key 方式，不走 OAuth。Claude Code 这类工具的接入方式在文档 https://taotoken.net/doc?utm_source=taotoken_aicg_blog_end&utm_medium=csdn&utm_campaign=rewrite&utm_content= 里有说明，按文档填 Base URL 和 Key。
JAR 上传后服务没更新：检查 Jenkins 任务里是否残留了 Maven 构建步骤。如果有，Build Now 会重新编译覆盖你上传的 JAR。正确做法是任务里只保留 SSH 后置动作。
Windows 下 jq 命令找不到：方案三依赖 jq 解析 Jenkins JSON 返回。Windows 需要单独安装 jq 并加入 PATH，否则轮询结果那一步会失败。
SSH 推送失败：检查 Publish Over SSH 的连通性测试是否通过，业务服务器/opt/app目录是否存在且有写权限，SSH 账号是否有执行 kill 和 nohup 的权限。
6. 长期编码与 Agent 场景的通道选择
三套 JAR 部署方案解决的是“内网无 Git 托管下怎么把本地产物推到服务器”的问题，而 IDEA、Cursor 里的模型调用解决的是“开发过程中 AI 辅助怎么稳定可用”的问题。两者叠加，才是完整的内网离线开发体验。
如果你的场景是长期编码、频繁用 Agent 类工具，建议把模型调用通道固定下来，用统一的 Base URL + Key + Model ID 配置。Coding Plan 入口在 https://taotoken.net/coding-plan?utm_source=taotoken_aicg_blog_end&utm_medium=csdn&utm_campaign=rewrite&utm_content= ，适合需要长期稳定调用的团队。模型对话验证入口在 https://taotoken.net/chat?utm_source=taotoken_aicg_blog_end&utm_medium=csdn&utm_campaign=rewrite&utm_content= ，可以先用它确认 Key 和 Model ID 可用，再填进 IDE。
回到部署本身，最后给一个实操建议：三套方案里，先用 IDEA External Tool 把链路跑通，确认 Jenkins 空任务、Publish Over SSH、启停脚本都没问题，再决定要不要升级到自研插件或 Cursor Skill。链路本身是通的，换的只是触发载体。把deploy-jenkins.sh里的 JENKINS_HOST、JOB_NAME、BUILD_TOKEN 三个值改成你自己的，右键跑一次，看 Jenkins 控制台日志和业务服务器健康检查，通了就说明整套内网离线部署站住了。
