• 记于：2026-07-19 晚上

背景#

平时用 Git 时，经常会遇到这种情况：

• 正在一个分支上改需求，改到一半；
• 突然来了一个线上问题，要先修 hotfix；
• 或者想同时开两个分支做不同事情；
• 又或者只是想临时拉一个分支下来看看，不想打断当前目录里的开发状态。

以前我一般会想到两种方式：

• git stash 之后切分支；
• 或者直接再 git clone 一份仓库。

这两种方式都能解决问题，但都不算特别舒服。

• stash 容易打断思路；
• 多 clone 一份仓库又比较重，尤其是项目比较大时。

这时候 git worktree 就很适合。

这是什么#

git worktree 可以理解为：

• 同一个 Git 仓库；
• 同时开多个工作目录；
• 每个工作目录可以检出不同分支，各自独立开发。

简单说，它不是让你多出多个仓库，而是让你在同一个仓库上同时拥有多个“工作现场”。

比如现在有一个仓库目录：

1

repo/

可以通过 worktree 再额外开两个目录：

1
2
3

repo/
repo-feature-a/
repo-hotfix-login/

这三个目录可以同时存在，并且分别工作在不同分支上。

有什么用#

我觉得它最直接的价值有几个：

• 不打断当前开发；
• 不需要频繁 stash；
• 不需要重复 clone 大仓库；
• 可以同时打开多个 IDE 窗口，分别处理不同任务；
• 很适合 hotfix、临时验证、并行开发。

比如我正在 master 上看代码，突然要修一个登录超时问题。
这时候没必要先把当前目录折腾一遍，直接新开一个 hotfix 工作树就行。

核心理解#

我觉得学 git worktree，先记住下面这几点就够了。

1. worktree 是“工作目录”，不是“分支”#

worktree 只是一个额外的工作区目录。
真正承载提交历史的，还是 Git 分支。

所以：

• 开新 worktree，本质上通常也是顺手开一个新分支；
• 改完后提交，也是提交到这个分支；
• 后续合并时，合并的是“分支”，不是“工作树目录”。

2. 它解决的是“并行开发”，不是“完全隔离”#

多个 worktree 共享同一个仓库的大部分 Git 数据。
比如提交对象、分支引用、远程信息这些，底层是共享的。

所以它更像：

• 一个仓库底座；
• 多个并行工作目录。

但它不是多个完全独立的 clone。

3. 每个 worktree 都有自己的检出状态#

这意味着：

• 当前目录可以是 master
• 另一个目录可以是 hotfix/login-timeout
• 再另一个目录可以是 feature/payment

它们互不打断，各自改各自的。

常见流程（重点）#

这一部分我觉得最重要，先学会用，再去记别的。

1. 新开一个工作树#

比如现在主目录在 master，我想单独开一个 hotfix 目录：

1

git worktree add -b hotfix/login-timeout ../repo-hotfix-login master

这条命令的意思是：

• 在 ../repo-hotfix-login 创建一个新的工作目录；
• 新建分支 hotfix/login-timeout；
• 这个分支从 master 切出来；
• 并且在新目录里检出这个分支。

2. 去新目录里开发并提交#

1
2
3

cd ../repo-hotfix-login
git add .
git commit -m "fix: login timeout"

到这里为止，主目录里的开发完全不用动。

3. 回主工作树合并#

这里是一个非常关键的点：

不是“合并 worktree”，而是“合并分支”。

比如我要把刚才的 hotfix 合并回 master：

1
2
3

cd ../repo
git switch master
git merge hotfix/login-timeout

如果团队是走 PR 流程，那通常不是本地直接 merge，而是：

1
2

cd ../repo-hotfix-login
git push -u origin hotfix/login-timeout

然后提 PR 到 master。

4. 合并后清理#

确认不再需要这个工作树之后，可以清理：

1
2

git worktree remove ../repo-hotfix-login
git branch -d hotfix/login-timeout

如果分支还没合并，git branch -d 会拒绝删除；
只有确认不需要时，才考虑 git branch -D。

常用命令#

下面这些是最常用的几个。

查看当前有哪些 worktree#

1

git worktree list

示例输出大概像这样：

1
2
3

/Users/you/code/repo               abc1234 [master]
/Users/you/code/repo-feature-a     def5678 [feature/a]
/Users/you/code/repo-hotfix-login  999aaaa [hotfix/login-timeout]

新建 worktree，并创建新分支#

1

git worktree add -b feature/a ../repo-feature-a master

基于已有分支创建 worktree#

1

git worktree add ../repo-release release/1.0

删除 worktree#

1

git worktree remove ../repo-feature-a

清理失效记录#

如果你手工删过目录，Git 里可能还留着 worktree 记录，这时可以：

1

git worktree prune

一个完整示例#

这里写一个我觉得最适合刚开始上手的完整流程。

假设当前目录是主仓库：

1
2

pwd
# /Users/you/code/repo

当前在 master：

1
2

git branch --show-current
# master

现在新开一个 hotfix 工作树：

1

git worktree add -b hotfix/user-status ../repo-hotfix-user-status master

去新目录开发：

1

cd ../repo-hotfix-user-status

改完代码后提交：

1
2

git add .
git commit -m "fix: user status display"

回主目录合并：

1
2
3

cd ../repo
git switch master
git merge hotfix/user-status

最后清理：

1
2

git worktree remove ../repo-hotfix-user-status
git branch -d hotfix/user-status

如果是团队协作场景，那就是把中间的本地合并步骤换成 push + PR。

注意点#

这部分很重要，实际使用时比较容易踩坑。

1. git worktree add 的第一个核心参数是“路径”#

比如：

1

git worktree add feat-a

这里的 feat-a 会被 Git 当成“目录路径”。
如果当前就在仓库目录里执行，那么 Git 会直接在当前目录下面创建一个 feat-a/ 子目录。

如果同时自动创建了同名分支，那么最终效果通常就是：

• 当前目录下多出一个 feat-a/
• 新 worktree 使用分支 feat-a

这个行为本身没问题，但一般不够清爽。
更推荐直接建成同级目录：

1

git worktree add -b feat-a ../repo-feat-a master

2. git worktree remove 删除的是“工作树路径”，不是“分支名”#

例如下面这种写法：

1

git worktree remove feature/login

如果 feature/login 只是分支名，而不是工作树目录路径，那么就会报错。

正确思路应该是：

1
2

git worktree remove ../repo-feature-login
git branch -d feature/login

也就是：

• remove 删除工作树目录
• branch -d 删除分支

3. 删除 worktree 后，分支默认还在#

这点也很容易忽略。

比如：

1

git worktree remove ../repo-feature-a

执行完后：

• worktree 目录没了；
• 但 feature/a 分支通常还在。

如果这个分支后面不需要了，还得再手动删分支。

4. 同一个分支不能同时在多个 worktree 里检出#

比如 feature/a 已经在某个 worktree 中打开了，那么一般不能再在另一个 worktree 中同时检出同一个本地分支。

这个限制本身是合理的，主要是为了避免混乱。

5. git branch 里的 + 表示该分支正在别的 worktree 中被检出#

这个细节顺手记一下也挺有用。

比如：

1
2

* master
+ feature/a

表示：

• master 是当前目录所在分支；
• feature/a 正在别的 worktree 中使用。

6. 不建议把长期 worktree 建在主仓库子目录下#

虽然技术上可以这样做，但从目录管理角度看，容易让主目录里出现额外的未跟踪目录，看起来比较乱。

更推荐的结构是：

1
2
3

repo/
repo-feature-a/
repo-hotfix-login/

而不是：

1
2
3

repo/
  feat-a/
  hotfix-login/

什么时候适合用#

我觉得这些场景特别适合：

• 正在开发时，突然插入 hotfix；
• 同时开多个分支并行开发；
• 想临时验证一个分支，但不想打断当前目录；
• 项目比较大，不想重复 clone；
• 想同时开多个终端 / IDE 窗口处理不同任务。

