2025-12-08 19:12:01
民间给微策略（MSTR）计算 NAV 用的方式是这样的:
$$
\text{NAV} = \text{资产} − \text{负债}
$$
如果把 MSTR 当作一个 BTC ETF 来看，使用这种计算方式比较合适。但 MSTR 官方的口径不同：
The multiple of the BTC Reserve, as of the specified date, calculated as the Company’s enterprise value (as we define it) divided by the BTC Reserve.
The Company’s enterprise value is calculated as the sum of (A) the total market value of all outstanding MSTR common stock, including class A common stock and class B common stock, calculated by multiplying the number of outstanding shares of class A common stock and class B common stock by the closing price of the class A common stock on the Nasdaq Global Select Market on the applicable date, (B) the aggregate principal amount of the Company’s indebtedness and (C) the aggregate notional value of the Company’s outstanding perpetual preferred stock, less (D) the Company’s most recently reported cash balance value.Although mNAV incorporates the label “NAV,” it is not equivalent to “net asset value” or “NAV” or any similar metric in the traditional financial context.
Additionally, it is not a measure of the amount by which the enterprise value exceeds net asset value in the traditional financial sense of those terms.Investors should rely on the financial statements and other disclosures contained in the Company’s SEC filings. This metric is merely a supplement, not a substitute, to the financial statements and other disclosures contained in the Company’s SEC filings. It should be used only by sophisticated investors who understand their limited purpose and many limitations.
所以根据 MSTR 的解读，mNAV 这名字里面虽然有个 "NAV"，但它不是 NAV，它是一个倍数，无单位，正确的算法是：
$$
\text{mNAV} = \frac{\text{EV}}{\text{BTC 价值}}
$$
其中，EV 是企业价值：
$$
\text{EV} = \text{Market Cap}
+ \text{Total Debt}
+ \text{Preferred Equity}
- \text{Cash}
$$
于是，
我的目的是用 MSTR 的方式来计算 mNav，而不是民间的做法。于是有：
market_cap = mstr_close * shares
ev = market_cap + debt + preferred_equity - cash
btc_value = btc_holdings * btc_close
mnav = ev / btc_value
= (market_cap + debt + preferred_equity - cash) / (btc_holdings * btc_close)
其中，mstr_close, shares, debt, preferred_equity, cash 可以直接从 Yahoo finance 拿到（ debt, preferred_equity, cash 要从季报里读，然后向前充填）； btc_holdings 和 btc_close 可以从从MSTR 官网 拿到
然后即可算出 mNAV。这个过程我让 AI 帮我 vibe coding 完成了。
由于 mNAV 可以直接预计算，所以不需要用 pine script 计算了，直接把上一步计算得到的结果塞到 pine script 里就行。
可以直接在这里使用我发布的脚本
2025-09-19 16:30:38
follow problems, not trends. 先把问题弄明白，代码只是把答案写下来。
程序是问题的解法。
现在你有一个明确的问题，它的解法可以压缩成一段可重复的动作。
你的程序 = 需求 →（抽象/分解）→ 可执行的步骤 → 稳定的结果
它不必伟大，也不必通用，只要稳定地把麻烦变成平静，就是好程序。
不会写程序的人，通过购买软件或订阅服务来租用别人的解决方案。
供应方卖的不是代码，卖的是可持续的可靠性与持续维护。
Vibe Coding 指的是：
门槛被抬走了：
这意味着越来越多的人将第一次「自己写程序」来解决自己的小问题
当问题规模很小（一个人的流程、少量数据、有限并发）时：
在这个尺度上，过去必须由工程师团队解决的门槛，显著降低。
比如说发博客文章这件事，Quaily 作为一个内容平台，需要向几千作者提供服务时，就需要通过合理的架构来解决数据规模上涨带来的问题。但如果自己做独立站点，只处理自己的文章，数量很少，甚至都不需要建立索引。
对工具类程序/服务显然是利空。如果核心价值是「把若干常见步骤串起来」，那么用户可能用 Vibe Coding 半天就复刻一个够用版。甚至，直接在 AI 对话框里就把事情解决了。
于是同质化功能的溢价被压缩，长尾需求被用户自助满足（比如图片处理）。
对授课/知识付费/方法论反而是利好。因为「把问题讲清楚」和「把需求说准」变得更重要。
好老师会教你如何描述问题、如何验证结果、如何迭代。这直接提升 Vibe Coding 的产出质量。
当问题跨过玩具规模，需要对外提供服务了：
这些都不是“几段提示词”能一蹴而就的。不具备计算机工程能力的人，目前无法仅凭 Vibe Coding 搞定大规模系统。
如果一个程序/业务的商业价值与规模效应、网络效应、分发、合规壁垒、数据壁垒、品牌与信任强相关，或者其价值本来就与技术无关（比如渠道、供给侧资源、IP），那么 Vibe Coding 难以替代：
举些栗子：
Vibe Coding 解决的是把意图落地为小而美的可运行草台方案，不是万能钥匙。
第一次写程序，不需要想架构有多优雅，先想我今天能把什么问题彻底解决。
把问题讲清楚，跑起来，验证结果。
这就足够好。
2025-09-06 12:37:06
之前在微信上班的时候，工作群里出了一件事：
一位前同事的孩子吃了从某电商购买的问题食品，被送进了医院。
所幸在群中电商朋友的帮助下，事情很快得到了处理：
当然以上措施的前两个放在消费下行的现在，已经不太可行了，毕竟 P 哒哒上的东西吃了也不一定会死对吧
另一个同事在群里说：做电商产品不重要，重要的是运营。
这个观点怎么说呢，有失偏颇。
今天因为这娃的爸是微信前员工，可以迅速得到了妥善处理，那明天其它顾客的娃出现症状怎么办呢？
如此关爱用户手段不具备良好伸缩性1。
Schelling 在 Choice and Consequence 中提到了「确定性生命」和「统计学生命」的区别：
确定性生命：一个有着棕色头发的六岁女孩需要几千美元接受一个手术，从而让她的生命能延续到圣诞节。社区邮局会被零钱和硬币淹没，因为人们都在捐款救她。
统计学生命：有新闻报道说，在取消销售税后，麻省的医院设施将不能得到及时更新，从而导致本来可以预防的死亡人数有一点点增加。不会有多少人为这新闻而落泪，更不要说捐款了。
电商这次关爱的用户是一位「确定性生命」，但是公司的数据报表里还有三亿「统计学生命」需要也更值得关爱。
如何在统计学尺度上描绘用户、理解情绪、关注到抱怨、制定规则，最终去关注这些似乎没有面孔、身份、性别、偏好的人，来避免诸如此类事件的发生，对规模化来说更有意义。
关爱分方法。
少有人会愿意花时间去考虑如何去理解和关爱自己的用户。
相比长期产品建设，人们更愿意用 ROI、GMV、DAU 等纯粹的数据指标去衡量产品和业务得失。
数据指标确实能够抽象和概括现状，但只要是指标就会丢失信息。
统计学用户不表现面孔，不代表他们没有面孔；能在数字之外看到用户的脸，才能创造顾客价值。
如果说回归商业，营销为王，那来回归一下营销，看看现代营销学之鼻祖 Philip Kotler 怎么说：
Marketing is not the art of finding clever ways to dispose of what you make. Marketing is the art of creating genuine customer value
营销并非一种以精明的方式兜售自己产品的技巧，而是一种创造顾客价值的艺术。
能对统计学用户给予关爱的产品设计，看似缺少运营，恰是对运营理解得最透彻的，在源头上做了正确的事情。
因为如果我是那个爸，我更希望自己的娃不要进医院，而不是有十二个不认识的叔叔阿姨来看她。
可伸缩性（scalable）是一个计算机领域术语。简单表述就是通过架构调整让系统做更多的事情，以较低的边际成本，服务更多用户。 ↩︎
2025-09-01 18:26:31
本文译自 Facebook 高级软件工程师 Forrest Smith 的文章《My Favorite Paradox》。
我得到了他的授权将文章翻译为中文。
我们正生活在一个“大数据”时代。免费游戏每天收集多达 300GB 的数据，网站记录你每一个像素的点击。现在甚至可以用 A/B 测试，来测试哪种 A/B 测试工具最好用。
谎言有三种：谎言、弥天大谎、统计数据。
—— 马克·吐温
有些人会恶意操控数字来得出他们想要的结论。我们对这种操作已经不陌生。
但还有一种更隐蔽的风险：那些聪明、受过良好教育、有理性思维的人，也可能从正确的数据中，得出完全相反的错误结论。这种事比你想象中容易发生得多。
1973 年，加州大学伯克利分校因涉嫌性别歧视被起诉。数据显示男性研究生录取率为 44%，而女性只有 35%。
| 申请人数 | 录取率 | |
|---|---|---|
| 男性 | 8442 | 44% |
| 女性 | 4321 | 35% |
这起诉讼引发了一项深入研究。研究结果却显示：不仅女性没有被歧视，她们的录取率甚至还更高！
这到底是怎么回事？数据不是已经很清楚了吗？
答案是：辛普森悖论。
在分组数据中出现的趋势，可能在合并后消失，甚至反转。
事情是这样的：有些院系录取率高，有些则很低。而女性更倾向申请竞争激烈的院系，男性则偏好录取率高的“容易进”的院系。整体看似男性更占优势，但一旦分院系来看，反而是女性更容易被录取。
| 男性申请 | 录取率 | 女性申请 | 录取率 | |
|---|---|---|---|---|
| 院系A | 825 | 62% | 108 | 82% |
| 院系B | 560 | 63% | 25 | 68% |
| 院系C | 325 | 37% | 593 | 34% |
| 院系D | 417 | 33% | 375 | 35% |
| 院系E | 191 | 28% | 393 | 24% |
| 院系F | 373 | 6% | 341 | 7% |
这是一个真实案例，也成为辛普森悖论中最经典的实例之一。
我非常喜欢这个悖论，因为它不仅会影响结果，甚至能彻底颠覆结论。而且这种“翻转”真的太容易发生了。
我们再看一个案例，加深理解。
肾结石有两种治疗方法，哪种更好？
看起来方案 B 更好，对吧？其实正确答案是：方案 A！
为什么会这样？
| 类型 | 方案 A | 方案 B |
|---|---|---|
| 小结石 | 93% (81/87) | 87% (234/270) |
| 大结石 | 73% (192/263) | 69% (55/80) |
| 总体 | 78% (273/350) | 83% (289/350) |
肾结石分大、小结石，大结石更难治。而无论是哪种结石，方案 A 的成功率都更高。
关键在于两种方案中，小结石与大结石的分布不同：
因为方案 A 的样本更多是难治的大结石，所以它的总体平均治愈率被“拖了后腿”。而方案 B 虽然整体治愈率高，但那是因为它治了更多容易处理的小结石。其实每一种结石类型上，方案 A 都更优秀。
辛普森悖论就像剥洋葱：最外层的数据说方案 B 更好；你深入一层，发现 A 才是赢家；再剥一层，也许在某些特定情形下又轮到 B 更合适。
比如老年患者？肥胖患者？合并其他疾病的患者？每深入一层，你都可能翻转之前的判断。
在分组数据中出现的趋势，可能在合并后消失，甚至反转。
我喜欢这种“每剥一层就推翻结论”的过程——它挑战直觉，逼你不断思考。
辛普森悖论不仅出现在招生或医学上，游戏数据分析也中招。
想象一个 FPS 游戏，玩家们抱怨狙击手太强了。你查看数据：
看起来玩家说得对。但深入一层：
这时候你可能开始想调整。但你还没深入够，继续剥洋葱：
最后两条我特别喜欢，因为：
我有个猜想——也许可以算是一条“定理”：
对于任何统计结果，都可以构造出一个相同数据但得出相反结论的场景。
这就是为什么，每当你得出一个数据结论时，都要问问自己：
无论你拥有多少数据，问对问题才是关键。
你可能出于好意做分析，但问错问题就会得出错误答案。
辛普森悖论是个警钟，提醒我们：小心统计的陷阱。要常常提醒自己：
“如果我再深入一层呢？”
再讲一个我很喜欢的故事。
2012 年，YouTube 工程师 Chris Zacharias 写了一篇博客《Page Weight Matters》。他在负责优化 YouTube 的视频播放页。原页面太大，达到 1.2MB，加载慢得令人抓狂。
他花了几天，把页面优化到了 98KB，减少了请求数，还用 HTML5 播放器取代了笨重的 Flash。感觉很棒，他上线了新版本。
一周后回头看数据，结果惊人：
新页面比老页面加载还慢！
平均延迟竟然上升了，怎么会？明明页面更小更快啊？
这其实又是辛普森悖论。
原因是：优化后新页面吸引了大量“新用户”，比如来自东南亚、南美、非洲等网络条件较差的地区。这些地区加载时间平均为两分钟——虽然慢，但已经能用了。
而在旧版本，他们压根打不开页面，自然也就不被统计进旧数据中。
所以，从 20 分钟缩短到 2 分钟，不是失败，而是巨大的胜利。整个原本无法使用 YouTube 的人群，现在终于可以用了。
结论呢？初步统计说这是失败的上线。
所以问题来了：我们有多少次，也在数据中误入了“悖论”，却浑然不觉？
2025-07-07 15:02:04
Quaily 最初是打算开源，但一年多来都没有找到开源的理由。如果开源的话，对于代码、架构、文档的质量的要求会很高，社区参与低的话，我是没有精力做这些事情了。
不过也陆续完成了不少开源仓库。这些仓库不是「为了开源而开源」，而是 Quaily 在实际开发里遇到具体问题后诞生的工具。
下面梳理它们的来历，并补充更技术向的细节。
虽然我的习惯是不出设计直接代码，但是项目规模稍大以后，还是希望有一套统一的视觉。
当时流行 Tailwind，但我不喜欢，冗余，废话太多，于是需要一套更轻巧、样式统一的 UI 组件，那就自己写吧，反正也不难。
<script setup>、SCSS 变量、按需 import＋Rollup Tree‑Shaking。src）：QButton / QInput / QTooltip / QDialog / QIcon* / QLoading 等 60+ 组件，配套 icon 集可直 import。查看 Demo。用法：
import { createApp } from 'vue'
import { QuailUI } from 'quail-ui'
import 'quail-ui/dist/style.css'
createApp(App).use(QuailUI)
Web 前端与 Obsidian 插件都需要和 Quaily API 交互，那就整个包吧。
src/ 以 ESM 方式导出 QuailyClient，内置 token 注入、重试与错误映射；Rollup 打包生成 dist/。主打一个一把梭，又不是不能用。
调用：
import { Client } from 'quail-js'
const client = new Client({ apibase: 'https://api.quaily.com', access_token: '...' })
const resp = await client.request(url, 'GET', null)
Quaily 早期无 Web‑CMS，一切创作在 Obsidian 中完成，需要一键发布。于是需要个 Obsidian 插件。
Quaily: Publish / Unpublish / Preview / Sync。goldmark 扩展性极好，适合 Quaily 用来扩展 Markdown 语法。
提供的扩展 ：
 语法；==text== → <mark>；<a title="…">。调用：
