20Bytes Log

低空具身智能：从空中 VLN 到空中 VLA

Sat, 25 Apr 2026 00:00:00 GMT

区分空中 VLN 与 VLA

2025-2026 年出现的一批空中具身工作会让 VLN / VLA 的边界显得很模糊：它们都在解决“无人机如何听懂语言并飞到目标位置”的问题，但有的论文叫 VLN，有的论文叫 VLA。这个模糊感是合理的，因为大模型正在把“找路（Navigation / Planning）”和“控制（Action / Control）”揉进同一个网络里。

核心判断不要看论文任务名，而要看两个东西：

神经网络最后一层的输出空间（Output Space）。
系统架构中是否仍然依赖传统规划器或控制器兜底。

判别标准

空中 VLN（Aerial Vision-Language Navigation）

网络输出：离散的高级指令（如前、后、左、右、上、下、停止）或三维空间航点（Waypoints，x/y/z 坐标）。

架构特征：AI 当“向导”，传统模块当“飞行员”。大模型主要负责理解语言、看图、选目标点或生成航点，然后交给传统局部规划器或控制器去执行，例如 A*、Receding-Horizon Planner、路径平滑、MPC 或避障模块。

关键点：导航和路径选择是显式的，底层飞行控制没有被神经网络完全接管。

空中 VLA（Aerial Vision-Language-Action）

网络输出：底层的、连续的物理控制信号。在没有机械臂的纯飞行任务中，通常就是连续速度控制指令，例如三轴线速度 v_x/v_y/v_z 加偏航角速度 yaw rate；如果带机械臂，还可能包括夹爪、关节角或末端执行器动作。

架构特征：AI 同时当“向导”和“飞行员”。系统强调端到端（End-to-End），网络高频输出下一步物理动作，避障、减速、侧移、绕行等行为都由策略网络隐式完成，而不是显式交给外部传统规划器。

关键点：动作直接改变具身智能体的物理状态，网络不只是告诉无人机“去哪”，而是直接决定“此刻怎么飞 / 怎么动”。

概念对比

VLA 是否涵盖 VLN？

可以从两个层面回答：

严格算法定义上：VLN 不是 VLA 的简单子集。 VLN 是宏观规划层面的任务，强调“根据语言和视觉找到路”；VLA 是动作控制层面的范式，强调“根据语言和视觉直接输出动作”。
任务能力和系统能力上：VLA 可以涵盖 VLN。 如果一个 VLA 模型接收“飞到红色屋顶上方”的语言指令，并通过连续速度控制最终到达目标位置，那么它已经完成了 VLN 的导航任务。区别是传统 VLN 把“找路”显式输出为航点或决策序列，而 VLA 把“找路”内化到神经网络隐藏状态中，直接吐出最终物理动作。

更直观地说：VLN 像导航地图，告诉你路线；VLA 像自动驾驶系统，不仅知道路线，还直接控制方向、速度和避障。因此，在能力上可以认为 VLA 向下兼容 VLN，但在论文分类时仍要看输出空间和系统架构。

Action 的边界争议

广义 VLA：Locomotion Action

在无人机领域，端到端输出速度本身就可以被视为 Action。原因是无人机需要在三维空间中对抗重力、气流和动态障碍，保持稳定飞行并完成长程导航。这个控制难度不亚于很多地面机器人的运动控制。因此，Velocity Commands、姿态控制或高频运动控制可以构成空中 VLA 的动作空间。

这类工作通常也可以叫 Locomotion VLA，也就是移动控制型 VLA。

狭义 VLA：Manipulation Action

更严格的具身智能定义会要求智能体不仅移动，还要改变物理世界状态，例如抓取、搬运、投放、组装或操作工具。对应到无人机场景，完全体空中 VLA 往往是“无人机 + 机械臂 / 夹爪”的 Aerial Manipulation，需要同时控制飞行平台和末端执行器。

这类工作更接近 Locomotion + Manipulation 的完整 VLA。

Title Inflation

当前学术界存在一定的“标题通胀”：VLA 是热门关键词，很多过去可能被称为 visuomotor policy 或端到端控制策略的工作，现在会被包装成 VLA。判断时不要只看标题，要回到输出空间：如果只是输出航点并依赖 Planner，仍然更接近 VLN；如果直接输出速度、姿态或机械动作，才更接近 VLA。

代表性论文分类

阵营一：模块化 Aerial VLN

OnFly: Onboard Zero-Shot Aerial Vision-Language Navigation toward Safety and Efficiency
- 归类：标准的零样本空中 VLN。
- 原因：核心思路是让 VLM 输出目标候选点（Candidate Goals），再通过语义几何验证器和传统局部规划器（如 Receding-Horizon Planner）保证安全与效率。
- 判断：AI 主要负责看图找航点，最后怎么飞过去、怎么避障，仍由规划器兜底，因此是典型 VLN 范式。
OpenFly: Aerial Vision-Language Navigation via Supervised-to-Reinforced Adaptation
- 归类：基于学习的空中 VLN。
- 原因：它关注从监督学习到强化学习的适应过程，用 RL 提升长序列路径决策的成功率，核心仍是“如何更好地到达终点”。
- 判断：优化对象是导航决策序列，而不是直接高频输出底层飞行控制信号，因此属于 VLN。

阵营二：端到端 Aerial VLA

AutoFly: Vision-Language-Action Model for UAV Autonomous Navigation in the Wild
- 归类：典型的 Locomotion VLA。
- 原因：论文强调端到端 VLA，并直接输出无人机速度控制指令（UAV Velocity Commands）。
- 判断：它抛弃预设航点和传统规划器，让网络直接根据视觉、语言和空间编码输出飞行动作，实现自主避障和导航，因此属于 VLA。
AerialVLA: A Vision-Language-Action Model for Aerial Navigation with Online Dialogue
- 归类：交互式 Aerial VLA。
- 原因：它不仅输出移动动作（Moving Action），还将“向人提问 / 请求澄清”建模为查询动作（Query Action）。
- 判断：系统输出直接决定具身智能体下一步行为：飞行、停留、询问或继续探索。这种把移动与交互都纳入 Action Space 的设计，体现了 VLA Agent 的思想。

一句话判断法

看模型结构图的最后一层：

如果输出的是坐标点、航点、离散方向，或者系统框图里还有 Planner、A*、MPC、Receding-Horizon Planner 等模块，优先归为 VLN。
如果网络直接输入图像和语言，直接输出 speed、velocity command、姿态控制、推力、机械臂关节参数，并强调 End-to-End，优先归为 VLA。

空中具身的发展路线

阶段一：纯 Aerial VLN。 AI 做向导，传统规划与控制模块兜底。
阶段二：移动控制型 Aerial VLA。 端到端输出速度或姿态动作，完成避障、抗扰和导航。
阶段三：空中移动操作。 无人机搭载机械臂或夹爪，实现抓取、搬运和投放等物理交互。
阶段四：多智能体协作 VLA。 无人机蜂群通过大模型进行协同搜索、救援、搭建或巡检。

