For those unfamiliar, lld is theLLVM linker, supporting PE/COFF, ELF, Mach-O, and WebAssembly ports.These object file formats differ significantly, and each port mustfollow the conventions of the platform's system linker. As a result, theports share limited code (diagnostics, memory allocation, etc) and havelargely separate reviewer groups.

With LLVM 22.1 releasing soon, I've added some notes to the https://github.com/llvm/llvm-project/blob/release/22.x/lld/docs/ReleaseNotes.rstas an lld/ELF maintainer. As usual, I've reviewed almost all the patchesnot authored by me.

For the first time, I used an LLM agent (Claude Code) to help lookthrough commits(git log release/21.x..release/22.x -- lld/ELF) and draftthe release notes. Despite my request to only read lld/ELF changes,Claude Code also crafted notes for other ports, which I retained sincetheir release notes had been quite sparse for several releases.

• --print-gc-sections=<file> has been added toredirect garbage collection section listing to a file, avoidingcontamination of stdout with other linker output. (#159706)
• A VersionNode lexer state has been added for betterversion script parsing. This brings the lexer behavior closer to GNU ld.(#174530)
• Unversioned undefined symbols now use version index 0, aligning withGNU ld 2.46 behavior. (#168189)
• .data.rel.ro.hot and .data.rel.ro.unlikelyare now recognized as RELRO sections, allowing profile-guided staticdata partitioning. (#148920)
• DTLTO now supports archive members and bitcode members of thinarchives. (#157043)
• For DTLTO,--thinlto-remote-compiler-prepend-arg=<arg> has beenadded to prepend an argument to the remote compiler's command line. (#162456)
• Balanced Partitioning (BP) section ordering now skips input sectionswith null data, and filters out section symbols. (#149265) (#151685)
• For AArch64, fixed a crash when using--fix-cortex-a53-843419 with synthetic sections andimproved handling when patched code is far from the short jump. (#170495)
• For AArch64, added support for the R_AARCH64_FUNCINIT64dynamic relocation type for relocating word-sized data using the returnvalue of a function. (#156564)
• For AArch64, added support for the R_AARCH64_PATCHINSTrelocation type to support deactivation symbols. (#133534)
• For AArch64, added support for reading AArch64 Build Attributes andconverting them into GNU Properties. (#147970)
• For ARM, fixed incorrect veneer generation for wraparound branchesat the high end of the 32-bit address space branching to the low end.(#165263)
• For LoongArch, -r now synthesizesR_LARCH_ALIGN at input section start to preserve alignmentinformation. (#153935)
• For LoongArch, added relocation types for LA32R/LA32S. (#172618) (#176312)
• For RISC-V, added infrastructure for handling vendor-specificrelocations. (#159987)
• For RISC-V, added support for statically resolved vendor-specificrelocations. (#169273)
• For RISC-V, -r now synthesizesR_RISCV_ALIGN at input section start to preserve alignmentinformation during two-stage linking. (#151639)

Besides me, Peter Smith (smithp35) and Jessica Clarke (jrtc27) havedone a lot of reviews.

jrtc27 has done great work simplifying the dynamic relocation system,which is highly appreciated.

I should call out https://github.com/llvm/llvm-project/pull/172618: forthis relatively large addition, the author and approver are from thesame company and contributing to their architecture, and neither theauthor nor the approver is a regular lld contributor/reviewer. Theauthor did not request review from regular reviewers and landed thepatch just 3 minutes after their colleague's approval. I left a commentasking to keep the PR open for other maintainers to review.

---

Link: lld 21 ELFchanges

我们都知道应该去做那些「难而正确」的事。我们熟读各类方法论：建立系统而非仅盯着目标；先确立身份认同再行动；利用福格行为模型微调习惯……但在现实的引力面前，这些道理往往显得苍白。

因为正确的事通常伴随着当下的痛感（或者枯燥），且反馈周期漫长。相比之下，大脑更原始的本能总是倾向于那些即时满足的选项。

当注意力即将滑向短期快感时，我们需要的不是宏大的意志力，而是一个微小的「阻断器」。深呼吸，就是这个阻断器。

这并非玄学，而是有着明确的生理机制。当我们焦虑或冲动时，身体由处于「战斗或逃跑」的交感神经主导。而深呼吸——特别是呼气长于吸气的呼吸——能激活迷走神经，强制启动副交感神经系统。这就像是给高速运转的大脑物理降温，将我们从应激状态强行拉回「休息与消化」的理智状态。

给自己设一个微小的「绊脚石」：在想要下意识点开那个红色 App 之前，或者伸手拿烟之前，深呼吸 3 次。

这里的难点在于「记得」。在多巴胺渴望飙升的瞬间，理智往往是缺席的。所以，不要指望意志力，要依靠环境暗示。比如给手机套一根橡皮筋，利用这个物理触感的停顿，给自己 3 秒钟的窗口期。如果不做这个动作，惯性会带走你；做了这个动作，选择权才更容易回到手中。

如果说深呼吸是急救包，那么冥想就是长期的肌肉训练。

冥想的核心功效，是培养一种「旁观者」的视角。它能帮我们对抗「注意力经济」的掠夺，打断「刺激-反应」的自动化回路。经过冥想训练的大脑，具备更敏锐的「觉察力」。当你下意识地刷手机时，大脑会突然亮起一盏灯：看，我产生了一个想寻求刺激的念头。

在这「被看见」的一瞬间，你就不再是情绪和欲望的奴隶，而是它们的主人。

现代的注意力经济通过高密度的感官轰炸（短视频、爆款标题），不仅拉高了多巴胺阈值，还让多巴胺受体变得极度迟钝。我们像耐药性极强的病人，对低刺激的事物（读书、深度思考、发呆）感到无法忍受的枯燥。

我们丧失了「无聊」的能力，而无聊恰恰是创造力的温床。冥想本质上是一件主动拥抱无聊的事。通过坚持冥想，你在为大脑进行「多巴胺排毒」，恢复受体的敏感度，重新学会如何与「无刺激」的状态相处，并从中获得平静的喜悦。

除了有点无聊，践行冥想最大的阻力，往往来自于我们把它看得太重，试图寻找一段「不被打扰」的完美时间，更高效的策略可能是「缝隙冥想」。

比如通勤的地铁上、排队等咖啡的间隙、或者是午休结束准备开始工作的瞬间。这些时刻原本也是「垃圾时间」，通常会被用来刷手机填补空白。如果能用这 3-5 分钟来关注呼吸，不需要特意调整坐姿，也不必追求绝对的安静，只要把注意力从纷乱的思绪中收回来。

这种「微冥想」虽然短暂，但因为它发生在高频的、甚至有些嘈杂的日常场景中，反而更能训练我们在混乱中随时「调用」平静的能力。

---

归根结底，我们无法控制外界的信息洪流，也难以完全屏蔽生活的噪音，但我们始终拥有控制自己呼吸的自由。

在刺激和反应之间，有一个空间。在那个空间里，藏着我们要选择的反应。在我们的反应里，藏着我们的成长和自由。

呼吸，就是撑开这个空间的支柱。它不是为了让你变成一台更高效的执行机器，而是为了让你在这个加速的世界里，依然能保有停顿的权利。在这个微小的停顿里，你不再是算法的猎物，而是自己的主人。

本文从「是什么、为什么用、怎么用」三个层面，详细讲解 RxSwift 中的 asDriver() 方法，适配新手理解，兼顾实用性和易懂性。

一、asDriver() 核心含义

asDriver() 是 RxSwift 中专门用于将 Observable ** 序列（或其他可转换序列，如 ** Single 、 Maybe ）转换为 ** Driver ** 序列 的方法。

简单来说，它是一个「序列类型转换器」：输入为 Observable，输出为 Driver，且转换过程中会自动为序列附加 Driver 特有的「UI 友好型安全特性」，无需手动额外配置。

补充前提：Driver 并非全新序列类型，而是 Observable 的「专用子类/特殊封装」，专门针对 UI ** 绑定场景**（如更新 Label 文本、刷新 TableView 数据、修改按钮状态等）设计，因此也被称为「UI 友好型序列」。

二、asDriver() 自动附加的 3 个关键安全特性

这是 Driver 的核心价值，也是 asDriver() 的核心意义——自动规避 UI 开发中常见的 3 个坑，减少冗余代码：

1. 确保在主线程订阅/发送事件

UI 操作必须在主线程执行（否则会崩溃或界面错乱），asDriver() 会自动将序列的事件派发切换到主线程，无需手动编写 observe(on: MainScheduler.instance)。

2. 确保序列不会发送 Error 事件

Driver 序列仅支持发送 next（传递数据）和 completed（序列结束）事件，不支持发送 Error ** 事件**。若原始 Observable 可能发送错误，asDriver() 要求必须提供「错误兜底值」（或错误处理逻辑），避免 UI 绑定链路因错误中断。

3. 具备「共享订阅」（共享事件流）特性

对应 RxSwift 中的 share(replay: 1, scope: .whileConnected)，多个观察者订阅同一个 Driver 序列时，不会重复执行上游逻辑（如网络请求、数据库查询），仅共享一份事件流，既节省资源，又能保证多个 UI 组件拿到的数据一致。

三、为什么需要用 asDriver()（适用场景）

核心场景：当需要将 Rx 序列的结果绑定到 UI 控件时，优先使用 ** asDriver() ** 转换为 ** Driver ** 序列。

反例：直接用 Observable 绑定 UI（需手动处理安全问题）

// 直接用 Observable 绑定 UI，需手动处理 3 个安全问题
someObservable
    .observe(on: MainScheduler.instance) // 1. 切换到主线程
    .catch { error in Observable.just("默认值") } // 2. 捕获错误，避免链路中断
    .share(replay: 1, scope: .whileConnected) // 3. 共享订阅
    .bind(to: label.rx.text)
    .disposed(by: disposeBag)

正例：用 asDriver() 绑定 UI（自动处理安全问题，代码简洁）

// asDriver() 自动处理安全问题，代码更简洁
someObservable
    .asDriver(onErrorJustReturn: "默认值") // 转换为 Driver，指定错误兜底值
    .drive(label.rx.text) // Driver 专用绑定方法（替代 bind）
    .disposed(by: disposeBag)

四、asDriver() 的常见用法

asDriver() 有两个常用重载方法，对应不同错误场景：

场景 1：原始序列可能发送错误（需兜底值）

使用 asDriver(onErrorJustReturn:)，传入「错误时序列要发送的默认值」，错误会被自动捕获，序列发送默认值后正常结束，不中断链路。

// 示例：网络请求结果绑定到 UI（网络请求可能失败，需兜底）
let networkRequest: Observable<String> = fetchDataFromServer() // 假设是网络请求序列

networkRequest
    .asDriver(onErrorJustReturn: "网络请求失败，请重试") // 错误兜底文本
    .drive(label.rx.text) // 绑定到 UILabel
    .disposed(by: disposeBag)

场景 2：原始序列不可能发送错误（如本地数据、UI 事件）

直接使用asDriver()，无需传入兜底值（因序列不会产生错误）。

// 示例：按钮点击事件转换为 Driver（按钮点击不会有错误）
let buttonTap: Observable<Void> = button.rx.tap

buttonTap
    .asDriver() // 无需兜底值，直接转换
    .drive(onNext: {
        print("按钮被点击了")
        // 执行 UI 操作，无需担心线程问题
    })
    .disposed(by: disposeBag)

五、补充：Driver 专用绑定方法 drive()

序列被 asDriver() 转换为 Driver 后，推荐使用 drive() 绑定，而非 bind()，原因如下：

• 语义更清晰：drive() 意为「驱动 UI 变化」，明确适配 UI 绑定场景；

• 更安全：drive() 内部已默认处理 UI 绑定的相关细节，避免意外绑定到非 UI 场景。

六、总结

1. asDriver() 是 RxSwift 中**「将 ** Observable ** 转换为 ** Driver ** 序列」**的专用方法，核心服务于 UI 绑定场景；

2. 转换后自动获得 3 个安全特性：主线程执行、不发送错误、共享订阅，减少手动冗余代码；

3. 用法区分：序列可能出错用 asDriver(onErrorJustReturn:)，不可能出错用 asDriver()，UI 绑定优先用 drive()。

LLVM 22 will be released. As usual, I maintain lld/ELF and have addedsome notes to https://github.com/llvm/llvm-project/blob/release/22.x/lld/docs/ReleaseNotes.rst.I've meticulously reviewed nearly all the patches that are not authoredby me. I'll delve into some of the key changes.

• --print-gc-sections=<file> has been added toredirect garbage collection section listing to a file, avoidingcontamination of stdout with other linker output. (#159706)
• A VersionNode lexer state has been added for betterversion script parsing. This brings the lexer behavior closer to GNU ld.(#174530)
• Unversioned undefined symbols now use version index 0, aligning withGNU ld 2.46 behavior. (#168189)
• .data.rel.ro.hot and .data.rel.ro.unlikelyare now recognized as RELRO sections, allowing profile-guided staticdata partitioning. (#148920)
• DTLTO now supports archive members and bitcode members of thinarchives. (#157043)
• For DTLTO,--thinlto-remote-compiler-prepend-arg=<arg> has beenadded to prepend an argument to the remote compiler's command line. (#162456)
• Balanced Partitioning (BP) section ordering now skips input sectionswith null data, and filters out section symbols. (#149265) (#151685)
• For AArch64, fixed a crash when using--fix-cortex-a53-843419 with synthetic sections andimproved handling when patched code is far from the short jump. (#170495)
• For AArch64, added support for the R_AARCH64_FUNCINIT64dynamic relocation type for relocating word-sized data using the returnvalue of a function. (#156564)
• For AArch64, added support for the R_AARCH64_PATCHINSTrelocation type to support deactivation symbols. (#133534)
• For AArch64, added support for reading AArch64 Build Attributes andconverting them into GNU Properties. (#147970)
• For ARM, fixed incorrect veneer generation for wraparound branchesat the high end of the 32-bit address space branching to the low end.(#165263)
• For LoongArch, -r now synthesizesR_LARCH_ALIGN at input section start to preserve alignmentinformation. (#153935)
• For LoongArch, added relocation types for LA32R/LA32S. (#172618) (#176312)
• For RISC-V, added infrastructure for handling vendor-specificrelocations. (#159987)
• For RISC-V, added support for statically resolved vendor-specificrelocations. (#169273)
• For RISC-V, -r now synthesizesR_RISCV_ALIGN at input section start to preserve alignmentinformation during two-stage linking. (#151639)

---

Link: lld 21 ELFchanges

今年夏天我大概尝试了 3 个月的冷水澡，感觉还不错，一开始不太适应，但慢慢也习惯了，后来天气一冷，就又换回了热水澡。

前几天在看 Andrew Huberman 的视频，他提到了洗冷水澡的诸多好处，尤其是对多巴胺的正面影响，就又开始了冷水澡的尝试，不过这次的挑战明显比夏天的大。

为了避免步子迈太大，我采用了热冷交替法：3 分钟热水（扩张血管），1 分钟冷水（收缩血管），然后做 2-3 个循环，最后以冷水结束。

有了 3 分钟的热水打底，让 1 分钟的冷水变得更能接受些，但当 10 来度的冷水浇在身上时，还是会忍不住地喊出来，甚至跳起来。第一轮的冷水冲击力最大，之后的会稍微好一些，但依旧在舒适区之外。

这看似有点受虐的几分钟，如果从投资的角度看，回报还是挺丰厚的。

硬件的「重启」

人类的身体不是为了恒温环境而设计的。在漫长的进化史上，舒适是异常，寒冷才是常态。当你拧开冷水龙头，实际上是在激活一段古老的代码。

更重要的是，它改变了你的化学环境。冷水能让多巴胺水平显著提升，这种提升不像糖或咖啡因那样会有随后的崩溃（crash），它是一种平稳的、持续的清醒，可以持续 2-3 个小时。

在注意力成为稀缺资源的今天，能够通过一种物理手段，在不服用任何药物的情况下获得这种精神上的敏锐度，这本身就是一种巨大的优势。

软件的「补丁」

洗冷水澡的理念跟斯多葛学派推崇的「自愿不适」(Voluntary Discomfort)也非常 match。但为什么要自找苦吃呢？

因为过度的舒适会让我们变得脆弱。当习惯了恒温、软床和热食，「基准线」会被抬高。一旦环境稍微变得恶劣，就会感到痛苦。冷水澡是一种重置基准线的方式。当你能从容面对冷水时，生活中的其他麻烦——交通堵塞、难缠的邮件、糟糕的天气——似乎就没那么难以忍受了。

这其实是在训练一种极其核心的能力：切断刺激与反应之间的自动连接。

当冷水击中你时，身体的自动反应是恐慌和急促呼吸。这和你在面对工作危机或社交压力时的反应是一样的。通过在冷水中强迫自己冷静下来、控制呼吸，实际上是在重写你的神经回路。你在告诉大脑：「虽然这很不舒服，但我依然掌舵。」

吃掉那只青蛙

早晨通常是一场意志力的博弈。大脑倾向于选择阻力最小的路径。而洗冷水澡是一个反向操作。

这不仅仅是洗澡，可能也是当天的第一个决定。你站在那里，理智告诉你应该拧开冷水，但本能告诉你不要。当你最终执行了理智的命令，你就赢得了一场微小的胜利。

这一胜虽然微不足道，但它至关重要。因为它设定了当天的基调：你不是一个顺从冲动的人，你是一个能够为了长远利益而克服短期不适的人。这种自我认同会像雪球一样滚动，影响你接下来在工作和生活中的每一个选择。

这可能就是为什么这种简单的习惯能带来惊人回报的原因。在这个充满捷径和舒适陷阱的世界里，愿意主动选择不适的人，拥有了一种隐形的竞争优势。

---

洗冷水澡对场地、器材的要求很低，只需要一个淋浴头，就可以开始，而它带来的回报，又非常丰厚。这就是塔勒布在《反脆弱》中提到的「非对称收益」（低风险，高收益）。这么好的投资机会，不想试试吗？

Runloop循环的代码，不是在主线程上运行的吗 Runloop循环的代码，不是在主线程上运行的吗 Runloop循环的代码，不是在主线程上运行的吗

不是说runloop是无限循环吗，为啥主线程还会休眠？ 不是说runloop是无限循环吗，为啥主线程还会休眠？

我们通常会觉得 Routine 是「自由」的反义词，它让人联想到枯燥的重复、僵化的日程表，或者那种一眼就能望到头的生活，这是一个巨大的误解。

在谈论 Routine 之前，我们先来看看复利公式：

FV=PV×(1+r)n

把它放到人生这个大背景下，天赋、机遇和单次努力的强度，构成了那个基础的增长率 r。很多雄心勃勃的人都盯着 r 看。他们试图通过一次通宵工作、一个绝妙的点子或者一次爆发式的冲刺来获得巨大的 FV。

但这很难持久。

Routine 的作用，是掌控指数 n。

在很多方面，Routine 就像是定投。如果只有在「感觉来了」的时候才去写作，或者在「状态很好」的时候才去锻炼，你的 n 是断断续续的，增长曲线是锯齿状的。

而一个好的 Routine 是一种承诺：无论我今天感觉如何，无论 r 是大是小，那个 n 都会自动加一。

当 n 足够大时，它就不再是线性的累加，而是指数级的爆发。那些伟大的小说家每天早起写几千字，不是因为他们每天都有几千字的灵感，而是因为他们把写作变成了一种像刷牙一样的生理节律。他们不对抗它，只是执行它。

这就是 Routine 的本质：它把困难的事情自动化，从而让时间站在你这一边。

---

很多人认为「我不设计 Routine，是因为我不想被束缚」。但真相是：根本不存在「没有 Routine」这回事。

如果你不主动设计你的生活流程，你的身体和环境会为你设计一套。这套「默认 Routine」通常由你的生物本能（懒惰）和外部世界（诱惑）共同编写。

当你拿起手机无意识地刷了两个小时，这本身就是一个极其高效和稳固的 Routine。

既然「默认 Routine」也是自动化的，为什么我们还会感到疲惫？

因为你并没有完全放弃。内心依然有一个想要变好的声音，它在不断地试图把这辆正滑向舒适区的车拉回来。这就是决策疲劳的来源：一场无休止的内战。

• 你的本能说：“再休息一会。”
• 你的理智说：“不行，该干活了。”
• 你的本能说：“那先倒杯水？”
• 你的理智说：“好吧，但喝完马上开始。”

这种讨价还价非常消耗能量，宝贵的精力被浪费在了「决定要做什么」上，而不是「做这件事」本身。

一个好的 Routine（比如「穿上跑鞋 = 出门」）是一条不可协商的规则。它绕过了「谈判」环节，直接进入行动。在这个过程中，你宝贵的意志力没有被内耗掉，而是被完整地保留给了真正重要的问题：如何解决这个难题？如何把作品打磨得更好？

---

如果把人生看作是一项长期的投资，建立 Routine，意味着你从一个短视的投机者，变成了一个长期的价值投资者。

投机者依赖心情、运气、状态、灵感（r），而投资者诉诸系统和时间（n）。

当你开始设计 Routine 时，实际上是在重新分配资产。你不再说「没办法，我就是管不住自己」，而是开始像分析一张糟糕的资产负债表一样分析你的生活：「哦，看来我在‘压力大’这个触发条件下，会自动买入‘逃避’这项资产。我需要调整策略，把它换成‘运动’。」

这并不容易。改变习惯总是痛苦的，但如果坚持下去，哪怕只是每天微调一点点，复利的力量就会显现。

最开始，你只是改变了起床后的 30 分钟。一年后，你会发现你变了一个人。

你不仅改变了你做的事，你改变了你是谁。

所以，不要再把 Routine 看作是一张枯燥的时间表。它是你为了结束内耗、夺回控制权而制定的投资策略。它是你对抗熵增、对抗平庸、对抗混乱的武器。

Routine 就是人生的复利。

Swift闭包语法详解 代码示例 详细解释 这是一个Swift中的闭包（Closure）语法，具体解释如下： 代码分解 语法分析 变量声明： var b：声明一个变量 b :() -> Void：指定

我们来看 The Swift Programming Language (6.2.3) 中的例子。 结构 TwelveOrLess 是属性包装器，属性包装器可以是 class、struct 和 enu

源码地址 https://github.com/bestswifter/BSBacktraceLogger 逐行注释

以 Claude Code 为代表的 Coding Agent 对软件行业的重塑已成定局。它们的可用性已然突破临界点，使得代码生成的边际成本显著下降，比如 Claude Code 本身已经已经全部由 Claude Code 编写了。过去需要一周的硬编码工作，现在可能缩短为半天；过去因技术门槛高而不敢涉猎的领域，现在变得触手可及。

效率的提升带来的是竞争规则的改变，当「实现能力」不再是短板，App 的核心竞争力将发生怎样的迁移？

Agent 的强大，本质上意味着功能性复制的成本显著降低。如果你的护城河仅仅是「写了一个别人写不出的功能」，除非这个功能有极高的技术门槛，否则，其他竞争对手可以用 Agent 在短时间内复刻出一个八九不离十的产品，以更低的价格，甚至免费，来吸引用户。

这正是经典的「智猪博弈」升级版：以前是大猪（创新者）踩踏板，一两只小猪（跟随者）在食槽边等；现在是一二十只全副武装的小猪在那等着。你费尽心思设计的复杂功能，可能通过几轮 Prompt 就被对方解构并重现。

在这个局面下，需要重点关注的，是那些 AI 无法生成、无法复制且具有时间复利 的东西。

1. 从功能实现转向用户洞察

代码是可以被复制的显性知识，但关于「为什么要这样做」的隐性知识是 AI 难以窃取的。

产品的初衷是为了解决特定问题。你需要比同行更深刻地理解你的用户群：他们的使用场景、痛点、情绪触发点以及那些「非理性的诉求」。AI 可以完美执行 How，但无法推导出 Why。

这种基于深刻洞察和独特审美提出的解决方案，是单纯的 UI 克隆无法比拟的。

2. 数据资产与迁移壁垒

用户使用你的产品越久，沉淀的历史记录、个性化偏好、内容积累就越多，迁移成本也就越高。即使竞争对手 1:1 复制了你的功能，他们也无法复制用户在你这里留下的数据上下文。

因此，产品的设计逻辑应从「提供工具」转向「沉淀资产」。让产品越用越懂用户，这种基于数据的个性化体验，是冷冰冰的 AI 克隆版无法比拟的。

3. 开发者角色的演进

代码层面，随着代码量的增加，保障代码的可维护性、可演进性和产品质量变得更加重要，这一方面需要加深对 Coding Agent 的理解，提升熟练度，另一方面也需要深厚的软件开发功底，还要非常熟悉业务。

4. 情感连接与分发网络

对于产品，不仅要解决问题，还要带来愉悦感。这种细微的交互体验、情感共鸣，是建立品牌忠诚度的关键，也是用户愿意自发传播的动力。

分发能力也很重要，在行业中积累的信誉、与 KOL 建立的友好关系、在 Apple/Google 生态中建立的信任权重，这些都是 AI 无法通过算法生成的「社会资本」。

---

Claude Code 并没有让 App 开发这件事变得没有价值，它只是消灭了平庸的重复造轮子，将竞争的维度拉向了两端：一端是更底层的系统架构与质量保障，另一端是更上层的用户洞察与品牌情感。夹在中间单纯靠「写代码」生存的空间，会被挤压地越来越小，甚至消失。

1️⃣ 什么是协议导向编程（POP） 协议导向编程 是 Swift 提出的编程范式，它的核心思想是： 通过协议（protocol）定义接口和行为，而不是依赖类继承。 通过协议扩展（protocol e

窗外的霓虹灯光透过雨幕，在 Jet 的合成皮风衣上投下斑驳的阴影。他抿了一口手中的高浓度咖啡因液，看着面前焦头烂额的 Nova。 “我的编译器又在尖叫了，” Nova 把全息屏幕推向 Jet，上面红色

🍎 引子 新九龙城的雨从未停过。霓虹灯的废气在湿漉漉的街道上晕染开来，像极了那个死于代码过载的倒霉蛋老王流出的脑浆。 在贫民窟第 404 区的一间昏暗安全屋里，一名代号为“老 K”的黑客正对着一块发着

这是本系列的第 2 篇，主题是：不懂不投。

我们刚开始投资理财的时候，通常会寻求以下这些方法来找到投资标的。

常见的错误办法

1、问朋友。我们通常会问那些看起来投资理财收益比较高的朋友，问他们应该买什么股票。
对于朋友推荐的股票，我们通常会“无脑”买入。但如果有一天，股票突然大幅回撤，我们通常就会陷入恐慌。我们会怀疑：这个朋友到底靠不靠谱？他之前赚钱是靠运气，还是因为现在判断出了问题？接着，我们就会陷入各种猜忌、焦虑和紧张中，最后甚至睡不着觉。如果股票持续下跌，我们甚至可能割肉离场。所以说，跟着朋友买其实并不那么靠谱。

2、看走势。我们可能会去看某些股票或基金的历史走势。看到它在过去三年或五年涨得很好，我们就买入。这也是理财 App 或者某些理财经理推荐的首选理由：它过去 X 年涨幅 XX，排名 XX。

但这很容易陷入“价值陷阱”，比如：

1. 周期性误判：有些股票仅仅是在某个周期内表现优秀。比如房地产在过去十年涨得很好，但这并非因为单体公司有多好，而是因为当时整个大环境让所有房企都很赚钱。如果你仅仅因为过去业绩好而买入，一旦遭遇经济下滑或泡沫破裂，就会面临巨大的损失。

2. 均值回归陷阱：很多股票或基金某年表现出色，仅仅是因为那一年的风格与它匹配。所有行业都有“大小年”之分，未来遇到“小年”时，表现自然就会变差。我把这叫做“均值回归”。

这就好比考试：你的平均水平可能是第三名。发挥好的时候能考第一名，发挥不好则可能掉到第五名，但你始终是在第三名上下徘徊。

很多基金经理或股票的表现也是在自身价值上下震荡。如果你在高点买入，在回撤时就会损失惨重，甚至被深套。

3、跟风。跟风是 A 股散户的常见操作，某个时间什么热，就跟风买什么，涨了就快速卖掉，主打一个击鼓传花，赌谁是最后接盘的大傻子。

这种情况下，我们假设你的胜率是 50%。每次获胜挣 20%，每次赌失败亏 20%。如果你进行了 10 次这样的操作，那你整体的收益期望就是 (1.2^5)*(0.8^5)=0.82,所以你折腾了半天，最后 1 块钱的本金变成了 0.82 元。

当然，如果有人认为自己跟风总是赢，这也是有可能的，但是因为自己不敢长期持有，只要涨一点点就卖，其实每次挣的是一点点收益。但是如果偶尔遇到亏损的时候，自己舍不得卖掉，就会一次亏很多。做这种短线操作的人，需要极强的止损纪律，大部分人也是很难做到的。

不懂不投

所以回到股票投资，我觉得投资理财一定要自己懂才行。如果你完全不懂或一知半解，这些都会成为你的陷阱。因为：

1. 心理层面：不懂的人往往“拿不住”。当股票大幅下跌时，无论是否割肉，你都会极度焦虑、睡不好觉，担心本金损失。
2. 投资层面：如果你懂，面对下跌说不定还能逆势加仓；即便不加仓，至少能睡个好觉。

此外，世界上还有很多投资陷阱。有些人甚至专门为“制造陷阱”而生，比如搞资金盘、割韭菜或传销。这些行为有些是非法的，有些则游走在法律边缘。如果大家没有能力分辨这些陷阱，很容易就在投资理财中遭遇严重的亏损。

小结

小结一下，常见的错误投资：

• 问朋友。其实本质上信的是朋友的业绩，朋友如果业绩下滑，就会怀疑。
• 看走势。其实本质上是用过去业绩替代未来判断，不靠谱。
• 跟风。纯投机，50% 胜率下期望是负的。

心理层面，只有懂了，才可能拿得住，睡得着觉。

另外，真正懂也可以避免很多骗局。

以上。

NSProcessInfoThermalState 的作用 NSProcessInfoThermalState 是一个用于表示设备散热状态的枚举类型。它帮助应用程序了解设备当前的温度水平,从而采取适当

1️⃣ Functor 特性在 Publisher 中的体现

Functor 核心：能够把函数映射到容器/上下文中的值，同时保持结构不变。

在 Combine 中：

• Publisher 可以看作一个 容器，异步发出值
• 使用 map 可以对 Publisher 发出的每个元素进行函数映射
• 不改变 Publisher 的结构，只改变输出值

---

示例

import Combine
import Foundation

let publisher = [1, 2, 3].publisher // ArrayPublisher<Int>

let mapped = publisher.map { $0 * 2 }

let cancellable = mapped.sink { value in
    print("Mapped value:", value)
}
// 输出：Mapped value: 2
//       Mapped value: 4
//       Mapped value: 6

• map 只改变 输出值，不改变 Publisher 的类型
• 多次 map 可组合，满足 Functor 规律：

let f: (Int) -> Int = { $0 + 1 }
let g: (Int) -> Int = { $0 * 10 }

let left = publisher.map(f).map(g)
let right = publisher.map { g(f($0)) }

• left == right ✅ 组合律满足

---

2️⃣ Monad 特性在 Publisher 中的体现

Monad 核心：支持 bind（flatMap）操作，能够把返回容器的函数平铺，避免嵌套容器。

在 Combine 中：

• flatMap 对应 Monad 的 bind
• 输入：(Output) -> Publisher<NewOutput, Failure>
• 输出：单一 Publisher，把可能产生的多个嵌套 Publisher 平铺
• 支持链式组合多个异步操作

---

示例

假设我们有两个异步 Publisher 函数：

func fetchNumber(_ id: Int) -> AnyPublisher<Int, Never> {
    Just(id * 2).eraseToAnyPublisher()
}

func fetchString(_ number: Int) -> AnyPublisher<String, Never> {
    Just("Number is (number)").eraseToAnyPublisher()
}

// 使用 flatMap 链式组合
let cancellable2 = [1, 2, 3].publisher
    .flatMap { fetchNumber($0) }   // Monad bind，平铺 Publisher
    .flatMap { fetchString($0) }
    .sink { print($0) }

解释：

1. [1,2,3].publisher → Publisher

2. .flatMap(fetchNumber) → Publisher

   • 每个值会生成一个新的 Publisher
   • flatMap 平铺输出，而不是产生嵌套 Publisher<Publisher>

3. .flatMap(fetchString) → Publisher

4. 最终输出一个 扁平 Publisher，可以订阅

---

3️⃣ Functor vs Monad 对比在 Combine 中

特性	Functor (map)	Monad (flatMap)
操作类型	(Output) -> NewOutput	(Output) -> Publisher<NewOutput, Failure>
结构变化	不改变 Publisher 层级	平铺嵌套 Publisher
适用场景	对值做同步转换	异步链式调用，生成新的 Publisher
示例	.map { $0 * 2 }	.flatMap { fetchNumber($0) }

---

4️⃣ 总结

1. Functor

   • Publisher.map → 映射输出值，保持 Publisher 结构
   • 遵循恒等和组合律

2. Monad

   • Publisher.flatMap → 绑定新的 Publisher，平铺嵌套，短路失败可处理
   • 支持函数式异步流水线，链式组合

💡 核心思想：

Combine 的 Publisher 就是一个 异步容器，Functor 和 Monad 的特性保证了：

1. 可以安全映射数据 (map)
2. 可以安全组合异步操作 (flatMap)
3. 异步值处理保持函数式风格，副作用集中在 sink 或 assign

笔记大概分为三类：个人相关、工作相关和知识相关。个人向的主体是「我」，通常只对自己有意义；工作向的笔记自然与工作相关；知识向的笔记则致力于形成知识网络，时效性较长，也是本文讨论的重点。

相信大家都有用过大语言模型（LLM），如 ChatGPT，DeepSeek，豆包，Gemini 等等，给一个问题，就能得到不错的答案，那么在大语言模型不断进化，AI 工具愈发强大的当下，是否还有记笔记的必要？我认为：不仅有必要，而且比以往更重要。 但前提是，我们需要重新定义「记笔记」这件事。

笔记是什么？我把它看作 「外化的思考脚手架」。我们的大脑工作内存有限，只能同时处理 3-5 个想法，笔记可以将大脑从「记忆」的负担中解放出来，全力投入到「运算」中。笔记不是最终的目的，而是用于构建更高层建筑的工具，比如写文章，做决策，解决问题，它的价值在于它能支撑你爬得更高。

更形象的比喻或许是：预处理过的「半成品料理包」。当你来到厨房（需要解决问题/写作/决策）时，不需要从洗菜、切菜开始，而是直接拿出切好的配菜、调好的酱汁，就能快速烹饪出一道大餐。

在 AI 时代，有什么不懂直接问 AI 就好了，为什么还要记笔记？因为缺少内化的知识网络，就问不出好问题，没有好问题，就很难得到好答案，就无法最大程度地挖掘 AI 的潜力。大语言模型遵循的是 GIGO（Garbage In Garbage Out）原则，没有好的输入，就很难得到好的输出。笔记系统可以帮助我们构建/强化知识网络，从而问出好问题。

比如前一阵很火的 Dan Koe 的 How to fix your entire life in 1 day 这篇文章，看完之后，可能觉得很有道理，但不一定能问出合适的 follow up，比如文章提到的思想跟斯多葛的消极想象有什么联系？或文章提到的身份认同理论是否与 Atomic Habits 中提到的身份认同概念一致？以这些问题为切入点，可能又能获得到一些不错的新的知识点和看世界的角度，进而丰富自己的知识体系。

工作流概览

一个好的笔记系统不仅仅是工具的堆砌，更是信息的流动。我的工作流包含五个阶段：

1. 捕获：极低阻力地快速收集。
2. 存储：将待处理内容归位到合适的介质。
3. 处理：提炼、消化原始内容。
4. 回顾：建立连接，内化知识。
5. 产出：用笔记解决实际问题，形成闭环。

一、捕获阶段 (Capture)

核心原则：极低阻力。灵感和信息稍纵即逝。这个阶段唯一的任务就是把脑子里的想法或外界的信息扔进一个固定的盒子里。此刻不要整理，也不要分类，只要丢进去即可。

我推荐 Apple Notes 的 Quick Note，系统级集成，很方便。Mac 上一键唤出，iPhone Control Center 随时点击。支持富媒体（语音、手绘、链接），就像一张随手可得的便利贴。

我的信息主要来自 Twitter(X)、YouTube、Newsletter、博客以及与 Gemini 的对话。为了解决「想看视频但没时间/效率低」的问题，我还构建了一套自动化流程：用 js 脚本调用 YouTube API 抓取字幕，通过 LLM 进行精简并整理成文章，最后打包成 Epub 电子书。这让我能像阅读文章一样「阅读」视频，大大提升了效率。

这里要避免沉迷于「寻找好内容」这种多巴胺陷阱，建议设定特定的「进货时间」（如周末早晨），批量获取信息，然后断连。同时不要试图在捕获阶段去消化内容，那样会打断「狩猎」节奏。

二、存储阶段 (Storage)

捕获的内容通常是链接、书籍或长文。这个阶段的目标是让它们「各归其位」，等待处理。

「链接」我推荐 Goodlinks。它没有订阅制，设计优雅，功能纯粹。我把它当作我的链接「中转站」。

「电子书」我没有使用 Apple Books 或 Calibre，而是直接使用 macOS Finder + Tags。把待看的书扔进文件夹，看完的书打上特定的标签，这样只要 filter by tag，就能看到看过的书和没看的书。这么做的一个原因是不争气的 Apple Books，它不支持 Smart Filter，只能手动创建 Collection，这样就很不方便筛选出没有看的书，我希望它像一个 Queue 或 Stack，随着书一本一本被看完，这个列表里的内容也会逐渐减少。还有一个原因是，书放进去后，再导出来也不太方便。

三、处理阶段 (Processing)

这是整个工作流中最重要，也是最容易被忽视的部分，很多人的笔记系统往往停在了上一步。这一步的目的是蒸馏(Distillation)，提炼出有价值的内容，而不是简单地复制粘贴。

这个阶段最重要的，也是最难的部分，是要为它留出时间（比如每天晚上），因为做这件事可能没有那么愉悦，如果不专门留时间，几乎肯定会被其他阻力更小的事情代替。

这个阶段我用到的工具是 Dia 浏览器，没有直接在仓库中处理是不想看着一大堆未处理的内容产生焦虑，选择 Dia 浏览器是因为它的 Vertical Sidebar 和 Split view 很方便，同时因为它是浏览器，对链接天然友好，还能方便地唤出 Gemini。

浏览器可以打开 pdf，但默认不支持 epub，所以我又做了一个浏览器的 epub 插件，可以一边看书，一边与 Gemini 就书的内容进行交流。

待处理的内容通常比较长，或者是非母语的内容，为了提高效率，我会先让 Gemini 对内容进行压缩，如果感兴趣，再去看原文，然后与 Gemini 就里面的内容进行深度的交流。这是一个例子。交流完后，通常会有这些产出：

• 一篇原文的精简版（放到笔记 App 里）
• 一篇讨论后的笔记（放到笔记 App 里）
• 一些原文的精彩摘录（放到笔记 App 里）
• 方便录入到 Anki 的卡片（整理成实体卡片）
• 相关推荐

Anki 相关的 App 一直用不起来，还是更喜欢实体的卡片，所以会把相关的知识点写到卡片上，顺便加深下印象。

处理后的笔记，我选择存放在 Bear 中。

• 为什么不选 Obsidian？ 它确实功能强大且免费，也有丰富的插件系统，但我用起来总觉得不够「舒服」。
• 为什么不选 Apple Notes？它对 Markdown 的支持不友好，内容也有点封闭，写作体验也不如 Bear。

选择 Bear 还有一个好处，它的笔记可以很方便地导出为 Markdown，方便二次加工和后续迁移。孤立的笔记是死的。让笔记活过来的关键是Link（链接）。因为 Bear 的笔记都存在本地的一个 SQLite 数据库里，所以可以很方便地读取和处理。我写了一个 js 脚本，将 Bear 里的笔记内容向量化（Vectorization），然后计算余弦相似度，自动生成「相关笔记」列表。

四、回顾阶段 (Review)

把笔记存进去如果不看，那意义也不大。为了方便回顾，我做了一个 Web App（notes.limboy.me），每次随机展示一篇笔记作为起点，然后通过「相关笔记」进行漫游。同时也会在碎片时间把上一个阶段生成的卡片拿出来翻一翻，加深印象。

五、产出阶段 (Output)

笔记不是目的，它是为了帮助生成洞见（Insight）、新的看事物的角度和强化知识网络而存在，最好的方式就是输出，比如写文章、做分享、做决策等。以写文章为例，如果想写一篇关于「习惯养成」的文章，不再是面对空白文档抓耳挠腮，只需在笔记库里搜索「习惯」、「行为心理学」，把相关的 5-6 个笔记块（料理包）调出来，重新排列组合，加上新的连接词，文章的 80% 就完成了。

结语

如果没有一套运行顺畅的笔记系统，没有为消化笔记专门留出时间，没有输出的压力，那么笔记的价值就会大打折扣，再好的工具也无法做到第二大脑。希望这篇文章能给你带来些帮助和启发，如果你有好的想法和经验，也欢迎分享。