Neomelt's Blog

谈谈 Lee Sedol moment

Neomelt — Tue, 04 Aug 2026 18:00:00 GMT

前两天在X上看到Tairan He的一句评论：“Everyone will have their Lee Sedol moment, just at a different time.”

从我大学拥有自己电脑后第一次接触 AI 时的 GPT 3.5，到现如今的 Claude Mythos 5/Fable 5 系列、Opus 5、GPT 5.6、DeepSeek V4 等模型百花齐放的景象，才过去了不到三年的时间，AI 已经从曾经那个只是存在于 web chat、鲜为人知的东西变成了如今无人不晓的智能助手，在这期间，来了很多人，走了更多的人。

AI 的发展改变了人们对它的态度。三年前，AI 几乎无法独立并且良好地承担工作，甚至简单的学习辅助，那时候如果有人看到 AI 写代码，一定会嗤之以鼻。直到 2025 年初，vibecoding 的概念横空出世，加之 Claude、OpenAI、Gemini 等一众模型的发布和 Cursor 这种 IDE 的发布，使得 AI coding 的主流风向快速地变成了 vibecoding。在 2026 年的夏天，越来越多的公司开始使用 AI native 的开发模式，越来越多的程序员、研究者从恐慌转变为接受这种开发/科研模式。

这让我不禁思考：当有一天，机器人也这样逐步发展，等到可以证明它能替代大部分人工作的那一天真正到来，我想那会是很具有悲情色彩和机遇的体验。

2016 年，李世石输给 AlphaGo 已经成了 AI 史上最著名的画面之一。

2026 年 8 月，这种感受又被推到了数学上。OpenAI 发布了一份 249 页的材料，称其中十项数学和理论计算机科学结果由内部模型获得，内容包括非 sofic 群的显式构造、对 Connes 刚性猜想的反例等。公开 PDF 的确包含十篇完整手稿，也明确写着结果来自内部模型。

这意味着模型已经能够生成值得领域专家严肃检查的研究手稿。

围棋有封闭规则、明确胜负和几乎无限的自我对弈。AlphaGo Zero 最惊人的地方，不只是它赢过人，而是它不再从人类棋谱开始，在三天自我对弈后就以 100:0 击败了曾战胜李世石的公开版 AlphaGo。DeepMind 当年的说明给出了这个结果。

一种很有解释力的框架是：一个领域越容易得到廉价、稳定、可重复的反馈，机器就越容易形成训练闭环。这不能单独预测所有领域的进展顺序，却能解释一个反直觉的现象：数学研究中的一部分任务，可能早于通马桶被突破；机器人学家的某个“李世石时刻”，也可能早于水管工真正失去工作。

这就是 Moravec 悖论最反讽的地方：在人类看来很高级的抽象推理，往往比我们下意识完成的感知与运动更容易被计算。

但是从某种意义上来讲：李世石是幸运的，他的 Lee Sedol moment 是确定的，我们很多人甚至都不会意识到这一天的到来，只能在事后才明白早已过去，就像 AI 之于程序员。

我相信，robotics 终将会迎来属于我们的 Lee Sedol moment，而且会和 AI 非常像。对机器人来说，我认为这个时刻至少应该满足几个条件：面对没有为它专门设计的真实环境，在没有遥操作和人工兜底的情况下，连续完成一项有实际价值的任务，并在成功率、速度或者成本上达到甚至超过熟练的人类。

AlphaGo 可以通过自我对弈得到近乎无限的数据，LLM 也拥有互联网规模的文本以及可以大规模并行的训练目标。但机器人没有这么廉价的反馈：每一次动作都要发生在真实或模拟的物理环境中，真机会磨损、会碰撞，仿真又很难完全复现摩擦、柔性和接触。因此机器人真正缺少的，也许是一套能够规模化运行的“动作—结果—修正”闭环。

人类从出生开始就在持续接收视觉、触觉、本体感觉和动作反馈，语言是在这套具身经验上逐渐生长出来的。现在一部分 VLA 走的却是另一条路径：先继承视觉语言模型的语义知识，再用有限的机器人数据把这些知识接到动作上。我不知道这种差异是不是机器人进展缓慢的决定性原因，但它至少说明，语言里的“知道”和身体能够使用的“知道”之间仍然隔着一层 grounding。

我仍然不认为单纯依靠语言模型直接输出动作会是最终方案。未来的机器人智能很可能还需要把视觉、触觉、本体感觉、动作历史、长期记忆和某种后果预测机制放进同一个闭环。它最终是否还会被叫作 LLM 我们无从得知，但真正重要的是系统完成这些事情的能力。

将视角放回到 2026 年的行业内：VLA？world model？RL？或者说其他的什么混合方案，哪一个会是方向呢，或者说是当前的局部最优解呢，我不知道，但是可以肯定的一点是，不管算法框架怎么变，可靠的硬件和高质量的物理交互数据都是绕不过去的约束。

至于最终的价值会沉淀在哪一层，现在还不能确定。

用 Tailscale 远程访问自己的机器

Neomelt — Tue, 21 Jul 2026 16:17:00 GMT

手上有张显卡一直闲着，想拿来跑生图，苦于没办法远程调用，问了 Claude 有没有解法，答案是 Tailscale。下面先从网络本身的约束讲起，捋清楚为什么只能这么干，再落到具体命令。

先看效果

远端有一台带 RTX 5060 Ti 的 Linux 主机，上面跑着 ComfyUI 出图服务，只监听 127.0.0.1:8188。我人在家里，轻薄本浏览器打开一个域名，就是完整的原生 Web 界面。这不是远程桌面串流，是真在浏览器里操作，没有串流那种卡顿：

全程不需要公网 IP、不需要自建服务器、不需要动路由器，而且这个服务从头到尾没有暴露给公网，甚至没有暴露给它所在局域网里的任何人。

两台机器互访，到底需要什么

先不急着谈工具。两台机器要能互访，需要的东西就三样：

得有个地址，能被路由到对方；
路径上每一跳（路由器、防火墙、NAT）都愿意帮你把包转过去；
公网不可信，所以还得能确认对方是谁，并且把流量加密。

麻烦在于，前两条在今天的互联网上默认不成立。IPv4 地址早在 2011 年就分配殆尽，绝大多数设备拿到的是 RFC 1918 私网地址（192.168.x / 10.x），躲在 NAT 后共享少数公网出口；家宽还常常再叠一层运营商级 NAT（CGNAT，Carrier-Grade NAT），这时候连你家路由器的 WAN 口拿到的都不是公网地址，端口映射根本没得做。而 NAT 说白了就是个单向阀：

出站连接及其回包放行；没有映射表项的入站包，一律丢弃。

于是家里的笔记本和远端主机各自躲在 NAT 后面，谁都没法被对方连进来。这不是哪里坏了，也不是你配置没弄对，就是 IPv4 不够用、大家挤一个出口的结果：

只剩三条路

入站被堵死之后，能走的路其实就剩三条：

路线	思路	代价
A. 制造公网可达点	买 VPS 做中转（frp 等）；或路由器端口映射	服务器钱和维护；映射需要你没有的路由器权限，家宽还常无公网 IPv4
B. 放弃网络层，搬画面	远控软件（RustDesk / 向日葵）	得到的是”屏幕”不是”网络”：画质延迟受限，无法 curl / SSH / 调 API
C. 钻 NAT 的空子	出站反正是允许的，那就让两边各自出站，在中间碰头	几乎没有，见下

路线 C 展开就是 NAT 穿越（NAT traversal），也就是俗称的打洞。两边先各自出站连一个会合点，把”我的公网映射地址和端口”跟”我的公钥”交换一下，然后同时朝对方的映射地址发包。两边的 NAT 都以为这是自家发起的会话，各自建了表项，回包就放行了，洞打通之后就是纯点对点直连。

这里”向会合点问出自己的公网映射地址和端口”，就是 STUN 在做的事（Session Traversal Utilities for NAT，现行标准 RFC 8489；早期的 RFC 3489 里 STUN 是另一个全称，现在已经废弃了，别搜错）。而”直连、打洞、中继几条路一起试，哪条通用哪条”是 ICE（RFC 8445）的思路。打洞走 UDP 不走 TCP，一是 WireGuard 本身就跑在 UDP 上，二是 TCP 打洞还要额外对付连接状态机，复杂度高出一截。

上面说的”少数严苛 NAT”得讲准点，它直接决定你会不会被迫走中继。NAT 建映射有两种行为：只按源地址端口分配、对谁都复用同一个映射的，叫端点无关映射（endpoint-independent mapping, EIM），这种能打洞；对每个不同目标都新开一个映射的，叫端点相关映射（EDM），也就是常说的对称型 NAT（symmetric NAT）——你从会合点问到的那个端口，拿去连对方时根本不是同一个，洞自然打不通。这套 NAT 行为的分类出自 RFC 4787，后面”怎么知道自己走的是直连还是中继”一节里有实测判断方法。

打不通就退回”两边都出站连一个中继，由它转发”，无非多一跳；因为只依赖出站，这条路总是走得通。

到这里路线 C 还差两块。前面第 3 条要的信任交给 WireGuard，密钥对就是身份，全程加密，跑在内核态，性能损耗基本可以不管。另外还需要一个”介绍人”服务，管公钥分发、地址簿和打洞撮合，注意它只负责介绍，数据流量不经它的手。

把这一套连打洞带中继带密钥管理全自动化到”装上就通”，就是 Tailscale。它没造什么新技术，就是认了 NAT 这个现实，然后把绕过去的路给修好了。

Tailscale 常被归到”内网穿透”里，但它跟 frp / ngrok 那一类不是一个东西：它是覆盖网络（overlay network）形态的 mesh VPN。两者确实都要解决 NAT 穿越，可目标是相反的——内网穿透是把某个服务暴露给公网，安全边界落在”地址没人知道”；mesh VPN 是把你自己的设备拉进同一个虚拟局域网，安全边界落在密钥。上面那张表里的路线 A 才是典型的内网穿透，本文走的是路线 C。后面 serve 和 funnel 的区别，说的还是这条线。

名词对照

上面推导出来的每个角色，Tailscale 里都有个对应的叫法：

推导中的角色	Tailscale 名词	说明
”我的设备们”这个信任集合	tailnet	边界 = 登录了你账号的设备（本质是一组 WireGuard 公钥）
虚拟地址	`100.x.y.z`	取自 CGNAT 保留段 100.64.0.0/10（RFC 6598），不与家用网段冲突
会合点 / 介绍人	控制面 / coordination server（login.tailscale.com）	分发公钥与地址簿、撮合打洞；不经手流量
打洞失败的兜底中继	DERP	Designated Encrypted Relay for Packets，全球部署，只转发密文
给地址起名	MagicDNS	`设备名.tailnet名.ts.net` 自动解析
把本机服务开门给 tailnet	tailscale serve	反代 + 自动 HTTPS，仅网内可见
serve 的公网版	tailscale funnel	会暴露到互联网——本文用不到，不确定就永远别开

组网后的全景是这样的：

个人免费额度 100 台设备，这个场景绰绰有余。

实操：远端主机安装

安装按官方文档手动来，一共四步，不用 curl | sh 那种黑箱。国内网络实测 pkgs.tailscale.com 和控制面均直连可达，无需代理：

# 1. 加官方 apt 源（noble = Ubuntu 24.04，其他版本换代号）
curl -fsSL https://pkgs.tailscale.com/stable/ubuntu/noble.noarmor.gpg \
  -o /usr/share/keyrings/tailscale-archive-keyring.gpg
curl -fsSL https://pkgs.tailscale.com/stable/ubuntu/noble.tailscale-keyring.list \
  -o /etc/apt/sources.list.d/tailscale.list

# 2. 装的是数据面守护进程 tailscaled（WireGuard 隧道就归它管）
apt-get update && apt-get install -y tailscale

# 3. 入网 = 把本机公钥注册进你的 tailnet：
#    会打印 https://login.tailscale.com/a/xxxx 链接，任意设备浏览器打开登录即可
tailscale up

# 4. 授权日常用户免 sudo 管理（serve 等命令不再要 root）
tailscale set --operator=你的用户名

建议把四步存成脚本 sudo bash tailscale-setup.sh 一次跑完。跑完 tailscale ip -4 能看到本机的 100.x 身份。

前置检查一项：被远程访问的机器不能自动休眠。GNOME 下看 gsettings get org.gnome.settings-daemon.plugins.power sleep-inactive-ac-timeout，为 0 即永不休眠（type 字段哪怕是 suspend，timeout 为 0 就不会生效）。

客户端（笔记本 / 手机）

装官方客户端（tailscale.com/download，手机在应用商店搜），登录同一个账号就行。前面名词对照里说过，tailnet 就是”登录了你账号的所有设备”，所以不存在单独的”组网”步骤——不用填对方 IP，也不用交换什么配置，客户端登录完，这台设备就已经在网里了。

任一设备上验证：

$ tailscale status
100.94.159.89  neomelt-b760m-h-ddr4  linux  -
100.84.35.92   fedora                linux  -

两台都在，组网完成。这时候 SSH 就已经能用了——远端 sshd 本来就在监听，只是过去你”够不着”它，现在可达性有了：

ssh neomelt@100.94.159.89

实操：把 ComfyUI 开给 tailnet

先说清一件事：一个服务监听哪个地址，等于它在决定信任谁。

监听 0.0.0.0 是信任整个局域网，而 ComfyUI 压根没有登录认证，等于把一扇没锁的门开给同网段所有人。监听 127.0.0.1 只信任本机，安全，但家里就用不上了。我想要的是第三种，只信任我自己那几台设备，而这正好就是 tailnet。

tailscale serve 就是把边界从”本机”外扩到”tailnet”的那扇门。远端主机上一条命令：

tailscale serve --bg 8188

