BoHuYeShan

我的简历里有一行字：训练过语言模型。一行字背后是几百天的时间。从搭数据管线、训到一半 loss 炸了重来、把整套东西搬到华为昇腾 910B 上再踩一遍坑，到后来发现这套”训练语言模型”的思维居然能一路迁移到蛋白质预测、再迁移到 AI 药物对接——这篇文章就是把这三次迁移完整讲一遍。 先交代清楚开源状态：医药侧（蛋白质、药物）的代码和模型，我暂时没有开源；语言模型侧的代码和仓库，在简历 V1 里提到的启智社区（OpenI）个人主页可以看到：openi.pcl.ac.cn/bhys。所以下面讲方法论和踩坑为主，代码点到为止。 第一部分：从零训练大语言模型，我踩过的坑架构别发明，抄已经收敛的模板训练 LLM 最反直觉的一件事是：架构设计在这个年代几乎不构成竞争力。Stanford CS336 课程的 Tatsu 讲过一句话我印象很深——2024 年大家都在 cosplay Llama2，2025 年的主题是”怎么训得不崩”，2026 年变成”怎么扛住长上下文”。我自己的经验印证了这一点：把主流开源模型的架构参数并排放在一起，90% 的维度几乎一模一样： pre-norm...

生物信息学有一个少被明说但每个人都心知肚明的现实：这个领域的人来自两个截然不同的起点。 有人是从计算机科学、软件工程、数学物理”跨”过来的——会写代码、懂算法，但在第一次拿到 RNA-seq 数据时，连”什么是文库、什么是接头、为什么要去重”都要从头学起。 有人是从生物学、医学、农学”转”过来的——做过 PCR、跑过胶、养过细胞，但在第一次面对终端窗口时，连 ls 和 cd 的区别都要查半天。 这两类人最终都在做同一件事——从生物数据里找答案。但他们走的路径、用的工具、面对的困难，完全不一样。 而 2026 年，AI 的介入让这两条路开始交汇了。但交汇的方式可能和大多数人想的不一样。 第一条路：从代码出发程序员转入生信的典型路径是：因为某个课题或项目需要分析生物数据，发现自己能写脚本、能调包、能搭环境，于是自然而然地接手了组里的计算任务。 这条路的人对以下场景不会陌生： 写 Python 脚本处理 FASTQ，用 Biopython 解析序列 搭 Snakemake 或 Nextflow 管线，把比对→定量→差异表达串起来 用 Docker/Singularity...

又看到有人做”AI 测试”了：挑五道专业课真题丢进网页对话框，回来对了三道半，于是下结论——“所谓大模型，专业水平堪堪及格，数学更是一塌糊涂，大家别神化。” 评论区一片附和。但我盯着这条帖子看了很久，因为它从头到尾建立在一个错误的预设上：他在考一个不许打草稿的学生。 一、先分清两种模式：chatbox 和 Agent今天大部分关于”AI 强不强”的争吵，参与者连自己在用什么模式都没分清。 chatbox 模式，就是那个最熟悉的输入框：你打一句话，模型回一段话。中间没有工具、没有执行环境，模型是”裸”的——它只能靠参数里记住的东西直接开口。网页版默认是这样，很多手机 App 也是这样，甚至不少”桌面客户端”也是这样。顺带补一个很多人一直没搞清的概念：相当一部分桌面 AI 应用，本质就是浏览器内核套了个壳，和你开的网页标签没有代差。判断一个产品处在什么模式，不看它的窗口长什么样、要不要下载安装，只看它背后给模型接了什么能力。 Agent 模式，则是给这个”裸模型”配上了手和脚。它能做的事情至少多了三样： 打草稿做计算——写一段代码，真的跑起来，看着输出说话； 编写文件——把中间...

