发布前先看清风险：Shipback 如何让 SFTP 部署可撤回
共享主机和普通 VPS 上，网站更新常常就是把本地目录通过 SFTP 上传到服务器。这个流程简单，却有个容易被忽略的问题：上传覆盖了线上文件之后，出错时未必有 Git 可以回滚。更棘手的是，服务器上可能有人直接修过文件；盲目恢复旧备份，又会覆盖这份线上修改。
Shipback SFTP 是一个面向 SFTP 主机的 Node.js 部署工具，提供命令行和 MCP 服务。它的设计重点不是替代版本控制，而是为文件上传增加备份、变更检查和撤回路径。适合维护 cPanel、Plesk 或普通 VPS 网站的开发者，也适合希望给编码 Agent 增加受控部署入口的团队。项目仓库标注 MIT 许可证，要求 Node.js 18 或更新版本。
部署前先预览，覆盖时保留服务器副本
最小工作流从 sites.json 开始，为站点配置主机、SFTP 端口、用户名、远端根目录和本地目录。README 示例使用 22 端口，但也提醒共享主机可能使用其他端口，须以主机商控制面板的 SSH 配置为准。密码可先运行命令交互保存到系统密钥环；项目说明密码不会传给模型。CI 场景也可通过环境变量 SFTP_PASSWORD 提供凭证。
先预演，不要上来就覆盖线上目录：
npm install -g shipback-sftp cd ~/sites shipback mysite --dry-run
检查计划确认目标文件无误后，再执行 shipback mysite。项目说明每次覆盖前，会把服务器上的原文件存进远端 _backup-，并逐个上传临时文件，再以重命名替换目标文件，避免连接中断时留下半截文件。部署记录还会记下新增文件和文件内容摘要，供后续恢复时判断当前状态。
这不是“上传失败就一定自动回滚”的承诺。它的价值在于保留恢复所需的信息，并提供明确的撤回命令；部署仍需由操作者检查目标目录和计划。
一条命令撤回，但不覆盖他人后续修改
如果刚才的发布需要撤销，可先预演恢复：
shipback mysite --restore --dry-run shipback mysite --restore
恢复操作会检查线上文件。如果文件仍是本次部署写入的版本，就恢复备份；若文件已被他人改动且与部署前后版本都不同，默认会停止并报告冲突，而不是直接覆盖。恢复本身也会留下备份，因此还可以撤回恢复操作。
这类保护对共享主机尤其有用：线上目录可能同时承载上传内容、表单数据或人工修正。项目的 UNDO-PROMISE.md 明确列出恢复边界，包括不触碰无关文件、处理中断恢复、避免写出站点目录，以及对冲突采取停止策略。开发者仍应先读这份说明，理解它覆盖与不覆盖的情形；不要把“可撤回”误解成完整的灾备方案，数据库、用户上传数据和站点配置仍需独立备份。
接入 Agent：预览和执行分开
Shipback 还提供 shipback-mcp，通过标准输入输出运行 MCP 服务。README 列出的工具包括 preview_deploy 和 deploy：前者生成计划，后者执行该计划；若预览后文件发生变化，执行会拒绝过期计划。还提供检查线上变化、拉取变更和预览/执行恢复等能力。Agent 工具不提供 --mirror 删除远端额外文件或 --no-backup 跳过备份的开关，降低了误操作面。
Claude Code 的配置示例如下：
claude mcp add shipback-sftp -- npx -y -p shipback-sftp shipback-mcp --sites /path/to/sites.json
上手时建议先对测试站点验证凭证、远端路径与权限，再给 Agent 仅开放必要站点。生产环境保留人工确认，尤其要谨慎处理目录镜像、清理旧备份等高影响操作。MCP 接入只是工具调用接口，不等于自动获得安全保障；主机账户权限、密钥保管和审阅部署计划仍然重要。
适用边界
Shipback 面向通过 SFTP 发布文件的站点，不是 Git 分支管理器，也不能代替数据库备份、异地备份或灾难恢复演练。它更适合“文件型站点、没有完整 Git 回滚链路、又担心线上手工改动被覆盖”的场景。若团队已经有可靠的 CI/CD、制品版本和回滚机制，应比较现有流程是否已覆盖同样问题，而不是只因新工具提供了 Agent 接口就增加一个生产写入通道。
选用此类部署工具时，可以先在临时目录做三个演练：正常部署后恢复；部署中断后恢复；线上文件被手工修改后尝试恢复。观察它是否明确报告冲突、备份是否可用，以及恢复是否只影响本次部署涉及的文件。把这些检查纳入上线清单，比单纯相信“undo”口号更可靠。
相关链接