Skip to content

Commit 290c7b2

Browse files
JusterZhuclaude
andauthored
feat(docs): rewrite agent-skills pages for newcomer-friendliness (#129)
Overview: fix repo reference to generalupdate-skill-codegen, add 'What is an Agent Skill?' concept section, add multi-AI-tool integration guide (Claude Code, Copilot, Cursor, Windsurf, etc.) generalupdate-init: rewrite for beginners — explain dual-process architecture, lead with inline term explanations, progressive code examples (3-line first, full config second), table explains 'why' each required field exists. generalupdate-ui: rewrite for beginners — clarify Client vs Upgrade role, simplify to 4 key states, add console progress bar example. generalupdate-strategy: rewrite for beginners — explain strategy essence (3 questions), quick picker table, per-strategy use-case/flow/pros-cons layout. English i18n: sync all changes. Co-authored-by: Claude <noreply@anthropic.com>
1 parent ed95103 commit 290c7b2

8 files changed

Lines changed: 1096 additions & 1167 deletions

File tree

website/docs/agent-skills/generalupdate-init.md

Lines changed: 169 additions & 258 deletions
Large diffs are not rendered by default.

website/docs/agent-skills/generalupdate-strategy.md

Lines changed: 120 additions & 156 deletions
Original file line numberDiff line numberDiff line change
@@ -4,203 +4,167 @@ sidebar_label: ⚙️ 策略指南
44
title: ⚙️ generalupdate-strategy — 更新策略指南
55
---
66

7-
# ⚙️ GeneralUpdate 更新策略完全指南
7+
# ⚙️ 选择你的更新策略
88

9-
> ⚠️ **针对 NuGet v10.5.0-beta.4**。该版本使用 `UpdateRequest` 配置,支持可编程 `Option` 系统。
9+
更新策略 = GeneralUpdate 用什么方式来发现和下载新版本。
10+
11+
根据你有没有后端服务、是否需要节省带宽、是否需要用户感知,选择一个适合你的策略。
1012

1113
---
1214

13-
## 📋 用户需求提取
15+
## 先理解:更新策略的本质
16+
17+
不管哪种策略,最终都是回答 3 个问题:
1418

1519
```
16-
### 部署环境
17-
- 是否有后端服务: ______(是/否/计划中)
18-
- 服务端类型: ______(GeneralSpacestation / 自定义 API / S3/MinIO / 无)
19-
- 客户端数量: ______(几十/几百/几千/万+)
20-
- 客户端是否 7×24 运行: ______(是/否)
20+
① 去哪查有没有新版本? ② 去哪下载更新包? ③ 怎么下载?
21+
│ │ │
22+
├ 自己查(轮询) ├ 自己的服务器 ├ 全量下载
23+
├ 服务端通知(推送) ├ 对象存储 OSS └ 只下载差异部分
24+
└ └
25+
```
2126

22-
### 更新需求
23-
- 是否需要节省带宽: ______(是/否 → 推荐差分)
24-
- 是否需要跳过中间版本: ______(是/否 → 推荐 CVP)
25-
- 是否需要服务端主动触发: ______(是/否 → 推荐 SignalR)
26-
- 是否需要用户无感知: ______(是/否 → 推荐静默)
27-
- 是否需要显示更新进度: ______(是/否 → 推荐标准 + UI)
27+
---
2828

29-
### 约束条件
30-
- 目标平台: ______(Windows/Linux/macOS/多平台)
31-
- 网络环境: ______(内网/公网/离线)
32-
- 是否需要崩溃恢复: ______(是/否 → 配合 Bowl)
33-
```
29+
## 策略快速选择表
30+
31+
看不懂术语没关系,先看这一列就行:
32+
33+
| 你的情况 | 推荐策略 | 一句话说明 |
34+
|----------|---------|-----------|
35+
| **有后端服务,新手入门** | **① 标准** | 最简单的方案,服务端返回版本信息,客户端下载更新 |
36+
| **没有后端,只想把包放云存储** | **② OSS** | 把更新包上传到 S3/MinIO,零服务端成本 |
37+
| **带宽有限,用户量大** | **④ 差分** | 每次只下载有变化的部分,省 60-90% 流量 |
38+
| **需要强制用户升到最新(跳过中间版本)** | **⑤ 跨版本** | 用户从 v1.0 直升 v3.0,不用逐个版本升 |
39+
| **用户无感知自动更新** | **③ 静默** | 后台下载完,下次启动自动生效 |
40+
| **需要紧急推送安全补丁** | **⑥ 推送** | 服务端主动告诉客户端"立刻更新" |
3441

3542
---
3643

37-
## 策略决策树(详细版)
38-
39-
```
40-
你的应用有后端服务吗?
41-
├── 有
42-
│ ├── 需要服务端主动推送更新?
43-
│ │ └── YES → ⑥ SignalR 推送(需额外部署 SignalR Hub)
44-
│ └── NO
45-
│ ├── 需要节省下载带宽?
46-
│ │ ├── YES → ④ 差分更新(生成补丁包,减少 60-90% 体积)
47-
│ │ └── NO
48-
│ │ ├── 需要跳过中间版本直达最新?
49-
│ │ │ ├── YES → ⑤ 跨版本 CVP(需服务端额外构建)
50-
│ │ │ └── NO
51-
│ │ │ └── ① 标准客户端-服务端(推荐新手入门)
52-
│ └── 需要后台无声升级?
53-
│ └── YES → ③ 静默更新(基于标准或 OSS + 定时轮询)
54-
55-
└── 没有(只有对象存储 S3/MinIO)
56-
├── 需要节省带宽?
57-
│ ├── YES → ④ 差分更新(OSS + 差分补丁)
58-
│ └── NO
59-
│ └── ② OSS 标准(最低成本,零服务端)
60-
61-
└── 需要后台无声升级?
62-
└── YES → ③ 静默更新(OSS + 定时检查)
63-
64-
### 混合策略组合
65-
66-
常见组合方案:
67-
| 场景 | 策略组合 | 说明 |
68-
|------|---------|------|
69-
| 标准 Web 应用 | ① 标准 + 🎨 UI | 有后端,显示进度 |
70-
| 无服务端节省带宽 | ② OSS + ④ 差分 | 零服务端 + 增量更新 |
71-
| 长期运行后台服务 | ③ 静默(基于 ① 或 ②) | 用户无感知 |
72-
| 强制升级 | ⑤ CVP + ⑥ SignalR | 跳过旧版本,主动推送 |
73-
| 企业级高可靠 | ① 标准 + Bowl + ③ 静默 | 完整链路 |
44+
## 逐个策略详解
45+
46+
### ① 标准客户端-服务端(推荐新手入门)
47+
48+
**适用场景**:你有后端服务(如 GeneralSpacestation),想快速实现自动更新。
49+
50+
```
51+
流程:客户端 → 问服务端"有新版本吗?"
52+
服务端 → 返回版本列表
53+
客户端 → 下载更新包 → 启动升级
7454
```
7555

76-
---
56+
**优点**:实现最简单,1 个 API 接口就能跑起来
57+
**缺点**:需要部署和维护后端服务
7758

78-
## 6 种策略详细对比
59+
### ② OSS 对象存储
7960

80-
| 策略 | 服务端 | 说明 |
81-
|------|:------:|------|
82-
| **① 标准客户端-服务端** | ✅ GeneralSpacestation | 有后端的中大型应用(推荐入门) |
83-
| **② OSS 对象存储** | ❌ 仅 S3/MinIO | 无后端,最低成本 |
84-
| **③ 静默更新** | ✅ 同①或② | 后台无声升级 |
85-
| **④ 差分更新** | ✅ 需差分构建 | 增量补丁节省带宽 |
86-
| **⑤ 跨版本 CVP** | ✅ 需 CVP 构建 | 跳过中间版本直跳 |
87-
| **⑥ SignalR 推送** | ✅ 需 SignalR Hub | 服务端主动推送 |
61+
**适用场景**:你没有后端服务,但有对象存储(阿里云 OSS / AWS S3 / MinIO)。
8862

89-
---
63+
```
64+
流程:客户端 → 定期读取 OSS 上的 versions.json
65+
OSS → 返回版本列表
66+
客户端 → 从 OSS 下载更新包 → 启动升级
67+
```
9068

91-
## 集成代码
69+
**优点**:零服务端,成本最低
70+
**缺点**:不区分主程序和升级程序的更新包;Bucket 要设置好权限
9271

93-
所有策略使用相同的配置模式:
72+
### ③ 静默更新
9473

95-
```csharp
96-
using GeneralUpdate.Core;
97-
using GeneralUpdate.Core.Configuration;
74+
**适用场景**:用户不需要看到更新过程,后台静默完成。
9875

99-
var config = new UpdateRequest
100-
{
101-
UpdateUrl = "https://your-server.com/api",
102-
AppSecretKey = "your-secret-key",
103-
MainAppName = "MyApp.exe",
104-
ClientVersion = "1.0.0.0",
105-
ProductId = "my-product-001",
106-
InstallPath = ".",
107-
};
76+
```
77+
流程:客户端在后台定期检查 → 发现新版本 → 静默下载
78+
下载完成后 → 通知用户"更新已下载,是否重启?"
79+
或:下次启动时自动生效
80+
```
81+
82+
**优点**:用户体验好,不打扰
83+
**缺点**:需要处理"下载完但用户不重启"的版本状态
84+
**轮询频率建议**:30-60 分钟一次(太短耗电/流量,太长用户等得久)
85+
86+
### ④ 差分更新
87+
88+
**适用场景**:你的更新包很大(>100MB),用户量多,想省带宽。
10889

109-
await new GeneralUpdateBootstrap()
110-
.SetConfig(config)
111-
.AddListener*(...)
112-
.LaunchAsync();
11390
```
91+
流程:服务端生成"补丁"(只记录新旧版本之间的差异)
92+
客户端下载补丁 → 本地合成新版本
93+
```
94+
95+
**优点**:节省 60-90% 的下载量
96+
**缺点**:服务端需要额外构建差分包;大文件(>2GB)可能触发整数溢出
11497

115-
或使用零配置 `SetSource()` API:
98+
### ⑤ 跨版本更新(CVP)
11699

117-
```csharp
118-
await new GeneralUpdateBootstrap()
119-
.SetSource(
120-
updateUrl: "https://your-server.com/api",
121-
appSecretKey: "your-secret-key")
122-
.AddListenerUpdateInfo(...)
123-
.LaunchAsync();
100+
**适用场景**:你的用户版本分散(有人还在 v1.0,有人是 v2.5),都需要升到 v3.0。
101+
102+
```
103+
流程:服务端保留所有版本的升级路径
104+
v1.0 用户 → 直接下载 v3.0 全量包
105+
v2.5 用户 → 只下载 v2.5→v3.0 的差分包
124106
```
125107

126-
具体示例参见 `examples/` 目录下的策略文件。
108+
**优点**:用户不用逐个版本升级
109+
**缺点**:服务端需要额外构建和维护版本跳转逻辑
127110

128-
---
111+
### ⑥ SignalR 推送
129112

130-
## 平台特定差异
113+
**适用场景**:需要紧急推送安全修复,不能让用户等轮询。
131114

132-
| 平台 | 特性 |
133-
|------|------|
134-
| **Windows** | 完整功能 |
135-
| **Linux** | 部分功能(无 Bowl) |
136-
| **macOS** | 同 Linux |
115+
```
116+
流程:服务端通过 SignalR 连接主动推送"有新版本"
117+
客户端立刻开始下载更新
118+
```
119+
120+
**优点**:实时推送,秒级响应
121+
**缺点**:需要额外部署 SignalR Hub;断线后要回退到轮询
137122

138123
---
139124

140-
## 已知问题
125+
## 混合策略组合
141126

142-
| # | 问题 | 规避方案 |
143-
|---|------|---------|
144-
| 1 | OSS 模式不区分 Main/Upgrade 更新 | 接受此行为 |
145-
| 2 | UpgradeApp.exe 必须放在 update/ 子目录 | 按规范部署 |
146-
| 3 | NuGet 版本冲突导致 "Method not found" | Client 和 Upgrade 使用相同版本号 |
147-
| 4 | 无限升级循环 | 确保 manifest.json 版本号正确 |
148-
| 5 | SignalR HubConnection Dispose 后重连崩溃 | Dispose 时将连接置 null |
127+
实际项目中,这些策略可以组合使用:
128+
129+
| 组合 | 适合谁 | 怎么做 |
130+
|------|--------|--------|
131+
| ① 标准 + UI | 几乎所有人 | 标准检查 + 显示下载进度条 |
132+
| ② OSS + ④ 差分 | 无后端 + 省带宽 | 更新包放 OSS,只下载差量 |
133+
| ③ 静默 + ① 标准 | 后台服务 | 定时间隔检查,后台下载 |
134+
| ⑤ 跨版本 + ⑥ 推送 | 强制升级 | 服务端推送"请立即更新",跳过所有中间版本 |
149135

150136
---
151137

152-
## ✅ 策略选择验证清单
153-
154-
### 策略匹配度
155-
- [ ] 选定的策略与部署环境匹配(有后端→标准/无后端→OSS)
156-
- [ ] 带宽需求与策略匹配(大文件→差分,版本多→CVP)
157-
- [ ] 用户体验目标与策略匹配(需要交互→标准+UI,后台→静默)
158-
- [ ] 平台兼容性确认(Linux/macOS 不支持 Bowl)
159-
160-
### OSS 策略
161-
- [ ] Bucket 权限设置为私有
162-
- [ ] 更新包的 URL 可公开访问或使用预签名 URL
163-
- [ ] Upgrade.exe 放在 `update/` 子目录(OSS 特有要求)
164-
- [ ] 没有区分 Main/Upgrade 独立更新包(OSS 限制,接受)
165-
166-
### 静默策略
167-
- [ ] 轮询间隔合理(建议 30-60 分钟,太短耗电/流量)
168-
- [ ] 有"新版本可用"的系统通知或托盘图标提示
169-
- [ ] 下载完成后再通知用户重启,而非下载前
170-
- [ ] 后台下载有流量/电量优化(WiFi 下才下载大包)
171-
172-
### SignalR 推送
173-
- [ ] HubConnection 的生命周期管理完善
174-
- [ ] 重连逻辑(自动重试 3 次,间隔递增)
175-
- [ ] Dispose 时将 HubConnection 置 null(否则重连崩溃)
176-
- [ ] 推送消息有超时保护和降级策略(推送失败→回退到轮询)
177-
178-
### 差分策略
179-
- [ ] 服务端有差分包生成机制(`DifferentialCore.CleanAsync`
180-
- [ ] 客户端 Pipeline 配置了 PatchMiddleware
181-
- [ ] 注意大文件差分可能触发的整数溢出(v10.4.6 已修复)
182-
- [ ] Linux/macOS 上 BSDIFF 补丁兼容性已验证
138+
## 如果你不确定选哪个
139+
140+
```
141+
有后端服务?
142+
├── 是 → ① 标准(先跑起来再说)
143+
│ 以后需要时再加 ④ 差分 或 ③ 静默
144+
145+
└── 否 → ② OSS(零成本起步)
146+
把更新包上传到 S3/MinIO
147+
```
148+
149+
**这个方案不会错**。先跑通再优化。
183150

184151
---
185152

186-
## ⚠️ 反模式清单
153+
## 需要留意的事情
187154

188-
| # | 反模式 | 后果 | 正确做法 |
189-
|---|--------|------|---------|
190-
| 1 | **有后端却选 OSS** | 浪费后端服务能力,失去版本管理 | 有后端 → 标准策略 |
191-
| 2 | **低频轮询(每天 1 次)** | 用户等很久才收到更新 | 静默模式 30-60 分钟轮询 |
192-
| 3 | **高频轮询(每分钟 1 次)** | 浪费带宽和电池 | 静默模式建议 ≥ 30 分钟 |
193-
| 4 | **SignalR 连接永不释放** | 内存泄漏 | 页面/应用关闭时 Dispose HubConnection |
194-
| 5 | **差分包太大(> 2GB)** | 整数溢出导致进程崩溃 | 分多个版本发布,或用全量包 |
195-
| 6 | **CVP 跳版本不测试中间版本 API 变更** | 客户端数据迁移失败 | 在服务端做好版本兼容测试 |
196-
| 7 | **OSS 包名不包含版本号** | 客户端版本比较逻辑异常 | `MyApp_1.0.0.0.zip` 格式命名 |
197-
| 8 | **静默更新后不通知用户重启** | 用户不知道新版本已下载 | 下载完成后通知 + 延迟重启选项 |
155+
| # | 问题 | 建议 |
156+
|---|------|------|
157+
| 1 | NuGet 版本不一致导致 "Method not found" | Client 和 Upgrade 的 NuGet 版本必须**完全一致** |
158+
| 2 | OSS 模式不区分 Main/Upgrade 更新 | 这是 OSS 的正常限制,接受即可 |
159+
| 3 | 升级程序必须放在 update/ 子目录 | 从第一个版本就建好这个目录结构 |
160+
| 4 | Linux/macOS 不支持 Bowl 崩溃守护 | 只有 Windows 可以用 Bowl |
161+
| 5 | 差分包不要超过 2GB | 大文件用全量包 |
198162

199163
---
200164

201-
## 相关技能
165+
## 相关页面
202166

203-
- `/generalupdate-init`如果还未配置 Bootstrap
204-
- `/generalupdate-ui`如果需要更新界面
205-
- `/generalupdate-troubleshoot`如果遇到问题
206-
- `/generalupdate-advanced`高级定制
167+
- [generalupdate-init](generalupdate-init) — Bootstrap 配置
168+
- [generalupdate-ui](generalupdate-ui)更新界面
169+
- [generalupdate-advanced](generalupdate-advanced)高级定制
170+
- [generalupdate-troubleshoot](generalupdate-troubleshoot)遇到问题

0 commit comments

Comments
 (0)