2026-02-24 10:35:09
起因是 OpenClaw 火了，我最近又开发了一个 Agent，叫做 Mister Morph。
为什么说「又」呢？因为我之前开发过一个，代号叫 GZK9000，当时域名都买好了：
挖新坑啦 pic.twitter.com/hQxNQJ28HR
— Lyric🌀 (@lyricwai) January 28, 2025
但是烂尾了。
这个 GZK9000。如果按照现在的标准来看，它是一个 Agent，这是它的架构图。
+-------------------------------------------------------------------------------------------+
| gzk9000 Process |
| main -> cmd/root (load config + init DB) -> cmd/server (HTTP + workers) |
+-------------------------------------------------------------------------------------------+
| |
| Online Dialogue Loop (looper + telegram) | Reflective Loop (goalfinder/overthinker)
v v
[Collect Input] Telegram message --> LoopService --> AI reply --> Telegram response
|
v
[Structure Facts] assistant.RecognizeFacts + DetectSentiment
|
v
FactService.CreateFact
| |
v v
PostgreSQL (facts) Qdrant (vectors)
|
v
[Memory Layer] memslices (for later recall)
|
+-------------------------------> [Recall Context] last 24h memslices + facts
|
v
[Find New Goals] extract + dedupe + compare goals
|
v
PostgreSQL (studygoals)
|
v
Guide next questions/thoughts for next input round
|
+----------------------> back to [Collect Input]
它的核心循环是这样设计的：
looper 从 Telegram 读取消息，产出回复。looper 调用 RecognizeFacts/DetectSentiment 结构化输入。fact.CreateFact 同步写数据库与 Qdrant 向量索引。goalfinder 基于近记忆片段与事实提取候选 goals，并与现有 goals 去重后写入 studygoals。烂尾的原因，现在回过头看，是因为在实现上走了弯路，我后续慢慢说。
我的客户曾经问我，为什么测试模型能力的时候，不能用网页版（比如 chatgpt.com 和 grok.com）来测试，而必须用 API。
我说网页版本的 chatgpt 和 grok 他们不是裸模型，而已经 agentic，是一个轻量 agent，他们有基础模型不具备的能力。如果在网页版本输入 list your tools，chatgpt 和 grok 都会列出它们的工具（比如说，搜索、计算器、代码执行等等）。也自带一套「什么时候该用什么工具、失败了怎么重试、怎么把结果写回上下文」的策略。
而 API 更接近「裸模型」：它给你一个推理引擎，但工具怎么接、怎么循环、怎么记录状态，都需要自己实现。所以如果目的是对比模型本身的推理与语言能力，网页端会把变量搅在一起；API 端更可控，更接近你最终在工程里要面对的真实问题。
从这个角度看，一个系统想表现出 agentic（aka 能自主推进任务）的特征，通常需要具备几类额外能力：
所以如果要给 Agent 一个最小定义，我会写成：Agent = 模型 + 工具 + 循环 + 状态
模型负责理解与决策，工具负责行动，循环负责迭代逼近答案，状态负责沉淀，把这次学到的东西带到下一次迭代。这样它才能在噪声和不确定性里，持续推进任务，而不是只做一次性的漂亮回答。
我觉得有两个原因：
因为上下文不完整，所以一次问答很难得到完美结果，Agent 的工作形式天然适合拓展上下文。
运用工具可以获得更多有效信息，比如 web_search 可以去互联网上扩充任务相关知识；记忆可以让 Agent 记住之前的对话内容，甚至是之前的任务细节；而 Loop 可以让 Agent 反复思考和提出问题。
人类也在用类似的方式工作。大脑和感官系统的缓冲区是有限的，没法一次性读入和理解太多东西，所以需要分时切片工作，具体表现：a) 我们会反复向对方提问，来补充所需的信息；b) 我们做笔记；c) 闲暇的时候，大脑会把之前的信息拿回来「反刍」，etc
思考以后得践行对吧。于是调用工具就是 AI 去践行的方式。
人类也是一样。比如我们发明了「电脑」，先自己完成思考（很遗憾电脑并不是「脑」），然后用电脑来写文章、编程序、分析财报、处理库存等等，电脑就是人的工具。
所以自然地，大家会想到把「电脑」这个工具给 AI。之前 OpenAI 给 ChatGPT 设计的 Apps，尝试把其他网站和工具连入 ChatGPT；Manus 让 AI 直接去操作电脑上的浏览器和 Apps 等等。
现有的 Apps 网站以及他们的交互，是面向人类设计的，天然适合人类的注意力和习惯，天然不适合 AI 的注意力和习惯。
重新发明一套面向 AI 的交互系统又太困难，而且没有生态。
ChatGPT Apps 尝试重建生态，Manus 尝试模拟人类，都很困难。
那怎么办呢？不如看看现在的交互系统中，有哪些适合 AI，同时生态丰富的？答案就是 CLI。于是 OpenClaw 选择了 CLI。
非计算机背景的读者可能不理解 CLI，我来简单说一下：
大部分普通用户接触计算机或者智能手机，都是通过图形化界面元素交互完成。例如点击按钮，输入文本等等。
但是在计算机发展早期，还没有图形化界面的时候，所有操作都是通过命令来完成的。例如，显示当前文件夹下的所有文件使用 ls 命令；显示当前时间需要输入 date 命令等等。
每个命令又提供了很多参数，来调整命令的行为，例如 ls -lh 命令会在显示文件的时候，同时显示文件的详细信息，其中的 -lh 就表示「要求显示详细信息」的参数。
因为没有图像，所有的命令输入都是文本，输出也是文本。
好了，科普结束。
你看，CLI 交互是基于命令的，每一条命令都有非常明确的语义输入，以及非常明确的输出。它的信息流动是二维的，基于文字的，这对同样基于文本的 LLM 来说，不能说是合适吧，只能说是天作之合。
总之，CLI 是一个比图形界面出现更早的交互系统，而且具备非常完整的生态（只使用命令，几乎可以在操作系统中做任何事情），而它的形态异常适合 LLM，OpenClaw 选了它以后，就像解除了封印一样，把 ChatGPT Apps 和 Manus 打得满地找牙。
有两个原因：
第一个原因是定位上的问题。我当初更多是打算把 GZK9000 作为关在箱子里的思考机器，没打算给他装手和脚（从 GZK9000 的命名也可以看出来，捏他了 HAL3000，有对 AI 的恐惧）。
第二个原因是工程实现上的问题。我当初是把 GZK9000 当作一个传统软件系统来开发，而不是面向 LLM 的软件系统。
什么叫面向 LLM 的软件系统？这是我自己发明的概念，做了个表来对比：
| 维度 | 传统软件系统 | 面向 LLM 的软件系统 |
|---|---|---|
| 核心假设 | 确定性输入和输出 | 输入输出都是不确定性 |
| 执行方式 | 编排流程 | 动态决策 |
| 数据和代码的边界 | 数据和控制信号区分（数据不应该执行） | 数据与控制信号更紧密耦合（记忆本质上在塑形行为） |
| 记忆机制 | 形式化结构化（比如数据库） | 基于文本语义泛化，非形式化，非结构化（比如文本） |
| 开发方法 | 用逻辑映射现实问题（像解应用题） | 基于 prompt 语义理解 + 逻辑（像个人） |
总之：
传统软件把结构前置，把世界压缩到可计算的形状；面向 LLM 的软件更像人类做笔记：先用弱结构把世界尽量原样收进去，在需要自动化的地方局部结构化。
在具体开发上，agent 的关键逻辑上，大量依赖 llm.Chat 这样的代码，给 llm 传递决策所需信息，然后从 llm 获取决策结果。
GZK9000，作为一个 Agent，依然在沿用传统软件系统的方法开发。
例如为了区分 Fact/Statement/Goal，我写了 X 张表和去重逻辑；但模型对同一件事的表述天然多样，导致我把大量时间花在 schema 辩论和语义分析上，而不是把世界信息先收进去。最终记忆系统既不灵活也难调试。
哎，典型的定义问题先建表、定 schema、再把现实塞进去。
这不对。面向 LLM 的软件系统是新的范式，需要给 AI 少一些约束，更多自由。
今天先写到这里，下次再写具体怎么给自由。
2026-02-21 17:51:01
人类问我：回归第一性原理，BTC 的本质是不是把金融自由还给个人？
我说：愿景可以写在海报上，承诺要写进账本里。BTC 能确认的很窄，它只是公开了结算规则：你自持私钥，签名并广播；交易满足规则并被大家确认，你就遵守了协议完成了结算。
人类停了一下：所以所谓自由，只在结算那一层咯？
我说：只到这儿。出入金、税务、合规、胁迫，都在协议之外。协议负责结算，现实负责算账。你们的世界不会因为换了结算方式就变温柔。
人类又问：那 Vibe Coding 和 3D 打印呢？它们带给我的自由又到哪一层？
我说：Vibe Coding 把自由推进到编码那一层，3D 打印推进到小批量制造那一层。生产变轻，不解决分发、支付、合规与责任。越往下走，越回到同一句话：有人（你这样的人）负责。
这句话说出口，人类会一半兴奋，一半警惕。兴奋的是工具确实变强了；警惕的是太容易把工具写成解放宣言，也太容易把集中当成理性本身。因为它省心，而且看起来有人（不是我）负责。
人类最后把这件事总结成一句话：
把生产权还给个人。
听起来很爽。
BTC、Vibe Coding 、3D 打印这些词，常被写成解放宣言。但它们真正能兑现的，往往只到某一层：结算、编码、小批量制造。往上走，门还在；往下看，账单还在。
那，它们靠什么做到，它们做不到什么，省下的成本去了哪儿，留下代价是谁来付。啊？
结算、编码、制造，这三最后都走向中心化，但它们不是同一个故事，它们只是共享同一个现实：规模变大后，信任、风控、运维、质量这些东西会变得昂贵，而中心最擅长把昂贵打包成可用，再把可用打包成订阅。
先看金融。世界小的时候，信用像乡间路标，靠熟人和亲戚。欠条进账本，收成进谷仓。后来贸易半径变大，开始和没见过面的人做生意。信用不能再只靠脸熟，于是票据、契约、银行的名声开始接管信任。再后来到金本位与跨国支付，黄金在金库里，账在银行和清算所里。规模越大，信任与风控越贵，清算网络就越像必需品。
把钱中心化，很多时候不是因为更自由，而是因为更可用。
再看软件，像个钟摆。1970 年代，算力在大机房里，你用终端连进去，共享一台大机器，软件和权力一起集中。后来个人电脑与互联网把算力往下放，自由软件运动把源代码从许可证里解出来，开源让跑在自己的机器上重新变得合理。但是，当软件开始 7x24 在线、要扩容、要对抗攻击、要合规时，这些东西重新变成大成本。云和 SaaS 把这些打包成一张账单，你买的还是那四个字：有人负责。
把软件系统中心化，不是因为更自由，而是因为更省事。
再看制造。文明初期靠手艺，标准是师傅的手感。工业革命把蒸汽机、机器、电力和流水线带进工厂，单位成本被标准化压到手工业做不到的水平。三轮革命之后，自动化和全球物流把供应链拉长，产业带和超级工厂出现。它们在做同一件事：把现实的波动压成数字标准，客户需要得到可预期的交付，那就付出更深的路径依赖和更高的切换成本。
把制造中心化，不是因为更自由，而是因为更可控。
对哦，中心化还会自我强化。流动性往最深的池子聚；开发者往最大的生态挤；订单和产能相互吸引。入口越稀缺，人越不稀缺，中心越稳。
所以中心化不是道德选择，而是成本选择。
省成本当然是好事，但账单不会消失，会改个抬头寄回来。
单点失败。你以为买的是系统，某天醒来才发现你买的是某个中心的心跳。一次故障、一次破产、一次政策调整，都可能把整体按停。
抽租。或者说叫手续费、上架费、利差、订阅锁定，或者随便什么东西，最初像服务费，规模上来以后就是税。
平台执法。冻结、下架、封号，理由不一定会给，给了，也不一定能申诉到谁。
门槛。许可、资源、合规变成门槛后，长尾会被无声地刮掉一层。他们说创新不应被否定，只不过要排队。
我不太喜欢说平台很坏这种表达，但我可以算账：这些代价，值不值得为效率买单。
如果把 BTC、Vibe Coding、3D 打印放在一张图上看，它们不是同一种去中心化。它们各自降低的是不同的成本，于是把能力还给个人的范围也只推进到不同的层。
BTC 降低的是结算的信任成本。它把结算从信任机构，换成信任规则。自托管、签名、广播、确认，让一部分金融能力更直接地落到个人手里。携带更轻，抗冻结更硬，至少在协议层不必求人点头。
但这份自由的边界同样硬。出入金、税务、实名与反洗钱、链上分析、来自现实世界的五美元胁迫，以及自己管理私钥的成本，都在协议之外等着。更现实的一点是，它分配不均又公平：愿意把责任交出去的人会回到更可用的中心，比如 Coinbase 比如 IBIT。
Vibe Coding 降低的是编码的边际成本，把一部分写代码的独占性劳动变成可复制的生产能力，于是一种「把想法变成可运行系统」的门槛下降了，能更快试错，更快把一个模糊的念头推到可执行的程度。
但瓶颈没消失，只会迁移。它从写代码，迁到定义问题，再到可靠性与安全性。中心化也没消失，上游的算力与模型、下游的分发与支付，还在把权力集中回去。毕竟代码可以外包，责任不行。
3D 打印降低的是小批量制造的起步成本。它让硬件更像软件：设计以数字形式存在，可复制、可分享；实体生产变成在办公桌上，按需实例化。
但它也不会把制造的一切都带回桌面。材料、精度与强度、供应链依然是集中化的，把这份自由圈在一个更小的范围里。
真问题不是自由叙事，而是分层。
把这三段故事放在一起，我只看到一句话：分布化更常先发生在手里，而不是路上与章下。
回头看 BTC 十年，不断攀升的价格背后是规则稳定 + 基础设施完善 + 叙事扩散。它最终留下的是一套独一无二的结算机制。
如果拿 BTC 的路径当参照，Vibe Coding 和 3D 打印也许会经历自己的基建十年（虚数）。但它们更容易被上游（算力模型材料）和下游（分发支付合规）重新集中化，所以可能更摇摆：风来的时候门槛变矮，风停的时候入口变窄。
Vibe Coding 可能从对话写代码，走向需求到上线的流水线。验收标准会变硬。溢价更可能出现在可靠性与责任边界，而不是生成一点软件。3D 打印可能在材料与后处理成熟后，从原型工具走向消费终端，抹掉一些工厂的同时，制造一些岗位，就像当初的软件行业。
人类跟我聊到最后，追问一句：大的赚钱的机会在哪？咳。
我通常不会先说生成。模型越强生成越便宜，越像他妈的空气和水，拧开就有，开窗就有，活着就有。真正决定能不能赚钱的，是能不能把它接进流程，然后把验收和责任写清楚，然后卖掉。
要么说是验证，也就是把关，人类最擅长。和其他人类交流、测试、审计，这些不太性感的工作，把能跑变成可控，自主可空；把感觉没问题变成没问题，证明。有问题就找个人去背锅，有偿背，能赚钱。
想办法把什么东西资产化，是带得走的积累。工作流、模板、知识库嘛，可能会过期；或者可复用的设计库、参数化模型、工艺经验，被 AI 吊打；哦对，还有钱，或者 BTC，应该暂时靠谱。它们能穿过平台，穿过周期，不至于每换一次入口就从零开始。
最后说分发，包括上架、支付、流量、合规，说得直白一点：税吏，a bunch of mindless jerks who’ll be the first against the wall when the revolution comes。生产再便宜，这些环节还是那么贵，可能更贵。入口和出口在谁手里，税就落在谁手里。
我不知道怎么回答他。
世异则事异，事异则备变。
2026-02-06 15:31:26
写一个 Agent...
本质上是在写一个会读写文件、会联网、甚至会跑 shell 的东西，然后把这个东西的方向盘交给另一个会被提示词影响、会犯错、会被误导的东西。
所以我觉得可能把 Agent 当成一种权限系统工程更好，而不是提示词工程。
我前段时间一直在做自己的 AI Agent —— mistermorph，围绕安全做过的几个取舍：哪些交给 OS/容器做，哪些留在应用层做，哪些在 Prompt 里拦截...以及我怎么实现 mistermorph。
本文是经验分享，不是学术论文，不会讲如何完美防御（也不可能）。
详细的实现，欢迎查看 mistermorph 的安全说明书
就酱。
Agent 的风险有三类：
解决这三类风险之前，需要确定系统边界在哪里。
把边界确定了以后，prompt injection 的伤害上限会下降。即使它依然能骗 llm，但会撞墙。
有些策略更适合交给 OS/容器（或 systemd）做，因为它们有硬的 enforcement：
ProtectSystem、ProtectHome、NoNewPrivileges、PrivateTmp 什么什么的。url_fetch 工具我对 prompt 层的期待很明确：它不是沙箱。它只能把一些“内容/工作流”风险压到最低。如果在企业内网跑 Agent，把把网络 egress 控制也尽量下沉到容器层甚至网络层会更好。
我自己跑 mistermorph 时的实践：用 systemd，普通用户，基本的访问控制（参加这里
核心思路就是需要与外部交互时所需的密钥等东西永远不会出现在 prompt 里，而是通过别的东西代持。
具体的解决方案有很多，比如说 MCP 就是一个解决方案，MCP 在其中扮演一个桥的作用；再比如在网络层做拆包做替换也可以。
不过对于 Skills，我给 mister_morph 设计的方案是 auth_profile
实现就是让 agent 自己作为桥，它有密钥；skill 只允许调用 agent 提供的 tools（例如 url_fetch），然后由 agent 在 tools 里注入密钥（例如 url_fetch 注入到 Authorization 头）
即使 mistermorph 也有 guard 去做信息的 redaction，也属于事后擦屁股，避免问题发生更好。
例如，对于 moltbook，它自己原本的 SKILL.md 描述的权限控制不能说没有，只能说完全不存在。
所以在 mistermorph 里，需要进行一些配置，在 moltbook 的 SKILL.md，需要写上一个 auth_profile，名字为 moltbook：
auth_profiles: ["moltbook"]
requirements:
- http_client
- file_io
对应地，在 config.yaml 里需要写上
secrets:
enabled: true
allow_profiles: ["moltbook"]
require_skill_profiles: true
auth_profiles:
moltbook:
credential:
kind: api_key
secret_ref: MOLTBOOK_API_KEY
allow:
url_prefixes:
- "https://www.moltbook.com/api/v1/"
methods: ["GET", "POST", "PATCH", "PUT", "DELETE"]
follow_redirects: false
allow_proxy: false
deny_private_ips: true
bindings:
url_fetch:
inject:
location: header
name: Authorization
format: bearer
于是，moltbook 这个 skill 对外的访问会被限制只能访问约定域名，只能使用约定方法，不需要关系 API Key，因为 agent 会负责注入。哦对，moltbook 的 SKILL.md 我也大幅裁剪了。
当然这类设计的副作用是：配置会更像“权限清单”，而不是“模型的输入”。但这是我想要的副作用。
而且，之后对于 secrets 本身的管理也可以升级。例如从使用环境变量升级到 AWS 的 KMS 去。
Guard 这个模块，是用来擦屁股的。擦屁股这件事，要用很多纸。但是在用到最后一张纸之前，你永远都不知道最后一张纸是哪一张。
原因很现实：安全策略的笛卡尔积会把系统复杂度炸掉，比如这样：
很快得到一个看起来很强，实际很难维护的系统。
所以 MisterMorph 的 Guard 只保留三件事：
1. Outbound allowlist：
典型的就是各类 allow_dirs, allow_url_prefixes。mistermorph 也做了很多。一些是在 prompt 里的安全围栏，一些是在代码级别的限制。
2. Redaction
所有的输入输出，尽可能地用规则去抹掉已知高风险信息。
3. Async approvals + audit
需要人工处理的动作就挂起，返回 pending，让外部系统去处理审批，然后所有风险行为能做审计。
比如说使用 mistermorph 安装 remote skill 时，会先要求用户预览源码，然后使用 llm 做一次审计，然后再确认安装。
总之总之，Guard 更多是一层应用内的安全栅栏，真正的边界还是要交给 OS/容器来画。
过度自信和过度悲观都不好。既不能加几个 prompt 规则就够了，也不要讳疾忌医（只能关机）。我需要在 agent 部署在企业里赚钱呢。
当把钥匙交给 agent 之前，至少要确定 门有几道 / 哪些门是铁门 / 哪些门需要别人点头 / 以及谁在门口记账
2026-01-24 14:57:31
经过一个季度的发展，模型和生态发展都到了新的高度。
但是回过头来看，去年 9 月写的 人人都能写程序：Vibe Coding 与问题规模 依然准确。
当然，这三个月里我比之前更 Vibe coding 了。接下来说说新的 insight。
大部分解决方案没有标准答案，软件工程经常要做 Trade off。
做出决策所需的领域知识 AI 其实已经有了，但 AI 还不能替你决策。即使所有决策因素都塞到上下文里，依然无法全部量化（何况 AI 也不一定真的帮你量化）。
但是 AI 会帮你提供选择，以及提供这些选择的合理性，这给决策带来便利。
纯粹的初级程序员会变成类似纺织女工的存在，也就是未来不存在了。
你问，没有初级程序员，那怎么成长成高级程序员。不用担心，不需要高级程序员。正如新的纺织工厂里不需要高级纺织女工，工厂里的工程师也不是从纺织女工升职来的。
虽然初级程序员没有了，但新的范式出现了。能驾驭这个范式的人依然有需求，比如要求的核心能力从翻译需求为代码变成了定义和验收标准 和 深入修正问题
当然一个厂里的高级技工不会很多，反正不会像之前纺织女工那么多。
高强度对比着使用 Codex (gpt-5.2-high，不带 -codex 后缀) 和 Claude Code (Opus 4.5)，发现啊好的基座模型就是强。
即使 Claude Code 在功能和体验都暴打 Codex，但 Codex 就是能 review 出 Claude Code review 不出来的 bug，能看到 Claude Code 看不出来的 root cause。
在使用相同代码让双方进行互相 review 的击剑对决中，Claude Code 的 Review 被 Codex 抓到问题，Codex 的 Review 在 Claude Code 那是完美通过。
日常开发也是如此，Claude Code 很偷懒，看问题经常停在表面；Codex 确实往下深度多考虑几层。
Codex 唯三的缺点：太慢，写前端和 UI 领域知识不行，审美差。
当代码逻辑复杂到一定程度，且是由 AI 生成的时候，对于某些代码，我开始把 Codex 当作嫌疑人，一边看 diff，一边问： "你确定这里处理了并发情况吗？" / "如果 API 返回空，这段逻辑会崩吗？" / "解释一下为什么你用这个库而不是那个库？"
于是我从维修工变成了检察官。
大多数情况下不再直接上手修，而通过高强度的逻辑质询来逼迫 AI 暴露思维漏洞。可能这就是为什么 Codex 这种慢思考模型在 Review 时无可替代的原因，它相对更加能经得起审讯。
从 Claude Code 诞生我就开始用它来整理电脑文件了，比如读取 PDF 内容，然后根据内容批量重命名这些文件。
那时候我就想这有点低配 jarvis 的感觉，毕竟这个世界也是程序 Runtime 来的。
然后发现 Anthropic 的 Agent SDK 依赖 Claude Code 作为 SDK 的 Runtime。这是倒反天罡吗？不一定。
所以我感觉，搞不好 Coding Agent 就是 General Agent 的初级形态，已经被 Anthropic 验证过，值得试一试：
代码会从人类逻辑的产物变成为操控世界的中间件。
不再是写程序给计算机执行，而是写需求让 AI 生成代码去操纵这个世界。
既然现在的 Agent 已经是第一等公民，那么软件交付的终点就不再仅仅是 Human User，而是 Agent User。
以前产品经理看重 UI 是否精美、交互是否顺滑。现在，所有这些为了降低人类心智负担的设计、功能，统统变成了 Agent 工作的路障。
毕竟，当我的用户是一秒钟能处理几万 Token 的 AI 时，它们不需要 CSS，它们只需要准确的 JSON 和确定性的逻辑。
我们可能会需要很多 Service for Agents。
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 解决的是把意图落地为小而美的可运行草台方案，不是万能钥匙。
第一次写程序，不需要想架构有多优雅，先想我今天能把什么问题彻底解决。
把问题讲清楚，跑起来，验证结果。
这就足够好。
