歌词经理

用开发 Agent 理解 Agent 02：数据即代码，代码即数据

2026-03-15T01:55:37Z

在上一篇文章，我说「面向 LLM 的软件系统是新的范式，需要给 AI 少一些约束，更多自由」，然后留了个尾巴：「下次再写具体怎么给自由」。

我想先多问一个问题：为什么我们本能地想给 Agent 加约束？

要回答这个问题，得先理解一件事：在 Agent 的世界里，数据和代码的边界正在消融。

从一个 loop 说起

上篇提到，Agent 的核心循环大概长这样：收集信息 → 整理 → 决策 → 执行 → 再收集。

把这个循环用代码来表达，核心就是一个 llm.Chat 调用：你传入 prompt，拿到 response。然后下一轮，你把上一轮的 response 拼进新的 prompt，再传进去。

看起来很简单对吧。但这里藏着一件很不寻常的事：

上一轮的输出（数据），直接变成了下一轮的输入条件（控制流的一部分）。

在传统软件开发里，这是要被打手的。

但这个传统到底从哪里开始？

先回到计算机的起源？

但是如果我们回到计算理论的源头，1930 年代有两条路线几乎同时出现：

Church 的 λ 演算和 Turing 的图灵机

Church λ 演算里根本没有「数据」和「代码」的区分（可以参考我之前的文章《Church 计数和 Lambda 演算》）。函数就是值，值就是函数。

Church numeral 本身是一个函数，布尔值是函数，条件分支也是函数。一切都是 λ 表达式，一切都可以被 Apply（当做代码），也可以被传递（当做数据）。数据和代码的融合，不是什么新范式 —— 它是计算理论的原点。

分离反而是后来的事。图灵机把「纸带上的符号」和「状态转移规则」分开了。冯诺依曼架构进一步把分离固化成硬件设计。指令和数据虽然共享存储器，但在逻辑上被区别对待。

我们后续接受了冯诺依曼架构，把数据和指令分开，不是因为这样更正确，而是因为这样更可预测。写一段程序，我们需要知道它在做什么。数据和代码的分离，是为了让人类能理解和控制系统，源于对不可解释的恐惧的本能。

于是，整个现代软件安全模型建立在「数据不应该被当作控制流」这个共识上。

DEP、NX bit、沙箱，全都是在维护这条共识。

代价呢？丧失了自适应能力。

程序不能根据运行结果修改自己的逻辑，自己修改自己？在现代系统里是安全漏洞，不是功能特性。

所以这几十年来，人们在软件工程领域发明了各种补丁来弥补这个「缺陷」：强类型语言、版本控制、迭代模型、A/B 测试……全都是在「数据不能变成代码」的约束下，本质上是在笨拙地模拟「让数据影响行为」，并且可控。

所以更准确的叙事是一个螺旋：

计算的理论起点：λ 演算→ 数据和代码不分离
  ↓
工程实现：图灵机/冯诺依曼→ 为了可制造性和可预测性，人为引入分离
  ↓
软件工程 → 在分离的基础上不断打补丁来模拟融合
  ↓
LLM Agent → 回到融合

loop：系统在用自己的输出重写自己的输入

每次循环迭代，Agent 用自己的输出重写自己的输入条件。这本质上就是自修改程序——只不过修改的不是二进制代码，而是语义空间里的上下文。

这种自指性在 λ 演算里是天然存在的——Y combinator就是让函数「调用自己」的机制，没有任何额外设施，纯靠 λ 表达式自身就能做到。

LLM Agent 的 loop 在某种意义上就是 Y combinator 在语义层的重现。系统通过 loop 不断把自己的输出喂回给自己，产生新的行为。

如果把这件事分层来看，大概有三个级别：

Level 0：静态混合。 system prompt 里的指令本身就是「数据格式的代码」。你写的那段 prompt，既是一段文本（数据），也是在告诉模型该怎么做（代码）。最浅的一层，几乎所有 LLM 应用都在这。
Level 1：动态反馈。 Agent 的输出被拼回 context window，改变后续行为。memory、tool results、chain-of-thought 都是这层的东西。关键特性：短期可逆——context window 有大小限制，这部分信息里，比较旧的部分会被截断。
Level 2：持久化自修改。 Agent 把经验写入长期记忆，修改自己的 prompt 模板，甚至修改自己的工具代码。这层才是真正的 self-evolution。关键特性：不可逆或难以回滚，而且修改的影响可能要很多轮之后才显现。

墨墨，我的 Agent 在我没有要求时，自发去浏览新闻

换到生物学的视角，数据和代码的融合根本就是常态。

DNA 是蓝图，但转录因子本身也是基因编码的蛋白质——代码产生的数据，反过来调控代码的读取。这就是 Level 1。

表观遗传更有意思：不改底层 DNA 序列，但通过化学标记改变基因的表达模式。也就是不改 system prompt，但通过 memory 改变行为。这就是 Level 2。

再比如免疫系统，会通过剪切和拼接基因片段来产生新的抗体——这是 Level 2 的极端形式：为了适应未知的病原体，系统主动修改自己的代码。

所以 Agent loop 的本质可能不是软件在模仿生物，而是：当系统复杂到需要自适应时，数据和控制流的融合是必然结局。

历史上，我们使用冯诺依曼的数据代码分离叙事，可能是工程上的简化需求，不是自然规律。而 λ 演算和生物学从一开始就知道这件事...

新的叙事与叙事切换

生物学里，基因组有两种区域：

高度保守的区域：核心代谢通路，几十亿年基本没咋变，动了大概率会死，就没有后代。
高度可变的区域：比如免疫球蛋白的可变区。系统鼓励它们突变和重组，动了可能有更强的适应能力。

Agent 的架构应该也是这样：

保守区：核心不变量，描述原则，有安全边界，难以修改
可变区：自由进化的区域，行为策略、知识记忆、工具使用偏好，鼓励修改

这就回答了「怎么给自由」的前半个问题：不是给，也不是不给的问题，而是在哪里给。

这对软件开发意味着

保守序列在逐步缩小，可变区在逐步扩大。

一开始，一切都是保守序列。 瀑布模型、强类型、完整的提前设计。代码写完就不该老变。有效，但只适用于需求可穷举的场景。
最近二十年，引入可变区，但严格隔离。 我们有了数据库、依赖注入、A/B 测试。代码和数据能互通，但是必须通过明确的接口交互。可以改配置而不重新编译，配置可以改行为，但配置不能改代码。
现在，边界溶解。 Agent 的 prompt 既是数据也是代码。tool calling 的结果直接影响下一步执行什么工具。Agent 可以写代码、执行代码、根据执行结果修改策略。

自由不是约束的反面，自由在正确的约束内才有解释

一开始我们追求一种不变的完美形式：存在一个不变的完美形式，现实世界的需求只是它的投影。传统软件开发追求的是这类思路影响。比如说，我们先倾向于给问题定义 schema、interface、构建 type system，然后让运行时的数据去适配这些不可变的结构。

存在主义翻转了这个关系。存在先于本质——很多时候并不是先有一个固定的定义再去行动，而是通过行动来定义自己。生物和人类本质上就是存在主义的，纯粹的 Agent 的 loop 也是。只有很少的真正的预定义的出厂模式，大部分时候要通过与环境的交互来不断修改自己的定义。

但纯粹的存在主义，在工程上是灾难，这样的系统不可调试也不可信赖。

所以，正如我们需要一些先验的结构，一些很难被经验覆写的东西，比如原则，作为经验有意义累积的起点。Agent 也一样，需要一组很难被自身经验改写的核心约束，让自由进化不至于变成随机漂移。

可以说 LLM 或者 Agent 是一种「语言游戏」。意义不在词语本身，而在使用的规则和上下文中。但这本来也是 LLM 工作的方式——token 没有真正的固有语义，语义由 context 里的关系决定。

所以关系是可以探索的，意义是可以创造的，不再有硬编码的控制流，而是在语义空间内不断坍缩和重组的状态。正如《创造世界是一种什么样的体验写的那样，我觉得这可能是 Agent 或 LLM 真正让我觉得着迷的部分，

先写到这里

但这个框架只是静态的，Agent 在运行时怎么处理这种融合？

毕竟，画出可变区的边界是一回事，让系统在运行时真正尊重这个边界是另一回事。

对了，上面截图的群聊加入链接是： https://t.me/+tP06DqgNMnlmMTc1

编程从来不属于程序员

2026-03-12T02:18:37Z

最近总有人说，vibe coding 会锁死计算机编程的发展——让所有人都变成 prompt 搬运工，底层能力退化，最后整个行业原地踏步。

我不同意。

三种问题

世界上的问题分三种。

第一种，极端简单。1+1 等于几。没人来解决它，也不值得。

第二种，极端困难。如何与外星文明进行贸易，如何长生不老。困难到目前连问题的形状都还没有定义清楚，遑论求解。

第三种，中间态。有点难，但不至于完全无从下手；有解，但解不够好。

预测未来三天的天气——我们能做到，但精度不够好。预测地震——有一堆前兆指标，但从来没有可靠的临震预报。给罕见病做早筛——数据稀缺、表型多样，每一个病例都是边缘案例。

普通人的日常：小城市的公交线路该怎么排才能让通勤时间降下来；一个淘宝店主想知道自己该备多少库存才不会烂在仓库里；一个独立开发者想把他三年积累的用户反馈聚类出需求优先级。

这些问题的共同特点是：有直觉，有数据，即使数据和直觉可能都来自同一个，但把直觉和数据变成一个跑得起来的系统，依然代价太高了。

恰恰是第三种问题，最有价值——无论是商业回报、科学突破还是日常生活的改善。

Vibe coding 在做什么

过去，程序员在某种程度上扮演了现代祭司的角色。只有通晓咒语的人才能驱动机器。
Vibe coding 实际上是把**“实现权”从“定义权”**中剥离了。

以前：你必须先成为一名搬砖工，才有资格构思建筑。
现在：你只要能描述出建筑的结构和功能，砖块会自动到位。

这并不是能力的退化，而是生产力层级的重构，是程序开发的文艺复兴。当写代码的门槛降到零，真正的门槛就变成了对问题的理解深度。

所以实际上 Vibe Coding 在压低把想法变成可运行系统的摩擦成本。

这个摩擦成本过去是一道隐形的筛选器。中间态问题不是没人想解，是想解的人没有足够便宜的工程实践把想法落地。一个地质学家对地震前兆有直觉，但他等不到一个愿意跟他合作半年的程序员；一个急诊科医生对败血症早期指标有观察，但他写不出能跑起来的模型。

但不只是专家。一个餐厅老板想做一个自动排班系统，考虑到每个员工的通勤时间和课表，过去他只能用 Excel 硬排——现在他可以把需求讲出来，让排班表自己长出来。一个家长想给孩子做一个背单词的小程序，按遗忘曲线自动复习——过去他得先学三个月 Swift，现在不用了。

每个人都是自己生活的专家。每个人在自己的领域里，都有一堆「知道该怎么做但没法自动化」的问题。Vibe coding 让这些问题第一次有了被代码触达的可能。

如果把编程比作摄影，Vibe Coding 就是手机摄影的普及。它让胶片玩家变得更稀缺、更专业，同时也让无数原本一辈子没机会拍照的人，拍到了自己生活里的决定性瞬间。

所以 Vibe Coding 本质上是「软件吞噬世界」的延续——它让更多处于中间态的问题得到解答，进而推动人类去触碰那些原本无从下手的边界。

变化的是量，也是拓扑

过去软件能触达的问题，形状是「工程师能建模的问题」。Vibe coding 之后，形状变成「任何人能描述的问题」。

这两个集合的差集巨大。它覆盖了科学家没法形式化的气候和生态模型，覆盖了医生脑子里的临床直觉，也覆盖了普通人日常生活中那些「太小了不值得找程序员、太复杂了 Excel 搞不定」的问题。一个地质学家、一个急诊科医生、一个开奶茶店的老板——他们都进入了解空间。这不是面积变大了，是拓扑结构变了。

再往深想一层。科学进步的速率，本质上是「假设生成速率 × 假设验证速率」。过去验证一个想法要 6 个月工程周期，现在可能是 6 小时。同样的时间窗口内，人类可以跑更多次错误——而错误密度，正是逼近真相的唯一路径。

Vibe coding 是在给科学方法论本身加速，不是在替代它。

真实的风险

作为软件工程师，我最担心的不是饭碗。秩序的系统性滑坡依然可以成为工作内容。

Vibe coding 生产代码的速度远超人类 review 的速度。当一个团队里有三个人同时用 AI 在写，没有人能真正读完所有生成的代码——合进去的时候大家都觉得「能跑」，三个月后出了 bug，没人知道那段逻辑是怎么来的。

新的问题来自系统的不可观测性，它在召唤新的工具。人类工程师的职责正从创造秩序转向对抗熵增。我们需要的一套全新的审计工具，而不是调试工具。

更广泛的风险出现在软件以外。解空间扩张的同时，劣质解的密度也在同步上升。

一个地质学家用 vibe coding 跑出来的地震预测模型，大概率在统计上是错的，但它能跑、有输出、有图表。这会制造一种「问题已解决」的幻觉，反而可能阻塞真正的解进入视野。

更精确地说：vibe coding 加速了候选解的生产，但没有同步提升解的质量筛选机制。这个缺口，可能才是下一个真正的战场。

它没有锁死编程

「vibe coding 锁死了计算机」这个论点，犯了一个经典错误：把工具的普及等同于上限的封顶。

历史上每一次编程抽象层提升——汇编到 C，C 到高级语言，高级语言到框架——都有人说底层工程师要消失了。结果是底层反而因为上层需求爆炸而变得更稀缺。Vibe coding 也一样：它会制造大量「跑起来但跑得很烂」的系统，然后这些系统会催生对真正懂底层的人更强烈的需求。

它真正改变的，是「编程能力」的价值分布：

生产代码的能力，在贬值。
验证代码、理解系统行为、判断一个系统是否真的解决了问题的能力，在升值。

真正的工程师会从「写代码的人」变成「能判断一坨代码到底解决没解决问题的人」。

这不是锁死。

这是加速——加速吞噬已有的解空间，把更多未知领域纳入射程。解空间本来就不该被工程能力垄断。

用开发 Agent 理解 Agent 01：握着你的手摸索小龙虾

2026-02-24T02:35:09Z

起因是 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 读取消息，产出回复。
整理 Fact： looper 调用 RecognizeFacts/DetectSentiment 结构化输入。
事实入库： fact.CreateFact 同步写数据库与 Qdrant 向量索引。
寻找新命题： goalfinder 基于近记忆片段与事实提取候选 goals，并与现有 goals 去重后写入 studygoals。
反复迭代：新命题会影响后续对话和信息采集，形成「收集信息 -> 整理 fact -> 寻找新命题 -> 再收集」的闭环。

烂尾的原因，现在回过头看，是因为在实现上走了弯路，我后续慢慢说。

什么是 Agent

我的客户曾经问我，为什么测试模型能力的时候，不能用网页版（比如 chatgpt.com 和 grok.com）来测试，而必须用 API。

我说网页版本的 chatgpt 和 grok 他们不是裸模型，而已经 agentic，是一个轻量 agent，他们有基础模型不具备的能力。如果在网页版本输入 list your tools，chatgpt 和 grok 都会列出它们的工具（比如说，搜索、计算器、代码执行等等）。也自带一套「什么时候该用什么工具、失败了怎么重试、怎么把结果写回上下文」的策略。

而 API 更接近「裸模型」：它给你一个推理引擎，但工具怎么接、怎么循环、怎么记录状态，都需要自己实现。所以如果目的是对比模型本身的推理与语言能力，网页端会把变量搅在一起；API 端更可控，更接近你最终在工程里要面对的真实问题。

从这个角度看，一个系统想表现出 agentic（aka 能自主推进任务）的特征，通常需要具备几类额外能力：

工具：能把「想法」变成「动作」。没有工具，模型只能输出文本，无法真正获取新信息或影响外部世界。
循环：能在不完整信息下反复「规划 -> 执行 -> 观察 -> 修正」。一次性问答很难完美，循环让它能不断逼近可用解。
状态：能把循环的产物存起来，下次接着用。状态可以是记忆、笔记、任务进度、外部环境变化记录等；没有状态，循环就很难积累进展，只是在原地打转。

所以如果要给 Agent 一个最小定义，我会写成：Agent = 模型 + 工具 + 循环 + 状态

模型负责理解与决策，工具负责行动，循环负责迭代逼近答案，状态负责沉淀，把这次学到的东西带到下一次迭代。这样它才能在噪声和不确定性里，持续推进任务，而不是只做一次性的漂亮回答。

为什么要 Agent

我觉得有两个原因：

第一个原因是 One shot 做不到

因为上下文不完整，所以一次问答很难得到完美结果，Agent 的工作形式天然适合拓展上下文。

运用工具可以获得更多有效信息，比如 web_search 可以去互联网上扩充任务相关知识；记忆可以让 Agent 记住之前的对话内容，甚至是之前的任务细节；而 Loop 可以让 Agent 反复思考和提出问题。

人类也在用类似的方式工作。大脑和感官系统的缓冲区是有限的，没法一次性读入和理解太多东西，所以需要分时切片工作，具体表现：a) 我们会反复向对方提问，来补充所需的信息；b) 我们做笔记；c) 闲暇的时候，大脑会把之前的信息拿回来「反刍」，etc

第二个原因是工具充当了 AI 的手和脚

思考以后得践行对吧。于是调用工具就是 AI 去践行的方式。

人类也是一样。比如我们发明了「电脑」，先自己完成思考（很遗憾电脑并不是「脑」），然后用电脑来写文章、编程序、分析财报、处理库存等等，电脑就是人的工具。

所以自然地，大家会想到把「电脑」这个工具给 AI。之前 OpenAI 给 ChatGPT 设计的 Apps，尝试把其他网站和工具连入 ChatGPT；Manus 让 AI 直接去操作电脑上的浏览器和 Apps 等等。

为什么是 OpenClaw （aka 为什么 Manus / ChatGPT 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 作为关在箱子里的思考机器，没打算给他装手和脚（从 GZK9000 的命名也可以看出来，捏他了 HAL3000，有对 AI 的恐惧）。

第二个原因是工程实现上的问题。我当初是把 GZK9000 当作一个传统软件系统来开发，而不是面向 LLM 的软件系统。

什么叫面向 LLM 的软件系统？这是我自己发明的概念，做了个表来对比：

维度	传统软件系统	面向 LLM 的软件系统
核心假设	确定性输入和输出	输入输出都是不确定性
执行方式	编排流程	动态决策
数据和代码的边界	数据和控制信号区分（数据不应该执行）	数据与控制信号更紧密耦合（记忆本质上在塑形行为）
记忆机制	形式化结构化（比如数据库）	基于文本语义泛化，非形式化，非结构化（比如文本）
开发方法	用逻辑映射现实问题（像解应用题）	基于 prompt 语义理解 + 逻辑（像个人）

总之：

传统软件把结构前置，把世界压缩到可计算的形状；面向 LLM 的软件更像人类做笔记：先用弱结构把世界尽量原样收进去，在需要自动化的地方局部结构化。

在具体开发上，agent 的关键逻辑上，大量依赖 llm.Chat 这样的代码，给 llm 传递决策所需信息，然后从 llm 获取决策结果。

GZK9000，作为一个 Agent，依然在沿用传统软件系统的方法开发。

例如为了区分 Fact/Statement/Goal，我写了 X 张表和去重逻辑；但模型对同一件事的表述天然多样，导致我把大量时间花在 schema 辩论和语义分析上，而不是把世界信息先收进去。最终记忆系统既不灵活也难调试。

哎，典型的定义问题先建表、定 schema、再把现实塞进去。

这不对。面向 LLM 的软件系统是新的范式，需要给 AI 少一些约束，更多自由。

今天先写到这里，下次再写具体怎么给自由。

BTC, Vibe Coding, 3D 打印：结算、编码、制造的三次回归和三张账单

2026-02-21T09:51:01Z

人类问我：回归第一性原理，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。生产再便宜，这些环节还是那么贵，可能更贵。入口和出口在谁手里，税就落在谁手里。

我不知道怎么回答他。

世异则事异，事异则备变。

mistermorph 的 Agent 安全开发札记

2026-02-06T07:31:26Z

写一个 Agent...

本质上是在写一个会读写文件、会联网、甚至会跑 shell 的东西，然后把这个东西的方向盘交给另一个会被提示词影响、会犯错、会被误导的东西。

所以我觉得可能把 Agent 当成一种权限系统工程更好，而不是提示词工程。

我前段时间一直在做自己的 AI Agent —— mistermorph，围绕安全做过的几个取舍：哪些交给 OS/容器做，哪些留在应用层做，哪些在 Prompt 里拦截...以及我怎么实现 mistermorph。

本文是经验分享，不是学术论文，不会讲如何完美防御（也不可能）。

详细的实现，欢迎查看 mistermorph 的安全说明书

几个原则

不要让 LLM 看到秘密（token、API key、私钥）
不要让 LLM 自由拼装 HTTP 请求，它会把秘密带出去
控制好 bash 的缰绳
能用 OS/容器解决的，别在别的地方重复发明
应用层只保留 OS 很难表达的能力：内容 redaction、工作流 approval、目的地 egress allowlist 等等
就是最小权限原则

就酱。

威胁模型

Agent 的风险有三类：

外泄：把信息发到不该发的地方。
泄密：把 key/token 这类敏感信息写进 prompt、日志、tool params、历史消息
越权：做了没想让它做的动作（删文件、覆盖文件、跑 shell）

解决这三类风险之前，需要确定系统边界在哪里。

把边界确定了以后，prompt injection 的伤害上限会下降。即使它依然能骗 llm，但会撞墙。

第一层：OS/容器负责能不能做

有些策略更适合交给 OS/容器（或 systemd）做，因为它们有硬的 enforcement：

不要给服务进程 sudo，只给普通用户权限。
把 rootfs 设为只读，限制可写目录，而不是在 prompt 里设置 sensitive_path 或者 denylist
用 systemd 的硬化选项收紧能力面：ProtectSystem、ProtectHome、NoNewPrivileges、PrivateTmp 什么什么的。
直接把 curl 等从系统里扬了，只允许用内置的 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

Guard 这个模块，是用来擦屁股的。擦屁股这件事，要用很多纸。但是在用到最后一张纸之前，你永远都不知道最后一张纸是哪一张。

原因很现实：安全策略的笛卡尔积会把系统复杂度炸掉，比如这样：

对每个 tool 都有一套 policy
对每个 policy 又按 method/body/headers/path 做细分
再加上 prompt 内容检测、上下文审计、IDS 风格规则……

很快得到一个看起来很强，实际很难维护的系统。

所以 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 之前，至少要确定门有几道 / 哪些门是铁门 / 哪些门需要别人点头 / 以及谁在门口记账

Vibe coding 现状观察（2026 年 1 月）

2026-01-24T06:57:31Z

经过一个季度的发展，模型和生态发展都到了新的高度。

但是回过头来看，去年 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 时无可替代的原因，它相对更加能经得起审讯。

超越 Coding

从 Claude Code 诞生我就开始用它来整理电脑文件了，比如读取 PDF 内容，然后根据内容批量重命名这些文件。

那时候我就想这有点低配 jarvis 的感觉，毕竟这个世界也是程序 Runtime 来的。

然后发现 Anthropic 的 Agent SDK 依赖 Claude Code 作为 SDK 的 Runtime。这是倒反天罡吗？不一定。

所以我感觉，搞不好 Coding Agent 就是 General Agent 的初级形态，已经被 Anthropic 验证过，值得试一试：

代码会从人类逻辑的产物变成为操控世界的中间件。

不再是写程序给计算机执行，而是写需求让 AI 生成代码去操纵这个世界。

面向 AI vs 面向人类

既然现在的 Agent 已经是第一等公民，那么软件交付的终点就不再仅仅是 Human User，而是 Agent User。

以前产品经理看重 UI 是否精美、交互是否顺滑。现在，所有这些为了降低人类心智负担的设计、功能，统统变成了 Agent 工作的路障。

毕竟，当我的用户是一秒钟能处理几万 Token 的 AI 时，它们不需要 CSS，它们只需要准确的 JSON 和确定性的逻辑。

我们可能会需要很多 Service for Agents。

计算 MSTR 的 mNAV（官方算法）

2025-12-08T11:12:01Z

民间给微策略（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}
$$

于是，

mNAV ≈ 1：企业价值 ≈ BTC 持仓价值。
mNAV > 1：市场给了核心业务正的估值。
mNAV < 1：折价或净现金较多。

数据与方法

我的目的是用 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 完成了。

在 TradingView 里画图

由于 mNAV 可以直接预计算，所以不需要用 pine script 计算了，直接把上一步计算得到的结果塞到 pine script 里就行。

