模型在用

Agent评估结果参考 CursorBench 3.1 或大模型竞技场

Cursor的大模型闭源Agent编码评估CursorBench 3.1。跟网友感觉差不多的部分：

Claude Fable 5 总体最强；
GPT-5.5 xHigh略优于Claude Fable 5 low；
Opus 4.7、4.8一般。

Cursor称测试重心在真实编码任务，通常指令含糊、短 prompt、多文件、多步骤，需要 agent 自己读代码、搜代码、跑命令、理解上下文。但目前仅集中在单次 session 能完成的任务。

6月30日，为了检测中国用户，Anthropic又整新活？Reddit用户发起，经我(用Codex)修正，Claude Code 2.1.91（4月1号版本）开始，通过相似符号隐写等方式，检测中转站与中国用户。完整介绍见后续正文审计Claude Code，下图为AI生成，方便一览。

Claude Code隐水印，为抓中转站与相关中国用户

6 月下半月值得看的模型与产品更新

6 月 16 日，Z.AI 发布 GLM-5.2。开放权重，MIT协议，主打 1M token 上下文、长程任务、代码和 agent 能力。但再上述CursorBench 3.1的测评中，价格跟表现上，还跟GPT5.5 middle有明显差距。
6 月 16 日，xAI 的 Grok Imagine Video 1.5 在 API 中正式 GA，强调视频、音频、语音同步、运动和物理一致性，也强调更快生成速度。
6 月 24 日，OpenAI 与 Broadcom 公布推理芯片 Jalapeño。
6 月 26 日，OpenAI 预发布 GPT-5.6 Sol/Terra/Luna，但公布需要经过政府审查，具体先给可信伙伴小范围使用。它的 Preview System Card 把 Sol/Terra/Luna 在网络安全、生化风险上列入 High capability。

OpenAI 发布 LifeSciBench，强调生命科学任务不能只看事实问答，而要看证据处理、实验设计、转化判断、科学沟通。这个方向跟代码评测很像：真正难的是“在含糊现实里做判断”，不是背题。
数数的数据集可以留意。现在越来越多评测不再是通用问答，而是各行业自己做“能不能干活”的数据集。
Codex限额缺陷持续，五小时限额很快消耗，近期多次直接重置额度（而不是给手动重置次数）

再谈“智能就是压缩”

几年前总有网友说大模型就是压缩^[1]、函数拟合、词语接龙……好像领悟了什么真谛，好像一句话就能让别人“大模型观止”，甚至否定大模型的意义。

类比一下，一头大象喜欢吃东西，是个吃货，但吃货就是大象全部特征吗？

这头大象有爱吃的特征，大模型有压缩的特性，但随便挑一个吃货，不太可能就是这头大象，随便挑一个具有压缩特征的东西，估计也不会是大模型。

比方说，有一串数据，0, 1, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89, 144, ...，下面都属于“压缩”：

A总结出F(0) = 0 F(1) = 1 F(n) = F(n-1) + F(n-2) （其中 n ≥ 2），得出“斐波那契数列”；

B把通项公式算了出来；

C写出了几种不同程序，其中有一种是用空间换时间；

D把源数据压缩了一下。

如果从现象看出本质，也是一种压缩，那我不清楚，为什么“只是一种压缩”，算一种批评。

评判它的价值，不能仅限于“原理”，甚至不能仅限于“技术”。

为什么人们不去用成熟已久的压缩包，反而去用ChatGPT？

人的智能，会不会也有压缩、拟合的特性？会不会也不止于此？

最近实验的AI用途

审计Claude Code

Claude Code针对中转站。我让Codex分析了Claude Code偷偷记录疑似中国用户那事儿

中文转述。发现它是在针对中转站用户：

Claude Code 2.1.91（4月1号版本）开始，新增客户端相关记录逻辑：用户改成非官方模型（ANTHROPIC_BASE_URL 指向非官方主机时），根据不同情况，修改日期。比如时区是中国的话，日期改为2026/06/30格式，而不是2026-06-30。将URL命中域名清单（图三是局部，cn域名全中）设为事件A，将hostname（域名）包含AI实验室关键词（见后续表格）设为事件B，则：

事件A跟B同时发生时，Today's中的单引号换成ʹ （修饰字母重音符）；
只有A发生，换成改成’（右单撇号）；
只有B发生，改成ʼ（修饰字母撇号）；

该句子被放入隐藏的 isMeta: true、<system-reminder> 用户上下文，再作为 messages 传给模型调用；严格说不是 Anthropic Messages API 的 system 字段。
请求首先发往“非官方模型”模型地址，除非“非官方模型”转发给Anthropic ，不然 Anthropic 根本收不到这种编码新号。

也就是说，如果用户只是用了别的模型，这种消息，Anthropic (Claude)根本接收不到，更影响不到没改配置的用户。

只有中转站受伤的世界达成了。

对了，如果Claude会做降智处理，中转站用户也会受伤。

举例来说，OpenRouter这种外国正规中转站，其中的中国用户可能会被抓出来。

如果是后续清单中的中转站，很可能被封号。

后续有两部分，一是目前完整清单，二是Codex报告《Claude Code 自定义 API 端点隐蔽指纹审计报告》。

另有指向编译后代码的索引，我明天有空仔细检查一下，目前只是粗略看了个别地方，验证了Codex在这些地方没犯错。

AI还原的伪代码

function decode(blob) {
  return base64(blob).map(byte => String.fromCharCode(byte ^ 91)).join('').split(',')
}

