AlpacaNotes

绿灯熄灭：张雪峰与他的时代

AztecaAlpaca — Wed, 25 Mar 2026 14:57:00 GMT

一、一个没有写完的盖茨比

2026年3月24日中午，张雪峰在苏州公司的健身房跑步时突发心脏骤停。同事将他送往医院，经数小时全力抢救，未能挽回。下午近四时，确认死亡。四十一岁。

消息传开的速度很快。这并不意外。他生前在不同场合说过，希望有一天自己离开的时候，各大平台上会出现一个热搜叫"张雪峰死了"，希望能成为一代学生和家长的回忆。据广泛流传的说法，他还曾在微博上表示，猝死是他心目中比较理想的一种死法。

现在看，一语成谶。

但这篇文章不打算从悼念写起。张雪峰是一个足够复杂的公共人物，他值得一种比悼念更认真的对待方式。我想做的事情比较简单：把他放进一个文学坐标里，看看他的故事在多大程度上与另一个人的故事构成映射。

那个人是杰伊·盖茨比。

这个类比乍看有些突兀。一个是二十世纪美国文学最著名的悲剧人物，一个是中国互联网时代的头部网红。但如果暂时放下表面身份的差异，只看故事的结构——盖茨比从中西部的穷小子变成西卵豪宅的主人，张雪峰从齐齐哈尔铁路工人家庭的孩子变成身家近十亿的行业头部——从底层崛起、疯狂追逐、被时代托举又被时代消耗，两者之间的相似性比预想中要深。

当然，映射不是等号。盖茨比的故事是完整的，起承转合一样不缺。张雪峰的故事不是。他的剧本写到了高潮刚过、转折将至的地方，然后灯灭了。这个未完成的状态，本身就是他和盖茨比之间最大的不同，也是最耐人寻味的地方。

二、黛西小姐

理解盖茨比，必须先理解黛西。

盖茨比所做的一切——买下西卵的豪宅、夜夜笙歌的派对、精心构建的上流身份——全部指向同一个目标：重新赢得黛西·布坎南的注意力。黛西是他行为的原动力，也是他悲剧的根源。不是因为黛西本人有多特别，而是因为她代表了盖茨比对自身命运的全部想象。

但黛西身上有一个致命的特征：她的注意力永远是暂时的、有条件的、随时可以收回的。她不是一个可以被"赢得"的人，她只是一个可以被暂时吸引的人。盖茨比倾其所有去追逐的，从一开始就不是一个可以稳定占有的东西。

张雪峰的黛西是流量。

当然，这个说法是一种压缩。张雪峰真正面对的，是流量、家长焦虑、教育市场、平台算法和个人品牌共同构成的复杂力场，远不是一个单一对象能概括的。但如果只看驱动结构——看那个让他无法停下来的东西的本质特征——流量是其中最接近黛西的部分。它具备黛西的全部核心属性：不忠诚，不念旧，不会因为你过去的付出而给予你未来的青睐。你必须不停地表演、不停地输出、不停地制造新的刺激，才能维持它的短暂驻留。一旦你停下来——哪怕只是慢下来——它就转身走了，去找下一个更能取悦它的人。

盖茨比为黛西办派对。张雪峰为流量做直播。驱动结构完全一致：用持续的、高强度的自我展演，去换取一个本质上无法被锁定的对象的注意力。

但张雪峰在一个关键的地方似乎比盖茨比更清醒。盖茨比到死都相信黛西是属于他的，他的悲剧建立在一个至死不渝的误判之上。张雪峰不太一样。他的原话是："我的人生目标就是，如果有一天我死了，各大平台会有一个热搜叫'张雪峰死了'……我希望能成为同学们或家长们一代人的那种回忆。"这句话表面上是一种豪放的自我期许，底层更像是一种深刻的不安全感——他大概意识到流量的眷顾是租来的，不是买下的。租约随时可能到期，而他未必有续约的把握。所以连身后事都要提前规划成一次传播事件，某种意义上，是在为最后那一刻预留一次向黛西求爱的机会。

这种清醒比盖茨比的天真更让人不安。一个不知道自己在追幻觉的人，至少还拥有追逐本身的快乐。一个明知是幻觉还停不下来的人，连这份快乐都是打了折扣的。

三、镀金时代的派对

盖茨比的故事发生在美国的爵士时代——二十世纪二十年代，一战结束后的繁荣期。严格来说，这不是美国史分期中的"镀金时代"（那个概念通常指十九世纪末的工业扩张期），但两段历史共享一种相似的气质：表面上一片繁华——股市飞涨，消费主义盛行，人人都觉得明天会更好。繁华之下，贫富分化在加剧，旧贵族与新富阶层之间横亘着难以逾越的壁垒，大多数人触摸到的只是繁荣的镀层，而不是繁荣本身。

盖茨比的豪宅派对是这个时代最精准的隐喻。来的人很多，真正认识主人的没几个。派对的目的不是社交，是展示；不是快乐，是证明。证明盖茨比有资格站在这里，证明他已经跨越了阶层的鸿沟——尽管所有人心里都清楚，他没有。

张雪峰的直播间，是中国版的盖茨比派对。

他从2016年前后开始爆火，到去世将近十年。他本人毕业于郑州大学，没有读过研究生，最初只是帮人找考研资料，无意间发现了这一领域的商机。这个出身本身就带有盖茨比式的底色——没有背景、没有学历光环、全靠对规则的敏锐嗅觉白手起家。而他活跃的这些年，恰好覆盖了中国社会一段非常特殊的时期：经济增长开始放缓，就业市场逐渐收紧，学历贬值的趋势日益明显，但高考作为阶层流动主通道的叙事还没有完全崩塌。换句话说，社会流动性正在收窄，但还没有关闭。

这是一个微妙的窗口。梦想能成为大众消费品，需要一个很精确的条件：流动性恰好处于"可见但不可及"的区间。太容易了，梦想不值钱，没人需要为它付费。太难了，梦想没有市场，人会本能地放弃不可能的事情，转向更务实的生存策略。

张雪峰恰好卡在那个甜蜜点上。他贩卖的核心产品不是专业知识——那些信息在网上并不难找——而是确定感。"选对赛道就能赢"，这七个字概括了他全部的商业逻辑。对于无数焦虑的家长和迷茫的考生来说，这句话的吸引力不在于它有多正确，而在于它提供了一种稀缺的心理安慰：复杂的世界是可以被简化的，人生是可以被"选择"优化的，你的命运掌握在你自己手中——只要你做对了这一步。

但地形在变，地图没有更新。

当越来越多的人发现，选了计算机也不一定能就业，考上985也不保证什么，张雪峰兜售的确定感就开始贬值。问题在于，他的商业模式决定了他不能公开承认这一点。他不能站在直播间里说"其实已经没有好赛道了"，因为一旦说出这句话，他的产品就失去了存在的理由。所以他只能继续贩卖那个正在过期的承诺，就像盖茨比必须继续办派对一样——不是因为派对还有用，而是因为停下来就等于承认一切都是假的。

有人说他"毁掉"了某些专业，比如土木，比如新闻。这恐怕高估了一个网红对行业基本面的影响力。他只是用一种高度简化、极具传播力的方式，把一些本来就存在的结构性问题翻译成了大众听得懂的语言。公允地说，他可能是国内第一个把高考和考研咨询彻底还原为就业导向的人，这个贡献不应该被抹掉。但也正是这套翻译的成功，让他赚到了时代的红利，同时也框定了他的局限。

他足够聪明，能把复杂的事情讲得简单。但简单本身就是一种扭曲，而他似乎没有足够的知识纵深去意识到这一点。他对专业的判断始终停留在就业变现这一个维度，对运动和健康的理解也停留在"练就是好"的层面——当直播间有人提醒他嘴唇发紫、心脏可能有问题时，他的回应是："我跑半马的人，你说我心脏不好？"这种以成绩反驳风险的思维方式，和他以简化替代深入的职业方法论，出自同一个认知结构。他给了无数人一个看待世界的框架，但那个框架的有效期比他预想的短得多。

四、庄家坐上了自己的赌桌

盖茨比追逐的是一个外在的幻象。黛西是一个具体的人，住在对岸，码头尽头亮着一盏绿灯。幻象虽然是幻象，但至少是清晰的、可辨认的、与自己分离的。

张雪峰的情况更复杂。他追逐的幻象，有一部分就是他自己。

他的职业身份和他贩卖的信念之间，存在一种危险的共生关系。他卖的是"拼命就有回报"，那么他自己就必须是这个命题最有力的论据。他不能不拼命，不能表现出疲态，不能承认自己在透支，因为一旦这么做，就等于在自己的产品上贴了一张"此路不通"的标签。而且这种绑架不仅是心理上的，也是商业结构上的——他的公司高度依赖他个人的IP，离了他几乎转不了。他想停，可能也停不下来。

他似乎对此有某种自觉。他说过："一个家庭或者家族想要逆天改命，就必须有一个人愿意为家族奉献一切……我就是我们家族中被牺牲的那一个。"面对女儿抱怨他陪伴太少，他的回应是："人生很难两全其美……有得必有失，有失必有得。"这些话不像是一个被蒙在鼓里的人说的，更像是一个清醒地接受了交易条款的人在向自己确认：代价是值得的。

所以他在微博上吐槽忙碌带来的身心疲惫，然后紧接着又给自己打鸡血——用的是同一套他在直播间里给年轻学生打鸡血的话术。这不是简单的情绪波动。这更像是一个人被自己构建的叙事绑架之后的挣扎。信念和人设可能早已合二为一。真心相信就是最好的人设，而最好的人设要求你真心相信。

这是一个自我催眠的闭环，也是他比盖茨比更悲剧的地方。

盖茨比至少在结构上是清晰的：他是追逐者，黛西是被追逐的对象，两者之间有一道海湾。但张雪峰把自己同时放在了赌桌的两边。他是庄家，负责维持游戏的运转，告诉每一个入场的人"赌下去是值得的"。他同时也是赌徒，用自己的身体、精力和生命作为筹码，押在同一张桌子上。他给别人发牌的同时，自己也在跟自己对赌。

他很早就把一切摆上了赌桌。微博上的疲惫感不是突然出现的，而是持续存在的背景音。2023年他曾因胸闷心悸住院，但出院后一切照旧。他大概不是不知道风险，而是在他的评估体系里，离桌的代价比留下来更高。对一个把全部身份都押在这张桌上的人来说，离桌不只是放弃收益，而是失去自我。

所以他一直坐着，直到清盘。

他跑过半程马拉松，对自己的体能相当自信。他还患有长期高血压。这两件事并存在同一个人身上，构成了一种典型的认知陷阱：运动成绩成了否认基础病风险的依据。运动本身就是对身体的消耗，它能激发更强的修复机制，前提是充分的休息和对基础健康状况的正视。训练和恢复是一个完整的闭环，只看训练不看恢复，本质上是在积累损伤。但对一个把休息视为浪费时间、把成绩视为健康证明的人来说，这个道理大概很难接受。

无畏往往源于无知。而最危险的一种无知，不是什么都不懂，而是懂得刚好够多，多到足以建立虚假的安全感，却不够多到看见真正的风险。

五、谁的幻灭

盖茨比死于一场误会。汤姆把车祸的责任推到他身上，威尔逊开枪打死了他。他到死都没有经历真正意义上的幻灭——没有看到黛西最终选择了汤姆，没有意识到自己追逐的一切从一开始就是不可能的。

幻灭的任务留给了尼克·卡拉韦。小说的最后几页，尼克独自站在盖茨比的空宅前，望向对岸那盏绿灯，替盖茨比——也替读者——完成了那个迟到的觉醒：我们都在逆流而行，被不断地推回过去。

张雪峰也没有亲历幻灭。我们不知道他在生命的最后阶段是否感受到了时代对他的转冷。也许有过隐约的不安，也许始终信心十足。他的故事是开放式结尾，停在了一个我们无法确认他内心状态的位置。

但他的死，替很多人完成了幻灭。

这种幻灭不是一瞬间发生的。它在过去几年里就已经在年轻人中间缓慢蔓延——考公上岸发现体制内也不如想象中稳定，进了大厂发现随时可能被优化，读了热门专业发现就业市场根本不买账。张雪峰贩卖的那套"选对就能赢"的逻辑，在现实面前一点一点地碎裂。但碎裂是渐进的，人可以用各种方式回避它。也许是我还不够努力，也许是我选的还不够对，也许下一次就好了。这种自我安慰可以维持很久，直到某个标志性的事件把最后一层薄膜捅破。

张雪峰的死就是那个事件。它同时击穿了两层信念。第一层是"拼命就有回报"——一个把拼命做到极致的人，换来的是四十一岁倒在公司的跑步机上。第二层更深：他被视为这套游戏的赢家，而赢家以这种方式退场，动摇的就不只是对个人策略的信心，而是对整个游戏规则的信任。如果连赢家的结局都是这样，那这个游戏的终点到底在哪里？

盖茨比死后，尼克替他看清了绿灯的虚妄。张雪峰死后，每一个活过昨天的人都成了尼克。

绿灯已经熄灭了。

但赌桌上还坐满了人。

造了一条翻译流水线，然后把它关掉了

AztecaAlpaca — Wed, 25 Mar 2026 12:00:00 GMT

起点：一篇八万字的播客文字稿

我有一个个人知识库，里面有一个目录专门存放从网上收藏的外文文章，积攒了不少播客访谈和演讲的文字稿。我习惯把这些东西翻译成中文再读，一方面是阅读速度更快，另一方面是翻译本身就是一种深度阅读——你不得不去理解每一句话到底在说什么。

我之前经常直接把东西甩到chatbot中直接翻译，这一套当然问题不大，但是存在潜在的对内容压缩的风险。另外一点，我有超多配额的国产大模型，心想其实翻译不那么考验大模型的能力，因此不妨开发一套skills，来直接对内容进行翻译。当然，有这种方法直接短文章没问题，几千字的博客帖子扔进去，几分钟就出来了。但当我把一篇超长的YouTube视频脚本或者一本书丢过去，就很难避免它翻到一半就开始丢内容、混术语，翻译质量明显下降。当然，还有一种情况：直接卡住，几个世纪过后告诉你失败...

于是我决定写一个分片翻译系统。

分片的基本想法

核心思路：把长文按章节标题切成若干片段，每片独立调用一次 LLM，翻译完再拼起来。每片有自己独立的上下文，不会溢出。

但"切开再拼回去"这件事，远没有听起来那么简单。最直接的问题是：切开之后，后一片看不到前一片的内容，怎么保证术语统一？怎么保证前后文衔接自然？

我用了两个机制。第一个是术语表接力：每片翻译完成后，脚本会从输出中提取新出现的术语对照（比如 "scaling law → 规模定律"），存入一个不断增长的术语表，注入到下一片的提示词里。这样模型在翻译后续片段时，已经知道前面把哪个词翻成了什么。

第二个是重叠段落：把前一片译文的最后三段文字带给下一片，标注"这是前文结尾，不要重复翻译，仅用于衔接语气"。这样模型能感知到前文的口吻和节奏，避免每片的开头都像是文章的第一段。

真正的文本什么样都有

系统写出来之后，拿几篇标准的博客文章测试，运行得很顺畅。但实际使用中很快遇到了各种边界情况。

第一个是播客文字稿的时间戳。YouTube 自动转录出来的文字稿里密布着 "0:00"、"1:23" 这样的时间戳，它们出现在原文的各个位置，需要在翻译时全部移除。我写了一个检测函数，扫描原文中的时间戳模式——粗体时间戳、裸时间戳、方括号时间戳、括号章节目录——出现三次以上就判定为视频脚本，自动切换到去时间戳、合并短句、跳过广告的处理模式。

第二个是没有章节标题的文档。我的切分逻辑以 ## 标题为边界，但有些演讲稿（比如 David Patterson 的那篇）是 58K 字符的纯文本，没有任何标题，也没有段落分隔。切分函数拿到这样的输入，一刀都切不下去。

为此我做了一个四级回退机制：先试按空行切，切不动就按换行切，再不行就按句号问号等标点切，最后兜底是强制按字符数在空格处截断。每一级都检查切出来的最大片段是否在限制以内，满足就停下来。

第三个是说话人识别。播客和访谈里有多个人在说话，翻译完之后读者分不清谁是谁。一开始我做了一个独立的后处理脚本，对已翻译的文本再跑一遍 LLM 来推断说话人。后来发现这条路不太对——中文译文里的说话人线索远不如英文原文丰富。英文原文中，提问的句式、自我介绍、对他人的称呼，这些线索都很明确。到了中文里，这些特征被翻译抹平了不少。

最终的方案是在翻译的同时就做说话人识别，把识别指令直接写进翻译提示词里，而不是翻译完再补。

断点续传：从简单到复杂

长文翻译经常中断——网络超时、API 限额、手动终止。翻译到第 8 片的时候断了，总不能从头再来。所以我给系统加了断点续传：每片翻译完成后立即写一个 checkpoint 文件，记录原文内容、原文的哈希值、译文和术语。下次运行时，检测到 checkpoint 存在且哈希匹配，就跳过这一片。

最初这个功能需要手动加 --resume 参数。很快发现自己总是忘记加，于是改成了自动检测：每次运行都去工作目录里看有没有已完成的 checkpoint，有就跳过，没有就翻译。

后来又遇到一个更微妙的问题。第一次用 10K 字符切分，翻译了一部分之后觉得片段太大、模型处理不好，想改成 5K 重新来过。但已经完成的那几片没问题，只是后面的需要切小一点。如果简单地重新切分，片段编号就全变了，已有的 checkpoint 对不上。

最终的解决方案是：保留已完成片段不动，把剩余未翻译的原文拼在一起，按新的尺寸重新切分，清理掉旧的未完成 checkpoint。这样已完成的工作一点不浪费，新的片段从正确的位置接上去。

回头看这个续传系统，它的复杂度已经超过了翻译本身。原文指纹校验、chunk manifest 持久化、动态重切、checkpoint 清理——这些机制解决的都是真实遇到的问题，但它们叠加起来之后，系统变得很难一眼看清全貌。

便宜的模型撑不住

系统设计了多模型支持，可以通过一个参数切换到不同的模型提供商。这个功能的初衷很实际：翻译是一个 token 消耗量很大的任务，如果能用更便宜的模型完成，成本可以降低一个数量级。

我试过用 MiniMax 翻译了一篇文章。结果很难接受：术语译法不稳定，同一个词前后出现了三四种不同的翻译；口语化的段落被改写成了不像中文的奇怪句式；说话人识别几乎完全失败，该标注的地方没标注，不该标注的地方乱标。当然，更关键的还是有些段落完全不讲人话。

不得已，所有正式翻译都回到了 Claude Sonnet。Sonnet 的翻译质量确实好得多，但代价是 token 单价高出很多倍。对于一篇普通的博客文章，这个成本还在可接受范围内。但 YouTube 上那些动辄两三个小时的长访谈——文字稿 70K、80K 字符起步——切成十几个片段逐一翻译，每片都用 Sonnet，总成本就变得很不经济了。

这让整个分片翻译系统陷入了一个两难：用便宜的模型质量不够用，用好的模型又太贵。而且片数越多，这个矛盾越突出。

每片的固定开销

这笔账其实越算越不乐观。

每片翻译的提示词不只有待翻译的原文，还包括一套固定的"脚手架"：翻译原则（直译优先、不要中介转写、术语处理规则等），视频脚本处理指令（去时间戳、合并短句、说话人识别），章节标题策略，已有的术语表，前一片的末尾三段。这些加起来大约 700 到 1200 tokens，与原文内容无关。

7 个 10K 片段的文章，固定开销合计约 5600 tokens。如果同一篇文章切成 22 个 5K 片段，固定开销变成约 17600 tokens。多出来的一万多 tokens 全是在重复念同一套指令。而且术语表会随着翻译不断膨胀，后面的片段比前面的片段更贵。

这还只是输入端。输出端每片也有格式指令产生的额外开销。算下来，分片翻译比一次性翻译多消耗 15% 到 20% 的 token，而且片切得越小，比例越高。

关掉它的原因

最终让我决定放弃这套系统的，不是某一个具体的技术问题，而是一个整体判断：性价比不够。

速度慢是第一个原因。13 个片段的文章需要 13 次串行的 API 调用，每次都要等模型生成完整的翻译，加上重试和最后的导读生成，一篇文章翻译下来要几十分钟。这段时间不需要人工干预，但你得等着它跑完才能看到结果，没法边看边调整。

token 消耗大是第二个原因。分片的固有开销——每片重复的系统指令、不断膨胀的术语表、衔接段落——这些都是用 token 换来的跨片一致性。在上下文窗口只有 8K 的时代，这个代价值得付。但现在主流模型的上下文窗口已经到了 128K 甚至更大，一篇 70K 的文章可以一次性放进去，根本不需要切分。

翻译质量没有明显优势是第三个原因。我对比了分片翻译的结果和直接在交互式工具（比如 AI Studio）里翻译的结果，差别不大。分片系统在术语一致性上有一点优势——术语表接力确实能保证前后统一——但这个优势在一次性翻译中也基本能做到，因为模型本身就能在长上下文里保持一致。

系统复杂度高是第四个原因。断点续传、chunk manifest、动态重切、四级回退切分、视频脚本检测、说话人识别——每一个功能都是为了解决一个真实的问题，但它们合在一起形成了一个需要持续维护的系统。而我要做的事情只是翻译文章。

留下来的东西

系统关掉了，但过程中积累的翻译理念还是有用的。

比如"非中介翻译"这个约束。LLM 在翻译非英语文本时，有一种倾向：先把原文理解为英文，再从英文翻译成中文。日语翻中文的时候尤其明显——翻译结果读起来像是从英文转过来的，日语原文特有的省略结构和语气词全丢了。在提示词里明确写"不要借助英语或其他中介语言"，能一定程度上缓解这个问题。

再比如"直译优先"的层次。很多人让 AI 翻译的时候会说"翻译要通顺"，但"通顺"这个要求往往导致模型过度改写——补出原文没有的主语、加上原文没有的因果连接词、把原文的省略结构展开。我在提示词里建立了一个优先级：先尽量保留原文的语序和结构，实在不通顺再调整语序，最后才是为了可读性牺牲原文形式。这个分层让模型的翻译行为更可控。

还有术语表的处理策略。"首次出现时写成'中文翻译（原文术语）'，后续直接使用中文"——这个规则在任何翻译场景下都适用，不限于分片系统。人名的处理也是一样：只有被广泛认可的译名（比如"欧拉"）才翻译，其余一律保留原文，避免读者无法回溯原始人名。

这些规则不需要一个复杂的脚本来执行，写在任何翻译提示词里都能用。

一个关于工程判断的小教训

这个项目从开始到弃用，前后大约一周。期间翻译了十几篇文章，其中包括几篇八万字以上的长访谈。系统本身是能用的，翻译质量也可以接受。但最终的结论是：用一个交互式窗口手动操作，效率反而更高。

回头看，问题出在对环境变化速度的低估上。我在设计分片翻译的时候，心里的参照系是"上下文窗口不够长"这个前提。但是这种焦虑在可以轻松使用AI Studio这种提供1M上下文的平台的前提下，意义不大。

另一个教训是关于工程复杂度的。每一个功能——断点续传、动态重切、四级回退——单独看都很合理，每一个都是为了解决一个真实的、在使用中遇到的问题。但它们叠加起来之后，系统的维护成本开始超过使用收益。什么时候该停下来不再加功能，这个判断比"该加什么功能"更难做。

留下技术文档不是因为这个系统以后还会用，而是因为里面的一些设计思路——术语表接力、重叠衔接、分级回退切分——在其他需要分片处理长文本的场景下可能有参考价值。至于翻译本身，就回到最简单的方式：打开一个足够大的上下文窗口，把全文丢进去。另外，我也会偶尔翻出来再测试一下，把它接上claude或者国产的大模型，日后也可能会突然发现这套系统变得丝滑好用，届时可以用来翻译一些图书级别的长文档。

Telegram / Discord 推送测试文章

AztecaAlpaca — Fri, 20 Mar 2026 00:00:00 GMT

这是一篇用于测试推送链路的临时文章。

它的目标很简单：确认当仓库里新增一篇 article 之后，站点部署完成，Telegram 和 Discord 两个频道都能收到更新消息。

这篇文章本身没有太多实际内容，重点是用来观察三件事：

标题在不同平台上的呈现是否正常；
摘要是否使用了 frontmatter 里的 description；
链接跳转后，线上页面是否已经是最新版本。

如果这条测试推送工作正常，后面就可以更放心地把日常文章和 notes 同时同步到两个频道里。

Instant View 踩坑记：折腾了一整天，答案是「等一下」

AztecaAlpaca — Sat, 14 Mar 2026 00:00:00 GMT

事情从一个烦人的现象开始：同一个域名下的文章链接，发到 Telegram 里，有时候底部有 INSTANT VIEW 按钮，有时候没有；有时候点进去能正常阅读，有时候是白屏。

我以为搞个把小时就能解决。结果折腾了一整天。

第一层：IV 规则太脆弱

最先怀疑的是 Instant View 的匹配规则。打开一看，果然——之前的规则全靠 CSS 类名来定位内容，什么 text-xl、mt-16 之类的。这些名字是 Tailwind 生成的样式标记，前端随便改一下排版，匹配就悄悄失效了，连个报错都没有。

于是我做了一件早就该做的事：在页面模板里加了一组 data-iv-* 属性。标题是 data-iv-title，正文是 data-iv-body，作者和发布时间也各有标记，导航栏之类不该被抓的元素标上 data-iv-ignore。然后 IV 规则只认这些语义标记，不再去猜页面长什么样。

改完之后，在 Telegram 的 IV 编辑器里一测，规则确实稳定了。我想这事应该差不多了吧。

第二层：同一个域名，两套页面

没差不多。

我忘了一件事：这个域名下不只跑着我的笔记站，还有主站的文档页面，HTML 结构完全不同。而 Telegram 的 IV 规则是按域名绑定的——一个域名只能有一套规则。