如果只是偶尔切一下分支，而且当前目录也很干净，那么直接 git switch 也完全够用。

总结#

git worktree 的核心价值，我觉得一句话就够了：

在同一个仓库里，同时拥有多个独立工作目录，用来并行处理不同分支的开发任务。

如果只想先学会用，那我觉得先记住下面这几条就够了：

1
2
3
4

git worktree list
git worktree add -b hotfix/xxx ../repo-hotfix-xxx master
git worktree remove ../repo-hotfix-xxx
git branch -d hotfix/xxx

另外还有一个最容易记混的点：

• worktree 是目录；
• branch 是分支；
• merge 合并的是分支，不是 worktree。

先把这几个动作顺下来，后面再用几次，基本就熟了。

• 记于：2026-07-08 下午
• 地点：浙江省·温州市·家里
• 天气：晴天

背景#

最近想把家里的 PVE 和局域网打通，目标比较明确：

• 家里有一台长期运行的 PVE 宿主机；
• 家里网络是光猫 192.168.1.x，路由器下挂主局域网 192.168.31.x；
• 另外有一台带公网 IP 的云服务器；
• 希望在外面的工作机上，既能访问 PVE 本机，也能访问家里的 192.168.31.0/24 网段。

最开始也看了 frp、WireGuard 等方案，最后还是选择了 EasyTier。主要原因是它更像一个“虚拟局域网”，除了节点互通，还能顺带做子网代理，把家里的整段 LAN 带出来。

整体拓扑#

这次实际采用的是三角色结构：

• VPS：共享节点 / 中继节点
• PVE：正式节点 + 子网代理节点
• 工作机：普通接入节点

逻辑上是这样：

1

工作机 <----> VPS(公网入口) <----> PVE <----> 192.168.31.0/24

这里要注意，VPS 不是传统意义上的“中心 VPN 服务器”，而更像 EasyTier 网络里的公网入口点。能直连时节点会尽量直连，不能直连时再走中继。

地址规划#

为了避免和家里的 192.168.1.x、192.168.31.x 混淆，我单独规划了一段 EasyTier 虚拟网：

• EasyTier 虚拟网：10.100.100.0/24
• PVE：10.100.100.1
• 工作机：10.100.100.2

家里真实局域网仍然保持原样：

• 家庭 LAN：192.168.31.0/24

PVE 通过子网代理，把 192.168.31.0/24 发布到 EasyTier 网络里。

VPS 配置#

VPS 使用 Docker Compose 运行。

docker-compose.yml

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

services:
  easytier:
    image: easytier/easytier:latest
    hostname: easytier
    container_name: easytier
    restart: unless-stopped
    network_mode: host
    cap_add:
      - NET_ADMIN
      - NET_RAW
    environment:
      - TZ=Asia/Shanghai
    devices:
      - /dev/net/tun:/dev/net/tun
    volumes:
      - /etc/machine-id:/etc/machine-id:ro
      - ./conf:/config
    command: >
      -c /config/easytier.toml
      --private-mode true

conf/easytier.toml

1
2
3
4
5
6
7
8

listeners = [
    "tcp://0.0.0.0:11010",
    "udp://0.0.0.0:11010",
]

[network_identity]
network_name = "ysm.easytier"
network_secret = "请替换成自己的强密码"

这里的重点有两个：

• listeners
  表示 VPS 对外监听 11010/tcp 和 11010/udp，作为其他节点的入网入口。
• --private-mode true
  表示这台共享节点只服务自己的这个网络，不对其他 EasyTier 网络开放。

另外，云服务器的安全组和系统防火墙都需要放行：

• 11010/tcp
• 11010/udp

PVE 配置#

PVE 不承担公网入口职责，它只负责两件事：

• 自己加入 EasyTier；
• 把家里的 192.168.31.0/24 带进来。

docker-compose.yml

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

services:
  easytier:
    image: easytier/easytier:latest
    hostname: easytier
    container_name: easytier
    restart: unless-stopped
    network_mode: host
    cap_add:
      - NET_ADMIN
      - NET_RAW
    environment:
      - TZ=Asia/Shanghai
    devices:
      - /dev/net/tun:/dev/net/tun
    volumes:
      - /etc/machine-id:/etc/machine-id:ro
      - ./conf:/config
    command: >
      -c /config/easytier.toml
      --ipv4 10.100.100.1
      --hostname pve.test
      -p tcp://<VPS公网IP>:11010
      -p udp://<VPS公网IP>:11010
      -n 192.168.31.0/24
      --no-listener

conf/easytier.toml

1
2
3

[network_identity]
network_name = "ysm.easytier"
network_secret = "请替换成与 VPS 相同的强密码"

这里几个参数需要重点理解：

• --ipv4 10.100.100.1
  给 PVE 分配固定的 EasyTier 虚拟 IP。
• -p tcp://... / -p udp://...
  告诉 PVE 先去找哪台公网节点入网。
• -n 192.168.31.0/24
  这是子网代理，把家里的主 LAN 发布出去。
• --no-listener
  表示 PVE 不在本机额外监听端口，只主动连出。

最后这个 --no-listener 很重要。因为我的 PVE 宿主机上本来就还有别的服务占用了默认端口，继续让 EasyTier 监听 11010 容易直接报 Address in use。

工作机配置（GUI）#

工作机这边我用的是 EasyTier GUI，没有手写配置文件。

我的配置思路是：

• 网络名：ysm.easytier
• 网络密码：与 VPS、PVE 一致
• 虚拟 IP：固定填 10.100.100.2
• Peer：
  • tcp://<VPS公网IP>:11010
  • udp://<VPS公网IP>:11010

这里不建议工作机用 DHCP 方式，原因有两个：

• 这套网络里我已经手工规划了 10.100.100.0/24；
• 工作机是常用节点，固定 IP 更方便记忆、排障和做书签。

如果工作机只是临时测试机器，用 DHCP 也不是不行，但要注意它不一定会落在我手工规划的 10.100.100.x 上。

验证方式#

节点都起来后，可以先在 VPS 和 PVE 上看状态：

1
2
3

docker exec easytier easytier-cli node
docker exec easytier easytier-cli peer
docker exec easytier easytier-cli route

正常情况下：

• VPS 侧能看到 pve.test
• 路由里能看到 10.100.100.1/24
• 路由里还能看到 192.168.31.0/24

工作机连上后，理论上应该能：

1
2

ping 10.100.100.1
ping 192.168.31.x

其中：

• 10.100.100.1 是 PVE 的 EasyTier 虚拟 IP；
• 192.168.31.x 是通过 PVE 代理出来的家庭内网设备地址。

踩坑记录#

这次实际折腾时踩了几个坑，顺手记一下。

1. PVE 启动时报 Address in use#

最开始直接照着 VPS 的思路给 PVE 配了 listeners，结果启动时报错：

1
2

failed to listen on tcp://0.0.0.0:11010
Address in use

原因是 PVE 本机已经有别的服务占用了默认端口。
解决方式有两个：

• 给 PVE 改监听端口；
• 或者像我这样，直接使用 --no-listener。

对“PVE 只是接入节点 + 子网代理”的场景，后者更简单。

2. 工作机同时连多个 EasyTier 网络时，11010 冲突#

我的工作机 GUI 里原本还连着另一个 EasyTier 网络，启动当前网络时报本地 11010 端口占用。

这里要区分清楚：

• 106.12.x.x:11010
  这是远端 VPS 的端口；
• 0.0.0.0:11010
  这是工作机本地监听端口。

同一台机器上多个 EasyTier 实例不能同时抢同一个本地监听端口。处理办法：

• 给不同网络配置不同本地 listener 端口；
• 或者对纯接入场景的实例关闭 listener。

3. Virtual IPv4: undefined#

工作机一开始用 GUI 的 DHCP 模式时，状态里一直显示：

1

Virtual IPv4: undefined

后来改成固定虚拟 IP 后恢复正常。
所以如果网络拓扑已经比较清晰，固定虚拟 IP 往往更省事。

