Yrom's

Advisor Strategy 里最难实现的是弱模型的「自知之明」

2026-04-21T15:10:00.000Z

4 月 9 号，Anthropic 发了个特别的功能 Advisor Strategy。

让学生姜维 Sonnet 或 Haiku 先跑任务，遇到搞不定的再请诸葛亮 Opus 出山。

官方跑分数据很亮眼。Sonnet + Opus advisor 在 SWE-bench Multilingual 上比 Sonnet 单独跑高了 2.7pp，成本反而降了 11.9%。Haiku + Opus 更夸张，BrowseComp 从 19.7% 飙到 41.2%，成本比 Sonnet 单独跑还低 85%。

激活的方式很简单：

response = client.messages.create(
    model="claude-sonnet-4-6",  # executor
    tools=[
        {
            "type": "advisor_20260301",
            "name": "advisor",
            "model": "claude-opus-4-6",
            "max_uses": 3,
        },
        # ... your other tools
    ],
    messages=[...]
)

# Advisor tokens reported separately
# in the usage block.

你往 Claude 模型 API 的 tools 数组里加一个 advisor_20260301，完事。整个过程在单次 API 调用内完成，不需要额外的编排层，不需要你自己管理上下文传递。

听起来很美对吧？

但仔细想想，似乎有个被忽略的关键问题：Sonnet 怎么知道什么时候该请教 Opus？

毕竟，熊将之所以熊，就是熊在盲目做决策上，如果有「自知之明」肯请教军师，那还能熊哪去？

反套路的编排模式

Multi-Agent 编排大家天然都是用强的lead弱模型：强模型（Opus）当指挥官，做plan、拆任务，分给小模型（Sonnet/Haiku）去执行。

但这个 Advisor Strategy 把逻辑翻转了：轮到弱模型当carry全程输出，强模型只当辅助。

Sonnet 自己决定调工具、写代码、迭代循环，95% 的工作量都在 Sonnet 完成。只有当 Sonnet 遇到它自己判断搞不定的决策时，才在服务端内部触发一次 Opus 推理，拿到 400-700 tokens 的建议，然后继续。

但这里有个隐含假设：

Sonnet 能准确判断”这个任务我搞不定”。

但这个判断题本身就是个很难的题目，好比你判断自己不知道什么，这比”知道自己知道”难多了。这就是所谓的 meta-cognition（元认知）——一个模型对自身能力边界的感知。

提示词能被复制，你的产品不能

2026-04-20T14:10:00.000Z

如果你正在做 Agent 产品，可能也面临一个问题：

我跟 LLM 搏斗了好几周甚至几个月，Prompt 调了十几版，Skill 也精心打磨了好几轮。要不要想办法防用户逆向提取提示词，保护 AI Agent 产品“知识产权”？

这个问题乍一听既合理也紧迫。

好比传统软件/手机应用，源代码绝对是核心资产，有一系列反调试、加混淆、加壳等保护防逆向的工具链。

那 AI 时代，Agent “源代码”似乎就是Prompt 和 Skill 那堆markdown 文本，毕竟市面上没几个能自己炼模型的对吧，大家都是LLM API Wrapper。这么类比，Prompt 和 Skill 是不是也该保护起来？

我研究了一圈，结论是：这个问题本身就是站不住脚的。

Why？技术上防不住

GitHub 上有仓库专门收集各大 AI 产品的泄露系统提示词。asgeirtj/system_prompts_leaks 有 38K+ stars，20.2K stars的elder-plinius/CL4R1T4S，136K+ stars x1xhlol/system-prompts-and-models-of-ai-tools 。这些仓库覆盖了 ChatGPT、Claude、Gemini、Grok 等一众在线的、本地的 AI 产品，有些连 JSON tool schema 和版本历史都被扒出来了。

Patrick Koss 看完这些泄露的提示词后总结：各家产品的系统提示词结构惊人地相似，都是”角色声明 + 工具列表 + 安全规则 + 输出格式”这个套路（Patrick Koss, “Stolen Blueprints: What We Learned From Leaked AI System Prompts”）。

OWASP 专门出了个 Cheat Sheet 教你怎么在 prompt 里写”不要透露你的指令”，然后自己在同一份文档里承认：

“Research shows that existing defensive approaches have significant limitations against persistent attackers due to power-law scaling behavior…”

