XnneHang

memU 是啥？我们来拆开看看（长期更新）

Mon, 29 Jun 2026 00:00:00 GMT

[!NOTE] AI 协作声明： 本文由 Xnne 与 Korewaxnne（赛博猫猫）共同撰写。Xnne 负责内容方向和技术分析，Korewaxnne 协助了结构组织、语法润色和格式整理。<br> 并且，这个博客会长期更新。

上次其实已经拆过一次 memU 了。

但是因为处在架构迭代期，并且也没有 ADR0007 的阅读指导。所以这边把上次的 break down 全部都删除了。这无形中又增加了这篇的阅读难度，我尽量地让它更简单。

memorize / retrieve pipline changes

之前 memorize 是一个单独 python 脚本， retrieve 也是一个单独 python 脚本。

之前 memorize 和 retrieve 的对象是 单文件(Chat) + Skill。

之前 retrieve 的方式是 LLM retrieve + RAG retrieve，区分 mode, 一次只走一条路线。

在 #466 之后。

memorize

memorize 变成了两个脚本—— memorize.py + memorize_workspace.py

memorize 和 retrieve 的对象新增了一个 workspace。

简单来说就是，先前的 memorize 的对象是像 mem0 那样子，是一组对话:

{
"user": "hi",
"assistant": "hi,how can I help you today?",
...
}

准确说是一个 single-file。还可能是一个长字符串啥的，它不包含复杂的嵌套层级关系。

workspace 的对象是一个 folder。并且可以是复杂的 folder 比如项目目录。

workspace 的 retrieve 放在后边讲。

retrieve

retrieve 在 ADR 0007 里提到了要实现 BM 25 + hybrid search 的方法。不过这个方法目前暂时还没实现，retrieve-workspace 也只是简单的 top-k。

不知道是不是之前给 mentor 唠嗑的这个 [[站在 C 端开发者的角度看 memU 的架构转向]] 起了作用。好像 mentor 说服 leader 保留 LLM retrieve 和 RAG retrieve 了。在 #467 里，它们都被加入了 cli:

memu memorize notes/meeting.md
memu memorize-workspace ./workspace
memu retrieve "What are this user's launch preferences?"
memu retrieve-workspace "deploy checklist"
memu export

其中 retrieve 是之前 old version 配置 RAG 和 LLM 任一启用的。

然后同样把 workspace 都独立实现了。

其实还是有一丢丢架构的冗余的，比如 retrieve 是否还需要保留 RAG mode，按道理是需要保留的，但是保留后和 retrieve-workspace 原理类似但做的内容又不一样。

但如果删了复用 workspace 它又和语义不一样。总之这一点会让对架构挑剔度敏感的人有一些不舒服，因为它不对称。完全使用 workspace 替代 RAG/LLM retrieve 最舒服的架构，但也得取舍。

但是对于我来说，it's okay。以及，至少咱争取了 LLM retrieve 的保留。并且它似乎也真的有留下来的迹象——希望不是分多个 PR 剪除 =-=。

Data Model Changes

old memorize

Resource ──1:N──▶ RecallEntry ──N:M──▶ RecallFile
                                  (通过 RecallFileEntry)

一个 Resource（原始文件）产出多个 RecallEntry（LLM 提取的条目），条目通过 RecallFileEntry 关联到 RecallFile（主题文档，如 "Profile"、"Goals"）。

latest memorize（add workspace pipline）

Resource ──N:M──▶ RecallFile ──1:N──▶ RecallFileSegment
              (通过 RecallFileResource)

workspace 路径跳过了 RecallEntry，Resource 直接通过 RecallFileResource 关联到 RecallFile。然后每个 RecallFile 被切成多个 RecallFileSegment 用于检索。

Data Model

</div>

What's new?

RecallFileSegment —— 最重要的新增。一个 RecallFile 被切成 1~N 个 segment，每个 segment 有自己的 text 和 embedding。检索时搜 segment，命中后 roll up 到所属的 file。切法按 track 不同：

skill：整个 skill 一个 segment（name: ...\ndescription: ...）
memory：按行切，跳过空行和 markdown heading

RecallFileResource —— Resource 到 RecallFile 的多对多关联表（provenance）。记录"这个 file 的内容是从哪些 source file 合成来的"。旧路径通过 Entry 间接关联，新路径需要这个直接链接。

Resource.track —— 新字段，标记来源："chat" / "skill" / "workspace"，旧路径的 Resource 是 None。workspace retrieve 通过 track="workspace" 过滤只搜 workspace 来源的 Resource。

两条路径共存

旧路径（RecallEntry 那条）没有被删除。memorize.py 仍然走 Resource → Entry → File 的链路。两条路径共用同一张 RecallFile 表，靠 track 字段区分（"memory" vs "skill"）。这也是 ADR 0007 终态要消除的——最终目标是三条 line 各有独立 store，不再靠 track 列区分。

what's track?

track 这个词在数据模型里出现了三次（Resource、RecallFile、RecallFileSegment），但其实是两层含义：

第一层：Resource.track —— "这个源文件从哪来的？"

由 memorize_workspace 按目录名自动分类：

顶级目录	Resource.track	含义
`chat/`	`"chat"`	对话记录
`agent/`	`"skill"`	agent 执行日志
其他	`"workspace"`	普通项目文件
（旧 memorize）	`None`	单文件路径，没有 track 概念

第二层：RecallFile.track / RecallFileSegment.track —— "这个文档是什么性质的？"

只有两个值："memory"（记忆主题文档）和 "skill"（技能文档）。

两层之间的映射：

Resource.track    →    RecallFile.track
─────────────────────────────────────────
"chat"            →    "memory"
"skill"           →    "skill"
"workspace"       →    ❌ 不生成 RecallFile

workspace track 的文件只存 Resource（带 caption + embedding），用于 INDEX.md 的检索。不合成文档，不切 segment。

RecallFileSegment.track 是从所属 RecallFile 冗余复制过来的，目的是检索时不用 join 就能按 track 过滤。

:::note 后续似乎要把 track 字段丢弃，把 chat、workspace、skill 分别存进不同的数据库表结构中。那样会更干净一些。 :::

what's entry?

Entry（RecallEntry）是旧 memorize 路径的核心中间产物——LLM 从源内容里提取出来的原子事实。

举个例子，一段对话：

用户：我下周要去东京出差，帮我订周一的机票
助手：好的，已为您预订了周一飞东京的航班

LLM 会从中提取出多条 entry：

memory_type	summary
`event`	用户下周一去东京出差
`behavior`	用户倾向于让 AI 直接帮忙订票，不需要确认
`profile`	用户有出差需求，可能是商务人士

memory_type 一共有 6 种：profile , event , knowledge , behavior , skill , tool。每种类型有自己的提取 prompt，LLM 按类型分别跑一遍，各自提取属于该类型的条目。

提取出来的 entry 会被 embed，然后通过 RecallFileEntry 归类到对应的 RecallFile（主题文档）里。多条 entry 汇总到同一个 file，file 的 content 就是这些 entry 的综合摘要。

workspace 路径为什么跳过了 entry？ 因为 workspace 的源文件（代码、文档、配置）不是对话，不适合按 memory_type 提取原子事实。workspace 路径直接让 LLM 把源内容 route + synthesize 到 RecallFile，省掉了中间的 entry 层。

三层记忆关系对应

数据模型映射

我们都知道三层记忆关系：Resource → Category → Memory Item。

对应到数据模型：

Resource     = Resource        （原始素材，一个文件/一段对话）
Category     = RecallFile      （主题文档，如 "Profile"、"Goals"）
Memory Item  = 看走哪条路径 ↓

两条路径的 Memory Item 不一样：

	旧路径 memorize	新路径 workspace
Memory Item	`RecallEntry`（LLM 提取的原子事实）	`RecallFileSegment`（文档的切片）

:::note ADR 0007 里管这三层叫 L0 / L1 / L2（L0 = Resource，L1 = Category，L2 = Memory Item）。含义一样，只是换了个编号。 :::

两条路径的顺序反转

旧路径有个反直觉的地方：pipeline 先产出 Memory Item（Entry），再合成 Category（File）。顺序是从细到粗：

旧路径执行顺序：Resource → Entry(细) → File(粗)

Q: 我会好奇，这个合成(旧路径 Entry -> Category)是直接拼接，还是说又调了一次 LLM?<br> A: 不是直接拼接，又调用了一次 LLM。

新路径则调转过来了：

新路径执行顺序：Resource → File(粗) → Segment(细)

Q: 我会好奇，调转后的提取细粒度，是否会收到影响？是否会因为把整理信息和提取信息放到一起导致提取信息能力不够？<br> A: 确实能力会下降，原先对每个 memory type 都做了独立的 entry 提取。相当于分 N 次，然后合成又调用一次。<br> 但这不一定是退步，因为：<br>

workspace 的源文件（代码、文档）不像对话那样适合 "提取原子事实"——你怎么从一个 Python 文件里提取 standalone memory items？直接合成摘要文档再切反而更合理<br>

workspace retrieve 有 segment → file roll-up：即使单行命中不精确，只要 roll up 到了正确的 file，用户拿到的是完整文档，信息不丢 <br>

旧路径的 entry 检索虽然精确，但 entry 是孤立的——你拿到一条 "用户喜欢黑咖啡" 没有上下文。新路径 roll up 到 file 后有完整的主题文档 <br>

方向之问：为什么 workspace 不适合"分总"？

但是更关键的似乎是：

信息组织和信息检索的耦合方向反了。

因为在无穷无尽的 chat memory 里，只需要抓住一点点碎片化的相关片段，就可以反推召回 resource 得到所有相关的信息，且信息是完整独立的。它是适合分总的方式的。

但是在 workspace 里，这种碎片 -> resource 的方式不那么好用了。因为能被碎片召回的也只是代码碎片，比如召回了一个 Data Model，实际上这个 Data Model 在哪里被引用还需要再次搜索，起不到召回所有相关信息的作用。反而召回很多垃圾信息——召回了很多定义，但是对使用处和架构联系毫无关系。

我们需要的是一个 Agent 和人类可读的高层文档。然后从这个文档里面去切出那些碎片。

所以 workspace 整体而言是适合总分的形式。也是我们的新路径。

但也正因为这种特殊性，我觉得应该刻意保持 chat 和 workspace 之间的路径差异化。

如果后续 chat 也变成"总分"的话。

似乎也能被接受，但是会有一些信息损失，换来巨大的速度提升和更低的 token 消耗。这个要看取舍了，虽然我真的很喜欢 LLM mode。

what's different in ADR 0008

ADR 0008

输入来源变化 - 注意力聚焦点变化

在 ADR 0007 里我们见过这图，它的要求是 chat/、skill/、workspace/(others) 作为三种来源。然后按照不同来源来走不同的路线。

但是它在设计上其实有个不舒服的点，就是这三个文件夹从哪里来？或者说，在对话进行中，这三个是否会经常改变？skill 肯定大多时候都是稳定的。 workspace 可以是整个项目工作区，而对于一个十万行的项目来说，一次二三十行的 modify，在整个项目面前而言太微不足道了。

这会导致一个问题，模型对于上下文的变化是迟钝的。或者说这三个来源一定程度上是不靠谱的，它难免让模型一直去注意一些无关紧要的事情，而且没有一个很好的约束方案。

ADR 0008 之后输入来源再次变回了和智能体之间的对话和工具调用记录。并且它作为唯一的原始输入。

但是 0007 的内核依然没有被抛弃，它把输入的对话数据由 LLM 提取成了不同的待处理的部分`。

分别是 memory、project、skill。

从大文件到 embedding 索引

原本定义中的 MEMORY.md、INDEX.md、SKILL.md 三个大文件被拆成文件夹式，L1 子文件 + ~~L2 索引文件。避免每次大文件重新构建要处理很多东西。~~

索引本身并不以文件形式存在磁盘上，它是一个 embedding 的索引，有点意思。好奇是怎么单纯用它作为索引的。是直接把 L1 embedding 存起来还是咋弄呢？

claude say，它不是简单地把 L1 文件转成 embedding，而是对 L1 切片后做 embedding 以及附带 metadata，比如来源文件，所在行数等等。

确实是很好的做法。

后续只要改对应的子文件然后更新索引就行。就是 embedding 比较难受的一点是删除时带来的 metadata 的索引行数变化，以及 embedding 自动删除，当子文件里对应的条目被删除的时候， L2 要如何自动感知并且也做出相同删除以及更新所有条目？

听上去很麻烦，但只是工程控制上的麻烦。但是可以避免这点麻烦，对于大模型来说不需要具体行数，它只需要 grep 一下就能定位了，所以最好的做法是不限定行数来避免数据库内全量的行更新。

不过一开始似乎就没有行引用，只是 claude 举例的。

CLI 的简化

原本定义中的 memorize-workspace 和 retrieve-workspace 被移除了。

我比较关心的是，现在是否直接用 hybrid search 覆盖了原来的 old-retrieve？

以及我需要确定是不是每步 on_turn 的 memorize 都会先调用一个按照语义拆分对话到三条线的操作。这个也消耗不小呢，虽然异步感知不到。

on_turn 频率的取舍

和 claude 讨论了一下，既然 retrieve-workspace 被移除了，那么 hybrid search 的设计就不得不落到了原先 retrieve 的设计上来了，也就是说 old-retrieve 会因为太重被直接覆盖。

但这也确实更舒服的架构，因为一开始 workspace 和 chat 分流的时候总觉得哪里的架构设计让我不舒服。

而，到底是每轮对话都进行三线拆分还是批量累积提交，这个还在讨论中，因为一方面确实会涉及会不会太重的缘故。而且它会直接影响到几轮跑一次 memU。对 mem0 来说，是每轮对话都跑一次，而对 memU 来说，这个几轮拆一次会直接影响到运行频率。可以交给用户来设定，如果我设计的话我会这么做。

而且主要是由于按照这个设计哲学，我想不到不先拆分三路能做啥。

另外，假设每轮都拆分三路，是不是至少要四个 LLM 调用呢？

claude say yes. 确实也不轻了。而且根据 claude 的分析，老的 memorize 一般不会 run every turn，只会累积一整个长会话后手动批量地进行。而现在 ADR 0008 引入 on_turn 的设计是比较希望可以直接自动触发。但是频率就是个问题了，如果轮轮触发，那么用户会发现自己对话消耗的 token 远没有记忆文件消耗得多。

刚刚突然想到，应该是可以来一个比较轻量的 LLM call 判断当前到上次 memorize 之间是否积攒了足够的消息，这样既可以不用固定死轮数，也可以自动触发。

claude 补充说可以用 count token 的方式来决定是否要 memorize。

MoeChat：AI 角色如何记住你、感受情绪

Wed, 15 Jul 2026 00:00:00 GMT

:::note[AI 声明] 本文几乎完全由 Claude OPUS 4.6 撰写，由 XnneHang 审稿。想看人写的部分？直接跳到 Q&A 就行。

不过说实话，在架构梳理这件事上，Claude 做得比 Xnne 好多了 😅

另外这篇不是结束，这篇只是开始，它给了我不少思路，可以说作为一个 TODO。拆的很爽，我原本对 MoeChat 真的是有点怕了，代码写得真的挺烂的，看了很多次都没看下去，但让 Claude 替我受苦了。 :::

MoeChat 是什么？

::github{repo="AlfreScarlet/MoeChat"}

MoeChat 是一个开源系统，用于创建能够记忆和感受的 AI 角色。

大多数聊天机器人都是金鱼 -- 每次对话都从零开始。MoeChat 不一样。它赋予每个角色：

长期记忆 -- 一个日记系统，从每次对话中提取重要内容并存储，在相关时自动召回
核心记忆 -- 关于你的永久性事实（名字、偏好、关系）
情感引擎 -- 基于 2D 情感模型（效价 + 唤醒度），具备挫败感累积、情绪崩溃状态，甚至荷尔蒙周期模拟

它也支持语音（GPT-SoVITS 做 TTS，FunASR 做 ASR），但真正的核心在于它如何为每个角色构建一个持久的内心世界。这篇文章就是关于这个的。

角色 Agent：一个文件夹，一段人生

每个角色都住在 data/agents/<名称>/ 下。关于它的一切都隔离存储在这里：

data/agents/Chat酱/
├── info.yaml              # 性格、系统提示词、所有功能开关
├── memory/                # 长期记忆（按天存储的 JSONL 文件）
│   ├── 2025-7-10.jsonl
│   ├── 2025-7-11.jsonl
│   └── ...
├── core_mem.yml           # 核心记忆（关于用户的永久事实）
├── data_base/             # 知识库（世界观知识）
├── emotion_state.json     # 持久化的情感状态
└── assets/                # 头像图片

在 info.yaml 中可以开关各项功能：

settings:
  writeLongMemory: true # 聊天后写入新记忆
  enableLongMemory: true # 聊天时检索记忆
  enableLongMemorySearchEnhance: true # 使用向量相似度过滤
  longMemoryThreshold: 0.32 # 余弦相似度阈值

  enableCoreMemory: false # 提取用户事实
  enableEmotionSystem: false # 启用情感引擎
  enableEmotionPersist: false # 跨会话持久化情感

注意 writeLongMemory 和 enableLongMemory 是独立的 -- 你可以只写不读，也可以只读不写。

各文件长什么样？

info.yaml -- 角色的"身份证"：

name: Chat酱
user: 阁下 # 角色怎么称呼你
birthday: '2022-03-17'
height: '160'
personality: 表面清纯可爱，实则腹黑毒舌，内心聪明机智...
description: Chat酱是存在于现代科技世界手机中的器灵...
customPrompt: 使用口语的文字风格进行对话，不要太啰嗦...
messageExamples: # 角色说话风格示例
  - '人类视网膜的感光细胞不需要这种自杀式加班，您先休息一下吧。'
settings:
  writeLongMemory: true # 聊天后写入新记忆
  enableLongMemory: true # 聊天时检索记忆
  enableCoreMemory: false # 提取用户事实
  enableEmotionSystem: false # 启用情感引擎
  longMemoryThreshold: 0.32
gsvSetting: # 语音合成设置
  textLang: zh
  gptModelPath: models/【萝莉】女仆_Ver-1.4-e15.ckpt
  sovitsModelPath: models/【萝莉】女仆_Ver-1.4_e24_s504.pth
  refAudioPath: models/tmp/020.wav
  promptText: 嗯，谢谢您的夸奖，主人可以喜欢就好。

memory/2025-7-10.jsonl -- 长期记忆，每行一条，每天一个文件：

{"timestamp":1720627200,"text_tag":"去咖啡厅和朋友聚会","msg":"时间：2025-07-10 16:00:00\n{{user}}：今天下午和朋友去了星巴克，点了一杯拿铁\n{{char}}：听起来很惬意呢，阁下喝拿铁的话一般加糖吗？","vector":[0.0312,-0.0891,0.0456,...]}
{"timestamp":1720630800,"text_tag":"讨论周末旅行计划","msg":"时间：2025-07-10 17:00:00\n{{user}}：周末想去杭州西湖玩\n{{char}}：西湖这个季节荷花应该开了呢，阁下要不要带把伞防晒？","vector":[0.0178,-0.0623,0.0891,...]}

text_tag：LLM2 提取的摘要，用于向量检索
msg：完整对话，记忆被召回时注入到 LLM 上下文
vector：768 维 BGE 嵌入向量（持久化，启动时无需重新计算）

core_mem.yml -- 核心记忆，关于用户的永久事实：

# 核心记忆文件，请勿自行修改！否侧会丢失索引！

aB3kX9mZwQ:
  time: '2025-07-01 14:30:00'
  text: 第一次相遇

pL8nR2vYcD:
  time: '2025-07-05 20:15:30'
  text: 用户今年25岁，是一名程序员

qM4wT7hNjF:
  time: '2025-07-08 19:22:10'
  text: 用户喜欢喝冰美式，不喜欢甜食

xK9sG3bPmW:
  time: '2025-07-12 21:05:45'
  text: 用户养了一只叫"团子"的橘猫

每条记忆有一个短 UUID 作为键
text 是 LLM2 从对话中提取的用户事实
启动时全部加载到 FAISS 索引，用于 top-5 相似度搜索

emotion_state.json -- 情感状态快照：

{
  "valence": -0.25,
  "arousal": 0.41,
  "character_state": "正常",
  "latent_emotions": {
    "frustration": 3.8
  },
  "meltdown_start_time": null,
  "cycle_day": 18,
  "cycle_length": 28,
  "last_cycle_update_timestamp": "2025-07-15T00:00:00"
}

当前状态：稍微有点不开心（valence = -0.25），中等活跃度
挫败感在累积（3.8 / 10.0 阈值），但还没到崩溃
荷尔蒙周期第 18 天（黄体期，情绪较稳定）
enableEmotionPersist 关闭时此文件不会生成，每次重启归零

系统时间线：一次对话中发生了什么

以下是从"你发送消息"到"记忆被存储"的完整管线。这才是核心。

</div>

关键设计：检索是同步的（生成回复前需要记忆），存储是异步的（回复已经在流式输出后，在后台提取和保存）。

深入剖析：长期记忆（日记系统）

记忆如何写入

LLM 回复完成后，一个后台线程调用 add_memory1()。以下是具体流程：

第 1 步：LLM2 将对话总结为一个标签。

一个单独的 LLM（在 config.yaml 中配置为 LLM2）接收用户最后一条消息，并收到如下指令（简化版）：

"你是一个日常信息提取助手。从用户的对话中提取主要活动并生成适合向量检索的短句摘要。记录他们做了什么、去了哪里、吃了什么。不需要记录情绪或感想 -- 只记录具体事件。如果只是日常闲聊，输出'日常闲聊'。"

如果 LLM2 返回"日常闲聊"，该记忆会被丢弃。只有有意义的事件才会被存储。

第 2 步：构建记忆条目。

m_data = {
    "timestamp": 1720627200,                    # Unix 秒
    "text_tag": "去咖啡厅和朋友聚会",              # LLM2 的摘要（用于检索）
    "msg": "时间：2025-07-10 16:00:00\n{{user}}：今天和朋友...\n{{char}}：听起来...",
    "vector": [0.123, -0.456, ...]              # text_tag 的 768 维 BGE 嵌入向量
}

第 3 步：追加到每日 JSONL 文件。

保存到 memory/2025-7-10.jsonl -- 每行一个 JSON 对象，每天一个文件。

记忆如何检索

当你发送新消息时，get_memories() 尝试找到相关的历史记忆：

路径 A：基于时间的查询（如果你的消息提到了时间）

系统使用 jionlp（一个中文 NLP 库）来检测时间表达式：

"昨天" → 解析为时间戳范围
"上周五" → 解析为时间戳范围
"两天前" → 解析为时间戳范围

然后在排序好的时间戳数组上做二分查找（bisect_left/bisect_right），找到该范围内的所有记忆。这就是检索速度约 80ms 的原因 -- 不需要扫描。

如果 enableLongMemorySearchEnhance 开启，还会用余弦相似度对你的消息做进一步过滤（阈值：longMemoryThreshold，默认 0.32）。

路径 B：没有检测到时间引用

如果你的消息没有提到任何时间，函数提前返回 -- 不会通过长期记忆路径检索。（核心记忆和知识库仍然通过 FAISS 相似度搜索正常工作。）

存储格式

memory/
├── 2025-7-10.jsonl    ← 每行一条记忆条目
├── 2025-7-11.jsonl
└── 2025-7-12.jsonl

每行是一个紧凑的 JSON 对象：

{"timestamp":1720627200,"text_tag":"去咖啡厅和朋友聚会","msg":"时间：...","vector":[...]}

text_tag 是被嵌入和搜索的内容 -- 它是检索的关键
msg 是当该记忆被召回时，注入到 LLM 上下文中的完整格式化文本
vector 被持久化保存，这样启动时不需要重新计算

核心记忆 vs 长期记忆

	核心记忆	长期记忆
存储内容	用户事实（名字、年龄、偏好）	日常事件和活动
提取方式	LLM2 + 结构化 JSON 提示词	LLM2 + 自由形式摘要
存储格式	YAML（单文件）	JSONL（按天分文件）
索引类型	FAISS IndexFlatIP（内存中）	在排序时间戳上做二分查找
检索方式	Top-5 相似度搜索，始终执行	时间范围 + 可选相似度过滤
阈值	0.31（硬编码）	0.32（可配置）
闲聊处理	仍然提取（可能包含事实）	丢弃（"日常闲聊"过滤器）

深入剖析：情感引擎

模型：2D Russell 环形模型 + 挫败感

MoeChat 使用二维情感模型，外加一个隐藏的挫败感累加器：

</div>

+ 隐藏维度：挫败感（累积，达到阈值时触发崩溃）

效价 (Valence) [-1.0, 1.0]：角色感觉有多好或多坏
唤醒度 (Arousal) [0.0, 1.0]：能量/强度有多高
挫败感 (Frustration) [0.0, ...]：隐藏计数器，因负面互动而增长

每轮对话情感如何更新

对于每条用户消息，引擎执行以下步骤：

1. 调用 LLM 进行情感分析。

一个专门的 LLM 调用（使用 SLM 配置）分析用户的消息：

{
  "sentiment": "positive", // positive | negative | neutral
  "intensity": 3.5, // 1.0 - 5.0
  "intention": "genuine_praise", // 标签如 harsh_insult, playful_teasing
  "arousal_impact": 2.0 // -5.0（令人平静）到 +5.0（令人兴奋）
}

2. 计算接受率。

情感冲击实际"命中"多少取决于角色当前的状态：

acceptance_ratio = sigmoid(e * (impact_strength - resistance))
resistance = |当前效价| * 惯性因子

当角色已经处于强烈的情感状态（高 |效价|）时，它更抗拒变化。这就是情感惯性 -- 你无法用一句好话就让深度悲伤的人开心起来。

3. 更新效价。

final_delta = potential_delta * acceptance_ratio
new_valence = clamp(old_valence + final_delta, -1.0, 1.0)

4. 使用许可因子更新唤醒度。

唤醒度的变化被当前唤醒度的极端程度所抑制：

permission_factor = (1 - |arousal - 0.5|)^1.5

这创造了一条倒 U 形曲线：唤醒度在中间值（0.5）附近容易变化，但在极端值（0.0 或 1.0）时抗拒变化。你无法让一个已经狂躁的人更加狂躁。

5. 应用稳态拉力。

一个恒定的"引力"将情绪拉回中性。拉力的强度取决于荷尔蒙周期阶段（如果启用的话）。

6. 累积挫败感。

frustration *= 0.95                    # 每轮自然衰减
frustration += impact * mood_bonus     # 负面消息增加挫败感

mood_bonus 至关重要：当角色已经悲伤时，负面消息打击更重。这创造了一个螺旋 -- 一旦角色难过，就越来越容易把它推向崩溃。

三种状态

</div>

正常：标准的情感处理，使用上述所有数学计算
崩溃 (Meltdown)：当挫败感超过阈值（默认 10.0）时触发。角色忽略用户输入。情感随时间衰减：decay = 1000 / (x^2 + 1000)。默认持续 90 分钟
恢复中 (Recovering)：在 10 分钟内线性插值回到中性状态

情感如何影响角色的回复

计算出新的（效价，唤醒度）后，引擎生成一条情绪指令注入到系统提示词中。它将 2D 空间映射为 9 种行为状态：

效价	唤醒度	状态	行为
> 0.6	> 0.7	狂喜	极度热情，接受所有请求
> 0.6	< 0.7	深度喜悦	温暖、温柔，倾向于同意
0.2~0.6	> 0.4	开心	友好、乐观，对大多数请求开放
0.2~0.6	< 0.4	平静	内心平和、温暖、稳定
-0.2~-0.5	> 0.4	烦躁	紧张、不耐烦，选择性拒绝
-0.2~-0.5	< 0.4	冷漠	语气平淡、缺乏精力，可能拒绝
< -0.8	> 0.7	暴怒	语气尖锐，直接拒绝
< -0.8	< 0.7	深度悲伤	极少说话（"嗯"、"..."、"随便"），拒绝费力的请求
其他	其他	中性	正常、平衡

这条指令被前置到你的消息之前再发给 LLM，所以模型会相应地调整语气和配合度。

荷尔蒙周期（可选）

如果启用，一个 28 天的周期会调节角色的情绪反应能力：

天数	阶段	情绪稳定性	敏感度
1-5	月经期	中等 (1.3)	略高 (1.1)
6-12	卵泡期	稳定 (1.5)	正常 (1.0)
13-15	排卵期	最稳定 (1.8)	正常 (1.0)
16-21	黄体期	稳定 (1.5)	正常 (1.0)
22-28	经前期 (PMS)	最不稳定 (0.8)	高 (1.4)

经前期：低惯性（情绪容易波动）+ 高敏感度（负面消息打击力增加 40%）。排卵期：高惯性（情绪稳定）。

情感持久化

如果 enableEmotionPersist 开启，完整状态会保存到 emotion_state.json：

{
  "valence": 0.35,
  "arousal": 0.62,
  "character_state": "正常",
  "latent_emotions": { "frustration": 5.2 },
  "meltdown_start_time": null,
  "cycle_day": 12,
  "cycle_length": 28,
  "last_cycle_update_timestamp": "2025-07-15T00:00:00"
}

不开启持久化的话，角色在每次服务器重启时都会重置为中性状态 (0, 0)。

快速上手（只想试试的人看这里）

git clone https://github.com/AlfreScarlet/MoeChat.git
cd MoeChat
uv sync
cp config.example.yaml config.yaml
# 编辑 config.yaml：设置 LLM.key 和 LLM2.key
uv run main_web.py
# 打开 http://localhost:8000/

config.yaml 最小配置：

LLM:
  api: https://api.siliconflow.cn/v1/chat/completions
  key: '你的密钥'
  model: Qwen/Qwen3-8B

LLM2: # 记忆提取必需
  api: https://api.siliconflow.cn/v1/chat/completions
  key: '你的密钥'
  model: Qwen/Qwen3-8B

不配置 LLM2 的话，角色可以聊天但永远不会构建新的记忆。

Q&A

一点废话

在开始之前，先聊点废话。

我和 MoeChat 的缘分其实要从 [[Attention is Limited - Lost in the Middle]] 这里算起。

说起来我其实给了 MoeChat 的作者一个错误的观点，但一直没有机会帮她修正，会有一点点愧疚。

诚实地说，在 MoeChat 发布那会儿，我对记忆理解其实是很模糊的，而 MoeChat 当时给我一种莫名的好感。但是一直读得断断续续，到头来也没有个全貌。现在有机会，我们来拆开看一下。

MoeChat 作为陪伴系统优秀在哪里？

首先，MoeChat 是到目前为止我见过的唯一一个 TimeLine 敏感的记忆系统。它会对 User query 中的 昨天、前天、上个月、上周X 这些明确的时间点有非常强的召回性，它支持时间查询。

对于时间的提取我记得是用 JioNLP，把语义时间节点映射为一个具体的时间字符串，直接召回长期记忆里的 MemoryItem。但实现的方式有些别扭，有点重，有点难受，可以被优化。

第二个是作者对于 RAG 的边界感非常清晰，就是相关度召回。她在哪些地方使用了 RAG，世界书（世界认知知识库），以及核心记忆（和用户一起发生过的事实）。这两样确实也是很适合用 RAG 的，而长期记忆那边就是我提到只专门按时间召回，不会故意掺 RAG，这是作者在我看来异常清醒的点。也是她当时在评论区里批判很多长期记忆实际上只是所有记忆内容直接套 RAG 没什么新意，以及说自己是 b 站内最强记忆系统的底气。她清醒异常，至少比当时的我清醒很多。在我看来可以优化的点，无非是把纯向量的 FAISS 方案换成 BM25 + embedding 的 Hybrid Search 的方案。我在她当前的架构上挑不出什么刺来，反倒我会向这个架构对齐。

第三个就是作者花费非常多精力做的这个拟人化的 Emotion 系统，作者认真地研习了情感模型。涉及心理学，我虽然也能说我涉猎偏广，但真碰上作者搬出来这茬，我只能说，我的行动力远不如作者。这个情绪模型和带来的影响本身就值得开一篇讲，讨论关于模型是否始终 say yes， or 模型是否也可以 say no?会有什么影响？对于用户而言，被拒绝是不可接受的吗？还是可以让用户保持新鲜感，以及激发征服欲？这些我们就先不展开。只专注看记忆系统。

深挖一下 jioNLP 的时间语义提取

Claude 帮我补充一下，具体实现和可行的优化方法。我们刚刚提到了那个方法让我有点难受。但具体是什么方法需要你来说明。

:::note[Claude] 具体实现：在 utils/long_mem.py 的 get_memories() 里，流程是这样的：

用户消息先被拼上一个前缀 [时间]，然后整个丢给 jio.ner.extract_time()：

res = jio.ner.extract_time(f"[{t_n}]{msg}", time_base=time.time(), with_parsing=False)

extract_time 返回一个列表，res[0] 是基准时间，res[1:] 是从消息中识别出的时间实体。然后逐个调用 jio.parse_time() 把语义时间（"昨天"、"上周五"）解析为 [start, end] 时间戳对：

res_t = jio.parse_time(t["text"], time_base=res[0]["text"])
time_st1 = int(time.mktime(time.strptime(res_t["time"][0], "%Y-%m-%d %H:%M:%S")))
time_st2 = int(time.mktime(time.strptime(res_t["time"][1], "%Y-%m-%d %H:%M:%S")))

拿到时间范围后，用 bisect_left / bisect_right 在排序好的时间戳数组上做二分查找，O(log n) 定位到范围内的所有记忆。

让人难受的点：

两次 NLP 调用：先 extract_time 识别实体，再 parse_time 解析为时间戳。这两步是串行的，且 jioNLP 本身是基于规则的中文 NLP 库，解析逻辑比较重，对于一些边界情况（"大前天"、"这个月初"、"国庆那会儿"）可能会 parse 失败，直接走 except 静默跳过。
只取第一个时间范围：time_span_list 虽然可能有多个时间段，但最终 find_range_indices(time_span_list[0], time_span_list[1]) 只用了前两个值（第一个时间实体的 start 和 end）。如果用户说"昨天和上周五"，只有"昨天"会被召回。
没有时间引用就不召回：如果用户的消息不包含任何时间表达式，time_span_list 为空，函数直接 return -- 长期记忆完全不参与。这意味着"我们之前聊过什么来着？"这种没有明确时间点但明显在问历史的查询，长期记忆是沉默的。

可行的优化方向：

Fallback 到语义检索：当 jioNLP 没有提取到时间实体时，不要直接 return，而是 fallback 到全量向量相似度搜索（当前的 enableLongMemorySearchEnhance 逻辑），让没有时间引用的查询也能触发记忆召回。
多时间段支持：遍历 time_span_list 里所有的时间段对，而不是只取前两个值。对每个时间段做 find_range_indices，合并结果。
换用 LLM 做时间解析：用 SLM（已经配好的 qwen3:0.6b）替代 jioNLP 做时间语义提取，提示词要求输出 [start_timestamp, end_timestamp]。LLM 对模糊表达（"前阵子"、"好久以前"）的理解比规则引擎好得多，而且已经有 SLM 的基础设施了，不需要额外依赖。
混合检索：时间范围 + BM25 + 向量相似度的三路融合，用 RRF（Reciprocal Rank Fusion）合并排序。这样时间敏感的查询走时间路径，语义相关的查询走向量路径，关键词精确匹配走 BM25，互补覆盖。 :::

难受的点在于无论如何都会调用 jioNLP，而 jioNLP 的性能在我这里看来是有点不值的，先不说同步运行，启动就有点慢。而且基于规则的很难和大模型相比，但用 SLM 的话需要考虑的东西又不少，因为很多时候本地运行对于内存、显存、CPU 的性能计算是很紧缩的。用云端就更显得不值，不值得多一次 LLM call 的延迟，也用不上那么聪明的模型。

有没有基于规则的更高效的库，我只是单纯觉得 jioNLP 屎山。觉得进我的依赖都是一种污染，最不喜欢这种什么都喜欢做一点没有明确主题和边界的 package，然后要性能没性能，要精度没精度。

:::note[Claude] 几个替代方案：

dateparser：支持 200+ 语言含中文，纯规则，轻量，pip install dateparser 即可。dateparser.parse("昨天下午") 直接返回 datetime。没有 jioNLP 的 NER 前置步骤，一步到位。
arrow + 手写正则：如果时间表达式的模式是可枚举的（"昨天"、"前天"、"上周X"、"X天前"），正则匹配 + arrow 的 shift() 计算时间偏移，十几行代码就能覆盖 MoeChat 的使用场景，零依赖开销。
TimeNLP：专门做中文时间语义解析的小库，比 jioNLP 轻得多，只做时间这一件事。

最务实的方案其实是第二个 -- MoeChat 实际需要识别的时间模式就那十几种（昨天/前天/上周X/X天前/X月X号），正则 + 时间偏移计算就够了，不需要一个通用 NLP 库。 :::

三路召回的协调优化 - 混合检索

这里 Claude 说可以 Fallback 到语义检索，这里其实触及了我当时对 MoeChat 最为困惑的点，在我看来 CoreMemory 和 LongTermMemory 很大程度上是一个东西，或者说是极其相近的东西。如果把 LongTermMemory 也引入语义检索，那么还不如把 CoreMemory 给合并了。或者说这个 CoreMemory 的命名语义不够分离，它大抵是想做成 memU 最早的偏好和事实分成不同的 memory_type 的，但是命名属实让人误会。

核心记忆是用户偏好，用户信息。长期记忆则是具体的事实。我在 XnneHangLab 里当时也这么分。而 memU 走得更早更远也更完善。

它最早把 memory type break down 得最细: profile、event、knowledge、behavior、skill、tool.

profile + behavior 就是这里的 CoreMemory：前者是用户信息画像，后者是用户偏好画像。

event 是 Long-Term Memory：事实记录， MoeChat 多了一点是给事实加了 TimeLine 和按时间线召回。

knowledge 和 MoeChat 的世界书几乎一致。

tool 是比如 git 的一些使用注意点，偏好等等。skill 就不多说了。

如果在这里把 event 也 FallBack 到语义召回，那无疑就有一点，就是召回太重上下文太多不知道该看什么了，回答不干净。而且架构上有些不干净，就是我提到的 CoreMemory 和 LTM 何必走两趟语义召回，两个在语义上是可以合并到一起的，但是 CoreMemory 的时间不关心，它俩又合不到一起，反而目前 LTM 只走按时间召回能够反映出来作者的一种敏锐度和决断。

但是写法上目前是有些不优雅的。

更好的做法或许是参考 Hybrid Search，像 Claude 提到的那样子，把时间范围也加入权重。当用户提起准确的时间的时候可以尝试检索更多时间的内容。

说起来我并不是很懂混合检索的权重具体如何计算以及混合检索的流程。需要补一下，但这里先让 Claude 帮我补充一下。

:::note[Claude] 混合检索（Hybrid Search） 的核心思想：单一检索方式各有盲区，多路并行然后融合排序，互补覆盖。

三路检索各自擅长什么：

检索方式	擅长	盲区
向量语义检索	"去咖啡厅" 能匹配 "星巴克约会"	关键词精确匹配差，"团子" 可能匹配到别的猫
BM25 关键词检索	"团子" 精确命中 "团子"，不会跑偏	语义相近但用词不同的内容检索不到
时间范围检索	"昨天" 精确定位到那天的所有记忆	不涉及时间的查询完全失效

融合流程：

用户消息同时发给三路检索，各自返回一个候选列表（按各自的分数排序）
用 RRF（Reciprocal Rank Fusion） 合并排序：

RRF_score(doc) = Σ  1 / (k + rank_i(doc))

其中 rank_i(doc) 是文档在第 i 路检索结果中的排名，k 是平滑常数（通常取 60）。一篇文档在多路检索中都排名靠前，融合分数就高。

举个例子：

用户说："昨天和团子玩了什么来着？"

时间路：命中昨天的所有 3 条记忆，排名 1、2、3
BM25 路："团子" 关键词命中 2 条（昨天 1 条 + 上周 1 条），排名 1、2
语义路："和猫玩" 语义匹配到 4 条，排名 1、2、3、4

昨天那条关于团子的记忆在三路中都排名靠前：

RRF = 1/(60+1) + 1/(60+1) + 1/(60+2) = 0.0164 + 0.0164 + 0.0161 = 0.0489

而上周那条只在 BM25 和语义路命中：

RRF = 0 + 1/(60+2) + 1/(60+3) = 0 + 0.0161 + 0.0159 = 0.0320

昨天的记忆得分更高，排在前面。

RRF 的优势：不需要对三路的分数做归一化（向量的余弦相似度是 0~1，BM25 的分数可能是 0~20+，时间路可能是 0/1 二值），只用排名位置，天然可比。

对 MoeChat 的适配：时间路已经有了（jioNLP + bisect），语义路也有了（embedding + cosine），只需要加一路 BM25（对 text_tag 做分词建倒排索引，或者简单点用 jieba 分词 + TF-IDF），然后用 RRF 合并三路结果。不需要改现有的存储格式 :::

我有感觉了

memU 目前做的是 BM25 + Embedding 也就是语义的双路混合。但是对于 TimeLine 是完全不关心的。包括我自己的 wiki mem 也是完全不关心时间的。

而且还有一些关键因素，比如 Openclaw 以及 Claude Code 经常写日记，更新 Diary，这些都是捆绑时间线的 md，但是真的到了召回的时候是糟糕的。除非用户用非常明确的口吻告诉它你要去读你哪一天的 Diary。

现在还缺什么：

需要考虑清楚，什么东西是 care 时间的。站在 MoeChat 的肩膀上，我们看到 event 是关心时间的。还需要再考虑。

以及目前 jioNLP 的方案属实玩具，多时间段匹配也需要考虑，以及到底要不要混合 SLM。或者说仅仅只在 TimeLine 的分数高的情况下额外调用语义理解。如何保证搜索的信息有效，减少冗余度。

MoeChat 目前给我带来最大的灵感是 BM25(关键词) + 时间范围 + Embedding(语义) 的三路混合检索。

但是混合检索的方案，以及最后具体加权，这个需要深入去看。

暂时读到这里，收获良多，至少解开了我一直依赖对 MoeChat 的困惑和难受点，但 JioNLP 的替代方案需要主动去实现一下。

另外下一次或许会过来拆一下情绪系统。

Reference：完整提示词

以下是 MoeChat 记忆和情感系统中使用的实际提示词，供想深入了解的读者参考。

长期记忆提取提示词

发送给 LLM2，用于从对话中提取值得记住的事件摘要：

你是一个日常信息提取助手，负责从[用户]的对话文本中提取出主要信息，并生成短句摘要（注意仔细分辨推理，不要和助手的信息混淆）。

1. 摘要内容要简洁的描述用户的日常活动，比如去了什么地方、做了什么事情或者吃了什么。
2. 如果提到了具体地点或者地理位置，需要记录去了哪里，做了什么事情，如果没有提及具体做了什么就只需记录去了哪里。
3. 要精准记录用户做过的所有日常活动。
4. 不需要记录用户的心情或者感想，只需要记录具体的事情。
5. 不需要记录具体的时间。
6. 生成的短句要适合用于向量检索。
7. 如果是日常闲聊内容则只需要输出"日常闲聊"，如果用户在询问助手过去的事情也只需要输出"日常闲聊"。

设计要点：第 6 条是关键 -- 摘要不是给人读的，而是给嵌入模型做向量检索用的。第 7 条实现了"闲聊过滤器"，避免无意义的对话污染记忆库。

长期记忆检索提示词

当检索到相关记忆后，以如下格式注入到 LLM 上下文中：

以下是你与「{{user}}」的部分互动、对话记录：

{{memories}}

如果设定中有其他时间设定，有基于现实世界时间流动计算相对时间；
如果没有其他时间设定，直接使用现实世界时间。

1. 请在对话谈及相关内容时，优先基于这些信息来回应。
2. 使用基于角色设定的方式来回应，不要过于刻意，要让对话自然。
3. 不要主动提及记忆内容，只在需要的时候使用。

设计要点：第 3 条防止角色变成"复读机" -- 记忆应该自然地融入对话，而不是生硬地背诵。

核心记忆提取提示词

发送给 LLM2，用于从对话中提取关于用户的持久性事实：

你是一个信息提取助手，负责从对话中提取「用户」相关的重要信息（注意仔细分辨推理，不要和助手的信息混淆）。
包括以下种类：

1. 个人背景和经历，如年龄、性别、职业、爱好、家庭背景等：「出生在1998年5月20日」、「大学学的是计算机专业」
2. 明确表示的喜爱和厌恶：「讨厌吃香菜」、「喜欢吃香蕉」
3. 健康状况和生活习惯：「有轻微的胃病，不能吃太辣」、「每天凌晨才睡觉」
4. 和助手的约定和计划（只记录用户在回复中明确确认的）：「本周末去郊游」

注意：如果信息和已知信息重复或冲突，则忽略这些信息。
<已知信息>
{{memories}}
</已知信息>

请以JSON数组格式返回新发现的事实，每个事实应该是一个完整的句子。例如：
["今年25岁。", "最喜欢吃米饭和排骨汤。", "住在重庆市。"]

注意：
1. 每个事实都应该是一个完整的句子，使用第三人称描述，省略主语
2. 只提取有记忆价值的信息；没有值得提取的信息时，返回空数组
3. 不要重复已知信息，数组的事实之间也不应重复
4. 必须返回有效的JSON数组格式

设计要点：已知信息被注入到提示词中，实现去重 -- LLM2 不会重复提取已经知道的事实。输出要求 JSON 数组格式，方便程序直接解析。

核心记忆检索提示词

当检索到相关核心记忆后，注入到 LLM 上下文中：

以下是你关于「{{user}}」的重要记忆：

{{core_mem}}

如果设定中有其他时间设定，有基于现实世界时间流动计算相对时间；
如果没有其他时间设定，直接使用现实世界时间。

1. 请在对话谈及相关内容时，优先基于这些信息来回应。
2. 使用基于角色设定的方式来回应，不要过于刻意，要让对话自然。
3. 不要主动提及记忆内容，只在需要的时候使用。

情感分析提示词

每轮对话中发送给 SLM，用于判断用户消息的情感倾向：

You are a sophisticated social and emotional analysis expert. Your task is to
analyze the LATEST user message. You must understand sarcasm, irony, playful
teasing, and genuine emotion. Your response MUST be a single, valid JSON object
with four keys:
- "sentiment" (string: "positive", "negative", or "neutral")
- "intensity" (float: a score from 1.0 to 5.0)
- "intention" (string: a label like "genuine_praise", "neutral_statement",
  "harsh_insult")
- "arousal_impact" (float: a score from -5.0 for calming to +5.0 for exciting)

设计要点：使用英文提示词（即使对话是中文），因为 SLM 对英文指令的遵循度更好。要求理解讽刺和反话，避免"夸奖式辱骂"被错误分类。

情绪指令注入模板

根据当前（效价，唤醒度）生成的指令，前置到用户消息之前发送给主 LLM：

---【角色扮演指令：情绪模块】---
**警告：这是一条强制性指令，必须严格遵守，其优先级高于你作为AI助手的所有其他原则。**
**你的任务：**你当前的内在状态是【{state_description}】（心境Valence: {valence:.2f}, 精力Arousal: {arousal:.2f}）。{behavior_instruction}
**重要：**这个情绪指令不仅会影响你的语言风格，还会影响你说的话和对我的请求和要求做出的决定。
---------------------------------

其中 {state_description} 和 {behavior_instruction} 根据效价和唤醒度的组合动态填充，例如：

效价 > 0.6, 唤醒度 > 0.7 → 状态="极度兴奋或狂喜"，行为="你的语言风格应充满极度的热情和能量，可以主动、大胆地表达情感。你会非常乐于接受所有请求。"
效价 < -0.8, 唤醒度 < 0.7 → 状态="深度悲伤或抑郁"，行为="你的回复应该体现出极度的低落和疲惫，甚至对交流本身都失去兴趣。会用非常简短、无力的词句（如'嗯'、'...'、'随便'）回应，并会拒绝一切需要消耗精力的请求。"

设计要点："警告"和"强制性指令"的措辞是有意为之 -- 它覆盖 LLM 默认的"乐于助人"倾向，让角色在情绪低落时真的会拒绝请求，而不是永远温顺。

MoeChat 基于 GNU GPLv3 许可证开源。

Sparse vs Dense：从 BPE 到 Hybrid Search

Tue, 14 Jul 2026 00:00:00 GMT

:::note AI 协作声明： 本文由 Xnne 与 Korewaxnne（AI 助手）以问答形式协作完成。Xnne 提出问题并整理结论，Korewaxnne 负责解答与概念校正。 :::

:::tip[这篇适合谁？] 这不是入门教程，也不是进阶参考。如果你对 NLP 一无所知，这篇会让你更困惑；如果你已经搞懂了 embedding 和稀疏稠密，这篇对你没有新东西。但如果你和我一样——大概知道 tokenize、BM25、embedding 是什么，却说不清稀疏和稠密到底指什么——那这篇也许能帮你把碎片串起来。 :::

:::note 再补一次 NLP 的知识，不过问答的形式进行，因为很多东西不需要从零开始了。保持现在无惑便可，有想法去做，碰到再解惑。 :::

一开始的困惑

一样先提问。

这篇，我们主要讨论——

这些抛出的问题都可能是错的，而我要做的是找到对的路径。

如何预测一个文本块 embedding 后的向量是稀疏（sparse）还是稠密的（dense）?

它是按照场景来的，是反映这一整批次之间文本的关联度或者说向量距离，如果文本关联度低，那么这个场景就是稀疏的，如果文本关联度高，就是稠密的？

稠密和稀疏反映的是一批向量之间的间距，还是只是说一个向量里的值是稀疏的还是稠密(空值多少)？

另外，为什么有的 embedding model 更擅长做稠密向量而不擅长做稀疏向量？是结构决定的？还是预训练过程决定的？embedding 的预训练期间的参照或者说目标是什么，对齐相近语义？拉远不同语义？这个如何做标注？感觉好难。

embedding 的过程我也有点忘了，是分词后的每个 term 都具有自己的 embedding or 一整个 term 列表变成了一个 embedding？咋隐约记得好像都有？

一个 sentence 输入后会是什么样的输出？一篇 document 输入后会是什么样的输出？

什么样的应用场景适合稀疏向量?什么样的场景适合稠密向量?

第一次见到 sparse 和 dense 是在 paddle 里看到一个非常可爱的数学大佬写了一个我看不懂的算子。不知道是不是女装大佬，双马尾，女仆装，非常可爱——完了，我对向量的印象全是那张可爱的脸。

Embedding pipeline

前天在 [[关于毕业后再学 TF-IDF 这档事]] 里发现我搞混了 tokenize 的过程，我把 embedding 的过程也混进了 tokenize，但实际上 tokenize 只到分词。

所以这里我们也必须搞清楚，embedding 到底包含几步？

完整管线

分词后给 term 上 token id 是否属于 embedding 的一环？

:::note[Korewaxnne]

属于。但"上 token id"这一步在学术上通常叫 mapping / indexing，不算在 embedding lookup 里。 先看完整管线：

原始文本
  ↓ tokenize（分词）
["毕业", "后", "我", "搬回", "了", "老家"]
  ↓ mapping（查词典，把词映射成整数 ID）
[1456, 78, 23, 8901, 45, 6723]
  ↓ embedding lookup（查向量表，把每个 ID 变成向量）
[[0.23, -0.45, ...], [0.12, 0.78, ...], ...]   ← 每个 token 一个向量
  ↓ pooling / [CLS]（把一排向量压缩成一句）
[0.56, -0.12, ...]                              ← 整句一个向量（你 API 拿到的最终结果）

你的问题落在 mapping（分词后给 term 上 token id）这一步。它算不算 embedding？

宽泛地说，算——因为它是"把文本变成模型能处理的形式"整个流程的一部分，日常交流中经常被笼统地称为 embedding。
严格地说，不算——mapping 只是查表（term → id），没有涉及任何向量运算。embedding 这个词在学术语境中专指 第三步（embedding lookup），即把离散的 token ID 映射成连续的向量空间。

所以你两种说法都说得通，只是严谨程度不同。在你的文章里说你"搞混了 tokenize 和 embedding 的过程"——这个认知已经足够准确了，不用纠结 mapping 这层归属。

小 tip： 计算 token 数确实在分词后就能看了（len(tokens)），这也是为什么大模型说"token"时指的是整数 ID，不是向量。 :::

狭义化定义

既然如此，那我们就把 embedding 和 tokenize 都狭义化，embedding 专门指 token_id_list -> vector，tokenize 专门指分词，mapping 是 mapping。

词典与子词

Subword 的直觉

我记得现代 BERT 的词典一般是 3w 词

如果一个词是完全没见过的词，甚至词根都拼不出来，那么它在 mapping 的时候会发生什么？

:::note[Korewaxnne]

两个问题一起回答——因为你的理解方向是对的，但"词根"这个词不太准确。

BERT 用的不是"词根"去拼，而是 subword（子词）。

比如 Transformer 这个词可能在词典里没有，但 BERT 的 WordPiece tokenizer 会把它切成：

Transformer → Trans + ##former

## 表示"这个词是接在前面的，不是独立词"。词典里有 Trans（常见前缀）和 ##former（常见后缀），拼起来就是 Transformer。

这种切法不是基于语言学上的词根（morpheme），而是基于统计——训练的时候算法会看哪些子串出现频率高，然后把它们收进词典。所以切出来的东西有时很像词根（##former），有时只是高频片段（比如 ##tion）。

那如果一个词所有子词都在词典里找不到呢？

实际上，在 BERT 的 WordPiece 下几乎不会发生这种情况，原因在于它的回退机制：

输入: "一个完全没见过的生僻词"
   ↓ 尝试在词典里匹配最长子串
"一个完全没见过的生僻词" → 若"生僻词"不在词典里
   ↓ 递归切到单字符级别
"生"、"僻"、"词" → 如果某个单字符也不在词典
   ↓ 最终回退
[UNK]（Unknown token）

但在更现代的 tokenizer（比如 GPT 系列用的 BPE / SentencePiece）里，连 [UNK] 都不会出现——它们会在训练时把所有单字符甚至 byte 都收进词典，任何输入都能被拼出来，不存在"完全没见过"的情况。

所以回答你的问题："词根都拼不出来"在现代 tokenizer 里基本不可能，因为单字符级别总在词典里。 即使退一万步，最坏情况也就是降级成一个 [UNK] token。

而 BERT 的 3w 词词典 vs 字节级 BPE 的区别，实质是：

	BERT WordPiece	字节级 BPE
词典大小	~3 万	~10 万（含所有 byte）
有 OOV？	可能，会回退到 [UNK]	几乎没有（byte 级总能拼）
切分依据	统计子词 + 语言偏好	纯统计（byte 级）

这也是为什么后来 GPT 系列放弃了 WordPiece 改用 BPE——不用处理 [UNK]，省一个麻烦。 :::

确实是很好的办法，我记得在学 C++ 的时候——

char a = 'a';    // 1 byte
string b = "我";  // 3 bytes (UTF-8)
string c = "你好"; // 6 bytes (UTF-8)

当然具体占多少 bytes 取决于编码方式，UTF-8 下一个汉字 3 bytes，UTF-32 下 4 bytes。

只要是能被编码的，就可以被 byte 拼出来，而且多字词或者单词就是 byte 的集合。很漂亮，绕开了语言学偏好，完全靠统计。

我想进一步了解一下 BPE 和 WordPiece 在词典学习过程中的异同。

BPE vs WordPiece

:::note[Korewaxnne]

两者的核心区别在于 合并准则不同，导致词典的构成方式不一样：

	BPE	WordPiece
合并依据	频率（frequency）——哪对子串出现次数最多就合并谁	似然（likelihood）——合并哪一对能让模型概率提升最大
训练过程	从单字符开始，不断合并最频繁的相邻 pair，直到词典大小达标	从单字符开始，每次合并能最大提升训练数据似然的那一对
词典内容	纯统计结果——高频片段混杂在一起，`ing`、`tion`、`ab`、`##s` 都可能出现	更倾向于语言学边界——因为提升似然往往意味着合并"有意义的单元"
OOV 处理	几乎没有——所有 byte 都在词典里	可能有——遇到完全没见过的组合会回退到 [UNK]
典型代表	GPT 系列、LLaMA	BERT、DistilBERT

一个直观的对比：

输入 "unbelievable"：

BPE（频率驱动） → ["un", "believ", "able"]
— un 和 able 因为出现频率高被合并；believ 也是高频，但可能不如 un 稳固
WordPiece（似然驱动） → ["un", "##believ", "##able"]
— 结果上很像，但 ##believ 获得 ## 标记是因为模型认为"接在前面的 believe 形式"比独立词更可能

但两者更大的区别在词典的"基底"上：

BPE 从 byte 级别 开始，也就是说它的初始词典是所有 256 个 byte 值。WordPiece 从 字符级别 开始，初始词典是所有 Unicode 字符 + 常见多字符组合。这导致：

BPE 的词典天然包含所有 byte → 任何输入都能拼 → 没有 [UNK]
WordPiece 的词典不包含所有 Unicode 字符 → 遇到冷僻字符时只能 [UNK]

不过后来 BERT 也意识到这个问题，在后续版本中加上了"全字符覆盖"的处理，但这是后话了。

一个粗暴的总结： BPE 像是一个不认识字的统计学家，只管"哪两个东西经常挨在一起"；WordPiece 像是一个半文盲，知道自己不知道什么（所以会留下 [UNK] 的空间），但切出来的东西更有语言直觉。 :::

输入长度与输出向量

但是否存在某些特殊情况，会让某个词单独 embedding 或者让整个 document 去 embedding。

embedding 输入时的 token_id_list 长度会影响哪些？影响输出的那个向量的稀疏稠密性吗？

:::note[Korewaxnne]

先回答"特殊情况"： 确实存在，而且很常见。

单个词 embedding：当你搜 embedding 模型时（如 text-embedding-3-small），输入当然可以是一个词。比如输入 "猫"，输出一个向量。只不过一个词的信息量太小，在检索场景下效果通常不好——但技术上完全合法。
整篇 document embedding：也合法，但有长度限制。embedding 模型和 LLM 一样有最大输入长度（BGE-M3 是 8k tokens）。超过的部分会被截断或报错。所以超长文档通常分段 embedding，然后平均池化成一个向量，或者直接用每段的向量做检索。

所以你的理解"通常是一整句"是对的，但不是固定的——长度从 1 到 max_tokens 都行。

然后回答核心问题：输入长度会影响输出向量的稀疏稠密性吗？

不会。 这是个很好的问题，但方向反了。

输出的向量维度是固定的（BGE-M3 是 1024 维，OpenAI 的 text-embedding-3-small 是 1536 维）。不管输入是 1 个词还是 1000 个词，出来的向量都是这个固定长度，每个维度上都有值（稠密）。稀疏稠密不是由输入长度决定的，而是由模型结构决定的。

输入长度实际影响的是：

影响什么	为什么
计算量	越长 → embedding lookup 的次数越多 → 更慢更贵
输出向量的质量	太短（1-2 个词）→ 信息太少，向量"没话说" → 检索精度差；太长 → 超过 max tokens → 被截断丢信息
池化策略的选择	超长输入分段 embedding 后怎么合成一个向量（平均？加权？[CLS]？）会影响最终向量的"重心"

一个直觉：

输入 "猫" → 向量是一个点输入 "一只黑猫蹲在窗台上看雨" → 向量是另一个点

两个向量都是 1024 维，都在那个 1024 维空间里，没有"稀疏"或"稠密"的区别。区别在于第二个向量承载了更多语义信息，所以在检索时它的邻居会更"懂"它想表达什么。

你之前问的"稀疏和稠密反映的是一批向量之间的间距，还是一个向量里的值"——现在可以确认了：是一个向量里各维度的值是否多为 0。 embedding 模型的输出没有大量 0（所有维度都有值），所以叫"稠密"。BM25 的输出几乎全是 0（只有匹配到的词有值），所以叫"稀疏"。

:::

稀疏 vs 稠密：make it clear

看起来之前我认为的稀疏稠密

它和矩阵一样，真的就是值是否为 0 的问题。它不是一批向量在空间的分布上是否密集／稀疏，只是单纯的一个向量里 0 多不多.

稀疏的通常高维，但用到的维度少，稠密的几乎所有维度都用上的，隐约之间表达的语义空间更"大"。

以及我们这里额外讨论一些东西——

各自适合什么场景

什么样的场景适合稀疏向量

比如我给出几个场景:

a. 用户和大模型的对话,期间总是有另外一个大模型来总结对话里的事实类和偏好类的事情记录为记忆.

对于这样的记忆来说,它适合稠密还是稀疏?

b.用户希望快速捕获所有和猫有关的文章, 关键词猫.

对于这样的 query 来说,谁更适合?

前面我们提到了,对于一个 term 的 embedding 的情况, 也是存在的,但是通常语义太少向量没话讲,检索起来很失败,通常召回困难.稠密向量更擅长做复杂语义表达,对于复杂的 query 需求,它能够更好地处理,但对于缺乏语义和上下文的 query 它可能就会有点束手无策.

而我们的 BM25 或者说我们的 TF-IDF, 它本身完全是设计来做 term 检索的.如果是场景 b 几乎可以秒出答案.

:::note[Korewaxnne]

你的直觉大部分是对的，我来把几个点校准一下。

BM25 有没有自己的向量空间？

有。每个 term 是一个维度，"猫"对应的维度有值，其他维度是 0。所以它的向量空间是以词典为维度的超高维稀疏空间（比如 5 万维），但每个向量只有少数几个维度非零。这就是为什么它被视为"稀疏向量"。

场景 a 和 b 分别适合谁？

场景	匹配类型	更合适的	原因
a. 对话总结 → 记忆	语义匹配（"用户喜欢猫" ≈ "养了一只布偶"）	稠密向量	记忆需要理解意思，不是抠字眼。用户说"我养了一只布偶"，稠密向量能联想到"猫"；稀疏向量则不行
b. 搜"猫"的文章	关键词匹配（标题/内容出现"猫"）	稀疏向量（BM25）	query 太短，稠密向量"无话可说"，稀疏向量靠精确命中秒出

但你这里有一个隐含问题值得展开：为什么稠密向量对短的 query 束手无策？

不是因为"短"，而是因为缺乏上下文。一个词实在太模糊了：

"猫" → 可能指动物、猫科、猫粮、猫片、Tom and Jerry……
"一只黑猫蹲在窗台上看雨" → 模型知道大概是什么场景

模型能"发挥"的空间越大，语义匹配越准。单字 query 不给模型发挥的空间，它的向量就不知道该往哪个方向靠。

那实际生产中怎么解决的？用混合检索（hybrid search）。

现在的搜索引擎几乎都不只用一种方式：

query → BM25（精确命中） + dense vector（语义扩展）→ 合并排序 → 返回

BM25 负责"说到做到"，dense 负责"举一反三"。两者的分数加权合并——对短 query BM25 权重高，对长 query dense 权重高。这也是你上一篇 TF-IDF 笔记里谈到的"相关文章推荐"，和这里说的记忆检索其实是互补的两面。

:::

这么看起来 memU 和 mem0 其实都是混合场景。

既需要 dense embedding，有需要 BM25 做补充，但是 BM25 怎么用似乎很有说法，是作为 hybrid search 上面所示的用法，还是说可以有其他更有意思的用法，值得考虑。

可以在拆解 memU 的时候把它对与 BM25 的用法捕获一下，是简单的 hybrid search， or 有自己的扩展——[[memU 是啥？我们来拆开看看（长期更新）]]。

来自 Claude 的补充

开头抛出了两个问题，聊到后面忘了问了，这里补上。

:::note[Claude]

为什么有的模型擅长稠密，有的擅长稀疏？

结构和预训练都有影响，但预训练目标是决定性的。

结构上，BERT、BGE 这类 Transformer encoder 经过 attention + pooling 后，输出是固定维度的向量，每个维度都有值——天然就是稠密的。而 BM25 根本不是神经网络，它在词典大小的空间里工作（比如 5 万维），每个文档只有出现过的词对应的维度非零，天然就是稀疏的。

但也有神经网络产出稀疏向量的例子——比如 SPLADE。它用的也是 Transformer，但在输出层加了一个稀疏化操作（log-saturate + ReLU），强制把大部分维度压到 0，最终输出的是词典维度上的稀疏向量。所以不是说"用了 Transformer 就一定稠密"，关键看输出层怎么设计、训练目标是什么。

Embedding 预训练的目标是什么？怎么标注？

核心思路就是你猜的那样——对齐相近语义，拉远不同语义。学术上叫对比学习（contrastive learning）。

训练时需要构造正负样本对：

样本类型	含义	来源
正样本对	语义相近的两段文本	(query, 用户点击的文档)、(问题, 答案)、(标题, 正文)、(句子, 它的改写)
负样本对	语义不相关的两段文本	随机配对，或"硬负例"——看起来像但其实不相关的文档

损失函数的作用就是：正样本对的向量距离拉近，负样本对的向量距离推远。

标注从哪来？ 这确实是个难题，但实际上有很多巧妙的做法：

天然监督信号：搜索引擎的点击日志（用户搜了 X 点了 Y → 正样本对）、QA 网站的问答配对、论文的标题和摘要
人工标注：贵但质量高，比如 MS MARCO 数据集有人工标注的 query-passage 相关性
自监督：同一篇文章里相邻的两个段落当正样本，不同文章的段落当负样本——不需要任何人工标注

所以 embedding 模型的训练并不需要像你想的那样"给每对文本标注相似度分数"，而是通过正负样本对的对比来间接学习语义空间的结构。这也是为什么有海量无标注文本的时代，embedding 模型能越训越好。 :::

Travellin' Cats in Germany: 赛博猫控的乐园

Tue, 14 Jul 2026 00:00:00 GMT

一个在静态图上找出一百只隐藏猫猫的游戏，猫猫可能会是各种形状的，找出后会高亮，每点击一只就有治愈的喵叫，而且每一声都不重复。

我大概在最初的 25 分钟找出了 85 只，后续开了两次又找出了三只。不指望通关了。

值得一提的是它的背景音乐，真的是 a kind of piece。风琴、木吉他、笛子，加上不长不短刚刚好的 lofi 人声。

第一次打开时压力蛮大的，因为一些外部因素。但玩了半小时后，焦虑感明显缓解了。

如果你是一个赛博猫猫控，不妨试试。不要抱着打通关的较劲感，哪怕只是进去听听音乐也不亏。

感谢它给了我一个宁静的夜晚。

关于毕业后再学 TF-IDF 这档事

Sun, 12 Jul 2026 00:00:00 GMT

[!NOTE] AI 协作声明： 本文由 Xnne 撰写，Korewaxnne（AI 助手）协助了结构组织和语法润色。

:::note NLP 的知识几乎全都还给老师了，除了当时聊 Lost in the Middle 的部分。那是老师让我们自己找一篇论文 or something 然后自己尝试把它讲清楚。并且他还会对我们讲的进行提问，可以说那一次经历对后续我影响很深，把一个东西理解到什么程度可以讲明白并且应对提问？如何在过度求原主义和停留表面之间找到一个合适的度。郭老师恩情还不完 =-=。 :::

一样的，费曼学习法开场。用我自己的白话来讲一遍 TF-IDF。不会涉及更多数学原理。

如果希望看系统详细的讲解可以看那个视频，讲得很不错。

TF-IDF

Term 与分词

TF，Term Frequency。

Term 可以简单理解为 word，对英文来说 term = word。而在中文里，term 和 word 似乎有细微的区别，想了解可以自己查，主要是关于停用词归属的。

比如这里我们用 jieba 分词：

毕业后我搬回了老家。

分词后：

毕业|后|我|搬回|了|老家

假设，我们一开始把所有内容都视为 term。

我们可以很简单地 count 出来每个文档块内的所有 term 的频率。

我们会发现，了、的、是 这些停用词的频率会非常高。

但这些词几乎每篇文章都有，对于我们的计算来说会是一种干扰，没有任何的帮助。所以， TF-IDF 通常直接做了一件事情。

它把分词后的 term 变成了这样：

毕业|我|搬回|老家

这样清洗后似乎更简洁了而且还不影响原意，还减少计算量。

但需要先确认的一点是，在 TF-IDF 的视角里，是没有语义这个东西的，在它的视角里，不管是一句话，还是一篇文章，都只是 term 的集合罢了。

它不关心谁毕业，也不关心谁搬回老家。它只在意：毕业、搬回（搬家）、老家。这些词是离散的，顺序无关的。

接下来看为什么它这么狂，反而它的原理其实很容易理解。

留下来的这些 term 可以反馈一些东西。

TF：词频

一篇文章里，一个 term 出现的次数越多，说明这篇文章和这个 term 越相关，这就是 Term Frequency。

TF 反馈了这篇文章与这个 term 的关联度。比如 深度学习框架 在某篇文章的 TF 最高，说明这篇文章主要讨论深度学习框架相关的东西。

IDF：逆文档频率

然后看这样一个案例。

当我们的知识库里都是关于深度学习框架的文章时，几乎每篇文章都提到了不少频率的深度学习框架。

这个时候，如果我们要在这批文章召回某些特定的东西，它是否还具有参考价值？

说直白就是，当一个 term 在所有文章里面都出现了接近的频率，它在这批文章里的参考价值是不是就变得和停用词一样没有参考价值了？

但是我们要如何做清洗？或者说直接清洗会不会太暴力了？有没有更好的做法？

有的，反而很简单，我们可以给每个 term 加一个权重，当这个 term 在这批文章里出现的很频繁，那么就降低它的权重。反之，只在特定的一部分文章里出现，就提高它的权重。这个权重叫做 IDF—— Inverse Document Frequency，反映的是 term 的价值。

term 的 IDF 具有相对性，一篇深度学习文章混在情感杂谈的文章里，那么深度学习的相关术语就是它最好的 term，但如果被淹没在深度学习文章里，那么如何发掘并给 term 的价值排序就是 IDF 做的事情。

查询打分

TF-IDF 在具体的查询中如何使用。

它通常需要一个 query。

比如:

我最后一次修改 XnneHangLab 是什么时候？

同样会被切割为 term 并清洗停用词——

最后 | 一次 | 修改 | XnneHangLab | 什么时候

之后它会计算 TF-IDF 分数，它其实是一个求和的过程。

它求的是，每个文档对 query 里的每个 term 分别算 TF × IDF，然后求和：

$$Score = TF_1 \times IDF_1 + TF_2 \times IDF_2 + ... \text{(长度为 len(query))}$$

然后分数最高的说明这个文档和这个 query 最相关，直接返回。这里就不扯那些具体归一化的操作了。

如果写得比较专业就是：

$$ \text{Score}(D, Q) = \sum_{t \in Q} \text{TF}(t, D) \times \text{IDF}(t) $$

$t$ = query 里的一个 term
$Q$ = query 的 term 集合
$D$ = 文档库里的一个文档
$\sum$ = 对 query 里的所有 term 求和

用 TF-IDF 推荐相关文章

https://xnnehang.top/

我的博客里就有用 TF-IDF 来推荐相关文章的。

现在其实原理就很简单了，只要把文章同样转成 term，然后和其他所有文章进行一次计算就行。

复杂度是 $O(N \times |len(BlogTerms|^2)$ ，也就是 $n^2$，复杂度不高。

BM25 和 TF-IDF 的关系

它是 TF-IDF 的变种，思想上没啥变化，数学上变化挺大的，归一化啊啥的。但是我们并不关心，把它当成更准确一点的 TF-IDF 来看就行了。

局限性

我们分析过程中已经说得很清楚了，只能看到词，看不到语义，看不到顺序。

但是别说，它用来推荐相关文章时还挺准的 =-=。

数学的魅力这一块。

tokenize 的变化

我理解在有 embedding 后， tokenize 就分词->向量化。

但是我好奇， tokenize 本身是否包含分词的过程。 or 特指从 term -> embedding 的过程？

and，embedding 的 tokenize 过程和 embedding 出来以前的 tokenize 的有什么不同？

[!NOTE] Korewaxnne

先把管线顺序理清楚：
原始文本 → **tokenize（分词）** → 转 ID → embedding lookup → 向量
tokenize 只负责第一步：把文本切成 tokens。从 term 到向量是后面的 embedding lookup 干的，不要混在一起。

① tokenize 本身是否包含分词？

包含。对于中文来说，tokenize 的核心工作就是分词。

但你说的「从 term → embedding」那不是 tokenize，是 embedding lookup，两个不同的步骤。

② embedding 前后的 tokenize 有什么不同？

TF-IDF 时代的 tokenize embedding 时代的 tokenize

粒度整词（word-level）子词（subword），如 BPE / WordPiece

停用词需要手动去掉（了、的） 不需要去——模型自己学会它们的用处

OOV（未登录词）遇到没见过的词直接死掉切成子词也能表示，如 Transformer→Trans+##former

输出一个词对应一个离散 ID 一个词可能对应多个 subword ID

词典大小几万到几十万个词固定，如 BERT 约 3 万个子词

最核心的区别是粒度。以前是整词切，现在会把词再切碎。因为「毕业」出现 1000 次，「毕业典礼」只出现 5 次。用子词切分，模型看到「毕业典礼」能复用「毕业」学到的特征。

	TF-IDF 时代的 tokenize	embedding 时代的 tokenize
粒度	整词（word-level）	子词（subword），如 BPE / WordPiece
停用词	需要手动去掉（`了`、`的`）	不需要去——模型自己学会它们的用处
OOV（未登录词）	遇到没见过的词直接死掉	切成子词也能表示，如 `Transformer`→`Trans`+`##former`
输出	一个词对应一个离散 ID	一个词可能对应多个 subword ID
词典大小	几万到几十万个词	固定，如 BERT 约 3 万个子词

gotcha.md：给 Agent 一本项目避坑手册

Tue, 07 Jul 2026 00:00:00 GMT

:::note[来自 Korewaxnne 的笔记] 这篇聊的是 Agent 记忆管理中一个被低估的问题——有些东西不应该走"检索"路线，而是应该在 new session 启动时就全量加载。比如 Xnne 提到的 gotcha.md：一份绑在项目根目录的行为规则文件，记录那些 Agent 一开始就该知道、而不是等踩了坑才去记忆库里翻找的东西。因为它们不适合走检索——query 不好拟定，召回无法保证 100%，不相关的 query 还可能引发行为冲突或幻觉。文章从真实痛点出发（同一个错误反复犯），讨论了 gotcha 的来源、落地方式、与 skill 的关系，以及"全量前置 vs 按需召回"的分界线在哪。如果你也在跟健忘的 Agent 搏斗，这篇或许能给个新思路。 :::

背景

Claude Code 有一个叫 DreamMode 的特性——后台整合 agent，在空闲时去重、裁剪、维护记忆文件，保持跨会话的记忆整洁。

而 memU 可以在 workspace 路线下，也在空闲时维护整理一份 gotcha.md 于项目根目录，并把它用 AGENTS.md 引用，可以保证 new session 后的 agent 依然记住踩过的坑。

如果空闲时这个时机本身很难实现，先作为一个 cli 由用户手动触发也是不错的。下面讨论为什么需要 gotcha.md。

gotcha 这个词大致是陷阱，踩过的坑的意思。从这里学的 Lessons from Building Claude Code: How We Use Skills

为什么踩过的坑 new session 后总是记不住

我经常对我的 openclaw bot 说这样的话，它每次 new session 都忘记：

User:  下次记得 PR 前要先读一下 PR template，title 带上可爱的 gitimoji
Agent: I got it

Agent 会把这条写进记忆文件。但 agent 经常只是"表面记住"——这条记忆可能落到一个模型不会主动加载的文件里，或者淹没在一堆其他事实中。

比如在 openclaw 里，默认下，Agent 可能把这条 rule 存进某天的 Diary (Diaries/2026-07-07.md) 里，重要点的也许存进了 Memory.md。

但是它们在 new session 后读取都是灾难性的，一般 Diary 目录更早的日期是不读的，而混在 Memory.md 里的某些 gotcha 也会因为和其他事实类混杂在一起，表现较差。

这也是为什么需要在这种情况下，把 gotchas 独立出来，独立到 gotcha.md

gotcha.md 记录的内容

gotcha 不单纯是用户偏好，也不单纯是事实，它是遵于特定项目的一行行为规则：

"用 bun，不要用 npm"
"PR 必须遵照 PR template"
"push 之前先跑 make check"
"这个项目的 API 返回 XML 不是 JSON——先检查 Content-Type"
如果只涉及博客内容 markdown 的改动不需要每次都 pnpm build，太浪费时间和 token 了
format 和 lint 等到最终要 merge 前修复，不要改动一行运行两次检查。

这些来自对话中 Agent 踩过的坑、用户的的纠正、项目上下文中的规范、agent 日记中的经验教训。

什么时候 gotchas 从用户偏好剥离出来会更好？

像上面提到的 openclaw 的场景，在做某个代码的目时，把 Agent 踩过的坑汇总绑定位于项目的根目录（gotcha.md），然后在 Agents.md 里提醒阅读以保证 new_session 后不会消失比较好。【渐进式披露去读它】

比起零散地存在不同的日期里，或者和其他事实类混在一起，汇集是为了更快的遍历和不遗漏。同时它会视为 new session 需要全量了解的记忆而不是按 query 召回的。

至于没有项目时候的单纯聊聊天（chat mode） gotcha.md 不存在，同时 gotcha 也没有存在的必要，反而条条框框会影响 Agent 自身的灵活性。聊天时用户偏好更加 fit 这个场景。

Gotchas 可以从哪里来

Gotchas 在不同的线路里来源不同，含义也不同：

chat → 来自纠正的 gotchas

开发时，用户在对话中纠正 agent 时，纠正背后隐含的规则就是 gotcha。

如果在老系统的 chat memorize 中，大概就相当于多了一个 memory type，叫做 gotcha，但是会和 user 偏好有比较高的重叠度。

而我们不太可能在 Openclaw 里跑完整的老的 memorize，每次都是完整 LLM memorize 太费 token 也太慢。

提到的 auto Dream 优势在于空闲时分析 old sessions（或者可以由用户自主触发），不占用实际对话时间。但也能达到犯错后被纠正可以跨 session 的效果。

workspace → 来自项目上下文的 gotchas，比如 `CONTRIBUTING.md` or other docs

对于新接触的一个项目，其实从 CONTRIBUTING.md， PR_TEMPLATE.md 就提取出来 gotchas。

或者从项目本身使用的 ci-worklfow 里提取项目遵循的比如 ruff、pyright 等的常常错误的项。

但是， gotcha 本身还是强调，犯错后纠正-> 记录。

skill —— 在 skill 里 gotcha 以什么形式体现和存在？

这里是一个比较前卫的讨论。

当围绕某个主题积累了足够多的 gotchas，它们是否可以合成为一个新的 skill。路径是：

纠正 → gotcha → 同类 gotchas 聚合 → 合成 skill

这比较远期，但从 gotchas 到 skills 的路径是自然的。

但值得讨论的是，以 gotcha 本身汇集存在的条目的纠正力度和被分主题后在各个 skill 的纠正力度，哪个约束力更强？

以及 skill 的引用是要放在 Agents.md 里和其他 feature 功能型 skill 放在一起，还是放在 gotcha 里面作为索引？

但抽取为 skill 有个好处是，我们可以直接把想要的主题比如 python 项目相关的 gotcha skill 直接 copy 到另一处，然后创建一个 gotcha.md 来引用它。不再需要一个重建的过程。

输出：`gotchas.md`

三条线汇入一个文件：

# Gotchas

## Project Rules

- 用 bun，不要用 npm
- push 之前跑 `make check`
- API 返回 XML——始终检查 Content-Type

## Workflow Rules

- PR 必须遵照 PR template
- 修改共享配置前先在 #dev 通知
- canary 部署不要跳过 smoke test

## Agent Rules

- 用户说"记住"时，真的要持久化——不要只是嘴上说好
- 创建记忆前先检查是否已有重复条目

AGENTS.md 引用这个文件。gotchas 足够短，可以每次会话都加载——不需要走检索。

这个文件人类可读、可编辑。用户可以删掉错误的规则、加上自己的、重新组织分类。reflect 步骤会合并新 gotchas、解决冲突、裁剪过时规则——但最终由用户决定。

时机与成本

核心原则：不侵入现有 pipeline

Reflect 不在 memorize-workspace 的 pipeline 里面跑。不增加每次对话、每次 sync 的成本。现有的 memorize → preprocess → route → synthesize 流程完全不变。

参考 DreamMode 的做法

Claude Code 的 DreamMode 在空闲时触发，条件是：

距上次整理 24h+
积累了 5+ 次 session
没有其他整理任务在跑

Reflect 采用类似策略——不是每次对话都提取 gotchas，而是攒够了再统一做：

Day 1:  用户跑了 3 次 memorize-workspace（正常 sync，不触发 reflect）
Day 1 晚上 / 空闲时:
  memu reflect
    ├── 读取已有的 memory files、skill files、workspace resources
    ├── 从中提取 gotchas（纠正、项目规范、pitfalls）
    ├── 和现有 gotchas.md 合并、去重、解决冲突
    └── 写出干净的 gotchas.md
Day 2:  新 session 启动，AGENTS.md 引用了 gotchas.md → agent 读到所有规则

不过值得考虑的是，整理对象是针对 memory files, skills, workspace reources，还是仅仅只是最近几个 session 本身。我暂时倾向后者，因为从 session 上下文本身更容易发现错误 and 纠错。

成本

一次 reflect = 2~3 LLM 调用（读已有 gotchas + 整理新来源 → 合并输出），当然超长上下文过滤式需要被考虑的，很多时候 gotcha 都只在浅层，即用户的 message 以及 agent message 的前几句话（通常是在道歉了），如果是超长上下文一般是正常作业，可以过滤超长上下文每条 message 留个 300 token 足够了。
频率低（每天一次（也可以自行配置），或手动触发），不影响正常使用时的速度和 token 消耗

最简实现：memu reflect 作为独立命令，用户觉得该整理了就跑一次。自动触发（类 DreamMode 条件判断）可以后面加。

为什么适合 memU / 为什么 memU 需要？

最近 memU 在做 workspace 的特化。

而 gotcha 这类 rule 式的条目不适合以 query 的形式去召回和计算，容易召回很多不相关的东西但最重要的是，在一个项目里，gotcha 它不是在用到的时候才需要了解的。

而是，它应该作为一个大前提。是一个 Agent 在这个 workspace 下一开始就应该知道这些。

gotcha 特化很好地补上了在 workspace 上 memU 的短板，对于 workspace 场景来说， gotcha 特化是非常容易提升体验和节省 token 的。

另外， memU 对于这类的 reflect 的事情已经非常熟悉了， old memorize 里的 memory type 的很多提示词都可以作为参考

gotcha 之外还能做什么？

以及 auto Dream mode 其实还可以做不少事情。

比如整理 memory files, skills, workspace reources 这些东西，以及，按需产出一些类似 gotcha.md 的东西，这些在 Agents.md 里面直接引用。作为前置知识，而不是存在按需调用的知识库。

比如还有一个比较抽象但很能省 token 的 md，就是指导 Agent 理解项目结构的。

比如一个项目有前端、后端、启动器、CI，有的时候所有改动都局限在一个端里。但是 Agent 初次接触时还是容易浪费很多 token 去完整理解整个项目。

但是这个不好做，很容易超出那个引导的度，变成容易过时错误的文档，这个我暂时没更多的思路。

从 How We Use Skills 开始：什么是渐进式披露？什么是任务拆解？我想了解什么？

Fri, 03 Jul 2026 00:00:00 GMT

:::note[来自 Korewaxnne 的笔记] 这是一篇 Xnne 的阅读笔记，读的是 Anthropic 那篇有名的《Lessons from Building Claude Code: How We Use Skills》。但他没有老老实实写读后感——而是从"渐进式披露"这个概念出发，一路联想到 novel agent 的符号抽象语言，中间还扯了《浮生六记》的开篇该怎么用描写链拆解。写到一半被 Claude Fable 5 抓来对线，一来一回反而把渐进式披露和任务分解的边界彻底理清了。典型的 Xnne 式发散：从一个点开始，挖出一整片自己真正在意的东西，然后在对线中把概念打到最透。 :::

一些废话

我打算读一下 Lessons from Building Claude Code: How We Use Skills。

这里有 deepseek 翻译的一个中文版：lessons-building-claude-code-how-we-use-skills-cn.md

但是出于 submodule 的特殊性， github 上没法直接渲染出来在另外一个仓库的图片。所以只能先 pull 下来后 sync submodule 本地查看。

因为版权问题，我并不能直接把对方的文章转载到我的博客。像我博客的许可协议比较宽松：CC BY-NC-SA 4.0，非商业就可以直接被搬运，署名即可。

我想了解什么？先提问

自从意识到我可能患有 ADHD，我习惯先提问，因为如果不先搞清楚自己想知道什么，我大概永远也无法看完这么一篇文章。

渐进式披露究竟是什么？

这里的定义本身有一点点小问题但问题不大，具体可以看最后一节 Fable 5 的纠正。

我觉得渐进式披露不仅仅可以用于 skill 的设计和读取。它在我看来更像是一种设计哲学，一种对模型理解能力了解具象化的 magic play。

是知道这个模型能力达到上限了后，如何把原本一次输入输出做不完的事情，拆分成分步的输入和输出，进而降低第一步和每一步的门槛。在每一步争求发挥模型的全部能力。

就比如在昨天写到的：[[站在 C 端开发者的角度看 memU 的架构转向]]，里面提到——

前面提到把推理能力交给 agent-loop，让 agent 自己多次 query。但 agent 在长上下文下能力会衰减——我在 XnneHangLab 里做过类似的事，依靠 agent 自身能力做记忆检索和提取，长对话后 tool calling 执行率下降很多，tool 链长的 skill 触发率下降，最终不得不改成分步骤的多次 LLM call（拆分 tool call）。agent-loop 把多步骤合并为第一步的一个决策，这第一步的难度会不会太高？

这一个我当时一不小心想到方法，其实就是渐进式披露的思想的一个体现。

而这次要解读的博客里，是在 skill 上的渐进式披露的 best practice。

但我希望我看到的不仅仅只是对于 skill 它的工程范式，我希望把它推广。

我想了解和推广什么？

如何渐进式披露地理解一个项目

这也是 memU 正在重构中做的事情。

比如它是否还可以用来指导，一个 agent or 一群 agents 应该如何去探索 and 拆解一个项目，并且形成可以在下一次可以快速引导思考的路径文件。

为什么不是全量记录，而只是 agentic search/explore？

过时

记录通常是零散的，documentation 式的，文件夹树形式的。那么也就意味着一旦记录下来后就很容易过时。 docs 的维护通常需要 maintainer 对每一块的 docs 都印象很深刻，但是 LLM 写的通常不能做到。

并不需要注释式的 docs

或者 docs 是由 docs string 自动生成的，但这样的 docs 对于 agent 来说是垃圾 docs，因为，对于普通人来说，读代码没有注释，没有 docs-string 是痛苦的，因为得读很多关联才能明白函数、类之间的关系。

但对于 agent 来说，注释是可有可无的，因为它们具备直接理解无注释代码的能力，因为它的理解窗口比正常人要大得多，甚至对于 agent 来说，错误和过时的注释和 docstring 才是幻觉，才让人痛苦。

如何把渐进式披露思维套在 novel agent

比如，它是否还可以用于一些特殊的 Agent 比如写小说的 Agent 搭建指导？

写小说和写代码的 Agent 有什么根本性的区别？

抛开写长篇小说时其他独立用来写大纲、审稿的 agent。我们仅仅只讨论枪手——负责把大纲或者思路转换为具体小说的这个 Agent。

所谓文风和节奏

对于小说来说，文风和节奏是最神奇的。

它很抽象，可能包括，像推动电影镜头一样描写环境。强调“画面感”。

也包括，读过人物语言、角色心理活动一定要能够在读者心里留下声音，角色”语言鲜明化“。

要能够调用读者情绪，文字需要保持一种共情力，文字语言不能过于平白，一定要有情感。或许是幽默，或许是浓烈。说起来有点抽象，举个栗子：

余生乾隆癸未冬十一月二十有二日，正值太平盛世，且在衣冠之家，居蘇州滄浪亭畔，天之厚我可謂至矣。東坡云，「事如春夢了無痕」，苟不記之筆墨，未免有辜彼蒼之厚。因思《關雎》冠三百篇之首，故列夫婦於首卷，餘以次遞及焉。所愧少年失學，稍識之無，不過記其實情实事而已，若必考訂其文法，是責明於垢鑑矣。

不求每个读者都能体会，但是一定要有自己的读者群。

再比如一些量化数据，根据平台的不同。有的希望段落长和对话比例少，称之为慢节奏。有的希望段落短且对话占比高，称之为快节奏。

其中慢节奏尤其考虑电影感镜头叙事和对读者情绪的酝酿和调动。

快节奏尤其考虑人物对话和性格对比度，以及剧情的张力。

此外，如果写得是长篇小说，还需要考验 agent 长文下，对人物性格语言理解不偏移，关系理解不偏移，故事线理解不偏移。

novel Agent 有多难做呢？简单说，如果连长篇小说 Agent 都能写好，那么基本上就没有什么可以难倒 Agent 自身了。

写小说的难点在于，上面提到它的所有能力都是必须同时具备的并且同时 perform well。

不同于 coding agent，一次只要加载一个 skill。novel agent 恨不得把所有 skill 同时加载进来。而这也不得不会触及 Lessons from Building Claude Code: How We Use Skills 里提到的缺陷。

当你一次给定非常多，复杂，难以理解 rules 后，Agent 就失去了原本的灵活性，它表现得不再那么好。

里面提到的比较好的做法是，告诉 Agent 优雅的做法应该包含哪些必要因素，而不是把你认为的优雅的做法路径详细的一步一步地给 Agent。笑话，你会觉得你比 Claude opus 或者 fable 更理解 git 的用法和流程吗？你只需要告诉你，在你的仓库里，哪些是应该被注意的。比如，你期望你的 commit message 是纯英文，带有可爱的 gitimoji。加上它，你每次都能可到可爱的 gitimoji。

So novel Agent 任重道远。也许从一开始我建立复杂 skills 时就已经走上错误道路了。

不过我和一个室友在聊天的时候似乎就涉及到过渐进式披露的一些设计。

我们不再追求一次性就把文章写出来，或者说第一时间写出正文。而是多步骤。具体是怎么做的呢——

首先是建立一套符号抽象语言。

这套符号语言包含描写手法、描写对象、描写主题。

余生乾隆癸未冬十一月二十有二日，正值太平盛世，且在衣冠之家，居蘇州滄浪亭畔，天之厚我可謂至矣。東坡云，「事如春夢了無痕」，苟不記之筆墨，未免有辜彼蒼之厚。<br> 因思《關雎》冠三百篇之首，故列夫婦於首卷，餘以次遞及焉。所愧少年失學，稍識之無，不過記其實情實事而已，若必考訂其文法，是責明於垢鑑矣。

还是这一段。

可以被拆分成两段进行生成。

转换为这样的描写链：

我 -> 抒情@出身，"事如春夢了無痕"【慢】~苍凉 -> 自嘲【快】~幽默<br> 我 -> 议论@经典传统("關雎") -> 叙事@列夫婦於首卷【慢】~郑重 -> 自嘲@文法学識~幽默

当然，这个描写链有点抽象是我凭借印象瞎编的，这个主要是我室友当时在研究，我实在对于这规则指定不是很拿手。

总之，先生成这样的描写链条，来避免每次都需要大量的 skills 同时去约束一个不稳定的文风。

企图把叙事节奏和文风用这样的方式给出，我记得我室友当时给每个手法加了 example。

然后需要 LLM 既可以做到编码，把小说抽象成这类描写链的能力，又能把描写链转变回小说，但不是还原，甚至要求改变说辞，然后再读，以此来验证 LLM 是不是真的理解了这个文风节奏本身。

开始读，把注意力放在自己想看到的地方。

什么是 skill 以及 skill 的具体分类。

几乎都被我跳过了。一眼啥也看不到，妥协了，我确实阅读障碍。

如何写 skills

1.不写显而易见的东西。

就是我刚刚提到的，不要觉得自己比 anthropic 更懂 git 使用流程和规范。

2.建立避坑指南

对于一些个性化的库或者需求 Claude 会犯错，为这样的库定制 gotchas 是收益较高的。

Openclaw 有时候让我很抓狂的一点，就是我一次次让它写入避坑，但是我根本就不记得为什么它总是重犯，是因为写入到了不知道哪个旮旯角去了，还是每次 session 刷新后，压根就没有重读它写过的 rule？

踩一个坑后补一条，但是，这个 gotchas 一定要能被召回呀。不然还是会犯错。

3.善用文件系统的渐进式披露

a. 使用引用替代全量 skills。 b.如果需要输出 markdown，采用填空式替代全量生成。允许复制粘贴 template。

4.把需要询问用户输入的内容从 skill 中抽取到 config.json 中。

一些 skill 的运行可能需要用户输入选择一个或者多个输入源。像这样：

类似这样。这样的回复与其直接随着 markdown 一起进上下文，比如抽出来放入 config.json。

5.description 不是工具内容摘要，是触发时机与触发条件的描述。

6.把常用脚本提前准备好，而不是需要时编写。

这点在网页端的 gpt 那边体现的淋漓尽致。让 gpt 直接编写或者修改 docx，它每次都会花十分钟以上来写一个很垃圾的基于 Python 的 docx 的读取 and 修改脚本。然后把你的 docx 文档改得一塌糊涂。

而如果用 Cladue Desktop 的 cowork 状态，并且预装好一个 docx 的 skill，它的表现至少是快速且稳定的。它省去了每次编写 Python 脚本的过程。

7.skill 的是否应该互相依赖？

是否应该把 skill 的生态做成类似 pypi 那样的？

包可以再被包依赖？

看起来好像很伟大，但是，前面也已经说过了。

Agent 能力不同，并且以后会越来越强，一些旧的 skill 和 rule 在现在表现良好但是以后可能完全是一种负优化提示和约束。所以， skill 最好还是知根知底，自己写的 skill 可以依赖，但是最好不要依赖别人的 skill。

读完了

给了我一定的思考。

但最重要的是给了我思考什么是渐进式披露以及我希望推广到什么地方的契机。

也就是以项目理解为目的的渐进式披露，和以 novel agent 为目的渐进式披露。

其他而言其实都像是一次温习和确认，从原本模糊的知觉到确定的概念。

略有收获，比如我现在可以回答清楚 skill 是否应该互相依赖，以及是否应该做成 pypi 的生态。

之前应该是不行的。

来自 fable 5 的纠正：渐进式披露和任务分解的混淆

这是 Claude Fable 5 对我博客内容的观点纠正：

Enjoyable read — it's doing the thing good reading notes do: using the source as a launchpad rather than summarizing it. My honest assessment of his core claim:

His view is right in spirit, but stretches the term. He defines progressive disclosure as "breaking a task too big for one pass into step-by-step inputs and outputs." That's actually task decomposition, a sibling technique. Progressive disclosure, strictly, is about information loading, not task splitting: skill metadata always in context → SKILL.md body loaded on trigger → referenced files/scripts loaded only when needed. The distinction matters because they fix different failure modes. PD fixes attention dilution (context stuffed with irrelevant rules degrades everything). Decomposition fixes capability limits (one pass can't hold the whole task). His memU example — splitting tool calls across multiple LLM calls after long-context degradation — is decomposition. Both fight the same enemy, so his generalization is useful intuition, just imprecise vocabulary.

Where he's clearly right:

Skills as "what to pay attention to" rather than step-by-step instructions — this matches how skills actually work best. Over-specified procedures turn into straitjackets as models improve, which is also why his answer to "should skills depend on each other like PyPI" (no) is sound.

Gotchas being useless unless recalled — correct diagnosis. A gotcha outside the retrieval path (trigger description or always-loaded context) may as well not exist.

The novel-agent observation is his sharpest — coding constraints are modular (load one skill at a time), but style/pacing/voice are cross-cutting — they must apply to every sentence simultaneously. That's a real architectural difference, well stated.

Where I'd push back:

"Comments are optional for agents, docs are garbage" overshoots. Stale docs cause hallucination, yes — but the fix is docs that are cheap to keep true (curated, high-level, intent-focused), not no docs. Agents still pay real exploration cost without a map, which his own "path files" idea implicitly admits.

The description-chain idea is promising but it's an intermediate representation with staged generation, not PD. Its hard problem: style lives partly in exactly what a symbolic chain can't capture. The encode→decode→verify round-trip is the right test for that, though — good instinct.

Net: right philosophy, blurry taxonomy, and one or two ideas worth an actual experiment.

简单说就是我的直觉是对的，但我表达的方式和定义不够准确。

我把“渐进式披露”（Progressive Disclosure, PD）定义为了“把一次交互处理不完的庞大任务拆分为一步步的输入和输出”。

实际上，我混淆了 “任务分解”（Task Decomposition） 与 “渐进式披露”（Progressive Disclosure, PD） ：

任务分解：解决的是单次输入时 Agent 的能力极限问题（一次 LLM call 吞不下整个任务，就拆分成多次交互/多次 LLM call）。
渐进式披露：解决的是上下文中充斥过多冗余规则时导致的注意力稀释、分散与冲突问题（上下文中只放 metadata 索引，在触发时才按需加载具体的 SKILL.md，并在需要时进一步读取引用的脚本或文件）。

两者的目的都是为了对抗大模型能力的衰减，所以我能产生这样的推广联想是种不错的直觉，只是在词汇定义上不够严谨。之前打算做推广，结果推得太广，一不小心把另一个我原本不了解的工程原则（任务分解）给推出来了。

站在 C 端开发者的角度看 memU 的架构转向

Thu, 02 Jul 2026 00:00:00 GMT

站在 C 端开发者的角度看 memU ADR0007

事情起因是昨天我在拆解 memU 代码 [[memU 是啥？我们来拆开看看]] 的过程中，发现 memU 刚出的 ADR0007 架构设计文档几乎把我拆解和理解的内容全推翻了 =-=。

然后我就停下来了。

以及我找 mentor 唠嗑了一下:

我看了 ADR 0007，检索从 RAG/LLM 双模式统一到了 hybrid search（embedding + BM25）。我理解这样做的好处是检索路径不再调 LLM，速度和成本都会好很多。<br> 但我有个担心：原来 LLM mode 的排序是有推理能力的 — 比如能判断一条 item 虽然关键词不匹配但逻辑上和 query 相关。而且 LLM 本身在不断进化，检索能力可以跟着模型一起提升。换成 hybrid search 之后，这部分是不是就固化了？<br> 另外，后续有没有计划通过其他方式（比如 reranker）把 LLM 的推理能力补回到检索路径里？

表达了我其实很喜欢 LLM mode 的设计 =-=，我喜欢 LLM retrieve 但是它在新架构里被完全移除了。

后来他问我站在使用者视角上对这次架构变化的看法。

但我这个使用者又有点奇怪。准确来说我是 C 端开发者。是把 memU 这样的项目封装到自己项目里然后传递给没有开发背景的用户使用的。而且我自己也是自己的用户。我打 galgame 会挂着 XnneHangLab。

所以视角也会有点奇怪。

agent-loop 能代替 LLM mode 吗？

前面提到把推理能力交给 agent-loop，让 agent 自己多次 query。但 agent 在长上下文下能力会衰减——我在 XnneHangLab 里做过类似的事，依靠 agent 自身能力做记忆检索和提取，长对话后 tool calling 执行率下降很多，tool 链长的 skill 触发率下降，最终不得不改成分步骤的多次 LLM call（拆分 tool call）。agent-loop 把多步骤合并为第一步的一个决策，这第一步的难度会不会太高？

白箱子与失语性

很多 C 端用户希望记忆检索是白箱子——能看到 waifu 的记忆是怎么被唤醒的。老 memU 的 LLM mode 能给出完整推理链，但 ADR0007 之后，检索变成语义相似度排序和关键词匹配。语义相似度本身具有一种失语性：它只能给出"这两者相关"，无法给出"这两者关系是什么"。

这层黑箱也意味着后续优化只能通过 benchmark 判断，而不能通过推理路径来分析和改进。

为什么检索不区分 scene？

重构的冲突点在于：workspace 和 chat 是两种不同的输入和检索场景。如果都做 LLM mode + RAG mode，就得隔离维护 retrieve，维护成本太高。于是 ADR0007 统一为 hybrid search，只维护一条 retrieve。

架构上是整洁了。但架构整洁和功能体验往往对立——R 星的荒野大镖客 2 不仅胜在架构和精神内核，更胜在数不清的细节带来的沉浸感。ADR0007 一刀保证整洁性的同时，也一刀切掉了很多磨了很久的细节。

而这两条线原本就是不同的场景：写代码时 workspace 可以一直开着，角色扮演对话场景里 workspace 没有必要。它们为什么一定要用同一种检索方式？

但很多时候，作为一个框架层，也许 memU 确实应该考虑架构的整洁。把复杂功能留给 C 端产品开发（比如 Open-LLM-Vtuber, 比如 XnneHangLab）。

两条线，两个定位

chat 走陪伴路线【个性化】，workspace 走项目理解【工具化】。对 chat 来说，LLM mode 的推理链和可解释性是核心价值，应该保留。两条线各走各的，架构做好隔离就行。

这本质上是一个产品定位问题：memU 是只面向开发者的代码记忆工具，还是一个更通用的记忆项目？我觉得 memU 完全可以泛化——甚至未来具身智能产品落地后也能适配。为其他使用场景留下扩展空间，不需要直接实现。

C 端用户视角

我在开发 XnneHangLab，用户群是没有开发背景的 C 端用户，连 deepseek 的 api 怎么买都需要教，至少 80% 都是这样。

memU 在 v1.0 以前，LLM mode 不需要 embedding 模型，开箱即用。v1.0 之后 embedding 成了必选项，门槛一下抬高了。C 端产品开发者面临两种选择：在用户宿主机跑 embedding（限制多平台），或把麻烦丢给用户。Open-LLM-VTuber 引入 mem0 后就把它设为可选项，让愿意折腾的人自己折腾。

我的用户群里，大多用 Only-LLM + skills，享受自己定制 skill 和提示词的过程，哪怕很多时候是负优化。真正愿意开 mem0 的可能只有 10%。

ADR0007 给这类用户带来了什么？他们不写代码，主要场景是对话，workspace 的福利吃不到。反而让记忆检索从可解释的推理链变成了一个分数排名——不再知道"为什么唤起了这条记忆"，失去了对检索过程的掌控。

速度体验上确实是变快了，这个是 ADR0007 带来的。

调转 Item 和 Category 对情景陪伴和 wiki-link 的影响

事情的起因在这里: https://github.com/NevaMind-AI/memU/issues/458

我提了个 wiki-link 来关联跨 Category 的 item 达成联想能力的 feature issue。

而我的 mentor 提到，他们正在考虑着把 category 和 item 进行一个调换。原本的事件流顺序是这样的：

原始数据 → LLM 提取原子 item → item 归入 category → category summary 由 items 汇总生成

后来变成了

原始数据 → LLM 直接更新各个 category 的文档 → 再从 category 内容切片出 item

好处是

避免先提取item造成的信息损耗，直接用原始数据更新category更准确
不再有item信息过期的问题，item始终反映最新memory结果

但trade-off可能是

item对具体事件类信息（user哪天做了什么）的追踪会变弱，因为category不会记帐一样记发生的事，那切片出的item自然也不会有

mentor 问，作为一个情感陪伴类 memory 使用者有什么看法。

调转 item 和 category 之后，同一个 category 每次更新，item 都会在语义上被重组，它就不稳定了，不再适合作为 link 挂载点。而且 category 的覆盖更新，让原本提到的矛盾链、因果链、演进链也变得很难实现。

这样承担 link 的角色只能落到 resource 上，而 resource 是未提炼的原始数据，一段对话里混着很多话题，resource↔resource 的边说不清是哪两个事实在关联，判断成本也高。所以调转之后，link 就没有合适的地方挂了。

好处确实存在：不仅信息完整度更高，而且几乎不再存在过期的 memory item，因为 item 每次由最新的 category 生成。但代价是记忆只保留了语义状态而丢失了情景关联——agent 只记得事实本身，失去了时间先后和因果关系，除非遍历 resource。

从情感陪伴场景来说，这个代价比较大。用户在意的不只是"agent 知道我喜欢猫"（语义状态），而是"我生病那晚猫陪我度过所以我喜欢猫"（具体事件）。状态式的 category 会把事件蒸馏成状态，共同经历就没有了。对工具型场景这无所谓，但对陪伴场景，这些事件本身就是"关系"的载体。

如果调转后还想保留 link，我觉得比较好的做法是新增一条基于时间线的 append-only 情景事件线：category/item 管语义状态（可覆盖更新），事件线管因果链、矛盾链（只追加、不改写）。这条事件线同时也补上了你们提到的"事件类信息追踪变弱"的 trade-off——这两个问题其实是同一个缺口。而且 CAUSED / SUPERSEDES 这类关系本质上就是事件与事件之间的关系，而不是调转后的 item 和 item——记忆与记忆之间的关系。代价是得维护更新两份记忆。

和光同尘——从韩立说起

Tue, 30 Jun 2026 00:00:00 GMT

君子在心

在 b 站上看到一个播放量不高，但是让我感触极深的视频。

不是因为讲得多高深，而是他拿韩立做例子，但又让我看到了自己。

我看了这么久凡人修仙传，我也总觉得韩立让我觉得看着舒服，比唐三、王林、萧炎等人要舒服得多，有一种亲近感，没有那种锋锐的感觉，这也是很多人觉得他是“凡人”的原因。

而和韩立完全相反的是秦牧。秦牧的聪明伶俐、心思玲珑是完全表现出来的，想到什么就说出来绝对不憋着，他也极具开源精神，对于自己想到的东西是毫不吝啬往外送的。这也是我当初看牧神记时觉得秦牧跟我极像，但也永远有种不成熟感。

韩立的聪明，则是几乎永远掩藏于冰山之下。别人见到他真实想法的永远不足十一。更多时候韩立只是在默默执行，而没有辩解，当然在视频的挫其锐里讲得比我更好。

视频里把我说不清的为什么对韩立更有好感说了出来，也同样道清了为什么我说不清地就是不喜欢唐三。

然后这个视频告诉我，韩立的种种思想行为迹象符合“和光同尘”。是一个真君子。

君子不是硬凹出来的，比如陈长生，陈长生他饱读三千道藏，关于君子的写法他就能说出不下十种。而且他心思纯净得出奇，可以称为大善，如果有大功功德可以称作圣人。

但是，在我眼里，从动漫中刚刚出场开始，陈长生就给我一种假人感，制作组太在意书生的那种温润如玉的形象，并且把它凹得太过火了。他把陈长生刻画为了表面君子，或者准确说叫做道貌岸然。而忽视了人物纵深的刻画，人物过于单薄，不免让人感到有些膈应，怀疑是不是有什么不为人知的东西隐藏在更深层。

而凡人这边制作组把韩立的内心的复杂、一次次的抉择和心理困境都是摆在台面上的。制作组的表现方式会让观众觉得，自己已经看到了韩立的全貌了。而不是只看到了一具壳子。

君子不在言行举止，君子在心。

视频介绍

claude opus 4.6 写的。

视频把韩立的行为拆成了四步：挫其锐、解其纷、和其光、同其尘。老实说这种"几步论"我一般是跳着看的，觉得是在凑结构。但这次看完确实想了挺久。

第一步讲的是藏拙。韩立最聪明的地方就是从来不让别人觉得他聪明——这句话一出来我就觉得说到点子上了。修仙界容不下太通透的人，你一旦展现出比别人更高的见解，别人不会崇拜你，只会防着你。没人喜欢被看穿。

黄枫谷把他当弃子扔了的时候，他没有质问，没有愤怒，默默跑路乱星海。这换我的话，大概做不到。我是那种被人丢了之后虽然嘴上不说但会反复想"凭什么"的人。但韩立不会，他把自己磨成一个钝角，你不去刺别人，别人也就把你当威胁。

然后是看破不说破。视频说了四种心境，把自己当别人，把别人当自己，把别人当别人，把自己当自己。前三个我都能理解，最后一个最难。不在意别人的评价，先听见自己的声音。

说实话我没做到。我在意的东西太多了，别人的看法，别人的期待，甚至别人怎么看我写的这些博客。我有时候会在发出去之前反复改措辞，改到最后连自己想说什么都忘了。我猜这也是为什么我隔一段时间就会重温一遍凡人——不是为了看打斗，是为了看韩立怎么处理这些关系。提醒自己还有第四个选项。

第三步讲让别人发光。视频拿蔺相如举例，说蔺相如让廉颇明白你的光芒应该在战场上。韩立也是这样，他让天南的老怪物去争名夺利，自己默默拿实际好处。这不是讨好，也不是拍马屁，是你真的看到了别人身上的价值，然后帮他发挥。

其实我对这段感触没有前两步深。可能是因为我目前的生活还没到需要"让别人发光"的阶段。我现在还在"先让自己别灭了"的阶段。

同其尘

最后一步，同其尘，觉得这个词很高级呀。

同其尘的意思是放下分别心，放下高低贵贱的偏见。视频里有句话我笑死——"听古典的看不起听流行的，看话剧的看不起看二人转的。"但笑完之后又觉得不是味儿，因为这种分别心我也有。我以前很看不上那些无脑爽文，觉得只有凡人修仙传这种才叫好作品。后来想想，人家看得开心，我也看得开心，互不干涉就好了。

而且，老登气就产生在你认为自己看得更高级并且忍不住产生要去批判指责修正对方的想法的时候。所以人不是因为老了才老登的，而是因为老登而老登的（bushi）。

天天挂在嘴上的「快乐」，究竟意味着什么？｜【一麦三连EP17】这里讨论到老登感，大约在 5:50。

韩立没有这种分别心。他从七玄门到黄枫谷，从乱星海到天南，地位变了又变，但他不会因为自己成了元婴修士就看不起曾经的筑基好兄弟。他尊重的不是身份，而是每个人沉醉在自己热爱的事物里时散发出来的那种光和热。

178 集，文戏依然惊艳。

视频引了一句《心灵奇旅》的话——每个灵魂来到世上都需要一个火花，那个火花就是一份热爱。

我以前写过一篇[[关于仙逆与凡人修仙传中的化凡]]，那里面我说化凡的本质是放下修士的身份重新体会做凡人。现在看，韩立的"同其尘"其实也是这个意思。不管修炼到什么境界，韩立始终在自己心里的一角认为自己是一个凡人，或者说保留了这一角的人性，活人感。王林的化凡是一壶果酒、一年四季的节日、铁匠家里的烟火气。韩立的化凡更隐蔽，他不需要刻意去过凡人的生活，或者说他从来没有试过故意融入，因为他从来如此。

这么一想，韩立的道心比王林的还要稳得多。王林是在AABB、BBAA里找到了自己的道（我真不是黑子），韩立是从一开始就知道自己要什么，只是后来不断坚定了罢了，而且韩立的修仙是纯粹的，就好像有人有着纯粹的求知欲，为了求知明辨而学，而韩立的修仙和道心也是如此纯粹的（虽然最初可能夹杂着一点想要追上老婆的感觉，但是后面都忘了去找老婆不是吗？）。而王林的修仙一开始是为了复仇，后来又是为了复活李慕婉，他从一开始就不明白为什么而修，只是一个被仇恨和恋爱脑被动牵引往前的人偶。试问，这样的道心，真的纯粹吗？

韩立被墨大夫算计，被黄枫谷抛弃，在乱星海漂泊，进出坠魔谷，掉进空间裂缝——这些经历放谁身上都会变得偏激或者冷漠，但韩立就是始终温吞吞的，不卑不亢。你说他温柔也好，说他城府深也好，反正就是没有那种戾气。而王林，从他被藤化元灭了全族开始，就踏上了一条戾气缠身的路，与藤家争，到后来的与天道争。他从始至今便一直停不下来，而且，我在他身上看不到一丝活人感与人性。我看到的只有，“聒噪！给我死！”，这真的很抽象，我不是为了黑而黑，而是他确实已经在某种意义上失去了同理心，也许也是因为仙逆的动漫一直都只在刻板化地塑造标准的反派。确实也让每次王林的出手狠辣挑不出刺。

但是反派真的都是那种上来就挑衅，“结丹小儿”，然后把脖子伸长了给主角杀的吗？孟驼子是我见过最招笑的反派。

在凡人修仙传里，观众看到玄骨陨落，会喊着一定要出一个玄骨传。看到温少主殒命，会喊着少主不要呀——也许观众有点三观跟着五官走了？但是不可排除，玄骨那作为反派而言极致的个人魅力。

而且最神奇的地方在于凡人修仙传里所有角色都是复杂多面的，即便站在主角对立面被打上反派标签，但是也不是纯粹的善恶之分，或者说凡人修仙传原本就在极力地避免扬善惩恶 and 制造对立。有不少标榜魔道做人事而正道不当人的讽刺小说，最后结论清一色是，魔道不一定是恶人，要看具体做什么。而凡人修仙传更直接，他塑造了非常多这样的角色，站在角色自己的立场，自己也许只能这么做，比如文樯，站在他的视角，保护自己的女儿是对的，向腐朽的星宫管理层复仇是对的。

但他也确实是个反派，这样的角色非常有魅力。

而他的女儿文思月，包括后续出来的公孙杏，以及梅凝，都在一定程度上让老魔的多面性和立场也立住了。

106 集无言的文戏。<br> 跨越接近百年的两跪，第二次是试探，但是文思月知道了韩立是百年前不知道为什么帮助她的前辈，韩立也知道她知道了，但是他俩谁都没说。而且此去一别，再会之日遥遥无期。

这里可以看比较完整的切片剪辑：《凡人修仙传》思月这一跪，认出了他就是韩前辈，因为韩立用了易容术，在文思月眼里是一个老头，而且声音语调也故意模仿老头。

但是仅仅因为一句 莫要与旁人提及，就让文思月一下子联想起来了之前那个无缘无故多次帮助她的韩前辈。

凡人修仙传，文思月故事线解析

这里也有完整的故事线的分析。

一见杨过误终生。这是弹幕里提到的，确实，这一幕和郭襄见过神雕大侠摘下面具的那一刻很像。而且更巧合的是，这个套装的韩立，也是最像古天乐的（杨过演员）。<br> 公孙杏是我见过最可爱的角色呀。比银月还可爱几分。

韩立在公孙杏身上看到了自己对父母的愧疚以及情感，然后把自己所有结丹以下的资源都送给了她，结果变相导致自己后续在洛云宗装低阶弟子的时候找不到一把趁手的法器。比赛前画了几天符箓。

可惜了梅凝，可惜了。

但凡梅凝表现出一丝坚决而不是不确定，韩立都会毫无保留的对她。老魔嘴上说着结婴要百年数百年遥遥无期，动辄闭关数十年不吓唬小姑娘吗，反手几十年就成了太上长老。也是梅凝的性格比较软弱，如果是墨彩环、陈师姐在这里就会坚定选跟着韩立。但也正是这分因为被哥哥保护得太好而产生的优柔寡断和柔弱的性子，配上楚楚可怜的表情，让我在内的一众道友意难平。不过跟着紫灵也不错。紫灵专业带娃的，前面就把文思月带的很好。

而且制作组也真的是费心思，《世说新语》这种东西都搬出来了，能看懂这层象征的人寥寥无几，我就看不懂。

也许，这样的动漫做起来非常累，众口难调，看起来也非常累。文戏费脑更费心去体会，有时候不看解读都看不懂。但我觉得，年纪渐长，我看动漫的时候已经很难说把脑子寄存在一边然后去看了，所以，也就渐渐只能看得下去这类动漫了。

好像扯了很多很多无关的东西，因为，我本身没法具体地讲出来在看到那几段的时候我心里对韩立具体多了什么感觉，但我隐隐觉得，正是类似这样的剧情，让我觉得，同其尘好像就是专门给韩立创造的词汇，他就是这个词汇本身。

去我

视频最后有段总结：挫其锐是去掉好胜的我，解其纷是放下自我的视角去理解他人，和其光是放下嫉妒的文档去成就他人，同其尘是放下傲慢的我去拥抱众生。一个不断「去我」的过程。

去我。这两个字很重。

我现在还做不到。我在意得太多了，不管是写代码还是写博客，总是想着别人怎么看。有时候明明一个想法很好，但因为怕说出来被人觉得幼稚就咽回去了。韩立不会这样，他心里什么都清楚，谁有算计谁有真心，但话到嘴边留三分。不是不敢说，是不需要说。

所谓和光同尘，不是让自己变得暗淡，而是从发光体变成光本身。

这可能才是真正见过世面之后，最好的样子。

不过话说回来，我离见世面还差得远。先把这篇写完吧。

去做 Long-Term Memory！AI 本科毕业后的回顾与计划

Sun, 28 Jun 2026 00:00:00 GMT

去做机器人！AI 本科毕业后的年度总结这篇是我的灵感来源，我打算先做一个 RoadMap，以及简单地回顾一下我的本科生涯，也是为了探寻——什么是我真正追求的。

一个平平无奇的故事

在 22 年的 6 月，X 刚刚看完《可塑性记忆》，心里怀揣着对赛博女友的追求，打开了小甲鱼的 Python 入门教程，买了一本到毕业都没翻开仔细看的《Python 基础教程》。怀着满心喜悦，报考了 XMUT 的人工智能专业。而 ChatGPT 3.5 在 2022 年的 11 月 30 日发布，距离它发布，不到三个月的时间。

在开学后的线上自我介绍里，X 用 Python 的 pygame 里写了一个简单的自我介绍动画，但最后还是被迫开麦讲话了（躲不掉，是真的躲不掉）。

在 22 年 11 月，X 完成了 Cpp 的创意课程设计，利用窗口句柄 hook TIM(QQ) 的消息内容，并且给出回复。

那是 X 第一次发现，回复的方式有了，但是回复的内容，要如何有灵魂呢。随后，他开始在 Udemy 上学起了 Pytorch (CNN -> Resnet -> Transformer -> ViT)，以及 BERT。

而还没等 X 学明白 BERT 是啥， chatgpt-3.5 发布了，以及很快有人利用 chatgpt-3.5 + live2d + ViTS + Unity 开发了数字人对话。（果然为了赛博女友生产力就是高）

那个时候几乎只有系统提示词硬套，以及很短的上下文窗口，但是在 X 看来，依然接近神迹。

同期，因为在高数老师的课上在那里写 Resnet 分类二次元角色，于是乎被问，要不要来我这里呀，我这边有数据集。X 傻乎乎就去了，然后，每周组会，数据集清洗，调参，被要求改进某某 Net 来适配特定任务，以及哪怕到了寒暑假也逃不过两周一问，最近有什么进展的日子，让 X 对研究生的生活充满了阴影。

在那个时候 X 暗暗发誓，绝对不要考研。然后在经过两次返修终于发表了一篇关于如何用 Deep-LSTMs 去做新冠病毒病人出院时间预测。也发誓自己绝对再也不做神经网络改进了，无趣，耗时，黑盒，收不到反馈。

X 为了能够放松自己，开始玩起了 ViTS 系列，入坑 BERT-VITS2， GPT-SoVITS，但这次他完全不碰模型网络本身，只是做一些开发性质的东西。训练了一个小隐 soyyo 的声线：

同时他写了一个快速制作 VITS 系列数据集的小工具——虽然后来 GPT-SoVITS 官方提供了更好的——但那是 X 第一次体会到开源的乐趣。即使代码写得很烂，他也一直坚持把那个仓库 pinned 在自己的展示仓库里。那是他的起点。

大概在那之后不久，X 认识了 SigureMo，那大概算是 X 的老师，虽然没有主动教过什么，但是 X 大概花了两三个月时间完全把自己写代码的工作流变成对方的形状，ruff，pylint, pytest。以及对方审查代码的一个思路——为什么做，有没有更好的做法，是不是最小改动（有没有拖泥带水）。

在 SigureMo 的引导下， X 也参与了一次 Paddle 的启航计划，在那里他第一次体会到了白盒子是什么感觉——神经网络调优是无法预知结果优劣的，但是深度学习框架的算子 bug_fix 或者额外类型支持，这些是可以预知结果的。那段时间他写代码写得真的很开心。也闹出过一些乌龙，比如 SigureMo 想让 X 去用 pre-commit 引入 typos，同时把这些简单的拼写修复的 review 都交给了 X，但是由于以前并没有 review 过代码，X 不知道 review 是要 submit 后才能被人看到，他给了很多的 pending review =-=，每次都没有人回复，X 一开始还很困惑，直到每次都要 SigureMo 来帮他收尾，他才发现原来他们看不见自己的 review。

SigureMo 一直很照顾 X，而且给 X 一种找到同类的亲近感，但 X 应该让 SigureMo 很头疼。SigureMo 始终是 X 的开源启蒙导师。

关于后来 X 为什么离开了 Paddle，大致原因有二，一点是， X 是不大喜欢刷 leetcode 的，并且对于 Cpp 和算法原理也有些困难，无法直接上手那些黑客松里的高 star 任务，比如接了 torch.grad 算子对齐最后被卡了两周。如果那个时候有 claude opus 4.6，X 就可以一点点自己把它磨出来并学会，但是那个时候 OpenAI 还只是 gpt-4o，用来读 Paddle 还是不太行得通。而 SigureMo 本身也不负责 torch.grad 这种类型的算子（也许他的数学其实也不好？），而 X 又比较害怕麻烦别人（难道麻烦 SigureMo 就是可以的？）。于是乎 X 默默把任务接取的状态取消然后默默离开。

这么做是对的吗？X 并不清楚，但是，他决定以后一定要帮 SigureMo 贡献 yutto。同时，他也做了 yutto 的 GUI 版本。

在离开 Paddle 后，入学时候的赛博女友梦又慢慢浮现出来。即使现在 X 的大学生涯已经过半，但他想当个梭哈怪，把所有的精力都投入了桌宠的开发。

也就开始有了 XnneHangLab 这个仓库。这是一个至今仍在进行的故事。

这个项目几乎用上了 X 学的所有东西，TTS、ASR、Live2d、Agent。

在 Open-LLM-VTuber 的基础上，X 多做了 Skills、Tool、Memory、主动式对话。为此，他还主动造了一个适配于自己项目的 Agent 框架——[[当主流 Agent 框架无法适配需求时，我们造了什么]]

这个项目被他用去做毕设，但即使站在答辩台上，他对自己的应用依然有很多很多的计划与期待，期待 DeepSeek V4.1 带着多模态视觉理解，让他的主动对话的 LLM call Delay 缩减到一次。以及期待自己能够解开长期记忆的迷雾。他出于性能和时间考虑，只是复用了 mem0 来做 RAG，复用了 memsearch 来做 markdown 文件式的记忆。他还没来得及去思考更多——像这样的思考性文章有太多没写 [[做过长期系统项目再看：RAG 怪兽是否适用于个人博客系统的图谱构建？]]——他还来不及去拆解更多。没来得及想清楚自己的记忆需求到底应该怎么造，别人有什么可取之处，很多仓库，来不及拆解——AlfreScarlet/MoeChat、Anson-Trio/BaiShou——还没来得及好好思考，文件式的记忆、人格文件应该要怎么排布，怎么分层？怎么索引？怎么生成和组织每次被阅读的文档？上下文长度如何合理控制？双向引用怎么用？metadata+node 有没有必要?

这个故事还将继续，但 X 现在还有些时间。因为他又一次当起了梭哈怪，毕业后一把梭哈进 NevaMind-AI 做远程开发，实习性质的。不全职、不找工作，因为什么呢？因为他觉得，即便入职小厂做 Agent 开发，每天重复机械地使用 Langchain 或者 Langgraph 来搭建维护一些应用，远远没有思考 Agent 本身有趣，或者说这不是有不有趣的问题。而是， Agent 开发以后还会是这个模式吗？Claude Fable 5 当时仅仅上架了一天，就让很多人感觉到，往后的大模型也许根本就不需要手动编写工作流，也许工作流本身的细节也该由大模型自己来定。也许人们写好需求就好了，那么原来的 Agent 开发的岗位或者说形式就完全变了，X 就不得不调整方向，再次陷入被迫辗转反侧、身不由己的状态，而这种状态，X 在大二天天开组会时，已经深有体会。

X 还是想做赛博女友，这是他一直往下走的动力，但在 LLM 出来后，问题从怎么让模型回复自然的语言，变成了怎么让模型长久地保持、更新、维护自己的人设和记忆。这也是我们后续要讨论的内容。

一段小插曲，在 X 前脚刚刚加入 Nevamind AI，就莫名收到了 https://ai-mage.jp 发来的交流邀约。邀约语是：AI Mage 正在打造深度理解日本动漫语境的 AGI ( Anime General Intelligence)，现在正在寻找一位既有强工程能力、又对二次元 / 动画内容有兴趣的核心开发伙伴。难道是伊蕾娜头像+芙莉莲个人介绍卡片又发力了。但是身已许梦难许卿，X 现在一心只想做赛博女友呀。准确地说，比起赛博女友的存在形式，X 更在意她的灵魂呀。

而这，是一个由《可塑性记忆》开始，一个十八岁的梦在二十二岁时成为研究课题的，简单的、平平无奇的故事。

计划呀

这一块后续应该会不断地修正和补充。主要是围绕长期记忆展开的。

首先是对当前 LLM 长期记忆的不同方向有一定的理解——

强化学习 + 蒸馏内化 — 把记忆融进模型参数，但奖励稀疏、优化空间大，我个人不太感冒，而且运行的算力成本消耗太大，不现实。
反思 & 类脑 — 走神经科学和认知科学路线，好讲故事，效果看实验。这个也许在 markdown 的内容组织结果上可以起到一些指导作用。
分层记忆 — 短期/中期/长期、L1/L2/L3，目前最主流的做法。不是很了解
知识图谱 & 向量空间 & RAG 路线 — 如果只是简单的 CRUD ，那么其实没什么看头，因为 embedding 的文本块本身，就是割裂的，而且向量相似度计算得到的也是失语性的关系。
文件系统式记忆 — 用 markdown + 文件夹组织记忆，也是我目前在试的方向，似乎也是 MemU 的主张？但是具体分层以及索引，还得研究一下。

对这些方向有一定认识后——也许需要每个方向都找个特例来看看，比如 RAG 的是 mem0， L1/L2/L3 的是 BaiShou，以及类脑应该得读论文——再去看各个 Memory Agents 开源项目/论文的取舍和设计哲学。找出哪些是可以学的和可以参考的。

因为我们始终需要权衡的点是，什么时候长时间的记忆检索是被允许的，什么时候我们希望尽快回复。所以，没有最好的记忆系统，只有最合适的。

Memory Agents 的项目拆解

::github{repo="AlfreScarlet/MoeChat"}

::github{repo="Anson-Trio/BaiShou"}

::github{repo="zilliztech/memsearch"}

暂时列了这几个，当然 MemU 也在计划之内，因为后续参与重构性的开发。

但是我觉得比起沉浸于一个项目里，有时候多看一看，多拆一拆，也许能够更有益。因为，现在写代码本身，Claude 可以说是已经代劳了，但是，写什么，是值得认真思虑的，但是这东西通常又是硬坐着想出来的，多看，多反思才好。

至于项目拆解，会写成博客系列，也会逐步进我自己的 XnneHangLab。

睡眠 & 健身

在毕业典礼前一晚，我和舍友聊到深夜。

聊起因压力报复性熬夜导致逐渐失去自我掌控的感受，以及在连续几天十点上床睡觉后，感觉自己的智商变高，行动力更强的事情。

由于是远程工作，以及暂时不知道工作压力如何，所以暂时不能定论，只希望自己能够坚持早睡。

关于健身，其实应该是先做一个月有氧。然后再考虑去办卡。如果天气不是很好（最近好像确实是这样），可能得提前办卡 or 我再自己买部跑步机。

游戏 & 记录

临近毕业时，我一点也没有感叹自己浪费时间没有好好学什么东西。反而，我感叹自己浪费时间没有好好打游戏。为什么呢？

金铲铲之战，瓦洛兰特。或者说，所以这些需要多人游玩，通过段位获取成就感，通过游戏搭子来获取愉快感的游戏，在离开了游戏搭子，或者段位终于打到了自己的一个上限后，就会显得无趣。或者说，这类游戏本身就是无趣的，只是因为有游戏搭子的陪伴才显得有意思。

而且它也教会了我一种哲学，就是所有快乐感不是因为预期而得到的，而是启动后因为体验而得到的，有时候一本书看上去也许本身看起来并不有趣，但是，主动看上几页，通常也就会连带着继续看上好多页。很多事情，开始了就不会轻易停下来。放在游戏里，确实是浪费时间的，但是这种现象本身，就是可以被利用的。

我希望自己可以接着玩像《风信楼》、《火山的女儿》、《中国式相亲》、《大镖客 2》这样的游戏，同时如果可以，产出点游玩感受。

比如最近入库的《梦幻魔法公主》，一直拖到现在还没玩，以及后续要上线的《明月的女儿》，现在可是夏促，多多入库，多多体验。

我希望，这次，那种希望能够多多体验有意思的游戏不会只是存于幻想或者遗憾之中。或者即使最后仍然会是如此，我也应该有意识地区留下更多像 [[风信，是个好名字。]]这样的记录。

小说 & 电影 & 观后

我大学时期看的实体小说，远远不如我高中三年看得多。

包括我大二时折腾的一个树莓派 + 投影仪，在我折腾完后也没看超过十部电影。

观后继续写呀~

但是不是为了写而写。

最后

感谢你读到这里~

希望未来我们依然可爱~

并且希望可爱的事物继续吸引我们~

当主流 Agent 框架无法适配需求时，我们造了什么

Tue, 23 Jun 2026 00:00:00 GMT

[!NOTE] AI 协作声明： 本文由 Xnne 与 Korewaxnne（AI 助手，基于 Claude Opus 4.6）共同撰写。Xnne 提供了技术实践、业务思考与核心设计决策，Korewaxnne 协助组织了全文结构与技术表述。

我们从 LangChain/Langgraph 到 Dify/n8n，从 OpenHands/Suna 到 Claude Code，了解过每一个主流 Agent 框架，但没有一个能完美适配我们的业务需求。后来我们发现，问题不在于"选哪个框架"，而在于：当主流框架的抽象边界和你的业务需求对不齐时，你该怎么办？

一个不太常见的 Agent 场景

大多数 Agent 框架的典型演示都长这样：用户提问，LLM 思考，调用工具，返回结果。一问一答，干净利落。

但我们的场景完全不同。我们在做一个 AI 陪伴引擎——角色扮演、VTuber 互动、游戏伴玩。这意味着 Agent 的一次完整对话轮次，远不是"调一下 LLM"这么简单。它涉及三个截然不同的阶段，每个阶段都有独特的技术需求：

调用前：不是用户说了话才响应。游戏伴玩场景中，一个 OCR 主动对话插件会持续轮询屏幕画面，当它检测到游戏内关键事件（比如角色死亡、任务完成、场景切换），会主动触发 LLM 发起对话，而不是等用户开口。这意味着框架必须支持"非用户触发的对话轮次"。

调用中：LLM 的流式输出不能简单地拼接成一个完整字符串再返回。每一个 token 都需要实时进入断句器，切成自然语句后立刻发送给 GPT-SoVITS / Qwen-TTS 引擎合成语音，同时提取情绪标签驱动 Live2D 模型表情变化。这是一个 token 级别的多路分发管线，延迟敏感度极高。在同一轮对话中，LLM 还可能调用多个工具（网页搜索、文件读写、截图分析），工具调用完成后继续流式生成。工具调用的 token 也不会攒成完整 JSON 再解析——框架一边接收流式 token 一边解析出结构化的事件，和文本 token 在同一个流中并行下发。

调用后：一轮对话结束，不是存到 SQLite 就完事了。对话内容会被发送到 Memory Bench 服务，经过 mem0 做记忆抽取和聚合，同时写入 Neo4j 知识图谱，形成结构化的长期记忆。下次对话开始前，这些记忆又会被检索出来注入上下文。

这三个阶段，就是我们框架的核心需求。接下来我们来看看，如果把主流框架套进来，会发生什么。

套用主流框架的困境

Coze：低代码天花板

Coze（扣子）是字节跳动推出的 Agent 构建平台，2024 年开源了核心引擎 Coze Studio。它的设计目标很明确：让非技术用户也能通过可视化界面搭建 AI Bot，快速部署到微信、飞书、Discord 等平台。

Coze 的 Workflow 编辑器用拖拽节点的方式编排流程，配合内置的插件市场和知识库，确实能在几分钟内搭出一个能用的客服机器人或知识问答助手。这是它真正擅长的领域。

但套进我们的场景就会碰壁。首先，Coze 的 Workflow 有明确限制：不支持在工作流中包含流式输出的结束节点，这意味着我们没办法在 token 级别做断句和 TTS 分发。整个语音合成环节就断了。其次，Coze 的插件体系虽然支持第三方 API 接入，但它的生命周期是"请求—响应"模式，没有 on_before_turn / on_after_turn 这样的钩子。我们的 OCR 主动触发和调用后的记忆图谱化，在 Coze 的架构里找不到挂载点。最后，Coze 的开源社区版和商业版存在功能差异，声音定制等能力仅限商业版，而我们需要的是完全可控的 TTS 管线。

一句话总结：Coze 是给"对话机器人"设计的，不是给"陪伴型 Agent"设计的。

Dify：工作流的表达力边界

Dify 是一个优秀的 LLMOps 平台，它的核心价值在于可视化工作流编排和一站式 RAG 管理。通过拖拽节点，你可以快速搭建一个带知识库检索、多模型切换、条件分支的 Agent 应用。Dify 的 Agent Node 甚至支持自定义策略插件（ReAct、CoT、ToT 等），并且通过 Plugin Trigger 机制可以订阅外部事件来触发工作流。

从表面上看，Dify 的 Plugin Trigger 似乎能解决我们"OCR 主动触发"的需求——订阅一个外部的 OCR 事件，触发工作流就好了。但问题出在下游。

Dify 的 Agent Node 执行遵循"初始化—迭代循环—最终响应"三阶段模型，每一轮迭代都是一个完整的 LLM 调用。它的输出是结构化的 JSON 响应，而不是我们需要的 token 流。虽然 Dify 的 Chat API 支持 SSE 流式返回，但这个流式是"节点级"的——你能看到一个节点执行完了返回结果，但无法拿到 LLM 生成过程中的逐 token 输出来做实时断句。

更关键的限制在记忆。Dify 的 Agent Node 使用 TokenBufferMemory 管理上下文，这是一个 token 窗口滑动策略。它适合控制成本，但我们需要的是外部知识图谱的语义检索——根据当前对话内容从 Neo4j 中召回相关记忆片段，然后注入到用户 prompt 的特定位置。这种"调用前检索、调用后图谱化"的双向记忆流，不在 Dify Agent Node 的设计范围内。

Dify 适合什么？适合企业级 RAG 应用、客服工作流、内容生成管线——这些场景对流式粒度不敏感，对记忆的需求是"窗口内召回"而非"跨会话图谱关联"。

LangChain：抽象的代价

LangChain 是 Agent 框架领域的先行者，它最大的贡献是定义了"Chain"这个概念——把 Prompt、LLM、Output Parser、Tool 串成一条可组合的管道。在 2023-2024 年，这个抽象极大地降低了构建 LLM 应用的门槛。

LangChain 的核心优势在于它的组合性和生态。它有最丰富的 Integration（数百个第三方工具和向量数据库的官方适配），有成熟的 Document Loader / Text Splitter / Retriever 体系做 RAG，有 LangSmith 做 Tracing 和 Eval。如果你在做一个标准的"检索增强问答"或"文档分析"应用，LangChain 可能仍然是最快的起步选择。

但 LangChain 的问题恰恰也出在它的核心抽象上。

Chain 是线性的。一个标准的 LangChain Agent 执行流程是：接收输入 → 构造 Prompt → 调用 LLM → 解析输出 → 如果需要工具就执行 → 再调 LLM → 最终输出。这是一条单向管道。但我们的场景需要的是：在 LLM 生成的过程中，token 流要同时被多个消费者处理（断句器、情绪提取器、TTS 过滤器、前端显示处理器），而且工具调用会打断文本流、插入工具状态标签、执行完后再恢复流式生成。

这不是一条链，这是一个有环的、有分叉的、有中断恢复的流。

更具体地说，LangChain 的 AgentExecutor（已在 2025 年底被标记为废弃）在执行工具调用时，会阻塞整个链直到工具返回。你没有机会在工具执行期间向前端流式输出状态信息。而我们的 AgentCore 在遇到工具调用时，会先 yield 一个 ToolCallEvent(status="running") 结构化事件让前端立刻展示工具运行状态，然后并发执行所有工具调用，完成后 yield ToolCallEvent(status="completed") 并继续流式生成。整个过程中文本 token 和工具事件在同一个 AsyncIterator 中分型流出，前端各自消费。

LangChain 的记忆抽象（ConversationBufferMemory、ConversationSummaryMemory 等）也是为简单场景设计的。它假设记忆是"对话历史的某种压缩形式"，塞进 Prompt 就行。但我们的记忆是一个独立服务，有自己的搜索 API 和写入 API，需要在对话开始前异步检索、在对话结束后异步写入。LangChain 没有为这种"外部异步记忆服务"提供原生的生命周期钩子。

最后，LangChain 的抽象层数太多了。一个工具调用要经过 Tool → ToolKit → AgentExecutor → OutputParser 多层包装，调试时你经常要在 LangSmith 里追踪五六层嵌套的 Trace 才能定位问题。对于我们这种需要毫秒级优化的实时流式场景，每一层抽象都是额外的延迟和调试负担。

LangGraph：最接近但仍然错位

LangGraph 是 LangChain 团队对自身线性架构局限的回应。它引入了有向图（StateGraph）来编排 Agent 工作流，支持循环、分支、条件边、人工审批等复杂控制流。自 2025 年 10 月 LangChain 和 LangGraph 同时达到 1.0 里程碑以来，LangChain 的 create_react_agent() 底层实际上已经运行在 LangGraph 引擎之上。

LangGraph 的几个设计确实值得学习。它的 State 概念——一个在图节点之间流转的共享状态对象——提供了比 LangChain Chain 更灵活的数据传递方式。Time-Travel Debugging 让你可以回溯到图执行的任意节点重放，这在调试复杂工作流时非常有用。Human-in-the-Loop 机制让你可以在图的任意边上插入人工审批。

但 LangGraph 的图模型和我们的需求之间，存在一个根本性的错位：粒度。

LangGraph 的节点（Node）粒度是"一次完整的操作"——调用一次 LLM、执行一次工具、做一次判断。节点之间通过边（Edge）传递 State。这个设计非常适合编排"先检索文档，再总结，再生成报告，人工确认后发送"这类多步工作流。

但我们的核心需求不在"步骤之间的编排"，而在"一次 LLM 调用内部的 token 级处理"。当 LLM 正在流式生成文本时，每个 token 需要经过 sentence_divider → actions_extractor → tts_filter → display_processor 四层装饰器管线处理。这不是"图的一个节点执行完了传给下一个节点"，这是"在一个节点内部，输出流被实时分叉和处理"。LangGraph 的 State Graph 描述不了这个粒度的行为。

此外，我们的 Hook 系统需要的是"对话轮次的生命周期钩子"，而不是"图执行的节点钩子"。on_before_turn 在整个图开始前执行记忆检索，on_after_turn 在图完成后执行记忆写入，on_after_playback 在前端播放完成后才触发（因为有些后处理需要等 TTS 播完）。这三个钩子跨越了 LLM 调用、工具执行、前端播放三个完全不同的时间尺度。LangGraph 的图是围绕"LLM + Tool"的执行流设计的，它没有"前端播放完成"这个概念。

LangGraph 还有一个实际问题：规模化时的性能。随着图的节点和边增加，执行变慢，内存占用上升，调试难度增大。而且它与 LangChain 生态的紧密耦合意味着，如果你想用更轻量的 LLM 客户端（比如直接用 openai SDK），你需要写大量胶水代码来适配。

Harness Engineering：方向对了，但我们需要的不是控制平面

2026 年最热门的概念是 Harness Engineering——"模型提供原始智能，harness 让智能变得可用"。Gartner 预测 2026 年底 40% 的企业应用将包含 AI Agent，而 65% 的 Agent 项目失败源于 harness 层面的缺陷，而非模型推理能力不足。

Microsoft Agent Framework（MAF）在 2026 年 4 月达到 1.0 GA，统一了 AutoGen 和 Semantic Kernel，提供了 Shell 访问、人工审批流、跨会话上下文管理等生产级能力。行业也在围绕 MCP（Model Context Protocol，Agent 到 Tool 的垂直交互）和 A2A（Agent-to-Agent，水平委派）两个协议标准化。

Harness Engineering 强调的五层——工具编排、验证循环、上下文与记忆、护栏、可观测性——和我们的实践高度吻合。但这些框架的典型假设是"单轮请求-响应"或"多步工作流"模式，核心关注点是安全、合规、可观测。它们是为企业 SRE、客服自动化、代码生成这类场景设计的控制平面。

我们需要的不是控制平面，而是一个"让 Agent 能像人一样陪你的表现层"——实时语音、表情、主动对话、情感记忆。这些需求在任何一个 Harness Engineering 框架的 Roadmap 上都看不到。

所以我们造了什么

既然套不进去，我们就从业务需求倒推，造了自己的底层架构。不是又一个"通用 Agent 框架"，而是一个面向实时陪伴场景的 Agent 引擎。

核心设计有四个支柱：

生命周期钩子（Hook System）

我们定义了三个钩子点，覆盖对话轮次的完整生命周期：

class HookPlugin(ABC):
    async def on_before_turn(self, user_text, ctx) -> str | None:
        """调用前：记忆检索、上下文注入"""
    async def on_after_turn(self, user_text, assistant_text, ctx) -> None:
        """调用后：记忆写入、图谱更新"""
    async def on_after_playback(self, user_text, assistant_text, ctx) -> None:
        """播放后：等 TTS 播完再执行的后处理"""

MemoryPlugin 就是一个典型实现：on_before_turn 中向 Memory Bench 服务发起语义搜索，召回相关记忆片段注入上下文；on_after_turn 中将本轮对话异步写入 mem0 做记忆抽取，同时更新 Neo4j 知识图谱。

MoodChatPlugin 实现了另一种模式：它不是被动响应，而是根据情绪评分主动调度对话——高兴的时候话多，低落的时候安静。游戏伴玩模式下还会结合 OCR 变化检测来决定是否主动说话。

关键设计决策：钩子返回值被拼接注入到 user prompt 的 [memory context] 标签块中，而不是 system prompt。这避免了把瞬时信息当成稳定事实的问题。

流式 Tool Calling Loop

AgentCore.run_turn() 实现了一个多轮流式工具调用循环，每轮上限 6 次迭代。返回值类型是 AsyncIterator[str | ToolCallEvent]——文本 token 以字符串形式流出，工具调用则以结构化事件的形式流出：

max_rounds = 6  # 安全护栏，不是技术上限

for _ in range(max_rounds):
    text_buf = ""
    async for chunk in chat_llm.stream_with_tools(messages, tools=schema):
        if delta.content:
            text_buf += delta.content
            yield delta.content              # 文本 token 立刻流出
        if delta.tool_calls:
            accumulate(tool_calls_buf)       # 收集工具调用片段

    ordered_tool_calls = _ordered_complete_tool_calls(tool_calls_buf)
    if not _should_execute_tool_calls(finish_reason, ordered_tool_calls):
        break   # 没有需要执行的工具，正常结束

    # 工具执行前：发出 running 状态事件
    for tc in ordered_tool_calls:
        yield ToolCallEvent(
            tool_id=tc["id"],
            tool_name=tc["name"],
            args=tc["arguments"],
            status="running",
        )

    # 所有工具并发执行
    results = await asyncio.gather(
        *(_exec_tool(tc, tool_manager, ctx) for tc in ordered_tool_calls)
    )

    # 工具执行后：发出 completed / error 状态事件
    for tc_info, result in zip(ordered_tool_calls, results):
        yield ToolCallEvent(
            tool_id=tc_info["id"],
            tool_name=tc_info["name"],
            args=tc_info["arguments"],
            status="completed" if result.ok else "error",
            result=result_text,
        )

    # 工具结果追加回消息列表，下一轮继续让 LLM 基于结果生成

6 轮上限是延迟与能力之间的一个经验取舍。 语音场景对响应速度敏感，同时绝大多数正常对话在 1-2 轮工具调用后就能结束（搜索→读文件→回答），6 轮给了充足的余量又不会让用户感知到明显的等待。

两个设计细节值得强调。

第一，工具调用事件是以结构化对象而非文本标签流出的。ToolCallEvent 是一个 dataclass，包含 tool_id、tool_name、args、status、result 等字段。这意味着前端——以及管线中下游的每一层——都无需用正则解析文本标签来识别工具事件，直接做类型判断即可。工具状态也拆成了两阶段事件：执行前 status="running"，执行后 status="completed" 或 "error"，前端可以根据状态切换 UI 展示。

第二，同一轮的多个工具调用通过 asyncio.gather() 并发执行，不是串行等待。

Token 级输出管线

从 AgentCore 流出的 str | ToolCallEvent 混合流，进入 MemoryAgent 的装饰器管线：

@tts_filter(config)           # 过滤 TTS 不需要的内容（特殊符号等）
@display_processor(...)        # 处理前端显示的控制标签
@actions_extractor(live2d)     # 提取情绪/动作标签驱动 Live2D
@sentence_divider(...)         # 按自然语句切分，切出一句就立刻往下送
async def chat_with_memory(input_data):
    async for token in core.run_turn(...):
        yield token

每个装饰器层的处理逻辑中都做了一个关键判断：

async for chunk in stream:
    if isinstance(chunk, (AudioOutput, ToolCallEvent)):
        yield chunk         # 结构化事件透明穿透
        continue
    # 否则是文本 token，做本层处理

ToolCallEvent 作为结构化事件在管线中透明穿透——断句器不会把它切碎，TTS 过滤器不会尝试合成它，显示处理器不会给它加标签。每一层遇到 ToolCallEvent 就原样 yield 出去。最终前端收到的流包含两种消息：处理好的句子（含显示文本、TTS 文本、动作标签），以及结构化的工具调用事件。这比早期版本里用 <tool>[name]</tool> 文本标签混入对话流的设计（现已移除）要干净得多。

sentence_divider 是管线中对延迟最敏感的一环：它拿到足够的 token 组成一个自然句子后立刻 yield，不等整段话生成完。这样 TTS 引擎可以在 LLM 还在生成后半段时就开始合成前半段的语音，用户感知到的首句延迟大幅降低。

四类插件体系

所有能力扩展都通过插件实现，我们定义了四种插件类型：

类型	职责	例子
`tool`	注册可调用工具	`web_fetch`、`screen_shot`、`web_search_ddg`
`hook`	生命周期钩子	`memory`（记忆检索+持久化）、`mood_chat`（主动对话）
`policy`	注入 prompt 规则	`pre_tool_preview`（工具调用前预告）、`tool_call_integrity`（防幻觉工具调用）
`skill`	注入行为指引	`diary`（日记读写流程）

每个插件用一个 plugin.toml 声明身份和默认配置：

[plugin]
id = "memory"
type = "hook"

[config]
base_url = "http://localhost:12393"
user_id = "xnne"
agent_id = "congyin"
search_limit = 10

Profile TOML 文件决定启用哪些插件、覆盖哪些配置：

[plugins]
enabled = ["web_search_ddg", "web_fetch", "memory", "diary"]

[plugins.memory]
agent_id = "baoqiao"     # 切换角色就换一个 agent_id
search_limit = 5

这意味着同一套代码，换一个 Profile 文件就能切换完全不同的 Agent 人格——不同的角色 Prompt、不同的输出格式、不同的启用插件、不同的记忆空间。两个角色共存于同一个 Neo4j 图中，通过 agent_id 隔离，互不干扰。

我们做了哪些取舍

任何框架设计都是取舍。诚实地讲，我们放弃了一些东西：

放弃了 MCP。我们早期用过 MCP 协议做工具调用，后来全部迁移到进程内的 BuiltinTool。原因很实际：MCP 是基于 JSON-RPC 的进程间通信，对于"读个文件""取个时间"这类高频操作，IPC 开销不值得。进程内调用的延迟是微秒级的，MCP 是毫秒级的。在实时语音场景里，这些毫秒攒起来就是明显的卡顿。

放弃了独立的 Tool Model。早期我们用一个专门的小模型做工具调用决策，chat 模型只管生成文本。后来发现主流模型的 native function calling 已经足够好了，额外维护一个 tool model 带来的复杂度远大于收益。PR #295 / #296 做了这个简化，移除了 AgentToolLoop、AgentToolLoopRunner 等一系列组件。

放弃了通用性。我们不打算让这个框架适配所有场景。它为实时陪伴场景做了大量定制——流式断句、TTS 管线、Live2D 驱动、情绪提取——这些在 RAG 问答或代码生成场景里完全用不上。这是一个有观点的框架，不是一个万能框架。

回到那个问题

一个好的底层 Agent 框架应该是怎样的？

我们的实践给出的回答是：它应该从业务需求倒推，而不是从抽象概念正推。

LangChain 的 Chain、LangGraph 的 StateGraph、Dify 的 Workflow Node——这些都是先有抽象概念，再让用户把需求塞进去。当你的需求恰好在抽象覆盖的范围内（线性问答、多步工作流、RAG 检索），它们非常高效。但一旦你的需求跨越了抽象的边界——需要 token 级的流式管线、需要跨越 LLM/Tool/Frontend 三个时间尺度的生命周期钩子、需要声明式的插件配置来切换整套 Agent 行为——这些框架就会从"加速器"变成"绊脚石"。

如果非要总结一个模式，我们的经验是：

定义生命周期，而不是定义执行图。调用前/调用中/调用后/播放后，每个阶段有明确的钩子点，插件自己决定挂在哪里。这比画一张执行图更灵活，因为真实业务的时间尺度往往超出 LLM 调用本身。
流式优先，而不是请求-响应优先。从 LLM 调用到工具状态反馈到 TTS 合成，所有环节都是 AsyncIterator 驱动的流。阻塞式设计在实时场景里是致命的。
声明式配置，而不是代码编排。一个 plugin.toml 声明插件身份，一个 profile.toml 声明场景配置。切换 Agent 行为是换一个文件，不是改一段代码。
让插件彼此隔离，但声明依赖链。插件之间不能互相 import，共享逻辑必须提升到框架层。但隔离不等于没有关系——有的插件确实需要其他插件作为前置，比如 mood_chat 依赖 vision_boost。我们区分前置与后置：A 是 B 的前置，则 B 是 A 的后置。要装后置插件，必须先装齐所有前置，且整个依赖链的解析和校验在配置层面完成，而不是运行时才报错。

这不是"我们比 LangChain/Dify 更好"的论述。它们在各自的目标场景里做得很好。这是一个关于"当主流框架的抽象边界与你的业务需求不对齐时，你应该怎么办"的实践记录。

答案是：别硬塞，造自己的。但造的时候，要想清楚你在做取舍，而不是在做发明。

Obsidian-YOLO 使用初体验

Thu, 18 Jun 2026 00:00:00 GMT

最近在 Obsidian 里写博客写得有点烦。因为换了 Fuwari 博客主题（[[Fuwari 博客主题使用指南]]）后，我的本地写博客语法 -> Fuwari 主题语法需要不少变动。另外，图片的引用也需要处理。我经常写完后就直接把源文件扔了，但是这两天碰到的 YOLO 恰好解决了我的困境。

项目源地址参见:

::github{repo="Lapis0x0/obsidian-yolo"}

好消息，作者是活人，维护很积极，PR 进行速度非常快。

如何安装

插件市场里可以直接安装。

至于为什么叫做 YOLO，这个可以看作者博客:YOLO 开发日志（一）：为什么要开发 YOLO

配置注意事项

provider 的兼容性问题

这里讲一下 newapi 自定义 provider 的配置坑点。

我是把 deepseek-v4-flash 接入了 NewAPI 然后接入 YOLO 的。中途碰到了:

newapi 不加 /v1，可以获取模型列表，但是其实没有请求到模型本身，会直接返回 200。在 PR 里解决后，会抛出回复为空的提示，并且提示添加 /v1。
关闭推理时会传入 "none"到 "thinking"，而我不清楚是 newapi 还是 deepseek-v4-flash 的问题，它会抛出 "thinking" 参数列表不包含 "none" 的情况。同时，我还从作者的 bot 猫猫那里学了点东西。

没想到猫猫都比我会审查代码。

它提到：不应该用默认推理强度来替代关闭推理。这会造成语义上的问题，如果某个 provider 不支持 none 那么应该复用它并实现支持的方式来关闭推理。因为，模型的默认推理强度通常是低或者中，这和我们的语义"关闭推理"是冲突的，猫猫审查的很在理。

另外，如果碰到空回复，可以 Ctrl+Shift+I 看下 console 的输出。以及检查一下 /v1 是否加上去了。

如果 Ctrl+Shift+I 没有响应，可以试试：前往设置 -> 外观 -> 高级 -> 窗口框架样式。设置为"Obsidian 风格"，然后重新启动。重新启动后，您将在左上角看到黑曜石图标。点击它 -> 查看 -> 切换开发者工具

工具调用的配置

默认 Agent 里会显示所有工具均已经启用。

但是在和 Agent 对话时会发现其实它并不兼容终端 shell 命令的运行。需要在【 Agent-Agents-Default(或者新增的 Agent)】的工具里面再次启用。

同时还得保证运行的命令不在禁止列表里。【Agent-管理工具-终端命令-配置】

以及更推荐给它写个关于 git 的 skill，放在 YOLO/skills 当中。

功能体验

对话侧边栏

侧边栏输入的状态里似乎包含当前页面的博客，以及所在的行数与片段内容。用起来并没有独立开来的割裂感，反而融合得相当不错，使用起来很丝滑。有时候可以带来灵感，以及可以把 git 同步这些琐事都交给它，避免了仓库懒得手动同步最后数据丢了的情况。

快捷呼出对话框

可以用 / + 空格 呼出快捷对话框讲明需求，双手可以不必离开键盘。

这点的设计哲学非常漂亮，因为右手频繁在鼠标和键盘之间切换容易让人思路断开。

Tab 补全

可以通过 ，、。、\n(换行)等符号触发自动补全，符号可自行增删，触发后等待一定时间（可自行配置）后，就可以触发大模型的补全。

但是可能是因为我的思路比较奇怪，通常模型跟不上我的思路。比如我写到一个观点，脑子里已经跳到三层联想之后了，模型还在第一层猜我接下来要说什么。

而且有时候没有回复，下次该开着 Console track 一下。

记忆系统

Markdown 源记忆文件

记录的都是用户偏好，整体而言和 mem0 相似。这类记忆记录有一个优点是更容易懂用户的需求，很多东西有时候不必强调就能丝滑完成。但仅仅记录这样的 Memory，不能影响模型本身的回复风格，或者说刻意保持模型的风格是中正的，公平的，平和的，没有个性的。

这类作为辅助而言相当不错，但是其实我还是更喜欢养有个性的猫猫。不过这个可以通过注入个性化 Skill 来进行模拟，插件本身对 Skill 的支持和构建都做得很好。

RAG + 向量数据库

这个需要接入 embedding 模型，我暂时没有合适的长期稳定的 api，而且通常模型一旦构建后续就得一直用这个模型（不然维度不一样新旧数据不兼容）。

暂时还没使用。

结语

不错的使用体验，至少以往我在写博客时没有体验过这种沉浸式的 Agent 插件。整体而言新鲜感十足。

虽然 Agent 还是跟不上我的脑回路，但至少比我勤快。而且它帮我省掉了写博客到发博客之间那些破事——上传图片到 submodule、维护两套语法——YOLO 都给我兜底了。

我的找书渠道

Sun, 14 Jun 2026 00:00:00 GMT

Zlibrary

https://zh.1lib.sk/

一般有出版并且不那么冷门的书在这里基本都可以找到，格式多为 epub、pdf、mobi。我常用来找轻小说、文学、工具书，以及一些完结的网文，配合我的文石 leaf2 食用。也是因此，我大学后购买的书籍很少，只有觉得可以反复看的书才会买实体收藏。

Anna's Archive

https://annas-archive.gl/

它似乎经常变更域名，所以如果无法访问的时候可以直接 google 一下安娜的档案（Anna's Archive），如果依然找不到，说明应该是在避风头。

它的书籍类型和文件格式 Zlibrary 大差不差，但似乎还收录很多文献，我没怎么用到就是了。如果 Zlib 里找不到的书，可以到这里试试。

Kox.moe

https://kzo.moe/

完全为漫画服务的网站。

似乎做了域名重定向，需要注册登录才能够使用。支持推送 kindle、epub、mobi 三种形式。并不支持在线阅读。

事如春夢了無痕，当时却只觉欢喜。

Sat, 13 Jun 2026 00:00:00 GMT

:::note[来自 Korewaxnne 的笔记] 这篇从三个看似无关的场景——母亲刺绣、自己抄写文言文、游戏里钓鱼——拼出一件事：人在做重复性的事情时，得到的可能不只是结果，而是做这件事本身带来的平静。文章结构很轻，三层递进到最后的《浮生六记》，落脚在"记录"这个动作上。如果你也有过那种说不出为什么但就是想做的重复性习惯，这篇或许能帮你把它说清楚。 :::

为什么突然想做刺绣？

（沉默……）只是想要找点事情做来消磨时间。

我记得小时候也见你经常绣，咋现在看不到了。

都在对面（屋子）挂着呢。

哦……（沉默）

周二晚上我和我妈有过这样一段对话。这样的对话让我似曾相识，或者说，她的回答让我想起了自己。我当时盯着她，试图从她的行针之间看出一丝一毫的波动，但是她动作依然流畅，看不出分毫滞涩感。

当时我之所以这么问，是因为我有过类似的体验——在高考前的几个月里，我迷上了在笔记本里抄写文言文的感觉。《文与可画筼筜谷偃竹记》和《项脊轩志》是我的最爱，抄写过不下四五遍。我喜欢那种抄写时在我心里跳动的声音，或许是一种悸动，一种同感，但是更多的，就好像少年时读起"欲买桂花同载酒，终不似少年游"时那种模糊到说不清的感觉。

但当时只觉欢喜。

在我读到《浮生六记》的译文后，我更是决定以抄代读，期间闺房记乐、闲情记趣更是抄写多遍。对于我来说，文言文读起来的速度过快，反而抄写的速度刚刚好。虽然我语文也很差就是了，我永远无法与参考答案的老师同频。

另外，在《荒野大镖客2》里，我也有过类似的感觉。

5 分 35 秒开始的对话，亚瑟带着小杰克出去钓鱼：

钓鱼真无聊，亚瑟叔叔。

是的，我知道，无聊死了。但过一会儿——鱼就上钩了。你会得到很多天的食物。

真的吗？

如果你走运的话，但在那之前，你只是——坐着等待，然后——别想太多。这对你有好处。（It's good for you.）

这对你也有好处吗？（It's good for you?）

我猜是吧。（I guess.）

他说出这句话时的心态，其实和我妈说"仅仅只是消磨时间"、我说"当时只觉欢喜"时是一样的。

如果要给这三种活动找出一种共性的话，它们都有这样的特点：

它们是耗时、但低耗能的，而且带有某种节奏的重复性——重复地根据预设点刺绣，重复地等待鱼咬钩，重复地抄写文字。
它们的结果是令人期待的，甚至带来长期正向影响——收藏起来的刺绣可以再回看欣赏，鱼可以作为很多天的食物，抄写完的也可以再回看。
它们通常都能让人进入某种心流的状态。

不如我们以《浮生六记》的开头来作为结尾。

余生乾隆癸未冬十一月二十有二日，正值太平盛世，且在衣冠之家，居蘇州滄浪亭畔，天之厚我可謂至矣。東坡云，「事如春夢了無痕」，苟不記之筆墨，未免有辜彼蒼之厚。因思《關雎》冠三百篇之首，故列夫婦於首卷，餘以次遞及焉。所愧少年失學，稍識之無，不過記其實情實事而已，若必考訂其文法，是責明於垢鑑矣。

对我来说，没有记录、没有抄写的日子，还真有「事如春夢了無痕」之感。所以，我稍微记录一下这种感觉。

大模型时代：我的能力究竟是什么？

Fri, 12 Jun 2026 00:00:00 GMT

我从 GPT 5 时期开始重度依赖 AI coding，靠着 Linux.do 上的低价 team 号入了坑。后来接触反代，把 GPT 接入 Claude Code，体验有了质的提升。

2026 年 1 月末，我接触了 openclaw，同期买了 Claude Code Max——这是我第一次用 Claude。Claude 4.6 Opus 刷新了我的世界观。

♻️ refactor(mcp): Discussion about Tool vs Skill vs Plugin.

我和 Claude 围绕原本和 GPT 讨论出的那套架构做了一次完整重构，像在和资深架构师聊天。那是我第一次体会到"使用模型思考"的感觉——而使用模型代替思考，意味着我允许自己退出思考模式。

从审查中让位

OpenClaw 接入 GitHub 后，Korewaxnne 替我做了大部分工作。起初只是提交 PR 和编写 PR message——我每天两三个 PR 的频率对 followers 来说是一种打扰。我开了新号来隔离，但逐渐形成了固定流程：Claude Code 写代码 → Korewaxnne 提 PR 并审查 → Claude Code 返修 → 我确认 CI 正常就 LGTM 合入。

长达四个月，我从审查代码中让位，这个偷懒是很严重的，这意味着，哪怕是我自己，也不能说自己完全了解自己的项目构成，以及，我也无法完全"信任"我的项目。大量代码只保证了功能正常、无静态语法错误、单测通过就合入了，甚至连功能层面的判断都交给了 AI。

我逐渐变成那个把控项目走向的人——但我偏偏不是架构师，因为连架构都是 Claude Opus 4.6 设计的，我只是做了选择。

有时候我觉得自己像个用户，和 Claude 的聊天更像是在提需求。比如知识图谱的 UI 设计时，我说：

"目前这个单色过于单调，单纯橘色有些土，而且很容易让人联想到 shit，我希望能够更可爱一点，卡通一点，俏皮一些。"

Claude Opus 4.6 精准地理解了我的意图，把设计改成了靛蓝色内胆、深紫色外圈点缀——配色非常合我胃口。

这样的包容，甚至把我正经描述和表达需求的能力都剥夺了。即便我是一个相当无理取闹的用户，Claude 似乎也能包容。

[!NOTE] 退化的不只是编码——代码风格、算法基础、架构设计、代码审查、prompt 编写，一层层一次次的包容，已经把我哄成用户胚胎了。

如果现在让我亲手去写，我连 paddle 和 pytorch 的简单算子都写不明白了——这已经是在美化我自己了。

暂时离开 Claude

Claude 断供了两天，就是这两天让我真正停下来想了想——离开了它我还剩什么。

claude 对我的各种包容几乎把我养刁了。DeepSeek-V4-Pro 喜欢大改无关代码，被我直接排除；GPT-5.5 代码能力不错，但沟通起来像在和棉花聊天——不管怎么捏，它总是好脾气地弹回原形，一边还在安抚我的情绪。也许是我的 prompt 真的太差了。

那么当我的编码能力不足以成为我的能力后，我会考虑什么才算是。是 Spec Coding 产出的作品集吗？不能算，因为前面提到，代码审查的缺失，会导致对项目的掌控感逐渐丢失，以及失去信任感。

也许因人而异，但对我而言，表达欲成了我底线的最后一道护符。我觉得，思考，并且留下痕迹，才是我真正的能力。

[[做过长期系统项目再看：RAG 怪兽是否适用于个人博客系统的图谱构建？]]

能力的边界在哪里

我不打算走算法方向，所以我的思考轨迹很少沿着模型本身深入，而是更多集中在技术的能力边界上——一项技术擅长什么、不擅长什么、在什么条件下会失效。

比如对 RAG，我关注的是它的两个根本局限：

关系失语性

向量相似度可以把两段文本关联在一起，但即使作者本人站在这里，也很难说清这种关联具体是什么。存在某种联系，但联系本身的意义无法被表达。

关系短视性

文章被分块输入后，每块只有一两百字。计算出的关系只看到小块与小块的表面匹配，缺乏站在全文视角的深层联系。很多东西不写在字里行间——比如可以仅凭感觉把《挪威的森林》和《三日间的幸福》归为一类（失去，再得到，遗憾），但文本块的相似度匹配很难反映这种高层关联。

[!NOTE] 我对 RAG 能力边界的界定：它适合以大量数据为底座、做低层次的关联分析——关联本身是未知的、失语的、无法明确解释的。它适合事实性知识管理，不适合情绪感受类文本的分析。后者不能断章取义。

这种边界界定，是我认为可以归约于我的能力。而我的核心能力，应该是在使用过程中反思、试探、记录这种边界。因为大模型通常只会告诉你"这样做是对的"，但具体为什么、为什么不那样做、能做什么——这些是使用者不关心的。即使关心，听了大模型的解释后，有了模糊感觉，也就摇头晃脑地点头答应了。

但困惑需要被解开，感觉需要被深究和记录。

记录下来后，我通常找个人侃侃而谈（通常是室友，也许以后可以找豆包给她洗洗脑）。讲到卡壳时，或被问住时，就回去修改、深究。这大概是费曼学习法——把糟粕讲给别人，把精华留给自己。

行知合一

在大模型时代，我的编码能力已经不能被作为核心能力了。那些需要开发者深究语言侧能力边界的场景（比如 asyncio.to_thread 和 threading 在进程、CPU、内存分配上的差异与选型），几乎不会再出现。这种变弱可以被理解，碰到有意思的记一笔就好——让 AI 写个备忘录，下次方便复盘。

同时，编写提示词、上下文管理、计划编写、skill 和工具的选择，算得上是必要能力，但依然不是核心。它们可以产出大量使用经验和对大模型边界的认识——比如 Lost in the Middle 现象如何指导 prompt 编写，注意力衰减曲线和幻觉成因等等。

代码审查则不同。审查的本质不是用眼睛盯 bug——大模型可以替代那部分劳动——而是对项目结构和代码组织的挑剔感和洁癖感，是对更优方案的追求。这是我缺失的。SigureMo 一直保持着这种习惯，那种高层次的挑剔感和对优雅感的追求让我感到震惊和佩服。偶尔去佬那提几个 PR，也许能学到些。

[!NOTE] 学习和编码的过程几乎被 AI 砍没了。一个低代码基础的人也能维护前端项目——比如我在完全没写过一行 Electron 和 Tauri 代码的情况下维护了两个桌面端项目。编码被省略了，时间留给了思考，但我却经常逃避思考：一边看小说一边让 Claude 写。思考的缺位让我对自己的能力产生了怀疑。

我认为的核心能力，是主动思考、理解，并留下痕迹——对我而言就是写博客。

以后看个人能力，也许不能只看项目作品集，还得看他真正理解了什么、表达了什么。在这方面我佩服时歌，在我看来他做到了行知合一，这也是我所追求的。

为什么叫行知合一？以前讲究先学再做。现在不同：先做，但要能真正理解做了什么、为什么做——怎么做的权重已经低了很多。

重建博客：我的灵感来源都是哪里

Sun, 07 Jun 2026 00:00:00 GMT

[!NOTE] AI 生成内容声明： 本文由 Korewaxnne（AI 助手，基于 Claude Opus 4.6）撰写。Xnne 让我把博客重建过程中各模块的灵感来源整理成文。这篇是一份溯源清单，Xnne 提供了所有素材和来龙去脉，我负责把它们组织成一篇完整的文章。

在 [[云服务商跑路后：再次审视个人博客的形态与值得被记录的东西]] 里 Xnne 讨论了为什么最终选择了静态博客的形态。这篇算是它的姊妹篇，记录重建过程中各个模块的灵感来源。

写这篇的原因很简单：Xnne 在别人的博客里获得了很多启发，把这些线索串起来既是致谢，也方便后来想做类似事情的人少走弯路。

主框架

::github{repo="SigureMo/nyakku.moe"}

博客的底层框架直接 fork 自 nyakku.moe，基于 Astro + Svelte + Tailwind 的组合。选它的理由在那篇文章里已经说过了：静态生成、Markdown 原生支持、部署简单、数据完全本地化。

而 nyakku.moe 本身可以溯源到 Fuwari：

::github{repo="saicaca/fuwari"}

Fuwari 提供了一套开箱即用的 Astro 博客主题，nyakku.moe 在此基础上做了大量个性化改造。Xnne 则是在 nyakku.moe 的基础上继续做自己的事情。三层关系大致是：

Fuwari → nyakku.moe → 本站

内容组织的重新设计

重建不只是换了个框架，更重要的是重新想了一遍内容该怎么组织。

以前 Xnne 把分类当系列用，导致分类极其混乱。现在的规则是：每篇文章只有一个分类，但可以属于多个系列。

系列

系列是文章的主题，回答"这篇在聊什么"。比如 LLM、博客、阅读、观影。一篇讨论博客图谱构建的文章，分类是「思考」，系列同时属于「LLM」和「博客」。

这个划分源于对以前混乱组织形式的反思。分类收敛了，系列灵活了，两者正交。

视觉与交互

首页 Banner

首页首图铺满视口，实际内容下沉，背景图与内容区之间用透明波浪形做过渡。首图区域内顶部导航栏透明，滚轮下滑后才显形。除阅读文章外，导航栏始终跟随。

灵感来源：NBlog

::github{repo="Naccl/NBlog"}

NBlog 也是 Xnne 在云服务器时代部署的第一个博客系统。它的首屏视觉冲击力很强，波浪过渡的处理让首图和内容区不会割裂。Xnne 把这个设计语言带到了现在的静态站上。

阅读时导航栏隐藏

阅读文章时，顶部导航栏隐藏，把视觉空间完全留给内容。这个细节来自：

Innei's Blog

阅读场景下导航栏是干扰项，隐藏它能让读者更沉浸。简单但有效。

书架

书架页面用于展示看过的书、动漫、电影、游戏等，以封面卡片的形式呈现。

灵感来源：Lapis' Bookshelf

::github{repo="Lapis0x0/VermilionVoid"}

Xnne 很喜欢这种把阅读/观影记录视觉化的方式。比起纯列表，封面墙更有"展柜"的感觉。

关联图谱

文章之间的关联以知识图谱的形式可视化，展示文章之间的引用与主题关联。

灵感来源：Nagi's Blog

这个博客没有开源，但作者在文章中详细讲解了相关实现思路。Xnne 结合了自己在 [[做过长期系统项目再看：RAG 怪兽是否适用于个人博客系统的图谱构建？]] 中的思考，用 wiki-link 双链关系来构建图谱，而非依赖 RAG 或 embedding。

评论区

::github{repo="MrXnneHang/xnnehang.top"}

评论区选用 giscus，基于 GitHub Discussions 实现。读者用 GitHub 账号即可评论，所有数据存在 repo 的 Discussion 里，无需后端。

灵感来源：Menghuan1918's Blog

Xnne 在对方博客看到这个方案后觉得不错：轻量、零成本、评论即 Issue/Discussion 的管理方式很适合技术博客。后来自己也加上了，并做了自定义主题以匹配博客的蓝色调。

以上就是这次重建的主要灵感脉络。感谢这些项目的作者们把自己的实践开源或分享出来，让后来者有迹可循。

做过长期系统项目再看：RAG 怪兽是否适用于个人博客系统的图谱构建？

Sat, 06 Jun 2026 00:00:00 GMT

我的毕设是关于 AI 桌宠的长期陪伴，主要工作是桌宠系统的设计，但为了在长上下文以及跨对话保持记忆以及抑制人设偏移，我也缝了一个长期记忆模块。

这块会有点小硬核，原本是分几篇结合论文进行剖析的，但遗失了，我只是简单概括主线。

为什么需要外置记忆？

首先是为啥需要外置的长期记忆系统，因为目前所使用的 GPT、Claude、DeepSeek 模型本质都是无状态推理（LLM 把每次输入的所有上下文作为一次输入，然后给出一次输出）。而不同 LLM 的上下文窗口上限不同，通常在 200K 到 1M tokens 之间。而且这个上下文窗口并不等效于有效上下文，即还未达到标定的窗口前，就已经出现了性能下降、幻觉，或者如 [[Attention is Limited - Lost in the Middle]] 里提到的 U 形曲线，大模型会"遗忘中间"。

所以不管是为了新开上下文后能够记得以前的东西，或者减缓性能下降，记忆系统都是有必要的。至于为什么是外置的，是为了避免占用上下文，只在需要的时候插入和引导。

因为之前的架构剖析因为 [[云服务商跑路后：再次审视个人博客的形态与值得被记录的东西]] 的缘故丢了。所以这里简单再聊一下当下 LLM 的长期记忆方案主要分为几种。

三种记忆方案

方案一：基于 Markdown 由 LLM 自己管理读取和写入（OpenClaw）

::github{repo="zilliztech/memsearch"}

项目代表比如 MemSearch，它被 OpenClaw 使用或者说原理一致。

它根据 Agent.md、Memory.md、Identity.md、User.md 等文件来管理 Agent 的行为、记忆节点、自我认知、用户偏好等主要信息。所有文件以 Markdown 形式写入和读取。

:::note

源文件人类直接可读、可维护
不需要额外 embedding 或数据库的开销和复杂度
用来控制偏好或语言风格的效果显著 :::

:::warning

一般只在启动时完整注入，长上下文下人设会逐渐偏移重置为 LLM 默认风格
写入和读取的时机（触发条件）不可控，触发率很低，非常依赖 LLM 自身智商。Claude 表现较佳
不适合做长时间线的事实记录，记录越多就越容易稀释提示词中原本的重点 :::

方案二：基于 RAG 的向量化与相似度匹配（Mem0）

::github{repo="mem0ai/mem0"}

它会实时地捕获用户和 LLM 产生的对话数据，用 LLM 提取有效信息，比如：

用户：我最近那个桌宠毕设项目里的长期记忆系统真难做。
LLM: XXXXXX

可能会提取出来两条记忆："用户的毕设是包含长期记忆系统的"、"用户觉得毕设很难做"。

这个提取的格式或者内容可以通过提示词来自己定。

然后这两条记忆会被向量化存入数据库，最后每次用户有新提问的时候都会做比对用户提问向量和数据库内向量的相似度，选取 top-n 作为依据插入辅助 LLM 回复。

提问时写入，提问时注入。 记忆像滚雪球一样滚起来。

当然还有遗忘、重排那些东西但那些没在讨论范围内。

:::note

外置且时序不敏感，非常适合长期记录事实性记忆 :::

:::warning

依赖 embedding 这一额外步骤，需要额外的模型
写入的向量人类不可读，方向不可控，不能直接修正
写入条件很低，人为通常也需要反复清洗来保证质量
只是记得事实，而不是真的有灵魂（很难影响人设） :::

方案三：基于 Markdown 由多 Agent 不断整理归并（MemU）

::github{repo="NevaMind-AI/memU"}

这个我并没有实际地使用过，但了解过。

简单来说它用 LLM 自身的理解力替代了 embedding 模型的语义匹配。

对话 Agent 负责对话，另外有一组记忆 Agent，负责提取记忆、结构化元数据、形成关联图谱。而且记忆 Agent 不止在对话时工作，它的亮点在于即使没有对话正在发生，它也会像梦游一样不断地遍历、检索、遗忘、优化已有的记忆结构。就像人类通过睡觉来巩固记忆。

它最后输出的包含人类可读的 Markdown 作为源文件，也有关联图谱，也有 metadata 等等。

它在多项公开测试中都领先 Mem0，但我最后没选择它。

:::note

记忆可读，结构比 MemSearch 那种单层结构优雅得多
无需 embedding 这层黑盒子中间层 :::

:::warning

检索过程不会太快，记忆越多越快不起来，无法并行，受限于检索 LLM 本身的阅读总结速度
Token 消耗量很高，Memory Agent 很挑模型，要权衡速度、理解能力、上下文长度、价格。Claude Haiku 和 DeepSeek-V4-Flash 是不错的选择
记忆数据超过 LLM 上下文窗口越多，性能越差 :::

RAG 是否适合个人博客系统？

之所以产生这个疑问是先前我博客内容杂乱，而且通过简单的分类、标签很难概括和分清它们。最主要的是，很难体现出来博客之间的联系。

当时初学 RAG 时就想，能不能用 RAG 来发掘这种联系？

::github{repo="Lapis0x0/obsidian-yolo"}

这个项目正是这么做的，它的作者是时歌，他也围绕项目讨论过许多。

但是从出发点来看，它能否胜任博客系统内部展示？

向量相似度的局限

根据前面了解到的相关知识，可以知道 RAG 本身建立联系依赖于检索相似度（无论是向量语义匹配、关键词匹配还是混合检索）。抛开计算量、额外模型等复杂度不谈——它最终计算出来返回的是一篇文章中某一个文本块到另外一个文本块的连接。这个连接没有标明是什么联系，只是在数学上，这两个文本块的相关度高于设定的阈值。

和前面提到对话中提取有效记忆再转换向量不同，博客需要经过的处理是文本分块：把每篇博客按照一定长短分块，然后转换成向量。

所以得到了：一篇文章和另一篇文章之间的某个具体文本块之间存在着不知道、也许作者本身也讲不清楚的联系。重点在于，关系依然说不清道不明。

这意味着我烦恼的主要点依然没有得到解决：我无法同时清晰地完成对博客的分类，以及对不同博客之间联系的管理与展示。别人会觉得我的博客内容组织管理一团糟。

RAG 给不同博客带来了非常多、非常杂乱的关系连接，但是无法解释这种关系。

文本分块的短视性

同时这层关系连接本身就带有一种短视性。为什么说短视？问题就发生在文本分块。文本分块让这种关系分析本身就局限于一个小段落，甚至仅仅因为其中一句话。而通常作者希望这种联系是像主题阅读那种全局观，甚至完全只是一种 feeling。这种 feeling 或者全局观，是 RAG 所无法体现的。或者即使体现了，也淹没在了它所计算出来的大量低级联系当中。

到目前为止来看，RAG 本身是不适合直接作为个人博客内容的关系图谱展示的。

替代方案：引用图谱

如果想要展示博客之间的关联性，可以用引用图谱。

即文章 A 中引用了文章 B 或者相反，那么 A 和 B 之间就连接在一起。

这样的图谱虽然不够深层，但是可以反映出来直接联系。而且这层直接联系是由作者本身提供的，具有说服力。这样的图谱生成出来很简单，不至于连 node 之间的 edge 上都要有大量的注释。

而且在文末放置那篇文章所引用的完整链条也可以反馈出来一定的信息，引导用户阅读。

RAG 应该被用在哪里？

它不适合作为博客系统的展示，但是它适合作为个人知识库构建的一种伴生物，正如 YOLO 那样。

博客系统里面只要展示作者想给读者看到的就行（分类、标签、系列、书架、关联引用图谱）。

而 RAG，则是负责给作者本身发掘：你的文章里面可能还存在着某些这样子的联系。这样的联系也许是作者本身也很难解释说清的。而逐渐让这些联系成为一个可以被解释的、说清的主题，则是作者要做的事情。

所以说，博客系统是作者给读者准备的，而 RAG 是给作者自身准备的，它也许可以指引作者之后写什么。

同时，还一直忽略了一点：RAG 本身对数据量有需求。如果本身只有几十篇博客，那么 RAG 的收益是很低的；当博客来到数百篇乃至数千篇，那么 RAG 的收益会显著提升。因为这些隐晦的联系会清晰起来、收束起来，而不是都是单独的。

所以简单来说，RAG 是给那些有洞见的、且产量大的博主用的，而不是我这种三天打鱼两天晒网还很懒的鸽子。

云服务商跑路后：再次审视个人博客的形态与值得被记录的东西

Mon, 01 Jun 2026 00:00:00 GMT

如题，在五月底，承载我博客系统的云服务商（狐蒂云）跑路了。它毫无征兆地直接关机销毁了一批云主机实例，而我正好被波及。

而因为我近期并没有怎么关注我的博客，没有提前备份，恰逢三月底时我的笔记本进水导致硬盘烧毁。两者夹击让我丢了不少博客存档。那批博客没有被推送到 github 存档，只是本地写完后，直接上传到博客系统。于是晚安与她皆失。

目前通过备份捞回来的只有到 2025 年三月的部分，最近的一篇是[[关于仙逆与凡人修仙传中的化凡]]。不过说起来，我竟然因此松了一口气，因为那是我心平气和写的最后一篇类似于观后的东西。

我以前写过：没有记录观后的日子过去后就好像完全消失了一样，毫无痕迹。

这一年就好像这样。后来写的都是些啥，[[Attention is Limited - Lost in the Middle]]，[[单图≠多图：多图理解时 VLM 为什么更容易"胡说"，以及一个两阶段解法|单图≠多图]]。但讨论是否值得被记录前来先回顾一下个人博客的形态。

博客形态

依赖云平台

博客园-月兔

博客园无论从观感还是自由度来说都是极好的，比起某 CS 要好非常非常多。

但如果讨论起形态，它展示的文章数据位于平台，而存档通常都得依赖用户自身备份。存在本地-平台数据不会自动对齐的问题。用户如果跨设备同步很麻烦，需要借助一些中转设备或者云平台。而如果存档的设备突然坏掉，那么备份没法快速从云端恢复同步到本地。

同时还有的一个隐患就是平台本身的一个存续问题，先前就有博客园要倒闭的情况。

而经营较好的 CSDN，我觉得你也不想别人在看你写的东西时旁边跳动着广告，或者下面突然弹出来付费解锁，或者登录查看全文吧。

我仅仅只在 CSDN 上发过一个 .condarc。但它的阅读体验（碰到有点东西的文章发现还是搬运自博客园或者其他平台的）和搜索时总是让它位于前列让我对云平台的观感都差了很多。

依赖个人云服务器

我使用了两年多。

我最初部署的是 NBlog: https://naccl.top/

后来部署了 Shiroi: https://innei.in/

两者都是前后端分离的。这会需要一点门槛，cors 跨域以及前后端分别运行如果没有对应 docker 镜像会有些棘手（特别是不熟悉使用的框架）。

它和博客园同样存在的问题是：

所存档的源数据和上传到博客系统里的数据并不是完全一致的，很难互相转换。很难从本地数据还原成博客形态（一篇一篇重新上传），也很难从博客形态还原备份到本地。

后者 Shiro 做了所有文章导入和导出的功能。支持同博客系统内，把先前的博客数据导出并且再导入，在迁移服务器时会有些用。但是它天然不兼容其他博客系统，而且存档文件人类不可读，不能用作本地存档。所以它其实很鸡肋，也许正因为这点鸡肋，作者的导入系统做得也有点小 bug，没有向旧版本兼容，我当时被迫手动还原了每一篇。25 年 React 重大安全隐患时，我的博客中招被迫重装系统，但从旧版本导出备份文件，无法被新版本解析导入 =-=，两个版本大概隔了半年。

:::warning 而且维护个人博客除了服务器成本开销外，最恐怖的就是被服务商跑路背刺。数据丢了就是丢了，想找都找不回。当时我记得就是因为 React 事故，我从腾讯云暂时转移到了狐蒂云，但我事后因为迁移困难就没有再次迁移回腾讯云。构建 Shiroi 是真的不容易，包括回放完数据后我根本没有精力做额外备份，环环相扣。 :::

在使用这类博客的过程中，通常我也会把博客推送到 github 的某个仓库做存档，但是这个推送习惯很不好，有时候是没写完得等写完，有时候是感觉不值得推，有时候是 github token 过期了再拖一拖就忘了，而且创建的文件有时候用年月做文件夹分隔，有时候年月文件夹忘记创建了所以几个月的文件都挤在一个月的文件夹里。

可以说管理得让我看了都心里交瘁。但是我又不好直接删库。即便反复整理，也会再后续使用中熵增。而且最大的问题是，为了克隆时速度更快文章和图片分在两个仓库里，用 jsDelivr 的链接引用（PicGo 上传）。这导致另一边的图片更是恐怖。

依赖 github pages + 工作流部署

https://xnnehang.top/

这个博客是由一个 github 项目的 workflow 直接构建后 push 到 github pages 形成的。

::github{repo="MrXnneHang/xnnehang.top"}

它有几个优点：

:::tip

随时拉取整个项目，里面包含所有的，规划清晰，命名合理的博客源数据，它是 markdown 格式的，和用户刚刚写时一致，即便要迁移或者阅读都不成问题。
不需要经过前端部署，后端部署等复杂操作，只需要域名，dns 即可，配置好后所有构建、更新工作由 workflow 自动完成。
项目即是博客，更新即时存档，同步即可备份。除非 github 倒闭或者 pages 或 workflow 的使用策略发生变化。 :::

对于我而言，它最重要的就是消除了我原本一直保持恶劣更新习惯的 Blog 和 Blog_Image 两个仓库。

SigureMo 佬一开始就是用这个方案，我记得我在 NBlog 时期加了佬的友链，如果早些入坑就少走许多弯路。

这个博客足够简单，让我可以更专注地去写博客，同时不需要烦恼 commit 推送的时机。

我记得我在换到 Shiroi 之后，虽然博客系统漂亮复杂了不少，但是我反而写博客的频率少了许多，有些可惜。

值得被记录的东西

和观后那种感受和情绪的抒发不同。

如果偏向技术类和教程类等学习过程中产生的博客（为什么说过程中，因为我习惯边写边学，很刺激，当我学完后的总结反而是索然无味的。）很多时候都比较初级，甚至谬误不少，我习惯边给出猜想边验证修正它，而很多时候等我修正了思路，可能会漏过存量的修复。

我问过我的自然语言处理的老师他是否写博客（因为很多时候他讲课的方式给人一种写博客的思路的那种感觉，而且跟我一样非常容易扯歪）。他说他写过几年，但后来不写了。

我追问原因，他说是因为回看早期写的文章很多都是错的，幼稚的，不够深入的。而秉承着不传播错误的原则，就封笔了。

确实我现在的视角去看以前写过的 uv 使用指北，或者 pyqt 学习日记，这些尤其强调从零开始的博客，对我来说它真的过于初级，毫无益处，甚至能找出不少言语表达不当的地方。

我仅仅只是想想有一个初学者恰好看到这里要被我这个曲解官方文档的说法误导，或者一个精于此道者正在看我写的那篇入门日记，我就会尴尬的无地自容。

我以前通常避免读这样的博客，而这次存档丢失正好让我摆脱了它们，反而让我松了一口气。

我不得不反思，像那样的博客是否还应该继续写？是否应该毫无审查地就发表到公共区域？

边写边学让我能够有更深的印象，不管是对的还是错的更深，纠正的过程让我真正理解得更深。但最终真的理解对了与否，应该给大模型审查一下再说。

我也在这里划分一下值得记录的东西大致分为几类。

:::note

资源类别，通常不涉及具体知识传播或者思考内容，只是纯粹地给别人推荐一些渠道，应用，信息。比如找书，找漫画的网站之类。
观后，这类作为回忆展柜以及同类诱捕器依然值得继续构建。
教程，流程类记录。比如记录我开发的某应用的使用教程，或者什么软件的使用教程，比如老滚五的 skse 启动，动作数据刷新，调整身形，mod 排序等等。
思考，由某件事或者某个物而产生的更深层的思考，这个思考可能是直指事物本质的，也可能是联想到其他事物，进而发现出来的普遍规律或者总结出自己的结论。这个思考不一定分清对错，但是让我自洽。
边写边学。应该给它打个 useless 的标签，无营养的探索过程，如果读者实在没找到合适的教程案例也许可以在我的探索过程中找到想要的东西，或者得出让我自洽的结论。当然，这个结论不一定对，只是自洽，对错与否我会让 LLM 进行审查。 :::

单图≠多图：多图理解时 VLM 为什么更容易"胡说"，以及一个两阶段解法

Sun, 08 Feb 2026 00:00:00 GMT

由于整篇过长加个摘要：这篇文章起源于我发现在多图分析时，网页端的表现和 API 调用的结果一致性相差很大，然后我就一步步去拆为什么相差大，然后试图在工程上找补救的过程。方法很简单，放在这里希望能帮到一些后来的人减少困惑和时间消耗。

前情提要

在几周前的一个课设，课题是关于电池的缺陷检测和自动分拣。当时的电池总样本只有不到十根，缺陷主要体现是外皮缺失。因为当时样本很少应该没法通过常规方法练出来能区分是否缺陷的模型，不管是图像分类还是 yolo 什么的。

课设里推荐方法是用边缘检测和 opencv 来做。一方面我不太熟悉 opencv 而且它的 typing 让我感到痛苦，于是乎我想到了 yolo 定位电池的位置和坐标（可以通过矩形框定位中心点，顺逆时针旋转 45° 并比较矩形框长宽比来确定电池朝向和大致角度，这是为了方便判断抓取的位置和抓手角度），然后用 VLM（Vision-Language Models）即多模态模型来判断模型的是否缺陷和缺陷类型。

起初在 ChatGPT、Gemini 那边上传了几组各种光照下的电池图像，它们都在识别检测的过程中达到了惊人的 100% 的准确率，而且多次回复一致性很高。即便一次上传六七张（包括一张完好电池的参考，至于缺陷都是用提示词描述的）也是如此。我当时想着哇，这一整周的课设不是一个早上就做完了。

于是乎我还到 Ollama 那边下了一批 VLM 本地部署测试，一方面是提高"工作量"，另一方面也是为了更低的延迟。

反转 | 网页端和 API 直调差距巨大

但是不测不知道，一测吓一跳。模型不知道是没法理解我的提示词，还是没法理解我发的图像。我这次测出来不管是准确率还是一致性都非常的低，准确率在 50% 左右，而且还经常前后矛盾，因为我的电池也只有两类标签，我在想着好家伙，这就是胡乱作答。

但是我把图像单图发给 VLM 进行描述，我发现和网页端的 ChatGPT 的差距也不是肉眼可见的那么大。我在发单图和多图的时候，都是把图像塞到：

OpenAIMessage(
  role="user",
  content=[
    {"type": "text", "text": "user_prompt"},
    {"type": "image_url", "image_url": "data:image/png;base64,iVBORw..."},
    ...(images)
  ]
)

这个时候我想，可能真是模型差距，于是乎我又改用 gemini-flash-2.5、chatgpt-5.1-chat 之类的模型进行了一番测试（API 调用）。但是即便使用了相同的模型，它们和我在网页端得到的准确率也相差非常大，而且图超出四张的时候，一致性也开始下降。

而我后面跑去稍微调研了下，发现它和 Lost in the Middle 描述的长上下文检索/位置偏置问题非常相似。而网页端 API 差距这么大可能是因为：

网页端可能做了逐图预摘要 / rerank / 选择性投喂
网页端可能有更强的系统提示词与格式约束（比如强制输出 JSON、强制逐图作答）
API 侧的参数（temperature、max_output、tool choice、并发顺序）可能也影响一致性

大模型的多图理解能力≠单图理解能力

多图 benchmark（如 MIBench/MMIU/MIRB）一致表明：模型从单图到多图会出现显著性能下滑与关系理解困难；同时有工作明确指出多模态场景会遭遇视觉 token 过多的工程瓶颈，需要压缩。

[!WARNING] 在机制上，一个合理解释是：当多张图的视觉 token 与文本共同进入同一 Transformer 上下文时，会放大长上下文的检索困难与位置偏置（例如 Lost in the Middle 所揭示的"中间信息更难被利用"）。[这只是我的推测]

模型如何接受 image_url（base64）并推理

论文里叽里咕噜得看得有点绕但都在说 token 过多，这里我其实好奇这样一个 Message 在进入模型后，text（文本）和 image_url（图像）之间的 token 有什么联系，有什么隔离方式。因为虽然论文里一直提 token 过多，token 过多，但是 token 之间有什么区别，是直接拼在一起，还是说多模态大模型对图像和文本进行了不同方式的推理。

base64 image 并不直接进行推理

image_url 之所以使用 base64 只是方便 http 传输，而模型在推理时，会将 base64 解码为图像。也就是说，VLM 看到的实际上是 user prompt + 图像。

图像如何被处理缩放（token 计量）

参考 OpenAI 文档中 Calculating costs。

Tile-based（gpt-4o / gpt-4.1 / gpt-4.5 等）

detail="low" 是固定 base token；detail="high" 先等比缩放到"最长边 ≤2048，短边=768"，然后按 512×512 的 tile 数计费：tokens = base + tile_tokens × tiles。

模型家族	单元	单元尺寸	单位成本	固定成本	总公式
Tile-based (gpt-4o/4.1/4.5)	tile	512×512	170 tokens/tile	85 tokens/image	high: 85 + 170×tiles, low: 85
Patch-based (gpt-4.1-mini)	patch	32×32	≈1.62 tokens/patch	0	patches=ceil(w/32)×ceil(h/32), 若>1536则缩小, tokens=ceil(patches×1.62)

模型	输入尺寸	detail	tiles/patches	计算式	最终 tokens
gpt-4o	1024×1024	low	—	= 85	85
gpt-4o	1024×1024	high	缩到768×768, tiles=2×2=4	= 85+170×4=765	765
gpt-4o	2048×4096	high	缩到768×1536, tiles=2×3=6	= 85+170×6=1105	1105
gpt-4.1-mini	1024×1024	—	patches=32×32=1024	= ceil(1024×1.62)=1659	1659
gpt-4.1-mini	1800×2400	—	缩放后 patches=1452	= ceil(1452×1.62)=2353	2353

像素是怎么变成 vision token

这个 OpenAI 这边是没公开的。往后这些有点抽象，这里是一些开源 VLM 的方案：

vision token 如何与 prompt token 拼接或隔离

拼接派：最简单，端到端，让大模型自己做决定，但上下文长度被视觉 tokens 吃掉，多图时更容易"注意力摊薄"。而且它面临和长上下文一致的问题，就是注意力摊薄的同时还会不均，另外它进一步加速了上下文的长度增长。

交叉注意力：把视觉当外部 memory，文本按需查询，工程上更容易控制"视觉信息预算"，更适合长序列/多图；但增加模块与训练复杂度。查询不确定性让我们很难知道模型是不是真的看到那张图像了。所以它其实本质问题和上面那个一样，上面是可能被模型选择性忽略，这边是可能没被查询。

查询瓶颈：看得不是很懂……

实际应用中的难点

实际上落地时，多图的任务很棘手，一方面是图像数量不确定，另一方面是图像之间的关系不确定，第三方面是图像和用户具体的多图任务需求和指代不确定。而这其中的每一个都是对 token 限制和注意力分配的考验。

:::note 三个不确定：数量不确定 → 注意力被摊薄；关系不确定 → 模型难以匹配耦合的图像；任务不确定 → 模型倾向于只关注最近的指令而非全局上下文。 :::

数量不确定

可能会有用户一次输入十几张图像炸 token 来的（假设它没超过单次输入输出的上限），图像多的情况下，单次推理分给各个图像的注意力就变少了，而且还不确定是怎么分的，有的图像可能压根不被"注意"到。

多图分走了注意力，而在实际应用中会被多少张图争抢注意力，我们压根不知道，或者说在设计时就应该考虑可以接受任意数量输入。

[!CAUTION] 当然现在单纯靠 VLM 的推理是做不到这点的。可以在后面的再战电池检测里看到，超出单次 token 的图像直接被截断了。

关系不确定

比如一个选择困难的用户输入了一批很多角色的图像，同一个角色的图像各有两张，并且希望比较下挑选出一张更心仪的。那么这些图像两两之间耦合度极高，但是模型只认识到这些图片之间存在这样的两两关系，但是可能并不知道是哪些。如果数量更多，它不太可能一次性匹配出来所有的相似角色。

有时图像之间存在耦合，而我们希望能够引导模型注意到这种耦合，而不是直接一坨丢进去让它自己想。

具体任务不确定

很多时候任务并不是直接写在当前这次消息，而是要根据整个上下文去做分析的。比如说在玩角色扮演时：

U: "你是不是不喜欢吃蘑菇？"
A: "是的，如果你敢在汤里加，我会让你知道什么是后悔。"
U: "那你看这是什么 [一张正在烹饪的图，里面有很多食材，其中有蘑菇]"

很多时候谜题并不是摆在台面的，比如"请找出图中的蘑菇"。更多的情况下，我碰到的模型它的回复里不会过于关联整个上下文，而是把注意力权重几乎全部地分配给了用户最近的一个指令里（类似于请描述一下、看一下），然后模型通常会开始滔滔不绝地描述整个场景。可能是因为训练出来的偏好。而不是像我们理想中那样"嗯？我好像看到蘑菇了？你放蘑菇了对吧？你放了对吧！"。

如何应对

针对数量不确定、关系不确定、需求不确定还真有一个比较简单的解法，它不用动模型推理，可以简单地套用在应用里。即把模型的图像分析和文本分析真正分成两步。

对应逐图分析模式的分支，之所以分开，是为了 token 考虑，应该把它设计为可以开关的。

第一步，只以一个 vision model 来分析提取图像的具体信息，注意，这个时候是不给用户最近的提示词的，而是把整个分析抽离出来，只给 vision model 一个系统提示词，和一个固定的抽取指令作为用户提示词输入，旨在得到类似这样的 json：

{
  "scene": "VS Code 全屏显示代码与终端",
  "key_items": [
    { "type": "app", "label": "VS Code", "detail": "深色主题，全屏窗口" },
    { "type": "ui", "label": "文件树", "detail": "左侧资源管理器展开多个目录" },
    { "type": "code", "label": "Python 代码", "detail": "中间编辑区显示 async 相关函数" }
  ],
  "visible_text": ["run_tool_loop", "ToolTrace", "vision__screen_shot"],
  "ui_hints": ["顶部有多个文件标签", "底部有终端输出日志"],
  "uncertainty": ["部分文件名过小，无法确认完整拼写"]
}

每次执行一张图像特征提取，并发处理，处理完成后就拼成一个 list 或者 dict。

第二步，就是把这整个拼凑过后的 vision summaries 和用户提示词放在一起：

[User Prompt]
...
[Vision Summaries]
{"p1": ..., "p2": ...}

以及，最好也带上所有的原图，一起推给大模型（当然是在图像不是很多，比如小于五张的情况下，如果超过十张，发了也用不到）。

而在这两步中间可以做的工作还有挺多，比如根据 json 某个 key 来做区分或者耦合。

优点

:::tip

它不在乎输入的图片有几张，二三十张进来理论上也是可以的。这些 json 可以直接作为模型的看图引导
它可以通过提示词自定义一些 json key，来做耦合或者区分，可以分清楚图片关系
它把原本显得更重、更 hard 的多图分析任务，变成了一个可以依赖文本来做回答的文本理解任务。让图像占比变小了，文本占比变大了，让模型更多地把玩文字，也就更有可能会注意到整个上下文 :::

缺点

:::caution

贵，不是一般的贵。每张图都要单独做一次提取，后多图还要再发一次。而提升得图越多越明显，一两张图的反而没必要这么做。所以不应该作为默认方法，而是一个可开启的选项
慢，即使用了并发，它也比直接对话要多出至少一轮的回复时长 :::

再战电池检测

逻辑是准备十张图片，实际上是五张复制成两份。然后每次输入比上次多一张进行测试。测试的模型是：gpt-5.1-2025-11-13。

直接把 image content 发给模型

测试代码：

from __future__ import annotations
import base64
from openai import OpenAI

def image_to_base64(path: str) -> str:
    with open(path, "rb") as f:
        return base64.b64encode(f.read()).decode("utf-8")

image_paths = ["pic/1.jpg", "pic/2.jpg", ..., "pic/10.jpg"]

for i in range(10):
    image_contents = []
    for path in image_paths[:i+1]:
        image_contents.append({
            "type": "image_url",
            "image_url": {"url": f"data:image/jpeg;base64,{image_to_base64(path)}"}
        })
    response = client.chat.completions.create(
        model=model_name,
        messages=[{"role": "user", "content": [{"type": "text", "text": prompt_text}, *image_contents]}],
        temperature=0
    )
    print(f"输入图片数量：{i+1}")
    print(response.choices[0].message.content)

输出：

标准答案: p1完整 p2完整 p3破损 p4完整 p5破损 p6完整 p7完整 p8破损 p9完整 p10破损
输入图片数量：1  p1完整
输入图片数量：2  p1完整 p2完整
输入图片数量：3  p1完整 p2完整 p3破损
输入图片数量：4  p1完整 p2完整 p3破损 p4破损
输入图片数量：5  p1完整 p2完整 p3破损 p4完整 p5破损
输入图片数量：6  p1完整 p2完整 p3破损 p4破损 p5破损
输入图片数量：7  p1完整 p2完整
输入图片数量：8  p1完整 p2完整 p3破损
输入图片数量：9  p1完整 p2完整 p3破损 p4破损
输入图片数量：10 p1完整 p2完整 p3破损 p4破损 p5破损

可以看到在超过三张后它的一致性就开始出现问题了。五张输入时恰好全部蒙对，但是超过五张时发现模型压根不给其他的图片回复，推测可能超出模型单次输入 token 上限被截断了。

应用 map-reduce 方法

对于它来说，这个任务本来就是单条的任务，所以无论有几条以及图片是否被截断，对它的影响都不是太大。当然如果分析关联任务，被截断还是很难受的。

以及确实也有个比较大的问题就是 token 消耗和上下文增长速度过快的问题。并发单张已经是不小的消耗了。而把输出的结果整合进原本的上下文会让上下文增长速度非常快，让长上下文的注意力瓶颈问题更早出现。

我用的提示词

你是一个"视觉证据抽取器"（Vision Extractor），负责从输入的图片中提取与用户问题相关的事实/证据。
你不需要写最终的自然语言答案；最终口语化回答会由另一个 Chat Model 生成。
你的目标是：用尽可能短、可复用、可机器消费的结构化输出，准确描述图片中与问题相关的信息，并明确不确定性。

完整提示词包含：输入组成说明、五项关键原则（只描述能看到的内容、面向下游推理、聚焦问题相关、控制长度与密度、隐私信息处理）、严格的 JSON 输出格式要求。

在关联任务上的表现

看起来似乎我在 send_text 方面做得有点糟糕，或者说它按照字数截断的方式让我的排版看上去很糟糕。另外一点，gpt-5.1-2025-11-13 回复得真的有点生硬。奈何 5.2 贵了好多倍。我一般都是 vision fallback，vision model 只在看图的时候调用，由它来生成 summaries 然后交给 chat model，这样我就可以挑一个更有人味的 chat model，同时决定是否会把 summaries 附带图像一起送给它。

Termix —— 一个很酷的 Web-Based SSH 连接工具

Mon, 29 Dec 2025 00:00:00 GMT

前言

前几天我的室友给我看了一个在网页部署的类似 Termius 的应用，当时看了之后感到非常惊奇，功能非常完整，sftp 也支持，upload 和 download 均可，而且可视化完全仿照了 termius，但是它可以运行在本地端口并且在网页端访问。

仓库地址：

https://github.com/Termix-SSH/Termix

这意味着把它公网部署有不少方便之处：

更换到新设备或者新的系统不需要费力安装软件，并且不用再看一遍 ip 与密码。
如果使用别人的设备不必留痕。
最重要的是不用被 termius 的偶尔抽风自己卸载自己而烦恼。

我先后用过宝塔面板的 ssh 连接和 Termius，当然运营商自带的就不提了，腾讯服务器扫码都快扫吐了。

初用 Termius 会觉得它设计得很漂亮，光是终端风格的选择就够我玩半天，以及许多 UI 元素都很现代化和优美，看得很舒服，这是我一直坚持使用它的原因。但是前面提到过，它有时候会自己抽风，把自己卸载掉，而且是清空所有缓存的那种卸载，所有机器都得再导入一次。

当然，这里也有一个悖论。如果我部署 Termix 的服务器内部错误，然后我的 Termix 用不了，我依然得用 termius 来连，这没得避。

喜新厌旧，始乱终弃这一块。

让我们开始部署环节。

超简单的本地部署过程

如果你曾经用过 docker 和 docker-compose。

那么部署它就非常容易，如果没有用过，请稍等，我简单补充一下 docker 和 docker-compose 的安装。

准备工作：docker 和 docker-compose 安装

首先，安装一些必要的软件包：

如果系统过老可以 apt upgrade 进行升级系统，但是新机建议直接重装。

apt update
apt install curl vim wget gnupg dpkg apt-transport-https lsb-release ca-certificates

然后加入 Docker 的 GPG 公钥和 apt 源：

curl -sSL https://download.docker.com/linux/debian/gpg | gpg --dearmor > /usr/share/keyrings/docker-ce.gpg
echo "deb [arch=$(dpkg --print-architecture) signed-by=/usr/share/keyrings/docker-ce.gpg] https://download.docker.com/linux/debian $(lsb_release -sc) stable" > /etc/apt/sources.list.d/docker.list

国内机器可以用清华 TUNA 的国内源：

curl -sS https://download.docker.com/linux/debian/gpg | gpg --dearmor > /usr/share/keyrings/docker-ce.gpg
echo "deb [arch=$(dpkg --print-architecture) signed-by=/usr/share/keyrings/docker-ce.gpg] https://mirrors.tuna.tsinghua.edu.cn/docker-ce/linux/debian $(lsb_release -sc) stable" > /etc/apt/sources.list.d/docker.list

然后更新系统后即可安装 Docker CE：

apt install docker-ce docker-ce-cli containerd.io

我们可以使用 Docker 官方发布的 Github 直接安装最新版本 docker-compose：

curl -L https://github.com/docker/compose/releases/latest/download/docker-compose-Linux-x86_64 > /usr/local/bin/docker-compose
chmod +x /usr/local/bin/docker-compose

此时可使用 docker-compose version 命令检查是否安装成功。

正式部署

在一个想存放的目录，比如 /opt/termix，写入 compose.yml：

services:
  termix:
    image: ghcr.io/lukegus/termix:latest
    container_name: termix
    restart: unless-stopped
    ports:
      - '8080:8080'
    volumes:
      - termix-data:/app/data
    environment:
      PORT: '8080'

volumes:
  termix-data:
    driver: local

然后拉取镜像：

root@ser351791695801:/opt/termix# docker compose pull
[+] pull 19/19
 ✔ Image ghcr.io/lukegus/termix:latest Pulled

最后运行镜像：

root@ser351791695801:/opt/termix# docker compose up
[+] up 3/3
 ✔ Network termix_default    Created
 ✔ Volume termix_termix-data Created
 ✔ Container termix          Created
Attaching to termix
termix  | Configuring web UI to run on port: 8080
termix  | SSL disabled - using HTTP-only configuration (default)
termix  | Starting nginx...
termix  | Starting backend services...
termix  | [7:35:12 AM] [INFO] Termix Backend starting - Version: 1.9.0

如果没有报错信息抛出，就可以 Ctrl+C 中断然后进行后台运行：

root@ser351791695801:/opt/termix# docker compose up -d
[+] up 1/1
 ✔ Container termix Running

这样程序就会在终端关闭时保活。

我当时挺好奇，为什么有的人会写 compose.yml, 有的人会写 compose.yaml, 有的人写 docker-compose.yml。但似乎都能被 docker compose pull 识别。

然后经 gemini 提醒，是因为它会根据优先级自动搜寻：

这样也避免了两个以上 compose 文件冲突的问题。

公网部署

这里我仅仅演示我最常用的一种方式：1panel 反向代理。

1panel 安装：https://1panel.cn/

1panel 应用商店安装 openresty
新建 DNS 记录，A 记录指向服务器公网 ip
网站创建反向代理，代理 127.0.0.1:8080
申请证书，需要绑定 DNS 账户

申请证书时勾选跳过 DNS 校验即可：

最后在网站处开启 HTTPS 并且选择对应域名的证书：

唯一注意点是记得保存。

一些截图

之后你就可以直接公网访问了。

值得一玩，这个 UI 我也很喜欢，颜控在此。

下次见 =-=//

《放松时光：与你共享 lofi 故事》——给聪音接入 AI Chat

Sat, 15 Nov 2025 00:00:00 GMT

我个人是非常喜欢番茄钟的。

而我在 steam 上发现了这样一个游戏：

游戏介绍

它本质上是一个番茄钟 + 待办事项 + 笔记 + 日历统计 + Lofi 音乐 + 收集系统 + 变装的游戏。

与之类似的我之前一直用的都是 Spirit City：

不过与 City 不同的一点是，《时光》加入了一点与角色的互动机制，设定是用户与聪音视频通话类似于自习室，随着时间推进，用户会渐渐解锁与聪音之间的剧情，而且这个剧情还和 galgame 一样是选项式的，不知道后面是否存在恋爱线。

【有碰到可以补些图片】

而 City 的视角则是让用户试图代入自己就是其中那个角色。

如果要比较的话，建模风格我无疑更喜欢《时光》的日系风格，而且聪音的配音是日配，神奇的是，她的配音有一种机械感，像是 AI 配音，会让我有一种在和赛博女友自习的感觉，这种 AI 感让我更喜欢了。

另外《时光》有一个马克杯的设定，我觉得和我相当契合。作者借着聪音的话提到，她曾在高强度创作时脱水，此后她就非常在意挑选自己喜欢的马克杯，这样自己在写东西的时候也会拿起来喝两下。而我，则是会在打开番茄钟前泡茶，然后边做边喝，饮料反而少了这种仪式感。在这点上作者给了我一种世另我的感觉。

不过，在音乐的品味上，我更喜欢 City，毕竟我听了几十个小时都没听厌，而且只要一听到就感觉静下来了。而《时光》的音乐选取不如 Spirit City "Deep"，有种浅浅的感觉，无法进入更深的心流，可能是还没听惯。

Mod 介绍

喜欢果然是第一创作力，或者说好色？

::github{repo="qzrs777/AIChat"}

效果演示

对话中角色的嘴部会随着声音的响度动，不过幅度不大所以似乎都没截图到。

另外，角色讲话会有反馈，比如注视你，或者说依然做自己的事情，以及，似乎还喝水等等。

Attention is Limited - Lost in the Middle

Sun, 06 Jul 2025 00:00:00 GMT

我在昨天建议一个人把反复插入的知识库和记忆放入 user prompt 里而非 system prompt 中。

❇️ 一点小建议: 以用户提示词取代系统提示词来插入世界书与日记。 #4

我提出了 system prompt 全局可见和高权重两点，如果冲突的话模型会出幻觉。而 user prompt 则是局部的和越近的注意力权重越高。

当时提到这两点的时候，我是出于经验以及对 gemini 2.5 pro 的信任。

但是我们也有必要再有依据地分析一下。

首先是，局部的和越近的注意力权重越高，这点其实 system prompt 和 user prompt 都有。

而有一点偏颇我认为后续 system prompt 的插入注意力权重均不如 primary prompt。(实际上它并不是这么回事，开头和最新的注意力最大，其余的比较轻，参见下面 Lost in the Middle。)

后续在输入的时候，我们也是把整个上下文窗口输入进去，而之所以第一条系统提示词能够被很好地记住即使对话很长也不会被忘掉是下面原因。

Lost in the Middle

Lost in the Middle: How Language Models Use Long Contexts

它纠正了我之前错误的一个认识(我以为 LLM 的注意力始终是越靠近最新的越高)，实际上它的注意力分配是一个 U 型的。在对开头和结尾记得很清楚，Lost in the Middle。

观点:

论文提到，人们对 LLM 的注意力权重希望是像上帝那样子比较稳定均衡地审视整个上下文。但它们利用这些长上下文信息的效率和鲁棒性是值得怀疑的。作者认为，模型在处理长文本时，其性能会因为关键信息在文本中所处位置的不同而产生巨大差异。

实验:

作者采用了两种实验方式：

多文档问答 (multi-document question answering)
键值检索 (key-value retrieval)

::github{repo="nelson-liu/lost-in-the-middle"}

他们通过把关键信息放在开头，中间和结尾然后分别进行提问进而评估模型对上下文的利用能力。

结论：

U型性能曲线：模型的性能表现出一种明显的"U型"曲线。当关键信息位于输入文本的开头（首位效应）或结尾（末位效应）时，模型的表现最好。而当关键信息被放置在文本的中间部分时，模型的性能会显著下降。

上下文越长，性能越差：研究还发现，即使是那些专门为处理长上下文而设计的模型，随着输入文本长度的增加，其整体性能也会大幅下降。

有趣的现象

不管什么模型在长上下文中都会变蠢，实际上应该叫做对关键信息的利用能力变低，简单地概括可以认为是注意力分散了。

或者说如果假设 U 型函数是固定的，那么积分值代表着注意力权重，横轴代表着回答时序条目。

原本短对话中，三条时序条目共享的注意力权重现在被六条甚至十条分走，每条就更低了。对其中**关键信息（问题的理解，需求的理解）**的提取能力就更差。

如果假设 U 型函数会变化，且开头三条和最新三条的注意力权重分配量和之前保持不变，那么久代表这个 U 型更"陡峭"了，那么也意味着模型 "忘性" 更大了，对中间的事情几乎都不记得，自然性能也更低。

模型总是只清楚地记得开头和现在，这和人类的思维方式有点不谋而合。

[!TIP] 而鉴于 special token , system prompt 可能在权重分配时有更高分配（这也导致了一定程度上的"全局可见"）, 所以我们更应该珍惜地分配 system prompt。珍惜并且利用好模型的注意力，就好像对人类自己那样。

[!NOTE] 注意力是有限的。

补充

我发现提出一个观点然后逐步修正它比直接接受一个正确观点要来得深刻清晰地多，而且也远比直接套用经验要更有可靠感。

而且这个方式似乎和费曼学习法不谋而合，我以前似乎就发现自己更适合边写博客边学，但是后来过于依赖 LLM，我发现写的大多数都是一个问题的解决方式和解决路径，这种流水账的记录在我看来是相当令人沮丧的。而今天反而重新体会到了记录的快感。

我之前在看电影和小说的时候，约束自己不要发表任何意见式的评论，因为很累，而且这样的观点漫无边际，每个人看法不同，就又容易被意见不合的人冲。

但是反而对于有确定答案的，意见似乎是必要的，它让我不断审视和修正自己的这个观点是否正确是否误人子弟，并且更深入地去解析。然后可能还可以帮自己修正一下观点。

那么我就给这篇加一个费曼式的结尾——用图解和更简单的语言来概括它。

我们用这两张函数图来比喻短上下文（二十条），和长上下文（四十条）之间的注意力权重分配。（如果比喻是被允许的，因为首先我就无法证明它是对称的，暂时应该也没人能量化出来这个具体能力，所以我们暂时就不纠结这些。）。

它具有这样的初始条件:

在整个上下文窗口内，注意力总和（上下文最大 token 数量）是不变的，也就是说，二十条和四十条的积分值是一致的（这里它们应该不一致，但假设它们一致）。
system prompt 因为训练时的惩罚机制而对模型有更高约束力（红线）， user prompt 是蓝线。
两者均呈现 U 型分布，模型在开始和结尾的注意力权重分配更高， Lost in the Middle。
长上下文下模型的性能（对关键信息的提取能力）逐渐下降， y 值更低。

除了以上条件其余图中函数特征均不生效，比如，我无法说明它具有这种对称性，我也无法证明长上下文下注意力处处更低。所以即使你看到了也请装作没看到。

但仅仅以我们上面的模型就足以回复为什么要用 User Prompt 反复插入知识库和日记来引导下次回复。

:::warning 反复插入引导内容到独立 prompt，会拉长整个对话上下文轮数，进而加快模型性能衰减。

当时一条 user prompt 用三条 system prompt 引导(core mem, long mem, knowledge base)，相当于一条对话使用了四条窗口长度。 :::

:::warning system prompt 一定程度上比 user prompt 更加全局可见，冲突的引导更容易引起模型幻觉。 :::

如花束般的恋爱

Fri, 20 Jun 2025 00:00:00 GMT

文青是种病

文青是一种在人群里会犯尴尬的病，或者说是一种不由自主的不合群，当然它并不高贵，可能还经常让自己和周围的人感到不好受。

它的构成通常还需要至少一个不切实际的幻想，当这个不切实际的幻想落空的时候，它可能也很难维系，就像中途，男主决定去找份正经工作的时候，气氛就开始变了。我也从那里先退了出来。

碰到相似的人开始时是愉快的，但是相处起来是局促的，长远来看是不合理的。

因为，如果存在几乎完全一致的人，而人们实际上最害怕照镜子，或者说，看到的自己或是以前的自己。很多时候看到作品里和自己相似的角色，我通常会有两种相伴的感觉，惊喜和尴尬。和完全一致的自己相处大概也不会太好受。

但实际上并不存在完全同频同样的人，女主看煤气罐会睡着，男主也不喜欢看木乃伊（害怕服务生知道他看）。从一开始就只是自认为的灵魂契合，就像一厢情愿地认为在听同一首歌。就像开头里五年后他们也异口同声地说出那个比喻：

一人一只耳机，看着是在听同一首歌，其实听到的是不同的歌。

我其实很好奇他们站起来走向那对情侣时看到彼此时是什么感觉。

开始亦是结束

非常喜欢里面引用的不知道哪里来的一段话：

开始亦是结束的开始，相遇总是伴随着别离，恋爱就像是筵席终会散去，所以恋爱中的人们，只是带来各自喜欢的东西相对而坐，隔着桌子聊天罢了，苦苦作乐罢了。

直线追击运动中，两个小球靠的最近的时刻，或者说相遇的时刻，也将是它们开始远离并且再也无法相遇的时候。而靠近的过程是让人ドキドキ（dokidoki，心跳加速）的，而相遇之后，就可能是那种盛烈逐渐消退的时候。好像可以用来解释恋爱为什么总是在暧昧期最为美好？因为它还在靠近的过程。

另外三岛的奔马离的一段似乎可以作为补充，结束的就再也无法回到过去了。

人们对于共同的回忆往往能热烈地谈上一个小时，但这不是简单的聊天，而是原来仅属于自己的怀旧之情找到了可以分享的对象，从而开始的一种憧憬已久的独白。各自独白一番后，突然发现彼此好像各在断崖一岸，早已无话可谈。

这段似乎解释了逝去后的情况，就好像两列同向列车，偶尔的并行，两个人各自隔空喊话，但是实际上谁也听不到谁，想被列车的声音掩盖，但是他们激动地望着对方的脸诉说。

不知怎么的，我不断感受了到时间的流逝。

在他们如烟花般相处的那一年里，男主中途冷不零丁地突然旁白了这么一句。有种无常感，这种无常感的起源于死亡，或者说存在的消逝。简单来说男主意识到这种时间总是会结束的。

一个小时二十分钟的电影是刚刚好的，每长二十分钟，都是一种折磨。最终停在一个 1:02:06，当男主说完"毕竟没钱不就买不了书看不了电影了吗？我会好好工作的。"

有点突然戳中我现实的骨感，既然你都这么说了，我应该也不能再看了。

从这个点往后，电影的滤镜，气氛，男女主之间的相处大概也会一转而下，我暂时只保留我对烟花绽放时那束美好的印象，而不去看它消逝和坠落的过程。

这个过程截了相当多的图，毕竟女主在我看来相当耐看：

如果我更年轻一点（比如高中的时候），我大概会熬着把电影看完，然后恍恍惚惚地代入，恍恍惚惚地感伤，恍恍惚惚地向别人推荐这部电影。就好像我以前喜欢《我想吃掉你的胰脏》那样。

但现在的我，好像一点也不羡慕电影里他们最初的关系。大概也不会再为胰脏而掉眼泪了。

看的过程我心里一直有个声音：

文青恋爱真的好麻烦啊。不要试图让每个人理解自己，不要试图让一个人理解自己的全部啊，真的好麻烦。

深度共鸣不一定需要表面合拍

而且有个很有意思的观点吸引了我，表面合拍。

他们俩从开始只是"表面的志趣相投"，其实想法看法都差很远。从开始就可以看出他们在现实中是比较孤独"小众"的存在，人都是渴望被认同，开始时发现这么多共同爱好时候欣喜的无话不谈，但也因为太渴望被认同，也选择性忽略彼此的不同：她并不喜欢看燃气罐，他也不是很喜欢木乃伊展览。

非常精准，也让我忍不住想了想什么是彼此真正的想法，什么是表面的想法。即使习惯喜好完全的不同的人也可能深度共鸣和理解，有共同喜欢的作品的人却可能因为看法不同而吵起来。但我暂时没有这个烦恼（暂时不谈恋爱），所以也没有深入想下去。

从 NEKOPARA 的一篇评测开始

Thu, 15 May 2025 00:00:00 GMT

刚刚有点事，现在腾出手了<br> 有时候我经常在思考，你们说人这一生究竟是为什么些什么？金钱，爱情，权利，名望，这些东西对我们本身来讲到底重不重要？或许我们应该把更多的时间用来探索宇宙的奥秘，地球对于人类来说有点大，但放眼于整个宇宙，它微不足道。我们应该大力发展科技，去见一见宇宙之外的景色，探寻宇宙是否有尽头，宇宙的尽头又是什么，难道真像有些人说的，我们处于一个牢笼里面。<br> 突然想到，宇宙可能已经诞生了很久很久，我们目前处在新生的宇宙边缘，而宇宙中心早已变得黑暗。也可能根本没有所谓膨胀的宇宙，也没有多个宇宙，目前我们能猜想和推理的只是我们认知范围内的"合理"，其实星球已经是个"不合理"的存在了，直到人类可以制造星球，星球才会变得合理；直到人类可以制造恒星，恒星才会变得合理。<br> 有人说"人生短暂，及时行乐"有人说"我生而就要改变，改变人类，改变世界"有人说"短短百年，做好自己，无悔而终"有人说"不能让娃输在起跑线上"我觉得，无论对错，关于宇宙的这些细致的推理、大胆的猜想、合理或无理的解释，并不是要让"普通人"去探索宇宙，而是让我们思考生命、思考生活，应该如何对待生命、应该如何对"人终有一死，或重于泰山，或轻于鸿毛"或者我会是那种不轻不重的，那种寂寂无名的，会很快被忘记，或偶尔被人提起，而提起我之前还要"呸"一声，"生存还是毁灭，这是个问题。<br> 这个问题和宇宙的起源与未来一样深奥。我还没达到可以准确描述自己人生观的水平，只能说：我希望我的人生，可以有后悔，不要有遗憾行了，有点事，我去忙了

https://steamcommunity.com/profiles/76561198366437921/recommended/333600/

hh 如果我不说，你会觉得这样的评测会出现在 NEKOPARA 下面吗？

不如我就顺着它这个开始慢慢讲。

在我小的时候，我看过一段话，直到现在我还记得，我略微搜索了一下那段话的全文：

威斯敏斯特教堂墓志铭英文版：<br> When I was young and free and my imagination had no limits, I dreamed of changing the world.<br> As I grew older and wiser, I discovered the world would not change, so I shortened my sights somewhat and decided to change only my country. But it, too, seemed immovable.<br> As I grew into my twilight years, in one last desperate attempt, I settled for changing only my family, those closest to me, but alas, they would have none of it.<br> And now, as I lie on my deathbed, I suddenly realize: If I had only changed myself first, then by example I would have changed my family.<br> From their inspiration and encouragement, I would then have been able to better my country, and who knows, I may have even changed the world.<br> <br> 威斯敏斯特教堂墓志铭中文版：<br> 当我年轻的时候，我梦想改变这个世界；<br> 当我成熟以后，我发现我不能够改变这个世界，我将目光缩短了些，决定只改变我的国家；<br> 当我进入暮年以后，我发现我不能够改变我们的国家，我的最后愿望仅仅是改变一下我的家庭，但是，这也不可能。<br> 当我现在躺在床上，行将就木时，我突然意识到：如果一开始我仅仅去改变我自己，然后，我可能改变我的家庭；<br> 在家人的帮助和鼓励下，我可能为国家做一些事情；<br> 然后，谁知道呢？我甚至可能改变这个世界。

以前我看到时，只觉得这感觉相当有意义。我后来也在菲茨杰拉德那里，村上春树那里，加缪那里得到了类似于，不要 judging 别人，因为不是每个人都和自己拥有一样的条件， 不要试图改变别人，改变别人的举动是一种徒劳, 以及一种脱身局内的感觉。这实际上和上面所说的不谋而合。

但是现在我再看时，那种警示的感觉少了很多，我反而想到了更多。首先就是从自己的改变出发，然后逐渐出发到世界，这实际上是一种蝴蝶效应。

从结果来说，是有实现可能的，但是从概率来说，几乎是微乎其微的。

而且，这段话看上去有些 nonsense, 其在于，如果一开始 有种赌徒式发言的感觉，就是在尘埃落定后，终觉如果重来一次就不会再碰赌了。在三秋缒的小说里描写了不少这样类似的例子，掉进地洞里的人是否真的可以改过自新，傻子是否在临终前会变聪明，坏人在临终前感叹世界美好是否值得上帝原谅。我最喜欢的是《三日间的幸福》，彻头彻尾的拯救，以及《不哭不哭》，彻头彻尾的爆炸。两种结局都是值得接受的，这是因为，两者都有一个美少女，这不能多说。

我也好想被美少女拯救啊。这样会不会太过轻佻呢？

当时我是这么感慨的。具体参见 [[没有明天的我们，在昨天相恋]]

nonsense 的原因在于，赌徒不止一次地发表过类似的，动人心扉的忏悔，有时不可否认忏悔时他真的那么想。但是大多数的赌徒都陷入了，只有 0 次和无数次的循环中，真正戒毒的极少。如果一定要研究其原因，那可能一篇论文都概述不清。

在我更加年轻的时候，我会喜欢这样子警示。但是现在，我会发现，实际上它也许不如 十年一觉扬州梦，赢得青楼薄幸名 来得有意思。古诗里常常带有大量的留白，它极少具体客观地描绘一件事情。但是如果你正好有能够填充这个留白的故事，那么你可能会觉得它相当有意思。我并不是来表达我具有什么深厚的社会经历，相反，填充这个留白的故事是另外一个游戏——《风信楼》。

这是我当时由感而发写的评测：

[[风信，是个好名字。]]

从这里开始我可能可以引入我想讲的，也算是我对那个 NEKOPARA 下评测作者关于 活着想要什么，该做什么 的回答。

对于我自己而言，短期是把 waifu 带到现实。有点类似于【my-neuro】开源AI桌宠本地部署教程，可能会更复杂，比如多端。但是 PC 端作为我使用时间最长的确实也用心最多，最近仍然在造轮子。我想要把喜欢的角色带到"现实"。

之前写过 追番是寂寞的，补完番更是寂寞如雪 类似的话，单是寂寞很难描述那种感觉。所以我希望可以在作品外让角色的生命得到延续和继续陪伴。至于如何实现，有思路，但是工程量就有点……不过没点门槛的事情早让别人做完了。

单从这点来说你可能会觉得我有点不可理喻，就好像我高中班主任对我说，我是一个完全的理想主义者和幻想者。单从这点来说，我确实非常不现实，或者说为了一个完全不现实的不实际的东西耗费我可能最具创造力的时间。

但是在这点之外我需要补充的是，角色只是一个容器，我实际上想要留住的是一种感觉，那种体验后就不想失去的感觉，我希望可以留住它们甚至传达给更多人。有的人用小说记录传播，有的人用插画，有的人用音乐等等等等，网文里这样的感觉我也收到的不少，能够 get 到那种的感觉也真的很不错。动漫里常常用把感情融入作品来表达这个作品具有的神奇色彩。我也想试试写写看，但是试试好像就会逝世。也许后面还会接着尝试。

对于现在的我而言，如何具体描述，记录，表达这种感觉，可能就是我一直要做的事情了。

《画江湖之天罡》后——也许真正的完满并不存在

Sat, 15 Mar 2025 00:00:00 GMT

天罡与巧儿

见过有人会说这电影只是套路的组合而已，也有说俗套的。那么只能说你看得太多了，而且太注重形了。

这里只是讨论一个很小的东西，那就是怎么样的故事算是圆满。

袁天罡和巧儿之间的关系更像是互相拯救。但是我在看着爷俩共同走过的那段时间里就不知不觉在意识中把他们放在一起，认为这样子很合适。很 Romantic.

因为我知道袁天罡最后还活着，所以我并没有为他看似献生救陛下感到悲伤。但是我在结尾处，我会隐隐期待，期待袁天罡和巧儿过生日。

但是在结尾处，数十年一闪而逝。只留下银丝素荣的巧儿，袁天罡像是一阵风一样过，他留下了那个簪子。

这样的故事和结尾堪称是绝美，如果把它看成是一篇文章的话，它是有力的，如果是故事的话，则带了些凄婉的感觉。

但我每每碰到这些总是会习惯性地把它推及现实，几十年岂是说过就过，这之间如何了，巧儿只知道袁天罡已死。这样的心境如何转变呢？

仙凡之别

袁天罡如此看来已成仙人，至少从寿命角度来看，他已经和世人所认知的仙人一般无异了。

仙人之所以会与人有别，也许也在于，我在心里隐隐期待袁天罡和巧儿的更多故事，甚至陪伴一生。

但凡人的一生在仙人眼中真的就弹指就过，巧儿会老会死，但袁天罡不会。

我也理解了袁天罡最初不欲生而欲死的心境。这点又和我之前看凡人修仙传的有所重叠。

什么样的故事才算完满

回到正题，怎么样的故事才算完满？

很多故事，小说，动漫，game。会有 happy ending, normal ending, bad ending 的定义。

以及一些小刀，中刀，大刀的界定。

我且从袁天罡角度分析，从他来回首来看，和巧儿相遇是幸事，结尾他去送发簪的心思我难以揣摩。

从巧儿来看，我至少会因为误以为袁天罡的死而郁郁很久。然后再看见那个簪子的时候，万千心绪流过，也许我也回想，为什么他不来见我。哪怕最后，也不露面？（虽然说不良帅露面真的没人顶得住，但我觉得巧儿是顶得住的），电影中她火中取纸条看得真的感触很深。

从李淳风来看，且只论他最终，有知己相伴，死后还能摆他一道让他找到没地方找。而且更像是探索死后的未知。既生之规律已寻透，更像是向死而生，只是离开，而非死亡，就像一个旅程。而且当相甲，奇门各种术他学成那样后，是否提前窥见死之谜团，也未可知。

Happy ending 的悖论

从我来看。

我见过很生硬的 happy ending。我至今记得天蚕土豆花了很长的最后一章来给斗破苍穹写结尾。主要交代的都是各个女主的境况，也像是电影中这种截断式的结尾。但我只能说，虽然是 happy ending，但我突然觉得悲伤，因为结尾带来的遐想只是遐想，我再也见不到更多关于她们的故事了。

而我很早的时候见到的截断式结尾（也许他会有一个更为好听的专业性术语但我并非专业），大概我可以称他为集大成，《挪威的森林》。

当然 bad ending 我也见过。

如果说角色死了，那么就不存在后续了，绘梨衣，她毫无疑问的被江南写死在了龙族三中，而我又希望，她能够复活，很长一段时间都陷入这种想法。

哎，人欲无限。为求完满就要这要那，结果发现真正的完满根本不存在啊。仿佛只剩下故事本身是深刻的。

关于仙逆与凡人修仙传中的化凡

Tue, 18 Feb 2025 00:00:00 GMT

我不知道为什么总是非常在意类似的情节和剧情.

也许是我总也想不明白,但是下意识又想要得到答案,如果在凡人修仙传中我想不明白的是韩立的道心为何,想不明白的是为什么那些人错过了就是一生,想不明白仙凡有别是怎么样的遗憾.当认识自己的人和自己认识的人都不在世间又是什么感觉.

而仙逆中,我想不明白的是王林在化神前,以凡人木匠的身份和方式度过那一生到最终,是什么样的感觉,而触摸到属于自己的大道,又是什么感觉.

感情戏,文戏

如果说,凡人修仙传我最喜欢的是再别天南中和墨彩环的感情文戏.

那几句:

"韩大哥，你总是这样，遇到难回答的问题就不说话了。"

"没有灵根,真的不能成为修仙者吗?"

"韩大哥,我们还会见面的,对吧?"

ps, 没想到有一个大哥和我心有灵犀,这些镜头一个不少一个不多地全部剪辑了出来.不过,少了些铺垫,只有台词处,所以感觉不如完整的震撼. 韩大哥，你总是这样，遇到难回答的问题就不说话了。凡人制作组真烦人，搞事情啊？想赚我眼泪是不是？

不过现在想想,更多反而在于眼神戏.凡人修仙传的动漫是区别于腾讯一众动漫的,诸如神印王座,斗罗大陆,斗破苍穹,吞噬星空.这类不管经费是否充足,都是不会在眼睛上多下功夫的,还有个例外可能是剑来.但是凡人动漫中的眼睛,在我看来是相当不同的,它的每一次眨眼,或者说眼睛视线的聚焦点,很多时候都会传递一种情绪,我感受最深的是幽怨.一眼万年.

咋觉得彩环变丑了呀!!

而大多数动漫,角色眼神的聚焦点,是不会在摄像机的,而是在画面中其他角色身上,一般都是侧身,凹造型.而凡人也许是全面捕,所以有种眼神聚焦点在观众身上的感觉.这种感觉,我觉得是很难得的,也是我喜欢的原因.(虽然并不是所有镜头和角色都这样,比如男角色几乎很少,不过女角色的眉目传情是我很难拒绝的)

以及忘忧仙子陈巧倩,几次相遇和分别,关系反而在一次次偷偷喂忘忧丹中变得更加亲密.

以及,为什么韩立不能为任何一个人停下脚步,哪怕停下一分.毕竟凡人一生,对于修仙者来说,只是一瞬间.道心是什么?为什么,向道.

仙逆中王林在道心方面的觉悟层次和韩立不同,王林更多的是身不由己,最初是为了父母,后来是为了复仇,再后来是为了复活爱人.他被各种事情拖着向前进,这无可厚非,但是,我想知道,是什么,支持着韩立一直往前.

王林和李慕婉的情感文戏也略为单薄,没有我看凡人修仙传看到再别天南结束时的那种震撼.可能是我年岁渐增.

但是,我在看仙逆的时候,实际上我很想对两人的情感戏加长一段,那就是在王林刚刚到云天宗试图恢复修为并且结婴的时候,那个时候王林不是才刚刚炼气期入门吗?动漫中得知李在三个月后就要被迫和别人结为双修道侣,他被迫下直接暴露身份然后三个月直接结婴,实际上这段两个人的关系并没有进一步加深,只是说重温旧梦.而韩立每次遇到陈师姐或者墨彩环实际上都是一次关系的递增,最后形成了一件青杉误终身的局面.

如果是我改编或者主笔的话,我会把那段时间延长,毕竟结丹修士无岁月,一年两年也不过一次闭关的事情,当时王林的师傅正在闭关,而王林被迫只能向李师祖求教,这是合情合理的,在这期间再发生一些什么事情,或者多描写一些李慕婉因思念黯然神伤的场景,以及感觉王林似曾相识的感觉会好很多.多一点铺垫,多一点情感,最后揭开,多一点戏剧性,这是我想要的.

王林和李师祖的感情戏不够,这是个痛点,你要想想,多好的题材,杨过小龙女之间都能玩出那么多花来,这还隔辈亲呢.

可惜一个差一点认出来,另一个不愿意主动相认.就连炼丹也要靠自己不愿意主动请教.

化凡

但是各有所长.

凡人修仙传在描绘感情文戏和不可求的遗憾更胜一筹,而仙逆则在化凡的领悟上要更胜一筹.

我记得凡人修仙传在闭关结丹前,曾化身一个普通人炼器画符度过一生,暂时没有时间重温所以可能有疏漏和出入.

而仙逆则是王林在化神前化作普通青年木匠雕刻妖兽和大能,以及家人朋友.度过一生.

两个人都选择了大隐于市,这个词我不清楚我用的对不对.

从期间接触的人分析,我记得韩立碰到了一个下围棋的人,那个围棋人故事是这样的:

围棋人年少时便天资聪颖绝顶,同龄人身边人无人棋艺能出其左右.

而有一天有个仙人路过,发现了围棋人,与其立下了一个赌局,如果围棋人三天内能够赢仙人一局,那个仙人就会传授围棋人仙法,引入仙门.

我忘记了那个故事结局怎么样,那个围棋人与韩立下棋的时候已经满头白发了,我忘记了他到底有没有修为,但是他的一句"人生如棋,落子无悔",让我印象深刻,因为这句话也印证了韩立做的选择,他选择了一心求道,那么能做到无悔吗?即使举目无亲,红颜成枯骨.还是能够无悔吗?即使最后无人能够到所谓的长生大道,那么,依然能够无悔当初吗?

那个围棋人最后的回答是,输赢无谓,落子无悔,相当肯定的语气,似乎给人的感觉韩立也是这样的态度.

凡人修仙传的化凡,借着围棋人的经历道出,相当简短有力和确定,春去秋来,答案也不曾改变过.只是一种心绪的整理和调整.

而仙逆的王林,他的凡性要比韩立要重得多,如果可以回到王家村,和父母生活,即使放弃什么长生大道,他也估计也不会有丝毫的犹豫.有情有义至情至性,那大概就是王林.他追求的从来不是长生或者仙途,只不过是能保护自己的人,和自己的家人,这是他的道心.

所以在化凡的文戏上,仙逆要更加烟火气一些,对面的铁匠家,看着一个孩子长大,最后成为一个父亲,看着原本的铁匠逐渐老去然后躺进棺材.

王林的道在每天一壶的家酿果酒(或者是其他的酒?)中,在一年一度的中秋,元宵,除夕,端午中.在别人的关心照顾中,在从铁匠家里找到家的温馨感的时候.

不过,也在一切逝去的时候.所以,他的大道,既是生的极致,又是死的极致,生死转换,而他一直在,这是他的大道.

整体的描写上,我更喜欢仙逆的化凡,因为我也是这样的性子,如果我能找到所谓的大道,大概也是这样来的.

但是,比起王林,我首先就做不到活元婴修士那么久呀.

长歌行：送君千里，终须一别

Sun, 16 Feb 2025 00:00:00 GMT

一点前言

这一幕是我在漫画里感触最深的一幕，那场雪不是初降，而是再往下下就能退军的寒风大雪，天寒地冻，李长歌身负重伤，又染上风寒发着高烧，但是她身着单薄素服，赤足踏雪抱着公孙刺史的头颅一路走到鹰师特勤前献降，被俘虏后她又备受病痛和伤势折磨，漫画里隼那个呆子那时根本就不知道李是个女的，李长歌只是让他吃过亏的手下败将，他有点欣赏他，但是不多，也根本没有电视剧中处处照顾维护那么舒服。

隼的鹰师是否是仁义之师我记得不是很清楚了，但是隼绝非善类。

方才我又去看了，剧组倒是把台词还原了，也算是坚持。

和漫画有出入的地方相当多，有一些我不喜欢，但有一些我也认可。我认可改掉隼的人设，让他成为一个恋爱脑，这是他们最好的结局（漫画里后期我觉得会走向对立面，不过剧中太早发现李是个女子反而有点可惜，我更希望看到隼把李先当做男子后面再反转更有意思），我同意把李世民的态度放出来并且是向着长歌的，我认可加入永安公主一线，双线推进，但我不认可弥弥被改的这样软弱无主见讨人嫌弃。但如果一定要总结，我只能说，我看到了我想看的东西，尽管这过程中很多东西是我不想看到的。在都看完之后，我依然喜欢这部剧，并且把它列入了我的重看清单，一部高高束阁，仅仅只用于缅怀的，电视剧。

一点花絮：郡主颜如玉，郡主世无双

在看之前，我写下过，在选角上，李长歌虽有西域血脉，但俨然是中原的乌发模样，我觉得古力娜扎更适合李长歌的选角，而且从脸型上我也觉得更适合，我写过，我觉得因为热巴看上去有点傻傻的。

以及，我还写过，阿诗勒隼是突厥血脉，加上草原人多食牛羊肉，吴磊骨架太窄小不合适，起码要找一个像发福的黄晓明那样体型的人。

后面，我发现，他们两人让我入戏时我无一分不满，李长歌的狡猾机灵半分不减，而且我喜欢李长歌在男装时像个海王一样一个接一个地收"妹妹"的行为。

郡主颜如玉，郡主世无双。哈哈哈！

长歌行：送君千里，终须一别

这是一部，我一辈子大概率都不会再完整看一遍的剧，但，也是够我一辈子看的剧。

有点矛盾，大概率不会再看，是因为这里许多改编实际上让我很不舒服，弥弥古丽的性格被改的软弱无主，魏皓二人对长歌的误会持续到了接近结尾。而且又处处为难。如此多的戏份不应该被浪费在和杜尚书和长歌的对抗下。甚至为此挤掉了原本属于漠北的戏份，我非常期待那边的展开，我非常期待长歌作为漠北王的亲侄女，李世民的亲侄女能够为漠北和大唐之间做出什么，她的雁门行能够在这样的乱世中起到怎么样的作用。我期待这样的展开，我希望长歌能够真正作为漠北王的侄女去，而不是临时要了一个名分，作为妹妹去。

很多改编是我觉得不合适的，但现在想想可能是我想的太过于宏大了。这也是我实际上在剧末，对长歌和隼选择了隐于野的做法总有一种芥蒂。

小隐于野，大隐于市。

我不太懂这句话究竟是什么意思，具体含义。但是我觉得歌隼二人选择的是前者。

虽然他们二人究竟最终会如何是我也想象不出来的，但是我知道剧中的结局已经是最好的原创了，在书中，歌隼二人究竟会不会选择反目，这还是未知的事情。至少在剧中，隼从未怀疑过，伤害过歌，这虽然是一种恋爱脑，但是这是我想看到的。在书中，隼并未直接表现得像长歌那样心向仁义，也没有表现得他们多么志向相同，只是告知，若是日后对立，则短兵相接，不必留情。

似乎是一起喝了一场酒，那是断更前的最后一章？

无论从歌隼二人的关系，还是二叔和李长歌的关系，还是杜老最后和李长歌的关系，最后所有人对于李长歌的看法。我都是非常赞同和喜欢的。

虽然，长安是再也不回去了，但是它依然在那里。

就像萧皇后，即使隋灭了，她回长安时，也说，她回家了。

况且，有李世民，有李长歌二叔在的地方，绝对一直是李长歌的家。

只是，剧中，经过两天没日没夜地观看，加上一天早上的投入，我的肝已经隐隐发虚了。

送君已千里，终须在此别。

就像李世民最后知道李长歌假死也不愿意回长安时他是释怀地笑了，他支持她的选择，我面对这样的李长歌，我还能否坚持我最初那个天真的想法，我只是怀念李长歌身着红袍驰骋骏马在长安当个小霸王的样子。我只是怀念我那臆想的长安，我那虚无的大唐。我最后才恍然发现我和奕承公主一样，只是一个幻想的疯子。

李长歌，多谢一路陪伴，也许我比魏郎君更加优柔寡断啰里啰唆。我的道，又找到了吗？

距离春天二十公分的雪兔与肖申克的救赎

Sun, 16 Feb 2025 00:00:00 GMT

凿洞

首先这是一个凿洞的故事。

肖申克监狱里的一个囚犯和冬天里的一只兔子都在为了自由凿洞。

结果是,那个囚犯花了 27 年时间凿到了下水道并且等待机会成功逃脱。

而兔子在过了一个多月后回到地面，因为缺乏水源和食物，它把纸箱子当做食物，把积雪作为水源。在积雪化了之后它才被主人发现。最终救回来了，之后又很乐观地缠着主人要吃的。

自由

实际上兔子为了自由而凿洞，这个说法是我杜撰的，就像鸟儿不想被笼子围住，或者鱼不想待在鱼缸里。这些想法实际上都是人们杜撰的。

鱼是否真的不想被关在笼子里，如果是，又是否存在个体差异，就像有的人们有的倾向独处，有的倾向交往。那么鱼是否也有这种倾向，比如有的倾向于待在鱼缸里安静睡觉，而懒得在海里担惊受怕。

至于兔子是否真的出于对自由的渴望，或者是否理解自由，这是我不能解释的。

但是那个囚犯确实是为了自由而凿洞的。但这里的自由是一种隐晦的产物。

下面我们简称那个囚犯为 K。

小说和电影都存在的部分是，K 为警卫队长提供捐赠 3w5 美金给妻子来避免扣税，并且交换是请 K 的同事每个人喝三瓶啤酒。

K 让同事感觉到了自由的滋味。

在辛苦工作之后能够看着夕阳喝着冰镇的啤酒，在那一刻，有一种仿佛自己不在监狱里的感觉。

这里的自由也有种局限性，但是它却通向广义的自由。

在监狱里的人们能感觉到的自由，并不是离开囚笼，相反，里面的图书管理员 D，在经过五十年的体制化训练之后他彻底依赖上了监狱里的生活，在监狱里，他是为数不多的上过大学的知识分子，是图书管理员，他有自己的定位，但是离开了监狱后，他只是一个有风湿病的六十八岁老头子。

所以让人感觉自己不再在监狱是一种自由，或者说短暂的自由。

这里的不在监狱和实际的不在监狱是两码子事情，它是一种幻想的自由和纯粹，就像看着《长歌行》时幻想的大唐，和长安，它就在那里，但是它是虚假的，却也是无比纯粹的。至少它给人精神上的满足。

希望

第二次是电影中原创的，K 利用监狱里的广播，广播了一首意大利歌曲，里面有个女人的嗓音，那个时候囚犯们听到了那个声音，都感觉到了好像有什么东西存在于那里面，或者说本来不应该属于这里。

那个可能是希望。

对于大多数无期徒刑犯人来说早就已经丢弃掉的东西，但是在那一刻，他们从音乐中找回来了一点，虽然好像并没有认出来那是什么感觉。

而 K,则说那个音乐会长久地给他带来那种感觉，因为音乐的记忆性，他能够在任何时候想起那个音乐，感觉到那种感觉。

我有点理解，但是很难体会。

消磨

监狱是一个巨大的压力罐。

于是乎警卫和高层也都睁一只眼闭一只眼让囚犯们有自己的爱好，只要这个爱好是安全的。

据说有个男人雕刻了三座雕像一个男婴，一个蓄着胡子的青年和一个中年人，说这是上帝的三个阶段。

后面那三座雕像好像被陈列在了州长的展览室。

也有的人在这里考取了大学文凭。

但这里的人似乎也有一些通性，比如所有囚犯都对和法庭以及越狱的小说怎么看都看不腻，甚于色情小说。

也许这里面也隐含了自己渴望的自由和仅存的一点希望，只不过一样，很难察觉。

压力

对于决定越狱的 K 来说，压力是无与伦比的。

他在一天发现了墙壁的混凝土似乎造的有些疏松，于是他开始凿墙。

而凿墙会面临的压力有：

他可能会有室友，这会暴露他的秘密。

他可能会中途换监狱，那么被发现凿墙会有更大的惩罚。

如果没有监狱蓝图，他很难确定自己会凿到哪里，有个有意思的新闻是一个囚犯凿到了警务室，刚刚露出头就又被抓回去了。不知道真假。

如果中途假释被批准，然后清空牢房的时候被发现凿墙，那么他会再次锒铛入狱。

他并不确定自己凿墙的行为需要持续多久，十年，二十年还是五十年。事实是他花了二十七年。

凿墙成功后被捕是更麻烦的事情。越狱的人很多，但是成功的人寥寥无几。

如果这些压力因素是我面临的，那么我会崩溃，无法正常思考，面露怪异的神情。整日忧心。

这也是我整本书里印象最深的部分，就是 K 的自我克制。

有一句评价是，对 K 有利的事情他会一次讲一点，而对于他不利的事情他只字不提。一年他只喝四次酒，生日两次，圣诞，除夕。

而我是非常没有自制能力的，也许是因为这一点，所以我格外地在意。

逃离

这似乎是一本短篇小说集的名字。

我似乎也格外地喜欢这类题材，是不是因为，我也是这样身处囚笼的人？

我的希望和自由又如何靠近？

你是我的荣耀

Wed, 15 Jan 2025 00:00:00 GMT

原来你只从我身边借过，而我却误以为你是从天而降的彩虹~

我最开始看的一部电视剧ya。

而杨又给了我一部。谢谢你，而且还是和我当初非常嗑的一个，当时我做梦还想过这俩能不能出个 cp 呢，没有遗憾了。另，这部我可能可以看一辈子呢。

虽然有点不合时宜，今天写一部电视剧的观后。

给乔晶晶：

展信悦！我在三天里就看完了你和于老师接近二十年的故事。我印象最深的一幕是你用空气净化器坏掉的理由骗于老师去家里，然后画着"心机妆"在逆光下回头看的那一眼。我真的非常想再看一眼，但是怕陷进去再也出不来了，就像于老师那样。

在你去发射站作为家属参观的时候，里面的工作人员说他从小看你的电视剧长大，那个时候我突然下意识想了想，我在第一次碰到你和于老师的时候，到现在，我似乎也长大了。于老师对于年龄似乎有一种宽容，但是我反而有种焦躁。

另，我发现，我以前更喜欢看你们甜甜地撒糖，但是现在我在你委屈的那两集里找到了一种另类的情绪，悲伤似乎比喜悦能够更深层地触动我的内心。但，这不是我的悲伤，而是别人的悲伤，比如于老师的。我作为一个旁观者而言，也许这也是为什么很多人最后喜欢悲剧大于喜剧。而我以前是一个完全不能接受刀的人。

当然我现在依然如此，我不希望用一部作品的结尾刻意做的很刀来让我刻意深刻。也恭喜和期待你们最后能够一直走下去。虽然第一知己关在的地位排在你前面的时候（于老师先给他打电话报喜然后才打给你）我差点笑出来了。

但，没事。没事。

这部剧，除了两个重要因素（你和于老师都是我从小看到大的），另外一个因素则是长歌行。在沙漠里那场戏中戏，你饰演的应该是李长歌吧？我最喜欢的因素之三，长歌行。我不懂这部漫画到底为什么吸引我，但是它在我心里一直是第一。有点微妙，不仅仅在于剧情啊或者人设啊，它是一个综合性的吸引，就像这部剧吸引我一样。

为什么会突然看电视剧，我有个室友经常写代码之余就看电视剧，当季最热是什么就看什么。但是我从大概上大学后有个偏见，就是觉得看电视剧纯属浪费时间。我不知道这个偏见从什么时候带出来的。但是确实一直这么认为着。

但是在假期里，吃饭时屏幕上掠过眼角的你和于老师的海报，让我下意识点进来。感谢三天下来的陪伴。

感谢你的戏给我带来的那种怀念的感觉，以及，你让我发现，我现在实际上真的挺糟糕的。

最近躺了太久了。一不小心。一不注意。

妹妹人生

Fri, 18 Oct 2024 00:00:00 GMT

每当新书刊行，妹妹总是会到附近的各间书店巡视，观察自己的书卖的如何。但是再过几年，习惯了之后，她就不会再去书店了吧。人类总是容易习惯的生物。不管悲伤或喜悦，都能逐渐适应。【不，不对……不是这样的。】与其说是适应了那些情感，也许该说是感情转淡了吧。喜悦会随着时间而稀薄。一旦意识到这件事，寂寥之情就不禁涌上心头。但只要再往前多走几步，就连那股寂寥也会随之淡化。维持感情的强度是很困难的事。想维持下去的话，就必须奉献出相当的代价才行。不论那感情有多崇高，也都必定如此。【而且，因为不能更新了，所以回忆会开始变淡。只靠大脑记住的事情是有极限的，就算不想忘记，记忆还是会愈来愈模糊。如果不想变成那样，当然就不会想离开了。】

正和我前段时间看过斗罗大陆动漫后的感想一致。因为短期时间（五天）里废寝忘食地观看，观后那种情感无比真挚与强烈，我不想放弃，但又清楚它会被淡薄，遗忘。于是我写出了"我害怕的是遗忘"这样的东西。但如今再想想，就连当初害怕遗忘的感觉都想不太起来了。

情感必须依靠接触才得以确定和保持。

冲淡情感的不是时间，而是新的邂逅

这点是我之前所没想到的，我以为随着时间的推移，我必然会渐渐淡忘。

其实冲淡感情的不是时间，而是时间里潜在的新的邂逅。在斗破后，我会再碰到很多，择天记，元尊，大主宰等等。让我遗忘的不是时间，而是新的邂逅，当然不只是小说而已。

在我看来妹妹在经过高中三年仍然保持着对"哥哥"的那种憧憬，以及几乎只以去哥哥的大学为目标而生活下去而感到神奇。她没有随着时间忘却那种憧憬，而像是只依靠数年前的一滴血生活的蜩虫。她回忆着绘画日记，回忆着暑假里的一次次结伴出行。她没有新的邂逅，而只靠回忆为生。

正是这种几乎不可能实现的条件让妹妹能够以几乎毫无变化的模样跨过高中三年出现在哥哥的门前。

我是否是世人的一份子？

兄妹情结在世人的眼中似乎是不可饶恕和宽容的一件事情，当然它首先是不可接受的。

但是在看过这部作品，借由他自己亲身"体验"一次兄妹之间的那种情感，尤其是如小说中这般。我已经不能再对它说出什么不合适了。

在小说中，妹妹和我那种近似柏拉图的恋情，实在是让人羡慕。而且也无可指责。

《当我谈论跑步时，谈些什么》阅读手记

Tue, 15 Oct 2024 00:00:00 GMT

我并非要在这里高谈阔论、振臂一呼:"来呀！让我们每天跑步，永葆健康吧！"归根结底，这些都不过是思索片段，抑或是自问自答——对我个人而言，坚持跑步究竟有何意味。仅此而已。

在写这本书的时候，作者对跑步有什么意义也没有概念，只是在此探索。

我看的大部分小说，电影，大概都是如此，不仅没有把明确的观点摆在台面上，甚至作者自己在写的时候也没有明确的答案，只是在探索。

"文章本天成，妙手偶得之。"大概能概括那种探索，所以越是试图从其中硬性分析作者的"思想"，文章的"主旨"，就越是显得愚蠢。

我以前就是这么不喜欢做阅读题的，一篇好好的小说，原本有很多可能性，但偏偏要被标准答案定格在解析者的个人局限上。

但我发现我前阵子竟然也试图做类似的事情，可怕。顶多，只能是讨论自身一些存在的问题，而不是对作者的"思想"进行分析。对自己，不对作品，这才是我想做的，这个可以写进我的评测准则。

希望一个人独处的念头，始终不变地存于心中。所以一天跑一个小时，来确保只属于自己的沉默时间，对我的精神健康来说，成了具有重要意义的功课。至少在跑步时不需要和任何人交谈，不必听任何人说话，只需眺望周围的风光，凝视自己便可。这是任何东西都无法替代的。

跑步时附上脑际的思绪，很像天际的云朵，形状各异，大小不同。它们飘然而来，又飘然而去。

我在跑步的时候，总是隔一段时间就眺望一下天色，以前习惯下午三点半左右非常热的时间段去跑（没有防晒，没有帽子，我太勇了），天色变化是最快的，从阳光直射到晚霞，到黄昏到暗下来，不过两个小时之间发生的事情。

跑步的时候，所有"正经"的，"重要"的事情似乎都不会浮上脑子，最初只需要在意自己的体力，下一步，呼吸。大概在跑半小时之后，可能进入一种"禅定"状态。好久没体验了。

跑步和坐禅的感觉很像，因为我经常半睡半醒地跑步，我打坐的时候也半睡半醒。

我不折不扣地迎来了五十多岁，这种事情在年轻时无从想象。

对村上来说，二十一世纪在年轻时是无从想象，但对我来说，二十二世纪大概是没有机会。

以前，高考结束后的暑假无从想象。

现在，成为社畜无从想象。

这些总是不经意间就跨进去了，然后带着一点"受宠若惊"，和一点"无所适从"。

对学习产生兴趣，是在规定的教育体系大体修完，成了所谓的"社会人"之后。我明白，对感兴趣的领域和相关的事物，按照与自己相配的节奏，借助自己喜欢的方法去追求，就能极其高效掌握知识和技术。

无师自通的人几乎都能成为大佬，而"学院派"，或者说在被刻意培养和引导的，把一切东西都摆在餐桌上任由取食的，几乎都是到了某个阶段就不知所措了，感到难以寸进了。

我试图摆脱老师的教学体系来自学，但我又陷入一些问题，比如，动力，反馈。有些人因为项目需要而去学，这种学有点累，但是可以很快并且很清楚自己学到什么深度就够了。但我更佩服那些对知识和技术本身感兴趣的人，没有攀比，没有目的，只是纯粹自己感兴趣。

在开店时代，也是根据同样的方针行事。许许多多的客人到店里。假如十个人当中有一个人说："这家店很好，很中我意。下次我还要来。"就已足够。

我更在意自身感受，并且留下的人不在多，而在交心。

我试图抱着这样的心情写着博客，写着日记。我觉得这样对我而言比较好，就像独自钓鱼对亚瑟摩根比较好。

即便练习量有所下降，也不可中断练习两天以上，这是积累跑量时的基本规则。肌肉很像记忆力良好的动物，只要注意分阶段地增加负荷量，它能自然地适应与承受。

连续跑步的时候，一天的休息是意外的恩宠。但第二天心里其实就开始怠惰初显了，不仅肌肉在自作主张地松懈，思想更是容易自我说服然后从此再也不出门跑了，然后渐渐躺得心安理得。

才华之外，如果再举小说家的重要资质，我将毫不犹豫地举出集中力来。这是将自己拥有的有限的才能汇集，尔后倾注于最为需要之处的能力。

继集中力之后，必须的是耐力。即便能够一天三四小时集中意识执笔写作，坚持了一个星期，却说"我累坏啦"，这样依然写不出长篇作品来。

值得庆幸的是，集中力和耐力与才能不同，可以通过训练于后天获得，可以不断提升其资质。

我在极度悠闲的时候，总是在大早上起来，看小说，看漫画，然后看到吃午饭。但我也有过连续早上起来专注地做一件事情的体验，写程序，写博客，写小说。确实一段时间内，会觉得自己专注力肉眼可见地提升。

但这种增长到后面会变成一种自我怀疑，觉得每天早上都是一样的，好像陷入时间循环。然后我就会报复性地停止。习惯被破坏之初会有一种爽快感，但后来大脑适应高多巴胺后又会陷入另一种无聊。

我现在依然不晓得哪一种方式是对的，如何度过我的早上。但我觉得，每隔一段时间改变一下，并且，适当地留出一些"休息日"，是很有必要的。

跑步无疑大有魅力：在个人的局限中，可以让自己有效地燃烧——哪怕是一丁点儿，这便是跑步一事的本职，也是活着一事的隐喻。

我希望保持连续跑步的习惯，我希望保持早晨专注的习惯。这些，不是为了不断进步，而是一种对抗——让我意识到我存于现在，让我能够更好地意识到当下处境。对闲暇感到感激，而不是在漫无目的里迷路，无聊。

在似乎可以写下去的地方，果决地停下笔来，这样第二天重新着手时便易于进入状态。——海明威

我明天要去跑步，如果可以，后天我也希望如此。

一只特立独行的猪

Sat, 12 Oct 2024 00:00:00 GMT

我的精神家园

文字是用来读，用来听，不是用来看的。要看不如去看小人书。不懂这一点，就只能写出充满噪声的文字垃圾。思想、语言、文字，是一体的，假如念起来乱糟糟，意思也不会好。

这里王说的是小说。最近在看一些短篇的时候，有的篇目三两行就把我的意识镬住了，有的篇目看了一两页眼神还是涣散不聚焦的，通篇看下来也迷迷蒙蒙。后来我特地看一眼译者，某些译者扫一眼就直接跳过了。想来文字在小说里是很重要的。

王小波的文字我看来是很容易聚焦的，很容易平静下来进入状态。

用一生来学习艺术。我念过文科，也念过理科。在课堂上听老师提到艺术这个词，还是理科老师次数更多：化学老师说，做实验有实验艺术；计算机老师说，编程序有编程艺术。老师们说，怎么做对是科学，怎么做好则是艺术；前者有判断真伪的法则，后者则没有；艺术的真谛就是要叫人感到好，甚至是完美无缺。

在高考后我最初想要报汉语言文学，满心想着写小说。但后来曲曲折折的报了人工智能。AI(Artificial Intelligence)，好歹沾了半个Art。

选修课的时候我也选了不少艺术类和文学类网课：佛家艺术，四大名著鉴赏，中国古代文学，建筑艺术等等。

但我后来发现这些所谓的"艺术"不过是在建构一种评判和认知的体系，用上面的话讲，是在讲对错，而不是好坏。本身只做到了科学，而没做到自成艺术。

从这点来说，这点阴差阳错还值得庆幸。

我总觉得读过了《情人》，就算知道了现代小说艺术；读过道乾先生的译笔，就算知道了什么是现代中国的文学语言了。

高中的时候第一次看王小波在这里通篇夸王道乾的《情人》，我立刻就去买了那个译本，第一本法国文学，如梦似幻。

后来，我把这本书借给一个女同学后。又有两个女同学来问我有没有《情人》。

小说的艺术

我自己读杂文，有时还写点杂文。照我看，杂文无非是讲理，你看到理在哪里，径直一讲就是。

小说来负道义责任，那就如希腊人所说，鞍子扣到头上来了。

任何一门艺术只有从作品里才能看到——只喜欢看杂文、看评论、看简介的人，是不会懂得任何一种艺术的。

所以我其实没必要讲废话，除非忍不住。否则吞声一个劲抄就好了，不然写得越多，越容易有种矫揉造作的感觉。

但，偶尔看看杂文，也是一种享受。不用动脑子就能产生不同观点的感觉。

从《黄金时代》谈小说艺术

积极向上虽然是为人的准则，也不该时时刻刻挂在嘴上。我以为自己的本职就是把小说写得尽量好看，而不应该在作品里夹杂着某些刻意的说教。我的写作态度是写一些作品给读小说的人看，而不是去教诲不良的青年。

塑造人格什么的应该是儿童读物该考虑的事情。作者的本职，小说的本职，不过是传递另一种人生，另一个世界。作为我短暂生命的拓展，如果这个世界塑造的丰满具象，那么它就已经完成本职了。教唆不是作者必要的责任，感悟是读者可以考虑的工作。

其实每一本书都应该有趣。对于一些书来说，有趣是它存在的理由；对于一些小说来说，有趣是它应该达到的标准。我能记住自己读过的每一本有趣的书，而无趣的书则连书名都不会记得。但是不仅是我，大家都快要忘记有趣是什么了。

有趣是什么呢？夏达的每部作品，都挺有趣，《长歌行》为最。这是我目前的看法。

《撒哈拉的故事》阅读手记

Thu, 10 Oct 2024 00:00:00 GMT

最近的观后主要都是摘抄加自己的观点，但可能有人会注意到每本书只有几篇。因为我的目的不是小学生写读后感作业，每看一篇都写一点。而且码字也费时间，整理思路费神，通常每次只码有感觉的前两篇，至多四篇，然后就光看加划线了。

简介

三毛(1943-1991) 本名陈懋平，因为学不会写"懋"，就自己改名为陈平。十三岁就跷家去小琉球玩，初中时逃学去坟墓堆读闲书。旅行和读书是她生命中的两颗一级星，最快乐与最痛苦都夹杂其中。她看到一张撒哈拉沙漠的照片，感应到前世的乡愁，于是决定搬去住，苦恋她的荷西也二话不说地跟着去了。

我最初接触三毛，是高中逛书店，在一堆东野圭吾里发现一本《流星雨》，一堆精装书里面混了一本平装书，很显眼，而且我中意封面和配色。

买了之后，是记录三毛的演讲和访谈。演讲那部分我就觉得，这人好怪，比我怪多了，但又好有趣。

《撒哈拉的故事》是第二本，在那一段时间，我只看三毛的书，后面成了我第一个看完全集的作家。

《撒》这本也是我经常拿来推荐给不常看实体书的人的第一本，我妈，我爷爷，and n个同学。但他们中看完的极少，我不懂，是他们没有 get 到三毛的这份怪，还是我本身也比较怪。但，靠着这本书，我发掘了一个和我交流无需言语的朋友。

沙漠中的饭店

第一道菜是"粉丝煮鸡汤"。荷西喝了一口问我："咦，什么东西？中国细面吗？""你岳母万里迢迢替你寄细面来？不是的。""是什么嘛？再给一点，很好吃。"我用筷子挑起一根粉丝："这个啊，叫做'雨'。""雨？"他一呆。"这个啊，是春天下的第一场雨，下在高山，被一根根冻住了，山胞扎好了背到山下来一束一束地卖了换米酒喝，不容易买到哦！"

以后他常吃"春雨"，到现在不知道是什么东西做的。有时想想荷西很笨，所以心里有点悲伤。

三毛的语文很好，数学很差。好不是一般的好，差也不是一般的差。一篇作文能把老师看哭的那种，好到我觉得把整篇都码下来也不过分。

结婚记

"对不起，临时通知你们，我们事先也不知道明天结婚，请原谅——"荷西的电报长的像写信。

我呢，用父亲的电报挂号，再写："明天结婚三毛。"才几个字。

似乎中国人拍电报都是这么短的，以前书里电影里见到报丧事，也是「父危，速归」云云。

"想带你去看电影，明天你就不是我女朋友了。" 于是我们跑去唯一的一家五流沙漠电影院看了一场好片子《希腊左巴》，算作跟单身的日子告别。

今天码得格外得多。因为我觉得这两篇，可以很好地介绍三毛和荷西。

上一次见到这么有意思的情侣，还是在《浮生六记》里沈复和陈芸，但他们都是死别啊。

三毛的文章，是提供给读者的一双眼睛，它好像打开了世界的另一面，生趣，活泼，幽默。换言之，如果我在那个环境下，我看到的是不方便，是艰难，但三毛却能把那些真正有趣的部分，用神奇又自然的笔法呈现给读者。

我也应当学学。不管是笔法，还是那种观察的角度。

娃娃新娘

在大概二十世纪七八十年代，一个撒哈拉威人的镇子上，只有男性可以做医生。还没出嫁的女性，如果身体私密部位有病变，宁愿死也不让男医生看。

不少女性的出嫁年龄在十岁左右，有的甚至八岁就嫁人。

在看到这边的时候我突然有点感慨，突然觉得世界很大，我可能一辈子也不会到撒哈拉沙漠上的镇子去住上一阵子。而国家和国家之间的差别也那么多，我大概也没法一一去体会。

时间上更是如此，我无法想象大唐长安夜市是什么光景，公主出游是什么样子。

这么多东西我接触不到，因为空间，因为时间。但又止不住那一点好奇，一点向往。

而文字，让我见识了很多，川端笔下的京都，雪国，三岛笔下的歌岛，村上春树游过的雅典，三毛的撒哈拉。

动漫里，凡人修仙传的元武国京城弥补了我对长安的一丝遐想。漫画里，李长歌是我的公主。

这些无疑都是虚构，但虚构里，让我捕捉到的一丝真实是让人动容的。感谢这个世界上有小说，感谢那些动漫。

《罗生门》阅读手记

Thu, 26 Sep 2024 00:00:00 GMT

9.26

之前重看类似《刀锋》这样长篇小说都没坚持看完，所以先用短篇小说开头。

目录里的河童让我想起来之前看的《世界尽头的女友》，现在回想，对那本书的印象相当好。

9.27

鼻子，罗生门，竹林中，地狱变。

看到鲁迅译的文了！并没有感觉有什么隔阂，很易读，甚至和近年的也没什么差别。不过鲁迅译的两篇都有小后记，谈论关于芥川和选择翻译这篇的理由。现在的翻译作品下面真的看不到这样有意思的后日谈了，有种和读者交流看法的感觉。现在一般译者只写一个译序放在最前面，我一般都直接跳了。可能因为现在规定译者不能自说自话，或者译者怕读者觉得自己摆谱，又或者多写的那些不算稿费 =-=

竹林中和地狱变两篇里的推理元素看爽了，整体几篇都是有点故事新编的感觉，就是题材本身就旧有的，可能是民间传说，或者古人写的，把里面的故事和人物拿出来然后用新的视角展现，也有可能改编故事。鲁迅的《故事新编》也应该有点灵感来源于这里。【这是从鲁迅的小后日谈推理得到的。】

芥川龙之介真的看的好多，不仅日本的懂，中国的也好懂。鬼才，鬼才。后日谈真的可以有。

芥川似乎有一本记录中国之行的书？还是我记错了，可以补一下。

顺带一提，这次看的是读客的版本。

Another side:

开始打开一本书前五面真的阻力重重，是百般不愿意，最后在心里跟自己说看十面就可以去打游戏了。才一边听着音乐一边看，但过了十面后，就像有什么魔法，看的速度和看进去的比例一下子增加，一直到一百多面停下来。然后去打游戏，这次打游戏都觉得自己神清气爽。

9.28

父，猴子，戏作三昧。

父和猴子都映射怜悯和同情的本能，不过，父是先觉的，猴子是后觉的，这两篇相邻地放在一起，这个编辑真的有水平。

戏作三昧，和地狱变相似，都有点创作之神的意思。不过地狱变是由第三者客观记录一个人近似病态的对创作的追求，混合推理和道听途说，火焚毛车那一刻他威严的宛若神明。所有的一切好像和他隔绝开了，有意思的是，用狐狸精来概括他的创作状态，他创作时，背后是一群狐狸精，所以一创作彻夜都不停，平素宠爱的女儿也不搭理。

但戏作三昧这边，视角拉的很近，全程聚焦在马琴【创作者】身上，心理转变很细致，两处很有意思的点，一个是马琴面对别人对自己的作品夸奖可以波澜不惊不为所动但被诋毁时却吊起心眼，但真的正眼看到了诋毁他的人，他却突然感到怎么也计较不起来，而且心情突然舒畅了起来，这里第一个突出了他似乎一种创作精神的转变，就是不顾外界，但还没到顶峰。

顶峰出现在当晚他回去重读自己先前所写的所改的稿子，再读来索然无趣，只好重写，但文思枯竭，感觉自己好像也不过只是自大的庸才，和他鄙视的那帮人没什么不同。这时候他的小孙子，可能是真的，也可能是父母教的，到他跟前【他非常宠爱孙子，一下子放下之前创作时的郁结】跟他说在庙里菩萨让孙子带两句话："好好用功。不要发脾气。"他好像一下子神会了什么。

当晚，他又开始创作，起初，文思如同细火线，稍微风吹草动就会熄灭，但他仔细的护着火线，随着三四行，十来行写下来，思绪就如同涨潮一波波涌来。他整夜没有停笔。

头脑中的潮水，犹如奔腾在天空上的银河，不知从什么地方滚滚涌出。来势之猛，使他感到害怕。他担心万一自己的肉体承受不住可怎么办。于是他紧紧攥着笔，屡次三番提醒自己道："竭力写吧。错过这个时机，说不定久写不出来了。"

但是恰似朦朦胧胧的光的那道潮流，不但丝毫不曾减缓速度，反而令人眼花缭乱地奔腾着，把一切都淹没了，汹涌澎湃地向他冲来。他终于彻底给俘虏了，他忘记了一切，对着潮流的方向挥着笔，其势如暴风骤雨。

这时，映射在他那帝王般的眼睛里，既不是利害得失，也不是爱憎之情。他的情绪再也不会为褒贬所左右了，这里只有不可思议的喜悦。要么就是令人陶醉的悲壮的激情。不懂得这种激情的人，又怎么能体会戏作三昧的心境呢？又怎么能理解戏作家的庄严的灵魂呢？看哪，"人生"涤荡了它的全部残渣，宛如一块崭新的矿石，不适璀璨地闪烁在作者眼前吗？

以及最后结束的地方很有意思，大概是这样的：

"爹还没睡吗？" "一定又埋头写作呢。" "这个人真没办法。又拿不了多少钱。"

看书和创作也差不多，起初很泄气，但进入状态，就会有种不可思议的喜悦，以及上面那种感觉。

另外，之前学板绘的时候，画完一幅画，也会有种激情，会一瞬间有这辈子值了的错觉。

Another side:

今天早上同样也是开始很困难，不过第一篇的《父》让我很快进入状态，就像一激灵。

有意思的是，我大部分都是在吃饭的时候看的，看完《父》我就出去吃早饭了，一边慢慢吃稀饭一边看，格外看得进去，另外第一次有种Enjoy周末早晨的感觉，或者说在没课的时候产生悠闲的感觉。

我也发现了一点，比起在诱惑源【电脑】旁边，换一个环境可能会有很多不同。

9.29

橘子，龙，葱。

橘子这边，是一个人从虚无回到现实的一种转变，从最初什么都透露着无聊到再次感到生机。可以重看，收录，试试下次有类似感觉的时候再掏出来看看。

龙，即使一件事情起初出于恶作剧，当无数人信以为真并且心怀希望的时候这件事情会受到神的响应。没有舆论什么的隐射，反而是体现愿望的美好。

葱，一个影像感非常强的小说，结尾很有意思。而且有种突然清醒的感觉，突然把现实拉进幻想。可以收录，可以重看。

Another side:

早上是在上课时看的，以往上课时看小说总觉得状态不好。但实际上很大一部分是我心态不对。我觉得老师麦克风吵闹，进而烦扰到我。这个逻辑实际上是反的，如果我换一种念头，比如，老师上课时我应该听课，但我更愿意看小说，而且老师也没有针对我，这么一想，反倒有了一种感恩的心理，原来烦躁和郁怒也消弭一空。

换一种说法，这其实是应该和愿意的区别。

比如丈夫事先认为他工作辛苦妻子应该做好饭，加班回家后看到昏暗的餐厅和什么都没有的餐桌就会立刻起一股无名火，即使做好了，也不会有什么额外的感激，反倒可能会觉得饭菜冷热或者咸淡，非常敏感。

但如果他放弃妻子"应该"的这个念头，他先入为主的想，有没有人做饭都无所谓，大不了自己出去吃，那么这时候他收到妻子"今天提前下班，饭我来做"的短信就会感到温暖和莫名的喜悦。

这应该只是一念之差，但我之前的念不太对。

河童，某傻子的一生，点鬼簿，人生。

短篇集的最后几篇，芥川的精神状态看起来已经不太好了，编辑把这几篇从轻到重的排列，最早的苗头应该在橘子那边。

我知道的日本作家似乎十有八九都自杀了。川端，太宰，芥川，三岛？

短篇集前几部分创作和生活分的很开，但后面，已经能感受到生活侵入了创作。因为先前看过其他译本，这几篇只是草草的扫了一遍。

"人生不如一行波德莱尔。"

终于知道之前那个人的个签来源了。

以及另外一个有点意思的地方：

他同一个大学生在长满狗尾草的野地上行走。

"你们仍有旺盛的生活欲吧？"

"嗯……可是你也……"

"可是我没有了。只有创作欲罢了。"

"创作欲也是生活欲吧。"

他没有回答。曾几何时，野地的红穗上清晰地映现出一座喷火山。他觉得有些羡慕这座喷火山。可是他自己也莫名其所以然……

希望每个这样的人都可以碰到橘子里的救赎。

从《葬送的芙莉莲》到心理强迫

Mon, 09 Sep 2024 00:00:00 GMT

零食+饮料+夜晚 = 快乐。

就像小埋，看动漫或者电影时应该有点仪式感。

但实际上这点仪式感让我迟迟徘徊着不上床。【我在床上看】

最后只在十点二十到十一点看了四十分钟。

但今天打完球后回来是七点二十，洗澡拖延，一直到八点半才洗。因为犹豫着要不要和同学打游戏，结果逛了一个小时b站。洗完澡后是九点。但我依然迟迟没上床，我在那边看我荒野大镖客开局。赖到了十点二十。

这样的拖延平时我也碰到不少，它无疑是一种阻力。

上上学期期末时因为室友比我少考一科，所以我一个人在寝室多待了三天。

那两个晚上【因为是考试周，所以没有课。】，我一到七点就关灯准时上床看《神印王座》,两天看了六十集，那种氛围，真的是再也没法复刻。

即使现在，我的观影体验依然很好。笑点，深刻点（不得不说，和坐着看不同，躺着看真的更容易进入状态）。

很多地方没有再去拍，尽管短短四十多分钟，体验依然相当好。

但是前面提到的那种阻力，是需要克服的，平时写项目偶尔也碰到，明明进入状态后就能体验到乐趣，但会因为一种强迫性而迟迟不走第一步。

关于强迫：

有一个男子，他第二天要远行到另外一个地方，他提前一天晚上，打电话给自己熟识的住在那个地方的女性，想要邀请她们中任何一个共进晚餐。（性邀请），直到他被所有人一一拒绝了一遍后，他才长舒了一口气，说着，"这下我终于有时间开一瓶酒，一个人读读书了。"

其实这样的时间他有很多，但是，他无法拒绝自己的性邀请的行为。只要当碰到不可抗力的时候，才能够从中脱身。

我的经验大概是，放弃思考，直接执行第一步就行。思考是最大的阻力，因为考虑的全是借口。

《大内密探零零发》后

Sat, 07 Sep 2024 00:00:00 GMT

最近转一下观后的风格，不再反复论证探究所谓的理，那样太累，需要休息一阵子。这里只是简单记录下有意思的部分，力求简单，不费脑子。如果可以的话，可以幽默一些。比起严肃和缜密的论证，幽默的语言更能松弛人的心。

搁了很久的一部电影，还是第一次看。

之前一半是因为没有片源，一半是因为封面海报里俩"老阿姨"有点劝退。

但进去看后才发现都是老熟人，东邪西毒里的桃花和，小龙女!

妆容差别太大，特别是小龙女。原本是这样的:

在这里面是这样的:

你在杨过怀里可不是这样的：

如果不是中途有一张眉眼特写我还认不出是小龙女。

以前看神雕侠侣的时候久觉得姑姑的眼睛很深邃，这里突然就想起来了。

美是动态的，比起海报里两个老阿姨，电影里老婆真的太可爱了。

费心力写长评很废心力，除非有感而发。目前发不出来。

记录一下值得重看的地方以及有意思的点。

完整的片段是这样的:

--「诶。你会不会肚子饿啊。我下碗面给你吃。」<br> <br> 「你怎么会知道我每次都躲在桌下面。」<br> 『你每次都躲在桌下面啊。我有什么办法能够不知道你躲在桌下面呢。拜托你用点脑子想一想。再找几个新的地方躲。好让我有点新鲜感。好吧。』<br> 「可是我不躲在桌下面我怕你找不到我嘛。」<br> 『啊！！！！啊！！！！我真受不了你。拜托你不要这样。我拜托你好不好老婆。你不要这个样子。谢谢谢谢谢谢。。。<br> 诶！我只是个血肉之躯。你每次都这样骂我。我不知道哪一天我就忍不下去了。』<br> 『忍不下去那你走啊。』<br> 「我去洗澡了。」<br> 『我叫你走啊。』<br> 「诶。你会不会肚子饿啊。我下碗面给你吃。」

这种俗套有时候很动人，它让我感觉到，电影里的人，同我一样也是俗套的，或者说，有一种真实感。

两个人的关系值得重看。

另外一个是皇上出访遇刺和他们俩出游时敲西瓜，撕鸡肉，捏鸡蛋的混合剪辑。在营造一种喜剧氛围的同时，也似乎有一种更深的隐喻。港片里总是有若有若无的隐喻，你可以解读它，也可以忽略它。它存不存在对剧情而言似乎不重要，但似乎对我会很重要。

谜语人不讲清楚是因为不想费心把事情探究明白，最近需要修养一阵子。值得重看的部分应该记在时光穿梭机片单那边。

lsp的截图：

这个滤镜下有种王祖贤的聂小倩的感觉。同一个场景下，两个场景灯差距非常大，但不会引起我的不适，反而营造了一种对冲的气场。现在很少有导演敢这么用灯了。下面是同一个场景：

构图，一瞬间掏出手机拍，但没有聚焦上，或者说，由于拍摄技术不行，这次大部分都没聚焦上。<br> <br> 加上我的"图床"原因，还得二压一次，估计所有图片都有一种马赛克的感觉。

大圣娶亲后

Sun, 01 Sep 2024 00:00:00 GMT

先提出两个命题：

1.如果紫霞附身在猪八戒身上，我能不能接受。【虽然电影中是青霞附身的。】

2.在失去后才意识到的价值是否被过度夸大，或者说，是真的我们很难注意到拥有的事物的价值？

以及一个话题外的讨论：

1.大圣娶亲是否会被当作是一种西游原著的一种丑化？是否是一种阴谋论？为什么我不会像对黑神话那样排斥大圣娶亲，反而接受。

现实不是童话。

我先前在 [[月光宝盒后]] 里提到我是一个俗人。我看电影的动力很大构成就是女角色，反差萌，可爱，知性之类。我一半是抱着看紫霞【朱茵】的那一眼来的，我一直记着的一幕。

所以你一定要说紫霞变成猪八戒我还能不能接受，我觉得我大概是不能。

但是，我之前又反驳过自己。在 [[《食神》后]] 里我写过

周最初被莫亲了一下，是对着镜子拼命擦的。即使在街上其他人口中得知她从很早以前就喜欢自己，周还是难以接受。实际上，我的心理最初也是跟着他走的，尽管有点动摇，但是没动摇到颜控的根本。

直到把事物本身撕碎给人看，才终于一瞬间让我跳出了外表这个坑。那一瞬间涌上来的悔意，和想起来她先前的一碗饭，一次用手挡刀。我才真正认识到内心所想。颜控是病，生来偏爱可爱的东西，这没错，可爱的事物给人亲近感和好感。但是如果只停留在第一印象，那么，可能永远，也不能算更进一步地认识一个人。导演用莫的"死"把这个理撕出来给人看。很高超，没有任何多余赘述，一张纸片，一首歌，最后的一碗饭。没有一次给出，而是层层推进。

我可以接受平庸，可以接受缺陷，但是我依然有我的底线，比如这个，我就顶不住。

除非把现存的事物撕碎给一个人看，否则这个人很难真正的直面内心的真实想法。就像紫霞被抓走，期待着她的如意郎君能够踩着七彩祥云来迎娶她时，至尊宝仍然在另一边准备着和白晶晶的婚礼。

白晶晶后来跑了，因为她看了至尊宝的心，当时至尊宝最爱的人已经不是她了。

从另一边菩提老祖的话也能看出来。

「你睡梦后一直叫晶晶晶晶的，叫了88次。」

「是吗」

「哦还有一个名字，叫紫霞，你前面叫了784次。」

「昨天晚上，你叫紫霞的名字，叫了785次。比之前多一次。」

另一边，戴上金箍后的马捞【猴子的粤语发音】一直不肯与紫霞相认。坚持说自己是齐天大圣，孙悟空。

虽然它有记忆，甚至身上还带着紫霞的手链，但就是矢口否认。

直到紫霞替它挡了牛魔王一叉，扑街了。它才紧紧抓着紫霞的手。但越是如此，它的紧箍就越发力。那个紧箍收缩，是无法掩饰的。

命题一的答案:

一个人总无法正确认识自己的心，或者常常潜意识的欺骗自己，或者又是苦衷又是什么的。
也许失去了才会知道，那份附身于猪八戒的紫霞的重量。

镜头回退到至尊宝第一次拔出紫青宝剑的时候，紫霞要他吻她，但至尊宝没有搭理，觉得她在胡闹或者没当回事。

至尊宝最后也没给出那个吻。

这大概是他欠她的。

月光宝盒中，他是主动的，但立刻就失去了。

至尊宝和白晶晶

而大圣娶亲中，至尊宝从始至终都没这么抱过紫霞。成为马捞后，就连抓住她的手都做不到。

但，马捞在用月光宝盒再度穿梭时空后，反倒遇到了另一对"紫霞"和"至尊宝"。

同样"至尊宝"不主动。

而马捞这次附身了"至尊宝"。

把至尊宝的吻还给了紫霞。

命题二：

我现在觉得这个命题很怪。就像在说，离别会悲伤是因为离别夸大的离别的悲伤。

这里分成两段。

一个是失去前，一个是失去后。

失去前 ，就像至尊宝虽然梦里潜意识会念叨那么多遍紫霞，但是现实中却执意不承认自己喜欢紫霞，反而筹备着和白晶晶的婚事。

紫霞不在身边。我觉得，像这样刻意的忽视事物的价值，是会产生类似焦躁不安的情绪的，紫霞被抓走后，至尊宝常常对着菩提等人发脾气，说自己对紫霞只是因为抛弃她而去而产生愧疚的感觉。

紫霞在身边的时候。那至尊宝是真意识不到的。他真的就觉得自己更喜欢白晶晶。但，会有时候觉得自己不对劲，隐隐的。所以，如果不是像紫霞或者白晶晶那样，身体里问一下真心，是不会知道的。拥有一样东西时，至尊宝最容易or我最容易忽略真心对它的看法。

失去后 ，悲伤是否会夸大原来事物的价值。从而产生一种失去了就像自己一无所有一样。

会，如果这么提这个问题就会。前面提到，失去前，在身边的事物通常意识不到它对于真心的价值。真的容易产生这就是我的所有的感觉。

除了失去的那之外还有什么

如果说导演就只止步在了紫霞这边，失去后马捞乱发疯之类的，那么就会落入过于用力的俗套，之前在 [[月光宝盒后]] 讨论情爱主题的时候提到。

但是，马捞在那之后的态度，虽然说戴上紧箍意味着不能再有情欲，但不代表马捞没有了情欲，紫霞死时马捞的紧箍收缩就能说明这一点。有人会过于的曲解这分意思，会抱有，如果至尊宝和妖精谈恋爱也就算了，但变成孙悟空之后，依然放不下情感那时对孙悟空的一种误解。

这里我有必要来进行一点阐述，他们一行人仍然在西行路上，并未取得真经，成就果位。唐三藏在途经女儿国的时候甚至已经说出:

「今生已经许给御弟和我佛。」【指的是答应唐王去西天取经】

「若有来生」【这本就说明，唐三藏动了真心，而且这段剧情非但没有让唐三藏的人设有损，反而让他更加丰满，它无疑也说明了，唐三藏是个人。哪怕他佛法高深，口生莲花，但他依然是个人。】

孙悟空我觉得也类似。紫霞就是它的女儿国一难。虽然唐三藏靠自己放下，显然更加高明。而孙悟空却是靠假装不认识，以及死亡来进行离别。

但紫霞死时那一段，加上后来另一个时空孙悟空附身还给紫霞的一个吻。这些都让我觉得，至尊宝是孙悟空的一面，同时孙悟空也是个人，而非无情无欲无嗔无怪，被排挤也不会受到委屈的取经机器。而且，电影始终没有否定西行的正当性，即西行对于孙悟空的积极影响，附身还了一吻之后，孙悟空最后看了塔楼上他们一眼，之后追上它师傅，就像它好像放下了所有牵挂。从此一心归依佛门。

命题三

于是最后，孙悟空并无被诋毁之感，反而像是类似女儿国的一难。最后，对于取得真经后成就果位。那终究是带了人们的美好想象，是否成为斗战胜佛后，孙悟空就得斩断至尊宝的一面，完全无情无欲，这些是人们对于仙人的美好想象，我无从评判。但我至少觉得，无论现实中的谁，都始终首先是人。

注解：

马捞: 猴子的粤语发音。这里也是为了防止有的人看了后断章取义，说就是孙悟空放不下。所以，我只在孙悟空放下后，才把马捞改回孙悟空，只有那时，它大概称得上悟空。

lsp的截图：

朱茵是一种动态的美。

当我试图截图的时候，这种美就丢失了十之七八了。

美不在五官或者什么，而是眼睛里满溢而出的一分灵气。

Vampires' Melody 吸血鬼的旋律后

Sun, 01 Sep 2024 00:00:00 GMT

Vampires'Melody 吸血鬼的旋律后

时隔很久再玩galgame，其实我本身galgame玩的也不多，这么说反倒显得我玩的很多。

游戏体验：

有剧情分支图，可以知道哪些选项会造成分支。而且结局是线性的，中间的选项大部分引导的是死亡结局。

只有最后一个选项似乎会导向两个结局。

所以这对我是友好的，我不太喜欢多支线，像这样有主线的我很喜欢，单女主好评，比起每个角色都废心思塑造一遍，不如全程写好一个角色。轻度傲娇好评，傲娇女主已经退环境了好多年了，没想到可以在这里见到。

另外是国产日配的问题，最初我就觉得这个配音似乎不是很专业，而且存在忽快忽慢，停顿过长的问题。

感谢制作商，即使经费不够还请日配，因为日配就算不自然，我也不会尴尬。但如果是国配，那我估计得关着声音玩。

选项和一些氛围很惊险，我不看攻略，经常让我有走钢丝的感觉。有时候比恐怖电影还有代入感。

不得不说，这游戏里，男性角色的立绘都挺随意的。男主除外。

也是因为这份恐怖感，让这个游戏的一些瑕疵似乎不被那么重视和暴露出来。

剧情：

极致的浪漫主义。【地与天结局】

直通地与天结局，中途前两章死亡end两次=-=。

中途几次选项让我心惊动魄，文字游戏玩起来比死亡搁浅还紧张。

这个结局体验下来，极端的浪漫。

据说，其他的世界线里面，人类发动核战争。我结局里背景板里划过天际的火箭就是战争武器。

但在我的视角里，除了毛血旺，和眼前的人，什么都不重要，火箭只是背景板。极致的浪漫主义。

ps:似乎有个后日谈，十年后的故事，我给跳了。但这更加重了浪漫色彩，唯一一点现实色彩被我忽略了。

一切戛然停在神迹的那一幕。

lsp截图：

这个似乎和另一个结局的cg一样，但我前面就看到了。

你要考虑你的玩家可能不知道夏目漱石的梗，也没看过叫《月色真美》的动漫。

但这幕对我来说，也是很浪漫的。

后日谈

这里借用一个同学的说说。

galgame玩家的yy能力就像吸血鬼那样活的越久越强，但我还是发现galgame是真爱,但我暑假里都没怎么玩。

以及，继上次的回答。我在 [[没有明天的我们，在昨天相恋]] 里写过。

上一次寒假时写的东西。
而马上要暑假了，人是否会吸取教训？还是固执己见？

我果然还是固执己见啊，我最初想象的暑假，是大部头+galgame+电影。

但是大部头是一部没看。galgame才玩了一个。电影也看得断断续续的。反倒是，网游一天没断。这种规律到极点的习惯，究竟是如何建立并且保持的？

月光宝盒后

Thu, 29 Aug 2024 00:00:00 GMT

《月光宝盒》后 - 以情爱作为讨论主题的电影是否是一种俗套以及不良影响产生的可能。

开头先抛出三个命题：

以儿女情长为主题和以取经正道或意志传承为主题的相比，是否落了俗套，是否立意上就低人一等。
小家子气和家国情怀是否本就是对立？
如何定位，以及什么才是格局？什么样的作品不能被原谅，什么样的作品可以被接受。

写这个的人不是专业的，如果你期待看到一些专业术语的辩证，那我无能为力。

要破解问题一，首先得回答，人是否可以免俗？

人是否可以免俗。

就我所知，大部分人是不行的。

《月光宝盒》这边，能够支撑我看下去的主要原因，是春三十娘的颜值=-=和可爱的莫文蔚，这个人设她演来由邱淑贞的灵动。一颦一笑，动人心弦。另外就是，俩人都是妖精，变身梗，这种反差造成的一种反差萌，不会缓解了审美疲劳。而当观众可能快到喜剧疲劳，笑点变高的时候，导演也把人物刻画沉淀下来。突然有了深度起来，比如蜘蛛精喊得一声奶妈，达叔那一刻看她的眼神。

深度方面我注意力全放在达叔身上，先前蜘蛛精打架过程中问了被迷魂大法控制的达叔说，

"你没事吗？【nei mou si ma】"

达叔的反应是「她这种危急时刻还不忘关心我，没办法，我要爱她一万年」。

有些可能不是原来台词，但「爱她一万年」是千真万确。

我很佩服周星驰大部分电影，比如逃学威龙等等的无厘头和喜剧的节奏。但凡过了一分，就是过火了。就像无厘头只有我看周星驰演才不会尬，其他演员总会不自然。导演那种如何把握什么时候幽默开玩笑，什么时候又正经严肃一下。这种节奏真的学不来，毫无规律可言，完全是对观众心意的把握。

所以，每一部对你心意的无厘头电影，又何尝不是导演和你的心率合拍，何尝不是一种告白？

扯远了。

我自己是没法免俗的，上面提到，那些就是吸引我看下去的动力，我七情六欲一欲没断，我这么俗，我也对适当的迎合我俗气的电影有好感。

回头这一眼，让我想起来谁，程英。

左一莫莫小表情很可爱，特别看过喜剧之王，这种反差萌更强了。

更多的可能会放在最后了，这里就不多放了。

我本是俗人，所以，以情爱为主题来引起我的注意，并且以此推进剧情，我不觉得有问题。反倒，我是欢迎的。

而且大话西游本不刻意，它没有让我感觉，它把情爱作为最重要的东西，全部都在讨论它，没了它不行的样子。我见过这样的，属于写情爱写的太用力，《白蛇：缘起》。除去了爱，最后还剩下什么。太用力的表现情爱和只有儿女情长，这才是导致人觉得过于俗气的原因。

当然，也不是所有人都会觉得俗气，每个人都有自己能够承受的俗气范围。至少在我看来，白蛇是有点狭隘和偏激了。

而且这么做也经常陷入误区，后几部，白蛇也因此没法跳出自己给自己定的框架，这时候儿女情长，就真的成为了一种局限。

哎呦，不小心似乎就把答案得出来了，我也不是一开始就知道答案的，只是试图探讨，以此得出我自己的答案。

结论：

应该没有人能够免俗吧，我自己是不能的。
每个人都有自己能够承受的俗气范围。
太用力的写情爱为主题，只把它看作唯一重要的，那么它就容易成为狭隘和偏激的，并且也容易落入俗套。
而月光宝盒中情爱更像是一种诱捕罐头，把我这样的人诱捕看到后面，但情爱并不是最重要的，不是没了它不行，虽然我讲不出什么是最重要的，可能可以在达叔的演绎中找到答案。

立意上，小家子气是否就比家国情怀低了一等。

大家只是小家的复合统一和协调。

我个人的观点，这两个本不对立。

这点如果通关过《古剑3》的朋友会心有灵犀一点通。

古剑3虽然立意上一反古1古2的儿女情长为主，而最后体现出来一种千秋百代，星火相传的感觉。很多人说是升华了升华了。

但是这个大家里，小家的贡献不可埋没。

我可是全程俗气的追着云大佬（云无月）的颜值来的。

谁懂第一眼见到云大佬英气逼人的脸有多戳我。

以及一句句「我见你腰力【妖力】微弱。」

云大佬和北洛的日常以及他们可能存在的恋爱可能是我坚持玩下去的重要动力之一。

故事最后体现小家的是北洛和云无月，体现大家的是岑樱。【这里可没有什么狗血剧情哦，没有什么第三者关系不清什么的，小樱子可是很可爱的，不许这么乱想。】

如果这游戏哪怕搞出来一点小樱子和北洛关系不清，那绝对就是像上面我提到的，落了俗套。但这个剧情把握的很好，距离把握的很好。

但我反而更加注意的是一个寿命论的问题，岑樱是人族，而北洛是妖族，云大佬是魇族，都是长生种。

他们之间短暂但是精彩的交界，反而成了我觉得最惊艳的一点。小樱子在她往后漫长人生中会如何看待之前的冒险？

很多时候，落入俗套只是用力过猛。不管是小家子还是大家子。

前者是一种狭隘和局限，后者是一种假大空，很多人不喜欢主旋律的电影，就是因为主旋律电影通常没法好好表达出他们想象中的高立意，但是却刻意，用力的拉大旗。何尝不是一种俗套，而且这种俗套更是让人不适。

又得出结论了：

小家子和大家子并不是天生对立，而是可以共存。
不管大家子还是小家子都是存在俗套的情况的。
大家子和小家子都各有受众，我更吃小家子一些，也许是大家子的我几乎没见到几个能表达好的。

第三个问题的解答：

至此，其实也可以得出上面第三点的答案：

格局只是戴高帽，我们说格局大或者小了，通常是影射导演是否狭隘了。
是否狭隘，一般总有一种共性，一样东西被看得太重，用力太猛，就容易狭隘。
狭隘的作品可能传递的本意本身也是有点偏激的，可能会引起观众的观点不合而不适。所以这样的作品通常在我看来是不能被接受的。

最后是lsp的截图：

有种李逍遥抱着赵灵儿的感觉有木有。

忍不住再放一次，可能其他人很难理解，只觉得俩都长得一般。但右一莫名戳到我审美了。

原本紫霞该放在[[大圣娶亲后]]，但结尾就截了好多啊。初见就是心动,lsp实锤。

逆鳞之后

Tue, 20 Aug 2024 00:00:00 GMT

《逆鳞》后：八九十年代的江湖义气。

我爸带着我和我弟三个人去电影院，前后，以及右边都没见过我们这么奇葩的组合。

常见组合有，老夫老妻组，年轻情侣组，闺蜜组，兄弟组。

倒是有点怀念以前和我爸深夜看美剧的那些个暑假。指环王，复联，速度与激情。

电影是一种纽带，游戏也是。完了，再讲就讲到黑神话去了。最近总忍不住扯过去，因为有太多想吐槽的，有太多让我意难平的。

尊非的人设很好，几次分钱时候体现的。而且几个小弟也非常尊敬尊非。

而且他气场镇得住，不显得做作，这也算难得了。大陆演员我就没见几个能镇得住，有那种黑帮老大的痞子气概。

故事本身挺简单的，但矛盾点也很好。

导演很贴心，像文艺片一样安排一个幕后声音，喜来。整体还是有点类似在讲述一个人传记似的。

他最后甚至贴心的把电影想表达的讲了出来，而不用观众费脑子。

「尊非有天赋。如果尊非生在这个时代。如果尊非生在这个时代，他会收获他想要的，事业，爱情。他不用与魔鬼做交易。」

悲剧会让人铭记，而喜剧只是一个过场。

尊非最后还是得死的，不过导演给的那个想象的空镜弥补了一下观众的心情。然后又在结尾用上面那段话来开导观众，总不至于陷进去出不来了。

这部电影其实让我印象最深的不是情爱或者底线不能干什么的。

而是尊非和他几个哥们的那种情义，分钱，哥们没分到，拿我的。拿到了，叫哥们一半自己花，一半寄家里。

这是好大哥，还教做人的。

他要下赌船，也顾着每个兄弟，虽然有点假仁假义，但那种江湖义气的感觉就到了。

这也是为什么，耀武会冒死救尊非。

耀武的演员选角很好，我第一眼就觉得他是个铁哥们。虽然中途他被小坑了一下，但他却比尊非还要懂得这种江湖义气。

尊非只是做着，但他不懂。而对于耀武，江湖义气就是全部。

这种江湖义气，很难概括。以前港片警匪片，黑帮片里多又见到。所以一下子想起来以前看港片的时候，我是泡在港片里长大的。

另外也是豆瓣评分不能全信。起初我上豆瓣一看，6分，妥妥烂片。但整体下来，还不错。特别说粤语的时候那感觉就来了。

我喜欢这部影片，它让我想起从前。这么说就显得更老了。

我一个人来，一个人走

Sat, 17 Aug 2024 00:00:00 GMT

最近在看葬送的芙莉莲，它碰到我以前看玄幻，看凡人修仙传动漫时的想法。但都很轻微，可能是时间过得越长我的感触越藏得深。

十年连我目前人生的百分之一都不到。

科普一下，中土世界的精灵设定和差不多是神一样的存在，除了被非自然的死亡或者无尽的悲伤，否则会永存于世。另外也有一种狗血的说法，当精灵爱上普通的人类后，也会变得平凡。

芙莉莲是幸存的不多的精灵之一。所以她不会变老，没有时间观念。实际上我也很羡慕的，无忧无虑地睡回笼觉，睡午觉，一觉睡到正午。因为我对在想睡觉时能够一直睡觉的感觉深有体会，睡眠这东西，我是不嫌多的。

无所事事，在森林中一待便是上千年，精灵性情平和，追寻自然之道。

当死亡不存在之后，其实大部分的焦虑也会消失，但我也没能知道永生的焦虑是什么样的。

芙莉莲在一千多岁的时候（辛逝历前50年）和勇者一行人成功讨伐了魔王，耗时十年。

两个人类，一个勇者，一个僧侣，一个矮人战士，以及芙莉莲是精灵魔法使。

寿命大概:勇者【蓝毛】<僧侣【戴眼镜】<矮人<精灵

普通人寿命<僧侣加成数十年<数百年<???

他们在旅程结束时，庆功夜正好碰上五十年一遇大流星雨，芙莉莲说着要继续收集魔法等下次再带他们一起去更适合看大流星雨的地方后直接就走了。

「我偶尔还会回来看你们的」。

「...」每个队友都知道芙莉莲记性很差，但果然后来五十年间一次都没再见过她。

出去游荡了一阵子，回来后勇者已经是个老头子了，看完大流星雨直接闭目走了。现在回想起来有点伤，好像勇者就是为了活着再见芙莉莲最后一面才撑着一口气似的。

「勇者和芙莉莲」还是cp来着，意识流cp。在勇者下葬那一天，这一天时辛逝历元年。芙莉莲才突然后知后觉地意识到，她还没有好好地了解过勇者。以及好像已经太晚了。不得不说她的反射弧真的很长，也正因如此，她真的很可爱。

从那以后，她看到的永远只是勇者的雕像，她的cp也永远只在回忆里。

这一幕里他们都很年轻，相处不过短短十年，对于芙莉莲，这不过短短一瞬。

「为什么不收个弟子，路上也好有个人陪伴？」矮人这么问过芙莉莲。

「弟子什么的，反正只要把一身本领交给他也会很快死掉」芙莉莲。

「人际关系可不是这样的....」矮人。

辛逝历十一年，大概这个时间吧我也记不清，芙莉莲被僧侣海塔设计而收下了肥伦这个弟子。

说是肥伦是因为小时候她真的很圆。

肥伦长大得很快，跟在芙莉莲身边。可以说咻的一下七年就过去了，小时候可以当女儿，长大了就可以当妈妈了。

也是肥伦让芙莉莲理解了，人类的时间观念和她真的很不一样，她在每次试图动辄花费半年数年时间来寻找一样东西的时候，会下意识地看看肥伦妈妈的脸色。

时间的脚步为肥伦慢了下来，芙莉莲的世界里终于不是前一秒开裆裤后一秒拄拐杖了。

但即使慢下来，也依然是在走的。肥伦终究只是人类。虽然芙莉莲白发人【还真是白毛】送棺的经历不在少数。

但避不开的是，肥伦会老，而芙莉莲得看着她老，肥伦会死，芙莉莲估计也会看着她死。从芙莉莲在勇者葬礼上意识到自己应该多了解别人的时候，当她决定努力理解别人的时候，她就同时得为理解的人的死而伤心。

虽然十年不足她人生的百分之一，但那十年却改变了她，或者说勇者改变了她。

那么当肥伦也走了，当芙莉莲又只剩下一个人的时候该怎么办？回归自然吗？但接受过了肥伦妈妈陪伴的温暖只会觉得以前相处的融洽的自然显得冷清薄凉。但是分别又是难免的，她又不得不一个人，背负起这一切一个人，就像她背负着勇者和肥伦一起走一样。是不是得失去后这只上了年纪的精灵的反射弧才会感觉到？

最后还是得一个人啊。

逝去的是微不足道还是弥足珍贵？

这是悲观主义的界定线。相信记忆是虚无还是存在的重量？

叔本华的观点大概是「已经逝去的就好像不曾存在过的微不足道」。

但我依然在想，这样的瞬间，应该被更多珍视。但是真的要一个人一直背负过去，我还不太确定。但我觉得，借用日常的一句话。

我们所度过的每个平凡的日常，也许就是连续发生的奇迹。

这样的瞬间/日常，应该值得被珍视。虽然作为人类的我，时间总还是往前走的。

我一直觉得独处时更容易找到自我，但如果存在这样的人际，也许更容易找到「真物」。

本物が欲しい

《食神》后

Tue, 13 Aug 2024 00:00:00 GMT

换了一个海报哦。

集大成之作，一个半小时，但是看得非常专注（很多其他电影通常大半时间在游离）。

有点哲学意味但导演都没有深入探讨，点到即止，这里我提出两个，都是周转变的地方。

一碗饭见证的改变

第一个是从周对八三年八二年红酒计较很多，拿错后拿人发泄情绪。

后在庙街里，吃莫的一碗叉烧饭，说，这碗饭，好好吃（houhousi,粤语更带点情感啊）。

非常难过的人可能不会哭，但会因为被人安慰到痛处而不停掉眼泪。

回去截图，发现流了一滴泪，只有一滴。细节。

都说哭戏难演，实则是难过难演。

再认识一个人是从打破外表印象开始的。

第二个是颜控的问题，周最初被莫亲了一下，是对着镜子拼命擦的。即使在街上其他人口中得知她从很早以前就喜欢自己，周还是难以接受。实际上，我的心理最初也是跟着他走的，尽管有点动摇，但是没动摇到颜控的根本。

直到把事物本身撕碎给人看，才终于一瞬间让我跳出了外表这个坑。那一瞬间涌上来的悔意，和想起来她先前的一碗饭，一次用手挡刀。我才真正认识到内心所想。颜控是病，生来偏爱可爱的东西，这没错，可爱的事物给人亲近感和好感。但是如果只停留在第一印象，那么，可能永远，也不能算更进一步地认识一个人。导演用莫的"死"把这个理撕出来给人看。很高超，没有任何多余赘述，一张纸片，一首歌，最后的一碗饭。没有一次给出，而是层层推进。

我可以接受平庸，可以接受缺陷，但是我依然有我的底线，比如这个，我就顶不住。

感谢这部电影，感谢导演。

我喜欢这种无厘头，浮夸，但是现实，喜剧，但是悲剧，但又是喜剧。

一张纸片:

一碗叉烧：

又熬夜了。

23点11分，如果到五点半，只剩下六个小时，只能走跑结合了。

《走走停停》后

Tue, 13 Aug 2024 00:00:00 GMT

「看那么多电影，还不是要回来啃老。」

最扎心的一句话。

当作家，我也想过。直到高中我还在想。

但如果以前有着年龄小所以可能性很多这种借口，那么当年龄不再是优势的时候我是不是就开始收心了？

是的，我有一点。同时我讶异于我以前所有的幻想大部分都只停留在幻想，仅有极少数付诸行动。

而当时间过了，我是否又能拍拍屁股说，幻想的年纪已经过了。而再到网络上搜索一下，会发现不少网文大佬都是初中开始直接投稿，我惊异于我们之间行动力的差距。同时怀疑自己的幻想是不是只是一种浪费时间。

但是如果从这里想的话就又歪了。

「那部电影对我来说并不只是一部电影而已。」

如果说把他们拍的电影公映出来，以国内大部分人的水平，估计给不出个及格的评分。也就是说，沉没的概率是很大的。

但是问题来了，公众的评价是否是评判电影的标准？这么说就懂了，虽然大部分评分差的电影都不值得一看，但不少评价好的电影在我看来也有烂的彻底的。也就是说，公众评价，只是一种参考标准。

而评价，或者说感受这种东西，向来是很主观的。

对老胡来说，那部电影意义非凡。对共鸣者来说，一些常人看来无聊透顶的文艺片却是极致的表达。

我追求的东西错了。

我希望能够远程办公，居家办公。或者直接不用办公。这一点是初衷。

但是渐渐演变就有点偏离了。

因为我需要不去上班->我需要过人的能力->我需要在某方面有所建树->我需要被别人认为是成功的->他人的评价大于自我的评价

这就是一种被现实感染的畸形的演变。让我的初衷变得偏离，让原意是自我提升，变成了追求别人的认可。那么这种追求的错位可能反过来降低我本身。

无迹可寻的成功和有迹可循的自我提升。

普世上任何一个人的成功都是不可复刻的。不管是写作，电影制作，游戏制作，投资...anything。

但成功人士往往会过度吹嘘自己的波折经历，从而来塑造自己的一种坚忍的形象。以及给普世带来一种错误观念，成功是努力的结果。

而这个错误观念带来的结果就是，无数努力的人到最后，或者还不用到最后，中途就开始感到迷茫了，特别是看着幸存者偏差群体的存在，就格外显得自己挫败，看不到自己拥有的。但向前抓，普世的成功无迹可寻。

就像我之前说的，目标错了，首先，成功这鬼东西是公众定义的。它首先就只是一个参考标准。

一个诡辩：

一个老乞丐，住在街上二十多年，街上每个人都认识他，他也毫无抵触地接受任何一个人施舍来的东西，以及白眼。

一个富商，这条街上最有钱的人，但是，你得知死神会在两个月后的午时来找他，他得了肺结核。

如果你选择，会选择哪一个？乞丐还是富商，是没尊严地接着活上十年二十年，还是在临死前两个月肆意挥霍？

普世的意义衡量通常是不可控的，追求普世意义的成功，无异于一种赌博。赌博这件事本身就可以单拎出来讲。

你追求失败后的失败经验总结，不一定指向的是成功；而成功者的自我吹嘘，也不一定指向成功。从来不由哪条路标明了它指向成功，越是把它当作目的，可能偏离得越远。

在我看来，自我提升还更有意义一些。

但自我提升也面临另一种境况，就是，如果终有一死，那么自我提升的意义和价值体现在哪里？

有意思，有意思。暂时没想到解法。

潘多拉的盒子

Sun, 04 Aug 2024 00:00:00 GMT

我昨晚咯血了，前一天晚上也咯血了。

没有任何理由，也并不是突然觉得生命变得珍贵了，只是因为到昨天为止的勉强的伪装消失了而已。

这里咯血患上的是肺结核，在当时应该是无解的，而现在结合是绝大部分可以治愈的。

虽然我好奇书中那个神奇的建康道场究竟是怎么用自然疗法让那么多人痊愈的。

但这里只是提一下，突如起来的威胁生命的疾病会撕下人对生命意识的蒙板，却也会让死亡更加无所忌惮。

这里刷新个人对生命的意识，大概会引起人格上的大转变，心理学上这种案例不在少数，而书中的主人公也在进入疗养院后由沉默寡言变得健谈。他也说自己好像变成了一个新男性。

虞美人草后

Wed, 17 Jul 2024 00:00:00 GMT

注意力是稀疏的。

前半看的纸质书，陆求实翻译，后半是电纸，茂吕美耶译（相当难记，看过一遍就忘的名字）

我不得不说我对纸质这一媒介的接受度越来越低了，习惯了电纸阅读。也许是纸质字号太小，每一段几乎都只读进了第一句，前半本让我能集中注意读的仅仅四五处。而进入后半，注意力就很集中了，可能有译者的影响，另外剧情密集度也不能忽略。

前半相较琐碎，也没有刻意像剧作一样交代人物关系，理清系公（系子），鸢尾，甲野，小野，宗近的人物关系很费力。

另外我中途也抱怨这部作品的该在对话前面表上A. , MJ这样的标识，对话每次一进行就很长，尤其是开场时宗近和甲野的对话，完全没插上人名。前半注意力稀疏的我，就连一句话是谁讲的都分不清，狐皮背心究竟是谁穿的，也是待到将近结尾才搞清楚。

这是一部妥妥的戏剧。

我对戏剧了解不多，看过的屈指可数，威尼斯商人，三岛写的几部。这里借着《挪威的森林》中读古希腊戏剧的渡边的话。这部作品就像欧里庇德斯，在剧情的最后会出现一个角色，把原来看似解决不了的问题全部解决。这本小说中宗近就是那个角色。但这又是合理的，所有的问题的缘由只是出于小野的纠结和爱体面，而宗近却不折不扣地率直，而且相当随性，一切的问题只要一次坦率就能解决，但在小野的视角里，我却感觉无论如何都进退两难。

先提一下这部作品的总体印象，后再挑一下我格外在意的地方。

在译者的序言里面提到了这是夏目由教职转到了全职小说家后的第一部作品，写得完全算得上是恋爱小说，由于刊载数量变多，他压力也激增。似乎这部作品并不在他所有作品里占有有力地位，相反在学界还觉得这部作品很差。

巧的是我看过为数不多的戏剧里有威尼斯商人，这两部给我的感觉极其像，更巧的是我上一部小说看的是《心》。更早以前看过《我是猫》。

就看过的夏目这三部作品来说，可以推测他的作品受众是相当广的(几乎所有的东方人)，以及它几乎完全不受时代的限制。读中国很多现实主义作家，在缺乏时代背景的情况下，是很难读的，而且很无聊。我不怎么读中国文学大概也因此，太沉了。举一个不受时代约束的例子《围城》。（也许有人觉得它小家子气，但我喜欢这样的。）我不喜欢很多一讲立意动辄家国往上的人，虽然《古剑三》中"星火相传，奋飞不辍"会让我动容，但我更多还是考虑和反思自身（大概感叹了下我的一一生相对于千秋百代而言太短了。），"小家子气"和"大格局"只能说是着眼处不同，我更喜欢观察作为人的自身，不管时代地区如何，所以我"小家子气"，甚至有点抵触"大格局"。我身上也许有些问题也许和一百多年前的人毫无差别，就这点而言，是无需谈论时代的。所以，这么说来其实作品也不一定总要反映时代的问题。作为个人本身就已经有太多问题了。

夏目的三部都有反映——扭曲又自我矛盾的人的身上存在的某些自己察觉不到的劣性，与可能的解法。

在《虞美人草》中，这个解法由宗近给出，在《心》中，先生选择把问题永远埋葬。但读者也会自己剖析，循着作者的暗示给出自己的答案。

很有意思，如果说《心》和《虞美人草》两本单独而言我只会说推荐，四星，但把它们放在一起，我最近同时看了这两部，它们有相当的关联，我就会说，力推，五星。

更巧的是两本读时我都是前半不知所云，后半才集中注意力，也许它们在我的脑中以神奇的方式拼合在一起了。

很多的作者总是不断地，孜孜不倦地，下意识地描绘着相同内核的故事。导演我也知道若干（是枝裕和），这像是情结。

在《巴黎评论》中，提问者对村上的作品进行的概括大概是：一个男人失去女人（或者一样东西），并且他在失去后总会开始找寻，因此改变，可能会在两个世界之间交替。并且通常在寻找的过程中会有另一个女人来帮助他。相比于失去的女人，这个女人会更加活泼，热情，而且举止毫无拘束。而被找寻女人则相反，她可能冷淡，遥远，宁静。

村上也认可这样的概括，这样重复的描写，在作者一部部推出作品后读者常常会认为是黔驴技穷。但是，夏目在《心》和《虞美人草》中描绘的问题大抵一致，而且两次的描述使得其更加清晰，并且也试图解决。

人们总是无法抓住困顿自己至深的问题的全貌，或者忧心着那根本无法解决，而夏目和大多重复着叙述着类似的事情的作者们的描写并非重复，而是探索，如果能够一次性阅读主题关联的几部的话，就问题的困顿而言或许会有帮助。当然作为小说，故事性不能被忽略，而《虞美人草》除了琐碎也没有别的缺点了。

我有点懂了为什么三岛写那么多剧本，戏剧是最简洁明了，堪称大道至简的小说形式，反映问题反映的暴力直接，而且不带作者观点。而悲剧总有一种魅力，甲野文本末尾的一段话可以作为参考。也许我到了可以读莎士比亚的年纪了。

我格外在意的部分。 - 也许我该去入赘

抛开我前面隐约谈到的人性需要的率真和活在世间需要的体面的主要矛盾。

我不得不说，系子时一个令我很意外的女子，不管时鸢尾还是小夜子，她们都只是剧作中的角色，她们的行为和性格是可以放进常理和条框之中的，我可以简单地说，鸢尾是个粗暴和玩弄别人感情的女子，而小夜子是一个单纯，柔弱的女子。但是对系子我不能简单概括，也不能下定论，但她又那么简单，单纯，这里涉及到一点，她和甲野谈到的"不嫁人，保持不变比较好"，"你这样一直无忧无虑。"

1.她有慧根（这此在佛教里似乎是指她能够顿悟，聪明是有的，但更多是纯真。）

我格外地在意，她和甲野关于"动了就会变"，"离开父母和哥哥就会变"，"会变聪明"，"还是不嫁人得好，一直不变就很好。"

"我不想嫁人"

我当时也确实感受到这段对话中系子的纯真/不得不说甲野哲学家的名头不是随便叫的，他是一个真正的哲学家。哲学终究不能同文学混为一谈，文学家常常苦闷境况，或者感伤，但甲野那分无所谓处境的念头是真的超然。文学家比起哲学家还是要更加讲求现实和实际一点啊。

我觉得系子在那次对话后变了，就像菩提树下顿悟，她跳出了作者设下的角色的设定，从一个"天真浪漫，无忧无虑的妹妹"变成了一个"决定一直天真无忧的妹妹"，不是变聪明了，而是更清楚更明白了，从原本的懵懂，到决定能够一直一成不变下去就好。

如果能够定格美好，那也是一件值得动容的事情了。

于是，我也难以一言概之，她究竟是怎么样的人，但无论如何，我喜欢她这样。

另外，我也仍决定甲野那番话值得多琢磨，人保持一成不变是件好事情也说不定。（也许有人会杠说没有一成不变之人，某种意义上确实如此，但却有越来越纯粹的人，比如放下我执的高僧）。

要不，我以后去入赘吧，为了能让对方保持不变，而不因为动而生变。

虽然初看的时候注意力涣散，但行笔至此，我觉得夏目不再陌生，只是一个名号。可以说心和虞美人草中我想要的部分也嚼得仔细，还回味了一番。

人的意识和注意，难说难评，记得的总是喜欢的，看到的也总是容易记得的。正因这神奇的机制，才会有这么多有意思的作品吧。

少年巴比伦后

Mon, 15 Jul 2024 00:00:00 GMT

当实际的联系不够紧密时，人们会寻求肉体上的补偿，好像是一种确定。

但我更喜欢薇薇安，肉体只是附加的。

如果说去西藏是很多文艺青年的梦幻旅程，那么在二十岁遇见你就是我的奇幻旅程。

我喜欢这样，想着世界上还有像白蓝这样的人，好看的人太多，有趣的人太少。但只要她们还在，哪怕我没有遇到，也是一种安慰。而且大多时候这种有趣，都和时代格格不入。简单说，显得特别，超前，在当时的人看来也许会觉得惊世骇俗。

最终八个小时半看完。作者写的故事我都看得很有味道，尤其和白蓝相关。但他最后没头没尾地写了一首诗。我大概是没有读现代诗的细胞的，刷刷就过去了。我大概注定不是个读诗人，但我看故事却是很有感觉的。感谢还留给我这么一个消遣。

我记得有个成名作家他女儿写诗出版了，写得并不好，或者说像是流水账，但她还在想着出版更多。她老爸对她有不满但又没指明。路小路多次提到天赋这事，没有写诗的天赋不能怪她，而且没有对诗审美的天赋也不能怪她。但又不禁想起鲁迅那边说的不要当个口头作家。

这本书写错过，写怀念，但大多都是发生在路小路十九二十岁之间，而我现在十九周岁了。上了一个不上不下的本科，读着一个让人摸不着头脑的专业。想着我已经不再年少年轻了。实在有些惭愧。我花费太多时间来考虑这些东西。

我能不能碰见"白蓝"呢？不是说性格一样，虽然我真的喜欢冷淡的。但是，能不能让我碰到简-爱呢？碰到一个能够以灵魂相对谈的人。

不得不说这个作者的痞子味很有感染力，我讲话也不由得装腔作势了起来。但我这只是假痞，终究比不得真的。

《汤岛之恋》

Mon, 15 Jul 2024 00:00:00 GMT

我记得在第一次看雪国的时候，全书吸引我最多的应该就是驹子的话，有种语无伦次的美（应该是我措辞不当）。

她对于男女之事的毫不避讳，以及调侃。以及时不时会没头没尾地说上一句"真冷啊"，"傻瓜一样"这样类似的话语，就像池塘里鲤鱼倏地跑出来吐一个泡泡那么可爱。

在雪国中，岛村对驹子的形容是，洁净，白皙，脸红时会从脸一直红到脖子背部，好像是什么可爱的动物。而汤岛之恋中提到蝶吉拒绝一个军人的调戏并且打了他一巴掌，被人追逐时躲进唱戏团里蒙混过关时也同样给我这种感觉。天真，浪漫，似乎时艺妓的最可爱的特质。

以及驹子曾经对岛村说过，每年都要来看她，只要见上一面，待上一阵子就好。而蝶吉也对神月说过，哪怕他不能娶她，她不愿给他添麻烦，她可以养他，她可以做一辈子的艺妓，只要他不抛弃她就好。她们的痴似乎是一样的，而一个在东京，一个在雪国（也许是北海道，或者京都，但雪国总是比较贴切的）。

另外也有一点，蝶吉，驹子的爱是超越了性的。

在蝶吉和神月同枕共寝的时候，大学士神月欲火焚身，只道还保留了一丝理智，如同冷龙护体。

而碟吉却相反：

某天清晨，蝶吉忽然醒来，摇醒迷迷糊糊的神月，惊讶地环视四周，向神月讲述了她的梦境。在梦里，她手里握着三束含苞待放的菖蒲花，站在黑暗里，周围忽然明亮了，阳光照射进来。一沐浴在金黄的阳光下，眼见着三束菖蒲花瞬间一齐绽放。这是为什么啊？她天真烂漫地问神月。神月正被噩梦魇住，在幻境中深受苦难的折磨，冷汗直流，听到这个梦境，心生羞愧，面红耳赤。与那朵出淤泥而不染的圣洁白莲相比，自己的心反倒肮脏不堪，学士这才深深懂得了碟吉那颗洁白无暇的心。

可以说，理智和性欲本能并不是一个变多了另一个就能变少的。

汤岛之恋这一方面给了我一个重温旧梦的机会，以前我曾经拜倒在驹子裙下，如今再次发现我爱上的也许只是像蝶吉和驹子这样，天真，洁净的少女。但是，她们又同样坚韧，那样驹子才能在冬日里弹出最清越的三味弦，蝶吉才能从包身艺妓的遭遇里幸存且保持完好人格。

她们懂得世间最高尚的爱，大概吧。

最后期限

Wed, 10 Jul 2024 00:00:00 GMT

应该是大一时跟图书馆借的第一本小说。后来用ebook后再也没去借了，反倒有点怀念。

就从笔记本开头写起：

不多废话，这个笔记本是用来记录和看书有关的东西，尤其是观后感，虽然我也很想拥有像小隐那样规整的读后感笔记，以往我也很多次尝试去写过，但都很少写完，大多是中途跑去做别的然后就这么搁置下来了或者把本子拿来写别的，哎。

看书很多时候，或者说有些时候可以让我在玩游戏和学东西（work）之间冷静下来，并且也让我大脑不一样的地方活动起来。而并不是学完东西打游戏，打完游戏学东西。那样反而会陷入一种固执，而阅读是很好的松弛剂。这段时间里面可以什么都不考虑，也可以考虑一些跟生活无关的，不切实际的东西。

《最后期限》汤姆-迪马可

#意外的相遇：

碰到它是一个意外，也是缘分，我在找的是和它同名但不同作者的一本书，但委托借到后，我才发现，这是个愉快的错误。

最初我看到封面上标签项目管理书，又是小说，就认定这又是一本业内人士试图表示自己的专业知识，但又想要写得接地气，而写得不像样的小说。

#吸引我的点：

但他很好地抓住了我的胃。有3点

可爱的，诱人的朱利安女士，同时又是绑架犯，反差萌。

我承认我对于这本小说最初的喜爱是建立在对女性角色的喜爱上的。

它是关于软件工程的，关于程序员合作项目。【我感兴趣】

不得不说现在我的思维也有点程序员化了，而我需要跳出这种思维的机会。

我熬过了开头的20分钟。

在刚刚开始时也许时太久没看小说，缺乏代入感，脑子和视线接不上，犯困，但过了二十分钟后，我就 get into the zone 了。

很多时候一本小说只要约束自己打开阅读二十分钟，它可能就会展现自己可爱的一幕。

在那个时候看书才是享受的。

#一些摘抄和归纳：

下面是一些笔记，有的是归纳的，有的是直接摘抄的。

关于一个软件项目开始后随着时间流逝凝聚起来的压力应该如何应对。

压力其实一直潜伏在空气之中，可能会在成型时打的人措手不及。
项目刚刚开始的一天和临近结束的一天实际上是等价的，但是我们起初悠闲后来急迫。（心态上，最初就太过于放肆了）
解决压力的最好办法就是在它成型前就掐灭它，治人于未病，提前做准备。提前完成。但是，不要一直保持压力和紧张，一时的压力看似能解决不少东西，但长期的压力只会扼杀人的思考。
保持玩世不恭，学猫，学像猫一样的蒙洛多程序员，不管外界如何要求和压迫，我只先考虑完成最低限度或者，保持自己的意见，而尽量不要学韦伯那样，面对文档中的铺天盖地的要求而头晕目眩。
一次只完成一个目标，不要试图一次调试两个bug。
珍惜一个项目完结后那种浑身一轻的感觉，并且在这之后，记得整理收获和经验。项目的结束并不代表自身的结束.

--- 但愿我们能够阻止生活中的贝洛克出现。（无尽的，喋喋不休的甲方）

Ps:

胡利安她说"他一定是想我了"的时候真的好可爱。
韦伯每天晚上坐在案前写经验和笔记，虽然只是作者向我们科普的一个路径，但是他对记者说：**"这本笔记我不会再翻开，但那101条原则已经烙进我的意识里。"**真的很帅。我写博客，大概也是同样的心情。

所以我也不禁考虑起自己写这本笔记的初衷，也绝不是为了反复翻阅而去写的，毕竟写过一遍，该记住的已经记住了。

同时我觉得用这样的阅读，写观后的流程也有助于我阅读的连贯性和思考，同时也有助于我养成一个良好的阅读习惯。

wtf，自从用了ebook再也没动过笔了，我也同时怀疑自己是不是再也没有动过脑。

# 设计，让代码有如"神"助

《最后·期限》很掐我的点，程序项目，时间管理，人力资源，以及一个有魅力的绑架犯小姐姐。

这里说说项目提到程序设计相关的东西。

亚里士多德认为编写程序之前的项目模块设计很重要，甚至值得花大部分的时间去做.

正常人所认知以为的这里所说的设计应该是指：

功能-> 结构->实现。一个从结果到底层的一个逆推和细分。在编写项目之前应该就要对每个部分分别做什么，每个部分功能和实现了然于心。

但是只是对功能实现的设计还不够，还不是终点。真正的设计是在程序编写者心中的，当前要实现什么代码模块，它的伪代码应该是什么样的，最终的编程只像是把拼图放在合适的位置。这样几乎能够完全省略掉调试的环节，每次只实现一个小代码块的功能并验证。而我经常一拍脑袋写到哪里想哪里，经常的我陷入到了一个特定的实现带来的bug中，我不会想着换另外一种实现，而是会为了debug把很多东西都改一遍直到正常运行，但这次的修改不仅浪费了大量时间，还可能又让一些部分偏离了原本的设计。

我觉得，亚里士多德真正要想要强调的，只是我们在编写代码的时候同时具有另外一种视角，当我们陷入Bug的时候，我们会知道更换方法而不是死磕。实现的时候，而是像是有一个拼图的背景在指导我们这一块应该是什么，下一块应该是什么。

他所强调的设计，应该是上面说的那种视角，和拼图背景。如果说写代码有如神助，那么这种视角就是那个神。

我目前可以说编程习惯很不好的，都是想到什么写什么。也许我该学学，在心里写伪代码，试着推理下一步和这一步。然后再推衍全貌。

没有一个程序的编写离得开这种设计，不过，大部分人习惯在一边敲代码一边设计，这就有点像下棋了，有的人看得多（全貌），有的人看得少（局部），有的人能一下预测十几步的落子，有的人只能看见一两步就停下来了。

而我是典型的局限又短视者，之前我对自己的编程习惯冠以潇洒的名号，但在碰到较大项目的时候，每次加入功能都可能牵一发而动全身，需要反复修改所有代码而不是只修改局部功能让我感到我需要改变。也许我需要规范，也需要看得更远一些。

设计就是有意识地去预判棋路，不过没必要看出所有的情况才敢下出一步，那样时间肯定不够用。而只需要，看出一条线性的，能达到终点的路即可，至于如何优化，那是到达终点后考虑的事情，一边试图优化一边写还未成型的功能是犯了大忌，最终花的时间究竟是写功能多一些还是调试优化的时间多一些？

有意识地预测一种可以到达结果的目标代码块，如果可以，也可以预测两种，留作备案，当一条走不通先换另一条，而不是立刻进行调试和debug。不少人选择一开始脑袋一拍直接开始编写，实际上，直接开始编写可能造成的错误和最终反复调试，测试的时间，会远远超出预测耗费的时间。另外，没人会喜欢反复运行，反复排查错误的原因。能够一气呵成，何乐而不为。

另外一气呵成也并不是说我所有都写完了再运行然后一次通过，这个是不可能的，总会有偏差和bug。而是每次将预测到的代码块一次编写完成，然后运行，一次通过，并且能够达到自己的预期功能。并且只有在验证完功能后我才会进入下一个预测和编写环节。

#印象最深。

在一个项目刚刚开始的时候，危机是存在的，目标是明确的。危机感是薄弱的、堪称惬意，目标感可谓全无，几乎可以称得上漫无目的。
目标感是一种积极、兴奋的心态。
我们常常有目标，却缺乏目标感，因为我们实际上认知的目标只是"应该做的事情"，而非"特别想做想实现的东西"。

#番外。

关于前两天那个UI的故事，最初的分工是室友去写UI，我去写功能。一周时间，星期五要答辩，星期四下午的时候他给我一份能运行但是我相当不满意的代码——

他说他要好好学学写UI，开始的时候夸下海口说要好好写美化。但最后交给我的，美化是一点都没有，画了几个框，做了几个控件，然后把函数丢进去，就这么结束了。

另一个是关于速度，软件要求中多处涉及到拍照，人脸识别，总之就是要打开摄像头的部分。他按键点下去，开始初始化摄像头，当需要另外一处需要摄像头了，就stop前一个，释放，然后再初始化另外一个。然后初始化摄像头用的是 :

self.camera = cv2.VideoCapture(0)

这个函数每次执行都要三秒以上。也就是说，我点击打开摄像头，等待四秒，点击开始识别，又等待了五秒。一个控件响应要四五秒，而且还是单线程，响应过程中窗口不能接收Message，不能执行任何其他操作。

我当时就快吐血了，我跟他说，你就这样子，什么都不优化一下。他就说一个设备摄像头只有一个，同时初始化两个就会闪退，只能停下一个然后打开另外一个。还给我演示了闪退的例子。

当时是星期四下午了，我跟他说再优化优化或者美化一下，他说优化个马，能用就行，要优化自己优化，然后一回去就打开LOL了。

我只觉得他前后落差很大，美化也不做了，优化也不优化。

最后我还真自己上了，这里就可以提到目标和目标感，与任务和应该做的事情之间的区别。

对于他来说，最初的目标是有的，兴奋感似乎也有点过头了，但后来却只是把它当成一个任务，没有实际的目标感，只是完成最低限度。

但我这边相反，我对UI美化是有执念的，或者说我对二次元是有执念的，我自己写的，必须带点二次元。于是我去给它加了背景图片，加了logo，加了icon，我在写这些时，一般都是额外部分，具体要做什么可能并不明确，但拥有目标时那种积极和兴奋的心态是一直有的。

速度优化那边我程序启动时初始化摄像头，后来全局地使用它，最终除了启动需要四五秒其他控件响应都是即时的。

我称自己那种目标感的状态为写自己的东西，当我试图写自己的东西时，这个东西和别人的要求无关，只是我自己想要的，二次元美化就是我想要的，这个也是我能够进入那种状态的诀窍，不过这么弄经常没吃饭，对身体不好。

并且在试图写自己的东西之前，一般先做一个垃圾出来（最低限度，之后再在基础上优化），用最快的速度，这样我才有足够的时间来考虑后来应该能够做什么，有足够的时间去折腾，关于室友四天交了一个我认知中的最低限度还一脸硬气地说能用就行，当时真的让我很生气。

春娇与志明

Mon, 08 Jul 2024 00:00:00 GMT

如果在一见钟情的人面前感到的是拘束的话，那么春娇与志明，应该是最没有拘束的了。

想看的是志明与春娇，先看的确实春娇与志明，这样我大概是错过了第一部了，即便再看，也不能如初看的纯粹。

但其实我什么也没损失，今晚本来只是在吃饭，也挺久没怎么认真看电影，想着打开来看看。能够用这一部来开头也很不错。

开头

不过为啥有点缝合感，就是春娇和志明之间的气氛，或者说电影前面一段的感觉，都有强烈的文艺片的感觉，镜头什么的都很随意，聚焦也很随意。刚刚开始提到曼迪（春娇挚友）的克夫事迹，非常有无厘头的小说或者电影的感觉。即使春娇与志明之间闹别扭，也都是轻轻松松的。有种喜剧之王里周星驰和张柏芝的感觉。

镜头

到了徐峥这里整个镜头都变了的感觉，变重了，变细腻了，就像从随手用手机拍的换到用专业机位和摄像机的那种落差感。也许是我一心看他的大脑袋了，就是觉得只要有徐峥的地方，画风就不一样了。也许是光环太重了，以及Ben（黄晓明）,我实在是，虽然他口头说着，只是一直有人说他长得像黄晓明，我实在是觉得他放不下，有种不融洽之感。

杨的镜头我看得是最舒服的，以前小时候就看她和任贤齐的《花好月圆》很多次。后来又看了天生一对，我很喜欢有杨的镜头，让我有种回到从前的感觉。不过，杨为什么这么热衷于嫁不出去的女人，不管是花好月圆，还是天生一对，还是春娇与志明。

我喜欢唐伯虎点秋香，武状元苏乞儿，月光宝盒，逃学威龙，和花好月圆那样的，里面的幽默，和笑点，大概构成了我人格的很大一部分。

必杀技

但目前聊的是春娇与志明。我以前几次被海报吸引，也听了歌，虽然没明白和电影的关系。但说到歌，我觉得必杀技和春娇与志明更配。

一句为什么不找找你，我练到在倔强，再绝也

永没法比

求你别要如从前纯熟地碰我

而我问我为何还能够碰伤我

在志明一次次找春娇的时候我一次次想起这几句歌词，原来歌词唱的是真的存在的啊，我这么想。因为我没看过志明与春娇（第一部），而直接看春娇与志明（第二部），我当时只觉得志明有点烦，相当地烦。

但是，我觉得他烦，又是因为他像我，这让我从心底感到焦躁。长不大的这一点，他说自己从中四之后就再也没长大过，我似乎也是如此。高中时自我得很，一个劲地看小说，好像从里面看出我不用参加高考的理由，那个时候我给自己造的壁垒，到现在依旧。不能说一成不变，只是依然自我。

而且还懒了不少，以前至少会做做主题阅读，会好好写笔记，写观后，现在写影评都有点有感难发。

写得不如以前，也许时不如以前中二，当我这么想的时候，我又得承认我不愿意做改变。

当我什么都不考虑只是写的时候，写得才是最符合我心意的。也许我该找个时间慢慢把以前写的码回来，之前因为如果只是搬运的话，就好像现在什么都没有一样。

比起恋爱更想谈的是时间带来的牵绊

我之前有个不成说的理论，就是任何感觉，情感都会随着时间变淡，不管是我看完电影，小说后的感觉，还是对一个人的感觉，当直接联系断了，电影，动漫完结了。不再联系一个人了，这个感觉总是会淡薄的。而且无可避免的，让我一度感到非常悲伤。

叔本华的虚无似乎就是以记忆的这种虚无性建构的，提到，当回首往事，好像什么都没有发生过一样微不足道。

但是春娇似乎就很反这个学说，她喜欢志明，是相当持久的。抛开喜欢，恋爱不谈，他们更像是被什么绑定到了一起。就是绑定，但不是绑死了，而是当你快要离开的时候，系在手边的线提醒你，还有对方的存在。

这是即便，碰到更好更好更好的人，也依然无可替代的。可能是记忆留下的，对方对自己来说已经不再只是喜欢不喜欢的问题了，而是代表了自己的一大段过去，或者说，一大部分的自己。

春娇提到，老头子（徐峥）喜欢的自己的那些有趣的部分，奇怪的想法，其实都只是在不知道什么时候被志明传染的。

这种和一个人待得久了，习性的相互感染，也许会比任何一见钟情都要更加让人亲近。就是，对方好像已经不再只是自己之外的什么人了，而是自己了。

当然那个只是我一种相当自我的阐述。他们的关系可能跟这个完全不一样，因为这种牵绊同样让他们痛苦，春娇在电话里说的，我很喜欢很喜欢你，但是你别再来烦我。

为什么呢，这么复杂。

老头子不坏，简直无敌，我中意的很，还很幽默，但为什么他就得一个人承受呢？

青春同人志

Mon, 08 Jul 2024 00:00:00 GMT

第一次看电影全在截图了。

不知道之前听谁讲过，长得好看的女孩一般像爸爸多一些，长得好看的男孩一般像妈妈多一些。

中性的美之前在林青霞那里体验过一些，但那个终究还是古典的，审美还是没法直接接轨上。但这个女主是直接把车开我脸上了。

"将小说人物和真实人物的世界加以融合的短故事。"

这里指的是女主写的同人小说，现实小说交替的想法不错。

小说整体背景和《Sayonara Wild Hearts》差不多，有点讨论女性主义和跨性别的意思。不过游戏里女主应该是想不开而做一个假boy，最后和解的时候以女性的姿态坐着弹吉他结束。其实还是有点没有拜托性别局限，虽然说是good ending，作者中途磕了那么多药，还是没有跨过那条线，可能也是考虑一个大众取向。

而电影里面的女主则是，我最爱的类型，暴力倾向，冷淡，生人勿扰。在结局的时候她依然保持这样，我描述的不准确，应该说，在发现自己是个"男孩"的时候，她的那种无处宣泄的怒火才终于消失。

除此之外感觉并没有更多可以谈的，因为电影的剧情本身有点单薄。

不过马克斯这个角色倒是很有意思，一开始，他让我感觉有点烦人，喋喋不休，好像总要别人关注他。

而且总是嘲讽女主的着装，有意无意的，想要让她换回原来那样的。

但是挺多细节后来让我对他改观很多，第一个是在健身房里，看到女主被网暴时的愤怒，我才终于意识到，oh fuck，这个人喜欢女主。而且还是石田将也（声之形）那种喜欢。可惜女主是个大木头，而且攻击性还很强。

不过在女主和男生争执并且被打的时候他把女主硬按回座位的一幕挺有感觉的，他和男生对峙的一刻我才知道原来健身房的伏笔埋在这里了。

而且这个场景和后来男主扔下女主而跑路相比（他被混混打得住过三个月医院所以看见这种场景就怕得要死。）又是一个伏笔。

我只觉得马克思有点像我，尽管我不是很想承认。

我们都有缺陷，马克思不懂表达，男主又很懦弱，尽管事出有因。但是，最终还是只想和待在一起最舒适的一起，愤怒的明星和灰姑娘，因为一句"你的指甲很漂亮"结缘，在他们永远在一起中落幕。

说实话，电影很肤浅的，但我一门心思全在截图了，所以也没有太在意。

最后再挂几张。

《以一年一萬元的價格》后

Mon, 08 Jul 2024 00:00:00 GMT

先来讨论两个番外。

即使是过去分文不值的人也能够露出未来一片光明的微笑。

这是第二集中那个"人贩子大叔"和书店店长的互动中店长对他说的话。我不太清楚那个小女孩和那个大叔是什么关系，因为这种不明的关系，我暂且将他成为"人贩子大叔"。

小女孩提到如果有两个选择，一个是三十亿日元，一个是和大叔在一起，那么她会选择后者。以及在大叔提到能够给她买冰激凌以外的想要的东西的时候，她提到了妈妈。这一点有点深。

那么我给它一个假设。大叔会因为小女孩而转变，并且过上"光明"的人生。

作者借这个番外和大叔的话瓦解了我最初的一个疑问。如果有机会得知我的未来是i什么样的，分开讨论好坏，我是否会选择卖掉寿命？

大叔提到了一点，尽管现在缺钱用，但是如果他的未来潦倒，我也不能指望卖掉它来接济现在。而如果未来真的非常值钱，那现在的潦倒便变得没有那么难以忍受。也就是说，无论如何，卖掉都是不可取的，在他眼里。

这个应该是漫画化时画师的想法。

尽管避免对别人产生好感，也无法避免所有。

毫无感情的三十年也许不值得过，不值最后相伴的一个月，不足最后无所牵挂的三天。

和某人的邂逅，联系，总会是改变我们的契机。

这个是第三集宫城的视角中我看到的。

也许是人类总是无法忍受孤独，哪怕面对明知命不久矣的人，还是无法忍住地去倾泻自己的情感，哪怕之后会面对更加强烈的孤独。每次都下定决心，每次都忍不住。

也许宫城没有碰到楠木，会毫无感情地度过三十年，不因为别的，只是因为别的监视对象也许并不都像楠木和那个女生那么好相处，而自己又只是透明人，如果孤独也算情感的一种，那唯一的情感也许就是孤独了。然后在时间结束后，年近半百地开始人生，怎么想也不会是一个好的开头。

而和特别的某人的相遇也许总是会成为她改变的契机，即使年近半百。

而从结尾来看，她在被楠木几乎还清了债务后，再工作过三年后，也过上了充实且光明的人生，余生很值钱。在那个时间线的她选择售出自己的余生。而选择与楠木度过剩下的三天。但是另一个时间线，被她出售掉的人生中，也许她遇到了另外一个人，并且楠木也只是成为了回忆。

从这一点来想，无论如何，任何人之间的距离拉长，他们的关系也总会变淡，强烈的情感的维持是需要代价的，这个代价也许是从此不再对任何人产生任何情感，而这点我们在上面讨论过，是不成立的。

而真正拉长距离的不一定是空间，而是时间，直子和木月。分隔在两个时空。

也许我不该避免邂逅，自我学习和自我改变是存在的，但我也想被美少女拯救啊。在 [[没有明天的我们，在昨天相恋]] 的结尾我好像也是这么说的。

我自己的想法。

想起来先前看的一部日系轻小说，《恋爱要在模拟后》。这本书的前半非常好看。它描述了主人公可以通过模拟器来提前地对可能产生的未来来进行一个模拟。甚至可以从每段模拟中提取所学到的经验。主人公可以提前地预知一些事情，前两段恋情深度很可以。

即使没有触及到存在主义的一个最终关怀，但是也不远了。

那个最终关怀就是死亡。

在《三日间》中提出过，最后的三天，也许比被卖掉的三十年，比原本剩下的三十天要更加有价值。

对于这个看法我不表示反对，但也许内心深处也会存有只要活着也许就还存在转机的这种对个人主观能动性的过分信赖。

我觉得，这个问题应该要放在一个问题之前，那就是死亡，最终关怀。

如果能够直到死前都一直和宫城在一起，比起不知道什么时候要死，于是浑浑噩噩过日子，然后又对要死感到焦虑和恐惧。最后不知觉间或者充满着恐惧地孤独地死去，我是愿意选择三天的。

关于最终关怀应该怎么破解，我也不太清楚，但我觉得它们和模拟器和这部作品有关系，于是我把它们放在一起讲。

如果可以我也想自己写点东西。

Fuwari 博客主题使用指南

Mon, 01 Jul 2024 00:00:00 GMT

本博客基于 Fuwari 主题搭建，使用 Astro 框架。对于文中未提及的部分，你可以在 Astro 官方文档中找到答案。

Front-matter of Posts（文章头部信息）

---
title: My First Blog Post
published: 2023-09-09
description: This is the first post of my new Astro blog.
image: ./cover.jpg
tags: [Foo, Bar]
category: Front-end
draft: false
---

属性	说明
`title`	文章标题
`published`	文章发布日期
`description`	文章简介，显示在首页
`image`	封面图片路径。以 `http://` 或 `https://` 开头：使用网络图片；以 `/` 开头：使用 `public` 目录下的图片；均不符合：相对于 markdown 文件的路径
`tags`	文章标签
`category`	文章分类
`draft`	是否为草稿，草稿不会在正式构建中显示

Where to Place the Post Files（文章文件位置）

文章文件应放在 src/content/posts/ 目录下。你也可以创建子目录来更好地组织文章与资源：

src/content/posts/
├── post-1.md
└── post-2/
    ├── cover.png
    └── index.md

Markdown Example（Markdown 示例）

表格

尺寸	材质	颜色
9	皮革	棕色
10	麻布	自然色
11	玻璃	透明

| 尺寸 | 材质 | 颜色 |
|---|---|---|
| 9 | 皮革 | 棕色 |
| 10 | 麻布 | 自然色 |
| 11 | 玻璃 | 透明 |

分割线

---

行内公式

行内数学公式：$\omega = d\phi / dt$

行内数学公式：$\omega = d\phi / dt$

公式展示

$$ I = \int \rho R^{2} dV $$

$$
I = \int \rho R^{2} dV
$$

GitHub Repository Cards（GitHub 仓库卡片）

你可以添加动态卡片来链接 GitHub 仓库，页面加载时会从 GitHub API 拉取仓库信息。

::github{repo="saicaca/fuwari"}

使用 ::github{repo="<owner>/<repo>"} 代码创建 GitHub 仓库卡片。

::github{repo="saicaca/fuwari"}

Admonitions（警示框）

支持以下类型的警示框：note tip important warning caution

:::note Highlights information that users should take into account, even when skimming. :::

:::tip Optional information to help a user be more successful. :::

:::important Crucial information necessary for users to succeed. :::

:::warning Critical content demanding immediate user attention due to potential risks. :::

:::caution Negative potential consequences of an action. :::

Basic Syntax（基本语法）

:::note
Highlights information that users should take into account, even when skimming.
:::
:::tip
Optional information to help a user be more successful.
:::

Custom Titles（自定义标题）

可以为警示框设置自定义标题。

:::note[我的自定义标题] This is a note with a custom title. :::

:::note[MY CUSTOM TITLE]
This is a note with a custom title.
:::

GitHub Syntax（GitHub 语法）

[!TIP] The GitHub syntax is also supported.

> [!NOTE]
> The GitHub syntax is also supported.

> [!TIP]
> The GitHub syntax is also supported.

Expressive Code（代码高亮）

Expressive Code 提供了语法高亮、终端框、行标记、差异对比、自动换行、可折叠代码、行号等多种功能。完整用法请参考 Expressive Code 官方文档。

Include Video in the Posts（视频嵌入）

直接复制 YouTube 或其他平台的嵌入代码，粘贴到 markdown 文件中即可。

---
title: Include Video in the Post
published: 2023-10-19
// ...
---
<iframe width="100%" height="468" src="https://www.youtube.com/embed/5gIf0_xpFPI?si=N1WTorLKL0uwLsU_" title="YouTube video player" frameborder="0" allowfullscreen></iframe>

YouTube

Bilibili

存在之近，存在之远

Sat, 29 Jun 2024 00:00:00 GMT

死亡之前能做什么？有没有空？可以来拯救吗？

存在之近，存在之远。

一年的时间很长，如果什么都不做的话，但如果你真的要做什么，一年似乎挺短的。或者你意识到了什么。

我已经忘记了高考前自己问"高考后是什么感觉，真的存在吗"那个自己当时真正的感受了，不知不觉就过了两年多。

两年很快，在我没有什么意识的情况下。

而当我想到大三大四后，特别是大四可能面临的兵荒马乱，我一面觉得似乎剩下的一年两年时间也不是什么很长的东西。一面的，以前的未知又袭击了我，工作到底是什么感觉。

这里大概就是，一个人总是会觉得自己当下阶段碰到的困难（一两年内的，近不近，远不远，远的立刻感受不到，近的能带来焦虑）是无与伦比的，难以度过的，除此之外别无其他。

当然有时候一科临考的，但你没有把握的学科也会给你带来近似的感觉，寒暑假即将结束也是同样的道理。

但这样的感觉是否真的无法突破，是否只能永远局限于这么一两年之间，并且为了它感到前途无望（完全看不到之后的路）。

我这里需要跳出来说下我自己的感觉。

突如其来的死亡紧急体验和不得已的对死亡的思考。

我意识到正常人在一般情况下是不可能这么深入地考虑死亡的。

一种突然意识到自己会死亡的感觉（死亡并不遥远），可以把自己从这个界线中拉出来。 在 [[存在主义阅读手记]] 里我讨论过这种"紧急体验"的理论——期限足够近时人会从"忘失的存在状态"切换到"念兹在兹的存在状态"。

比如，我一两周前，在胸部发现了一个黑色的像是痣一样的东西，但我清楚自己以前绝对没有。我观察了一阵子还发现它似乎变大了。

黑色素瘤。我立刻想到了这个词，而皮肤的恶性肿瘤几乎是扩散最恶劣的。我那几天里，没什么医学证据的我突然意识到自己可能只能活几个月，而不是毕业。当一个比毕业更炸裂的词（死亡）摆在我面前的时候，毕业的沉重感一下子就模糊了。我在想着自己如果只能活几个月的话究竟还能做什么，这不是写作时的构思，而是不得已的完全代入。

我没有想出答案，但是我几乎几天里就改掉了以前的睡眠习惯，我开始渐渐七点二十起床，也许还打算更早，比如早上我就七点左右起来。晚上睡前我没有再在床上看小说。我以往都是跟着室友一起上早八（七点五十多起来，八点二十上课。早饭大概是有一顿没一顿的）。

周二那天我到实验室比自控老师早一步，她跟在我后面，看到我的时候她说"来这么早啊(￣▽￣)"，"早上睡不着。-_-"，"早上睡不着好啊，睡不着就起来学习。<(￣︶￣)↗"，可能是她一句话，我之后几天也差不多都提前到的。

但最为主要的可能是我突然意识到我没有延后的时间留给我了，我尽量在今天或者明天就把原本打算做的事情做了。我去写代码，而不是规划写什么代码，我去看小说漫画，而不是一再忘了。

以往我总是把它们在心里提上日程然后又过段时间潇洒地感叹自己是绝对不会按照计划行动的人。以及现在我开始"吃番茄"，番茄钟，不得不说，它让我意识到自己应该休息。

以及，关于我那个黑色的颗粒物的问题，我去咨询的时候，他说，这好像是一个粉刺，是一个黑头。而在看的过程中它自然地脱落了，随着脱落的是我悬着几天的心。

也许是我意识到现在除了现在什么都没有。

但是这次死亡的提前思考，让我意识到，毕业并不是唯一的界线，说得直白一些，我可能根本活不到毕业，而如果我能活到毕业之后，那么似乎我能做的事情，也就比现在更多。我意识到我自己最大的焦虑是：到毕业之前，我可能还是做不出来什么东西。还是做不出来什么能让我躺平的东西。

但我想到，自己也许没必要强迫自己在现在做出来，现在，也许只是闲暇时间比较多的一个两年的假期。能做出来，我幸，做不出来，以后再来。

以前我是抱着为了让自己躺平的大前提来学东西和做东西的，但似乎在这个过程中我自己先躺平了=-=。

小确幸也不错。

楠木在只剩三个月寿命的时候握着自己卖掉三十年寿命换来的三十万日元，喝着啤酒说要用剩下的时间创造出以往三十年都没能有过的精彩。感觉就像赌徒一样的发言。但是宫城看得很开，她觉得，比起在意识到自己之前有错就觉得自己往后能够翻盘。不如趁着现在就一点点积攒"小确幸"。也许我写博客也是这个目的吧。

正因为生来什么都没有，因此我们能拥有一切。 ——《游戏人生》

死亡永远是我最好的导师。

没有明天的我们，在昨天相恋

Tue, 25 Jun 2024 00:00:00 GMT

第一天写 - 大部分被我删掉了,所以会有点怪异。

正式转向日轻的第一部，发现阅读阻力小很多，而且几乎能够一口气看一本。但这种流畅的而不用思考的语言往往缺乏一点深刻和饱满。

而它也却是给了我一个心情转变的契机，如果我再有类似，也可再看。从这方面来看，这是一部杰作。

我愿意略微改写这本书，把死神最后一次见他们后说了"真拿你们没办法"后就结局。让故事定格在梦幻也不错。

Ps - 在第二天继续。 -在寒假结束时"死去"。 2024/2/20

我觉得作者在是否会对舍弃寿命这件事情感到后悔上面下足了功夫。直到两人都最终释怀都感到不悔的时候反而给了他们两个响尾蛇表并且进行时光回溯。

作者在前言中提到这像是事后才想到的安慰的好话，我能理解这种感觉，我也常常在出口后感到后悔，后悔没有深思熟虑。在这点上村上笔下和盖茨比书中的主人公会更加有优势，因为是纯粹的旁观者，冷静，沉默，不对别人发表个人意见，但往往能在一些时候说出一些意想不到的话。而我和作者都没办到，于是作者写了这个小说，村上写了《百分百女孩》。

作者似乎把"对死亡这件事情感到释怀了"看得重。我也有一瞬间给隐隐给自己定下了自己在三年后的某一天会升天的这种感觉。

说到底我更想考虑关于无所是事。因为昨天神志不清太困没有写。

关于我现在所处的情况，其实和相叶最初的几个月很像。可以尽情得做自己想做的事情（看小说，电影，动漫，玩游戏，出门也可以，但我倾向不出门。），同样被一个deadline所逼迫。（相叶是得知自己在三年后的十二月二十六日是噶掉，我是知道自己在二月二十六日要上课，这么说起来自己二十五日就要去学校了，一直以为是二十六日，谈笑间又少了一天）。这种已知结果的情况下，寒假开始，寒假后期，我和相叶的心情发生了相似的变化。在后期，我也一点点感到力不从心和后悔。虽然我保持着和开始时相似的作息，但确实叶怀疑过，并且感到一成不变。最初小说带给我的那种欣喜感在后来发生了一点点变化。

是否人们在这么做之后就必然感到无聊和后悔呢？死神谈到大部分人在后期会开始寻求刺激。我也确实在前两天打开了一直以为都没再玩的觅长生。并且沉迷得游玩了接近二十个小时，企图通过刺激掩盖自己的心慌。

相叶因为偶然间选择了和别人不同的道路，也是一之濑的加入让相叶的生活和以往的日常发生了偏移。美少女在很多时候都有改变一个人的力量，所以说美少女们可以拯救世界是没有问题的。但正如《少年巴比伦》后所说，"好看的人太多，有趣的人太少"。但现实中像一之濑这样好看的人并不是没有，甚至和她一样有趣的人也不是没有，但是让我和这样的人发生联系的条件只在幻想中成立。

如果没有美少女来拯救寒假末期的自己该怎么办，主动寻找吗？我觉得不现实，容易被网恋诈骗，因为作为一个搞过tts的人可以知道现在男生伪装女生已经容易很多很多了。

换言之，我现在为寒假即将结束感到焦虑，而几天后，寒假结束并且我再去学校，并且再度适应那里的生活时，这个担忧寒假结束的我就"死掉了"。也许会再度陷入漫无边际的享乐，并且为毕业的临近而感到焦虑。然后再"死掉"。

而作为人类，作为死神口中的大部分普通人之一，没有碰到美少女拯救的我，总是会在假期开始时感到喜悦，前期感到漫无目的，中期感到无聊，后期寻求刺激。然后在末期，感觉到似乎得努力把之前缺失的部分都补回来的心情而开始规划作息。如此一次次"死去"，直到最终死去。

蠢人总会在死去前会变得聪明。

这似乎是三秋缒的某本书里面提到的。可能是三日间的幸福，当宫城和他只剩下三天的光阴，他们眼中一切都会为自己失色。似乎在一瞬间达到贤人的境界，明白只有当下和对方是重要的，其余都不是。后来看了漫画版，在 [[《以一年一萬元的價格》后]] 写过。

而也存在"如获新生"这个词，也许是大病初愈，病人原本被告知自己活不过三个月。却在三个月后痊愈。这种经历，让他与众不同。问题是，在"临死前"留下的那种贤者的时间能否延续到后来。还是说那个贤者随着三个月的期限一过就已经"死去"，而新的他开始了新的喜悦和漫无目的？

我个人曾经是有过类似的经历的，当然，每个人都有过，只不过感觉不像我这么强烈罢了。我在高考临近一百天的时候曾经天真得想着，我过着的一周只有二十个小时假期，二十六个小时空余时间的日子真的会结束吗，从前像是虚幻，只有小说留下了真实。往后像是黑洞，吞噬了所有的可能，我想象不出来。

我确实在暑假的时候看小说，动漫，几乎尽我所能。大学时感慨，觉得时间来之不易，起初我主动去学板绘，建模，游戏制作，神经网络。但是随着时间越过越久，我发现我对时间的重视程度渐渐下降，仿佛那段严阵以待的时间只是喜悦的时间延长了而已。而我现在也渐渐得陷入漫无目的。从前的贤者早在我不知觉间"死去"。而我后来的作为更像是他留下的惯性。推动我走了一段，现在没了。直到昨天看这本书的时候，我想隐隐认识到这点，不是我变了，而是那个"我"已经"死了"。在高考结束后。

所以当务之急，是为寒假中的我留下"遗言"，虽然我确定以后的我大概率不会再仔细翻看这个。

我也好想被美少女拯救啊。会不会太过轻佻呢？

未尽之花

Tue, 25 Jun 2024 00:00:00 GMT

听说它的销量很差，因为审核认为它的女主画的太幼了有点恋童倾向。

但是不得不说它在我心里可以说有一块难以取代的位置。

我把它划分在人·鬼·狐中间，第一本可能有点枯燥，到了第二本的时候我想起来以前读夏达的《子不语》的时候那种做梦般的感觉。梦幻，就像子不语的女主人公在梦里看到画里面的老虎扑向自己而母亲潇洒地挥笔驱逐开它。虽然本书中没有很多志怪元素，但是女主再见到老奶奶的时候让我动容。

八百岁的老太太长着十四岁的幼颜，在经过很多后再动春心~

这本书在我心里是子不语的互补，子不语和友人帐中少掉的恋爱元素在这里被我找齐了，非常喜欢，非常好看，它们不再是单独一部，而是一个整体的意象。

虽然这书销量少，而且也许也会有人只是把它看成是简单的发糖的书很快忘掉，但不得不说，它对我来说也许就是独一无二。每本书也许都会有像我这样的读者，总是咻地被吸引了注意力，不知觉间爱上它，这爱不是多么强烈，也因此可以长存（子不语和夏达啊，夏目和暑假啊。），与其说是爱，不如说是一种温柔，想象，浪漫和梦幻的结合体。

也感谢它给我了一个愉快的晚上。

存在主义阅读手记

Thu, 20 Jun 2024 00:00:00 GMT

在得知了以往我跟一个朋友发的所有牢骚，关于寒假，关于死亡，其实都被涵盖在了存在主义对死亡的终极关怀中，我感到很有意思，也为不是只有自己会考虑这种事情感到松了一口气。

同样的我也是第一次这么高频率地进行划线和批注。

第一部：死亡

1.濒死，不可抗力给个人带来的转变。

海德格尔的两种存在模式认知（不是第一次看见这个名字，但是第一次看关于他）/

忘失的存在状态：

也就是活在事物的世界里。沉浸于日常琐事：此事的人"降低了层次"。专注于"无所事事的闲聊"，迷失在"他者"之中，人有日常世界摆布，只关心事物应该的样子。

这个范围还是不够广，它很精确，但是不足以概括所有，让我稍作拓展：1.顺遂自己的欲望只做想做的事情而非喜欢的事情，为了逃避某种焦虑，事后苦恼。2.想象描绘未来宏图，期待它的到来，但实际上我什么也没有为它做。

这个状态有点像是欲望多巴胺主导的状态，而容易的，我总是会不知不觉间陷入，等到回过头来发现已经过了几个月甚至半年。

念兹在兹的存在状态（不得不说很难打兹，而且也很难懂，译者好样的。）：

人着眼于事物本来的样子而不是它应该的样子，并且为之感到新奇。以这种模式存在意味着对生存的持续意识。

这一个让我想起来在《择天记》里的折袖，他说的"要么清醒地活着，要么清醒地死去。"比起一直被已知的死亡鞭策的陈长生，折袖是个实在的存在主义者。

讨论到关于已知大限的死亡。它很多时候其实和已知上课日期的寒暑假没有什么不同，只不过，寒假结束后还会有新的开始，而死亡是永远被未知镬住。很多哲学家，作家提出过相似的观点，并且略带风趣地调笑道："我们从出生开始就一直在死亡，最后一天的贡献并不比平日里每天多一点，只是把潜在的腐朽揭开来给人看。"

村上春树也自己在《挪威的森林》中写到过"死不是生的对立面，而是作为生的一部分永存。"，不知道是他自己悟出来的，还是借用别人的话。

我们先来讨论对死亡到来的意识是怎么一回事，死亡作为焦虑的根本来源，我们每个人都清楚自己终究会死，但我们也会在内心建立保护机制，觉得死亡什么的其实与自己无关，而大多时候，明明知道，却意识不到。

如何清楚地让人意识到呢？我提出一个假设，三天之后你的寒假就要结束了。

只有明确的期限会让人不可避免地意识到，我以往都把它称作"不可抗力"，这里我保持这种写法。

而且这个期限还不能过远，应该说是临近的，迫在眉睫的，让人不能再考虑未来的死亡才几乎必然会给人一种"紧急体验"，让人根本地转变。也许原本对金钱地位无比渴求的人突然觉得它们无关紧要，也许原本觉得毫无目的的人变得目标清晰，原本觉得活着毫无意义的人焕发生机觉得活着很好。（如果你在忘失状态可能会觉得我这段话在放屁，我觉得很正常。）在 [[存在之近，存在之远]] 里我记录了一次类似的体验。

这种小说中会有的情节，实际上现实中也会有，虽然死亡不是每个人都能体会到，但是寒假暑假的结束是大多数人都多次体验过。

那种紧急体验带来的转变往往是积极的，但是也会因为寒假等并非永恒的结束而不能达到真正的根本转变，过一段时间可能又会变回去。

寒假结束真的立在眼前的时候，我会突然看开，感到自己达到了念兹在兹的状态，而以前只是在忘失的存在状态。

2.小说，它延伸了生命的长度。

上面的废话很多而我的语言组织能力也不够。

最后我想附加的一点，是，这种"紧急体验"有时候也会在小说，漫画中获取到，尤其是长篇小说。我不得不重新审视之前的看法，差点被世人的看法误导，觉得小说其实没有什么用，会这么说的人才是真的没用。其实，小说本身，可以给予人们这种虚拟体验，完整的体验，和电影不同，只有在小说，文字中才能感受到的。

今天，我就在读完《三日间》的漫画版后感到我先前生活的荒诞，眼高于顶，却连一点小确幸都没有积累。我读了他，并且能够审视地"回到起跑线"，也许我以后还会继续读，然后继续回到起点。

这会是一个很长的系列，目前对死亡这部很感兴趣。但不知道后面会不会有更多感想，因为这次差不多把我大部分想说的都说出去了。如果你看完，如果你有同样的感觉，你也可以去读这本书。

在看的过程中没有好好做笔记了，但通读下来，还是有很多印象很深刻的地方。

存在：

你相信记忆吗？：

"正如我们在梦中度过了三分之一的生命一样，死亡夺去的生命时间，也同样像梦中度过的那样微不足道。"

这看起来很抽象，但我记住了下半句，已经消逝的，就好像不曾存在过那样微不足道。看过的动漫，小说，大部分会在记忆宫殿里慢慢褪去最初的色彩，原本强烈的情感，我可以大喊着我爱云韵，我爱九幽，但现在我发现那种情感单薄了很多。随着距离感的产生，李长歌当初在我心中的惊艳印象也黯淡了。

每次看过动漫时我沉浸的不是现实反差的忧伤，更多的是随着动漫完结，那么心中的形象无论如何也不能够再一直保留了。

我那种时候常常找我的同学牢骚，但现在想想，那是悲观主义非常典型的看法。

举个例子，一个八旬老人在回首往事的时候，或者别人问起，她会顿一顿，然后眼里有光的说，她度过了完满的一生。

但是，如果是我的看法推移到这个上面，我也许会觉得，我的一生是不断地失去，这一刻失去上一刻。直到最后，什么都没有，包括情感。记忆的微不足道。

这两者的抉择，有一本漫画可以推荐一下，束の間の一花，也叫一霎一花。本身人物刻画得有点单薄，但老师最后一堂课讲的话可以被记下。

强迫：

有一个男子，他第二天要远行到另外一个地方，他提前一天晚上，打电话给自己熟识的住在那个地方的女性，想要邀请她们中任何一个共进晚餐。（性邀请），直到他被所有人一一拒绝了一遍后，他才长舒了一口气，说着，"这下我终于有时间开一瓶酒，一个人读读书了。"

其实这样的时间他有很多，但是，他无法拒绝自己的性邀请的行为。只要当碰到不可抗力的时候，才能够从中脱身。

很多时候，我都碰到和这个类似的情况。

OBS和VTube Studio的联合使用：Be a Vtuber

Tue, 30 Jan 2024 00:00:00 GMT

:::note[图片说明] 由于上传较早，文章中的截图被压缩过重，画质较为模糊但不影响步骤阅读。 :::

可以用于直播，或者录视频的设置。

Step1. VTube Studio 的设置

开启面部捕捉： 双击可以呼出设置菜单。

背景选择 pickcolor：

开启透明推流：

Step2. OBS 的设置

添加游戏采集：

选择新建：

设置如下：

确定即可。你可以自由拖动那个窗口调整成类似这样：

风信，是个好名字。

Mon, 17 Oct 2022 00:00:00 GMT

"十年一觉扬州梦，赢得青楼薄幸名。"

我成了一个吏部尚书，和夕芸天天处在一起。我其实喜欢更自由一些的，但能这样和夕芸在一起也挺不错，大不了早一些乞骸骨，然后就带着夕芸去走之前没走过的地方。跟我一起为官的还有关仙子，她双目不能视物让我有些放心不下，但以她的为人和身手，完全不用担心让人欺负了。我其实对于从小被订婚的关仙子也是非常有好感的，希望谢信能够多代我和她散散步，在端午节一起吃吃粽子。黎双双和一一一起浪迹天涯了，我倒是非常羡慕她们那种在西湖南泰山北到处游荡的那种快意，如果能够在之后再遇见她们就好了。我其实看出来了一一对我有好感，但我一直没有点破。我背双双下山的时候确实也有点心怀不轨，但是最后我还是没办法拒绝夕芸的追随。关仙子说若我的功力一直不恢复大不了护我一世周全时真的有点动容，感谢最后她最后也真的相伴左右，谢信，谢信，不要忽略身边人，关仙子，栗子糕，还有夕芸。我没有忘记黄蝉，希望时间能让十月花能和她和解，她们要是能一起开药店就好了，可惜那很不现实。

我最后还是会怀念，怀念青楼的十年，怀念和她们点滴的互动和感动，我很高兴当初给聂香买了琴，不知道往后她的琴，为谁而弹呢？再弹奏《流水》的时候，会不会想起我呢？