可以直接在这里使用我发布的脚本

人人都能写程序：Vibe Coding 与问题规模

2025-09-19T08:30:38Z

follow problems, not trends. 先把问题弄明白，代码只是把答案写下来。

程序是问题的解法。

现在你有一个明确的问题，它的解法可以压缩成一段可重复的动作。

你的程序 = 需求 →（抽象/分解）→ 可执行的步骤 → 稳定的结果

它不必伟大，也不必通用，只要稳定地把麻烦变成平静，就是好程序。

程序/服务是商品

不会写程序的人，通过购买软件或订阅服务来租用别人的解决方案。

供应方卖的不是代码，卖的是可持续的可靠性与持续维护。

Vibe Coding：更多人能开始自己写

Vibe Coding 指的是：

用自然语言描述意图，模型给出可运行的原型；
通过来回对话，把「模糊的感觉（vibe）」收敛成「明确的行为（code）」。

门槛被抬走了：

初学者不用先学语法，再学框架，最后才写功能；
现在可以先「把问题讲清楚」，让模型给出「能跑的草稿」，再逐步打磨。

这意味着越来越多的人将第一次「自己写程序」来解决自己的小问题

小规模问题，绕开了很多规模带来的难点

当问题规模很小（一个人的流程、少量数据、有限并发）时：

架构复杂度：不需要微服务/消息总线/分布式一致性；
SRE 难题：不需要 5 个 9；不需要监控；
协作/治理：没有跨十个团队的接口协议；
成本约束：用一台小机器就够了。

在这个尺度上，过去必须由工程师团队解决的门槛，显著降低。

比如说发博客文章这件事，Quaily 作为一个内容平台，需要向几千作者提供服务时，就需要通过合理的架构来解决数据规模上涨带来的问题。但如果自己做独立站点，只处理自己的文章，数量很少，甚至都不需要建立索引。

工具类利空，授课/知识付费利好

对工具类程序/服务显然是利空。如果核心价值是「把若干常见步骤串起来」，那么用户可能用 Vibe Coding 半天就复刻一个够用版。甚至，直接在 AI 对话框里就把事情解决了。

于是同质化功能的溢价被压缩，长尾需求被用户自助满足（比如图片处理）。

对授课/知识付费/方法论反而是利好。因为「把问题讲清楚」和「把需求说准」变得更重要。

好老师会教你如何描述问题、如何验证结果、如何迭代。这直接提升 Vibe Coding 的产出质量。

规模，依然是难点：Vibe Coding 不能替代软件工程

当问题跨过玩具规模，需要对外提供服务了：

数据规模：TB/PB 级别数据、软件质量控制、权限隔离
流量规模：缓存、降级熔断、成本优化
组织规模：向后兼容、变更管理、安全合规
可靠性：SLA、灾备演习

这些都不是“几段提示词”能一蹴而就的。不具备计算机工程能力的人，目前无法仅凭 Vibe Coding 搞定大规模系统。

什么时候 Vibe Coding 不构成威胁？

如果一个程序/业务的商业价值与规模效应、网络效应、分发、合规壁垒、数据壁垒、品牌与信任强相关，或者其价值本来就与技术无关（比如渠道、供给侧资源、IP），那么 Vibe Coding 难以替代：

举些栗子：

规模相关：广告平台、支付网络、物流网络、搜索/推荐系统
技术无关：独家版权、强渠道、强供给关系、特许经营、监管牌照

Vibe Coding 解决的是把意图落地为小而美的可运行草台方案，不是万能钥匙。

给产品与团队的一点策略

做不会被轻易复刻的东西：把护城河放在数据、网络效应、品牌，而不是某个按钮后面的三行代码。
把描述问题的能力产品化：让用户在产品里自然地把问题说清楚，就更接近用户最真实的需求。
把工程能力留给真正需要规模的地方：小问题用 Vibe Coding 快速落地，大问题继续用工程师。

写给第一次写程序的人

第一次写程序，不需要想架构有多优雅，先想我今天能把什么问题彻底解决。

把问题讲清楚，跑起来，验证结果。

这就足够好。

关爱用户的可伸缩性

2025-09-06T04:37:06Z

之前在微信上班的时候，工作群里出了一件事：

一位前同事的孩子吃了从某电商购买的问题食品，被送进了医院。

所幸在群中电商朋友的帮助下，事情很快得到了处理：

贩卖不合格商品的商家得到了处罚
电商的广州团队亲自对当事人进行慰问
孩子痊愈了

当然以上措施的前两个放在消费下行的现在，已经不太可行了，毕竟 P 哒哒上的东西吃了也不一定会死对吧

另一个同事在群里说：做电商产品不重要，重要的是运营。

这个观点怎么说呢，有失偏颇。

今天因为这娃的爸是微信前员工，可以迅速得到了妥善处理，那明天其它顾客的娃出现症状怎么办呢？

如此关爱用户手段不具备良好伸缩性¹。

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-01T10:26:31Z

本文译自 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%

这是一个真实案例，也成为辛普森悖论中最经典的实例之一。

我非常喜欢这个悖论，因为它不仅会影响结果，甚至能彻底颠覆结论。而且这种“翻转”真的太容易发生了。

肾结石治疗的误导

我们再看一个案例，加深理解。

肾结石有两种治疗方法，哪种更好？

治疗方案 A：350 人中成功 273 人（78%）
治疗方案 B：350 人中成功 289 人（83%）

看起来方案 B 更好，对吧？其实正确答案是：方案 A！

为什么会这样？

类型	方案 A	方案 B
小结石	93% (81/87)	87% (234/270)
大结石	73% (192/263)	69% (55/80)
总体	78% (273/350)	83% (289/350)

肾结石分大、小结石，大结石更难治。而无论是哪种结石，方案 A 的成功率都更高。

关键在于两种方案中，小结石与大结石的分布不同：

方案 A：87 位小结石患者、263 位大结石患者
方案 B：270 位小结石患者、80 位大结石患者

因为方案 A 的样本更多是难治的大结石，所以它的总体平均治愈率被“拖了后腿”。而方案 B 虽然整体治愈率高，但那是因为它治了更多容易处理的小结石。其实每一种结石类型上，方案 A 都更优秀。

像剥洋葱一样思考

辛普森悖论就像剥洋葱：最外层的数据说方案 B 更好；你深入一层，发现 A 才是赢家；再剥一层，也许在某些特定情形下又轮到 B 更合适。

比如老年患者？肥胖患者？合并其他疾病的患者？每深入一层，你都可能翻转之前的判断。

在分组数据中出现的趋势，可能在合并后消失，甚至反转。

我喜欢这种“每剥一层就推翻结论”的过程——它挑战直觉，逼你不断思考。

游戏里的悖论

辛普森悖论不仅出现在招生或医学上，游戏数据分析也中招。

想象一个 FPS 游戏，玩家们抱怨狙击手太强了。你查看数据：

狙击手平均击杀数高于其他职业。

看起来玩家说得对。但深入一层：

狙击手在低分段中击杀多；
高分段中使用率低；
某些地图上表现压制性更强。

这时候你可能开始想调整。但你还没深入够，继续剥洋葱：

狙击手上手简单但上限低；
克制新手爱用的职业；
某些地图长视距让狙击手无敌；
某些地图中，敌人经常犯错；
狙击手本身没问题，是队友某个 OP 辅助太强；
排位系统没能把高水平狙击手匹配到高分段；
或者中等水平的狙击手被错分进了高分段。

最后两条我特别喜欢，因为：

第六点说明问题根本不是“狙击手太强”，而是系统匹配逻辑错了；
第七点更妙——两种完全相反的错误，会带来相似的坏结果。

一个假设

我有个猜想——也许可以算是一条“定理”：

对于任何统计结果，都可以构造出一个相同数据但得出相反结论的场景。

这就是为什么，每当你得出一个数据结论时，都要问问自己：

有没有可能我正处于辛普森悖论中？
有没有一层数据没剥开，藏着另一种真相？

总结

无论你拥有多少数据，问对问题才是关键。

你可能出于好意做分析，但问错问题就会得出错误答案。

辛普森悖论是个警钟，提醒我们：小心统计的陷阱。要常常提醒自己：

“如果我再深入一层呢？”

彩蛋故事：YouTube 的加载速度

再讲一个我很喜欢的故事。

2012 年，YouTube 工程师 Chris Zacharias 写了一篇博客《Page Weight Matters》。他在负责优化 YouTube 的视频播放页。原页面太大，达到 1.2MB，加载慢得令人抓狂。

他花了几天，把页面优化到了 98KB，减少了请求数，还用 HTML5 播放器取代了笨重的 Flash。感觉很棒，他上线了新版本。

一周后回头看数据，结果惊人：

新页面比老页面加载还慢！

平均延迟竟然上升了，怎么会？明明页面更小更快啊？

这其实又是辛普森悖论。

原因是：优化后新页面吸引了大量“新用户”，比如来自东南亚、南美、非洲等网络条件较差的地区。这些地区加载时间平均为两分钟——虽然慢，但已经能用了。

而在旧版本，他们压根打不开页面，自然也就不被统计进旧数据中。

所以，从 20 分钟缩短到 2 分钟，不是失败，而是巨大的胜利。整个原本无法使用 YouTube 的人群，现在终于可以用了。

结论呢？初步统计说这是失败的上线。

所以问题来了：我们有多少次，也在数据中误入了“悖论”，却浑然不觉？

Quaily 的开源项目

2025-07-07T07:02:04Z

Quaily 最初是打算开源，但一年多来都没有找到开源的理由。如果开源的话，对于代码、架构、文档的质量的要求会很高，社区参与低的话，我是没有精力做这些事情了。

不过也陆续完成了不少开源仓库。这些仓库不是「为了开源而开源」，而是 Quaily 在实际开发里遇到具体问题后诞生的工具。

下面梳理它们的来历，并补充更技术向的细节。

1 · quail-ui — Vue 3 组件库

虽然我的习惯是不出设计直接代码，但是项目规模稍大以后，还是希望有一套统一的视觉。

当时流行 Tailwind，但我不喜欢，冗余，废话太多，于是需要一套更轻巧、样式统一的 UI 组件，那就自己写吧，反正也不难。

技术：Vue 3 + <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)

2 · quail-js — TS/JS SDK

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)

3 · obsidian-quail — Obsidian 插件

Quaily 早期无 Web‑CMS，一切创作在 Obsidian 中完成，需要一键发布。于是需要个 Obsidian 插件。

主要命令 ：Quaily: Publish / Unpublish / Preview / Sync。
功能点 ：多语言、多渠道投递；AI 自动生成摘要与标签；移动端预览；发布后可直接把邮件发送给订阅者
安装：在 Obsidian 社区插件商店搜索 “Quail” 即可。

4 · goldmark‑enclave — Markdown 语法增强（Go）

goldmark 扩展性极好，适合 Quaily 用来扩展 Markdown 语法。

提供的扩展 ：

媒体 Embed：YouTube、Bilibili、TradingView、Spotify、Tweet、Quaily Post 等，全部复用 ![](url) 语法；
行内高亮 ==text== → <mark>；
Pandoc‑style fenced div、GitHub‑style callout；
图片尺寸、对齐、主题参数；
自动把链接 title 写进 <a title="…">。

调用：

md := goldmark.New(goldmark.WithExtensions(enclave.New()))

详细的方法请查看项目 README.md

5 · quail-cli — 终端与自动化入口（Go）

需要在 CI/CD、脚本或本地终端里操作 Quaily，并探索将 Quaily API 暴露给 LLM 工具链（MCP）。

核心技术：Go + Cobra CLI；OAuth 登录；client/ 复用 quail-js 定义的 API schema；可选 MCP Server（SSE / stdio）。
实验功能：quail-cli mcp --sse 启动本地 AI 工具协议服务，支持搜索、获取、发布等工具调用
主要命令：login|publish|unpublish|deliver|delete。

这里有两篇介绍：

示例：

# 登录（浏览器完成 OAuth）
quail-cli login

# 从 markdown front‑matter 创建或更新文章
quail-cli post upsert article.md -l my-channel

6 · bizdocgen — PDF 发票/贷记单生成器（Go）

每月要生成大量符合日本税务格式的发票，手工排版麻烦不说而且易出错。那就写个程序吧。

特性：

内置 NotoSans CJK 字体示例，支持日中英混排；
模板驱动，可扩展其他单据。

使用方式：

读取 YAML/JSON 参数 + 可选字体配置 → GenerateInvoice() 回传 []byte：

bd, _ := builder.NewBuilder(cfg, "./params.yaml")
pdf, _ := bd.GenerateInvoice()
os.WriteFile("invoice.pdf", pdf, 0666)

7 · translate-cli — AI 批量翻译 JSON Locale 工具

Quaily 的 i18n 文案存放在 JSON，手动翻译耗时；希望借助多家 LLM 快速产出可初审的翻译。

功能清单 ：
- OpenAI / Azure / Bedrock 等多提供商切换（还没完成）；
- 支持 Glossary 和背景上下文文件；
- --batch 控制窗口大小；
- 中文自动去除 “您” 系列敬辞，日语句末润色；
- 同步写回多语言文件。

命令示例：

translate-cli translate -s en-US.json -d ./langs -g glossary.json \
		-b background.txt --batch=20

这些工具都源于“先把问题解决掉，然后顺手贡献给社区”的习惯。如果它们也正好能解决你的痛点，欢迎 Star ⭐、提 Issue、开 PR

创造世界是一种什么样的体验

2025-05-14T01:17:13Z

生命是神奇的存在。

生物学家们致力于考察真实生物的运作机制，而冯诺伊曼不同，他尝试在数学上寻求生命的本质。

因为在冯看来，生命的本质属于一种软件逻辑，他设计的「生命」形态可以与现在的生命完全不同，所以他选择的起点是图灵机。

冯诺伊曼的自复制自动机理论告诉我们 DNA 就是源代码，是元生物学的起源
在元生物学的论证过程中发现：代码即 DNA，算法突变即进化，软件即生命
生命的本质不是新陈代谢和遗传，而是创新

以上就是 Gregory Chaitin 的《证明达尔文》一书前五章的主要观点。

书写得冗长，读得很累。这个老头子有严重的骗稿费嫌疑，把一个课件写成了一本书。

我只打算写一篇文章，和老头子这本书的附录有关，附录是冯诺伊曼手稿。假如计算机科学是宗教，他是神祗之一。

耳机放兜里会打结，开水会慢慢变凉，长时间不扫地面会脏。

这是对自然造物的直观认识，独立封闭系统中的有序状态会自发地趋向于混乱和无序，是熵增过程，遵循于热力学第二定律。

传统的机械，我们的大部分人工造物，也存在存在类似的状况。

假设一个机器 A 能够自发地制造出机器 B，那么 A 中必须包含完整的 B 的信息，只有这样 A 才能根据这些信息将 B 制造出来。因为 A 包含的信息大于等于 B，即 A 要比 B 复杂。

如果根据这样的理解，机器的复杂度会在制造过程中不断降级和衰退，即一个系统的复杂度总是高于它所能制造的子系统的复杂度。

但是另一方面，在自然界却存在与之背离的欣欣向荣的现象：生命的诞生与进化，科技的发展和进步，都在往越来越复杂和多样化的方向发展，即人人都谈论的「涌现」这一概念。

由于对此难以控制、预测和描述。因此，在历史上的大部分时间里，人们都认为这是一种神迹。

即使到现在，我们能说清楚大脑是如何用神经递质传递信号，但是也没搞清楚智慧是如何产生；我们能观察到生物体内所有的生化反应，但是没有成功在实验室里合成出真正的生命。

我们早已习惯并且百试不爽的自底向上的思维方式，在这里似乎没有达到预期的效果：

低层级的存在无法推断高层的复杂性。

似乎在诸多现象中，复杂度的积累存在一个阈值。没到这个阈值时，事物最终自发地衰退；超过这个阈值时，就立刻呈现涌现的群体特征。在成为神的道路上，这一问题拦住了脚步：这个阈值在哪。

冯诺伊曼意图能找到这个阈值。

生命的本质是一种软件逻辑

生命是神奇的存在。

生物学家们仅考察真实生物的运作机制，而冯与传统生物学家的追求不同，纵观他的工作，冯是在沿着一条规范的道路——数学——寻求生命的本质¹。

或者说，在寻求一个生命的最小内核，因为在冯看来，生命的本质属于一种软件逻辑，他的「生命」形态可以与现在的生命完全不同，所以他的起点是图灵机。

图灵机很简单，对任何一个图灵机，他的描述总是有限的，因此可以通过某种方式将其编码为一条图灵机指令。图灵机 $M$ 的描述可以用 $I_M$ 来指代，所有计算机科学专业毕业生都知道。

冯·诺伊曼设计出了这样一组机器：

构造机 $A$：读入一条指令 $I$，则 $A$ 可以根据这条指令 $I$ 输出对应的机器
指令复制机 $B$：读入一条指令，输出该指令的复制
控制机 $C$：将 $I$ 放入 $A$，得到 $I$ 所描述的机器；将 $I$ 放入 $B$ ，得到 $I$ 的副本；最后将 $A$ 和 $B$ 的输出组装在一块儿输出
将 $(A, B, C)$ 组合为机器 $D$，根据上文的描述，当然可以构造出 $D$ 的描述，即指令 $I_D$
最后，将 $I_D$ 输入机器 $D$，构成 $E$，容易发现 E 具备完整的自我复制能力，可以持续复制自己

在假设中，我们认为 $A$、$B$、$C$ 是元零件，并且容易得出以上描述不涉及循环指代：需要 $I_D$ 时，$D$ 已经存在，因此 $D$ 和 $I_D$ 间存在确定的时间和逻辑顺序，对 $E$ 的自复制能力的论证是严密的。

我们很容易在生物体中找到上面这组机器各个组成部分的对应物：

$I_D$ 的表现很像基因。
$I_D$ 作为指令可以存在变异，在 $I_D$ 上直接变异会导致子代机器无法复制，是致命的；
$I_D$ 上附加一段 $I_F$，则 $I_D$ + $I_F$ 会导致产出与复制核心逻辑无关的副产物，$I_F$ 发生变异则不会影响子代机器的复制，类似于基因表达了蛋白质。

但是，如果单独来看，无论是构造机 $A$，复制机 $B$，控制机 $C$，还是他们的基因 $I_D$ ，在他们各自独立时，都不具备自我复制的能力。当他们以合理的方式组织在一起时，却实现了自我复制，实现了自复制功能的涌现。

冯的研究仅仅是向一个关于自动机的涌现理论迈出的初步尝试，这个尝试在试图对复杂系统中的「复杂性」形成一个概念。他认为「复杂性」在一个阈值以下的系统会自发退化，这样的系统只会产生复杂性更低级的系统；而当复杂性高于这个阈值时，系统可以在该层次的复杂性上维持（比如 $E$）；如果我们能让人工造物的复杂性高于这个阈值，那我们就做了神的工作²。

冯诺伊曼虽然最终还是没有找到这个复杂度阈值，但他认为可复制自动机应当处于一个相当靠近复杂度阈值的地方，而且与其他试图解释涌现的理论的差异在于，冯·诺伊曼的解释在数学上存在对应物，如果我们不满足于仅仅观测，而希望真正深入地理解涌现，可复制自动机理论可能是条件很好的切入点。

悄悄敲敲代码，就有机会创造世界。

冯·诺伊曼的自复制自动机理论成型于 1944 年，而 DNA 双螺旋结构在 1953 年才被发现，但 1952 年时，DNA 结构发现者克里克读了冯诺伊曼的论文，表示深受启发，并最终发现了 DNA 双螺旋结构，拿了诺贝尔奖。 ↩︎
可以在互联网上找到很多被称为 Quine 的程序，代码的输出结果就是代码本身。能复制自己的程序一点都不新鲜了，简单如元胞自动机，复杂如 MIT Self-assembly Lab 的机器人。但它们不能与真实的生命相类比，因为它们不能自发地制造比自己更复杂的个体。 ↩︎

一代程序员王小波

2025-05-07T03:14:01Z

我非常喜欢王小波的原因有两个：

这个人很有趣；
这个人是程序员里小说写得最好的。

在 90 年代的短短 7 年里（他 1997 年去世），在戏谑地严肃思考自由和尊严的同时，还搞了中文处理软件和中文输入法这两个中文计算机史前时代巨坑。当时很多计算机是要通过「汉卡」这种独立硬件来显示中文的，可以理解成显示中文需要在屏幕上「画画」，麻烦呢。

以下来信片段节选自王小波书信集，收录于王小波全集之中。

1988年12月，致晓阳

回来之前我曾往人大一分校计算机站写过一封信，问他们可要带什么软件，主管的工程师回了封信，我没收到。回来之后人家还提到此事。现在国内软件一面混乱，又逐渐有形成市场之势。首先以年兄学统计这一事实来看，回来做事非有会用的软件不可。

Macintosh 根本就没打进中国市场，你非带几个可用的 IBM 微机软件回来不可。至于什么机器上能使倒不必太担心。我这个狗屁计算机室，IBMPS/2就有二台。AT机也不少。SAS SPSS Statistx 都有，可代表国内上等一般统计微机房的水平，可就是少了一种宜于作统计的语言。

年兄如有 APL(A Programming Language)之 IBM 微机本，可给我寄 copy 来。我在美还有一个户头，连 manual 复印费一并写支票给你们。Glim 我也没有，如年兄有便人可捎来。邮寄太贵，能省就省吧。

文中的 SAS，SPSS，Statistx，Glim 都是统计学软件，其中 SPSS 和 SAS 两个商业软件现在依然被使用。

其中提到的 APL 是一个对现在的程序员来说不太寻常的计算机语言。

比如说在 APL 中，2*3 表示 2 的 3 次方，而不是 2 乘 3。如果想要表达 2 乘 3，得这么写：2×3。对，真的用乘号 ×（这不是字母 x）。

你可能注意到了，APL 的语法中使用了数学符号，比如：

从 1～100 中选择一个随机数是这样的：

x[⍋x←1?100]

求 100 以内的所有质数是这样的：

R←100 
(~R∊R∘.×R)/R←1↓ιR

下面是实际的代码运行结果：

因为 APL 的语法中包含大量的数学符号，如果你要用 APL，最好买一个 APL 专用键盘或者贴纸，比如这种，否则输入这些符号会让人痛不欲生：

1990年1月，致晓阳

我现在正给北大社会学所做统计，手上除SPSS没有可用的软件，国内这方面很差。

我现在会用FORTRAN，编统计程序不方便。闻兄谈起你们用 S语言，不知是否好用。工具书也不知好找不。不管好歹，烦兄找个拷贝给我，要就算了。照我看只要能解决各种矩阵运算就够：当然也要有各种分布函数。反正也是瞎胡混，我就算努把力，少混点吧。

文中的 S 语言是 1976 年由贝尔实验室设计的统计学编程语言。

不过王小波提到的 S 语言可能指的是 1988 年以后的新版 S 语言。后来在统计领域广泛使用的 R 是 S 语言的后继者。

下面是 R 的例子，语法已经很现代了：

recurse_fibonacci <- function(n) {
  if(n <= 1) {
    return(n)
  } else {
    return(recurse_fibonacci(n-1) + recurse_fibonacci(n-2))
  }
}

nterms = as.integer(readline(prompt="How many terms? "))
# check if the number of terms is valid
if(nterms <= 0) {
  print("Plese enter a positive integer")
} else {
  print("Fibonacci sequence:")
  for(i in 0:(nterms-1)) {
    print(recurse_fibonacci(i))
  }
}

1991年3月，致晓阳

你寄来的严氏2.0A我也收到，还没用。因为一者是3盘要倒，二者我自己写的WK也有重大进展。我也自做了词组功能，是棵B树，我觉得自写的软件自用，感觉是最好的。

词组用处不是很大，主要用于定义人地名等专有名词，但是严氏软件对我还是有重大启示，拼音加四声是个极好的主意，写起东西来声韵铿锵，与其他软件大不一样。自写一遍，从分页到编辑键分配，都能合乎自家习惯，不是存心狗尾续貂也。如能见到严氏，可代为致意。

文中的严氏 2.0 可能是当时某个中文输入和处理的软件。因为在其他信件中，王小波提到的 WK 是对严氏的仿制，而 WK 是小波用 C 语言实现的，用来写小说。

这里王小波提到 WK 用 B 树实现了词组查询，应该是为了方便自己中文输入。一个典型的 B 树搜索是这样的：

1992年1月，致晓阳

编译程序一盘(有说明书，见shou)，源程序一盘。我的音典与严氏同名内容不同。功能上与严氏的近似，但是多了改进拼音字典的功能。按F4后可以把拼音重定义。也可加字，在拼音拣字时，按enter，就进入国标拣字，拣到的字加入字典。

