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. Changesback ported to the 21.x release are removed(git log --oneline llvmorg-22-init..llvmorg-21.1.8 -- lld).

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)This is an interesting relocatablelinking challenge for linker relaxation.

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.

Distributed ThinLTO

Distributed ThinLTO(DTLTO) enables distributing ThinLTO backend compilations toexternal systems (e.g., Incredibuild, distcc-like tools) during the linkstep. This feature was contributed by PlayStation, who had offered it asa proprietary technology before upstreaming.

The traditional distributed ThinLTO is implemented in Bazel in buck2.Bazel-style distribution (build system orchestrated)uses a multi-step workflow:

1
2
3
4
5
6
7
8
9

# Compile to bitcode (made parallel by build system)
clang -c -O2 -flto=thin a.c b.c
# Thin link
clang -flto=thin -fuse-ld=lld -Wl,--thinlto-index-only=a.rsp,--thinlto-emit-imports-files -Wl,--thinlto-prefix-replace=';lto/' a.o b.o
# Backend compilation (distributed by build system) with dynamic dependencies
clang -c -O2 -fthinlto-index=lto/a.o.thinlto.bc a.o -o lto/a.o
clang -c -O2 -fthinlto-index=lto/b.o.thinlto.bc b.o -o lto/b.o
# Final native link
clang -fuse-ld=lld @a.rsp   # a.rsp contains lto/a.o and lto/b.o

The build system sees the index files from step 2 as outputs andschedules step 3 jobs across the build cluster. This requires a buildsystem that handles dynamic dependencies—outputs ofstep 2 determine inputs to step 3.

DTLTO (linker orchestrated) integrates steps 2-4into a single link invocation:

1
2

clang -flto=thin -c a.c b.c
clang -flto=thin -fuse-ld=lld -fthinlto-distributor=<distributor> *.o

LLD performs the thin-link internally, generates a JSON jobdescription for each backend compilation, invokes the distributorprocess, waits for native objects, and links them. The distributor isresponsible for farming out the compilations to remote machines.

DTLTO works with any build system but requires a separate distributorprocess that speaks its JSON protocol. DTLTO is essentially "ThinLTOdistribution for projects that don't use Bazel".

Pointer Field Protection

R_AARCH64_PATCHINST is a static relocation type usedwith Pointer Field Protection (PFP), which leverages Armv8.3-A PointerAuthentication (PAC) to protect pointer fields in structs.

Consider the following C++ code:

1
2
3
4
5
6
7
8
9

struct cls {
  ~cls();
  long *ptr;
private:
  long *ptr2;
};

long *load(cls *c) { return c->ptr; }
void store(cls *c, long *ptr) { c->ptr = ptr; }

With Pointer Field Protection enabled, the compiler generates PACinstructions to sign and authenticate pointers:

1
2
3
4
5
6
7
8
9
10

load:
  ldr   x8, [x0]      // Load the PAC-signed pointer from c->ptr
  autda x8, x0        // Authenticate and strip the PAC, R_AARCH64_PATCHINST __pfp_ds__ZTS3cls.ptr
  mov   x0, x8
  ret

store:
  pacda x1, x0        // Sign ptr using c as a discriminator, R_AARCH64_PATCHINST __pfp_ds__ZTS3cls.ptr
  str   x1, [x0]
  ret

Each PAC instruction is associated with anR_AARCH64_PATCHINST relocation referencing adeactivation symbol (the __pfp_ds_ prefixstands for "pointer field protection deactivation symbol"). By default,__pfp_ds__ZTS3cls.ptr is an undefined weak symbol in everyrelocatable file.

However, if the field's address escapes in any translation unit(e.g., someone takes &c->ptr), the compiler definesthe deactivation symbol as an absolute symbol (ELFSHN_ABS). When the linker sees a defined deactivationsymbol, it patches the PAC instruction to a NOP(R_AARCH64_PATCHINST acts as R_AARCH64_ABS64when the referenced symbol is defined), disabling the protection forthat field. This is necessary because external code could modify thepointer without signing it, which would cause authenticationfailures.

The linker allows duplicate definitions of absolute symbols if thevalues are identical.

R_AARCH64_FUNCINIT64 is a related static relocation typethat produces an R_AARCH64_IRELATIVE dynamic relocation (GNU indirectfunction). It initializes function pointers in static data at loadtime by calling a resolver function that returns the PAC-signedaddress.

PFP is AArch64-specific because it relies on Pointer Authentication(PAC), a hardware feature introduced in Armv8.3-A. PAC providesdedicated instructions (pacda, autda, etc.)that cryptographically sign pointers using keys stored in systemregisters. x86-64 lacks an equivalent mechanism—Intel CET providesshadow stacks and indirect branch tracking for control-flow integrity,but cannot sign arbitrary data pointers stored in memory.

Takeaways:

• Security features need linker support. This is because many featuresrequire aggregated information across all translation units. In thiscase, if any TU exposes a field's address, the linker disablesprotection for this field everywhere The implementation isusually lightweight.
• Relocations can do more than fill in addresses:R_AARCH64_PATCHINST conditionally patches instructions toNOPs based on symbol resolution. This is a different paradigm fromtraditional "compute address, write it" relocations.

RISC-V vendor relocations

RISC-V's openness encourages vendors to add custom instructions.Qualcomm has the uC extensions for their microcontrollers; CHERIoT addscapability-based security.

The RISC-V psABI adopted the vendor relocation system:

1
2

Relocation 0: R_RISCV_VENDOR      references symbol "QUALCOMM"
Relocation 1: R_RISCV_QC_ABS20_U  (vendor-specific type)

The R_RISCV_VENDOR marker identifies the vendornamespace via its symbol reference. The subsequent relocation uses avendor-specific type number that only makes sense within that namespace.Different vendors can reuse the same type numbers without conflict.

In lld 22:

• Infrastructure for vendor relocations was added (#159987).The implementation folds vendor namespace information into the upperbits of RelType, allowing existing relocation processingcode to work with minimal changes.
• Support for statically-resolved vendor relocations was added (#169273),including Qualcomm and Andes relocation types. The patch landed withoutinvolving the regular lld/ELF reviewer pool. For changes that setarchitectural precedents, broader consensus should be sought beforemerging. I've commentedon this.

The RISC-Vtoolchain conventions document the vendor relocation scheme.

There's a maintainability concern: accepting vendor-specificrelocations into the core linker sets a precedent. RISC-V is uniquelyfragmented compared to other LLVM backends-x86, AArch64, PowerPC, andothers don't have nearly as many vendors adding custom instructions andrelocations. This fragmentation is a direct consequence of RISC-V's opennature and extensibility, but it creates new challenges for upstreamtoolchain maintainers. Accumulated vendor-specific code could become asignificant maintenance burden.

Link: lld 21 ELFchanges

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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。但为什么要自找苦吃呢？

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

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

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

吃掉那只青蛙

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

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

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

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

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

我们通常会觉得 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 就是人生的复利。

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

这是本系列的第 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% 胜率下期望是负的。

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

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

以上。

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

相信大家都有用过大语言模型（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% 就完成了。

结语

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