是的，从根本上就防不住。

AI 时代，学得慢，就是快？

2026-04-01T15:00:00.000Z

今天看到雷叔写故事公众号文章引用了一个颇具“振聋发聩”的说法：

“AI 时代，只要你学得够慢，你就不用学了。”

屠龙术

确实，AI 发展太快了，“AI一日，世间三年”。各种名词、热点，层出不穷。

举个例子：XXX Engineering。从一开始 Prompt Engineering，到 Context Engineering，现在又 Harness Engineering。

我曾经还研究过：“Vibe Engineering”，“Memory Engineering”。

这种感觉像在追赶潮流，埋头苦练，回头看发现原来学的是屠龙术。

剑法精妙，步法飘逸，炉火纯青。

问题只有一个：

龙不存在。

当 Token 成为新生产资料：程序员的价值正在归零？

2026-03-23T14:00:00.000Z

最近我常在想一个 Live or die 的问题：作为程序员，我们赖以生存的本钱到底是什么？ 换句话说，老板凭什么为此而掏腰包？

是能写那一大段自诩优雅而简洁的 Effective Modern C++ 代码吗？还是靠踩坑磨炼出来的对复杂系统的工程直觉？

之前，我觉得程序员这活是存在入行门槛的，好歹是个脑力劳动，至少智力水平得在线，那么撬动老板付钱的本质是”智力杠杆”，越聪明的人能力天花板越高舞台越大自然也就越贵。

但当我看着 Claude Code 分分钟重构完原本我打算花一周时间重构的跨平台渲染器并跑起来时，我觉得这杠杆不存在了，连支点都不复存在了。

智力通胀

过去，智力水平可以看作是一种壁垒，绝顶聪明的人万里挑一。但在 AI 浪潮下智力正在发生严重的通货膨胀。智力变成了水电煤一样的基础商品，只要肯付钱买， Token 就能无限供应。我们这些”脑力劳动者”的底层价值正在迅速瓦解。

我逐渐意识到，Token 根本不是什么 LLM 的输出单位。它是全新的生产资料，是 AI 时代的”石油”。谁掌握了它，谁就拥有了新质生产力。

Tokenmaxxing：硅谷的新风尚

Tokenmaxxing 游戏：把 AI 额度用到极限。图来自digit.in

你也许刷到过，硅谷的科技公司正掀起一场刷 Token 的比赛，叫 Tokenmaxxing。

在 Meta 和 OpenAI 的内部，现在赫然矗立着「Token 消耗排行榜」，不比做出什么东西，纯粹看烧了多少 Token——比谁在同一时间周期内更会烧 Token！阿里和腾讯也宣称为员工提供无限量免费 Token 福利，鼓励使用 AI 工具工作。。。

没有银弹：Agentic Coding 时代的软件工程效率边界

2026-03-16T15:10:00.000Z

Fred Brooks 在 1986 年关于《没有银弹》的预言，在 2026 年 AI Coding 火热的当下依然成立吗？

1. Fred Brooks 的框架：本质 vs 偶然

1986 年，《人月神话》的作者 Fred Brooks 发表了一篇经典论文 《No Silver Bullet - Essence and Accidents of Software Engineering》 ，他借用亚里士多德哲学概念把当时的软件工程的面临的困难分成了两类：

类型	定义	能否消除
Essence（本质）	软件固有的内在的、不可简化的属性，完全靠人抽象的逻辑思维活动进行概念构建、系统设计	❌ 无法消除
Accidents（偶然）	抽象概念的表达（编码）过程中，工具、实践、环境带来的伴生问题，比如受制于硬件、编程语言特性、研发团队的协作等	✅ 可以改进

1.1 四大本质困难

Brooks 进一步将本质困难分为了四大类：

Complexity（复杂性）：软件系统的构造之复杂且增长非线性，导致系统的理解、设计、实现、维护等活动变得困难。
Conformity（一致性）：软件的复杂性很多时候是人为强加的，它必须适应各种已经存在的不同的人不同时间为不同原因建立的接口、系统、合规性约束等，没有“放之四海皆准”的解决方案。
Changeability（易变性）：软件纯粹是“思想的产物”，逻辑上极易被修改，永远处于“拥抱变化”的巨大压力状态，用户不断有新需求，而软件也不断适应新硬件环境，而修改成本随系统规模增长
Invisibility（不可见性）：软件无法在物理空间直接可视化她的逻辑实体，摸不到它的”几何形状”，虽然可以画流程图、架构图来描述系统的控制流、数据流等，但这些都是”静态”的描述，无法直观软件的“动态”行为，阻碍了设计者之间的沟通。

