为了防 Claude Code 误删文件,我在全局 settings 里加了一条 deny 规则 Bash(rm -rf *)。翻本机 10 月 7 日到 21 日的会话记录:这条规则拦下 14 次删除,模型被拒后 8 次换新目录名、6 次直接放弃删除,一次都没换写法绕过。但在 Claude Code 2.1.285 上用 stub 逐字回放 22 种删除写法后发现:rm -fr、rm -r -f、rm -Rf、rm -r 在手动、auto、bypass 三种模式下都照删不误,/bin/rm、find -delete、bash -c 在手动和 bypass 模式下也能删。auto 模式下,工作目录内的 rm -fr 会被当成「acceptEdits 也会放行」的操作,连分类器都不过。另一道闸是内置的 dangerous-rm 检查,目标是 $D/* 这类变量展开时触发,bypass 模式也拦;多行命令里前面有 heredoc,它就跟不上同一条命令里的变量赋值。文末给出一个 PreToolUse hook,三种模式下补齐全部递归删除写法,并告诉模型被拒后该怎么做。
给一个日更公众号做了 40 天「LLM 提案 + 代码判定」的自动调优循环:18 个版本、8 次回滚,其中 3 次回滚掉的是人拍板的决定,还有一个旋钮与父版本完全相同的版本也被判了回滚。按真实数据算,每个版本要攒约 2.5 万阅读才分得出 20% 的差异,日均 60 阅读的小号要跑 400 天。本文复盘飞轮转不起来的五个原因,以及真正起作用的是什么。
用第三方模型跑 Claude Code auto 模式,每个有副作用的动作都会用你的会话模型向同一个后端多发一次判定请求:系统提示词 132,470 字符,单次约 2.97 万输入 token,比主循环那一步还多。判定请求一失败,就出现「xxx is temporarily unavailable, so auto mode cannot determine the safety of Bash」。本文用故障注入代理把每种失败对应的报错原文测了一遍:500 → (server error)、429 → (rate-limited)、529 → (overloaded)、断连 → (connection failed),这几种会自动重试 5 次;超过 60 秒没回 → (timed out);**没有括号 = 后端拒收(4xx),只试 1 次,重试多少遍都一样**;后端回了但模型没给判定 → could not evaluate,连续 3 次就退回人工确认。另外实测 CLAUDE_CODE_AUTO_MODE_MODEL 不生效,判定器只能跟着会话模型换。Claude Code 2.1.285,真实后端 DeepSeek v4-pro 与小米 MiMo v2.5。
在 24GB M4 Mac mini 上用 LM Studio 跑 gemma-4-e4b(Q4_K_M)实测:生成速度约 29.5 tok/s,GPU offload 从全开调到全关只慢 11%;真正让人觉得慢的是长 prompt 的预填充——1.3 万 token 的 prompt 要等 39.4 秒才出第一个字(约 330 token/s),全 CPU 时还要再慢 3.4~3.7 倍。相同前缀的第二次请求首字只要 0.1 秒(前缀缓存)。--parallel 4 时同时来 4 个请求,每个只剩 9.7 tok/s。
24GB 的 M4 Mac mini,Ollama 0.19 只认到 17.8 GiB 显存,默认上下文只给 4096。实测 qwen3:4b:上下文从 4k 开到 32k,占用从 3.73GB 涨到 9.89GB;OLLAMA_NUM_PARALLEL=4 时 8k 上下文占用等于单路 32k,但 ollama ps 只显示 8192;开 Flash Attention + q4_0 KV 量化后 32k 只要 4.31GB、64k 只要 5.77GB,速度不变。上下文开到远超内存时 Ollama 不会提前拒绝,而是直接开始分配,16 秒内系统可用内存掉到 23%。全部挪到 CPU 只慢 25%。
Claude Code 靠报错文案判断「上下文太长」:后端说 prompt is too long 或 input is too long for requested model,它会自动压缩对话后重发,用户无感;DeepSeek 和 OpenAI 风格中转返回的 This model's maximum context length is …,它不认识,直接报 API Error: 400,每轮都失败。手动 /compact 有效;更好的办法是用 CLAUDE_CODE_MAX_CONTEXT_TOKENS(非 claude- 模型 ID)或 CLAUDE_CODE_AUTO_COMPACT_WINDOW(claude- 模型 ID)告诉它真实上限,让它提前压缩。Claude Code 2.1.285 + 本地 stub 实测。
Claude Code 转圈不动、或者停在 Retrying in 0s,多半是后端没有回数据。实测 2.1.285(API key + ANTHROPIC_BASE_URL):后端不回响应头时每次等 6 分钟(360 秒)才判超时,把 API_TIMEOUT_MS 调到 60 万、90 万也不变,只能调小;默认重试 10 次,总共可能卡一个多小时。中转站如果把回复缓冲到生成完才返回,超过 6 分钟的回复永远拿不到。按 Esc 可以随时中断。全部在本地 stub 上实测。
Claude Code 遇到 429 会先自动重试,最多 10 次、约 3 分钟。retry-after 不超过 60 秒时会等满再试(实测 10 秒、60 秒都恢复成功),61 秒及以上一次都不重试,立刻报 API Error: Request rejected (429)。中转站(new-api)的中文限流提示会原样显示,空 body 显示 status code (no body)。交互模式下每句话会同时发 2 个请求,限流额度消耗也是 2 倍。全部在本地 stub 上实测,Claude Code 2.1.285。
果蝇全脑 13.9 万个神经元,在一台 Mac mini 上模拟 1 秒脑时间要 12.6 秒,权重矩阵约 121 MB。照同样的模型和算法外推:小鼠 7,089 万个神经元,模拟 1 秒要约 41 小时、权重占约 1.4 TB 内存;人脑 861 亿个神经元,模拟 1 秒要约 5.7 年、需要约 1.7 PB 内存。但算力还不是最难的墙。按 FlyWire 的校对效率,光是把小鼠脑的 AI 分割改对,就要约 1.7 万人年;而且就算接线图完整,现在的模型也没有学习、记忆和神经调质。本文把四堵墙逐一摆出来,每个数字都注明出处和假设。
MaleCNS 是一只雄性果蝇完整中枢神经系统的接线图:166,700 个神经元,第一次把大脑和腹神经索(相当于脊髓)放在同一张图里。2026 年 6 月发布 v1.0,9 月在 Cell 上发表,许可证 CC BY 4.0,可以商用。它和 2024 年的 FlyWire 是两套完全不同的工程:不同性别、不同电镜、不同的 AI 分割。论文对比雌雄两只脑发现,11,710 种神经元里只有 138 种两性异形、289 种雄性特有、71 种雌性特有,而且都集中在高级脑中枢。我用 FlyWire 官方注释表按脑区重算了一遍,比例最高的不是中央脑,而是大脑向身体发指令的下行神经元:8.4%。
macOS 上的 Clash Verge Rev 2.5.6,系统代理模式一切正常,一打开 TUN(虚拟网卡)就连百度都打不开。直接连 mihomo 内核的 API 排查,发现是两个独立的根因叠在一起:一是 Hysteria2 节点的 UDP 出站没有绑定到物理网卡,被 TUN 路由吸回自己,形成回环;二是系统 DNS 被 Tailscale MagicDNS(100.100.100.100)接管,查询走 Tailscale 的 utun,Clash 的 dns-hijack 拦不到,拿回来的是被污染的 IP。修法只需两段 Merge 覆写:route-exclude-address 把节点 IP 排除出 TUN,再打开 sniffer 从 SNI 还原域名。文中每一步都附复现命令和实测输出。
一只雌果蝇的大脑被切成 7,062 片、每片 35~40 纳米厚,电镜拍了 16 个月、2,100 万张照片、106 TB;AI 把每根神经纤维描出来,再由科研人员、专业团队和一群游戏玩家改了 3,013,513 次,最终得到 139,255 个神经元、5,450 万个突触的完整接线图。本文按工序拆开这张地图的制作过程,也讲清楚常被搜到的「谷歌果蝇」到底是怎么回事:Google 在 2019 年给这只果蝇做过一版自动分割,但 FlyWire 最终用的是普林斯顿自己重做的版本。