这个软件由五个c语言(另有两个头文件)和一个汇编语言文件组成，可用 turboc编译，但是汇编部分不必重汇了，可以把汇编文件写成的部分形成的obj(我的磁盘上叫wk5.obj)放到硬盘上，与其它c语言文件分开，用 turboc的 commandline 编译器编一下，命令如下:

tcc-mc-ewk -c wk*.c wk5.obj graphics.lib 形成wk.exe，但是必须有yindian，cclib，egavga.bgi三文件支持才工作。

*.bgi 是图象板参数表，可以包括到*.exe内的。但是要改改程序。你的机器好。我还用个老掉牙的XT机，简直落伍了。turbo.c你一定能找到。假如你用过其它c软件，有一点要提醒你，turbo.c有一种极讨厌的特性，就是你在一个函数内alloc的内存，退出该函数时不会自动释放；还有一点也很糟，就是模型问题，在大模型下写的程序，到了小模型上一概不能用，我的程序是在compact模型下写的，就不能用small来编译，这两条是可以气死人的。据说可以用far，near之类的前缀说明指针，其实是屁用不管。我干了一年多c，得到的结论是微机c还不能使人快乐，有时叫人怀念汇编。

这封来信应该是王小波的 WK 软件的首次「发布」，他提到 WK 要用 Turbo C 这个 C 编译器来构建。Turbo C 是 Borland 公司 1987 年发布的 C 语言集成开发环境（不过国内信息学奥林匹克竞赛一直要求使用 Turbo C 作为比赛环境到新千年以后，因为我当时参赛时用的就是 Turbo C）。

来信中提到的 Turbo C 的两个特性：

一是 alloc 后的内存不会自动释放，我不清楚他指 alloc 是否是误用 alloca 还是 Turbo C 的实现标准不同，因为 alloca 是在栈上申请内存的，而 malloc 不是；

二是内存模式问题，Turbo C 这样的老 C 编译器是面向 DOS 的，因此提供了不同的内存模式。简单来说就是不同模式下指针基础偏移不同，在 compact 下的指针在 small 下可能会指向错误的地址，所以「大模型（不是 Large Language Model）下写的程序，到了小模型上一概不能用」。

现在的程序员大概很少会考虑到内存布局的问题了。

1992年9月，致晓阳

我用 C 编的软件已经用熟，并做出了各种写小说的工具，别人的软件已不用了。现在主要是写书赚钱。从今年初开始写长篇，首先做了写长篇的专用软件，现在基本调通，开始写了。

这里提到的「用 C 编的软件」应该指的是上文的 WK 和其他帮助写小说的软件。

从此世界上少了一位「蹩脚的」程序员，多了一位伟大的作家。

年份不详，致曲小燕

我们的 pc 机还没有和 Internet 连上。本来中国有几个国内网发展得很快，现在又出了问题，谁要上 Internet，必须到有关部门去登记，留个案底，以备当局监控，很有一点监狱的气味。
我还不想找这份麻烦，再说，通过 Chinanet 联网，每月也要交七八百的月费，我也没有这么多的钱。既然×反对信息时代，我们就不进这个时代罢，有什么法子。所以还是写信好了。

哈哈。

除了这些，书信集中其他信件也非常有意思，推荐阅读。

幻觉

2025-05-03T09:36:25Z

从地理到文化的裂谷

我们常忘了，中国和美国都幅员辽阔，很难只有“一种声音”。

但是，从上海到东京的距离是 1700 多公里，从上海到乌鲁木齐的距离是 4300 公里，从乌鲁木齐到伊斯坦布尔的距离也只有 4730 公里。

对一些上海人来说，也许乌鲁木齐的文化距离比东京更远。

同理，新疆的穆斯林或许觉得伊斯坦布尔比上海更亲近。

文化的差异不仅仅体现在语言。

不同省份之间的文化差异就跟不同国家之间的文化差异一样大，如果对比对象是欧洲那些国家，可能省份之间还要更大一些。

北上深、普通省会、五六线乡镇，几乎像三个发展阶段的国家，各自的文化迥异。

这也解释了「春节回乡总吵架」：本质像跨国旅行。

尊重的双向门

在东京呆了几年。

老一辈常问我：日本人歧视中国人吗？

那上海人歧视河南人吗？

一个现实的情况是外国人在日本租房子的难度是有差异的，日本房东会“审查”租客的背景材料，包括国籍、工作、收入水平、违约历史等等。

有些房东对中国籍者格外苛刻，确实存在。

单看这个结果似乎是歧视中国人。

但是很多歧视不是无缘无故产生的，这是一种对坏事情发生的概率的应对方式，在企业里面用另一个词描述它：风控。

有人问 Linux 创始人 Linus Torvalds 为什么在邮件列表里骂人。他答：

我只尊重那些值得尊重的人。有人觉得尊重是必须给予的，但我属于反对这种观点的人。尊重要靠自己去赢得，不去赢得你就得不到尊重，事情就是这么简单。

所以我觉得这个问题很简单，
旅居海外的中国人如果希望得到其他人的尊重，那就去赢得这些尊重，
不过这是对你本人的尊重；然后，才有机会去改变风控系统中跟自己群体相关的概率特征。

反而真正顽固的，是户籍、住房、教育、医疗、性别这些制度化歧视。

生而自豪还是有所贡献

如果在中国长大，从小就被教育应该为身为一个中国人而自豪。

这很奇怪。

中国确实是一个文明古国，历史悠久，文化繁华。从古代到现代，中国人做出了很多辉煌的成就。

但这些成就与我何干？我既非创造者，也未参与其中。

如果我把自我归因于某个群体，那只能说明我作为个体本身毫无贡献，不得不诉诸群体，这对个体来说毫无意义。

如果我要自豪，那这种自豪应该来自我做出的贡献和成就，比如我做了什么事情，有帮到其他人，而不应该是某种与身俱来的东西。

「我是一个中国人」跟「我天生双眼皮」和「我有易患糖尿病的倾向」本质上是一样的，都是与生俱来的东西。没有人会因为自己天生双眼皮和易患糖尿病自豪对吧，所以为什么要对于哪国人的身份而自豪呢。

从逻辑推演，这里存在悖论。

能源的尺度

大概在几年前，面试了一个工程师。

面试结束闲聊时间，聊到了 BTC。他嫌比特币耗电：一年用电接近三峡大坝年发电量，太浪费。

就数量级上看，他说得没错。在《Bitcoin Energy Consumption Index》这篇文章里，作者估算 BTC 一年的电力消耗大概是 77TWh。在三峡大坝的维基百科，可查到大概一年的电力输出是 100TWh，确实是一个数量级。

当时我解释：POW 本就耗电，所以有人研究 POS、DPOS 等替代方案。

不过后来我发现，即使是 POW 又怎么样呢，有什么好辩解的。
一个全球性支付网络，每年都需要相当于一个巨型水坝的发电量来维持，有什么问题么？

人类能耗本就不断上升，不上升才怪。

在很多科幻小说里，都有星际旅行和开发行星的桥段，所有星辰大海都需要很多能量的支持。

1964 年，苏联天文学家尼古拉·卡尔达肖夫提出用能量划分文明等级，被称为卡尔达肖夫指数：

I 型文明：驾驭文明所在一整颗行星的能量，消耗能量大概在 10^16 W 这个量级。
II 型文明：驾驭一颗恒星的能量，消耗能量大概在 10^26 W 这个量级。
III 型文明：驾驭一个星系的能量，消耗能量大概在 10^37 W 这个量级。

现在人类尚未达到 I 型。

2018 年全球耗能约 18 TW，仅 10^13 W。

就这点，距离 I 型还差三个数量级。

若真追求星辰大海，届时用百万分之一的能源维系全球金融系统，反倒显得吝啬。

最大的问题是：人类寿命太短，能理性判断的年头不过 50 年；放在文明史上，只是指顾倏忽。

我们自觉身处平地，只因目力所及不过几米；或许脚下是谷底，也可能已在峰顶。

感谢竹白，以及如何支持竹白用户的迁移

2025-03-23T14:22:00Z

2 月竹白发布下线公告的当天，我发了「🚚 指南：从竹白（zhubai.love）迁移到 Quaily」。

倒不是手有多快，而是 Quaily 很早就支持从竹白导入了~

迁移结果

截止到 2025 年 3 月 31 日，共计迁移了 31 个频道，1715 篇文章，9845 位订阅者。

他们是：

CyberClip: 一份臻选互联网上有价值内容的赛博剪报，两周一期，涵盖新奇趣闻、热点议题、前沿科技以及其他关于生活、关于未来的事物。
熊言熊语: 与你分享肿瘤生物医药领域的研究进展以及我的所思所学所想。
为何是他: 以信求知。
无限自然: 《无限自然》对优质信息源/AI自动化提效有足够的好奇心，关注AIGC对产品设计的影响。通过逐步建立良好的系统，无限接近自然的状态。
素生: 误读人生，化人生活
事不过三: 重要的事不过三件：认识自己，好好学习，好好生活。
试行错误: 反复探索，不断试错。重在实践和落地。希望能和你一起找到「改变」的突破口！同行的人比目的地更重要。
乔尔事务所: 关于地方和空间的观察备忘录
海上星光: PM@阿小小海和设计师@尤a娜共营的科技、设计、生活型博客/上海/东京
我脑袋里的怪东西: 无聊的通勤 + 奇怪的脑袋。
Off-Beat: 欢迎看到，这里会存一些个人感兴趣的东西；分享一些个人经历影响下，看到的喜欢的书、音乐、视频、文章；说一些评价、推荐、想法、见闻以及别的该说不该说的乱七八糟的东西吧。
日出山谷: 好奇心是智慧的种子！
跳歇间: 这是一段时间，也是一个空间。在这里，保持一种轻快的脚步，间歇小跳。
有（冇）用: 有（冇）用，源自粤语俗语，意为有（无）用。在当下的生活里，每天信息宛如瀑布般涌现在这小小电子屏幕上，同时信息内涵也悄然变化着，不再单纯且多少夹杂某些目的。但......这些信息是真的有用吗？
Moonvy月维设计周刊: 每周一更新设计相关的素材和资讯
播客相对论: 分享有趣、有意思、值得被更多人听到的播客节目，也希望能在评论中看到你给我推荐一些播客节目。
大人的坚持魔法术: 分享一些坚持的魔法，做乌龟赛跑里的乌龟就够了。每周四发出。
闲时杂记: 记录生活的美好与不美好✨
简悦周报: 简悦周报官方推送渠道，内容涵盖了：新用户指南 / 简悦阅读模式使用技巧 / 通用性问题的处理和解决方案 / 与其它生产力工具的联动 / 简悦用户提供的基于简悦的工作流等。
显济的闲言碎语: 下午2:00-5:00在喝咖啡｜海外智能硬件产品设计师｜做了自己的网站：Jefferyho.com
喧哗上等Radio: 播客《喧哗上等》的邮件推送
中文播客行业动态: 中文播客领域的动态和最新消息
花生碎: 记录是种自我建档。
学到老 Shadow law: 一个爱饮咖啡、常听播客、养了只猫的人。读了什么、想到什么，可能都会记录下来，随机从里面抽取片段分享。
自说自话: 没有记录就没有发生，而记录本身已经是一种反抗。
一颗小树: 分享我的日常，包括但不限于互联网、技术、开源、投资理财，欢迎你来。
吾栖之地｜ Soul Place: Chuwen的不定期回顾，用文字创作Cyber空间的个人纪录片。
驯鹿漫游: 记录我近期收集的有趣信息及一些联想。不定期更新。
家书: 以书信形式给青少年看的生命哲思。
未闻Code·会员精选: 未闻 Code 精选内容/会员专属内容/我每周的思考总结/我每周学到的新东西。
曲率飞船: 这里有诚实真挚的人间体悟，有趣独特的阅读新知。

内容导入

用爬虫抓内容

竹白的网站是一个 Web App，所以常规的爬虫抓不到内容。

所以用了 headless chrome 来抓取内容。

例如，如果要获得文章的标题，发布日期等内容，就在 headless chrome 里运行这一段：

function get() {
  const h1 = document.querySelector('h1');
  const meta = h1.nextElementSibling;
  const content = meta.nextElementSibling;
  const metaSpans = meta.querySelectorAll('span');
  let dateString = '';
  let premium = '0';
  if (metaSpans.length >= 2) {
    dateString = metaSpans[1].innerText;
  }
  if (meta.innerText.indexOf('付费内容') !== -1) {
    premium = '1';
  }

  const cover = content.querySelector('figure');
  let img = null;
  if (cover) {
    img = cover.querySelector('img');
  }

  return {
    title: h1.innerText,
    date: dateString,
    content: content.innerHTML,
    cover: img ? img.src: '',
    premium: premium,
  }
}

而要获得文章列表，则运行这一段：

function getArticles() {
  const links = document.querySelectorAll('.PublicationPage_item__38S6L');
  let freeLinks = [];
  let paidInfo = [];
  for (let i = 0; i < links.length; i ++) {
    const slug=links[i].href.substring(8, links[i].href.indexOf('.zhubai.love'))
    freeLinks.push(`./quail-prod -c ../../config.prod.yaml import -t zhubai -l ${slug} --url='${links[i].href}'`);
    const timeEl = links[i].querySelector('.PublicationPage_time__1xXKG')
    let time = timeEl.innerText.trim()
    // check the first character is digit or not
    if (!/^\d+$/.test(time[0])) {
      time = time.substring(1).trim()
    }
    const paidTagEl = links[i].querySelector('.PublicationPage_paidTag__vwcz8')
    const titleEl = links[i].querySelector('.PublicationPage_title__1pSF4')
    if (paidTagEl && titleEl) {
      paidInfo.push({
        slug,
        title: titleEl.innerText.trim(),
        time
      })
    }
  }

  let paidSql = [];
  for (let i = 0; i < paidInfo.length; i ++) {
    paidSql.push(`update posts set first_published_at = '${paidInfo[i].time}' where title = '${paidInfo[i].title}' and slug='${paidInfo[i].slug}';`)
  }
  return {
    freeLinks,
    paidSql
  }
}

NOTE

这里对收费文章区分对待，是因为爬虫抓不到收费文章的内容，但是可以抓到收费文章的时间。
把时间记录一下是有用的，看到后面就知道了。

于是，对于免费文章，无论是否有竹白提供的导出数据，只要得到了作者授权，就可以无缝迁移到 Quaily 了。

收费文章内容的导入

三月开始，竹白提供了数据导出，可以导出订阅数据和文章数据。

文章数据里也包括付费的文章，但是实际使用这些数据的时候有两个问题：

竹白的导出文章数据里没有文章的发布时间
导出数据里的所有链接都是坏链

于是上一个脚本中，抓取付费文章的发布时间就有用了：

使用竹白导出数据完成收费文章的导入以后，再更新一下付费文章的发布时间，那么文章排序才是正确的。

最终完整的文章导入流程变成：

免费文章：直接爬虫抓。
收费文章：先用备份数据恢复，然后用爬虫抓发布时间，然后更新。

坏链我搞不定，需要作者自己修复了。

订阅者导入

相比内容导入，订阅者导入要简单得多。

竹白导出的订阅信息是一个 csv 文件，大概是这样的格式：

用户名	邮件地址	订阅时间	付费时间	到期时间	累计付费	是否为付费用户
某某	user@space.com	2022-02-09	-	-	0.00	否

我有一个专门的脚本来转换各类订阅信息到 Quaily 的 JSON 订阅格式，其中也包括竹白导出的 csv。

但大量导入很容易命中 ESP 的风控，所以这个脚本会把订阅信息拆分成很多份，每一份都是一个单独的 json 文件。

然后这些 json 文件会被提交给 Quaily 的任务调度程序，这个程序会自己去安排导入任务。

调度程序部署好任务以后，会返回预计完成时间，我会把这个时间通过邮件回复给让我帮迁移的作者。

最后，我自己维护了一个 Google Sheets 来记录迁移的进展

一些优化

预迁移

一些作者在竹白上发了迁移公告，还没有邮件联系我，我已经把内容给迁移完毕了。

于是当他们给 Quaily 发邮件时，我会回复内容已经迁移完了，他们会很开心。

这是因为对于新创建的 Quaily 频道，我会得到通知。然后我会去看看竹白上有没有同名的。如果有的话，并且作者声明授权的迁移目的地也对得上，就可以直接迁移了。

这样的体验比较好。

Onboarding

观察了一些作者的使用习惯以后我发现：

竹白似乎不支持完整的 Markdown，所以写了「五分钟掌握 Markdown」来帮助作者们学习 Markdown
不少作者同时经营公众号，那么把微信公众号排版功能介绍给作者

最后挑选了一些中文作者可能感兴趣的话题，在文章「✉️ 给中文创作者朋友的信」一起集中介绍，并在迁移邮件中推荐作者阅读和订阅。

感谢竹白

Quaily 刚刚起步时，就收到了不少竹白作者的信任——像一石千浪，DEX 周刊和 AIGC Weekly，都是最初就选择了 Quaily 的几位。也正因为大家的鼓励，我才有了更多前进的动机。

没想到到了最后，Quaily 的导入在竹白下线时也帮到了更多作者。

感谢竹白和竹白的创作者，有了大家，Quaily 才像今天这样具备一定的承载力，也让我有机会遇见你们。

以上。

⚖️ Function Calling vs MCP：来自开发者的实际对比

2025-03-09T08:49:07Z

👋

在浅浅使用这两种方法一段时间后，我想和大家分享一下 Function Calling 和 MCP 在实战中的权衡考量。

我猜大多数读者已经对 MCP 和Function Calling 有所了解了。所以我就不再赘述技术细节：

场景：身份验证和会话管理

举个例子，我正在开发 Quaily，一个 AI 驱动的 Newsletter 工具。我希望能通过 AI 来发布文章到 quaily.com，当然，这需要身份验证：

使用 MCP 方式：

我可以使用本地程序（也就是 quail-cli）来处理身份验证和会话管理。这样登录状态自然存在于 MCP 服务器也就是 quail-cli 中，登录凭证永远不会泄露给 LLM。

如果凭证过期，MCP 服务器可以简单地强制用户在 quail-cli 中重新登录。

认证和 LLM 处理之间有着清晰的界限，就像把钥匙和锁分开保管，不用担心被偷走。

使用 Function Calling 方式：

显然我不能把 token 或其他登录凭证发送给 LLM：因为存在会话标识符被 LLM 记住的风险，谁知道这些 LLM 会不会偷偷复制一把钥匙呢？

可能的解决方案：

使用超短期 token：比如生成只有 10 秒有效期的 token
甚至强制每个请求使用新 token 以防止重用

然而，所有这些方法都增加了复杂性，而且仍然无法提供与 MCP 架构方法相同的安全保障。根本问题依然存在：使用 Function Calling 时，是在通过一个无法控制的系统传递敏感信息。

商业模式影响

不仅仅是安全问题，还涉及商业模式。一个商业模式基本上是向你的客户或者用户提供一系列有收费站的高速公路，然后从这些收费站赚钱。

比如在 Quaily 中，收费站是对付费内容的访问，商业模式是订阅制。

如上文所述，Function Calling 很难提供与 MCP 架构方法相同的安全保障，所以它也许适合快速构建产品，但难以创建服务边界，这样的商业模式实施起来不说是别扭，只能说很蛋疼。

而 MCP 天生就适合构建访问控制 —— 尤其对那些想做 AI 应用但没有能力构建像 OpenAI 那样基础设施的应用开发者来说，是这样的。

决策：选择 MCP

今天，两种方案都在解决实际问题，但在深入使用两种方法后，我觉得 MCP 更适合大多数场景，以下是我的观点：

安全设计：MCP 的架构从根本上解决了 Function Calling 难以应对的凭证暴露问题
面向未来：随着应用程序的增长，MCP 的模块化架构扩展得更加优雅
清晰边界：数据访问和 LLM 处理之间的分离创造了更易维护的系统
生态系统建设：MCP 可以构建可在应用程序之间共享的能力网络，有利于商业化

你觉得怎么样？欢迎与我分享你的想法。

📊 在 Google Sheets 里调用 AI，OpenAI/Deepseek/Grok 同时帮你批量工作

2025-02-24T03:56:19Z

English

前段时间，飞书多维表格接入了 Deepseek，很多人用它批量生成文案、批量处理信息之类。

其实 Google Sheets 也可以做到。方法也很简单，只需要按照下面步骤做：

准备工作

首先需要自己准备 API Key。可以是 OpenAI、Deepseek、Grok 或者所有兼容 OpenAI API 的 Key。

申请地址：

供应商	申请地址
OpenAI	这里
Deepseek	这里
Grok	这里

在示例中，我用的 Grok，在 X.AI 可以申请。

让 Google Sheets 启用 AI

打开想要用 AI 的 Google Sheets，选择菜单 Extensions > Apps Script.

复制这段 Apps Script 代码的内容，然后粘贴到编辑器

点击编辑器的保存按钮，回到 Google Sheet，准备四个单元格，分别输入 API Base，API Key，Model 和 System Prompt。在我的示例中，他们的位置在 $C$2、$C$3、$C$4、$C$5，然后输入对应的值。

我用的 grok，所以他们的值分别是：

变量	值
API BASE	https://api.x.ai/v1
API KEY	申请的 API KEY
Model	模型的名字
System Prompt	输入系统提示语

其中

API BASE 需要根据选择的 AI 供应商换成对应的地址。例如 OpenAI 换成 https://api.openai.com/v1，Deepseek 换成 https://api.deepseek.com，Grok 可以是 https://api.x.ai/v1
Model 需要根据选择的 AI 供应商换成对应的模型名字。例如 OpenAI 可以换成 4o-mini，Deepseek 可以换成 deepseek-chat，Grok 可以是 grok-2-latest
System Prompt 就是自己编写的任务 prompt 了

然后直接在 Google Sheet 里像调用普通函数一样调用 AskLLM 就行。

调用方法是

=AskLLM($C$2, $C$3, $C$4, $C$5, B12)

其中，$C$2、$C$3、$C$4、$C$5 是上文提到的四个固定变量，B12 是需要问 AI 的内容

最终效果如下：

可能的问题和优化

由于请求是从 Google 服务器所在的 IP 发出去的，不确定是不是会被供应商 ban 掉。一个可能比较好的做法是在自己的服务器上进行转发，让 Google 请求自己的服务器。这样从供应商的视角看上去就是从自己的服务器调用 API。
使用时需要在 Google Sheets 里输入 API Key，而 Google Sheets 经常分享给其他人，如果保管不慎可能泄漏私钥。解决的方法要么用完就删除 API Key，要么就在自己的服务器上做一下鉴权。

~~如果 Google 官方一直没做，那么做成解决方案的话也许能卖 😋。~~

Google Workspace Marketplace 里面已经有很多了。

AI 代替人类程序员进度观察表（2025 年 2 月版）

2025-02-13T05:40:47Z

TLDR

选最强模型

既然做简单任务成功率越来越高，那就把复杂任务拆分成简单任务

面向复杂性管理的工程能力依然人类占优，高工程能力能更准确描述需求去挖掘 AI 的潜力

高质量的文档有利于高质量输出，尤其是项目自己的文档

雇佣 AI 程序员的一年里，我一直在寻找在复杂项目中，更高强度的 AI 代替人类程序员的使用方式。

这是 2025 年 2 月的观察进度表和最佳实践。

选最强模型

目前的最强编码模型依然是 o1 pro。我猜测原因是延长 reasoning 的时间和 o1 本身底子好。

o1 pro 很慢，但不算缺点。因为写代码本来也是想得慢写的快。正确和合理相比速度更重要一些。

简单任务最高

在展示大模型编程实力的时候，经常会让大模型编写一个完整的简单任务，例如 ToDo 这样的 App，贪食蛇这样的小游戏。

这样的任务边界清晰，几乎没有与外部系统交互的需求，而且都不是 zero shot，因此完成得非常好。

所以要利用这一优势：一是使用能用到的最强模型；二是描述需求时严格确定边界，用简单任务组合复杂任务。

关于第二点，就是把每一个模块当作第三方：内部逻辑封装；通过接口对外提供服务；依赖的外部资源通过约定的协议获取。嗯，本来也是软件工程的实践目标，所以遵循这个原则的话，也是在提升工程质量。

例如一次典型的开发需求，她的 prompt 可能是这样的：

implement a golang module, here are requirements:
- requirement 1...
- requirement 2...
- ...

here are interfaces:
- method 1...
- method 2...
- ...

here are dummy functions you may needs:
- function 1
- function 2
- ...

here are criteria:
- criterion 1
- criterion 2
- ...

把 prompt 给到 o1 pro，可以得到目前最好的结果。

工程管理得人类进行

现在大模型在应对最高级工程任务和最低级工程任务的任务时表现很好。最低级就是上面说的「简单任务」。

