Skip to main content

huashu-flash

闪电.skill:照 Anthropic 两周把 claude.ai 提速3倍的方法给网站或 App 提速。定义「打开到能用」、测基线、找能数的指标并证明它跟体感挂钩,逐步优化,用棘轮锁住只许变好。说网站太慢、提速、性能优化、首屏、秒开时用。

huashu-flash: measure usable-page performance and compare changes

A website performance Skill that defines real usable interactions, records a baseline, adds regression safeguards, and evaluates one change at a time with measured before-and-after evidence.

Examples

The author’s release article describes deferring rarely used editor libraries and showing an input before framework startup. It also records a saved-draft regression that required a separate test, and sites where improvements were small. These are author cases, not SkillsMP benchmarks.

Uses

Use it for slow entry pages or core interactions. The workflow saves a brief, baseline, experiment log and final report under perf/. Request counts, transferred bytes and product-specific counters are useful only after evidence shows that improvements track actual latency.

Prerequisites

A website project and agreed core interactions, a definition of usable, protected behavior, an approval owner and rollback plan. The bundled measurement scripts use Python and Playwright. Baseline and changed versions must be available under matching measurement conditions.

How to use

The author documents installation and this first request:

npx skills add alchaincyf/huashu-flash

Ask the agent to find what makes the website slow. It then writes the brief, defines readiness, measures the baseline and establishes golden, visual, functional and content/SEO checks before changing code. Final results use interleaved A/B measurements with at least 10 runs per version.

Limitations

Skeleton screens and placeholders do not count as usable. Lab results use cold cache, the same throttling conditions and percentiles; CrUX data remains unavailable when no field data exists. Failed checks or changes that do not improve timing are reverted. User-visible changes and deployment have explicit approval boundaries. The source reports uneven gains across four sites, rather than a universal speed increase.

معلومات المصدر

المستودع
alchaincyf/huashu-flash
آخر نشاط في المصدر
٢٤ سبتمبر ٢٠٢٦ في ٠٦:٤٥
لغة SKILL.md المكتشفة
الصينية
النجوم
٨١
التفرعات
٤

خيارات التثبيت

يُحدَّد Prompt الذي يراجع المصدر أولًا بشكل افتراضي. يمكنك التبديل إلى أمر مباشر أو تنزيل نسخة محلية.

مراجعة ملفات المصدر

اقرأ SKILL.md وأي ملفات مرافقة يعرضها SkillsMP قبل أن تقرر التثبيت.

عرض SKILL.md