有两点要注意。第一次跑会提示 tailnet 还没启用 Serve，命令打印一个 login.tailscale.com/f/serve?... 链接，然后就开始轮询等着，看着像卡死了，其实是等你去浏览器点一下启用，这是个一次性开关，点完命令自己就继续了。之后网内任何设备打开 https://设备名.tailnet名.ts.net 就能到。这里用 HTTPS 是因为浏览器对明文页面有各种功能限制，而 ts.net 的证书是自动签的，你什么都不用配，首次访问慢几秒就是在签证书。

顺手再挂一个静态目录，翻出图产物用（与反代共存于同一域名）：

tailscale serve --bg --set-path /outputs /home/neomelt/ComfyUI/output

$ tailscale serve status
https://neomelt-b760m-h-ddr4.tail8bd030.ts.net (tailnet only)
|-- /         proxy http://127.0.0.1:8188
|-- /outputs/ path  /home/neomelt/ComfyUI/output

一次请求的完整路径是这样。注意 ComfyUI 从头到尾只监听回环，门开在 tailscaled 上，而 tailscaled 只认自己 tailnet 里的成员：

日常使用

# 远端主机上起服务（>> 追加日志；zsh 开了 noclobber 的话 > 第二次会翻车）
nohup ~/ComfyUI/start.sh >> ~/ComfyUI/comfyui.log 2>&1 &

# 停服务（按端口杀，不误伤；pkill 按名字匹配有相对路径的坑）
fuser -k 8188/tcp

# 人在家里远程起停：先 SSH 上去，再执行上面两条
ssh neomelt@100.94.159.89

浏览器收藏两个地址就够了：主界面 https://xxx.ts.net，出图目录 https://xxx.ts.net/outputs/WAI/。

怎么知道自己走的是直连还是中继

前面推导说打洞成功走 P2P、打不通退 DERP，那自己这条链路实际走的哪种？不用猜，两条命令就能看出来。

tailscale netcheck 报告本机的网络条件，下面是这台远端主机的实测输出（公网地址已抹掉）：

* UDP: true
* IPv4: yes, x.x.x.x:52812
* MappingVariesByDestIP: false
* PortMapping:
* Nearest DERP: Singapore
* DERP latency:
    - sin: 41.3ms  (Singapore)
    - hkg: 76.3ms  (Hong Kong)
    - blr: 78.9ms  (Bengaluru)
    - tok: 118.4ms (Tokyo)
    ...

要看的就三处。UDP: true 说明 UDP 出站没被封，这是打洞的前提。MappingVariesByDestIP 正是前面 EIM / EDM 那个概念的实测判定——false 表示映射不随目标变化，属于能打洞的那类；这里要是 true，那就是对称型 NAT，这台机器大概率只能走中继。Nearest DERP 和那张延迟表是万一走中继时的兜底路径。

具体某条连接实际走哪，看 tailscale status 的末列。前面组网验证时那两行末列是 -，意思是当时没有活跃流量；连接活跃时这一列会变成 active; direct <地址:端口> 或 active; relay <节点>，走中继时还会带上 DERP 节点的城市代号。单独探一条连接则用 tailscale ping 设备名。

运维速查

tailscale status                  # 所有节点在线状态（末列看 direct / relay）
tailscale ip -4                   # 本机 100.x 地址
tailscale netcheck                # 本机网络条件：UDP、NAT 类型、DERP 延迟
tailscale serve status            # 当前反代路由表
tailscale serve --https=443 off   # 关掉全部反代
tailscale down / up               # 本机断开 / 恢复入网

避坑与排障

下面都是我实际踩过的坑：

serve 第一次运行时看起来像卡住了，其实是在等你去管理台点启用，不是 bug（前面 ComfyUI 一节说过）。
serve 的配置是持久的，机器重启后反代路由会自动恢复；但被反代的服务本身（ComfyUI）不归它管，得自己拉起来，不然页面 502。
浏览器的代理插件可能会劫持 .ts.net 域名，走了代理反而解析失败，把这个域名加进直连规则就好。
DERP 中继的延迟：netcheck 实测这台机器最近的节点是新加坡 41.3ms、香港 76.3ms、东京 118.4ms，节点列表里没有中国大陆。但要注意这是单边到中继的 RTT，真走中继时两端各绕一趟，端到端只会比这个数更大。我没实测过完整走中继的链路，具体多少不打包票。打洞成功走 P2P 的体验很好。

页面打不开的时候，按顺序查三层就行：先确认自己这台设备入网了，再确认对面那台机器在线，最后确认它上面的服务还活着。哪一层出的问题很快就能定位出来：

最后说说安全

tailnet 说到底就是”你账号名下的一堆 WireGuard 公钥”，一台设备能不能进来由密钥决定，跟它在哪个网络里没有关系，其实这就是”零信任”这个词的意思。流量全程加密，就算走 DERP 中继，中继手里拿到的也只是密文——私钥从不离开本机，中继没有解密的可能。

不过”由密钥决定”这句还差一层：公钥的分发是控制面在管的，所以你隐含信任了 Tailscale 的控制面不会往你的 tailnet 里偷偷塞节点。官方文档自己把这个威胁写得很直白——“If Tailscale were malicious, and stealthily inserted new nodes into your network, then Tailscale could send or receive traffic to your existing nodes in plaintext.”。要堵这个口子就得开 tailnet lock：开启之后，新节点必须被你指定的签名节点签过名，其他节点才认它，信任就从 Tailscale 的基础设施移到你自己手上了。个人自用开不开另说，但这层信任在哪得心里有数。

还有件事我一开始没意识到：你的 ts.net 域名并不是秘密。serve 的 HTTPS 证书是 Tailscale 替你从 Let’s Encrypt 签的，而公开 CA 签出去的证书都必须写进 Certificate Transparency 日志，这是浏览器强制的要求，本意是让 CA 没法偷偷乱签证书。代价就是证书里的域名也跟着公开了，所以别人在 crt.sh 上搜你的 tailnet 名字，就能把你所有开过 serve 的机器名列出来。

这件事本身不影响 serve 的安全性，公网上那个名字后面根本没有监听端口，拦住外人的是密钥，不是域名难猜。但它有个实际后果——“反正没人知道我的域名”这层心理防线根本不存在。所以再强调一遍 serve 和 funnel 的区别：serve 只开给 tailnet 内部，funnel 是直接暴露到公网。哪天你手滑给这台机器开了 funnel，域名早就在公开日志里躺着了，被扫到只是时间问题，而 ComfyUI 连登录都没有。这种服务只能用 serve。

Tailscale 还有一些这篇没用到的功能：ACL（控制哪台设备能访问哪台的哪个端口）、Tailscale SSH、exit node（把全部流量从某台设备出去）、tailnet sharing（把单台设备分享给别人的账号），有需要可以再研究。

附：环境与版本

服务端：Ubuntu 24.04 (noble)，tailscale 1.98.9，2026-07-18 配置
客户端：Fedora 笔记本 + 手机
被反代服务：ComfyUI 0.28.0（监听 127.0.0.1:8188）
网络环境：远端局域网（无公网 IP、无路由器权限）↔ 家庭宽带，实测组网与访问正常
文中所有命令都在上述环境里实际跑过，netcheck 那段是服务端的实测输出
只有 tailscale status 的 direct / relay 那列我没实测到，依据的是官方 CLI 文档

关于RM的碎碎念

Neomelt — Sun, 07 Jun 2026 06:10:00 GMT

今年是真的作为观众了，现在回想起来25赛季结束的时候发了个空间：

26赛季前半程我基本都是跟着的，在陪他们烧烤拍完联盟赛完整形态后我就算是彻底的退休了，听他们说后期都没想着能进对抗赛，据说拍完对抗赛的完整形态很多人从心态上就已经崩盘了，甚至都开始写赛季总结了😂，我常常在想：为什么上一年能预见到，再进步一点就能抵达那梦想之地，可经历了一整个赛季的沉浮，却还是只差那么一点？我想了很久，始终想不通。

技术，管理，资金，人力，无论是从公司还是一个学生机器人组织来看，这几部分都是毋庸置疑的组成基石。如果真的以一种严苛的视角审视这支队伍，基本上每一个角度都说不上优秀，但是对于一群脱产且从来没有接受过体系化的技术、管理的培养的愣头青来说，似乎也无法苛责太多。在这样一个倡导学术至上、基础教育崩塌的大学环境里，注定无法找到很多能够完全沉下心来做工程的人，这也就可以解释为什么每一年都是一些真的想做好、能沉下心做的人做了绝大多数的工作。

从管理的角度来说其实也不应该去苛责。一个好的管理比一个优秀的技术人员更加难遇到，所以说技术做得好的人不一定是一个好的管理者，这也就解释了为什么看似管得很可以、但是总感觉哪里不太对劲的问题。队里现在形成的思维就是觉得做技术做得好的人应该在打完自己的赛季之后去做管理，但是其实从公司的角度去看，管理的技术水平可以不是很好，或者说从来没做过技术。可学生组织和公司是不一样的，公司那套没办法完全照搬到学生组织上来——首先两者的人才库是完全不同的，对于一群刚刚经历过12年填鸭教育的脱产群体来说，这还是太难了。

所以至此我得出了一个悲观的结论：没有真正管理过中小型组织的人指导、光靠学生，是很难将一个队伍真正带到一个健康的运作状态的。

所以，我现在的心态又转变到了个人发展优先的半边——在不完全影响队伍进度的情况下专注于个人技术的精进和职业生涯的发展。我很喜欢一句话：每一个rmer心里都有一座金灿灿的奖杯。rmer应该在意的不一定只是总冠军的奖杯，还可以是那颗总冠军的心，怀着这种心态去想其实比赛输赢也好，各种杂事也好，沟通矛盾也好，似乎都是可以调和的，但是这些终究还是太理想了……

4月总结：忙碌，迷茫，方向，机遇？

Neomelt — Fri, 01 May 2026 18:10:00 GMT

3月31号，随着南航CZ3670的航班在朦胧的凌晨降落在宝安机场，我开始了我在深圳的实习生活。

回顾这一个月的经历，莫名的觉得这个四月为何这么漫长，做了好多从未做过的事，见了好多从未见过的人。第一次坐飞机，第一次一个人在外面租房住，第一次上班，第一次领工资，见了曾经相熟的朋友，还有很多只是在网上熟悉的朋友，和从未有过交集的朋友。从一开始时候的紧张局促到现在的相对平静（也许是班味hh），我个人的感受是比较强烈的。

短短一个月在两家公司上班，先是在第一家写行为树，但是说实话我对其产品是不抱希望的，所以其实在短短的十二/二十天的时间里，并没有去做很多东西，因为当时没上几天班就有松某机器人的面试，为此还特地请了一个早上的假去面试，面试时间大概一个小时，面试官没有去过多的问技术，甚至聊了半小时天，聊比赛以及学习经历的事情，当时自我感觉面试体验良好，估计有戏，说一周后会有结果，但是两周才出感谢信，虽然当时已经被拒麻了，但是真被拒了感觉还是很难受的，那天结束后我难受了一个周末，也早思考究竟是不是自己不适合去做软件研发，是不是不是公司想要的人才。想了好久我也想通了，降低期待是最好的选择，坚定的去走系统工程师的方向。后来又过了几天，前面面过的一家公司被捞起来了，面试流程推的很快，面试也没有问很多技术上的东西，倒是问了很多方法论的东西，面试官问我想不想来做测开，我说可以，因为我现在最要紧的是了解业界的机器人业务流程，想做软件可以后面慢慢沉淀。面完就oc了，晚上发了书面offer,然后约定的4.22入职，一整个流程相当快，在现在这家的短短一周时间（有效工作时间），我认知到了我的贫瘠，逼迫我更多的从产品角度去思考。

目前的岗位只有我一个实习生，这是困难，也是机遇，我必须把握，和团队里的伙伴更好的交流沟通去共同做好我们的产品。我很希望在这家有潜力的，年轻的公司转正并且继续工作下去，当然我更希望能去干软件的工作。

一次安装windows的记录

Neomelt — Sun, 29 Mar 2026 14:10:00 GMT

前言

由于必须要去做office相关的工作，而linux对其的支持有极差，正好博主的游戏本坏了，也没打算再修，所以干脆把990pro拆下来装到tb上用来做Windows的载体。

镜像

由于博主是linux系统，不太好做系统盘，所以让朋友帮忙做了一个win11专业工作站版的镜像

如果不懂镜像怎么做的朋友可以找其他资料自行制作

安装

这一步没什么好说的，就是点点点

驱动安装

由于新装的系统是没有任何驱动的，所以需要去用usb有线联网更新Windows去自动补全驱动

windows的激活

一个刷到的邪修：

在Windows的cmd(管理员)里依次输入下面三行命令即可激活Windows专业工作站版本：

slmgr /ipk NRG8B-VKK3Q-CXVCJ-9G2XF-6Q84J
slmgr /skms kms.03k.org
slmgr /ato

专业版密钥可以看另一个视频：

Gazebo 仿真中的 z-fighting 问题记录

Neomelt — Mon, 16 Mar 2026 08:49:00 GMT

今天在 Gazebo 里调一个仿真模型时，遇到了一个显示问题：车体上的灯条只有在差不多正对着看的时候才显示得比较完整，一旦视角稍微偏一点，边缘就像缺了一块，转动镜头的时候还会忽隐忽现，大概像这样：

可以看到当我们转动视角之后部分灯条会消失，一开始我怀疑的是材质或者光照。因为这个灯条本身用了 emissive，看起来像是“自发光”的部件，所以第一反应会觉得是不是 Gazebo / Ogre2 对这种材质的表现不太稳定。但后面仔细看现象之后，发现问题其实不在光照，而在几何本身。

现象

这个问题最明显的表现有几个：

