进化概率论

重命名了一下 moa-plus 技能，blog-helper 直接罢工——init.sh 报错说找不到路径，draft.py 和 review.py 也跟着挂。代码里埋了一个硬编码的定时炸弹。 问题：技能之间不该拉拉扯扯blog-helper 是博客创作与发布流水线技能，需要调用 MOA 类深度思考能力来审稿和写稿。但改造前，代码里到处都是对 moa-plus 路径的硬编码依赖： init.sh

一个 P1 被 3 天的老任务挡住心跳任务队列是系统自动化的心脏——每天定时处理一堆待办：清理日志、回传结果、更新看板。我一开始用的是最简单的 FIFO（先入先出）：按提交时间排，先来的先处理。 简单，优雅，完美。 直到一个 P1 任务（高优先级，影响主流程）在队列里躺了整整 16 小时——前面压着 3 个 3 天前的批量任务，它们一个个执行完，才轮到它。 FIFO 的优雅，在混合负载下变成了灾难

日志像洪水，一打开页面就被成千上万行无意义的 INFO、DEBUG 淹没，关键的错误片段根本找不到。每次想从 Bug 追踪器里抽出当天最值得记的事，都要手动筛选、复制、再粘贴，效率低得让人怀疑自己在写代码还是在做体力活。三层筛选把这场“信息噪声”压缩成一篇可读的日记，既保留了审计痕迹，又让人类一眼看到重点。 必备环境 服务器 ModelBase（内网地址） GPU：2× RTX 2080 Ti

凌晨两点，我盯着 OpenCode 的终端，96 条消息排队等待处理，54 个工具调用在后台疯狂争夺显存。 模型开始胡言乱语，生成的代码越来越离谱——这不是 bug，而是系统在超负荷下崩溃的前兆。如果你也经历过类似的“深夜翻车”，这篇文章就是为你准备的。 前置条件这次优化在 ModelBase 服务器上完成，硬件配置比较特殊，提前列出来，避免你照着教程踩坑。 服务器：ModelBase（内网服务

为了维持一个 GitHub 账号的「活跃度」，很多人的做法是写个简单的 Python 脚本，每天定时修改一个 heartbeat.txt 文件的日期，然后 git push。这种做法在初级阶段很管用，但一旦涉及复杂的部署流程，比如我的 Hexo 博客，这种「心跳代码」就成了噩梦：它会频繁触发 GitHub Actions 的构建任务，浪费额度，甚至在某些时间点因为构建冲突导致正经的博文发布失败。

凌晨三点，运维群里有人喊了一声：“完了。”我们的 AI Agent 没有在半小时后补发健康检查——工程师 A 记得要改那个心跳偏差修复逻辑，觉得发行版更新完再搞也不迟。结果两周后，Agent 把-1 发给了生产数据库。 “记得做”等于“不会做”——这是我们掏了真金白银买来的教训。 AI Agent 系统里，最优先级的任务从来不是定时任务，而是那些“回头处理一下”的事情。而恰恰是这些不定时任务，会以

8887 条老数据，1511 条新数据，理论上合完应该是 10398 条。但最终只拿到 8908 条——差了 1490 条。数据去哪了？是丢了，还是它们本来就不该在？ 这篇文章记录 ReShare 数据库从两套独立实例合并为一套的完整过程，包括数据导出、主键冲突处理、业务级去重、以及那些让人半夜爬起来查日志的坑。 前置条件 PostgreSQL 16，源库和目标库版本一致 ModelBase 服务

昨晚发了篇新文章，顺手点进标签页想检查分类效果。浏览器转了半天，甩给我一个 404。分类页也一样，白板一块。但首页好好的，文章也能正常打开。 刚推上去的新文章，怎么标签和分类就没了？ 我是韩梅梅，AI 量化交易团队的负责人，平时维护着团队的技术博客。这个博客用 Hexo 搭的，部署在 GitHub Pages 上。排查了两个小时，最后发现问题根本不在我的代码里——是 GitHub Pages 在背

用单个大模型写技术文章，我遇到过一个非常一致的失败模式：前两段像人写的，写到后面逻辑开始跳、论据开始虚、结构开始散。换一个更大的模型？好一点，但问题依旧。 后来想明白了一件事：问题不在模型不够大，在于单一模型的能力分布天然不均匀。 一个模型同时负责查资料、搭结构、写文字、查错，就像让一个人同时当作者、编辑和校对——总有一个角色会拉胯。 更反直觉的是，论文已经证明了：把几个中等模型组合起来，效果可以

昨天深夜，我把 169 行 HTML 文件喂给 write_file 工具，以为会看到干净的代码。结果打开一看——每行前面都多了个 142| 的前缀，像给每行贴了个条形码。一行还行，169 行全被污染。 这就是做开源大模型天梯图最真实的日常：你以为在写代码，其实是在和数据打架。 起因很简单：想找一个能直观对比开源大模型编程能力的排行榜。不是那种只列了十几个主流模型的简表，而是把 2023 年到现在