1.2 Brooks 悲观的预言：本质困难无法消除

“There is no single development, in either technology or management technique, which by itself promises even one order-of-magnitude improvement within a decade in productivity, in reliability, in simplicity.”

没有任何单一的技术或管理方法，能在十年内带来哪怕一个数量级（10x）的效率提升。

如今，40 年过去了，软件工程的世界天翻地覆， AI Coding 火热的当下，这个论断还成立吗？

软件开发生命周期从传统到AI迁移图。图来自《2026 Agentic Coding 趋势报告》by Anthropic

论文分享：挂羊头卖狗肉！中转站 API 的模型欺诈行为研究

2026-03-06T11:00:00.000Z

图来自原文，Comic for the production, transaction, use, and audit of shadow APIs

三句话总结 (TL;DR)

想要用上GPT、Gemini、Claude 这类前沿LLM，官方API往往价格不菲、支付门槛高、还有地域限制。CISPA 信息安全中心的研究者对官方LLM API和对应的影子API进行了系统性审计，发现 45.83% 的Endpoint无法通过模型指纹验证，有些甚至还是开源模型平替或者降智版，与官方API的跑分性能差异最高达 47.21%。

CISPA Helmholtz Center for Information Security 是德国顶尖的网络安全研究机构

你以为掏钱买的 GPT-5，但实际中转站可能给你用的是 GLM-4-9B！

更令人瞠目的是研究者发现有多个影子API被上百篇学术论文使用过，其中最火的一个（论文作者没提是哪篇），截至2025年12月6日，引用量高达近6千次，在GitHub上收获了58k stars，这意味着部分学术结论建立在错误的基础上！严重损害了科学研究的可重复性和有效性。

Most of these papers have accepted by top venues, such as ACL, CVPR, and ICLR…
These deceptive practices critically undermine the reproducibility and validity of scientific research…

Pass^k：评估智能体可靠性的建议指标

2026-03-03T10:30:00.000Z

Google DeepMind 的研究员 Philipp Schmid 指出，业界常用的评估指标 Pass@k 具有一定的迷惑性和误导性，建议使用Pass^k 来评估智能体的可靠性。

图来自Anthropic 的技术博客 Demystifying evals for AI agents

论文分享：攻破你的 OpenClaw 🦞机器人，最好用的武器是 PUA

2026-03-03T04:00:00.000Z

30+ 位研究者给 AI 智能体配了邮箱、Discord 和 Shell 权限，然后让 20 人去攻破它们。技术攻击全被防住了，社会工程攻击全军覆没。

论文分享：AI 如何影响技能形成

2026-02-26T09:20:00.000Z

Anthropic 的随机对照试验证明，用 AI 辅助学新库会让测验分数掉 17%，但「只问概念不要代码」的交互模式能保住学习效果

【AI】论文精读：TinyLoRA —— 用 13 个参数让模型学会推理

2026-02-10T12:00:00.000Z

注意

这是一篇让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，达到相近性能需要更大的更新规模。

我做了个 Skill，把论文翻译变成了一行指令

2026-02-05T13:00:00.000Z

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

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

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

燃烧吧，GLM 4.7.

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

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

Develop OpenGL Apps In A Docker Container Without GPU

2025-07-27T13:00:00.000Z

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.

About Mesa

Mesa is an open-source implementation of OpenGL that provides software rasterizers inside its Gallium driver, such as softpipe and LLVMpipe, for CPU-based rendering.
The Gallium LLVMpipe driver uses LLVM to do runtime code generation with LLVM IR, is multithreaded and offers better performance than softpipe.
Read more about Mesa's llvmpipe.

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.

RTT (Render To Texture) with EGL + OpenGL
Image made by author

微调IndexTTS以输出可控情绪的语言音频

2025-06-15T12:12:20.000Z

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

About IndexTTS