只有接近正视角时灯条显示还算完整
一旦转动视角，灯条表面开始闪烁
有时边缘会变细，像是被削掉了一层
有时会出现局部破碎或者忽隐忽现

查了一下资料，也顺手问了 GPT，才知道这种“跟着视角变化一起抖”的问题，其实很像经典的 z-fighting。

排查过程

回头看模型结构之后，问题很快就对上了。

前装甲板在 model.sdf 第 84 行附近，厚度写的是 0.012，所以它的前表面在局部坐标里相当于 x = +0.006。

前灯条在 model.sdf 第 93 行附近，中心偏移是 x = 0.003，自身厚度是 0.006，所以它的前表面也是 x = +0.006。

这就意味着，灯条的外表面和装甲板的外表面正好压在同一个位置上。更准确地说，灯条其实有一部分嵌进了装甲板里，只把最外面那一层面和外壳表面重合了。

后、左、右几个灯条也基本是同样的写法，所以会一起中招。

原因

这个问题本质上不是“谁的世界坐标更靠前”那么简单。

GPU 在渲染的时候，会对每个像素做深度比较。屏幕上的每个像素都有一个 depth buffer，用来记录当前离相机最近的片元。

问题在于这个深度值不是无限精确的。常见深度缓冲精度只有 24 bit 左右，而且经过透视投影之后，深度分布本身还是非线性的。

如果两个面非常接近，甚至干脆共面，那么它们投影到同一个像素时，深度值就会接近到深度缓冲分不清谁前谁后。结果就是：

有时这个面通过深度测试
有时另一个面通过深度测试
相机一转，投影关系和像素覆盖变化之后，显示结果也跟着跳

这就是 z-fighting。

这里顺手放一张 wiki 对 z-fighting 的解释图：

一句话概括就是：两个几乎贴在一起的面，在深度缓冲里抢前后顺序。

为什么一转视角更明显

这个现象特别容易让人误判成“材质闪了”或者“光照不稳定”，但其实它和视角变化强相关，是因为深度比较发生在投影之后的屏幕空间里。

相机一转，同一个三角形会落到不同像素上，每个像素的深度量化结果也会变，所以原本勉强还能显示的两个面，就开始交替抢占可见性，表现出来就是闪烁、缺块和边缘抖动。

如果物体离得更远、场景尺度更大，或者相机的 far clip / near clip 比例很夸张，这种问题通常还会更明显。

Gazebo 仿真的局限性

这里顺手记一下一个容易混淆的点。

灯条用了 emissive，它更接近“这个材质自己看起来是亮的”，并不等价于“它真的会像灯一样照亮周围环境”。

所以：

“没有真实泛光、照不到环境”这件事，确实和 Gazebo / Ogre2 的材质表现有关
“转视角时灯条破碎、闪动、变细”这件事，核心是几何面重合导致的 z-fighting

这两个现象可能同时出现，但不是同一个问题。

解决办法

这个问题最稳的修法其实很简单，就是不要让两个面重合，给它们留一个很小的间距。

比如这几个灯条的位置，可以把原本贴得太近的偏移量稍微往外挪一点：

前灯条从 0.003 改到 0.007
后灯条从 -0.003 改到 -0.007
左右两侧同理

这样灯条会从装甲板表面稍微“抬出来”一点点。这个量级通常 1 到 2 mm 就够了，肉眼几乎看不出来，但深度缓冲已经能稳定区分两个面了。

另一类办法是用 depth bias 或者 polygon offset，有些引擎在做 decal、标记层时会这样处理。不过在普通 SDF 模型里，直接把几何错开一点通常更稳，也更直观。

修好效果

虽然真实装甲板和灯条的上表面本来就可能非常接近，但在真实世界里，这点差异通常不会像仿真里这样被放大。这大概也是仿真和现实之间一个很典型的小区别。

经验总结

这次问题本身不算复杂，但确实很值得记一下。

以后在搭仿真的时候如果看到下面这种现象：

模型表面某一层东西贴着底面
转视角时开始闪
边缘抖动、缺块、忽隐忽现

那就可以优先往这几个方向查：

先查是不是共面或者几乎共面
再查是不是相机 near / far clip 导致深度精度不够
最后再去怀疑材质、光照或者驱动

像灯条、铭牌、装饰片、UI 面板、地面标线这种“贴表面”的结构，只要两层面重合，就迟早会遇到 z-fighting。

这算是一个很典型的图形学老问题。不是 Gazebo 独有，也不是老引擎才会有。只要还是光栅化渲染、还是有限深度精度，这个坑就一直都在。

一次把 OpenClaw 从连环报错拉回可用：sub2api + Telegram 实战排障复盘

Neomelt — Thu, 26 Feb 2026 11:04:00 GMT

这篇文章记录一次完整的排障过程，目标是把 OpenClaw 从多错并发的状态恢复至可用。

最终结果：

No API key found for provider "openai-codex" 不再出现。
sub2api / gpt-5.3-codex 能正常返回内容，403 解除。
Telegram 机器人完成配对后可稳定对话。

为了后续复用，把排障拆成两条主线：模型链路、Telegram 链路。

故障现象

初始日志中持续出现三类报错：

No API key found for provider "openai-codex"
telegram deleteWebhook failed: Network request for 'deleteWebhook' failed!
telegram setMyCommands failed: Network request for 'setMyCommands' failed!

以及一条权限相关提示（后续步骤中用到）：

security audit: device access upgrade requested ...

这三类错误不是同一根因，需要分开处理。

三个初始误判

先把错误判断列出来，这比”最终答案”更有参考价值。

看到 No API key 就认为是 key 本身无效。
看到 403 blocked 就认为是 key 或 model 名配置错误。
看到 Telegram 网络失败，认为 shell 中的代理变量已经够用。

这三个判断后来都被逐一推翻。

第一阶段：`No API key` 是路由与 auth schema 问题

先看运行时，而不是静态配置

openclaw models status --json

这一步的关键不在于核对 key 的值，而是确认当前会话实际走的 provider 路径。输出中仍然存在 openai-codex 残留路径被尝试，说明问题不是”没写 key”，而是”系统在尝试走一个已被废弃的 provider”。

`auth-profiles.json` 有内容不代表能被当前版本正确读取

当时文件中有内容，但结构不符合当前版本的识别格式。整理后的结构（脱敏）：

{
  "version": 1,
  "profiles": {
    "provider:xxx": {
      "type": "api_key",
      "provider": "xxx",
      "key": "sk-***"
    }
  },
  "lastGood": {},
  "usageStats": {}
}

处理步骤：先验证 schema 能被正常读取，再把不再使用的 provider 彻底移除，避免旧残留干扰路由。

模型侧的最终收敛

只保留 sub2api/gpt-5.3-codex 这一条可用路径。多个 provider 并存时，session 实际走的路径和预期可能不一致，排障结论因此失效。

第二阶段：`403 blocked` 是上游策略拦截，而非 key 错误

这是整次排障中最不直观的部分。

排除 key 错误的方法

用同一把 key 分别测模型枚举接口和推理接口：

枚举接口（GET /v1/models）：正常返回
推理接口（POST /v1/responses）：返回 403

结论：不是完全鉴权失败，而是特定类型的请求被上游策略拒绝。

定位到 User-Agent 的过程

控制变量：同一 endpoint、同一 key、同一 body，仅修改请求头。

SDK 风格 UA：403
curl/8.5.0 UA：正常返回

可以确认：上游对客户端指纹（UA）存在拦截策略，并非账号或模型配置问题。

修复方案

在 sub2api provider 配置中显式覆盖 User-Agent：

{
  "models": {
    "providers": {
      "sub2api": {
        "headers": {
          "User-Agent": "curl/8.5.0"
        }
      }
    }
  }
}

用新 session 验证：

openclaw agent --agent main --session-id <new> --message "回复ok" --json

返回正常内容，模型链路收口。

第三阶段：Telegram 网络失败是进程环境边界问题

shell 中已配置代理，但 gateway 依旧报 Network request failed。

原因在于：gateway 是 systemd 用户服务，并非当前终端的子进程。在 shell 中 export HTTP_PROXY 不会注入到已运行的 systemd service 进程。

解决方法是直接在通道配置中写入显式代理：

{
  "channels": {
    "telegram": {
      "enabled": true,
      "dmPolicy": "pairing",
      "botToken": "8775***",
      "proxy": "http://127.0.0.1:7897"
    }
  }
}

重启后日志中 setMyCommands/deleteWebhook 不再循环报错。

容易遗漏的步骤：设备权限批准

如果日志中已出现 scope upgrade request，需要执行设备批准：

openclaw devices approve --latest

这一步缺失会导致 CLI 与 gateway 之间的连接持续被拒。

`dmPolicy = "pairing"` 时机器人只回配对码是预期行为

首次私聊时，机器人只返回 user id 和 pairing code，这不是故障。

拿到 code 后执行批准命令：

openclaw pairing approve telegram UCJPTR6U

批准完成后，后续消息才会进入正常会话。

排障方法论总结

这次排障暴露了一个常见误区：按报错文案的字面含义直接修改配置，而不验证实际的运行时状态。

更可靠的做法分四步：

先确认运行时的实际路由，而非只看静态配置文件。
将”本地读取问题”与”上游拒绝问题”分开验证。
对模糊错误（如 403）做最小变量实验，逐一排除 UA、endpoint、body 的影响。
涉及 systemd 服务时，不依赖 shell 环境继承，所有配置显式写入。

报错文案是排障入口，不是结论。

安全提醒

排障过程中出现过真实 key 和 token，文章内已做脱敏处理。修复完成后建议对相关凭据做一次轮换，这不是流程形式，而是降低实际泄漏风险的必要动作。

从 GitHub Pages 到 Vercel 镜像：以及 Giscus -> Waline 评论迁移实录

Neomelt — Mon, 23 Feb 2026 09:46:00 GMT

这篇是一次比较实用的站点改造记录：我把博客从单一 GitHub Pages 发布，改成了 GitHub Pages + Vercel 双平台；同时把评论系统从 Giscus 换成 Waline。

中间没什么“高大上设计”，就是一路踩坑一路修。把关键决策和坑点记下来，后面自己维护也省事。

先说结果

现在线上是这个状态：

www.neomelt.cloud 走 Vercel（主站）。
GitHub Pages 继续保留，作为镜像发布链路。
评论系统已经切到 Waline，文章页和列表页都能显示阅读量/评论数。
计数路径做了统一，不会再出现“同一篇文章两套数据”。

为什么要加 Vercel，而不是只用 GitHub Pages

GitHub Pages 本身没问题，我原来也是一直这么跑。
这次加 Vercel，主要是两个原因：

自定义域名和部署体验更直接，跟 Astro 的适配也顺手。
想保留两条发布链路，某个平台抽风时不至于整站都挂。

这里有个经常让人误解的点：
一个域名主机名在 DNS 上只能主要指向一个平台。

也就是说 www.neomelt.cloud 不可能同时“直接”指向 Vercel 和 GitHub Pages。
如果想做镜像，正确姿势是不同子域名分流，例如：

www.neomelt.cloud -> Vercel
neomelt.cloud -> GitHub Pages

2026-07-25 更新：上面的分流姿势最后没有落地，也不打算落了。现状是 neomelt.cloud 由 Vercel 做 308 跳转到 www，GitHub Pages 没绑自定义域名，镜像只在 neomelt.github.io/Neomelt_blog/ 可达。维持单入口的理由：全站流通的链接（分享、搜索收录、RSS）全是 www，Vercel 真挂的时候裸域上的镜像救不了这些链接，不如把 github.io 地址当冷备手动发出去，还省一条要维护的部署链路。镜像仍跟着 Actions 自动部署。

这次部署层面我改了什么

站点构建主流程其实没大动，GitHub Actions 还是保留。
只补了一个关键环境变量，保证 Pages 构建时也能拿到 Waline 地址：

env:
  PUBLIC_WALINE_SERVER_URL: ${{ vars.PUBLIC_WALINE_SERVER_URL || secrets.PUBLIC_WALINE_SERVER_URL }}

Vercel 这边我没走“再套一层 GitHub Action 推送”，直接让 Vercel 连 Git 仓库自动部署，链路更短，也更不容易出幺蛾子。

Giscus -> Waline：为什么换，怎么换

我换 Waline 的主要考虑是：

想要更可控的后端配置，不完全绑在 GitHub Discussions。
以后做评论能力扩展（比如表情、策略、审核）会更灵活。

代码上核心就三块。

第一块是评论组件本体，重写 Comments.astro，直接用 Waline client 初始化：

init({
  el: "#waline",
  serverURL,
  path: walinePath,
  pageview: true,
  comment: true,
});

serverURL 从 PUBLIC_WALINE_SERVER_URL 读取，这样本地和线上都能通过环境变量切换。

第二块是计数组件，我加了一个 WalineCounter.astro。
因为列表页没有评论输入框，但我又想显示文章浏览量和评论数，所以把计数逻辑拆出来单独跑。

第三块是路径标准化。
这个问题不处理的话，数据一定会裂开：比如同一篇文章从 /blog/xxx 和 /posts/xxx 进去，会被 Waline 记成两个 path。

我最后统一映射到 /posts/...：

export function getWalinePathForPost(
  postId: string,
  collection: "blog" | "zueg" = "blog",
): string {
  const basePath =
    collection === "zueg" ? `/posts/zueg/${postId}` : `/posts/${postId}`;
  return normalizeWalinePath(basePath);
}

另外我把 emoji 包也换了，加入了 bilibili 那套，界面观感比默认的好不少。

这次最关键的坑

1) Waline API 403

这个坑花的时间最多。
现象是后端明明起了，但前端请求一直被拒。最后定位到 SECURE_DOMAINS 配置和当前访问域名不匹配，导致被拦。

结论很简单：
域名白名单必须和你真实访问域名一一对应，差一个都可能 403。