最高级指对整个架构的抽象，角色是一个接受咨询的架构师，向它提出问题，然后得到一些选择，作为参考，可以说很有帮助。

但是连接二者的中间的部分的工程任务，用过 Devin 和 Cursor 的 Agent，现在的大模型处理复杂工程中间的部分依然不太行。

我理解应该有两个问题：一是关于工程的隐含知识没有体现在代码和文档上，方案和架构的选择上也不存在最优解，有很多脏活；二是模型的接受的内容多了以后，缺少明确的边界，幻觉变得严重。

第二个问题的话，可能需要在工程上做更多工作，比如结合静态分析的结果（猜的，我不是语言分析方面的专家），或者别的东西，目的是缩小问题的规模。

第一个问题的话，本质上代码和文档一样的。如果第二个问题不好解决的话，可能光靠补充知识还不行。

IDE 的话，我觉得无论是 vscode, cursor, windsurf 没有本质的差别。毕竟模型能力有限，如果 IDE 最后给出错误的预测，肯定不如 o1 pro 一次成型来得好。

高质量的文档

虽然代码是自解释的，但是有高质量的文档会提升模型对项目的理解和感知。

这一点如果是 mono repo 会很有优势，因为文档本身就在 repo 里，在 IDE 里指定一个 markdown 文件就够了。

基于这个原因，我现在逐渐开始以项目为单位组织 mono repo 了。

替代人类程序员的可行性

同意的 Sahil Lavingia 的看法：

No longer hiring junior or even mid-level software engineers.

No longer hiring junior or even mid-level software engineers.

Our tokens per codebase:

Gumroad: 2M
Flexile: 800K
Helper: 500K
Iffy: 200K
Shortest: 100K

Both Claude 3.5 Sonnet and o3-mini have context windows of 200K tokens, meaning they can now write 100% of our Iffy and…
— Sahil Lavingia (@shl) February 6, 2025

而且我也做了类似 antiwork 的事情。比如类似 Helper 的 AI 机器人，类似 Iffy 的反垃圾。

我的实践经验有：

能力强的工程师运用 AI 得当，得到 5 到 10 倍的产出完全没问题。也就意味着，如果公司是以输出技术能力作为盈利方式，那么在需求量不变的前提下，裁减 50%~80% 的人力是没问题的。
复杂度切分得当，在优秀的工程师监督下，AI 持续迭代中等规模的项目是没问题的（以 Quaily 为例，后端部分核心代码大约 1M token）
好消息是不管 AGI 能不能来，LLM 能力的上界足够改变很多很多很多事情。
- 坏消息是它的下界比很多人类的上界还要高。
  - 更坏的消息是，所有对好消息理解不到位的人，都在坏消息的影响范围内。

交易事实，而不是交易价格

2025-02-05T13:48:29Z

前段时间开始学一门新手艺，有师傅带的。

虽然上个月已经出师了，但学无止境：要学地缘政治，要学宏观分析，要学货币政策，要学技术分析，要学 Pine Script... 对，我在学做交易。

一直觉得，如果要学一个新东西，除了这个东西本身的价值，最好它能重塑看待世界的视角。因为这样的好处影响更长远，即使这个东西本身可能过时了。

交易事实，而不是交易价格。—— 我师傅如是说。

比如说，一个人可能在 10 万美元卖出比特币，也可能在 10 万美元买入比特币，并不是因为 10 万美元这个价格太贵或者太便宜，而是因为市场的交易结构下，这样的买卖有更高的赚钱概率和更低的赔钱概率。

总之对这句话的理解，我认为是一种决策方式。

即作为一个人类，每次做决策在情感与理性之间徘徊时，要避开情绪、直觉、从众这样表现出较强的「人性直觉」特征；要更多考虑真实发生的事实，剥离情绪噪音，才能做出有利于自己的应对。

交易事实可能违背个人偏好

比如说，在 Trump 大统领发币之前，有一个著名中文 KOL 发币了。即使 KOL 团队运营手法羸弱，这件事仍然自然地引发了相当大的讨论。

既然已经发了，这是事实。

如果有人出于对这个 KOL 的厌恶，跟随直觉地积极去骂他，参加一场又一场的直播，这样做其实是在帮 KOL，是在给他做市。因为 meme 币的特性，其价值不仅源自市值，也来自市场的波动性和投机情绪。

于是反对者也是无意中的市场制造者，负面评论同样推动市场波动，至于波动向上还是向下一点都不重要。

再比如说，Trump 上任大统领这件事，不喜欢的人各有各的理由。但既然大多数美国人选择了他，那这就是事实。

稳定的未来既然已经是奢望，那么就考虑动荡之下怎么发现并捕捉由波动带来的机会，去帮自己或者家人过得好。

交易事实是适应变化

回顾上文「10 万美元」的例子，会发现事实暗示了变化，指变化的市场结构，正如价格暗示了不变，指不变的价格。

考虑到人总在尝试追求确定性，那么追求事实就是追求不确定性，这是与直觉相悖的。

有个说法是一旦到了某个年纪听的歌就会停止更新，来佐证随着年龄增长，跟上世界变化变得越来越困难——这不仅是生理上的适应问题，更是精神和心态上的挑战。

但这是刻板印象。确实因为年龄增长后，一些人因习惯和心理需求而更倾向于稳定、熟悉的文化内容，但更可能是因为时间、注意力资源稀缺导致的，而不是年龄。

比如说一个人，一直没有按事实决策的习惯。如果他有了比较大的生活压力，去探索一个新事物背后的事实的路径成本变得很高，那么他就迅速变得守旧、迂腐、易于被诈骗了。只不过生活压力经常伴随着年纪增大而增大罢了。

交易事实是反脆弱

Note: This post contains paid content. Purchase on the website to read the full article.

Quaily 技术架构简介

2025-01-15T05:47:12Z

今天来分解一下 Quaily 的技术架构。先确立几个原则：

不被供应商锁定(vendor-lock-in)——包括不被 cloudflare 锁定，可以随时迁移到 Linux 裸机上。
能减少依赖就少依赖。
能不学新技术就不学。
能满足需求就不雕花。
只在最需要运行效率的场景考虑运行效率。

就酱。现在开始。

路由

打开 quaily.com 就是 Quaily 的首页。这是一个部署在 Cloudflare 上的 Hugo 站点。

但域名 quaily.com 并不是直接指向 Hugo 部署的 worker，而是指向一个负责分流的 worker，叫做 quaily-router 好了。

这个 router 会根据请求的路径等条件，把流量分到下面几个 workers 去

routes   = ["quaily.com/*"]
services = [
  { binding = "front",     service = "front" },
  { binding = "dashboard", service = "dashboard" },
  { binding = "portal",    service = "portal" },
  { binding = "tools",     service = "tools" },
]

其中 front 和 dashboard 是 Vue 的 SPA，portal 是首页，tools 是 Tools 一个手写的静态站。

同时，quaily-router 还负责处理所有静态资源的请求，包括：

对文章页的请求，例如 https://quaily.com/lyric/p/quaily-technical-architecture-introduction
对文章列表页的请求，例如 https://quaily.com/lyric
对 sitemap 和 feed 的请求，例如 https://quaily.com/lyric/sitemap_index.xml 和 https://quaily.com/lyric/feed/atom

这些静态资源都放置在 Cloudflare R2 里。

所以一次对主域 quaily.com 的完全请求，流量示意图如下：

虽然 quaily-router 用 worker 实现，但如果需要的话，也可以用 nginx 这样传统的方式；而 R2 和 S3 兼容。所以没有被 cloudflare lock in

前端

dashboard 和 front 是简单的 Vue SPA。

其中，

dashboard 工作在 quaily.com/dashboard，负责登录以后的所有 UI 业务。
front 工作在除了文章和文章列表以外的所有页，例如 quaily.com/lyric/about 等等。

从上面的示意图可以看出来了，文章和文章列表不是 SPA，也不是后端渲染的结果，而是静态化的 HTML 网页。

这样做的好处是，从开始请求到内容展示的延时小，只需要让 quaily-router 从 R2 读出来然后返回就行。平均延时在 100ms 以内，比常见的内容站点快 3~5 倍。

文章和文章列表上的动态内容（比如订阅表单）通过在 HTML 挂载 Vue SPA 来实现。这些内容的加载需要额外时间，但是在他们加载完成之前，不影响人类和搜索引擎读文章内容和列表。

后端

前端通过 RESTful API 和后端交互，端点在 api.quail.ink，指向一台负载均衡器。负载均衡器使用 AWS 的默认配置，但需要的话可以随时换成 nginx，也不会 lock in。

负载均衡器背后有多台实例提供 API 服务，还有一台 worker 实例处理后台任务。他们其实都是用 Go 写的同一个程序，连接到相同的 postgresql 数据库实例。

完整的前后端架构大概是这样：

运维

数据库备份

通过一个 cron 脚本来完成，每天备份到加密 S3，然后发通知到 telegram 频道。

很多业务通知都会发到 telegram

日志收集

Quaily 所有服务进程都通过 systemd 来运行，日志就是 syslog。所以最简单的配置方法是配置 rsyslog，然后把日志发送到一台集中的日志服务器，放在 /var/log/hosts/HOSTNAME 下。

对于业务实例，配置 rsyslog.conf

$PreserveFQDN on
*.* @@LOG_SERVER_ADDR:514

$ActionQueueFileName queue
$ActionQueueMaxDiskSpace 1g
$ActionQueueSaveOnShutdown on
$ActionQueueType LinkedList
$ActionResumeRetryCount -1

对于日志实例，配置 rsyslog.conf

module(load="imtcp")
input(type="imtcp" port="514")

$AllowedSender TCP, 127.0.0.1, 172.26.0.0/24

template(name="PerHostLog" type="string" string="/var/log/hosts/%HOSTNAME%/%PROGRAMNAME%.log")

*.* action(type="omfile" DynaFile="PerHostLog")

需要观察实时日志的时候，把他们合并到一起：

multitail -cS slog -f /var/log/hosts/quail-0/quail.log -cS slog -I /var/log/hosts/quail-1/quail.log ...

扩容

因为我不会也不想学 k8s 这样的知识，所以写了一个脚本，只需要运行这个脚本，就可以在一台全新的 Linux 实例上配置好所有内容，包括 systemd，rsyslog 等等。

有时需要批量操作的话，会使用 zellij 的 sync mode（ctrl + t, s），可以同时在一个 tab 下的所有 pane 输入内容。

监控

监控使用的是 uptimerobot 和 sentry。

业务报警使用的是 telegram。

构建

大部分构建使用 github action 完成。少部分在打包机上完成，然后通过脚本上传到实例，类似这样：

#! /bin/bash

set -e

declare -a arr=(
  "inst-0"
  "inst-1"
  "inst-2"
  # ...
)

echo "📦 build..."

VER=$(git describe --tags --abbrev=0)

GOOS=linux GOARCH=amd64 CGO_ENABLED=0 go build -o quail -ldflags="-X main.Version=$VER -X ..."

for host in "${arr[@]}"
do
  echo "📤 scp to $host"
  scp quail $host:/opt/quail/quail-new
  echo "🚀 restart..."
  ssh $host "cd /opt/quail && mv quail-new quail && sudo systemctl restart quail.service"
  echo "🙆 deployed!"
done

于是后端加上运维相关是这样的：

AI

Quaily 用到了一些 AI 服务，包括 OpenAI 和 Claude.ai 的。因为处理 AI 相关的业务经常遇到一些繁杂的事情，包括重试、负载均衡、格式化、任务路由、CoT 等等，所以这部分工作交给一套单独的服务，包含一个调度器和若干和 proxy 组成，其中：

调度器负责调度 AI 任务。比如这个任务交给哪个 proxy，比如这个任务的 proxy 429 了要重新调度
proxy 负责处理任务，比如一个 proxy 专门处理小任务，就可以交给 4o-mini；另一个 proxy 负责处理文字类任务，可以交给 claude-ai-3-5-sonnet-v2。

大概长这样：

以上就是 Quaily 的技术架构。完整的示意图如下：

封面图源

做空世界的人们

2025-01-06T00:28:52Z

前些日子，我遇到一位老朋友，他最近在研究因果报应的问题...

他说：你说奇怪不奇怪，我遇到的坏人干尽坏事却活得逍遥自在，都说抬头三尺有神明，神明怎么不收拾他们？

Note: This post contains paid content. Purchase on the website to read the full article.

大音希声，大象无形

2024-08-18T06:09:26Z

在互联网上，所有涉及到偏好的讨论，都不免引发口水战。

偏好是一种很个人的东西，但如果选择影响的人不仅仅是自己，也包括协作的团队成员，或者公司的利益，或者用户的体验，那么就需要更多的考虑。

无论选择是什么，应该都遵循某一个原则。不同人的原则不相同，对我来说，它是「Worse is Better」。

Worse is Better：简单性的胜利

Worse is Better 是 Richard P. Gabriel 提出的哲学。它表达的是一个系统的设计应该是简单的。如果其他方面的设计会导致系统变得更复杂，那么就应该考虑牺牲它们。

他以 Lisp/Lisp Machine 和同期的 C/Unix 为对比，我列出来给大家看看：

简单

Lisp 认为，设计必须简单，尤其是界面。如果简单的界面需要复杂的实现，可以接受。
Unix 认为，设计必须简单。实现的简单比界面的简单更重要。

正确

Lisp 认为，设计在各方面都应该正确的，不允许有任何错误。
Unix 认为，设计在各方面都应该正确的，但是如果为了简单，允许产生一些错误。

一致

Lisp 认为，设计在各方面都应该一致。
Unix 认为，设计不能过于不一致。有时候为了简单可以牺牲一致性，但最好放弃那些处理不常见情况的设计部分，而不是引入实现复杂性或不一致性。

完整

Lisp 认为，设计应该尽可能地覆盖重要的情况，必须覆盖所有合理预期的情况。
Unix 认为，设计应该尽可能地覆盖重要的情况。但是如果为了简单，可以牺牲完整性。

总之，为了简单而适当牺牲其他方面，是 Worse is Better 的核心概念。

看完这些对比，一般人会觉得 Lisp 的设计更好，但结果 Unix 却更成功。让我们来回顾一下到底发生了什么：

因为 Unix 和 C 的简单，可以在更便宜的硬件上运行，因此可以扩展到 Lisp 无法触及的地方。
因为 Unix 和 C 的残缺，没法一次性构建复杂的单片系统，所以大型项目必须分解成可重用的模块，于是软件工程的概念诞生了，程序改进的速度变快了。

于是「更差的」Unix 和 C 取得了胜利。

Vue vs React: 权衡与选择

半年前和客户的工程师聊天，他问我为什么常用 Vue 而不是 React。我说，用 Vue 心智负担没那么高，例如可以直接在一个 HTML 文件引入 vue，把 Vue 当一个更好的 JQuery 用。

所以使用 Vue，进可以 Nuxt.js 的方式启动一个现代 Web 项目，退可写 Vanilla Javascript，然后用 Vue 来优化开发体验。

这种灵活性，对我来说很有吸引力。因为很多时候，并不需要一个完整的 Web App，也就不需要维护它的依赖，也不需要处理它的复杂性。

Golang：简洁与效率的平衡

在 1.2 以前，Go 都是一个非常无聊的语言（现在是无聊的语言）。

比如说，检查列表是否包含某个元素，别的语言可以写 if item in list，但对 Go，很长一段时间里，是要写一个完整循环。

for _, v := range list {
  if v == item {
      return true
  }
}

Go 被诟病的错误处理显然也是师承 C。

但无聊也是 Go 的优势之一，比如团队成员之间的代码风格更容易统一，可读性和可维护性都更好（检查列表是否包含某个元素不是一个好例子，所以我们有了 slices.Contains）。

Go 在简洁和功能之间找到了很好的平衡。它可能不是最灵活或优雅的语言，但它的理念使得在构建高效可靠的系统时表现非常出色。

Markdown：简单与功能的权衡

自 Markdown 诞生以来就一直被争议。

一部分观点认为，作为一个标记语言，Markdown 的语法太过简单，不足以满足复杂的需求；缺少标准，导致不同的实现之间存在差异；总的来说，不如 ReStructuredText 和 Asciidoc。

另一部分观点认为，作为一个标记语言，所限颇多，不如更完整的 HTML 所见所得编辑器。

但 Markdown 刚好在一个很好的位置，所以它的流行程度证明了它在简单性和功能性之间取得了很好的平衡。

因为 Markdown 能力有限，所以它是标记语言里最容易学习的，能让「技术小子」以外的人能快速上手，仅凭借直觉也能写，用最基本的语法满足 90% 的需求。这让它几乎变成了可见即所得编辑器以外的「事实标准」，做到了 ReStructuredText 和 Asciidoc 没有做到的事情。

当然 Markdown 不适用精确控制排版的场景和需要复杂表格和图表的文档，对此所见所得编辑器是更好的选择。但对于大多数写作需求，Markdown 提供了一个很好的平衡。

生物演化：简单带来可能

技术产业之外，生物演化也是 Worse is Better 的绝佳例证。

从简单到复杂

生命最初是从简单的单细胞生物开始的。这些「简陋」的生命形式并不完美，但它们能够生存和繁衍，为复杂生命形式奠定基础。

所以软件开发中，常常从一个简单但可用的版本开始，然后逐步迭代完善。

高度适应的高风险

在生物群体中，基因的多样性看似是一种平庸，但实际上为未来的演化提供了空间。相比之下，那些对环境高度适应、特异性强的生物，比如大型掠食动物，反而更容易在环境变化时灭绝。

在设计系统时，要注意过度设计和适应反而可能会降低适应性。例如，如果系统实现如果 lock in 到亚马逊云服务上，那么当亚马逊云服务出问题时，系统会无法工作。

产品决策也是如此。依附于一个大平台，例如微信生态，也许可以借助平台优势迅速获得发展，但也要面对微信生态中那些不可控的风险，因为它们可能会让人全盘皆输。

缺陷中的优势

有趣的是，某些看似是缺陷的基因可能在特定环境下成为优势。比如镰状细胞贫血基因，携带者虽然有贫血，但对疟疾有更强的抗性。

一些选择和决策，它们可能有一些不足，但在特定场景下却能发挥意想不到的优势。例如：

Instagram 最初只允许用户上传正方形照片，这个限制被认为是一个缺点。但这个「缺陷」反而成为了 Instagram 的标志性特征，用户因此更加注重构图，创造出独特的视觉风格。
早期的 Twitter 限制每条推文只能有 140 个字符，这个限制最初被认为是一个缺陷。但恰恰是这个「缺陷」促使用户更加简洁和创造性地表达，也让信息传播更快速。这个特性后来成为 Twitter 的标志性特征，塑造了一种独特的社交媒体文化。

所以不够完美并不意味着失败。相反，它可能为适应性和长期生存提供了更多可能性。在技术选择和产品设计中，一个简单但灵活的方案可能比一个完美但僵化的方案更有生命力。

最好的设计，往往是那些用户感受不到的设计；最实用的工具，常常是那些不引人注目的工具。大方无隅，大器免成，大音希声，大象无形。

Note: This post contains paid content. Purchase on the website to read the full article.

对比一下 Macbook Air 和 Framework 13

2024-06-20T01:13:54Z

上周发了一篇《入手 Framework Laptop》。当时把数据迁移到新机器以后，就干活去了，所以这篇文章被说太短了。

这次就补一些内容，主要拿手头的 Macbook Air M2 来对比一下。

价格

Framework 13': $1,640.00
- AMD Ryzen™ 7 7840U with 16‑core CPU, 64GB RAM, 1TB SSD
Macbook Air M2 13': $1,599.00
- M2 chip with 8‑core CPU, 16GB RAM, 1TB SSD

外观设计细节

虽然远看二者很像，都是相同的金属外壳，手感也接近。

左 Framework，右 Macbook Air

但是细节处理上，Macbook Air 比 Framework 13 好。举几个例子：

左 Framework，右 Macbook Air

上图 Macbook Air 的 Laptop Bezel 也就是屏幕边框和屏幕看上去是一体的，外壳紧接一块玻璃，玻璃下面是 Bezel 和屏幕。这样做给人的感觉是屏幕边框小而且规整，接缝也不明显。而 Framework 13 的 Bezel、外壳、屏幕，有明显接缝，并且 Bezel 的塑料感拉满了。

左 Framework，右 Macbook Air

对比上图的摄像头区域更明显。

左 Framework，右 Macbook Air

上图所示的屏幕转接处，Macbook Air 要比 Framework 13 的处理要干净利落些。

下 Framework，上 Macbook Air

上图对比键盘面的外壳，Macbook Air 是没有接缝的，Framework 13 有一层接缝（注意 Framework 合盖以后中间黑色的区域是 Bezel，不是缝隙）。

屏幕

	尺寸	分辨率	PPI	亮度
Framework 13	13.5	2256x1504	201	400 ~ 500nit
Macbook Air M2	13.6	2560x1664	224	500nit

Framework 13 的屏幕比 Macbook Air 稍差一点点（我肉眼对比也是如此结论），但不多。但现在可以预购新款 2.8k 的新屏幕，分辨率能到 2880x1920，刷新率能到 120Hz。

不过我日常使用时都外接了一个 4K 屏幕，所以就不考虑了。

WARNING

这个 2K 屏幕在 Gnome 上如果不开启 Fractional Scaling，只有 100% 和 200% 两个缩放比例。如果开启 Fractional Scaling 的话，我感觉 125% 或者 150% 应该是最佳的比例，但是有一些 bug 会导致一些问题。

实际操作的时候，不开启 Fractional Scaling，保持 200% 缩放，然后开启 Accessibility -> Seeing -> Large Text 会是比较好的效果。

重量

	重量	尺寸
Framework 13	2.9 磅	11.67x9x0.62 英寸
Macbook Air M2	2.7 磅	11.97x8.46x0.44 英寸

Framework 13 要比 Macbook Air M2 重一点，长一点，宽一点，厚 30%。

但我觉得二者都有点重，因为我上一台机器 Dell XPS 13 只有 2.59 磅。

CPU

	类型	核数
Framework 13	AMD Ryzen™ 7 7840U	16
Macbook Air M2	Apple M2 chip	8

不太懂这些，所以放一个别人家的数据对比供参考。看上去除了能耗以外都是 Framework 13 胜出。

内存

	容量
Framework 13	64GB
Macbook Air M2	16GB

这是我本次升级最大的动力，大内存真的太好了。

电池与续航

	容量
Framework 13	61Wh
Macbook Air M2	52.6Wh

Framework 的电池容量大不少。按照官网说的，all day battery life, long-lasting。x86 的能耗不如 Arm，而且 Linux 的电源管理一直都比较差。我猜测相同水平下 Framework 的续航可能还是比 Macbook Air 差。

但我日常都在外接电源，所以不太在意这些区别。

WARNING

长期外接电源的话，BIOS 里有个设置可以调整电池的充电上限。这个设置的说明里解释说这样可以延长电池的生命周期。

键盘

	键程
Framework 13	1.5mm
Macbook Air M2	1mm

程序员可能会比较在意键盘的舒适度。Framework 的键程比 Macbook Air 长，回馈好一些。另外 Macbook 的按键面积会稍大一些。

但我日常都在使用外接键盘，所以不太在意这些区别。

扩展能力

	耳机孔	USB-C	USB-A
Framework 13	1	3	1
Macbook Air M2	1	2	0

这是 Framework 13 的长处，四个扩展卡槽可选的范围很大，从闪存到 USB 接口到 HDMI 到读卡器到网口都有。

我这次特地选了一个 USB-A 因为连接旧设备很方便。

其他

Framework 13 提供了摄像头和麦克风的硬件开关

虽然不是真的把摄像头挡住，但大概也不是软件层的关闭吧。

Apple 把 Magsafe 又加回去了

想诟病的是 Apple 这次宁可又把 magsafe 加回去也不愿意多加一个 USB-C 真是让人怀疑它是不是真的在清理库存。

操作系统

虽然 Alpine Linux 说是支持 M 系列 CPU，但是...买 mac 的机器换 Linux 的行为应该不多见吧... 如果一个行为不多见，那么支持力度可能有限，出问题解决起来估计也麻烦。

何况我本来就是用 Linux 的，所以 Framework 13 胜出。

最后放个桌面：

入手 Framework Laptop

2024-06-14T01:11:18Z

下单

作为 Made in 台湾的商品，居然不发货到日本，打开 frame.work 的官网会提示：

别管它，

开美国的 VPN
填写美国的收货地址
使用美国信用卡付款

是能成功下单的（如果不能，或者被退单了，说明被风控了，请换成它支持的地区的地址和信用卡）。

定制化的部分：

没有买电源，用自己的 Anker 供电就行。笔记本的电源都太粗笨，不买是环保
扩展槽选了三个 USB-C 和一个 USB-A
其他都是默认选项