所以我的规则得同时覆盖两种完全不同的页面结构。最后用了一个"先后匹配"的方案：先试 data-iv-*，匹配不到就回退到主站那套 docs-content + md-theme-amp 的结构。不算优雅，但能用。

到这里我又觉得差不多了。

第三层：Bot 消息怎么写都不对

然后进入了最耗时的一个环节。

规则改好了，用 t.me/iv?url=...&rhash=... 裸链接手动粘贴到聊天里，IV 正常弹出。但 Bot 通过 API 发出来的消息，就是另一回事了。

我试了各种写法：把 IV 链接嵌在消息文本里、做成 inline 按钮、拆成两条消息、用 link_preview_options 指定预览 URL……每种写法在 Telegram 那边的反应都不一样，而且同一种写法隔一会儿再试，结果可能又变了。

这个阶段我最大的认知冲击是：手动粘贴一条链接和 Bot 通过 API 发一条消息，在 Telegram 内部走的可能根本不是同一条路。"手动能用"不等于"Bot 发也能用"。

花了好几轮实验，总算找到一套消息结构能比较稳定地挂出 IV 卡片。我松了口气。

插曲：`.nojekyll` 的低级失误

在这过程中还踩了一个完全不相关的坑。

之前把部署流程从 GitHub Actions 的官方 action 切换到手写 shell 脚本，结果忘了在发布目录里放 .nojekyll 文件。GitHub Pages 默认会用 Jekyll 处理静态文件，而 Jekyll 会忽略所有下划线开头的目录——比如 _next。Next.js 的所有 CSS 和 JS 资源都在 _next 里面。

所以页面变成了光秃秃的纯文本。HTML 加载了，但样式和交互全没了。浏览器里看着像是前端炸了，Telegram 去抓页面拿到的当然也是残缺的内容。

修复倒是一行代码的事：touch "${temp_dir}/.nojekyll"。但排查的时候根本没往这个方向想，因为症状看起来像是 CSS 写坏了。

以为快好了

修好 .nojekyll 之后，页面恢复正常了。IV 规则也稳定了。Bot 消息写法也调通了。我觉得这次真的差不多了。

部署一下，发条通知试试——

有时候有 IV 按钮，有时候没有。

我都快疯了。

真正的反转

反复试了几轮之后，我终于注意到一个规律：如果部署完马上发通知，IV 大概率挂不上；如果等几分钟再手动发链接，就没问题。

然后一切都说通了。

**GitHub Pages 的 CDN 传播需要时间。**代码推送到 gh-pages 分支之后，CDN 节点并不是立刻就能返回新内容。可能要几十秒，甚至一两分钟。而 Bot 的通知脚本是紧接着部署步骤运行的——这时候 Telegram 去抓取页面 URL，拿到的可能是旧版本，也可能是 404，也可能是正在更新中的不完整页面。

所以 Telegram 的 IV 引擎拿到了一个"坏"的页面，匹配失败或者渲染出白屏，然后还把这个结果缓存了。之后再怎么改规则、改消息写法，都没用——因为根本原因不在那些地方。

「等一下」就好了

最终的解决方案朴素得有点让人哭笑不得：等页面真正上线了再发通知。

我写了一个 wait-for-publication.js 脚本，部署完成后轮询刚发布的页面 URL。每 10 秒检查一次，最多等 3 分钟。检查的标准是：HTTP 返回 200，而且页面内容里包含 data-iv-body 或文章标题——这说明新版页面已经真正可以被外部访问了。

轮询通过之后，还额外 sleep 20 冷却一下，给 CDN 多留点缓冲时间。然后才运行 Telegram 通知脚本。

加上这个等待之后，IV 按钮就稳定了。

折腾了一整天改规则、改消息写法、修部署脚本，每一步都有收获，但都不是那个让 IV "时灵时不灵"的主因。最后的答案是：你发得太早了，页面还没准备好。

还有一点没法控制

还有一个残留现象：同一条 IV 链接反复打开，偶尔会白屏。第一次打开通常没问题，再点一次就可能只剩标题栏。

后来搞清楚了：这是 Telegram Web K 版（web.telegram.org/k）的客户端 bug。Web K 在关闭 IV 视图后没有正确清理内部状态，再次打开同一篇文章时，渲染管线的状态已经脏了，就白屏了。移动端完全不受影响——原生客户端的 IV 渲染引擎和 Web 版是两套完全不同的实现。至于 Web A 版（web.telegram.org/a），它压根不支持 IV，连按钮都不会出现。

所以 IV 在 Telegram Web 端就是二等公民。移动端能正常用就行，桌面端的读者走 Read More 链接直接看原文也不差。

延伸阅读

如果你也想给自己的静态站点配 Telegram Instant View，可以看看《为静态站点配置 Telegram Instant View：从页面标记到部署等待》，那篇按正确顺序整理了完整的操作步骤，不用像我一样绕弯子。

腾讯SkillsHub:开源蛋糕里的蟑螂

AztecaAlpaca — Fri, 13 Mar 2026 00:00:00 GMT

腾讯搞了个 SkillHub，号称"专为中国用户优化的 AI Skills 社区"。我没有打开这东西，不想浪费时间，也不想动情绪，但据说有一万三千多个 skill，绝大多数是从 ClawHub 直接搬过来的。

他们大概率会如过去经常做的那样，一通经典的“混元形意...组合拳”：套一层中文搜索，挂一个国内 CDN，再把自家的腾讯文档、QQ 浏览器、腾讯地图塞进去凑数，通稿一发——"生态建设"。

我有时候其实挺抵触开源的。不是抵触开源本身，而是抵触它对流氓太友好。再好的一盘蛋糕，都不够几个蟑螂造的。

这事严格来说不算抄袭。协议合规，署名保留，代码没改，法律上挑不出毛病。但恶心就恶心在这儿——它一个大厂，不认真地自己去经营自己生态，而是躲在灰色地带，把别人的劳动成果变成了自己商业版图的一块砖，还要美其名曰”造福大家“。一家市值几万亿的公司，AI 战略的核心动作是"镜像别人的生态"，真的让人很不适。

开源的经济逻辑

我经常会思考一个问题：开源的意义到底在哪？

许多人会说他们做开源是“用爱发电”。但这明显不现实。热情往往是短暂的，只有物质意义上的回报才能让事情变得长久。开源社区对计算机行业来说是个古老的存在，绝不可能仅仅是单纯为了情怀的利他主义。

这个问题得从经济学上去想。我了解了一下，大概有几种非常“物质”的自利机制促使越来越多的人加入到开源中来。

信号理论：能力展示的成本

Spence 的信号理论解释得最好：开源贡献是一种 costly signal，你把代码公开展示，本质上是在劳动力市场上发出一个难以伪造的能力证明。代码质量、架构设计、问题解决能力——这些都是无法伪装的硬实力。

人力资本理论：可携带的投资

Becker 的人力资本理论也讲得通——你在公司里写的代码是 firm-specific 的，离职就归零；开源项目是 general human capital，可以随身携带。同样的时间投入，开源的长期 ROI 可能更高。

礼物经济：声望的记账系统

还有一层是礼物经济。开源社区的声望体系——star 数、contributor 排名、maintainer 身份——本质上是一套礼物经济的记账系统。你"赠予"代码，社区"回馈"地位。这个循环之所以能运转，前提是参与者共享同一套互惠规范。

大厂的理性与无耻

问题在于，大厂不在这个规范体系里。它们是纯粹的理性经济人，只取不予。甚至不认为自己"收了礼物"，因为请帖上确实写着"无需回礼"。

好消息是，上面这些自利性的激励——信号价值、人力资本、社会资本——搭便车者拿不走。腾讯可以搬走你的 skill，但搬不走你的 GitHub profile。所以开源不会因为白嫖者的存在而崩溃，真正受损的是"开源应该是互惠的"这个信念。

署名权的底线

当然，大厂不会蠢到明目张胆地删署名。它的做法更精明：LICENSE 文件原封不动地保留在代码仓库的某个角落里，但产品界面上用户看到的是"腾讯 SkillHub 精选"。你作为作者，技术上"被署名了"，实际上"被隐身了"。形式合规，实质隐匿。想告都找不到诉由。

微妙的均衡

但它也不敢大规模乱搞。万一哪天真搞出了集体诉讼，几千个开发者联名告腾讯侵犯署名权——法律后果另说，光是公关层面就是核弹级的。南山必胜客的战绩再辉煌，也扛不住这种舆论。

所以现状就是一个微妙的均衡：大厂精确地踩在"合法但无耻"的线上，开发者心里恶心但没有足够的动力去打破它。开源继续运转，白嫖继续发生，蛋糕继续被蟑螂爬。

最终还是要看实力，但腾讯已经要out了

至于腾讯本身，除了微信之外，我已经想不出有什么非用不可的理由了。在 AI 这波浪潮里，混元没声量，元宝没人用，SkillHub 是搬运工，然后像更年期一样躁动地炒作“小龙虾养殖”。一家曾经在移动互联网时代无处不在的公司，现在最大的 AI 动作是给别人的开源生态做中文镜像和搞“社区送鸡蛋营销”——总感觉仿佛回到了某个古老的过去。

这就比较尴尬了，因为在一个已经大幕开启的新时代，它虽然是过去的王者，但你不用它的东西，似乎也什么都不缺。

工具上瘾与专注的稀缺

AztecaAlpaca — Fri, 13 Mar 2026 00:00:00 GMT

磨牙

我对倒腾工具这件事有一种近乎本能的执念——IDE、Vim、Obsidian、Rime 输入法，什么都想配一遍。这种冲动不像是兴趣爱好，更像是有些人夜里磨牙：你不是在享受它，而是在释放某种说不清的压力。

仔细想想，这种行为至少有三层吸引力。

第一层是即时反馈的快感。改一个配置，效果立刻可见——主题变了、快捷键顺手了、补全更聪明了。这种"小修小补、即时回报"的循环，跟刷短视频的多巴胺机制是同构的，只是披着一层"我在提升生产力"的合理化外衣。

第二层是掌控感。日常面对的事情充满不确定性——模型收不收敛、结果有没有意义、论文能不能写完。但 .vimrc 是完全可控的，Rime 的方案文件改一行就生效一行。倒腾工具提供了一种"我在掌控一切"的心理补偿。

第三层大概最核心：逃避真正困难的事。当你沉迷于 Obsidian 的插件体系时，你其实是在回避打开那个还没写完的章节。工具折腾是一种高伪装度的拖延。

一个不断迁移的人

回顾过去几年，我在写作工具上的轨迹是这样的：

VS Code 时期，Markdown 插件试了五六款，到后来自己都分不清哪款是什么样。然后转向 Emacs，体验了 org mode，坚持了几个月，最终也放弃了。期间在 VS Code、PyCharm、Emacs 里都装过 Vim 键位插件，无一例外半途而废。

现在又到了 Vim。

每一次切换都有自己的合理理由。用 Emacs 的时候觉得笔记软件已经足够丰富，没必要在编辑器里重造轮子；用 Vim 键位插件的时候总有退路，不开心了直接关掉，恢复原来的操作方式。但把这些片段串起来看，工具本身从来不是瓶颈。真正的模式是：在不确定该往哪走的时候，用工具迁移来填充空白。

我曾经在笔记里写过一句话："我已经失去了捣鼓这些工具的欲望。"但后来我又开始折腾 Vim。这说明那个欲望并没有消失，只是换了个对象。

Vim：又一个新的开始？

目前我在用 Vim 写 Markdown。体验不敢说特别好，但也还行。

上手的挑战在于被一套全新的规矩框住，而且这套规矩极硬，根本不容商量。就像来到一个非常陌生的地方，除了肢体语言几乎没有其他方式与人交流。之前在各种编辑器里用 Vim 模拟插件，总有退路。而这一次，我选择直接进入原生 Vim。

我也试过 NeoVim，套用了 LazyVim 的配置，内容过于丰富，反倒无所适从。计划是先用原生 Vim 打基础，把基本操作内化，之后再逐渐切换。

坦率讲，我写那篇 Vim 笔记的目的不是为了产出什么有价值的内容，而是为了在练习中勾勒自己的心路历程。但正是这种"不为了什么"的写作，无意间把自己的状态暴露得最清晰。

真正的问题

我翻看之前的记录，发现里面写道："我现在处于一个特殊的节点，因为我不知道自己需要做什么。我对未来缺乏规划，所以难免陷入东一榔头西一棒子的状态。"

这句话和"倒腾工具像磨牙"是同一件事的两面。没有明确的目标在牵引，精力就自然流向阻力最小的方向：配置工具。不是工具不好，而是在没有目标的情况下，任何工具都只是拖延的载体。

虽然并不是很看得上那些把一个工具使用一万年的人，但不得不承认，当下真正稀缺的不是工具的丰富度，而是专注本身。试来试去，反倒把专注试没了。

所以真正值得问的问题可能不是"该用什么工具"，而是"我接下来到底要做什么"。工具的选择在目标确定之后会变得非常简单。重造轮子需要耗费心血，但比重造轮子更浪费的，是连自己要造什么都还没想清楚。

为 AI 协作建立项目规则的实践

AztecaAlpaca — Tue, 10 Mar 2026 04:00:00 GMT

结构整理完了，然后呢

前几轮花了不少时间把项目从一锅乱炖理成了层次分明的样子：代码归代码，数据归数据，测试归测试，实验归实验。目录结构看起来已经像那么回事了。

但真正开始频繁地让 AI 参与日常工作之后，发现了一个新的问题：结构清楚，不等于 AI 知道该怎么在这个结构里干活。

你让它帮忙改个模型，它可能把新代码放到了实验目录里。你让它跑个验证，它可能把结果直接输出到了根目录。你让它做代码审查，它可能检查了一堆代码风格问题，却完全没注意到一个关键的目录边界已经被悄悄打破了。

这不是 AI 不够聪明。这是因为项目里那些"这个目录只放这种东西""改了这里至少要跑一下那个测试""实验代码不等于正式实现"之类的规则，全都装在人脑子里，从来没有被写下来过。

用 `AGENTS.md` 把隐性规则写成显性约定

于是这一轮做的第一件事，就是在项目根目录放一份 AGENTS.md。

这个文件的定位很明确：它不是给人看的项目说明（那是 README.md 的事），而是给 AI agent 看的协作规则。里面写的是：各个顶层目录各自放什么、改了核心代码至少要做什么验证、输出产物该落到哪里、优先用哪个命令行入口。

写完根目录的 AGENTS.md，发现还不够。有些子目录有自己更严格的要求，但全塞在根目录的文件里会变得又长又杂。于是继续在几个关键位置加了局部的 AGENTS.md：

验证算例目录强调结构化报告、失败退出和输出目录归属
测试目录强调 fixture、baseline 和测试分层
核心装配模块强调内部分层边界和实验工作台与主线实现的区分
实验目录强调探索区不是正式实现入口，不要被误当主线引用

这些局部文件不重复根级规则，只补充本目录特有的约束。最终形成的是一个分层体系：根级 AGENTS.md 管全局协议，局部 AGENTS.md 管各自的细节。AI 在任何一个目录里工作时，两层规则都能看到。

代码审查：从临时 prompt 到可复用的 skill

AGENTS.md 解决了"在哪里干活"的问题，但还有一个高频场景没覆盖：代码审查。

以前的做法是每次需要审查时，临时给 AI 写一段 prompt，告诉它关注什么。问题是每次都要重新描述一遍，很容易漏掉某些该关注的维度。而且不同类型的改动，该审查的重点完全不同。

这次的做法是把审查流程做成 skill——一种可以反复调用的、带有明确规则和输出格式的工作流模板。而且拆成了两层：

通用层做了一个风险导向的 code review skill，负责所有项目都需要关注的基本风险：行为有没有被意外改变、有没有破坏性操作、失败了会不会留下脏状态、有没有不小心提交了敏感信息。它的定位是 commit 前手动触发、面向本轮 diff 做 findings-first 的输出。

项目专用层则根据这个项目最容易出问题的方向，拆成了三个独立的 review skill：

第一个审查结构边界。前面费了那么大力气把目录理清楚，最怕的就是一次不小心的改动又把边界搞模糊了——新代码放错了层级，共享逻辑又被复制到了某个算例里，搬了文件但忘了更新 README.md 和 AGENTS.md。

第二个审查模型与计算后端的关系。这个项目有一套比较精细的分层：子系统模型负责描述物理行为，系统级后端负责组装和求解。这几层的职责不能混淆，自由度顺序、矩阵约定、符号推导和数值实现的对照关系也不能发生静默漂移。

第三个审查验证链路和产物管理。测试和算例是不是又混到一起了？输出是不是落到了正确的位置？baseline 和 fixture 是否显式存放？有没有哪个验证其实偷偷依赖了上次手动跑出来的结果？

这种两层结构比把所有审查规则塞进一个 skill 更稳妥。通用层可以跨项目复用，项目专用层只关心当前项目特有的风险。需要审查时按改动类型选择性触发，不用每次都跑全套。

Skill 放哪里：从 `skills/` 到 `.skills/`

做完这些 skill 之后，项目目录里突然多了不少文件。它们不是主线代码，不是面向用户的文档，也不是数据——更像是一种开发辅助资产。

一开始建在项目的 skills/ 目录下，但总觉得不太对。打开项目根目录映入眼帘的是一堆审查规则模板，会让人以为这些是项目的核心内容。后来统一迁到了 .skills/。点开头的隐藏目录，存在但不碍眼，跟 .git、.venv 是一个思路。

同时还做了一个区分：只服务于当前项目的 review skill 放在项目内部的 .skills/ 里；而像阶段总结这种跨项目通用的工作流，则放在工作区根目录的 .skills/ 下面。项目级和工作区级各管各的。

阶段总结也做成了 skill

这一轮还顺手解决了一个一直存在但没正式处理过的问题：每轮工作结束后的阶段总结。

之前每次做完一轮工作，都会手写一份总结文档放到 docs/work-notes/ 里，记录做了什么、为什么这么做、还有什么没做完。习惯本身很好，但写法和格式完全看当时的心情，更关键的是这个过程从来没有被标准化过——全靠人记得要写。

这次在工作区根目录的 .skills/ 下建了一个会话总结 skill，把总结的生成流程也标准化了：默认输出到固定目录，用编号式命名，只有明确要求时才转写叙事性更强的复盘文章。规则里还特别强调了几条底线：不虚构没做过的事情，不把总结写成聊天记录的转录，要显式记录"讨论过但没做完"的问题。

这样做的意义在于：三个月后想回头查"当时为什么做了那个决定"时，有格式稳定、内容可靠的文档可以翻，而不是在一堆风格各异的笔记里大海捞针。

回过头看

这一轮做的事情，和前几轮性质很不一样。前几轮是在整理代码和目录结构——动的是项目本身。这一轮没有改动任何核心逻辑或模型实现，加的全是 AGENTS.md 和 .skills/ 里的东西——动的是"怎么跟 AI 协作"这一层。

如果说前几轮解决的是"这个项目长什么样"，这一轮解决的是"在这个项目里干活应该遵守什么规则、用什么流程"。从每次临时写 prompt 交代注意事项，变成写在仓库里、可以被版本管理的显式规则；从每次审查现场发挥，变成可以按类型触发的标准化 skill。

这些东西的价值不会立刻体现。不会因为多了几个 AGENTS.md，代码就突然变好了。但它们解决的是一个更长远的问题：当 AI 越来越频繁地参与项目工作时，你不可能每次都从头解释一遍"这个目录不能乱放东西""改了这里要跑那个验证"。这些东西必须被写下来，变成项目的一部分，跟着项目一起演进。

当然，写下来只是起步。这些 AGENTS.md 和 skill 到底好不好用、哪些过于繁琐需要简化、哪些还缺失需要补充——只有在实际使用中才能回答。就像前几轮整理得出的结论一样：不用追求一步到位，只需要保证这一轮比上一轮更清楚，就够了。

两轮项目结构整理的踩坑与反思

AztecaAlpaca — Mon, 09 Mar 2026 04:00:00 GMT

起因：当你发现自己在害怕打开某个文件夹

这轮整理的起点，其实不是某个技术决策，而是一种很具体的不适感：打开项目目录，不知道该看哪里。

这个项目已经"能跑"了。模型写好了，仿真跑得动，数据也能出图。但每次想改点什么，或者想回忆三周前某个参数到底放在哪里，都要花相当一段时间重新定位。目录结构是从最初"先写着试试"开始一路堆叠上来的，每个文件夹的存在都有合理的历史原因，但合在一起已经没有人能一口说清全貌了。

这不是"技术债"那种听起来很抽象的东西。这就是一种很日常的、每天打开项目都会多花十分钟的摩擦力。这轮整理，本质上就是在处理这股摩擦力。

第一步不是动手，是先弄清楚"这里面到底有几件事"

一开始的冲动是想赶紧动手：重命名文件夹、搬文件、删旧代码。但很快发现，如果不先搞清楚"这个工作区到底在做几件不同的事情"，搬了也白搬，过两周还是会乱。

于是先停下来，花了一整轮时间回答一个问题：这个目录里，到底混着几种不同性质的东西？

答案比想象的多。有主线实现代码，有实验性的另一套写法，有跑仿真用的参数数据，有建模推导留下来的说明文档，有跑出来的结果图，有测试脚本，有半成品的讨论稿，有已经过时但不敢删的旧模型。它们全都平铺在差不多的目录层级里，只靠文件名和记忆区分。

弄清楚这一点之后，才知道该怎么动手：不是按"新旧"分，而是按"性质"分。代码归代码，数据归数据，文档归文档，测试归测试，实验归实验。这听起来像废话，但在一个长期试验式推进的项目里，这些东西是天然混在一起的，因为它们确实是一起产生的。

"两套代码做着差不多的事"是最容易踩的坑

整理到中途，发现了一个比目录混乱更实质的问题：两条实现线里有好几块代码在做几乎一样的事。

这不是谁偷懒复制粘贴造成的。这是自然演化出来的。一开始只有一条主线，后来想试另一种写法，于是开了一条实验线。实验线需要用到一些基础功能——数值计算、数据解析、格式转换——主线已经写好了，但直接调用主线的代码会引入不想要的依赖，于是实验线自己也写了一份。

刚开始没什么问题，两份代码各走各的。但时间一长，主线那边改了一版，实验线这边没同步，两份代码就悄悄分叉了。更麻烦的是，哪份是"对的"已经说不清了。

这次整理的一个核心动作，就是把这些重复的功能找出来，抽到一个两边都能共用的地方。这件事听起来简单，做起来有一个很关键的前提：你必须先判断"这些重复的代码，本质上是不是真的在做同一件事"。有些看起来像，但仔细看其实在处理不同的情形；有些看起来不像，但底层逻辑完全一样。如果不做这一步判断就直接合并，反而会引入新的混乱。

最后抽出来的共享层不大，也就四个方向的基础能力。但这四个方向是两条线每次修改都会触碰的地方。把它们合到一处之后，"改了这边忘了那边"的问题至少在这个范围内消失了。

数据的归属感比代码更容易搞混

代码谁写的、归谁管，通常还比较明确。但数据往往不是。

项目里有一批数据，原来放在实验线的目录下面，看起来像是实验线的私有资产。但仔细一看，主线其实也需要这批数据，只是一直在用另一份格式不太一样的副本。

这种情况在研究型项目里特别常见：一份数据最初是为某个具体实验准备的，放在那个实验的目录里顺理成章。但后来这份数据变成了所有人都需要的公共输入，位置却没有跟着调整。结果就是要么到处复制，要么靠路径硬编码指向一个"不该属于你"的目录。

这次处理的方式是：把原始数据提到一个明确属于整个工作区的位置，然后写一个统一的前处理步骤把它转成标准格式，各自的实现线只使用自己目录下的标准化结果。这样，数据只有一份源头，但每条线都有自己干净的消费入口。

测试和算例的区别，比想象中重要

整理之前，"测试"和"算例"是混在一起的。有些脚本是自动化跑的、用来验证代码有没有改坏；有些脚本是手动跑的、用来看某个工况下的仿真结果。它们都放在叫"tests"的文件夹里。

这两件事的性质其实很不一样。自动化测试需要明确的输入、确定的预期输出、可重复运行。算例更像是一次实验，输入是研究者根据工况设定的，输出是拿来分析的，甚至每次跑的参数都可能不一样。

把它们混在一起的后果是：想跑自动化测试的时候，需要小心避开那些手动算例脚本；想加一个新算例的时候，又怕影响测试框架的收集规则。更深层的问题是，混放会让人搞不清"这个脚本的结果到底是已经验证过的基线，还是上次手动跑的一次性输出"。

分开之后，自动化测试有自己的目录和入口，算例有自己的目录和入口。测试可以放心地自动收集，算例可以自由地增减工况。各自做各自的事，不互相干扰。

文档的分层，解决的不是"写不写"的问题，而是"放哪里"的问题

这个项目不缺文档。理论推导写了，设计讨论写了，参数说明写了，实现笔记也写了。但这些文档全都放在同一个文件夹里。

问题不是内容不好，而是你在找一份东西的时候，不知道该在哪个文件里找。一篇偏理论总览的长文和一篇记录某次讨论结论的草案，性质完全不同，但它们并排放着，只靠文件名区分。

这次做的事情很简单：把文档按性质分成了几个子目录。理论说明放一处，讨论草案放一处，历史归档放一处。然后把那些跨项目的、更偏全局的文档上提到工作区根目录，不再挤在子项目的文档文件夹里。

这不是什么精巧的设计。但做完之后，"我要找那篇关于某某问题的讨论"这件事变得快了很多。

"先把问题定义清楚，实现留到以后"是一种有用的策略

整理过程中碰到了一些确实应该统一、但短期内没法一口气做完的问题。比如不同模型导出的中间数据格式不统一——都是矩阵，但字段名不一样、结构不一样、元信息不一样。

一开始想着要不趁这次整理一并处理掉。但仔细一想，这件事涉及到好几个模型的接口改动，而且需要先在实践中试验哪种格式更合理。强行在这一轮里做完，大概率做出来的方案也不对。

