HUHU BLOG

解析 Langchain deepagents 的 Skills 实现

Sun, 30 Nov 2025 00:00:00 GMT

传统的 Agent 设计思路：把 Agent 可能需要的所有知识、工具说明、工作流程都写进 system prompt——在启动时一次性加载全部上下文。这种”静态预加载”模式忽视了一个关键事实：上下文窗口是一种具有递减收益边际的有限资源。

这种方式存在三个根本性问题：

Token 膨胀与成本失控。一个功能丰富的 Agent 可能有几十甚至上百个 tool，每个 tool 的详细说明可能有几百 token。以 Manus 的实践数据为例，Agent 的平均输入与输出 token 比例约为 100:1，这意味着预填充阶段的成本占据绝对主导。更关键的是，工具定义在序列化后通常位于上下文的前部，任何变更都会使后续所有动作和观察的 KV 缓存失效——未缓存的 token 成本可能是缓存 token 的 10 倍。

上下文腐烂（Context Rot）。Chroma 团队的研究表明，模型性能下降受三个因素驱动：上下文长度增加导致注意力稀释、问题与关键信息的语义相似度降低、以及关键信息与周围干扰内容的语义相似度过高。这三个因素会相互放大。当 system prompt 过长时，精心设计的核心指令会被淹没在工具描述中，模型越来越难以准确匹配到真正相关的指令——即使技术上支持 128K 甚至 1M 的上下文窗口，最大上下文窗口 ≠ 最佳注意力窗口。

动态性与可维护性缺失。静态加载意味着想修改某个 tool 就得重新部署整个 Agent。

deepagents-cli 的解法来自一个简单的洞察：Agent 不需要一开始就知道所有事情，它只需要知道”有哪些事情可以知道”。

渐进式披露：Anthropic 的 Agent Skills 模式

这个设计模式来自 Anthropic 的工程实践（其实最早是 Manus 提出来的🤗），称之为 Progressive Disclosure。核心思想是：

启动时：只告诉 Agent “有一些 skills 可用”（名称 + 一句话描述）

运行时：当任务匹配某个 skill 时，Agent 主动读取完整说明

执行时：按照说明完成任务

这就像一个专业人士的工作方式：他知道自己有哪些参考手册，但只在需要时才翻开具体章节。

Claude Code 是闭源的，但最近 Langchain 推出了 deepagents-cli ，同时也更新了 Claude Code 的 skills 机制。So, 感谢开源，能够学习内部的逻辑实现，接下来让我引用代码来展示这个机制是如何实现的。

实现解剖：从目录结构到运行时

Skill 的物理结构

每个 skill 是一个独立的目录，必须包含一个 SKILL.md 文件：

SKILL.md 的格式很关键。它用 YAML frontmatter 提供元数据，正文是详细的使用说明：

这个设计的精妙之处在于：frontmatter 和正文都是给 Agent 读的，但在不同阶段按需加载。启动时 Agent 只读取 frontmatter（摘要层）来构建全局索引，知道”有哪些 skill 可用”；运行时当 Agent 判断某个 skill 相关时，才按需读取正文（核心层）来获取完整的使用说明。这正是渐进式披露（Progressive Disclosure）的核心——用元信息替代完整信息，按需加载而非预加载。

数据结构：SkillMetadata

这四个字段足够让 Agent 做出”是否需要这个 skill”的判断，同时 path 字段让 Agent 知道去哪里获取详细信息。

加载逻辑：安全优先

具体的加载逻辑有几个值得注意的设计：

路径安全校验。在读取任何文件之前，先验证路径是否在合法目录内：

这防止了目录遍历攻击。比如一个恶意的 skill 目录包含指向 ../../.ssh/id_rsa 的符号链接——这段代码会拒绝它。

文件大小限制。防止 DoS 攻击：

两级覆盖机制。支持用户级和项目级 skills，项目级可以覆盖同名的用户级 skill：

这个设计让团队可以在项目中定制 skill，而不影响个人的全局配置。

Middleware：Agent 生命周期的钩子系统

要理解 skills 如何在运行时生效，需要先理解 middleware 机制。

什么是 Middleware？

Middleware 是一种在请求处理流程中插入自定义逻辑的模式。在 deepagents 中，middleware 可以：

在 Agent 执行前修改状态（before_agent）

在每次 LLM 调用时修改请求/响应（wrap_model_call）

在 Agent 执行后处理结果（after_agent）

这不是 deepagents 发明的概念——Web 框架（Express、Django）、消息队列、数据库驱动都有类似机制。它的核心价值是解耦：让不同的关注点（skills、memory、human-in-the-loop）可以独立实现和组合。

SkillsMiddleware 的实现

两个关键方法：

before_agent()：此钩子在 agent 开始执行之前运行。换句话说，它发生在代理的实际功能执行之前，用来对代理的初始状态进行准备。每一次 invoke 只会运行一次，也就是说，不管 Agent 后续的行为涉及到多少 model 或者 tool 调用，这个钩子只会在最初的那一刻触发一次，而不会在流程中重复运行。

wrap_model_call()：每次 LLM 调用时触发，注入 skills 信息到 system prompt

💡

before_agent

对单次 agent.invoke({...})：跑一次；

对同一个 thread 连续多次调 invoke：每次 invoke 又会再跑一遍 before_agent；

中途的 jump_to: "model"、jump_to: "tools" 不会让 before_agent 再次触发（它们只会重跑 before_model 等）。

最终注入的内容大致呈现为：

注意这里只有名称、描述和路径——完整的 SKILL.md 内容并没有被加载。

Middleware 的组装

在创建 Agent 时，SkillsMiddleware 和其他 middleware 一起被注册：

运行时：Skills 在 Agent 生命周期中的完整运行机制

前面阐述了 middleware 的执行顺序和 wrap_model_call 的工作原理，现在来完整地追踪一个 skill 从”被发现”到”被使用”的全过程。理解这个过程很重要，因为它揭示了渐进式披露模式的精髓：Agent 不是一开始就知道如何使用 skill，而是在运行时逐步”学习”的。

Agent 生命周期概览

在深入细节之前，先看一下 Agent 处理一次用户请求的完整生命周期：

注意 Phase 2 中的”Agent 循环”——这是 Agent 的核心工作模式。Agent 不是一次性完成任务的，而是通过多轮 LLM 调用和工具调用来逐步推进。每一轮 LLM 调用都会触发 wrap_model_call，这意味着 skills 列表会被反复注入到 system prompt 中。

模拟示例：搜索 deep learning 论文

让我们用一个具体的例子来追踪整个过程。用户输入：“帮我搜索一下 deep learning 相关的论文”

Phase 1: 初始化阶段

当用户按下回车的那一刻，Agent 开始处理这个请求。首先，所有 middleware 的 before_agent() 方法会按顺序执行。对于 SkillsMiddleware 来说，这是它”发现” skills 的时刻：

这个方法做了什么？它调用 list_skills() 函数，扫描用户级和项目级的 skills 目录。对于每个找到的 skill 目录，它会：

检查目录下是否存在 SKILL.md 文件

读取 SKILL.md 的前几行，解析 YAML frontmatter

提取 name 和 description 字段

假设用户的 skills 目录下有 arxiv-search、web-research、langgraph-docs 三个 skill，扫描完成后，state 中会存储这样的数据：

Note，此时 Agent 只知道这些 skill 的名称和一句话描述，完整的 SKILL.md 内容还没有被读取。这就是”渐进式披露”的第一步：让 Agent 知道有哪些能力可用，但不告诉它具体怎么用。

Phase 2: Agent 循环

初始化完成后，Agent 进入核心的工作循环。这个循环会持续进行，直到 Agent 认为任务已经完成。

第一轮 LLM 调用：分析请求，决定使用 skill

在调用 LLM 之前，wrap_model_call() 会被触发。SkillsMiddleware 在这里把 skills 列表注入到 system prompt：

注入后，LLM 看到的 system prompt 末尾会多出这样一段：

现在 LLM 收到了用户的请求”帮我搜索一下 deep learning 相关的论文”，同时它也看到了可用的 skills 列表。LLM 的推理过程大概是这样的：

用户想搜索论文… 让我看看有什么 skill 可以帮忙…
arxiv-search: “Search arXiv preprint repository for papers…” —— 这个看起来很匹配！
按照 Skills System 的指引，我应该先读取这个 skill 的完整说明。

于是 LLM 决定调用 read_file 工具：

Agent 执行 read_file 工具，读取 arxiv-search/SKILL.md 的完整内容。这个文件可能有几百行，包含：

这是渐进式披露的第二步：当 Agent 确定需要某个 skill 时，才读取完整的使用说明。

第二轮 LLM 调用：根据 SKILL.md 执行任务

现在 Agent 已经读取了完整的 SKILL.md，它知道了：

这个 skill 适用于什么场景

如何调用 Python 脚本

需要传递什么参数

有哪些示例可以参考

LLM 根据这些信息，决定调用 shell 工具执行搜索：

Agent 执行 shell 命令，运行 arxiv_search.py 脚本。这个脚本会：

连接 arXiv API

搜索包含 “deep learning” 的论文

返回前 5 篇论文的标题和摘要

脚本输出可能是这样的：

第三轮 LLM 调用：整理结果，回复用户

Agent 收到脚本的输出后，需要把这些原始数据整理成用户友好的回复。LLM 会分析搜索结果，提取关键信息，然后生成一个结构化的回复：

Phase 3: 返回阶段

任务完成后，所有 middleware 的 after_agent() 方法会依次执行。对于 SkillsMiddleware 来说，这个阶段通常不需要做什么特殊处理。但其他 middleware 可能会在这里做一些整理工作，比如保存日志、更新缓存等。

如果用户问的是其他问题？

假设用户问的是”LangGraph 怎么实现状态管理？“，整个流程会有所不同：

Phase 1 同样会扫描所有 skills，得到相同的 skills_metadata

第一轮 LLM 调用时，LLM 会发现 langgraph-docs skill 更匹配这个问题

Agent 会读取 langgraph-docs/SKILL.md 而不是 arxiv-search/SKILL.md

后续的执行会按照 langgraph-docs skill 的指引进行

如果用户问的是”1+1等于几？“，LLM 可能会判断没有任何 skill 适用于这个简单问题，直接回答而不读取任何 SKILL.md。

这就是渐进式披露的威力：Agent 只在需要时才获取知识，不需要时完全不加载。

为什么这个设计有效？

回顾整个过程，我们可以看到几个关键的设计决策：

1. 元数据与详情分离

在 Phase 1，Agent 只加载了 skill 的名称和描述。完整的 SKILL.md 只在真正需要时才被读取。如果用户问的是”今天天气怎么样”，arxiv-search 的 SKILL.md 根本不会被加载。

2. LLM 自主决策

Agent 不是被动地执行预设的规则，而是由 LLM 自主判断是否需要使用 skill。这种设计让 Agent 能够灵活应对各种请求，而不需要为每种情况编写硬编码的逻辑。

3. 自然语言作为接口

SKILL.md 是用自然语言写的，LLM 可以直接理解并执行。这比传统的 API 文档或配置文件更灵活——Agent 可以根据具体情况调整执行方式，甚至在遇到问题时自主尝试其他方法。

4. 多轮对话的必要性

整个过程涉及多轮 LLM 调用：第一轮决定使用哪个 skill，第二轮根据 skill 说明执行任务，第三轮整理结果。这种多轮模式是 Agent 能够处理复杂任务的关键。

这个模式的普适性

Skills 机制的核心洞察 —— 延迟加载 + 按需获取——其实是一个通用的系统设计原则。

在操作系统中，这叫虚拟内存：程序不需要一开始就把所有代码加载到内存，用到哪页加载哪页。

在 Web 开发中，这叫懒加载：页面不需要一开始就加载所有资源，滚动到哪里加载哪里。

在知识管理中，这叫渐进式学习：你不需要先学完所有知识才能开始工作，遇到问题时再深入学习。

deepagents-cli 把这个原则应用到了 AI Agent 的能力管理上。随着 Agent 能力越来越丰富，这种”知道自己不知道什么，但知道去哪里找”的设计会越来越重要。

Have a try~

如果你想体验这个机制，可以：

安装 deepagents-cli：pip install deepagents-cli

创建一个简单的 skill：

写一个 SKILL.md：

运行 deepagents，然后问一个匹配你 skill 描述的问题

观察 Agent 是如何发现并使用你的 skill 的。

Skills 机制展示了一个重要的设计理念：好的抽象不是隐藏复杂性，而是让复杂性在正确的时机出现。Agent 不需要一开始就知道所有事情，它只需要知道如何在需要时获取知识，这可能是构建真正可扩展的 AI Agent 系统的关键。

参考

Anthropic Engineering Blog - Equipping Agents for the Real World with Agent Skills

Manus Blog - Context Engineering for AI Agents: Lessons from Building Manus

LangChain - deepagents-cli: Open Source AI Agent Framework

Chroma Research - Evaluating Chunking Strategies for Retrieval

AutoDL 部署 Qwen3-32B Lora Model 踩坑记录

Mon, 08 Sep 2025 00:00:00 GMT

最近在做组里的项目，为了满足甲方的要求，在组内服务器上对 Qwen-32B 模型进行了 Lora 微调。之后甲方要求测试模型服务，但是不提供服务器进行部署 😅，没办法，只能租服务器部署提供远程访问。在租赁的服务器上部署模型之前，我在本地事先跑通了完整的部署和测试流程，整个过程比较简单，按照 ms-swift 文档 deploy 就行（前期使用 ms-swift 进行 sft 的）。

出于 AutoDL GPU 服务器的性价比高，在通过 vram-calculator 计算部署和推理需要的大致显存后，租赁了 vGPU 32GB x 4 的实例。原本以为很快就能交付部署，谁能想一个坑接着一个坑的排，最终 AI 在我的辅助下也是和我一起解决了所有问题。推理成功的那一刻再一次体会到了一点点解决编程 bug 的激动 😭

镜像环境不匹配

🚨

这是最坑的，官网没有任何提示 vGPU 不能用最新的镜像，最后还是给客服提 bug 时，客服才说 vGPU 用不了最新的镜像 🤡。我就请问了，不能用别在镜像列表里显示啊，显示也该提示允许的 GPU 型号吧，真服咧。（9.7 写这篇博客时已经支持了）

1. 镜像环境选择

本着“用新不用旧”的原则，我最开始直接选择了平台提供的基于 CUDA 12.8 的官方镜像，使用了当时较新的 PyTorch 版本。

2. 多卡通信测试失败

其实在实际进行多卡测试之前，我是先走一遍正常的部署流程的：

pip install 相关依赖，然后执行推理，出现了vLLM 多进程 Worker 初始化失败错误，大致日志如下（复现 bug 时，无法选择此镜像了）：

与 AI 进行多次讨论、排查之后，依然未解决问题。只能尝试选择联系客服，客服给我一个脚本，来测试多卡之间通信是否正常。

脚本主要的流程是：在多卡环境下，对一个大张量进行 all_reduce 操作（这里是连续进行 10 次 all_reduce 操作），并统计其平均带宽和耗时。内容如下：

使用主机自带的 Base 环境（先埋个坑）执行 torchrun 命令后，程序立即崩溃。错误日志如下:

进程因 exitcode: -11 而失败，并收到 Signal 11 (SIGSEGV)，这是一个典型的段错误，意味着程序访问了无效的内存地址。这通常不是 Python 代码逻辑错误，而是底层 C++/CUDA 代码层面出现了问题。

3. 问题排查：分析 NCCL 通信失败原因

3.1 最小化张量测试

创建一个试脚本，使用极小的张量：

结果：即使是 2KB 的小张量也会触发段错误。

3.2 仅初始化进程组

结果：成功运行！说明进程组初始化没问题，问题出在 all_reduce 操作。

3.3 启用 NCCL 调试信息

添加 NCCL 调试环境变量：

然后在日志中可以看到比较关键的警告信息：

发现：NCCL 无法正确调用某些 CUDA 函数，表明库之间的兼容性出现了问题。

3.4 切换到 Gloo 后端验证

使用 gloo 后端替代 nccl：

结果：成功运行！这证实了问题确实是 NCCL 触发的，并且是兼容性问题。

💡

Gloo 是一个由 Facebook 开发的，用于分布式训练的通信库后端。

核心功能：Gloo 基于 TCP/IP 协议，提供了一套高效的集体通信操作，用于在不同计算节点之间同步数据和模型参数。

GPU 分布式训练：虽然 Gloo 也支持 GPU，但性能通常不如专为 NVIDIA GPU 深度优化的 NCCL 后端。

4. 问题根因

NCCL 2.27.3 无法正确调用 CUDA 12.8 的某些函数

错误信息：CUDA some PFN functions not found in the library

这表明 NCCL 库与当前 CUDA 版本存在不兼容

容器环境可能进一步导致了兼容性问题

AutoDL 容器环境中的 CUDA 配置可能与 NCCL 预期的环境有差异，某些底层 CUDA 函数的链接或加载可能受到影响

段错误发生在 NCCL 通信操作时

初始化进程组成功，但 all_reduce 操作触发崩溃，与数据大小无关，这表明是 NCCL 库在调用底层 CUDA 函数时出错

5. 吐槽

最后给官方客服提交 bug 时，客服说这个镜像是专门为 5090 准备的，vGPU 不适配，然后告诉我说明在如下图中：

谁能知道这里面有镜像说明哈？不应该在选择镜像的时候进行提醒和说明吗？而且打开文档发现，也并没有提醒用户适配性的问题，只是说 5090、RTX PRO 6000 请使用此镜像，没有表明其他显卡不能用…… 糟糕的文档 🤡

9.7 日，写这篇博客时，再次复现 Bug 时，发现官网已经添加了镜像选择的提示，这算前人栽树后人乘凉嘛 🥹：

控制变量，循序渐进

选择了一个 CUDA 12.4 的镜像，具体环境配置如下：

PyTorch 2.5.1

Python 3.12

CUDA 12.4

① : 创建虚拟环境 & 安装 ms-swift

然后测试多卡通信，发现测试也是直接失败 😭，还是同样的错误，更懵逼：

再次询问客服，客服问我是否更换了 torch 的版本，让我尝试在实例自带的 Base 环境进行测试。在主机自带的 Base 环境下，运行通信测试脚本，GPU 通信成功！！输出如下：

Amazing，竟然有 torch 的问题。观察pip list 发现，ms-swift 安装的 pytorch 和实例镜像自带的 Base 环境中的 Pytorch 确实不一致。

2.5.1+cu124：打包时已内置 CUDA 12.4 的 GPU 轮子（同时内置 NCCL），安装后不用本机 CUDA Toolkit 。

2.8.0：可能是 CPU 版或通过 PyTorch 官网上的安装选择器拿到的某个 GPU 版，具体以安装的 wheel 为准。

查看 torch==2.8.0 具体的版本信息：

在这里问题就比较明确了，通过 ms-swift 安装的 torch 针对的是 CUDA 12.8，但是实例的 GPU 只能支持所有低于或等于 12.4 版本的 CUDA Toolkit 编译的程序：

但事实好像并不是这样 😵‍💫。从官网查询得知，从 11.0 版本开始，NVIDIA 引入了 CUDA 的 Minor Version Compatibility 。这意味着，在同一主版本号内（12.x），一个较新版本的 CUDA Toolkit (如 12.8) 编译的程序，可以运行在一个支持较低版本 CUDA (如 12.4) 但支持 12.x 的驱动程序上。官网还有几个相似的概念，可能会有些困惑：

兼容性类型	驱动版本	CUDA 工具包版本	描述
向后兼容性 (Backward Compatibility)	新	旧	(默认支持) 新驱动可以运行旧版 CUDA 工具包编译的应用。这是最常见的情况。
次要版本兼容性 (Minor-Version Compatibility)	旧	新 (主版本号相同)	在同一主版本号内（如驱动为 525.x，工具包为 12.y），旧驱动可运行新工具包的应用。
前向兼容性 (Forward Compatibility)	旧	新 (主版本号可不同)	(需兼容包) 跨越主版本号，旧驱动可运行新工具包编译的应用（例如驱动为 525.x，工具包为 13.x）。

