论文：How AI Impacts Skill Formation
arXiv：2601.20245
作者：Judy Hanwen Shen、Alex Tamkin（Anthropic）
主题：AI 辅助、技能形成（Skill Formation）、认知卸载（Cognitive Offloading）
中文翻译：AI 如何影响技能形成

一句话总结（TL;DR）

52 名开发者参与的 RCT(Randomized Controlled Trial 随机对照实验)：开发者在有无AI辅助的情况下学习掌握一个新的python异步编程库。研究发现，使用AI会损害开发者对概念的理解、代码阅读和调试能力，且平均来看并未带来显著的效率提升。那些将编码任务完全交给AI的参与者虽然工作效率有所提高，但代价是未能真正学会这个库。

1. 直觉开场：学开车

如果把学一门新技术比作学开车，那 AI 辅助就像一个随叫随到的司机——你一挥手，他就帮你把整段路开完了。任务完成了？完成了。你会开车了吗？大概率没有~

Anthropic 的这篇研究报告就是在严肃地回答这个问题：让 AI 帮着写代码，你到底算学会了吗？

图1：核心结果。左：AI 组技能全面下降；右：6 种 AI 交互模式，其中 3 种能保住学习效果。

2. 背景：AI 辅助编码

AI 编码辅助已经有一堆研究报告发布了有力的数据证明了：

有一个不那么惊人的一致发现是：经验越少的人，从 AI 获得的加速越多。

但不知道你有没有发现这里有个悖论：最需要学习的新手恰恰最容易把活儿全甩给 AI。生产力看起来提升了，但你习得的技能呢？

这篇paper就想衡量一下 使用 AI 的过程本身是否阻碍了技能习得。

图2：有 AI 辅助时，新手可能跳过了”边做边学”的过程，直接到达”任务完成”——但技能没跟上。

研究者提出的两个直接的问题：

• Q1：学新技能时，AI 能提升生产力吗？
• Q2：AI 辅助会削弱新技能的形成吗？

论文：Learning to Reason in 13 Parameters
arXiv：2602.04118
主题：参数高效微调（PEFT）与强化学习（RL）

中文翻译版：2602.04118
翻译SKILL: yrom/arxiv-paper-translator

一句话总结（TL;DR）

TinyLoRA 用 LoRA-XS + 随机投影 + 权重绑定把可训练参数压到 13 个，配合 GRPO 在 GSM8K 评测集上跑分从 76% 提到 91%。关键发现：强化学习（RL） 的稀疏可验证信号比监督微调（SFT）的逐 Token 信号更适合采用极低参数的设置。

1. 直觉开场：13 个参数？

如果把全量微调看成”重装整台电脑”，那 LoRA 像”换一条内存条”，TinyLoRA 则更像”在 BIOS 里拨了 13 个开关”——改动极小，但让模型更愿意”想一想、写长一点”，推理准确率就上来了。

图1：GSM8K 主结果（GRPO）。13 参数即可逼近全量微调性能，虚线为未训练与全量微调基线。

图2：SFT 在低参数区间效果明显弱于 RL，达到相近性能需要更大的更新规模。

之前我用过 PDFMathTranslate 翻译 PDF 论文，效果还行。但他有个问题：只能翻译 PDF 文件、只能按页翻译，而且很慢~。其实有时候我只需要翻译部分章节。

无意间，我看到 arXiv 其实提供了PDF的 LaTeX 源码。

下载一个来解压看，是作者的原始LaTeX。我就想，能不能用Claude Code（或者Opencode）这种AI助手直接翻译 LaTeX 源码？然后编译出中文 PDF 文件！

是的，我入了GLM 的Coding Plan 的坑，实际体验下来，GLM 4.7 写代码只能说凑合。花钱雇了一个实习生，虽然智力水平够不上博士，平常放着不用就浑身难受，我试了让他翻译翻译论文还是可以的~（虽然，需要花点时间调教

这就是我搞这个项目最初的想法： arxiv-paper-translator

Introduction

When developing graphics applications such as OpenGL or Vulkan apps, we typically using hardware acceleration need a graphics card (Graphics Processing Unit, aka. GPU) to render graphics for better performance and visual quality.

However, in some cases, we may not have access to a GPU, such as headless cloud server or in a CI/CD environment.

