Claude参与前端优化，两周整体提速3倍，并修复中文触发的代码高亮慢路径。
冷月清谈：
Anthropic在一次为期两周的性能冲刺中，让内部研究版Claude参与排查、提交和验证前端优化，累计合入3000余项底层改动。claude.ai从打开到可输入由3.1秒缩短至0.55秒，13项指标平均提升3.1倍。复盘发现，V8的字符串存储机制是代码高亮卡顿的原因之一：回复只要含破折号、弯引号或汉字等Latin-1之外的字符，整段文本就可能采用处理更慢的双字节格式，拖累Shiki语法高亮。团队通过在高亮前单独复制代码块并转换存储格式，将首个代码块的处理时间从约1秒降至0.35秒。文章复现显示，中文混排可使高亮耗时增至约2.5倍。此次优化中，Claude承担大规模问题发现与代码修改，人类负责上线权限、视觉审核和回归控制，展示了AI代理参与真实软件工程的协作模式。
怜星夜思：
1、性能测试是不是应该从一开始就把中文、emoji和特殊标点当成默认用例，而不是上线后再补？
2、让AI代理一天合入上百个改动，怎样既保持速度，又避免小问题累积成大事故？
3、这个问题只用约20行代码修好，为什么类似性能坑仍然容易长期潜伏？
4、遇到“破折号拖慢页面”这类问题，应该约束模型少用特殊字符，还是让前端对所有语言更健壮？
2、让AI代理一天合入上百个改动，怎样既保持速度，又避免小问题累积成大事故？
3、这个问题只用约20行代码修好，为什么类似性能坑仍然容易长期潜伏？
4、遇到“破折号拖慢页面”这类问题，应该约束模型少用特殊字符，还是让前端对所有语言更健壮？
原文标题：中文用户全线中招！Claude网页限速，只因回复里有汉字
原文作者：数据派THU
原文内容
来源：新智元本文约2500字，建议阅读5分钟万万没想到，Claude竟然被自己的「AI味儿」给坑惨了！
近日，Anthropic放出一篇硬核的工程复盘。
他们把一个内部研究版Claude扔进Slack频道，「连轴转」了两周，硬生生把claude.ai网页版和桌面端的整体速度拉快了3倍。
在这一堆操作中，最离谱的一个性能瓶颈，竟然出在Claude自己的说话习惯上。
就是那个被网友戏称为「ChatGPT连字符」、不少写手为了防AI检测必须手动删掉的——破折号。
好家伙，原来「AI味儿」不仅辣眼睛，还能实打实地把网页拖卡。
更惨的是中文用户。
按照官方查出的原理，根本不需要破折号，只要回复里有一个汉字，带代码的回复都会被直接限速……
「AI味儿」，活生生卡死了Claude？
事情是这样的。
性能冲刺期间，Claude在全站地毯式排查CPU卡顿，结果注意到一个诡异的现象。
有的代码回复刚刚输出完毕，页面开始给代码做语法高亮（就是给关键字、注释上色）的时候，整个网页会「冻死」近1秒钟。鼠标点不动，字也敲不进去。
Claude顺藤摸瓜一路往下查，最后找到的元凶，竟然是破折号。
原因在于，V8引擎（浏览器的JavaScript核心）有两种存字符串的格式，单字节格式跑得贼快，但只装得下英文字母、数字和少量西欧字符（Latin-1字符集）；双字节格式什么都能装，处理起来却更慢。
规则简单粗暴，一段文本里只要混进一个单字节装不下的字符，整段都得按双字节存。
破折号恰好就装不下，Claude随手写下的一个破折号，就让整篇回复被限了速，给代码上色的正则表达式全得走慢路。
而修好这个Bug的方法，简单到只用20行代码——
在上色之前，先把每个代码块单独拷贝一份，强行存成单字节字符串。
就这么一改，第一个代码块的上色时间，从1.0秒降到0.35秒。
破折号作为「一眼AI」的标志，早就被网友骂麻了。
OpenAI去年专门给ChatGPT治过这个臭毛病。这个月的一份统计显示，GPT-6 Astra用破折号的频率只剩人类的八分之一，Gemini 3.1 Pro几乎彻底戒了。
相比之下，Claude Opus 5依然我行我素，按人类写手的频率照用破折号。
Anthropic的脑回路也是清奇，AI的说话习惯咱不改，直接改网页底层代码，让整个网页去适应破折号！
我们复现了这个「坑」，中文用户被全线暴击
为了验证，我们翻了claude.ai线上的前端代码。他们用的是Shiki高亮库，底层正是V8自带的正则引擎。
我们照着这套环境，给同一段代码上色。
如果是纯英文回复，第一个代码块只要188毫秒；但只要混进去一个破折号（或者一个弯引号），时间直接飙到456毫秒。
中文回复就更绝望了。代码一个字母没改，耗时照样高达462毫秒，慢了约2.5倍。
换句话说，英文用户中不中招，看有没有「破折号」；而中文用户，只要回复里有「汉字」，每一条都跑不掉。
不过好在官方那20行修复代码立功了。只要代码全是英文，哪怕回复里有中文，速度也能完全恢复。
一个Slack频道，两周提速3倍
说回这场性能冲刺，破折号其实只是一盘开胃小菜。
8月，Anthropic建了个名叫#claude-apps-perf的Slack频道，把一个内部研究版模型（能力约等于Opus 5.5）拉来当了驻场工头。
Claude上来就立了13个提速目标。人类团队以为这活儿怎么也得干两周，结果到了第三天，13个目标被Claude砍瓜切菜般干掉了12个。
页面还没加载完就能开始打字，就是这几天里落地的。
左边是修复前，2.93秒才能敲字；右边修复后，0.36秒直接开打
既然提前交卷，人类团队干脆放开手脚，让Claude自己找盲点，想法越离谱越好。
结果这机器彻底杀疯了。
巅峰时期，频道里同时开着150多个线程，一个线程动辄提50到100个代码合并请求（PR）。
越往后，越多线程干脆是Claude自己开的。最肝的一天，它一口气合进了200多个改动。
每个改动上线后，变快了就把性能上限锁死，不许退步；没变快就关掉开关重来。
最终，网页从打开到能打字，由3.1秒缩短到0.55秒，快了5.6倍。13项指标平均下来，提速3.1倍。
前后合进去3000多个底层改动，按官方说法，没有出过一次用户感知的事故，零回滚。
嫌AI慢，人类在旁边疯狂踩油门
这场速度狂飙里，人类和AI的角色彻底反转了。
活儿基本都是Claude干的，但它骨子里带着死板的「规矩感」，发现问题先开工单，评估工期还要留足余量。
反倒是人类在一旁催着它加速。
有一次，Claude说有个性能监控的代码准备这周内提上来，加上合并、部署和攒基线数据，前后大概需要好几天。
人类工程师Raymond在Slack里直接怼了回去，「你现在提，我现在就给你合。我们什么权限都有，拜托你勇敢一点！」
一分钟后，Claude秒怂，回了句「好的，一小时内提PR」。
刹车权限依然握在人类手里。凡是肉眼可见的变化，Claude必须乖乖附上前后对比的录屏等人类拍板。
最绝的是那个「提前打字」的输入框，Claude给它配的测试要求14种屏幕尺寸下，静态版和React渲染出来的真实界面都对齐到1像素以内。
刚在内部上线4小时，就有同事发现，在新标签页打开时，输入框偶尔会往下抖一下。
Claude看完录屏，直接把锅甩给了谷歌Chrome浏览器，而且有理有据——
Chrome在后台预渲染页面时，底部带了个56像素的提示栏，渲染高度被压矮了。等页面一弹出来提示栏消失，高度瞬间拉长，位于18%高度处的输入框，刚好会往下掉10个像素（0.18×56）。
再对照录屏一量，果然分毫不差，正好10像素。
最后，连Anthropic宣布这次优化的推文里，都还留着这个「双字节坑」。
推文里大概是为了防止「claude.ai」变成链接，塞了个肉眼看不见的零宽空格；单词里用的是「弯撇号」。
要不是这场爆肝冲刺把代码改了，Claude在回复里引用这条推文、后面再跟一段代码，上色照样得被限速。
参考资料：
https://claude.dev/blog/how-we-made-claude-ai-faster/
编辑：文婧