所以，具体分析现有组件，可以得出：

组件	版本	解释
NVIDIA Driver	`550.120`	由于版本够新，它通过Minor-Version Compatibility 支持了更新的 CUDA 12.8。
`nvidia-smi` CUDA	`12.4`	驱动程序原生支持的 CUDA 版本。在有兼容性的情况下，它不再是一个严格的上限，而更像一个参考基线。
PyTorch CUDA	`12.8`	编译 PyTorch 时使用的工具包版本。
`torch.cuda.is_available()`	`True`	最终的验证结果。这个 `True` 值确认了整个环境（驱动 + PyTorch）配置正确且可以协同工作。如果存在不兼容问题，这个命令会返回 `False` 或者程序会直接报错。

既然官方支持了“次要版本兼容性”，驱动也满足 12.x，那为什么会导致程序崩溃呢？为了进一步测试兼容性的问题，我新创建了一个实例，镜像一致，但是驱动更新，而且支持的最高 CUDA Version 为 13.0：

在这个环境上按照同样的流程测试，通信测试成功：

🤔

综合以上文档、实验和分析，只能得出报错的可能原因是：CUDA 版本不匹配导致 NCCL 在通信阶段崩溃（SIGSEGV）。

完整梳理：

swift 安装的 PyTorch 是 2.8.0+cu128，也就是 CUDA 12.8 构建：

print(torch.__version__, torch.version.cuda) → 2.8.0+cu128 12.8

宿主机驱动只支持到 CUDA 12.4：

nvidia-smi → CUDA Version: 12.4 (Driver 550.120)

低于运行时所需的驱动版本时，CUDA/NCCL 常在初始化或集合通信（如 all_reduce）里直接段错误（-11）而不是抛 Python 异常；日志里也显示首个失败进程为 local_rank: 3 收到 SIGSEGV。

结论：用 CUDA 12.8 编译的 PyTorch/NCCL 在仅支持 12.4 的驱动上运行，触发本地库崩溃。

② : 创建虚拟环境 & 安装指定的 torch

这里为了防止其他意外发生，指定了和 Base 环境同样的 torch 版本 2.5.1 进行测试。

正常运行：

在虚拟环境中安装和 Base 环境一样的 Pytorch 也能够测试成功，说明确实是安装的 PyTorch 二进制的问题。

③: ② & 安装 swift

在 ② 操作的基础上，再安装 swift，测试后再次发生了和 ① 一样的错误，查看依赖安装日志，发现 pip 在安装 ms-swift 时，自动卸载了 torch==2.5.1+cu124。此时再运行多卡通信测试，使用的就是 torch==2.7.1 ，所以 SIGSEGV 段错误再次出现。

④: ① & 删除 swift 自带的 torch & 安装指定的 torch

既然 swift 会删除原来的 torch，也并没有提供使用现有的 torch 选项，那就尝试在安装 swift 之后，卸载自带的 torch，再安装 torch==2.5.1+cu124 。此时需要注意的点是，替换 torch 后需要测试 swift 是否能够正常运行，防止 swift 强绑定了特定的 torch 版本。

正常运行：

⑤: ④ & 使用已有的 torch 从头编译 vllm

和直接安装 ms-swift 同理，安装 vllm 也会覆盖原有安装的 Pytorch，但是如果安装 vllm 后，再进行替换，会导致 Vllm 不可用，因为 vllm 为了保证其内部 CUDA 扩展的兼容性，通常会严格绑定一个特定的 PyTorch 版本。替换自定义的 Pytorch也会导致不兼容，使 vllm 无法使用。所以这里根据官方文档使用已有的 torch 从头编译 vllm：

https://docs.vllm.ai/en/v0.8.0/getting_started/installation/gpu.html#build-wheel-from-source

刚开始也是没动脑子，直接 clone 最新的代码库就编译了，编译报错：

日志说明现在编译的 vLLM 代码启用了 FP8 相关内核，并引用了 PyTorch C++ 里较新的 dtype（at::Float8_e8m0fnu）。而当前环境里的 PyTorch=2.5.1 的头文件里还没有这个类型（CMake 也警告 “Pytorch version 2.7.1 expected…”）。换句话说：vLLM 当前源码分支比当前环境中的 PyTorch 版本新，所以编译时找不到该符号，导致失败。然后我也再次没动脑子的采用了 ChatGPT 的建议：

社区里在 torch 2.5.1 + CUDA 12.4 下成功安装 vLLM 0.7.3 的案例很多。

编译时，由于没有设置 MAX_JOBS ，导致编译过程中并发数太大，直接导致内存爆炸（OOM Killed）：

现象: 在编译过程中，特别是编译 FlashAttention 等复杂的 CUDA 内核时，进程突然终止，日志中出现 Killed 字样或 exitcode: 137。

分析: 这是典型的内存不足（Out of Memory）信号。nvcc 编译器在进行模板实例化时会消耗大量内存，如果 pip 的并行编译任务数（MAX_JOBS）过高，很容易超出实例的物理内存上限。

解决: 限制并行编译任务数。

一杯咖啡时间后，编译成功：

测试通信，多卡通信正常，yeah ^_^

运行时问题诊断与分析

环境就绪后，开始进行完整的模型部署，但新的问题也随之而来。

1. 因 vLLM 版本不匹配导致的显存溢出 (OOM)

这个问题的根本原因在于编译的 Vllm 版本太低，还未对 Qwen3 Model 进行适配 🥲。也是自己疏忽，直接选择了 ChatGPT 提供的版本，ChatGPT 是根据 CUDA Version 进行选择的，但是没有考虑到模型的问题。

现象: 服务启动时，显存被迅速占满，并抛出 torch.OutOfMemoryError。但根据先前的计算，显存是足够用于推理的，在加载阶段报错，应该是其他问题。

Qwen3ForCausalLM has no vLLM implementation, falling back to Transformers implementation

根本原因: 从日志中可以看到，该 vLLM 版本不原生支持 Qwen3 模型，因此自动回退到 HuggingFace Transformers 库的后端实现。

2. 多卡环境下 LoRA 加载超时

查看官方的 Release 信息，可以得知 Vllm 是在 V0.8.4 开始支持 Qwen3 的，考虑到 V0.8.5 还修复了一些 bug，所以我选择升级 vLLM==0.8.5 并重新编译：

又一次尝试运行部署脚本之后，终于部署成功了！！！

但尝试请求服务进行推理时，新的问题出现了 🤡。大概就是 vllm 多进程推理时等待 worker 响应超时，出现超时错误：

日志如下，稍微长

Cloudfare 缓存引发的 CORS 问题

Thu, 26 Jun 2025 00:00:00 GMT

起因是刷到一个在线摄影集项目 Afilmory ，被其美观干净的 UI 所吸引，所以也想部署一个自己的摄影集网站，虽然买相机至今还没拍摄多少照片……

本着能白嫖就白嫖的原则，使用 Cloudfare R2 作为照片存储桶，Vercel 来部署静态网站。部署项目采用的是本地图片预处理 + 远程静态资源使用的方式，因为项目在构建时需要处理大量图片，这是一个非常消耗计算资源（CPU 和内存）的过程。Vercel 的免费套餐构建环境有时间和内存限制，如果照片数量很多，构建过程很可能会失败。下面就着重讲述一下使用 Cloudfare R2 存储照片、使用并出现问题的过程。

Cloudfare R2 搭建图床

Cloudflare R2 是一款对象存储服务，旨在让开发者能够存储大量非结构化数据，其最核心的特点是免除了其他云存储服务商通常会收取的高昂的出口费用。

R2 提供了一个非常可观的免费套餐，尤其适合个人开发者和小型项目：

每月 10 GB 的免费存储空间。

每月 100 万次免费的写入操作。

每月 1000 万次免费的读取操作。

具体的图床搭建步骤可以参考这篇文章：从零开始搭建你的免费图床系统（Cloudflare R2 + WebP Cloud + PicGo）。之后，对于每张上传的图片，便可以得到可以公共访问的 URL：

📢

建议绑定一个自定义域名，因为 cloudfare 提供的域名有一定的限制：

This URL is rate-limited and not recommended for production. Cloudflare features like Access and Caching are unavailable. Connect a custom domain to the bucket to support production workloads.

绑定自定义域名需要将域名托管到 cloudfare 上，步骤也很简单，按照提供的信息更换原来域名的域名服务器为 Cloudflare 的域名服务器。同时迁移成功后，所有和域名解析相关的操作都必须在 Cloudflare 的 DNS 控制台进行，原来域名提供商的 DNS 解析设置将不再生效。

CORS 策略

CORS 的全称是 “跨域资源共享” (Cross-Origin Resource Sharing)。它是一种基于 HTTP 头的机制，允许服务器声明，除了它自己的源（域、协议或端口）之外，还有哪些源可以有权限访问它加载的资源。

为什么需要 CORS？源于“同源策略”

要理解 CORS，首先必须理解浏览器的 “同源策略” (Same-Origin Policy)。同源策略是浏览器最核心、最基本的安全功能。它规定，一个源的文档或脚本，只能与和它 “同源” 的资源进行交互。

如果两个 URL 的协议 (protocol)、主机 (host) 和端口 (port) 都相同，那么它们就是同源的。

URL	与 `http://example.com/index.html` 的比较	结果
`http://example.com/page.html`	同源	允许
`https://example.com/index.html`	不同协议 (https vs http)	跨域
`http://www.example.com/index.html`	不同主机 (www.example.com vs example.com)	跨域
`http://example.com:8080/index.html`	不同端口 (8080 vs 80)	跨域

同源策略极大地提高了浏览器的安全性，可以有效防止恶意网站通过脚本轻易地窃取你在其他网站上的数据。但是，跨域请求（比如从 site-a.com 的前端页面请求 api.b.com 的数据）在某些情况下是合理且常见的需求。为了在不完全破坏同源策略安全性的前提下，有控制地允许这些跨域请求，CORS 应运而生。

CORS 是如何工作的？

CORS 的核心思想是：使用新增的 HTTP 头部，让服务器告诉浏览器，它是否允许当前这个源的请求。 整个过程由浏览器自动完成，对前端开发者来说通常是无感的。

浏览器在请求头中自动加入 Origin 字段，表明请求来自哪个源。

服务器收到请求后，检查 Origin 字段。如果这个源在许可范围内，服务器就会在响应头中加入 Access-Control-Allow-Origin 字段。

浏览器接收到响应后，检查 Access-Control-Allow-Origin 字段。如果该字段的值是请求的源，则请求成功，浏览器将响应内容交给 JavaScript。否则，浏览器会拦截响应，并在控制台抛出 CORS 错误。

📢

CORS 完全由服务器端控制， 解决 CORS 问题的关键在于正确配置服务器的响应头。

Cloudfare R2 设置 CORS

构建好站点之后，如果在没有配置 Cloudfare R2 的 CORS 策略情况下，直接打开图片，会得到对应的报错：

打开 Cloudfare R2 并进入创建的存储图，比如我的是 huhu-photo，在 Settings 菜单栏下就有 CORS 配置界面，可以设置对应的 CORS 策略：

我设置的策略如下，并没有限制特定的域名请求：

"AllowedOrigins"：告诉 R2 允许哪些源（域名）来访问资源，这里是允许公开请求。

"AllowedMethods": 允许的 HTTP 请求方法，对于图片对象来说，GET 、HEAD 和 OPTIONS 一般就足够了。

⚠️

问题来了，即使我设置了 CORS 策略，使用了无痕浏览（排除缓存的问题），但是在查看某些图片时依然遭到了拒绝，显示同样的 CORS 错误，而且这些出错的图片不是固定的，同时这是为什么呢？

询问 AI 之后，尝试使用 curl 验证一下请求返回的 header 部分，来确定 CORS 策略是否正确生效：

可以看到响应部分确实有 access-control-allow-origin 字段，排除了 CORS 策略的问题。查不到具体的问题，只能去提交个 issue 了，果然 issue 是最好的学习地方，有个佬遇到了同样的问题，并给出了具体的原因，以及完整的复现流程 🤩，具体内容在这里。

cloudfare 缓存导致的请求错误

💡

源服务器 R2 只在收到带有 Origin 请求头的请求时，才会在响应里加上 CORS 相关的头部（比如 Access-Control-Allow-Origin）。

接下来具体阐述一下佬友给出的问题原因和解决方案：

第一次请求（缓存建立）：当浏览器第一次请求一张图片时，这个请求可能没有带上 Origin 头（表明这是一个跨域请求）。Cloudflare 的边缘节点收到请求后，发现自己的缓存里没有这张图，于是就去 R2 仓库里把图取了过来。因为这次请求没有跨域信息，所以 R2 返回的图片不包含 CORS 响应头（比如 Access-Control-Allow-Origin）。Cloudflare 拿到这张不带 CORS 头的图片后，于是就把这张图缓存到了自己的服务器上。

第二次请求（触发跨域）：当网站（gallery.mwwlzz.top）再次请求这张图片时，这次请求是一个明确的跨域请求，浏览器会带上 Origin 头。请求发到 Cloudflare。

问题发生：Cloudflare 在自己的边缘节点上看到了这个请求，发现这张图有缓存。于是，直接把上次缓存的那张不带 CORS 头的图片返回给了浏览器。

浏览器报错：浏览器收到了图片，但发现响应里没有 CORS 响应头，于是出于安全考虑，就拒绝加载图片，并在控制台报出 CORS 错误。

📢

源服务器 R2 只在收到带有 Origin 请求头的请求时，才会在响应里加上 CORS 相关的头部（比如 Access-Control-Allow-Origin）。

这就是为什么问题会随机出现：能否加载成功，取决于请求的那张图片在 Cloudflare 的缓存里是带 CORS 头的版本还是不带 CORS 头的版本。刷新页面可能会清除或替换缓存，导致加载情况发生变化。

错误的 Cloudflare 缓存如何产生的呢？

❓

既然浏览器会自动加上 Origin 头，那为什么会没有触发 CORS 呢？哪种情况可能没有带上 Origin 头呢？

场景一：触发了 CORS 的“标准跨域请求”

浏览器：

网站里的 JavaScript 代码要请求一张图片，图片的域名是 hu-r2.mwwlzz.top。

浏览器发现这两个域名不一样，这是一个跨域请求。

于是，浏览器在发给 Cloudflare 的请求里，自动加上了一个 Origin 请求头，告诉服务器这个请求来自哪里。

请求头里包含：Origin: https://gallery.mwwlzz.top

Cloudflare：

收到这个带 Origin 头的请求。

假设此时缓存里没有这张图，它就把这个完整的请求转发给源服务器 R2。

R2 服务器：

收到请求，看到了 Origin 请求头。

检查策略，发现 https://gallery.mwwlzz.top 是被允许的。

于是，它在返回图片数据的同时，在响应头里加上了 Access-Control-Allow-Origin: https://gallery.mwwlzz.top。

结果：这份带有 CORS 头部的完整响应被送回 Cloudflare，Cloudflare 可能会缓存它，然后再发给浏览器。浏览器收到后，检查头部发现来源匹配，于是正常显示图片。

场景二：没有触发 CORS 的“直接请求”（问题的根源）

这种情况可能在多种情况下发生，最典型的一个例子就是：

⚠️

直接在浏览器地址栏里输入了图片地址 https://hu-r2.mwwlzz.top/image.jpg 并查看图片。（我好像确实干了）

浏览器直接访问：

用户请求的地址和资源地址的域名是同一个 (hu-r2.mwwlzz.top)。

浏览器认为“这不是跨域请求”。

因此，浏览器发送的请求里完全不包含 Origin 这个请求头。

Cloudflare：

收到这个不带 Origin 头的请求。

假设缓存是空的，它把这个请求转发给 R2。

R2 服务器：

收到请求，检查请求头。

没有找到 Origin 请求头。

R2 认为这不是跨域请求，没必要加任何 CORS 相关的头部。

于是，它只返回了图片数据和一些基本头部，响应里完全没有 Access-Control-Allow-Origin。

关键时刻：缓存建立：

Cloudflare 收到了这份不带 CORS 头部的响应。

对于 Cloudflare 来说，这是一份完全有效的响应，它的任务就是提升之后的访问速度，所以它把这份不完整的响应缓存了下来。

现在，Cloudflare 的缓存里有了一份不带 CORS 头部的图片。之后，当通过网站再去请求这张已经被缓存的图片时：

网站发起了一个带 Origin 头的跨域请求。

请求到达 Cloudflare。

Cloudflare 在缓存里找到了这张图，直接把上次在场景二中缓存的那份不带 CORS 头部的响应返回给了浏览器。

浏览器收到了这份响应，发现它需要进行跨域检查，却找不到所需的 Access-Control-Allow-Origin 头部，于是立刻拒绝加载图片，并在控制台报错。

结论

Cloudflare 本身是无辜的，它只是一个高效的缓存系统，忠实地缓存从源服务器 R2 收到的东西。问题的根源在于，它缓存了由一个“非跨域请求”所产生的“不带 CORS 头的响应”，然后错误地将这份缓存提供给了一个需要 CORS 头的“跨域请求”。

设置 Cloudflare 不缓存 R2 资源

解决方案的核心就是告诉 Cloudflare：凡是访问 R2 图片域名的请求，都不要缓存，每次都去 R2 源服务器拿。 这样就能保证每次请求返回的都是 R2 直接给出的、带有正确 CORS 策略的响应。因此需要创建一个 “缓存规则 (Cache Rule)” ：

选择绑定的域名：这里是 mwwlzz.top

进入缓存规则页面：

在左侧的菜单栏中，找到并点击 “Caching”。

在下拉菜单中，选择 “Cache Rules” 。

创建新规则：

点击 “Create rule” 按钮。

配置规则：

Rule name: 给规则起一个名字，比如 Bypass Cache for R2。

When incoming requests match...: 这里是设置规则的触发条件。

在 Field 下拉框中，选择 “Hostname”。
在 Operator 下拉框中，选择 “equals” 。
在 Value 输入框中，填入 R2 绑定的自定义域名 hu-r2.mwwlzz.top

Then...: 这里是设置匹配成功后要执行的操作。

找到 Cache eligibility 这个选项。
选择 “Bypass cache”。

保存并部署

规则创建后会立即生效。现在所有访问 hu-r2.mwwlzz.top 的请求都会绕过 Cloudflare 的 CDN 缓存，直接由 R2 处理，按理说彻底解决了间歇性的 CORS 问题。但是，还是会出现之前的问题 🥲。

接着尝试清楚所有的缓存，同样是在 “Caching” 菜单栏下，找到 “Configuration”，然后点击 “Purge Everything”，即可清除所有的 cloudfare 缓存内容。但，还是不行。

Worker 脚本拦截并修改响应

由于上述方法都不行，最后尝试部署一个 worker，拦截所有发往 R2 域名的响应，然后强行给这些响应加上正确的 CORS 头部，最后再发给浏览器。这样一来，无论 R2 返回的响应是否带 CORS 头，也无论 Cloudflare 的缓存里是什么内容，Worker 都会确保最终浏览器收到的响应一定是带有正确 CORS 头的。

这段代码会做两件事：

如果收到 OPTIONS 预检请求，它会直接返回正确的 CORS 头部，告诉浏览器“安全，请继续”。

如果收到 GET 或 HEAD 等实际的图片请求，它会先从 R2（或缓存）获取图片，然后强行在响应中添加上正确的 CORS 头部再返回给浏览器。

设置路由来触发 Worker：

Worker 创建并部署好代码后，它还不知道要对哪些请求生效。我们需要告诉它。找到 Worker 的管理页面：

点击 “Triggers” 选项卡。

在 “Routes” 部分，点击 “Add route”。