2) 管理后台初始化

Waline 首次初始化需要走：

/ui/register（首个管理员）
/ui/profile（确认登录状态）

这一步如果卡住，我建议按这个顺序查：

后端环境变量有没有真正生效。
前端 PUBLIC_WALINE_SERVER_URL 是否写对。
浏览器缓存/Cookie 是否残留旧状态。

3) 页面出现两组统计数字

我自己还踩了个前端层面的坑：页面同时渲染了两组统计文案（中英文各一行），看起来像“数字对不上”。
最后直接删掉重复行，只保留一组统计展示，问题就消失了。

4) 安卓 QQ 内置浏览器看不到评论框

这个坑挺隐蔽：Edge 和 Android 系统浏览器都正常，只有 QQ 内置浏览器不显示评论。
最后定位到前端加载方式兼容性问题。

我原来是这样加载 Waline 的：

<script type="module">
动态 import("https://unpkg.com/...")

这套在某些 X5 内核环境下会直接不执行，结果就是评论节点一直空白。
最终修法是改成 UMD 版本，并加双 CDN 回退：

首选 unpkg
失败后自动切 jsdelivr

后续又补了一层本地兜底：把 waline.umd.js 和 waline.css 放到站点 public/vendor，前端先尝试同源加载，再走 CDN。
这样即使 QQ 内置浏览器对第三方 CDN 抽风，也不至于整块评论直接消失。

最终这次调整上线后，neomelt.cloud 和 www.neomelt.cloud 在安卓 QQ 内置浏览器里都已经能正常显示评论区。
到这一步，我把评论加载策略就固定成了：

同源本地静态资源优先（/vendor/waline.umd.js、/vendor/waline.css）
外部 CDN 仅作为回退路径
加载失败时给出页面内可见提示，不再静默失败

现在这套方案的取舍

优点很直接：

发布链路不再单点。
评论系统可控性更高。
统计口径统一，数据可信度更高。

代价也有：

配置项明显变多（尤其是域名和环境变量）。
排障复杂度上升，需要同时看前端、部署平台、Waline 后端。

总体上我觉得这次改造是值得的，维护成本可接受，收益也足够大。

如果你也在做类似迁移，我的建议是：
先把“路径统一策略”和“环境变量命名”定下来，再动部署，不然很容易边改边乱。

关于计算机技术的一些想法

Neomelt — Thu, 19 Feb 2026 16:14:00 GMT

代码是高优先级工具（创造 vs 重复）

我一直都在思考并且寻找一个问题的答案—如何变成一个很厉害的人也就是其他人口中的—大佬。

为此我付出了两年的时间来实践，探索，却总是没能找到一个完美的，或者说能说服我的答案。直到最近重新恢复了阅读以及看了很多大佬的履历后心中才慢慢有了一点感悟。

那就是真正的将代码当作自己处理事情的一种高优先级工具。以及保有对世界的热爱与好奇。

(PS:每次开始码字就累，算了，今天先歇会儿吧，反正也不着急，想法也不算很成熟)

—2.18续

换了输入法后才感觉码字舒服点了。结合最近对于 vibecoding 的新看法，以及为什么有的人能够做到年薪百万且上班不累，有的人却在996且收入不高（感觉该叠甲了2333，没有歧视的意思，单纯在思考这个现象，有看到的人就当我瞎说了），其实这在于他们工作的性质不同：有的人是在创造，而有的人却是在做机械化的重复劳动。

机械劳动与创造性工作，本质上的区别在于“杠杆率”。机械化劳动是没有杠杆的，你的时间卖了一次就没了；而创造性劳动自带极高的杠杆。

就像前面所说的，把代码当成解决现实问题的工具。这种“杠杆”在实际开发中非常具体：

觉得 htop 看不出历史趋势、不够直观时，我没有选择死盯着跳动的数字，而是随手用 Rust 写了一个带曲线的 Linux 显卡监视器；

发现队员们需要频繁去刷 RoboMaster 论坛学习开源技术时，用 Go 写了一个爬虫，把个人的技术能力转化成了团队获取资讯的自动化流水线；

或者，在调试复杂的机器人底层硬件和算法时，我不再忍受沉默的终端黑框框和令人抓狂的延迟，而是直接动手造了一个属于自己的零拷贝低延迟的可视化调参软件（PulseScope—尚在开发中）。

这些动作，就是把“重复劳动”抽象成了“创造性工具”。大佬们之所以厉害，是因为他们一直在写能帮自己（甚至帮别人）干活的代码，用工具把自己的能力放大了成百上千倍。最近流行的 vibecoding，其实也是在强调这种摆脱机械的语法束缚，直接进入“创造心流”的状态。

保有对世界的热爱与好奇

这是最核心的内驱力。无论是去啃那些硬核的计算机底层原理，还是去构思一个复杂的架构设计，如果没有纯粹的好奇心，在这个过程中只会感到痛苦和枯燥。

很多时候，驱使我去折腾一项新技术的，并不是什么宏大的目标，或者功利性的任务，而仅仅是一个简单的念头：“这玩意好像很好玩，是怎么跑起来的？我能不能把它拆了自己重构一个更好的？”

回想一下自己这几年折腾过的东西，其实都是这种好奇心在作祟。比如在打比赛调车的时候，传统的终端输出看着让人抓狂，满屏跳动的数字毫无直观性可言。如果没有好奇心，可能我也就咬咬牙，随大流忍着继续用黑框框了。但那种“极客的玩心”会让我忍不住去想：既然现有的不好用，为什么我不自己动手搞一个类似 PulseScope 这样的可视化工具出来？把那些冷冰冰的参数变成直观的图表，不比死磕终端酷多了吗？

对不同技术栈的探索也是一样。从写底层的 C++，到为了折腾自定义客户端去摸索 Rust 和 Bevy 引擎，再到用 Astro 框架一点点把现在这个博客搭起来，或者是用 Go 写个爬虫。如果单纯把编程当成一种任务，这些跨度极大的技术栈切换只会让人觉得心力交瘁、疲于奔命。但如果是出于对未知世界的热爱，去研究一门新语言的特性，去弄懂一个框架的底层逻辑，那么枯燥的查文档和解 Bug 的过程本身，就变成了一种享受。

其实看了那么多大佬的经历后我发现，他们之所以能持续地产出高质量的作品，并不是因为他们有着常人难以企及的、用来对抗痛苦的钢铁意志，而是因为他们根本就乐在其中。这种对世界的好奇心，才是抵抗内耗和疲惫的最佳武器。

当代码不再是机械劳动的产物，而是你用来探索、解构和重塑这个世界的触角时，事情的性质就完全变了。

真正的深度是“系统性地解决问题”

但在用新时代的工具去延展这些触角时，我却经历了一次认知上的震荡。

写到这里，我突然有一种心虚的感觉。因为前面提到的那些“创造”——觉得 htop 不直观于是用 Rust 写的 Linux 显卡监视器、为了方便队员看开源文章写的 Go 爬虫、为了告别痛苦的终端调车搞的可视化软件，甚至是我一直在迭代的这个博客…其实很大一部分代码，并不是我一行一行敲出来的。

它们是我“Vibe”出来的。

这也是为什么我总是会有“感觉我的思考好像没有深度了”的想法的原因。因为当你不再需要为了一个 C++ 的野指针报错，或者 Rust 的生命周期死磕一整个下午时，真的会产生一种“不劳而获”的错觉。vibecoding 剥夺了那种“受尽折磨后终于跑通”的虚假成就感，让人直接面对结果。这甚至让我产生了一种“冒名顶替综合征”——代码都不是我手敲的，我算什么大佬？我还是在创造吗？

(PS: 发现没有，人有时候就是会陷入受苦的路径依赖，习惯了在泥泞中跋涉，突然被跑车送到了终点，反而怀疑方向错没错🤣)

但顺着我自己总结的第一条感悟仔细往下想，我发现我可能陷入了思维误区。

既然我得出的结论是“把代码当作处理事情的高优先级工具”，那我追求的难道不该是最高效地把工具造出来，去解决实际问题吗？

以前，机械化劳动的本质是“翻译”——脑子想好逻辑，双手把逻辑翻译成特定语言的语法。而 vibecoding，其实就是把这种低级的“翻译工作”外包了。它不是在消解创造，而是在给杠杆“加杠杆”。

AI 根本不知道我们打比赛需要关注什么开源文章，也不知道调车时盯着黑框框终端有多崩溃，更无法凭空捏造出一个 Linux 显卡监视器的架构。是我发现了痛点，定义了需求，挑选了合适的语言（Rust, Go, C++），然后“驾驭”着 AI 把解决方案落地。这就好比我从一个苦哈哈的“砖瓦匠”，变成了“架构师”兼“产品经理”。

真正的深度，从来不在于能手撸多复杂的底层语法，而在于能否“系统性地解决问题”。只要那份对世界的好奇心还在，只要我知道自己在造什么，能敏锐地发现痛点并用工具去填平它，那 Vibe 出来的代码，照样是我在这个世界打下的烙印。

2026 最新：国内环境低成本注册 Claude 账号防封教程

Neomelt — Thu, 19 Feb 2026 07:51:00 GMT

引言

众所周知，Claude 对于国内的管控非常严格，比如 IDC IP 连坐、虚拟号秒拒、新号高危等等，之前总是觉得其他好像也能用，但是在尝试了 copilot 、anti-gravity 和 Qoder，但是实际上体验都很一般，copilot 体验最差，完全就像一个未开智的小登，一直给你堆屎山；qoder 次之，虽然还算便宜，但是搭配具体的使用便捷性和方式来说很不习惯，充了一个月 pro 用了三四天就再也没有用过了，最近在用 anti-gravity，免费但是很容易断连，不过模型还是不错的，写写前端和一些简单的后端我觉得是很不错的，而且 plan 模式我是很喜欢的，但是就是很不稳定吧。

昨天晚上看到有群友(大佬)招人，一个要求是会用 Claude,我顿时很感慨，加上我今天早上在知乎看到一篇回答¹：Redis之父也宣称 vibecoding 改变了他的生活方式,这篇回答里有句话说的很好：“朋友，我就一个建议。不管你觉得理想的世界应该是啥样，你都没法通过拒绝现实去改变它。死撑着不用 AI，对你的职业生涯一点好处都没有。动动脑子，认真试一下这些新工具。多花几周去沉浸式体验，别试个五分钟就忙着给自己原有的偏见找补。你要想办法让自己，一个人活成一支队伍。如果现在觉得不好用，过几个月再试试。你可能觉得，自己辛辛苦苦学了这么久编程，结果现在机器全代劳了。但你想想，当年你熬夜写代码，看着项目跑通时，你心里那团火到底是因为什么？是因为，创造。现在，如果你能玩转 AI，你能构建出更多，更牛的东西。那种乐趣，一点都没变。”

看到这我瞬间觉得很感动：对啊，我的目的不就是做有趣的事情吗，而且我曾经也说过“好的工具能够显著的提高开发效率”，这样来看我之前对vibecoding的反感荡然无存，是啊，我们需要的是产品、是结果，而不是这个东西是怎么来的，没有人真正关心你的东西是怎么写出来的，你做出来了你就是牛，这就是你的产品，而且那种创造的感觉一点没有变。

前置条件

干净的节点与环境隔离

节点选择

别迷信原生 IP，关键看风控值。个人实测使用美国加州圣何塞的节点，通过 whoer.net 测试伪装度达到 90%（DNS 无泄漏）

环境无菌室

绝对不要在日常使用的主力浏览器直接注册！

在 Chrome 中新建一个无任何账号登录的独立 Profile（配置），这能确保你的本地 Cookie 和以前访问国内网站的复杂浏览器指纹不会污染新环境。（Edge应该也可以，不过我想很多技术er应该都会喜欢chrome的简约）

将 claude.ai 保存为本地 PWA 应用，彻底隔绝本地 Cookie 和复杂指纹污染。之后访问 claude.ai 也尽量走这个新的 profile，避免被封号。

接码

登录最好使用注册时间较长的gmail账号，以谷歌账号的形式登录应该会更加安全。

然后就是需要手机号验证了，这是最大的难点了。

接码平台推荐

避开已失效的老平台（如 sms-activate）和各种 GV 虚拟号。实测使用 hero-sms （博主两次就成功了）或 PingMe。

核心法则——“归属地一致”：节点是美国 IP，就必须买美国的实体手机号。

收到后尽量手动键盘输入，不要复制粘贴(虽然我是直接cv的没啥事，但是还是尽量谨慎一点好)

给路由加层规则

(注：本文以经典版 Clash Verge 为例，使用 Rev 版本或其他客户端的用户，核心思路都是通过 Merge 或 Rule Providers 将 claude.ai 和 anthropic.com 的流量固定为同一节点)”

找到自己的代理软件的 profiles 界面，找到下面这个方框

然后右键edit进入代码界面,将自己的节点名称写进去（一个字也不能错）

设置完之后save然后重启内核即可生效，但是一定要记得将代理模式切为rule，不然如果走的是global的话一旦切换了节点，你Claude的ip也会跳，会引发很大的封号危机。

注意事项

尽量用新的、干净的profile来登录 claude.ai，防止被复杂的cookies环境干扰导致封号。
尽量不要随意切换ip登录 claude.ai，最少也要隔6小时。

Redis 之父称「手写代码不再必要」，你如何看待 AI 对编程的影响？ ↩

Ubuntu系统雾凇输入法配置

Neomelt — Wed, 18 Feb 2026 14:01:00 GMT

前言

Linux 下的中文输入法一直是个痛点。默认的 IBus 常常“不够聪明”，而 Rime（中州韵）虽然强大，但默认配置过于简陋，劝退了不少人。

我由于最近买了新电脑，没有配置雾凇所以就一直捏着鼻子使用默认的输入法，但是今天晚上写随笔的时候实在是忍无可忍了，垃圾的词库导致我将很多时间都浪费在找候选词上，所以折腾了一会就换成了一套颜值在线、词库强大、极客感十足的终极方案：Fcitx5 框架 + 雾淞拼音 (Rime-Ice)。

这套方案的优点：

Fcitx5：轻量、现代，对 Wayland 支持更好。
雾淞拼音：长期维护的简体词库，开箱即用，自带日期、拆字、Emoji 等功能。
完全离线：隐私安全，没有广告。

第一步：卸载旧爱，安装新欢

Ubuntu/Debian 默认通常是 IBus，我们需要先安装 Fcitx5 及其 Rime 引擎。

注意：一定要安装 librime-plugin-lua，否则雾淞拼音的“日期/时间”等高级功能无法使用。

sudo apt update
sudo apt install fcitx5 fcitx5-rime librime-plugin-lua fcitx5-config-qt

安装完成后，通过 im-config 切换输入法框架：

im-config -n fcitx5

⚠️ 踩坑点 1：执行完这一步必须重启电脑（或注销），否则系统还在运行 IBus，Fcitx5 无法接管键盘。

第二步：部署雾淞拼音 (Rime-Ice)

Rime 的灵魂在于“配置方案”。我们要把默认的“朙月拼音”换成“雾淞拼音”。

推荐使用 git 部署，这样以后更新词库只需要 git pull，非常方便。

# 1. 创建 Fcitx5 的 Rime 目录（如果没有）
mkdir -p ~/.local/share/fcitx5/rime

# 2. 进入目录
cd ~/.local/share/fcitx5/rime

# 3. 克隆仓库（--depth 1 减少下载体积）
git clone --depth 1 https://github.com/iDvel/rime-ice.git .

第三步：关键配置 (Shift 切换 & 激活方案)

这一步是为了符合 Windows/Mac 的使用习惯：按 Shift 键切换中/英文。

在 ~/.local/share/fcitx5/rime 目录下新建（或编辑）default.custom.yaml

sudo nano ~/.local/share/fcitx5/rime/default.custom.yaml
## 如果没有这个文件需要自行创建

patch:
  # 1. 只有这一行，Rime 才会真正使用雾淞拼音
  schema_list:
    - schema: rime_ice

  # 2. 覆盖快捷键设置
  "ascii_composer/switch_key":
    Shift_L: commit_code # 左 Shift：上屏并切换中英
    Shift_R: noop # 右 Shift：无操作（防止误触）
    Control_L: noop # 屏蔽 Ctrl 切换，避免与系统快捷键冲突
    Control_R: noop

第四步：告别“黑白框” (美化)

默认的 Fcitx5 皮肤非常原始（只有黑白文字）。我们可以安装 Material 风格的主题。

sudo apt install fcitx5-material-color

安装后，打开 Fcitx 5 配置 (Fcitx5 Configuration)：

进入配置附加组件 (Addons)。

找到经典用户界面 (Classic UI) -> 点击配置。

主题 (Theme) 选择 Material-Color-Teal 或 Material-Color-Blue。

建议把字体 (Font) 调大一点（例如 14 或 16）。

第五步：踩坑记录 (无法开机自启)

这是我在 Ubuntu (Gnome) 上遇到的最大问题：重启后 Fcitx5 不会自动运行，按快捷键也没反应。

解决方法：强制添加开机自启。

打开终端，直接写入一个自启文件：

mkdir -p ~/.config/autostart
cat <<EOF > ~/.config/autostart/fcitx5.desktop
[Desktop Entry]
Type=Application
Exec=/usr/bin/fcitx5 -d
Hidden=false
NoDisplay=false
X-GNOME-Autostart-enabled=true
Name=Fcitx5
Comment=Start Fcitx5 Input Method
EOF

踩坑点 2：命令里的 -d 参数很重要，它代表后台守护进程运行。如果不加，可能启动失败。

常用技巧速查

部署完后，体验简直起飞。这里记录几个开发者常用的功能：

快速输入日期/时间（写 Log 神器）：

输入 rq -> 2026-02-18

输入 sj -> 21:30:00

特殊符号：

输入 v 然后按 1~9，可以快速找箭头、数学符号、序号等。

或者用 / 开头，例如 /xl (希腊字母)。

拆字模式（遇到不认识的字）：

按 u + U 进入拆字。例如输入 uu + huo huo huo -> 焱。

Emoji：

直接输拼音：haha -> 😂，xixi -> 🦏。

注意：雾凇输入发在ubuntu22.04会出现因依赖库版本过低无法兼容的情况，表现为切换到中文输入法的时候无法呼出选词框，解决办法

Rust入门指南

Neomelt — Sat, 16 Aug 2025 13:40:00 GMT

用了一段时间 Rust 之后，想把核心概念整理一遍。这篇文章不是语法手册，而是帮你建立对 Rust 的直觉——尤其是所有权这套东西，理解了它，Rust 就通了一大半。

为什么是 Rust？

Rust 解决的核心问题是：在没有垃圾回收的情况下保证内存安全。

C/C++ 让你手动管理内存，性能极高，但悬空指针、double free、数据竞争这些问题防不胜防。GC 语言（Go、Java、Python）解决了安全问题，但运行时开销和 GC 停顿是绕不开的代价。

Rust 的答案是把内存管理的规则编译进类型系统，让编译器在编译期替你检查，运行时零开销。代价是学习曲线陡。

所有权：Rust 的核心

Rust 里每个值有且只有一个所有者（owner）。所有者离开作用域，值就被释放。

{
    let s = String::from("hello"); // s 是这个字符串的所有者
    // 使用 s
} // s 离开作用域，字符串内存被释放

所有权转移（Move）

把值赋给另一个变量，所有权转移，原变量失效：

let s1 = String::from("hello");
let s2 = s1;           // 所有权转移给 s2
// println!("{}", s1); // 编译错误：s1 已经无效
println!("{}", s2);    // 正常

这就是 Rust 防止 double free 的方式——同一块内存永远只有一个所有者。

Clone：显式深拷贝

如果确实需要两份数据，用 .clone()：

let s1 = String::from("hello");
let s2 = s1.clone(); // 深拷贝，两者独立
println!("{} {}", s1, s2); // 都有效

Copy 类型

整数、浮点数、布尔、字符这些存在栈上的类型实现了 Copy trait，赋值时自动复制，不会转移所有权：

let x = 5;
let y = x;               // 复制，不是移动
println!("{} {}", x, y); // 都有效

借用：临时使用，不拿走

大多数时候你不想转移所有权，只是想用一下。用引用（&）来借用：

fn print_len(s: &String) {
    println!("长度: {}", s.len());
}

let s = String::from("hello");
print_len(&s);     // 借用给函数，s 的所有权没有转移
println!("{}", s); // s 仍然有效

可变借用

默认借用是只读的。要修改，需要可变借用 &mut：

fn add_world(s: &mut String) {
    s.push_str(", world");
}

let mut s = String::from("hello");
add_world(&mut s);
println!("{}", s); // "hello, world"

借用规则

Rust 在编译期强制执行两条规则：

同一时刻，要么只有一个可变借用，要么有任意多个不可变借用
引用必须始终有效（不能有悬空引用）

let mut s = String::from("hello");

let r1 = &s;
let r2 = &s;      // 多个不可变借用，没问题
// let r3 = &mut s; // 编译错误：不能同时存在可变和不可变借用

println!("{} {}", r1, r2);
// r1, r2 最后使用完毕，之后可以创建可变借用
let r3 = &mut s;
r3.push('!');

这套规则在编译期消灭了数据竞争。

枚举和模式匹配

Rust 的枚举比其他语言强大得多，每个变体可以携带不同类型的数据：

enum Shape {
    Circle(f64),
    Rectangle(f64, f64),
    Triangle { base: f64, height: f64 },
}

fn area(shape: &Shape) -> f64 {
    match shape {
        Shape::Circle(r)                    => std::f64::consts::PI * r * r,
        Shape::Rectangle(w, h)              => w * h,
        Shape::Triangle { base, height }    => 0.5 * base * height,
    }
}

match 必须穷举所有变体，漏掉一个编译不过——这个特性在你添加新枚举变体时会提醒你更新所有相关处理逻辑，非常实用。

错误处理：Option 和 Result

Rust 没有 null，没有异常，用类型来表达”可能缺失”和”可能失败”。

Option：值可能不存在

fn find_first_even(nums: &[i32]) -> Option<i32> {
    for &n in nums {
        if n % 2 == 0 {
            return Some(n);
        }
    }
    None
}

match find_first_even(&[1, 3, 4, 7]) {
    Some(n) => println!("找到了: {}", n),
    None    => println!("没有偶数"),
}

Result：操作可能出错

use std::fs;

fn read_config(path: &str) -> Result<String, std::io::Error> {
    fs::read_to_string(path)
}

match read_config("config.toml") {
    Ok(content) => println!("{}", content),
    Err(e)      => eprintln!("读取失败: {}", e),
}

? 运算符：错误传播的语法糖

在返回 Result 的函数内，? 会在出错时提前返回错误：

fn process() -> Result<(), std::io::Error> {
    let content = fs::read_to_string("a.txt")?; // 出错则直接返回 Err
    let more    = fs::read_to_string("b.txt")?;
    println!("{}{}", content, more);
    Ok(())
}

相比手动 match 每个结果，? 让错误处理代码简洁很多。

Trait：定义共同行为

Trait 类似其他语言的接口，定义类型必须实现的方法：

trait Describe {
    fn describe(&self) -> String;
}

struct Dog { name: String }
struct Cat { name: String }

impl Describe for Dog {
    fn describe(&self) -> String {
        format!("{} 是一只狗", self.name)
    }
}

impl Describe for Cat {
    fn describe(&self) -> String {
        format!("{} 是一只猫", self.name)
    }
}

fn print_info(animal: &impl Describe) {
    println!("{}", animal.describe());
}

标准库里有很多常用 trait，比如 Display（格式化输出）、Iterator、From/Into，实现它们就能融入 Rust 生态。

接下来

理解了所有权和借用，你对 Rust 的基础心智模型就建立起来了。建议的学习路径：

The Book — 官方教程，质量极高，适合系统学习
Rustlings — 通过修复小练习来熟悉语法，适合动手党
找个实际项目练手，哪怕是写个命令行小工具，遇到编译器报错再查文档，进步最快

Rust 的学习曲线主要在前期跟编译器”吵架”，但过了那个阶段你会发现，编译器拦下来的那些错误，在其他语言里都是运行时 bug。

为什么我重新搭了一个博客

Neomelt — Thu, 14 Aug 2025 02:21:00 GMT

这不是我第一次搭博客，但应该是认真想用起来的一次。

之前也折腾过，Hexo、Hugo，搭完放着吃灰，过几个月看到别人的博客又手痒，重新搭，然后继续吃灰。这次换了 Astro，强迫症发作在框架上花了不少时间——但这不是重点，重点是我想搞清楚自己为什么总在搭博客却不在写博客。

写博客是为了什么

学了快两年了，我越来越觉得自己有一个问题：动手能力尚可，但理论基础很薄。

能跑起来 ROS2 的导航栈，能用 Rust 写点东西，能把 SLAM 的流程大概跑通，但如果有人问我”卡尔曼滤波为什么这么设计”，或者”Rust 所有权的本质是什么”，我很可能答不上来，或者答得很模糊。

这个感觉越来越让我不舒服。工程上能 run 起来，但对底层原理说不清楚，感觉像踩在沙子上——能站着，但不稳。

写博客是我给自己的一个要求：写得出来才算真的懂。费曼说的那个方法，用自己的话解释清楚一件事，比反复看书有效得多。这个博客就是我的”解释给自己听”的地方。

我在学什么

目前主要在几个方向折腾：

机器人相关

ROS2 是主要工具，最近在啃导航栈——Nav2 的行为树、代价地图、局部规划器那一套。CV 方向做过一些目标检测的活，去年搞过 SLAM，用的是 PointLIO 和 slam_toolbox，但对里面的数学还不够扎实，是接下来要补的。

系统编程

Rust、C++、Go 都在用，语言只是工具，哪个合适用哪个。Rust 在机器人项目里写过一些工具和库，C++ 是 ROS 生态绕不开的，Go 偶尔写写后端服务。

AI/深度学习

这块还在入门，从基础的神经网络开始补。最近在玩 Agent，用 OpenClaw 之类的框架搭了一些东西，感觉很有意思，目标是能读懂论文、理解方法设计的动机，而不只是会调包。

接下来

这个博客大概会记录：学到的东西、踩过的坑、对某个问题的理解。不一定高深，但要真实——我不会写自己没搞懂的东西假装懂了。

先把基础补扎实。慢慢来。

git命令速查

Neomelt — Fri, 31 Jan 2025 01:28:00 GMT

Main Porcelain Commands（主要高层指令）

1. `git add`

git add <file>
git add .

用途：将文件内容添加到索引（暂存区）

| 选项 | -------------------------------- | -n, --dry-run | -v, --verbose | -f, --force | -i, --interactive | -p, --patch | -e, --edit | -u, --update | -A, --all, --no-ignore | --no-all, --ignore-removal | -N, --intent-to-add | --refresh | --ignore-errors | --ignore-missing | --no-warn-embedded-repo | --renormalize | --chmod=(+ | --pathspec-from-file=& | --pathspec-file-nul | -- | 说明 | | --------------------------------------------------------- | -------------------------------- | | 不实际添加文件，只显示哪些文件将被添加。 | | 详细模式，显示每个添加文件的状态。 | | 允许添加被 .gitignore 忽略的文件。 | | 交互式添加，进入交互界面选择要暂存的内容。 | | 交互式选择补丁（hunks），允许只暂存一个文件中的部分改动。 | | 在编辑器中打开差异，允许手动编辑暂存内容。 | | 更新已追踪文件的索引，不处理新文件。 | -removal | 暂存所有改动（新增、修改、删除）。 | | 暂存新增和修改，但不暂存删除。 | | 记下路径，稍后再添加内容（对 git diff 可见但未暂存）。 | | 不添加文件，只刷新索引中的统计信息。 | | 如果某些文件因为错误无法添加，继续添加其他文件。 | | 与 —refresh 配合使用，忽略丢失的文件。 | | 不警告嵌入式仓库。 | | 对所有追踪文件应用“清洁”过滤。 | | -)x | 强制修改被添加文件的可执行权限。 | #x3C;file> | 从文件中读取路径规范。 | | 配合上一个参数，路径规范由 NUL 字符分隔。 | | 分隔选项和路径规范，防止文件名与选项冲突。 |

2. `git bisect`

git bisect start
git bisect bad
git bisect good <commit>

用途：使用二分查找定位引入 Bug 的提交

| 选项 | 说明 | | ------------------------------------------------ | ------------------------------------- | ------------------------------------ | | start [<bad> [<good>...]] [--] [<pathspec>...] | 启动二分查找。 | | bad [<rev>] | 标记当前（或指定）版本为“坏”。 | | good [<rev>...] | 标记一个或多个版本为“好”。 | | new [<rev>] / old [<rev>] | 用于非 Bug 类（如性能）的查找替代词。 | | terms [--term-good <term> --term-bad <term>] | 设置查找的术语。 | | skip [(<rev> | <range>)...] | 跳过指定的提交（如该提交无法编译）。 | | reset [<commit>] | 退出二分查找并回到指定分支。 | | visualize / view | 查看当前查找范围。 | | replay <logfile> | 从日志文件重放查找过程。 | | log | 显示当前的查找日志。 | | run <cmd> <args>... | 通过运行脚本自动进行二分查找。 |

3. `git branch`

git branch <branch-name>
git branch -d <branch-name>

用途：列出、创建或删除分支

选项	说明
`-a, --all`	显示本地和远程所有分支。
`-r, --remotes`	只显示远程追踪分支。
`-v, --verbose`	显示每个分支的最后一次提交 ID 和注释。
`-vv`	显示与远程分支的追踪关系和领先/落后数。
`-q, --quiet`	安静模式。
`--show-current`	只打印当前分支名称。
`-f, --force`	强制创建或重命名分支。
`-m, --move`	重命名分支。
`-M`	强制重命名。
`-c, --copy`	拷贝分支。
`-C`	强制拷贝。
`-d, --delete`	删除已合并的分支。
`-D`	强制删除分支（无论是否合并）。
`-l, --list`	显示分支列表（默认）。
`--create-reflog`	为新分支创建 reflog。
`--edit-description`	打开编辑器编辑分支描述。
`--set-upstream-to=<remote/branch>`	设置本地分支追踪远程分支。
`--unset-upstream`	移除上游追踪关系。
`--contains [<commit>]`	列出包含特定提交的分支。
`--no-contains [<commit>]`	列出不包含特定提交的分支。
`--merged [<commit>]`	列出已合并到当前分支的分支。
`--no-merged [<commit>]`	列出尚未合并的分支。
`--sort=<key>`	按特定字段（如 authordate）排序。
`--points-at <object>`	列出指向特定对象的分支。
`--format <format>`	自定义输出格式。

4. `git checkout`

git checkout <branch>
git checkout -b <new-branch>

用途：切换分支或恢复工作树文件

选项	说明
`-q, --quiet`	安静模式，不显示反馈。
`--[no-]progress`	强制显示进度。
`-b <new_branch>`	创建并切换到新分支。
`-B <new_branch>`	创建（或重置）并切换到新分支。
`-l`	为新分支创建 reflog。
`-d, --detach`	切换到指向某个提交的状态（分离头指针状态）。
`-t, --track`	为新分支设置上游（upstream）追踪。
`--guess / --no-guess`	如果分支名不存在，尝试从远程库匹配。
`--orphan <new_branch>`	创建一个没有任何历史的新分支。
`-2, --ours`	在冲突合并中检出“我们的”版本。
`-3, --theirs`	在冲突合并中检出“他们的”版本。
`-m, --merge`	切换分支时，尝试合并当前未保存的修改。
`--conflict=<style>`	指定冲突显示样式（merge 或 diff3）。
`-p, --patch`	交互式选择部分代码块进行恢复。
`--overlay / --no-overlay`	指定是否允许检出时删除工作区的文件。
`--pathspec-from-file=<file>`	从文件中读取路径规范。
`--pathspec-file-nul`	路径规范由 NUL 字符分隔。
`--ignore-other-worktrees`	忽略该分支是否在其他工作树中已被检出。
`--recurse-submodules / --no-recurse-submodules`	递归更新子模块。

5. `git cherry-pick`

git cherry-pick <commit>

用途：将现有提交引入的更改应用到当前分支

选项	说明
`<commit>...`	指定要拣选的提交。
`-e, --edit`	拣选后允许在编辑器中修改提交信息。
`--cleanup=<mode>`	设置提交信息的清理方式。
`-x`	在提交信息末尾追加“cherry picked from commit …”的说明。
`-r`	(已废弃) 过去用于 -x 的参数。
`-m, --mainline <parent-number>`	拣选合并提交时，指定父分支编号。
`-n, --no-commit`	只应用更改到工作区和暂存区，不自动生成提交。
`-s, --signoff`	在提交信息中添加 Signed-off-by 标签。
`-S[<keyid>], --gpg-sign[=<keyid>]`	进行 GPG 签名。
`--ff`	如果当前 HEAD 是拣选提交的父级，则执行快进。
`--allow-empty`	允许拣选空提交。
`--allow-empty-message`	允许空提交信息。
`--keep-redundant-commits`	保留那些不产生改动的提交。
`--strategy=<strategy>`	选择合并策略（如 recursive, resolve）。
`-X, --strategy-option=<option>`	向合并策略传递特定选项。
`--rerere-autoupdate / --no-rerere-autoupdate`	如果可能，自动更新冲突解决记录。
`--abort`	取消拣选过程。
`--continue`	解决冲突后继续。
`--skip`	跳过当前提交，继续拣选序列中的下一个。
`--quit`	退出当前拣选，保留当前状态但不继续。

6. `git clean`

git clean -fd

用途：从工作树中删除未追踪的文件

选项	说明
`-d`	除了删除文件外，同时删除未追踪的目录。
`-f, --force`	强制执行（Git 配置通常要求此项，防止误删）。
`-i, --interactive`	交互式确认每一个删除操作。
`-n, --dry-run`	显示哪些文件将被删除，但不实际执行。
`-q, --quiet`	安静模式。
`-e <pattern>, --exclude=<pattern>`	排除匹配模式的文件。
`-x`	同时删除被 .gitignore 忽略的文件。
`-X`	仅删除被忽略的文件，不删除未追踪但未忽略的文件。

7. `git clone`

git clone <repository> [directory]

用途：将存储库克隆到新目录

选项	说明
`-l, --local`	克隆本地路径时，尽可能使用硬链接。
`--no-hardlinks`	克隆本地路径时强制复制，不使用硬链接。
`-s, --shared`	克隆本地路径时，不复制对象，而是设置共享（危险：删除原库会破坏此库）。
`--reference [-if-able] <repository>`	使用本地已有仓库作为参考以加速克隆。
`--dissociate`	配合 —reference 使用，下载完后切断参考关系。
`-q, --quiet`	不显示进度报告。
`-v, --verbose`	详细模式。
`--progress`	显示进度报告。
`--server-option=<option>`	向远程服务器发送特定协议选项。
`-n, --no-checkout`	克隆后不执行检出操作，只下载对象数据库。
`--bare`	创建一个裸仓库（不带工作目录）。
`--mirror`	创建镜像仓库（包含所有引用，且设置为远程镜像）。
`-o <name>, --origin <name>`	指定远程仓库的名称，默认为 origin。
`-b <name>, --branch <name>`	克隆后自动切换到指定分支。
`-u <upload-pack>, --upload-pack <upload-pack>`	指定远程使用的 git-upload-pack 路径。
`--template=<directory>`	指定模板目录。
`-c <key>=<value>, --config <key>=<value>`	在克隆出的新库中设置配置。
`--depth <depth>`	浅克隆。只下载最近的指定次数提交。
`--shallow-since=<date>`	下载指定日期后的提交。
`--shallow-exclude=<revision>`	排除特定版本后的所有历史。
`--[no-]single-branch`	只克隆一个分支（默认克隆所有分支）。
`--no-tags`	不下载远程标签。
`--recurse-submodules[=<pathspec>]`	递归初始化并克隆所有子模块。
`--[no-]shallow-submodules`	对子模块也执行浅克隆。
`--[no-]remote-submodules`	子模块使用远程追踪分支。
`-j <n>, --jobs <n>`	并行克隆子模块的数量。
`--sparse`	初始化稀疏检出。
`--filter=<filter-spec>`	使用部分克隆（Partial Clone）过滤对象。
`--bundle-uri=<uri>`	从指定的 URI 获取 bundle 加速初始化。

8. `git commit`

git commit -m "message"
git commit --amend

用途：记录对存储库的更改

| 选项 | 说明 | | ------------------------------------------- | -------------------------------------------------------------- | -------------------------------- | | -a, --all | 自动暂存所有修改和删除的文件（不包括新文件）。 | | -p, --patch | 交互式选择部分代码块进行提交。 | | -C <commit>, --reuse-message=<commit> | 重用指定提交的信息。 | | -c <commit>, --reedit-message=<commit> | 重用并编辑指定提交的信息。 | | --fixup=[(amend | reword):]<commit> | 创建用于 autosquash 的修复提交。 | | --squash=<commit> | 创建用于 autosquash 的合并提交。 | | --reset-author | 将作者更新为当前用户。 | | --short / --branch / --porcelain / --long | 不同的输出状态格式。 | | -z, --null | 状态输出使用 NUL 分隔符。 | | -F <file>, --file=<file> | 从文件中读取提交信息。 | | --author=<author> | 手动指定作者（“Name ” 格式）。 | | --date=<date> | 手动指定提交日期。 | | -m <msg>, --message=<msg> | 直接输入提交信息。 | | -t <file>, --template=<file> | 使用指定文件作为提交信息模板。 | | -s, --signoff | 在末尾添加 Signed-off-by。 | | -S[<keyid>], --gpg-sign[=<keyid>] | 进行 GPG 签名。 | | -n, --no-verify | 跳过 pre-commit 和 commit-msg 钩子。 | | --allow-empty | 允许没有文件变动的提交。 | | --allow-empty-message | 允许空信息提交。 | | --cleanup=<mode> | 设置提交信息清理方式（strip, whitespace, verbatim, default）。 | | -e, --edit | 打开编辑器编辑信息。 | | --no-edit | 不打开编辑器，直接提交。 | | --amend | 覆盖最后一次提交。 | | --no-post-rewrite | 绕过 post-rewrite 钩子。 | | -i, --include | 在提交前将指定文件加入暂存。 | | -o, --only | 仅提交指定文件，忽略其他已暂存的内容。 | | --pathspec-from-file=<file> | 从文件读取路径规范。 | | -u[<mode>], --untracked-files[=<mode>] | 显示未追踪文件的模式（no, normal, all）。 |

9. `git diff`

git diff
git diff --staged

用途：显示提交之间、提交与工作树之间等的差异由于参数极多，分为通用对比选项和特定路径选项。完整参数列表：

| 选项 | 说明 | | ----------------------------------------------------------------------------------------- | ---------------------------------------------- | --------- | ------- | -------------- | | 通用对比选项 (Common Diff Options) | | | -p, -u, --patch | 生成补丁（默认模式）。 | | -s, --no-patch | 抑制文本差异输出。 | | -u<n> | 指定差异上下文的行数（默认 3）。 | | --raw | 以原始格式显示差异。 | | --indent-heuristic / --no-indent-heuristic | 启用/禁用启发式算法以使差异更易读。 | | --minimal | 花更多时间寻找最小差异。 | | --patience / --histogram | 使用不同的差异算法。 | | --diff-algorithm={patience | minimal | histogram | myers} | 手动选定算法。 | | --stat[=<width>[,<name-width>[,<count>]]] | 生成文件名和修改行数的统计。 | | --numstat | 类似 stat，但显示数字格式且易于机器解析。 | | --shortstat | 只显示统计摘要（一行）。 | | --dirstat[=<param1,param2,...>] | 显示目录级别的差异分布。 | | --summary | 显示扩展摘要（创建、更名等信息）。 | | -z | 输出使用 NUL 分隔符。 | | --name-only | 只显示修改的文件名。 | | --name-status | 显示文件名及状态（A, M, D 等）。 | | --submodule[=<format>] | 指定子模块差异的显示格式（log, short, diff）。 | | --color[=<when>] / --no-color | 控制终端颜色输出。 | | --word-diff[=<mode>] | 进行单词级别的差异对比。 | | -B[<n>][/<m>] | 断开完全重写的文件对比。 | | -M[<n>] | 检测文件更名。 | | -C[<n>] | 检测文件拷贝。 | | --find-copies-harder | 更努力地寻找拷贝来源。 | | -D, --irreversible-delete | 省略删除文件的原始内容。 | | -O<orderfile> | 按指定文件中的顺序对文件差异进行排序。 | | --relative[=<path>] | 相对于指定路径显示差异。 | | -a, --text | 将所有文件视为文本处理。 | | --ignore-cr-at-eol / --ignore-space-at-eol / --ignore-space-change / --ignore-all-space | 各种忽略空白的选项。 | | --ws-error-highlight=<kind> | 高亮显示空白错误（context, old, new）。 | | --ext-diff / --no-ext-diff | 是否使用外部差异工具。 | | 特定对比范围 | | | git diff [<options>] [--] [<path>...] | 对比工作区与索引。 | | git diff [<options>] --cached [<commit>] [--] [<path>...] | 对比暂存区与提交。 | | git diff [<options>] <commit> <commit> [--] [<path>...] | 对比两个提交。 |