上一篇聊了 chatbox 和 Agent 模式的区别，有朋友说：道理懂了，可打开应用商店一看，叫得上名字的 Agent 产品几十个，到底谁跟谁是一家人？ 这篇就来扒血统。结论先放在这里：市面上 Agent 产品看着百花齐放，扒开皮看骨架，真正称得上”祖宗”的上游体系，一只手数得过来。 国内厂商的产品，绝大多数都能在这几个上游里找到自己的位置——有的学 Pi，有的学 Claude Code，有的干脆直接 fork。 一、先搞清楚：Agent ≠ 模型谈血统之前，得先立住一个概念：harness。 你用的每一个编程 Agent，都是两部分拼起来的：底下的模型负责”想”，外面的 harness 负责”干”——工具怎么编排、循环怎么跑、权限怎么管、上下文怎么裁剪、文件怎么编辑。同一个模型换一套 harness，表现能差出一个档次；反过来，同一套 harness 接不同模型，体验也天差地别。 所以看一个 Agent 产品，不能只看它接的是谁家的模型——模型是发动机，harness 是整车的底盘和操控。市面上的”百花齐放”，大部分来自底盘设计的不同，而不是发动机的不同。 二、几大上游，...

昨天那篇长文里有一节讲数据清洗，只写了九百字。落笔的时候我就知道那一节撑不起这个话题——它是三次迁移里我踩坑最密集、也最能区分”做过”和”没做过”的地方。所以今天单独展开讲一件事：同样叫”数据清洗”，大语言模型和 AI 制药是两个完全不同的工种。前者是减法，后者是手术。 一、LLM 的清洗为什么”简单”：它已经被工具驯化了先说清楚我说的”简单”是什么意思——不是不难，而是方法论已经收敛、工具已经工业化。今天做一份预训练语料，流程几乎是标准的： 规则保底：Gopher/C4 式启发式，按行过滤过短过长、统计词频分布、砍高比例标点 模型打分：训一个小分类器判别”像不像高质量人类文本”，KenCC/FineWeb-Edu 都是这个思路 两级去重：精确去重（13-gram hash）+ 模糊去重（MinHash LSH），SlimPajama 靠这套滤掉约 48% 的重复 token 防污染：GSM8K/MATH/HumanEval 的 n-gram 指纹，清洗时精确剔除重叠片段 HuggingFace 的 datatrove 把这四步全做...

