BoHuYeShan

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

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

很多人对 AI 的态度，建立在两个错误上。 一个是用的时候：效果不好，第一反应是”模型不行”。但有没有一种可能——你是在 chat 模式裸用的，连工具都没给；或者你甩了一句”帮我优化下”，然后怪它没懂你。 另一个是评的时候：拿一道”洗车店 50 米该开车还是走路”的残缺题去考 AI，AI 答”走路”就被制成表情包全网嘲。可那道题在传播中，早把”我想洗车”这个条件弄丢了。 这篇不聊怎么调 prompt 的玄学，而是给你一张分层自查表：你用不好 AI，基本就是下面四层里某层卡住了；而网上那些”AI 翻车”的笑话，往往也是出题人自己没说清。 先自测一下，答”否”越多，你越该往下读： 你用 AI 时，开的是 Agent、给了工具，还是一直拿对话框当万能？ 你提需求，是”明确可验收的目标”，还是”帮我弄个好用的东西”这种猜谜？ 你会不会把规划放权给强模型、让一般模型执行，并按任务选模型方向？ 你会不会配 harness、权限、上下文，让分工真正落地？ 这四层从下往上，顺序不能反。下面一层层拆。 一、先定位：你卡在哪一层的”使用断层”很多人以为”用不好 AI”是个单一问题，要么怪模型、要么怪自己不会写 prompt。但真正的情况是一张分层图——你大概率是其中某一层断了，而且往往是最底下那层。 层 它在解决什么 典型症状（中了几条？） L0 模式层 你给没给 AI 工具...

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

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

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

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

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

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

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、记忆文件、对话历史和终端输出。而这一整包东西，每一轮对话都会被完整送进模型，每一轮都在消耗它的注意力——这就是我说的”无形的内存”。 这内存有多贵？学术界的量化比任何博客都直白。一篇 2026 年的 arXiv 论文（Instruction-Tool Retrieval, ITR）测量发现：在典型的 agent 循环里，系统指令和工具定义要吃约 90% 的可用 to...