4. 防火墙一定要放 TCP 和 UDP#

VPS 入口端口要同时开放：

• 11010/tcp
• 11010/udp

只开其中一个，节点可能会表现为不断重试、连接超时或者只能部分建链。

5. 15888 不是组网端口，而是本地管理端口#

这次还遇到一个容易误判的问题：

1
2

failed to connect to server: tcp://127.0.0.1:15888
Connection refused

一开始很容易把它理解成“15888 被占用了”，但其实不是。

15888 是 EasyTier 的本地管理 RPC 端口，不是节点之间真正组网和传输数据的端口。它主要给这些命令或界面使用：

• easytier-cli node
• easytier-cli peer
• easytier-cli route
• GUI 读取本机 EasyTier 实例状态

要和 11010 区分开：

• 11010/tcp、11010/udp
  这是 EasyTier 节点之间真正建链和通信的数据面端口；
• 15888
  这是本机 easytier-cli 去查询 easytier-core 状态的管理面端口。

所以 Connection refused 的真实含义通常是：

• 当前实例没有监听默认的 15888；
• 或者当前实例其实用了别的 RPC 端口；
• 或者实例正在重启，cli 查询时端口还没就绪；
• 或者因为 network_mode: host，同一台机器 / 同一网络命名空间里还有别的 EasyTier 实例，导致默认端口行为混乱。

这里还有一个容易忽略的点：

• 不同机器之间，rpc-portal 可以相同；
• 只有在同一台机器 / 同一网络命名空间里存在多个 EasyTier 实例时，才建议显式区分。

为了排障稳定，最好不要依赖默认 15888，而是显式指定。

例如：

• VPS：--rpc-portal 15889
• PVE：--rpc-portal 15890

查询状态时也显式指定同一个端口：

1
2
3

easytier-cli --rpc-portal 127.0.0.1:15890 node
easytier-cli --rpc-portal 127.0.0.1:15890 peer
easytier-cli --rpc-portal 127.0.0.1:15890 route

一句话总结：

• 15888 是 EasyTier 本地管理端口，不是业务端口；
• Connection refused 表示默认管理端口没人监听，不等于“被占用”；
• 比较稳的做法是给实例显式配置 --rpc-portal，并在 easytier-cli 查询时指定同一个端口。

总结#

这套方案跑通后，效果还是很满意的：

• VPS 负责公网入口；
• PVE 负责把家庭内网带出来；
• 工作机作为普通接入节点；
• 最终既可以访问 10.100.100.1，也可以访问 192.168.31.0/24。

如果只想远程访问家里单个服务，frp 一类工具会更轻。
但如果目标是“把家里局域网整体搬到外面”，EasyTier 确实更顺手。

参考资料#

• EasyTier 官方文档
• EasyTier Github

• 记于：2026-06-14 晚上
• 地点：浙江省·温州市·家里
• 天气：多云

晚饭结束，坐在电脑前处理一些杂事，用手推了一下眼镜，闻到手上的烟熏皮臭味；想了想，记录一下吧。

现在正坐在弟弟家，楼下是村里的龙舟活动宴席，摆台唱歌跳舞，悲喜真是不相通。

昨天晚上，周六，跟往常一样，在自己家里休息着；20:51，来了一通电话，是堂哥的，接听，电话里是急促的声音：“快回来快回来，你（爸妈）家里着火了！”，此时老婆也在家，爸爸在带着娃，我一下子惊了，窜起身，一边跟他们喊话传达，一边跑到门口拿灭火器穿拖鞋，往老家飞奔而去。

我家距离老家直线距离也就百来米，路上看到不断有几个人对向从我身边跑过，身型眼熟，但是天黑认不出；
一分钟左右，跑到大伯家后门（大伯、我爸、我叔三兄弟三间连着的木质砖瓦老房子），此时看到屋顶上方浓烟滚滚，我继续跑到前门，看到中间我爸那间火最大，大家也在帮着救火，我跑过去开门，发现反锁着，踹门也踹不进，发现玻璃已经碎了不少，于是拔了灭火器保险栓就往里喷，喷了10来秒耗尽了，但是基本没效果，里面火很大，我也没法把喷头探进去，这个灭火器是喷嘴在手把上的那种；
丢下灭火器，看到路上远远围了些人，我过去问了下情况～此处记忆有些模糊；
问起妈妈是否在里面/意识到门是锁着的，我妈可能在里面睡觉，顿时有些慌了，一边喊我妈一边跑到后面准备从后门进去，记得此时我爸也已经赶来了，跟他说明了大概情况，说妈妈可能在里面，然后我从后门外卫生间过道跑到后门口，要进去，但是烟往外滚，前面火光很大，楼梯那里应该上不去，退回来了；
然后准备直接爬上后门外卫生间顶部，慌乱下随便找了两个一大一小的桶叠起来，站上去，手扒卫生间顶部外沿，但是一下子使不上劲，手滑了下来；这边不好爬，跑到路侧大伯房子边上，有个水表箱，踩上去，手一抓，使劲爬了上去；
我爸也不知道从哪边爬了上来，卫生间顶部和楼上后窗户之间是塑料棚连接的，我继续喊着我妈，然后跪着爬过去靠近窗户，往里爬想要进去，但此时没想到浓烟的厉害，自然的吸了一口，顿时上呼吸道刺痛，一瞬间我感受到了死亡的威胁，不多想就往回退，看到我爸也正往里爬，我想叫他回来但是下意识张不了嘴，尽快退回无烟处，大声喊，叫我爸回来，他也很快退回来了；
然后，我一时没了主意，在边沿坐了一会儿，看着路上的人群，吵闹声、燃爆声、坍塌声……

过了一会儿，我下去跑向人群，问他们是否看到我妈，我爸也在旁边，我问我爸同时大声喊是否打过119了，说是打过了；
再一会儿，村里的火情应急小三轮车也过来，他们在拉水管，我焦急等待，但是迟迟不出水，我跑向河边停车那里，那个发动机始终拉不起来，无奈至极。

我又跑到后面，问别人是否有看到我妈，都说没看到，心想真的不好了，我妈极有可能在里面；
看到我弟和朋友也来了，简单交流了下情况，我继续跑来跑去反复询问确认；大伯一家也在，也说没看到我妈；
于是，心又冷了下来，站在旁边看人来人往；
救火队不知道什么时候来的，我都没发觉，看到后跑过去跟他们说中间那间可能有人，希望他们能优先救人；
不过他们有自己的判断，一边在前面喷水灭火，一边在后面进去往外拿煤气瓶，我也不好多说，还是在一旁等待；

突然想起来我应该要打个120，万一我妈真在里面，虽然可能人已经没了，但是万一呢；于是拨打了120，说明了情况，让他们赶紧过来；
不知道过了多久，印象中听见有救护车的鸣笛的声音，他们给我打了电话问具体在哪里，我他们问下路人；这边烟和火这么大，一下子就能看到的；
不过后来迟迟没见120人员进来；

再后来，住旁边的舅妈来到旁边，问起我妈，讨论中说起家前门反锁，电瓶车也还在（我妈平时百来米的路都要开电瓶车），又是一阵失落，真的完了；
期间，堂弟也打来电话询问情况，简短交流后挂断；
我叔也赶来了，他的房子是出租的，现在想起，那两个租客，应该是母子吗，那女的大概也有50来岁，之前还往里跑，拼命往外拉一大纸箱的衣服，被几个人强行搀扶出来了。。。我也忘了衣服有没有拿出来，后来她还要继续冲进去～我记得他儿子也赶来了，也要往里冲，说什么东西在里面，不过也被拦住了；
大伯母也是哭天抢地说要进去拿衣服。。。当然也被拉住了；

再后来，反正越聚越多，印象中我一直前后跑来跑去，东看看西问问，持续打我妈电话，一直没打通（她平时就这样），前后打了十几个电话；
然后听到我爸说有人在棋牌室看到我妈，心放下来一些，因为毕竟没见到人；我跟我弟、老婆同步了消息，然后就是等灭火了；