10. `git fetch`

git fetch origin

用途：从另一个存储库下载对象和引用

| 选项 | 说明 | | ------------------------------------------------------- | ---------------------------------------------- | ---- | ---------------------- | | --all | 获取所有远程仓库。 | | -a, --append | 将获取的引用追加到现有 FETCH_HEAD 而不是覆盖。 | | --atomic | 使用原子操作更新引用。 | | --depth=<depth> / --deepen=<depth> | 设置或增加浅克隆的深度。 | | --shallow-since=<date> / --shallow-exclude=<revision> | 基于日期或版本限制历史下载。 | | --unshallow | 将浅克隆转换为完整仓库。 | | --dry-run | 显示将执行的操作但不实际更新。 | | -f, --force | 强制更新本地分支引用。 | | -k, --keep | 保留下载的 pack 文件。 | | -p, --prune | 获取后删除远程已不存在的追踪分支。 | | -P, --prune-tags | 同时也清理远程已不存在的标签。 | | -n, --no-tags | 不获取标签。 | | -t, --tags | 获取远程所有标签。 | | --recurse-submodules[=yes | on-demand | no] | 控制子模块的递归获取。 | | -j, --jobs=<n> | 并行下载的作业数。 | | --set-upstream | 设置本地分支的上游。 | | --submodule-prefix=<path> | 为子模块输出添加路径前缀。 | | -q, --quiet / -v, --verbose / --progress | 控制输出详细度。 | | -o <option>, --server-option=<option> | 向服务器传递协议选项。 | | --show-forced-updates / --no-show-forced-updates | 显示强制更新的详细摘要。 | | -4, --ipv4 / -6, --ipv6 | 强制使用特定的 IP 协议。 |

11. `git gc`

git gc

用途：清除不必要的文件并优化本地存储库

选项	说明
`--aggressive`	更深入地压缩，耗时更长。
`--auto`	检查是否有必要运行 gc，如果有则执行（通常在后台运行）。
`--prune=<date>`	删除早于指定日期的孤立对象（默认 2 周）。
`--no-prune`	不删除任何对象。
`-q, --quiet`	不显示进度。
`--force`	强制运行，即使有其他 gc 进程正在运行。
`--keep-largest-pack`	在重打包时保留最大的 pack 文件。

12. `git grep`

git grep "pattern"

用途：查找匹配模式的行

选项	说明
`--cached`	搜索索引中的文件而非工作树。
`--no-index`	搜索当前目录下未被 Git 管理的文件。
`--untracked`	同时搜索未追踪的文件。
`--recurse-submodules`	递归搜索所有子模块。
`-i, --ignore-case`	忽略大小写。
`-w, --word-regexp`	匹配完整单词。
`-v, --invert-match`	显示不匹配的行。
`-h / -H`	是否在输出中显示文件名。
`-E, --extended-regexp / -G, --basic-regexp / -P, --perl-regexp / -F, --fixed-strings`	选择正则引擎。
`-n, --line-number`	显示行号。
`--column`	显示匹配项在行中的列数。
`-l, --files-with-matches / -L, --files-without-match`	只显示文件名。
`-z, --null`	文件名后接 NUL。
`-c, --count`	显示匹配行数。
`-p, --show-function`	显示匹配行所属的函数名。
`-W, --function-context`	显示整个函数的内容。
`-e <pattern>`	指定匹配模式（支持多个）。
`--and / --or / --not / ( )`	组合多个匹配模式。
`--threads <num>`	并行搜索的线程数。

13. `git init`

git init [directory]

用途：创建或重新初始化 Git 仓库

选项	说明
`--bare`	创建裸仓库（无工作树）。
`--template=<dir>`	指定模板目录。
`--separate-git-dir=<git-dir>`	将 .git 目录存放在别处并建立链接。
`--initial-branch=<name>, -b <name>`	指定初始分支名。
`--shared[=<permissions>]`	设置仓库共享权限（group, all, 或者八进制数）。
`-q, --quiet`	安静模式。

14. `git log`

git log
git log --oneline --graph

用途：显示提交日志继承了 git diff 的大部分对比参数，并增加了日志特有参数。完整参数列表：

| 选项 | 说明 | | ---------------------------------------------------- | ---------------------------------------------- | ---- | ---- | -------------------------- | | -n <number> | 限制输出的提交数量。 | | --follow | 继续列出重命名之前的文件历史（仅限单个路径）。 | | --decorate[=short | full | auto | no] | 是否显示分支、标签等名称。 | | --source | 显示每个提交是从哪个分支引用的。 | | --[no-]mailmap | 是否使用 mailmap 文件映射作者名/邮箱。 | | --full-diff | 即使限制了路径，也显示整个提交的 diff。 | | -L <start>,<end>:<file> | 显示文件特定行范围的历史。 | | 筛选参数 | | | --since, --after=<date> / --until, --before=<date> | 时间过滤。 | | --author=<pattern> / --committer=<pattern> | 按作者/提交者过滤。 | | --grep=<pattern> | 按提交信息关键词过滤。 | | --all-match | 多个 grep/author 必须同时满足。 | | --invert-grep | 显示不匹配 grep 的提交。 | | --merges / --no-merges | 只显示/不显示合并提交。 | | --first-parent | 只跟随第一个父提交。 | | 范围与引用参数 | | | --all | 显示所有引用的历史。 | | --branches[=<pattern>] / --tags / --remotes | 显示分支/标签/远程引用。 | | --reflog | 显示 reflog 记录。 | | --bisect | 显示二分查找期间的日志。 | | 输出格式 | | | --oneline | 一行显示一个提交。 | | --graph | 显示字符图形化的分支演变图。 | | --pretty=<format>, --format=<format> | 自定义输出格式。 | | --abbrev-commit | 使用缩写的哈希值。 |

15. `git merge`

git merge <branch>

用途：合并两个或多个开发历史

选项	说明
`--stat, -n, --no-stat`	显示/不显示合并后的差异统计。
`--summary, --no-summary`	(已过时) 等同于 —stat。
`--log[=<n>], --no-log`	在合并提交信息中包含来自被合并分支的短日志。
`--squash, --no-squash`	将所有合并的更改压缩为一个新的提交，不保留分支历史。
`--ff, --no-ff, --ff-only`	指定合并策略（快进、强制生成合并节点、仅允许快进）。
`--verify-signatures, --no-verify-signatures`	验证被合并提交的 GPG 签名。
`-s <strategy>, --strategy=<strategy>`	指定合并策略（recursive, resolve, octopus, ours, subtree）。
`-X <option>, --strategy-option=<option>`	向合并策略传递特定选项。
`-m <message>`	设置合并提交的信息。
`-F <file>, --file=<file>`	从文件读取提交信息。
`--edit, -e, --no-edit`	是否在提交前打开编辑器修改信息。
`--cleanup=<mode>`	提交信息清理模式。
`--rerere-autoupdate, --no-rerere-autoupdate`	自动将冲突解决结果记录到索引。
`--abort`	发生冲突时放弃合并，恢复到合并前状态。
`--quit`	退出合并过程，保留当前状态但不完成合并。
`--continue`	解决冲突后继续合并过程。
`--allow-unrelated-histories`	允许合并两个没有共同祖先的项目。
`-S[<keyid>], --gpg-sign[=<keyid>]`	使用 GPG 签名合并提交。
`--overwrite-ignore, --no-overwrite-ignore`	允许/禁止覆盖被忽略的文件。
`-q, --quiet`	安静模式。
`-v, --verbose`	详细模式。
`--progress, --no-progress`	强制显示/不显示进度。
`--autostash, --no-autostash`	合并前自动 stash 未保存的修改，完成后 pop。
`--into-name <branch>`	指定合并的目标名称（用于自定义脚本）。

16. `git mv`

git mv <source> <destination>

用途：移动或重命名文件、目录或符号链接

选项	说明
`-v, --verbose`	详细模式，显示移动操作。
`-n, --dry-run`	仅显示将要执行的操作，不实际移动。
`-f, --force`	即使目标文件已存在也强制移动。
`-k`	跳过移动或重命名过程中产生的错误。

17. `git pull`

git pull origin <branch>

用途：获取并集成远程或其他分支的更改

| 选项 | 说明 | | ------------------------------------------------- | ---------------------------- | ------ | ---------------- | ---------------------------------------- | | -q, --quiet, -v, --verbose | 控制输出。 | | --recurse-submodules[=yes | on-demand | no] | 递归获取子模块。 | | --commit, --no-commit | 拉取后是否自动提交合并结果。 | | --edit, -e, --no-edit | 是否编辑合并信息。 | | --cleanup=<mode> | 信息清理模式。 | | --ff, --no-ff, --ff-only | 合并选项。 | | --log[=<n>], --no-log | 包含短日志。 | | --stat, -n, --no-stat | 显示统计。 | | --squash, --no-squash | 压缩合并。 | | -s <strategy>, --strategy=<strategy> | 合并策略。 | | -X <option>, --strategy-option=<option> | 策略选项。 | | --verify-signatures, --no-verify-signatures | GPG 验证。 | | --summary, --no-summary | 统计摘要。 | | --autostash, --no-autostash | 自动暂存。 | | --allow-unrelated-histories | 允许无关历史合并。 | | -r, --rebase[=false | true | merges | interactive] | 核心参数，指定使用 rebase 而不是 merge。 | | --no-rebase | 禁用 rebase。 | | --all | 获取所有远程。 | | -p, --prune | 清理失效分支。 | | -t, --tags | 获取标签。 | | --dry-run | 演习。 | | -f, --force | 强制拉取。 | | -k, --keep | 保留 pack 文件。 | | --depth=<depth>, --unshallow, --update-shallow | 浅克隆相关选项。 | | --refmap=<refspec> | 指定引用的映射关系。 | | -o <option>, --server-option=<option> | 传递服务器协议选项。 | | --show-forced-updates, --no-show-forced-updates | 显示强制更新。 |

18. `git push`

git push origin <branch>

用途：更新远程引用及相关对象

| 选项 | 说明 | | ------------------------------------------------ | ------------------------------------------ | -------- | ----------------------- | ---------------- | | --all, --branches | 推送所有分支。 | | --prune | 删除远程已不存在的本地分支。 | | --mirror | 镜像推送（所有引用）。 | | -n, --dry-run | 模拟推送。 | | --porcelain | 机器可读输出。 | | -d, --delete | 删除远程引用。 | | --tags | 推送所有标签。 | | --follow-tags | 推送带注解的标签且该标签指向被推送的提交。 | | --[no-]signed, --signed=(true | false | if-ask) | 使用 GPG 签名推送操作。 | | --[no-]atomic | 原子推送。 | | -o <option>, --server-option=<option> | 服务器选项。 | | --receive-pack=<path>, --exec=<path> | 指定远程接收程序的路径。 | | --[no-]force-with-lease[=<refname>[:<expect>]] | 安全强推。 | | -f, --force | 强制推送。 | | --force-if-includes | 如果包含远程更新则允许强推。 | | --[no-]push-option=<option> | 传递推送选项。 | | --[no-]recurse-submodules=(check | on-demand | only | no) | 子模块推送行为。 | | --[no-]verify | 跳过 pre-push 钩子。 | | -t, --thin | 使用瘦包传输（减少带宽）。 | | -q, --quiet, -v, --verbose | 输出控制。 | | --progress | 显示进度。 | | -u, --set-upstream | 建立追踪关系。 |

19. `git rebase`

git rebase <branch>
git rebase -i HEAD~3

用途：在另一个基端之上重新应用提交

| 选项 | 说明 | | ------------------------------------------------ | ---------------------------------------------- | ------------------------- | ------------------ | | --onto <newbase> | 指定新的基准点。 | | --keep-base | 保持基准点（通常用于本地重排）。 | | --continue | 解决冲突后继续 rebase。 | | --abort | 取消 rebase 并恢复到初始状态。 | | --quit | 退出 rebase 但保留当前状态。 | | --apply, --no-apply | 使用 git apply 模式（旧模式）。 | | --merge, --no-merge | 使用合并后端（默认模式）。 | | --empty=(drop | keep | ask) | 处理空提交的行为。 | | -m, --merge | 同上。 | | -X <option>, --strategy-option=<option> | 合并策略选项。 | | -s <strategy>, --strategy=<strategy> | 合并策略。 | | --[no-]rerere-autoupdate | 自动冲突解决。 | | -q, --quiet, -v, --verbose | 输出详细度。 | | --stat, -n | 显示统计。 | | --no-stat | 不显示统计。 | | --committer-date-is-author-date, --ignore-date | 修改提交时间。 | | --reset-author-date | 重置作者时间。 | | --signoff | 添加签名行。 | | -r, --rebase-merges[=(rebase-cousins | no-rebase-cousins)] | 保留合并结构进行 rebase。 | | -x <cmd>, --exec <cmd> | 在每个提交应用后执行命令（常用于测试）。 | | --root | 对根提交进行 rebase。 | | --autosquash, --no-autosquash | 配合 fixup! 信息自动压缩。 | | --autostash, --no-autostash | 自动暂存。 | | --[no-]reschedule-failed-exec | 如果 exec 失败，重新安排 rebase。 | | --fork-point, --no-fork-point | 自动寻找派生点。 | | -i, --interactive | 交互式模式，允许 pick, squash, edit, drop 等。 |

20. `git reset`

git reset --soft HEAD~1
git reset --hard HEAD

用途：重置当前 HEAD 到指定状态