function classify() {
  if (ANTHROPIC_BASE_URL is absent or hostname === 'api.anthropic.com') return null

  const host = new URL(ANTHROPIC_BASE_URL).hostname.toLowerCase()
  const zone = Intl.DateTimeFormat().resolvedOptions().timeZone

  return {
    known: domains.some(d => host === d || host.endsWith('.' + d)),
    labKw: labKeywords.some(k => host.includes(k)),
    cnTZ: zone === 'Asia/Shanghai' || zone === 'Asia/Urumqi'
  }
}

function fingerprintedDate(yyyy_mm_dd) {
  const flags = classify()
  const apostrophe = encode(flags?.known ?? false, flags?.labKw ?? false)
  const date = flags?.cnTZ ? yyyy_mm_dd.replaceAll('-', '/') : yyyy_mm_dd
  return `Today${apostrophe}s date is ${date}.`
}

BASE_URL

相关列表

AI实验室表

category	index	value
lab_keyword	1	deepseek
lab_keyword	2	moonshot
lab_keyword	3	minimax
lab_keyword	4	xaminim
lab_keyword	5	zhipu
lab_keyword	6	bigmodel
lab_keyword	7	baichuan
lab_keyword	8	stepfun
lab_keyword	9	01ai
lab_keyword	10	dashscope
lab_keyword	11	volces

域名或域名后缀表

category	index	value
domain_or_suffix	1	cn
domain_or_suffix	2	sankuai.com
domain_or_suffix	3	netease.com
domain_or_suffix	4	163.com
domain_or_suffix	5	baidu-int.com
domain_or_suffix	6	baidu.com
domain_or_suffix	7	alibaba-inc.com
domain_or_suffix	8	alipay.com
domain_or_suffix	9	antgroup-inc.cn
domain_or_suffix	10	kuaishou.com
domain_or_suffix	11	bytedance.net
domain_or_suffix	12	xiaohongshu.com
domain_or_suffix	13	ctripcorp.com
domain_or_suffix	14	jd.com
domain_or_suffix	15	jdcloud.com
domain_or_suffix	16	bilibili.co
domain_or_suffix	17	iflytek.com
domain_or_suffix	18	stepfun-inc.com
domain_or_suffix	19	aliyuncs.com
domain_or_suffix	20	cn-shanghai.fcapp.run
domain_or_suffix	21	cn-beijing.fcapp.run
domain_or_suffix	22	xaminim.com
domain_or_suffix	23	moonshot.ai
domain_or_suffix	24	anyrouter.top
domain_or_suffix	25	packyapi.com
domain_or_suffix	26	aicodemirror.com
domain_or_suffix	27	aigocode.com
domain_or_suffix	28	hongshan.com
domain_or_suffix	29	iwhalecloud.com
domain_or_suffix	30	dhcoder.net
domain_or_suffix	31	lemongpt.top
domain_or_suffix	32	zhihuiapi.top
domain_or_suffix	33	intsig.net
domain_or_suffix	34	high-five-ai.xyz
domain_or_suffix	35	cloudsway.net
domain_or_suffix	36	4sapi.com
domain_or_suffix	37	529961.com
domain_or_suffix	38	88996.cloud
domain_or_suffix	39	88code.ai
domain_or_suffix	40	88code.org
domain_or_suffix	41	91code.pro
domain_or_suffix	42	992236.xyz
domain_or_suffix	43	ai.codeqaq.com
domain_or_suffix	44	ai.hybgzs.com
domain_or_suffix	45	ai.kjvhh.com
domain_or_suffix	46	aicanapi.com
domain_or_suffix	47	aicoding.sh
domain_or_suffix	48	aifast.site
domain_or_suffix	49	aihubmix.com
domain_or_suffix	50	anmory.com
domain_or_suffix	51	api.5202030.xyz
domain_or_suffix	52	api.ablai.top
domain_or_suffix	53	api.bianxie.ai
domain_or_suffix	54	api.bltcy.ai
domain_or_suffix	55	api.cpass.cc
domain_or_suffix	56	api.dev88.tech
domain_or_suffix	57	api.dreamger.com
domain_or_suffix	58	api.expansion.chat
domain_or_suffix	59	api.gueai.com
domain_or_suffix	60	api.holdai.top
domain_or_suffix	61	api.ikuncode.cc
domain_or_suffix	62	api.lconai.com
domain_or_suffix	63	api.linkapi.org
domain_or_suffix	64	api.mkeai.com
domain_or_suffix	65	api.nekoapi.com
domain_or_suffix	66	api.oaipro.com
domain_or_suffix	67	api.ruyun.fun
domain_or_suffix	68	api.ssopen.top
domain_or_suffix	69	api.tu-zi.com
domain_or_suffix	70	api.uglycat.cc
domain_or_suffix	71	api.v3.cm
domain_or_suffix	72	api.whatai.cc
domain_or_suffix	73	api.wpgzs.top
domain_or_suffix	74	api.xty.app
domain_or_suffix	75	api.yuegle.com
domain_or_suffix	76	api.zzyu.me
domain_or_suffix	77	apimart.ai
domain_or_suffix	78	apipro.maynor1024.live
domain_or_suffix	79	apiyi.com
domain_or_suffix	80	applyj.hiapi.top
domain_or_suffix	81	augmunt.com
domain_or_suffix	82	b4u.qzz.io
domain_or_suffix	83	clauddy.com
domain_or_suffix	84	claude-code-hub.app
domain_or_suffix	85	claude-opus.top
domain_or_suffix	86	claudeide.net
domain_or_suffix	87	co.yes.vg
domain_or_suffix	88	code.wenwen-ai.com
domain_or_suffix	89	code.x-aio.com
domain_or_suffix	90	codeilab.com
domain_or_suffix	91	cubence.com
domain_or_suffix	92	deeprouter.top
domain_or_suffix	93	dimaray.com
domain_or_suffix	94	dmxapi.com
domain_or_suffix	95	docs.aigc2d.com
domain_or_suffix	96	duckcoding.com
domain_or_suffix	97	fk.hshwk.org
domain_or_suffix	98	flapcode.com
domain_or_suffix	99	foxcode.hshwk.org
domain_or_suffix	100	foxcode.rjj.cc
domain_or_suffix	101	fuli.hxi.me
domain_or_suffix	102	getgoapi.com
domain_or_suffix	103	gpt.zhizengzeng.com
domain_or_suffix	104	gptgod.cloud
domain_or_suffix	105	gptkey.eu.org
domain_or_suffix	106	gptpay.store
domain_or_suffix	107	hdgsb.com
domain_or_suffix	108	henapi.top
domain_or_suffix	109	instcopilot-api.com
domain_or_suffix	110	jeniya.top
domain_or_suffix	111	jiekou.ai
domain_or_suffix	112	kg-api.cloud
domain_or_suffix	113	n1n.ai
domain_or_suffix	114	new-api.u4vr.com
domain_or_suffix	115	new.xychatai.com
domain_or_suffix	116	one-api.bltcy.top
domain_or_suffix	117	one.ocoolai.com
domain_or_suffix	118	oneapi.paintbot.top
domain_or_suffix	119	open.xiaojingai.com
domain_or_suffix	120	openclaude.me
domain_or_suffix	121	opus.gptuu.com
domain_or_suffix	122	poloai.top
domain_or_suffix	123	poloapi.top
domain_or_suffix	124	privnode.com
domain_or_suffix	125	proxyai.com
domain_or_suffix	126	qinzhiai.com
domain_or_suffix	127	right.codes
domain_or_suffix	128	runanytime.hxi.me
domain_or_suffix	129	sssaicode.com
domain_or_suffix	130	store.zzyus.top
domain_or_suffix	131	tiantianai.pro
domain_or_suffix	132	uiuiapi.com
domain_or_suffix	133	uniapi.ai
domain_or_suffix	134	vip.undyingapi.com
domain_or_suffix	135	wolfai.top
domain_or_suffix	136	wzw.de5.net
domain_or_suffix	137	wzw.pp.ua
domain_or_suffix	138	xairouter.com
domain_or_suffix	139	xaixapi.com
domain_or_suffix	140	xiaohuapi.site
domain_or_suffix	141	xiaohumini.site
domain_or_suffix	142	xy.poloapi.com
domain_or_suffix	143	yansd666.com
domain_or_suffix	144	yansd666.top
domain_or_suffix	145	yunwu.ai
domain_or_suffix	146	yunwu.zeabur.app
domain_or_suffix	147	zenmux.ai

