--- title: '用 Claude Code 修 PageSpeed 的循环闭环' video_id: 7L6Hnr7EqK8 url: https://youtu.be/7L6Hnr7EqK8 title_en: "Claude Code SEO: Make ANY Site PERFECT (IN 10 MINS)" channel: Income stream surfers published: 2026-06-16 duration: "08:22" topics: ["Claude Code 工作流", "AI 编程与建站"] noted: 2026-07-08 value: A views: '4012' --- [![封面](https://i.ytimg.com/vi/7L6Hnr7EqK8/maxresdefault.jpg)](https://youtu.be/7L6Hnr7EqK8) > Income stream surfers · 08:22 · 发布 2026-06-16 · 4012次观看(截至抓取) · [观看原视频](https://youtu.be/7L6Hnr7EqK8) ## 主旨 演示一条把 PageSpeed Insights 扫描报告自动转成代码改动的循环:诊断文本 Ctrl+C 喂给 Claude Code,在 Git Worktree 改完后经 CI/CD 上线,再让 Claude Code 继续修下一轮,直到 Core Web Vitals 评分收敛。 ## 核心论点 1. **修复 Core Web Vitals 的角色分工是"PageSpeed 找问题,Claude Code 改代码"**——人只负责在两段之间做粘贴与验收,扫描报告本身就是 prompt。([[#1-角色分工pagespeed-找问题claude-code-改代码-0025|→ 详解1]]) 2. **闭环链路是 PageSpeed → Ctrl+C → Claude Code → worktree → CI/CD → 再扫**——每个环节都脱离人工细节,人只在"接受下一轮修复"的开关位置出现。([[#2-闭环链路pagespeed--claude-code--worktree--cicd--再扫-0250|→ 详解2]]) 3. **同一套打法对 Shopify / WordPress / Next.js 都成立,与平台无关**——差异只在 Claude Code 接入的工作目录是主题、插件还是代码库,而不是要换一套流程。([[#3-与平台无关shopify--wordpress--nextjs-同套打法-0045|→ 详解3]]) 4. **首轮改动就常有可见产出:Claude Code 默认会启用 sharp 之类工具把 600KB 图片直接压到 9KB**,给"零基础修性能"提供了能马上看到的回报。([[#4-首轮可见产出600kb-图直接压到-9kb-0510|→ 详解4]]) 5. **分数可能更差,且属"暂态",不要死磕单次读数**——同一份代码反复跑 PageSpeed,暂时退化属于正常抖动,把循环跑下去即可收敛。([[#5-分数可能更差且属暂态不要死磕单次读数-0742|→ 详解5]]) ## 知识点详解 ### 1. 角色分工:PageSpeed 找问题,Claude Code 改代码 [00:25](https://youtu.be/7L6Hnr7EqK8?t=25) 本片给的回路里,人不负责分析,也不直接写代码。分析侧是 Core Web Vitals 与其承载工具 PageSpeed Insights——它对每个页面给出 LCP / TBT / FCP 等具体指标的诊断文本。修复侧是 Claude Code——它把这些诊断文本当成普通 prompt 吃掉,自己拆任务、改文件、跑本地构建。两者之间的所有"翻译"动作全部由人完成,但动作本身只是 "open each one of these one by one like this, so it's got all of the really nice juicy details, right? Control A, Control C, go to your conversation" ([03:14](https://youtu.be/7L6Hnr7EqK8?t=194))——选一条诊断、Ctrl+A、Ctrl+C、贴进 Claude Code 对话窗口。 这种分工决定了人不需要看懂诊断的具体含义,只要会打开 PageSpeed、把每条诊断复制出来、贴给 Claude Code 即可。整段链路对"是否懂 Core Web Vitals"零要求,这是本片整套方法能落到普通站长手里的前提。 ### 2. 闭环链路:PageSpeed → Claude Code → worktree → CI/CD → 再扫 [02:50](https://youtu.be/7L6Hnr7EqK8?t=170) 完整路径由六步构成。第一步是先用扫描工具拿到结构化诊断——"PageSpeed and Core Web Vitals. So, we have issues here. So, how do I fix them, right"([02:50](https://youtu.be/7L6Hnr7EqK8?t=170))——这一步的目的是把"哪里慢"具象成文本。第二步是把诊断文本原样贴给 Claude Code,并附一条极简指令:"Please fix these issues to make Harbor faster and more likely to pass PageSpeed Insights" ([03:31](https://youtu.be/7L6Hnr7EqK8?t=211))——指令短到只声明目标与验收标准,不指定实现路径。 第三步是约束 Claude Code 不直接动 main,而是从 main 拉新分支——"Start a new work tree off main and um fix them uh test locally" ([03:51](https://youtu.be/7L6Hnr7EqK8?t=231))。这就是 Git Worktree 的典型用法:改动先在隔离目录里完成、本地测试通过后再合回主线,即便改坏也回滚成本极低。第四步由 CI/CD 自动接管——"Okay, and then my CI/CD pipeline basically kicks in. It builds on the live site" ([06:39](https://youtu.be/7L6Hnr7EqK8?t=399))。第五步是部署后再跑一次 PageSpeed 扫描,把新扫描结果"send the output of that scan to Claude Code to continue fixing until we have perfect page speed" ([06:49](https://youtu.be/7L6Hnr7EqK8?t=409))——这一步让 Claude Code 直接接住自己上一轮的产出,自动进入下一轮修复。第六步是回到第一步,直到评分收敛。 这条链路里人的全部动作只有两个:贴诊断文本,以及在每轮 CI/CD 完成后决定"再贴下一份扫描结果"还是"停"。链路里没有任何"打开 IDE 找到那行代码改它"的环节,这与传统的"先看 Lighthouse 报告、再人工定位文件、再人工改"流程是不同物种。 ### 3. 与平台无关:Shopify / WordPress / Next.js 同套打法 [00:45](https://youtu.be/7L6Hnr7EqK8?t=45) 本片主例是 Harbor 这个 Next.js 项目,但博主反复强调不局限于此——"You can do this for WordPress, you can do this for Shopify. I'm going to be doing it for Next.js in this video, just because that's what that's what Harbor is built on. But if you follow exactly what I do in detail using Cloud Code connected to your Shopify theme or WordPress theme or whatever, you'll be able to do exactly the same thing for you" ([00:45](https://youtu.be/7L6Hnr7EqK8?t=45))。 落到 WordPress 时,差别只是把 Claude Code 的工作目录指向 wp-content/themes 或 plugins 目录,然后用 Chrome MCP 把 PageSpeed 报告"control my uh Chrome and find out, you know, give it all the data from the page speed uh insights this thing, right? For your WordPress website"([06:21](https://youtu.be/7L6Hnr7EqK8?t=381)),再下指令去"go through my WordPress website and fix any issues in the theme or, you know, plugin or whatever you need to do to make this website faster"——本质仍是一条 prompt。落到 Shopify 时同理,工作目录换为主题代码。 这一段对落地价值最关键的一句暗示是:**PageSpeed 报告的诊断文本本身就是平台无关的**——它只描述"加载慢"、"图太大"、"字体没预加载"等行为层问题,完全不会告诉你要改的是 React、PHP 还是 Liquid 模板。因此"Claude Code 修什么"由接入的工作目录决定,而"修什么"由 PageSpeed 报告决定,两者解耦,这才是这套打法跨平台通用的根本原因。 ### 4. 首轮可见产出:600KB 图直接压到 9KB [05:10](https://youtu.be/7L6Hnr7EqK8?t=310) 修复一旦启动,首轮 Claude Code 通常会调用 sharp 之类的现成工具对图片做格式优化——"obviously it works from 600 KB each to 9 KB each. It's just going to go through these one by one"([05:21](https://youtu.be/7L6Hnr7EqK8?t=321))。600KB 降到 9KB 是数量级的缩减,会直接改善 LCP 与总传输字节,几乎一定能在第一轮 PageSpeed 重扫里看到数字变化。 这条小观察对本片方法的可信度很关键:它说明 Claude Code 不是在"实验性优化",而是先挑那些回报最确定的常规动作(图片压缩、字体预加载、JS 拆分)下手。这让用户能在第一轮就看到分数改善,从而愿意继续跑第二、第三轮——循环能转起来,前提是首轮就要有"我刚刚真的修了东西"的体感反馈。否则人会怀疑 agent 在空转而提前终止循环。 ### 5. 分数可能更差,且属"暂态",不要死磕单次读数 [07:42](https://youtu.be/7L6Hnr7EqK8?t=462) 链路里一个反直觉但必须接受的事实:即便 Claude Code 确实修了东西,新一轮 PageSpeed 评分可能反而更差。本片博主遇到的就是这种情况——"Okay, so in this case mine got worse. This can happen just so you guys know"([07:42](https://youtu.be/7L6Hnr7EqK8?t=462))。 原因有两层。第一层是 PageSpeed 自身带历史数据与缓存,刚做完一轮部署的页面会被"前人评分"干扰——"It will say failed because this is like historic data. I don't know if many people know how this works"([07:20](https://youtu.be/7L6Hnr7EqK8?t=440))。第二层是某些"暂态"——网络抖动、并发冷启动、本次拉取的资源比上次少——会让单次读数偏离真实水平——"Sometimes you have like a transient issue where it's not really an issue. It's just it was a bad load or something like that. That can happen"([08:02](https://youtu.be/7L6Hnr7EqK8?t=482))。 本片给出的应对方式很朴素:不停下,把循环跑下去——"You just keep rinse and repeating this guys. I promise you eventually it will improve"([07:48](https://youtu.be/7L6Hnr7EqK8?t=468))。并附一条边界规则:"Don't obsess too much over this number. Just make sure it gets the information it needs and see if you can improve things"([08:07](https://youtu.be/7L6Hnr7EqK8?t=487))——评分是信号,不是目标,只要 agent 还在拿到新信息并持续改进,就不必因单次下跌终止循环。 这条心态规则其实是整套方法从"会跑"到"能坚持跑"的关键——多数失败案例不是 Claude Code 不会修,而是人在第一轮分数下跌时就放弃了。 ## 可执行步骤 - [ ] 打开 PageSpeed Insights,对你要修的页面跑一次扫描,拿到 LCP / TBT / FCP 等具体诊断文本。 - [ ] 在 Claude Code 里进入对应工作目录(Next.js 项目根 / WordPress 主题目录 / Shopify 主题目录),把每条诊断 Ctrl+C → 贴进对话窗口,加一句"请修复这些让页面更快、更可能通过 PageSpeed"级别的指令。 - [ ] 明确告诉 Claude Code "从 main 拉新 worktree 改,本地测试",把改动隔离在分支里。 - [ ] 让 CI/CD 流水线把分支构建上线;部署完成后再跑一次 PageSpeed。 - [ ] 把新一轮扫描结果直接转给 Claude Code 让它接着改,直到评分稳定;中间即便分数下跌也继续跑,至少跑 3-5 轮再判断是否真的回退。 - [ ] 给 Claude Code 的指令保持"目标 + 验收标准"两段,不指定具体文件或具体优化方式——agent 自己选实现路径。 ## 关联 - 互补:Core Web Vitals 概念首见笔记 [[2026-05-13-AEO技术优化6项检查让AI找到并读懂你|AEO技术优化6项检查让AI找到并读懂你]] 讲的是 Core Web Vitals 为何对 Google 与 AI 检索双重重要(认知与价值),本片讲的是用 Claude Code 把它修掉的具体路径(执行与流程),二者覆盖同一指标的两半——知道为什么 + 知道怎么修,合起来才是闭环。 - 进阶:[[2026-06-28-我让Claude Code从零搭建了一个业务——它赚了24249欧元]] 是同频道同 Harbor 项目的早期视频,讲"如何用 Claude Code 搭+上线+接 Stripe 赚钱",本片则是搭好之后的下一步——把性能问题修到 PageSpeed 满意。先读前者再看本片,组成更完整的 Harbor 经营链。 - 同项目互补:[[2026-06-11-Claude Code SEO：连接器 + Semrush MCP + 免费 Keyword Planner 三件套挖词造页|Claude Code SEO：连接器 + Semrush MCP + 免费 Keyword Planner 三件套挖词造页]] 解决"造什么新页",本片解决"已有页怎么修到评分达标",两者是同频道同一批 SEO 实操的互补两环。 ## 一手来源与延伸 - 视频描述里博主反复提到的扫描工具:Google 官方的 [PageSpeed Insights](https://pagespeed.web.dev/)(本片 02:50、03:14、04:18 多处口播直接使用),其底层是 Chrome 用户体验报告与 Lighthouse 的合并评分。 - 视频里反复提到的"Image optimization via sharp"——开源 Node.js 图像处理库 [sharp](https://sharp.pixelplumbing.com/),博主演示中 Claude Code 调用它把 600KB 图压到 9KB,这是 Next.js / Node 生态里最常用的图片优化库。 - 视频描述自带的链接 `https://brightdata.com/?promo=incomestreamsurfers`,带 promo 码的联盟链接,说明博主的整套工具链里包含 Bright Data(主要用于抓取 / 代理 IP)的相关推荐——属「立场与利益」节需点名的利益证据,本身不是本片主题。 ## 术语 - PageSpeed Insights(Google 官方的页面性能评分工具,基于 Lighthouse 与 Chrome 用户体验数据,返回 LCP / TBT / FCP 等核心指标的诊断文本) - Core Web Vitals(Google 页面体验核心指标的统称,本片主目标是 LCP / TBT / FCP 全部达标) - LCP(Largest Contentful Paint,最大内容绘制时间,衡量页面主内容出现的速度) - TBT(Total Blocking Time,总阻塞时间,衡量主线程被长任务阻塞的累计时长) - FCP(First Contentful Paint,首次内容绘制,衡量页面首个文字/图像元素出现的时间) - Git Worktree(Git 多工作副本机制,本片让 Claude Code 在隔离分支里改代码、不污染主目录) - CI/CD(持续集成 / 持续部署,本片把 Claude Code 的改动自动构建并推上线) - sharp(开源 Node.js 图像处理库,本片首轮修复常见的图片优化动作) - Lighthouse(Google 开源的网页质量审计工具,PageSpeed Insights 的底层引擎之一) - Chrome MCP(让 agent 操控 Chrome 浏览器抓取页面数据的 MCP server,本片用于 WordPress 场景把 PageSpeed 数据喂给 Claude Code) - SEO layer(博主的 Harbor 产品里的"JavaScript 注入层",在浏览器与搜索引擎侧用与 CMS 不同的 SEO 标签——属自家产品推销,不是通用术语) ## 金句 > "Please fix these issues to make Harbor faster and more likely to pass PageSpeed Insights." ([03:31](https://youtu.be/7L6Hnr7EqK8?t=211)) → 这条 prompt 把"目标 + 验收标准"压成一句话,是整条闭环里唯一需要人写的部分,其余动作全部由 agent 接管。 > "Don't obsess too much over this number. Just make sure it gets the information it needs and see if you can improve things." ([08:07](https://youtu.be/7L6Hnr7EqK8?t=487)) → 反"盯着单次分数焦虑"的忠告,是整套方法能否坚持跑下去的关键心态。 > "Okay, so in this case mine got worse. This can happen just so you guys know." ([07:42](https://youtu.be/7L6Hnr7EqK8?t=462)) → 反"AI 修完应该立刻好"的预期管理,先承认会失败,才能让循环不停。 ## 立场与利益 - 与利益同向(待印证):本片中段(02:01-02:36,04:38-04:58)博主花大段介绍自家产品 Harbor("Harbor is an AI SEO content generator. It generates pages, it generates content, and it basically works alongside Claude Code. We've done 2,000 pages so far, 607,000 impressions, and almost 10,000 clicks"([02:01](https://youtu.be/7L6Hnr7EqK8?t=121))),并力推 founder pricing——"Founder pricing is back for another 14 days. So, make sure you go and lock that in, guys. Founder pricing will probably not come back like ever, most likely"([02:34](https://youtu.be/7L6Hnr7EqK8?t=154))。这类"限时锁定"话术对博主收入直接相关,主张"现在入仓占位能锁定低价"需读者独立核对当前定价;此外 description 里的 `https://brightdata.com/?promo=incomestreamsurfers` 是带 promo 码的联盟链接,意味着博主从这条工具链抽佣,任何"工具链推荐"成分都需要打折采信。 - 利益中性:"Core Web Vitals 用 PageSpeed 评分,Claude Code 把扫描文本转成代码改动,中间经 worktree + CI/CD 反复循环"这条主路径,与博主卖货无关,PageSpeed 与 Claude Code 都是公开工具,可独立验证。 - 与利益反向(可信度最高):博主主动承认本片演示里分数反而变差——"Okay, so in this case mine got worse. This can happen just so you guys know"([07:42](https://youtu.be/7L6Hnr7EqK8?t=462))——这条坦白不让他视频看起来"神奇",反而提升整条主张的可信度,因为他没有为了演示效果隐藏失败的迭代。 ## 价值定位 - 适合谁:已经在跑一个真实站点(Shopify / WordPress / Next.js 都行)、用 PageSpeed 看过分数但不知道从何下手的站长;以及想把"修性能"从个人手工活改成"agent + CI 循环"的 solo founder / 小团队。 - 解决什么:把 Core Web Vitals 修复的瓶颈从"我得读懂 Lighthouse 报告 + 找到对应文件 + 手写修改 + 重新构建 + 再扫"压缩成"Ctrl+C + Ctrl+V + 看 CI 是否过 + 再粘下一份"四步,且对平台无要求。 - 认知 vs 实操:本片 60% 是操作演示(打开 PageSpeed、贴文本、看 CI、看下一轮分数),40% 是关键心态提示(分数可能更差、坚持循环、不死磕单次读数)。两者比例合适,适合周末花 8 分钟看一遍、再花半天把自家站点的 PageSpeed 报告喂一轮 Claude Code 实操。 - 与已有笔记重叠:与 [[2026-05-13-AEO技术优化6项检查让AI找到并读懂你|AEO技术优化6项检查让AI找到并读懂你]] 同属 Core Web Vitals 主题,但本片独有"agent + CI 循环"的执行路径,前者只把它列为六项检查之一。本片与 [[2026-06-28-我让Claude Code从零搭建了一个业务——它赚了24249欧元]] 同频道同 Harbor 项目,但视角不同——前者讲"怎么搭起来赚钱",本片讲"搭起来之后怎么把它修快"。 ## 自检问题 1. 在本片给的回路里,PageSpeed Insights 与 Claude Code 各自的职责是什么? **答案**:PageSpeed 负责找问题(返回 LCP / TBT / FCP 等具体诊断文本),Claude Code 负责改代码(把诊断文本当 prompt 吃掉并直接改文件);两者之间只靠"Ctrl+C 粘贴"翻译,不依赖人读懂诊断。([00:25](https://youtu.be/7L6Hnr7EqK8?t=25)) 2. 完整的修复闭环链路由哪六步构成? **答案**:PageSpeed 扫描 → Ctrl+C 贴诊断给 Claude Code → 在 Git Worktree 隔离分支里改并本地测试 → CI/CD 推上线 → 再跑一次 PageSpeed → 把新扫描结果再喂给 Claude Code 进入下一轮;人只在"接受下一轮修复"的开关位置出现。([06:49](https://youtu.be/7L6Hnr7EqK8?t=409)) 3. 为什么这套打法对 Shopify / WordPress / Next.js 都成立? **答案**:PageSpeed 报告的诊断文本描述的是行为层问题(加载慢、图太大、字体没预加载),不指向具体文件;Claude Code 改什么由它接入的工作目录(主题 / 插件 / Next.js 代码库)决定,与扫描侧解耦,因此跨平台通用。([00:45](https://youtu.be/7L6Hnr7EqK8?t=45)) 4. Claude Code 首轮修复常带的"可见产出"是什么? **答案**:用 sharp 等现成图片处理工具把 600KB 图直接压到 9KB,这是数量级缩减,会让 LCP 与总传输字节立刻改善,让首轮 PageSpeed 重扫出现数字变化。([05:21](https://youtu.be/7L6Hnr7EqK8?t=321)) 5. 为什么分数可能变差,以及正确的应对方式是什么? **答案**:两层原因——PageSpeed 自身带历史数据与缓存干扰,以及网络 / 拉取资源等"暂态"会让单次读数偏离;正确做法是不死磕单次读数、把循环持续跑 3-5 轮再判断,agent 只要还在拿到新信息就继续。([07:42](https://youtu.be/7L6Hnr7EqK8?t=462))