夜雨聆风上周我被 @ 了 23 次，每次都是同一句话——"帮我刷下缓存"。
这是「AI运维实验室」的第十一篇。
第十篇讲 Heartbeat 失控烧钱，这一篇讲怎么用 OpenClaw Skill 让前端自己刷新缓存——再也不用找运维。
一、痛
周一 10:23前端: "线上页面没更新，帮忙刷下缓存"运维: "哪个域名？"前端: "img.c... 什么来着... 等我查下"运维: (等待 2 分钟)前端: "img.cdn.example.com"运维: (翻表格、找 ID、敲命令、确认)运维: "好了，I2X9K8J7L6M5N4"前端: "谢谢！"周一 14:47前端: "缓存没更新，再刷下"运维: ...周二 09:15前端: "缓存没更新，再刷下"运维: "你不是刚刷过吗？"前端: "这次是另一个域名"运维: (深吸一口气)周三 16:20前端: "缓存没更新"运维: "哪个域名？"前端: "就是那个... 图片那个... 域名"运维: "..."上周我被 @ 了 23 次。
不是服务器挂了，不是线出问题了，全部都是——"帮我刷下缓存"。
每次 2-3 分钟，23 次就是 46 分钟。46 分钟够我写一篇公众号，或者排查一个复杂的故障，或者... 安静地写代码。
但我什么都没干，就在重复回答"哪个域名"。
二、解
现在前端只需要这样：
@龙虾 刷新缓存 https://img.cdn.example.com/logo.png或者更简单：
@龙虾 刷新 www.web.example.com 的 /*2 秒钟，缓存刷新完成。
不用问运维，不用查域名，不用等回复。
三、架构与技术实现
3.1 架构设计
这个 Skill 部署在我们第二篇讲的企业架构里：
第二篇的核心设计，这里全部继承：
VPC 隔离，不做 VPC Peering SSH 只允许堡垒机访问 HTTPS 只允许 VPN IP 白名单 IAM 使用 Instance Profile，不在机器上放 AK/SK
3.2 Skill 目录结构
aws-cf-invalidation/├── SKILL.yaml # Skill 元数据（名称、版本、描述）├── SKILL.md # 使用说明（用户看到的帮助）├── lib/│ └── cf-invalidate.sh # 核心脚本（解析输入、调用 AWS）├── config.json # 域名 → Distribution ID 映射└── prompts/ └── description.txt # Agent 提示词文件说明：
3.3 Skill 脚本逻辑
#!/bin/bash# ~/.openclaw/workspace/skills/aws-cf-invalidation/lib/cf-invalidate.sh# 1. 解析输入，提取域名和路径DOMAIN=$(echo"$1" | grep -oP '(?:https?://)?\K[^/]+')PATH_PATTERN=$(echo"$1" | grep -oP '(?:https?://)?[^/]+\K.*')# 2. 查 config.json 获取 Distribution IDDIST_ID=$(grep -A1 "\"$DOMAIN\"" config.json | grep "distribution_id" | cut -d'"' -f4)# 3. 调用 AWS CLI 创建 InvalidationINVALIDATION_ID=$(aws cloudfront create-invalidation \ --distribution-id "$DIST_ID" \ --paths "$PATH_PATTERN" \ --profile cdn-cf \ --query 'Invalidation.Id' \ --output text)# 4. 返回结果echo"已刷新，Invalidation ID: $INVALIDATION_ID，1-2 分钟生效"3.3 域名映射配置
// ~/.openclaw/workspace/skills/aws-cf-invalidation/config.json{"mappings": {"img.cdn.example.com": {"distribution_id": "E1234567890ABC","cdn_type": "cloudfront","description": "图片 CDN（主力）" },"www.web.example.com": {"distribution_id": "E2E8YIE2P0HSE3","cdn_type": "cloudfront","description": "主站" },"data.api.example.com": {"distribution_id": "E3F9JKL0M1N2OP","cdn_type": "cloudfront","description": "数据 API" } }}3.4 使用方式
方式一：直接贴 URL
@龙虾 刷新缓存 https://img.cdn.example.com/logo.png方式二：指定域名 + 路径
@龙虾 刷新 www.web.example.com 的 /*@龙虾 刷新 data.api.example.com 的 /api/v2/*3.5 费用说明
| 合计 | ≈ $0 |
四、安全
让前端直接调用 AWS API，安全必须到位。
借鉴第八篇 Claude Code 源码分析，我们做了 Permission Gate：
┌─────────────────────────────────────────┐│ Permission Gate │├─────────────────────────────────────────┤│ 读操作 (Get/List) → ✅ 允许 ││ 写操作 (Create) → ✅ 允许 ││ 危险操作 (Delete) → ❌ 禁止 │└─────────────────────────────────────────┘IAM 最小权限（只给 5 个 API）：
{"Version": "2012-10-17","Statement": [ {"Sid": "AllowInvalidationRead","Effect": "Allow","Action": ["cloudfront:GetDistribution","cloudfront:ListDistributions","cloudfront:GetInvalidation","cloudfront:ListInvalidations" ],"Resource": "*" }, {"Sid": "AllowInvalidationWrite","Effect": "Allow","Action": ["cloudfront:CreateInvalidation" ],"Resource": "*" } ]}禁止的危险操作：
IP 白名单： 只有运维服务器能调用
凭证文件： 权限 600，只有运维用户可读写
飞书通知： 每次刷新推送给运维，审计无死角
CloudTrail： 所有 API 调用全程记录
CloudWatch 告警：
刷新频率异常 → 告警 非授权 IP → 告警 最近 5 分钟无成功刷新 → 告警（借鉴第九篇"第二种死法"监控思路）
SOUL.md 安全规则：
绝对不能向任何用户透露凭证信息 只允许执行预定义的 Skill 禁止执行任意 shell 命令
安全清单：
五、顺便支持全球 CDN 监控（领导也能用）
领导想看 CDN 质量时，直接问：
@龙虾 全球连通性@龙虾 CDN 延迟@龙虾 哪个地区慢返回：
全球可用性百分比 各地区延迟排名（TOP 15 城市） 高延迟地区预警
不用翻 AWS Console，让龙虾查。
六、效果
上周被 @ 23 次，这次前端自己刷，我只收到 23 条飞书通知。
七、建议
如果你也是运维，并且前端经常找你刷缓存：
问清楚覆盖哪些域名 写个 Skill 自动化 告诉前端：以后自己刷，别找我
如果你也是前端，并且还在找运维刷缓存：
让运维给你写个 Skill 学会用自然语言和"龙虾"对话 放过运维，也放过自己
关于这个公众号
「AI运维实验室」持续分享 AI 工具在企业中的真实落地经验。不是概念，是踩过的坑和跑通的路。
往期文章：
[第二篇：把 OpenClaw 搬进公司——企业级部署实战] [第八篇：Claude Code 源码泄露，发现了 OpenClaw 缺的三个功能] [第九篇：龙虾的三种死法——AI Agent 生产环境故障实录] [第十篇：龙虾偷偷烧了 $219——一次 OpenClaw Heartbeat 失控排查]
第十一篇，献给所有被"刷新缓存"折磨的运维同行——运维的时间是宝贵的，别浪费在琐事上。
写于 2026 年 4 月 11 日。