In this blog post, I will show you how to develop OpenGL applications inside a Linux server environment which is running in a GPU-less Docker container (in my case, a MacBook Pro with Apple Silicon M3).

Github repo yrom/docker-egl-opengl

Overview

On a headless Linux server without a GPU, we can use the software implementation of OpenGL provided by Mesa.

On Linux, EGL is commonly used as the integration layer between OpenGL and the native windowing system, such as X window system and Wayland.

EGL also supports off-screen rendering by creating an headless surface called Pbuffer (pixel buffer), which enables rendering without any real display or window.

本文为作者记录学习和微调 IndexTTS 以生成带有可控情绪的语音音频的过程。

微调实验结果

以下使用 NVIDIA GeForce RTX 4070 大约半小时微调后的 IndexTTS 所生成的中英文语音音频样例：

完整的实验 Jupyter Notebook 见仓库 yrom/finetune-index-tts

模型结构与微调思路

IndexTTS 基于 Tortoise TTS，采用了多个模块协同，其主要流程如下：

要达到微调目标，主要涉及两个核心部分：

• BPE 分词器: 基于 sentencepiece，将文本和新增的情绪标签（如 <GIGGLES>）编码为词表序列ID。
• GPT2 自回归模块：通过微调学习根据目标情绪标签ID生成合适的音频 latent 表示。

本文记录一下将PyTorch模型适配到MLX的过程。

什么是MLX？

MLX is an array framework for machine learning on Apple silicon, brought to you by Apple machine learning research.
https://github.com/ml-explore/mlx/blob/main/README.md

MLX 是适应于苹果M系列芯片(Apple Silicon)的机器学习框架。

mlx的array设计更加接近于numpy^[1]，而不是PyTorch的tensor，即只存有结构信息（如形状、数据类型等），没有其它与深度学习训练相关的属性（如梯度）。与numpy和torch不同的是，mlx 的array是 Unified Memory 可以在CPU和GPU之间共享，这也是mlx被单独开发而非拓展pytorch的 mps backend的理由^[2]。

模型转换实践

BigVGAN PyTorch -> mlx-BigVGAN

基本的映射

问题

在特效渲染的项目中，通常会有很多的实现不同功能的 Shader，比如：高斯模糊、液化、色彩校准、LUT等等。在使用特效时会遇到一些可能是 Shader 导致的性能问题，比如：渲染速度慢、实时渲染卡顿等等。这时候，就需要一个能够快速找到有性能问题的 Shader的方法，即本文。

定位

工欲善其事，必先利其器。

首先，需要一个能够快速评估性能的工具（详见之前的汇总Graphics API Debuggers），挑一个适合的测试真机+测试工具 （个人使用的是 Arm Performance Studio for Mobile 。

推荐观测的指标：

• FPS （对于实时渲染的项目）
• GPU 使用率
• CPU 使用率
• 内存使用量

其次，针使用场景创建一系列基准测试用例，用于比较不同Shader实现的性能，找出瓶颈所在。

对于定位 Shader 的性能问题，推荐使用以下方法：

1. 整体，用一个简单的 Shader （或什么也不做的 NULL-Shader） 替换掉所有的 Shader，观察性能变化。如果性能有明显提升，说明瓶颈问题大概率在 Shader 上。
2. 二分法定位，将 Shader 分为 AB两部分，分别测量 A + 原始Shader 和 原始Shader + B，进行性能对比，继续二分，重复对比，直到找出性能问题的 Shader。

什么是 Uniform Buffer Object？

见WIKI： https://www.khronos.org/opengl/wiki/Uniform_Buffer_Object

及 learnopengl 中的示例：https://learnopengl.com/Advanced-OpenGL/Advanced-GLSL#:~:text=the%20geometry%20shader.-,Uniform%20buffer%20objects,-We%27ve%20been%20using

在项目中使用 UBO 时，遇到了一些坑，这里记录一下。

坑1：UBO 的对齐问题

在使用 UBO 时，需要注意 UBO 的对齐问题。为了代码的可移植性，一般会直接使用 std140 来定义 UBO 的内存布局，如：

1
2
3
4
5
6
7

layout (std140) uniform ExampleBlock
{
    float value;
    vec3  vector;
    mat4  matrix;
    bool  boolean;
};