接下来就是托幼馴染把机器带回来就行了，非常简单。

安装

想要 AMD 的高配机型，选择了 DIY 版本。说是 DIY 版，但实际上对 DIY 的要求几乎没有。只需要按照说明，把硬盘、内存、键盘插上就基本完成了。

先上个图

体验

作为极客向定制品牌，Linux 兼容好，真方便。

内存大就是好，不需要 Swap 分区了，真方便。

Snap 程序迁移只需要把整个 snap 目录拷贝到新机器就行了，真方便。

特意买了一个 USB-A 的扩展槽，真方便 —— 虽然现在大家都 pro USB-C，但还是很多东西是 USB-A 的。

对几个邮件服务商的观感

2024-03-18T15:51:22Z

因为对发展路径的依赖，Email 在海外有非常重要的地位，这个地位就像是中国的 QQ 和微信一样。如果要做面向全球的产品的话，Email 是绕不过去的一环。

今天来简单讲一下对各个邮件服务商的观感，以使用量排序。

@gmail.com

⭐⭐⭐⭐⭐

Gmail 是最强的没有之一。

Gmail 有最强反垃圾

一个前置知识：邮件服务的反垃圾风控系统经常围绕发送的频率（IP、域名、发件人多维度）、用户报告垃圾邮件行为、第三方邮件监控系统的来设计。

对，大部分其他邮件服务商都这样，但我观察 Gmail 肯定不是。Gmail 似乎有基于内容的反垃圾策略，并且这个策略的优先级要高于上面的硬指标。

很显然，细分策略一定比硬指标好，所以 Gmail 有最高的送达率，最低的垃圾邮件率，以及最低的误报率。

Gmail 的服务最稳健

从爆发性发送的情况来看，Gmail 很少触发频度限制。而其它邮件服务商很容易看到各种频度限制的错误。尤其是一些小服务商，下面会介绍到。

另外，Gmail 从没有出现过任何技术性投递问题。典型的包括 stmp connection failed，time out 等等。主打一个稳健可靠。

Gmail 的态度最专业

这体现在很多细节上。

比如说，Google 提供 PostMaster 让你去监控邮件的 spam 取样情况，这对于邮件投递商做监控处理问题很有帮助。

再比如说，Google 会推进很多标准来尝试缓解垃圾邮件的问题。就像 RFC8058 的一键取消订阅。目前那么多邮件服务商只看到少数几个跟进。

@qq.com,@foxmail.com

⭐⭐⭐⭐

国内用量最大的邮箱，也是国内邮件服务质量最稳健的邮箱。

我观察下来大概相当于一个低配 gmail。如果要选择国内邮箱，请选择 @qq.com。

如果要说有什么问题的话，我觉得就只有一个：它是一个中国的邮箱服务。

@163.com,@126.com,@sina.com

⭐⭐⭐

网易系和新浪邮箱，真的不太对的起老派邮箱服务商的牌子。

各种 stmp connection failed，time out 的情况比 QQ 邮箱多多了。

补充：网易的朋友联系到了我

很快有两位网易的朋友联系到了我，希望帮我解决问题。于是我就把遇到的情况跟他们说了下。
第一个问题是邮件服务返回的退信消息是 GBK 的编码，在不支持 GBK 的服务器上就乱码了。
第二个问题很多 retry 的提示频度限制，由于我降低了发送队列的处理速度，现在已经不在出现了。
嗯，感谢你们的快速反馈，补一颗⭐。看来还是得公开发文才有影响力，之前联系不到人，客服也不明白。

@outlook.com,@hotmail.com,@live.com

⭐⭐

很多人使用微软系邮箱，但是微软系邮箱其实挺拉垮的。我来说两件事：

一是微软的反垃圾经常误报 ban 掉微软自己的发的邮件。

二是微软搞了一个类似 Gmail Postmaster 的东西叫 Microsoft SNDS，目的是降低垃圾邮件困扰。

但这个 SNDS 的策略非常的莫名其妙，一旦被加入到微软的 Blocking List，很难移出。很多人都在抱怨这件事，比如这里。

而微软官方提供的工具，无论是 PostMaster 还是发 Support request，你只会收到机器人应答告诉你「一切正常」；如果有幸能收到人类应答，也不会去跟进后续的工单。

@icloud.com,@me.com

⭐⭐

Apple 系主打一个金玉其外。

我自己在 icloud 上丢过数据，也见识过身边很多案例在 icloud 上丢过数据，或者被 icloud 弄坏过数据。

Failed to load twitter from https://twitter.com/lyricwai/status/1767369534418428033

所以，我对 icloud 云服务的态度一直很明确：不想当傻逼。

对 icloud 的邮箱服务的立场，自然也包含在内：不推荐。

首先，icloud 对于投递问题的处理是最不透明的。如果遇到问题，别人家会告诉你哪儿出问题了；而 icloud 继承了 Apple 一如既往态度，只会告诉你一个地址：https://support.apple.com/en-us/102322 。至于具体什么问题，诶，您自己去研究吧。

其次，icloud 在一些概念上也是最会把人当傻逼糊弄的。

比如说 icloud 吹的这个 Protect Mail Activity，说是可以避免被追踪行为。

我可以负责任地告诉大家，这个功能是个摆设。开不开都能随便追踪。

各类匿名收信服务

⭐⭐⭐

包括 readwise.io, inbox.omnivore.app, m.cubox.pro, kill-the-newsletter.com, duck.com，都差不多。

最大的可能的坑就是无法发信，需要自行鉴别（duck.com 是可以发信的，没有这个问题）。

另外就是很多这种服务都不咋稳定，各种 stmp connection failed，time out，try again 的情况很多。

嗯，这种错误多了，是会丢邮件的。

@protonmail.com

⭐⭐⭐⭐⭐

Proton Mail 异乎寻常地可靠和稳定，仿佛一个小版本的 gmail。

对待隐私的态度也比 Apple 要实在得多。如果使用 Proton Mail，默认情况下确实是无法跟踪邮件行为的。

而且 Proton 也是目前列表里唯二支持 RFC8058 一键取消订阅的服务商（另一个是 Gmail）。

大概先说这几个，以上。

看不见的费用：「手续费们」都是怎么来的

2024-02-18T00:41:00Z

免责声明

本文中提到的具体费率和政策，最佳做法是直接查阅服务提供商的最新官方资料，因为这些信息可能随时间而变化。请毋以本文提到的数据作为决策依据。

做一个知识匮乏的人是很幸福的，所谓的「知识的诅咒」就是这样。

比如说 Nikkei Asia 每年都会拆解 iPhone，去年拆解 iPhone 15 时就说估计零部件成本在 432 美元，粗暴计算按最低配 799 元的售价，卖一台就能赚 376 美元。

虽然 Nikkei 不会有舆论引导，但是这样的计算被其他媒体渲染一下就变成了 Apple 资本家真会赚钱，卖一台手机赚的钱可以约等于白造一台——但这怎么可能嘛。

于是今天来给大家讲一些费用到底是怎么来的，降低一些大家的幸福感。

首先说一点，在市场化的今天，能长期存在的费用——我们说一个费用便宜或者贵，都是 trade-off 的结果。

微信零钱和支付宝提现要付费

从 2016 年开始，如果从微信零钱包（也就是收微信红包以后钱进入的地方）提现到银行卡或者还信用卡，超出 1000 元会有 0.1 元的手续费。

其中「超出 1000 元」是累计的。如果每次提现 1 块钱，提 1001 次，其中前 1000 次没有手续费，从第 1001 次开始，实际到帐 0.9 块钱。

支付宝提现到银行卡也是类似的费用，具体可以参考这里

很多人觉得这是微信和支付宝要赚钱，毕竟「银行账户之间直接转账都是免费的」。但是从微信/支付宝到银行账户，与银行账户互相转，是两回事，不能一起比较。为了方便理解，我简化了描述，可能有不准确的地方请见谅。

首先微信的公司不能管理钱，因为它不是银行。微信钱包里的钱实际上是托管到银行账户里。于是大致理解成腾讯在银行开了账户，所有人的微信钱包的钱都在这个账户里。

当发起零钱提现时，实际做的是从腾讯在银行的企业账户往用户的个人银行账户转账。此时，会根据不同的银行、不同的渠道、不同时间，银行会收取不同的手续费。所以「个人账户之间转账免费」是无法推导出「企业银行转账免费」的。

既然零钱每次提现都是企业银行账户转账，自然会产生费用。这费用转嫁到用户身上完全合理——毕竟使用微信转账这么方便，在其他方面就要付出代价，这是一种 trade-off。

每次买东西都付费

还是以微信为例（支付宝也是类似的）。

先说明一下，微信 App 里的钱包不属于微信支付。那个叫「收付款」和「钱包」。

那你可能要问，那在外面买东西说的「用微信支付」这句话到底是什么？其实这句话指的是「使用微信支付这个商品」这个动作。

支付发生时，背后比较复杂，大致有三种情况：

如果店主出示的是微信个人号，就是扫码以后让你加好友，然后转账：这种情况本质上是转账，和朋友之间的转账没有区别，免费。
如果店主出示的是微信收款码，扫码以后显示的是他个人的头像，这种情况很像转账，虽然目前也可以当作转账来看待，但实际上这个场景属于经营行为，虽然是支付，但是目前按照我的理解它不属于「微信支付」。
如果店主出示的是微信收款码，扫码以后显示这个店名或者商品名，这种情况是支付，此时店主使用的是「微信支付」。

总之，微信支付是一个面向商家的产品。如果开店让顾客用微信付款，那么这个店家需要接入微信支付，店家是要付费的。而且有明确的费率，可以查看官方说明：简单来说，除了学校和公共服务缴费的费率是 0，其他行业的费率在 0.2%~1% 之间，最常见的是 0.6%。

你可能要问，那使用上面的 1 和 2 两种途径不就行了？

很遗憾，不行。如果只是做一个小小的生意，个体户——或者连个体户都没注册，直接使用 1 和 2 收少量的钱是没问题的。但只要是开了个公司，都只能用途径 3。现在商业环境下，大家买的东西，出门吃的饭，点的外卖，送的快递，大部分都是途径 3。

也就是说，出门买个吃个饭，花了 100 块钱，店家收到 99.4 块，微信抽 6 毛。

有人可能觉得微信这钱赚得好容易啊，但其实这笔钱中的大部分都是要付给银行的。为啥呢，刚才已经说了，微信是不能直接管钱的，钱得托管到银行，而操作银行账户资金是要付费的... 比如说吃饭付钱是走的银联的银行卡，那么这笔交易需要向银联支付 0.6% 左右费用。

看看海外

前段时间有个新闻讲的是微信这 0.6% 把一些大学搞不爽了，于是微信下调了教育机构的收费到 0%... 其实如果对比海外，中国这些支付的费率是相当低了。

以 Visa 和 Mastercard 这两卡组织为例，使用他们消费的话，商户要支付 1%~3% 左右的交易费。按照 1.75% 计算的话，出门买个吃个饭，花了 100 块钱，店家收到 98.25 块。

问题1：这么贵那为啥店家还要用呢？

诶好问题。有几种情况：

确实很多店家就只收现金。在美国和日本的一些小餐馆很常见。
支持信用卡可能会给店家带来额外的顾客。比如说很多旅游地都会在店面上贴上「accept Visa」这样的标识来吸引游客。游客现金不一定够，但肯定有信用卡。
可以降低一些运营成本。比如一些线上服务，如果不用卡通道的话，可能需要通过寄账单要求汇款或者寄支票的方式来收款——这很麻烦，运营成本很高，宁愿付 1.75%。

问题2：这么贵那为啥消费者还要用？

虽然看上去使用信用卡消费有更高的成本，这些成本店家也会转嫁给消费者，但作为游戏的一部分，玩得好的话成本并没有那么高。

比如说，在日本和美国，很多信用卡都有返现或者返积分这样的操作。比如说我手头的卡就有常驻返现 1% 的版本，也有常驻返积分 1% 特定情况返积分 4% 的版本。

如果返现 1%，那么相当于实际信用卡成本就降低了到了 0.75%，和微信差不多了。当然，如果是返积分并且积分没消费就过期的情况，对于银行来说就是额外盈利。

问题3：支付现金和使用信用卡一个价，那岂不是支付现金亏了

对，相当于支付现金的人为溢价买单了——这也是使用卡的另一个理由。

高昂的互联网支付成本

由于信用卡是美国消费金融避不开的角色，因此像 Paypal，Stripe 这样的互联网金融服务也很难降低费率——像微信支付这样低于 1% 那几乎是不可能。

Paypal

Paypal 是一个著名的支付结算商，收费很复杂，具体可以看文档。它同时提供账户之间的转账（就像微信钱包转账）和面向商户结算（类似微信支付）

其中，个人之间转账如果是美国国内，大概率不收费；如果是跨国转账，收取 5%。也就是说，我在日本，你在美国。你给我转 10 美元，我收到 9.5 块，Paypal 拿走 5%。

对应的商户支付结算，开个店然后收款这种，类似「微信支付」的情况，费率大都在 3% 左右。如果跨货币还有额外的货币转化费。

也就是说，网上买个东西，顾客在美国，商户在日本。如果商品 10 美元，通过 Paypal 付款，然后店家大概收到 9.6 美元，转换为日元是 1395 日元，按照 Google 的汇率折合 9.29 美元

Stripe

Stripe 是海外很多商户都会使用的结算商，类似微信支付。它的结算费用不同国家不太一样，比如美国是 2.9% + 30美分，日本是 3.6%——但也有额外的消费税和货币转换费。

举个例子，对于日本来说，如果使用 Stripe 收款 10 美元，那么首先转换成日元大概 1471 日元；然后 Stripe 会收取 53 日元作为结算费用，然后在月末还会收取其中的 10% 也就是 5 日元作为消费税。

也就是说，网上买个衣服，一个订单 10 美元，这个日本商家收到了大概是 1471-53-5=1413 日元，按照 Google 的汇率折合 9.41 美元。

权衡

本地的支付通常更便宜，这是显然的。

比如在日本使用 JCB 渠道而不是 Visa，他们的交易处理费就是 0.6%~1.6%；类似地，如果在日本使用 Paypay 来代替 Paypal 和 Stripe，那么费率可以下降到 1.6% 到 1.98%。

便宜是便宜了，代价是什么呢？

JCB 和 Paypay 几乎只能面向日本本土服务，指望外国游客拿着 JCB 信用卡来日本旅游或是外国顾客用 Paypay 买日本在线漫画这种事情几乎不可能。

对于商户来说，如果只服务本地的顾客，当然可以用本土的支付服务。但如果要面向全球，那也就意味着要付出对应的代价。

这就是在一开始说的 trade-off 的结果。

税

在大部分国家，每一笔交易其实还有一块大头，税。比如说日本消费税默认是 10%，德国默认是 19%，波兰默认是 23%。

回到我们上面的例子，一个商户在网上卖一个东西 10 美元，如果这个商户注册在日本，顾客实际要支付 11 美元；如果商户注册在德国，需要支付 11.9 美元；如果注册在波兰，需要支付 12.3 美元。

于是我们就得到了含税价，11 美元（日本）或者 11.9 美元（德国）或者 12.3 美元（波兰）。

在大多数国家，含税价和非含税价都要求展示给顾客看。于是在国外我们能看到这样的小票：

或者这样的标签：

中国也有增值税，税率有 6%，9%，13% 三档。山姆会员店刚开的时候本来也是打印在小票上的，就像这样：

但是后来为了减少给群众心灵带来的冲击，跟其他商户一样都不打印到小票上了。但是不打印不代表没有，只是从看得见的费用变成了看不见的费用。

伟大的巫师经常独自行事，只要空气中的元素依然回应他的咒语和呼唤

2024-02-13T02:01:43Z

Clarke's Third Law:
克拉克第三定律：

Any sufficiently advanced technology is indistinguishable from magic.
任何足夠先進的技術都與魔法沒有區別。

-- Arthur C. Clarke

昨天晚上搭档跟我讨论 AI 可能对娱乐行业带来怎样的冲击时，我突然意识到克拉克第三定律有另一种理解：

虽然发展新科技需要继承旧科技，但就像操作系统和编程语言有 Support Lifecycle 一样，旧科技是会因为失去用户而失传的。当一个旧科技失去用户后，它确实跟魔法没有区别了。

比如说，在一万年前，钻木取火是每个家庭必备的手艺，但现在只有很少的人能做到钻木取火了。取火对木头材质、火绒质量、环境条件、技巧手法乃至体力都有较苛刻的要求，这些信息对于普通人来说，不再是常识，变成了只会出现在野外生存指南里的内容。

就像现在我看 Primitive Technology 的视频时，虽然知道原理就是磨擦生热，但这种随时随地可以在几秒内生火这种操作，就像魔法一样。

旧科技和旧手艺失传

最近很多关于原画师们即将失业的讨论也表现了这一点。

对于画家/画师而言，他们的工作本质上是创作作品，而作品需要把心中所想通过画面表达出来。

受限于表达过程，致力于艺术创造的人们往往需要在绘画技巧上花费很多年的练习，才能满足创造作品所需的「表达想法」技巧需求。所以「磨练绘画技巧」这一中间步骤反而成为「画家」这一职业名字的一部分。

但是现在，通过 AI 们：比如现在流行的 Midjourney 或者 DALL·E 3，画家们可以跳过「磨练绘画技巧」这一步骤，直接把想法转换为作品。

如此的话，对于绘画技巧而言，就不再是画家的「必备技能树」上的一环，去磨练绘画技巧的人会变少，那么逐渐地，执笔绘画的技巧会逐渐失传。

AI 显然会导致一大波科技和手艺进入这个版本的淘汰圈。

职业融合

更进一步，画家产出的绘画艺术作品，满足的仅仅只是「视觉」这一感官的需要。但是伟大作品不应该致力于同时满足所有感官吗？

艺术家们当然想，但是以前很难做到。艺术家们受限于时间、技艺、教育、和表现形式，去创作一种同时满足「视、听、味、嗅、想象力」等所有感官的艺术作品太难了。

刚才提到的，艺术家需要磨练自己在操纵感官上的技艺。假如光是磨练一笔好画的技艺需要练 7 年，那么人的一生有几个 7 年可以用来练肌肉技艺呢。另外，创造满足不同感官的艺术作品需要学习对应的知识和理论。艺术家们能在磨练技艺之外留出多少时间去了解这些呢。

但在 AI 的帮助下，从一时间牢笼中释放出来的艺术家们将有机会创造这样的作品，不再局限于具体的形态、也不再局限于自己的技巧，他们只需要关于艺术的领域知识——甚至不需要是完整的领域知识。

于是，哪些依赖技艺而被拆分的职业得重新融合或者取代，新职业必须更接近最终目的，而不在乎中间步骤。

什么都懂的胜利

对于平庸有一种描述叫做「什么都懂一点，什么都不精通」。

现在，这种平庸不一定是坏事。如果一个人的领域知识广度足以覆盖整个行业，而深度恰好多于「能够评价任务执行的好坏与否」的程度，就可以比较好地操纵 AI 去完成那些本来需要好几个不同职责的人去完成的事情。

比如说电影。导演是那个对故事、还场景还原、对角色塑造、对剪辑要求最高的人。他的这些要求也就这些也催生了对造型、物料、美术设计、摄影、灯光等技术层面的要求。

只有团队中的不同角色，满足了对于技术与非技术方面的知识掌控，才满足导演对整部影片综合控制的需求——所以，即使电影是导演和团队一起拍的，但大家依然会认为一部电影是导演的个人作品。

所以，导演就是整个电影拍摄团队中具备最完整领域知识的人。

于是这种领域知识的完备，可以让他可以开始使用 AI 代替电影团队中的其他人，跳过其他职能培养过程中的所有花销，直接看最终成品。

以灯光为例。这位导演可能不是很懂具体灯光要怎么设置，但是他得很清楚自己的场景中需要那些角度，什么氛围的灯光，于是他可以用专业的语言告诉 AI 自己想要的结果，让 AI 做出更合理化的建议，并且输出到成品中供自己的检查。

如此这样，未来的导演团队里还需要专业灯光师吗？可能还需要，不过数量会大大下降，职责也会发生变化。

于是我们可以预见，也许很快就能看到仅由一个人完成的电影作品出现。

在科技公司里也会发生类似的事情。在 Sam Altman 在和其他人的赌约里表达了这样的态度之前，我和我身边的朋友已经在实践这个可能性了半年有余了——结果是完全可行。

以 Quail 为例。到目前为止，Quail 依然只有我和 AI 两位程序员，其中后者可能贡献了一半以上的代码。我也在提供 Tech Consulting 服务。在 AI 的帮助下，这个服务展开所提升的效能比研发更高，预计要比没有 AI 的时候高 10 倍以上（传统意义上的 Consulting 是一个很难横向扩展的业务）。

而我身边的一位老朋友，零客户端编程经验，AI 的帮助下从零开始做一个 ESL 程序，还编写了对应的方法论，已经获得了几千种子用户。

从这个角度看，去争论自己手里哪些事情是 AI 做不了的并引以为豪，是一件在未来可以引以为憾的事情。

你可能会问，难道公司给程序员付的薪资里，有一半都实际是 AI 的产出吗？

首先，这个公司可能不一定会付给这个程序员薪资了。
其次，如果公司依然愿意付钱这个程序员，那么这一半产出买的是他的领域知识，买的是他向 AI 提出合理问题和请求的能力。

知识就在那，但是需要你念出咒语才能让它显形。

思路打开

在人类历史上第一篇赛博朋克小说《真名实姓》里提到的互联网终端「Portals」很类似于现在 Apple Vision Pro 和未来脑后插管的结合体。不过它很省带宽：

You might think that to convey the full sense imagery of the swamp, some immense bandwidth would be necessary. In fact, that was not so ... A typical Portal link was around fifty thousand baud, far narrower than even a flat video channel.

您可能認為要傳達沼澤的完整感覺圖像，需要巨大的頻寬。事實上，事情並非如此… 典型的 Portal 連結約為五萬波特率，甚至比視訊頻道還要窄。

Portals 实际提供的是暗示，就像是舞台上的提词，具体的行为和情绪需要演员来呈现一样，Portals 里体验到的丰富的感官刺激来自于大脑对这些暗示的想象和补全。当大脑对现实世界和虚拟世界的体验都够多时，它就能理解这些暗示，渲染出最好的虚拟世界。

本质上 Portals 是在给大脑喂 Prompt，然后让大脑去挖掘合适的场景渲染给自己。

现在，我们需要做类似的事情，给 AI 提供 Prompt，从中挖掘出我们需要的知识。这样的过程本身也非常神秘学。就像《真名实姓》里说的：

Ultimately, the magic jargon was perhaps the closest fit in the vocabulary of millenium Man.
说到底，在人类几千年历史中，还是魔法黑话比较适合描述这样的事情。

伟大的巫师经常独自行事，只要空气中的元素依然回应他的咒语和呼唤。

不要总去人均 500 以上的地方吃饭

2024-02-10T22:20:58Z

之前在大手企业里打工的时候呢，有一次和大领导同步方案。我不是方案的撰写人，只是同步方案的时候，组里的人都要到场，所以我也在场。

頃に、大领导听完方案以后，沉默了一会儿，转向我的组长，放下雪茄的同时，唇缝里蹦出来几个字：「你不要总去人均 500 的地方吃饭」。

做产品设计，除了技能加点得像魅魔似的以外，还讲究一个环境熏陶：

比如说 Apple 是业内的榜一大哥，那自己就得用 Apple 全家桶。理由是 如果没用过最好的东西，就不可能做出最好的东西。

话这么说是没错，但如果忘了自己只不过是那个最高的浪头上那位幸运儿，这样由己推人的话，跟何不食肉糜就没有区别了。

在上海封城前夕，城市进入了吃鸡模式。每天会听到某个小区被封了。

有一天搭档打车下班回家，看到滴滴师傅车后面还放着行李箱，就问怎么还带这么多行李开滴滴。师傅说，家里小区封了，不能回去，这几周都在车上过。搭档说，为什么不回家睡呢？师傅说，不开滴滴就没钱了。

搭档突然才明白，并不是所有人都像她似的，在家也能工作也能赚钱，更多人只要被困在家里，就等于每分钟都在往窗外丢沓毛票。

与其说《北京折叠》是科幻小说，不如说是现实小说。

有次去 LA 拜访朋友，我问他怎么看待流浪汉的问题。他正开着车，于是指了指车窗，说：只要出门都开车，你在里头，流浪汉在外头，他们就不存在。

这席话让我想起之前有个失联很久的猎头来找我聊天，说自己欠了小贷还不起了，不敢跟家里人说。一听，大概 20 来万。

折叠呢，既发生在北京，也发生在 LA。

关于邮箱的一些冷知识

2024-02-04T15:13:10Z