IndexTTS 是B站 Index 团队开源的一款语音合成模型TTS，支持中文、英文的零样本语音克隆。特色是参数量小还可以用拼音声调来控制中文多音字发音。其基本结构基于 Tortoise TTS 和 XTTS，声码器（Vocoder）则采用 BigVGAN。虽然官方报告中提到了支持合成可控情绪音频，但实际目前并未开放相关能力的代码和使用方式 issues#13。

微调实验结果

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

参考音频	合成的语音试听
Elise-1	Hey there my name is Elise, <GIGGLES> and I’m a speech generation model that can sound like a person.
	你好 , 我是 ELISE, 一个语音生成模型 , <GIGGLES> 我的声音听起来跟真人一样 .
Female-1	Seriously? <giggles> That’s the cutest thing I’ve ever heard!
	真的吗？ <giggles> 这也太可爱了吧！
Male-1	Wha—? Cute? <giggles> You think I’m cute?! Well, uh, thanks, I guess?
	哎呀! 忘了他还在那等我们呢！ <giggles> 我们两个动作得快点了！

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

模型结构与微调思路

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

图为作者绘制

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

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

将PyTorch模型适配到MLX

2025-05-14T06:12:10.000Z

本文记录一下将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]。

array与tensor的区别

np.array和torch.tensor的区别可以阅读What is a Tensor in Machine Learning?

模型转换实践

BigVGAN PyTorch -> mlx-BigVGAN

基本的映射

	torch	mlx
DataTypes	Data types	Data Types
NN	`torch.nn.*`	`mlx.nn.*`
Parameters/Weight/Buffer	`torch.Tensor`	`mlx.core.array`
ModuleList	`torch.nn.ModuleList`	`list`
ModuleDict	`torch.nn.ModuleDict`	`dict`
Transform	`torch.fft`	`mlx.core.fft`

如何快速定位有性能问题的 Shader 和一些简单有效的优化方法

2024-04-08T04:03:43.000Z

问题

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

定位

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

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

推荐观测的指标：

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

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

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

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

OpenGL Uniform Buffer Object 的坑

2024-02-24T05:10:00.000Z

什么是 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 的内存布局，如：

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

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

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

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

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

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

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

通过 dyld-interposing 实现C/C++代码注入

2023-10-19T06:22:54.000Z

苹果系统的链接器/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函数的实现：

malloc_trace.c

// 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);

test.c

// 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;
}

$ 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, ##########

Graphics API Debuggers

2023-09-27T09:50:57.000Z

Learning Render Graph

2023-08-13T15:27:37.000Z

什么是 Render Graph？
Render Graph 或者说 Frame graph 是对复杂渲染管线的一个高度抽象，以图（Graph）的形式呈现渲染过程中的各个步骤，不同的渲染任务之间的依赖关系，以及它们对资源（如纹理、缓冲区等）的使用。

Frame graphs are a design pattern for handling complex rendering pipelines, which are currently used in industry. Their usage is motivated by handling barriers, queue synchronization and memory aliasing in the background by abstracting the rendering pipeline of a frame on a higher level.
—— https://github.com/gfx-rs/gfx/wiki/Frame-graphs

解决什么问题？
在传统的渲染管线中，渲染过程通常被划分为多个阶段，如下图所示：

这些阶段之间存在着输入和输出的依赖关系，其中一个阶段的输出作为下一个阶段的输入。

Render Graph 的主要思想是将渲染过程表示为一个有向无环图（DAG），其中节点表示渲染通道（Render pass），边表示依赖关系。每个渲染通道执行特定的渲染操作，可具有输入和输出资源，例如Texture、Frame Buffer和执行的 Shader/Program。例如，假设节点 A 的输出Texture是节点 B 的输入Texture，那么节点 B 就依赖于节点 A。

通过概括渲染流程中的依赖关系，确保渲染阶段按正确的顺序执行，并且在需要时可基于一定的同步机制（Fence、Semaphore、Resource barriers）尽可能地并行执行渲染通道。

Render Graph 的目标是为了解决大型渲染引擎里复杂渲染管线中的一些问题。如资源生命周期管理、渲染效率、渲染过程的可视化调试等等。

Render Graph 不仅在游戏引擎中广泛应用：

Unity 3D, The render graph system

Unreal Engine, Render Dependency Graph

