MoreRSS

site iconArmin修改

算法工程师、美元VC、AI创业、大厂AI产品 
请复制 RSS 到你的阅读器,或快速订阅到 :

Inoreader Feedly Follow Feedbin Local Reader

Armin的 RSS 预览

/dreaming:OpenClaw 的记忆整理机制

2026-04-06 08:00:00

/dreamingopenclaw 2026.4.5 发布的新功能,是一套全新的“记忆整理机制”。

OpenClaw 本来的记忆结构其实很朴素,它直接存在工作区里的 Markdown 文件中。

  • MEMORY.md:长期记忆,存放稳定的事实、偏好、重要决策
  • memory/YYYY-MM-DD.md:每日记忆,存放当天的上下文、临时观察、对话过程中的记录
  • DREAMS.md:开启 dreaming 后新增的“梦境日记”,记录 dreaming 的整理过程和摘要

/dreaming真正做的事情是:从 daily memory 里,筛出那些被反复提起、反复召回、跨天仍然重要的信息,再把它们升格进 MEMORY.md

/dreaming 出现之前,OpenClaw 是怎么记忆的?

这是理解这个功能最关键的一步。因为很多人会误以为:“是不是 2026.4.5 之前,OpenClaw 还不会长期记忆?”

答案是否定的。

/dreaming 出现之前,OpenClaw 已经有长期记忆,只是形成长期记忆的方式更直接,也更依赖模型当下的判断。主要有两种路径。

1. 对话过程中直接写入

如果用户明确说:

记住我更喜欢 TypeScript。

或者模型判断某件事明显属于长期有效的信息,比如用户偏好、项目长期背景、关键技术决策,它就可以直接写进记忆文件。

如果它认为这是长期知识,就写到 MEMORY.md;如果它认为这只是当天上下文,就更可能写到 memory/YYYY-MM-DD.md

2. 会话压缩前自动补写

OpenClaw 有一个默认开启的机制,叫 memory flush。当会话接近 compaction,也就是要做上下文压缩之前,系统会先触发一个静默回合,提醒 Agent:

现在快压缩了,如果有值得长期保存的信息,先写进记忆文件。

这一步的作用很现实,防止一些原本还留在上下文窗口里的重要信息,在压缩后丢失。

所以,/dreaming 出现之前,OpenClaw 会记,但更像“当场记录”;缺少一套系统性的“事后复盘和筛选”机制。

/dreaming 解决的是什么问题?

问题不在“能不能记”,而在“记得够不够好”。举个很典型的场景。

假设你这几天一直在和 OpenClaw 讨论同一个问题:

  • 第一天:我们项目 API 先用 REST,不用 GraphQL
  • 第二天:之前 API 架构怎么定的?
  • 第三天:登录接口和 projects 接口当时怎么规划的?

在没有 dreaming 的时候,这段信息当然也可能被记住。

但它是否最终进入 MEMORY.md,很大程度上取决于模型在某一次当下交互里,有没有判断出它足够“长期重要”。

而 dreaming 的逻辑是另一种思路:它不急着在第一次出现时就决定,而是先观察。它会看:

  • 这条信息有没有被反复召回
  • 每次召回时相关度高不高
  • 是不是不同问题都在指向它
  • 是不是跨了不止一天,而不是当天偶然被提了很多次

如果这些信号都足够强,它才会认为:这不是一次性的上下文,而是值得进入长期记忆的稳定信息。

也就是说,dreaming 的价值是:更有依据地决定该存什么。

用一个最直观的例子理解 dreaming

假设 daily memory 里有这样一段内容:

# memory/2026-04-04.md

## API 决策

决定采用 REST,不用 GraphQL。

原因:实现简单、缓存友好、团队熟悉。

接口先做:
- GET /users
- POST /auth/login
- GET /projects/:id

这段内容最开始只是 daily memory,也就是“当天笔记”。

接下来几天里,用户又不断提到相关问题:

  • “之前 API 是怎么定的?”
  • “为什么我们没选 GraphQL?”
  • “登录接口最初是不是 /auth/login?”

每次问这些问题时,memory_search 都会把这段 daily memory 找出来。

dreaming 看到的不是“这段内容出现过一次”,而是:

这段内容在多天、多轮问答里,被反复召回,而且命中很准。

于是它最终可能把这条信息整理后写入 MEMORY.md