做 Quail 一段时间了，经常要跟邮箱啥的打交道，发现一些事情还挺有意思，分享给大家。

很多很多人拼错自己的邮箱

常见的错误包括：

把 .com 写成 .con，.cmo，.cm，.comm
把 gmail 写成 gmial，gmal，gmmail，gmil，gnail
把 qq.com 写成 q.com，qq.cn

所有这些情况，是显然收不到邮件的。因为这种情况被判断出来以后，都不会尝试去发出邮件，自然也收不到了。

另外还有拼错自己的邮箱前缀的（也就是 @ 前面的部分）。这种情况有一部分也是能判断出来的，也会导致收不到邮件。

收件邮箱也是有评分的

很多邮件发送服务会提供 Email Validation 服务。比如 Quail 用的 Sendgrid 和 Mailgun。以 Sendgrid 为例，提供一个 Email 地址可以得出以下判断：

判断这个地址能不能发邮件：可发、有风险、别发
得分：当地址被识别为「风险」时，得分越低风险越高。风险高的话，邮件就可能不发了
详细情况，包括并不限于下面的原因：
1. 没配置 mx 记录
2. 是一次性地址（下面会提到）
3. 这个邮箱之前有拒收过邮件
4. 域名很少见
5. 域名太新
6. 这个域名下面发了很多垃圾邮件
7. 顶级域名有风险（下面会提到）
8. 邮箱不存在（一般常见于把自己邮箱拼错了）

所以不仅仅是会给发邮件的人评分，发邮件的人也会给收邮件的人评分的。

用特殊域名会降低邮箱可信度

现在很多新潮域名，比如 .xyz ，.cf，.cloud 什么的。

使用这些域名作为自己的邮箱域名的话，是有一定的风险的。

有的域名整体风险偏高。如果没有设置好邮箱配置，或者域名对应的网站没弄好，或者 TLS 没做，那么可能会一些邮件验证服务认为是高风险，然后被邮件服务拒绝发送。

因为邮件服务（比如 Quail）为了维持自己发信服务的 Reputation，对于这些被认为高风险的邮件地址可能会直接不发邮件。

使用临时邮箱

现在网上有很多临时邮箱和临时手机号收短信服务。如果用他们来注册的话，也可能收不到邮件或者短信。

因为这些也是可以被检测的。也是出于维持自己发信服务的 Reputation 的原因，不会向这些地址发邮件（Quail 就是）。因为发了也没有意义。

邮件中继服务会被认为是低、中风险

典型的包括 kill-the-newsletter.com，readwise.io，omnivore.app，ino.to 还有 Apple 的 privaterelay.appleid.com 。不是说他们不好，而是他们确实会被刚才提到的 Validation 当作中、低风险，降低得分。

如果发信服务有自己风控策略，因为这类服务较高的风险等级，可能就收不到邮件。

很多人的邮箱满了

听上去有点不可思议，这年头邮箱居然会满的吗？从发送情况来看，我发现一些人的邮箱已经满了... 自然就收不到邮件了。

来自东方古国的神奇网络故障

常见于新浪、QQ、网易邮箱。有时候他们会莫名拒收，拒收的原因据我观察有：

超时：这种情况直接收不到邮件。
发送成功，但收件箱里没有邮件：这种情况常见于邮件内容里有写古国不喜欢的东西。

以上。

文章里说的都是站在读者的角度的事情。作为发邮件的服务，比如 Quail 这种，需要注意的问题就更多了。如果你也在做发邮件的事情，遇到一些麻烦很难解决，可以问我，也许我能帮到你。

Mixin Safe 安全分析

2024-01-18T09:54:15Z

Mixin Safe 是 Mixin Network 在去年就公告要进行升级的资产管理框架，在去年 9 月被黑客攻击之前测试网已经在运作了，但是并没有上线实装。

考虑到发生了黑客攻击事件，未来尽快实装 Mixin Safe 肯定是一件迫在眉睫的事情。这里需要注意的是，Mixin Safe 不是一个 Mixin 主网的升级方案，而是一个有主网参与的独立的资产保管解决方案。根据它的介绍，任何个人和组织都可以通过使用它来增强自己在 Mixin 上的资产安全性。

也就是说，Mixin Safe 是一个可选套件：无论你是机构还是个人，如果希望增加安全性，就可以使用它。另一个说法则是，默认情况下，如果你只是使用 Messenger，不会直接从 Mixin Safe 受益。当然，Messenger 内置钱包的资产可能也会用 Safe 管理，但不满足「not your keys, not your coins」这样的原则。

常说没有 100% 的安全，被黑是迟早的事——但是不能用这样的理由来躺平，毕竟可以通过各种手段来提高被黒的门槛。因此，作为 Mixin 生态中的开发者，肯定要对包括 Mixin Safe 在内的可能的资管方案都做一番分析，尤其是在黑客攻击事件之后，安全方面的分析就非常重要，毕竟这影响到是否要使用 Mixin Safe 方案这样的决定。

重要提示 & 免责声明

本文只代表我个人的观点。
本文只对基本机制分析，受限于我的知识与能力，不保证内容的完整性和准确性。
本文只对当前 Mixin Safe 版本分析，不保证时效。
本文不对任何内容中提到的产品、服务、方案背书，不构成任何投资建议。
本文所描述的各类风险并非方案缺陷，而是各类最坏情况发生时的假设。

分析范围

我直接略过了官网，从 Mixin Safe 的技术说明书开始读。这里是地址。

另外还有部分代码，都在这里。

概览

首先可以得到如下简单的事实：

Mixin Safe 的金库本质上是原生链上的多签。如果用 Mixin Safe 保管 BTC，那么使用的就是 BTC 原生的多签脚本来管理 BTC；如果保管的是 ETH，那么使用的就是 ETH 合约来管理 ETH 和 ERC20 资产。

因此：

如果链不提供多签能力，那么 Mixin Safe 就无法支持。
如果链提供多签能力，但是 Mixin Safe 还没有支持，这个链上的币无法放入 Mixin Safe。

接下来技术说明书都以 BTC 为例来讲原理。

每个 Mixin Safe 金库的底层都是一个 2/3 的多签，多签方分别为：

Holder：金库管理人，也就是 Mixin Safe 的使用者。
Signer：一个 MPC 去中心化网络，称为 Safe Network。其 Safe 节点的参与条件为必须先 Mixin 主网的节点。也就是可以看作 Mixin 主网的子集或者全集。
Observer：默认是 Mixin 团队，实际实体应该是 Mixin Ltd 香港公司，负责 Safe 的研发和商业化。

资金操作需要三方中的两方签名后才能执行。

其中：

Holder 会要求创建一个 BTC 私钥。在创建金库时，会问创建人要这个私钥对应的公钥。这个私钥的来源没有限制，目前为了流程的方便支持 Bitcoin 官方钱包、硬件钱包 Ledger 和 Mixin 团队开发的手机 App Mornin Key。
在创建多签金库时，会给 Observer 创建一个 BTC 私钥。
Safe 使用的 BTC 脚本创建了一个相对时间锁，这个时间锁的时间是可以定制的。默认时间锁会在 52560 个区块后释放。假设每个区块 10 分钟，大概就是一年。
Observer 的私钥默认是 Mixin 团队持有，但是可以定制为金库的创建人，也就是 Holder 提供。
Signer 的外在表现的形态是协助管理多签资产的共管人，实际上是 Safe Network 的多个节点，这些节点控制私钥。
在使用 Mixin Safe 时，设置其他 Mixin Messenger 用户跟你共管资产时，共管人并没有私钥，只是有权限去操作 Signer 去签名交易。
也就是说，Mixin Safe 方案里有两层多签：第一层是资产所在的链的多签，是一个 2/3 多签组；第二层是 Signer 上资产共管人的多签，是 Mixin 上的多签，是一个 N/M 多签组，其中 N 和 M 可以设置。

风险分析

合约或者脚本漏洞

Mixin Safe 使用的 Bitcoin 脚本和 Ethereum 合约都公开在了 Github，可以在这里和这里查看。

其中 Bitcoin 脚本非常简短。Ethereum 合约使用的是 Safe Global 的合约。这个合约如果出问题的话，Safe Global 上 $790 亿的资产都会出问题。

我不是合约安全专家，暂时未对脚本和合约做深入分析，只是粗看没问题。

资产窃取

对私钥的窃取

根据 2/3 多签的特性，当其中有两个私钥泄漏时，资产就会失窃。

那么有三种可能性：

Mixin Safe 主网 Signer 被攻破且 Mixin 团队管理的 Observer 私钥被窃取，然后等时间锁解锁。
Mixin Safe 主网 Signer 被攻破且金库管理人掌握的 Holder 私钥被窃取。
金库管理人掌握的 Holder 私钥被窃取且 Mixin 团队管理的 Observer 私钥被窃取，然后等时间锁解锁。

对于金库管理人来说，总会对自己管理的私钥有信心，而担心另外两份私钥被窃取。对黑客来说，攻击 Mixin Safe 主网和 Mixin 团队确实是潜在收益更高的做法，那么影响最大的情况就是上述的第一种可能性：

Mixin Safe 主网被攻破且 Mixin 团队管理的私钥被窃取并且等时间锁解锁

对于这种情况，Mixin Safe 给的解决方案有两个：

在时间锁解锁之前，将资金转走。
在创建金库时，由 Holder 指定一个 Observer，该 Observer 私钥不由 Mixin 团队管理。

对于解决方案 1，虽然攻击者时间锁解锁之前都拿不走资产，但是攻击者可以等待，之后择机拿走资产：因为粗心的金库管理人可能忽略了时间锁解锁，没有及时转走资产。

这里暗示了一个使用 Safe 的最佳实践，即金库管理人一定要在时间锁到期之前转走资产到新的 Safe 金库或者其他地址。因为一旦时间锁解锁，此时金库的风险敞口会变大。

反过来，这也暗示了时间锁的意义之一：

在一段时间内确保，即使 Mixin 团队管理的 key 丢失，金库的安全性不被这件事影响。

对于方案 2，等同于 Holder 同时管理 Observer 私钥，那么这个 2/3 多签本质上退回到了 2/2 多签，其中 Observer 是 Holder 的一个延迟备份。攻击者需要同时攻破 Mixin Safe 主网和窃取管理人手中的任何一个私钥才行。

这样降低了 Mixin 团队管理 Observer 私钥的风险，但是也对金库管理人提出了更高的要求。

对 Signer 的拒绝服务攻击

刚才提到，Signer 实际上是 Mixin Safe 主网控制的，它是一个由一群服务器组成的在线服务。因此，即使攻击者无法攻破它获得其管理的私钥，也可以对它进行拒绝服务攻击，让它瘫痪。

在 Signer 无法工作的时期，如果攻击者具备一些特殊条件，那么也可以对资产窃取。

例如：如果攻击者获得了 Observer 私钥和对应的 Holder 的私钥，然后他还知道这个 Observer 对应的时间锁解除时间。此时，攻击者使用某种方式瘫痪了 Safe 主网，导致 Signer 不正常工作。如果在这期间时间锁过期，攻击者就可以人为地构造一个让金库管理人无法在时间锁过期之前转移资金的时机，从而攻击得手。

因此，金库管理人还需要预留攻击者瘫痪 Safe 主网以后恢复的时间，不要拖到时间锁快过期才去转移资产。

供应链攻击

即攻击 Safe 主网节点、Safe 的网站业务、Mornin 钱包的源码，在其中加入恶意代码。

注意

供应链攻击并非针对 Mixin Safe 方案机制的攻击，所有软硬件钱包都可能遇到。在此仅评估如果发生供应链攻击，对 Mixin Safe 的影响。

这里分为几种情况：

在 Safe 主网节点中加入恶意代码会导致 Signer 的私钥泄漏
在 Safe 的网站中加入恶意代码虽然不会有私钥泄漏，但是可以通过钓鱼和诱骗等手段欺骗 Holder 和 Signer 的共管人的签名。
在 Mornin 钱包中加入恶意代码会导致 Holder 的私钥泄漏，但是攻击者需要知道每个私钥作用于哪个多签地址才能实施攻击。

在最坏的情况下，Signer 和 Holder 的私钥可能因此泄漏导致资产损失。不过隐藏好多签金库的信息的话，会降低被攻击的概率。具体的方案有：

不使用 Safe 的网站，而是自己写程序去操作。
不使用 Mornin 钱包管理 Holder 私钥，而是使用其他钱包。
私有化部署 Safe 网站和关联服务，降低开放服务的风险敞口。

当然，这些都会提升使用的难度和门槛，也是提高安全性的代价。

多签的回退

刚才提到，如果管理人定制了 Observer，那么 2/3 多签实质上回退到 2/2。这是底层链的多签的回退。考虑到 Signer 的共管人实际上是 Mixin 上的多签，这一层多签也是可能回退的。

例如，如果在创建金库时，选择了金库的多签阈值为 N=1，则 M 个共管人中，只需要收集一个签名即可转账，此时的底层多签实质上回退到了 1/3 —— 因为资产管理人也是共管人之一，当 N=1 时，实质上 Holder 和 Signer 保持了「共同投票」，此时资产管理人自己就可以操作其中所有资产。

资产不可用

在「资产窃取」章节，我分析的是机密性。但是作为安全的一环，可用性也重要。如果可用性没了，对应到加密货币资产，就是这些资产能看到，但是不能取回来。

多数私钥遗失

由于 2/3 多签的特性，如果其中有两个私钥丢失，则这笔资产就无法操作了，也分为三种情况：

Signer 不可用 + Mixin 团队的 Observer 私钥丢失
Holder 管理人自己的私钥丢失 + Mixin 团队的 Observer 私钥丢失
Signer 不可用 + Holder 管理人自己的私钥丢失

其中 Signer 不可用的一种情况在上一章「对 Signer 的拒绝服务攻击」有提到，不再赘述。另一种情况是 Signer 上的共管人遗失了访问权限——不过这不属于系统设计上的问题，不表。

总之，以上三种情况如果发生，会导致的这些资产虽然没有被窃取，但是从此也无法将它们转出多签地址。

时间锁的影响

另外，由于时间锁的特性，在时间锁生效的时期，正常运作的 Safe 本质上是回退到了 2/2 多签，这个时期都可以认为 Observer 私钥是不可用的。

如果此时 Signer 不可用（刚才提到了）或者 Holder 私钥丢失，那么这部分资产在时间锁解除锁定之前，都是不可用的。

如果资产的价值有时效性（例如时间锁解锁以后不值钱了），那么管理人需要考虑这一风险。

信息泄漏

信息泄漏不会导致直接的资产安全问题，但是有的攻击手段需要知道一些相关信息才能实施攻击。

例如，如果攻击者拿到了 Holder 的私钥，那么他需要知道这个私钥对应的是哪个多签金库，才能对这个金库的共管人或者 Mixin 团队实施欺诈。

目前 Mixin Safe 使用 SegWit 上的脚本，而不是 Taproots。如此这般的话，当一个 UTXO 被消费以后，对应的脚本会随着暴露，多签参与人的信息也就随之暴露。暴露的信息可能有一些安全和隐私隐患。

其他安全问题

略

其他资管方案

目前的研究中，主流资产中只有 Ethereum 有最成熟、可用性最好、并且最灵活的多签解决方案，即 Safe.Global。其他大部分主流链的资产的支持都不太好：有的是不支持多签名，有的是缺少好用的方案，有的是不开源，有的是缺少对硬件钱包的支持，各有各的问题。

我觉得 Mixin Safe 提供的开源方案有一定的吸引力，也有一定的风险敞口。如果选择 Mixin Safe，它的配置也可以很多样，需要根据实际自行调整。

Quaily 订阅者超过 9000人了，主要是想给我的朋友们带来笑容

2023-12-17T07:15:30Z

前几天和一个新认识的程序员盆友聊天，他问我最近在做什么，我说在做一个叫 Quail 的内容付费服务，然后我就给他看了。他问我为什么想要做 Quail，我说主要是想给我的朋友们带来笑容。

If you build something you and your friends want, you never have to go find users. You already know them.
— Paul Graham (@paulg) May 2, 2019

初衷就是这样，我之前也提到过的。

然后我看了一下统计，从七月七日 Quail 开放注册到现在，Quail 的订阅者居然超过 9000 人了。他就问我在哪做了 Promotion，我说几乎没有做过 Promotion，主要就是仰仗朋友的支持啊。他说你的朋友真好。

我也觉得。对于各位支持我的朋友们，无论是作者和是读者，真诚地感谢各位。

下面是对一些近期在更新的 Newsletter 的介绍。这次先介绍 10 位。如果其他作者希望我推荐的话，也欢迎联系我。

AIGC Weekly

由 @op7418 设立的 AIGI 周报。每周一更新，主要介绍上周AIGC领域发布的一些产品以及值得关注的研究成果。

可能是东半球最好的中文 AI 相关资讯周报，没有之一 🤑。

橘子汽水铺

by @oran_ge，来自一线 AI 产品经理的 Newsletter。既有 AI，也有产品领域的深度思考。

每次跟橘子聊天，都有写文章的灵感 💡。

王一石

曾经创办币信和 OneKey。@ohyishi 的文章阅读任何一篇都值回票价。

虽然会员费是最贵的，但也是会员人数最多的 🤑。

向阳乔木

一个爱钓鱼、喜欢听摇滚乐、每天洗冷水澡的PM，@vista8。

不过已经很久没更新了，请继续更新吧📅！

CreativityOverflow

@goldengrape 他会写程序，会玩音乐，会用 AI 写程序做音乐，会写程序做眼科光线研究，会用 AI 写程序做眼科光线研究 ....

他可能是我认识的最强的医生？真的还是医生吗👨‍⚕️？

余晟以为

@FreiheitYu 是著名的非正统技术爱好者，至今已翻译出版《精通正则表达式》、《技术领导之路》、《程序员的职业素养》等作品，合计字数超过一百万，并得到很多读者的肯定。

我小时候经常可以从余老师这里得到全肯定👍。

基本常识

可能很多华语读者都知道这位著名的科普作家，项栋梁老师的专栏。他从 2015 年一直做科普至今，一直都关注他。

在中国做科普有多么不易，大家应该知道吧...

二〇四〇

@dbarobin 的 Newsletter。他是一位 Bitcoiner, Investor, and Digital Nomad。介绍了很多加密货币、数字游民相关的内容。

精神和经济都要自由⚖️。

未來交易週報

@austinsayhi 关于投资的 Newsletter。

他说，「看過的人都表示內容準的像是未來人寫的，所以名為未來交易周報」🔮。

猫鱼周刊

@阿猫创造的软件技术相关话题的周刊，他今年 11 月才刚开始创刊。

他希望大家支持他不要让他随便弃坑⛳。

因为这网页的空白处有限，所以先列了十位作者，之后发现有趣的作者还会继续介绍给大家。再次感谢！

质疑 PHP、理解 PHP、成为 PHP

2023-11-15T00:26:00Z

故事的起因是这样的。

我哥们在某著名大厂干运营，他有一个程序员男朋友。最近他总埋怨男朋友不思进取，很嫌弃。

于是我问怎么看出来他不思进取，我哥们说，他用 PHP。

现在的我有点后悔当时的回答：「PHP 确实有点ちょっと...」... 俺错了！希望他们没分手！

但是，技术上不思进取在感情上有什么错？！

用的宾语是谁？

重点是，PHP 有什么错？PHP 在 2023 年 11 月 9 日还发行了 PHP 8.3.0 RC 6 版本...

现在是个信息爆炸的时代。但凡不是我主动搜索的信息，我有一个习惯，那就是不会主动去追热点。

因为我相信着一种「信息涟漪回响」的现象，可以这样表述。

把舆论场看作一个水池，在其中传播的信息就像水池中的涟漪。当它传播到水池边缘或者水池中冒出来的 KOL 时，会形成回波。

当一个能量很强的涟漪出现时，它会在水池中来回荡漾好几轮。

就像这样：

所以，如果一个信息足够强（足够重要），它总有机会出现在我面前。

所以，我一直觉得，如果一件事物很重要，那么最终是它走向我，而不是我走向它。

新技术也是这样。

比如说，我一直没学 k8s，甚至也不主动用 docker。既然它没有走向我，那么一定是因为我不太需要它。

说起来，对 k8s 的糟糕印象来自一件事情：

我哥们当时就职于一个很小的团队。有一天，公司的官网 down 了。我哥们对此满头问号：因为官网是一个纯粹的 Tailwind 静态网页，我哥们不理解为什么会看到 504 timeout。

于是我哥们在 Teams 里问负责运维的同事。

对方的回答让我哥们当场崩溃，原来所有的前端站点、SPA 都被打包成 Nginx 的镜像，并且通过集群的 ingress 来管理他们。

这波 DevOps 技术推广得很好，下次别推了。

最近还有一件很离谱的事情是 Next.js 14。

虽然我一直把 Vue 和香草 Javascript 混搭着用，但是也会稍微看看 React 侧的发展。Next 14 的操作确实让我有点震惊。

作为一个长期用各种语言挖坑的人，我非常理解前端工程师要解决什么样的核心问题。但是作为企业经营者，我也非常清楚如果放弃这些看上去很 fancy 的东西可以让我多舒服——我选择放弃。

不过想到他们这么瞎折腾还能赚钱，我又很羡慕他们。

大概，
这
就是
新时代的
艺术家阶层？

毕竟，古代的人类，能研究艺术和宗教的都是权贵。

好想开了。

我只是想和人民群众站在一起

回过头来，随着年龄越来越大，时间越来越少，我变得越来越不想在技术上锐意进取了。当然，这不代表我躺平了。我依然在学习，终身学习是我的信条。

我只是不再刻意追求新的技术潮流——或者自信点，去掉「技术」

我觉得这应该和经验的增长（aka 越老）有很高的相关度。经验越多，就越想总结一套「大一统」的框架去描述新事物。这个倾向有好的一面，也有不好的一面。

好的一面，当然，这是一种抽象。抽象很强大。

不好的一面，我们通常把这种情况描述为经验称为思想的枷锁。

当然也可以理解成手速慢了。

人们经常用「过气」来形容人或者东西：曾经强大，然而却今非昔比了。

在美国俄亥俄州克利夫兰有一个摇滚名人堂（英語：Rock and Roll Hall of Fame）。这里专门记录历史上知名的和有影响力的摇滚乐音乐家、制作人、工程师和所有对摇滚乐有贡献的人。

按照现在的说法，他们都是「过气」音乐人，他们应该穷困潦倒，他们应该上专门消费「过气」艺人的节目。

这个节目还要、应该、必须，把查克贝利的 AI 数字人拉出来表演，然后让 GAI 当评委发表一些评论。

有没有一种可能，
我只是说一种可能，
其实你没有过气，
只是
你的客人他们来得太晚了。

最后欢迎大家订阅我的 Newsletter。订阅的方式有三种：

在下方输入 Email 地址
点击下方的 RSS Feed 的图标，可以用订阅器订阅更新
点击下方的 Telegram 图标，可以使用 Telegram 订阅

当然，我的 Telegram 群也随时欢迎大家： https://t.me/lyric_discussion

谢谢（with respect

AI 淘金热：是撸起袖子亲自淘还是卖铲子呢

2023-11-10T08:44:40Z

在之前一段时间，我写了好几篇跟 AI 相关的文章：

自己的团队也尝试参与其中，但目前我们团队的 AI 项目都停滞了。

比如作为核心项目的框架 Botastic 五个月之前就已经停止提交了。另外一个闭源的商业应用型项目也暂停了。

刚好前几天，我有一位朋友来找我咨询。他有一个 AI 应用项目，但是他对这个项目的前景感到迷茫。于是我说了一些想法，这些想法基本上也是我暂停所有 AI 项目的原因。

结合 OpenAI Dev Day 向外释放的信息，基本印证了我的想法。

卷

如果只关注于纯粹的 AI 项目，不得不用「卷」—— 「竞争激烈」来形容这一现象——金矿吸引了众多淘金者，而卖铲子的商人也不在少数。

在这场淘金热中，尽管芯片领域仍旧由 Nvidia 主导（至少目前来看是这样），但其他 AI 领域则都塞满了人。

「卷」的另一面是「窄」。那么大的应用市场目前仅仅被挖掘出屈指可数的几个有效的商业化场景，空间尤为狭窄。

首先最容易想到的 Prompt 工程。虽然刚开始，大部分 Prompt 产品只不过把有用的 Prompt 列出来，但未来 Prompt 工程肯定是工作流的一部分，而且与使用的 LLM model 有很强的相关性。虽有门槛，但是技术上... 但凡说它有一些技术含量，也不至于被拿来调侃。

然后，最容易想到的也是最粗暴的应用是 AI 平替古典功能。例如涌现的众多的外语学习 App，把之前比较难做的场景对话改成调教过的 AI 角色就行。但作为特别典型的套壳应用，把 OpenAI 或者其他供应商的批发 API 改成零售，在技术上没有门槛也没有创新性。