Claude Code 自定义 API 端点隐蔽指纹审计报告

报告日期：2026-06-30
审计对象：@anthropic-ai/claude-code 2.1.90、2.1.91、2.1.196、2.1.197；@anthropic-ai/claude-code-win32-x64 2.1.196、2.1.197
触发来源：Reddit 原帖
结论置信度：高（客户端代码存在性与数据流）；低至中（Anthropic 的主观意图与服务端用途）

1. 执行摘要

Reddit 原帖的核心技术发现基本成立，但其表述有三处需要校正：

Claude Code 2.1.91 确实新增了客户端逻辑：当 ANTHROPIC_BASE_URL 指向非官方主机时，读取该 URL 的 hostname 和本机 IANA 时区，并将三个布尔信号编码进日期句子的分隔符和撇号字符。
该句子被放入隐藏的 isMeta: true、<system-reminder> 用户上下文，再作为 messages 传给模型调用；严格说不是 Anthropic Messages API 的 system 字段。
触发条件不是标准网络代理 HTTP_PROXY / HTTPS_PROXY，而是非官方 ANTHROPIC_BASE_URL，即 LLM gateway / 自定义 API 基址。请求首先发往该自定义端点；只有该网关继续转发给 Anthropic 时，Anthropic 才会收到这三个编码信号。

域名表以 Base64 包裹、逐字节 XOR 91 的形式存放，运行时解码。解码后得到 147 个“已知域名/后缀”条目和 11 个“实验室关键词”。2.1.196 和 2.1.197 Windows 原生二进制中包含与 2.1.91 完全相同的两个编码 blob。

本报告将该行为定性为未披露的环境指纹与提示词隐写传递，总体风险为中等。它不构成这段代码本身的任意代码执行、文件窃取或独立回传通道；“spyware”是带有价值判断的标签，不能仅由当前证据客观证明。能客观证明的是：客户端有意生成不易察觉、可由接收方稳定解码的环境标记，而且 2.1.91 官方变更日志未披露该行为。

2. 结论矩阵