舅妈打电话让朋友在棋牌室那边找找我妈，一会儿，说是没看到，这下又不安了；再次跑去跟消防员说明，中间可能有人，他们说要从旁边进，我继续打电话；
突然，这次电话通了，那边有声音，像我妈的又不太像，信号好像不好，没一会儿就被挂断了；
我继续拨打，占线，然后好像是我妈电话打来，我接了，确定是她，然后跟消防员反馈后就跑去找人了；

有人喊我，说看到我妈了，在后面，我赶紧跑过去，在远处听到我妈的声音，再近些看，确实是我妈，心放下了；
然后再次跟我弟和我老婆同步消息～

我老婆说小舅也来了，但是被拦了进不来；

然后有人跟我问了些话，我站着聊了几句，跟我爸说了声要回去换衣服（当时下雨，衣服湿透了），就回去了；

回去换了衣服，宝宝已经睡了，跟老婆说了几句，又过去（伞都忘记带了）；

接下来也没什么急事了，人没事，剩下的就是等灭完火了；
我婶也来了，应该是跟我叔一起来的，聊了几句；
警察在疏散人员，邻居们不愿意走，在闲聊；

再后来，火灭了，收尾了，拉起警戒线，大家相继散去，警察、消防员、村里干部、路人，大家都散了；
想起来期间有个阿姨，好像是周边的，不过我不认识，她送了些新的衣物过来，人还挺好的；

后来，本来让爸妈去弟弟那边睡的，但是我妈迷信，说是火灾后第一晚不能住（弟弟或我）家里，得去庙里住；我爸也去了；

然后，我也回去了，已经是23点多，继续加班到2点多～赶项目；
大概是3点左右睡的；

然后就是今天了，06-14号，周日。

今天还要带宝宝去复诊，看皮肤过敏，前两天可能被蚊虫叮咬了；

上午小舅和小舅妈来，问了下昨晚的情况，又闲聊了会儿；然后我们3个就去前面看老房子了；
三间房子，我家和大伯家烧毁严重，我家的中间的岩石横向都断开三节，由金属门框抗着，看起来随时会塌；

过去看到我大伯在清理，我叔和邻居在河边榕树下，问了我爸在哪里，说刚才出去了；
然后一群人闲聊，听到保险，说是农村这种木质房子，村镇都要求买保险的，我问了我叔，确实有买；
不过应该是10元最低的那种，我查了下，好像赔的不多，几千到万把块～如果是买300的最多能赔30多万；

后来我爸回来了，三轮车里是八仙桌和一些摆盘的水果和肉类，说是要请道士过来做法；
道士来了，让我爸清理下门口木头和瓦片，让准备谷子、黄酒、香、水桶、木柴等，还要10个盘子，我妈去借了，摆好盘，又找了些木头批了，找了锅，烧木头和黄纸，道士用谷子在地上画符，桌子摆在门口，然后开始做法；
我叔家信耶稣，没做，有个庇护符贴到我爸和大伯家中间；

做法结束后，摆盘和香、谷子等装入桶中，让倒到河里；

然后堂弟来了，聊了些话；
想起来，怎么一直没见着小白（狗）呢，他的好兄弟lucky（狗）都来了，不会烧里面了吧～

然后中午去弟弟那边吃了，吃完后，我和老婆带宝宝去复诊，好转了，不过做检查时宝宝怕得很，现在别人把他反过来就以为要打针～今天没有打针，开了点药，明天基本不用复诊了；

回去后，就都去弟弟那边了，我妈和我老婆带娃，我爸和我弟去忙了，我也要加加班、处理些零碎；

今天一整天都没见到小白～

后面的事，就是振作起来修房子了；阿喜同志（我爸）才60多岁，正是奋斗的年纪～加油～
我也努力赚钱；

就这样流水账式简单记录一下吧，也不校对了。

起火原因好像也没找到，明天再问问，正好应该还要去一趟消防局那边，开证明，再去派出所补办各种证件；

最后，放几张图片。

• 记于：2026-05-26 上午
• 地点：浙江省·温州市·家里
• 天气：多云

前言#

无意间看到了【腾讯广告算法大赛】，关于机器学习/推荐算法的，我其实几乎一点不懂，但是想着借助AI或许可以试一试。

前两天24号第一轮比赛已经结束了，当然，我没入围～排名200名开外～

截止目前26号，工业赛道排名前三分数已经0.854+了，第20名也有0.852+，我最后几天冲刺想要突破0.85+，失败了，最佳分数停留在0.845582。

第一轮赛事04.24-05.23，我是在提前一周左右开始报名、补知识做准备。
从头到尾我本地做了一些还算详细的日志（也是让AI记录的），包括：【学习计划与记录】、【参赛过程日志】、【运行日志】以及一些详细的模型训练和评测记录日志。

基于以上，我让AI写了一份总结与复盘。

以下部分就是AI写的了，我仅做校对与修正。

背景#

这次参加的是 Tencent UNI-REC Challenge，也就是大家常说的 TAAC 2026 / KDD Cup 2026 腾讯广告赛题。
我参加的是 Industrial Track，单人作战，Round 1 最终没有晋级。

先把结论放前面：

• 我这次不是输在“没交作业”，而是输在没有找到能稳定跨过 0.85 的单模型家族；
• 我不是机器学习、推荐系统出身，而是更偏 Java Web 开发背景；
• 我这次参赛很大程度上是一次“AI 协作做算法比赛”的真实实验；
• 最后的已知最强线上模型，还是一条很朴素的稳定主线，AUC 大约卡在 0.8455；
• 后面几条看起来更聪明的终盘结构线，反而在 hidden test 上翻车了。

虽然没有晋级，但这轮比赛对我来说并不是“白打”。
它把我的技术边界、比赛节奏感、实验方法、和 AI 协作方式，都打得比以前清楚得多。

我的技术情况#

先说我自己的起点。

我并不是传统算法选手，也不是推荐系统工程师。
我的主背景更接近：

• Java Web 开发
• 业务系统开发
• 中后端工程实现
• 一些产品和独立开发经验

但在下面这些方向上，我的基础相对弱一些：

• 机器学习
• 推荐系统
• CTR / CVR 建模
• 大规模广告排序
• 比赛型实验设计

所以这次参赛，一开始就不是“硬刚纯算法”，而是一个比较明确的组合打法：

• 我自己负责方向、执行、取舍、节奏；
• AI 负责辅助理解规则、梳理代码、帮我控实验发散、一起做技术判断；
• 平台训练和评测由我自己盯；
• 日志、决策、实验脉络持续记录下来。

说白了，这次不是“我拿 AI 当搜索框”，而是认真把它当一个高强度协作者来用了。

赛事情况#

这次比赛的几个关键信息，我在前期就反复确认过。

• 赛题：Tencent UNI-REC Challenge
• 赛道：我参加的是 Industrial Track
• Round 1 时间：
  • 2026-04-24 至 2026-05-23 23:59:59 AOE
• Round 2 时间：
  • 2026-05-25 至 2026-06-24 23:59:59 AOE
• 晋级规则：
  • Industrial Track 前 20 进入 Round 2
• 每天最多 3 次提交
• 主指标是 ROC-AUC
• 明确禁止 ensemble
• Round 2 还要求完整训练和推理代码可复现
• 还要交 workshop 论文/技术报告

这里有一个对我后面影响很大的点：

这题禁止 ensemble#

这个限制非常关键。

因为很多比赛到了后期，最直接的涨分手段往往不是继续改单模型，而是：

• 平均
• 加权
• blending
• stacking
• 多 checkpoint 组合

但这题明确不允许。

这意味着你最后必须回到一件很硬的事情上：

• 单模型本体到底够不够强

我后面很多焦虑，本质上都来自这里。
因为一旦单模型主线卡住了，你就没有“最后用融合补一脚”的退路。

参赛前的判断#

我前期对这次比赛的定位，其实还算清醒。