## 重要技术决策

- 2026-04-04:项目 API 采用 REST,不使用 GraphQL。
  原因:实现更简单、缓存支持更好、团队更熟悉。

以后再问同类问题,系统就更容易直接从长期记忆里取出这个结论,而不是每次都去翻某一天的流水账。

那什么信息不会被 dreaming 升格?

理解这个边界也很重要。dreaming 不是自动把所有 daily memory 全部搬进 MEMORY.md。如果这样做,长期记忆很快就会被噪音塞满。

通常不会被升格的,是那些一次性、短生命周期、局部上下文型的信息,比如:

  • “今天 3:17 把按钮改成蓝色”
  • “刚才试了一个命令,失败了”
  • “这轮调试先临时注释掉一个函数”

这些信息对当前会话可能有用,但通常不构成长期稳定上下文。所以它们更适合留在 memory/YYYY-MM-DD.md,而不是进入 MEMORY.md

这个功能要不要手动使用?

要手动开启,但开启之后会自动运行。

当前官方文档里,用户常见的控制命令包括:

/dreaming on
/dreaming off
/dreaming status
/dreaming help

也就是说,用户需要先决定:我要不要启用 dreaming。但一旦启用之后,它就不是那种“每次都要自己手动执行一次”的功能了。

开启之后,它是怎么自动运行的?

默认配置里,dreaming 是关闭的:

{
  "plugins": {
    "entries": {
      "memory-core": {
        "config": {
          "dreaming": {
            "enabled": false,
            "frequency": "0 3 * * *"
          }
        }
      }
    }
  }
}

这里最值得关注的是这两个字段:

  • enabled
  • frequency

如果你把 dreaming 开启,而不额外改配置,那么它默认会按下面这个 cron 表达式调度:

0 3 * * *

也就是:每天凌晨 3 点执行一次完整 dreaming sweep。

这次 sweep 会按顺序跑完整个后台流程,内部包含:

  • light
  • REM
  • deep

其中只有 deep 阶段会真正把内容追加到 MEMORY.md

light:先整理短期材料

这一阶段更像“收拾桌面”。系统会先把最近出现过、被召回过的短期记忆整理出来,做基础归并、去重和候选收集,让后面的流程有一份更干净的候选集合可以处理。

你可以把它理解为:先把最近哪些内容值得关注,初步捞出来。

REM:再提炼主题、联系和模式

这一阶段更像“做联想和归纳”。它不只是看某一句话本身,而是会尝试把多条相关的短期线索联系起来,提取出更高层的主题、模式或反思。

比如零散的问题可能都指向同一个长期主题:

  • 用户持续偏好 TypeScript
  • 项目 API 一直围绕 REST 决策展开
  • 某个联系人在多个上下文里重复出现

所以 REM 更像是:把零散片段组织成有意义的主题。

deep:最后决定哪些内容真正进入长期记忆

这是最关键的一步。到了 deep 阶段,系统才会结合前面的召回证据和筛选结果,判断哪些候选项真的值得写入 MEMORY.md

也就是说:

  • light 负责收集和整理
  • REM 负责归纳和提炼
  • deep 负责最终升格

所以这三步像一条逐层收敛的流水线:从短期片段,到主题线索,再到长期记忆。


为什么 dreaming 比旧机制更强?

它把长期记忆的生成,从一次性的主观判断,变成了基于真实召回证据的筛选过程。

在旧机制里,某条信息能不能进入 MEMORY.md,主要取决于模型在某一轮对话中的当场判断。

它可能会判断得很好,也可能会漏掉真正重要的信息,或者把一些只在当下有用的细节过早写进长期记忆。

而 dreaming 的逻辑更像“延迟决策”:先不急着升格,先观察这条信息在真实使用中是否反复被召回、是否跨天仍然重要、是否在不同问题里都发挥作用。等证据足够强,再把它写进 MEMORY.md

这带来几个很具体的改进。

1. 长期记忆会更干净

旧机制更容易把一些一次性细节写进长期记忆,比如临时调试状态、当天的局部修改、很快就会过期的上下文。

dreaming 通过召回频率、相关度、查询多样性等加权信号做筛选,目标是让长期记忆只保留高信号内容,而不是不断膨胀成一个杂乱备忘录。

2. 升格依据会更稳定

