reactived，从这里开始

我曾经把个人博客理解为一个容器：写过的东西依次放进去，时间自然会替它们形成秩序。后来我越来越确信，时间只会形成档案，不会自动形成观点。一个站点真正值得长期维护的部分，是它如何选择问题、建立联系，又如何在新证据出现时修改自己。

reactived 的新起点，就是把这种选择变得清楚。

不是栏目，而是观察系统的三个尺度

这个站点会写 AI、开源项目、产品、编程语言、函数式编程、并发和架构。它们看起来像很多主题，但我并不打算把它们平铺成一排互不相关的栏目。更稳定的结构，是用三个尺度理解它们：

1. Intelligence：模型、运行时、Agent 和上层应用如何形成新的智能系统。
2. Systems：基础设施、分布式系统与开源架构如何把抽象意图变成可运行的系统。
3. Languages：语言、类型、语义和计算模型如何约束我们能够表达与构造的东西。

它们不是彼此隔离的文件夹。模型服务的约束会改变产品体验，语言的并发模型会改变系统架构，开源项目中的一个实现选择也可能暴露出更大的产品判断。

先理解变化发生在哪里，再判断系统应该如何被构造。技术细节不是装饰，它们是判断能够成立的证据。

从“是什么”继续追到“为什么这样构造”

技术文章很容易停在两端：一端是概念摘要，另一端是代码片段。真正有价值的分析通常发生在中间——把约束、边界、权衡和最终行为连成一条可以检验的链路。

例如，分析一个开源 Agent 项目时，我更关心下面这条路径，而不是罗列功能：

type SystemDecision = {
  constraint: string
  boundary: string
  mechanism: string
  userVisibleEffect: string
}

const analysis = (decision: SystemDecision) =>
  `${decision.constraint} -> ${decision.mechanism} -> ${decision.userVisibleEffect}`

这条路径要求文章同时回答四个问题：

• 它面对的真实约束是什么；
• 责任被放在哪一个边界；
• 代码或架构用什么机制承担这项责任；
• 这个机制最终如何改变性能、可靠性或用户体验。

深度不是篇幅。深度是你能否把一个可见结果，沿着真实机制追溯到形成它的约束。

写作形式服务于问题，而不是反过来

不同问题需要不同的叙述速度。本站会使用四种主要形式，但形式只是阅读合同，不是内容边界。

一篇文章也不会因为使用了某种形式，就被锁死在一个主题里。关于函数式并发的文章，既可以属于语言设计，也可以讨论运行时和分布式架构；对 Agent 产品的研究，也可能一路追到模型调用、状态同步和权限边界。

内容需要可以被连接

文章 metadata 是连接这些内容的基础。它不是发布后台里的附属字段，而是站点结构的事实来源：

type ArticleMeta = {
  format: 'explainer' | 'deep-dive' | 'research' | 'essay'
  domain?: 'intelligence' | 'systems' | 'languages'
  topics: string[]
  translationKey?: string
}

因此，同一篇文章能够进入最新写作、主题索引、系列和相关阅读，而不需要在多个页面手工复制一份列表。中文与英文版本通过 translationKey 关联，也仍然保有各自独立的正文与摘要。

输入发生变化，模型更新理解，系统据此重构；新的系统又继续接收下一次变化。 reactive 不是视觉效果，而是一种持续理解与构造的循环。

个人站点仍然应该有个人判断

结构化不意味着把个人声音抹掉。恰恰相反，只有当事实、推理和观点被清楚地区分，个人判断才真正有价值。

我会尽量做到：

• 对事实给出可以追溯的依据；
• 对推断说明中间链路；
• 对偏好承认它依赖的目标与约束；
• 对尚未确定的结论保留继续修改的空间。

这也是域名里最后一个 d 的另一层含义：daemon。它不是“永远输出”的姿态，而是一个持续在线的进程——观察变化、更新模型，在值得写的时候构造出更好的解释。¹

如果要用一句话概括这次重建，它仍然是：理解变化，构造系统。