入局建议

对于刚进入空中具身领域的研究者，较稳妥的路线不是继续卷纯找路 VLN，也不是一开始就做复杂的无人机机械臂真机控制，而是选择 Benchmark + Locomotion VLA 的组合。

学习新一代物理仿真平台，例如 Nvidia Isaac Sim 或 Genesis，尽量避免完全依赖较老的 AirSim 流程。
复现一个端到端输出速度的 baseline，用模仿学习（IL）或强化学习（RL）跑通从文本、图像到三轴线速度 / 角速度的完整数据流。
做一个“小而美”的空中具身 benchmark，例如动态风扰、狭窄空间穿越、空中磁吸 / 抓取、长程语言导航中的实时避障。
做 Sim-to-Real 闭环验证，例如使用 Crazyflie 这类轻量、耐摔、飞控开源的平台，把模型部署到真实无人机上，形成物理世界中的闭环展示。

基建方面

Base Model

Dataset

Benchmark

Framework

VLA

Task：类似于机器人领域的 VLA 任务，只不过这里的 A (Action) 是描述无人机的速度。

VLN（视觉语言导航）

Task：给定一个自然语言指令，指导无人机在环境中导航。

1. 什么是空中视觉语言导航？

2. 空中视觉语言导航的独特挑战：

三维路径规划与六自由度控制

维度增加。无人机在完整的6 DOF（自由度）空间中运行，导致动作空间的复杂性呈指数级增长，使传统规划算法在计算上难以处理。
从路径到轨迹。挑战不仅在于找到航点（路径规划），还在于生成平滑且动态可行的飞行轨迹（轨迹规划），必须考虑无人机的物理约束。
三维障碍物规避。碰撞规避不再是二维问题。无人机必须在杂乱的三维环境中导航，避开静态和动态障碍物，需要实时、全方位的感知。

从空中视角进行语义理解

多变的视角。无人机灵活的视角导致在不同高度和角度下对物体的感知发生巨大的变化，使得一致性识别变得困难。
稀疏的语义信息。空中视角通常覆盖广阔区域，与指令相关的地标可能很小、很远或在视觉上不突出，形成稀疏的语义景观。使得跨模态对齐变得更具挑战性。（vision-language alignment）
对鲁棒语义分割的需求。智能体必须对航拍图像进行鲁棒的语义分割，将像素分类为“建筑”、“道路”等类别，以理解环境结构。

连接仿真与真实世界的无人机部署

用 GitHub Actions 把关注圈动态整理成每日邮件摘要

Sun, 12 Apr 2026 00:00:00 GMT

每天打开 GitHub Dashboard，几百条动态刷出来：某个大厂仓库被几十个人同时 star、机器人在各种 PR 里留评论、github-actions[bot] 贡献了大半的活动量……真正有价值的信号——"某个你关注的人开始了一个新项目"、"某个朋友 fork 了一个不起眼但很有意思的库"——全被淹没在噪声里。

这篇文章记录我是怎么解决这个问题的：用 Python 写一个脚本，搭配 GitHub Actions 每天自动跑，把真正值得看的动态整理成一封 HTML 邮件发给自己，零服务器成本。

1. 问题拆解

解决之前先想清楚"好的摘要"长什么样。我给自己列了三条标准：

聚焦个人行为：我更想知道"张三今天创建了一个新仓库"，而不是"anthropics/claude-code 今天被 40 个人 star 了"。
大厂项目只看数字：Google、Anthropic、OpenAI 这类大厂的项目每天都会有大量 star，列出所有 star 的人名没有意义，只需要知道"今天涨了多少"。
过滤掉机器人：github-actions[bot]、dependabot、renovate 这类账号的活动对我没有信息量，应该直接剔除。

2. 技术选型

| 需求 | 方案 | |---|---| | 获取关注人的动态 | GitHub REST API | | 定时运行 | GitHub Actions（免费） | | 发送邮件 | Python smtplib + Gmail App Password | | AI 摘要（可选） | 兼容 OpenAI 格式的 API |

没有服务器、没有数据库、没有额外费用。整个系统的"基础设施"就是一个 GitHub 仓库和一个 YAML 文件。

3. 核心思路：用对 API 端点

这是整个项目最关键的设计决策，也是最容易走弯路的地方。

GitHub 有一个看起来很合适的接口：

GET /users/{username}/received_events/public

它会返回你 Dashboard 上的聚合动态流。但实际用下来会发现一个严重问题：它会静默丢弃很多事件。Dashboard 上明明显示的动态，这个接口可能根本不返回。

正确做法是分两步走：

第一步：GET /users/{me}/following
         → 拿到你关注的所有人的 login 列表

第二步：对每个人循环调用
         GET /users/{user}/events/public
         → 拿到他们各自的公开动态

这样等于把 GitHub 内部的聚合逻辑自己实现了一遍，结果和 Dashboard 完全一致。

API 调用量估算：假设你关注了 100 人，每天有活动的可能有 30 人：

1 次 /following 请求
100 次 /events/public 请求
30 次 /users/{user} 请求（只对有活动的人拉 profile 用于显示真名）
共 ~131 次，而 GitHub 认证用户每小时限额 5000 次，完全够用

4. 整体架构

项目分成五个模块，按流水线顺序执行：

main.py
  ↓
[1] fetcher.py   — 拉 following 列表 + 每人的动态
  ↓
[2] aggregator.py — 分组、去重、过滤机器人、识别大厂项目
  ↓
[3] summarizer.py — 调用 AI 接口生成 3-6 条摘要（可选）
  ↓
[4] renderer.py   — 生成 HTML 邮件
  ↓
[5] mailer.py     — 通过 SMTP 发送

每一步只负责自己的事，输出传给下一步，方便单独测试和修改。

5. 聚合层的关键设计

aggregator.py 是整个系统信息质量的核心，几个重要决策：

5.1 机器人过滤

GitHub 的官方机器人账号都带有 [bot] 后缀，直接按字符串匹配就能过滤：

def _is_bot(login: str) -> bool:
    if login.endswith("[bot]"):
        return True
    # 少数没有 [bot] 后缀的常见机器人账号
    return login.lower() in {"dependabot", "renovate", "codecov"}

5.2 大厂项目识别

维护一个大厂组织名单，对这些 org 下的仓库在 trending 区只显示数量，不列人名：

BIG_ORGS = {
    "anthropics", "google", "google-gemini",
    "openai", "microsoft", "meta", "nvidia",
    "huggingface", "MiniMax-AI",
    # ... 可以按需扩充
}

def _is_big_org(repo_full_name: str) -> bool:
    org = repo_full_name.split("/")[0]
    return org.lower() in {o.lower() for o in BIG_ORGS}

5.3 个人亮点提取

从所有事件里按优先级提取"值得单独展示"的个人行为：

优先级排序：
  新建仓库 (CreateEvent)  >  发布版本 (ReleaseEvent)
  > fork 了小众项目 (ForkEvent)  > star 了小众项目 (WatchEvent)

大厂仓库的 star 和 fork 不进入个人亮点，避免被大厂活动主导。

6. 邮件结构

最终邮件分为四个区块，从上到下信息密度递减：

🤖 AI 速览         — 3-6 条 AI 提炼的要点（可选）
👤 个人亮点        — 新建仓库、发布版本、fork/star 小众项目
🔥 关注圈热门      — 小众热门（带 @who）/ 大厂项目（只看数量）
👥 按人分组        — 每人完整动态，过滤机器人后按事件数排序

同时展示 GitHub 登录名和真实显示名：

👤 个人亮点
🆕 Peter Steinberger (@steipete) 创建了新仓库 steipete/openclaw
⭐ Vincent Qin (@vincentqyw) star 了 isaaccorley/rsim

7. GitHub Actions 配置

核心是这一段 cron 配置：

on:
  schedule:
    - cron: "0 23 * * *"   # UTC 23:00 = 北京时间 07:00
  workflow_dispatch: {}     # 支持手动触发

所有敏感信息通过 GitHub Secrets 注入，脚本里不硬编码任何账号信息：

env:
  GH_USERNAME: ${{ secrets.GH_USERNAME }}
  GH_TOKEN: ${{ secrets.GH_PAT }}
  SMTP_HOST: ${{ secrets.SMTP_HOST }}
  SMTP_PORT: ${{ secrets.SMTP_PORT }}
  SMTP_USER: ${{ secrets.SMTP_USER }}
  SMTP_PASS: ${{ secrets.SMTP_PASS }}
  MAIL_FROM: ${{ secrets.MAIL_FROM }}
  MAIL_TO: ${{ secrets.MAIL_TO }}

8. 本地测试

用 SKIP_EMAIL=1 环境变量可以跳过发邮件，只在本地生成 HTML 文件查看效果：

# 复制 .env.example 并填好配置
cp .env.example .env

# 加载配置，跳过发邮件，只生成 HTML
export $(cat .env | grep -v '^#' | xargs)
SKIP_EMAIL=1 python main.py

# 用浏览器打开查看效果
xdg-open output/digest-*.html   # Linux
open output/digest-*.html        # macOS

9. 几个踩过的坑

received_events 的坑：最开始用 /received_events/public，发现大量关注的人的活动根本不出现。排查了很久才意识到是 GitHub 那边的聚合策略问题，换成逐人拉取后完全解决。

SMTP 端口类型错误：在 GitHub Secrets 里填写端口号时，值被 Actions 读取后如果带了多余空格会导致 int() 转换失败。确保填入的是纯数字，没有引号和空格。

机器人噪声：最初的版本里 github-actions[bot] 贡献了超过 60 条"动态"，占据了大半版面。加了 bot 过滤后，邮件内容密度一下子提高了很多。

大厂项目列人名：早期版本在 trending 区把 anthropics/claude-code 的 35 个 starer 全部列出来，用处不大还占空间。按 org 分类后改成"35 人 star"，清晰多了。

10. 可扩展的方向

DIGEST_HOURS 参数：改成 168 就变成每周摘要
事件类型过滤：不关心 IssueCommentEvent 的话，直接在 aggregator 里注释掉
大厂名单：BIG_ORGS 是一个普通的 Python set，按需增删
邮件样式：renderer.py 顶部的 CSS 常量可以直接改

11. 总结

这个项目的核心并不复杂，一个 300 行的 Python 脚本加上一个 40 行的 GitHub Actions YAML，就能把一个每天手动刷 Dashboard 的习惯变成一封每天自动送到邮箱的摘要。

真正花时间的不是写代码，而是想清楚"什么信息对我有价值"——过滤掉机器人、区分大厂和小众项目、把个人行为置顶——这几个决策让最终的邮件质量差别很大。

如果你也被 GitHub Dashboard 的信息量压倒，可以参考这个思路自己搭一套。

GitHub PR 流程指南：从 Fork 到 Merge 的标准七步法

Sat, 11 Apr 2026 00:00:00 GMT

PR 是协作的核心。即便你只是修复一个很小的 Bug，比如某个 Issue 里提到的边界情况问题，最终也往往要通过 Pull Request 把修改提交给维护者审查、讨论，再合并进主分支。

如果你是第一次给别人的仓库贡献代码，最容易卡住的并不是写代码本身，而是不清楚整套流程该怎么走。本文就按照一个最常见的开源协作场景，把 GitHub PR 的标准流程完整走一遍。

1. 标准 PR 七步法

| 步骤 | 作用 | 命令 / 动作 | | --- | --- | --- | | 1. Fork | 把别人的仓库复制到自己的 GitHub 账号下 | 点击原仓库右上角 Fork | | 2. Clone | 把自己账号下的仓库下载到本地 | git clone https://github.com/你的名字/仓库名.git | | 3. Branch | 为本次修改创建独立分支，不直接改 main | git checkout -b fix-bug-description | | 4. Commit | 编写代码并提交，提交信息要清晰 | git commit -m "fix: handle empty array in geval" | | 5. Push | 把本地分支推送到自己的 GitHub 仓库 | git push origin fix-bug-description | | 6. Open PR | 从你的分支发起 Pull Request | GitHub 页面点击 Compare & pull request | | 7. Review | 等待审核并根据反馈继续修改 | 回复评论、追加提交，直到被合并 |

先记住一句最重要的话：

永远不要直接在 main 分支上改代码并提交 PR。

这样做的好处是，你的每一次修改都是独立、可回退、可审查的，不会把别的实验性代码混在一起。

2. 开始前先理解：PR 到底是什么

PR 的全称是 Pull Request。它并不是“把代码直接塞给别人”，而是：

你先在自己的分支完成修改。
然后发起一个“请把我这部分改动拉进来”的请求。
维护者查看差异、提出意见、要求修改或直接合并。

所以 PR 本质上既是代码提交方式，也是沟通方式。好的 PR 不只是在“交代码”，更是在告诉 reviewer：

我改了什么
为什么这样改
影响范围是什么
我已经怎么验证过

3. 第一步：Fork 仓库

如果你没有原仓库的直接写权限，通常第一步就是 Fork。

Fork 的作用是把原仓库复制一份到你自己的账号下。比如原仓库是：

https://github.com/original-author/project

Fork 之后，你会得到：

https://github.com/your-name/project

后续你的所有修改，都会先推到你自己的这个仓库里，而不是直接推到原作者的仓库。

适用场景很简单：

开源项目贡献代码：通常需要 Fork
团队内部仓库且你有写权限：有时可以直接拉分支，不一定需要 Fork

4. 第二步：Clone 到本地

Fork 完成后，把自己的仓库克隆到本地：

git clone https://github.com/your-name/project.git
cd project

这一步的作用是把远程代码下载到你电脑上，方便你本地开发、运行和测试。

如果你准备长期给这个项目贡献代码，推荐额外配置一个 upstream，也就是原仓库地址：

git remote add upstream https://github.com/original-author/project.git
git remote -v

这样以后同步原仓库更新会更方便。

5. 第三步：创建分支

不要在 main 上直接开发，而是为这次任务单独建一个分支：

git checkout -b fix-bug-description

如果你已经提前配置了 upstream，更稳妥的做法是先同步原仓库主分支，再切新分支：

git checkout main
git pull upstream main
git checkout -b fix-bug-description

分支命名建议做到“看名字就知道在做什么”，常见格式如下：

fix-empty-array-bug
docs-update-pr-guide
feat-user-profile

分支名不要起成 test、new-branch、update 这种信息量太低的名字，否则后面自己都容易看不懂。

6. 第四步：编码并提交 Commit

接下来就是正常改代码、运行测试、确认修改没有问题，然后提交。

git add .
git commit -m "fix: handle empty array in geval"

Commit message 最好满足两个要求：

一眼能看懂你改了什么
使用动词开头，尽量具体

几个对比：

好的写法：fix: handle empty array in geval
好的写法：docs: add pull request workflow guide
不推荐：update code
不推荐：fix bug

如果改动比较复杂，也可以拆成多次 commit。比起一个超大的提交，reviewer 通常更喜欢一组边界清晰的小提交。

7. 第五步：Push 到自己的远程仓库

本地提交完成后，把分支推送到 GitHub：

git push origin fix-bug-description

第一次推送新分支时，也可以这样写：

git push -u origin fix-bug-description

加上 -u 后，Git 会记住本地分支和远程分支的跟踪关系。以后你再执行 git push、git pull 会更省事。

推送成功后，GitHub 通常会提示你这个分支刚刚更新，并给出一个快捷入口，让你直接发起 PR。

8. 第六步：Open PR

现在回到 GitHub 页面，你会看到一个 Compare & pull request 按钮。点击之后，就进入创建 PR 的页面。

这里最重要的是检查两件事：

base repository 和 base branch 是否正确
head repository 和 compare branch 是否是你刚才推送的分支

多数情况下，你的目标应该是：

base: original-author/project <- main
compare: your-name/project <- fix-bug-description

PR 标题建议直接概括这次改动，例如：

fix: handle empty array in geval
docs: add GitHub PR workflow guide
feat: support custom avatar upload

PR 描述则建议至少写清楚这几件事：

## 变更内容
- 修复空数组情况下的异常处理

## 为什么修改
- 某些输入会导致函数提前报错

## 如何验证
- 补充了测试用例
- 本地执行相关测试通过

## 影响范围
- 仅影响 `geval` 的边界处理逻辑

如果是界面类修改，附上截图；如果关联某个 Issue，也可以写上 Closes #8613 之类的说明，让 GitHub 在 PR 合并后自动关闭对应 Issue。

9. 第七步：Review 与二次修改

发起 PR 并不意味着流程结束，很多时候这一步才是真正的协作开始。

维护者可能会：

直接通过并合并
提出代码风格建议
要求补测试
询问为什么这样实现
建议换一种更稳妥的写法

你需要做的是继续在同一个分支上修改，然后再次提交并 push：

git add .
git commit -m "refactor: simplify edge case handling"
git push origin fix-bug-description

不需要重新开一个新的 PR。只要你继续往这个分支 push，当前 PR 会自动更新。

这也是很多新手第一次用 PR 时最容易误解的地方：PR 不是“一次性投递”，而是“围绕同一个分支持续迭代”。

10. 新人最常见的三个坑

10.1 直接在 `main` 上改代码

这是最常见的问题。这样做会让你的工作分支混乱，也不利于后续继续同步上游仓库。

10.2 PR 太大

如果一个 PR 同时改了 Bug、重构、文档、样式、命名，reviewer 会很难看。尽量做到一个 PR 只解决一个明确问题。

10.3 只写标题，不写描述

对你自己来说你当然知道改了什么，但 reviewer 不一定知道。PR 描述写得越清楚，审核速度通常越快。

11. 一套适合直接照抄的完整命令

下面是一套最常见的开源贡献命令流，你可以直接代入仓库地址和分支名：

# 1. 克隆自己的 Fork
git clone https://github.com/your-name/project.git
cd project

# 2. 添加上游仓库
git remote add upstream https://github.com/original-author/project.git

# 3. 同步主分支
git checkout main
git pull upstream main

# 4. 新建功能分支
git checkout -b fix-bug-description

# 5. 修改代码后提交
git add .
git commit -m "fix: handle empty array in geval"

# 6. 推送到自己的仓库
git push -u origin fix-bug-description

然后回到 GitHub 页面，点击 Compare & pull request，补全标题和描述，等待 review 即可。

12. 总结

一个标准的 GitHub PR 流程，可以概括为：

Fork -> Clone -> Branch -> Commit -> Push -> Open PR -> Review

把这七步跑顺之后，你就已经具备参与大多数开源项目协作的基础能力了。真正的重点不只是“把代码传上去”，而是通过清晰的分支、提交和 PR 描述，让别人更容易理解并接受你的修改。

如果你把 PR 当成一次正式沟通，而不仅仅是一段代码上传，协作体验会顺畅很多。

13. 参考资料

构建个人学术追踪系统：自动化 arXiv 论文监控实践

Sat, 11 Apr 2026 00:00:00 GMT

在AI领域，每天arXiv上都会涌现大量新论文。对于专注于特定方向的研究者来说， manually 浏览和筛选既耗时又低效。这篇文章将分享我搭建的一套自动化论文追踪系统的完整思路，希望能给有类似需求的同学一些参考。

项目动机

在关注 Vision-Language-Action (VLA)、Vision-Language Navigation (VLN) 等具身智能方向时，我遇到了几个痛点：

信息过载：arXiv每天上新数百篇论文，手动筛选效率极低
语言障碍：英文标题和摘要阅读成本高，快速理解核心贡献需要时间
兴趣匹配：不同研究方向关注点不同，需要个性化过滤
知识管理：看过的论文容易遗忘，缺乏系统化的标记和回顾机制

基于这些需求，我设计并实现了一套自动化解决方案。

系统架构概览

整个系统由三个核心模块组成：

| 模块 | 功能 | 技术方案 | |------|------|----------| | 数据采集 | 从arXiv抓取目标领域论文 | arxiv-python + 定时任务 | | 内容处理 | 翻译、格式化、去重 | DeepSeek API + 缓存机制 | | 展示交互 | Web端展示与个性化标记 | GitHub Pages + localStorage |

┌─────────────┐     ┌──────────────┐     ┌─────────────┐
│   arXiv     │────▶│   Python     │────▶│   GitHub    │
│   API       │     │   处理脚本   │     │   Pages     │
└─────────────┘     └──────────────┘     └─────────────┘
                           │                    │
                           ▼                    ▼
                    ┌──────────────┐     ┌─────────────┐
                    │  DeepSeek    │     │  用户标记   │
                    │  翻译服务    │     │  & 筛选    │
                    └──────────────┘     └─────────────┘

核心实现细节

1. 精准的关键词检索策略

不同于简单的关键词匹配，系统支持多维度复合检索。以VLA领域为例：

keywords:
  "VLA":
    filters:
      - "Vision-Language-Action Model"
      - "Vision Language Action"
      - "VLA Model"
      - "RT-2"
      - "OpenVLA"

通过 OR 逻辑组合多个相关关键词，可以最大程度避免遗漏，同时通过分层配置支持多领域并行追踪。

2. 智能双语展示

论文标题和摘要的翻译是提升阅读效率的关键。系统采用了以下策略：

翻译流程：

首次遇到论文时，调用大模型API进行翻译
翻译结果缓存到本地JSON文件，避免重复调用
增量更新机制，只处理新增论文

提示工程：

system_prompt = (
    "Translate the paper title and abstract into Chinese. "
    "Return only JSON with keys: title_zh, abstract_zh."
)

这种结构化的翻译要求确保输出格式统一，便于后续处理。

3. HJFY集成：便捷的PDF访问

系统集成了 HJFY 学术搜索服务，为每篇论文生成直接访问链接。这解决了arXiv访问不稳定的问题，提供了更流畅的PDF阅读体验。

4. Web端个性化标记

在生成的GitHub Pages页面中，每篇论文都配有交互式评估按钮：

✅ 已读：标记已浏览过的论文
❌ 跳过：不感兴趣，后续可过滤
⭐ 收藏：重要论文，需要深度阅读

技术实现：

// 使用localStorage保存用户标记
const storageKey = (id) => `vlm_arxiv_daily_eval:${id}`;
localStorage.setItem(storageKey(arxivId), evaluation);

这种设计的好处是：

无需后端服务器，纯前端实现
用户数据保存在本地，隐私安全
跨会话持久化，刷新不丢失

5. 摘要独立页面

为了提供更好的阅读体验，系统为每篇论文生成独立的摘要页面：

中英文摘要对照展示
简洁的排版设计
一键返回主列表

这些页面通过脚本自动生成，维护成本极低。

自动化运维

GitHub Actions 定时任务

利用GitHub Actions实现每日自动更新：

on:
  schedule:
    - cron: '0 1 * * *'  # 每天凌晨1点执行
  workflow_dispatch:     # 支持手动触发

jobs:
  update-papers:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Run crawler
        run: python daily_arxiv.py
      - name: Commit changes
        run: |
          git add .
          git commit -m "Update daily papers"
          git push

增量更新机制

为了避免重复处理，系统实现了多层缓存：

翻译缓存：已翻译的论文ID和结果
论文数据缓存：arXiv元数据
摘要缓存：英文原文存储

这种设计使得每日更新通常在几秒内完成，API调用成本也大幅降低。

技术亮点与优化

1. 优雅的错误处理

网络请求和API调用都有完善的异常处理：

try:
    resp = requests.post(url, headers=headers, json=payload, timeout=60)
    resp.raise_for_status()
except Exception as exc:
    logging.warning(f"Translation failed: {exc}")
    return {}

2. Markdown到HTML的灵活转换

系统支持生成多种输出格式：

README.md：GitHub仓库展示
docs/index.html：GitHub Pages交互式页面
docs/wechat.md：微信公众号文章格式

通过配置灵活切换，一份代码满足多平台需求。

3. 数学公式排版优化

针对论文标题中常见的LaTeX数学公式，实现了简单的格式化：

def pretty_math(s: str) -> str:
    # 处理 $...$ 格式的行内公式
    match = re.search(r"\$.*\$", s)
    if match:
        # 添加适当的空格，提升渲染效果
        ...

实际效果

经过几个月的运行，这套系统带来了显著的效率提升：

时间节省：从每天30-40分钟的浏览筛选，缩短到5分钟快速浏览
信息完整：双语展示降低了理解门槛
知识沉淀：通过标记系统建立了个人论文库
社区价值：开源后帮助了同领域的研究者

扩展思路

这个系统的架构可以很容易地扩展到其他场景：

多领域追踪：通过修改配置文件，可以追踪任意arXiv分类
邮件订阅：增加邮件推送功能，每日发送精选论文
RSS输出：生成RSS feed，方便集成到阅读器
协作标记：结合后端数据库，实现团队共享的论文库

总结

这套系统的核心思想是：自动化处理重复性工作，保留人的判断和决策。技术本身并不复杂，关键在于：

清晰定义需求，解决真实痛点
合理选择技术方案，避免过度工程化
注重用户体验，降低使用门槛
保持可扩展性，预留迭代空间

对于研究者来说，工具的价值不在于功能多复杂，而在于能否真正提升工作效率。希望这篇文章能给正在考虑搭建类似系统的同学一些启发。

致谢

本项目基于 cv-arxiv-daily 二次开发，在此感谢原作者 @Vincentqyw 的开源贡献。同时也要感谢 HJFY 提供的学术搜索服务，让论文PDF访问更加便捷。

开源社区的力量让这些工具不断完善，如果你也从中受益，欢迎star和支持相关项目。

参考资源

Git 实用指南：从重置仓库到代码贡献标准工作流

Mon, 09 Mar 2026 00:00:00 GMT

1. 从本地代码重建全新的 GitHub 仓库

有时候本地已经有一份代码，但原来的 Git 仓库历史不再需要。最直接的做法是删除旧的 Git 信息，然后在 GitHub 上新建一个空仓库重新提交。

核心步骤

删除本地旧 Git 信息：
```
cd /path/to/your/project-name
rm -rf .git
```
这会清空提交历史和远程关联，但保留代码文件。
重新初始化本地仓库：
```
git init
git branch -M main
```
在 GitHub 新建空仓库：不要勾选 README、.gitignore 或 License。

关联新的远程仓库并推送：