以前更像“模型觉得重要就记”。现在更像“这条信息确实在后续多轮使用中证明了自己重要”。

这意味着长期记忆的形成,不再那么依赖某一次对话时模型的即时判断,而更多依赖真实的复用证据。

3. 更容易保留长期模式,而不是一次性细节

什么是长期模式?

比如:

  • 用户长期偏好
  • 项目的核心技术决策
  • 反复出现的人物关系
  • 跨多天仍然会被问到的背景事实

这些内容本来就应该成为长期记忆,但在旧机制里不一定每次都能被及时、准确地升格。dreaming 则更擅长把这类“持续有效的信息”沉淀下来。

4. 更不容易把过期内容写进长期记忆

官方文档提到,promotion 之前会重新读取 live daily note,而不是盲目依赖旧快照。这能降低一种典型风险:

某条内容曾经出现过,但后来被用户修改了、删除了,或者其实已经失效了。

旧机制下,这类信息更容易因为“当时看起来重要”而被写进长期记忆;dreaming 则在流程上更强调 promotion 前再次确认当前版本。

5. 更可观察、更可审计

旧机制很多时候比较黑盒。你知道它记了,但不一定知道为什么记。

而 dreaming 这套流程至少给了更多可观察面:

  • DREAMS.md
  • Dreams UI
  • openclaw memory promote
  • promotion 候选项和阈值配置

这意味着你可以更具体地检查它是怎么筛选出来的。

没有 /dreaming 的 OpenClaw,也能记忆;有了 /dreaming 之后,它开始更像一个会复盘、会沉淀、会筛选长期知识的系统。

它补上是“记忆整理能力”。

再换一种更形象的说法:

  • memory/YYYY-MM-DD.md 像当天的工作笔记
  • memory_search 像翻笔记找线索
  • MEMORY.md 像整理后的长期知识库
  • /dreaming 像晚上帮你把笔记复盘一遍,决定哪些内容值得永久留下

这就是为什么这个功能看起来不张扬,但实际上非常关键。

因为一个真正能长期协作的 AI,不只是要“知道你刚刚说了什么”,更重要的是:它要逐渐知道,什么是值得一直记住的。

wechat2md:将公众号文章转为Markdown

2026-03-15 08:00:00

wechat2md 是一个将微信公众号文章一键转换为 Markdown 文件的工具。无论是归档文章、二次编辑,还是迁移到其他平台,它都能帮你快速完成格式转换。

在线体验地址:wechat2md.arminli.com

核心功能

  • 格式转换:将微信公众号的富文本内容转为标准 Markdown,包含标题、段落、粗体、列表、引用等格式

  • 图片处理:通过图床转存,彻底解决微信图片防盗链问题

  • 元数据提取:自动提取文章标题、作者、发布日期,并生成 YAML front matter

多种使用方式

  • Web 界面(最简单,无需安装)直接访问 wechat2md.arminli.com,粘贴链接即可转换。

  • HTTP API(适合集成到自己的工具链)支持 JavaScript、Python 等语言直接调用,方便接入自动化工作流。

Clawdbot / OpenClaw 是如何记住一切的

2026-02-01 08:00:00

Clawdbot (OpenClaw) 是一个开源的个人 AI 助手(MIT 许可证),由 Peter Steinberger 创建。与 ChatGPT 或 Claude 这类运行在云端的模型不同,Clawdbot 完全在你的本地机器上运行,并且可以集成到你已经在使用的聊天平台中,比如 Discord、WhatsApp、Telegram 等。

Clawdbot 与众不同之处在于,它能够 自主处理真实世界的任务:管理邮件、安排日历事件、处理航班值机、以及按计划运行后台任务。但真正吸引我注意的是它的 持久化记忆系统 —— 它可以 7×24 小时保留上下文,记住对话内容,并在未来的交互中持续构建和利用这些记忆。

Clawdbot 不是基于云端、也不是由公司控制记忆,而是 将所有记忆保存在本地,让用户完全拥有自己的上下文和技能。

下面我们来深入看看它是如何工作的。


上下文是如何构建的

在讨论记忆之前,我们先看一次请求中,模型究竟”看到了什么”:

[0] 系统提示词(静态 + 条件指令)
[1] 项目上下文(引导文件:AGENTS.md、SOUL.md 等)
[2] 对话历史(消息、工具调用、压缩摘要)
[3] 当前消息