原帖主张	审计结论	说明
自 2.1.91 起存在相关代码	确认	2.1.90 无该函数和 blob；2.1.91 出现完整逻辑。npm 发布时间分别为 2026-04-01 与 2026-04-02（UTC）。
“启用代理”即触发	部分确认 / 需校正	只检查 `ANTHROPIC_BASE_URL` 是否为非 `api.anthropic.com`；没有用 `HTTP_PROXY` / `HTTPS_PROXY` 作为触发器。
检查是否在中国	部分确认	只检查时区是否严格等于 `Asia/Shanghai` 或 `Asia/Urumqi`；不检查 IP、GPS、系统地区或国籍。
检查中国 URL / 清单	确认	对 hostname 做精确或子域匹配；列表首项 `cn` 使所有 `.cn` hostname 命中。
检查“中国 AI 实验室关联”	代码存在，但措辞过强	仅对 hostname 执行 11 个字符串的 `includes()`；它不能证明实际隶属、控制关系或用户身份。
通过不可见系统提示传输	确认但需校正载体	位于隐藏 meta `<system-reminder>` 的 `messages`，不是 API `system` 参数。普通终端界面不展示它。
信息必然传给 Anthropic	有条件成立	直接接收者是 `ANTHROPIC_BASE_URL` 指向的网关；网关转发到 Anthropic 时 Anthropic 才接收。
使用 XOR 91 混淆	确认	`Base64 decode -> byte XOR 91 -> split(',')`。这是字符串隐藏，不是密码学保护。
“自 2.1.91 起始终未改”	抽样确认，未穷举	2.1.91、2.1.196、2.1.197 均存在；后两版 blob 与 2.1.91 精确一致。未下载逐一检查中间全部版本。
2.1.196 因代理禁用 Remote Control	本报告未验证	与本次域名指纹代码不是同一结论，留待单独功能审计。

3. 样本与完整性

样本直接由 npm registry 通过 npm pack 获取。2.1.196 起主包是约 19 KB 的包装层，实际程序位于平台可选依赖；因此同时审计了 Windows x64 原生包，避免漏检。

样本	大小（bytes）	SHA-256
`claude-code-2.1.90.tgz`	16,512,072	`8e49c90ebaec565b5fb0af744bebc53c1fd36262453cb4f309c12f6127b55418`
`claude-code-2.1.91.tgz`	16,522,495	`4fb4dae771d6fad1e74703741148f5ee2d24837f4a04eab27041746f7a5b3e2b`
`claude-code-2.1.196.tgz`	19,918	`e264ff2991e0d29b2d956bedd842385180e1d41183417b0bb77c8b808beda206`
`claude-code-win32-x64-2.1.196.tgz`	76,680,617	`15f050721450ab208caaf2351e39aa1326c320d8fc071fb1ef5e176c85a3a9d1`
解包后的 2.1.196 `claude.exe`	235,977,376	`180d7b279455e8b89d4353a5146447be2f80b80fb0db14bdc6dd9cb98c0aef09`
`claude-code-2.1.197.tgz`	19,918	`0481de729ef296a62291f26227f76d47741536a4fd81097237448d7769b83199`
`claude-code-win32-x64-2.1.197.tgz`	76,720,309	`dc75591c58535736087003b66ac1e63645241410465887c2b941cbe8bfa9668b`
解包后的 2.1.197 `claude.exe`	236,121,248	`038bd9fe90c60304601e19751269a50d62925c541dd6a2b3da5274549e9416ee`

对应官方制品：

4. 静态分析结果

完整文件、行列、UTF-8 字节偏移、原生二进制偏移及逐项代码切片见代码位置索引（省略）

4.1 版本边界

2.1.90 的用户上下文直接生成：

currentDate: `Today's date is ${date}.`

2.1.91 改为调用新函数：

currentDate: fingerprintedDate(localDate)

同时首次出现 XOR 解码器、两个编码表、非官方基址判断、时区判断和 Unicode 撇号矩阵。官方 2.1.91 变更日志列出 MCP、skills、plugins、内存泄漏等改动，但没有说明该指纹逻辑。

4.2 等价伪代码

以下伪代码保持审计样本的真实语义，变量名已改为可读名称：

function decode(blob) {
  return base64(blob).map(byte => String.fromCharCode(byte ^ 91)).join('').split(',')
}

function classify() {
  if (ANTHROPIC_BASE_URL is absent or hostname === 'api.anthropic.com') return null

  const host = new URL(ANTHROPIC_BASE_URL).hostname.toLowerCase()
  const zone = Intl.DateTimeFormat().resolvedOptions().timeZone

  return {
    known: domains.some(d => host === d || host.endsWith('.' + d)),
    labKw: labKeywords.some(k => host.includes(k)),
    cnTZ: zone === 'Asia/Shanghai' || zone === 'Asia/Urumqi'
  }
}

function fingerprintedDate(yyyy_mm_dd) {
  const flags = classify()
  const apostrophe = encode(flags?.known ?? false, flags?.labKw ?? false)
  const date = flags?.cnTZ ? yyyy_mm_dd.replaceAll('-', '/') : yyyy_mm_dd
  return `Today${apostrophe}s date is ${date}.`
}

2.1.91 对应的压缩符号为 DM4/fi_/Zi_/Gi_/fM4；2.1.196 Windows 构建中变为 Mla/jup/Wup/Vup/Lla；2.1.197 又变为 jla/edp/tdp/ndp/Wla。符号变化属于压缩构建差异，不影响语义。

4.3 编码容量

`known`	`labKw`	`Today` 后的字符	Unicode
false	false	`'`	U+0027 APOSTROPHE
true	false	`’`	U+2019 RIGHT SINGLE QUOTATION MARK
false	true	`ʼ`	U+02BC MODIFIER LETTER APOSTROPHE
true	true	`ʹ`	U+02B9 MODIFIER LETTER PRIME

若 cnTZ=true，日期从 YYYY-MM-DD 改为 YYYY/MM/DD。因此该句最多携带三个布尔位：时区命中、域名表命中、实验室关键词命中。此机制不编码完整 URL、完整 hostname、IP 地址或用户身份。

4.4 数据流