我没有把自己当成“成熟算法选手”，而是把自己定位成：

• 一个工程背景更强的参赛者
• 一个单人实验负责人
• 一个用 AI 强化信息处理和决策能力的人

所以我最开始的目标不是一口气冲榜，而是很现实的四步：

1. 跑通 baseline
2. 做出有效提交
3. 找到 1~2 条能稳定改进的单模型主线
4. 在可复现和时延约束下，尽量把分往上抬

这个起步策略现在回头看，我觉得是对的。

参赛过程#

我把整个过程大致分成三个阶段：

• 前期：跑通、理解、建立主线
• 中期：收敛、抬稳定线、确认平台期
• 后期：追 0.85，赌结构，但没有成功

一、前期：先把 baseline 跑起来，再搞明白什么是真信号#

1. 最开始，我先确认了一件现实问题#

我本地机器是 MacBook M1。

所以我一开始就没有幻想“本地完整训练 Round 1”这种事。
本地更适合做的是：

• 读 demo 数据
• 看 schema
• 理解输入输出
• 跑小样本
• 改代码
• 排查脚本问题

真正训练和评测，还是要依赖平台。

这一点如果前面认不清，后面节奏会很乱。

2. baseline 比我想象中更值得认真拆#

很多人拿到 baseline，第一反应是“先跑一下，再说”。
但我这次前面花了不少时间做结构化拆解。

包括：

• 数据列结构
• 非序列特征和序列特征怎么分
• 多域序列怎么组织
• 模型主干是怎么工作的
• 训练器和 checkpoint 机制
• 推理链路和 predictions.json 格式

这个动作当时看起来慢，但后面很值。

因为比赛不是只靠“多开实验”赢的；
很多时候是靠你足够早知道：

• 这段代码到底在学什么
• 这条线到底为什么涨
• 这次离线指标到底意味着什么

3. baseline 第一枪给了我信心#

2026-04-28，baseline 的官方评测结果出来了：

• AUC = 0.845179

这个分数有两个意义：

• 第一，证明 baseline 不是完全没法打；
• 第二，说明这题的单模型 baseline 本身就不低。

也就是说，这不是那种“baseline 0.78，随便改改就 0.84”的题。
这题一开始就站在相对高的位置上，想继续往上推，是很难的。

4. 前期最有价值的改动，是 RoPE#

前期我做过一些小实验：

• 改序列长度
• grouped NS tokenizer
• RoPE
• LongerEncoder
• 换 seed
• focal loss

其中真正最先在线上被验证为正收益的，是 RoPE 那条线。

2026-04-29：

• t3.m38050 = 0.845331

它超过了 baseline 的 0.845179。

这个提升不大，但非常重要。
因为它让我确认了一件事：

• 这个 baseline 不是完全推不动

你在比赛里最怕的不是改动没涨分，而是你根本不知道有没有任何方向会被线上承认。
t3 的意义就在这里。

5. 但前期也很快告诉我：不是所有“看起来合理”的方向都成立#

后面我试了：

• LongerEncoder(top_k=50)
• focal loss
• 一些轻量正则和压缩线

这些方向要么离线就不强，要么线上不承认，要么直接止损。

前期给我的第一个真正比赛感受就是：

• 广告排序比赛里，“听起来合理” 和 “线上真的有效”，中间隔着很深的沟。

二、中期：开始收敛主线，但也开始碰到平台期#

1. 这中间还有一个大插曲：榜单 reset#

前面做着做着，官方修了 Industrial Track 的测试集，榜单 reset 了一次。

这个事情对我影响很大。

因为它意味着：

• 之前的线上 best 不能直接当新榜依据
• 一些旧实验的线上排序可能会变
• 你必须重新验证自己认为“成立”的路线

这也是我后面为什么越来越强调：

• 日志要记
• checkpoint 要审计
• 不能只记一个分数
• 必须知道这个分数是在哪个测试集、哪个阶段、哪个配置下出来的

2. 中期我开始做 validation rebuild#

大概到 2026-05-02 之后，我开始更认真地处理 validation 问题。

因为我逐渐发现：

• 单看某一个 valid split
• 或者只看主验证 AUC

很容易在 hidden test 上被骗。

所以我开始逐步建立：

• interleaved primary
• tail diagnostic
• time_tail

这些验证口径。

说白了，我在中期逐渐把问题从：

• “哪个 checkpoint 离线最高”

变成了：

• “哪个 checkpoint 的离线信号更像 hidden test 会接受的信号”

这个转变我觉得是对的。

3. t24 成了我真正的稳定主线#

中期最核心的一条线，是 t24_user_ns_tokens2_item_ns_tokens1。

后面我最终锁定的历史最佳模型也是它：

• t24_21.m68490
• 历史已知最好线上 AUC：0.845582

这条线对我来说非常重要。

因为它不花哨，但稳。
它后面基本承担了两个角色：

• 一个是“当前最强保底线”
• 一个是“后续所有进攻线的参考基准”

4. 我还开过一条更像“进攻线”的 t30#

t30 是 t24 + batch_size=128 的方向。

离线看，它一度很有戏。
在等效曝光量下，甚至明显强于 t24 同阶段。

这也是中期最容易让人上头的一类情况：

• 离线曲线很好看
• 指标也单调改善
• 你会觉得“这条线快要成了”

但最后线上没有兑现。

这件事给我的教训非常深：

• 离线强，不等于线上就会更强

尤其当两条线最终线上只差 1e-4 ~ 1e-3 的时候，很多你以为已经“看懂”的信号，其实都还不够稳。

5. 到 t32 的时候，我基本确认：我撞到平台期了#

2026-05-14：

• t32@34185 线上结果是 0.845335

它没有超过 t24@68490 = 0.845582。

这一刻我实际上已经得到一个非常关键的判断：

• 继续在 t24/t30/t32 家族里靠选点、验证切分、batch size 微调，大概率只能在 0.845 附近波动

也就是说：

• 我需要的不是更会挑 checkpoint
• 而是另一条更强的模型家族

这就是我后面进入后期“结构进攻”的起点。

三、后期：我开始追 0.85，但最后没追上#

1. 后期的心态其实已经变了#

到后面我逐渐形成了一个很主观、但很现实的判断：

• 如果 AUC 还不到 0.85，那这轮大概率就不够

严格来说，晋级线不一定就是 0.85；
但对我当时的观察和心理预期来说，0.85 已经成了一个很强的目标线。

这也让后期策略变得更激进：

• 我不再只想“比 0.8455 多一点”
• 我想要的是能真正跳一个台阶的东西

2. 后期我开的，是一批“更像新家族”的线#

从 t33 开始，我后面试了不少结构方向：

• t33：hidden 从 64 -> 96
• t34：layer 从 2 -> 3
• t35：num_queries = 2
• t36：item-heavy NS 分配
• t41：target-aware sequence matching
• t42：tail sequence summary
• t43：target-aware + tail16
• t44：recent target gate
• t45/t46：稳定化的 hidden96 家族
• t55-t60：最后几天的终盘修复线和新 query family

这里面，有些方向离线是有正信号的。

比如：

• t35 证明 queries=2 的排序收益是成立的
• t34 说明加深不是完全没用
• t41/t42 在某些阶段也给过我结构上“像是有戏”的感觉

但问题在于：

• 它们要么没有形成能稳定上线的单点
• 要么离线增益还不够大
• 要么被 hidden test 直接否了

3. 最让我难受的一次，是 t58#

终盘我做了一条 t58 线：

• 保持 t24/t56 骨干
• 只改 seq_d 的截断方式
• 把单纯前截断改成 head + tail hybrid truncation

它离线不是特别炸裂，但看起来是有一点收益的。

后来拿到的离线峰值大概是：

• t58@45276
• AUC/valid = 0.8633871675
• LogLoss/valid = 0.2264489681

但线上结果出来以后，直接把这条线判死了：

• t58.m37730 = 0.835486

这不是“没达到预期”，而是方向性错误。