Cocos Creator, 面向数据的可定制渲染管线

它的理念也在现代图形 API 中可窥一斑，如Vulkan 的 Render Pass、DirectX 12 的 Command List、Metal 的 Render Pass等。
从Android 原生库 (.so) 中里挖掘一些有用的信息

2023-07-25T09:20:18.000Z

当一个 Android APP 需要集成别的地方来的原生库（.so）时，你可能也会跟我一样会有那么几点疑惑：
- 这个 so 用的什么 NDK 版本编译的？会不会跟项目里其它的so 冲突，尤其项目里使用共享 C++ STL的情况下 ANDROID_STL=c++_shared，一个应用不能使用多个 C++ 运行时
- 这个 so 目标 Android API 等级是多少？会不会大于项目的minSdkVersion？
- 这个 so 依赖（链接）其它哪些 so？这些 so 有没有都放进项目里？
- 这个 so 有没有除了用文件哈希之外唯一编号，用来标识崩溃堆栈等？
ps. 本文假定读者有一定 Android Native 开发经验，且理解一些基本的概念。

查看 so 的 NDK 版本信息
通过 readelf 工具查看 Android NDK 编译出来的 so 的 Section headers 里有什么 Android 特有的玩意。

ps. 可以用 ndk-which 找到 NDK 中预编译好的 readelf：
1
2
$ $ANDROID_NDK_HOME/ndk-which --abi arm64-v8a readelf
/~/ndk/21.4.7075529/prebuilt/darwin-x86_64/bin/../../../toolchains/llvm/prebuilt/darwin-x86_64/bin/aarch64-linux-android-readelf
定义一个名为 readelf 的 alias 方便在 Terminal 中调用 aarch64-linux-android-readelf
1
2
3
4
5
$ alias readelf=`$ANDROID_NDK_HOME/ndk-which --abi arm64-v8a readelf`
$ readelf -v
GNU readelf (GNU Binutils) 2.27.0.20170315
Copyright (C) 2016 Free Software Foundation, Inc.
...
以 NDK 中带的 libc++_shared.so 为例，在我本机上路径是$ANDROID_NDK_HOME/toolchains/llvm/prebuilt/darwin-x86_64/sysroot/usr/lib/aarch64-linux-android/libc++_shared.so：
1
$ readelf -WS $ANDROID_NDK_HOME/toolchains/llvm/prebuilt/darwin-x86_64/sysroot/usr/lib/aarch64-linux-android/libc++_shared.so

Yrom's

Advisor Strategy 里最难实现的是弱模型的「自知之明」

反套路的编排模式

提示词能被复制，你的产品不能

Why？技术上防不住

AI 时代，学得慢，就是快？

屠龙术

当 Token 成为新生产资料：程序员的价值正在归零？

智力通胀

Tokenmaxxing：硅谷的新风尚

没有银弹：Agentic Coding 时代的软件工程效率边界

1. Fred Brooks 的框架：本质 vs 偶然

1.1 四大本质困难

1.2 Brooks 悲观的预言：本质困难无法消除

论文分享：挂羊头卖狗肉！中转站 API 的模型欺诈行为研究

三句话总结 (TL;DR)

Pass^k：评估智能体可靠性的建议指标

论文分享：攻破你的 OpenClaw 🦞机器人，最好用的武器是 PUA

论文分享：AI 如何影响技能形成

【AI】论文精读：TinyLoRA —— 用 13 个参数让模型学会推理

一句话总结（TL;DR）

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

我做了个 Skill，把论文翻译变成了一行指令

Develop OpenGL Apps In A Docker Container Without GPU

Introduction

Overview

微调IndexTTS以输出可控情绪的语言音频

微调实验结果

模型结构与微调思路

将PyTorch模型适配到MLX

什么是MLX？

模型转换实践

基本的映射

如何快速定位有性能问题的 Shader 和一些简单有效的优化方法

问题

定位

OpenGL Uniform Buffer Object 的坑

什么是 Uniform Buffer Object？

坑1：UBO 的对齐问题

通过 dyld-interposing 实现C/C++代码注入

举个栗子

Graphics API Debuggers

Learning Render Graph

什么是 Render Graph？

解决什么问题？

从Android 原生库 (.so) 中里挖掘一些有用的信息

查看 so 的 NDK 版本信息