$ man context-wiki/deployments-vercel

部署就是把你本地的代码变更发布到互联网上。推送到 GitHub。Vercel 接收。构建站点。部署。完成。我第一次推送到 main 分支，看到 Vercel 在 45 秒内构建好我的站点时，感觉就像直接跳到了最精彩的部分。不用 FTP 上传。不用手动文件传输。只需要推送代码，它就上线了。三个网站（shawnos.ai、thegtmos.ai、thecontentos.ai）全部通过一次推送部署。这不是魔法，这就是现代部署的工作方式。

模式

每个分支都有自己的预览 URL。把功能分支推送到 GitHub，Vercel 会生成一个独特的 URL，你可以在上线前查看变更效果。这对测试来说非常有用。你可以把预览 URL 分享给协作者，在手机上检查，或者只是在合并到 main 之前确认变更看起来没问题。 工作流程：创建分支、做变更、推送分支、检查预览 URL、如有需要修复问题、确认没问题后合并到 main、main 自动部署到生产环境。你永远不会把坏掉的代码部署到生产环境，因为你在预览阶段就发现了问题。

模式

密钥放在 Vercel 上，不在你的代码里。API 密钥、数据库 URL、MCP 令牌。你在 Vercel 仪表板中为每个项目添加它们。你部署的站点通过 process.env 访问它们。它们永远不会出现在你的仓库里，永远不会被提交到 Git，永远不会出现在构建日志中。 在本地，你创建一个 .env 文件放同样的变量。把 .env 加到 .gitignore 中让它永远不被提交。Vercel 有自己的生产环境副本。这种分离意味着你可以在本地开发和生产环境使用不同的值而不产生冲突。

专业技巧

我构建了 /deploy 技能，这样我就不用记住部署步骤了。它暂存所有修改过的文件。从 diff 生成提交消息。提交。推送到 GitHub。等待 Vercel 开始构建。监控构建进度。确认所有三个站点都以 200 状态码上线。报告结果。我输入 /deploy，其他一切自动发生。三个网站，一次推送，不到一分钟。 这就是技能模式应用于基础设施。我可以手动运行这些命令。但为什么要这样做？技能更快、更一致，还能捕获我会遗漏的错误。它还会为日报追踪器记录部署信息。

反模式

部署失败通常有三个常见原因。构建错误：TypeScript 报错、缺少导入、依赖损坏。在本地修复错误，再次推送。环境变量问题：某个变量在本地存在但不在 Vercel 上。检查 Vercel 仪表板并添加缺少的变量。依赖冲突：你的锁文件与 package.json 不同步。删除 node_modules，重新安装，推送更新后的锁文件。 /deploy 技能会检查构建状态并报告失败及相关错误。但如果你跳过技能手动推送，就去 Vercel 仪表板查看构建日志。错误总在日志里。先看日志再猜原因。