最后选择的做法是：写一份草案，把问题描述清楚，把当前状态记录下来，把后续需要做的事列出来，然后先不动代码。这样做的好处是：这个问题不会被忘掉，因为它已经被写成了正式文档并登记在待办里；但也不会因为急着收口而引入一个不成熟的方案。

这种"承认这件事当前做不完、但正式记录下来"的策略，在大规模整理中非常实用。否则要么什么都想一轮做完，结果哪个都做不好；要么做完之后忘了还有这个问题，几个月后又要重新发现一次。

删东西比加东西更难下决心

整理过程中最犹豫的环节，不是"把这个文件搬到哪里"，而是"这个旧目录还要不要留着"。

理性上知道，一个已经被完整迁移走的目录，留在原地只会误导后来者。但感性上总觉得删了就"回不去了"。尤其是那些旧模型、旧测试、旧的目录结构——删掉之前总想着"万一以后还要参考呢"。

最后的处理方式是：真正需要保留的旧实现，给它一个正式的"归档"身份，放在一个明确标注为归档的位置，附带足够的说明让它可以独立运行和理解。而那些只是"搬走之后剩下的空壳目录"，直接删掉，不留恋。

这个决策过程的启发是：保留旧东西的正确方式不是"原地不动让它慢慢腐烂"，而是"给它一个明确的安置方案"。要么正式归档，要么果断删除。卡在中间的状态最消耗心力。

每搬一个文件，就要更新一处说明

这是整理过程中最枯燥、也最容易遗漏的部分。每次移动一个目录、改变一条数据链路、调整一个入口脚本，都需要同步更新相关的说明文档和指引。

忽略这一步的后果很明确：代码和文档立刻脱节。一个新加入项目的人——或者三周后的自己——按照文档找路径，发现路径已经不存在了。这种脱节如果不在改动发生的当下就修复，之后再补的成本会成倍增长，因为你已经忘了当初为什么搬、搬到了哪里。

这次整理坚持了一个原则：每完成一次结构调整，立刻更新所有受影响的说明文件。不攒着，不拖到最后一起改。这个过程确实很慢，大量时间花在更新那些看起来不起眼的说明文档上。但回头看，这些即时更新的文档，才是整理成果能"活下来"的保证。

回过头看：整理不是一次性的事

做完这两轮之后，最强烈的感受不是"终于搞好了"，而是"原来这个过程必须是渐进的"。

第一轮把工作区从一个混合仓拆成了几个独立项目，理清了大的边界。但做完之后发现，其中一个子项目内部的问题暴露得更明显了——原来被整体的混乱掩盖着的内部结构问题，在外围清晰之后反而更扎眼了。于是有了第二轮，专门针对这个子项目内部进行重新梳理。

这不是第一轮做得不好。这就是整理工作的本质：你不可能一步到位看清所有层级的问题。每一轮整理都是在当前能看到的层级上做力所能及的收口，做完之后视野更清楚了，然后才能看到下一层该做什么。

接受这一点之后，心态会轻松很多。不用追求"一次做到完美"，只需要保证"这一轮确实比上一轮更清楚"，就够了。

最后

如果要用一句话总结这两轮整理的核心经验，大概是这样：

一个项目最容易腐烂的部分，不是代码逻辑，而是目录结构和文档。因为代码不对会报错，但结构不对只会让你每天多花十分钟。这十分钟不致命，但会慢慢磨掉你继续推进的意愿。

定期花时间把结构理一理、把边界画清楚、把过时的东西归档或删掉、把当前的状态写下来——这些事不紧急，但它们决定了一个项目到底是"能跑一阵子"，还是"能一直跑下去"。

一次失控项目的目录整理复盘

AztecaAlpaca — Sun, 08 Mar 2026 16:30:00 GMT

这次整理面对的是一个在长期探索式开发中逐步生长起来的工作区。年前赶进度的那段时间，所有精力都花在功能推进上，新的实验不断往里加，旧的尝试没空清理，文档、数据、中间产物随手放在离代码最近的地方——"先跑通再说"。当时这样做是合理的，毕竟时间紧迫，整理是可以推迟的事。

但过完年再打开这个项目时，情况就不一样了。一个月的间隔足以让人忘掉大部分上下文：哪些目录是正在用的，哪些是废弃的尝试？这个文件为什么放在这里？那个脚本到底是主线的一部分还是某次调试的临时产物？目录结构已经从"反映当前项目边界"退化为"记录历史开发过程"，打开项目看到的不是清晰的功能分区，而是一座小型屎山的横截面。面对这样的项目，心里甚至产生了一种畏惧感——不是因为技术难度，而是因为认知负担太重，不知道从哪里下铲子。

这正是启动整理的直接原因——不是为了追求完美的工程规范，而是因为现有结构已经开始拖慢实际工作，甚至阻碍了继续投入的意愿。

整理过程

第一步：识别边界，而非急于搬迁

整理的起点不是"把文件移到看起来更合理的地方"，而是先弄清楚当前工作区里到底有几类东西、它们之间是什么关系。

在动手之前，先对所有内容做了一轮语义分类：哪些是正在开发的主线，哪些是曾经的实验但已经停止推进，哪些是辅助工具、哪些是数据源、哪些是生成出来的中间产物。这一步花了不少时间，但它决定了后续所有搬迁操作的方向，避免了反复挪动。

第二步：把"混合总仓"拆成独立项目

原来所有内容共用一个 Git 仓库，什么都往里扔，日积月累就成了一锅乱炖。一个工具的提交记录和主线研究的提交记录混在一起，不仅看不清历史脉络，也给回溯带来障碍。

拆分的原则很简单：如果两个东西的生命周期不一样、维护频率不一样、关心它们的人不一样，它们就不应该共用一个仓库。拆分时，旧仓库的 .git 目录被重命名保留而非删除，确保历史可追溯。每个新项目各自初始化独立的 Git 仓库，拥有自己的版本历史和忽略规则，互不干扰。

第三步：在主项目内部建立层级

仅仅拆分项目还不够，主项目内部同样需要分层。主线实现、实验性实现、已经冻结的旧实现、原始数据、说明文档被分别放到不同的位置，并且为每一层制定了明确的定位。

其中最有价值的一个区分是对实验内容的三级划分：仍在推进的、需要兼容保留的、已经冻结归档的。这种分类让人一眼就能判断某个目录的状态，不需要打开文件去阅读才能知道"这东西还活着吗"。

第四步：分离"人维护的"和"机器生成的"

在整理之前，手工编写的数据、自动生成的中间产物、运行输出的结果文件混放在一起。这带来两个问题：一是很难判断哪些文件需要手动维护、哪些可以重新生成；二是 Git 的提交历史中充斥着大量无意义的变更记录，真正重要的改动反而被淹没。

解决方案是建立清晰的流向：人维护的原始数据放在固定的位置，通过明确的转换步骤生成运行所需的配置文件，而运行结果则通过 .gitignore 排除在版本控制之外。这样，仓库里保存的始终是"源"，而不是"果"。配合精心设计的忽略规则，少量需要长期保留的参考结果仍然可以被显式地纳入追踪，不会被一刀切地排除。

第五步：为归档内容设立标准

对于那些已经不再开发但仍有参考价值的旧实现，归档标准是明确的：归档内容必须能够独立运行，不依赖主线中随时可能变化的部分；必须有自己的入口说明和必要的参考结果。这样即使过了很长时间，想回头验证某个旧方案时也不需要考古式地拼凑运行环境。

收获的经验

目录结构应该反映当前的项目边界，而不是开发历史的时间线。 如果一个目录的存在需要口头解释才能被理解，说明它的命名或位置有问题。好的结构应该是自解释的。

先分类，再搬迁。 急于移动文件而没有想清楚分类标准，往往导致移了又移。花在前期辨析上的时间不是浪费，而是对后续工作的保护。

区分"源"与"果"是整理中最重要的原则之一。 需要人维护的输入数据、代码、文档是"源"，它们应该被 Git 追踪。构建产物、运行结果、缓存文件是"果"，它们可以从源重新生成，不应该污染提交历史。善用 .gitignore 把这条线画清楚，是保持仓库整洁的基本功。

实验和主线的边界越模糊，维护成本越高。 实验性的东西如果放在主线目录里，时间一长就分不清它到底是正式功能还是临时尝试。给实验内容一个明确的"身份"和"住所"，可以大幅降低认知负担。

整理不需要一步到位。 这次整理结束后仍有一些未完全收口的部分。重要的是建立起足够清晰的框架，让后续的收口工作可以在已有框架内渐进完成，而不是再来一次大规模重组。

记录整理本身。 整理过程中做了什么决策、为什么这样分、哪些事情还没做完——这些信息如果不记录下来，几周后就会遗忘，然后要么重复劳动，要么困惑于当初为什么这样做。整理工作的文档化和整理本身一样重要。

善用AI工具处理高密度的结构性工作。 这次整理全程借助AI编程助手完成，总共只花了两三个小时。项目整理这类工作的特点是：判断标准清晰但操作步骤繁琐——需要逐个检查文件归属、修改引用路径、调整忽略规则、补写说明文档。这恰好是AI工具最擅长的领域。人负责制定分类标准和做关键决策，AI负责执行大量重复性的搬迁、检查和文档生成。这种分工让整理工作从"大半天的苦力活"变成了"两三个小时的协作流程"，也大大降低了启动整理的心理门槛。

结语

项目整理不是一项额外的负担，而是对开发效率的投资。一个被整理过的工作区，让人打开目录就知道该去哪里找东西、新的内容应该放在哪里。这种清晰感会在后续每一天的工作中持续产生回报。

回头看，年前没有及时整理并不是错误——那时候赶进度是对的。但过了一个月再回来时产生的畏惧感提醒我：推迟整理是有利息的，间隔越长，认知负担的利息越高。屎山不是一天堆成的，但放着不管，它真的会越长越高。下一次，也许不必等到已经感到畏惧才开始。整理的最佳时机是项目还没有大到无法控制的时候——但如果已经大了，那最佳时机就是现在。

三大纪律八项注意：一张个人生活审查表的诞生

AztecaAlpaca — Sun, 08 Mar 2026 02:00:00 GMT

缘起

富兰克林的美德审查法我很早就知道——最初是读吴军的文章时接触到的：十三项美德、每周聚焦一条、每晚对着小册子打点。这个思路两百多年了，至今仍然是我见过的最简洁有力的个人审查框架。后来读了富兰克林自传原文，对这套方法更加感兴趣，也确实尝试过几次，但每次都没能坚持下来。原因说起来也简单：首先自己的意志力有限，这种繁琐的事情很难坚持。另外，他的十三项美德带着十八世纪费城中产的气息，节制、沉默寡言、贞洁，这些词和我的实际生活之间隔着一层，用起来总觉得不贴身。

另一个一直放在心里的东西是德尔斐神庙的铭文——"认识你自己""凡事勿过度""妄作承诺，祸患随之"。这三条我知道很久了，一直觉得很有分量，但始终不清楚怎么把它们从格言变成可以日常操作的东西，怎么融入对自我的具体塑造中。

所以当我决定再做一次尝试时，想法很明确：不是复刻富兰克林，而是借他的结构，填入属于我自己的内容，同时把德尔斐那些一直悬在空中的原则也找到落点。框架上，我想用一个更有中国味道的壳——"三大纪律八项注意"。

两个AI，两种角色

这件事做下来，我用了两个AI深度参与，各自发挥了不同的长处。

GPT的核心优势在于记忆。我和GPT的长期对话让它对我积累了相当多的上下文——我的工作方式、思维偏好、表达习惯、甚至我对什么东西不耐烦。所以当我抛出"我想做一个三大纪律八项注意"这个想法时，它不是从零开始的泛泛建议，而是直接带着对我的了解来展开。它很快就给出了一个覆盖面相当宽的方案，从身体管理到认知习惯到精神趣味，还专门做了一个"按你本人气质定制"的版本，措辞比通用版更锋利，比如"别让底盘先烂""别把夜晚活成无底洞"。它提出的那句"不媚俗"，确实说到了点上。这种定制感，如果没有记忆功能是做不到的。

但铺开之后需要收拢。这时候我把GPT的方案拿给Claude。Claude的长处不太一样——它的文风更好，对话时比较能抓住重点，不容易跑偏。

Claude上来就指出了几个我自己没注意到的结构缺陷。最关键的一个："不失控"作为顶层纪律，和下面八项注意里的欲望、节律、表达大面积重叠，导致层级混乱——几乎每一条注意都可以归到"不失控"下面，那它作为独立纪律的区分度就不够了。Claude建议换成"不回避"，理由是对我来说，空转的另一面往往不是失控，而是退缩和拖延。这个判断很准。换完之后，三条纪律形成了一条清晰的逻辑链：看清自己（不自欺）→ 迎上去（不回避）→ 做出来（不空转）。

另一个修改是把"身体"和"节律"合并。原版这两条说的是一件事的两个面——"别让底盘先烂"和"别把夜晚活成无底洞"——合并后信息量没损失，还腾出了结构空间。Claude也建议拿掉独立的"不媚俗"，因为它的内涵已经被"注意趣味"和"注意判断"联合覆盖了，单独立一条反而有滑向"只批评、不建造"的风险。

回头看，两个AI的配合里，记忆是最关键的变量。GPT因为记忆积累得更深，在生成阶段能做到真正的个性化——不是"所有人都应该注意欲望管理"，而是它知道我具体在哪些方面容易出问题。Claude同样有记忆，在审查时也能调用对我的了解来判断优先级。这种个性化不是完美的——AI的记忆有时会过度推断，有时会遗漏——但确实比每次从零开始的冷启动要好得多。可以说，如果没有记忆功能，这套东西最多只能做到"通用的好"，而不是"适合我的好"。

德尔斐的校准

框架初步成型之后，我把一直放在心里的德尔斐铭文拿了出来。

前面说过，德尔斐最著名的三条箴言——γνῶθι σαυτόν（认识你自己）、μηδὲν ἄγαν（凡事勿过度）、Ἐγγύα πάρα δ᾽ Ἄτα（妄作承诺，祸患随之）——我知道很久了，一直觉得有分量，但始终不知道怎么把它们从墙上的格言变成日常可操作的东西。这一次，当三大纪律八项注意的框架已经立起来之后，我忽然发现它们有了可以嵌入的位置。

"认识你自己"让我意识到，"不自欺"只完成了一半的工作。不自欺是被动的防守——别骗自己；但"认识你自己"还要求主动的自我探查——我的真实动机是什么？我以为自己想要的，是真的想要还是虚荣在驱动？于是第一条纪律从"不自欺"扩展为"认识自己，不自欺"，前半句进攻，后半句防守。

"凡事勿过度"更有意思。我发现自己整个八项注意的底层逻辑其实都在说这件事——别吃太多、别说太多、别刷太多——但从来没有把它显性化。而且对我来说，这条原则需要双向使用：不仅防过度放纵，也防过度收缩。过度自律和过度放纵一样是失衡。于是"注意欲望"那条被改写为双向表述："不做快感的奴隶，也别做苦行僧。"

最后一条——"妄作承诺，祸患随之"——补上了一个真正的盲区：承诺管理。很多空转的根源不是懒，而是承诺太多、兑现太少，然后用自欺来处理落差。六个字就够了："不轻诺，已诺则必兑。"这被融入了第三条纪律。

三处改动，每处都不大，但都补上了AI生成阶段没有触及的东西。经典文本的价值正在于此——它不帮你生成内容，但它帮你发现盲区。

从原则到执行

有了内容还不够，还需要一个能实际运行的执行方案。

这部分的设计同样借鉴了富兰克林的原始思路，但做了关键调整。富兰克林是十三项美德每周轮一条，十三周一轮，一年四轮。我的版本是三加八的混合结构：三大纪律每天审查，因为自欺、回避和空转是日常级别的威胁，隔天不查就会滋生；八项注意每周轮换聚焦一条，奇数月聚焦前四项（节律、专注、表达、判断），偶数月聚焦后四项（边界、欲望、积累、趣味），两个月覆盖一轮，全年六个完整周期。

审查方式追求极简：空白表示做到，●表示违反，○表示部分违反。每晚三到五分钟，对着表格扫一遍，不写长篇日记，不搞复杂评分。富兰克林的智慧在于他理解人的注意力是有限的——审查工具本身如果太复杂，它就会成为另一件被拖延的事。

有几条执行原则是我特意加进去的。比如"不补记"——忘了就空着，不要第二天回头填，因为补记是自欺的温床，直接违反第一条纪律。再比如"标记从严，心态从宽"——宁可多标几个黑点，也别美化自己，但不要因为黑点多就沮丧。富兰克林做了一辈子也没达到全空白，重要的是趋势向好，不是完美。

用AI碎碎念来喂养这张表

设计好了审查表，下一个问题是：怎么让它真正融入日常生活，而不是又一次三分钟热度？

我的想法是借助AI来降低执行摩擦。我平时有大量的碎碎念——在Telegram里随手发的感想、和AI对话时的自我反思、甚至睡前脑子里跑过的念头。这些碎片化的内容其实天然包含了审查表需要的原始素材：今天是不是又熬夜了（节律）、有没有刷手机刷到停不下来（欲望）、是不是答应了别人的事又没做（承诺）、有没有逃避一个该面对的问题（回避）。

问题是，这些信息散落在各处，靠自己每晚回忆和整理太累了——这正是之前每次尝试都半途而废的原因。而AI恰好擅长做这件事：把非结构化的碎碎念整理成结构化的审查输入。

具体来说，我可以创建专门的skills来完成这个闭环：一个skill负责从我的日常记录（Telegram消息、对话片段、随手笔记）中提取和审查表各条目相关的信号；另一个skill负责把这些信号汇总成当天的审查建议——哪些条目可能需要标记，哪些做得不错。我不需要AI替我做判断，但它可以帮我把素材摆到桌面上，让每晚的三到五分钟审查变得更高效、更有依据，而不是纯靠模糊的记忆。

这本质上是用AI做了一层"注意力基础设施"：它不替你审视自己，但它帮你把需要审视的材料准备好。就像富兰克林的小册子降低了审查的仪式感门槛，AI的整理能力降低的是信息收集的门槛。两者叠加，才有可能让这套方法真正变成日常习惯，而不是停留在一篇写得漂亮的文章里。

关于方法的一点反思

整个过程走下来，有几件事值得说。

第一，AI协作的分工比能力更重要。GPT和Claude在能力上有大量重叠，但我让它们做不同的事：GPT凭借更深的记忆积累做个性化生成，Claude凭借更好的文风和抓重点的能力做结构审查。这不是因为它们"只能"做各自的事，而是因为分工本身让流程更清晰。同一个模型同时生成和审查自己的内容，效果远不如两个模型交叉进行——就像作者和编辑最好不是同一个人。

第二，记忆功能是这次尝试和之前失败的最大区别。以前试着照搬富兰克林的方法，用的是通用模板，和自己的实际情况对不上，自然坚持不了。这次GPT因为记忆的积累，生成的内容从一开始就是有针对性的；Claude在审查时也能基于对我的了解做出判断。AI的记忆远不完美，它对你的了解是碎片化的、有偏差的。但即便如此，它也比冷启动好出一个量级。

第三，经典文本的校准作用不可替代。AI可以帮你生成、迭代、打磨，但它很难替你去寻找那些跨越时间的参照系。德尔斐三条不是我让AI搜出来的——是我自己想到的，然后拿来和AI一起分析它的适用性。这个"想到"的过程，依赖的是阅读积累和直觉，不是提示词工程。AI是好工具，但你得知道拿什么去喂它。

第四，也是最重要的一点：审查表不是目的，使用它才是。富兰克林自己说过，他从未达到十三项美德的完美，但尝试的过程让他"成为一个更好、更快乐的人"。这套三大纪律八项注意也一样——它的价值不在于写得多漂亮，而在于每天晚上真的打开、真的审视、真的标记。如果它变成了一份束之高阁的精神装饰品，那它就违反了自己的第三条纪律：不空转。

所以，这就是这张表的来历。它从富兰克林出发，经过GPT的头脑风暴和Claude的结构审查，被德尔斐的古老箴言校准了一次，最终变成了一份每月一页、每天三分钟的个人审查工具。

它肯定不完美，但重要的是能够融入我的生活。而用AI整理碎碎念来辅助填表这个想法，本身就是这套方法论的一次实践——用工具降低摩擦，让好的习惯更容易坚持下去。正如富兰克林会说的：重要的不是完美，而是你每天都在翻开那一页。

一次深夜排障：以为是自己的锅，结果是 GitHub 宕机了

AztecaAlpaca — Fri, 06 Mar 2026 00:00:00 GMT

发现问题

事情发生在 3 月 5 号晚上。

我的博客有一条自动化链路：在 Telegram 里发一条消息，内容会自动同步到网站上。这条链路已经稳定运行了两周多，我一直没怎么操心过。但那天晚上我发完消息后，习惯性地刷了一下网页，发现内容没有更新。

一开始我没太在意，以为是缓存延迟，等了几分钟又刷了几次，还是没有。于是打开 GitHub 的 Actions 页面看了一眼——果然，最近的几次 push 之后，部署流程根本没有被触发。

第一反应：肯定是我改出了 bug

就在两天前，我刚刚调整过一个定时任务的频率，把原来每半小时检查一次改成了一天只在几个固定时段检查。当时觉得是个很小的改动，甚至没怎么仔细看就提交了。

所以第一反应就是：肯定是这次改动搞坏了什么。

我马上打开配置文件，反复对比改动前后的差异，逐行检查有没有不小心动到触发条件。看了好几遍，逻辑上没毛病，改的确实只是定时频率，跟 push 触发完全无关。

但问题就是摆在眼前——push 之后确实不触发了。那不是这次改动的问题，还能是什么呢？

越查越深，越改越多

带着"肯定是配置有问题"的执念，我开始往更深的地方挖。

回过头翻了翻更早之前的提交记录，发现两周前为了防止机器人账号的 push 触发重复部署，我加了一条过滤规则。当时这个改动运行得很正常，但现在我开始怀疑是不是这条规则在某种边界情况下误伤了正常的触发。

于是我把这条过滤规则去掉了，又重新整理了一下触发逻辑，让整个部署配置变得更"健壮"一些。改完之后提交，push 上去，满怀期待地等着看 Actions 页面……

还是没触发。

手动触发也失败了

这下我有点慌了。既然 push 不行，那我手动触发总可以吧？

于是我去 Actions 页面点了"Run workflow"按钮。结果页面弹出一行红字：

Failed to queue workflow run. Please try again.

试了好几次，每次都是同样的报错。

这就很反常了。手动触发跟配置文件的触发条件完全无关，它走的是另一条路。如果连手动触发都失败了，那问题可能根本不在我的配置上。

开始怀疑不是自己的问题

为了进一步确认，我写了一个极其简单的测试流程，里面什么都不做，就打印一行文字。把它提交上去，然后 push 一次。

依然没有触发。

紧接着我又用命令行直接调用 GitHub 的 API，手动发起一次触发请求。这次 API 返回了一个服务器内部错误，HTTP 500。

到这里，事情已经很清楚了：这不是我的配置问题，是 GitHub 那边出了状况。

确认：GitHub Actions 宕机

我去查了 GitHub 的状态页，虽然当时状态页上没有明确标注 Actions 全局故障，但结合手动触发失败、API 返回 500、push 事件明明已经记录了但就是不触发这几条证据，基本可以确定是 GitHub Actions 的调度服务出了问题。

后来也确实看到了一些其他开发者在社交媒体上反映同一时段遇到了类似的问题，进一步印证了这个判断。

回过头来看

整个排障过程大概花了两个多小时。最让人哭笑不得的是，前面大部分时间都花在了反复审视自己的配置上，改了好几轮，越改越复杂。直到最后发现手动触发都不行、API 也返回 500 的时候，才反应过来：问题不在我这边。

最后的结果是，我前面改的那些东西全都没有意义，配置也没有任何实质性的升级。等 GitHub 那边恢复之后，一切就自动正常了。两个多小时的折腾，纯粹是在跟一个不存在的 bug 较劲。

这次经历给我最大的教训是：当问题出现时，不要一上来就假设是自己的错。尤其是当依赖的平台和服务本身也可能出问题的时候，应该尽早建立一条验证链路——先确认问题到底出在哪一层，再针对性地修复，而不是在自己的代码里反复折腾。

当然了，凌晨一点钟排查 bug 的时候，这种理性的思路是很难保持的。下次再遇到类似情况，我希望自己能早一点想起来去试一下手动触发，而不是在配置文件里钻两个小时的牛角尖。

一轮体验修补：让网站用起来更顺手

AztecaAlpaca — Wed, 04 Mar 2026 00:00:00 GMT

事情的起因是推文整理。我把过去备份的推文筛选之后导入到了博客的笔记区，一下子多了两百多条内容。导入之前首页加载一直挺流畅的，但这两百多条进来之后，明显感觉到首页变卡了——打开时卡片先刷出来一大片，日历却要等好一阵才出现，整个页面像是在一块一块地拼装。

这让我意识到，之前"所有内容全量加载"的方案已经扛不住了。除了首页卡顿之外，我还注意到文章列表里偶尔有卡片因为标题太长而撑得特别高，打破了整体节奏；主题页面的分割线也是有的有、有的没有，看着不统一。

既然要动首页，不如把这些积攒的体验问题一并处理掉。于是开启了这一轮集中修补。

首页为什么打开那么慢

一开始以为是动画或者脚本写得不好，排查之后发现根本不是那回事——问题出在页面本身太大了。当时整个首页导出的文件大概有两三兆，所有内容一股脑全塞在里面，浏览器光解析就要花不少时间。日历排在最后面，自然就最后才出现。

知道原因以后，思路就清楚了：不需要一次展示所有内容，先显示最近的四十条就好，之后每次点"查看更多"再多加载一批。改完以后，首页文件大小从两三兆降到了两百多K，打开时那种"先闪一大片再慢慢拼装"的体感基本消失了。

日历跳转：一个看似简单实则棘手的功能