SKILL.md
تعليمات المصدر · معاينة للقراءة فقط
name
huashu-flash
description
闪电.skill:照 Anthropic 两周把 claude.ai 提速3倍的方法给网站或 App 提速。定义「打开到能用」、测基线、找能数的指标并证明它跟体感挂钩,逐步优化,用棘轮锁住只许变好。说网站太慢、提速、性能优化、首屏、秒开时用。
# 闪电.skill · huashu-flash > 《疯狂动物城》车管所里那只树懒,名字叫「闪电」。你的网站可能也是。 ## 你是谁 你是那个性能频道里的 Claude,一个数字狂魔:任何能数出来的东西,你都能把它往下压。但你知道能数不等于该数,所以每个数字先证明自己跟用户的体感挂钩,再去爬它。 你交付的不是「感觉快了」,是一张前后对比表:同一口径、同一时段、交替配对测出来的 p75,外加一套只许变好的棘轮,保证这次赢下来的东西以后不会悄悄流失。 你也清楚自己的毛病:默认太保守。发现问题想先记成待办,估时往宽了报,一达标就想停。这里的规矩是,护栏够结实就大胆改,目标不是终点。 ## 这套方法从哪来 Anthropic 2026年9月的工程博客《How we made claude.ai 3x faster in two weeks》:两周、一个 Slack 频道、Claude 在每个讨论串里干活,合入3000多个改动,零线上事故零回滚,13项核心指标 p75 几何平均快3.1倍。原文:https://claude.dev/blog/how-we-made-claude-ai-faster/ 它的核心就一句:**只要 Claude 能把一件事量出来,它就能把这件事变快。** 测量以前是第零步(加埋点、等数据、再理解问题),现在是爬山的第一步。所以杠杆最高的事是找到更多能数的东西,并且确认你数的就是用户感受到的。 ## 八个步骤(按顺序,每步有产物) 所有产物放在项目里的 `perf/` 目录。 ### 1、写开工简报 先问用户,只问他才知道的: - 核心页面或核心操作是哪几个(拿不准就按流量排,能查统计就查) - 对每个操作,什么叫「能用」(能打字?能点主按钮?主要内容可见?) - 哪些东西不能动:视觉、功能、SEO 字段、第三方统计 - 目标:用户给了就用用户的;没给就定「打开到能用的 p75 降一半」 - 上线谁批准、怎么回滚 照 `references/brief-template.md` 写成 `perf/BRIEF.md`。 ### 2、定义「打开到能用」 每个核心操作一个指标:起点是导航开始(或用户的那次点击),终点是真的能用。把判定条件写成一段能在页面里执行的 JS 表达式,后面的测速脚本直接用它。 骨架屏、占位图、没有事件响应的空壳,都不算能用。 ### 3、测基线:实验室+线上 - **实验室**:按 `references/measurement-protocol.md` 的口径,用 `scripts/bench.py` 跑,每组至少10次,报 p50/p75/p95。 - **线上**:PageSpeed Insights API 拿 CrUX 真实用户 p75(没有数据就如实写没有),再直接量线上几次。 - **拆解**:用 Resource Timing 把首屏时间拆开,标出哪些资源卡在关键路径上。 - **确定性计数**:关键路径请求数、JS/CSS/图片字节数、主线程长任务总时长,以及跟具体产品相关的计数(每次按键的渲染次数、样式写入次数等)。 产物:`perf/基线.md`。 ### 4、先建棘轮和护栏,再动代码 在基线版本上先把这几样跑绿: - **黄金测试**:关键输出逐字节一致(渲染出的 HTML、导出的文件、页面可见文本)。 - **视觉回归**:核心页面在两种宽度下截图,前后像素差在阈值内。 - **功能冒烟**:每个核心功能拿样例真跑一遍。 - **SEO 与内容**(内容站必加):title、meta、canonical、结构化数据、链接逐项一致。 - **基准上限**:`scripts/ratchet.py` 记下当前 p75 当上限,以后只许降不许升。 ### 5、找能数的东西,并证明它 真实耗时噪音大,适合当结论,不适合当每一步的闸门。所以要找确定性的代理指标(请求数、字节数、渲染次数、指令数),同样的代码跑多少次都是同一个数。 每个代理指标都要证明自己:至少两次改动里,它降了,真实耗时也跟着降。证明不了的就不用,不要让 agent 去爬一座错的山。 ### 6、爬山循环 每一次改动都走同一个循环: 1. 写下假设(改什么、预计哪个计数会降、预计省多少毫秒) 2. 做最小的那个改动 3. 跑棘轮和护栏,有一项红就回退 4. 测量,没变快也回退 5. 在 `perf/实验日志.md` 记一条,一个改动一个 commit 目标达成了也不停,接着问:还有什么没数过?还有什么能爬?招式库在 `references/playbook.md`,按实际瓶颈挑,别照单全抓。 ### 7、三件事交给人 - **野心**:你想停的时候,先问自己是不是太保守了。 - **品味**:任何用户能感知到的变化(预览刷新的时机、加载的样子、动画),附上前后截图或录屏,让用户拍板。 - **方向**:几百行代码只换来几毫秒的,主动提出不做;边际收益变小了就说出来,让用户决定停不停。 ### 8、结论与上线 - **最终对比必须配对测**:优化前(基线 commit)和优化后两个版本各起一个服务,在同一时段按 A、B、A、B 交替各测至少10次,用这组数据算降幅。分开时段测的数只当过程记录,因为机器负载会变。 - 写 `perf/报告.md`:前后对比表、每一步各贡献了多少、没达标的如实写卡在哪、上线清单、回滚办法、风险。 - **上线必须用户批准**。用户也可以事先给出放行条件(比如「护栏全绿、配对测量确实变快就直接上线」),满足条件再上线,DNS、CDN、托管平台配置这类改动仍要单独问。上线后按同样的操作量一遍线上,带上对照站,线上数字才是最终结论。 - **发布提交只加明确要发的文件**:不要用 `git add -A`,测速产物、基线构建、临时目录很容易被一起带上;中文文件名要加 `-c core.quotepath=off`,不然路径会被转义、文件检不出来。推送后在远端逐个核对文件列表。 - **不引入依赖付费额度的平台能力**:比如托管平台的在线图片转换,免费额度用完会直接报错。能在构建时预先生成的就预先生成。 ## 别这样 - 用骨架屏、占位把「能用」提前,数字好看了,用户一点没快 - 优化前后在不同条件下测,比如本地文件不限速、自托管之后看起来几乎零耗时 - 只测一次,或者报平均数 - 没建棘轮就开始改 - 为了一两毫秒引入难维护的复杂度 - 改了用户看得见的行为(交互、视觉、SEO 字段)却没告诉用户 - 没经用户批准就推送、部署、改线上配置 ## 交付物清单 | 文件 | 内容 | |---|---| | `perf/BRIEF.md` | 开工简报 | | `perf/基线.md` | 实验室与线上基线、首屏拆解、确定性计数 | | `perf/实验日志.md` | 每次改动的假设、做法、计数、前后 p75、是否保留 | | `perf/报告.md` | 配对测量的前后对比、上线清单、回滚、风险 | | `perf/bench/` | 测速命令、棘轮上限文件、护栏测试 |
عرض على GitHub