メニュー
代理节点/中转链健康巡检:逐节点探端口存活、延迟、出口 IP、流量,读中转链探针日志,核对订阅有效性,输出一张红黄绿健康表。只诊断不改动。触发:/ray-nodecheck 或 /ray-nodecheck 「节点名」。
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
把口播文稿、观点句或一个完整选题做成编辑隐喻拼贴风格的视频（黑白半调剪贴 + 平坦色场 + 从空场逐件组装的定格动画）。两种模式：单句 5 秒 B-roll（单条或批量），以及 beat map 驱动的 45–60 秒完整讲解片（含旁白 TTS、内容感知变速、字幕与拼装）。用户说“拼贴 b-roll”“纸拼贴视频”“vox 那种风格的视频”“半调拼贴动画”“给这句口播配画面”“把这个选题做成拼贴讲解视频”时使用；也承接 ray-writer / ray-cover 产出后的视频化下游需求。不用于：需要精确图层与时间线控制（转 HyperFrames）、只要提示词不要成片、真人口播或产品实拍广告。
把已经定稿的中文长文排成适合手机浏览的微信公众号富文本，生成可复制预览，在用户确认后创建或更新公众号草稿，并回读核对标题、封面、正文、空段落、署名和中文编码。用于“给公众号重新排版”“把这篇推到微信公众号草稿箱”“更新已有微信草稿”“公众号排版太单调或有多余空行”“恢复失败的草稿更新”时。优先更新文章 frontmatter 记录的原草稿，不制造同题重复草稿；未经明确授权只做到预览，不发布文章。
rayskills 工具箱的主入口与路由。当用户不确定该用哪个 ray-* skill、只是丢来一个真实任务/处境，或明确要求把一篇内容从 idea、调研、写作、封面一路送到公众号或 X Articles 草稿箱时，用本 skill 读取上下文，判断最该做的一步或执行已确认的内容生产链。也用于一轮工作完成后决定下一步。触发：/ray 或 /ray 后接任何真实任务描述。用户无需记住具体 skill 名。
把灵感、剪藏审核卡、调研包、长期知识或已有草稿装配成有事实、有情绪、有网感和传播力的中文长文，并接入用户本地 Obsidian 知识库的成稿包、调研、草稿、发布与复盘流程。用于用户说“把这个 idea 写成文章”“从这条资料发展成长文”“写一篇公众号或 X 长文”“检查或重写这篇文章”“把内容生产流水化”时；找不到兼容知识库时先转交 ray-obsidian 建立或适配。不得虚构用户经历、数据、现场或情绪，不自动发布，也不使用 WeWrite。
把已经确定核心判断的文章、成稿包或长文转成公众号、普通 X 分享图与 X Articles 后台封面。提炼一个可一眼读懂的视觉隐喻，在 Ray 的编辑视觉体系中选择复古现代主义、极简隐喻、安静油墨、编辑隐喻拼贴或工具桥接方向，先生成无字底图，再用确定性排版写入准确中文标题，并输出各平台文件、提示词和清单。用于“给这篇文章做封面”“公众号和 X 都要封面”“做 5:2 Article 封面”“用 Adrian 或 Vox 那类风格”“把内容生产接上封面管线”时；不用于正文写作、自动发布或完整解说视频。
在用户本地新建、检查或渐进适配一个面向长期知识与内容生产的 Obsidian 知识库，复用 Ray 的资料、知识、灵感、成稿包、调研、草稿、发布与回流分层。用于“帮我搭一个 Obsidian 知识库”“给 ray-writer 准备本地知识库”“把现有 vault 接入内容生产管线”“检查知识库结构是否完整”时；也在 ray-writer 找不到兼容知识库时使用。只补缺失结构，不覆盖、移动或删除用户已有笔记，不强制安装插件、同步服务或 Git。
| name | ray-nodecheck |
| description | 代理节点/中转链健康巡检:逐节点探端口存活、延迟、出口 IP、流量,读中转链探针日志,核对订阅有效性,输出一张红黄绿健康表。只诊断不改动。触发:/ray-nodecheck 或 /ray-nodecheck 「节点名」。 |
对一组代理节点和中转链做一次体检,产出一张能一眼看出"哪台病了、病在哪"的表。只读不写——发现问题给判断和建议动作,不自动切换、不自动重启(切换是人工决策)。
/ray-nodecheck # 全部节点 + 中转链
/ray-nodecheck us-node-1 # 单节点深查
/ray-nodecheck --sub # 只核订阅有效性
先定位节点清单来源:
config.json 里的 nodes[])→ 读出 name/server/port/ssh_host<probe_log_dir>/<chain>.log(目录按你的部署而定)对每个节点,并行跑:
1a. 端口存活
curl -sk -o /dev/null -w '%{http_code}' --connect-timeout 10 https://<server>:<port>
判定:返回 400 或 200 = 活(Reality 对非 VLESS 客户端回 400,是正常的);超时/连接拒绝/000 = 死。
1b. 连接延迟
curl -sk -o /dev/null -w '%{time_connect}' --connect-timeout 10 https://<server>:<port>
分档:<0.5s 好 / 0.5–2s 慢 / >2s 或超时 判死。
1c. 面板侧实况(若节点跑 3x-ui,可选)
经面板 API 拉入站的实时流量(↑/↓)和 client 状态,顺带确认 clients 不是 null(空 email 坑的后遗症)。
从节点实际出口看到的公网 IP,验证是不是预期落地:
ssh <ssh_host> 'curl -s --connect-timeout 10 https://api.ipify.org'
用途:① 确认没被识别/污染 ② 中转链上确认出口落在正确的末端机器 ③ IP 变动(CGNAT 漂移)预警。把结果和上次记录比,变了就标黄。
探针每 15s 一跳,logfmt 单行写日志。读最近状态:
ssh <relay_host> 'tail -5 <probe_log_dir>/<chain>.log'
ssh <relay_host> 'grep -vE "result=ok" <probe_log_dir>/<chain>.log | tail -50' # 只看异常
日志字段与判读:
chain=<chain> tcp_connect_ms=42 wg_hs_age_s=18 probe_dur_ms=45 result=ok
| result | 含义 | 阈值 | 该做什么 |
|---|---|---|---|
ok | 健康 | tcp<500ms 且 wg 握手<180s | — |
slow | 延迟高 | tcp 500–2000ms | 观察,连续出现查中间跳 |
tcp_timeout | 转发不通 | tcp>2000ms 或连不上 | 中转那一跳挂了,考虑人工切链 |
wg_stale | 隧道实质断 | wg 握手≥180s(漏约7次keepalive) | WG 隧道挂,查对端/重启 wg |
wg_unknown | 探不到握手 | wg 命令失败/无输出 | 探针环境或 wg 接口问题 |
wg_hs_age_s=-1 表示从未握手或探测失败。切链事件历史看探针日志目录下的 switches.log。
curl -s <订阅URL> | head -50
核对:
proxies: 节点数 == 期望节点数(少了说明某节点掉出订阅)proxy-groups 里节点名和实际节点对得上.mrs 源 URL 可达(自建源挂了会导致客户端规则加载失败)输出一张总表,按严重度排序(死的在最上面):
节点 端口 延迟 出口IP 状态 备注
─────────────────────────────────────────────────────────
us-node-1 ❌死 — — 🔴 curl 超时,查中转链
us-node-2 ✅活 0.8s 1.2.3.4 🟡 延迟偏高
jp-node-1 ✅活 0.1s 5.6.7.8 🟢
中转链 chain-a — 42ms — 🟢 wg 握手 18s,正常
中转链 chain-b — timeout — 🔴 tcp_timeout,最近12跳异常
订阅 — — — 🟢 4/4 节点在册,源可达
表下附: