企业官网建设流程全解析

• AI 应用
• 提示工程
• 人工智能
• 前端

本文围绕 ChatGPT-Shortcut（AI Short）的“开启同步更新”文档展开：解释为什么 Vercel 一键部署的实例会一直提示“存在更新”，给出“删除原仓库 → Fork 项目 → 在 Vercel 导入 Fork 重新部署”的标准解法，并逐行剖析仓库内 Upstream Sync 工作流的触发时机、权限配置与失败兜底逻辑。读完后你可以让自部署的实例每天自动跟随上游代码更新，并知道同步失败时如何手动补救。

问题背景：为什么一键部署后一直提示“有更新”

ChatGPT-Shortcut 的 部署文档 支持标准部署、离线部署等形态，最常见的路径是通过 Vercel 一键部署按钮拉起自己的实例。但 README 中明确提示了一个坑：

Vercel's one-click deploy creates a new project (not a fork), so the upstream-update check won't work.（Vercel 的一键部署会新建一个项目而非 fork，所以上游更新检查不会生效。）

原因很直接：Vercel 的一键部署本质上是通过“克隆”方式在你账号下新建了一个独立的仓库项目，它与上游仓库（rockbenben/ChatGPT-Shortcut）之间不存在 Git fork 关系。没有 fork 关系，就没有“上游/下游”这条链路，站点自然检测不到上游是否有新提交，于是页面上的“存在更新”提示会一直挂着。

解决思路是把部署源从“新建项目”换成“真正的 fork”，再让 fork 自动跟随上游。

标准解法：Fork 后在 Vercel 重新导入

按 开启同步更新（对应中文原文 docs/deploy/sync-updates.md）给出的三步操作：

1. 删除原仓库：把 Vercel 一键部署生成的那个“非 fork”仓库删掉；
2. Fork 本项目：使用项目页面右上角的Fork按钮 fork ChatGPT-Shortcut，这样新仓库才带有所需的.github/workflows/同步配置，并与上游建立 fork 关系；
3. 在 Vercel 重新导入并部署：进入 Vercel 的新项目页面，在 Import Git Repository 处选择刚 fork 的仓库（而不是原项目）完成部署。

完成这三步后，你的部署源就是一个标准 fork，后面的自动同步才有生效的前提。

仓库源码剖析：Upstream Sync 工作流

fork 关系建立后，自动同步由仓库内的工作流.github/workflows/rsync.yml实现。这个文件就是文档中“在 Actions 页面启用 Workflows”所指的目标工作流，完整内容如下：

name: Upstream Sync permissions: contents: write on: schedule: - cron: "0 0 * * *" # every day workflow_dispatch: jobs: sync_latest_from_upstream: name: Sync latest commits from upstream repo runs-on: ubuntu-latest if: ${{ github.event.repository.fork }} steps: - name: Checkout target repo uses: actions/checkout@v6 - name: Sync upstream changes id: sync uses: aormsby/Fork-Sync-With-Upstream-action@v3.4 with: upstream_sync_repo: rockbenben/ChatGPT-Shortcut upstream_sync_branch: main target_sync_branch: main target_repo_token: ${{ secrets.GITHUB_TOKEN }} # automatically generated, no need to set test_mode: false - name: Sync check if: failure() run: | echo "::error::由于权限不足，导致同步失败（这是预期的行为），请前往仓库首页手动执行[Sync fork]。" echo "::error::Due to insufficient permissions, synchronization failed (as expected). Please go to the repository homepage and manually perform [Sync fork]." exit 1

从源码结构看，这个工作流的设计要点有四处，正好对应文档中的操作说明：

1. 每天一次的定时触发 + 手动触发

schedule.cron: "0 0 * * *"表示每天（UTC 0 点）自动执行一次——这就是文档所说“启用后项目每天自动同步”的实现；workflow_dispatch则允许你在 Actions 页面手动点击运行，对应文档中“手动跑一次 Upstream Sync Action”的要求。

2. 只写内容，且仅在 fork 仓库中生效

