读者打开你的「ChatGPT 自定义 GPT 设置」教程。Step 3 写「打开 Configure tab,填 Knowledge 区」。但截图是 2024 年的布局,那块当时还叫 Upload files。读者屏幕上写的是 Knowledge,字段位置也不一样,于是卡住——连自己是不是在对的地方都不确定。同一个产品、改了标签、挪了字段。你写的时候文字是对的,UI 动了、图没跟上。
最快修法: 别再手动改图。(1) 按平台清点每张截图,这样一次重设计就能映射到一份已知的文章清单。(2) 先批量替换流量最高的受影响文章。(3) 再把截图交给脚本(Playwright)管理,让下次重设计时图自动重生成,而不是静默过期。检测、批量更新、截图流水线——按这个顺序来。
截图会按一个你控制不了的节奏老化过期。每次 UI 重设计都打破所有引用旧版的教程,而多数团队没有刷新流程,于是图从「有帮助」漂到「主动误导」,直到读者投诉才有人发现。AI 产品迭代很快,一张刚截的图几个月内就可能过期。
你属于哪一类
| 症状 | 可能原因 | 跳到 |
|---|---|---|
| 某平台重设计后它的文章全显旧 | 重设计后没审计 | 原因 1、Step 1 + 2 |
| 列不出某产品的全部截图 | 没集中索引 | 原因 2、Step 1 |
ls 看不出哪些图旧 | 文件名没版本戳 | 原因 3、Step 3 |
到处都是 "ChatGPT screenshot" 这种 alt | alt 太泛 | 原因 4、Step 4 |
| 文字和图描述的不是同一步 | 图文对齐松 | 原因 5 |
| 只有投诉才暴露过期 | 没有过期标记机制 | 原因 6、Step 5 + 6 + 7 |
常见原因
按命中率从高到低。
1. 平台重设计了,截图没重新审计
厂商某个周二推了重设计。你有 40 篇文章引用那套 UI。没人安排审计,于是这 40 篇当天集体静默过期。AI 产品动得快:ChatGPT、Claude、Gemini、Cursor 在 2025-2026 期间都重排过设置菜单、改过区块名字,所以一张截图在拍下几个月内就可能变错。
如何判断:挑一个近期重设计的平台,抽 5 篇引用其 UI 的文章,和今天的实际产品对比。3 篇或以上显示旧 UI,就是没审计。
2. 截图没集中索引
每篇文章把图 inline 放在自己旁边(或 src/content/.../assets/<slug>/),没有集中清单。UI 变时没有一份「产品 X 的所有截图」总表可对照。
如何判断:试着列出全站某一平台的每张截图。如果唯一办法是在几百个文件里手动 grep,就是没索引。
3. 文件名没版本戳
图叫 screenshot1.png 或 chatgpt.png,名字里看不出是上个月还是 18 个月前拍的。
如何判断:ls public/screenshots/(或你的 assets 目录)。文件名不带日期或版本标记,每张图实际上都是无日期的。
4. alt 文字泛泛,不具描述性
alt="ChatGPT screenshot" 谁也帮不到。WCAG 2.2 成功标准 1.1.1(Level A)要求文本替代要传达图的用途,而不只是说明「这里有张图」。泛 alt 也过不了你自己的审计——它没给出图本该展示什么的线索。
如何判断:grep alt="screenshot,或末尾只是一个光秃产品名的 alt 值。任何命中都太泛。
5. 文字没和截图具体对齐
文字说「点 submit」,截图在下方某处。按钮一挪,文字和图就分叉,之间没有锚把它们连起来,你也分不清某张过期的图属于哪一步。
如何判断:把一篇教程从头读到尾。如果你没法轻松说出「这张图说明第 N 步」,对齐就是松的。
6. 没有机制标记截图过期
没有 PR check、没有 lint、没有定期复查。过期只在读者投诉时才浮现。
如何判断:你上次主动刷新截图(不是为了响应投诉)是什么时候?答案是「不记得」就是没有流程。
最短修复路径
Step 1-2 找出并排队问题。Step 3-4 让年龄可见、可用。Step 5-7 防止复发——Step 7 是耐用的根治。
Step 1:按平台清点截图
用正确的 markdown 图片模式。开启图片的标记是 ![,所以要转义那个方括号:
# 每篇嵌入 markdown 图片的文章
grep -rlE '!\[' src/content/articles/ | head -40
# 从 markdown 图片里抽出图片路径 + alt
grep -rnoE '!\[[^]]*\]\([^)]+\)' src/content/articles/
# 也要抓 JSX <img> / <Image> 组件,markdown 正则会漏掉
grep -rnE '<(img|Image)\b' src/content/articles/
把命中按平台分桶(chatgpt-*、claude-*、gemini-*、cursor-*、midjourney-*)。结果就是原因 2 里缺的那份按平台索引。某平台重设计时,你已经知道要动哪些文章。
Step 2:先按流量、再按重设计新近度排优先
没法一次刷新全部,那就刷新读者真正会看的。
最高优先:
- 高展示文章(看 Search Console / analytics)
- 平台 6 个月内重设计过
低优先:
- 低流量文章
- 平台 UI 稳定 2 年以上
把按平台的清单按展示量排序,对任何近期改过的平台从上往下做。
Step 3:文件名带版本戳
重命名图片,让年龄从文件名就能看出:
之前:chatgpt-ui.png
之后:chatgpt-ui-2026-06.png
或标记重设计的代际:
chatgpt-ui-v3-redesign.png
现在 ls 一眼看出哪些旧。刷新时写一个新文件(chatgpt-ui-2026-12.png)并改文章引用;旧文件留下来,作为 UI 过去样子的带日期快照。
Step 4:alt 文字写具体
<!-- 差:什么都没说,过不了 WCAG 1.1.1 -->
<img src="..." alt="ChatGPT screenshot" />
<!-- 好:说出这张图要证明什么,约 125 字符 -->
<img
src="..."
alt="ChatGPT GPT editor, Configure tab, Knowledge section with two files attached (2026-06 UI)"
/>
alt 控制在 125 字符左右——多数屏幕阅读器在这个长度附近会停顿——并以图的用途开头,别用 “image of” 或 “screenshot of”。具体 alt 同时服务慢连接读者、屏幕阅读器用户,和你自己未来的审计。如果你有大量泛 alt,先批量修;见 大量图片缺 alt 文字。
Step 5:建季度审计 checklist
# screenshot-audit-Q2-2026.md
## ChatGPT 文章(15)
- [ ] chatgpt-custom-gpt-setup — 拍于 2024-08,重设计 2026-03 -> 更新
- [ ] chatgpt-memory-feature — 拍于 2026-04,当前 -> OK
## Claude 文章(12)
- [ ] claude-projects-setup — 拍于 2025-11,检查标签是否改名
每篇大约预算 10 分钟重拍,放进季度节奏。
Step 6:在 MDX 里记录拍摄日期
import ChatGPTUI from "./assets/chatgpt-ui-2026-06.png";
{/* captured: 2026-06, ChatGPT GPT editor v3 */}
<img src={ChatGPTUI} alt="ChatGPT Configure tab, Knowledge section (2026-06)" />
然后一个小 CI 脚本就能解析这些 captured: 注释,把任何超过阈值(比如 9 个月)的图列为「待 review」,把看不见的老化变成可见的清单项。
Step 7(根治):用脚本生成截图
唯一能彻底止住截图过期的办法,是不再手工画图。用 Playwright 驱动真实 UI,从一个纳入版本库的脚本里抓图:
// screenshots/chatgpt-gpt-editor.spec.js
import { test } from '@playwright/test';
test('GPT editor Configure tab', async ({ page }) => {
await page.goto('https://chatgpt.com/gpts/editor');
// ...用保存的 auth state 登录,导航到 Configure tab...
await page.getByRole('tab', { name: 'Configure' }).click();
await page.screenshot({
path: 'src/content/.../assets/chatgpt-ui-2026-06.png',
fullPage: false,
});
});
重跑脚本,每张图都反映当前 UI——按钮挪了、区块改名了,重生成的图都会带出来,不用再手动翻找过期文件。在上面再叠两层检测,均经核实截至 2026 年 6 月仍适用:
- CI 里做视觉 diff。 Playwright 的
expect(page).toHaveScreenshot()(或 Percy / Applitools)把每张抓图和基线对比,像素一动就让构建失败,于是厂商重设计变成一个红色检查项,而不是一条读者投诉。 - Playwright MCP。 让 agent 驱动同一个浏览器,从一句提示词里重新生成文档截图,适合在两次完整脚本运行之间做一次性刷新。
对于没有公开 / 可登录 URL(或反爬很严)的产品,保留 Step 5-6 的手动节奏——但能自动化的都自动化。
如何确认已修好
- 把刷新后的文章和实际产品并排打开,逐条走每个编号步骤。文字里点名的每个标签、tab、字段,截图里都出现。
grep -rnE '!\[|<(img|Image)\b' <article>只返回带版本戳、日期为当前的资源。- 每张截图都有说明它展示什么的 alt 文字(没有
alt="screenshot")。 - 如果你做了 Step 7:截图脚本在本地跑绿,且视觉 diff 检查已接入 CI,下次重设计会让构建失败。
预防建议
- 文件名带版本戳,
ls就能看出年龄。 - 维护好按平台的文章索引,任何重设计都能直接映射到一份审计清单。
- 跑季度审计,并为它预算时间。
- 在 MDX 里记
captured:日期,加一个 CI 脚本 flag 超龄的图。 - 给每张截图写具体、以用途为先的 alt(WCAG 1.1.1)。
- 用 Playwright 脚本化抓图,加一道视觉 diff 闸门,让重设计打破的是构建,而不是读者的信任。
- 平台重设计后两周内批量更新受影响文章——别等投诉。
常见问题
AI 工具的 UI 到底多久变一次? 频到季度审计只是下限、不是上限。ChatGPT、Claude、Gemini、Cursor 在 2025-2026 期间各自都改过设置菜单、重命名过区块。任何快迭代 AI 产品的截图,过两个季度就当它可疑。
重设计后是不是每张截图都得重拍? 不用。按流量排优先(Step 2)。只改了一个标签名的重设计,可能只影响引用那个标签的步骤;整体布局大改才会牵动全部。把实际 UI 和你的抓图做 diff,真正动了的才更新。
对小站点,用 Playwright 自动化截图值得吗? 如果你有不止几篇 UI 教程,值得——第一次有平台重设计时它就回本了,因为重生成取代了横跨每篇文章的手动翻找。只有几页的话,Step 5-6 的手动节奏就够了。
截图的 alt 文字理想长度是多少? 125 字符左右。屏幕阅读器常在这个长度附近停顿,而且它逼你说出图的用途,而不是逐像素描述。如果一张截图确实需要更多,就在周边正文或图注里描述,alt 保持简短。
截图是当前的,但读者还是迷路——为什么? 多半是原因 5:文字没锚到图上。在步骤里引用确切标签(「点 Configure」),把截图直接放在它说明的那一步下面,并裁到相关区域,别让读者去扫整个 UI。