系统提示词定义了代理的能力和可用工具。而与记忆最相关的是 项目上下文(Project Context),它包含了一些 用户可编辑的 Markdown 文件,并且会被注入到每一次请求中。

这些文件和记忆文件一起,存在于代理的工作区中,使得整个代理的配置 完全透明、可编辑


上下文 vs 记忆

理解 上下文(Context)记忆(Memory) 的区别,是理解 Clawdbot 的关键。

上下文(Context)

上下文是模型在一次请求中看到的所有内容

Context = 系统提示词 + 对话历史 + 工具结果 + 附件

上下文的特点:

  • 短暂的:只在当前请求中存在
  • 有上限的:受模型上下文窗口限制(例如 200K tokens)
  • 昂贵的:每个 token 都影响 API 成本和速度

记忆(Memory)

记忆是 存储在磁盘上的内容

Memory = MEMORY.md + memory/*.md + 会话转录

记忆的特点:

  • 持久的:重启、隔天、隔月都不会丢失
  • 无上限的:可以无限增长
  • 廉价的:存储不产生 API 成本
  • 可搜索的:支持语义检索

记忆工具(Memory Tools)

Clawdbot 通过两个专用工具访问记忆:


1. memory_search

用途:在所有记忆文件中查找相关内容

{
  "name": "memory_search",
  "description": "强制回忆步骤:在回答有关过往工作、决策、日期、人物、偏好或待办事项的问题前,语义搜索 MEMORY.md + memory/*.md",
  "parameters": {
    "query": "我们对 API 做了什么决定?",
    "maxResults": 6,
    "minScore": 0.35
  }
}

返回结果:

{
  "results": [
    {
      "path": "memory/2026-01-20.md",
      "startLine": 45,
      "endLine": 52,
      "score": 0.87,
      "snippet": "## API 讨论\n决定为了简化采用 REST 而不是 GraphQL...",
      "source": "memory"
    }
  ],
  "provider": "openai",
  "model": "text-embedding-3-small"
}

2. memory_get

用途:在 memory_search 找到结果后,读取具体内容

{
  "name": "memory_get",
  "description": "在 memory_search 之后读取指定记忆文件的具体行",
  "parameters": {
    "path": "memory/2026-01-20.md",
    "from": 45,
    "lines": 15
  }
}

返回结果:

{
  "path": "memory/2026-01-20.md",
  "text": "## API 讨论\n\n与团队讨论了 API 架构。\n\n### 决策\n我们选择 REST 而不是 GraphQL,原因如下:
1. 实现更简单
2. 更好的缓存支持
3. 团队更熟悉\n\n### 接口
- GET /users
- POST /auth/login
- GET /projects/:id"
}

写入记忆(Writing to Memory)

Clawdbot 没有专门的 memory_write 工具。它直接使用标准的 写入 / 编辑文件工具 来修改 Markdown 文件。

因为记忆本质上就是普通的 Markdown,你也可以 手动编辑这些文件(系统会自动重新索引)。

写入到哪里,由 AGENTS.md 中的提示词逻辑决定。

此外,在 会话压缩前会话结束时,也会自动写入记忆(后文会详细说明)。


记忆存储结构

Clawdbot 的设计理念是:

“记忆就是代理工作区里的普通 Markdown 文件。”

两层记忆系统

默认路径:~/clawd/

~/clawd/
├── MEMORY.md              # 第二层:长期整理后的知识
└── memory/
    ├── 2026-01-26.md      # 第一层:当天记录
    ├── 2026-01-25.md
    ├── 2026-01-24.md
    └── ...

第一层:每日日志(Layer 1)

路径:memory/YYYY-MM-DD.md 特点:只追加,不修改

代理会在以下情况写入这里:

  • 想要记住某件事
  • 用户明确要求”记住”某件事

示例:

# 2026-01-26

## 10:30 AM - API 讨论
与用户讨论了 REST vs GraphQL。
决定:使用 REST。
关键接口:/users, /auth, /projects。

## 2:15 PM - 部署
已将 v2.3.0 部署到生产环境,无问题。

## 4:00 PM - 用户偏好
用户提到他们更偏好 TypeScript 而不是 JavaScript。

第二层:长期记忆(Layer 2)

文件:MEMORY.md

这里存放的是 经过整理、长期有效的知识。当代理认为某些信息是 重要的决定、观点、经验或结论 时,就会写入这里。

示例:

# 长期记忆

## 用户偏好
- 偏好 TypeScript 而不是 JavaScript
- 喜欢简洁的解释
- 正在开发 "Acme Dashboard" 项目

## 重要决策
- 2026-01-15:选择 PostgreSQL 作为数据库
- 2026-01-20:采用 REST 而不是 GraphQL
- 2026-01-26:使用 Tailwind CSS 作为样式方案

## 关键联系人
- Alice([email protected])- 设计负责人
- Bob([email protected])- 后端工程师

代理如何知道要读取记忆?

这一切由 AGENTS.md 驱动(该文件会自动加载):

## 每次会话开始前,必须执行:
1. 读取 SOUL.md —— 你是谁
2. 读取 USER.md —— 你在帮助谁
3. 读取 memory/YYYY-MM-DD.md(今天和昨天)
4. 如果是主会话(直接与用户对话),也要读取 MEMORY.md
不要询问权限,直接执行。

记忆是如何被索引的

当一个记忆文件被保存时,后台会发生以下流程:

  1. 文件保存
  2. 文件监听器检测到变更(使用 Chokidar)
  3. 文本切块(约 400 tokens,80 tokens 重叠)
  4. 向量化(embedding)
  5. 存储到 SQLite 数据库

向量搜索由 sqlite-vec 支持,关键词搜索由 SQLite FTS5 支持,两者结合实现 混合搜索


记忆是如何被搜索的?

Clawdbot 同时执行两种搜索:

  • 向量搜索(语义)
  • BM25 关键词搜索(精确匹配)

最终评分公式:

finalScore = (0.7 * 向量得分) + (0.3 * 文本得分)

这样既能找到”意思相同”的内容,也不会漏掉 ID、日期、名字等精确关键词。


多代理记忆隔离(Multi-Agent Memory)

Clawdbot 支持多个代理,每个代理的记忆 完全隔离

~/.clawdbot/memory/
├── main.sqlite
└── work.sqlite

~/clawd/        # main 代理工作区
~/clawd-work/   # work 代理工作区

默认情况下:

  • 不会跨代理读取记忆
  • 每个代理拥有独立人格与上下文

这非常适合将 个人聊天工作聊天 分离。


上下文压缩(Compaction)

所有模型都有上下文窗口限制。当接近上限时,Clawdbot 会自动进行 对话压缩

  • 老对话 → 摘要
  • 最近对话 → 保留原文
  • 摘要 → 写入磁盘

压缩是 持久化的,不会在下一次会话中丢失。


预压缩记忆刷新(Memory Flush)

由于压缩是有损的,Clawdbot 在压缩前会触发一次 静默记忆刷新

  • 扫描当前对话
  • 将重要信息写入记忆文件
  • 用户完全无感知

这样可以确保 重要信息不会在压缩中丢失


剪枝(Pruning)

工具输出可能非常巨大(例如构建日志)。剪枝会在 不修改磁盘历史 的前提下,裁剪发送给模型的内容,降低成本。


会话生命周期

会话默认每天重置,也可以配置为其他模式。每次使用 /new 开启新会话时,可以触发 会话记忆钩子,自动保存上一个会话的核心内容。


结论

Clawdbot 的记忆系统成功,是因为它遵循了几个关键原则:

  1. 透明而非黑箱
  2. 搜索优于强行注入上下文
  3. 持久优于会话
  4. 混合优于单一方案

书单推荐 2025.11

2025-11-16 08:00:00

Unreasonable Hospitality: The Remarkable Power of Giving People More Than They Expect 由前纽约米其林三星餐厅 Eleven Madison Park 的合伙人威尔·古达拉(Will Guidara)撰写。书中讲述他如何将一家普通的高级餐厅,转变为世界最佳用餐体验的故事。

作者以亲身经历展示了”待客之道”的核心——不仅是提供服务,更是通过真诚、创造性和细致入微的关怀,让顾客感到被重视、被理解。

这本书不仅适合餐饮从业者,也启发任何从事服务、管理或团队领导的人。它提醒我们,卓越往往来自超出预期的一点点努力,而真诚的热情可以改变人与人之间的关系乃至整个组织的文化。


《Hollywood Ending》 是一本深入揭示美国电影界著名人物哈维·韦恩斯坦(Harvey Weinstein)兴衰历程的作品,全景展现了他如何从皇后区的普通青年成长为好莱坞最有权势的制片人,又最终因为一系列性犯罪指控而身败名裂。

这本书不仅记录了韦恩斯坦的职业生涯、与兄弟鲍勃的复杂关系及其与政商名流的密切往来,也详尽还原了其犯罪行为被曝光、引发”#MeToo”运动的全过程。

作者通过大量第一手材料和深度采访,让读者看到一个既野心勃勃、极具创造力,又操纵权力与掩盖罪行的复杂人物。书中不仅是一个人的陨落史,更透视了包庇与沉默如何在好莱坞这样的权力场中滋生、蔓延。


《Air-Borne: The Hidden History of the Life We Breathe》 是一部空气生物学发展史。书中揭示了我们每天呼吸的空气中隐藏着成千上万的微生物、种子、致病菌和生命体,从平流层到地表,空气自身就构成了一个”气生生物群落”(aerobiome)。

作者以路易·巴斯德在法国高山上捕捉空气中微生物的科学实验为起点,讲述了自 19 世纪以来人类探索气生生物的故事。书中描绘了科学家如何通过空中采样、热气球实验,甚至通过飞机与云层研究,逐步揭示空气中生命的多样性,以及它们与人类健康、全球气候和疾病传播之间复杂而深远的联系。

作者还探讨了空气传播致病因子的历史事件,包括瘟疫、粮食危机和生物武器,以及人类对气中健康威胁的恐惧与反思。


在上海看完贝聿铭展览后读了这三本书,都很不错。《百年贝聿铭》传记性质更强,里面可以看出其对香山饭店的不满。《贝聿铭传》老一些是 90 年代的书,里面细节更多比如汉考克大厦和香山饭店和政府打交道,可能由于写的时间早里面还是比较敢写的。


启明创投梁颖宇早期的创投经历,之前只知道她在医药行业投的非常好,读了这本书才知道她之前创办过很多公司,还包括了一家肿瘤医院。

AI 泡沫即将破灭?从 AI infra 开销与 GDP 占比分析

2025-11-07 08:00:00

这两天美股尤其是 AI、科技股开始回调,我看到很多人开始讨论 AI 是否已经见顶。我发现 Theory Ventures 对于此有一个非常好的类比。

从 GDP 占比来看,目前的 AI infra 开销只在美国历史上排第六,前面依次是二战和一战、罗斯福新政、铁路建设和高速公路建设。

值得注意的是,今天 AI infra 开销占比已经超过了 2000 年著名的 dot com bubble、曼哈顿计划以及阿波罗登月计划。

由于 OpenAI 预计在 2030 年花费 295B,假设它占市场份额的30295B,假设它占市场份额的 30%,那么 AI 总开销将在 983B,也只占据 GDP 的 2.8%。

如果将这个比例提高到 6%(对标当年的美国铁路建设开销),那么谷歌、Meta、OpenAI 和 Microsoft 的每年开销应该是今天的 5-7 倍!

如果你相信生成式 AI 是超过当年美国铁路建设的影响力,那么今天的 AI 开销只是很小一部分。

AI 在 ICPC world final 战胜人类的一天

2025-09-18 08:00:00

人类团队排名:

OpenAI 成绩:

OpenAI 认为最难的 G 题:

对人类来说最难的 C 题(无人通过),AI 只花了几十分钟就解决。

对 AI 最难的 G 题(动用了另一个实验性推理模型,提交 9 次),最强的人类队伍只花了 3 次尝试就解决。

Gemini 把解题代码全部开源,而 OpenAI 没有。我推测有几种可能:

1. 代码/解题方式不够优雅

2. 出现类似与 AlphaGo 与李世石的“神之一手”的“智能涌现”时刻,战略保密

3. 比赛真实使用的其实不是 gpt5,担心公众无法复现

一直以编程能力见长的 Anthropic 没有参赛,可能是因为这个场景对多模态推理有更高的要求,因为 AI 拿到的是 PDF 题面,里面有复杂的图形图标等。

最后一个有意思的地方在于美国没有拿到金牌的大学,联想到美国大学 ICPC 中的华人学生含量和之前的反华运动,不知是不是蝴蝶效应开始了呢。