• permissions: contents: write授予工作流写内容的最小权限，这是把上游提交合并进你分支所必需的；
• 任务的if: ${{ github.event.repository.fork }}条件保证该工作流只在你 fork 出来的仓库里执行。这一点印证了前文“必须先 fork 再部署”的必要性——如果部署源不是 fork，这个条件为假，同步任务根本不会运行。

3. 上游来源硬编码为main分支

upstream_sync_repo: rockbenben/ChatGPT-Shortcut、upstream_sync_branch: main、target_sync_branch: main三个参数表明：同步方向固定为“上游main→ 你的 fork 的main”，使用的是社区通用的 Fork-Sync Action（aormsby/Fork-Sync-With-Upstream-action@v3.4），令牌直接取 GitHub 自动生成的secrets.GITHUB_TOKEN，无需自行配置任何 Secret。

4. 权限失败时的双语错误兜底

最后一个Sync check步骤带if: failure()，只在同步失败时输出：

由于权限不足，导致同步失败（这是预期的行为），请前往仓库首页手动执行[Sync fork]。

这解释了文档中那句醒目提示——“如果遇到 Upstream Sync 执行错误，请手动执行一次 Sync Fork”。fork 刚建立时，GitHub 出于安全考虑会默认禁用fork 仓库里的工作流（Workflow dispatch 被置灰），此时定时任务拿不到足够权限而失败，工作流便输出上述提示，指引你到仓库首页手动执行一次Sync fork。执行一次后权限链路打通，后续每日自动同步即可正常进行。

启用步骤：Fork 后开启自动同步

结合上面的工作流实现，完整启用流程是：

1. Fork 项目，并在 Vercel 导入该 fork 完成部署；
2. 进入 fork 仓库的Actions页面，启用 Workflows（fork 默认处于禁用状态）；
3. 手动运行一次Upstream Sync工作流；
4. 若该次运行失败并出现“权限不足，请手动执行 Sync fork”的红字提示，前往仓库首页点击Sync fork按钮执行一次手动同步，之后每日定时同步即可生效。

手动更新：立即拿到上游最新代码

如果不愿意等当天的定时任务，也可以随时手动同步。GitHub 官方对同步 fork 的说明见其文档（Syncing a fork），核心思路都是先把上游main拉进来再合并到你自己的main，例如：

git remote add upstream https://github.com/rockbenben/ChatGPT-Shortcut.git git fetch upstream git checkout main git merge upstream/main git push origin main

对于 fork 仓库，直接点仓库首页的Sync fork → Update branch是最省事的方式，效果与上面等价。

同步后的部署链路：为什么推送到 main 就自动上线

自动同步把上游main合并进你的 forkmain后，部署如何跟进？这由另一份工作流.github/workflows/main.yml保证：它监听push到main分支的事件，执行actions/checkout@v6（fetch-depth: 0以拿到完整历史）、Node 24 +yarn install --frozen-lockfile安装依赖、yarn build构建站点。从源码结构看，每次 Upstream Sync 合并产生新的main提交后，都会触发这条构建/部署链路——“每天同步 + 推送即构建”两段拼起来，才构成文档承诺的“项目每天自动同步”闭环。

构建侧的一个细节值得注意：docusaurus.config.js 中站点通过git log取最后提交时间作为文档“最近更新”时间，Dockerfile 则在 Docker 场景下设置SKIP_GIT_INFO=true跳过 git 依赖。也就是说，文档页面上的时间戳、sitemap 的 lastmod 都来自 git 历史——fork 通过同步持续获得新的上游提交时间，这些信息会随每日同步自然刷新。

小结

• Vercel 一键部署创建的是独立项目而非 fork，导致上游更新检测失效；正确姿势是删除原仓库 → Fork → Vercel 导入 fork 重新部署；
• fork 仓库内的 Upstream Sync 工作流 每天定时把上游main合并到你的main，失败时会明确提示手动执行Sync fork；
• 同步产生的main推送再由 main.yml 的构建流程接管，完成每日自动更新；
• 急用时可用 GitHub 的 Sync fork 能力立即拉取上游代码。

如果你希望第一时间获得功能更新通知，也可以给本项目 star / watch，以便在有新功能时及时收到提醒。

• AI 应用
• 提示工程
• 人工智能
• 前端