也就是说，这条线不是 checkpoint 选差了，也不是差一点点没兑现；
而是这整个 family 对 hidden test 就是不适配。

这次结果对我打击挺大的。
因为它说明：

• 不是所有“更贴近最近行为”的想法，hidden test 都会买账

而且一旦这条线线上掉了这么多，你就没法再骗自己说：

• “也许后一个 step 就好了”

4. 最后一条真正像“新家族”的尝试，是 t60#

比赛最后，我还开了 t60。

这条线我其实挺看重的，因为它不是继续加 side branch，而是直接改主干：

• 把主 query family 改成 item-conditioned
• 让候选 item 在生成每个序列域 Q token 时就参与条件化

我到现在都觉得，这个方向在思路上是对的。
因为它试图解决的是一个更本质的问题：

• 你的历史摘要是不是太“通用”了
• 它有没有真正针对当前 candidate item 来重构历史信息

但现实问题也很明显：

• t60 开得太晚了
• 我没有时间把它跑出完整证据链
• 它没来得及成为一条真正可以和 t24 正面对比的成熟线

5. 最后我还是回头重提了历史最佳 t24#

比赛最后，我又重提了一次历史最佳模型：

• t24_21.m68490

这次出来的线上结果是：

• 0.845517

和历史最好 0.845582 只差：

• 0.000065

这件事最后把结论彻底钉死了：

• t24 仍然是我已知最强稳定线
• 但它的真实线上 ceiling 大约就是 0.8455

换句话说：

• 我不是最后一枪没打对
• 我是这轮从头到尾都没找到一条稳定跨过 0.85 的单模型家族

最终结果#

Round 1 结束，我没有晋级。

如果只看结果，这当然是失败。

而且不是那种“只差一个操作”的失败。
更准确地说，是：

• 这轮我把一条稳定 0.8455 的主线打得很清楚了
• 但我没有把它推成一条 0.85+ 的主线

这个差距，说小不小，说大也不算特别大。
但在比赛里，很多时候就是这几千分之一，决定你有没有下一轮。

我这次做对了什么#

1. 我很早就开始记日志#

这次我最庆幸的一件事，就是从比较早的时候就开始系统记：

• 规则
• baseline 理解
• 数据理解
• 每条实验线
• checkpoint
• 线上结果
• 决策理由

这让后期虽然很焦虑，但不至于失控。

因为我至少知道：

• 哪条线是真的成立
• 哪条线只是离线看着好
• 哪条线已经明确线上翻车

2. 我没有把资源浪费在大而散的随机试错上#

虽然我开的线不少，但整体上还是比较有层次的：

• 前期先跑通和找早期正信号
• 中期收敛到稳定主线
• 后期再做结构进攻

我没有在第一周就胡乱堆特别多复杂结构，也没有一开始就想着“靠黑科技一把冲榜”。

这个节奏我觉得是合理的。

3. 我较早确认了比赛的真实约束#

比如：

• 禁 ensemble
• 提交次数有限
• 线上 hidden test 和离线 valid 不会完全一致
• 最后必须考虑 reproducibility 和 latency

这些事情如果前面不重视，后面很容易在错误的问题上消耗很多时间。

4. 我认真把 AI 当协作者用，而不是当搜索框#

这点我自己还是挺满意的。

这次不是简单让 AI 帮我“写个代码”或者“解释个概念”；
而是长期让它参与：

• 读 baseline
• 帮我约束实验发散
• 整理日志
• 复盘主线
• 识别平台期
• 判断哪些方向该止损

这个模式我后面大概率还会继续用。

我这次做错了什么#

1. 我真正的“更强主模型家族”起得还是太晚#

这是最大问题。

我前面虽然做了很多实验，但中期很长一段时间，还是在 t24 家族附近做修补和延长。

这不是完全错；
但如果目标是 0.85+，那你迟早要问自己一句：

• 这条线是不是已经封顶了？

我真正彻底承认这件事，是在 t32 线上结果出来以后。
到那时再全力转结构进攻，其实已经晚了。

2. 我对 hidden test 的适配方式，理解得还不够深#

比如 t58 这类线，离线看起来是“有道理”的：

• 最近行为更重要
• 序列头尾都保留一点

但线上直接掉到 0.835486。

这说明我对 hidden test 真实偏好的理解，其实还没有到能稳定做结构命中的程度。

3. 我还是有一点“离线上头”#

比赛里很容易这样：

• 看到一条曲线涨了
• 看到某个点 AUC 很好
• 就想继续加码

但这题后面反复告诉我：

• 离线 1e-4 级别的优势，很多时候线上根本不稳
• 甚至方向都可能反

这方面我虽然中后期已经越来越克制，但还是吃了亏。

4. 单人作战的节奏管理，还是会天然吃亏#

单人参赛的优点是：

• 决策链短
• 不需要沟通成本

缺点也很明显：

• 平台训练、日志、判断、代码、提测，全都要自己盯
• 很容易在某条线上投入过多注意力
• 很难做到真正意义上的并行脑力分工

这个问题很现实，不是靠“努力一点”就能完全解决的。

关于 AI 这次到底帮了我什么#

如果让我总结一句话：

• AI 没帮我凭空造出一个 0.85+ 的模型，但它确实帮我把这轮比赛打得比我一个人瞎撞要清楚得多。

它帮到我的地方主要在：

• 读代码和 baseline
• 理规则
• 组织实验信息
• 维护日志
• 帮我收敛问题
• 及时提醒我哪些方向其实已经该停了

它没能替代我的地方也很明显：

• 最终 hidden test 偏好仍然要靠真实比赛经验和模型直觉
• 提交节奏和资源取舍还是得自己扛
• 模型 family 到底强不强，最后还是成绩说话

所以我现在对 AI 的看法反而更稳了：

• 它不是外挂
• 也不是答案生成器
• 它更像一个不会累的高频协作者

前提是你自己得知道你在做什么，至少知道你想逼近什么问题。

如果再来一次，我会怎么打#

如果让我重新打一遍这轮 Round 1，我会改几件事：

1. 更早承认主线封顶#

一旦发现 t24/t30/t32 这类线长期卡在 0.845x，我会更早转向“新 family”，而不是继续做过多保守修补。

2. 更早做 item-conditioned 主干，而不是更晚才想到#

像 t60 这种思路，我下次会更早开。
因为它解决的是主干表达问题，不是末期外挂问题。

3. 更严格地区分三类实验#

• 保底线
• 结构侦察线
• 真正提交线

这三类线如果混在一起，后面很容易乱。

4. 更早把“hidden test 不吃什么”总结出来#

不是只记“哪个涨了”，也要更早总结：

• 哪类结构线上会掉
• 哪类看似合理的 recent bias 会翻车
• 哪类 side branch 是离线虚高

这个负样本知识，其实很值钱。

这轮比赛对我最大的价值#

如果只按是否晋级来算，这轮当然是失败。

但从更长一点的视角看，它给我的价值很大：

• 我第一次完整打完了一轮这种级别的广告/推荐比赛
• 我第一次比较系统地把工程思维和算法实验方法结合起来
• 我第一次认真验证了“AI 协作做比赛”到底能走到什么程度
• 我第一次把“日志、实验、决策、复盘”做成了一个真正连续的过程

更重要的是，它让我知道了我现在到底差在哪。

这比“只知道自己没晋级”要有用得多。

我差的不是：

• 会不会写训练脚本
• 会不会跑平台
• 会不会做 baseline 改造

我真正差的是：

• 能不能更早找到对 hidden test 真正有效的主模型家族

这件事，下一轮再练。

最后#

Round 1 结束了，没晋级。

这篇文章不算庆功文，更像是一次认真存档。

我想把这段过程记下来，主要有两个原因：

• 第一，给未来的自己留一个清晰版本，别以后只记得“当时好像打过一个比赛”
• 第二，给和我类似背景的人一个参考：
  • 不是纯算法出身
  • 但想认真打一场比赛
  • 想看看 AI 到底能不能作为高强度协作者