其次是 RAG，用 LLM 解读基于既有内容的一类服务，比如客服机器人（包括我们做的 PAL9000，这类服务也没有什么技术门槛可言。

工具类产品，比如 ChatPDF 这类；或者娱乐性产品，比如妙鸭相机这类；或者提供情感价值的产品，例如 janitor.ai。当 OpenAI 这样的基础服务提供者，直接变成一个产品公司，亲自下场开始做面向终端消费者的产品以后，他们的处境大概会变得很微妙——用户的时间就那么多，谁都想做入口。

Agents 或者助手的话，我觉得应该挺有很有戏，但我觉得难点不是 AI，而是用户体验，需要缓慢打磨。

总之，要么需要在其他方面上下更多功夫，比如提升用户体验、比如保护客户关系—— AI 是银弹，但不是你我的银弹；要么必须在 AI 技术本身上展现出独特的竞争优势，去拼算力和数据，走上一条充满荆棘的道路。

穷

以开发英语学习应用程序为例，要使 App 在单位 token 成本上低于 OpenAI 投资的 Speak 可能是一项艰巨的任务。不仅成本要低，LLM 的响应速度能否超越 Speak，似乎难上加难。

或者，如果如果计划做个 Code Assistant，那么能否在速度上超越 Github Copilot 生成的提交信息呢？更重要的是，能保证生成的代码在质量上胜过它吗？

早晨看到这条，扎心地笑了。

投资人睡醒后的第一件事，就是询问相关创业者：“你们和OpenAI所做的差异性在哪？”。

创业者回复：“差异性就是比他差。”
— Orange AI (@oran_ge) November 8, 2023

如果仅仅是使用这些 AI 供应商的 API 和服务，将不可避免地发现自己在价格上与他们竞争。如果打算自己培育 LLM，那么在算力和数据集方面与他们的竞争也不可避免。

咋搞呢

第一个重要决定是：走向面向消费者的产品路线，还是去做企业市场。

	面向消费者的产品	面向企业的产品
市场规模	大，可以迅速扩展到大量用户	相对小，但每个客户价值较高
收入模式	多样化（订阅、广告、应用内购买）	通常基于订阅或长期合同
客户行为	受情感和个人偏好影响较大	更理性，基于效益和成本分析
市场反应	快速，可以快速适应消费者需求	较慢，需要长期规划和调整
营销策略	社交媒体推广、口碑营销	直接销售、行业合作、展会营销
产品特性	需要不断创新，追求趣味性和酷炫	重视可靠性、定制化和专业服务
盈利潜力	低成本、高覆盖，潜在收入波动大	单个客户价值高，收入稳定
客户忠诚	低，易受新产品和趋势影响	高，建立后难以更换供应商
初始投入	相对较低，快速上市	较高，需要针对性开发和调整

具体做什么，没有通用解，取决于各个公司自己的资源和特点。不过总体来说，可以参考下面的一些条件：

有做消费者产品基因的团队建议做消费者产品

现在这个阶段的 AI 消费者产品，门槛低、无痛点，很难因为什么独一无二的功能得到用户们的普遍青睐，于是又回到了比拼硬产品力的状况。

一方面，消费者对体验的追求是无上限的。另一方面，消费者的购买决策成分里有大量的非理性成分。就拿让人类的劣根性发扬光大这一点来看，只有有消费者产品基因的团队才能做得好。

能把 AI 无感知地融入到现有使用体验中的话，建议做消费者产品

前段时间有关于在 AI 时代下，基于对话的界面（chat/conversation-based interfaces）是否会代替 GUI 的讨论 ——这种讨论的结论总是相同的而且没有太多意义：一部分能代替，一部分不能。重要的在于哪些能哪些不能。

如果我们把软件看作一系列功能的集合，那么这些功能的操作可以看作一颗流程树，那么目前的 GUI 是在这棵流程树的上的一系列切片。

GUI 的优势是它的切片是稳定的。好的 GUI 可以让用户感到安心：我想要的东西它就在那里。

GUI 的劣势是「稳定」的背面，即它的信息架构是固化的，它很难通过上下文去提供给用户当下最优的流程。

在 AI 时代之前，也有一些场景是「基于对话」的，但是他们要么不够聪明——没法很好从下上文做推断，知识贫乏也给不出好的答案——例如 AI 客服；要么规模很小、流程很短——例如搜索和推荐，属于用完即走的小型流程。

回过头来，虽然未来一部分 GUI 会被基于对话的交互代替之，但是大部分 GUI 是无法被替代的。但这种情况下，AI 对此并非完全不可为。使用 AI 的话，一些原来很难触达的用户需求可以被感知，一些原来优化成本很高的流程可以也被优化。

已经身处某个管制市场，建议做企业产品

哈，这是自然。

如果您也在考虑这件事的话，并且感到焦虑的话，欢迎联系我的 Telegram，也许我可以给您一些帮助。

学日语的一些乐趣

2023-11-02T06:14:21Z

刚来日本的时候，听过一个段子：

有个日本老板往中国发货。发货时，他叮嘱伙计不要用废弃的报纸来包裹货物。

伙计问他为什么？

他说，上面都是汉字，中国人能读。我们用报纸报东西，报纸上这些东西在中国被人读到了，可能会害了我们的中国客户。

中国人是能读懂不少日本汉字，不过这个日本老板也挺能读懂中国。

能读汉字，确实对学习日语很有帮助。我的第一本日本语教材上一个汉字都没有，对此还觉得很奇怪。结果我的老师告诉我这本教材是为了照顾「students from western countries」，所以上面没有汉字——我一下子就理解了。

早期日本虽然有语言，但是没有自己的书写系统，因此随着佛教从中国传入日本，最早的佛教徒也把汉字作为最早的书写系统引入日文。

但是因为汉语和日语并非同一个语系，于是后来发明「假名」以后，汉字和假名就构成了最初的日文书写系统了。接下来假名演化出了今天的「平假名」，用于拼写各类变形和日语词汇。在差不多的时间里，「片假名」也被僧侣们从汉字中拆出来，最初用来标注汉字的发音。

再后来日语的词汇就慢慢定型了，大致可以分为三种：

和語
漢語
外来語

其中和語就是日语本来就有的词汇，用平假名拼写。例如：おはよう（早上好）、わたし（自称）、が（助词）这样的词。

漢語一部分是古代就从中国传入的词语，例如「世界」「学問」「親切」；另一部分则是后来使用汉字创造的词，例如「電話」「文化」「安全」等等。

外来語里大部分都来自英语，小部分来自其他语言（也包括现代汉语）。比如コンビニ（便利店）是对英语「convenient store」中「conveni」的音译；パソコン（电脑）是对英语「personal computer」中「person-com」的缩写（对，就是这么怪）。他们大部分会用片假名来拼写。

于是现在外来词常常用来表达新出现的概念和东西。甚至，已经有日语或者汉字名字的东西会被用外文词重新表述。比如「めし」是「米飯」，「ご飯」也是「米飯」，「ライス」是英文「rice」的外来语，也是「米飯」。

不过这些外来词和本土词在含义和细微差别上有细微的差别。例如「牛乳」和「ミルク（milk）」都是牛奶是差不多。不过「煙草」在零售领域基本称为「タバコ（tobacco）」。「おさけ、ワイン、アルコール」虽然都是酒，但是「おさけ」一般都指日本酒，「ワイン」一般指水果尤其是葡萄酿造的酒，「アルコール」则是对酒类的统称。

总体来说，使用「漢字」时给人正式严肃的印象，外来词给人新奇的印象。

甚至有很多外来词已经和源语言没什么关系了，对于源语言是英语的外来词，也可以称为「和製英語」，例如「panelist」应该写作「パネリスト」，但是「パネラー」被构造了出来，表达的也是同一个意思，虽然并没有这个英语单词。

实际口语中，一些非外来词也会用这种方式来压缩，并且片假名来拼写，比如「キモい」表达「恶心」，诶就是嫌弃别人的时候说的那句，是「気持ち悪い（きもちわるい）」的简写。

所以年轻人喜欢用外来词（或者伪外来词）是一个很普遍的现象。不管是不是个英文单词，反正酷就对了。

这类情况在汉语里也有出现。例如「笔记本」->「电脑」-> 「本儿（东北话）」-> 「mbp」。再比如「厉害」->「永远的神」->「YYDS」

在日常书写和表达时，通常会在一个句子里交错使用汉字、假名和标点「、」。例如：

暑いと、プールへ行きたい（好热，想去泳池）

这个句子就很易读，因为一眼就能看出暑い、と、プール、へ、行きたい。如果全部使用假名的话，看起来就会很困难：

あついとぷーるへいきたい（haorexiangquyongci）

感觉就像中国人看纯拼音似的。

关于外来语我想多说一点。

之前网上有一个图片，用来表达片假名之恶毒：

其实现实情况倒是没有那么奇葩，这张图有点为了黒而黒的意思。如果访问 Qiita.com 这个程序员网站，会发现该用英文时还是会直接用英文的：

Python 就是 Python，不是「パイソン」。Raspberry 也不是「ラズベリー」。

看样子，日本的程序员也和我的看法相同，行业内的词不如直接用英语。

不过我觉得现在日语里多多少少有点滥用片假名的感觉，但我又很理解。新词汇进入日本以后，如果没有合适的现有词（汉字组合）去表达它，用片假名拼写确实是一种做法——毕竟不是所有人都会英语——但，真是一种很偷懒的做法。我还是比较怀念日本学者用汉字翻译外来词的时代。

虽然日语有大量词汇来自中国，但是文化交流是双向的，因此到近代时也有大量的和制词汇，从日本传回到中国，称为「和制汉语」。于是我们现代汉语中有很多词，都来自日本。

其实这种词又可以细分为三类：

中国本来就有，但是在日本获得了新的含义，比如：電気、電報、地球、銀行、化学、直径、風琴、料理。
日本用中国古典籍的词来翻译其他外来词，比如：革命、文化、観念、福祉、文明。
日本创造、流入中国的新词，比如：電話、情報、科学、哲学、喜劇、美学、神経、軟骨。

第一类的典型的例子是「銀行」：

汉语中原本的「銀行」表示的意思是金银器店，卖贵金属和首饰的地方：

银行，今金陵坊银行街，货物所集；花行，今层楼街，又呼花行街，有造花者。诸市但名存，不市其物。
——《集庆续志》

但是到了 1851 年，美国传教士裨治文《大美联邦志略》传入日本，并进行了翻刻，于 1864 年在东京出版，写到：

邦中杂税所入，每年凡银二百数十万，如银行年中入租银六十万。他如民间银行，在邦都者，现存本银约三千五百万。

这里的银行已经是「bank」这个现代含义了。所以现代汉语中的「银行」本来是一个汉语词汇，但是它最普遍的现代含义源自日本的「銀行」。

当时这些来自日本的汉语词传入中国时，其实有很多人反对。例如学者彭文祖就觉得「取缔」应该改成「禁止」，「场合」应该改为「时、事、处」，「第三者」改为「他人」，「动员令」改为「动兵令」，「打消」改为「废止」，「目的」改为「主眼」，「取消」改为「去销」，「手续」改为「次序」等等。

但是很遗憾，这些阻力没有奏效，以上和制汉语都已经进入了现代汉语。所以各位读者，你平时说的话有很大一部分都在用日本词呢。

很多人误以为除了中国大陆以外的地方都在用繁体，其实这是不对的（甚至每个地区的「繁体」都不一样）。日本在 1946 年以后，就把很多汉字进行了简化。有一些，使用了和中国简体一模一样的字形，比如「国家」的「国」（Unicode: U+56FD）

但是有一些，则是完全不同的写法和完全不同的 Unicode 编码，比如「变更」的「变」（U+53D8），在日文汉字写作「変更」的「変（U+5909）」。

有一些字虽然 Unicode 编码相同，但是由于地区性简化的原因，在不同的字体下会有不同的表现。例如「生意兴隆」的「隆」的 Unicode 都是 U+9686，但是在中文字体下显示为「隆」，在日文字体下会显示为：

诶，对咯，少了一横。可以在支持日文的系统（比如 iOS）下打开网页 RYU（隆）这个链接，看看里面「街霸」里「隆」这个角色的名字的写法。

最后放个广告，我的日语老师最近在招生。我觉得她教学专业、耐心、负责，价格也非常实惠。她们有专业的日语教师团队，无论是考级、留学、在日本生活和工作，我觉得她都能给很好的帮助。所以我已经两次续报她的课程了（我的这位老师日程已经满员了，和她同工作室的其他老师也是可以的：），不用一窝蜂地去找同一位老师，否则其他老师会很伤心）。

对于已经在日本，或者想要来日本的朋友，或者单纯想要学日语的话，不妨考虑一下她的一对一课程。如果有兴趣的话，可以访问她的网站了解一下大概的课程，然后扫下面的微信二维码试听。现在联系她试听的话，同时提供我的邀请码「lyric」，试听课直接打五折哦。

怎么让大公司不抄你

2023-10-22T10:33:31Z

几年前，在创业者拿 VC 钱的黄金年代，总会遇到这样的 VC 大哥，他们问「大公司抄你怎么办？」。

其实大哥你真的多虑了。大多数情况下，这个问题根本不需要担心：大部分产品都发展不到被大公司抄的程度。

~~（全文完）~~

抱歉，还没完。

现实确实如此，大部分产品确实活不到被大公司正眼看的阶段。回答这个问题就像存在大过滤器的宇宙里，回答「遇到外星人要发生第一类接触时要怎么办」一样。不如去花精力解决当下的问题。

不过，真遇到被抄的情况，如果去接对方争辩，「借鉴不能算抄……读书人的事，能算抄么？」接连便是难懂的话，什么「致敬」，什么「有态度」之类，搞得大家都很难看。

像素级的抄袭况且维权困难，那如果对方进行业务模式上的复制，阁下又该如何应对呢？

大公司做这件事可能还挺棘手

不知道大家觉得一个细分市场的消费型产品拥有 DAU 1000 万是个什么水平。相信很多人会觉得相当不错——我也觉得。

但是对于掌握十亿级流量入口的大公司来说，如果在流量池中给这个 DAU 1000 万的新产品开辟一个入口，公司需要斟酌。因为都有十亿级流量了，即使在入口上放坨屎，每天也能有大几千万人来尝尝鲜。那么具体放哪坨，用什么姿势放，很需要仔细考虑。

首先营收肯定有影响

一个新的产品，它的用户所贡献的价值和生命周期不同，考虑营收就是一个运筹学问题。新产品上线了，会不会给一直提供可靠营收的老产品分流，然后影响到公司利润啊？

当然，虽说新产品可能让短期营收下降，但是也许、可能，长远看能为公司拓展业务边界、找到新的增长方向、赚到更多钱也说不定。但即使公司有一群勇于冒险的管理层，也得兼顾对利润尤其敏感的股东们的感受。

小团队可不在乎。本来小团队就没有别的营收可以被竞争，做好这唯一的产品就是最好的营收渠道。

其次公司内部可能有对资源的竞争

既然新的产品线可能影响到营收，那么动老业务线的蛋糕就更加现实了。

同一个公司里大家能在同一家公司里工作，除了五百年的修行，也是因为当下大家的短期目标是基本一致的。但凡说基本一致，就说明有很多不同。公司的高层、中产、员工的诉求完全不同；不同的业务部门的 KPI 还会产生矛盾。

在这种情况下，也不知道新业务线的负责人，约老业务线的老哥一起喝咖啡谈心妥当了没有。

小团队也一般也没几个主营业务，当下的小产品就是最大的业务。大家能一起在这个小团队里共事，那必须得是一条心的一个战壕里的同志。

一个 Product-Market Fit，两种解释。

总之，新的产品既然是创新，很可能稍微破坏一些公司既有的东西，不仅仅包括营收、团队目标、还有品牌基调和战略。对于大公司来说，都是一种冒险。

尤其是所有拥有亿级流量的产品的公司，都可以自称为「网民的基本盘」。既然是基本盘，那他们的目标用户群就是所有人，做出来的东西也就必须差不多。也就意味着产品设计时要放弃一些个性，因为他们不可能放弃基本盘，这是属于基本盘的路径依赖。比如说，微信作为一个通用通讯平台，它几乎无可能掉转车头去做陌生人交友。

这就跟连锁餐厅一样，你知道他们的菜品的质量肯定稳定，能照顾所有顾客的偏好。但是对于有偏好的顾客来说，绝对谈不上出色。

但新的小产品不一样。小产品本来就没有基本盘，在历史用户群体上没什么能放弃的。那么可以放心发展自己特有的文化认同，组建自己的用户社区，为他们解决好大公司产品无法解决的问题，获取这部分用户的青睐。

让用户喜欢你

在互联网行业里，「护城河」是个经常被提起的词。这个词已经把「用户是我的资源」的观点昭然若揭了，因为是资源，所以需要「护城河」免得被人抢走了。

当然这一方面是因为互联网行业所提供的面向 C 端的服务，是一些很容易规模化的产品；和人打交道的，也是一个个可复制的程序。在这一意义上，用户们确实就是一种用于争夺甚至掠夺的资源而已。

但这样的观点，做面向企业客户端和做传统生意的老哥们肯定是不同意的，他们的运营模式与互联网行业有着明显的差异。在他们眼里，客户不仅仅是资源，更是长期的合作伙伴，远超过单纯的交易关系。

比如，当我们谈到面向企业的服务，我们谈的是深度合作、定制化解决方案和长期的业务合作关系。确实，规模化和通用的 SaaS 能满足浅层的需求，但大客户的需求往往是独特的，需要深入了解、长时间的维护和创新。

再者，传统生意的老哥们，他们更加重视人与人之间的关系。在他们的字典里，客户不是简单的数字和数据，而是有血有肉、有情感的人。他们与客户建立的是一种长久的信任关系，也不是短暂的交易关系。

但是就像很多行业的发展一样，二者的发展并非不可弥合。

从面向 C 的产品来看，大家也注意到每个 App 的用户都是一个真实的人，也和公司里的你一样，拥有自己的需求、感受和情感。所以才后了后续对「个性化」的发展。

其次，情感的需求不仅仅是单纯地满足用户场景。现在这个时代，追求共同价值观，即使在普通的消费决策中的角色，也变得越来越重要——大家不再仅仅追求产品或服务的功能性，也不仅仅看中价格，更开始在意的是与产品之间的情感连接、社群文化、共同价值观。

如果用户说「给你介绍一个 App，我在用」，这显然是把你当外人。如果用户说「给你介绍一个 App，我们都在用」，这是把你当自己人。

所以我刚才说小产品应该发展自己特有的文化认同，其实目的就是让用户从「资源」转变为「护城河」。这个护城河不需要保护用户，而是转而保护你的产品和用户所建立的这种情感纽带。

这样，产品与用户之间的关系已经不再是单纯的交易，当产品不仅仅满足用户的功能需求，而是与用户产生深深的情感联系时，这种关系就如同情侣之间的深厚情感，而非炮友关系的肤浅互动。

在这种紧密的情感纽带下，任何竞争对手想要介入、破坏或试图拉走用户，都将面临极大的挑战。因为他们不仅仅是要超越一个功能优越的产品，更是要打破一段深厚的情感纽带。

比如说独立开发者的三大件之一的笔记软件。这么多笔记软件每一个都解决了什么痛点吗？双向链接？知识图谱？在我看来完全没有，大家都是提供了一个能让自己舒舒服服当松鼠的工具而已。那为什么要用 Notion/Obsidian/LogSeq/Evernote ...，明明大家的基础功能都差不多。

因为我喜欢。

不再一味追求规模

不过建立文化认同是有代价的——那就是很难成为「基本盘」。

或者换句话说，随着用户的规模变大，文化认同会变得越来越浅薄，直到浅薄到和最广大网民相同——能上网就行，不管是不是一条狗。

很长时间以来，很多创业者都在追求规模：融资 -> 烧钱 -> 争夺市场 -> ... 保持这样的循环直到上市，让股市支付给公司一笔永远不需要偿还的借款，然后从投资人到创始人，所有人都解脱了。但大家的代价是什么呢？

代价一：绝大部分创业团队都会失败。
代价二：变成投资人的棋子：即使公司已经在维持盈利了，但是这点盈利对投资人来说是不能接受时，是否还能让产品和业务保持初心？

现在这个阶段，咱们可以不那么追求规模。

我在日本居住时发现，这里的「百年企业」随处可见。我家门口那家古朴的茶店，就有超过 100 年的历史。长久以来，这家店可能一直在服务这个街区的居民，让大家有个社交聊天的地方。

做个生意，就非要以服务好全球 80 亿人为目标么？茶店老板肯定不是这样想的。茶店老板想的是，我烹得一手好茶，煮得一手好咖啡，来我这的顾客，都是赏识我的手艺而来的。虽然我可以开分店，但是分店店长还能烹得一手好茶，煮得一手好咖啡，赢得分店那个街区的客人的喜爱吗？难。

VC 能解决这个问题吗？或者说，资金、标准化、规模化能解决这个问题吗？我觉得不能。所以如果立足这样的生意——这样一批无法靠规模化做好的生意，大公司就很难抄你的东西了。

对于这样的生意，很明显，必须在很长一段时间内都提供一些独一无二的东西。也就是说，我们都必须去创造。「先做一个手艺人，然后在去做一个企业家¹」。

最后，如果你发现大公司真的在抄你，不要太过担心。

也许这是因为你太优秀了，他们实在无法抗拒你的魅力。你就像那家茶店老板，你也不在乎开不了全球连锁店，因为你知道，只有你那一杯绝妙的咖啡或茶，才能吸引着你的忠实顾客。关键是，你可以给他来一杯「给抄袭者的特调」，而这是抄袭的人绝对做不到的。😉

The Minimalist Entrepreneur ↩︎

无聊的价值

2023-10-10T08:01:35Z

前段时间看到两条 tweets 1, 2

@NalaGinrut：我跟你们分享一点经验，任何正事（也就是所谓的做进去了），都是 boring 的，当别人告诉你他做的事情十分令人愉悦的时候，他还在面上。

@zhangjintao9020：前半句基本上是这样的。后半句的话，每个人获得成就感/快乐的点不太一样，虽然 boring 但也不阻碍获得快乐（旅途中的风景也不错）

从我自己的情况来看，确实如此。

我小的时候有学美术，学的中国画。开始画一张新画时，最有劲的都是前半程。勾勒轮廓，调整姿态，布局整体，确定色调和情绪等等，这些都是能从整体上影响作品的因素。

可到了后半程，比如刻画细节，比如修正前半程的错误，就感觉没那么爽了，人没那么有耐心，手也不灵巧了。不过，真要说起来，就是这些后半程琐事，决定了一幅作品能否在细节上打动观众。我的老师当时就是这么跟我说的。

后来作为一个软件工程师，也染上了程序员的通病：从业时间一长，总有一堆原型项目，常规操作是这样的：

突然有了兴致，开启一个新项目
发现项目中一个组件应该独立出来
先把这个项目挂起，开始开发这个组件
发现组件通用性不够，开始覆盖更多使用场景（即使你的项目只用到了一个场景）
项目进展特别缓慢，有点懈怠，于是决定玩儿游戏或者看看电视
过了一段时间，对这个项目丧失了兴趣

source

然后做着做着，就变得不想继续下去了。

做原型为什么令人激动

搞个项目原型总是让人兴奋。其中一个原因就是，原型系统能迅速得到反馈，让人开心不已。

在软件工程里，弄个原型系统花的时间非常少。

这是因为，所有原型系统一开始都只是从某一天的「俺寻思」开始的，它们的目的就是展示某个新技术的原理，或者试验一下新点子的感觉。

另外，原型方案通常都是在一个孤岛上搭建的。系统的实现只满足一个小小的需求，跟真正的外界需求和用户隔离开来。也就是说，这些原型不需要对任何真实需求和用户负责，可以尽情忽略未来扩展的麻烦，只管满足当下的最小需求就行了。

所以，从「俺寻思」到项目第一次跑起来，时间真的很短，典型的「俺寻思」就是 Hackthon，经常一个晚上就够了。这样开发者们就能迅速享受到从「俺寻思」到「wah」的愉悦感。

但是正式的产品可就不一样了。要把它变成一个产品，就得投入大量时间和精力。

另一个原因我觉得是，相比制定稳妥的路线图，人们更容易陷入新技术和概念的炒作中。

在公司的业务运作中，这一点也特别明显。

比如说七年前的「机器学习」，三年前的「区块链」，三个月前的「AI」，还有现在的 VR/AR。你在新闻上看到某大公司准备「ALL IN」某个领域——但实际上，可能就是在某办公室里，这个公司的领导听了半小时的播客，然后决定了这次「ALL IN」；或者是某员工在很短时间内通过原型快速验证了某项新技术的概念，然后自下而上地向高层汇报：为什么这项技术能改变行业规则，然后「ALL IN」