写 Agent 的文章很多，但大部分在讲”怎么用”，很少讲”怎么把一个编码代理做成一个可持续维护的发行版”。最近我把 Zeta 的仓库从头翻了一遍，它值得拆一拆的地方不在于功能多，而在于它把几个真问题答得比较实在：fork 上游怎么不烂尾、长会话怎么压成本、重活怎么不拖后腿。这篇是记录。 先交代背景：Zeta 是 Bun-native 的编码代理发行版，构建在 OMP 运行时之上，目前 18603 个提交，monorepo 里 @linxiraos/* 包命名空间，Rust 原生引擎在 crates/ 下，构建链同时挂 Bazel 和 Nix。产品面（网页）上写的”子代理、计划模式、LSP/DAP、事后记忆、hashline 编辑、时间旅行规则”这些是结果，过程比结果有意思。 上游策略：release-tag 合并 + 语义移植，两条腿分开任何基于开源上游做产品的团队都会遇到同一个问题：上游跑得飞快，你跟进，合并冲突爆炸；你不跟进，就烂尾成一个孤岛。Zeta 的对策是把”合并”和”移植”彻底分开，写死在文档里（document/upstream-sync.md）： ...

生信圈有一个默认的坏习惯：每次分析都现写脚本。README 上跑一次，交给别人跑就报错，重跑一遍结果还不一样。很多人把这归咎于”环境问题”，但根子是每次都在从零生成代码，而不是复用经过测试的实现。Linxira Bio SDK 的出发点就是反着来的一句定位：让常规分析用经过测试的实现，而不是每次运行生成一个新脚本。我翻了它的仓库，把它的结构拆一遍。 执行模型：默认本地，资源不够才往上走Bio SDK 的执行模型在文档里写得很明确：本地执行是默认，只有当实测的 CPU 时间、内存、GPU、数据库或存储需求超过本地执行包络时，才把工作移去本地 GPU、机构调度器或经批准的云端。”浏览器在线服务只是连接器，不是计算内核”——需要显式用户操作门、人工控制的认证，并且绝不存储或自动填充账号凭据。 这句话信息量很大。它把”本地优先”从口号变成了规则：不是”我们拒绝云”，而是**”先测，超了再迁移”**——迁移理由必须是可测量的指标，不是感觉。这也解释了为什么结构查看器要把解压后的 PDB/mmCIF 限制在 128 MiB、10 万个原子以内——本地渲染的物理边界是设计过的，不...

2026 年 7 月 24 日，Anthropic 在官方技术博客发了一篇文章，标题是《The new rules of context engineering for Claude 5 generation models》。Claude Code 团队在里面披露了一件反直觉的事：他们在为 Claude Opus 5、Fable 5 这类新一代模型迁移时，删除了超过 80% 的系统提示词，内部编码评测没有出现可测量的退步。 这不是一次普通的”提示词优化”，它宣告了一个范式的转向：从”提示词工程”走向”上下文工程”，而上下文工程的第一步，是给强模型做减法。 先想清楚”无形的内存”到底是什么讨论 Agent 的人经常犯一个错误：把”给模型的指令”和”模型拿到的上下文”混为一谈。上下文（context）是一个比 Prompt 大得多的概念——它包含系统提示、工具定义、CLAUDE.md/AGENTS.md、记忆文件、对话历史和终端输出。而这一整包东西，每一轮对话都会被完整送进模型，每一轮都在消耗它的注意力——这就是我说的”无形的内存”。 这内存有多贵？学术界的量化比任何博...

一个反直觉的观察：生信行业早就把软件分发交给了 conda 和容器，但把基底发行版的选择留给了每一台工作站的主人。 你可以在 Docker 里跑任何版本的软件，却逃不掉宿主内核、GLIBC 和显卡驱动三方之间的耦合。真正的争论往往不在”哪个软件源全”，而在”这台机器用什么更新哲学”。 先把问题框对：谁在用这些机器谈 Ubuntu 和 Arch 之前，先明确这类机器的画像，否则讨论会失焦： 联网的。工作站和服务器终究要上网，拉数据、拉镜像、同步代码，暴露面是真实的。 非安全专家的主人。绝大多数用生信做分析的课题组，不会专门雇一个安全运维。用户的能力边界决定了系统的默认行为不能太依赖人。 工具链要新鲜。CUDA 支持矩阵、编译器版本、新发布的生信软件，决定了机器还能不能装新东西。 这三条放一起，问题的核心就清晰了：一台要联网、没人专职维护、又想跟上新工具的工作站，最该担心的是”补丁到不了”还是”更新会弄坏”？ 这不是非黑即白的答案，而是两种成本的对赌。 核心差异：内核级滚动很多人分不清”滚动发行”和”LTS 发行”的区别，常常把”Arch 不稳定”挂在嘴边。先厘清一个事实：两...

生信分析为什么越跑越慢如果你做过真正的大规模生物信息学分析，一定遇到过这种情况：数据量从几个 GB 涨到几十个 GB，脚本的运行时间从几分钟涨到几小时，甚至直接跑崩。 这不是你的代码写得不好。这是 Python 和 R 本身的限制。 解释型语言的代价Python 和 R 的核心问题不在语言本身好不好用，而在每一次循环执行时，解释器都要做大量额外工作： 1234# 一段看似简单的循环total = 0for i in range(10_000_000): total += i * 0.5 在 Python 里，每一次 total += i * 0.5 都要经历： 从对象池取出 i → 检查类型 从对象池取出 total → 检查类型 执行乘法 → 创建新的 float 对象 执行加法 → 创建新的 float 对象 引用计数更新 → 垃圾回收潜在触发 同样的逻辑在 Rust 里：直接编译成 addss 指令操作 CPU 寄存器，零开销。 操作 Python R Rust Go 1 亿次整数加法 ~15s ~20s 0.05s 0.15s 100 万次空循...