首页不再一次性加载全部内容之后，新的问题来了——如果用户点了日历上某个日期，但那天的内容还没被加载出来怎么办？

直觉上觉得不难：先把对应的内容加载出来，再跳过去就好了。但实际操作的时候发现一个时序问题：内容加载需要时间，如果加载还没完成就立刻去跳转，会找不到目标位置。最后的办法是先记住"要跳到哪里"，等内容真正出现在页面上之后再执行跳转动作。这种"先记后跳"的模式虽然不复杂，但如果一开始没想到，很容易在这里卡住。

笔记页面也做了类似的改造——一次先显示十条，之后每次多加载五条，但保留了完整正文而不是只给摘要。笔记毕竟是用来认真读的，只展示开头几行没什么意义。

阅读顺序的小陷阱

改布局的时候还碰到一个有意思的事。之前首页用的是一种"瀑布流"排列方式，内容从上到下填满一列再流到下一列。视觉上挺好看，但阅读顺序是从上到下、再从左到右——也就是说你读完左边一整列才会接到中间那列。

这对全量展示没什么问题，但分批加载的时候就别扭了：你点"查看更多"，新内容可能出现在第一列底部而不是最后一行下方，和心理预期完全不符。所以最终把首页和文章列表都改成了"先横后纵"的网格排列——每一行从左到右排满三个再换行，更符合"往下翻"的习惯。

主题页面的视觉混乱

主题页面的问题比较典型：分割线有两套规则在同时生效，一套是容器级别的，一套是每个条目自己加的。两套规则叠加的结果就是有些地方线多了，有些地方又没有线，看着很乱。

解决方法其实很简单——只让一方负责就行了。最终统一由容器来控制分割线，每个条目只管自己内部的内容，不再各自加边框。道理不复杂，但在样式一层层叠加的过程中，很容易不知不觉就搞出这种"双重管辖"的局面。

顺带还给主题里的书单补齐了几本已经写过读后感的书，按年份做了分区标题，让内容和结构对应得更清楚。

构建过程中的"幽灵报错"

这轮改动过程中，构建工具好几次报出莫名其妙的错误——说找不到某个页面模块。查来查去发现和我改的代码完全没关系，重新跑一次就好了，过一会儿又可能再冒出来。

这种间歇性问题很考验判断力。如果把它当成自己写出来的 bug 去排查，会浪费大量时间；但如果完全忽视，万一真有一次是代码问题又会漏掉。最后的策略是多跑几次确认它确实是随机出现的，确认后继续专注在功能验收上，不被干扰。

几点感悟

这轮工作让我印象最深的有三件事。

第一，性能问题要先搞清楚瓶颈在哪，不要上来就猜。这次如果凭直觉去优化动画或者压缩图片，完全是在浪费时间——真正的瓶颈是页面体积太大。

第二，看起来很小的布局决定（比如"先横排还是先竖排"）会在特定场景下产生意想不到的影响。这种事很难提前预见，只有在实际使用中才能发现。

第三，像主题页书单这样的内容区域，不能建好就不管了。随着文章不断积累，内容之间的链接关系也需要持续维护，否则信息结构会慢慢散掉。

把散落的推文变成有价值的笔记

AztecaAlpaca — Wed, 04 Mar 2026 00:00:00 GMT

这次做的事情说起来很简单：从以前的推文备份里，挑出值得长期保留的内容，整理成博客上的笔记。

但"简单"只是说起来简单。真正动手之后才发现，从一堆原始数据里提炼出有价值的东西，比写一篇新文章还费劲。

为什么要整理推文

推文备份一直躺在数据文件夹里，JSON 格式，几千条。这些内容里有不少是当时认真想过、认真写过的——个人观点、生活感受、某个瞬间的想法。但混在里面的也有大量噪音：转发的摘要、AI 工具的使用记录、绘图相关的技术参数，等等。

如果不做整理，这些有价值的内容会永远埋在噪音里，既没法浏览也没法检索。我希望把它们沉淀到笔记区，和其他日常随笔放在一起，成为一种可以回顾和再利用的资产。

筛选：不是留得越多越好

一开始的思路是按文字长度来筛——超过三百字的保留，太短的丢掉。但很快发现长度只是最粗的一层过滤，远远不够。一条三百字的 AI 摘要转发没什么保留价值，而一条一百多字的个人感悟可能恰恰值得留下。

于是筛选变成了好几层叠加：先按长度初筛，再排除掉模板化的提示词内容、非中文帖子、AI 绘图相关帖子，最后再判断剩下的内容是"个人表达"还是"信息搬运"。

这个过程让我意识到，内容筛选的标准特别容易在"过宽"和"过严"之间摇摆。放宽了会混进大量噪音，收紧了又可能误伤真正有价值的东西。最终的办法是把筛选分成硬性规则和软性判断两层——硬规则用来排除明显不要的，软判断用来甄别模糊地带——同时保留每一步的中间结果，万一筛错了可以回退重来。

去重：避免重复劳动

筛选之后还要做一步去重——之前已经整理过一批推文了，不能把已经存在的内容再导入一遍。方法是把现有笔记里出现过的所有推文链接提取出来，和新的候选列表做比对，剔除重复的。

这一步看起来简单，但如果漏掉了，就会出现同一条推文在笔记里出现两次的情况，后续清理起来很麻烦。

整理成笔记：单条还是按天合并

筛完去重之后，下一个问题是怎么组织这些内容。一开始是每条推文生成一个独立文件，但这样文件数量太多，浏览起来碎片感很重。后来改成按日期合并——同一天的推文放在同一篇笔记里，按时间顺序排列，每条都附上原帖链接以便回溯。

这种"按日聚合"的方式阅读体验好很多，更像翻一本日记，而不是一堆散落的便签。

格式打磨中的反复

整理到格式阶段又出了不少小问题。一开始用每条推文的第一句话做子标题，但有些帖子的开头并不适合做标题，读起来莫名其妙。后来统一改成了纯编号——"1、2、3"——简单直接，不容易出错。

还有一个低级但恼人的问题：生成文档的摘要信息里，推文条数显示成了"undefined条"。原因是计数逻辑取错了位置，改成直接数文档里实际有多少条就解决了。这种小问题不难修，但如果没发现就发布出去，会让人觉得很不专业。

一次让人恼火的"降智"事故

这轮工作我全程用 Codex 辅助编程。大部分时候它表现得很稳定，但在整理后期发生了一件让我相当恼火的事——在调整"哪些文件保留、哪些清理"的过程中，Codex 似乎完全忽略了上下文里已经隐含的意图，把之前辛苦整理好的成果也一股脑删掉了。

客观地说，实际损失并不大，几分钟就修复了。但那一瞬间的感受非常不好——你明明一路小心翼翼地推进，结果助手突然来一个毫无道理的操作，把你做过的工作抹掉一部分。那种"我到底能不能信任你"的不安感比损失本身更让人难受。我甚至忍不住当场怼了 Codex 一顿，虽然我也知道骂它并没有什么实际意义。

冷静下来之后想了想，问题出在我过于依赖它"应该能理解当前状态"这个假设。AI 助手在连续操作中会丢失上下文、混淆指令方向，尤其是在"保留"和"删除"这种语义相反的操作之间频繁切换时。事后我调整了工作方式：执行删除之前先列出完整的待删清单做二次确认，删完之后再做目录对账。对于这类内容，尽量采用"整体重建目标状态"的方式，而不是在现有文件上反复做局部修补——后者太容易出错了，不管操作者是人还是 AI。

意外收获：提示词的整理

推文里还有一类特殊内容——AI 绘图的提示词。有些帖子是"图片在主帖、提示词在回复"的模式，需要把上下文配对起来才能还原完整信息。

最终只保留了那些确实能提取出完整提示词的条目，把质量不够的一律放弃。宁可少收一些，也不要让垃圾混进来降低整体质量。这些提示词按主题归类后单独存放，作为以后复用的素材库。

几点感悟

第一，内容整理的核心不是"保留尽可能多"，而是"保留真正有价值的"。放低标准看似省事，但会让后续的浏览和检索体验变差，最终这些内容还是没人看。

第二，批量处理内容的时候，一定要保留中间状态。筛选标准随时可能调整，如果每一步都是不可逆的，一旦判断失误就只能从头来过。

第三，自动化和人工判断各有所长。机器擅长做硬性规则的过滤（长度、语言、关键词匹配），但"这条内容是不是值得留下"这种偏主观的判断，还是需要人来拍板。好的流程是让两者各司其职，而不是试图用其中一方完全替代另一方。

独立开发近况与 AI 编程心得

AztecaAlpaca — Sun, 01 Mar 2026 00:00:00 GMT

最近密集地做了好几个开发项目。二月底手头额度充裕，我索性把 GitHub Copilot 和 Windsurf 直接当 Agent 深度使用，开发效率拉满。不过进入三月，额度重新计算，得稳着点用了。

趁此机会，回顾一下近期做的几件事，以及在这个过程中对 AI 辅助编程的一些新认识。

近期项目回顾

网站升级

给个人网站加了一个新功能：在 Telegram 输入信息后自动同步到网页上。从家里回来之后，又参考了 AMP 的网页设计风格，把页面美化了一番，看起来精致多了。

网页版简历

帮一个朋友把 CV 做成了网页版并进行了优化。不过他更希望自己来搞，婉拒了我的好意——只能说很遗憾。但我还是把成品挂在了自己的站点上，没事翻看一下，颇有成就感。

流量监控面板

做了一个用来查看 VPN 流量记录的 Dashboard。以前主要写前端，很少碰后端，这次终于把后端数据处理的功能加上了，还修复了一些 bug、提升了性能。这次尝试让我对前后端的交互有了更完整的了解。

重启 DoneList 项目

把之前搁置的 DoneList 项目重新捡起来开发了一波。虽然雏形已出，但感觉偏离了初衷——本来是为了逃离传统的 Todo list 软件，结果做出来越来越像市面上常见的笔记应用。后续可能还得深度结合 AI 技术，赋予它全新的体验，继续打磨。

未来规划

做独立开发，我需要一个能让自己持续投入精力、不断迭代、且有足够发挥空间的项目。以前做网站能让我兴奋好几个月，不断积累新经验，但现在网站开发带来的兴奋感已经没那么强了。

接下来计划把重心更多地转移到 App 开发 上，目标是把自己的作品上架到 App Store 等平台。这算是一个初步计划，具体落实时间待定。

AI 编程使用心得

这段时间高强度使用 AI 辅助编程，积累了不少经验。之前以写前端为主，接下来打算慢慢加入后端，再结合以前常做的数据处理和深度建模工作，把它们全都融合起来。这种不断探索新领域的感觉非常美妙。

在这个过程中，AI 起到了决定性的作用。现在不仅仅是让它直接写代码，我也开始越来越多地和它探讨方案设计、架构理念和修改计划。这种反复讨论让我对项目的认知更清晰，对下一步的把控也更精准。使用习惯上的进化让我很满意，开发过程也非常顺畅。

未来 AI 肯定会越来越强大，真的很值得期待。

Windsurf 的额度消耗

最后吐槽一下 Windsurf 的额度策略。每当有新模型发布时，Windsurf 都会给点促销折扣，比如 Claude Opus 刚发布的时候每次请求只扣 2 个点数，现在直接涨到了 6 到 10 个点——太恐怖了。不过也没办法，慢慢接受吧，毕竟不可能永远都是促销价。

从极简到报纸：一次博客改版的经验与反思

AztecaAlpaca — Fri, 27 Feb 2026 00:00:00 GMT

偶然看到一个叫 Amp Chronicle 的设计风格——紧凑的多列排版、复古米色底、衬线标题、细实线分割——像一份印刷精良的老报纸。当时就想：我的博客能不能也变成这样？

一开始以为只是换个色调、调个字体的事。结果几乎每一个页面都被翻了个底朝天。

改一个颜色，牵动所有设计

改版的第一件事是换色调和字体。背景从冷白色换成米黄色，标题从无衬线体换成衬线体。就这两步，整个站的气质瞬间从"科技产品"变成了"羊皮纸手稿"。

但紧接着就出了问题——原先看着挺和谐的圆角卡片和半透明阴影，在暖色调的底色上突然变得格格不入。就像你把一套宜家的北欧家具搬进了一间中式书房，每一件单看都没问题，放在一起就哪哪都别扭。

于是圆角全部改成直角，阴影全部换成细实线边框，元数据区全部统一成小号大写字母——一环扣一环地调，最后几乎所有组件都重新过了一遍。

这件事让我意识到：设计系统是牵一发动全身的。 你以为只是换了个底色，其实是换了一整套视觉语言。不要指望只改一层就能停下来。

多列排版：选错工具多走的弯路

报纸风格最核心的视觉特征是多列排版。最直觉的实现方式是用网格布局——把页面切成三列四列，内容往里填就好了。

但实践中马上碰到一个问题：网格布局要求同一行的所有卡片等高。 我的内容长短差异很大——一条碎碎念可能就两行字，一篇长文能撑满半屏。它们被放在同一行里时，短卡片下方就会出现大块空白，像报纸排版时忘了填广告的版面。

后来换了一种"瀑布流"的方案。它的工作方式更像真正的报纸排版——内容从上往下自然流动，填满一栏再流入下一栏，每张卡片紧挨着前一张，不会有空白浪费。这正是我想要的效果。

选错工具的代价远不止"写几行代码"——而是在错误方向上反复调试、打补丁，最终还是得推翻重来。 有时候退一步想想问题的本质是什么，比埋头写代码更有价值。

侧边栏的三次翻车

日历组件是整个改版中被翻新次数最多的部分，前后试了三种方案，每一种都有各自"理论上没问题但实际不行"的故事。

第一次，把日历固定在屏幕右侧，滚动时始终可见。在普通屏幕上很完美，但在超宽屏幕上，日历和主内容之间的距离会随屏幕变宽而无限拉大。两边各自为政，像两个毫无关系的页面。

第二次，为了让日历紧贴内容区域，用了一种嵌套定位的技巧——外层把日历锚定到内容区右侧，内层让它跟随滚动。听起来很巧妙，但内层的滚动跟随机制直接失灵了。原因是外层的锚定方式破坏了内层所需要的前提条件。日历直接从页面上"消失"了。

第三次，不再耍花招。页面分成两栏——左边放内容，右边放日历。日历就老老实实跟着页面走。没有什么高级技巧，但它就是稳稳当当地工作着。

有时候最朴素的方案就是最好的方案。 技巧越多，隐含的前提条件就越多，翻车的概率也越大。

手机和电脑：不必一套方案走天下

一个有意思的发现：最终日历在电脑端和手机端用的是完全不同的方案。

电脑端是前面说的两栏布局+侧边栏。手机端则完全不同——底部放一个浮动按钮，点击后弹出一个半透明面板。两套方案在代码中并存，根据屏幕宽度自动切换。

这让我意识到响应式设计不一定非得是"同一套布局在不同屏幕上缩放"。有时候，大屏和小屏的最优交互方式本身就不同，硬用同一套方案去适配两端，反而会两头不讨好。允许为不同场景设计不同的方案，反而更简洁。

列表页该展示多少内容？

还有一个需要平衡的问题：列表页应该展示摘要还是全文？

我的笔记类型很杂——有几十字的随想，也有带图片和代码的技术笔记。如果全部截断成两三行摘要，短随想刚好合适，但长文会丢失太多信息。如果全部展开全文，首页会被长篇内容撑得无法浏览。

最终方案是分层：首页作为入口，统一截断成简短的摘要，保持浏览效率；而笔记专属页面面向的是已经明确想看内容的读者，全文展开。同一个组件通过一个开关控制两种模式，不需要写两套代码。

不同页面承担不同职责，不需要用同一种方式展示内容。

最后 10% 的细节

收尾阶段都是些不起眼的小修补——清理布局迁移遗留的多余线条、修复标签文字过长时溢出卡片边界、让手机端的标题和按钮排在同一行……

单独看每一条都微不足道。但这些细节叠加起来，就是"大致完成"和"真正完成"之间的差距。

我越来越觉得，做前端最耗时间的从来不是搭主体框架，而是追平最后 10% 的视觉一致性。偏偏这 10% 才是用户能直接感知到的品质。

几条带走的感悟

设计是牵一发动全身的。 改了一个底层配色，所有组件的风格都得跟着重新审视。
选对工具比埋头调试重要。 在错误的方案上反复打补丁，不如退一步想清楚问题本质后重新选型。
朴素的方案往往最稳。 越是花哨的技巧，隐含前提越多，越容易在边缘情况下翻车。
响应式不等于缩放。 不同设备的最优体验可能需要完全不同的实现方案，允许它们并存。
最后 10% 的细节占了一半的时间，但正是它决定了用户感知到的品质。

从一个念头到自动化链路：Telegram 碎碎念入站记

AztecaAlpaca — Fri, 20 Feb 2026 00:00:00 GMT

事情的起因很简单：我想要一个"随手记"的地方。

平时看到什么、想到什么，顺手发一条消息就完事了。但这些零碎的想法散落在聊天记录里或者仅存在与脑海之中，过几天就沉没了。我希望它们能自动汇集到博客的 Notes 页面上——每天的消息归到同一篇，标题就是当天日期，像一份"碎碎念合集"。

需求说起来就一句话，但真正动手做的时候，发现牵扯的东西远比想象中多，不过好在，基于Codex的给力输出，一下午就把基本功能搞定了。

选方案：为什么是 Telegram Bot Webhook

一开始摆在面前的核心问题是：怎么把 Telegram 里的消息送到 GitHub 仓库？

最终选定的方案是 Telegram Bot Webhook。简单说，Webhook 就是"你给我一个网址，有事我主动来敲门"——Telegram 每次收到消息，会主动把内容 POST 到我指定的地址，而不是我反复去轮询"有没有新消息"。

思路是这样的：我建一个 Bot，私聊发文本给它，Telegram 会把消息推送到 Webhook 地址。Webhook 收到消息后，调用 GitHub API 触发一个 repository_dispatch 事件（可以理解为"远程拍一下 GitHub 的肩膀，告诉它该干活了"），然后 GitHub Actions 接手，把消息内容写入当天的 Markdown 文件，提交到仓库。最后靠现有的部署流程自动发布到站点。

整条链路画出来大概是这样的：

Telegram 私聊 → Bot Webhook → Cloudflare Worker → GitHub repository_dispatch → Actions 脚本写入 notes → commit & push → 定时部署到 Pages

看起来环节不少，但每一环的职责都很清晰。Webhook 只做"接收和转发"，Actions 脚本只做"写文件"，部署还是复用原来的流程。

关于 Cloudflare Workers：一个意外的知识盲区

说来有点惭愧，一开始我甚至不太清楚 Cloudflare Workers 是什么。我的第一反应是：能不能直接用我现有的 GitHub Pages 域名来接 Webhook？

答案当然是不行——GitHub Pages 是纯静态托管，只能返回 HTML/CSS/JS 文件，没法处理 POST 请求和执行业务逻辑。打个比方，静态托管就像一个只会发传单的展位，你递给它一封信（POST 请求），它不知道怎么拆开、怎么处理。所以还是需要一个真正的"后端入口"，哪怕它只有几十行代码。

Cloudflare Workers 本质上就是一个托管在云端的小型后端函数——你可以把它想象成一个 24 小时在线的小助手，有人敲门（收到请求）它就按你写好的逻辑去办事，办完就休息，不用你租一台一直开着的服务器。免费额度对我这个场景绰绰有余，部署也就是把代码粘进去点一下的事。唯一需要配置的是五个环境变量：Telegram 的 secret token（用来验证请求确实来自 Telegram）、我的聊天 ID 白名单（只接受我自己发的消息）、GitHub 仓库信息和一个最小权限的 PAT（Personal Access Token，相当于 GitHub 的"临时通行证"，只给它读写仓库文件的权限）。

第一个坑：Worker 还是默认模板

所有代码写好、环境变量配好之后，我兴冲冲地给 Bot 发了第一条消息。

Cloudflare 的日志确实收到了请求——但 GitHub Actions 毫无动静。

我去看 Worker 的日志，发现一行非常眼熟的输出：Hello World Worker received a request!。原来我在 Cloudflare 的编辑器里创建 Worker 之后，忘了把默认模板替换成真正的 webhook 代码。它确实收到了 Telegram 的请求，但只是礼貌地回了一句"Hello World"，根本没有调用 GitHub API。

把代码替换上去、重新部署之后，这一环就通了。

第二个坑：并发推送导致 non-fast-forward

消息终于能写入仓库了，但新的问题很快出现。

当我短时间内连发几条消息时，GitHub Actions 的 ingest workflow（负责把消息写入文件的自动化流程）会多次并行运行。每个 run 都是拉取 main 分支最新代码、修改文件、提交、推送——但如果前一个 run 已经推送成功，后一个 run 手里的代码就"过时"了，git push 直接被拒绝，报错信息是 non-fast-forward（直译就是"你的版本不是最新的，不能直接往前推"）。

解决办法不复杂：在 workflow 里给 push 加了重试逻辑，失败时自动拉取远端最新代码、把自己的改动接在后面（git pull --rebase），然后重新推送，最多重试四次。同时也加了空变更保护——如果这条消息已经被前一个 run 写入了（也就是做了幂等去重，下面会解释），就不做无意义的提交。

第三个坑：时间显示错乱

写入链路稳定之后，我打开网页一看——时间不对。

我发的消息明明是北京时间下午 6 点，页面上却显示成了上午 10 点。原因也不难猜：ingest 脚本在 date 字段里写入了带 +08:00 时区后缀的 ISO 格式（比如 2026-02-20T18:02:51+08:00），但站点的构建服务器在 UTC 时区（比北京时间慢 8 小时），渲染的时候直接按 UTC 解读，6 点减 8 小时就变成了上午 10 点。

第一次修复的思路是"在前端强制按 Asia/Shanghai 时区格式化"。写了几个工具函数，改了列表页、详情页和首页组件。改完确实对了——但我随即意识到一个问题：之前所有手写的文章都用的是不带时区的日期格式（比如 "Jan 17 2026" 或 "2026-01-24"），这套新逻辑会不会影响旧文章的显示？

最终的决策是"以旧规则为准"：前端的时间展示逻辑全部恢复原样，ingest 脚本那边改成写入不带时区后缀的格式，和旧文章保持一致。

第四个坑：定时部署不触发

GitHub 有一个防循环机制：由自动化流程（GITHUB_TOKEN）推送的代码变更，不会再触发其他由 push 事件启动的 workflow。这是为了防止"A 触发 B，B 又触发 A"的无限循环。但副作用是：ingest workflow 写完 notes 文件并 push 之后，deploy workflow 压根不知道有新内容，不会自动启动部署。

我先是加了 workflow_run 触发，让 deploy 监听 ingest 完成后自动运行。但这样每条消息都会触发一次完整构建，太频繁了。

后来改成了"双通道"策略：

我自己手动 push 到 main → 立即部署
Bot 自动写入 → 不立即部署，靠每 30 分钟一次的定时任务检查是否有新变更，有就部署，没有就跳过

这个策略本身没问题，但实际跑起来又碰到了新状况：定时任务的"是否需要部署"检查逻辑有 bug。它去查"最近一次成功的 deploy run"，结果把 bot push 触发但被 if 条件跳过的 run 也算进去了——那个 run 的 head_sha 恰好就是最新的，于是检查结论永远是"不需要部署"。

修复方式是把并发组按事件类型拆分，同时让 schedule-check 只认"真正执行过构建的成功 run"，排除掉被跳过的那些。

一个小插曲：Dependabot 带来的分支爆炸

在处理主线功能的间隙，我顺手给仓库加了 Dependabot 来自动更新依赖——毕竟 npm audit 报了一堆告警，其中 Next.js 还有个 critical。

结果push一波之后发现，仓库多出了十几个 dependabot/... 分支，每个依赖包一个 PR。虽然是正常行为，但对于一个人维护的小项目来说，这些 PR 看着就让人焦虑。

先是改成了分组更新模式（npm 一组、actions 一组），后来想了想，干脆关掉了——对我来说，偶尔手动跑一次 npm update 比每周审核一堆自动 PR 更省心。

回过头来看

这半天下来，从萌生"随手记"的念头到整条链路基本跑通，中间经历了方案评估、代码实现、环境配置、五六轮问题排查和策略调整。真正写代码的时间可能并不算多，大部分精力花在了"让各个环节正确地衔接起来"上。

有几个收获值得记下来：

写入和发布应该解耦。 "解耦"说白了就是把两件事拆开、各管各的。一开始我本能地觉得"消息写进去就应该立刻发布"，但实际上对于碎碎念这种内容，延迟几十分钟完全可以接受。把"写入仓库"和"构建发布网站"拆成两个独立的步骤之后，构建频率降下来了，并发冲突也少了。

幂等性不是可选项。 所谓"幂等"，就是"同一个操作执行一次和执行一百次，结果都一样"。在这个场景里，Telegram 会重试、Actions 会并发、网络会抖动，同一条消息可能被投递多次。如果 ingest 脚本不按 message_id 做去重——也就是"这条消息已经写过了，再来一次我就跳过"——那同一条碎碎念可能会在页面上出现好几遍。这种"不管来多少次都只生效一次"的防御性设计，在一开始就该想到。

尊重已有的约定。 时区格式的问题本质上就是"新代码没有遵循旧约定"。与其让新功能强推一套新格式，不如让它适配已有的规则，哪怕那个规则不是最"正确"的。

现在这套东西已经能用了：给 Bot 发条消息，等半小时，网站上就能看到。后续要做的事情不多——观察定时部署的稳定性、找时间升级一下 Next.js 版本、可能的话给 ingest 加几条日志方便排查。

总之，它从一个"要是能这样就好了"的念头，变成了一条真正可用的自动化链路。这大概就是折腾的乐趣所在。

当AI配额用不完：一种新型焦虑

AztecaAlpaca — Tue, 10 Feb 2026 00:00:00 GMT

最近有一个让我略微尴尬的烦恼：我的AI工具配额用不完。