md := goldmark.New(goldmark.WithExtensions(enclave.New()))
详细的方法请查看项目 README.md
需要在 CI/CD、脚本或本地终端里操作 Quaily，并探索将 Quaily API 暴露给 LLM 工具链（MCP）。
这里有两篇介绍：
示例：
# 登录（浏览器完成 OAuth）
quail-cli login
# 从 markdown front‑matter 创建或更新文章
quail-cli post upsert article.md -l my-channel
每月要生成大量符合日本税务格式的发票，手工排版麻烦不说而且易出错。那就写个程序吧。
特性 ：
使用方式：
读取 YAML/JSON 参数 + 可选字体配置 → GenerateInvoice() 回传 []byte：
bd, _ := builder.NewBuilder(cfg, "./params.yaml")
pdf, _ := bd.GenerateInvoice()
os.WriteFile("invoice.pdf", pdf, 0666)
Quaily 的 i18n 文案存放在 JSON，手动翻译耗时；希望借助多家 LLM 快速产出可初审的翻译。
--batch 控制窗口大小；命令示例：
translate-cli translate -s en-US.json -d ./langs -g glossary.json \
-b background.txt --batch=20
这些工具都源于“先把问题解决掉，然后顺手贡献给社区”的习惯。如果它们也正好能解决你的痛点，欢迎 Star ⭐、提 Issue、开 PR
2025-05-14 09:17:13
生命是神奇的存在。
生物学家们致力于考察真实生物的运作机制，而冯诺伊曼不同，他尝试在数学上寻求生命的本质。
因为在冯看来，生命的本质属于一种软件逻辑，他设计的「生命」形态可以与现在的生命完全不同，所以他选择的起点是图灵机。
以上就是 Gregory Chaitin 的《证明达尔文》一书前五章的主要观点。
书写得冗长，读得很累。这个老头子有严重的骗稿费嫌疑，把一个课件写成了一本书。
我只打算写一篇文章，和老头子这本书的附录有关，附录是冯诺伊曼手稿。假如计算机科学是宗教，他是神祗之一。
耳机放兜里会打结，开水会慢慢变凉，长时间不扫地面会脏。
这是对自然造物的直观认识，独立封闭系统中的有序状态会自发地趋向于混乱和无序，是熵增过程，遵循于热力学第二定律。
传统的机械，我们的大部分人工造物，也存在存在类似的状况。
假设一个机器 A 能够自发地制造出机器 B，那么 A 中必须包含完整的 B 的信息，只有这样 A 才能根据这些信息将 B 制造出来。因为 A 包含的信息大于等于 B，即 A 要比 B 复杂。
如果根据这样的理解，机器的复杂度会在制造过程中不断降级和衰退，即一个系统的复杂度总是高于它所能制造的子系统的复杂度。
但是另一方面，在自然界却存在与之背离的欣欣向荣的现象：生命的诞生与进化，科技的发展和进步，都在往越来越复杂和多样化的方向发展，即人人都谈论的「涌现」这一概念。
由于对此难以控制、预测和描述。因此，在历史上的大部分时间里，人们都认为这是一种神迹。
即使到现在，我们能说清楚大脑是如何用神经递质传递信号，但是也没搞清楚智慧是如何产生；我们能观察到生物体内所有的生化反应，但是没有成功在实验室里合成出真正的生命。
我们早已习惯并且百试不爽的自底向上的思维方式，在这里似乎没有达到预期的效果：
低层级的存在无法推断高层的复杂性。
似乎在诸多现象中，复杂度的积累存在一个阈值。没到这个阈值时，事物最终自发地衰退；超过这个阈值时，就立刻呈现涌现的群体特征。在成为神的道路上，这一问题拦住了脚步：这个阈值在哪。
冯诺伊曼意图能找到这个阈值。
生命是神奇的存在。
生物学家们仅考察真实生物的运作机制，而冯与传统生物学家的追求不同，纵观他的工作，冯是在沿着一条规范的道路——数学——寻求生命的本质1。
或者说，在寻求一个生命的最小内核，因为在冯看来，生命的本质属于一种软件逻辑，他的「生命」形态可以与现在的生命完全不同，所以他的起点是图灵机。
图灵机很简单，对任何一个图灵机，他的描述总是有限的，因此可以通过某种方式将其编码为一条图灵机指令。图灵机 $M$ 的描述可以用 $I_M$ 来指代，所有计算机科学专业毕业生都知道。
冯·诺伊曼设计出了这样一组机器：
在假设中，我们认为 $A$、$B$、$C$ 是元零件，并且容易得出以上描述不涉及循环指代：需要 $I_D$ 时，$D$ 已经存在，因此 $D$ 和 $I_D$ 间存在确定的时间和逻辑顺序，对 $E$ 的自复制能力的论证是严密的。
我们很容易在生物体中找到上面这组机器各个组成部分的对应物：
但是，如果单独来看，无论是构造机 $A$，复制机 $B$，控制机 $C$，还是他们的基因 $I_D$ ，在他们各自独立时，都不具备自我复制的能力。当他们以合理的方式组织在一起时，却实现了自我复制，实现了自复制功能的涌现。
冯的研究仅仅是向一个关于自动机的涌现理论迈出的初步尝试，这个尝试在试图对复杂系统中的「复杂性」形成一个概念。他认为「复杂性」在一个阈值以下的系统会自发退化，这样的系统只会产生复杂性更低级的系统；而当复杂性高于这个阈值时，系统可以在该层次的复杂性上维持（比如 $E$）；如果我们能让人工造物的复杂性高于这个阈值，那我们就做了神的工作2。
冯诺伊曼虽然最终还是没有找到这个复杂度阈值，但他认为可复制自动机应当处于一个相当靠近复杂度阈值的地方，而且与其他试图解释涌现的理论的差异在于，冯·诺伊曼的解释在数学上存在对应物，如果我们不满足于仅仅观测，而希望真正深入地理解涌现，可复制自动机理论可能是条件很好的切入点。
悄悄敲敲代码，就有机会创造世界。
