Update 文章 “音乐哲学的数学原理”

content/blog/codex-cli简单配置第三方兼容api.md

@@ -0,0 +1,124 @@
+---
+title: Codex CLI简单配置第三方兼容API
+date: 2026-03-08T23:56:00.000+08:00
+author: 线粒体
+---
+## 引言
+
+Codex CLI是OpenAI推出的AI编程Agent工具，类似Claude Code。据说它可以取代Claude Code，成为最好的CLI编程工具；不过在下对此不置可否。CLI相较于GUI插件的一个显著的好处是，大部分代码编辑器都可以用，因为它的运行只依赖终端，而且也比较稳定。所以我个人还是比较喜欢CLI。
+
+最近我有幸用到了大佬的Codex中转站，故在此将我配置Codex CLI的经验作一分享。
+
+> 本文所用环境是Windows和Windows PowerShell，Linux可以参考适用，大同小异。
+
+## 安装
+
+安装Codex CLI，运行如下命令：
+
+```powershell
+npm i -g @openai/codex
+```
+
+验证安装是否成功，运行：
+
+```powershell
+codex --version
+```
+
+若输出版本号，即代表安装成功。
+
+## 配置文件介绍
+
+如果仅仅是使用OpenAI官方提供的接口来使用模型，那么直接运行：
+
+```powershell
+codex
+```
+
+然后按照交互式指引，登录OpenAI账号或填入API Key即可。但是本文介绍的是使用第三方中转站（即OpenAI兼容API）来使用模型，因此需要关注一些配置文件。
+
+Codex CLI的配置文件位于用户家目录（即`C:\Users\<用户名>\.codex`）中。为了配置第三方API，需要修改这里的`config.toml`。在初次安装且未进行配置的情况下，`config.toml`应该是不存在的，因此需要手动创建。创建好后，编辑该文件，写入如下模板内容：
+
+```toml
+model_provider = "custom"
+model = "gpt-5.3-codex"
+model_reasoning_effort = "medium"
+preferred_auth_method = "apikey"
+
+[model_providers.custom]
+name = "custom"
+base_url = "http://api.custom.ai/v1"
+wire_api = "responses"
+env_key = "CUSTOM_OPENAI_API_KEY"
+requires_openai_auth = true
+```
+
+这个内容等一下还要进行修改。我们要确认已经获得了以下三项必要信息：
+
+- 第三方API的Base URL
+- 第三方API的Key
+- 第三方API可用的模型名
+
+才能进行这里的配置。因此需要先从第三方站那里获取这些信息，各家不同，此不赘述。
+
+## 修改配置文件
+
+首先，Codex CLI支持配置多个`model_provider`。每个定义时用`[model_providers.xxx]`开头，然后写入各项参数。文件开头的：
+
+```toml
+model_provider = "xxx"
+```
+
+即CLI默认选用的`model_provider`。接下来我们自定义一个`[model_providers.custom]`。
+
+修改模板中的`base_url`为第三方API的Base URL：
+
+```toml
+base_url = "http://api.custom.ai/v1"
+```
+
+修改`env_key`为一个自定义的环境变量名，比如：
+
+```toml
+env_key = "CUSTOM_OPENAI_API_KEY"
+```
+
+这行配置的意思是，CLI要去这个环境变量里找API Key。所以需要修改环境变量。对于Windows 11，打开系统设置—系统信息—高级系统设置—环境变量，然后添加一个用户变量，名为刚才定义的名字，值为第三方API提供的API Key。
+
+> 有些人认为配置环境变量很麻烦，所以在此也有第二种方法。
+> 
+> 首先，删去`env_key`字段。当一个`model_provider`没有配置`env_key`的时候，CLI就会去读取和`config.toml`同目录的`auth.json`，来获取API Key。
+> 
+> 新建`auth.json`文件，写入：
+> 
+> ```json
+> {
+>   "OPENAI_API_KEY": "apikey-xxxxxx"
+> }
+> ```
+> 
+> 这里`"OPENAI_API_KEY"`这个变量名是不能改的，否则就会读取不到。只要将后面的值替换成自己的API Key即可。
+> 
+> 这样做的缺点是，如果配置了多个`model_provider`，且都没有设置`env_key`，那么它们就会读取同一个Key。
+
+最后配置使用的模型。这个配置在CLI里也可以以交互式方式设置（通过`/model`指令）。修改文件开头的`model`为第三方API提供的任一可用模型，例如：
+
+```toml
+model = "gpt-5.3-codex"
+```
+
+然后就可以使用了。至于详细的配置文档，可以参考[官方文档](https://developers.openai.com/codex/config-basic)。
+
+## 使用
+
+在任意文件夹运行：
+
+```powershell
+codex
+```
+
+即可启动Codex CLI，使用的是我们刚才配置的`custom`。可以根据提示进行个性化配置。
+
+## 结语
+
+本文所述方法只是最简单的配置，更多用法可以参考[官方文档](https://developers.openai.com/codex/cli)。不当之处，欢迎指正！

content/blog/为什么清水阁是神.md

@@ -0,0 +1,22 @@
+---
+title: 为什么清水阁是神
+date: 2024-11-25T21:23:00.000+08:00
+author: NukaCirno
+---
+这样事情，此时此刻正在全球各地上演，下一个就有可能是你！（指写了东西没地方发）
+
+除非你能做出生命中最正确的 选择（一阵强劲的音乐响起）
+
+向所有人证明，你有打动所有人的智慧和点子
+
+加入清水阁吧！成为文艺创作不可缺少的笔杆
+
+让别人见识雄诗奇文
+
+让精神魅力席卷大地
+
+成为英雄😎
+
+成为传奇😎
+
+成为清水阁写手😎

content/blog/二叉树.md

@@ -0,0 +1,34 @@
+---
+title: 二叉树
+date: 2026-03-27T11:27:00.000+08:00
+author: 线粒体
+---
+2015年左右，三年级的我第一次见到了代码。那时候见到了一位正在上大学的姐姐的Visual Basic作业，本身就对电脑很感兴趣的我，很快就被吸引了。我在她的电脑上乱敲键盘，打出一大堆乱码，说这就是我的代码。她还夸我很厉害。
+
+2017年，我第一次学编程。我的第一门编程语言是C，第一本编程书是谭浩强。我每天看一点点，写一点点。为什么函数要先声明再实现？这是在编程中困扰我的第一个重大问题。我花了两个月的时间，才理解函数的声明和函数的实现是分离的，后来我才知道这个叫封装。
+
+我用`stdio`写了一些命令行程序。那时候不知道用代码编辑器，而是用记事本写代码。
+
+很快我就觉得命令行不是我想要的，我想要炫酷的GUI。于是我的第二门语言是VB，那时候我觉得VB就是写GUI最好的语言。但是一开始我完全没有理解面向对象，不知道什么叫实例。所以我又开始啃VB的书。不过这一次比学C快多了，不到半个月我就能用VB写程序了，而且还用上了Visual Studio。
+
+但是我的VB生涯只持续了很短的时间，一个原因是这门语言本身不太流行，框架也很少。于是我的第三门语言是Java，看的书是臭名昭著的《从入门到精通》。这样一本烂书却让我学会了Java大部分的基础知识。现在人们学Java可能是为了做互联网开发，但那时候，我从C学到Java，乃至后面的C#，都没有对互联网开发展现出任何兴趣，更不懂什么SaaS，只是一心想做一个“买断制产品”。所以我对桌面软件非常感兴趣，也可以说是我的技能树点歪了。
+
+我学做Java Swing，用`Thread`手搓动画，做了一个工具箱软件。这是我的第一个称得上“作品”的项目，总共有三千多行。但后来我换了电脑，一行都没有保存下来。年轻人总觉得自己将来有无限可能，有谁不把过去通通抛在脑后呢？
+
+当我觉得Java也不过瘾的时候，我开始学C#，做Unity 3D。从Java转C#并不需要多少成本，倒是把大部分时间都放在了研究U3D上。我做了一个小游戏。此外还学WinForms，做了一个文本编辑器，还在省级比赛上获了一等奖。
+
+以上都是2017到2018年间发生的事，这两年我完成了我迄今所用几乎所有技术的原始积累。可惜的是，2018年开始直到2025年，7年间，我没有学习任何一门新语言，Android和WPF的学习也无疾而终。
+
+2022年，我做出了我人生中一个极为不妥的决定：转到文科班。在2022年以前，我从没想过有一天我会去学文科，我一直以为自己是个纯正的理科生。但是人在环境极度压抑的情况下会做出一些极端的决定，我只是为了赌气，或者说想逃离那个班级环境，就让我的理想和前途大打折扣。
+
+同年的某一天，一位老师给我一份资料，问我要不要去参加信竞。那时候我只觉得数竞、化竞、生竞才是“正规竞赛”，对信竞并不上心，便敷衍过去。
+
+后来上了大学，才发现大量CS领域的大佬都是信竞出身，有些甚至从小学开始到高中，一直参加信竞。
+
+而我自小学毕业到高考的6年内，再也没有2017年那样深入钻研过编程。
+
+而我在2025一年间学到的编程知识，却比我过去人生中所学的总和还要多。
+
+当我今天只能通过考研来进入这个自幼向往的行业时，不禁回想起十年前独自啃书本写代码的那些时光。
+
+种一棵树最好的时间是十年前，其次是现在。

content/blog/再会，青铃.md

@@ -1,6 +1,6 @@
 ---
 title: 再会，青铃
-date: 2024-12-05T16:17:00.000+08:00
+date: 2024-11-22T05:46:00.000+08:00
 author: 线粒体
 ---
 在小说或电影中，每当将要发生重大事变时，总要推波助澜、营造声势，正所谓“山雨欲来风满楼”，仿佛全世界都在为这场事变各显神通。然而在现实生活中，重大事变的发生，往往在悄无声息中来临，将死亡一般的幽静打破，如暴风雨般席卷过去，然后又回归死亡一般的幽静。我和青铃的结识和分离，便是如此。

content/blog/夕阳下的摇滚.md

@@ -0,0 +1,60 @@
+---
+title: 夕阳下的摇滚
+date: 2024-12-08T22:49:00.000+08:00
+author: 猕猴桃教教主
+---
+![](/uploads/夕阳下的摇滚.png)
+
+## 主歌1
+
+火红夕阳下，祁连披霞，热烈的少年，自由潇洒。
+
+贝斯架子鼓，键盘电吉他，路灯相伴归家。
+
+金黄夕阳下，镜湖浮华，炙热的青春，激情挥洒。
+
+激昂的节奏，腾飞的音符，青春永不散场。
+
+## 桥段1
+
+夕阳余晖下，我们去追逐，希望的光芒。
+
+将青春绽放，让梦想启航，陶醉音乐海洋，舞台尽情释放。
+
+## 副歌1
+
+我们的天地啊，忘情歌一曲。
+
+晚霞是帷幕，远山为听众，轻风拂叶伴奏，我们心跳动。
+
+这是我们青春的生命之歌。
+
+我们心之所向，是远方梦想。
+
+共赴星辰大海，你我共一程，追寻诗与远方，青春的见证。
+
+心若相依相知，天涯亦是咫尺。
+
+## 主歌短2
+
+仍旧是黄昏，山水依旧，那群少年啊，不复往日。
+
+再来奏一曲，青春的绝唱，只为当初梦想。
+
+## 桥段2
+
+承载着梦想，承载着过往，紫红色的霞，连结我们心，唯有放声高歌，唱响最强音，曲终收拨当心画。
+
+## 副歌2与再现
+
+人生聚散如梦，烟雨不由人。
+
+每当夕阳西下，忆往昔过往，一路笑语欢歌，笑颜自难忘。
+
+只奈不敌十八毕业这一别。
+
+黄昏安然宁静，落霞夕阳边。
+
+晚风牵着思念，暮色浴群山。余晖散落双肩，燕子入雄关。
+
+指尖弹出盛夏，回忆永驻心间。

content/blog/平凡的世界.md

@@ -0,0 +1,40 @@
+---
+title: 平凡的世界
+date: 2024-11-25T13:35:00.000+08:00
+author: 刁钻神
+---
+ 如果辉煌是一种奢求  
+那就不必将它给予  
+黄土高原上的旧砖场  
+写满了过去与辉煌  
+曾经意气风发的少年  
+也终是如父辈那般  
+让生活压弯了脊梁
+
+如果爱情是一种奢求  
+那就不必将它给予  
+汹涌的洪水将你带走  
+而我仍在这里等候  
+古塔山上的约定  
+在洪水中化为泡影  
+只剩杜梨树下定格的时光
+
+如果生活注定平凡  
+请让生命之歌唱响不凡  
+砖场上的炉烟 山屹梁上的少年  
+又挺立起脊梁  
+矿洞下的煤炭  
+躬耕于黑暗的少年  
+仍向往远方
+
+如果世界像此平凡  
+也请你们引吭高歌  
+追寻向往的世界的模样  
+也许不曾有诗和远方  
+但杜梨树下仍有祈望  
+窑洞里面还有热望  
+
+这是平凡的世界  
+亦是生命不朽的华章  
+我们在此平凡  
+我们的生命在此不朽

content/blog/我与天地周旋久，宁作吾.md

@@ -0,0 +1,6 @@
+---
+title: 我与天地周旋久，宁作吾
+date: 2024-11-26T12:26:00.000+08:00
+author: 南木
+---
+![](/uploads/e06cd44654d0d8c4bf52af1fc331a32.jpg)

content/blog/我们.md

@@ -0,0 +1,14 @@
+---
+title: 我们
+date: 2024-11-26T13:35:00.000+08:00
+author: 南木
+---
+———金钱美人何足贵，惟有手足是归处
+
+诗云：“海内存知己，天涯若比邻。”邓公言：“实践是检验真理的的唯一标准”，是啊，此番异乡千里的实践果然证明王勃所言，你们，或者说“我们”，是我在这无亲少友之地唯一的慰藉。寂寞之时，我便翻看那一本在我手边寸尺不离的“流光集”，诸君之精神，诸君之笔力，诸君之相貌跃然于眼前。怀念啊，怎能不怀念？我怀念“冷冷雨，没焦点因找不到你”；我怀念“在雨中漫步，蓝色街灯渐露”；我怀念“一件黑色毛衣，两个人的回忆”；我怀念有人修身养性，我怀念有人cnmb；我怀念中秋之月，我怀念跨年之夜。是永远依靠的肩膀，是永远可以畅谈的梦想。正有你们，才为这个“我们”定义了与众不同的概念———兄弟。
+
+把手放在键盘上好久，却打出来寥寥几句。不经想起“临表涕零，不知所言”，想说的太多，堵塞在脑子里，竟都变成了沉默和眼泪。大连下雪了，凛冽的海风和雪花击落了楼下仅剩的几片枫叶。我对诸君的思念也似这冬雪一发不可收拾。某不善言，文笔浅陋，仅祝冬安，表思念之绪耳。
+
+不知何时才能再见到你们，我们再次围坐一桌，把酒言欢 。
+
+心中欲发千万言，语至唇边，语至唇边，唯有沉默泪涟涟。

content/blog/戰艦-榛名-昭和十九年-捷一號作戰.md

@@ -0,0 +1,10 @@
+---
+title: 戰艦 榛名  昭和十九年 捷一號作戰
+date: 2024-11-25T22:01:00.000+08:00
+author: NukaCirno
+---
+![](/uploads/1000003572-1536x864.jpg)
+
+![](/uploads/1000003567-1024x576.jpg)
+
+![](/uploads/1000003577-1024x576.jpg)

content/blog/无题-1.md

@@ -0,0 +1,18 @@
+---
+title: 无题
+date: 2024-11-25T23:40:00.000+08:00
+author: 刁钻神
+---
+微风送走夏日的炎热  
+带来属于秋的独特风光  
+而我们彼此分离各奔西东  
+但我仍在这里  
+在遗憾与落寞中感受四季  
+我也曾想出人头地  
+但如今也只能延着已行的路前进  
+未曾记起旧日的身影  
+却又难忘记往日的回忆  
+我向往又迷茫  
+无知却又清醒  
+等待旧日的满天星飘散  
+我也将彻底遗忘

content/blog/有感.md

@@ -0,0 +1,7 @@
+---
+title: 有感
+date: 2026-03-19T00:31:00.000+08:00
+author: 线粒体
+---
+早岁未曾染尘伤，入世何能不彷徨。  
+年华似玉身世苦，人生如梦湘水凉。

content/blog/江城子·怀友.md

@@ -0,0 +1,8 @@
+---
+title: 江城子·怀友
+date: 2024-11-25T21:44:00.000+08:00
+author: 南木
+---
+与君初遇少年场，意飞扬，志如钢。笑语欢声、共饮春千觞。岁月悠悠情似酒，同喜乐，共炎凉。
+
+天涯孤影对残阳，忆流光，泪千行。翌日相逢、应是旧容妆？梦里今宵再聚首，酌月色，叙离殇。

content/blog/糖原1-1.md

@@ -0,0 +1,22 @@
+---
+title: 糖原1.1
+date: 2026-03-09T10:54:00.000+08:00
+author: 线粒体
+---
+之前设计的[糖原2.0](https://qingshuige.ink/blog/%E7%B3%96%E5%8E%9F2-0/)，可以说想象力天马行空，但是现在看来，难免有过度设计之嫌。这个架构主要是为了保证糖原的核心竞争力——弱信息茧房，于是设计了前端（闭源）—中心服务器（闭源）—节点服务器（开源）的三层架构。本质上，这种做法是想通过将技术神秘化，获取对推荐算法的绝对掌控。但是实际上，这种做法是没有必要的。因为真正好的软件，即便开源也能保证最初的愿景不被篡改。而且对于软件的运营，代码只是其中的一个部分，能够吸引人的还有很多方面。再者，客观上，这个方案也几乎没有办法实现。因为所有的流量都需要经过中心服务器转发，社区越大压力越大，中心一挂社区就挂，显然很不科学。因此，我准备放弃这个方案，转而**将糖原全面开源**。让我们为糖原1.1鼓掌欢呼！（误）
+
+全面开源的意思就是，所有程序代码全部开源，并且允许自部署。
+
+有人担心，糖原的初心是为了减弱信息茧房，需要一个中心化的控制权。而全面开源以后，人人都可以部署，反而变成去中心化，那怎么能减弱信息茧房呢？
+
+在我看来，信息茧房是一种结构化的社会问题。单纯依靠一两个软件是解决不了的。因为即便有了糖原，大家照样还是会部署Misskey这种平台。因此糖原只能面向自愿加入这个弱茧房社区的用户，如果这种理念受到欢迎，那么自然会受到推广，从而吸引越来越多的人加入。也就是说，真正吸引人的不是程序本身，而是环境、价值与氛围，这就是开放的哲学。
+
+更进一步而言，既然我们的用户群体都是自愿抛弃信息茧房的人，那么他们为什么要自己部署我的开源程序呢？如果是为了圈地自萌，他们显然有更好的专精的开源项目可以用，何必用糖原呢？
+
+因此并不需要担心网络上出现大量的“糖原实例”，变成一个又一个的独立王国。从现在的知名度上来说，这是杞人忧天；即便将来有了知名度，也不太可能出现这种情况，原因刚才已经说过了。相反，大家可能会更倾向于给我的项目提Pull Request，不断优化。
+
+这种现象的原理是，任何软件都有一种无形的资产，即用户群体。对于独立的论坛社区，用户群体是分离的。而对于这种自愿抛弃茧房的社区，用户群体必然是趋向合一，因为要想抛弃茧房就意味着要联合，不联合就没必要用这个软件。这是一个反证法。
+
+当然，退一步讲，糖原也完全可以允许自部署，但前提是各个实例间要保持开放和联合。原理也和刚才说的一样，如果服主不联合，他也不会选糖原。这样就可以造就一个去中心化的、分布式的统一弱茧房社区。
+
+这并不是新鲜概念，很多论坛项目早就有这种机制。糖原的意义在于，站在巨人的肩膀上更进一步，做到更公平、更开放。并且，将来我们可以在各个平台上做出高性能的原生前端。

content/blog/糖原2-0.md

@@ -0,0 +1,30 @@
+---
+title: 糖原2.0
+date: 2025-12-12T21:26:00.000+08:00
+author: 线粒体
+---
+我既想把糖原开源，又想保证推荐算法是公平的。虽然我很喜欢Misskey，但是我觉得Misskey还是有点自立门户。毕竟你需要主动连接到别人的服务器，才能获取他们的信息。如果你不主动连接，那就会成为茧房，而弱茧房乃是我开发糖原的初心。因此我在洗澡的时候产生了如下设想：
+
+1. 将糖原前后端重构为漏斗状结构，支持第三方服务器自部署。
+
+2. 设计一个中心服务器，服务端程序**不开源**。
+
+3. 前端仍然**不开源**。所有前端连接到中心服务器，获取帖子数据。
+
+4. 设计**开源**的自部署节点服务器程序，任何人都可以部署。每个节点都不能直接向前端通讯，只能向中心服务器通讯。并且每个节点都需要向中心服务器注册。
+
+5. 前端能够获取当前连接到中心服务器的节点服务器有哪些。
+
+6. 每当前端发表一条内容，可以指定节点服务器。随后这条内容的元信息被注册在中心服务器，并通过中心服务器调用节点服务器的接口，传送到节点服务器保存。
+
+7. 每当前端需要获取一条内容，中心服务器从对应节点服务器获取内容数据，并传递到前端。
+
+8. 允许节点服务器服主在内容上附加特性，并在传送过程中得到保留，在前端得以显示。这些特性可以是付费内容，但是前端本身不提供付费接口，服主须自行处理。
+
+9. 节点服务器还可以增加其余特色功能。这些特色功能必须配合前端的相应接口。
+
+10. 由于所有帖子的元数据已存储在中心服务器，因此推荐算法通过中心服务器控制，可以保证公平。
+
+11. 节点服务器不得对中心服务器要求的内容造假，中心服务器通过摘要算法等手段鉴别内容真实性。
+
+如此一来即兼得开源的自由性和中心化的公平性.

content/blog/论vibe-coding替代程序员.md

@@ -0,0 +1,20 @@
+---
+title: 论Vibe Coding替代程序员
+date: 2026-03-23T04:04:00.000+08:00
+author: 线粒体
+---
+自从有了AI，用AI写代码，替代这个替代那个的论调就越来越多了，给人的感觉是程序员很不值钱——确实啊，要是值钱怎么能叫“码农”呢！我自己编程水平有限，平时也大量用AI写代码，所以我应该是AI的受益者而不是受害者，是AI让我变得更值钱了。但是我也觉得，AI替代一切、低代码开发这类论调，言过其实。与其考虑AI能替代什么，不如考虑作为开发者，最不能被AI替代的东西是什么。
+
+首先我觉得第一个层级的不可替代性，是判断力。众所周知，现有的AI模型是一个黑箱。我们在数学上可以通过严密的逻辑推导，证明一个命题的真假。但是据我了解，AI模型是通过概率推算的方式，得到一种“最可能的结果”。固然这个正确率会很高，但是即便是99.99%，也是和逻辑推导有本质区别的。“像”和“是”是完全不同的两个概念。所以AI如果按照现在的这种模型进行发展，那永远都可能出现错误的结果。这时候只能依赖开发者进行判断。
+
+一些重复性的工作、简单的工作、答案很明确的工作，确实没必要身体力行。直接交给AI就能做，而且说不定还是最佳实践。但是不写不代表不会看。双手解放出来，大脑还得工作。这就像AI写小说，本质上，我脑子里想好一个情节和中心思想，交给AI，它就能帮我完成一部小说。只是文笔和细节上会很差，但是我相信它会越来越好。前提是我自己首先是一个懂文学的人，不然我怎么判断他写的符不符合要求呢？写代码同理，开发者可以不关心AI的实现方式，但是起码要清楚它的意图，能看到全局。这就要求开发者具备高水平的判断力。
+
+但是一些极力推崇Vibe Coding而贬低开发者的人，恰恰没有认识到这一点，所以他们认为程序员没有必要存在，自己不会编程也可以做出好的产品。实际上他们也落入了一个经济学概率的陷阱，那就是他们在做的实际上不是真正的开发，而是一种商业投机或管理，这是完全不同的两个领域。他们所做的实际上只是雇人帮他们写代码做了一个产品，只是员工是按token计费的便宜的AI模型。而程序员却要对代码的整体质量负责，还要关注DevOps等等方面的问题，这些事情没有一定的开发知识是完全无法解决的。
+
+一开始人们打孔；嫌打孔太慢，就写汇编；嫌汇编太慢，就写高级语言……今天有人说打孔的人很蠢、写汇编的人很蠢，但是当时的硬件条件和需求就是那样。会打孔的人肯定会汇编，会汇编的人肯定会高级语言。一言以蔽之，工具的高级性掩盖不了它的工具性。来来回回折腾到今天，发现贯通“古今”的核心能力，还是判断力和系统思维能力，这是真正属于人的主体能力。
+
+将来的AI或许也会出现这种能力，那时候人类的思维想必也会来到更高的一个层次，思考一些我们今天想象不到且将来的AI也不能思考的问题。
+
+这就将我们引入第二个层级的不可替代性，那就是元认知的能力。我们总是在考虑AI替代程序员，可曾设想，我们发明计算机是为了解决问题，将来即便AI真的替代了程序员，我们的问题却不完全需要由计算机来解决？虽然计算机神乎其技，但是推而放诸人类历史，它也只是一个重大事物。将来会不会有超级计算机、超超级计算机，乃至全新的计算形态？那时候现有的AI还能处理这些事务吗？考虑到这些问题，我们说，那么好，AI替代程序员，就让它替代吧，因为我们有更深奥的问题要研究。
+
+程序员——或者更广义的计算机科学研究者——在我不成熟的思考下，至少有这样两个不可替代性，其实也就是进化性。

content/blog/论糖原.md

@@ -0,0 +1,76 @@
+---
+title: 论糖原
+date: 2025-01-22T22:55:00.000+08:00
+author: 线粒体
+---
+## 一、引言
+
+作为一个在互联网混迹十几年的人，同时作为一个不时有些新想法的年轻人，我常常感到我们目前的互联网——特别是中文互联网——缺乏一些东西。我们缺乏一个真正开放、真实、纯粹的互联网社交平台。
+
+当我打开知乎、推特、小红书、百度贴吧等等一众妇孺皆知的APP，映入眼帘的往往是满屏的广告，或者长篇大论灌水，或者一些专门运营账号的人杜撰出来的哗众取宠的东西。从数量上虽然蔚为大观，但它们不是属于一个现实世界的人的真实思想，有很多捏造的成分，是虚的，价值很低。
+
+难道我们每天上网就是为了发布和接受这些虚无缥缈的信息？我觉得这不是互联网应该发挥的功用。互联网社交应当回归到每个人，回归到平等，回归到连接，回归到真实表露。
+
+我自己是一个勉强有一点技术积淀的人，又喜欢用别人眼中“瞎操心”的方式察觉一些社会问题，找到问题还想要做点贡献。于是我准备在互联网社交这一个很小又很大的领域下手。
+
+**我准备开发一个叫作“糖原”的APP。**
+
+## 二、糖原的定位
+
+糖原是一个类似于X（原Twitter）、微博和QQ空间的，贴近生活的，现实化、轻松化、平等化的个人自我表达平台。
+
+糖原不是视频平台，也不能写小说，也不是专门用来发表高论的。它没那么严肃。发表一条推文（暂且借用一下这个概念），源于生活中的一点感想想要记录，只需要一句话、一张图就可以了。很简约。
+
+每个人都有公平的被人看见的机会，不会因身份等要素增加或减少曝光。
+
+某种程度上来说，糖原发挥的作用有点像大字报。
+
+## 三、糖原的主要精神理念
+
+### （一）短小精悍
+
+糖原只允许用户发几行文字，或者发几张图片，不允许写长篇大论或者当相册用。因为一旦出现大量的长篇大论，这个软件就会变得冷峭，而且虚的东西就会掺杂进来，像知乎一样，使人不敢接近。这不符合糖原“现实化、轻松化”的初衷。生活中的话，几句就够了。
+
+### （二）公平交往
+
+**第一，糖原上发表的所有推文不得设置可见性，强制公开可见。**糖原默认用户在上面发表的东西是允许让全世界看到的，别人**实际上**看不看得到、感不感兴趣另说，但必须要让所有人**能够**看到。这样可以避免糖原成为私密日记本。
+
+**第二，糖原的推荐是随机的，不受身份、热度、声望等因素影响。**糖原会有像当下主流APP那样的推荐首页，但不会做非常精准的推荐。所有的推文享有均等的机会出现在用户首页。就算要精准化，最多也是精确到用户感兴趣的领域，并且领域不会细分。这样可以避免出现信息茧房，也可以避免当下社交软件“有理在于声高”的弊端。
+
+**第三，糖原要把国际化放在开发理念的顶尖位置。**必须要有对于世界主要语言的完整支持，并且功能上不能只服务中国用户，要在世界主要国家提供良好的体验。要保证不同国家的人打开糖原，除了语言外没有任何差别。这并不是说我们不做本地化，而是应当做本地化的加法，不能做本地化的减法。如iOS的日历APP，在一些国家就做了加法，提供了当地常用的历法和节假日，但是并不影响其基本功能，而且其他国家的用户只要感兴趣也可以用。反例是大多数国产APP，只要出了中国，没有了中国手机号，就没法用。
+
+### （三）去无脑化
+
+**糖原上发表的所有推文不设置点赞功能。**因为人们对一个观点的判断，很大程度上会受到认同这个观点的人数的影响，而不是逻辑思考。点赞功能将这种影响放大并精确量化，似乎点赞越多，他说得就越对，不利于人们思考。而且你认为他对，却不用说出对的理由，只需要点个赞就可以了。表达立场的成本如此之低，让本就匮乏的思考雪上加霜。所以糖原要避免这个问题。当你赞同或反对一条推文，你要么藏在心里，要么进行文字评论，而一评论就得说出理由，还得应付别人的反驳，所以你要仔细考虑。这样就将“无脑带节奏”这一现象发生的频率降低。
+
+## 四、糖原的主要技术理念
+
+### （一）跨平台原生性
+
+糖原需要在目前主流的操作系统和平台上拥有该平台的原生APP。所谓原生APP，就是用操作系统开发商提供的框架进行开发，而不用第三方技术进行生成。这主要是出于性能和体验考虑。性能方面，原生APP往往胜出，而第三方框架做出的APP通常依赖各种库、多层抽象和转换，效率低下。体验方面，原生APP能提供最接近OS本身外观、逻辑的体验，可以和系统融为一体。这方面的一个很好的例子是Telegram，它十分全面地支持了所在系统的特性。
+
+将来是否会出现全平台统一、真正做到“一次编写到处运行”的系统？无法预言。但用户追求的体验总归是趋向易用性，开发者追求的体验也总归是趋向通用性，因此就算将来不会出现这样的系统，各个平台系统之间的壁垒也不会立得太高，开发和使用体验也会趋同。至于WebApp，虽然开发起来很容易，跨平台也很简单，但在任何一个平台都无法提供接近平台原生的体验，而且效率极其低下。将来操作系统一趋同，甚至开发框架都可能趋同，WebApp的优势就不明显了。故长远来看，我们做原生开发，局势是对我们有利的。
+
+### （二）跨平台功能一致性
+
+糖原在任何平台上，不管是性能最好的电脑还是性能最弱的手表，都要提供尽可能同等的功能体验。不能因为某个平台性能强，就多出很多功能；某个平台性能弱，就阉割很多功能。据我们了解，目前即便是性能最弱的手表平台，也可以支撑起一个社交APP的90%的功能。只不过很多开发者不愿意做适配，使得很多APP在手表端是残次品，从而给我们造成了“手表性能很弱，不足以支撑这个APP”的错觉。糖原要拨乱反正，如果电脑端能做100%的事情，那么手机端可以做99%，手表端至少也要做90%。
+
+另一方面，有些APP号称跨平台功能一致，实际上不同平台的体验和逻辑天差地别。比如QQ空间相册，虽然手机端和Web端都可以上传照片，但是手机端的上传速率是Web端的数倍之多，而且界面大相径庭。此类APP其实并没有实现跨平台功能一致，只能说是功能相似。糖原要做到真正的一致，同一个功能在不同的平台上的体验和逻辑要统一，让它只有形式上的差别，而没有实质上的区分。
+
+### 五、糖原的主要商业理念
+
+### （一）盈利模式
+
+虽然我做软件不是为了赚钱，但也不能亏钱；因为我不是富二代，无法用爱发电，软件运营的收入至少应当能够支撑服务器、域名等所需费用，这样软件才能长久地运营下去。如果软件不仅不亏钱，还能赚一点，那么我就更有动力去把它做大做强，更有动力推动它成为我理想中的样貌。因此，商业上的运营不仅是必要的，而且是有益的。但是要合理运营，不能唯利是图，以金钱为导向做软件。
+
+**第一，以软件品质为导向，吸引用户主动捐赠。**糖原要做出过硬的品质，建立良好的口碑，赢得用户赞赏，然后引导其出于鼓励开发者而心甘情愿地捐赠。这是目前开源软件主要的收益模式，我们可以学习。这也是上上之策，是最令人心安理得、有成就感的收益来源。
+
+**第二，合理划分功能等级，适当安排增值内购。**糖原在基础功能上要让所有用户免费使用，但一些增加体验感的功能可以划分给付费用户使用。但是这种划分和定价是十分困难的，一不小心就会被人调侃为“精准的刀法”和“等级森严”。我们的原则是，付费功能只能是锦上添花，不能是雪中送炭；只能起到四菜加一汤的作用，不能起到米饭加四菜的作用。并且，定价要尽可能压低，尽可能靠近收回成本的收益目标。
+
+**第三，糖原若添加广告，则广告不能过度影响使用体验。**必须抵制开屏广告、摇一摇广告、弹窗广告、通知推送广告、“拼多多式”广告等流氓广告。广告的布局和设计应当具备较高的品味，使得广告在整个APP中居于次要地位，不能喧宾夺主。
+
+### （二）市场竞争原则
+
+目前，全世界社交APP的市场已经基本被瓜分殆尽，我们没有能力和大厂竞争。但是我们所做的是一个比较细小的领域，也可以避免很多竞争。我们的精神理念、技术理念具备一定的先锋性和独特性，因此如果要在市场竞争中生存下来，则需要坚持我们的特色。一定要避免跟风，走上跟其他APP一样的赛道。我们可以学习别家做法，但我们要有所取舍。要考虑我们做的决策是不是有利于我们独树一帜，是不是有利于提升用户粘性，是不是有利于我们在这个细分领域树立话语权。我们不需要吸引大多数用户来用我们的软件，只要小部分需要我们软件的人来用，我们就算成功。
+
+**对于我们的这些理念是否迎合了一部分用户的需求、是否符合历史发展方向的问题，我们要在战略上树立自信，也要在战术上接受考验。**至少我本人是第一次做这么大的软件，缺乏经验，战略眼光也不敏锐。应当边做边学、认真细致。做了就不要怕失败，大不了换个方向再来。

content/blog/音乐哲学的数学原理.md

@@ -0,0 +1,60 @@
+---
+title: 音乐哲学的数学原理
+date: 2026-03-30T14:06:00.000+08:00
+author: 线粒体
+---
+声音是由物体的振动产生的。从听觉上来说，振动频率越快，音调就越高；振动频率越慢，音调就越低。我们用$F=a\  \mathrm{Hz}$表示振动频率，其中$a \in (0, +\infty)$。
+
+那么既然$a$可以有无限个取值，是不是代表，我们可以用的**音**也是无穷？显然不是。对于人类来说，人耳生理上的限制决定我们并不能准确分辨所有的声音。比如，某两个音可能频率不同，但听起来一样；或者某个音频率太高或太低，根本听不见。
+
+首先我们探讨第一个问题，即人耳能听到的频率处于什么范围。根据研究，大部分人能够听到的频率介于$20\  \mathrm{Hz}$到$20000\  \mathrm{Hz}$之间。所以说，如果你想演奏人类能够欣赏的音乐，首先应当使得$a \in [20,20000]$。
+
+现在来探讨第二个问题：频率不同，是不是我们的耳朵就一定能准确感知这种不同？
+
+你可以使用一些设备播放一个特定频率的正弦波。首先将频率调到$440\  \mathrm{Hz}$，聆听一小会。然后调到$441\  \mathrm{Hz}$，你能分辨这两个音之间的不同吗？
+
+如此不断将频率调大，直到你可以明显感知到“音变高了”，观察频率数字，看看和$440\  \mathrm{Hz}$相差多少。对于一些听觉比较敏感的人，可能在调到$441\  \mathrm{Hz}$时马上就能感知到变化。但是对于一些听觉不那么敏感的人，可能要调到$443\  \mathrm{Hz}$乃至更高。这个简单的实验说明人耳对频率的分辨力是有一定限度的。所以，我们可用的频率$a$又缩小了，它的取值变成了一个离散集。
+
+让我们继续这个实验，依然从$440\  \mathrm{Hz}$开始，逐步上调频率。当然，这次你可以调得快一点，甚至直接按住按键，让频率连续快速增长。当一串滑音进入你的耳朵后，敏锐的听觉会捕捉到有一个“**回归**”的音。这个音听起来跟$440\  \mathrm{Hz}$非常相似，但是明显更高。这时候找到这个音的频率，发现是$880\  \mathrm{Hz}$。
+
+$880\  \mathrm{Hz}$可以有两种含义：一种是$440\  \mathrm{Hz}+440\  \mathrm{Hz}$，另一种是$440\  \mathrm{Hz} \times 2$。这时候我们会产生一个想法：如果我想再找到一个“回归”的音，应该将频率加上$440\  \mathrm{Hz}$还是乘以$2$呢？
+
+依然可以用实验来验证。将频率调到$880\  \mathrm{Hz} + 440\  \mathrm{Hz} = 1320\  \mathrm{Hz}$，和$880\  \mathrm{Hz}$比较，发现两个音好像没什么关系。再将频率调到$880\  \mathrm{Hz} \times 2 = 1760\  \mathrm{Hz}$，马上可以分辨出这个音又是一个“回归”的音。
+
+所以我们发现一个定律：频率$2^ka$在听觉上是回归的，其中$k \in \mathbb{Z}$。
+
+这样一来，我们能用的频率虽然没有发生什么变化，但是由于$\forall a$都有$2^ka$，所以真正可以称得上听起来“不重复”的频率，实际上只有$[2^ka, 2^{k+1}a]$这个区间。不管你选定怎样的$a$，对于任意一个$k$的取值所形成的各个区间，音都是“重复”的，只是音调的高低有所变化。
+
+所以我们的发挥空间一下子就变得非常有限。
+
+这时候你可能会说：没关系，反正人耳可以分辨$2\  \mathrm{Hz}$的频率变化。$[2^ka, 2^{k+1}a]$之中不是还有很多个$2\  \mathrm{Hz}$吗？所以可用的频率还是非常多的。
+
+确实，从数学上看，
+
+$$
+m = \frac{2^{k+1}a-2^ka}{2\  \mathrm{Hz}}
+$$
+
+随着$k$和$a$的增长，$m$会越来越大，也就是说我们可用的频率会越来越多。可惜很不幸的是，频率越高或越低，人耳的分辨力越差。而且即便是$2\  \mathrm{Hz}$的差异，也不足以用来形成音乐。因为音乐的要求是人能够快速分辨不同的音高，这就要求不同音高间差异应当足够明显。而且，如果这个区间内不同的音高太多，会增加大脑处理的负担。我们的大脑天生倾向于处理具有相似性的事物，包括音乐。所以我们采用的音高应该尽可能少，但又足以充分利用这个区间内的可用频率。
+
+我们使用的音，应该在各个区间内数量相等且“回归”。也就是说，第二个区间的第$n$个音，应当等于第一个区间第$n$音的$2$倍，以此类推。因此就不能采用$m$的算法，因为那样会导致不同的区间内音的数量不一样。
+
+那么每个区间内应该有多少个音最合适？
+
+经过世界各国在漫长历史过程中的实践，最终在当下，绝大多数音乐家都认为，每个区间内有$12$个音，最符合人类听觉和美感方面的要求。
+
+也就是说，假设以$a$作为第一个音，那么$2^{\frac{1}{12}}a$就是第二个音，$2^{\frac{2}{12}}a$就是第三个音……这样一来，对于任意$a$，在经过$12$个音后，都会“回归”到$2a$。
+
+比如，假设第一个音是$2^{\frac{2}{12}}a$，经过$12$个音，也就是
+
+$$
+2^{\frac{2}{12}}a \cdot 2^{\frac{1}{12} \cdot 12} = 2^\frac{14}{12}a = 2 \cdot 2^{\frac{2}{12}}a
+$$
+
+这称为“**十二平均律**”。
+
+你可能会产生疑问：为什么要把$2^ka$中的$k$分成$12$份，而不是把$2^{k+1}a - 2^ka$本身分成$12$份，也就是为什么不使用等差形式：
+
+$$\frac{2^{k+1}a - 2^ka}{12}$$
+
+这个问题又是另一个有趣的话题，可能还需要一篇文章来解释。

static/admin/config.yml

@@ -30,6 +30,7 @@ collections:
               "猕猴桃教教主",
               "aspaticopia",
               "文默居士",
+              "NukaCirno"
             ],
           default: "线粒体",
         }