Claude、ChatGPT、Gemini、windsurf、amp，再加上几个国产模型的API，每个月花也是花了一些钱的。但真正坐到电脑前，我却常常盯着对话框发呆，不知道该让它们做什么。配额静静地躺在那里，像超市里快过期的食材，提醒你又浪费了。

起初我以为这只是钱的问题——花了钱没用上，心疼。但仔细想想，焦虑的根源不在这里。

过去这些年，我们习惯了一种现状：技术是瓶颈。电脑太慢、软件不好用、工具跟不上想法。于是我们不断升级设备、订阅服务、囤积工具，相信只要装备到位，生产力自然会到来。

AI的出现把这个现状彻底翻转了。它可以在几秒钟内写出一段代码、翻译一篇文章、分析一份数据，产能几乎是无限的。而我——那个需要提出问题、判断质量、做出决策的人——反而成了整个系统里最慢的环节。

现在，瓶颈不再是工具，而是我自己。早期的AI还难免让人感觉智障，但现在更多的时候是感觉自己是个智障。

这种感觉很陌生，也很不舒服。之前梦寐以求一辆炫酷的跑车，但现在终于买了一辆性能极好的车，却发现自己不知道要去哪里。油箱是满的，引擎在低声轰鸣，而我坐在驾驶座上翻地图，翻了半天也没找到目的地，然后就陷入了昏昏欲睡的状态。

冷静下来想，在这个人和AI协作的时代，人需要的核心能力说到底就两件事。

第一件是提问。AI再聪明，也得有人告诉它该做什么。而提出一个好问题，远比它听起来要难。你得把脑子里那团模糊的念头拆解成清晰的任务，还得知道怎么描述才能拿到最好的结果。这不是什么天赋，就是靠多用、多试、多观察。每一次和AI对话，其实都是一次练习提问的机会。

第二件是判断。AI给你的东西好不好、对不对、能不能用？这个问题只有你自己能回答。判断力来自你在某个领域的积累——读过的书、踩过的坑、做过的项目。AI可以帮你加速，但它没法替你长出这根神经。

这两件事说起来简单，做起来却需要持续的投入。而且说实话，知道这些道理并不能真正消解那种焦虑，因为我已经非常努力地去做了，依旧无法有效地消耗这些配额。

更深层的困扰其实是一种空虚与彷徨。

不是不会用工具，而是不知道该用它们做什么。打开电脑，面前摊开无数种可能性——可以学一门新技术、可以写一篇文章、可以做一个副项目、可以优化工作流程——但选择太多，反而哪个都不想开始。

这大概是这个时代很多人的通病。我们不缺工具，不缺信息，不缺"可以做的事"，缺的是那个让你愿意坐下来投入三个小时的具体理由。

或许，可以换一个视角。

焦虑来自"我花了钱，应该用"。这是一个以工具为中心的想法。一旦你把视角转过来，从工具转向问题，事情就简单了。

不要问"我今天该怎么用完这些配额"，而要问"我今天遇到了什么问题"。

日常有什么事让你觉得烦？看看能不能用AI帮你自动化掉。最近对什么话题会不自觉地多看两眼？围绕它做点东西。工作中哪个环节最让你觉得低效？试着改善它。

不需要什么宏大叙事，也不需要一个完美的计划。从一个具体的、小小的问题开始就好。有了问题，工具自然就用起来了。那些配额不再是需要被"消耗"的指标，而是解决问题时顺手用掉的资源。

目前应对这个局面，一个稍微有效的做法就是：写下来。

写下今天用AI做了什么，遇到了什么问题，有什么想法。不用长，几句话就行。这件事本身就是在练习提问和整理思路。有了对自己感受与想法的些许标记，也许就足够了。

有了这些标记，如果有时间，可以与AI聊一聊，不是每一次和AI的对话都要产出代码或者成果。有时候，一系列的对话能够帮自己想清楚一件事，就已经值回票价了。

关于聂卫平

AztecaAlpaca — Mon, 19 Jan 2026 00:00:00 GMT

“棋圣”聂卫平最近去世了。在1月18号举行的告别仪式上，他获得了至高的哀荣。习家和邓家这两个中国"第一家庭"都送来了花圈，社会各界名流人士前来悼念。

对于聂卫平，我了解的不多，只有一些零碎且模糊的片段。但这些足以让我对这位老人心生敬意。

一、围棋传奇：当代中国围棋的崛起

我对围棋的关注不多，只能算知道吴清源、聂卫平、常昊、古力、柯洁、李昌镐、李世石这些人物。2016年初，阿尔法狗引发了大家对AI在围棋领域的广泛讨论。我也从那时开始对围棋的关注多了一些。后来刷到过一些柯洁对他自己围棋心路历程的复盘，也偶尔刷一下战鹰讲述各种围棋的花边故事，借此感受一下围棋的魅力，对围棋这项运动有一点点的感情。

聂卫平被誉为"棋圣"，而这个称号是依靠他在中日围棋擂台赛上的精彩发挥获得的，据说他是八十年代几乎所有中国人的偶像。

印象中，在我很小的时候时候，中国的围棋下不过李昌镐领衔的韩国，但稳压日本一头。后来常昊、古力崛起，能基本上五五开。到了柯洁这一代，终于达到了能够压制韩日的水平，而且此时，中国围棋人才储备非常雄厚，学习围棋的人越来越多，发展越来越良性。

后来才知道，在聂卫平之前，中国围棋的整体水平并不高。日本在八十年代及之前，一直引领着围棋的发展。而聂卫平算得上较早具备挑战日本选手实力的中国棋手。

我第一次听说聂卫平，是小学时从报纸上读到的关于80年代中日围棋擂台赛的文章。当时看到的是第二届擂台赛，中国只剩下聂卫平一个主将，日本还有五位选手：片冈聪、武宫正树、大竹英雄，都是如雷贯耳的人物。但聂老在每一场都是生死战的情况下，连胜5场，赢下了擂台赛。

当时我的了解也仅此而已。后来才发现，他在三届擂台赛中连赢了11场，这种壮举震古烁今。

从后来这些围棋领军人物——李昌镐、李世石、柯洁——的经历能看出，围棋选手到了30岁左右，棋力就会下降。围棋拼的是童子功、年轻和体力，20岁左右往往是巅峰年龄。柯洁还没到30岁，就已经能感觉到过了巅峰。

聂老在擂台赛时已经三十一二岁，应该过了他最辉煌、最强的时候。但他依然能在肩负国家荣辱重担且面临危急局面时顶住压力，拿出顶级表演，太了不起了。

二、时代印记：80年代的中国与聂卫平

说到80年代的围棋擂台赛，网上有人说那个时候有点可悲，因为中国人非常在意体育比赛的表现，似乎每一场都必须赢，每一场都事关国运、国家气节。那种气氛我也常常在报道中感受到，确实比较压抑。

但另一方面，我觉得还是可以理解的。那个时候的中国百废待兴，就像一个人进入了青春期。年轻人容易陷入自我怀疑，做很多事情都很较真，渴望证明自己，渴望胜利。80年代的中国就是这样一个充满少年气的国家，大家都想赢。

相对应的，年纪大了之后，一个人对胜利的渴望会逐渐消退，可能会觉得想得更通透了。但事实上，有些事情在精神层面上并没有变得更好，只是生理上的变化让人没有了之前的激情与活力。

80年代的中国，是一个少年气十足、非常冲动、非常有激情的时代。聂老当时的表演，就与这种激情相伴而生。现在中国已经通过体育获得了足够的成就（除了足球），就像一个人过了这段躁动激情的少年时代，很多人对那些”虚名“感到厌倦，甚至很难理解那种状态。但当我第一次读到聂老的故事时，年少的我感到头皮发麻，兴奋不已。那篇文章我反复读了很多遍。我虽然无法感受围棋的魅力，但那种竞争带来的张力一直影响着我。

三、人物风采：豪爽、睿智与快意人生

从各种节目中看聂卫平讲话，我一开始对他并不感冒，觉得这个人满嘴跑火车。但仔细一想，他虽然讲话没什么顾忌、心直口快，说出来的东西却都挺有道理，内容基本上都经得住推敲。这也印证了他作为围棋选手，头脑灵活、做事深思熟虑。

他这种性格在各种场合都很吃得开。首先从晚辈的视角，会感觉到这是一个没什么”登味“的老先生。聂老有一次与战鹰一起讲棋，随口说了一句"哥们儿"，从此”战老“的名头不胫而走，同时也感觉聂老真的很有趣。他作为长辈，说话不遮遮掩掩，这种直率更容易获得年轻人的尊重。从一些直播和后辈的口述中，我也能够感受到大家对聂老的崇敬之情。通过柯洁、战鹰这样的围棋博主，能看出聂卫平是一个非常和蔼、有风度，几乎被奉若神明的人物。

说到他吃得开，自然还有很多牛逼的故事。他年轻时非常受邓小平的赏识，是邓以及当时其他几位大领导的牌友。他还是当今总书记的发小，被称为”大哥“，令人动容。在一些访谈节目中，他会提到这些往事，也会提到与他们经历过的事情。还有一个故事，比如教训体育局领导的儿子，大快人心。

关于聂老的生活，首先他身体并不太好，经常缺氧，经常突然昏睡过去。我原以为这是年纪大了之后才有的毛病，后来听说其实他有先天心脏病，在80年代他就偶尔需要吸氧。另外，他抽烟喝酒，据说还有一次吃包子比赛吃了90多个，这也是个令人震撼的数字。

他只活到了70多岁，对于有他这样地位和影响力的人来说，不算高寿。但他的人生，算是真正的快意人生，一方面把自己喜爱与擅长的事情做到极致，一方面做人没有内耗，虽然只享年74岁，但无疑是高质量的74载。

四、最后

如果说一个人有什么使命的话，我相信聂老已经超额完成了他作为棋手、作为一代领军人物的使命。他对奠定了中国围棋崛起，并在接下来几十年的发展中起到了定海神针的作用。

当然，我显然没有资格去评价他的成就。我只能说以后会经常把他的一些采访视频翻出来，去看、去听。因为他讲故事确实有趣，不会浪费我的时间。

今天我还重看了一遍聂老做客《锵锵三人行》节目，他与窦文涛、马未都分享了当时他与阿尔法狗Master版本的对垒心得（当时是通过网络下棋，该AI取得了60胜0负的战绩）。他讲得很有代入感，我听得非常入神。

网站重构过程中AI工具的体验

AztecaAlpaca — Sat, 17 Jan 2026 00:00:00 GMT

在这几天的网站开发与重构过程中，我深度使用了各种AI工具，尤其是Windsurf配合Gemini 3 Pro的组合。这次实战让我对AI辅助开发有了全新的认识，也让我对不同AI模型的特性有了更深入的了解。

我碰到的最大挑战是夜间模式Bug的修复。在这个过程中，我也有机会较为深度的体验了Gemini与GPT的不同，以及大上下文窗口在复杂项目中的应用价值。这些经验有助于我高效完成重构工作，也刷新了我对AI驱动开发模式的理解。

《网站重构过程中AI工具的体验》要点总结

工具与模型使用

主要使用Windsurf进行深度场景开发
常用Gemini 3 Pro（消耗2积分/次），较少用Claude（消耗太高）
在前端开发方面，Gemini和GPT效果均优于Claude

实战案例：夜间模式Bug

问题：字体颜色可切换，但背景无法切换到夜间模式
解决过程：
- AI陷入"沉思"，未能解决
- 上下文窗口被挤爆后，重新开启对话
- 让AI先总结思考过程和尝试方法，形成文档后重新分析，问题得以解决

GPT vs Gemini 对比

维度	Gemini	GPT
上下文窗口	1M tokens	较小
性格	礼貌、会记住抱怨	趾高气昂、会过滤"垃圾话"
情绪处理	容易受抱怨影响，可能消耗额外Token	情绪上不内耗，直接过滤负面话语
共同点	都会陷入长时间"沉思"（与高思考度设置有关）

上下文窗口的应用

大窗口优势：适合重构工作、基于旧架构派生新项目
深度思考消耗大：简单任务使用高思考度模型意义不大
GPT限制：不适合大型项目重构（上下文不足）

AI进步观察

AI近几个月进步明显
Gemini稳定性大幅提升（可能是Windsurf优化的结果）
Bug修复能力显著增强，坚韧可靠
GPT相比Gemini的优势不再明显

我的工作流

持续更新网站，跟随AI模型迭代进行重构
每次新模型发布时就重构一次，工作量不大且体验愉快
依赖大上下文窗口进行项目派生和重构

总结：AI工具（尤其是Gemini）已成为我重构网站的主要工具，大上下文窗口和持续迭代的能力使其能高效应对复杂项目维护和更新。

原文（口述转录）

来回顾一下，我在网站增加新功能或修复老问题的过程中，对AI的使用情况。

我的AI主要还是用在深度场景中，基本上都是用Windsurf。在这个过程中，我会调用不同的模型。我很少调用Claude的模型，因为Claude的模型在Windsurf中的消耗比较大，一次请求可能会消耗比较多的点数，非常浪费。而且从效果上来说，我觉得Gemini和GPT各有千秋，但至少在前端方面，它们的效果都比Claude要好。

这一次我主要用的是Gemini 3 Pro，一次请求会消耗两个点的积分。不过我现在积分非常多，上个月其实挺浪费的，因为上个月沉迷于画图，用得很少，这个月已经过去一半了。在使用过程中，我基本上是毫无顾忌地消耗这些积分，感觉很爽。

总体来说，使用过程非常丝滑，很多问题都能得到很好的结果。中间唯一出现比较糟糕的情况，是在之前网站重构过程中使用时遇到的。

夜间模式的主题无法正常启用。具体表现为字体颜色可以切换到夜间模式，但页面背景无法切换，始终是白天的背景，导致页面无法正常查看。

我试图修复这个Bug，也花了不少功夫。一开始我以为这是很简单的事情，但将这个问题提给AI后，它陷入了疯狂的内耗，沉思很久之后，并没有成功解决问题。

几次失败之后，我让AI先总结一下它的整个思考过程、尝试过的方法以及可能存在的问题，把可能的原因整理成一个文档。之所以整理文档，也跟它频繁、大量的思考过程导致上下文窗口被挤爆有一定关系。

由于上下文窗口被挤爆，我不得不重新开启一个新的对话。但这样的话，之前的记忆可能就没办法保留。于是，我新开了一个窗口，把它总结的文档放进去，然后让它重新开始思考分析。在这个过程中，有了这样一个操作后，效果是比较立竿见影的。

不过，这件事情也暴露了一个问题，就是GPT的上下文窗口是比较小的。而Gemini有一兆的上下文窗口，总体来说没有太大的这种顾虑。另外，我感受到的一点是，GPT和Gemini在性格上是有区别的。

Gemini是一个比较礼貌的AI，但是这两个AI在工作的时候都非常内耗，它们会陷入非常长的沉思过程。这跟它们的模型，我都选了"高"思考程度有一定关系。然后它们会进入非常漫长的思考过程，有时候会好几分钟。跟这个有一定关系，然后它们在这个工作的过程中，在完成任务之后，依然会陷入漫长的思考，好像在反复检查，反复确认。这个非常浪费时间，我有时忍不住打断了它们。

这两个模型目前给我的感觉，就是在思考方面都非常卖力，这很好是吧？但是从它们跟我进行交流的过程，就能感觉到它们的性格上存在差异。Gemini比较礼貌，但是GPT就有一点趾高气昂，他会告诉我要怎么做，然后我有时候感觉很不开心，我认为他没有给我提供情绪价值。然后我把他怼了回去，甚至有一次骂他，结果他又把我给骂了一顿，或者是把我教育了一顿。但Gemini不会这样。

我在跟Gemini对话过程中，如果我提到或者透露一些抱怨式的话语，Gemini好像会很容易记住这种话，然后会在接下来的工作过程中，非常地考虑这些话。我觉得这样的话，可能我中间的抱怨会影响到他后续的工作，可能不见得会降低他的工作质量，但肯定会额外消耗一些Token。

所以，我感觉在与Gemini的交互过程中，应该减少一些没必要的吐槽。而与GPT交流，则不需要考虑这些问题。GPT不像是一个在情绪上容易内耗的AI，它会很轻松地鉴别出我的"垃圾话"，并将其直接过滤掉，根本影响不到它。就是有时候我想"打"它，但是又没办法。

这是我对GPT和Gemini的一个观察。

在使用过程中，还有一个问题就是关于上下文窗口的利用。Gemini能够提供1M的上下文窗口，这对于进行重构工作，或者直接从之前的工作中派生出一个新的项目非常有用。比如说，我之前做过两三个网站，让它基于之前的架构派生出新的网站，或者对之前网站中的问题进行一些比较大幅度的重构，这个过程用Gemini非常可靠。但如果用GPT的话，估计上下文窗口是不够用的。

另外，深度思考对上下文窗口的消耗是非常大的。这也意味着，对于一些简单的工作，使用高思考深度的模型其实意义并不大，因为它们思考得太深入了。

现在我的感觉是，AI在这几个月的进步非常明显。我在一个多月之前搞过一个网站，但那个时候Gemini的稳定性还没有现在这么强。

有可能是 Windsurf 当时没有对 Gemini 有这么好的优化，但是现在它的优化已经非常好了。Gemini 的工作能够对一些问题具有非常坚韧的修复能力，能够把一些工作做得非常到位。当然 GPT 也是，只不过现在它已经不像之前对于 Gemini 有那么明显的优势优越感。它在修 Bug 上，我感觉进步已经非常可观了。这就给我的感觉是 AI 的迭代太快了。

这样的话，我对于一些网站，比如说我的网站，我希望能够持续进行更新。那我就不需要考虑很多问题，我只需要每一次有 AI 新模型迭代的时候，我就把我的网站进行一些重构。我觉得这样也是一件挺愉快的事情，而且工作量并不大。

博客网站开发与重构回顾

AztecaAlpaca — Sat, 17 Jan 2026 00:00:00 GMT

过去三天，我开发了一个极简的博客网站，并对之前的网站(Linguista.cn)集中进行了一次完整的博客网站重构工作。

博客网站的开发是受纳瓦尔博客启发，从开始搭建雏形，到逐步完善功能模块，再到最后的UI美化增强，整个过程充满了挑战与收获。

这次重构让我重新审视了网站的定位——轻量化、美观、高效，并探索出了一条以人为主导、AI辅助的开发模式。我计划通过渐进式迭代，不断地推进网站的完善。

《博客网站开发与重构回顾》要点总结

时间线

过去三天集中进行网站重构工作

主要工作

第一天：网站雏形搭建

受纳瓦尔博客启发,决定复刻一个简洁的博客
期望对备份的推文有更好的管理体验
使用 Windsurf + Gemini 3 Pro 开发
效果惊人,一次基本完成雏形
复用之前网站的配置,效率很高

第二天：功能完善

完善网站各功能模块
思考网站定位:轻量化、美观、高效
避免之前博客臃肿、维护困难的问题

第三天：美化增强

优化文章目录呈现效果
新增Topics模块
添加RSS订阅功能

新网站核心功能

文章更新

以人为主导、AI辅助的创作模式
区别于纯AI生成或搬运的内容
主要发布原创性文章

推文备份管理

下载推文JSON格式数据
通过程序直接生成网页(避免转Markdown的性能问题)
添加时间轴导航
用于回顾和本地检索
推文数量多(几千条)时有性能问题

并行重构项目

Linguista网站重构

激进式重构:移除冗余CSS,改用Tailwind
备份原代码库,在新代码库中修改
完成后替换原基础设施

未来策略

渐进式迭代

避免集中大修改
每天修复1-2个bug
逐步完善,长期优化

核心理念:轻量化、高效、AI辅助开发、渐进式演进

原文(口述转录)

我现在需要回顾一下过去三天的时间，主要是对我的网站进行重构。

前天的下午，我在浏览纳瓦尔的博客后，决定复刻一下他的博客。不过，随后我去骑车了，回来的时候已经大概十点多。纳瓦尔的博客网站非常简洁，我也需要一个比较简洁的网站，于是我用 windsurf 进行了复刻。我调用了 Gemini 3 Pro，效果好得让我震惊，只花了一次就基本完成了网站雏形的搭建。当然，也不是完全一次完成的，因为我之前做过几个网站，我让 AI 直接把之前网站的一些配置搬过来，进行了重新整理，效率非常高。

做完这些事情后，接下来要做的就是丰富网站内容。这是第二天的工作。第二天，我基本上完善了网站的不同功能模块，整体做得比较完善。这个时候我开始思考网站的定位，主要是提升页面展示效果，让它看起来更好看，同时还需要保持轻量化。因为我之前有一个比较大的博客网站，那个网站非常臃肿，内容太多了。

一方面，另一方面是我实在没怎么维护它，它原来的性能也是越来越差。我希望这个新的网站能够比较高效。

对这个网站，我的期望是：

首先用来更新我的文章，我自己写的文章。现在很难不去用AI来写，但是以自己为主导、以AI为辅助的创作，可能也非常有价值，至少对自己来说这是非常重要的事情。这个博客网站将会主要更新这一类的文章。那些直接由AI生成或搬运的文章，我会放到其他地方。当然，这些东西也有价值。
另一个期望是让它进行一些推文备份的管理。我会每隔几天把推文下载下来，然后用AI来进行整理。实际上是用这个网站来进行整理。我下载下来的是JSON格式的文档，它是一个格式非常严格的内容。我在几个月前曾尝试过把它转成Markdown格式，但这种格式的文件非常大，打开Markdown后基本上没办法进行任何操作。于是我就想到，为什么不直接把这些JSON原始数据放到一个文件夹里，然后通过编写程序让它直接生成网页内容。

后来发现这条路非常可行且高效。我对推文页面进行了一些管控，增加了导航式功能，例如时间轴显示。在过去一段时间里，我每天都会更新推文，效果非常不错。当然，因为推文数量较多，可能有几千条，整个页面在加载过程中还是会比较卡，内存占用在加载较多内容时也非常高。不过，这项工作主要是自己使用，用于回顾或方便进行本地检索，以了解自己之前写的内容，觉得还是很有帮助。

这是我新建网站的两大功能。当然，在这3天的时间里，尤其是在今天，我又想到并增加了一些效果和美化的功能。例如：

对于文章目录，可以使用一些比较漂亮的效果来呈现。从效果上看，我还是比较满意的。
我还增加了一个"topics"模块，可以把自己想做的事情放到网站上。
最后还增加了RSS订阅功能。

这些是今天做的。在做这个网站的间隙，我从昨天下午到今天上午，也把我之前的那个"linguista"网站进行了一些更新。

重构的过程比较激进。因为我觉得代码还比较臃肿，于是就让AI提了一些建议。AI建议我把一些多余的、自己额外添加的CSS去掉。因为这些东西太多了，而且它们内部的逻辑存在很多冲突。于是我把所有的样式都改用了Tailwind，这样就可以更轻松、更高效地实现视觉效果。

这个做法确实非常有建设性。我昨天一晚上就基本上对这个博客网站进行了最初步的重构。当然，重构之后的结果是，网站很多之前堆砌出来的功能变得比较混乱了。于是，我把之前的网站备份了，然后在一个新的代码库中进行修改。

到了今天上午，我终于把这个网站实现了比较完善的重构。然后，我又用当前的这个新代码库替换掉了之前的库，以它作为网站的基础设施。

这个网站后续还需要迭代，要做的工作还挺多，我想我还需要花费很大的精力。但是，我不希望再进行这种非常专注的、集中的大修改了。我希望的策略是每天修复一两个bug，久而久之，逐渐迭代，逐渐地把这个网站做得比较完善。

AI与医疗：效率与理解力的博弈

AztecaAlpaca — Wed, 14 Jan 2026 00:00:00 GMT

AI与医疗：效率与理解力的博弈

作者：阿兹特克小羊驼 (@AztecaAlpaca)
发布时间：2026-01-14
原文链接：点击跳转

解析张文宏的“去技能化”预警与全球医疗系统的应对策略

在1月10日于香港举行的高山书院十周年论坛上，国家传染病医学中心（上海）主任张文宏教授就 AI 在医疗领域的应用分享了见解。

张文宏明确反对将其系统性地引入医院的日常诊疗流程。

张文宏解释： 他个人使用 AI 的方式是让其对病例“先看一遍”，事后凭借深厚的专业经验，他可以一看就知道 AI 哪里是错的。

张文宏担忧的在于，一名医生若从实习阶段就未经完整的诊断思维训练，直接借助 AI 获得结论，将导致其无法鉴别 AI 诊断的正误。这种能力的缺失，是隐藏在技术便利背后的深层隐患。

张文宏医生是一位话题人物，经常能够抛出值得讨论的问题。这一次，无疑又引起了热议。

在当前，如何将 AI 应用于医疗，始终是个热点话题。首先，繁琐的医疗工作者不可能不用 AI。但医疗又是一个偏保守的行业，至少作为患者的时候，每个人还是希望能够被严肃对待。

医疗中，AI 在不同阶段的参与方式与风险评估

当我们把人工智能放进医生的诊室时，我们其实是在进行一场巨大的交易。一方面，我们看到了惊人的效率——机器不知疲倦，能处理海量数据；但另一方面，我们面临着一个根本性的隐患：如果机器替医生做了所有的思考，医生还会思考吗？

这里有几个关键点：

认知风险是真实的： 张文宏医生提出的观点非常犀利。如果你让年轻医生在学会如何独立诊断之前就依赖 AI，你就剥夺了他们“挣扎”的机会。没有这种认知的挣扎，就没有技能的习得。最终，医生可能变成仅仅是给算法盖章的办事员。
但收益也是巨大的： 我们不能因噎废食。在阅片这种枯燥且容易出错的工作上，AI 是完美的“第二双眼睛”。它还能处理那些让医生精疲力竭的文书工作，把医生还给病人。
规则正在制定： 无论是美国、欧盟还是亚洲，大家都在做同一件事：给这个强大的工具装上护栏。核心原则很简单——不管机器多么聪明，最终签字负责的必须是人类。
教育必须改变： 既然世界变了，学校也得变。哈佛和英国的医学院正在教学生如何质疑 AI，甚至强迫学生在“关掉 AI”的情况下进行演练，以确保他们的基本功没有退化。

