# 部署三件套：一句话认出亲兄弟 ## 概述 本期是工作流自动化线的横评，拆五件已在国内主流 Claude Code 环境上架的 Skills：cloudflare-deploy、netlify-deploy、render-deploy 三件部署件，加上 CI 向导 github-actions-skill 和跨会话框架 long-running-agent。核心发现有三条：其一，三件部署件共享一字不差的沙箱提权话术，是同一批模板的产出，但各自的「脑子」完全不同——一个做地图、一个做流水线、一个做决策引擎；其二，工作流类 Skills 已分化出五种可命名的设计范式，从「问路地图」到「外置状态机」，复杂度跨度极大；其三，render-deploy 把 MCP 工具放在 CLI 之前，这是部署类 Skill 的一个新信号：命令行正在给函数调用让位。以下评分基于逐段精读 SKILL.md 原文与可见的设计信号，未含实时 Star 数据。 ## 评测对比表 | Skill | 功能完整度 (25%) | 设计质量 (25%) | 实战效果 (20%) | 上手难度 (15%) | 生态信号 (15%) | 加权总分 | |-------|------|------|------|------|------|------| | render-deploy | ★★★★★ | ★★★★★ | ★★★★ | ★★★ | ★★★★★ | **4.5** | | long-running-agent | ★★★★ | ★★★★★ | ★★★★ | ★★★ | ★★★★ | **4.1** | | cloudflare-deploy | ★★★★★ | ★★★★ | ★★★ | ★★★★ | ★★★★ | **4.05** | | netlify-deploy | ★★★★ | ★★★ | ★★★★ | ★★★★★ | ★★★★ | **3.9** | | github-actions-skill | ★★★ | ★★★★ | ★★★★ | ★★★★★ | ★★★ | **3.75** | > 说明：「上手难度」分数越高代表越容易上手；「生态信号」依据官方出品迹象、姊妹件互引、被文档引用情况等可见信号评定。 ## 三件部署件：一张母版，三种脑子 先把「亲兄弟」的证据摆出来。三件部署件的 SKILL.md 里都写着同一段话，一字不差： ``` - When sandboxing blocks the deployment network calls, rerun with `sandbox_permissions=require_escalated`. - The deployment might take a few minutes. Use appropriate timeout values. ``` 结尾的 Troubleshooting 段也是同一段「Escalated Network Access」模板，连给用户的示例话术都相同：「The deploy needs escalated network access to deploy to X. I can rerun the command with escalated permissions—want me to proceed?」，只差一个平台名。这是典型的同一批模板批量产出的文字指纹。三家平台官方各自维护的文档不会巧合到这个程度——至于是平台官方出品、聚合方统一包装，还是某个上游模板库的分发，未经官方证实，但从文字看同源无疑。 有意思的是：母版相同，脑子却完全不同。 ### cloudflare-deploy：一张问路地图 **定位**：Cloudflare 全产品线的路由器。主文件里没有一个具体的部署命令，只有六棵决策树——「我要跑代码」「我要存数据」「我要 AI/ML」「我要联网」「我要安全」「我要媒体」——每棵树把你导向 `references/` 下的对应目录。 **亮点**：这是渐进式披露（progressive disclosure）的教科书做法。Cloudflare 有四五十个产品，Workers、D1、R2、Queues、Vectorize、Tunnel……全塞进一个 SKILL.md 会把上下文撑爆。它的解法是主文件只留「问路」，真正的文档按需加载：你说「我要跑定时任务」，它才去读 `references/cron-triggers/`。产品索引用表格列全了从 Compute 到 IaC 的每一项，查全率几乎无死角。 **短板**：地图不管走路的后果。它验证认证用 `npx wrangler whoami`，之后就把你交给各产品的子文档，没有 netlify-deploy 那种「部署完汇报 URL」的闭环。对于「把这个目录发上线」这种最常见的小需求，你要先被路由、再加载、再执行，路径偏长。它的适用场景是「我要在 Cloudflare 上做点事，但不知道用哪个产品」；如果你的需求就是部署一个静态站，它大材小用了。 ### netlify-deploy：一条六步流水线 **定位**：三件里最「朴素」的一件，单文件线性工作流，六步走完：验认证 → 探测站点链接状态 → link 或 init → 装依赖 → 部署 → 汇报。 **亮点**：它把部署中最容易翻车的「已链接 / 未链接」分支写得很细：先用 `npx netlify status` 判断，未链接则尝试用 Git remote 地址 `npx netlify link --git-remote-url` 自动认亲，认亲失败再退到 `npx netlify init` 交互式建站。这个「先自动认亲、失败再问人」的降级链条，正是 Agent 部署最需要的行为规范。另外它默认先发 preview、确认后再 `--prod` 上生产，把「先测试再上线」写成了默认行为，这是对生产环境的敬畏。 **短板**：设计上最浅。没有 IaC（不生成 netlify.toml 的内容，只说 CLI 会自动用），错误处理是「报错对照表」式的枚举，没有诊断逻辑。对单页静态站和常规前端项目够用，一旦涉及 Functions、环境变量组、多环境，就要靠结尾挂载的三个 references（CLI 命令、部署模式、netlify.toml 指南）补课。 ### render-deploy：一台决策引擎（本期深度拆解对象） **定位**：三件里唯一把「选择」本身做成核心逻辑的。它开头就亮明两条路：Git 仓库走 Blueprint（IaC）或 Direct Creation（MCP 直建），预构建 Docker 镜像则明确告知 MCP 不支持、请走 Dashboard。 **亮点一：方法选择启发式。** 它不问你「想用哪种方式」，而是先分析代码库，然后用两条互补规则裁决—— > **全部满足**以下条件 → Direct Creation：单服务、无独立 worker/cron、无附加数据库、仅简单环境变量。 > **任一满足** → Blueprint：多服务、需要数据库或 Redis、有定时任务、要可复现的 IaC、monorepo。 「ALL true 走快路，ANY true 走稳路」，拿不准时默认 Blueprint 保安全。这是把工程师的部署决策经验编译成了布尔逻辑，五件里只此一份。 **亮点二：MCP 一等公民。** 它的部署主力不是 shell 命令而是 MCP 函数调用：`list_services()`、`list_deploys(serviceId, limit: 1)`、`list_logs(resource, level: ["error"])`、`get_metrics(...)`。CLI 只是 fallback。它甚至内置了给 Cursor、Claude Code、Codex 三个客户端的 MCP 接入指引，连 `claude mcp add --transport http render https://mcp.render.com/mcp` 这条命令都直接给出。 **亮点三：闭环。** 部署不是终点——第 7 步强制验证：查部署状态是否 `live`、等 2-3 分钟扫错误日志、拉 CPU/内存指标，配一套四步 post-deploy 检查清单（live 状态 → 健康端点 200 → 错误日志签名 → 环境变量与 `0.0.0.0:$PORT` 端口绑定），再挂一份 triage 指南。安全上，密钥环境变量统一标 `sync: false`，强制用户去 Dashboard 手填，Agent 全程不碰明文密钥。 **短板**：概念密度三件里最高——Blueprint、MCP、deeplink、workspace、`sync: false`，新手第一遍读会很吃力；且深度依赖 Render MCP 服务已接入，没配 MCP 时体验折半。文中提到的安装脚本托管在 `raw.githubusercontent.com/render-oss/cli` 下，加上它还推荐了姊妹件 `render-debug`，官方出品的迹象在三件里最明显。 ### github-actions-skill：只会一招的问询台 **定位**：注意，它不叫「CI skill」——它只做一件事：帮你把 GitHub Actions 通过 SSH 连到自己的 VPS，生成 deploy.yml。部署方式三选一：执行命令、rsync 同步、两者都要。 **亮点**：交互设计是五件里最规矩的。阶段一「每次只问一个问题」，必填四项、可选项给默认值（端口默认 22、分支默认 main，回车即过）；阶段二用 ASCII 表格把配置全部摊开让你确认；阶段三按序产出密钥生成命令、`ssh-copy-id` 配置、Secrets 清单表、两套 workflow 模板（命令执行走 `appleboy/ssh-action@v1.0.3`，rsync 走原生 `ssh-keyscan` + `rsync -avz --delete`）；阶段四给分步操作指引。这是把「配置生成器」做成了「业务受理窗口」。 **短板**：覆盖面窄，只管「GitHub Actions → SSH → VPS」这一条巷子，没有构建测试、没有多环境、没有回滚；依赖第三方 action（appleboy/ssh-action）锁定在 v1.0.3，时效性存疑；Secrets 清单里 `SSH_PORT` 仅在非默认时需要，但模板里 port 一栏无条件引用了该 Secret，细看有小的自洽瑕疵。它全文用中文写成——这在 Skill 生态里本身就是个样本：非英文世界的作者正在按同一套 SKILL.md 规范写自己的件。 ### long-running-agent：给 Agent 立交规 **定位**：严格说它不是「自动化某个流程」，而是「让 Agent 能干长活」。核心命题：Agent 每个新会话都是失忆的，于是必然犯三种错——一口气梭哈到上下文爆掉、看到半成品就宣布完工、留下烂摊子不记录。 **亮点**：解法是「两 Agent + 三文件」。Initializer Agent（仅首会话）搭好 init.sh、feature_list.json、claude-progress.txt 并完成首次提交；Coding Agent（后续每个会话）按固定的七步启动序列找回状态：`pwd` → 读进度文件 → 读功能清单 → 看 git log → 跑 init.sh → 跑基础测试 → 挑一个失败的功能开工。 最值钱的是状态机设计：feature_list.json 用 JSON 而非 Markdown——文中明说是「防止不当编辑」，Agent 只允许改 `passes` 字段，不许动测试描述，且「只有端到端验证通过才能标 true」。进度日志强制「离开前必 commit + 更新进度文件」。结尾还有一张失败模式对照表（一口气梭哈 → 拆功能清单；提前宣布胜利 → 查清单里的失败项……），把已知的坑写成了交规。 **短板**：它改变的是你的使用习惯而非替你干活，需要你接受「每个会话都从读文件开始」这套仪式，上手成本不低；要求跨会话项目才见效，小任务用它纯属仪式感。这套 init.sh / feature_list.json / progress 文件的三件套结构在社区流传较广，本地这版是它的框架化封装。 ## 五种范式：工作流件的设计光谱 五件摆在一起，能看到工作流类 Skills 已经分化出五种可复用的设计范式： ```mermaid flowchart TD ROOT["工作流件五种范式"] --> A["地图路由型"] ROOT --> B["线性流水线型"] ROOT --> C["决策引擎型"] ROOT --> D["向导问答型"] ROOT --> E["外置状态机型"] A --> A1["主文件只放决策树
细节按需加载"] B --> B1["固定步骤顺序执行
失败即停"] C --> E1["先分析再选路
执行后强制验证"] D --> D1["一次一问
表格确认后生成"] E --> E1["状态写进JSON和日志
跨会话恢复"] A1 --> AF["cloudflare-deploy"] B1 --> BF["netlify-deploy"] E1 --> CF["render-deploy"] D1 --> DF["github-actions-skill"] AF2["long-running-agent"] --> EF ``` 选型建议很简单：需求越模糊，越要地图型；需求越标准，越要流水线型；环境越复杂，越要决策引擎型；用户越不熟，越要向导型；任务越长，越要状态机型。 render-deploy 的完整闭环值得单独一张图——它是五件里唯一「执行后强制验证」的： ```mermaid flowchart TD S["分析代码库"] --> Q{"多服务或带数据库?"} Q -->|是| BP["生成render.yaml"] Q -->|否| MC["MCP直建服务"] BP --> V["render blueprints validate"] V --> P["提交并推送仓库"] P --> L["生成Dashboard深层链接"] L --> U["用户在网页端点Apply"] U --> CH["MCP查部署状态"] CH --> LOG["扫错误日志"] LOG --> MET["拉健康指标"] MC --> CH ``` ## 安装与使用 这五件均可按 Claude Code 的通用机制安装——把包含 SKILL.md 的文件夹放进 `~/.claude/skills/` 即可，Claude Code 会按各件 frontmatter 的描述自动触发。用社区安装器时，来源仓库请以各平台官方文档为准： ```bash # 通用手动安装（以 render-deploy 为例） git clone <该skill的仓库地址> ~/.claude/skills/render-deploy # 触发方式：对话中直接说出意图 # "把这个项目部署到 Render" → render-deploy # "我要用 Cloudflare Workers" → cloudflare-deploy # "发到 Netlify" → netlify-deploy # "帮我配 GitHub Actions 自动部署到我的 VPS" → github-actions-skill # "这个项目要跨好几天做，帮我建跨会话框架" → long-running-agent # 三件部署件共同的沙箱前提：部署需出网 # 若沙箱拦截网络，需按 SKILL.md 指引以提权网络权限重跑部署命令 ``` ## 推荐排行榜 - **设计最值得抄**：render-deploy —— 方法选择启发式（ALL/ANY 双规则）、`sync: false` 密钥隔离、部署后强制验证，三招都是可以直接搬进你自己 Skill 的模式。 - **最适合新手**：github-actions-skill —— 一次一问、回车过默认、表格确认，全程不需要你懂 Actions。 - **最适合当日常工具**：netlify-deploy —— 六步流水线覆盖 90% 的常规部署，先 preview 后生产的默认顺序很稳。 - **最耐拆**：cloudflare-deploy —— 决策树 + references 索引的结构，是「大平台全家桶」类 Skill 的标准答案。 - **最改变工作方式**：long-running-agent —— 五件里唯一不替你干活、却让其他一切的活变得可持续的件。 按综合分排序：render-deploy（4.5）> long-running-agent（4.1）> cloudflare-deploy（4.05）> netlify-deploy（3.9）> github-actions-skill（3.75）。如果你只装一件，装 render-deploy；如果你常年跟 VPS 打交道，加装 github-actions-skill；如果你的项目一做就是几周，long-running-agent 优先级提到最高。 最后说回那个文字指纹。三件部署件连「如何向用户请求提权」的话术都完全一致——这意味着 Skill 生态正在出现「模板化生产」：同一套骨架，填入不同平台的行为逻辑。对使用者的启示很直接：看到这类件，别急着评价单件好坏，先找它的母版——母版的质量，决定了这一批件的下限。 ## 参考来源 1. [Netlify CLI 官方文档](https://docs.netlify.com/cli/get-started/) — netlify-deploy SKILL.md 引用的部署命令与工作流依据 2. [Netlify 文件式配置参考](https://docs.netlify.com/configure-builds/file-based-configuration/) — netlify.toml 配置项的官方参考 3. [Render MCP 服务端点](https://mcp.render.com/mcp) — render-deploy 中 MCP 直建方式所依赖的官方 MCP 服务 4. [Render CLI 安装脚本](https://raw.githubusercontent.com/render-oss/cli/main/bin/install.sh) — render-deploy 内引用的官方 CLI 安装源（render-oss 组织） 5. [Render API Keys 设置页](https://dashboard.render.com/u/*/settings#api-keys) — render-deploy 中密钥获取入口 6. 本地一手材料：`~/.claude/skills/` 下 cloudflare-deploy、netlify-deploy、render-deploy、github-actions-skill、long-running-agent 五件的 SKILL.md 原文，本文所有原文引用均出自此处 > [!tip] 51学通信知识星球 > **星主：爱卫生**（微信：gprshome201101）——公众号「51学通信」创办者，19 年通信行业运维与讲师经验，著有《GPRS网络信令实例详解》《EPC原理与实践》《5G核心网原理与实践》三本纸质书（各大电商平台有售）。 > **星球定位**：深耕 5G 核心网、IMS、NFV/AI、云原生等 ICT 领域，主打运维岗位与信令分析。 > **当前规模**：5200 篇主题 / 990 个回答，198 元/年。 > **加入福利**：加入星球后请加爱卫生微信，拉您进知识星球年度陪伴与答疑群——不限量回复您的各种问题，另有群内分享。 > **AI 加持**：51学通信知识星球已作为 skill 接入 WorkBuddy，使用 deepseek-4-flash 在海量星球帖子中精准找贴、找视频、找 FAQ 和案例，做总结、找文档和 PPT 等场景全覆盖。