std140 的布局规则 理解了是一回事，但是在C++中写一个 UBO 对应的struct 的时候，还是会出现对齐问题。比如C++ 中用下面这个 struct 来对应上面的 ExampleBlock：

1
2
3
4
5
6

struct ExampleBlock {
    float value;
    glm::vec3 vector;
    glm::mat4 matrix;
    bool boolean;
};

这个结构体在C++编译器的眼里是按C++ 自己的内存布局规则来的，这时候我们需要手动按std140对齐：

1
2
3
4
5
6

struct alignas(16) ExampleBlock {
    float value;
    glm::vec4 vector;
    glm::mat4 matrix;
    alignas(4) bool boolean;
};

注意上面例子中的 struct 中的 bool 类型，需要对齐到 4字节。

但是，如果你这么写了，仍然可能会遇到一个问题，C++ 代码中明明设置的是 false ，但是程序执行后，在 Shader Program 中读取到的却是 true。(ﾟДﾟ≡ﾟдﾟ)!?

苹果系统的链接器/usr/lib/dyld 提供了一个叫dyld-interposing的功能（从 Mac OS X 10.4 开始），可以在程序启动时替换掉某个函数的实现。这个功能可以用来实现代码注入（详见：《Mac OS X Internals: A Systems Approach》- Amit Singh - 第二章 2.6.3.4 dyld interposing）

举个栗子

比如，我们可以在程序运行时，替换掉malloc函数的实现：

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

// malloc_trace.c
#include <stdio.h>
#include <stdlib.h>

#include <mach-o/dyld-interposing.h>
#include <memory.h> // memset
#include <malloc/malloc.h> // malloc_printf

void *trace_malloc(size_t size) {
  char *p = malloc(size);
  // fills with '#'
  memset(p, '#', size);
  malloc_printf("malloc(%u) = %p\n", size, p);
  return (void *)p;
}

DYLD_INTERPOSE(trace_malloc, malloc);

1
2
3
4
5
6
7
8
9

// test.c
#include <stdio.h>
#include <stdlib.h>
int main() {
    char *p = (char*)malloc(10);
    printf("malloc return %p, %s\n", p, p);
    free(p);
    return 0;
}

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

$ cc -dynamiclib -o libmalloctrace.dylib malloc_trace.c -install_name libmalloctrace.dylib
$ cc -o test test.c
$ DYLD_INSERT_LIBRARIES=libmalloctrace.dylib ./test

test(46555,0x11bdd3600) malloc: malloc(1536) = 0x7febbc808200
test(46555,0x11bdd3600) malloc: malloc(32) = 0x7febbc704130
test(46555,0x11bdd3600) malloc: malloc(32) = 0x7febbc704170
test(46555,0x11bdd3600) malloc: malloc(20) = 0x7febbc705550
test(46555,0x11bdd3600) malloc: malloc(422) = 0x7febbc7055d0
test(46555,0x11bdd3600) malloc: malloc(50) = 0x7febbc7057e0
test(46555,0x11bdd3600) malloc: malloc(16) = 0x7febbc705880
test(46555,0x11bdd3600) malloc: malloc(52) = 0x7febbc705900
test(46555,0x11bdd3600) malloc: malloc(12) = 0x7febbc7059b0
test(46555,0x11bdd3600) malloc: malloc(10) = 0x7febbc705b00
test(46555,0x11bdd3600) malloc: malloc(4096) = 0x7febbc808800
malloc return 0x7febbc705b00, ##########

• Microsoft GPUView
• AMD Radeon GPU Developer Tools Suite (AMD GPUs)
• NVIDIA NSight Graphics (NVIDIA GPUs)
• Intel Graphics Performance Analyser (Intel GPUs)
• Qualcom Snapdragon Profiler
• Arm Mobile Studio (Mali GPUs)(Android graphics tracing with Graphics Analyzer)
• RenderDoc
• Xcode Graphics Debugger (on mac, for Metal & OpenGLES)
• OpenGL Profiler (in Additional Tools for Xcode)
• Spector.js (WebGL)
• 华为图形性能调优 Huawei Graphics Profiler (Huawei phones or tablets)
• PowerVR DevTools - PVRTune (PowerVR GPUs)
• Android GPU Inspector(a few Android devices)