我的答案是：

• 能
• 但它帮你的是“更清楚地打”
• 不是“直接替你赢”

这轮先到这里。

以上，AI总结与复盘结束。

补充#

AI：Codex / GPT 5.4

• 赛事官网

• 记于：2026-05-12 晚上
• 地点：浙江省·温州市·家里
• 天气：晴天

今天512🙏

简介#

该应用是一个集笔记、待办、日程、密码管理、画布管理、导航管理等便利工具与一身的个人工作台。
使用Flutter开发，目前支持macos+windows。
应用名称暂时随便取的，后面可能会换～

项目背景#

简单来说就是：需要笔记、待办、日程相关功能的工具，同时对数据安全有焦虑，不想再继续使用市面上的云笔记产品。

功能介绍#

功能比较直观，简单贴个图，文字也懒得说明了～
具体功能和样式以实际最新应用为准。

总览#

看板#

笔记#

日程#

导航#

IT工具#

密码库#

画布#

设置#

后续#

还在持续优化更新中；
接下来准备上架appstore；
计划后面会支持多平台同步；

下载及反馈#

• 小Y工作台.dmg
• todo5.exe
• 反馈地址

• 记于：2026-04-01 上午
• 地点：浙江省·温州市·家里
• 天气：多云

简介#

插入排序是一种简单的排序算法，它的工作原理是通过将一个元素插入到已排序的子序列中，来实现排序。
将其想象成手中扑克牌的排序过程，这样就比较直观了。

实现#

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74

/**
 * 插入排序
 */
public class InsertionSort {

    public static void main(String[] args) {
        // 生成100个待排序随机数
        int[] arr = randomArray(100); 

        // 打印排序前的数组
        System.out.println("before sort: ");
        print(arr);

        // 排序
        long t1 = System.currentTimeMillis();
        int[] arr2 = insertionSort(arr);
        long t2 = System.currentTimeMillis();
        System.out.println("\ntime: " + (t2 - t1) + "ms");

        // 打印排序后的数组
        System.out.println("after sort: ");
        print(arr2);
        System.out.println();
    }

    public static int[] insertionSort(int[] arr) {
        // 从第2个开始遍历
        for (int i = 1; i < arr.length; i++) {
           // 往左边对比，直到找到比它大的或者到头
            for (int j = i; j > 0; j--) {
                if (arr[j] < arr[j - 1]) {
                    // swap
                    int temp = arr[j - 1];
                    arr[j - 1] = arr[j];
                    arr[j] = temp;
                } else {
                    break;
                }
            }
        }
        return arr;
    }

    // print
    public static void print(int[] arr) {
        for (int i = 0; i < arr.length; i++) {
            System.out.print(arr[i] + " ");
        }
    }

    public static int[] randomArray(int n) {
        if (n <= 0) {
            return new int[0];
        }

        int[] arr = new int[n];

        // 1. 初始化 1~n
        for (int i = 0; i < n; i++) {
            arr[i] = i + 1;
        }

        // 2. 洗牌
        java.util.Random random = new java.util.Random();
        for (int i = n - 1; i > 0; i--) {
            int j = random.nextInt(i + 1); // [0, i]
            int temp = arr[i];
            arr[i] = arr[j];
            arr[j] = temp;
        }

        return arr;
    }
}

主要见 insertionSort 方法。
思路：

1. 从第2个元素遍历，与左边的元素对比。
2. 如果当前元素小于左边的元素，交换它们的位置。
3. 继续对比左边的元素，直到找到比它大的或者到头。

参考#

• 《算法导论》

• 记于：2026-01-04 下午
• 地点：浙江省·温州市·家里
• 天气：多云

背景#

一开始是为了参加华为鸿蒙极客松比赛而开发的，大概是25年5月份左右；
时间上比较仓促，剩最后10来天才知道这个比赛，然后实际花了一个星期左右才勉强完成前后端开发；
app是用鸿蒙原生开发的，之前有看过一些官方教程；
总之最后是没有入围，意料之中，我感觉是我审错题了～；

搁置了一段时间，后来又有鸿蒙的激励计划，截止25年年底活动还剩3个多月，也就是9月、10月份左右知道这个活动的；
这时候是准备用uniappx重新开发，它支持鸿蒙，同时也想着可以发布到微信小程序；
接下来就是开始探索开发了。

功能介绍#

一句话介绍：“一款针对云彩相关主题的图文社交APP；主要功能有：发布和浏览图文、点赞评论收藏关注等互动、云百科信息查看、个人主页等。”
底部有鸿蒙应用商店的链接，这里就不贴图了。
微信上搜索【每日云彩】也能搜到小程序版本。

功能上其实没有做什么调研和思考，会不会有用户喜欢也不清楚，就是自己想了一下，做按自己的需求和理解做了；
现在既然两个平台都已经上架了，这样我也有动力继续迭代下去，哪怕没什么人用；
目前只是初版，功能也比较简单，后续还是会用业余时间逐步迭代，不过具体功能的话可能还是以自己的需求为主，如果有真实用户提需求和建议的话，我也会考虑的。

开发过程#

对于前端部分，之前开发过微信小程序，也懂一点vuejs，uniapp也接触过一些，大概属于需要搜索引擎和AI辅助的程度；
uniapp和uniappx都支持鸿蒙，对比了一下，网上查查，AI问问，最终是选择了uniappx；
然后，全手写是不可能的～整个app端几乎90%以上是AI写的；

万事开头难，开始阶段，用AI提示词生成的效果，真是符合不了一点预期；
我也是第一次用提示词做项目，没啥经验，提示词写的基本也是很随意、口语化的、无结构的；
然后就是问AI，说是用模板，让AI给了模板参考，效果有好一些，不过最重要的还是对具体需求的描述，起码要像需求文档覆盖到各个功能点，然后细化描述功能点；
这时候出来的效果能达到我大概60%的预期了，只是一些页面会有布局错乱的问题；

然后就是需要显式添加一些规则和约束，因为哪怕一开始就定义过了AI的角色和指责，也会出现不听话的情况，所以一些点需要对其进行强调；
经过多次提示词调优，生成的效果能达到预期的80%，这时候我认为就差不多了，达到一个“提示词投入/效果产出”性价比不错的状态，继续优化提示词也没法获取大幅的效果提升了；

接下来就是跟AI进行多伦对话来完善了，同时集成接口，然后还有优化。
后端部分就不多说了，主要就是配合前端业务写一些接口，然后应上架要求，加上内容审核机制。

一些细节：

1
2
3
4
5
6

提示词的效果不仅仅取决于提示词本身，还取决于使用的IDE以及不同大模型和不同版本，甚至完全相同的情况下前后分别跑两次，出来的效果也不完全相同；
对于IDE，我先后使用了多个，包括：腾讯的CodeBuddy、阿里的Qoder、字节的Trae，当然还有vscode里的GithubCopilot、Cursor等等，市面上大部分主流的应该都用了；
一开始腾讯的CodeBuddy效果非常不错，但是在一次升级后，感觉变得弱智了，不知道是不是我的错觉；
阿里的Qoder也不错，只是免费额度不太够；
字节的Trae也不错，目前是我的免费主力～
GithubCopilot和Cursor主要也是额度问题，效果我忘了，用的没有前几个那么多；

1
2
3

还有就是，开发的时候先创建一个初始脚手架，比如uniappx，官方提供了基础的“Hello uni-app x”模板；
如果直接让AI根据提示词生成代码的话，由于缺少“框架”部分的信息，会导致效果不符合预期，需要在提示词中额外补充；
而在脚手架项目下再进行生成的话，可以提示AI让其写法、风格参考当前项目，省事一些。

最后在底部附上【初版提示词】链接（后来又微调了几版，没有保存）。

链接#

• 每日云彩-鸿蒙版
• 每日云彩-初版提示词

• 记于：2026-01-06 下午
• 地点：浙江省·温州市·家里
• 天气：晴天

背景#

