用 AI 辅助二次开发，如何持续同步开源项目更新？

假设要做一个工单系统，前端基于开源管理后台，后端基于另一个开源 API 项目。开发一段时间后，自己的业务代码越来越多，上游也有了新版本。

这时需要处理的问题是：怎样吸收上游的修复，又不覆盖自己的业务修改？

以前可以把前后端各自放在二次开发仓库里，分别合并上游，再通过集成仓库固定版本组合。现在有了 AI 编程工具，对于个人项目或小团队，我会优先考虑把前后端放在同一个仓库，让 AI 协助检查和移植上游更新。

以前用仓库关系管理更新

一种常见做法是维护三个仓库：前端、后端和集成仓库。前后端保留各自的上游历史，集成仓库通过 Git submodule 记录采用的提交。

这样可以分别升级前后端，也能固定经过验证的版本组合。不过，一次业务修改可能涉及多个 PR，还需要更新子模块引用。对于主要由自己维护的项目，这些操作未必划算。

单仓库以前也能用，只是两个上游的差异需要自己跟踪和适配。AI 让这部分工作多了一种处理方式。

现在可以把源码放在一起，让 AI 协助同步

工单系统可以直接组织成一个普通仓库：

helpdesk/
├── web/                       # 基于开源项目的前端代码
├── api/                       # 基于开源项目的后端代码
├── deploy/
└── docs/
    ├── upstream-sources.md    # 上游来源和已同步版本
    └── local-customizations.md # 业务定制与适配原因

web/ 和 api/ 都由当前仓库直接跟踪。修改一个需要前后端配合的功能时，可以在同一个分支里开发、联调和提交。

需要更新时，让能够读取代码、获取上游源码并执行命令的 AI 编程工具，对照当前项目分析差异，协助移植修复、调整调用和补充验证。涉及接口变化时，它也可以同时查看前后端的实现。

这里采用的是按差异移植更新的方式。把两个独立项目的源码放进不同目录后，不能假设一次普通的 git merge 就能自动完成目录映射和双上游同步。

仍然要告诉 AI，上次同步到了哪里

只说“检查一下上游更新”，信息还不够。

AI 至少需要看到三份内容：上次采用的上游版本、这次准备采用的上游版本，以及当前包含业务修改的代码。这样才能区分上游改动和本地定制。

可以在 docs/upstream-sources.md 中记录：

# 所有地址均为占位示例；提交 ID 需填写真实的完整值。
web:
  repository: https://example.com/open-source/admin-starter.git
  branch: main
  baseline_commit: <上次完成同步的完整提交 ID>
  local_path: web/

api:
  repository: https://example.com/open-source/api-starter.git
  branch: main
  baseline_commit: <上次完成同步的完整提交 ID>
  local_path: api/

有了准确的提交 ID，还要能取得对应的源码。可以在单独的参考目录保留上游克隆，或从远端获取这些提交，再用 git diff 比较旧基线和目标提交之间的变化。参考克隆只用于读取，不是额外维护的业务仓库。

本地改过的登录逻辑、权限模型和响应格式，也应简要记录原因。比如“工单列表使用服务端分页”，比一句“这里做过定制”更能帮助 AI 判断哪些行为需要保留。

一次更新，可以怎样交给 AI

我会先让 AI 检查变化，确认范围后再修改。下面这段指令可以作为起点：

阅读 docs/upstream-sources.md 和 docs/local-customizations.md，
检查前端上游从已记录基线到本次选定目标提交的变化。

先固定目标提交，列出修复、功能变化和兼容性调整，
说明哪些影响当前项目，以及需要修改的文件，暂不修改代码。

确认范围后，在独立分支中移植相关更新，保留现有业务行为。
执行项目已有的检查、测试和构建，并验证登录、创建工单和指派流程。

完成后说明采用和跳过的变更、验证结果，以及尚未确定的问题。

例如，上游修改了请求拦截器，而本地接入了自己的令牌刷新机制。这时需要对照旧实现、新实现和本地适配，判断修复应落在哪里。直接用上游文件覆盖，可能把业务逻辑一起替换掉。

同样，上游新增的演示页面未必需要引入，但它依赖的公共组件或配置变化可能影响已有页面。让 AI 解释依赖关系，再决定移植范围，比只根据提交标题挑选更可靠。

同步记录也要与实际结果一致。如果目标提交包含十项变化，只移植了其中两项，就记录已移植的提交和暂缓项，保留完整同步基线。只有目标范围已经逐项核对、该适配的内容都处理完，才推进基线，避免下次检查跳过遗漏内容。

AI 减少检查成本，验证仍然要落到业务上

AI 可以协助阅读大量差异，但生成的修改仍然可能有遗漏。构建成功，只能说明一部分问题没有出现。

对工单系统，至少要实际验证登录、创建工单、指派和查询结果。涉及权限、认证或数据库迁移时，还要检查旧数据和原有业务行为是否兼容。没有运行条件的验证，应明确记为未完成。

更新检查可以手动触发。需要定期执行时，再配置定时任务或 CI，让 AI 生成差异报告或更新 PR；把检查规则写进文档，并不会自动开始持续监控。

如果前后端本来就由不同团队维护、需要独立发布，分仓仍然合理。对于自己维护、经常同时修改前后端的项目，我会先用单仓库，保留准确的上游基线和定制说明，再把差异分析与适配工作交给 AI 协助完成。