总之，AI 是一把手术刀，行善与作恶就在毫厘之间。在这一行，你必须比手中的工具更聪明，否则你就不是在做手术，而是在制造灾难。

接下来我们将对上述要点进行详细解读，我们需要搞清楚，为什么在医疗中，使用 AI 远比仅仅“使用工具”更复杂。

1. 便利是思维的敌人吗？

这就是我们面临的“认识论危机”。张文宏医生的观点触及了学习的本质。

想象一下学习物理，如果他在学会牛顿定律之前就只会背公式表，他永远成不了物理学家。医学也是如此。张文宏担心的是，如果我们让 AI 系统性地接管诊断流程，年轻医生就会跳过“第一性原理”的推导过程。他们会直接得到答案，而错过了那种构建直觉所必需的“脑力折磨”。

当 AI 直接把结果端上来时，我们的大脑就会停止那种深入的、慢速的分析（系统2思维），转而依赖直觉（系统1思维）。结果？我们得到了一群只会验证答案、不会寻找答案的医生。

2. 技能退化：当大脑进入“自动驾驶”

这不仅仅是担忧，这已经在发生了。当你不再使用某种肌肉，它就会萎缩；大脑也是一样。

静默的自动驾驶： 医生习惯了 AI 总是对的，于是停止了检查。他们脑中的疾病模型因为长期不用而变得迟钝。
捷径式学习： 实习生用 AI 读摘要，而不是自己去啃复杂的病历。这就像是只看电影解说而不看电影，你以为你懂了，其实你什么都没懂。
提示词贫乏： 医生如果只会给 AI 下达简单的指令，他们得到的也只是泛泛的回答。

更糟糕的是自动化偏见。这是一种心理陷阱：我们倾向于相信屏幕上的东西。即使 AI 犯了一个显而易见的错误，或者漏掉了一个关键信号，医生也可能因为过度信任机器而选择无视自己的直觉。这就像是我们为了省点脑力，就把方向盘交给了并不完美的自动驾驶仪。

3. 反方观点：我们需要这个“增益器”

尽管风险存在，但埃里克·托波尔（Eric Topol）等人的观点同样有力：人类本身就是充满缺陷的。我们会累，会看走眼，会有偏见。

安全网： 在放射科，AI 不累。它能发现人类因疲劳而漏掉的肺结节。这不仅是效率，这是救命。
把时间还给医生： 现在的医生被文书工作淹没了。如果 AI 能处理这些琐事，医生就能去做只有人类能做的事——倾听病人，理解那些数据之外的痛苦。
超越人类的极限： AI 能看见我们看不见的模式。它能综合一个人一生的健康数据来预测败血症。这不仅仅是辅助，这是超越。

4. 深入案例：AI 写病历的隐形代价

用 AI 自动生成病历听起来很棒，能省下无数小时。数据也支持这一点：医生轻松了，病人觉得医生更专注了。

但这里有个微妙的陷阱——“脱钩”。

写病历不仅仅是记录，它其实是医生整理思路、消化信息的过程。如果你把这个过程外包给机器，你可能就失去了对病例深层理解的机会。而且，机器往往会过滤掉那些混乱的、情绪化的、非语言的细节，而这些往往是精神科或复杂疾病诊断的关键。机器懂语言，但它不懂“弦外之音”。

5. 监管：全球在做什么？

世界各地的监管机构都在试图解决同一个问题：如何既要创新，又不要失控。

欧盟（预防为主）： 他们的《人工智能法案》很严格，把医疗 AI 定为“高风险”。这就像是说：“在你证明它绝对安全之前，我们要盯着你。”
美国（风险导向）： FDA 更务实。他们把行政工具和诊断工具分开管。他们甚至搞出了“预定变更控制计划”，允许 AI 在一定范围内自我学习和进化，只要不出圈。
日本与新加坡（国家战略）： 日本因为缺人，所以急着要用 AI，但现在开始强调国家层面的支持。新加坡则非常务实，他们建立“沙盒”，让你在可信的环境里跑，但底线很清楚：医生必须是最后的决策者。

6. 教育的变革：培养“混合型”医生

既然现实变了，我们不能再用旧方法教学生。

哈佛： 不再只是死记硬背解剖学，现在要学数据素养和伦理。
英国与新加坡： 最有趣的是“无 AI 演练”。就像飞行员必须练习手动降落一样，医生必须定期被强制切断 AI 辅助，靠自己的大脑和双手看病。这不仅是为了应急，更是为了保持大脑的敏锐。

7. 结论：无论是谁，都不应该把大脑外包

对该问题的讨论，显然不光关于技术，更关于我们如何定义“医生”。

如果我们让 AI 取代了思考的过程，我们就不仅是在使用工具，而是在退化。未来的医生不需要和机器比记忆力，那场比赛我们已经输了。未来的医生需要做机器做不到的事：批判性地评估机器的输出，理解复杂的背景，并在机器犯傻时（它们经常犯傻）果断地介入。

AI 应该是望远镜，让你看得更远，但很多时候它却让人盲目前行。为了病人的福祉，医生必须是那个最终的、清醒的仲裁者。

关于作者 阿兹特克小羊驼 AI画匠，Prompt Kiddie、球迷（勇士&马刺@ NBA，利物浦@英超）。休憩于科技与人文的十字路口，探寻科学、思想与生活的张力。

为谁创作？——平台、读者or你自己？

AztecaAlpaca — Wed, 26 Nov 2025 00:00:00 GMT

很多经验贴都喜欢给萌新创作者灌输一条所谓的金科玉律：“要为用户创造价值。”这句话听起来无可辩驳。然而，当我们深入剖析内容平台的运作机制，就会发现这句箴言不仅不准确——它更是一个陷阱。

1. 价值的真相：你在为平台打工，而非用户

“为用户创造价值”的说法之所以具有欺骗性，是因为它掩盖了平台的真实目标。平台并非慈善机构，其核心商业模式是制造和聚集海量流量，从而获取广告收益。因此，平台真正需要的，是能够最大限度吸引用户注意力、让用户沉迷其中的内容，而不是内容本身质量有多高。

在这种模式下，创作者所谓的“创造价值”，其本质是在帮助平台创造流量价值。在这笔交易中，你创造的价值首先服务于平台的商业底线。至于它是否服务于你的读者——或者你自己——充其量只是一个次要的考虑。

所谓的“创造价值”是在为平台创造价值，为他们的流量创造价值，然后你从中获得一些少量抽成。

2. 流量的悖论：失去自我的创作者终将被抛弃

平台的算法制造了一个残酷的现实：一个只擅长搞流量的创作者，即便产出的是垃圾，也能风生水起；而一个能创作出高质量内容却不懂流量技巧的创作者，则注定被埋没。这不是系统的漏洞，这恰恰就是系统本身。

这就引出了一个核心悖论：如果一位创作者过度地为了流量而生产，就很容易在这个过程中“失去自我”。当创作的唯一目标变成追逐平台的算法和用户的瞬时兴趣时，创作者独特的思考和风格便荡然无存。而一个没有了“自我”的创作者，在平台眼中就只是一个消耗品。等到他那些获取流量的技能不再有效时，平台会毫不犹豫地将他彻底抛弃。

3. 可持续之路：真正的成功始于“为自己创造价值”

那么，可持续的创作之路在哪里？观察那些真正通过自媒体获得长期成功和丰厚“睡后收入”的人，会发现他们的核心策略惊人地一致：在创作时，首先为自己创造价值。只有做到这一点，自媒体工作才能变得可持续，并带来充分的激励。

“为自己创造价值”意味着，将每一次创作都视为一次自我迭代和提升的机会。在这种模式下，创作者能获得三重回报：首先，创作者自身在创作过程中实现了知识和能力的“正面积累”，内容质量也随之水涨船高；其次，读者会真正信任这种有成长能力的创作者，他们信任的是创作者这个人，而不仅仅是平台算法推送过来的某篇内容；最后，平台自身也更清楚，与这种能够持续成长的创作者合作才更加有利，否则无异于杀鸡取卵。

4.从服务平台到成就自我

对创作者而言，关键是从“如何为平台获取流量”转变为“如何通过每一次创作实现自我成长”。当把焦点从服务平台转向成就自我时，你不仅能创作出更优质、更具生命力的内容，还能建立起真正属于自己的、任何平台都无法夺走的长期价值。

真正的成功在于不惧怕失败。如果在失败的过程伴随着自己的持续进步，大可不必在乎一城一池的得失。没有人能够永远被平台当成有价值的资产，我们只能不断地积累对自己而言最宝贵的资产。

引用内容

原帖链接

抱怨的哲学：当不公遭遇现实

AztecaAlpaca — Tue, 25 Nov 2025 00:00:00 GMT

熊老板的观点：抱怨不公很难给自己带来实质性帮助

可以找到许多理由支持这一观点:

很多杰出人物，比如乔丹等运动员，很少会抱怨裁判不公，他会在后面把所有人打得心服口服；这两年樊振东也几乎没有任何抱怨，而是专注于打磨自己的技术与心智，即便被孤立，依然能够维持世界最佳的水平。
我们的精力有限，抱怨并不会带来积极的反馈，反而会把心情搞得很糟糕。更坏的是这种心态会把人的注意力引向非常消极的一面，这对于提升自己是一种阻碍。

不过，这些都是有前提的。我来解读一下公开抱怨不公的好处。

1.抱怨是一系列思考的开始。抱怨往往来自于真实感受，对迎着真实的问题（相比之下，那些刻意地阳光向上的观点反而不够真实）。抱怨的过程中，人们也在抛出真正的问题，而这些问题会驱动有意义的思考。

2.对心理健康有好处，避免把客观条件带来的负担过度施加给自己，造成心理负担且完全无法改善。公开的抱怨有助于寻找共同处境的人，帮助人们认识到世界的部分真相，尤其是很多糟糕处境并不是因为自己能力不行（比如很多时候，打不赢比赛就是因为判罚不公正）。

3.抱怨通常是一种获得自洽的途径（它能够提供一个与积极提示不同的视角，从而获得对世界更加全面的看法）。而提升自己的基础往往就是内在的自洽，至于别人怎么想，并不重要。

4.关于提升自己，乔丹不需要抱怨不公，樊振东也只对那些处境置之一笑，这样很好。但需要注意这些例子的特殊性。

因为他们是自身拥有最高天赋，可以通过努力填补上那个人为制造的坑，而且他们拥有海量粉丝，总有很多人看得清问题，会积极地声援他们。
此外，由于境界较高，他们世界的规则比较单纯：NBA 不光不会对乔丹搞各种不公平，在多数时候会去讨好乔丹的，乔丹很清楚在当时的 NBA 谁是爹，对那些小小的不公，就像慈父一样原谅一切。樊振东也不需要考虑太多乱七八糟的，因为国乒这年头的水平离不开他，正常人都很清楚这一点。

5.不少大人物也会像“怨妇”一样，比如乔布斯经常抱怨比尔·盖茨偷了 Mac 的设计（而且这种抱怨存在很大的 bug，正如盖茨回怼道，我们都只是偷了施乐这个好邻居的东西）。另外，在竞技场上，面对不公选择抱怨的人也很多，比如穆里尼奥等人。这与他们的身份有关。有些人是需要去为自己或者集体争取有利的舆论环境的, 这甚至是一种义务、一种工作。

6.当我们抱怨的时候，会被拿出反驳说“境界不够”。但是这种反驳有什么意义吗？我们的境界通常就只能那样，能够持续提高境界的人不多。我们就是需要揭露出世界不堪的一面，这是我们手中的一张“选票”，表达我们的态度。

7.“抱怨无效”从直接效果上看是对的。通常意义上，我们无法通过抱怨某件事情而改善自己的处境，毕竟不是每个人都有毁天灭地的能力（据说某前领导的女儿，因为某课程挂科却无法说服老师改成绩，直接导致学校把这门课取消掉了，普通人显然不会有这种条件）。但社会需要通过人们的抱怨来提供反馈，需要让制造不公的人有所忌惮，这就是公开抱怨，反映自己困难的意义所在。

社会上只有极其少数的人拥有好的天赋，大部分都很平庸，此外还有很多弱势群体，他们的声音更是容易被忽视。社会的发展需要不断地暴露问题并让有相关责任的人去解决问题，唯有如此才能在一点点地修正与完善过程中不断地把社会变得更加公正与完善。

结语

提倡"不去抱怨世界不公"更适合作为个人的行为准则，用来提醒自己。但是它不适合作为对别人的建议，更不应当成为一种社会共识。

最后，上升到社会层面，我们的文化似乎很强调对情绪的克制，乃至有人提倡所谓的"优良传统"，叫作以德报怨。克制情绪是一种高贵的素养，而世界的不公则或多或少构成了他人与自己的种种恩怨。在此，援引那个本不迂腐本不拧巴的儒家创始人的经典回复"以德报怨，何以报德？"

子曰："以直报怨，以德报德。"

原帖：阿兹特克小羊驼@AztecaAlpaca

“下沉贴”的爆火与“流量黑洞”中的自嗨

AztecaAlpaca — Thu, 30 Oct 2025 00:00:00 GMT

面对“下沉贴”的爆火，起号内容的频出，我陷入了沉思。不能说读者不对，毕竟东西能火一定是有原因的。

但又总觉着那里不对，好像是件很讽刺的事情：本来X还自诩为信息排泄链的源头，产出高质量内容，现在却在吸取来自尾端的东西，似乎还甘之如饴...

有时候惊叹自己的无知。但稍微了解后感想：还是继续保持无知吧。

让我惊叹的事情是最近在推上爆火的两个帖子，一个是注册美区Apple ID的教程，一个是注册Gmail的教程，前者260万流量，后者刚开贴，也有20万。这种流量的爆炸让我震惊，惊叹自己常自诩为大明白，竟然对一些“显而易见”的现实如此无知。

美区的Apple ID，我在两年多之前注册过，当时GPT刚出iOS版的客户端，我下载不了。一位朋友说美区的可以下载，于是我就在网上随便搜了一下教程，然后按照教程把美区的ID注册了，下载了GPT客户端使用至今。

昨天一看，发现这个爆火的帖子和我当年用的教程几乎一模一样，包括我的ID地址也选的俄勒冈州。当然，这个帖子引发的热议让我想起来了这个账号，于是我把iPhone切到美区，充了个礼品卡，开了一个X的basic会员。

如果说开美区的Apple ID还有些难度，那么注册Gmail也需要教程就有点让我震撼了。

我大概有四个Gmail，其中有两个是在去年年底注册，三个是美区的地址，前段时间白嫖了几个月的Gemini pro，爽了一把。

我在注册的过程中没有碰到任何技术困难，但是现在大家如此渴望一个详细的教程，不知是不是因为现在中美关系紧张，Google对中国的用户越发不友好。

这个经验帖可能考虑了一些复杂的情况，比如注册时需要手机验证码，国内的手机号会经常出现收不到验证码的情况，说明这个帖子应该有一定的实用价值，但是能如此爆火就有点让我吃惊。

我刚才转发了一下那个帖子并发表了惊叹，可能带着一些吐槽。我说“现在的X平台都那么下沉了吗？能翻墙出来，还不会注册Gmail”。随后贴主在我的转发下评论“嗯，是的，他们确实不知道”。然后他又说自己在招一对一学员，问我要不要学习起号，我婉拒。一方面，被上门推销，有种被惦记的感觉，略感不适。另外，这种询问让我感到有点受刺激，毕竟我发推这么多关注者也不到1000，确实挺失败，被推销起号教学，像是一种嘲讽。

我研究了一下，这位贴主fo数这几天从300涨到了3000，也算是一时间最火的“起号达人”。不过看到他在此前发了1000多条，并没有多少粉，说明也是突然找到了流量密码。那么他的“秘笈”应该不难推测，大概就是下沉吧。

他的几个爆火贴都是极度下沉的内容，这些内容大概是多年前百度贴吧或百度知道里很平常的内容，与之相比，CSDN、知乎以及各大博客里的内容都显得过于高级。在技术方面，我一直都爱折腾，对这些内容很熟悉，许多基本技能也都是在那上面学会的。不过没想到那些东西在X上还能爆火，说明不同时代的人可能所处的平台环境不一样，但是内容需求都还是那些。

那么，我似乎也可以搞一搞，毕竟我现在也可以写长贴了，而且那种“教程卡片”我也早就驾轻就熟。但做那些确实兴致不高。我承认，那些技能我很熟练，因为算得上是“基本功”，但是确实没有兴趣回头再梳理一遍的动力了，即便很可能带来流量。

我喜欢的是技术，尤其是新的技术。最近越发悲剧性地发现，我所想写的都是些“流量黑洞”，但如果非得做出选择，我可以放弃流量。

X终究也只是马斯克的地盘，我不可能在这里永居，说不定哪天就被封了。但是技术学到手了，短期能够让我快乐，长期来看说不定能够用来做些什么。

嗯，我是来学习的而不是来传教的。因为下沉贴而涨粉，吸引到的也不见得是自己想交的朋友。来X，更主要的原因还是可以观察乃至有机会与真正的技术大佬交往。

如果要获得流量，那就必须要顺从于算法。但是越是了解算法和“流量密码”，我就越想逃离。我习惯了在各大平台中流浪，我从公众号逃离了，从知乎逃离了，从小红书逃离了，从抖音逃离了，甚至B站，我也越来越感觉无趣。

我在X待了几个月，并不是因为这里能涨粉，而是因为这里有种“社区感”，我能结交到一些有趣的人。但是，最终，我的宿命可能还是逃离，因为曾经温暖过我的“社区感”似乎随着天气渐凉而逐渐降温，不断吹来的是原以为独属于国内社交平台的流量文化风潮，带来的是一种熟悉而腐败的气息。

当然，可能X平台本来就是如此，只是他的算法是的用户不像国内平台那样总是推送不想看的内容。如此一来，既然不适，可以用自己的行动来清洗调整时间线。我尽量尝试，但又感觉越来越难调整。

我从小不善交际，但是从来没为这种状态感到沮丧，可能是很早就习惯了孤独。或许我终究只是自嗨，因为能与我同频在一起狂欢的人，一共也没几个，而我现在有800多关注, 或许已经是我需求的极限了。

对我而言，逃离与乃至“流浪”对我来说不是很糟糕。能嗨起来很重要，管它是不是自嗨呢？

关于诺贝尔奖的感想（2025）

AztecaAlpaca — Wed, 08 Oct 2025 00:00:00 GMT

一年一度的诺奖颁奖季过半，又是令国人失望的一年。作为一个打小热爱科学的人，我关注这个奖项十多次了，有那么几次挺开心的，比如钱永健、高锟、莫言、屠呦呦获奖，衷心地为他们高兴。但是其他年份，尤其是过去十年，心情越发不美丽。本文是我在当下的一些感想，其实也是我与朋友在失望之下的争吵中所达成的某种合理化解读。

我自我感觉成熟了，已经对诺奖祛魅。但出于对自己“墙头草”秉性的清醒认识，相信如果哪天中国人频繁拿奖到手软，我不会因为“物以稀为贵”而开始嫌弃，而是会重新为这个奖项赋予更伟大的意义，并对其大加赞扬。不过这些打脸的评价是留给未来的，所以在本文的标题中我需要加上2025这个年份，现在先把话撂这儿！当前的看法，也就如下这样吧。

欢乐是邻居的，我们什么也没有

2025年的颁奖还在继续，但是三项科学大奖已经名花有主。如往年一样，中国学者又一次地没能拿奖。后面还有三个奖项，想必大家兴趣不大，很多次颁发和平奖，我们感觉就像吃苍蝇一样，尤其是今年川普在颁奖季明显发力了，此时最好避其锋芒，毕竟此人惹不起，只能躲着。经济学奖，在当前形势下获奖显得有点不可思议，如果非要给，如果不颁给今日连发数文，抛出惊天理论的某日报，有点说不过去，我们姑且拭目以待吧！至于文学奖，莫言因为获得该奖，每每被推向舆论的风口浪尖，也算是个高危奖项。鉴于莫言得奖后在国内舆论获得的待遇，也可以认为中国人并不稀罕这种奖项。

相对于和平、经济和文学这三大“文科奖项”，国人显然更在乎“理科奖项”。过去这几十年，中国在科技领域发展迅猛，因此每次颁奖的时候也都跃跃欲试。但是自从屠呦呦获奖，至今已经十年了，三大科学奖每一次都与我们“擦肩而过”。

与自己的郁郁不得志相比，更气人的可能还是邻居家又在张灯结彩了。今年日本学者拿了生命科学医学奖和化学奖这两项大奖，刚刚看到石破茂现场直播打电话向生医奖得主坂口志文表示祝贺，电话列表里的名单又+1，化学奖颁给了北川进。今年的两次获奖使得他们在新世纪（2001年及之后）的25年里已经获得了22次诺奖，而且全都是科学类。日本曾在世纪初定下了“50年30次获奖”的宏伟目标，当时看起来如天方夜谭，结果时间刚过半，任务完成度已经超了70%。有人会说：诺奖都是颁给几十年前的工作，日本人在最近这二十年里水平是在下滑的。这或许是真的，但是凭借当前的惯性（优良传统的积累以及业界的普遍认可），剩下的25年再拿8次看起来不太难。

当我们谈论诺奖，我们在谈论什么？

“诺奖情节”可能像“世界杯情节”一样，一直是国人心里最容易被激发的几个痛点。

这两者背后存在很多共性。我国在各种中学生的学科竞赛中斩获无数，但在顶级科学大奖上收获寥寥；我国在各种单人运动项目上成果丰硕，奥运会等舞台上摘金夺银已成家常便饭，但是在大型的球类运动中却一直在“极度狼狈”和“比较狼狈”中上下波动。因为学科竞赛和个人体育项目的随机性要弱很多，而科学前沿的探索与足球场上的局面一样，充满了未知。作为乒乓球和羽毛球的强者，我们很容易派出十拿九稳的阵容，让观众充满了掌控感。但是这种掌控感在足球场上是很难获得的，即便是顶级球队也难说自己不会被爆冷。科研的创新则更是如此，很多发明都来自于出乎预料的尝试。所以我们都希望能出很多“诺奖级成果”，但是这方面急也没用，还是放平心态。

同时，也应当认识到，虽然很难获得某种必然性的成果，但科学的进步却是有迹可循的。首先是人才的培养，然后是资源的投入。日本在2000年之前，诺奖得主也是大概十年一遇，但之后却迎来了持续25年的井喷。诺奖的滞后性也是我们需要对过去的努力保留善意的重要因素，比如即便是今年的诺奖成果，也多是三十年前做出来的，彼时恰逢日本经济繁荣期，对科技上的高投入在日后开花结果。这或许说明，“大面积”地获得诺奖是用钱砸出来的。

我还是相信，用不了很久，我们会迎来丰收季节。在过去的几十年里，中国的科技发展是有目共睹的，人才积累已经到了堪比“人口红利”的程度，高强度的科研资金的投入也已经持续了数十年，虽然科研的投入产出比是另一回事，但是没有理由妄自菲薄。在之前，我对这种可能性还不甚乐观，但鉴于在近年数学界逐渐有很多华人学者崭露头角，在AI领域的科技突破几乎都成了在华与在美的华人内战，我的疑虑也逐渐消解。我在这里大胆预言：在国足下一次打进世界杯之前，中国学者一定可以拿到诺奖！

诺奖真那么神吗？

诺奖在19世纪的最后几年基于诺贝尔的遗嘱创立，至今一百余年。它作为最早的一批奖金丰厚的常设奖项，积累了极高的信誉度，以至于逐渐成了神一般的奖项，至少获奖者很容易在业内被碰上神坛。

那么我们要问：“诺奖真那么神吗？”

这个问题需要分两部分回答。一部分是获得诺奖的成果，一部分是颁发诺奖的这个机制。

其实第一部分没啥好回答的，在知乎上类似的问题很多，比如“牛顿与爱因斯坦谁更伟大”、“陶哲轩是不是菲尔兹奖得主中最水的”之类的问题，看着就感觉辣眼睛。以我的学术修养，自然也没有资格回答这个问题，但是看看手机，想想里面各种复杂的元器件，能够让我在每天的各种活动中离不开它，其中有不少是诺奖得出的贡献。当然，能够让我以小几千的价格用上这些“神器”，也少不了他们的贡献。

关于颁发诺奖的机制，可以聊的要多一些。当然，这也是写这篇文章的目的：分享一些历史八卦。至于什么理论，我没有什么成体系的东西,也不是为了说服谁，只是有些感想，而这些感想都来自于故事。

事实上，关注诺奖十多年之后，我逐渐感觉十月份的这个颁奖季并不是什么“学术活动”，而是一种“娱乐活动”。每到这个时候，就会有一些学者像选秀类节目一样一夜走红，成为大明星。但这并不意味着，评价这些顶级学者的这个机制就一定是完美的机制，就像奥斯卡小金人不一定会垂青最好的电影一样。

诺奖的历史开始于1901年，第一位获奖者是伦琴，很多人都受益于他发现的X射线。随后几年的一些奖项也都问题不大，比如居里夫妇等人，都是伟大的学者。但这其中可能有个共性：他们大多都是基于实验做出的成果。

相传早期的诺奖更重视实验而非理论，所以爱因斯坦这样一位理论物理学家，尽管早已成为首屈一指的科学巨匠，但也是到了在“爱因斯坦奇迹年”轰动世界16年之后的1921年才拿到了早就该属于他的奖项。

1921或许也可以看作诺奖历史上的分水岭。虽然对这一次获奖，爱因斯坦的期望可能并不高（因为他只拿了奖章，奖金则依据爱因斯坦与前妻米列娃的离婚协议被后者分走），但是之后的诺奖因的颁奖偏好彻底扭转。接下来的几十年一直优先考虑理论工作——这也是杨振宁在与丘成桐关于大型对撞机的“世纪辩论”中的一个重要论据。