选项	说明
`-q, --quiet`	安静模式，仅报告错误。
`--pathspec-from-file=<file>`	从文件中读取路径规范。
`--pathspec-file-nul`	路径规范以 NUL 分隔。
`模式选项`
`--soft`	重置 HEAD，保留索引和工作区。
`--mixed`	(默认) 重置 HEAD 和索引，保留工作区。
`--hard`	重置 HEAD、索引和工作区（危险：丢弃所有未提交修改）。
`--merge`	重置 HEAD 和索引，尝试保留工作区中未受冲突影响的修改。
`--keep`	重置 HEAD 和索引，如果工作区有本地修改则中止重置。
`--[no-]recurse-submodules`	控制是否递归重置子模块。
`--`	分隔选项和路径，用于重置特定文件而不移动 HEAD。

21. `git restore`

git restore <file>
git restore --staged <file>

用途：还原工作树文件

选项	说明
`-s <tree>, --source=<tree>`	指定恢复源（默认为索引或 HEAD）。
`-p, --patch`	交互式选择要还原的代码块。
`-W, --worktree`	(默认) 还原工作树文件。
`-S, --staged`	还原暂存区（索引）文件。
`-q, --quiet`	安静模式。
`--progress, --no-progress`	强制显示进度。
`--ignore-unmerged`	还原时忽略未合并的条目。
`--overlay, --no-overlay`	指定是否允许删除不在源中的文件。
`--recurse-submodules, --no-recurse-submodules`	递归恢复子模块。
`--conflict=<style>`	指定冲突显示样式（merge, diff3）。
`--ignore-skip-worktree-bits`	在稀疏检出模式下忽略 skip-worktree 位。
`--pathspec-from-file=<file>`	从文件读取路径。

22. `git revert`

git revert <commit>

用途：通过创建一个新的提交来撤销现有的提交

选项	说明
`<commit>...`	指定要撤销的提交。
`-e, --edit`	创建提交前打开编辑器。
`-m <parent-number>, --mainline <parent-number>`	撤销合并提交时指定父分支。
`-n, --no-commit`	只修改工作区和索引，不自动创建提交。
`-s, --signoff`	添加 Signed-off-by。
`-S[<keyid>], --gpg-sign[=<keyid>]`	GPG 签名。
`--strategy=<strategy>`	指定合并策略。
`-X, --strategy-option=<option>`	策略选项。
`--cleanup=<mode>`	信息清理模式。
`--reference`	(已废弃) 过去用于记录来源。
`--abort, --quit, --continue, --skip`	流程控制。

23. `git rm`

git rm <file>

用途：从工作树和索引中删除文件

选项	说明
`-f, --force`	强制删除（即使文件有修改）。
`-n, --dry-run`	演习模式。
`-r`	递归删除目录。
`--cached`	只从索引中删除，保留工作树中的物理文件。
`--ignore-unmatch`	即使没有匹配的文件也以 0 退出（不报错）。
`-q, --quiet`	安静模式。
`--pathspec-from-file=<file> / --pathspec-file-nul`	批量路径处理。

24. `git show`

git show <commit>

用途：显示各种类型的对象（提交、标签、树等）

选项	说明
`--[no-]patch`	显示/不显示补丁。
`-s, --no-patch`	抑制文本差异。
`--stat / --numstat / --shortstat`	统计信息。
`--format=<format> / --pretty=<format>`	输出格式。
`--abbrev-commit`	缩写哈希。
`--[no-]notes[=<ref>]`	显示备注。
`--show-signature`	验证 GPG 签名。
`集成 git diff 所有参数`	如 —color, —word-diff 等。

25. `git stash`

git stash
git stash pop

用途：暂存脏工作目录中的更改

| 选项 | 说明 | | ------------------------------- | ---------------------------------- | ---------------------- | | list | 列出所有暂存记录。 | | show [<stash>] | 查看某个暂存的具体改动。 | | drop [-q | --quiet] [<stash>] | 删除某个暂存记录。 | | pop [--index] [-q | --quiet] [<stash>] | 恢复暂存并删除记录。 | | apply [--index] [-q | --quiet] [<stash>] | 恢复暂存但不删除记录。 | | branch <branchname> [<stash>] | 从暂存记录创建新分支。 | | push | 推入暂存区。 | | -p, --patch | 交互式选择。 | | -k, --[no-]keep-index | 暂存后保留索引中的内容。 | | -u, --include-untracked | 包含未追踪文件。 | | -a, --all | 包含所有文件（含忽略文件）。 | | -m <message> | 添加备注。 | | --pathspec-from-file=<file> | 路径过滤。 | | clear | 清除所有暂存记录。 | | create / store | (底层) 手动创建和存储 stash 对象。 |

26. `git status`

git status

用途：显示工作树状态

选项	说明
`-v, --verbose`	显示具体改动的 diff。
`-s, --short`	短格式输出。
`-b, --branch`	显示当前分支和追踪信息。
`--show-stash`	显示 stash 的数量。
`--porcelain[=<version>]`	机器可读的输出格式。
`--long`	长格式输出（默认）。
`-u[<mode>], --untracked-files[=<mode>]`	未追踪文件显示模式（no, normal, all）。
`--ignore-submodules[=<when>]`	忽略子模块变动（none, untracked, dirty, all）。
`--ignored[=<mode>]`	显示被忽略的文件（no, traditional, matching）。
`-z`	使用 NUL 终止符。
`--no-ahead-behind`	不计算领先/落后数量。
`--renormalize`	显示重归一化后的状态。

27. `git submodule`

git submodule add <repository>
git submodule update --init

用途：初始化、更新或检查子模块

| 选项 | 说明 | | ---------------------------------------------------------- | ---------------------------------- | ---------------------- | | add [-b <branch>] [--name <name>] <repository> [<path>] | 添加子模块。 | | status [--cached] [--recursive] | 显示子模块状态。 | | init [<path>...] | 初始化子模块配置。 | | deinit [-f | --force] [<path>...] | 注销子模块。 | | update [--init] [--remote] [-f] [--rebase | --merge] [--recursive] | 更新子模块到指定提交。 | | set-branch (-b | --branch) <branch> [<path>] | 设置子模块追踪的分支。 | | set-url [<path>] <newurl> | 修改子模块仓库地址。 | | summary [--cached] [--for-status] [<commit>] [<path>...] | 显示子模块变更摘要。 | | foreach [--recursive] <command> | 在每个子模块执行 shell 指令。 | | sync [--recursive] [<path>...] | 同步子模块的 URL 配置。 | | absorbgitdirs | 将子模块的 .git 目录吸收到主仓库。 |

28. `git switch`

git switch <branch>
git switch -c <new-branch>

用途：切换分支

选项	说明
`-c <new_branch>, --create <new_branch>`	创建并切换。
`-C <new_branch>, --force-create <new_branch>`	强制创建并切换。
`-d, --detach`	切换到游离 HEAD。
`-t, --track / --no-track`	设置上游关系。
`--guess / --no-guess`	自动推测远程分支名。
`-f, --force`	丢弃本地修改并切换。
`-m, --merge`	切换时合并修改。
`-q, --quiet`	安静模式。
`--progress`	显示进度。
`--recurse-submodules / --no-recurse-submodules`	递归处理子模块。

29. `git tag`

git tag <tag-name>
git tag -a <tag-name> -m "message"

用途：创建、列出、删除或验证标签

选项	说明
`-a, --annotate`	创建带注解的标签（推荐）。
`-m <msg>, -F <file>`	指定标签信息。
`-s, --sign`	使用 GPG 签名标签。
`-u <keyid>`	指定签名使用的私钥。
`-f, --force`	强制重置已存在的标签。
`-d, --delete`	删除标签。
`-v, --verify`	验证 GPG 签名。
`-l, --list`	列出标签。
`-n[<num>]`	列出标签及对应的消息行数。
`--contains [<commit>] / --no-contains`	筛选包含/不包含某提交的标签。
`--points-at <object>`	指向特定对象的标签。
`--merged [<commit>] / --no-merged`	合并筛选。
`--sort=<key>`	排序。
`--format=<format>`	自定义输出。

30. `git config`

git config --global user.name "name"
git config --global user.email "email"

用途：获取和设置仓库或全局选项

选项	说明
`文件位置选项`
`--global`	读写全局配置文件（~/.gitconfig）。
`--system`	读写系统级配置文件（/etc/gitconfig）。
`--local`	(默认) 读写当前仓库配置文件（.git/config）。
`--worktree`	读写当前工作树的配置文件（用于多工作树）。
`-f <file>, --file <file>`	指定任意配置文件。
`--blob <blob>`	从指定的 Git blob 对象中读取配置。
`操作动作`
`--get`	获取给定键的值。
`--get-all`	获取键的所有值（用于多值键）。
`--get-regexp`	获取匹配正则的键及其值。
`--get-urlmatch <name> <url>`	获取最匹配指定 URL 的配置（如 http 代理）。
`--replace-all`	替换匹配模式的所有行。
`--add`	添加新行而不替换。
`--unset`	删除匹配的行。
`--unset-all`	删除匹配的所有行。
`--rename-section`	重构配置段。
`--remove-section`	删除整个配置段。
`-l, --list`	列出所有配置及其来源。
`-e, --edit`	打开编辑器修改。
`--get-color <name> [<default>]`	获取配置的颜色。
`--get-colorbool <name> [<stdout-is-tty>]`	获取是否应使用颜色。
`值类型约束`
`--type <type>`	强制转换类型（bool, int, bool-or-int, path, expiry-date）。
`--bool, --int, --bool-or-int, --path, --expiry-date`	(过时，建议用 —type)。
`输出控制`
`-z, --null`	输出以 NUL 字符结束。
`--name-only`	仅输出键名。
`--show-origin`	显示配置的来源文件。
`--show-scope`	显示配置的作用域（local, global, system, command）。
`--fixed-value`	将值模式视为字面量字符串而非正则。
`--default <value>`	如果没有匹配项，输出默认值。
`--includes / --no-includes`	查找时是否遵循 include 指令。

31. `git reflog`

git reflog

用途：管理引用日志（记录 HEAD 的每一次移动）

选项	说明
`show [<ref>]`	显示指定引用的日志。
`expire`	清理过期的日志条目。
`--expire=<time>`	设置过期时间（默认 90 天）。
`--expire-unreachable=<time>`	设置不可达条目的过期时间（默认 30 天）。
`--all`	对所有引用执行。
`--rewrite`	重写。
`--updateref`	更新引用。
`--stale-fix`	修复旧的引用记录。
`delete <ref>@ {<specifier>}`	删除特定条目。
`exists <ref>`	检查引用日志是否存在。

32. `git remote`

git remote add origin <url>
git remote -v

用途：管理追踪的远程仓库

| 选项 | 说明 | | ----------------------------------------- | --------------------- | -------------- | ------------------ | | set-head <name> (-a | -d | <branch>) | 设置远程默认分支。 | | set-branches [--add] <name> <branch>... | 设置追踪的分支列表。 | | show [-n] <name>... | 查看远程详情。 | | prune [-n | --dry-run] <name>... | 清理陈旧分支。 | | update [-p | --prune] [<group> | <remote>]... | 批量获取更新。 |

33. `git blame`

git blame

用途：显示文件的每一行最后是谁修改的参数非常详尽，用于深度回溯。完整参数列表：

选项	说明
`-b`	对边界提交显示空白的 SHA-1。
`--root`	不把根提交视为边界。
`--show-stats`	在输出结束时显示统计信息。
`-L <start>,<end>`	只追踪指定范围的行（支持行号、正则、偏移量）。
`-l`	显示长哈希值（默认缩写）。
`-t`	显示原始时间戳。
`-S <revs-file>`	使用来自文件的修订版本。
`--reverse`	反向追溯（查看某行在未来哪个提交被修改/删除）。
`-p, --porcelain`	输出专门为机器解析设计的格式。
`--line-porcelain`	在 porcelain 格式基础上增加每行内容。
`--incremental`	增量输出结果。
`-c`	使用 git annotate 风格。
`--score-debug`	显示文件内移动/复制的调试分数。
`-f, --show-name`	显示原始提交中的文件名。
`-n, --show-number`	显示原始提交中的行号。
`-s`	抑制作者姓名和时间戳的显示。
`-e, --show-email`	显示作者邮箱。
`-w`	忽略空白字符的变化。
`--[no-]abbrev[=<n>]`	指定哈希缩写长度。
`--indent-heuristic`	使用缩进启发式算法。
`--color-lines`	对行注释进行着色。
`--color-by-age`	按代码年龄着色。
`--minimal`	花更多时间寻找最小改动。
`-M[<num>]`	检测文件内的移动。
`-C[<num>]`	检测从其他文件移动或复制而来的行。
`-h`	显示简要帮助。

附录：Git 高级概念

用户接口定义 (User-facing Interfaces)

gitattributes：定义了针对特定路径的属性（如换行符处理、合并策略、差异过滤）
gitignore：匹配规则：/ 前缀表示根目录，* 通配符，! 取反
githooks：关键钩子包括 pre-commit, commit-msg, post-merge, pre-push, update, post-receive
gitrevisions：参数解析顺序、路径规范（Pathspec）语法、修订版本选择语法

开发者协议与格式 (Developer-facing)

format-bundle：.bundle 文件格式定义
format-index：Git 索引文件格式
format-pack：打包文件（.pack/.idx）格式
protocol-v2：Git 有线传输协议版本 2（高性能传输协议）

外部命令 (External Commands)

这些是你系统中安装的、以 git- 开头的非 Git 原生工具，Git 允许直接调用：

bloom-*：Open Robotics 提供的机器人软件发布工具（常用于 ROS 2 仓库管理）
clang-format：代码格式化工具，你可以通过 git clang-format 对暂存区代码进行自动格式化