git remote add origin [https://github.com/your-username/your-repo-name.git](https://github.com/your-username/your-repo-name.git)
git add .
git commit -m "Initial commit"
git push -u origin main

2. 代码贡献与团队协作标准工作流 (Workflow)

对于参与团队项目，我们有一套标准的协作流程。强烈建议在开始前系统学习 Git 的版本管理。

2.1 环境准备与克隆

登录：使用加入了该 repo 权限的 GitHub 账号登录。
下载 Git：Git 官方下载
克隆仓库：获取远程代码到本地，请务必使用 git clone 而不是直接 Download ZIP。(如果国内使用不稳定，建议配置好网络环境)。

git clone [https://github.com/your-organization/your-repo-name.git](https://github.com/your-organization/your-repo-name.git)

2.2 同步主分支与创建开发分支

每次开发新功能前，确保基于最新的 main 分支拉取新的工作分支：

# 切换到主分支并同步远程最新代码
git checkout main 
git pull 

# 创建并切换到新分支进行开发
git checkout -b feature-your-new-task

分支命名规范：

一个分支只对应一个任务。

名称通常为 2-3 个单词，尽量简洁明了（如 feature-login-page）。

如果可能重名，可以加时间戳避免冲突（如 feature-login-250601）。

好例子：issue-15

坏例子：yaml（缺乏信息量）、branch-new-feature（没必要加 branch 前缀）

2.3 编写代码与提交 (Commit)

修改代码时，请始终确保自己在刚才创建的任务分支上工作（可通过 VSCode 左下角状态栏确认）。

AI 辅助：尽量利用 AI（Cursor / Claude / Trae）辅助编程，可通过 @ 引入文件或整个代码库上下文。
提交原则：提交前必须进行测试。每次提交应尽可能小但完整。切勿提交庞大的数据文件！
提交流程：强烈建议使用 VSCode 自带的图形化界面（Source Control）进行 add 和 commit，这比纯命令行更直观。

Commit Message 规范：

标题行（首行）：5-10 个词，简明扼要。

详细正文（可选）：与标题行空一行，用 1-3 句话描述复杂的变更细节。

2.4 发布分支与合并请求 (Pull Request)

尽早与 Reviewer 分享你的代码以获取反馈。

推送分支：点击 VSCode 中的 Publish/Push 按钮，或者运行：
```
git push -u origin your-branch-name
```
创建 PR：在 GitHub 上针对刚才推送的分支发起 Pull Request (PR)。
- 注意：非常小心地检查 PR 的目标分支（通常是 origin/main）。
- PR 标题：一般 5-10 个单词，以动词开头（例如："add user login feature"）。不要用 "fix a bug" 这种过于宽泛的标题。
- PR 描述：如有需要，请将测试结果、详细说明粘贴到评论中，附上截图更佳。

2.5 代码审查 (Review)

在 GitHub 上请求审阅（Request Reviews），或者在评论中 @reviewer。
若具备权限，推荐添加 GitHub Copilot 等 AI 工具作为辅助审阅者。
根据反馈修改代码，提升 PR 质量，直到获得 Approval。

3. 学习资源与参考资料

如果你想深入学习 Git，以下资源非常值得推荐：

官方与图形化教程：
- Atlassian Git Tutorials
- VSCode 中的 Git 使用指南
可视化交互式学习：
- Learn Git Branching（强推！以可视化的方式学习 Git 分支）
底层原理解读：
- 【中文字幕】Linus 在 2007 年 Google Talk 上介绍 Git
- 深入理解 Git Merge 工作原理

WSL Ubuntu 22.04（Bot）创建流程文档

Tue, 24 Feb 2026 00:00:00 GMT

一、目标

新建 WSL 实例
名称：Bot
系统：Ubuntu 22.04
安装位置：F:\WSL\Bot
使用方式：--import（tar 模式，推荐）

二、准备工作

1. 创建安装目录

在 PowerShell 执行：

mkdir F:\WSL\Bot

三、下载 Ubuntu 22.04 WSL rootfs

官方目录：

https://cloud-images.ubuntu.com/wsl/jammy/current/

下载文件（普通 PC 选择 amd64）：

ubuntu-jammy-wsl-amd64-ubuntu22.04lts.rootfs.tar.gz

下载后放在：

F:\WSL\

例如：

F:\WSL\ubuntu-jammy-wsl-amd64-ubuntu22.04lts.rootfs.tar.gz

四、导入为新的 WSL 实例

执行：

wsl --import Bot F:\WSL\Bot F:\WSL\ubuntu-jammy-wsl-amd64-ubuntu22.04lts.rootfs.tar.gz --version 2

提示：

操作成功完成。

五、启动系统

wsl -d Bot

首次进入默认是 root 用户：

root@xxx:#

六、创建普通用户（推荐）

1. 创建用户

adduser bot

填写密码，其余信息直接回车。

2. 添加 sudo 权限

usermod -aG sudo bot

七、设置默认登录用户（永久）

编辑配置文件：

nano /etc/wsl.conf

写入：

[user]
default=bot

保存退出后，在 PowerShell 执行：

wsl --shutdown

重新进入：

wsl -d Bot

应显示：

bot@xxx:~$

八、初始化系统（推荐）

sudo apt update && sudo apt upgrade -y
sudo apt install build-essential git curl wget -y

作用：

更新系统
安装基础开发工具

九、验证安装

wsl -l -v

应显示：

Blogs_U24
Bot

最终结构

F:\WSL\
├── Bot
└── ubuntu-jammy-wsl-amd64-ubuntu22.04lts.rootfs.tar.gz

关键说明

推荐使用 --import（tar 模式），不依赖微软商店
可自定义安装位置
方便备份与迁移
更适合开发环境

如果你需要，我可以再给你整理：

WSL 迁移流程
备份恢复流程
性能优化配置
Python / Docker 初始化模板

经典基础网络回顾

Fri, 20 Feb 2026 00:00:00 GMT

import { ArxivRating, RatingCriteria } from '@/components/advanced'

论文速览

| 论文 | 年份 | 方向 | | --- | --- | --- | | LeNet-5 | 1998 | CNN 早期代表：卷积+池化+端到端训练（IEEE 1998） | | AlexNet | 2012 | ImageNet 突破：GPU+ReLU/Dropout 等（NeurIPS 2012） | | VGG | 2014 | 3×3 小卷积核深层堆叠，迁移友好（ICLR 2015） | | Inception-v1 (GoogLeNet) | 2014 | 多尺度并行卷积，控开销（CVPR 2015） | | ResNet | 2015 | 残差连接，深层可训练（CVPR 2016） | | DenseNet | 2016/2017 | 稠密连接，特征复用强、参数高效（CVPR 2017） | | Transformer | 2017 | 自注意力范式：从 NLP 扩展到视觉（NeurIPS 2017） |

LeNet-5 (1998)

AlexNet

VGG

Inception-v1 (GoogLeNet)

ResNet

DenseNet

Transformer

目标检测发展进程

Sat, 21 Feb 2026 00:00:00 GMT

import { ArxivRating, RatingCriteria } from '@/components/advanced'

方法分类总览

| 大类 | 子类 | 代表论文 | | --- | --- | --- | | Two-stage | R-CNN 系谱 | R-CNN（CVPR 2014）、SPPnet（ECCV 2014）、Fast R-CNN（ICCV 2015）、Faster R-CNN（NeurIPS 2015）、FPN（CVPR 2017）、Mask R-CNN（ICCV 2017） | | One-stage | YOLO | YOLOv1（CVPR 2016）、YOLOv3（arXiv 2018）、YOLOX（arXiv 2021）、YOLOv5（Ultralytics）、YOLOv8（Ultralytics）、YOLO11（Ultralytics）、YOLOv12（arXiv 2025）、YOLO26（Ultralytics） | | One-stage | Dense / Anchor(-free) | SSD（ECCV 2016）、RetinaNet / Focal Loss（ICCV 2017）、FCOS（ICCV 2019）、CenterNet（CVPR 2019）、ATSS（CVPR 2020）、GFL（CVPR 2021） | | Transformer | ViT 预备工作 | ViT: An Image is Worth 16x16 Words（ICLR 2021） | | Transformer | DETR 基线与改进 | DETR（ECCV 2020）、Conditional DETR（ICCV 2021）、Dynamic DETR（ICCV 2021）、Deformable DETR（ICLR 2021）、DAB-DETR（ICLR 2022）、DN-DETR（CVPR 2022）、DINO（ICLR 2023）、DQ-DETR（ECCV 2024）、DEIM（CVPR 2025）、D-FINE（ICLR 2025） | | Transformer | 实时 DETR | RT-DETR（CVPR 2024）、RT-DETRv2（arXiv 2024）、RT-DETRv3（WACV 2025） |

Fast R-CNN 系列（Two-stage）

R-CNN

SPPnet

Fast R-CNN

Faster R-CNN

FPN

Mask R-CNN

One-stage 经典 Dense/Anchor(-free) 路线

SSD

RetinaNet / Focal Loss

FCOS

CenterNet

ATSS

GFL

YOLO 系列（One-stage）

YOLOv1

YOLOv3

YOLOX

YOLOv5（Ultralytics）

YOLOv8（Ultralytics）

YOLO11（Ultralytics）

YOLOv12

YOLO26（Ultralytics）

Transformer 系列

预备工作：ViT

DETR 基线与改进

DETR

Conditional DETR

Dynamic DETR

Deformable DETR

DAB-DETR

DN-DETR

DINO

DQ-DETR

DEIM

D-FINE

实时 DETR 分支

RT-DETR（DETRs Beat YOLOs on Real-time Object Detection）

RT-DETRv2

RT-DETRv3

LLM 经典脉络回顾

Sun, 22 Feb 2026 00:00:00 GMT

import { ArxivRating, RatingCriteria } from '@/components/advanced'

脉络总览（按演进顺序）

| 阶段 | 主题 | 代表论文 | | --- | --- | --- | | 基础架构 | Transformer 统一序列建模 | Attention Is All You Need（NeurIPS 2017） | | 预训练范式 | 编码器与通用表征 | BERT（NAACL 2019） | | LLM 爆发 | 少样本能力与规模效应 | GPT-3 / Language Models are Few-Shot Learners（NeurIPS 2020） | | 规模方法论 | Scaling Laws 与算力分配 | Scaling Laws for Neural Language Models（2020） | | 规模方法论 | 计算最优训练（Chinchilla） | Training Compute-Optimal Large Language Models（NeurIPS 2022） | | 外部知识 | RAG 检索增强生成 | Retrieval-Augmented Generation（NeurIPS 2020） | | 稀疏计算 | MoE 扩展到万亿参数 | Switch Transformers（JMLR 2022） | | 对齐与指令跟随 | RLHF 训练指令模型 | Training language models to follow instructions with human feedback（NeurIPS 2022） | | 推理能力 | CoT 提示引出推理 | Chain-of-Thought Prompting（2022） | | 开源高效 | 公开数据训练强 LLM | LLaMA（2023） |

基础架构

Transformer

预训练范式

BERT

LLM 爆发

GPT-3

规模方法论（Scaling）

Scaling Laws

Chinchilla / 计算最优训练

外部知识与记忆

RAG

稀疏计算（MoE）

Switch Transformers

对齐与指令跟随（Alignment）

InstructGPT / RLHF

推理能力（Reasoning）

Chain-of-Thought

开源高效（Open LLM）

LLaMA

公司 / 团队谱系（按机构分类）

DeepSeek（算法 + 训练范式 + 模型演进）

| 方向 | 关键词 | 代表论文 | | --- | --- | --- | | 强化学习推理 | GRPO | DeepSeekMath（2024） | | 推理能力 | RL 驱动推理 | DeepSeek-R1（2025） | | 推理/泛化增强 | Training-Free GRPO | Training-Free GRPO（2025） | | 模型迭代 | 高效开放模型 | DeepSeek-V3.2（2025） | | 架构与扩展 | mHC | mHC: Manifold-Constrained Hyper-Connections（2025/2026） | | 方法总结 | DeepSeek 范式 | DeepSeek: Paradigm Shifts and Technical Evolution…（2025） |

DeepSeekMath（GRPO）

DeepSeek-R1

Training-Free GRPO

DeepSeek-V3.2

mHC

DeepSeek 范式总结（含 GRPO/MLA/MoE/MTP 等）

IsaacGym 环境搭建完整指南

Sat, 07 Feb 2026 00:00:00 GMT

1. 前言

IsaacGym 是 NVIDIA 推出的高性能物理仿真环境，专为强化学习和机器人研究设计。本文详细记录了在 Ubuntu 18.04 系统上搭建 IsaacGym 和 unitree_rl_gym 环境的完整流程，以及在搭建过程中可能遇到的问题和解决方案。

2. 服务器配置

本次搭建使用的服务器配置如下：

操作系统：Ubuntu 18.04.6 LTS
CPU：Intel® Core™ i7-8700 CPU @ 3.20GHz × 12
内存：15.6 GiB
存储：1.2 TB（可用 3.3GB）
GPU：GeForce（具体型号未在文档中说明）

3. 安装步骤

步骤 1：下载 unitree_rl_gym 项目

在 /home/ros-melodic/Desktop 目录下载 unitree_rl_gym 项目：

cd /home/ros-melodic/Desktop
git clone https://github.com/unitreerobotics/unitree_rl_gym.git

项目地址：unitreerobotics/unitree_rl_gym

步骤 2：创建 Conda 虚拟环境

使用 conda 建立虚拟环境，推荐使用 Python 3.8：

conda create -n unitree_rl_gym python=3.8
conda activate unitree_rl_gym

步骤 3：安装 PyTorch 和 CUDA

安装 PyTorch 1.10.0 和对应的 CUDA 11.3 版本：

pip3 install torch==1.10.0+cu113 torchvision==0.11.1+cu113 torchaudio==0.10.0+cu113 -f https://download.pytorch.org/whl/cu113/torch_stable.html

步骤 4：安装 Isaac Gym

从 NVIDIA 官网下载 Isaac Gym Preview 4：https://developer.nvidia.com/isaac-gym
将下载的 Isaac Gym 放入 unitree_rl_gym-main 目录下便于管理
安装 Isaac Gym：

cd isaacgym/python
pip install -e .

步骤 5：安装 rsl_rl 算法库

注意：项目要求 rsl_rl 版本为 v1.0.2，并非最新 master 版本，且使用 pip 不能指定 v1.0.2 版本，需要通过 git 安装：

git clone https://github.com/leggedrobotics/rsl_rl.git
cd rsl_rl
git checkout v1.0.2
pip install -e .

步骤 6：设置 unitree_rl_gym 环境

返回 unitree_rl_gym-main 目录，设置环境：

cd ../unitree_rl_gym-main
pip install -e .

重要注意事项：

numpy 版本问题：项目会默认安装 numpy 1.20.0 版本（过于古早），推荐使用 1.21.6 版本：

pip install numpy==1.21.6

setuptools 版本问题：步骤 2 中安装的 Python 3.8 默认 setuptools 为 72.0.0 版本，可能会导致项目中 import 出现问题，推荐使用 58.0.0 版本，且不能使用 conda 安装：

pip install setuptools==58.0.0

步骤 7：测试 demo

运行 go2 机器人的训练脚本进行测试：

python legged_gym/scripts/train.py --task=go2

如果能够正常运行，说明环境搭建成功。

4. 常见问题及解决方案

问题：libpython3.8.so.1.0 缺失

在运行 Isaac Gym 时，可能会遇到 libpython3.8.so.1.0 缺失的错误。以下提供两种解决方案：

方案 1：临时设置 LD_LIBRARY_PATH

确认 LD_LIBRARY_PATH 是否包含 conda 环境的库目录：

echo $LD_LIBRARY_PATH

查找 libpython3.8.so.1.0 文件：

find $(conda info --base) -name libpython3.8.so.1.0 2>/dev/null

如果找到了文件（假设路径是 /home/ros-melodic/mambaforge/envs/unitree_rl_gym/lib/），设置环境变量：

export LD_LIBRARY_PATH=/home/ros-melodic/mambaforge/envs/unitree_rl_gym/lib:$LD_LIBRARY_PATH

永久设置（添加到 ~/.bashrc）：

echo 'export LD_LIBRARY_PATH=/home/ros-melodic/mambaforge/envs/unitree_rl_gym/lib:$LD_LIBRARY_PATH' >> ~/.bashrc
source ~/.bashrc

方案 2：Conda 环境下永久解决方法

这是更优雅的解决方案，通过 conda 的环境激活/停用脚本来自动管理环境变量：

确定 libpython3.8.so.1.0 位置：

sudo updatedb
locate libpython3.8.so.1.0

如果是在 conda 虚拟环境中安装的，应该位于 $CONDA_PREFIX/lib 目录。

conda activate unitree_rl_gym
cd $CONDA_PREFIX
mkdir -p ./etc/conda/activate.d
mkdir -p ./etc/conda/deactivate.d
touch ./etc/conda/activate.d/env_vars.sh
touch ./etc/conda/deactivate.d/env_vars.sh

编辑 activate.d/env_vars.sh，添加以下内容：

export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$CONDA_PREFIX/lib

编辑 deactivate.d/env_vars.sh，添加以下内容：

# 保存原始的 LD_LIBRARY_PATH
ORIGINAL_LD_LIBRARY_PATH=$LD_LIBRARY_PATH

# 要删除的目录
DIRECTORY_TO_REMOVE="$CONDA_PREFIX/lib"

# 使用 grep 过滤掉要删除的目录项
NEW_LD_LIBRARY_PATH=$(echo $LD_LIBRARY_PATH | tr ':' '\n' | grep -v "$DIRECTORY_TO_REMOVE" | tr '\n' ':')

# 设置新的 LD_LIBRARY_PATH
export LD_LIBRARY_PATH=$NEW_LD_LIBRARY_PATH

这样设置后，每次激活 conda 环境时会自动添加库路径，停用环境时会自动移除，不会影响其他环境。

5. 总结

本文详细介绍了 IsaacGym 和 unitree_rl_gym 环境的搭建流程，包括：

完整的 7 步安装流程
关键依赖版本的选择（Python 3.8、PyTorch 1.10.0、numpy 1.21.6、setuptools 58.0.0）
常见的 libpython3.8.so.1.0 缺失问题的两种解决方案

在搭建过程中，特别需要注意版本兼容性问题，尤其是 rsl_rl 必须使用 v1.0.2 版本，以及 numpy 和 setuptools 的版本选择。通过本文的指导，可以顺利完成 IsaacGym 环境的搭建，为后续的强化学习研究和机器人仿真打下基础。

我的第一篇博文

Sat, 17 Jan 2026 00:00:00 GMT

1. 前言

作为 AI 领域的 Researcher，我深知技术更新换代的速度之快。为了更好地记录和分享我的学习与研究过程，我决定开启个人博客。在这里，我将分享我的技术见解、研究成果以及日常生活点滴。

2. 我的博客的主要设计

本博客基于 Axi-Theme 主题，根据 Axi 的博客指导进行部署，主要记录 Posts 和 Paper Readings 两大类内容，并拥有 Tags 和 Achives 页面，方便读者浏览和查找感兴趣的内容。

20Bytes Log

低空具身智能：从空中 VLN 到空中 VLA

区分空中 VLN 与 VLA

判别标准

概念对比

VLA 是否涵盖 VLN？

Action 的边界争议

代表性论文分类

一句话判断法

空中具身的发展路线

入局建议

基建方面

Base Model

Dataset

Benchmark

Framework

VLA

VLN（视觉语言导航）

1. 什么是空中视觉语言导航？

2. 空中视觉语言导航的独特挑战：

三维路径规划与六自由度控制

从空中视角进行语义理解

连接仿真与真实世界的无人机部署

用 GitHub Actions 把关注圈动态整理成每日邮件摘要

1. 问题拆解

2. 技术选型

3. 核心思路：用对 API 端点

4. 整体架构

5. 聚合层的关键设计

5.1 机器人过滤

5.2 大厂项目识别

5.3 个人亮点提取

6. 邮件结构

7. GitHub Actions 配置

8. 本地测试

9. 几个踩过的坑

10. 可扩展的方向

11. 总结

GitHub PR 流程指南：从 Fork 到 Merge 的标准七步法

1. 标准 PR 七步法

2. 开始前先理解：PR 到底是什么

3. 第一步：Fork 仓库

4. 第二步：Clone 到本地

5. 第三步：创建分支

6. 第四步：编码并提交 Commit

7. 第五步：Push 到自己的远程仓库

8. 第六步：Open PR

9. 第七步：Review 与二次修改

10. 新人最常见的三个坑

10.1 直接在 main 上改代码

10.2 PR 太大

10.3 只写标题，不写描述

11. 一套适合直接照抄的完整命令

12. 总结

13. 参考资料

构建个人学术追踪系统：自动化 arXiv 论文监控实践

项目动机

系统架构概览

核心实现细节

1. 精准的关键词检索策略

2. 智能双语展示

3. HJFY集成：便捷的PDF访问

4. Web端个性化标记

5. 摘要独立页面

自动化运维

GitHub Actions 定时任务

增量更新机制

技术亮点与优化

1. 优雅的错误处理

2. Markdown到HTML的灵活转换

3. 数学公式排版优化

实际效果

扩展思路

总结

致谢

参考资源

Git 实用指南：从重置仓库到代码贡献标准工作流

1. 从本地代码重建全新的 GitHub 仓库

核心步骤

2. 代码贡献与团队协作标准工作流 (Workflow)

10.1 直接在 `main` 上改代码