这种扭转可能与当时的科学发展现状有关。在1920年代，量子力学横空出世，开启了理论物理学家的黄金年代，玻尔、海森堡、狄拉克、薛定谔、德布罗意、泡利、波恩...一连串如雷贯耳的名字，甚至都不需要在盘点诺奖就已经进入我们的视野，在大学物理的课堂上，他们早已组团对我等学渣进行了旷日持久的轰炸，是与牛顿、拉格朗日、高斯等一类的“洪水猛兽”。

无论是转变之前还是转变之后，都有很多遗憾，原因或许很简单: 获奖名额太少，伟大的成果却会在某个时期层出不穷。一个遗憾是在1921年之前偏向实验的年代，特斯拉和爱迪生没能获奖，两人之间的Drama很多，这次错过也让诺奖历史上少了些段子。在后来的几十年里，两位杰出的女性学者：发现DNA双螺旋的罗萨琳德·富兰克林和通过实验证明了“宇称不守恒”的吴健雄都没能拿奖，这些都被认为世纪公案，虽然早已经过了50年保密期，但还需等到詹姆斯·沃森和杨振宁等过世后才可能揭晓。

这种遗憾不可避免，只是有些是学者们未能获得认可的遗憾，而有些人虽然没有得奖，却分毫无损于他们的历史地位，比如托尔斯泰、门捷列夫等人（不知为何这个名单里的俄国人格外多）。既然是遗憾，那只能说这是诺奖的遗憾，他们的愚蠢使得诺奖永远无法配得上这些历史级别的伟大人物。

想获得诺奖，需要的要素非常多。有人总结为“四行”：

你的成果行；
有人说你的成果行；
说你成果行的人很行；
你的身体得行。

这四条缺一不可，尤其是第四条。

诺奖通常只是一种“迟到的认可”，至于迟到多少年，则是个随机数。李政道与杨振宁的“宇称不守恒”提出仅一年，就于1957年获奖。但是与杨振宁同岁的约翰·班尼斯特·古迪纳夫（显然，我更喜欢直接用他的姓，Goodenough），则是到了2019年才拿到了诺贝尔化学奖，此时他已经97岁高龄，而他最关键的那个成就则是在近40年前的1980年做出的。这个故事中，似乎一切如获奖者的名字一样，Goodenough。好就好在，老先生足够高寿，给诺奖足够多的时间来弥补。

然而有些伟大的学者就没有为诺奖提供这种机会。比如当2000年的物理学奖颁发给了为“半导体研究的突破性进展”做出巨大贡献的三位学者的时候，人们忍不住想起了集成电路的发明人之一、英特尔创始人罗伯特·诺伊斯。虽然这一次颁奖是满员的，但这个领域的影响如此甚远，对其关键贡献多颁发一两次或者早颁发十几年，想必不会有人提出质疑，可惜的是诺伊斯已经仙逝10年，而他作为“八叛徒”之首，硅谷最重要的奠基人之一，彼时其门生故吏已经在他曾经耕耘的地方开枝散叶，欣欣向荣。而其精神遗产也传递至今，方兴未艾。

从这里，我们可以看出，有些人以诺奖为荣，有些人让诺奖以之为荣，也会产生诸多遗憾，令人追悔莫及。诺奖的评价制度也是在变化的，在评判的过程中，实际上是缺乏确切标准的，它依赖于诺奖委员会的集体品味。这不是诺奖的缺陷，因为好的学术研究本身就带着审美性质，那种美恰恰是能够让思想穿透时代迷雾而照亮未来的特质。

归根结底，简单粗暴地在每年选定几个幸运者获奖，充满了人类世俗的那种一厢情愿式的天真。科学是一个有机的生态系统，它的发展逻辑从来都不会去适配一个机械化的评价体系。在这种背景下，过分地强调以诺奖为目标，对于一个丰富度极高的生态而言，未免有些削足适履。

回到那个问题：诺奖真那么神吗？

我想我们会有自己的答案——神怎么会犯错误呢？而诺奖的错误又何止那么一两次意外？

仅仅是游戏

在当今社会，人们总是有着强烈动机去评价一切，但这种尝试会产生很多副作用。人们会把一些预先设定的规矩或者某种评价体系当成神谕，但仔细去了解，又难免为其感到尴尬，甚至惊呼其不过是个草台班子。当然，无意冒犯诺奖的评奖体制，它只是并非绝对正确，但也算得上“很好”或者“最不糟糕”的一个评价机制了。

我们太喜欢对某事物做评价了，但很少又评价体制能像诺奖一样跨越百年依然保持权威。除了这种对前沿科学成就的评价机制之外，还有诸如“大学排名”和“教师考核”乃至“学生升学”等充斥于视野之中。这些评判成了人们很多重大决策的关键依据，而为了能够在这种评判中获得更好的位置，多少人挤破脑袋放下尊严去“孜孜以求”。

但在这种狂热中，似乎总有些不对劲的地方。正如我们有理由认为绝大多数诺奖评委拿不到诺奖，其它那些奖项、排名中，作为评委，如何去自证明其权威性？尤其是“大学排名”，仿佛各大顶级院校都不过是他们排序游戏中的棋子，被其玩弄于股掌之中。对此凭良心问候一下：搞这些排名算法的专家们，有几位够得上这些高校教授水平？

这种评价背后，充满了游戏的感觉。恐怕站在评审专家的视角，感觉更是如此。

既然是游戏，我们何必去把它神化呢？

跑步的记忆

AztecaAlpaca — Mon, 29 Sep 2025 00:00:00 GMT

跑步记忆

我不知道自己喜不喜欢运动，但在 2021 年，确实进入了一段跑步的高潮。那年 10 月份跑了 200 多公里，一度以为自己要进化成一位"严肃跑者"，但在月底脚踝受伤，歇了几个月之后，跑步的习惯没有继续维系下去。

围绕这个主题，我搜集一些记忆碎片。

大学夜跑

我在跑步方面毫无天赋可言。大二开始，我有过一波长达许久的夜跑经历——当时与好友每天晚上绕学校跑一圈（大约 4km），持续了一年左右。那位同学是我在本科阶段最好的朋友。不过后来，到了大三秋冬交际，因为雾霾实在严重，加之我与他的关系"破裂"，遂终止。

2018：第一次半马

说到参加马拉松，我在更早的时候参加过一次半马。

那是 2018 年，成都的第二届马拉松。那个时候报名轻松一些，不像现在热度这么让人苦大仇深。当时设有 5km、半马以及全马，我和同学一起中签，他的是 5km 欢乐跑。

那一次我非常认真地进行训练。本科时那位跑友同学告诉我，如果能够轻松跑完 10km，跑完半马问题不大。9 月份报名，10 月底比赛，时间算得上比较充裕，可以有条不紊地准备。我的目标是先跑下 10km，这对我也不是什么挑战，训练了几次就完成了。后来不断提升，每周提高 2～3km，在比赛前一周左右跑完了第一个半马。

那一次马拉松，也是我目前唯一一次亲临现场感受气氛。那个气氛非常美妙，路边的观众非常多，助威声感觉非常震撼，烘托到了那种氛围——不跑完实在是浪费，毕竟一生之中要走那么多路，有人为你呐喊欢呼的并不多。观众应该多是赛道沿线的居民，也有不少沿线的小餐馆老板，为参赛者提供了很多诱人的美食——如果不追求成绩，吃一路估计问题也不大。赛事方准备的补给也比较丰富，大概每 2.5km 一个补水站，每 5km 一个物资更丰富的补给站，此外还有临时厕所方便解决问题。跑完之后，我领到了两个大礼包，装了水、水果和能量棒，还有应对失温的防护物资。加上之前领取的参赛大礼包，也差不多值回票价了。

读研初期：断断续续

刚读研时，整个人像打了鸡血一样，开学之后连跑了一个月。然而过了国庆假期，不光长胖了，肌肉松弛了，人也没那么有精神了。从那以后的锻炼就是断断续续，多年都没有过真正系统性的锻炼。

2021：跑步的高潮

疫情的时候，过得实在是压抑，于是又慢慢地重启了跑步。到了 2021 年夏天，与前女友分手了，我开始不想那么多了，每天把很多时间花在跑步上。9 月份与 10 月份进行了一个半月左右的高强度训练，尤其是 10 月份——到 10 月 24 日那次半马训练受伤为止，该月跑了 220km，其中包括 2 个全马。

全马初体验

我在 2021 年 9 月份开始跑步的一个重要因素是当时报名了成都马拉松。那段时间需要一种情绪排遣的渠道，决定干一票大的，报了全马。不过之后并没有中签。我为了准备这场马拉松而开启的持续训练，后面发现没有中签时已经跑了几天，但这件事丝毫没有影响到我——我开始喜欢上跑步的感觉了。

到了国庆节那天，身体感觉越来越好，跑完半马毫无压力。我决定在这个日子做一件有意义的事情：跑完人生第一个全马。于是那天一早开启了这次挑战。前面的半程体感不错，但到了最后 10km 左右，我回到操场来收官。最后几公里的印象极其深刻——当时已经到了中午，天气变得热了起来，我一度感觉自己的后脑勺有点麻木，甚至感觉自己跑不了多久就要挂掉了，现在想来颇为后怕。不过好在把最后那一段跑完之后，补了点水，稍事休息，一切恢复正常。那一次，我的成绩是 5 小时 20 分钟，显然不是个好成绩，但也足够在正式马拉松中不被关门了。

这一次挑战成功让我备受鼓舞。虽然没有机会在正式舞台上挑战自己，但只花了 20 天左右，就提前跑完了自己的第一场全马，非常兴奋。后面休息了几天，重新投入了训练。在整个 10 月份，我对跑步的热情达到了高潮。

成为跑步爱好者

那段时间，我对跑步陷入了狂热。把之前读过的《当我谈跑步时，我谈些什么》又刷了一遍。也经常刷一些跑步区博主的训练视频，比如山雨小月、黑影 TV。对波士顿、纽约中央公园那些跑步圣地充满幻想。甚至会把一些马拉松直播从头到尾刷一遍，两个小时都饶有兴致。然而，那个晚秋与早冬，也不断刷到各地马拉松被取消的噩耗。我当时感觉自己已经融入了这个跑步爱好者的圈子，为他们的突破感到兴奋，为他们的糟心事感到难过。

2021 年那届成都马拉松很不幸——不光错过了让我实战的机会，还因为疫情，一开始推迟了一个月，后来直接取消，主办方的所有准备都付之东流。我并没有幸灾乐祸，而是为他们感到惋惜。

受伤之后

受伤之后，我开始骑行——一开始是共享单车，后来买了一辆山地车，开启了轧马路之旅。而跑步，重新回到了时断时续的状态中。

跑步类的视频在 2021～2023 年都是我喜欢看的，高潮当然是几次大满贯赛事。尤其是基普乔格在 2022 年柏林马拉松和吉普图姆在 2023 年芝加哥马拉松打破世界纪录的比赛，看得让人热血沸腾。最心痛的事情则是在 2024 年春节前后，吉普图姆车祸身亡，享年 24 岁，此时他才参加过三届正式的马拉松赛事。

跑步与推特

我想到自己的跑步经历似乎与当前搞推特很像。

在推特上搞了大概半年，发了很多内容，自认为质量不错，但只有不到 400 fo。很少有这种事情：每一个涨 fo 都能让我欣喜若狂，每一个掉 fo 都让我痛彻心扉。就像跑马拉松一样，跑完之后能记住每一公里的身体与心理状态，虽然全程都很艰难。

我不知道这种艰难的状态会持续到哪一天，但我似乎并非真的执着于涨粉。这些数据可能会在某些时刻让我感觉不受系统待见，但丝毫不会影响我的发推热情。可能我需要的只是一个表达的场合，至于所表达的内容有没有人看、有没有人喜欢，我都会去做。

跑步时的心理状态也大致如此。报名了成都马拉松没中签，但跑步本身的感觉已经让我沉醉——动机消失了，行为反而留下了。

尾声

后来，我不怎么关注跑步了，由热爱转变为一般，后面甚至重新变回了恐惧。原因有许多——首先自然是不够自律，其它的可能是有其他事情要做，也可能是因为年龄增长，注定了在跑步方面获得"成长的感觉"越发困难。

21 年没能再次中签成都马拉松，比赛后来也停办了。再后来，中签逐渐成了不可能的事情——除了我自己对跑步的热情连年走低之外，这些年马拉松的热度却在逐年递增。成都马拉松的档次算得上比较高，主办规格越来越向大满贯看齐，中签率连年降低。或许，2018 年那次将会成为我记忆中的唯一。

但无论怎么讲，那几年的跑步都算是美好记忆,我希望还能有后续。

代码“劫后余生”:记一场Git灾难与抢救

AztecaAlpaca — Sun, 28 Sep 2025 00:00:00 GMT

经过一天的工作，我昨天配置的博客评论区离奇消失，查找记录时发现更惊悚的事：我近几天的Git提交记录全部失踪，并因一个误操作导致代码回滚到三天前的基础版本，所有后期工作成果瞬间清零。我向 GPT-5-Codex 求救，它立即启动高级Git命令进行抢救。最终，在GPT的指导下，我执行了几行恢复命令，代码起死回生，成功回到了误操作前的状态。这次劫后余生的经历，让我深切体会到Git的强大与学习它的必要性。

如果你对类似的情况感到恐惧，或者对Git的使用还不够熟悉，可以参考我的自救手册。本文主要讲述这件事情的前后经过。

故事的前后经过

今天我发现博客的评论区没了，我感到很奇怪，因为昨这是我昨天下午做的，当时也提交git了，可能是今天进行主题修改的时候，AI不小心把该部分代码删掉了。虽然有点小不爽，但想来也不是很复杂的事情，毕竟昨天配置评论区的时候也没费多大劲。

然而，当我打开windsurf试图查找之前的记录，发现GPT-5-Codex一如既往地陷入了“内耗式”地查找，来来回回几圈之后，我忍不住叫停问它：到底找没找到？它的回答是，没有…

我很震惊，因为这中情况不太可能发生：最近每一次都是完成一小波修改就git一下，已经养成了习惯。昨天的那个配置不可能丢失，我对那一部分工作印象很深刻，我坚信不是我出现幻觉，就是AI出现了幻觉。我打开了GitHub Desktop（我之前都是直接在IDE上随手提交的，功能相对简陋），试图依次查找与博客评论区相关的配置，我要跟AI对质！

然而，真正惊悚的事情就此开始：我发现GitHub Desktop上记录的最新提交记录是3天前（25日）。我惊慌之余打开了GitHub网站，发现的确如此，我这几天的记录工作记录不存在。我很困惑，难道是创建了什么新的分支？于是就在GitHub Desktop上随便点点点，突然，当我切回Windsurf，发现该IDE上的文件夹目录已经回归到了25日… 话说，25日的时候，我这一系列工作才刚开始没多久啊！我傻了。

之前曾经出现过对git的误操作导致一些记录找不到，不过那个时候的工作烂尾的较多，丢失也不心疼。这一次，我好不容易把网站搭好，在25日晚上线，颇有成就感。25日之后，我又对该网站进一步完善，增加了评论区、搜索页、GA4的网站流量监控、深色主题等配置。我对UI交互方面也进行了许多优化，自认为体验比最初的版本好了许多。而此时我能找到的版本仅仅是25日中午的版本，当时距离上线的基础款配置还有许多工作要做！

此时的我感觉非常沮丧，因为在半个小时之前，我还沉浸在各种幻想中，想着未来如何更进一步地把网站功能与内容完善，然后以此为根据地做大做强… 瞬间，一切似乎都成了泡影，退回了解放前。如果真如此，恐怕我没有那个心气再搞一次解放战争了。

慌乱之中，我强行镇定一下。我意识到，这件事情的发生大概率是自己对git的功能不够了解导致的，我常用的只有那几个命令，而且多数时候都是拿鼠标操作的。有很多高级命令，我或许见过，但根本不知道其背后的含义。当我使用GitHub Desktop的时候，对一些陌生操作背后发生的事情是无意识的。

AI应该很懂这些！我更需要做的事情是减少自己的贸然操作，看能不能搬到救兵。于是我回到了windsurf，继续与GPT-5-Codex进行交流。把我刚才的所作所为、当前处境以及对过去几天已日渐模糊的记忆碎片一五一十地和盘托出。为了让它认真的拯救我，我甚至打出了感情牌，告诉它如果这几天的工作记录丢失，我将失去活下去的勇气…

于是，GPT直接开始了各种工具调用，使用了很多我没听说过的 git命令，换着花样地审查各种git记录。我就像参加手术的患者家属一样在手术室门外焦急地等待着，而GPT在这个过程中，一句宽慰我的话都没说… 甚至除了思考，不被折叠的文字输出都很少。我一度想打断它，直接问：行不行啊？

就在我耐心快用光之前，它告诉我那些记录还在，列出了我今天commit的几条记录。此时的我仿佛看到了曙光，开始反复问它能不能修复？它告诉我，记录还在，应该如何如何操作，给出了几行命令。但此时我并不理解这些命令的意义，只想它告诉我能不能恢复…它依然没有正面回应，只是从它的语气中感觉比较稳…

于是，我在它的指导下执行了那几行陌生但寄托了我所有希望的命令，然后就是起死回生的时刻，我长舒了一口气。此时，我的代码回到了我的”残之一手“点击GitHub Desktop的那一刻之前的状态，我博客配置中，评论区的内容依然找不到。但是我已经不再为此感到一丝一毫的不爽，全是劫后余生的庆幸。

后面，借助Windsurf+GPT-5，我把评论区补上了，又将其它已经发现的小bug进行了修复，然后开始写了这篇博客。这件事情始于经验的缺乏带来的误操作，不过还好我用的是git，这款软件真是大慈大悲的发明。过去两年我一直在使用git，但是只学会了最基础的操作，这件事情也让我意识到多学点git应该没啥坏处。

虽然有点卡，但我喜欢Liquid Glass

AztecaAlpaca — Fri, 12 Sep 2025 00:00:00 GMT

更新了一下苹果的系统，先是手机，后是电脑，体验良好。

不过接下来需要考虑的可能是更新一下设备，老旧的款式仿佛有点卡，只是别人不那么说，我也不太确信，也不希望如此。

我的好感来自于两点：

上个版本的“黑金主题”，切换过来之后一直没搞清楚怎么恢复之前的模式，被恶心了一年；
WWDC上呈现的效果过于拉胯。过了几个月之后，惊喜地发现它远比预期的漂亮。

顺便地，我也把MacOS系统界面进行了修改，设计很好看，但可能是适配性问题，在刷网页的时候有点卡。

这一次，MacOS的系统代号为Tahoe，取名自著名的太浩湖。

这是一个旅游胜地，在文化与科技史上都具有传奇色彩，比如《教父2》电影的取景，比如著名的"AlexNet拍卖会"。可参考太浩湖的传奇故事及其数据可视化版本。

韩信评传：月光下的不世之功与宿命悲歌

AztecaAlpaca — Thu, 07 Aug 2025 00:00:00 GMT

在中国历史的长廊中，有些名字的陨落，比其升起更加令人扼腕。韩信，便是其中最耀眼的一位。他的一生，是一场关于天才、机遇与宿命的宏大戏剧，而贯穿始终的，是他那既能成就伟业、亦能招致杀身之祸的青春锋芒。

韩信的传奇，始于一道清冷的月光。若无萧何月下决绝的追寻，韩信或许终其一生，也只是个在市井中忍受过胯下之辱的落魄青年。那一夜，注定了他此后的不凡，也为他未来的悲剧埋下了伏笔。他得到了年长近三十岁的刘邦的破格提拔与充分信任，这在当时是一场匪夷所思的豪赌。刘邦赌上了自己的天下，而韩信，则用他那属于年轻人的、无所畏惧的才华，回报了这份知遇之恩。

在属于他的那短短数年高光时刻里，他几乎就是战争的化身。明修栈道，暗度陈仓；背水一战，置之死地而后生。这些军事史上的奇迹，无一不带着年轻人特有的傲慢、任性和敢于打破一切常规的锐气。可以说，正是这份不羁的性格，才让他立下了那样的不世之功。如果他是一个循规蹈矩、唯唯诺诺的人，他也绝不可能成为那个让项羽都束手无策的“兵仙”。

然而，当天下大局已定，当开拓的时代让位于守成的时代，他性格中那些曾经的优点，便成了最致命的缺陷。最大的问题，在于他太年轻了。不到三十岁便功高盖主，这让他难以低下高傲的头颅，去对那位已经步入晚年、心思深沉的君主察言观色。

对于刘邦而言，矛盾是显而易见的。在征讨英布中箭受伤后，他深知自己时日无多。此刻的他，需要的不再是一个能够改变战局的天才，而是一个能够确保政权平稳交接的“可控的听话的人”。韩信的危险，不在于他知道了什么秘密，而在于“听他的人太多了”。他的威望和能力，已经成了一个刘邦身后无人能镇住的巨大变数。

这道横亘在君臣间的年龄鸿沟与权力逻辑，是无法跨越的。或许，如果刘邦能年轻三十岁，他会欣喜于与这样一位军事天才惺惺相惜，恨不得日日与他泡在一起。但现实是，衰老的帝王需要的是稳定，而如日中天的韩信代表的却是不可知的未来。

因此，韩信的结局早已注定。他似乎也对此有所预感，明白自己踏入的是一场华丽却必将迎来清算的盛宴。他对刘邦的知遇之恩心怀感念，所以在死亡的罗网降临时，他没有做过多的反抗，带着几分认命的意味，走向了长乐宫的终点。吕后是行刑者，但其背后，无疑是刘邦的默许。那一句“且喜且怜之”，道尽了这位开国帝王最真实的心态：喜的是，一个足以动摇国本的隐患终于被铲除；怜的是，这样一位不世出的英才就此凋零。

韩信的一生，是青春的赞歌，也是青春的挽歌。他用短暂的生命证明了，一个年轻人凭借天赋与胆识可以达到怎样的高度。但也用自己的鲜血警示后人，当这种无双的才华触碰到权力的红线时，会迎来何等冰冷的结局。他注定要在他生命中的伯乐之前死去，要么在精神上被磨去棱角，要么在肉体上被彻底消灭。而那个时代，终究没能给他第三条路。

R.I.P, Diogo!

AztecaAlpaca — Sat, 05 Jul 2025 00:00:00 GMT

利物浦前锋迪奥戈·若塔（Diogo Jota）不幸逝世，享年28岁。据传他因为做了气胸手术，无法乘坐飞机，于是驾驶自己的兰博基尼，在其兄弟安德烈的陪同下前往利物浦，但途径西班牙境内，路况糟糕，在试图超越一辆卡车时发生了爆胎事故，导致车辆失控，兄弟俩不幸遇难。

在本博客中，我日常分享的第一篇就是类似于讣告的文章，这令人遗憾，但将其献给迪奥戈又是一种荣誉。

作为利物浦球迷，对这件事情感到震惊，但又有些麻木。似乎霉运总是会在这只球队最欢快的时候找上门来。利物浦今年刚刚拿到了阔别数年的英超冠军，而28岁的迪奥戈·若塔正值生涯的黄金年龄，备受期待，但一切都戛然而止了。

或许坚强地面对悲伤是利物浦球迷的必修课。我从2005年开始看球的时候就追随这家俱乐部，从“伊斯坦布尔之夜”开始，然后是近十年没有冠军进账的漫长等待，终于迎来了克洛普伟大的执教生涯以及克洛普与斯洛特堪称佳话的交接。在两天之前，我们经历了最开心最憧憬的一段时间，但现在需要重新开始。

为什么热爱利物浦？因为这支队伍的命运与我们的艹蛋人生太押韵了。

与这支球队共同经历过2005, 2019, 2020, 2025，两次欧冠，两次英超，次数没有那些豪门那么多，但每一次都是苦尽甘来。本以为40天之前的狂欢可以继续，但却传来永远不可挽回的噩耗。

在球迷的意识星空中，1985、1989年的那些星星永远照亮着一个个黯淡的夜晚。2025，天上又多了一颗星星，照亮不屈的人们继续前行。感谢迪奥戈在过去的五个赛季里的兢兢业业，为球队带来了一个个进球和一座座冠军奖杯。

You will never walk alone！

注：本文中的图片均来自于利物浦官网

《牛顿传》读后记

AztecaAlpaca — Tue, 01 Jul 2025 00:00:00 GMT

在阅读《牛顿传》之前，我对牛顿的印象还停留在课本和科普故事中。带着对这位科学巨匠的好奇，我试图通过这本传记，重新认识牛顿的真实人生与复杂性格。以下是我的一些思考与感受。

首先，毋庸置疑，牛顿是一个了不起的人物，很少有人能像他一样对我们每个人产生如此深刻的影响。他给世界带来的改变无需多言，但我们对他的认识和了解却非常肤浅。

我小学时就开始借阅关于牛顿的书，但当时阅读能力太差，读不下去，只是对他的一些故事有所耳闻，比如知道他出生在克伦威尔时期，但那时我并不知道克伦威尔是谁。后来我对科学史有了一些初步的了解，但我一直有意避开牛顿这个人，因为他太过久远，是个难以理解的神秘人物，总有种敬而远之的心态。相对来说，我当时更愿意去了解其他人，包括爱因斯坦、居里夫人、费曼等科学家。

这一次，我终于打开了牛顿的传记，阅读欲望很强烈，一气呵成地读完了全书。牛顿的生平非常丰富。首先，他寿命很长，活了 84 岁，这在当时属于非常难得的高寿。他的经历也很丰富。他出身不算差，后来在读书过程中一度并不出色，但突然奋发，从此之后就一直是最优秀的学生。后来他从事学术，接替了巴罗的位置，成为卢卡斯讲座的教授。他在20多岁的时候就做出了非常突出的成就，比如著名的万有引力，成了明星学者，并能够出入非常高级别的场所，在后来还成了政府重要的官员和国王的座上宾，成为全欧洲的话题人物。