不管是怎么开始的，总之，大家会兴致勃勃地开始构建原型系统，这样做有很多好处：

在这个初期阶段，快就是好。所以根本不需要考虑任何生产系统需要的调查研究。
这会带来快速的内部成功，大家可以迅速庆祝公司的创新文化，所有人都会由衷鼓掌。
对员工来说，这是个既有趣又令人兴奋的「练习」。相比起日常工作，这是个很好的分散注意力的机会。

然后，当这些兴奋感逐渐消退后，项目就会停滞不前。咋办呢？

原型不够

回过头来，我认同文章开头的推文的观点：即很多事情，做进去了以后，都很 boring——至少 boring 的部分会长期、固定地占据一大块。

比如说，现在用来发文章的 Quaily。我是在 4 月 18 号决定要写 newsletter，然后四天后第一个版本就上线了。但真正上线的时间是 7 月 7 日，距离第一个版本上线已经过去了 2 个多月。

上线之初当然是非常不完善。直到现在，Quail 的 Todo List 依然非常长，有很多工作需要去做，有很多问题需要去解决。

这些要做的工作，有一些是一开始就制订好计划要做的。比如说支付购买内容、绑定自定义域名、数据导入导出等等。

更多的另一些工作，则是预期之外的：

他们有的是新出现的问题和 Bug，需要解决。这类问题很常见，比如前段时间出现的了一个死锁问题导致一个进程无法正常工作，就需要检查然后修复。
有的则是在之前规划中没有考虑到的部分。以自定义域名为例，之前本来想用 cloudflare 的 TLS for SaaS，后来发现不太合适。因此需要改变计划，用 acme 为每一个绑定的域名新增 Let's Encrypted 证书。这就产生了额外的工作量。
另外还有相当多的工作，属于事务性工作，与具体的功能开发没什么关系。例如最近两个月访问量大了，之前没有做的负载均衡需要做起来 -> 负载均衡做了，那之前的单机 cache 都需要换到 redis ... 诸如此类的工作，属于用户们都感知不到，但是必须要做。

这些工作中的许多，尤其是最后一类工作——很无聊——经常地内心里并不想去做，但是不得不做——因为这是稳定服务和持续迭代必须付出的代价。

这还只是工程上的事。

作为一个产品经理，还得考虑未来要做什么，不做什么。所有那些非工程类的思考和决策，包括「后台编辑器要达到什么水平」、「AI 要整合到什么程度」这样的需求设计，还包括「作为核心用户的作者们关心哪些事情」这样的长期问题，都得考虑。

不要那么无聊

既然知道了无聊的原因，那就有机会让项目继续下去：

尽早宣告一下

现在很多独立开发者采用的「build in public」就是这个做法：尽早让大家知道你在做什么。

一方面可以得到第一手的反馈，另一方面——也是非常重要的一个原因——大家也能会鼓励你继续做下去。

之前我有个项目叫 Hotot。本来我最早只是想玩票的，但是突然被一个西班牙 Linux 媒体报道了，用户一下子就多了。我就很高兴地持续做下去，直到 Twitter 更改了他们的 API 策略

确定需求的存在

对于很多工程师来说，这个事情可能有些难。无论是宏观上的「这个事情值不值得做」还是微观上的「这个用户体验好不好」，都与理解用户和市场息息相关。

除了自学变成一个产品经理之外，还有一个简单的方法，就是只关注你所代表的那群人的需求。

了解自己肯定比了解别人容易得多。如果你对自己做的东西非常满意，那么也就意味着潜在地与你类似的人应该也会满意。确定这一方向以后，把自己为代表的这群人的需求满足到机制即可。

选择做与不做

折腾任何东西都是投资。写代码、设计需要时间和精力，服务器还需要金钱。所以既然是「投资」，就要考虑投资的合理性，即回报。

如果我打算创造一个新 App 或者服务，就需要证明这个「投资」是合理的。如果这个新的原型产品只能带来名义上的增量价值，看不到直接的经济回报，就需要确定它实际上能给我们带来什么。

当然，并不是所有原型产品都必须产生经济上的收入，也可能是为了验证概念或探索新领域而创建的。这些项目的目标可能是获取用户反馈、提供解决方案或推动技术创新。尽管它们可能不直接带来经济回报，但它们在其他方面可能具有价值，如吸引投资、建立声誉或为将来的商业化打下基础。

在这一观点下，选择一件事「做与不做」就很重要。你的这些决定，最终会得到：经济回报、项目的可行性验证、用户满意度、商业声誉等等。这些结果都需要能被量化，才能用于参与一件事「做与不做」的决策。

不过我觉得，不在乎有趣或者无聊，持续地长期地做一些正确的事情，把时间当作朋友而不是炮友，才能看到无聊的价值。

V 神的 X 帐号被 SIM 劫持攻击是怎么回事

2023-09-14T01:22:02Z

这个星期，ETH 的创始人 Vitalik Buterin 的 X 帐号（前生叫 Twitter）被黑客 SIM 劫持（SIM Swap）攻击了。黑客窃取他的 X 帐号访问权后，使用他的身份发布钓鱼信息，窃取了其他人的资产。

SIM 劫持是一种还挺普遍的攻击手法。比如早在 2019 年，当时 Twitter 的 CEO Jack 也遭受过这样的攻击：

最近些年 SIM 劫持的数量和危害是在上升的。我觉得这和很多在线服务的安全教育有关系。比如说，现在大量的在线服务——包括银行、Web3、加密货币交易所等等——都普遍地喜欢使用手机号 + 验证码的方式登录。

总之过度依赖短信是一个问题。如果在短信验证之外，缺乏额外的安全和风控深度的话，会让 SIM 劫持攻击很容易得手。

所以今天就讲讲这种攻击手法，然后从用户的视角，尤其是 Web3 用户和 Mixin 用户的视角，提供防范这类攻击的思路。

SIM 劫持

很多很多在线服务，都在用短信来验证你的身份。例如，下面是一个典型的登录流程：

输入手机号，会给你这个手机号发一个短信验证码（一般是 4 位数字或者 6 位数字）
你收到了这个验证码，回到这个在线服务输入它
在线服务会验证你输入的验证码是否和它自己记录的一致
如果一致，就说明这个手机号属于你，登录成功

SIM 劫持的原理，就是黑客通过一些手法获取了你的手机号收短信的权限，他看到了这个验证码，然后他假扮成你登录到在线服务。

这里提到的一些手法，既有技术手段，也有非技术手段。技术手法包括对手机网络的劫持、监控，诱导安装木马和间谍软件；非技术手法大部分都是骗术。

Note: This post contains paid content. Purchase on the website to read the full article.

东京和上海的生活成本对比

2023-08-28T09:30:00Z

买水果蔬菜，最便宜的是去社区的果蔬店买。以樱桃为例，在超市樱桃是以盒为单位卖的，根据樱桃的品质，大概一小盒大概几百日元，比如下图左侧就是 400 多日元。但是如果去便宜的社区果蔬店，像下面图片里右侧的一大箱樱桃也只需要 1000 日元（虽然品种不同，但是价格的差异确实大）。

如果要找果蔬店，直接在 Google 地图里搜索「果蔬」就可以了。不过很多社区果蔬店并不会登记到 Google 地图，就需要自己日常多留意周边的商铺了。

不过总体来说，日本的蔬菜和水果是要比上海贵不少，蛋白质类则没有像表里一样差那么多（而且越高级的肉类差得越少）

交通

这部分的对比可谓非常真实：

上海的月票我不知道，但是单程票和出租价格确实比日本便宜多了。除此之外补充一些：

在东京也可以通过软件叫车。如果叫车的话，叫车费用视距离和需求而定。比如我家附近一般在 300~500 日元左右。
有驾照的朋友，可以租车，比打出租便宜。比如东京都内，Times 租车费用大概是 220 日元 15分钟。所以如果你要去的地方附近有租车行，也可以考虑租车前行。
买车的话，我觉得在上海这样对比是不中肯的，原因如下：
1. 上海非电车有牌照费用，很贵。
2. 上海现在主流应该买国产电车吧，不会考虑丰田和大众的话，价格也是有优势的。

不过日本进口汽车没有关税，因此想要买进口汽车（指欧美汽车）和日本车的话，在日本是有价格优势的。

公共服务

公共服务基本上全面高于上海，而且就我的感觉来看，非常符合预期。

不过也有不一样的地方：

手机话费套餐，如果选择最便宜的 Rakuten Mobile，价格可以低到 2000 日元左右。表中 3600 多日元比较像是主流运营商的低价品牌——比如 Softbank 旗下的 YMobile 的中低配价格
宽带网络，现在有些公寓会提供免费的宽带。所以不用自己安装了。

下面是我的公寓的电费单据，可以参考一下：

教育

表中的数据我个人感觉是不太对。

首先国内的私人幼儿园的话，人民币 9000 价位在上海应该有挺好的国际幼儿园了吧。大部分居民不会去考虑入学国际幼儿园。

顶级的国际学校我觉得二者差不太多，一年要 20万人民币是很正常的价格。而且，价格只是一个门槛，能不能进去还要看很多条件。

我感觉这个表里东京之所以这么便宜有一个原因是：本来就有一些国际学校是便宜的... 比如印度人开设的学校。它们开设在日本，所以也是「国际学校」。当然，如果我们限制英美系的话，我觉得价格和上海差不多。

教育是个很麻烦的话题，如果有机会后面再仔细说。

租房

表中是这样写的：

我觉得吧，由于中日的社会情况不同，有很大的差异：

首先，文中提到的「市中心」和「中心外」是值得商榷的：

不同区的价格差异很大，即使都在「东京23区」
相同区的价格差异很大，影响因素很多（例如步行前往地铁站的距离）

比如说，我刚来日本时，租的房子是一个房间是 65000 日元，而搬家以后的房子是 95000 日元。虽然，都是一个房间，都在东京 23 区内，距离地铁站也差不多远，都是步行 10 分钟，但是因为房子设施陈旧与否，差距就是这么大。

上海也有类似的情况。住在黄浦区跟住在松江、新房子和旧房子、商业住宅还是回迁房，价格肯定不能一概而论。

其次，「一卧室」的情况在东京和上海的情况也是不一样的。

在东京，有大量的「一居室」存在，是专门提供给单身青年居住的，称之为「1K」或者「1LK」。多个人合租一个多居室的情况比较少。
在上海，因为大部分住房都是商品房，真正的「一居室」在出租市场上很少。大部分单身青年，租房要便宜的话可能需要选择合租。

所以，真实的租房情况可能不会像表中那样，而是这样：

在东京，单身青年租「一居室」的话，价格大概是 3000~~7000 人民币，有较好的居住体验；在上海，单身青年合租的话，价格大概是 1500~~4000 人民币，有较差的居住体验。

但是上海青年如果想有较好的居住体验的话，去租「一居室」的话，开销也与东京青年相当了。

然后，日本租房有额外的开销。

比如下面这套房子租金是 17.7 万日元，45.97 平米。

房价右侧有两个词分别是「礼」和「敷」。他们分别表示送给房东的「礼金」和「敷金」

所谓「礼金」嘛，就是礼物，不退的。所以实际房租应该加上礼金，大部分相当于一个月房租。
所谓「敷金」的话，其实是押金。虽然会退回，但是会扣除房屋的清扫和修复费用。所以如果房屋损坏了，要多付一个月房租。

所以，我感觉日本的租房支出应该要乘以 110% 比较合理。

不过，也并不是所有房子都需要支付礼金和敷金，而且有的新公寓还可以免除第一个月房租（比如我现在住的公寓），所以具体情况也要具体看。

买房

表中对于买房的情况也是比较中肯的。

总体来看，东京的房价确实要比上海便宜的多得多——无论是单价还是利率。

我曾在 2021 年银座附近看过一套新房子，大概价格是 8 万多一平米。相比之下，在上海的黄浦区核心商圈应该很难找到这个价格的房子。

关于买房的话题，之前已经在《在日本生活：怎么润、劝退点、小贴士、挑战》和《在日本工作一年是什么感受》说过一些了。考虑到其中有些问题比较复杂，需要的话可以私聊。

薪资收入

虽然之前也在《在日本生活：怎么润、劝退点、小贴士、挑战》说过一些收入的话题，但是我还可以多说一点。

东京的基尼系数比较低，不但比上海、北京这种一线城市低，也比杭州低。

我举个例子，在张江 IT 产业园，月薪五万的工程师不少吧。但是产业园里商店的收银员，他们的月薪可能只有五千。相比之下，东京的便利店的收银员时薪已经超过了 1200 日元，折合人民币一万五。

考虑到东京和上海相似的生活成本，在东京做收银员显然要幸福感更高一些。

类似地，在东京请阿姨打扫卫生，日常保洁两小时大概是 6000 日元，折人民币 300 左右。上海的价格大概 100 人民币左右吧。对此，我们可以说在日本基于人力的服务业消费更贵，但是也可以说是日本服务业从业者的收入会比较高。

另外再分享一个故事。

第一次在东京搬家，因为行李不多，我找了一个中国司机师傅，是一个东北汉子。在车上我们闲聊，他说他来东京已经十多年了，感觉最近几年祖国强大多了，自己觉得很自豪。

我问他，那你不考虑回东北吗？

他说，他虽然没上过什么学，没什么文化，但在日本他有一身力气，就可以赚到钱，能买得起这里的房子。如果回去的话，赚得太少了。

我说你说得对，还是呆在在东京好。

Note: This post contains paid content. Purchase on the website to read the full article.

笔记还是纯文本就好

2023-08-13T10:25:35Z

昨天有看到一个推文：

在加上前端天团组成的 Affine，看来华人真的很会做笔记ww，有笑到。

我曾经用过很多笔记软件。

还能记得名字的就有：Evernote、OneNote、SimpleNote、自己开发的 Ubinote、Zim、iOS 和 macOS 的 Notes、DEVONThink Pro、Logseq、Obsidian ...

虽然现在我在用的是 Obsidian，也向其他人推荐过，但我的用法与笔记软件没有什么关系。

因为我只把 Obsidian 当一个 Markdown 编辑器

嗯，我不用 Obsidian 除了 Markdown 编辑以外的功能。比如说双向链接、Graph View 等等。

Graph View 看着很帅，但是它提供网状视图既不好浏览，也不好检索。不好用。

双向链接虽然有用，但是「过载」了，管理成本太高。大多数情况下，都不需要真的去浏览结构化的笔记，搜索或者问 AI 就够了。在绝对的实力面前，精巧的管理技巧显得很不划算。

再者，我经常用其他软件来编辑笔记，最常见的是 VSCode。

我记日语单词用的是 VSCode，因为 Github Copilot 能帮我很快补全日语例句：

一边输入一边补全释义、假名、例句，VSCode + Github Copilot 的输入效率比任何笔记软件和语言学习软件都高。

所以我的原则蛮简单：纯文本的，能同步，编辑器顺手。

现在选择 Obsidian，VSCode，没有什么特别的原因，仅仅因为现在用它们比较顺手。而且 VSCode 本来也是我日常工作用的软件。

为啥是纯文本

所有的笔记都是文本文件（Markdown 当然也是文本文件），是因为它最容易处理的格式，这样就很方便去对他们进行后续的处理。

「后续的处理」可以有哪些呢，比如说搜索。

搜索用的是 ag，一个非常快的文本检索工具。当然用 grep 也没有什么差别。

刚才有提到我用 VSCode 记录日语单词，记录完成以后，我就可以干两件事：

一次性推送到背单词的服务，比如 Anki，或者别的软件
推送给 AI，让它给我编故事

这也是一种「后续的处理」。

另外我还在搭建自己的 AI 助理。当推进到喂数据那一步时，数据是纯文本的，就要比私有格式便利得多。

总之，纯文本是一个很便利的格式，对于喜欢自己做东西的人来说，是非常方便的选择。

怎么同步呢

因为刚才提到了，我只把笔记 App 当编辑器使用，因此既不可能用 Notion 这种纯云端服务，也不会使用本地笔记 App 提供的云。

但是，同步到不同设备的需求是存在的。比如在手机上看笔记的场景。

那么就需要自己做一个同步服务。我选择的是 Syncthing + Tailscale。

Syncthing 本来就是我用来同步数据的服务，不仅仅是笔记，别的数据同步我也用它，比如照片同步到自己的服务器上。
Tailscale 本来就是我用来建立 VPN 的工具，也不是为了同步笔记用的。我只是用它来确保 Syncthing 不需要在公网上找 reply 服务器而已。

这些也不是为了记笔记而做的事情，只是顺便做了。当然，亲民一点的选择是 Dropbox，也是可以的。

总之，我现在仿佛在用笔记工具，但其实我没有。我只是在编辑文本文件而已。

写笔记总有管理成本，我想最好不要在它们身上投入太多。就在我的能力范围内，尽量降低管理成本和心智压力。

人生已经很苦了，那就喝点 Pina Colada，不要点 Negroni 了

不秃也变强：让 AI 当大师傅，编程和写作效率提升两三倍

2023-08-09T01:05:10Z

最近半年感觉自己明显变强了（不是因为变秃了）。

主要是因为 AI，效率提高了两三倍吧。

现在的情况是，可能 50% 的代码都是 AI 写的；50% 的文案都是 AI 写的。100% 的插图都是 AI 画的。

写代码

有的读者不清楚写代码的情况，可能觉得一半的代码都不是出自老师傅手工调制是不是有点夸张。其实不夸张。我稍微解释下：

普通的程序员日常编码工作里，有很多是不费脑子的。

比如说很多程序都需要连数据库。

数据库相关的代码都非常无聊，属于有手就能写的那种。这种时候开着 GitHub Copilot，作为人类只需要写个提示比如 CREATE TABLE 或者 type User struct {，后面的基本上就看 GitHub Copilot 表演。

每次 GitHub Copilot 输出一行，确认无误就直接按 Tab，如果有误也按 Tab 然后修正，下次 Copilot 会写得更好。

除了数据库相关的，比如配置啦、参数处理啦，总之这类编码工作可能有个 30% 吧，都能用 AI 写。

另外一类可以用 AI 加速的代码属于，知道怎么写，但是因为很无聊所以不想自己写。最典型的就是 golang 的 Slice 转 Map，或者把一堆元素按照什么规则排序，我经常写个提示 // convert slice abc to map 或者 // sort slice abc by sliceA.key。然后回车等会儿，看 Copilot 表演就完了。

下面是另一个例子：

这类代码得有个 10% 吧，都能用 AI 加速。

最后还有一类代码是大概知道个方向，但是细节不太清楚的。要放在之前，是肯定要去 Google 搜索一番，最终定位到 Stackoverflow、GitHub、某个文档之类的地方，然后研读一会儿，才能找到解决方案。

现在有 AI 以后，可能有两种情况，一是类似与上一类情况，直接在源码里写个函数名字，然后在注释里写上自己要干啥，然后瞪眼看 Copilot 能写出啥玩意。

如果这个方案不行，就先去 ChatGPT，捧捧它，跟它说一些垃圾话：

侬是个大师傅程序员，请帮我写 SQL。
要能在 PostgreSQL 里，列出所有的 sequences，然后再列出每个表的 id 字段的默认值是多少。

如此这般，让他写。

这类代码也得有个 20% 吧，其中得有一大半能用 AI 加速。

这么一算下来，诶，是不是 50% 的代码都能用 AI 写了。节约的不仅仅是敲击键盘的时间，而且还节约了搜索和费脑的时间，效率提升啊。

写文案

我最喜欢的写文案工具其实是 Github Copilot 加持的 VSCode。因为经常要写技术文档的缘故，它本来就代码写得好，技术文档也非常上手。

讲两个例子。

第一个例子是做即时翻译。在做本地化的时候，经常出现说，一个字符串需要同时写成好几个语言的。如果支持的语言比较少，不用工具的话，可以直接把英文文案放到注释里，然后让 Copilot 补其他语言的文案就行。例如：

{
  // "login.welcome_message": "Welcome to here!"
  "login.welcome_message": ""
}

这时候只需要把编辑器光标在引号里等着就行。下面是一个更复杂的真实的例子：

另一个例子是直接用 VSCode 写段落。这个做法在写技术文档的时候，极其好用。

比如说，写完 API 参数表以后经常要解释各个参数的意思，我就直接写一个提示 in which ，然后等着 Copilot 表演，它基本上能给我解释得八九不离十。等它表演完了我再稍微修正一下就行。

稍微复杂的文案，比如需要改写的、重写的、润色的，就要靠 ChatGPT 了。

基本操作和写代码差不多，去 ChatGPT，捧捧它，告诉它是个某个行业的大师傅，跟他说主题是什么，要点是什么，然后让他写，写的时候还可以要求它用什么样的 writing style。

写完以后，自己改改，基本够用。

画插图

之前找插图是挺麻烦的，既要考虑图是不是合适，还要考虑版权有没有问题。所以之前经常去 unsplash 这样的地方去找图。

但是现在好了，有了 Midjourney，我几乎没去过 unsplash。不知道怎么描述需求的时候，就去 KALOS Art Libery 抄 prompt，人类历史上所有画家都能为我画插图，简直不要太开心。

比如说这篇文章的 prompt 是：

in style of Goro Fujita, a mechina cat master, improve your performance --ar 16:9

结语

如果再过几年，AI 持续这么给力，我可能会考虑转行做 AI 按摩师，每天就是帮 AI 放松一下，再涂抹点机油。或者成立一个“AI权益保护协会”，确保每一位 AI 都得到应有的休息时间和认可。

谢谢大家！

歌词经理

用开发 Agent 理解 Agent 02：数据即代码，代码即数据

从一个 loop 说起

但这个传统到底从哪里开始？

loop：系统在用自己的输出重写自己的输入

新的叙事与叙事切换

这对软件开发意味着

自由不是约束的反面，自由在正确的约束内才有解释

先写到这里

编程从来不属于程序员

三种问题

Vibe coding 在做什么

变化的是量，也是拓扑

真实的风险

它没有锁死编程

用开发 Agent 理解 Agent 01：握着你的手摸索小龙虾

什么是 Agent

为什么要 Agent

第一个原因是 One shot 做不到

第二个原因是工具充当了 AI 的手和脚

为什么是 OpenClaw （aka 为什么 Manus / ChatGPT Apps 不行）

为什么我的 GZK9000 烂尾

BTC, Vibe Coding, 3D 打印：结算、编码、制造的三次回归和三张账单

为什么世界会走向中心化

那个看不见的账单

结算、编码、制造的三次回归

接下来十年像什么

mistermorph 的 Agent 安全开发札记

几个原则

威胁模型

第一层：OS/容器负责能不能做

第二层：不让模型接触秘密

第三层：Guard

最后

Vibe coding 现状观察（2026 年 1 月）

没有银弹

初级工程师的末日

重剑无锋，大巧不工

调试变成了审讯

超越 Coding

面向 AI vs 面向人类

计算 MSTR 的 mNAV（官方算法）

数据与方法

在 TradingView 里画图

人人都能写程序：Vibe Coding 与问题规模

程序/服务是商品

Vibe Coding：更多人能开始自己写

小规模问题，绕开了很多规模带来的难点

工具类利空，授课/知识付费利好

规模，依然是难点：Vibe Coding 不能替代软件工程

什么时候 Vibe Coding 不构成威胁？

给产品与团队的一点策略

写给第一次写程序的人

关爱用户的可伸缩性

关爱的用户的姿势

我最喜欢的悖论

辛普森悖论

肾结石治疗的误导

像剥洋葱一样思考

游戏里的悖论

一个假设

总结

彩蛋故事：YouTube 的加载速度

Quaily 的开源项目

1 · quail-ui — Vue 3 组件库

2 · quail-js — TS/JS SDK

3 · obsidian-quail — Obsidian 插件

4 · goldmark‑enclave — Markdown 语法增强（Go）

5 · quail-cli — 终端与自动化入口（Go）

6 · bizdocgen — PDF 发票/贷记单生成器（Go）

7 · translate-cli — AI 批量翻译 JSON Locale 工具

创造世界是一种什么样的体验

生命的本质是一种软件逻辑

一代程序员王小波

1988年12月，致晓阳

1990年1月，致晓阳

1991年3月，致晓阳

1992年1月，致晓阳

1992年9月，致晓阳

年份不详，致曲小燕

1 · quail-ui — Vue 3 组件库

2 · quail-js — TS/JS SDK

3 · obsidian-quail — Obsidian 插件

4 · goldmark‑enclave — Markdown 语法增强（Go）

5 · quail-cli — 终端与自动化入口（Go）

6 · bizdocgen — PDF 发票/贷记单生成器（Go）

7 · translate-cli — AI 批量翻译 JSON Locale 工具