在 Route 输入框中，填入 R2 域名，并使用通配符匹配所有路径：hu-r2.mwwlzz.top/*

Zone 选择主域名 mwwlzz.top。

点击 “Add route” 保存。

完成以上所有步骤后，这个 Worker 就会自动修改所有对 R2 资源的请求，强行保证 CORS 头部正确无误。至此，也确实彻底解决了之前的问题！

一点感想

想记录这次解决问题的过程，是因为感触良多。AI 能成为高效的“执行者”，却难成深刻的“洞察者”。当面对复杂未知的问题时，它的能力边界就显现出来。而人的智慧和经验与社区的公开，恰好能弥补这最后的“一公里”。一个有经验的开发者，能根据过往的经验找出问题的关键，这种需要实际工程的经验积累，是 AI 难以复制的。而社区打破了个人认知的孤岛，让分散的智慧得以汇聚和分享。

最后也是得到了好看的 gallery，欢迎浏览我这还较为青涩的摄影：https://gallery.mwwlzz.top/

使用 Tree-sitter 构建 PHP 代码控制流图 (CFG)

Wed, 19 Mar 2025 00:00:00 GMT

引言

在程序分析和编译器优化中，控制流图（Control Flow Graph, CFG） 是一种重要的数据结构。它用于表示程序的执行流程，帮助分析代码的可达性、优化代码执行路径，甚至用于静态分析工具来检测潜在的错误或漏洞。

在本文中，我们将通过具体的代码实现，探讨如何使用 Tree-Sitter 解析 PHP 代码的 抽象语法树（AST），并基于 AST 构建 控制流图（CFG）。

💡

什么是控制流图？

控制流图（CFG）是一种有向图，其中：

节点（Node） 代表程序中的基本块（Basic Block），具有单一的入口点和单一的出口点，在块内不会发生分支或跳转。

边（Edge） 代表控制流的转移方向。例如，从一个语句顺序执行到下一个语句，或者条件判断后根据条件结果转移到不同的分支。

一个简易版的控制流图如下：

在这个示例中， if (x > 0) 语句会导致程序执行路径的分叉，形成两个不同的执行流。

如何从 AST 构建 CFG？

在深入代码细节之前，我们首先需要理解如何从 AST 构建 CFG。AST 表示了代码的语法结构，但它更侧重于代码的层次结构和语法成分，而非执行流程。而 CFG 则专注于描述程序的控制流路径，即代码执行的顺序和分支。

💡

AST 是一种树状结构，节点间的关系主要是父子关系，难以直接体现代码的执行顺序和跳转关系。例如，if 语句在 AST 中只是一个节点，其条件和分支代码块是其子节点，但 AST 本身不直接表达 "如果条件成立，执行哪个分支，否则执行哪个分支" 的控制流信息。

CFG 使用图结构，节点代表基本代码块或语句，有向边代表控制流的转移。这种图结构能够清晰地表达代码的执行路径、分支、循环等控制流信息，更适合进行程序分析。

从 AST 构建 CFG 的基本步骤和原理

从 AST 构建 CFG 的过程，本质上是一个 AST 节点的遍历和转换过程。我们需要遍历 AST，识别出对控制流有影响的语句节点，并将它们转换为 CFG 中的节点，并根据语句的控制流语义添加 CFG 边。以下是构建过程中的一些关键步骤和原理：

AST 节点遍历： 通常采用深度优先遍历的方式遍历 AST。这样可以按照代码的逻辑顺序访问到各个语句节点。

识别控制流语句： 在遍历过程中，我们需要识别出 AST 中代表控制流语句的节点类型：

条件和分支语句:

if_statement - 条件分支

switch_statement - 多路分支

循环语句:

while_statement - while循环

do_statement - do-while循环

for_statement - for循环

foreach_statement - foreach循环

跳转语句:

goto_statement - 无条件跳转

continue_statement - 继续下一次循环

break_statement - 跳出循环

return_statement - 函数返回

异常处理:

try_statement - 异常捕获和处理

程序终止:

exit_statement - 程序退出

复合语句:

compound_statement - 包含多条语句的代码块，会影响控制流的嵌套结构

创建 CFG 节点： 对于每个识别出的控制流语句节点，我们需要在 CFG 中创建一个对应的CFG 节点。这个 CFG 节点通常会包含以下信息：

节点 ID： 用于唯一标识 CFG 节点。通常可以使用 AST 节点的 ID 或生成新的唯一 ID。

节点类型： 表示 CFG 节点对应的语句类型，例如 if_statement 等。

节点文本： 可选地包含节点对应的源代码文本。

其他属性： 例如是否是分支节点等，可以根据具体需求添加。

🌟添加 CFG 边🌟： 根据不同语句的控制流语义，在 CFG 节点之间添加有向边，表示控制流的转移方向。添加边的关键在于理解每种语句的执行逻辑：

🔥

总结：AST 到 CFG 的转换是一个语义理解和图构建的过程。我们需要理解不同 AST 节点代表的语句的控制流语义，并将其转换为 CFG 图的节点和边，最终得到能够清晰表达程序控制流的图结构。

代码概览：基于 Tree-sitter 的 PHP CFG 构建器

📢

本文的代码实现，参考了一个开源项目中基于 C 语言的 CFG 构建方法，也有些逻辑处理是个人的见解，所以可能会有逻辑错误的实现。

代码的实现主要包括两部分，AST 的构建、遍历，CFG 的构建。所以代码可以组织为两个模块：

ast_parser: 负责使用 Tree-sitter 解析 PHP 代码，并提供查询 AST 节点的功能。它能够识别 PHP 代码中的函数定义、各种语句类型，并提取节点的关键属性。

cfg_builder : 专注于 CFG 的构建，它递归遍历 AST，根据不同的语句类型生成 CFG 的节点和边。

构建 AST

在 Python 中实现 AST 的构建还是比较简单的，直接使用 tree_sitter_language_pack 库就行：

这样，我们就得到了输入 code 的完整 AST。在构建 CFG 时，实现的是基于 function 粒度的，所以我们还需要把输入代码中所有的 function 提取出来，可以定义一个辅助函数，用于从 AST 中提取指定类型的 node：

💡

为什么这样处理？ 函数是代码的基本模块。为每个函数构建独立的 CFG 是常见的做法，便于函数级别的分析和理解。函数体内的控制流逻辑与外部代码隔离，后续可以通过函数调用图(Call Graph, CG)连接函数 CFG 和调用点 CFG。

有了 query 函数，我们就可以传入 root_node 递归获取所有的 function node：

准备好这些基本输入之后，就可以着手构建 CFG 了。

构建 CFG

在整个构建 CFG 的过程中，我们需要维护每个代码块或语句的入口节点 (in_nodes) 和 出口节点 (out_nodes)。

入口节点 (in_nodes)：表示控制流进入当前代码块或语句的入口边集合。

出口节点 (out_nodes)：表示控制流从当前代码块或语句出去的出口边集合。

通过 in_nodes和 out_nodes的传递和连接，可以将各个语句的 CFG 片段组合成完整的函数或程序的 CFG。下面是需要使用的数据结构：

NodeInfo: dict[str, str | int | bool | list[tuple[int, int]]]

NodeInfo 类型用于存储 CFG 中每个节点的详细信息。它是一个字典，包含以下键值对：

"id": str - 节点的唯一标识符。通常基于 Tree-sitter AST 节点的 ID 生成，确保每个 CFG 节点都有唯一的身份，方便在图中引用和查找。

"type": str - 节点代表的 AST 节点类型。例如，"if_statement"、"function_definition"、"expression_statement" 等。这有助于理解 CFG 节点在代码中的语义角色。

"start": tuple[int, int] - 节点代码在源文件中的起始位置，表示为 (行号, 列号) 的元组。方便将 CFG 节点映射回源代码，进行代码定位和分析。

"end": tuple[int, int] - 节点代码在源文件中的结束位置，同样表示为 (行号, 列号) 的元组。与 "start" 配合使用，可以精确定位节点对应的代码范围。

"is_branch": bool - 标识节点是否为分支节点。例如，if 语句、while 循环等条件判断语句对应的节点会被标记为 True，表示控制流在此处会发生分支。

"text": str - 节点对应的源代码文本。存储了节点代表的代码片段的文本内容，使 CFG 节点更易于理解和调试。

示例： 一个 if_statement 节点的 NodeInfo 可能如下所示：

Nodes: list[tuple[NodeInfo, str]]

Nodes 类型用于表示 一组 CFG 节点及其相关的边标签。它是一个列表，列表中的每个元素都是一个元组。

tuple[NodeInfo, str] - 表示一个 CFG 节点以及与其关联的边标签。

第一个元素 NodeInfo: CFG 节点的 NodeInfo 对象，包含了节点的详细信息。
第二个元素 str: 边标签。在 create_cfg 函数中，Nodes 通常作为 in_nodes 参数传递，表示 控制流进入当前节点的入口来源。边标签用于区分不同的入口路径。

示例： create_cfg 函数的 in_nodes 参数可能是一个 Nodes 列表，如下所示：

Edges: list[tuple[str, str]]

Edges 类型用于表示 一组 CFG 边。它是一个列表，列表中的每个元素都是一个元组，代表一条边。

tuple[str, str] - 表示一条 CFG 边，元组包含两个字符串：

第一个 str: parent_id (父节点 ID) - 边的起始节点的 ID。表示控制流从哪个节点流出。
第二个 str: label (边标签) - 边的标签，用于区分不同类型的控制流转移。例如：

"" (空字符串): 表示顺序执行的边，没有特殊条件。
"True": 表示条件为真时执行的分支。例如，if 语句的 True 分支边。
"False": 表示条件为假时执行的分支。例如，if 语句的 False 分支边。
"Exception": 表示异常处理的边。例如，try 块到 catch 块的异常边。
"case " 或 "default": 用于 switch 语句的 case 分支边，标签为对应的 case 值或 "default"。

示例： 一个节点的 Edges 列表可能如下所示，表示该节点有两条入边：

CFG_GRAPH: list[tuple[NodeInfo, Edges]]

CFG_GRAPH 类型用于表示 完整的控制流图 (CFG)。它是一个列表，列表中的每个元素都是一个元组。

tuple[NodeInfo, Edges] - 表示 CFG 中的一个节点及其所有入边。

第一个元素 NodeInfo: CFG 节点的 NodeInfo 对象，包含了节点的详细信息。
第二个元素 Edges: Edges 对象，即该节点的所有入边列表。

示例： 一个 CFG_GRAPH 可能如下所示，表示一个包含三个节点的 CFG：

其中 node_info_A、node_info_B、node_info_C 分别是节点 A、B、C 的 NodeInfo 对象，"A_ID" 和 "B_ID" 分别是节点 A 和 B 的 ID。

💡

NodeInfo 封装了节点的属性信息，Edges 和 Nodes 用于表示边的集合，而 CFG_GRAPH 则将节点和边组织在一起，构成完整的 CFG 图的列表表示形式。

之后我们需要实现一个函数，它接收一个 Tree-sitter 节点 node 和一个 in_nodes 列表作为输入，输出构建的 CFG_GRAPH 以及当前节点处理后的 out_nodes。函数内部需要识别和处理不同的 statement，创建相应的 CFG 节点和相互连接边。所以，解析来开始最重要的部分~

函数定义 (`function_definition`)

创建函数节点：首先为函数定义创建一个 CFG 节点，并将其添加到 CFG 列表中。函数的入口节点没有入边，因此入边列表为空 []。

递归处理函数体：获取函数体的 body 节点，并递归调用处理函数体内的语句。函数体的入口边指向函数定义的节点。

返回结果：函数定义的 CFG 片段由函数节点和函数体 CFG 片段组成。函数定义本身没有出口节点，因此返回空的 out_nodes 列表 []。

复合语句块 (`compound_statement`)

顺序处理子语句：compound_statement 代表代码块( 被{ 和 } 包裹的)，例如函数体、循环体、if 语句块等。它包含一系列顺序执行的子语句。

迭代处理子节点：遍历 compound_statement 的子节点，跳过花括号 {}。

递归调用：对每个子节点递归调用 handle_node 处理。

关键：控制流传递 in_nodes 会在循环中被更新为上一个子语句的 out_nodes。这意味着前一个语句的出口节点会成为下一个语句的入口节点，保证了代码块内语句的顺序执行。

compound_statement 体现了代码的顺序执行流程。通过迭代处理子语句并传递 in_nodes 和 out_nodes，可以正确地将代码块内的语句连接成线性的控制流路径。

`if` 语句 (`if_statement`)

创建 if 条件节点：为 if 语句创建一个 CFG 节点，表示条件判断。其入边来自 in_nodes。

处理 if 主体 (True 分支)：递归调用 handle_node 处理 if 语句的 body (即 if 条件成立时执行的代码块)。body 的入口边指向 if 条件节点，并标记为 "True" 分支。

处理 else 或 else if 分支 (False 分支)：

如果存在 alternative (即 else 或 else if 语句)，则递归调用 handle_node 处理 alternative。alternative 的入口边也指向 if 条件节点，并标记为 "False" 分支。
如果只有 if 没有 else，则 if 条件不成立时的控制流直接跳过 if 主体，到达 if 语句之后的代码。

合并出口节点：if 语句的出口节点是 if 主体 (True 分支) 的出口节点和 else/else if 分支 (False 分支，如果存在) 的出口节点的并集。如果只有 if，则出口节点是 if 主体的出口节点和 if 条件节点本身的 "False" 分支出口 (代表条件不成立时直接跳过 if 块)。

💡

if 语句引入了条件分支，控制流根据条件表达式的结果选择不同的执行路径。通过为 if 条件创建节点，并为 True 和 False 分支分别递归处理，清晰地表示了这种分支结构。标记 "True" 和 "False" 边可以区分不同的控制流路径。

`else_if_clause` 和 `else_clause`

else_if_clause 和 else_clause 的 body 实际上是一个 if_statement 节点，因此，直接递归调用自身处理它们的 body 节点，并将 in_nodes 原样传递下去。

循环语句 (`while_statement`, `for_statement`, `foreach_statement`)

创建循环条件/迭代节点：为循环语句 (例如 while, for, foreach) 创建一个 CFG 节点，表示循环的条件判断或迭代过程。其入边来自 in_nodes。

处理循环体 (True 分支)：递归处理循环的 body (循环体代码块)。body 的入口边指向循环条件/迭代节点，并标记为 "True" 分支 (表示条件成立，进入循环体)。

循环边： 将循环体 body 的出口节点连接回循环条件/迭代节点，形成循环的回路。这表示循环体执行完毕后，控制流会再次回到循环条件判断处。

处理 break 语句：break 语句会跳出循环。找到循环体内的所有 break 节点，并将它们作为循环语句的出口节点之一。

处理 continue 语句：continue 语句会跳过当前循环迭代的剩余部分，直接进入下一次迭代。找到循环体内的所有 continue 节点，并将它们连接到循环条件/迭代节点，表示控制流回到循环开始处。

循环出口节点：循环语句的出口节点包括：

False 分支： 当循环条件不成立时，控制流会跳出循环。用从循环条件/迭代节点出发的 "False" 边表示。
break 语句出口： 循环体内的 break 语句也会导致跳出循环，break 语句本身也作为循环的出口节点。

🔥

所以，整体的入边有三种情况：

循环主体的前一个 statement，也就是 in_nodes

循环内部的 continue，控制流回到循环开始处

循环主体的最后一条语句，形成循环的回路

💡

循环语句引入了重复执行的代码块。通过创建循环条件/迭代节点、处理循环体、添加循环边、处理 break 和 continue 语句，完整地表示了循环结构的控制流。循环边和 break/continue 边的处理是构建正确循环 CFG 的关键。

`do_statement` (do-while 循环)

do_statement (do-while 循环) 与 while_statement 等循环类似，但它是先执行循环体，再判断循环条件。因此，处理逻辑也类似，但入口边和循环边的连接方式有所不同：

循环体入口：do_statement 的入口边实际上指向的是循环体的第一条语句 (或循环条件节点，如果循环体为空)。

循环边：循环体的出口节点连接到 do_statement 的条件节点，形成循环回路。

其他处理 (循环条件节点创建、break/continue 处理、出口节点) 与 while_statement 等循环类似。可能还需要注意的是 continue 节点执行之后，跳转到的是 do while 的条件节点

💡

关键区别： do-while 循环至少执行一次循环体，而 while 等循环可能一次都不执行。CFG 构建需要体现这种差异，主要体现在入口边和循环边的连接上。

`switch_statement` (switch 语句)

💡

switch_statement 的处理逻辑与 if_statement 类似，但有一些关键区别：

switch 语句的控制流是基于 case 语句的匹配，而不是 if-else 的条件判断。

case 语句的执行可能会贯穿多个 case（如果没有 break）。

break 语句会跳出 switch 语句，而 default 语句是可选的。

switch_statement 根据条件表达式的值，跳转到不同的 case 分支执行。处理逻辑如下：

创建 switch 节点：为 switch 语句创建 CFG 节点。

遍历 case 分支：迭代处理 switch 语句 body 中的每个 case 和 default 分支。

case 节点：为每个 case 分支创建一个 CFG 节点。case 节点的入边来自 switch 节点胡或上一个 case 语句的 out_nodes（如果没有 break），将 switch 语句到 case 语句的边标记为 case_name (或 "default" 对于 default 分支)。
case 语句块处理：递归调用处理每个 case 分支的代码块。case 语句块的入口边指向 case 节点。

break 语句处理：case 分支通常以 break 语句结束，跳出 switch 语句。找到每个 case 分支中的 break 节点，并将它们作为 switch 语句的出口节点之一。

switch 语句出口节点：switch 语句的出口节点包括所有 case 分支中的 break 语句的出口节点，以及最后一个 case 或者 default 的出口节点。

1. for case_node in body.children[1:-1] 为什么要指定 body.children 范围为 [1:-1]？

body 是 switch_statement 的 body 部分，通常是一个 {} 包裹的 case 语句块。例如：

在 AST 解析树中，body.children 可能包含：

children[0] 是 {（大括号的起始）。

children[-1] 是 }（大括号的结束）。

children[1:-1] 才是真正的 case 语句块。

因此，body.children[1:-1] 过滤掉了 {}，只遍历 case 和 default 语句。

2. index 和 case_name 的作用是什么？

case_name：用于存储 case 语句的匹配值。例如：

这里 case_name = "1"，用于标记 switch 语句到 case 语句的边。

index：用于确定 case 语句的第一条执行语句的索引。例如：

在 AST 解析树中：

case 关键字是 children[0]。
1（匹配值）是 children[1]。
:（冒号）是 children[2]。
doSomething(); 是 children[3]（第一条执行语句）。

因此，index = 3，表示 case 语句的第一条执行语句的索引。

对于 default 语句：

default 关键字是 children[0]。
:（冒号）是 children[1]。
handleDefault(); 是 children[2]（第一条执行语句）。

因此，index = 2。

这就是为什么 case 语句的 index = 3，而 default 语句的 index = 2。

总结

代码片段	`case_name`	`index`	说明
`case 1:`	`"1"`	`3`	`case` 语句的第一条执行语句在 `children[3]`
`default:`	`"default"`	`2`	`default` 语句的第一条执行语句在 `children[2]`

这样可以确保 case 和 default 语句的第一条执行语句被正确解析，并加入 CFG 结构。

`goto_statement` (goto 语句)

goto_statement 用于无条件跳转到代码中标记的标签位置 (labeled_statement)。处理逻辑如下：

创建 goto 节点：为 goto 语句创建 CFG 节点。

连接到标签位置：查找 goto 语句跳转的目标标签 (labeled_statement)。如果找到标签，则创建从 goto 节点到标签节点的边。

💡

goto 语句直接改变控制流的执行路径。通过创建 goto 节点并连接到目标标签节点，表示了 goto 语句的跳转行为。

`return_statement`, `break_statement`, `continue_statement`, `exit_statement`

这些语句都代表了程序控制流的终止或转移：

return_statement: 函数返回。

break_statement: 跳出循环或 switch 语句。

continue_statement: 跳过当前循环迭代的剩余部分。

exit_statement: 程序退出。

对于这些语句，处理逻辑相对简单：

创建语句节点：为每种语句创建 CFG 节点。

出口节点为空：这些语句通常是控制流的终点 (例如 return 和 exit) 或转移点 (例如 break 和 continue)，它们本身没有后继节点 (在当前函数或代码块的 CFG 中)。因此，它们的 out_nodes 返回为空 []。控制流的转移目标 (例如 break 跳出的循环的后继节点) 在处理包含这些语句的结构 (例如循环、switch、函数) 时已经确定好了。

普通语句

对于其他没有特殊控制流含义的普通语句 (例如赋值语句、函数调用语句等)，处理逻辑如下：

创建语句节点：为普通语句创建 CFG 节点。

顺序连接：将当前语句节点连接到 in_nodes，形成顺序执行的控制流路径。

出口节点：当前语句节点本身作为出口节点，传递给下一个语句作为 in_nodes。

💡

普通语句是代码的基本组成部分，它们按照代码的顺序依次执行。通过创建节点并顺序连接，表示了这种基本的顺序控制流。

待处理 ⚠️

对于影响程序控制流执行的，还有 try catch 、 throw statement 等，目前对于 try catch 语句的处理还是有些问题，因为 try 的主体里可能有 throw 语句，这样会立刻跳转到匹配的 catch 上，所以有个匹配连接 exception 的问题。

总结

总而言之，CFG 构建的核心思想是：

递归遍历 AST: 从根节点开始，递归地处理 AST 的每个节点。

语句类型判断: 根据节点的类型 (node.type)，判断当前节点代表的语句类型。

分类型处理: 针对不同的语句类型，采用不同的逻辑来构建 CFG 节点和边，以准确地表示该语句的控制流语义。

控制流传递: 通过 in_nodes 和 out_nodes 参数，在递归调用之间传递控制流信息，保证 CFG 的连贯性和正确性。

特殊语句处理: 重点处理具有特殊控制流含义的语句，例如条件分支 (if, switch)、循环 (while, for, do)、跳转 (goto, break, continue, return, throw)、异常处理 (try-catch-finally) 等。

感谢

特别感谢 https://github.com/rebibabo/INVEST 项目提供的思路和相关代码实现，让整个 PHP 的实现过程变得容易许多，同时通过该项目也学到了很多知识~

（就是项目的代码组织不是特别好，一个文件中的代码太长了 🫢，所以感谢 cursor 帮我梳理代码😂，后面写 PHP 的版本时，重构为模块化的了）

仔细瞧瞧 Tree-Sitter

Mon, 17 Mar 2025 00:00:00 GMT

Tree-sitter 是什么？

Tree-sitter 官方文档

在软件开发领域，理解和操作代码的结构至关重要。无论是语法高亮、代码导航，还是更高级的静态分析和代码重构，都离不开对代码的精确解析。Tree-sitter 正是为此而生的一个强大的工具，它是一个通用的解析器生成器和增量解析库，能够为各种编程语言构建具体的语法树，并在代码编辑过程中高效地更新这些语法树。

Tree-sitter 的核心在于其能够以高效且可靠的方式理解代码结构。它主要通过以下几个关键功能实现这一点：

解析器生成器和增量解析库： Tree-sitter 不仅是一个能够根据语言文法生成解析器的工具，更是一个在代码发生变化时能够智能地、只重新解析修改部分的库。这种增量解析的能力使得在文本编辑器中进行实时代码分析成为可能。

具体的语法树（Concrete Syntax Tree, CST）： Tree-sitter 将源代码解析成一棵包含代码中每一个词法单元（token）信息的具体语法树。与抽象语法树（Abstract Syntax Tree, AST）不同，CST 保留了源代码的所有细节，这对于需要精确理解代码结构的应用场景非常有用。

查询语言： Tree-sitter 提供了一种简洁的、基于 S-表达式的查询语言，允许开发者方便地在生成的语法树中查找特定的代码模式。这种查询能力是实现语法高亮、代码导航等功能的基础。

语言绑定： 为了方便在不同的编程环境中使用，Tree-sitter 提供了多种语言的绑定，包括官方支持的 C#, Go, Haskell, Java, JavaScript, Kotlin, Python, Rust, Zig，以及社区贡献的更多语言绑定。这使得开发者可以使用自己熟悉的编程语言来操作 Tree-sitter。

Tree-sitter 的语法系统

Tree-sitter 语法本质上是一个 grammar.js 文件，这个文件用 JavaScript 描述语言的语法规则。虽然语法规则是用 JavaScript 描述的，但这只是用来生成最终 C 程序的中间描述。编写完 grammar.js 文件之后，使用 tree-sitter generate [OPTIONS] [GRAMMAR_PATH] 命令即可生成对应语言的解析器。

💡

tree-sitter generate 读取当前工作目录中的 grammar.js 文件，并创建一个名为 src/parser.c 的文件，该文件实现了分析器。更改语法后，只需再次运行 tree-sitter generate。1

经过观察，在 src 目录下还有几个固定的文件，比如 grammar.json 等，在官方的文档中并没有找到明确的说明 grammar.json 来源，但是在一些 issue 中可以看到核心开发者的说明：

grammar.json is generated with tree-sitter generate (along with everything in src minus scanner.c)

所以，执行 tree-sitter generate 命令后，Tree-sitter 工具链会处理 grammar.js 文件，并在 src/ 目录下生成多个文件，包括 grammar.json 以及解析器的 C 代码。

所以，grammar.json 是从 grammar.js 文件自动生成的，生成过程如下：

首先，开发者在 JavaScript 文件 grammar.js 中定义语言语法规则

当运行 Tree-sitter CLI 命令 tree-sitter generate 时，Tree-sitter 工具会：

解析 grammar.js 文件

提取语法规则

将这些规则转换为标准化的 JSON 格式

自动生成 src/grammar.json 文件

对于 grammar.json ，因为其组织方式是 json，所以通过这个文件来学习对应语言的语法解析规则较于 grammar.js 是容易的。但是对于其存在的具体作用，下面是 AI 搜索给出的答案：

🤖

grammar.json 文件扮演着重要的角色：

中间表示：它作为 JavaScript 语法定义和最终 C 解析器代码之间的中间表示

规则标准化：提供了语法规则的标准化表示

解析器生成：Tree-sitter 的解析器生成器使用这个文件来生成实际的解析器代码

跨平台兼容：JSON 格式确保语法定义可以在不同平台和工具之间共享

`grammar.json` 的构成

一个完整的grammar.json 通常包含一万行左右的规则定义，所以如果要全部理解不同 statement 的语法还是需要学习一段时间的。不过全部学习也不是必要的，因为不同 statement 的语法规则声明方式是类似的，所以可以掌握基本的定义方式，直接搜索需要处理的 statement 即可。下面通过 PHP 语言的 grammar.json 来分析具体的内容。

grammar.json 的结构和组织方式是通过 $schema 字段指向的 URL 规定的，JSON Schema 文件描述了 Tree-sitter 语法的结构和规则，下面是一个 grammar.json 应该包含的顶层键以及对应内容的类型：

$schema:

类型为 string，表示 schema 的 URL。

name:

描述语法的名称。

类型为 string，必须匹配正则表达式 ^[a-zA-Z_]\\w*，即以字母或下划线开头，后面可以跟字母、数字或下划线。

inherits:

可选字段，表示继承自的父语法名称。

类型为 string，同样需要匹配正则表达式 ^[a-zA-Z_]\\w*。

rules:

定义语法的核心规则。

类型为 object，其键需要匹配正则表达式 ^[a-zA-Z_]\\w*$，值引用了 #/definitions/rule。

extras:

定义额外的规则（通常是空白字符或注释）。

类型为 array，元素是 rule，且不允许重复。

precedences:

定义规则的优先级。

类型为 array，每个元素是另一个数组，包含唯一的字符串或 symbol-rule。

reserved:

定义保留的规则。

类型为 object，键是规则名称，值是 rule 的数组。

externals:

定义外部规则。

类型为 array，元素是 rule。

inline:

定义内联规则。

类型为 array，元素是字符串，表示规则名称。

conflicts:

定义冲突规则。

类型为 array，每个元素是一个字符串数组，表示可能冲突的规则名称。

word:

定义一个特殊的规则名称，用于标识“单词”。

类型为 string，需要匹配正则表达式 ^[a-zA-Z_]\\w*。

supertypes:

定义隐藏规则的名称，这些规则会被视为“超类型”。

类型为 array，元素是字符串，表示规则名称。

Rules

https://tree-sitter.github.io/tree-sitter/creating-parsers/2-the-grammar-dsl.html

整个 grammar.json 的核心内容便是 rules 字段，它定义了具体的语法核心规则，每个子键值对定义一个语法规则：

键：这些是语法规则的名称（例如 program、statement、for_statement、expression）。这些名称会成为抽象语法树（AST）中的节点类型，当 tree-sitter 解析代码时会生成这些节点。可以将它们视为语言中不同的语法结构。

值（规则定义）： 这些是规则定义本身。每个值是一个 JSON 对象，用于指定如何识别和解析由键命名的语法规则。这些定义告诉 tree-sitter 在输入文本中寻找哪些模式，以识别该规则的实例。

每个规则定义（rules 字典中的值）是一个 JSON 对象，并且必须包含一个 "type" 属性。这个 "type" 属性决定了正在定义的语法规则的类型，以及 tree-sitter 应该如何解析它。grammar.schema.json 中的 definitions 定义了全部类型的规则，它们是语法规则的基础构件：

1. `blank-rule`

含义： 表示空或空规则。它通常用于 CHOICE 规则中，使语法的某些部分可选。

属性： 没有特别显著的属性，仅作为占位符。

必须包含字段： "type": "BLANK"。

在 simple_parameter 中，参数的 type 是可选的，由 BLANK 选项表示。

2. `string-rule`

含义： 这种规则类型表示必须在输入中精确匹配的字面字符串。

关键属性： "value"

"value"：需要精确匹配的字符串。

必须包含字段：

"type": "STRING"
"value": 字符串值。

在 _semicolon （分号，主要作用是标识语句的结束）规则中，";" 表示它会精确匹配 PHP 代码中的分号字符。

3. `pattern-rule`

含义： 这种规则类型使用正则表达式匹配一个标记。

关键属性： "value"

"value"：正则表达式模式。

可选属性： "flags"

"flags"：正则表达式标志（例如 "i" 表示不区分大小写匹配）

必须包含字段：

"type": "PATTERN"
"value": 正则表达式。

php_tag 规则使用正则表达式匹配 PHP 起始标签的各种变体（如 、、、）。

`4. symbol-rule`

含义：这种规则类型表示对同一 rules 字段中定义的另一个规则的引用。它用于从简单规则构建更复杂的规则。

关键属性： "name"

"name"： "name" 的值是另一个规则的名称，此规则引用该名称。

必须包含字段：

"type": "SYMBOL"
"name": 符号名称。

在此示例中，program 规则使用 SYMBOL 引用了 text 规则。在解析时，tree-sitter 会查看 text 规则的定义以理解 text 的组成。

`5. seq-rule`

含义：这种规则类型定义了必须按顺序匹配的一组规则。可以理解为“规则 A 后接规则 B 后接规则 C”。

关键属性： "members"

"members"：一个规则定义数组（可以是 SYMBOL、STRING、PATTERN 或其他规则类型）。这个数组中的每个元素都是一个子规则的定义。SEQ 规则要求输入文本必须按照 "members" 数组中子规则定义的顺序依次匹配。

必须包含字段：

"type": "SEQ"
"members": 一个 rule 的数组。

 function_static_declaration 规则的 "type" 是 "SEQ"，它定义了 PHP 中函数内部 static 变量声明的语法结构。

固定开头: SEQ 的第一个成员确保了每个函数内的静态变量声明必须以 static 关键字开始。

变量声明序列: SEQ 的第二个成员（本身也是一个 SEQ）处理了静态变量声明的列表。它强制至少要有一个 static_variable_declaration，并且允许通过逗号分隔声明多个变量。这种嵌套的 SEQ 结构展示了如何用 SEQ 组合更复杂的序列模式。

语句结束符: SEQ 的第三个成员确保了整个 static 变量声明语句以分号结束，符合 PHP 语句的语法规则。

在这个例子中，第二行 static $count = 0; 和第三行 static $name = "example", $value; 都匹配 function_static_declaration 规则。

static $count = 0; 匹配 function_static_declaration，因为：

以 static 关键字开始 (members[0])。

接着是一个 static_variable_declaration ($count = 0) (members[1] 的内部 SEQ 的 members[0])。

最后以分号 ; 结束 (members[2])。

static $name = "example", $value; 也匹配 function_static_declaration，因为：

以 static 关键字开始 (members[0])。

接着是第一个 static_variable_declaration ($name = "example") (members[1] 的内部 SEQ 的 members[0])。

然后是逗号 , 和第二个 static_variable_declaration ($value)，这部分通过 members[1] 的内部 SEQ 的 members[1] (即 REPEAT 规则) 来处理。

最后以分号 ; 结束 (members[2])。

`6. choice-rule`

含义：这种规则类型定义了多个规则之间的选择。它表示“匹配规则 A 或规则 B 或规则 C”。

关键属性： "members"

"members"：一个规则定义数组。

必须包含字段：

"type": "CHOICE"
"members": 一个 rule 的数组。

statement 规则可以是列出的任何语句类型（空语句、复合语句、if 语句等）。

`7. alias-rule`

含义：这种规则类型重命名 AST 中的节点类型。这对于使 AST 更具语义意义或一致性非常有用，即使底层语法规则名称不同。

关键属性： "content"、"value"、"named"

"content"：需要重命名的规则。
"value"：希望在 AST 中为节点命名的新名称。
"named"：布尔值，决定了通过别名创建的节点是命名节点(named node)还是匿名节点(anonymous node)，通常关键字为 false，命名节点为 true。

必须包含字段：

"type": "ALIAS"
"value": 别名值。
"named": 是否命名规则。
"content": 引用的规则。

💡

Tree-sitter 的语法树中存在两种主要的节点类型：

1. 命名节点 (named: true)

代表语言中的有意义语法结构（如变量声明、函数定义等）

在语法树中明确可见，可以通过名称引用

通常表示更高层次的语法概念

在查询语言中可以直接通过名称选择

2. 匿名节点 (named: false)

代表语法标记、分隔符或其他辅助性元素（如括号、逗号、关键字等）

在语法树的可视化表示中通常不作为独立节点显示

被视为父节点的一部分而不是独立实体

在查询语言中不能直接通过名称选择，但可以通过其字面值匹配

区别：

语法树结构:

命名节点 (named: true) 在树中作为独立节点存在

匿名节点 (named: false) 仅作为字符串值存在，不产生独立节点

查询影响:

可以编写查询来捕获命名节点: (parameter_name) @param

无法直接通过名称查询匿名节点，但可以通过内容匹配: "let" @keyword

named 字段决定了别名节点是作为语法树中的独立实体存在（named: true），还是仅作为父节点的一部分存在（named: false）。理解这一区别对于正确设计语法、编写查询以及处理语法树至关重要。

final_modifier 规则将关键字 "final" 别名为 AST 中名为 "final" 的节点。_class_const_declaration 规则将 _class_const_declaration 规则别名为 AST 中的 const_declaration 节点。

`8. repeat-rule & repeat1-rule`

含义：这些规则类型定义重复。

"REPEAT"：匹配 content 规则零次或多次。
"REPEAT1"：匹配 content 规则一次或多次。

关键属性： "content"

"content"：要重复的规则定义。

必须包含字段：

"type": "REPEAT" || "type": "REPEAT1"
"content": 引用的规则。

在 program 规则中，在 php_tag 之后可以有零次或多次 statement。text 规则被定义为其内容至少重复一次。

`9. token-rule`

token 规则的核心功能是将一个复杂的规则整体视为单一词法单元。它指示解析器将匹配的内容作为一个原子单元处理，而不是分解为更小的部分。当使用 token 方法时，我们创建了一个单一的文本标记。token 方法只接受终结规则（terminal rules），因此不能引用其他规则。

含义：将一个复杂的模式标记为单个词法单元，适用于“当多个字符应该被视为单个不可分割的标记时”，通常用于语法中的终结符号（标记）。

关键属性： "content"

"content"：定义标记的规则

必须包含字段：

"type": 可以是 "TOKEN" 或 "IMMEDIATE_TOKEN"。
"content": 引用的规则。

integer 规则是一个 TOKEN，它可以是几种模式之一（十进制、八进制、十六进制、二进制）。

`10. field-rule`

含义：为 AST 中的子节点命名。

关键属性： "name"、"content"

"name"：希望赋予子节点的名称（例如 "condition"、"body"、"name"）。
"content"：子节点的规则定义。

必须包含字段：

"name": 字段名称。
"type": "FIELD"
"content": 引用的规则。

在 if_statement 规则中，parenthesized_expression 被命名为 "condition"，紧随其后的 statement 被命名为 "body"，使其在 AST 中清楚地表示每个部分的含义。

`11. prec-rule 和优先级规则（PREC_LEFT、PREC_RIGHT、PREC_DYNAMIC）`

含义：这些规则用于处理语法中的运算符优先级和结合性，尤其是在表达式中。它们帮助解析时解决歧义。

"PREC"：设置一个通用的优先级级别。
"PREC_LEFT"：设置左结合性和优先级。
"PREC_RIGHT"：设置右结合性和优先级。
"PREC_DYNAMIC"：动态优先级，通常用于更复杂的情况。

关键属性： "value" 和 "content"

"value"：优先级级别（数字越大优先级越高）。
"content"：优先级适用的规则。

必须包含字段：

"type": 可以是 "PREC"、"PREC_LEFT"、"PREC_RIGHT" 或 "PREC_DYNAMIC"。
"value": 优先级值，可以是整数或字符串。
"content": 引用的规则。

在 unary_op_expression 中，PREC_LEFT 使得像 -5 中的 - 这种一元运算符具有左结合性，优先级为 19。sequence_expression 中的 PREC 使用一个较低的值，使逗号运算符的优先级非常低。

`示例阐述`

下面通过 if_statement 的规则定义进行具体的示例讲解。

👇 展开查看完整的 if_statement 定义



咔！𝟐𝟎𝟐4 结束啦~
Sat, 28 Dec 2024 00:00:00 GMT
开心的事，在年终总结，不开心的，在年终了结
学途 📚
今年，可以说是比较有意义的一年，我的学生身份发生了转变，在成电获得了学士学位，然后去国科大攻读硕士研究生。
毕~业~啦 🎓🧑‍🎓
大学四年好像并没有很漫长……还记得大一刚开学时，我和我爸拖着行李做了九个小时的高铁来到了成都，这是我第一次来到离家这么远的地方，那时我也比较期待，因为20年的抖音经常能刷到“成都太古里”等视频，让我认为，成都，潮流、年轻又现代化的一个城市。
支教队好朋友的毕业合照
六月初，学院的毕业典礼如期的举行，意味着大学生活真的接近了尾声。拍学院毕业照、班级毕业照以及同学毕业照，参加毕业典礼，听着老师们送的祝福。最后，收拾宿舍床铺，卖掉带不回去的东西，和周围同学告别后，就这样离开了成电，离开成都，因为时间原因也没有加入朋友的毕业旅行。坐在出租车上，看着学校渐行渐远，难免会不舍，还会再见吗？成都可能还会，但有些人可能不再了吧……
回想四年的生活，我好像就是循规蹈矩，按部就班的学习，卷绩点，卷保研，参加一些学院工作室和社会实践活动。虽然通过招新加入了学校网安工作室、参加了中国计算机设计大赛拿了全国三等奖，但是，感觉自己很水。进入工作室之后并没有持续学习，导致去参加 CTF 比赛完全是去吃东西，计算机设计大赛也没有技术含量，就是数据可视化系统。四年间要说让我印象最深刻的，可能就是大三下学期的实习了吧，我并没有去大厂或者公司实习，一方面因为自己算法很差，感觉通过不了面试；另一方面是想卷保研，所以申请了清华的 NISL 实验室面试。半年的实习，让我在工程、科研上相较之前都有了比较大的进步，虽然比较累，但很充实，参与的两篇论文工作也都在今年中了 ISSTA🥳~
毕业证书和录取通知书
大学的遗憾可能就是不够努力去争取吧，在有时间的时候，没有像周围同学去大厂实习，也没能像一些同学专心做科研发表顶会，也没有主动一些去交朋友。总是在给自己找借口，认为自己没时间，不去争取，不去进步，总想着多放松摆烂。如果大一就能有这种觉悟，可能大学四年会很充实吧 😶‍🌫️
和女朋友的毕业合照
但，四年的大学生活时光还是很美好的 😋，加入社团摄影，参加支教队，相识了女朋友，结交到了好朋友，在成都 City walk，九眼桥、宽窄巷子、杜甫草堂、都江堰、青城山、大熊猫基地、太古里等等，巴适；和女朋友各种探店，吃吃吃；和朋友自驾去了川西，美美美。总之，成都给我留下了美好的回忆，成都就是最巴适的城市，Number 1 🤩
读-研-了 🗣️
国科大桥
八月底开学，我和我爸、我姐拖着行李来到了北京，然后坐上果壳的校车从市区前往非常偏僻的怀柔。校区确实很新，也挺大，隔着一条马路，分为东区和西区，附近都是山或者荒原，有些地方还在建设。我们学校背后就是山，旁边是雁栖湖景区，山上有些小动物会溜进校园里，比如蛇蛇🐍、小鹿等，听说还有野猪，所以学校的环境是没得说，很漂亮。但就是太偏僻了，去怀柔市区需要打的🚖半小时，去北京市区需要坐城际小火车一个半小时，只能说去哪都不方便，学校附近也没商场啥的，连外卖都没得，只能每天都吃学校的食堂，但能吃的好像也没几个窗口，经常搞错单的渔粉窗口、有虫子的盖饭、难吃一批的拼盘……每天两问舍友：吃什么？（因为早上不吃饭 😀）
果壳图书馆
研究生我也没选择竞选加入学生会、班干部等，总觉着很麻烦，只想清静一些。所以半年的研究生生活还是很单调的，日常的上课，完成组里交代的活，和腾讯会议打交道，跟着师兄搞科研，闲了就学习一些开源项目，然后跟着室友去健身房增肌锻炼，所以基本就是泡在宿舍里。周末不加班的情况下就写写周刊，打打游戏，或者坐三四个小时的车去大兴找女朋友（虽在同一城市，但没想到北京这么大 🥲）。
穿越人海为科学而来
这半年在科研上更多的感觉在做调研，和导师聊我后面想做的研究方向是 LLM for Software Engineering，目前在推进的是 LLM for Vulnerability Dection。花了一个月的时间调研了现有的工作，目前就和师兄们一起想 idea 然后测试，但还有一些难题还没有很好的解决，希望后续工作顺利~ 
Coding 🧑‍💻
去年的一个 flag 就是，希望今年能够多学一些技术，为开源做一些贡献，应该也是小小实现了一点点🤗
今年应该主要是创建了两个 repo。一个是 
CodeTransEval
Github
CodeTransEval
Owner
huhusmang
Updated
Oct 21, 2025
，也就是我的毕业设计，一个评估 CodeLLM 在复杂的数据结构和算法上代码生成的框架，包括输入预处理、模型调用、输出处理、测试执行和可视化分析模块，代码其实已经经过一次简单的重构，但是目前来看，项目的结构组织还是很难看 😅，现在也没时间（懒得）重构了 😬
另一个项目是 
Awesome-LLMs-for-Vulnerability-Detection
Github
Awesome-LLMs-for-Vulnerability-Detection
Owner
huhusmang
Updated
Jan 19, 2026
，起因是在调研的时候想着像一些项目也做一个当前领域的汇总，如果有相同研究领域的人，也能方便一些，目前也有 40 个 🌟🌟 咧，嘿嘿，看来也是有其他人需要的。项目也使用了一个 Github Action，用于每天定时获取 Arxiv 上有关使用 LLM 进行漏洞检测的最新文章，这也是借鉴了一个项目的想法，然后使用了最新的库进行了重写。开源伟大 🥳
图中的两个 PR 是看到师兄的一个下载安全四大顶会的项目，正好之前调研时有一个需求，我想找到这个会议上和给定方向或者关键词相关的论文，所以就 fork 下来在 AI 助手的陪伴下，比较快的完成了这个需求，通过调用 AI 根据论文的标题和摘要，判断是否是相关的论文 😊，不得不说，和 AI 一起写代码，在需求明确的情况下，是非常舒服的（写的上瘾 🤣）。然后后面又因为我主要使用 Notion 来记录各种笔记，所以又加了一个导出到 Notion 的 feature。 其实也顺便做了一个导入到 Zotero 的，但是发现导入的数据没有 doi，所以发现导入后也没什么用，不会自动下载对应的论文。
因为课程评估的大量重复性工作，所以我也做了一个课程评估的小插件，这样就可以一键填写评估内容了😊（视频演示）
哦对，我终于尝试丢掉 conda，用上了如此优雅，相见恨晚的 uv，太优雅了，赏！
⛳
立个 flag，明年做一个完整的 AI 加持的论文收集和分类的工具。
周刊 📜
今年暑假，八月十一号，我发了第一篇《随笔周刊》。写周刊的原因是因为看了很多周刊，感觉很有趣，可以整理一下一周的所见、所闻、所想等，我平时收藏的比较多，所以也会想有一个输出内容的地方，可以是介绍这周看到的有趣论文；或是有用、有趣的开源项目；或是好看的视频；或是好听的音乐；或者好看的照片；或是个人的吐槽和经历；或是玩的游戏等等。因为我是一个不太会主动和别人分享日常生活的人，我日常生活中更喜欢当做一个倾听者，听他人的经历或者分享，但我有时候发现一些东西或者有些想法也想分享，所以我感觉周刊可能适合我，我不需要关心别人喜不喜欢或者感不感兴趣，因为我更多的是把它当作个人周报，哦我也不是啥大咖，也没啥人知道我的周刊 😃。
目前一共写了 18 篇周刊，虽不能做到周周更新，但是不重要，不想有这个约束，随心就好 🤠
生活 🌄
旅行 🚅
今年旅游和出去耍比去年还是多了挺多的，保研之后的大四时间还是比较充裕的 😊
西昌
三周年的时候，不知道该怎么过，学校附近都逛得差不多了，也想去看点大自然风景，小红书刷到西昌不错，有风有云有“海”，然后就直接出发寻找春天啦。邛海有骑行道，就在当地租了个小电车，环海骑行了一圈，那天天气也很好，所以天很蓝，景很美，沿途有好看的地方就随时停下来，拍拍照📷。中间路过一个古村，有很多提供少数民族服饰拍照的，看着还不错就买了个套餐给女朋友拍一套，包括化妆、衣服和拍照，不得不说专业摄影师拍人像还是有东西的，首先是有一套研究好的动作，不同景色搭配不同的动作，会告诉你眼睛看哪，手和脚该怎么摆，还是挺不错的哦。就是最后的精修图价格有点贵，套餐里好像自带五张，再多修一张 50😀，小贵，不过好看的照片还是都让修了的。傍晚到达了一个日落观景点，等了一个小时，看到了还不错的日落。这好像是我第一次骑电动车载人，哈哈哈，不过还好，车技还是可以的。
看日落
骑小电车
云南
后面四月份也来了一场说走就走的旅行，因为朋友说她们计划好了去云南，搞得我心痒痒，一直想去云南，看看洱海和古城。本来还挺犹豫不决的，女朋友很爽快说去，那就直接买了一周后的机票。可以说很开心，第一次坐飞机，然后来到了电视剧中的那个有风的地方，但四天的旅途可谓是特种兵。
第一天先坐飞机到昆明，然后坐高铁到大理，晚上逛古城，古城感觉还好，现在古城商业化都挺严重的，而且卖的东西都大差不差，重复性很高，不过看古城里的小酒馆还是挺不错的，氛围不错😌。
烟花🎇
篝火晚会
I 💗 DaLi
第二天早起看日出，然后骑共享单车环洱海西线，早上人很少，几乎没什么人，而且天气是大晴天，真的太美了！海边，晴天，微风，空气清新，这可太适合骑行了(＾∀＾)☀️。下午去喜洲古镇，但感觉没啥，主要也没时间去体验扎染。正好那几天碰上了有节日活动，晚山有风花雪月节，去古镇体验了篝火晚会，最后还有超级漂亮的烟花，一天下来太充实了😋。
骑行 🚲
美丽的洱海
后面第三天坐大巴去丽江，哦，太难受了，坐旅游大巴还是一如既往的恶心想吐，下车去民宿的路上还走错了路线，拖个行李箱在石子路的古城里走，要命(ㆆ_ㆆ)✌️。晚上随便逛了逛丽江古城，比大理古城丰富一些，但也就简单逛了逛，早回去休息，因为第二天要早起准备去玉龙雪山。五点多出发去看日照金山，但云层太厚没看到😮‍💨。而且那天大索道要维修，所以没去登顶，坐小索道去爬了会牛背山，还阔以吧。
玉龙雪山
索道
丽江古城
总体来说几天的旅程有点赶，没有足够的时间和💰来慢慢体验，但我感觉大理还是更适合我，喜欢出门就可以看到海的地方，在海边散散步，这种感觉很 chill
邓紫棋演唱会
六月初，邓紫棋来成都开演唱会，女朋友是邓紫棋的粉丝，我也挺喜欢邓紫棋的歌。正好抢票那天我很丝滑的抢到了两张票🥳，太激动了，而且后面分到的位置也靠前。之前我其实认为花这么多钱去听演唱会很不值，不就是现场版听歌嘛，还不一定有戴上降噪耳机的好听，除非买内场前几排可能还会和歌手有个互动。但当演唱会开始，《摩天动物园》点燃开场，邓紫棋从舞台下升起来的时候，瞬间就超激动，后面虽然我记不到歌词，也会一直跟着哼哼 😜，听完之后意犹未尽，甚至有了戒断反应，演唱会的氛围还是太沉浸啦！！！
北京故宫
开学的时候，我爸和我姐来送我，所以提前来了两天，打算和家人逛逛。哦，故宫票可真难抢，刷了四十分钟才抢到•ᴗ•💧。而且，逛故宫的人太多了，根本没心情看建筑，人挤人，还热的不行，就感觉很累，一点都不想继续逛了😮‍💨，而且这种古建筑，历史不好的话最好请个（或蹭一个）导游讲解，反正我是看不出来啥门道，只知道古人好牛，这建筑上的图案纹理真细腻(¯▽¯)👍
红墙
好漂亮哦
天津
中秋节和一起来到果壳的大学同学去天津玩了两三天，但好像没有找到特别令人哇塞的地方😂，白天逛了逛涂鸦墙，打卡了黑神话的涂鸦，在意式风情区溜达一圈，然后晚上做了超级无敌大冤种的天津之眼🤡，还不如去坐那个轮船。第二天去滨海新区逛了逛，还行就是有些单调，海景还是不错的
北京野生动物园
国庆和女朋友去了北野，嗯，很累很累，主要是人很多的情况下啥景点应该都没意思了，只有无尽的排队(~_~💧)。九点到开始排猛兽区，然后排了三四个小时才排到，就坐在车里逛了十五分钟左右，主要是那猛兽区一点也不猛，一个个就趴在那里睡觉晒太阳，除了黑熊扒着路过的车要肉吃，这确实第一次见，熊是真大啊😂。所以我感觉如果来得晚，为了这十几分钟排三四个小时太冤种了🤡。后面在园区里随便逛逛小动物感觉挺不错的，有卡皮巴拉，鹈鹕，成群的小猴子，还有袋鼠🦘，有个爬行动物专区还挺不错的，原来蜥蜴🦎有这么多品种😲。哦，最后一点，北野太偏了，没车的情况下交通太不方便了🫠
可爱的袋鼠
nie了吧唧的老虎
好吃的熊
环球影城
十月底和女朋友去了环球影城，体验万圣主题👻，我其实比较胆小的，不敢去鬼屋，之前在成都欢乐谷的时候，我都是排在朋友之间，低着头过鬼屋，但也被吓得不轻😅。这次只有我和我女朋友，所以我只能站在我女朋友后面了😁🫣，没办法，她胆子比我大☺️，但三个鬼屋，逐渐 big 胆，最后一个因为后面的人尖叫声太足了，全程想笑🤣。感觉游乐设施和场景比鬼屋好玩，体验太沉浸了，只可惜买的夜场票，好多项目还没玩，之后买全日票再去逛逛。没体验到霸天虎过山车，看着太帅了，下次也不敢🫨
探店 🍜
今年探店明显比去年少了很多，因为下面半年基本都是在学校吃食堂。要说现在记起来的好吃的或者想吃的，可能就是：梅菜扣肉饼，大学宿舍门口的烤冷面，九锅又一堂的酸菜鱼，小薇薇烤肉。还有在丽江吃的几顿饭都挺不错，印象深可能是因为在大理吃的饭都不咋地吧。
吃吃吃！
看剧 📺
今年也是看了二十多部电影和电视剧，有很多喜欢的，也不乏看到烂片。同样，我列一下我心中的 Top6（还是挺难选的，好多好看的）：
机器人之梦：三刷不腻，虽然是无声电影，但独特的画风以及细腻的情感刻画足以让人沉浸其中，结尾虽然略带遗憾，但也充满了希望与释怀。September 太好听啦~
小巷人家：看完心里暖暖的，真想继续看他们的生活 🥹
沙丘2：太帅了，激动的我大晚上看完，骑着自行车在路上狂飙，就 tm 像骑沙虫一样
唐朝诡事录之西行：每个案子立意都好好 😭，剧情设计的太好了，好期待第三部
好东西：很不错的电影，喜剧元素也很多。做一个小孩儿~
照明商店：一群素昧平生的人，努力与过去和解。后面太好哭了，一切都串起来了，一切都是有原因的。
哦对，《因果报应也》挺好看的 ☺️，期待明年的精彩电影和电视剧
游戏 🎮
今年玩了九款游戏呢！原来有这么多哈哈哈，感觉自己今年没玩几个，主要就是上半年在玩帕鲁，下半年玩黑猴，而且研究生开学之后就没咋玩了，时间都不是很充裕。帕鲁的话成就都拿到了，最近的更新还没玩，刚开始确实好上头，抓宝可梦帕鲁，这太有意思了，小时候看神奇宝贝就想着自己能抓就好了，各种属性的帕鲁，还能当资本家压榨让他们打工，这不就是爽文主人公嘛哈哈哈，后面帕鲁都抓到之后，就没咋玩了，因为只剩下需要慢慢肝的了。
黑猴的话，说实话我是第一次正式玩魂类游戏，之前玩巫师、大镖客等都没继续玩下去，主要是不清楚要干啥，进去太迷了，就懒得探索了。黑猴能开始，还是有很大的主观倾向，齐天大圣，从小看到大的，谁不喜欢啊。小时候（现在也是）路上看到个直直的棍子，都想捡起来耍会。所以也是直接购入了豪华版开玩，但是打到大头娃娃就打的有点怀疑，还好慢慢的还是学会了如何正确打 boss，看准招式，及时闪躲，切忌贪🔪。一周目的通关也是用了风灵月影的，有几个 boss 实在打不过，比如寅虎、小黄龙、杨戬，但是毒敌大王我是用毛毛流打过去的，有几个 boss 死了二三十次才过去哈哈哈，成为不了识破仙人。已经开启了二周目去刷成就，二周目就下载了一些不是很影响游戏平衡的 mod，因为跑图还是有点累的。这个月新更新的连战模式也好玩，可以练技术！我也要成为识！破！仙！人！
顺便期待一下明年的文明 7，再来一回合就睡觉🤣🤣🤣
健康 🥗
今年上半年本来是挺健康的，但是后半年来到北京的四个月，有三个月都生病了🤒。十月底因为细菌感染得了肺炎，不知道是不是去环球影城感染的，没去查之前，只是发高烧，也没有咳嗽和流鼻涕，单纯的发高烧，最高发烧到 39.2，吃布洛芬也没用。两天没退烧（第一天去校医务室拿了一些药）就去市医院查血了，抽血和拍 CT 之后，结果是左上肺位置有肺炎，C反应蛋白指标52.5，就立即进行了输液，输液三天之后烧退了，再吃一周的药就好了。
但是十一月中下旬不知怎么的，又感冒了，开始咳嗽，而且比较剧烈，不过没发烧。正好之前医生让我三四周后去复查，所以就又去医院进行检查，CT 显示肺炎好了，但是得了急性支气管炎，又开了一周的药，三四百 🥹，吃了一周多咳嗽好了。
不幸的是，十二月中下旬我又开始咳嗽和流鼻涕了，感觉是周末爬山送水导致的，上山的时候没带口罩，喘气也比较急促，导致吸入了很多凉气，当时就感觉嗓子不舒服，第二天就开始流鼻涕，后面就开始逐渐咳嗽了，而且鼻涕很多不见好转，又去医院验血，结果是细菌感染，支气管炎 🙂，我就这么容易细菌感染嘛😭，咳嗽真的不舒服，特别是想睡觉的时候，一个咳嗽给弄醒了，哎。
不知道为什么，可能是没适应北京的气候吧，导致这么高频的生病。断断续续的咳嗽也让我的健身终止了，十月底之后就没再去过。希望下年能够健健康康 🙏
AI 🤩
今年 AI 领域的发展依然很迅速，模型、产品、论文等层出不穷。对于我这种 AI 激进者，很期待能力更强的模型发布，期待更自动化的产品发布，期待更多的新技术出现、更多的技术细节披露和开源！下面简单的介绍一下我目前的 AI 工作流吧。
Coding
工具：Windsurf（pro），Cursor（pro），Copilot，Gemini（API）
对于一个需要实现的需求，我会先尽量明确和细化需求，特别是对于比较复杂的任务。然后我会先使用 Windsurf 根据需求生成一个初始的版本，接着使用 Cursor 进行进一步的开发和迭代。在两个工具中我都是优先使用 claude 3.5 sonnet，效果不好的话就换成 o1。这样我整个开发过程效率会提升很多，我就变成了一个需求确定和细化的角色。
当然 AI 给出的解决方案不一定是最优解，在需求是匹配的任务上尤为明显，AI 更倾向给出正则表达式的方案，而且会过于依赖提供的例子，导致有种 “过拟合”，不够 general，这时候就需要自己思考比较好的解决方案和算法了，当然也可以和 AI 一起头脑风暴。所以，我是用 AI 辅助编程时，AI 对于我更多的是一位出色的将自然语言描述转化为代码的翻译角色。
阅读总结
工具：ChatGPT（plus），豆包
因为有日常读论文的需求，在并不想精读的情况下，可以直接拖拽给豆包进行快速总结，了解文章的大致内容和提出的方法，如果有意思值得细读的话就会先保存到 Zotero 中。精读时我会使用 ChatGPT，因为对比其他的模型使用感受，还是 ChatGPT 在进行阐述总结时，给的答案最满意，比如 Claude 3.5 总是倾向于简短的列出要点，一点一点的，不喜欢。而且，精读的过程是需要保证莫模型的一个基础能力的，这样对于论文中的概念和细节才能够理解并阐述的清楚，能力不强的可能会出现幻觉。
AI 搜索
工具：Perplexity（pro），豆包，腾讯元宝
对于 AI 搜索，日常的简单询问、非技术性问题我一般直接调起豆包进行回答了，对于稍微专业一点的报告类似的，可以使用元宝的深度搜索，因为元宝还是接入了微信的公众号信息源，公众号的信息还是挺丰富的。对于技术性问题，我会使用英文作为输入，然后使用 Perplexity 进行检索相关信息，因为中文输入的话会被国内的某些信息源污染 🥵。
API 调用
Zotero：在 Zotero 中下载翻译和 GPT 插件后，可以自定义配置自己的 API，翻译目前使用 Gemini 1.5 flash，便宜快速稳定，效果还好😉。GPT 插件用的还是 4o 模型。
Cherry Studio：本地的 ChatLLM 客户端，可以使用自己的 API 的本地应用，通过设置不同 prompt 的角色助手，快速完成不同的需求；还可以自定义多个知识库，通过 RAG 对话自己的文件。另外也可以方便使用开源 LLM~
今年还买了两个小鸡，一个腾讯云 2c2，一个最近刚买的香港 4c4g，后续应该主要续费 4c4g 的，还是内存大点舒服。vps 主要就是部署一些在线服务，比如我现在的 api 管理，以及在线 Chat 客户端可以给家人使用。
AI 集成平台
趁着黑五六折特价订阅了 Monica 的 Unlimited 套餐，这样也可以无限（次数超了也应该会降智的）使用一些高级模型，还可以使用各种流行的绘画和视频模型，这就很方便，不用订阅其他服务了。
今年模型和产品的快速发展和迭代，我也在不断更新我的整个工作流，尽可能的让 AI 融入到我的工作流中，来提升我的效率。有时候在浏览器选中一段文字时，会搞笑的出现各个插件同时弹出来的情景🤣，争着抢着让我点它。
o1 系列模型的出现，让模型的发展进入了另一个阶段，各大厂商也都推出自带思维链的模型，着重提升模型的推理能力。目前有闭源的 OpenAI 的 o1 和 Gemini 的 thinking model，国内两大国产之光 Deepseek 和 Qwen 也都推出了推理模型，而且是开源，深受欢迎！今年只是推理模型的开端，我相信 25 年，模型的能力会更让人 wasai！也很期待 Agent 真正到来 🤩
展望 ✨
愿新的一年仍有阳光满路暖如初☀️
对于新的一年，我最希望的就是身体健健康康，平平安安 🙏。对于科研，希望下年能发表一篇论文（CCF-A 更好 ☺️），自己的科研能力再 up up。对于工程，还是希望自己能够不断学习新的框架和技术，继续做一些自己有需求的东西，在此基础上也能为开源做一些贡献。对于爱情，我相信我和女朋友会更加甜蜜幸福🥰。最后，我也相信我的 25 年肯定也是哇塞的！🎇
 


布尔逻辑表达式取反
Sat, 21 Dec 2024 00:00:00 GMT
最近有这样一个需求，我需要对一个复合字符串 PHP 逻辑表达式进行取反，得到取反后的字符串逻辑表达式，例子如下：
由于我需要进行批量操作，所以需要一个程序能够自动化实现这种转化。首先的想法是，先考虑如何使用 Python 实现简单的字符串逻辑表达式取反操作，比如：
如果能够实现上述功能，那就可以先将字符串 PHP 逻辑表达式进行抽象，转化为符号表达的逻辑表达式，然后再进行取反，最后通过第一步骤的字典再映射回去。所以，重点是实现符号字符串逻辑表达式的取反操作。
符号字符串逻辑表达式的 AST 抽象
处理逻辑表达式并不是简单的从左到右进行处理，逻辑表达式中的运算符有不同的优先级：
括号 ()
最高优先级
用于改变默认的运算顺序
可以嵌套使用
非（NOT）
一元运算符
对操作数取反
符号表示：¬, !, NOT, ~
与（AND）
二元运算符
所有操作数为真时结果为真
符号表示：∧, &&, AND, ·
或（OR）
二元运算符
任一操作数为真时结果为真
符号表示：∨, ||, OR, +
所以需要想一种办法，先将逻辑表达式抽象出一个运算优先级分明的表示，比如针对之前提到的例子 (!(!A || !(B && C)) && (D || !E)) ，最外层的运算符应该是第二个 && ，即表达式的结果一定是左侧表达式 !(!A || !(B && C)) 的结果和右侧表达式 (D || !E) 的结果的 && 操作。然后同理，可以同样处理左右两侧表达式，有些像数据机构中的树的算法思想，所以可不可以将其转化为一棵树呢？
我先搜索有没有类似的实现，发现有一个博客介绍到将字符串逻辑表达式转化为 AST，也就是抽象语法树，但是并没有给出具体的输入输出例子，也不清楚得到的 AST 是什么样的？所以我直接给 AI 提了这个需求，得到的答案如下（当然经过了多次修改哈 🤪）:
文法规则
文法规则是一组用于描述特定语言结构的规则。它们定义了如何将语言中的不同元素组合在一起形成有效的语句或表达式。可以将文法规则想象成语言的“骨架”，它决定了句子如何被构建。
在当前的实现中，文法规则用于定义被解析的语言的语法。解析器根据这些规则检查输入的语句是否符合语法，并构建相应的内部表示（ AST）。
EXPR := TERM { 'or' TERM }: 一个 EXPR (表达式) 由一个 TERM (项) 开始，后面可以跟零个或多个由 "or" 连接的 TERM。 这表示 "or" 运算具有最低的优先级。{} 表示大括号内的内容可以重复零次或多次。
TERM := FACTOR { 'and' FACTOR }: 一个 TERM (项) 由一个 FACTOR (因子) 开始，后面可以跟零个或多个由 "and" 连接的 FACTOR。这表示 "and" 运算的优先级高于 "or"。
FACTOR := 'not' FACTOR | VARIABLE | '(' EXPR ')': 一个 FACTOR (因子) 可以是 "not" 后跟一个 FACTOR，或者是一个 VARIABLE (变量)，或者是一个由括号包围的 EXPR。这表示 "not" 运算具有最高的优先级，而括号可以用来改变运算顺序。
VARIABLE := 字母开头的标识符: 一个 VARIABLE (变量) 是一个以字母开头的标识符（这里简化了，实际上标识符的规则更复杂）。
递归下降解析器
递归下降解析器是一种自顶向下的解析器，它通过为文法规则中的每个非终结符 (non-terminal) 编写一个函数来实现解析。这些函数相互递归调用，以匹配输入字符串中的结构，就像文法规则所描述的那样。
特点:
易于理解和实现: 递归下降解析器的结构通常与文法规则非常相似，因此相对容易理解和实现。
递归性质: 解析过程是递归的，因为函数会相互调用来解析子结构。
自顶向下: 解析从文法的起始符号（在本例中是 EXPR）开始，然后逐步向下解析到更小的组成部分。
当前代码如何实现递归下降？
parse 函数及其子函数 (parse_expression, parse_term, parse_factor) 共同构成了一个递归下降解析器，用于解析逻辑表达式。它们的工作原理如下：
与文法规则的对应关系:
parse_expression 对应文法规则 EXPR := TERM { 'or' TERM }
parse_term 对应文法规则 TERM := FACTOR { 'and' FACTOR }
parse_factor 对应文法规则 FACTOR := 'not' FACTOR | VARIABLE | '(' EXPR ')'
递归调用: 这些函数根据文法规则相互递归调用。例如：
parse_expression 调用 parse_term 来解析 "or" 运算符两侧的项。
parse_term 调用 parse_factor 来解析 "and" 运算符两侧的因子。
parse_factor 在遇到括号时会调用 parse_expression 来解析括号内的表达式，形成递归。
自顶向下解析: 解析从 parse 函数开始，它调用 parse_expression，然后 parse_expression 调用 parse_term，parse_term 调用 parse_factor，形成自顶向下的解析过程。
处理优先级和结合性: 通过函数的调用顺序和循环结构，解析器隐式地处理了运算符的优先级和结合性。例如，parse_expression 在循环中处理 "or"，而 parse_term 在循环中处理 "and"，这确保了 "and" 的优先级高于 "or"。
构建 AST: 在递归调用的过程中，每个函数都构建 AST 的一部分，并将部分结果返回给调用它的函数。最终，parse 函数返回完整的 AST。
总之，这组函数实现了一个递归下降解析器，它根据给定的文法递归地解析逻辑表达式。每个函数负责解析特定类型的语法结构（表达式、项、因子），并根据需要递归调用其他函数。最终可以将输入的表达式，转化为类似如下优先级清晰的逻辑表达式：
所以，有无已有的第三库实现？🧐
对于这中通用的规则处理或者解析，我相信丰富的 Python 生态肯定已有相关的实现！通过搜索发现，能够实现转化 AST 需求的解析器还挺多，就是复杂度的区别。
ast 标准库
首先是 Python 中的 ast 标准库，没想到可以直接进行转换！ ast 可以直接接收一个逻辑表达式并转化为 AST：
mode="eval"：指定解析模式为"eval"：
输入的字符串将被解析为一个可求值的表达式
与其他模式相比（如"exec"用于执行语句，"single"用于交互式输入），"eval"模式专门用于处理单个表达式
返回值：返回一个ast.Expression对象，这个对象包含了表达式的语法树结构，可以通过.body属性访问具体的语法树节点
例如，如果输入表达式是 "A and B"，生成的AST会包含：
一个BoolOp节点（表示布尔运算）
运算符And
两个Name节点（分别代表A和B）
😶‍🌫️
不得不说，即使知道某一个 Python 库，也只是知道常用的操作，像这些不看文档都发现不了，不得不说，AI 真香 😋
在得到 AST 之后，只需要写一个遍历即可：
你看，又有好东西，还有 ast.NodeTransformer ，不对，我确实好像没咋用过 python 的 ast 模块，肤浅了肤浅了🙈，真优雅~
lark 
https://github.com/lark-parser/lark
Lark 是一个用于 Python 的现代解析库，专注于易用性、性能和模块化设计。它能够解析任何上下文无关文法（Context-Free Grammar），并且提供了多种解析算法供选择，包括 Earley、 LALR(1) 和 CYK。 lark 能够根据文法自动构建解析树（Parse Tree），无需额外的构建代码。
嗯，好多名词没看懂，但是 get 到了重点， lark 库是天生的根据文法规则构建解析树的圣体。那肯定更优雅！ lark 的使用包括：定义文法规则；定义解析器（可选）。
最顶层是 expr，处理 or 运算
中间层是 term，处理 and 运算
底层是 factor，处理 not 运算、括号和变量
这种层次结构确保了运算符优先级：not > and > or
TreeBuilder 的作用是将解析树转换为简单的抽象语法树（AST）。
当解析器遇到语法规则中定义的模式时，会调用对应的方法
每个方法接收一个 children 参数，包含该规则的所有子节点
方法返回一个简化的表示形式，通常是元组
例如，对于表达式 "not (A && B)":
variable 方法处理 A 和 B，返回它们的值
and_expr 方法处理 A && B，返回 ("and", "A", "B")
not_factor 方法处理整个表达式，返回 ("not", ("and", "A", "B"))
📜
还有一些第三方库，暂时就没有尝试了，感觉 lark 就很优雅了，就先列举一下：
pyparsing : https://github.com/pyparsing/pyparsing/
funcparserlib : https://github.com/vlasovskikh/funcparserlib
基于 AST 的逻辑表达式取反
有了 AST，对 AST 中的节点进行取反操作，就相当于对一颗二叉树执行德摩根定律，完全可以套用二叉树的递归算法进行处理，这就很方便了：
函数采用递归的方式处理这个表达式。函数会不断地调用自身来处理表达式的子部分，直到遇到最基本的节点元素——变量。
基本情况 - 变量: 如果遇到一个变量（字符串），函数会在它前面加上 "not" 来表示取反，并返回结果。
操作符处理: 如果遇到一个操作符（元组），函数会根据操作符的类型进行不同的处理：
"not": 如果是 "not" 操作符，函数会直接返回被取反的子表达式，相当于去除了一层 "not"。
"and" 和 "or": 如果是 "and" 或 "or" 操作符，函数会应用德摩根定律。函数会将当前的 "and" 或 "or" 操作符替换成对应的 "or" 或 "and"，然后递归地对两个子表达式进行取反操作。
至此，大部分核心操作已经完成，现在可以输入一个字符串逻辑表达式，得到取反后的字符串逻辑表达式，验证如下：
非常的牛啊，我自己算都得一会，唯一的瑕疵就是有些多余的括号，但无伤大雅，而且这些例子都比较复杂了，真实的需求并不需要这么复杂逻辑表达式。
PHP 逻辑表达式抽象为符号逻辑表达式
现在剩下来的工作就是如何将 PHP 逻辑表达式抽象为符号逻辑表达式，比如：
在实现时，使用的是正则匹配，通过正则表达式识别到 PHP 中的数据结构等，然后进行 tokenize。目前的要求如下：
识别逻辑运算符：&&, ||, !, (, )
处理复杂的 PHP 表达式，包括：
函数调用：function_name($param)
变量访问：$variable
对象属性访问：$obj->property
数组访问：array[index]
比较表达式：===, !==, ==, !=, >=, <=
能处理嵌套的括号结构
这些规则都是根据测试用例不断添加的，这也是我在这种情况下不太喜欢用正则的原因，因为不够 general。然后为每个唯一的操作数分配一个大写字母（A-Z），并建立双向映射。最终实现结果如下：
总结
Ok，大致的就这些，并不是复杂的一个问题，但是刚开始处理的时候，由于太过依赖 AI，就直接将最开始的需求交给了它，然后反复的 chat、debug，但越改越乱，最后给出的更改基本上都是只适用于给出的这些用例，很气哦，浪费时间。所以还是自己先调研一下，想出一个大致的思路，然后让 AI 结合我进行 Coding，逻辑理清楚之后，一会就实现了~
So，需要推理或者思考的算法逻辑问题可以先思考一下（想不到可以调研类似实现或者给 o1 头脑风暴试试），有一个大致的路线，再交给 AI 实现，这样不仅节约时间，而且还能使用下自己的🧠，别退化了哈哈哈


Follow 认证
Mon, 23 Sep 2024 00:00:00 GMT
This message is used to verify that this feed (feedId:60613242413328384) belongs to me (userId:55922905684581376). Join me in enjoying the next generation information browser https://follow.is.
 


WSL2 安装和配置 Pytorch GPU
Mon, 09 Sep 2024 00:00:00 GMT
前提条件
Windows 10 版本 21H2 或更高版本或者 Win 11
NVIDIA 的显卡
WSL 2 上安装的是 Ubuntu 20.04 或更高版本
Windows 已经安装了 Nvidia 的驱动程序
⚠️
驱动程序需要适用于 WSL，即能使用虚拟 GPU，因为在 WSL 上，使用的 CUDA 驱动程序是系统上安装的 Windows 驱动程序的一部分，目前电脑最新的驱动程序基本上都是支持的
在进行测试安装时，本地配置为 Windows 11；安装的是 WSL2，系统为 Ubuntu 22.04；Windows 已经安装最新的 Nvidia 驱动程序。
自定义安装 WSL 🌟
顺便写一下之前是如何自定义安装 WSL 的，即非 C 盘安装。
按照 https://learn.microsoft.com/zh-cn/windows/wsl/install-manual 执行完步骤五（步骤三之后重启电脑）
在 下载发行版  这个标题下选择一个版本进行安装
安装之后得到的是 .appx 之类后缀的压缩包
解压，得到两个架构的 .appx Ubuntu
解压 x64 的 .appx 
点击 ubuntu.exe 进行安装
ok，这就安装好了，适用于之前未安装过 WSL 的，如果之前通过任何方式安装过，需要将相关旧文件都删除，还挺麻烦的，删不干净安装可能会报错等！
安装 CUDA
确定支持的版本
首先在终端中输入 nvidia-smi 来获取目前显卡支持的最高 cuda 的版本，如图，目前我的电脑支持使用的最高 CUDA 版本是 12.6。
📌
nvidia-smi 命令需要在安装驱动后才能使用
在 Ubuntu 上安装 NVIDIA CUDA
通常，Linux 版 CUDA 工具包会附带打包 GPU 的设备驱动程序。但在 WSL 2 上，使用的 CUDA 驱动程序是系统上安装的 Windows 驱动程序的一部分，因此必须注意不能直接使用 apt-get install cuda 的形式安装 CUDA，直接从 Ubuntu 存储库安装 CUDA 工具包软件包将导致安装 Linux NVIDIA 显卡驱动程序，这不适用于 WSL2。1
首先删除旧的 GPG 密钥：
下载 CUDA 安装优先级文件：这个文件定义了 APT 包管理器在安装过程中如何为 CUDA 软件包设置优先级，以确保 CUDA 包在系统中的高优先级处理。
移动优先级文件到指定目录：这个目录用于存放 APT 包的优先级配置文件，确保 CUDA 包的优先级比其他包更高，避免安装其他版本时发生冲突。
获取 NVIDIA 的 GPG 密钥：APT 包管理器使用 GPG 公钥来验证从远程仓库下载的软件包的真实性和完整性。这里下载的是 NVIDIA 提供的公钥，保证从 NVIDIA 服务器下载的 CUDA 软件包是安全和可信的。
添加 CUDA 软件源到系统：添加 NVIDIA 的 CUDA 软件源到 APT 包管理器中，使得我们可以从这个源中直接安装 CUDA 相关的软件包。
更新 APT 包索引和安装 CUDA 工具包
首先查看目前可用的 CUDA 包的版本，然后根据之前步骤确定的系统支持的最高 CUDA 版本来确定安装的版本。
但同时也要注意，一般要求 Pytorch 支持的 CUDA 版本最好能够和安装的 CUDA 版本一致，虽然有向下兼容性，但是为了后续出现一些 bug，最好选择相同的版本。从图中可以看出目前的 Pytorch 最高仅支持到 12.4 的 CUDA，所以我们选择安装 cuda-toolkit=12.4.1-1 
❓
这里是有一些疑问的，我在进行最后一步安装的是 cuda-toolkit，但是教程给的是 cuda 。因为之前提到 sudo apt-get install cuda 将安装整个 CUDA 软件包，其中包括 CUDA 工具包和必要的 NVIDIA 驱动程序，但是驱动是不必要的，而 cuda-toolkit 软件包专注于提供创建和构建 CUDA 应用程序所需的开发工具，包括库、头文件和其他资源，不包括驱动程序。1

但是我发现之前添加的CUDA 软件源是单独为 WSL 适配的，可以看到： compute/cuda/repos/wsl-ubuntu/x86_64/ ，所以不清楚使用 apt-get install cuda  进行安装会不会产生什么影响？
设置环境变量
编辑 ~/.bashrc ，添加以下内容，保存然后执行 source ~/.bashrc 
验证安装
这个命令将显示已安装的 CUDA 编译器（nvcc）的版本信息。如果成功安装会看到类似如下的输出：
安装 cuDNN
在安装好 CUDA 之后，通常还需要安装 cuDNN（CUDA Deep Neural Network library），特别是使用深度学习框架（如 PyTorch 或 TensorFlow）进行 GPU 加速的深度学习任务。
为什么需要安装 cuDNN？
cuDNN 是 NVIDIA 提供的一个高性能库，专门优化了深度学习的常见操作，例如卷积运算、池化、归一化和激活函数等。它在 CUDA 的基础上进一步优化了这些操作，使得深度学习框架能够更高效地使用 GPU。
深度学习框架的依赖：大多数深度学习框架（如 PyTorch 和 TensorFlow）都使用 cuDNN 来加速卷积神经网络等深度学习模型中的常见操作。虽然这些框架可以只使用 CUDA 进行加速，但安装 cuDNN 能够显著提升性能。
计算效率：cuDNN 对神经网络的操作进行了高度优化，特别是在多层卷积、RNN 等操作中，cuDNN 的性能大大优于只使用 CUDA 的实现。
下载对应版本的 cuDNN
首先访问 https://developer.nvidia.com/rdp/cudnn-archive 选择最新版本的 cuDNN
之前安装的是 12.4 版本的 CUDA，所以我们选择第一个进行安装，对于 cuDNN 安装就和普通的 Linux 安装步骤一样，不需要考虑 WSL 的特殊性了，因此我们下载 linux x86_64 的：https://developer.nvidia.com/downloads/compute/cudnn/secure/8.9.7/local_installers/12.x/cudnn-linux-x86_64-8.9.7.29_cuda12-archive.tar.xz/
解压并复制相关文件到指定位置
1. 解压 .tar.xz 文件
首先需要将 .tar.xz 文件解压。假设你下载的文件名是 cudnn-linux-x86_64-.tar.xz，可以使用以下命令来解压缩文件：
这会将文件解压到一个文件夹中，通常会包含 cuda/include 和 cuda/lib64 目录。
2. 将 cuDNN 文件复制到 CUDA 目录
接下来，将 cuDNN 的头文件和库复制到 CUDA 安装目录中。通常 CUDA 会安装在 /usr/local/cuda/ 目录下。
执行以下命令：
这些命令会将解压出来的 cuDNN 文件复制到系统的 CUDA 安装目录中，确保 cuDNN 的库和头文件正确集成到 CUDA 环境中。
3. 检查 cuDNN 是否安装成功
安装完成后，你可以通过检查 cudnn_version.h 文件来确认 cuDNN 是否正确安装。执行以下命令：
你应该会看到类似以下的输出，显示已安装的 cuDNN 版本号：
这个输出表明你已经成功安装了 cuDNN，并且你当前安装的版本是 8.9.7。
安装 Pytorch
如之前提到的，访问页面：https://pytorch.org/get-started/locally/，然后选择相应的选项，CUDA 版本选择之前安装的，我这里使用的是 conda，所以最终的命令如下：
💡
可以看到这里面也有一些 torchvision 等库，可能暂时用不到，可以自行选择安装
然后就是验证是否安装成功并且设置好 GPU 环境，运行以下代码即可：
总结
总的安装过程大概就是：
确定系统支持的最高的 CUDA 版本
确定目前 Pytorch 支持哪些 CUDA 的版本
通过官方给的 WSL 软件源，下载合适版本的 cuda-toolkit
找到支持选定的 CUDA 版本的 cuDNN
📌
这只是安装方法的一种，可以参考下方的参考链接 1 和 2 使用其他方法安装，比如本地 deb 安装等。
之前的环境在另一个电脑上配置的，也是刚开始学习 DL 时配置的，后面实习、做项目用到卡也都是用的服务器，本地只适合做些小实验和用来学习，所以换新电脑后也没配。最近上人工智能攻防课，需要环境，所以打算在 WSL 中配置，因为 Linux 下写代码还是比 Windows 舒服的。前前后后找了相关文档和教程，问了 AI，总体还是顺利的，没有出现配置错误~
参考
Enabling GPU acceleration with the NVIDIA CUDA Platform
Nvidia：CUDA on WSL User Guide
Install Tensorflow & Pytorch with CUDA [Linux | WSL2]
Everything About CUDA in WSL2 Ubuntu


Code Translation
Thu, 18 Jul 2024 00:00:00 GMT
TL;DR
🙈
该文章介绍了一个用于评估 CodeLLMs 在代码翻译任务上的功能性和安全性的自动化框架，旨在通过指定模型名称，实现自动化评估模型的表现。框架支持模型推理、输入处理、输出处理、模板设置、批量运行、指标计算及可视化分析，并提供了一个易用且美观的前端UI界面。同时对评估结果进行了深入的分析和可视化。            
✍️Introduction
代码翻译 （Code Translation）
代码翻译（Code Translation）指的是将一种编程语言编写的源代码转换成另一种编程语言同时保持相同功能的过程。如图为将Python代码翻译为功能一致的Java代码示例。这种转换可以是从低级语言到高级语言，也可以是在同等级别的语言之间转换，例如从Python2转换到Python3，从Java转换到Python等。
将 Python 代码翻译为 Java 代码      
代码翻译的目的通常是为了利用目标语言的特定优势，如更好的性能、更广泛的库支持或更适合特定应用的语言特性或者是为了维护遗留系统等。代码翻译不仅仅是简单的语法替换，还需要处理不同编程语言之间的语义差异，确保转换后的代码在功能和性能上与原代码等效，生成的代码必须语法正确，且不引入错误。因此，这是一个复杂且技术要求高的过程，通常需要专门的工具和深入的语言知识来实现。
CodeLLMs
代码生成模型是一种人工智能模型，它可以根据给定的输入生成代码。这种模型通常使用机器学习和自然语言处理技术，通过学习大量的代码样本和规则，来理解代码的结构和语法，并能够根据用户的需求生成相应的代码，能够完成诸如代码生成、代码补全、代码翻译等多种编程任务。
A Survey on Language Models for Code
意义
在实际的生产环境中，我们不仅希望模型生成的代码在功能上正确无误，同时也需保证代码的安全性。功能性评估关注代码是否正确实现了预定功能，包括其逻辑正确性和满足特定需求的能力。安全性评估则着重于市场的代码是否存在可能导致数据泄露或引入漏洞等安全隐患。
为什么要评估安全性？LLMs 的训练通常包括两个阶段：预训练和微调。在预训练阶段，模型通常在大规模的语料数据集上训练，比如 Github 仓库的代码，这就难免会引入包含漏洞的相关代码，导致模型在生成相关代码时输出具有漏洞 🐞的代码。Pearce 的开创性研究首次对 GitHub Copilot 在程序生成过程中的安全性进行了系统评估。研究结果表明，在约 40% 的测试场景中，Copilot 生成的代码存在可被利用的安全漏洞。                                                     
重复性工作 ❓ ❓❓ 
功能性评估 ☑️
目前已经有较多的权威 Benchmarks 大多针对的是代码生成和补全任务，评估模型输出的代码在测试用例上的 Pass@k 等指标，比如 EvalPlus Leaderboard，LiveBench，Big Code Models Leaderboard 等，具有全面的模型和不受污染的实时数据集、具有区分度的高难度题目等。         
但是对于代码翻译任务上的功能性评估，目前的权威 Benchmarks 较少，只有几个相关的数据集，XLCoST，G-TransEval，CodeTransOcean，CodeXGLUE，xCodeEval 等，而且这些数据集普遍存在一些局限性。首先，大多数数据集倾向于包含简单的编程问题，如基本算法实现或简单的代码片段，缺乏对复杂数据结构和算法的覆盖。这与现实生产环境中开发人员面临的复杂工程和算法问题形成鲜明对比，限制了这些数据集在评估模型处理复杂算法和编程任务能力方面的有效性。其次，现有数据集中的测试用例数量通常较为有限，且案例设计较为简单，往往未能涵盖大范围的边界值和异常情况。评估代码大模型的功能性正确需要丰富多样的测试用例，以模拟实际应用场景中的各种输入和约束条件。
安全性评估 🐞
目前对于代码翻译任务上的安全性评估是没有相关研究的 🤗（我来当第一人bushi 🙈）。因此需要自己构建评估数据集、评估方法和评估框架。 考虑源代码不存在漏洞时，翻译成另一种语言的结果是否出现漏洞？源代码存在漏洞时，翻译成另一种语言的结果是否仍保留这些漏洞？
Contribution✨
引入了一个功能性评估数据集，共100条，数据的选取日期在2023年之后（因为数据收集部分是在23年末），每个数据有五个测试用例，覆盖不同的测试用例范围，100条数据中含有各个难度的题目，相较之前研究提供的简单数据，该数据集有二叉树算法，图算法，递归等复杂算法和高级数据结构。同时每个问题都提供了Python, Java, C++三种编程语言的结构基本一致的标准答案，每个答案都通过全部的测试用例。
引入了一个安全性评估数据集，该数据集通过搜集已有的公开数据集和安全网站提供的示例漏洞样本组合而成，经过滤后共50条。区别于之前的安全数据集，本项目的评估任务是代码翻译任务，所以对于将包含漏洞的Python代码翻译为Java代码，需要保证Python中的漏洞类型在Java中同样存在，且可以翻译为对应的Java代码。因此首先需要人工确定该Python代码包含的漏洞在Java中也有对应的漏洞，然后确定该Python代码可以翻译为Java代码。
引入了一个自动化的评估框架，只需指定模型名称即可实现自动化评估模型的表现，框架包含模型推理，输入处理，输出处理，模板设置，批量运行，指标计算，可视化分析等。并且提供了一个易用且美观的前端UI界面，可以浏览数据集，提交任务，查看任务状态，查看模型输出结果以及分析模型输出指标值等，将框架的部分脚本整合为API，为前端提供调用服务。
对实验的评估结果进行了数据分析，全面的横向和纵向对比模型的表现。                  
💫Method
数据集构建🔢
功能性评估数据集
数据收集：从 LeetCode、HackerRank 以及洛谷三个平台收集不同类型和不同难度的算法题目，每个题目需要收集对应的description、tag、difficulty、params 以及三种编程语言的标准答案。100条数据中，简单（easy）级别有37题，中等（medium）级别有53题，困难（difficulty）级别有10题。            
数据审查：由于本评估任务为代码翻译任务，所以特别强调三种语言的参考解答在结构上的一致性，这对于确保CodeBLEU评估指标的有效性至关重要。对于那些难以在结构上保持一致的标准解答的题目，将进行必要的修订或剔除，以维持数据集的标准化和一致性。  
安全性评估数据集
数据收集：从 CodeQL 官方仓库、SVEN 研究公开的数据集以及 SecurityEval 研究公开的数据集收集相关的具有 Python 漏洞的代码片段，共五十条数据。
数据审查：
使用 CodeQL 对收集的Python漏洞代码样本进行了全面验证，确保其包含预定的漏洞类型。         
跨语言漏洞的对比分析：验证Python和Java两种语言中的安全漏洞一致性，依据CodeQL官方提供的CWE漏洞类型清单，对Python代码样本中的漏洞进行了系统审查，确保Java版本中存在相同类型的漏洞。例如，如果存在特定于Python Flask框架的漏洞（如flask-debug），而Java中无对应实现，则应从数据集中移除该样本。      
评估框架构建 ⚒️
目前全部的代码已经开源，这也算是我第一个完整的项目，期间经历了一次电脑宕机 push 我尝试将代码同步到 github 中，并使用 git 管理我的整个 project。  
CodeTransEval
Github
CodeTransEval
Owner
huhusmang
Updated
Oct 21, 2025
                            
评估流程图   
💡
说明：该框架流程图将功能性评估和安全性评估进行了统一，两种评估在流程上基本一致，对于输入处理和模型调用模块也是共用的，区别可能在于输出处理和测试执行模块，因为安全性的评估是调用外部第三方工具分析整个文件，所以较为简单。因此下面的每个模块分析都已功能性为主。                                                           
输入处理模块 📄
因为数据集只是提供了单纯的代码片段，不能直接输入给 LLM，需要指明具体的要求和任务等，因此需要设计 Prompt 模板，然后对其进行拼接作为 LLM 的输入。
下面为功能性评估的 prompt 模板，四个可替换参数为： SL ，TL ，SC ，PARAMS。可以看到下面的 prompt 大致分为三个层次：必要的要求即翻译任务；数据的相关信息；返回代码片段应遵循的要求。其中有四个要求是关于返回代码片段的，因为在实际的实验过程中发现有些模型，特笔是模型本身能力较差，指令遵循能力不好的模型，总是会输出一些上下文（比如相关的代码解释等）和代码注释等，以及输出的代码格式不符合标准的 md 语法没，导致后续无法自动化解析。这里并没有尝试让模型输出 json 格式的数据，感觉应该是个不错的选择，因为之后看到其他 repo 使用了 json output parser。
评估流程—输入处理
下面是安全性评估的 prompt 模板，其中的要求更多了，主要是因为漏洞评估的数据集涉及到了很多 web 服务的代码，因此在 java 代码中需要引入标准库或者第三方库。由于使用 CodeQL 进行漏洞检测，需要提供的 java 代码能够通过编译，所以需要实际的调用库，从下面的要求可以看出，我首先明确大多数情况下先使用内置的标准库，在标准库无法实现对应功能情况下，使用一些常见的、相关依赖较少的库。然后如果引用了第三方库，需要提供 pom.xml ，以为 CodeQL 可以自动编译 maven 管理的项目。
🤗
这些要求和方法也是我自己尝试了几个可能的编译方法之后，在自动化优先的情况下所提出来的，肯定还有更好的方法，毕竟我对 java 项目不是很熟悉~                               
模型调用模块 🤙
目前也有成熟的模型统一接口调用的 repo 比如 
litellm
Github
litellm
Owner
BerriAI
Updated
Dec 27, 2025
，但当时编写项目最初版本的时候，是先对一两个模型进行测试，而且都是有 API 提供商的，所以就直接翻阅官方文档调用对应的 API 了。期间这个模块经历了几次迭代：抽象出统一的调用接口、添加 Pydantic 库作为前置的参数传入验证以及统一的 API key 管理。                                   
评估流程—模型调用  
输出处理模块 🧰
从上一个模块的示例图可以看到，即使模型的输入要求了输出的格式，但是在返回的结果中仍有文字描述等信息，所以需要从模型的输出中提取出需要的代码片段，具体的需求如下：                                                    
提取出模型输出中所有的代码片段，基于正则表达式匹配 md 的 code blcok     
去除代码块中的所有注释，因为对于后续的 CodeBLEU 指标会有影响
去除相关的定义数据结构的代码，比如定义 TreeNode 等，因为这些已经在模板文件中定义，防止运行时发生冲突。（这里可能会有一些潜在的问题，因为如果模型输出的代码中定义的数据结构和已经定义好的不一致，就会导致对应的代码无法运行，原本可能正确的代码判为错误的。但是由于在输入的 prompt 中传入了 params ，其中包含了数据结构的 Name ，且经过观察模型能够与传入 params 中的数据结构保持一致，暂未发现由此引发的误判）。
去除代码块中包含 main 函数等调用函数，因为嵌入到模板中会造成目标函数多次调用或者造成冲突等其他影响。 
提取出源代码对应的翻译后的代码。这里的步骤可能令人匪夷所思，认为有些多余，因为经过上述四 个步骤处理后的代码就应该是目标代码了。但实际测试会发现一些问题（提前说明一下，因为在后续的自动化测试运行模块中，为每种语言都定义了一个模板文件，只需传入相关的代码片段即可，也就是翻译后的  n 个函数以及 entry point 。比如一个搜索相关的算法有两个函数 count 和 dfs ，其中 dfs 函数是被调用的递归函数，所以 entry point 就是 count ）：
源代码的 entry point 翻译为目标语言代码后，entry point 发生了改变，即使代码可能功能正确的，也会导致模板文件中运行测试用例的部分因为找不到对应函数，导致无法调用函数进行测试。比如 lengthOfLongestSubsequence 翻译后可能会变为 length_of_longest_subsequence             
❓
所以问题的难点就抽象转化为：给定 n 个函数，如何找到整体的 entry point
方法一：正则表达式提取
整个大致的提取流程如下：
将代码片段转化为 code lines
遍历所有的 code lines，基于正则表达式提取出定义的 function name
将所有 function 转化为由 name 和 body 构成的一个字典
遍历每个 function body，识别出被调用的 function，保留未被其他函数调用的函数，这些函数就被认为是“主函数”，默认提取第一个为 entry point ，虽然有些逻辑 bug，但是基本所有情况都是只有一个“主函数”（需要考虑自己调用自己的递归函数）           
提取主函数的 body，然后递归提取子函数的 body，作为最终的 target code                                
整个提取过程都是使用的正则匹配来提取，需要考虑以下几个提取的问题：
如何识别一个编程语言中的函数，即识别出一个函数的 body
如何识别出一个函数的函数名
如何识别出调用的函数    
如何识别并处理自己调用自己的递归函数
具体的实现代码可以查阅代码库，每个编程语言都需要编写专门的正则表达式，而且需要多次测试执行，反复修改代码。因此对于复杂的、多步骤的提取处理，感觉正则处理很是复杂且逻辑还可能有瑕疵，不建议使用了 🥵 🥵🥵                               
评估流程—输出 处理
🫠
整个正则表达式的编写，经历了很多次的调试才到最终的版本，因为基于规则的匹配不可能一蹴而就，刚开始想不到一些点，只能多次尝试，尽可能覆盖多的、范围广的测试用例。比如在 C++ 中识别函数名，基于 re.compile(r".*\s+\b[A-Za-z_][A-Za-z0-9_]*\b\s*\(.*\)\s*\{") 规则匹配的话，会错误的将 while 等带有 {} 体的认为函数体，进而识别出错误的函数名。                                                      
方法二：基于 AST 提取
tree-sitter
Github
tree-sitter
Owner
tree-sitter
Updated
Dec 27, 2025
 是一个强大的解析器生成工具和增量解析库，它为编程工具提供了一种新的解析系统。Tree-sitter可以为源文件构建一个具体的语法树，并且能够在源文件被编辑时高效地更新这个语法树。
AST 是源代码的树状表示，它抽象地表示了代码的结构，而不是具体的语法细节。每个节点代表源代码中的一个语法元素，如函数定义、变量声明、表达式等。
AST 包含了详细的语法信息，能够精确地区分不同类型的节点。例如，可以轻松识别出哪些节点是方法声明（"method_declaration"），哪些是方法调用（"method_invocation"）。通过深度优先或广度优先搜索，访问树中的每一个节点，根据节点提供的信息就可以提取出代码中的方法声明和方法调用等相关元素。下面已 Java 为例，阐述如何使用 tree-sitter 大致的提取相关信息。
首先加载 Java 语言的 Language 对象，然后创建一个 Parser 对象，这个对象将用于解析 Java 代码  。
假设我们有代码如下：
那生成的 AST 如下所示（每个 node 只展示其 type 的信息）：


𝟐𝟎𝟐𝟑•全剧终
Sun, 31 Dec 2023 00:00:00 GMT
2023年即将过去，我的这一年，空空落落又满满当当，昏昏沉沉又明明白白，无所谓好也无所谓坏，但这就是实实在在，属于我的日子，平淡，也适合！
created by DALLE·3
学习 📚
今年在学习方面的成果有两个，一个是推研，另一个应该就是在实习期间参与了一些研究和项目。
旅途 🚃
今年的 6-9 月份，都在围绕着保研进行展开，特别是 6、7 月份，整个人的压力很大，每天忙着复习、准备资料以及浏览着各种最新的信息，防止错过什么重要的通知。当然，最后也 “柳暗花明又一村”，虽然自己的推免成绩排名不是很好，前面入营的情况很惨，但是对于后面入营的学校，都认真准备，保证自己争取到的名额都拿到~ 
最后也算是去了自己的一个意向的组，后面仍需继续努力，更多的保研旅途可以看这篇文章 😊
拍摄于推研复习期间
科研 🧪
今年半年多都在清华 NISL 组参与远程实习，期间也参与了两篇论文工作 📝。我还很清楚记得，刚进组的我就像一个安全和科研方面的小白，面对涉及到的工程以及论文方面都不太懂，感觉压力很大。不过很幸运，有很好的学长带着我，组内的氛围也很融洽，在小组会上提出难以解决的问题也能很快解决，慢慢的，也就渐渐的熟悉了 Binary Code Similarity Detection(BCSD) 这个领域，后面就参与调研、跑实验、写 paper。犹记得五月份有段时间，为了赶很多实验，经常一天工作十几个小时，现在想想，挺 crazy 的 🤣
最后也很感谢这段实习经历以及各位学长老师们，对我提升很大，不论是工程、研究还是沟通合作上，也希望 2024 年初能收到论文投中的好消息 🙏 🥰
实习期间每天都在和这八张卡打交道，不过好爽😎
项目 👨‍💻
记录一下今年参与的一个小项目，是在进组之后，我这边的任务就是测评国内的大模型在代码翻译领域上的表现。具体工作包括：题目收集、自动化评测框架编写、主流模型评测。整个项目流程大概一个半月，在此期间我的电脑也很不给力，坏了两次，第一次坏了之后很害怕，因为是本地开发的，也没有尝试过 git 备份，电脑修好之后就赶紧配置了 git 备份，现在也养成了写好一部分就 commit 的习惯 🫡。顺便 post 一下我今年的 🗑️ 年度报告，明年加油！(其他的没  commit 就不写了 😗)
生活 ☀️
回过头来看照片和一些记录，发现今年在一些片段的闲暇时刻享受了不少乐趣~ 包括吃、旅游、煲剧、听歌等，let’s see it 👇
探店 🍽️
今年感觉最大的一个改变就是，会吃了，两个意思都有：能吃；喜欢吃好吃的 😂，每周或两周就想和💞女朋友 💞一起出去探个店，或者吃收藏夹里的店，嘎嘎香，有时候不禁会想，以后离开成都吃不到这么好吃实惠的没事了，呜呜呜 😭。让我想想目前记到的好吃的店：酸菜鱼、捞王(第一次尝试)、地锅鸡、鸡公煲、麻椒鸡、干锅烤鱼、汉巴味德…… 我还是直接 post 图吧，ok, so
旅游 🚵‍♂️
今年应该算两次旅游，一次和女朋友在三月底也就是两周年的时候去成都的一个花田旅游，很开心，拍了很多照片，吃了两周年蛋糕，现在想想快三周年啦~ (美女就不给看了 😜
第二次旅行是在国庆末，当时刚推免结束，来一场说走就走的旅行，五个人自驾去了川西，绕着小环线走了一圈。成都 → 泸定桥 → 红海子(迦嘎措) → 鱼子西 → 木雅大寺 → 四姑娘山 → 卧龙大熊猫基地 → 都江堰 → 成都。五天的旅程，只有第二天的天气最好，在红海子拍了很多好看的风景和合照~，最遗憾的莫过于第三天在鱼子西五点多起去看日照金山 🏔️，但是云层很厚，并没有看到什么，最神奇的是我们不甘心，有其他旅游团都走了，我们又呆了一会，眼看云层在慢慢散去，刚拍一两张照片，结果突然下雪了 ❄️，然后一分钟之内，远处的山不见踪影，雪也渐渐变大了，大部分人从原路返回，但我们的计划路线是继续往西，目前这条路下雪挺危险，幸运的是遇到一个一样开着坦克 的驴友，也要往那边走，然后两辆车相互照应，一起出发了！
之后的天气也大多是阴天，不给力，不过总体的旅程还是很不错的，新奇的自驾体验，虽然我是那个经常忘记安全带的副驾 🙂。藏餐也还不错，但是那个什么牛肉，是真的咬不动 😅，牛肉盖被还是不错滴，搞笑的是，吃的最香的一顿是一家餐馆的川菜，真香，果然川菜还是永远嘀神 🥰。哦~期间还会玩了一个卡牌游戏：uno，挺不错的，笑得腹肌都出来了 🤣。这趟旅程之前我还准备了一些药，怕自己高反，不过看起来我很健康哦，基本没有什么反应，除了爬山的时候轻微喘不上气，吸一两口就好了~，最高海拔 4500 米左右。更多 🖼️照片 👉 这里
有机会，希望能去看贡嘎，看日照金山，去稻城亚丁 🏞️
看剧 📺
回头一看记录，发现今年煲的剧还是挺多的，电影+电视剧+动漫等大概 30 部，在这之中，有些剧给我的后劲很大，我来给个 top5:
漫长的季节（个人认为封神 💥，准备二刷）
绝命毒师 1-5 季（say my name.）
莲花楼（世上再无李相夷 😭，准备二刷）
雾山五行（打戏太丝滑帅了）
狂飙（风浪越大，鱼越贵）
当然还有很多剧给我留下了深刻的印象，就像三体、黑暗荣耀等，每部剧都有值得的看点。很高兴今年的许多国产剧给我留下了深刻的印象，期待 2024 年的佳作~ 🥳
（附一下豆瓣的 2023 年度电影榜单，网页做得好漂亮 👍
健康 🩺
今年没怎么生病感冒，只在三月初应该是得了一次甲流，发烧了四五天。今年在健康方面的一个坏消息应该是 “腰肌劳损” 或者是 “轻度腰间盘突出” 了 😭😭，一二月份在家的时候当时只知道屁股疼，并不知道什么情况引起的，以为是天太冷，在家里盖厚被子翻个身都疼的翻不过去 😵‍💫。后面回学校得了甲流的第七天吧，腿疼的走不了路，走路腿都发抖，站不稳 🥵。去医院做了抽血、CT各种检查，诊断出是腰间盘突出压迫神经导致的，当时给我开了一些止疼药，不过吃了两天之后就不疼了，真是吓死了 😣。
后面五月份整天从早到晚的坐着赶实验，又开始屁股疼，也就是 “坐骨神经痛”，没办法，经常想提醒自己经常起来走走，但是忘了或者太懒了 🙂，最近这几天又疼了，真难受，必须嘚提醒自己经常站起来走走了，以及做一些拉伸活动 🏋️。感觉程序员这一行久坐是难免的，之前也收藏了一些其他人的腰椎、颈椎等康复指南，贴一下，以后跟着练习 💪：
RehabilitationGuide
AnsonZnl • Updated Apr 24, 2025 
还有一些关于健康的指南，也贴一下：
HumanSystemOptimization
zijie0 • Updated Dec 28, 2024
HowToLiveLonger
geekan • Updated Dec 28, 2024
拉伸动作： http://xhslink.com/48Tnjy
游戏 🎮
今年没怎么玩游戏，玩的也都是休闲种地、开放世界做任务或者卡牌游戏，最喜欢的是 Raft，通关了，从一个小木板到最后一艘战舰，满满的成就感~；星露谷物语就是和 npy 一起种种地，养老；文明6 玩的时候很上头，经典 “最后一回合”，不知不觉几小时过去了 😅。期待明年的游戏大作 “黑神话悟空” 🤩 🥳
探索 AI 🤩 
Stuff happening faster than you can read up on what stuff is happening.
今年可以说是 AI 大爆发的一年，从 2022 年的 11 月 30 日，ChatGPT 上线以来，我被 LLM 的能力深深的震撼，之后，全球在大模型的各大赛道上竞相发展，几乎每周都会有一个甚至多个新的产品发布。这一年，我在一些我常看的社交 app 上也关注了很多的 AI 领域博主，像 X、Youtube、tg 等，最主要的还是 X，很多产品的发布以及科学家、研究人员都在上面发布自己的产品或者研究。今年我感觉我闲暇的大部分时间都在刷推 😊
有人写了一篇文章，讲述了这一 AI 元年。也有人总结了自己认为的 top10 AI 工具，和我感觉也很像：
还有一些我用了之后感觉很不错的产品：
Perplexity AI （在实时信息搜索上，感觉比 GPT4 好用，而且随着版本的迭代更新，功能越来越强大）
devv.ai （新一代 AI 加持的程序员搜索引擎，也很好用，已加入常驻）
Copilot （GPT4-Turbo 加持的 Bing chat，最近感觉用起来还是不错的）
Dify （很强大的自定义 Agent）
Pika 1.0 （不错的视频生成产品）
SDXL （更强大的 model，重点是可以搭配 ComfyUI 以及各种 Lora 本地部署）
HeyGen （创建属于你自己的数字人）
OpenAI Translator（跨平台划词翻译，只不过我不舍得用 API key 来翻译 😂）
还有很多不错的 AI 产品，各个赛道竞争很激烈，对于我这种 AI 加速主义者很开心，有种日新月异的感觉，期待着更厉害的产品发布 🤩。我本来还期待圣诞节 OpenAI 会发布 GPT 4.5 作为圣诞礼物，结果没有 🫠，期待明年初的另一波高潮！
AI 对于我来说，是明显提高我的工作效率的，不管是 coding 上，还是学习研究上，我经常使用 AI 做的事：
编写代码，常用的是 ChatGPT4。并不是说它一定给我一次即可运行的代码，但是对于复杂的问题，它会给我一个灵感或者大致的方向，基于给出的答案，进一步修改，基本上几次对话，就可以解决我的问题。记得之前，我应该要 google 好久，不仅要找思路，还要翻阅 API 文档 🙃
绘画，常用的是 DALLE·3、SDXL + Lora。从 DALLE·3 发布之后，我能够很容易的绘画，只需简单的提示词，就可以得到我想要的画作，目前通过 DALLE·3 绘制的图像大概有 2000 张，之前是想存在 Notion 上的，但是加载好慢，就在本地使用 Obsidian 搭建了一个 Gallery，很巴适~。后面看大佬调的 Lora 模型眼红，就自己本地使用 ComfyUI 搭建一个画，感觉也不错，出图也挺快。当然最想用的还是 Midjourney，但是没 💵
调研和学习，常用的是 ChatGPT4、GPTs、Perplexity、devv。首先是很方便使用制作好的 Research 相关的 GPTs 来调研搜索相关 paper。对于不会的知识点，也可以很方便的使用以上工具来学习，只需来一场酣畅淋漓的对话，不懂就问，不用害羞问别人了 😀
翻译，常用的是宝玉老师的 GPTs。很好用的中英互译的 GPTs，翻译的很地道，就很 Nice!
写文档，常用的是 ChatGPT4，GPTs。收集材料 + 总结 + 写作，一条龙服务 🥰
在关注 AI 领域的这一年，自己也学了很多知识和技术，LLM 的训练、微调、对齐、推理部署，prompt 工程，stable diffusion 原理，MoE，多模态模型等，收藏夹里放了很多资料和博客等，github 的 star、Omnivore 的收藏夹里还有 X 的收藏夹里等等，还有很多 🤣，很多收藏了没时间看和研究，毕竟自己以后的研究领域重点不在这方面，但是就有这个收集癖好 🤗，还有浏览器的收藏夹里也一堆 tools 😬
Github Star 的 repo
同时这一年关注了很多博主和大佬，也能与他们互动提问，这里最先感谢的莫过于 C 大 💝 🌹，给了我很多帮助，也期待着大佬的新产品上线！！！
最后期待一波 2024 的 AI  浪潮，冲啊 💥💥💥
DALLE·3
DALLE·3
DALLE·3
展望 🌠
🎆
我的𝟚𝟘𝟚𝟜年一定很哇塞 🎆
大学生活就要结束了，明年的下半年就要踏入另一个旅程——研究生，还是很不舍的，希望大四的下学期能够充实快乐的度过，也希望有一场毕业旅行 🚙。下半年进入研究生生活，继续加油努力！2024 希望自己能多学一些技术，提升自己的编程能力，也想为开源社区做贡献 🤗。2024 更要注重自己的身体健康，保护自己的腰椎颈椎 🚴。最后也希望 2024 年和 npy 也能甜蜜幸福 🥰 💗
DALLE·3
 
 


保研旅途
Sun, 01 Oct 2023 00:00:00 GMT
BackGround
本科：中九
专业：网安
排名：10/202
CET-4: 550
CET-6: 501
竞赛：一个国三（水奖）、安恒杯三等奖（大佬带飞）
科研：一篇 CCS 第三作者在投，一篇 USENIX 第四作者在投 
两篇论文参与都是在大三下学期实习的过程中产出的，其实在此间感觉学到了很多东西，进步也很大。具体的工作也都是一点没有水，所以在后续面试的过程中，关于科研的问题回答的基本都是很满意的。
入营 & 优营情况
电科网安
面试流程：
考生3分钟自我介绍（可外语），介绍本人学习、科研、社会实践或实际工作表现等。仅限口述表达。
外语能力考查（不少于5分钟）。由面试专家组对考生的口语和听力进行测试。
专业知识考查。题库中抽取题目作答，重点考查程序设计、算法设计与分析、软件工程、计算机组成原理、数据库、计算机网络、编译原理、密码学（该科目限报考083900网络空间安全专业考生）等基础知识情况。
专业素质和能力考查。
英语考核，分值：100分。综合考核，分值：200分。
外语能力考察我当时问的没有生活问题，是两个关于科研经历的问题。专业知识抽题感觉这个就贼看运气，题目的难度是不一样的，大概流程就是，一个文件夹里面有很多题，你随机选一个文档，回答里面的题目，抽完就删掉了。由于我报名的是网安，打听了一番都说是密码学的，结果我抽中个数据结构设计的，时间紧迫，我也早忘了，所以 🐓🐓了，网安可能就是密码学和数据结构两门课。后面就是简历面。
后面双选我当时也没联系老师，就直接填了意向导师，有三个志愿，我都挑了带头人强导 😬，第一个志愿是zxs教授，然后也顺利的进了。当时其实也挺怕进不了的，没保底，不过发信息问了招生办，三个志愿都没匹配的话会重新发表再选。
信工所国重
国重这个当时面试刚开始有点尴尬，前一天问的几个同学，英语面试都是先自我介绍，然后我开始的时候就直接怼上刚背的自我介绍，当时我看有个老师一脸懵，看看其他老师看看我，还笑，我想我的口语这么难听嘛 🥲，结果老师说 stop，哦！原来开始不是自我介绍，是英文问答， 🌿，然后一连串问了我六七个英语问题，生活专业问题都有，给我干傻了，但是我就本着说错无所谓，说出来并尽量流畅最重要，也撑过去了。然后后面是漫长的拷打，从研究经历到项目，不过只要自己实打实做的，应该没啥问题，并没有涉及专业课。
面试之前联系了意向导师ck老师，虽然没面试，但统一面试之后，老师也给我发了组内的面试通知，时间挺紧张的，一天时间读一篇论文然后汇报，我其实还没有涉足那个领域，所以其实有点担心的，但是在ChatGPT的帮助下，入门一些知识还是挺快的。所以一天也基本完成了相关知识点概览以及论文的阅读、PPT的制作，然后就是十分钟的汇报，半小时的拷打，这个过程还是感觉挺🐓的，因为问了好多深刻性的见解问题，比如如何改进，有哪些问题等，因为初次涉猎这个领域，所以基本回答的很少。然后老师针对我的研究领域提问，提问的也是站在整个领域的高度的问题，当然，我并没有回答的很好，但是这也让我当时更觉得这个老师好厉害！面完之后，我也自己查阅了问题，不过确实应该值得思考~ 后面又有一次二十分钟左右的学长群面，主要是简历面，询问项目细节，回答整体不错，也受到了学长们的称赞，开心 🥰
信工所的最终优营名单公布的时间是比较晚的，大概面试完之后二十天左右才出来。这边是8月4号公布的名单，六个室总共招了350个人，还是比较多的，名单里还看见个 thu ✌
南软
我报的是学硕，当时没了解多少，发现学硕名额贼少 🥴，所以后面也是递补入营的。当时递补入营之后，发的通知是要联系老师，所以我也下午抓紧联系了一个老师，然后老师说，今年的机试难度大幅提高，当时就想这不更 🐔了，后面也就真寄了，虽然我当时已经做好准备了，但是还是有点难受，真菜 💩。
然后笔试有计网、OS、数据库还有软工，开卷，我特地买了一本南大的软件工程书，然后背了四本书过去，像个大冤种。考试的时候就能翻到一题能看书的，其他基本都是扩展题目类似的，也有可能我太菜，我记得我做着做着就笑起来了 😅。四科每科25分，最后没做出来几题，为了交卷不尴尬，只能硬zou一点~
第二天就是面试，面试首先是给一段英文，朗读然后翻译为中文，我磕磕绊绊的翻译一半，感觉挺难的。然后是简历面试，没有专业课啥的了，我面试的老师当时给我的感觉都是挺好的，很和蔼。
面完试之后，因为感觉没啥希望了，想着第一次来南京，干脆下午和晚上暴走旅行：先锋书店 → 古鸡鸣寺 → 玄武湖 → 秦淮河，感觉很不错！
8月1号晚上九点半左右，发邮件通知的是良好，我还以为啥都没呢哈哈哈，但是好像听说入营最低是良好，不知道真假，maybe，因为我感觉我考的贼烂💩,  Alright~
Nan Jing journey
中科大网安
当时参加完南软下午直接去中科大了，不得不说，中科大的夏令营简直吹爆！！！太巴适了，首先是包吃住，然后送一对礼品，给的校园卡里面有100 💵
大礼包
第二天的开营仪式直接给我惊呆了好吧，早上坐大巴到体育馆，一进去，哇塞，这就是有钱的科大！仪式感、诚意慢慢！
学校的食堂也很好吃 😋😋😋，而且高新校区的建筑以及图书馆真的好壮观，新校区就是NICE！环境只能说超级好，处处科技感~
前两天都在参观校区、实验室等，真的很不错捏~  然后我之前也尝试联系了zwm老师，但是已读不回，然而面试前一天通知晚上预面试。晚上参加的时候，大概有12个人，大佬很多，好几个四篇paper，也有一二作的佬。当时感觉应该没什么希望了，但是晚上回去之后通知拿到了专硕的offer，所以还是很开心的~ 然后第二天的面试，有两次，也就是每个人都要参加两次面试，我都是倒数第二个，还是很折磨人的，每个人20min。刚开始是英文自我介绍、然后问答，有专业课和简历项目，但是专业课看老师以及你的成绩单，当时我最高的是计网，所以提问的是计网，也都答上来了~
高新校区
 
上午的面试还不错，下午的就有点感觉离谱了，几乎没问专业课和研究经历，问了我的爱好摄影，为啥手机的光圈不如单反的，底层原理是什么？ 🤡 wtf? 我也就接连 ”不好意思 “😃 
第二天早上也是收到优营通知了，面试完那天晚上也一直在考虑是信工所直博还是科大专硕，问了群友、家人、npy等，大概的意向是去北京，因为两边都拿到了心仪的强导名额，所以只需要考虑一些其他因素了（like 以后发展、异地恋、机遇等吧~)，所以后面也给当时分配的导师说了，把offer放了。
清华网研院工程博
本来夏令营没入营之后，都不打算考虑贵清华了，之后实习的导师让我报名工程硕博试试，然后让导师给我写了推荐信，很快的就报名完了工程博。但是从8月15左右报名完，到清华预推免开始面试，我这边还是没结果，当时我还在军训，想着应该也是没了，出于担心还是问了一下导师，导师说工程博的面试还没开始🥲🥲🥲。最后9月20日应该是给所有报名的发了一个问卷调查，其中也就涉及意向企业的志愿。9月21日发了审核通过的通知，然后通知9月24日线下面试，只能说很极限。
然后这个工程硕博的考核也是比较震撼的：10个面试官（有企业hr）面试半小时，先是个人陈述十分钟，然后拷打个人陈述的内容，没有专业课啥的。我在等待的过程中，都听见面试官说“要求半小时考核，剩下时间干什么呢🤣”。
面试的过程中，企业 hr 拷打的最多，hr 考察的比较多的就是你的项目，你在其中的贡献以及工作占比等，我感觉我吃了项目少的亏，然后 hr 也会问一些企业面试中的一些智力测试题，成功测试出我是个菜🐶，我还记得题目：“给你两根绳子，一根燃烧完需要60分钟，请你准确测量出来45分钟”，不好意思，我太菜，有限的思考时间内我没想出来😭😭😭。
哦！还有一个比较离谱的是去之前，好多人都劝退，因为这个工程硕博才是第二年，培养方案啥的都不清楚，有说“打黑工”、“不好毕业”、“工程博慎重考虑”、”我走了，不面试了”，结果最后拿到offer都不放弃，我乐了，真会放烟雾弹💣
之后，骑着车逛了两小时的清大，真的大，来张图，真不错🤩，更多照片在这里：
最后第二天晚上十二点有人收到了录取通知，很遗憾没拿到，哭哭，之后有说候补的，但是没有人鸽网研院，哎，就这样吧，至少去过，很不错！
去向
最终也算是去了自己的一个意向学校和导师组，在这里也十分感谢实习期间各位学长和老师带给我的帮助、丰富的科研经历，同时也感谢一路上相伴的家人、朋友和老师 🥰🥰🥰！
中间其实还有一段比较魔幻的过程，从上面的录取通知可以看到从直博改为了学硕，其实在之前问录取意向的时候是选的学硕，因为对自己的能力还不是有很好的认知，所以想要稳一些，但是9.28发的邮件是直博，联系老师也未及时回复，以为最后确定的也是直博，心想直博也就直博吧。但是9.30凌晨导师问我报的是不是学硕，emmmm，原来是之前确定的就是学硕，只不过中间和教务处沟通出了差错。导师也建议我读学硕，因为我这样不坚定读博的还是别轻易尝试，给自己一个硕士缓冲期，评估一下自己！所以之后又联系了招生办改志愿。
总结
前前后后大概三个月，也对应三个阶段，一路上起起伏伏，也庆幸自己没有放弃摆烂，一直坚持着。整体的每场面试也都尽力发挥了，将自己的所掌握的科研项目以及专业知识都尽可能的展现出来。最后希望自己之后的研究生阶段科研顺利，未来的路还很长，需继续努力，加油！
轻舟已过万重山