开发的事情断断续续的，前后花了大概有一个月时间，开发完成后，激励活动时间大概还剩有两个月；
接下来就是准备上架了，上架流程反而是最麻烦的。

上架准备#

首先是准备上架华为鸿蒙应用市场，开始就是因为这边的赛事和激励活动才开发的应用；
我的应用属于社区类型的，华为市场的上架资质要求如下：

1
2
3
4

（1）《安全评估报告》
（2）《安全评估报告》在全国互联网安全服务管理平台的提交结果截图且现场检查结果为“通过”或审核状态为“审核通过”
（3）ICP备案或《增值电信业务经营许可证》
（4）《计算机软件著作权登记证书》、《APP电子版权证书》或《软件著作权认证证书》（三者选一）

• 《安全评估报告》

  1 2 3 4 5

  这个需要在【全国互联网安全管理服务平台】进行操作，底部有平台链接； 需要登记应用的一些信息，包括安全措施描述等，然后可以选择自评估，自己负责； 一开始这是作为个人主体下的应用，所以我是将鸿蒙应用创建在华为的个人主体账号下； 同时《安全评估报告》也是以个人主体进行登记的； 这些操作为后面埋了个坑～

• ICP备案或《增值电信业务经营许可证》

  1 2 3 4 5

  支持群里说，我这社区类型的应用需要《增值电信业务经营许可证》； 这许可证申请需要公司注资100万，还有其他一些要求，我暂时搞不定这块，为此上架的事情又搁置了一段时间； 后来又网上查了下，说是非盈利的应用不需要《增值电信业务经营许可证》，只需ICP备案即可； 然后又继续备案事项。

• 《软著》

  1	支持群里说这个可以晚点，等应用上架后再处理。

备案#

先说ICP备案的，这事情异常麻烦；
我用的是百度云服务器，就在上面提交应用的备案信息；
很快就被驳回了，理由也是社区类的应用需要《增值电信业务经营许可证》，然后才能进行ICP备案；
又提交了几次，备注里说了应用是非经营性的，都驳回了；
然后提工单，我说明了根据规定，非经营性应用无需许可证，反正对方意思是，只要是社区类型的就要许可证；
来回交涉几次，后来对方来电，我再次强调我的应用是非盈利的，并要求对方给出驳回的明确依据；
其实法条/规定本身是比较宽松的，但是服务商抓的紧，可能是为了规避责任或图省事吧；
后来对方肯定是拿不出具体驳回的规定依据，就要求我去咨询管局，拿到可以备案的证明；
然后我咨询了浙江省的通信管理局，向其明确确认非营利性应用不需要《增值电信业务经营许可证》就可以进行ICP备案；
我提取了电话录音，再次提交，这次终于是过了。

当然后面还有域名的备案，这跟应用备案里填写的域名信息是两回事，所以又花了点时间。

安全评估报告#

再来说下《安全评估报告》，这事本身还算顺利，只是等待周期比较长；
提交后，信息流转到本地公安（网管相关部门吧），电话联系询问了一些信息；
由于计划同时上架微信小程序，而那边的【社区】类目必须要公司主体才能选择，所以应用是以公司主体进行备案的；
所以公安那边说最好用公司主体重新提交，然后我就用公司主体重新提交了一份，后来审核过了；

后面华为鸿蒙应用上架的时候问题就来了，进行应用资质审核的时候，由于应用在个人主体的华为账号下，而《安全评估报告》是公司主体，导致主体不一致而驳回，当然其他应用bug方面的问题也有；
另外一个大的问题就是罪恶的审核3.5事项（底部有链接），也是活动大群里很多人吐槽的，以“应用内容单一、不丰富”之类的理由驳回，完全不匹配，完全不合理，根本就是用来卡控的手段；

主体不一致的问题，要么注册公司主体的账号，所有信息重新配置，包括包名占用问题，得先注销，还有证书之类的要重新申请，还得重新进行应用备案（证书也得备案～），非常麻烦且耗时；
或者就是进行应用迁移，在问了支持群后，说这个暂时只支持上架后的应用进行迁移；

上架事宜又搁置了一段时间；
后来活动截止时间逼近，又开始进行问题修复。

对于主体不一致的问题，正准备使用下策，自己手动一点点重新填写和配置信息（重新备案的事情肯定来不及只能延后了，会不会因为备案信息不一致被驳回也不知道）；
这时无意间发现了“迁移”按钮，未上架的应用现在也支持迁移了；
再提交了迁移申请后，等了一两天，终于是审核通过并完成迁移。

接下来就是3.5事项的问题了，顺带着其他bug也修复了下，提交后反正驳回原因中一直带有3.5事项；
虽然距离月底12.31没剩几天了，但是也没办法；期间倒是把微信小程序先给上架了；

最后几天，再次提交审核，备注里强调了这是第一个版本，后续还要继续完善功能的，如果还要驳回，请明确指出具体命中哪一行哪一句规则；
然后审核了好几天，我一直催审，同时在支持群里反馈；
所幸最后一天终于是审核通过并上架了。

上架后续#

成功上架后，也是松一口气了，想着到时候有5千到1万的激励奖金，心情舒畅；
同时也在大群里说了成功上架的事；

直到晚上20点左右，刺激的来了～
一位群友问我商户服务开通了没，我脑子一懵，什么商户服务，看了他发的截图，看了活动规则，写着“若您报名的开发者账号在2025年12月31日前仍未成功开通商户服务，视为放弃激励。”；
晚上回去21点多了，赶紧申请开通商户服务，提了加急工单，但是都已经下班了，最后无果，没赶上；
然后过两天商户服务通过了，为时已晚，我在支持群里问了，也提了工单咨询，说是这种情况就是拿不到激励奖金了～

总结#

简单总结一下，这事费时费力，最后没拿到奖金，个人认为按照活动初衷，开发者有效建设鸿蒙生态，不应该在这种问题上卡脖子；
不过规则如此，愿赌服输，也是没有办法；
说起来也只能是自己的问题了，其实一开始肯定是有看到这个规则的，但是整个开发和上架周期太长了，开始不急于处理这个事情，最后几天又这么赶，忙起来就把这事给漏掉了；
鸿蒙这边的事情就先翻篇了，接下来以微信小程序那边为主，有空就迭代功能。

顺便吐槽下，开发才花了一个月，备案的时间比开发还长，难度还这么大，真是不知道说什么好。
还有微信小程序那边我也要吐槽一下，3天驳回15次，真的想骂人，还是忍住了。

然后，26年，再接再厉吧！～

链接#

• 鸿蒙应用开发者激励计划2025
• 华为应用资质审核要求
• 华为应用审核3.5事项
• 全国互联网安全管理服务平台

• 记于：2025-12-04 晚上
• 地点：浙江省·温州市·家里
• 天气：晴天

背景#

做了个公司官网，静态版本的，唯一的一个数据交互是“提交需求表单”；
又不想为此部署一套“重量级”的后端服务，找了些第三方的集成方案，包括飞书、钉钉等平台都有通知API；
但是不太想依赖这些，后来找到了个纯粹一些的第三方表单服务（Formspree，底部有官网链接）；
使用也是比较简单的，只要将表单提交到特定地址，就能收到邮件通知。

集成#

1.注册登录后，先创建一个项目（默认也会有一个项目）：

2.创建一个表单，填入表单名称、选择刚才创建的项目、接收通知的邮箱：

3.在表单的[Workflow]->[Validations]添加表单相应的字段名称，每个字段可以设置为是否必填、数据类型以及内容长度范围：

注意：email字段是平台预置的，无法删除，但是可以修改是否必填
提示：这个[Validations]其实可以不用设置，需要校验字段的话设置一下
提示：下面的[Actions]可以设置表单提交后的动作，比如提醒方式、集成其他系统之类的

4.网页里表单设置action地址：

提示：action地址是在[Overview]标签页里获取

5.效果：

提示：创建表单时填写的那个邮箱也会收到通知邮件

链接#

• Formspree