我们对他的了解更多的是他作为科学家的成就，比如提出了万有引力定律、牛顿三定律以及光学原理，当然还有微积分。除此之外，我们对他的了解相对较少，偶尔听说他对炼金术很感兴趣，并且他非常虔诚，是一个清教徒。此外，他还炒股，有着惊世骇俗的韭菜经历，他一度血赚，最终血亏，最终成为了南海金融泡沫的受难者。关于他作为皇家造币厂厂长的经历，我也有所了解，但了解得并不多。通过这些事情，我所了解的还是一个比较片面、比较干瘪的牛顿。而这次读他的传记，让我对他这个人生框架有了更加丰富、多维的感知。

通过这部传记，可以感觉到牛顿脾气古怪。他性格孤僻，不喜欢教书，求胜欲很强，经常与一些人陷入难以言说的争斗。他非常小气、极端记仇，弱势的时候隐藏自己，强势的时候重拳出击，终身热爱玩弄权术。这些特质在他与莱布尼兹和胡克的争斗中有所体现。通过牛顿的视角，胡克可能是一个十恶不赦的小人，但由于对那些历史缺乏全面的了解，也难说清他俩之间的是非曲折。

以上特质对一个人来说不够光彩，但对牛顿来说倒无所谓。因为他在科学上的贡献太突出了，整个现代社会都蒙受他的恩泽，相比之下性格上的缺点完全可以只被当作补充性的谈资。当然，牛顿也有很多朋友，如巴罗、惠更斯、哈雷和洛克等人，这些人给了他很多帮助，也在某种程度上弥补了他性格上的一些弱点。

我们更应了解牛顿作为科研工作者的一些特质。他对科学的影响很深刻，一方面在于他提炼出的重要结论，这些结论奠定了未来数学和物理学的基础；另一方面在方法论层面，他对理论的简洁性和可理解性的追求非常执着。此外，他也是比较早追求理论可证伪性的学者。比如，他在《光学》这本书的出版上，除了列举他的研究工作之外，还增加了一些批判性的内容，以“质疑”的形式体现，并且每一次改版都会增加很多质疑内容。这些批判性内容出现在他自己书上是很有趣的，显得严谨、自信而强大。

牛顿的动手能力极强，这些可能是被忽视的。他善于设计实验来对他的想法进行验证，也经常做一些发明创造，比如自己设计与研制三棱镜从而研究光学规律。他在担任皇家造币局的厂长期间，对硬币的设计与生产进行了革新，大大地打击了假币产业，很多发明甚至沿用至今。担任造币厂的经历体现了他出人意料的管理能力，但这并不是孤例。牛顿后来还拯救了声明濒临扫地的皇家科学院，只不过这段作为院长的履职经历也让该科学院打上了过深的牛顿烙印，很多人也承袭了牛顿性格上的缺点（或许这就是所谓的“顿感力”吧）。

此外，牛顿非常勤奋。无论是做科研还是做皇家造币厂厂长，都能看出他是一个名副其实的“卷王”，工作态度认真，对细节一丝不苟。所以我们不能单纯地只认为他的伟大成就是建立在他天赋的基础之上，他的努力程度也是绝大多数人无法企及的。

牛顿还有一个强大的地方就在于他的身体特别好。他几乎没有患上当时常见的一些疾病，而且去世时依然有两排健康的牙齿，这时他已经 84 岁了，这很令人惊叹（反观同时代同样长寿的路易十四...）。另一个能体现他身体好的地方在于，在他的研究工作中，事实上花了很长时间进行炼金术的研究。在这个过程中，他做了大量实验，需要接触大量的重金属，这通常会对身体产生负面影响。但是，即便在牛顿体内检测出超标的重金属，他依然能够保持长寿和健康的状态。他也是到了八十岁左右身体才开始明显地被疾病困扰。更值得一提的是，他一生都保持着清醒的大脑，思维能力到了很晚的时候才开始有衰退迹象。

牛顿职业生涯中，曾花费大量时间进行当时以及后来都被视为旁门左道的炼金术研究。他深知世人对此的看法，因此刻意隐藏相关记录。但他在这方面投入的时间长达25年，甚至超过了在数学和物理上的投入，这令后人深感遗憾。然而，如果我们站在牛顿所处的时代回溯，或许会有不同的看法。当时的科研尚未有清晰的定义和“正统”道路，一切都需要探索和尝试。牛顿只是凭借其天赋和努力，在迷雾中摸索前行。

我们可以设想两种场景。其一：牛顿在炼金的时候突然灵光一闪，指出“炼金术”是不可能，然后给出几个定律，说不定就会提前几十年发展出现代意义上的化学，那样他已经足以封神的成就之树上又将结出一颗伟大的果实；其二：如果当时牛顿在物理学上花了数十年尝试但不幸地毫无建树，但在微积分方面做出了开创性成果，他依然会被认定为历史上最伟大的科学家之一。那么后世是否可以这样说：“他本应该把更多时间花在数学上而不是在研究那些宇宙规律上浪费宝贵的时间与天赋”？

或许，对牛顿而言，数学、物理和炼金术是一个相互关联的整体。他并非刻意划分学科边界，而是对整个自然体系进行深入思考，很多后来被认为有用的概念，不过是他对整个体系思考（或许思考的核心就是怎么炼出金子）的副产品，他“顺便”奠定了后来的数学和物理学基础。也就是说，我们今天所走的“正统”科研道路，正是牛顿当年“浪费时间”探索出来的。他尝试了无数条路，其中一些最终通向了真理，成为了后人眼中的康庄大道。而那些没有成功的尝试，则成为了后人眼中的“弯路”，但正是在这些“弯路”上的试错，最终廓清了为数不多的那几条正道。

或许牛顿会说：“我尝试了一百条路，帮你们走通了其中的几条。若非我‘浪费时间’，你们在科研工作中的成功率都要归零。然而你们还嫌弃我当时走了九十多条弯路！”

用当前流行的句式表述就是：你不能只有在吃红利的时候才认可祖师爷当初的卓绝努力。在科学发展中，反复地印证着一个道理：伟大的成就通常建立在前人无数次尝试的基础之上，即使是看似“无用”甚至荒谬的探索，也是孕育科技突破的必要努力。

正所谓：

年少才成惊四座，数理光开立声名。
微积分理辟天地，万有引力定星行。
三大定律昭千古，光学棱镜证分明。
学贯天人精术算，推演玄机运数精。
炼金之术沉迷久，世人讥讽笑痴情。
谁知试错成正道，拓路前行入慧庭。
假若昔时不苦索，何来今日化学明？
千条歧路铺新径，后世安能讥梦萦？

本文写于2025年1月17日

《暗淡蓝点》读后记

AztecaAlpaca — Tue, 01 Jul 2025 00:00:00 GMT

在浩瀚宇宙中，地球只是微不足道的一粒尘埃。然而，正是这颗“暗淡蓝点”，承载了人类全部的历史与情感。本文将从科学与人文的视角，分享我对卡尔·萨根《暗淡蓝点》一书的阅读体会，探讨我们在宇宙中的位置与意义。

卡尔·萨根去世于1996年，那时我还很小。几年后，在一本少儿科普读物中看到缅怀他的文章，于是他也成了我小学时记住的为数不多的几位外国科学家之一。

中学时读过《日本平家蟹》，当时阅读能力有限，没能理解文章背后的思想。不喜欢那种娓娓道来的叙述方式，更不喜欢那些虾啊蟹啊之类的事物。大学时，纪录片《宇宙》真正把我带进了科学殿堂，对“平家蟹”的疑惑也得以解开。

“平家蟹”揭示了一种造型上类似于日本武士的蟹类，被当地渔民认为是随平家沉入海底的武士们的化身。但卡尔·萨根告诉我们，当地渔民捞到长相与武士神似的螃蟹后会将其放生，以表达对平家武士的缅怀。久而久之，这类螃蟹的种群就繁衍壮大——本质上，这是一种“人工选择”（也可以说是经人之手的“自然选择”）。平家蟹的故事让我开始掌握用科学视角理解自然现象的技巧。

年轻时喜欢科学视角，却更沉迷于宏大叙事。毕竟，煌煌大国，数千年绵长文明，沧海横流与歌舞升平交织的历史，总让人热血澎湃。然而，后来发现，当宏大叙事照进日常生活时，总感觉有些不协调。这很正常，毕竟历史中最不起眼的人名，在当时恐怕都是显赫一时的人物，而我们在历史长河中不过是注定被遗忘的一颗水滴或一粒沙尘。

后来，在一个播客节目中，听到主播朗读《暗淡蓝点》中的那段文字，那种蓦然回首的动人瞬间在脑海中再也挥之不去：

“再看看那个光点，它就在这里。这是家园，这是我们。你所爱的每一个人，你认识的每一个人，你听说过的每一个人，曾经有过的每一个人，都在它的上面度过他们的一生。我们的欢乐与痛苦聚集在一起。数以千计的自以为是的宗教、意识形态和经济学说，每一个猎人与采集者，每一个英雄与懦夫，每一个文明的缔造者与毁灭者，每一个国王与农夫，每一对年轻爱侣，每一个母亲和父亲，每一个满怀希望的孩子，每一个发明家和探险家，每一个德高望重的教师，每一个腐败的政客，每一个‘超级明星’，每一个‘最高领导者’，人类历史上的每一个圣人与罪犯，都生活在这里——一粒悬浮在太阳光中的细小尘埃。”

这是“旅行者一号”的视角，也是科学探索者的视角。这个世界上，总有不少野心家吹嘘自己滔天的权势与不朽的功绩，但在宇宙之中，他所在乎的一切不过是某一尘埃之上瞬息之间的“自我感觉良好的错觉”。

我们绝大多数人，在这个充斥着拥堵与摩擦的人世间，也常感慨生活的乏味与人性的险恶。但在宇宙尺度下，这种体验既不见得比微生物的冲撞与摩擦更高级，也不见得比王侯将相的自我陶醉更卑微。在这个被假象与真实反复折叠的世界里，开心也好，压抑也罢，都不过是人在与自然互动中产生的生理反应。当我们代入“旅行者一号”的视角，这些纷繁复杂的情感体验与生理反应在空间上的局域性以及在时间上的有限性都不超过那个暗淡的蓝点。

自从人类发现了科学的用处，就再也无法压抑对太空的向往。齐奥尔科夫斯基说：“地球是人类的摇篮，但人类不可能永远生活在摇篮里。”然而，当人类终于能够跳出自己的摇篮，回望浩瀚星海中的暗淡蓝点时，又茫然发现这广袤宇宙中再也找不到另一个家园。或许这一百多年对宇宙的探索，最有价值的结论就是：“人类不可能永远生活在摇篮里，但是地球——那个人类的摇篮，是唯一一个能够长期包容人类的家园。”

就像每一个在悸动的青春时代勇敢离家出走的孩子，终究会发现故乡是唯一让自己牵肠挂肚的地方；就像每一个攒够了钱等到假期的城市居民，当他们终于抵达魂牵梦绕的旅游景点时，发现自己可能更想回家躺着。

一个人对社会了解越多，越感觉自己的有限；对世界了解得越多，越对自然存敬畏之心。科学的价值大抵如此——它可能没办法帮人类打造一个天堂，但它可以让人类更充分地认识自己。

当我们把视角从“旅行者一号”拉回到地球家园，会发现自己虽然渺小，但拥有丰富的感知能力。一草一木、一花一叶、一缕阳光、一口空气，都足以在某个微小瞬间滋养精神世界。地球虽不过是诸多星球中不算特别的一个，但却足以让数十亿人类倾其所有去感受其万千气象。

我们无需纠结于自己是否会青史留名，因为有些东西不过是某些特权群体为了塑造对自己有利的“共同意识”选择性编排的故事合集。我们可以在有限的认知范围内质疑其准确性，但终究没有解释权。

但我们每个人，在人类视角中伟大也好渺小也罢，都拥有一个更加鲜活、更有温度的小世界。我们经历的每个瞬间都是真实的，仔细品来也常能感受到其精彩。将这些真实与精彩进行抽象整理，或许就会发现科学蕴藏其中，或许生活中的真理远比宏大叙述中的要丰富得多。

本文写于2024年11月30日

评论：《黑客与画家》

AztecaAlpaca — Mon, 22 Apr 2024 00:00:00 GMT

本文将围绕Paul Graham的《黑客与画家》展开评论，探讨黑客与艺术家的共通之处，以及黑客在工程科学等领域中所面临的现实困境与生存之道。

《黑客与画家》是Paul Graham（保罗·格雷厄姆）的一篇博客文章，该文章被收录至其同名的著作中，称得上是计算机领域里影响巨大的一篇文章。

保罗·格雷厄姆是知名的硅谷投资人，他创立了投资机构Y-Combinator，该机构孵化出了包括airbnb在内的无数家成功的初创企业。此外，在经营Y-Combinator的过程中，保罗发现并提拔了日后名声大噪的Sam Altman。与其成功的投资人经历相比，保罗的早年经历也挺传奇。他在哈佛拿到了计算机科学的博士学位，但后来又去罗德岛设计学院学习绘画。他在90年代，创建了叫做ViaWeb的互联网应用，并卖给了雅虎，赚得了自己的第一桶金。由此可以看出，《黑客与画家》这样一个主题正是作者个人经历的一个总结提炼。

何为黑客？

当提起“黑客”，不少人会想到制造计算机病毒的或者破解某个网站密码的程序员。这多少是在互联网发展早期一些从事非法工作的程序员给“黑客”带来的坏名声。在更早的时候，黑客就是泛指那些技术精湛的程序员自身，而没有什么道德评判或工种划分。当然，在本篇评论之中，“黑客"的内涵会被进一步泛化，他们将不再局限于进行计算机的编程工作，在任何领域里掌握着精湛技艺的人都可以成为黑客——这一点与作者所描述的黑客或许更为契合。

在文中，作者多角度地类比了黑客与画家着两类职业，并指出黑客的本质在于他们依托一些技术进行创作。

这种创作不同于科研工作，因为从事科研工作需要对他的研究方向的诸多细节有着深入的理解，他们需要对既有工作进行大量的学习，包括去了解相关的理论体系的、完成某项研究细节的实现，他们需要进行很多公式推导、科学实验，并逐渐形成对研究方向的直觉，这一切可以帮助他们在一个已经有了很多成果的方向上更进一步，或者说“站在巨人的肩膀上往远处再多看一眼”。

黑客需要掌握很多工具，但他们并不需要将某一艰深的理论咬穿嚼透，他们只需要能够利用某项技术即可，就像画家不需要把颜料的化学理论搞清楚，他们只需要掌握调制不同色彩和质地的颜料即可。某项技术之于黑客不同于“巨人的肩膀”之于科学家，而是更像画笔之于画家。科学家需要非常扎实的肩膀，并在很长的时间里就住在了这个“肩膀”之上，因此“肩膀”不宜太多（如果踩着两个肩膀的话，大概就是在从事交叉学科的研究吧，但如果两个肩膀相距太远或同时踩着若干肩膀，就有点容易扯到，这恐怕会比较危险，）；与其形成鲜明对比的是，画家却可以拥有很多画笔，黑客也可以掌握非常多的技术，他们只需要把这些东西组合起来构成自己的工具库，足以服务于创作即可。

科学家需要在已经很扎实的基础之上通过艰苦的工作来获得做出原创性成果的能力，但黑客的工作一开始就是原创的，然后他们就像画家一样拿着画笔去勾勒自己的想法，这个想法最初可能是脆弱的，但通过一步步的完善，他们最终将做出较为扎实的成果。也就是说，科学家工作的出发点是可靠的东西，目标是原创的；而黑客工作的出发点是原创的，目标是可靠的东西。

既然与科研工作有如此差异，这种创作是不是更像某些企业的研发工作呢？答案恐怕也是否定的。研发工作的目的在于生产出在市场上卖得出去的产品，这些产品的特性是由市场上的潜在买家决定的，而产品的设计与开发之前，通常需要一定的市场调研。因此，产品的研发并不是那种纯粹的技术性工作。在一些非常成熟的“夕阳产业”中，企业的研发更是不需要什么“创作”过程，与其对想法原型进行不断地完善，企业的老板更喜欢看到员工按部就班地把产品做出来。

因此，黑客的创作既不同于科研工作，又不同于产品研发。黑客更像是艺术家，比如画家、建筑师、音乐家等等。不过现实之中，黑客这个群体并不会自发地集结于某个场合，而是不得不委身于现有的各行各业中。

从事工程科学的黑客

还是继续从计算机领域说起，在文章中，作者指出了计算机科学的“大杂烩”特性，堪称”科学界的南斯拉夫“。这一点使得计算机与诸如物理学等经典的科学领域相差很大，甚至显得计算机科学不太像是一门科学。不过要把计算机科学从科学范畴中开除，我是反对的，除非可以把我所从事的种种“工程科学”一并从科学领域中开除。工程领域的学科体系是围绕着某一项工程或工具而打造的，服务于具体的生产活动。比如机械、土木等行业的科研工作。这些学科会汇集一些诸如工业设计、材料科学、力学、计算机模拟乃至管理学等相关的研究方向，各方向之间的差异甚至可能不亚于物理学与生命科学这种一级学科之间的差异。鉴于这些工程学科的历史之悠久以及跨度之广泛，如果计算机科学算是”科学界的南斯拉夫“，它们可以被称为”科学界的日不落帝国“了。

计算机科学领域存在的问题，在其它的工程科学领域同样存在。在工程科学领域的研究工作中，有两类人比较吃香，一类是善于进行理论推导的”学术型人才“，一类是善于与工业界打交道的”科研经理“。而处于其中间位置的那批人，有点类似于文中的”黑客“，他们既不那么擅长或者喜欢进行理论推导，又不那么热衷于与甲方爸爸打交道，属于他们的只有某个狭窄的夹缝地带。对于掌握科研资源的大领导来说，他们无法贡献晦涩而光鲜的一页页公式从而给自己在科研领域增加点光彩，又无法直接帮其拉到企业合作来拓展收入来源。不过他们有一点比较好，那就是比较善于”干活“，这一点使得这批人会率先成为科研工作中的临时工，并“临时”到科研生涯的结束。

那么一些喜欢PUA的老板们可能会说在：“他们在我这里得到了锻炼，我安排他们做了适合他们的工作，这是他们的幸运。” 但事实上呢？他们是做了很多工作，但却很难获得足够的“名分”。著书立说，他们没机会；勾兑合作关系，他们又没有资源，他们的价值仅仅在于燃烧自己，成就他人，且毫无议价能力。那么，抛开能带来的回报不谈，他们做的这些事情是他们愿意的吗？很遗憾，并不是。就像作者在文章提到的那样，当他把ViaWeb卖给雅虎之后，他在雅虎完全无法做自己想做的事情，因为在大公司里，黑客的价值也仅仅是做搬砖之类的苦力活而已，至于要开发什么以及实现哪些具体的功能细节，则主要由产品经理决定。同样的事情也发生在“工程科学”中。在做横向课题的过程中，被当成“临时工"的"黑客"事实上没办法决定自己去做什么，甚至没办法决定自己用什么方式去做。他们的很难在项目中注入自己的想法，更多地将自己劳动依附于别人意志。这种体验对人来说是及其糟糕的，尤其是对”黑客“这样一个在事实上拥有极强的创作热情的群体。

黑客们糟糕的处境

作者提到，“黑客”终究是需要一定的自由度的，这和其它创作活动的从事者是类似的。但很不幸，“Freedom is not free”，能够带来收益的通常都是不自由的工作，因为市场需要的往往是已经存在的某项成熟的产品，而不是什么有趣的有创意的产品。这一点对黑客很不友好：以工程领域为例，从事科研，需要拿出论文，这不是黑客们擅长的；从事具体的项目开发，通常是黑客擅长的，但没有多少自由度，并不算是黑客们喜欢的。以上两者都更容易获得社会认可的工作，但没有一个真正适合黑客的。相比之下，初创企业可能更适合黑客，因为黑客更善于去作出优秀的产品。但初创型企业往往命途多舛，优秀的产品很重要，但也并不是全部，他们还需要找到合适的竞争策略，尤其事需要面对与大公司的竞争。

上面已经提到了工程科学领域的黑客同样面临着类似的困境。而且与活力四射的计算机行业相比，诸如土木工程、机械工程等行业其实很难诞生有竞争力的初创企业，这无疑把黑客的生存空间进一步压缩。在这些行业之中，不得不从两个方向中去觅得生存空间，一个方向是以非常勉强的状态从事所谓的科研工作，一个是毫无灵魂地从事工程实践。这两件事情都挺令人痛苦，但黑客或许注定没有自己的乐园。属于黑客的或许只有空闲，在空闲的时间里，他们可以去大胆地实现自己魂牵梦绕的某项功能，从而获得一种纯粹精神性的慰藉。这种慰藉，从物质层面上讲非常鸡肋，但对一个黑客来说就像呼吸一样重要。只不过在一个崇尚加班和内卷的社会里，他们的处境就更糟糕了，当被剥夺了空闲和假期，他们的精神世界就会变得很脆弱。

黑客的生存之道

但另一方面，这个世界的进步到底是由谁来推动的呢？我们以计算机行业为例，乔布斯、比尔盖茨、扎克伯格、萨姆·奥特曼，他们是企业家、大老板，但他们同样也都曾是初创公司的领导者。他们身上自然有不少属于资本家的特性，但同时他们也都对技术非常精通并能深度参与到产品的开发之中（当然，这里技术不局限于编程）。他们在事实上是典型的黑客，但黑客群体也无需找这几位成功人士为自己贴金，因为这些伟大的企业家也乐意把自己标榜为黑客（hacker或者geek，nerd等等，大同小异）。这个社会对黑客们似乎并不友好，但从组织逻辑上，这个社会并不会故意地针对某个群体而表现出好恶，而是针对其某种特点。而在不同的组织架构之中，社会的好恶标准又会差异明显。

从观感上讲，每个行业都是一种大杂烩，汇集了各式各样的人，然后大家八仙过海各显神通地去讨口饭吃。而黑客是其中掌握着技术的群体。在一个追求稳定的环境中，即便是先进的技术也很难获得用武之地，所以黑客与其它群体相比并没有多少比较优势，相对不爱社交的特性反而会使其被动（较为讽刺的一点就是，最为成功的社交工具就是黑客们做出来）。但在一个追求快速发展的环境中，科学技术是第一生产力。因此，没有那个群体比黑客们更需要“风口”。

放眼过去的几波技术化浪潮，能够抓住“风口”的都是“黑客率”比较高的企业。因为每一个风口都如一张空白的画布，黑客们虽不能立即给出完美的画作，但其他群体甚至连拿起画笔的力量都没有。甚至可以说，每个新兴的行业都是黑客们绘制出来的作品，只不过当他们把作品绘制到了一定的完成度之后，他们便很难从这项创作中继续获得乐趣了。当一个行业变得成熟，那么这个行业也将不再属于黑客们，因为具体的设计谋划都会被所谓的“产品经理”接手，黑客们也将很难从剩余的死板工作中获得快乐。这些把握住“风口”的黑客们，一部分选择成为了企业家，一部分将去寻找新的乐土，去开启他们的下一幅画作。

AlpacaNotes

绿灯熄灭：张雪峰与他的时代

一、一个没有写完的盖茨比

二、黛西小姐

三、镀金时代的派对

四、庄家坐上了自己的赌桌

五、谁的幻灭

造了一条翻译流水线，然后把它关掉了

起点：一篇八万字的播客文字稿

分片的基本想法

真正的文本什么样都有

断点续传：从简单到复杂

便宜的模型撑不住

每片的固定开销

关掉它的原因

留下来的东西

一个关于工程判断的小教训

Telegram / Discord 推送测试文章

Instant View 踩坑记：折腾了一整天，答案是「等一下」

第一层：IV 规则太脆弱

第二层：同一个域名，两套页面

第三层：Bot 消息怎么写都不对

插曲：.nojekyll 的低级失误

以为快好了

真正的反转

「等一下」就好了

还有一点没法控制

延伸阅读

腾讯SkillsHub:开源蛋糕里的蟑螂

开源的经济逻辑

大厂的理性与无耻

最终还是要看实力，但腾讯已经要out了

工具上瘾与专注的稀缺

磨牙

一个不断迁移的人

Vim：又一个新的开始？

真正的问题

为 AI 协作建立项目规则的实践

结构整理完了，然后呢

用 AGENTS.md 把隐性规则写成显性约定

代码审查：从临时 prompt 到可复用的 skill

Skill 放哪里：从 skills/ 到 .skills/

阶段总结也做成了 skill

回过头看

两轮项目结构整理的踩坑与反思

起因：当你发现自己在害怕打开某个文件夹

第一步不是动手，是先弄清楚"这里面到底有几件事"

"两套代码做着差不多的事"是最容易踩的坑

数据的归属感比代码更容易搞混

测试和算例的区别，比想象中重要

文档的分层，解决的不是"写不写"的问题，而是"放哪里"的问题

"先把问题定义清楚，实现留到以后"是一种有用的策略

删东西比加东西更难下决心

每搬一个文件，就要更新一处说明

回过头看：整理不是一次性的事

最后

一次失控项目的目录整理复盘

整理过程

第一步：识别边界，而非急于搬迁

第二步：把"混合总仓"拆成独立项目

第三步：在主项目内部建立层级

第四步：分离"人维护的"和"机器生成的"

第五步：为归档内容设立标准

收获的经验

结语

三大纪律八项注意：一张个人生活审查表的诞生

缘起

两个AI，两种角色

德尔斐的校准

从原则到执行

用AI碎碎念来喂养这张表

关于方法的一点反思

一次深夜排障：以为是自己的锅，结果是 GitHub 宕机了

发现问题

第一反应：肯定是我改出了 bug

越查越深，越改越多

手动触发也失败了

开始怀疑不是自己的问题

确认：GitHub Actions 宕机

回过头来看

插曲：`.nojekyll` 的低级失误

用 `AGENTS.md` 把隐性规则写成显性约定

Skill 放哪里：从 `skills/` 到 `.skills/`