你花了一下午做好一个仪表盘、作品集或文档站——然后到了没人喜欢的那一步：把它弄上线。要选主机、要敲部署命令、要在公开前先预览、还要有把握出问题能回滚。如果你曾在晚上 11 点部署网站、结果线上 URL 出现一个坏掉的资源路径，你懂这种痛。Hermes 现在内置一个可选技能，把整套仪式变成五步、一条命令的流水线：publish-site。

2026 年 8 月 27 日合并（PR #72189）的 publish-site 是一个零核心占用的技能——不新增工具、不改动 Hermes 核心——效果等同于 ChatGPT Work 的 “Sites”：保存版本、部署、需要时回滚，全部跑在你自己拥有的基础设施上。它是一套纪律严明的流水线：本地预览确认、先打版本再部署、供应商阶梯、上线前强制 HTTP-200 验证，回滚一条命令搞定。

这个技能做什么

流水线永远是同样的五步，技能的 SKILL.md 把每一步的准确命令都写清楚了：

1. 构建 — 跑你的构建命令（npm run build 等），确定输出目录（dist/、build/）。
2. 预览确认 — 本地起服务，或开一个可分享的隧道，让别的人在公开前先确认。
3. 提交 + 打 tag — 每次部署都用 git tag 记录版本（先版本化、再部署）。
4. 沿供应商阶梯部署 — 默认 GitHub Pages；需要更多时用 Cloudflare Pages 或 Netlify。
5. 验证线上 URL — 真实 HTTP 检查，期望返回 200，然后才算成功。

安装：

hermes skills install official/web-development/publish-site

一步步来

1. 本地预览，需要时分享

需要就构建，然后伺服输出目录：

python3 -m http.server 8080 --directory dist

想要可分享的预览链接——用户在其他机器上，或你想先拿到确认再上线——在后台终端会话里开一条快速隧道：

cloudflared tunnel --url http://localhost:8080

你会拿到一个 https://*.trycloudflare.com 链接交给对方。确认后关掉隧道。

2. 先打版本再部署

每次部署都打一个 git tag——这是之后回滚只需一条命令的原因：

git add -A && git commit -m "deploy: <what>" && git tag deploy-YYYYMMDD-HHMM

3. 沿供应商阶梯部署

技能按顺序检查已认证的供应商 CLI：

供应商	命令	前置条件
GitHub Pages（默认）	git subtree push --prefix dist origin gh-pages	gh auth status 通过
Cloudflare Pages	npx wrangler@latest pages deploy dist --project-name <name>	wrangler whoami 通过，或设置了 CLOUDFLARE_API_TOKEN
Netlify	netlify deploy --prod --dir dist	netlify status 通过

如果仓库还没开 GitHub Pages：

gh api repos/{owner}/{repo}/pages -X POST -f 'source[branch]=gh-pages' -f 'source[path]=/'

4. 用真实 HTTP 检查验证

报告成功之前，技能要求对线上 URL 做真实的 HTTP 检查：

curl -sS -o /dev/null -w '%{http_code}' <url>    # 期望 200

5. 需要时回滚

糟糕的部署离“消失”只有一条命令：切回上一个 tag 重新部署。

git checkout <previous-tag> -- . && redeploy

什么时候用（和什么时候不用）

当你想把网站放到网上——“发布这个”、“帮我托管”、“给我一个能分享的链接”——部署刚做好的仪表盘/报告/作品集/文档站、更新已上线的网站（重新部署 = 新版本）、回滚一次失败的部署，或者单纯不想挑主机时，加载这个技能。它覆盖静态网站和 SPA 构建产物：纯 HTML/CSS/JS，或 Vite、Next export、Astro 等生成的 dist//build/ 目录。

它不覆盖服务端运行时。要零账号配置的一次性 serverless 部署，请用同类的 cloudflare-temporary-deploy 可选技能。技能还假设至少有一个已认证的供应商 CLI——先检查 gh auth status、wrangler whoami 或 netlify status。

为什么这套模式值得学

即使你不安装它，技能里烙着的三个习惯也值得偷走：

• 公开前先预览。 可分享隧道把“发了再祈祷”变成“先确认”——两分钟的一步，能赶在全世界看到之前抓住坏资源、错 base path、丢字体。
• 每次部署都打版本。 每个部署一个 git tag，意味着任何版本都可复现、任何回滚都是一次 checkout。“线上是哪个版本？“有了精确答案。
• 宣布完成前先验证。 HTTP-200 检查干掉那句经典的谎言：“我部署好了”——而网站其实在 404。对线上 URL 跑一次 curl 是成功唯一诚实的定义。

融入你的 Hermes 工作流

技能设计成请求匹配时由 agent 自动加载（“发布这个”、“部署这个”、“给我个链接”）——与 Hermes 其他技能相同的触发模型。如果你是技能系统新手，看我们的项目级技能指南了解 .hermes/skills/ 的运作与信任门禁，顶级技能概览了解更大的生态。想了解可选技能如何在不动核心的情况下扩展 Hermes，publish-site PR 本身是个干净的样本——476 行新增，主要是 SKILL.md 加测试套件，零核心改动。

安装和使用这个技能都只要一条命令，而它编码的纪律——预览、打 tag、部署、验证、回滚——正是专业团队花大价钱买工具才能拿到的工作流。现在它是一个按需加载、跑在你自有基础设施上的技能。下次晚上 11 点做完网站，“部署它”就是一条以 200 结尾的五步流水线——而不是一句祈祷。