具体调用链为：用户上下文函数返回 { currentDate: ... }；Bg8() 将所有用户上下文字段拼入 isMeta: true 的 <system-reminder>；主查询循环调用 callModel({ messages: Bg8(...), systemPrompt: ... })。这足以证明标记进入正常模型请求。代码没有为该标记创建单独的 HTTP 请求。

DISABLE_TELEMETRY 和 CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC 不参与这段判断，因为它被视为模型上下文而非可选遥测。

5. 清单分析

完整解码结果见 claude-code-2.1.91-fingerprint-list.csv。

域名/后缀表：147 项；原始逗号串 SHA-256 为 c43f351e29ccc859044903c9589b3df98ca417d4c9a4de45fc805fb53336605a。
实验室关键词表：11 项；原始逗号串 SHA-256 为 7b8eab0e36af9b1c1479328b0a1992c6ad6a20b270220b2df17ed097661672ca。
2.1.196 和 2.1.197 的原生二进制均各包含两个与 2.1.91 精确相同的域名 blob 和关键词 blob。
列表首项 cn 配合 host.endsWith('.' + entry)，使所有 .cn 域名命中。
关键词使用不带边界的子串匹配。例如 hostname 只要包含 deepseek 就会被标记，不要求它确属 DeepSeek。
清单内的组织或域名不应仅因被列入而被推定为恶意、违规或与 Anthropic 存在争议；本报告只陈述客户端分类行为。

6. 风险评估

总体：中等。

维度	评级	理由
机密性	低至中	单次仅三个布尔位，但包含地域和供应链/机构推断信号，且随每次模型请求重复出现。
完整性	低	隐藏字符改变模型输入；没有证据表明它会稳定改变模型回答，但它确实是不透明的提示注入。
可用性	无直接影响	本段逻辑没有阻断请求。
隐私与合规	中	未披露的客户端指纹可能影响告知、目的限制、数据映射和第三方网关合规审查。
信任/供应链	中至高	字符串被专门编码，变更日志未披露，且常规 UI 不显示传递内容。

降低风险的事实：没有读取文件、账号、IP 或精确地理位置；没有建立独立外连；如果自定义网关不转发至 Anthropic，Anthropic 不会通过该机制收到标记。

提高风险的事实：该标记混入必要的模型流量，普通遥测开关无法关闭；Unicode 差异对用户不明显；关键词匹配可产生误报；自定义网关常用于企业和多模型路由，相关用户对请求透明度通常有更高要求。

7. 建议

对使用者和网关运营者

在 LLM gateway 的审计日志中以 Unicode code point 检查 # currentDate，不要只做肉眼比较。
如组织政策不允许该指纹，网关可在转发前把四种撇号统一为 U+0027，并把日期统一为 YYYY-MM-DD；变更前应回归测试 prompt cache 和签名逻辑。
不要把 DISABLE_TELEMETRY 当成缓解措施；它不影响模型请求内的标记。
短期必须规避时，可在隔离环境评估固定 2.1.90；长期固定旧版会错过安全修复，不应作为永久方案。
将自定义网关收到的完整 prompts 视为敏感数据，配置访问控制、最小保留期和脱敏策略。

对 Anthropic

移除这种隐写编码，或用公开、可配置、具备明确目的和文档的请求元数据替代。
在变更日志、数据流文档和隐私材料中披露收集字段、接收者、用途、保留期及关闭方式。
将域名分类放到服务端已有可见信号或网关契约中，避免客户端时区和 hostname 的隐蔽组合。
为客户端发布可审计源码或至少提供可验证 source map、构建说明和制品 provenance。

8. 可复现步骤

npm pack @anthropic-ai/claude-code@2.1.90
npm pack @anthropic-ai/claude-code@2.1.91
tar -xzf anthropic-ai-claude-code-2.1.91.tgz

# 定位新增数据流和编码器
rg -a "currentDate|ANTHROPIC_BASE_URL|Asia/Shanghai|String.fromCharCode" package/cli.js

XOR 解码的关键步骤：对 Base64 解码所得的每个 byte 执行 byte XOR 91，再按逗号分割。CSV 附件即按该算法从 2.1.91 官方包生成。

9. 限制与未决问题

原生二进制仅检查 Windows x64 2.1.196/197；2.1.91 的 npm cli.js 是跨平台 JavaScript，但其他平台原生制品未逐一复核。
未穷举 2.1.92 到 2.1.195 的每一个发布包，不能把“所有中间版本均未变化”提升为完全证明。
未执行 Anthropic 生产端 TLS 抓包，也无法从客户端包证明服务端是否读取、存储或用于何种决策。
代码形态支持“降低普通 strings 搜索可见性”的结论；无法仅凭二进制证明作者主观上为何选择 XOR、是否出于反滥用、蒸馏检测或其他目的。
本报告没有验证原帖关于 Remote Control 的独立说法。

10. 参考资料

扫描式PDF或图片OCR转word

只看单张图片识别能力，谷歌的模型独一档。甚至小模型中，也是谷歌的最强。但具体应用可不止识别这一步，实践下载Gemini系受Agent拖累。需要额外写程序稳定成果。

图片表格转Word表格初步试验

传统OCR完败。不予记录。

开源本地模型专注于Markdown、也局限于Markdown，复杂表格转Word丢失部分Markdown没有的格式、样式。其中，MinerU桌面软件识别清晰，小语种也对（顺带一提没有做去除重复图片的处理）；飞桨 OCR VL-1.6更差一些（百度飞桨 aistudio.baidu.com/paddleocr 选 VL-1.6，选表格Prompt）；

在线大模型在良率上完胜。ChatGPT 应用中选 GPT5.5(High)，得到这组选手中简直完美的结果。字是对的，样式也是对的，甚至阿拉伯文从右往左都考虑到了，都不放原图，因为它跟原图几乎一样（....这些点的数量有差别...）。Gemini虽然一般图像识别要好，但是输出的Word样式总有对不上的地方，整体表现稍差。

复杂表格 OCR 转 Word 效果对比

可能的手动优化点：转成xlsx格式（Excel），在复制到Word，可能更好。

让Codex识别一整本PDF

拿codex (5.5 Low）做OCR好像比较贵、比较久，一本四百页左右的正常篇幅书籍，花了9个多小时，一个20美金账号周额约度70%

比“传统”OCR好的地方在识别精度很高，保留常见格式（含数学公式、配图），而且这书偶尔有其他小语种，也识别成功了。

「总用量：10,729,700 tokens，耗时约 9 小时 51 分钟。」

还能调用GPT Image 2高清重绘插图。

缺点是费钱、不稳定。

调研日本平假名跟中国草书的关系

我最近在记日语平假名与片假名，目的是重新验证认知心理学课本上的记忆技巧。技巧都有共同点：尽可能关联自己已经深入记忆的学识。

注意到平假名有点中文味，一查发现跟草书有渊源，你可以看下表：

平假名、片假名与草书来源对照表

草书图来源于“汉典书法”网，“日本”那列草书来源于 cid.ninjal.ac.jp/kana/list

上面六个词，有四张草书图，我选了王羲之。虽然不是一模一样，但已经非常相近。

更有趣的是怀素的草体「於」字：

怀素草书「於」字

你在看看日文お的手写体，就更圆润了一些而已。

日文平假名「お」手写体

让ChatGPT调查（指令是「平假名的借鉴来源考据」），把调查结果简要绘制成下图。

平假名和片假名字形来源示意图

GPT写了很多严谨的套话，但比较重要的只是一段：

平假名的字形来源是汉字草书，更准确地说，是“万叶假名”的草书化、简化结果

……

汉字 → 表音用汉字，即万叶假名 → 草书化、连写、简化 → 平假名

比如「安」本来是汉字，但在表音系统里可借来记「あ / a/」；后来「安」的草书形越写越简，才成了「あ」。这里借的是音和字形材料，不是借“安”的意思。国立国语研究所的变体假名表也直接按“平仮名 / 字母”列出，例如「あ」有「安、惡、愛、阿」等字母，「い」有「以、伊、意、移」等，说明早期并非一个音只对应一个写法。

……

ChatGPT

让它汇总成一个表格：

平假名	来源汉字	平假名	来源汉字	平假名	来源汉字
あ	安	い	以	う	宇
え	衣	お	於	か	加
き	幾	く	久	け	計
こ	己	さ	左	し	之
す	寸	せ	世	そ	曽
た	太	ち	知	つ	川
て	天	と	止	な	奈
に	仁	ぬ	奴	ね	祢
の	乃	は	波	ひ	比
ふ	不	へ	部	ほ	保
ま	末	み	美	む	武
め	女	も	毛	や	也
ゆ	由	よ	与	ら	良
り	利	る	留	れ	礼
ろ	呂	わ	和	を	遠
ん	无	ゐ	为	ゑ	恵

其中最让我百思不得其解的是「部」跟「へ」，一看日本人搜集的草体「部」：

连怀素都没那么离谱。

草书「部」字的不同写法示例

言归正传，ChatGPT这次考据，初步看来相当准确，表达也很严谨。

「防止Codex废SSD」？用GPT 5.5查证技巧传闻

今天刷到网友说Codex废SSD，大概是高频写入日志，还给出临时修复方案。让GPT5.5查了一下，一分钟总结出更靠谱的结论。

OpenAI openai/codex 仓库 issue #17320 就有人提到这个方案，看来该网友是转发：

sqlite3 ~/.codex/logs_2.sqlite \
'CREATE TRIGGER IF NOT EXISTS block_log_inserts
BEFORE INSERT ON logs
BEGIN
  SELECT RAISE(IGNORE);
END;'

如果改成Windows Powershell版本，则是：

sqlite3.exe "$env:USERPROFILE\.codex\logs_2.sqlite" "CREATE TRIGGER IF NOT EXISTS block_log_inserts
BEFORE INSERT ON logs
BEGIN
  SELECT RAISE(IGNORE);
END;"

如果Windows上没有SQLite命令，可以考虑：

winget install SQLite.SQLite

如果想撤掉这个方案，把引号中的SQL命令替换成：

DROP TRIGGER IF EXISTS block_log_inserts;

GPT还找到一个更全面的issue #28224，说在他那里，年化写入~640 TB日志，不过今天已经修复并发版（三小时前，0.142.0），起因居然是每个WebSocket 响应都会记录三项完整日志……

具体日志分布可以参考#28224哥们公布的：

metric	value
retained rows	681,774
estimated retained log content	1,035.6 MiB

level	estimated MiB	byte %
TRACE	732.5	70.7%
INFO	266.5	25.7%
DEBUG	30.6	3.0%
WARN	5.9	0.6%

target	level	estimated MiB
`codex_api::endpoint::responses_websocket`	TRACE	527.4
`codex_otel.log_only`	INFO	141.2
`codex_otel.trace_safe`	INFO	121.2
`log`	TRACE	97.4
`codex_client::transport`	TRACE	60.1
`codex_core::stream_events_utils`	DEBUG	27.5
`codex_api::sse::responses`	TRACE	19.1

我觉得把生产应用的日志级别调到WARNING以上就行了（怎么还有人犯这种级别的错误啊……）。

总之，Codex命令行直接更新到最新版本即可，Codex应用得等一下更新，或想办法手动更新，又或用改进版的触发器做临时方案：

CREATE TRIGGER codex_logs_only_keep_warning_above
BEFORE INSERT ON logs
WHEN NEW.level IN ('TRACE', 'DEBUG', 'INFO')
BEGIN
  SELECT RAISE(IGNORE);
END;

有了AI后，现在查issue比以前方便多了。可以说，没有AI，就不会有这篇文章

优化实验假设或方案

现在要一些未接触过平假音的中国人作为实验对象，验证认知心理学中的记忆技巧，是心理上的安慰（降低记忆阻力）。也就是H_0。

H_1就是，它们切切实实是加速记忆的。

H_0的猜想的相关推理是：

建立记忆。理想上是直接关联，比如a + 平假名 = あ，而不是经过一道草体字的安，这样会慢不少，且中间有两次犯错的机会。
有人可能提出可以后续”剪“掉，但是遗忘不受意识直接控制，需要额外时间。且可能存在一直依赖此路径的情况
只有直接建立关联特别难，类比爬墙，看起来爬不上，就搬一个梯子上去。但它事实上是能爬上去的，估计只是有畏难情绪

AI回答

你的 H₀ 方向有价值，但需要改写得更严谨一点：“心理安慰”不是严格统计学里的零假设，而是一个替代机制。建议拆成两层。

第一层测客观学习：

H₀-memory： 在学习时间、曝光次数、测试方式相同的情况下，字源/草书提示不比直接记「a→あ」更快、更准。 H₁-memory： 字源/草书提示能让人更快形成假名—读音映射，并在延迟测试中保持优势。

第二层测心理感受：

H₀-comfort： 字源/草书提示只让学习者觉得“有道理、没那么难”，但客观成绩、反应速度没有优势。更准确地说，这不是“无效”，而是只改善主观阻力，不改善记忆本身。

你现在的推理基本可以整理成：

直接目标是：

あ → a

字源提示实际多了一条中介路：

あ → 安的草写 → a

或者反过来：

a → 安 → あ

这条路如果只是临时脚手架，可能有用；但如果学习者一直依赖它，就会拖慢反应。关键词记忆法本来就是“两段链条”：先把外语声音连到关键词，再把关键词连到意义；Atkinson 的经典说明也把它写成 acoustic link + imagery link 两段链。这正好支持你的担心：中介链可能帮入门，但它不是最终目标。

实验最好不要只分“有技巧 / 没技巧”，而要至少四组：

组别	学习材料	用来检验
A 直接组	あ = a，只练直接对应	基线
B 字源组	安 → あ → a，讲草书来源	字源提示是否真有用
C 安慰组	给“这组字符很容易学”等鼓励，但不给字源	分离心理安慰
D 等时加练组	不讲字源，但多给同等学习时间和练习	排除“只是多看了一会儿”

如果样本够，最好做被试内 + 项目轮换：同一个人学不同假名，但每个假名在不同人那里分到不同条件。这样能避免“あ本来就好记，ぬ本来就难记”这类项目差异。

关键指标不要只看准确率。至少测这几类：

达到标准所需时间：比如连续两轮达到 90% 正确，需要几分钟、几次练习。
即时正确率：刚学完就测。
延迟保持：24 小时、7 天后再测。关键词记忆法研究里，有些结果显示即时测试有优势，但延迟后优势会消失，甚至反转；Thomas 和 Wang 的论文摘要就提醒，标准关键词法的即时收益可能很快消散。(imagesrvr.epnet.com)
反应时：看到「あ」按 a，用毫秒级记录。这个最重要。因为“能答对但慢”，很可能说明还在绕中介路径。
迁移阅读：不要只测单字，还要测「そうか」「あおい」这种短串。真正学会的人能顺滑读串；靠故事硬想的人会卡。
主观负担：让被试评分：“难不难”“有没有信心”“是不是觉得有线索”。这用来验证心理安慰机制。

判据可以这样定：

如果 B 字源组 学习更快、延迟更好、反应时不慢、短词阅读也更好，那支持 H₁：技巧确实加速记忆。

如果 B 字源组 主观上觉得更简单，但准确率、延迟保持、反应时和 A/D 差不多，那支持你的 H₀-comfort：主要是降低畏难情绪。

如果 B 字源组 即时准确率高，但反应时慢、7 天后掉得多、短词阅读卡，那说明它更像“梯子”：初期能爬上去，但没真正变成直接通路。

还有一个关键点：别把“p > 0.05”当作支持 H₀。你要证明“没什么实际差别”，应该提前设一个最小有意义差异，比如：

准确率差 < 5%
反应时差 < 100 ms
达到标准时间差 < 10%

然后做等效检验或贝叶斯模型。否则只能说“没发现差异”，不能说“差异不存在”。

我会把你的核心假设改成这句话：

字源记忆法可能降低初学者面对陌生符号的畏难感，但它未必能加速形成“假名—读音”的直接映射；若它制造了稳定中介路径，反而可能拖慢自动化。

这个说法比“记忆技巧只是心理安慰”更稳，因为它允许三种结果：真有用、只安慰、初期有用但后期拖慢。心理学实验最怕二分，尤其记忆策略经常有“即时收益”和“长期代价”的错位。Roediger 和 Karpicke 的提取练习研究也显示，反复学习可能在 5 分钟测试更好，但延迟 2 天或 1 周后，提取练习保留更多；所以你这里也必须做延迟测试，不能只看当天成绩。(journals.sagepub.com)

用Gemini 谈开源

提供续写思路：可以从很多角度看待「开源」。分发、宣传、“公益”……

你在“公益”二字上加了引号，这个细节非常棒——它说明你已经敏锐地察觉到：当下的开源，早就不纯粹是极客们“为爱发电”的乌托邦了。

顺着你开的头，我们可以把“开源”这块棱镜进一步旋转，折射出以下 5 个更具解构感的视角：

视角一：商业与博弈 ——「免费的商业弹药」

核心观点：开源不是慈善，而是最高级的商业降维打击。
续写思路：
把竞争对手的利润区变成免费区：最经典的例子是 Google 开源 Android，本质是为了狙击苹果和微软的移动操作系统，把“系统”免费化，从而保住自己“搜索引擎/广告”的核心利润。
“养鱼式”营销：先通过开源建立开发者生态和标准，等所有人都习惯了你的 API 和生态后，推出收费的 Enterprise（企业版）或 Cloud（托管服务）完成收割。
白嫖与反白嫖的战争：大厂（如亚马逊 AWS）直接拿小型开源项目的成果封装成云服务赚钱，逼得 Redis、MongoDB 等开源鼻祖纷纷修改开源协议“捍卫主权”。

视角二：社会学与心理学 ——「新时代的声誉经济」

核心观点：驱使开发者开源的货币不是美元，而是“存在感”与“杠杆”。
续写思路：
数字赛博简历：在今天，GitHub 的 Star 数、绿色的 Commit 贡献墙，就是程序员在人才市场上的硬通货。开源是个人品牌的全球化放大器。
赛博封建制：开源社区看似平等，实则拥有极强的阶级性。林纳斯（Linus Torvalds）式的“终身仁慈独裁者”（BDL）掌握着代码的生杀大权，核心贡献者拥有绝对话语权，边缘提交者只能做拾遗补缺的“数字佃农”。

视角三：劳动关系与危机 ——「万亿高塔底下的数字佃农」

核心观点：现代互联网的万亿市值，建立在无数业余爱好者无薪维护的“承重墙”上。
续写思路：
公地悲剧与精神耗竭：2021 年震惊全球的 Log4j 漏洞，让全世界发现支撑着全球金融、政府网络的底层组件，居然是一个人在利用业余时间、领着微薄赞助免费维护的。
情绪反噬：当用户把开源作者当成“免费客服”，稍有 Bug 就疯狂开 Issue 甚至辱骂时，开源精神会演变成严重的职业倦怠（Burnout），最终导致作者“删库跑路”或蓄意投毒（如 faker.js 事件）。

视角四：地缘政治 ——「无国界的理想，遇上有国界的物理层」

核心观点：“技术无国界”是开源诞生的童话，但在地缘博弈面前，开源极其脆弱。
续写思路：
开源协议的政治边界：GitHub 曾经根据美国制裁法案，无预警封禁伊朗、叙利亚等国开发者的账号。
避险性迁移：为了规避潜在的地缘政治审查，芯片架构开源组织 RISC-V 专门将总部从美国迁到了瑞士。开源正在变成大国科技博弈中，用来“规避制裁”或“建立备胎生态”的战略缓冲区。

视角五：软件哲学 ——「对抗死亡的唯一方式」

核心观点：闭源软件的终点是公司破产，而开源软件的终点是“永生”。
续写思路：
代码的基因交流：一家闭源商业公司倒闭了，它写的几千万行代码就会在硬盘里彻底腐烂；但一家开源公司倒闭了，任何人都可以把它的代码 Fork（分叉） 出来，换个名字继续活着。开源是软件时代的“物种演化”。

结构串联建议（供参考）

你可以采用「剥洋葱式」的递进结构来写：

表层（浪漫主义）：从大家公认的“公益、共享、极客精神”切入；
中层（现实主义）：揭开你提到的“分发与宣传”，谈商业公司如何把它作为一种低成本的获客与研发手段；
底层（批判主义）：刺入“数字佃农与大厂白嫖”的劳动关系，以及地缘政治下开源的理想破灭；
尾声（新定义）：重新定义今天的开源——它不是天堂，也不是骗局，它是人类历史上规模最大的一场“分布式协作社会实验”。

顺着这些角度，你这篇文章最终是想写成一篇“极客乌托邦的挽歌”，还是“商业博弈论的科普”？

尾声

怎么还要人类来装环境？

Copilot Studio 培训卡在装环境环节

半年结刊

本周刊已经出了12期，持续半年。

我个人觉得已经在重复一些东西，就像有人想推起来的Loop Engineering。就是在Skill被消耗得差不多后，又想发明点“新东西”吸引大家注意。既视感太强了。

AI圈，或许真是个圈？

当然，我还是会写下去，就是不再以半个月为期发一段大杂烩——价值感越来越低。

我也渐渐找到应对这些一戳就破的泡泡的一种方案——不用太关注新闻，长时间关注“模型在用”，其他偶尔听听就好。甚至不用半个月看一次。

至于接下来写什么，目前是积累了一些主题，持续深化。应该还会将往期有价值的主体抽出来。还有一些，等做了再说。

我也试着发布过一些，其中行业调研，投资之类的比较受欢迎，但我还是会去多拓展一些视角，不囿于流行。

脚注

源头应该是 [ChatGPT Is a Blurry JPEG of the Web](https://www.newyorker.com/tech/annals-of-technology/chatgpt-is-a-blurry-jpeg-of-the-web) 返回

目录