我们用[插件目录]把 Git 合并地狱熄火了:AI 并行写功能也不怕

起因 😵‍💫

事情是这样的：AI 写代码真的太快了，快到你会觉得“哇我今天能做 5 个新功能”。

然后现实给你一巴掌：合并冲突 50 个，而且冲突不是那种“点两下就好”的，是那种“你修完了能跑，但你也不知道你修对没”的。

更要命的是——大家并行探索的时候，最容易一起碰到同一批核心文件（入口、公共逻辑、数据处理那几个），AI 还爱顺手重构：改函数名、挪文件、合并起来直接开盲盒🎁

我们不缺开发速度，缺的是：怎么让多人 + 多 AI 并行探索，不把仓库炸掉。

—

方案 🧩（一句话版）

把项目拆成两块：

Core（核心）：尽量稳定、尽量少改

Plugins（插件）：所有新功能都在自己小文件夹里写，互不打扰

最关键的规则也只有一条：

> 新功能只允许写在 plugins/xxx/ 里（新增文件为主），不要去碰核心文件。

我们用的“最规范但不复杂”的目录长这样👇

core/                 # 核心区：稳定、少动

  app.py              # 主入口：只负责“加载/挂载插件”

  logic.py            # 公共规则/算法（尽量当成稳定 API）

  database.py         # 公共数据接口

plugins/              # 插件区：所有新功能都在这里

  my_feature/

    manifest.json     # 插件登记表：名字、入口在哪、开关等

    ui.py             # 页面/交互（或命令入口）

    service.py        # 业务实现（可选）

    README.md         # 怎么跑、截图、说明

    data/             # 插件自己的测试数据（可选）

然后“入口文件”只干一件事：扫描 plugins/*/manifest.json，把插件挂出来。

（重点：自动扫描，别手写插件列表，不然入口还是会冲突。）

—

解释 🤝（为啥这招能救命）

Git 冲突的底层逻辑很朴素：两个人改了同一个文件的同一段内容，就冲突。

以前冲突多，因为大家都在改“大家都要用的地方”：

入口文件、公共逻辑、数据文件 —— 这些就是天然的“冲突热点”。

插件目录之后，开发变成这样：

A 同学：只动 plugins/a_feature/**

B 同学：只动 plugins/b_feature/**

大家改的是不同文件夹，Git 基本没理由冲突。

就算 AI 写炸了，也只炸自己的插件，不会把整个项目拖下水✅

给 AI 的“边界感”规则（超重要⚠️）

你们可以每次都把这段贴给 AI（真的能减少 80% 乱改）：

> 你现在在一个插件化项目里开发新功能。

✅ 你只能在 plugins/<plugin_name>/ 里新增/修改文件。

❌ 不允许改 core/ 下除“插件加载区”以外的任何代码；不允许重构、移动、重命名、删除现有文件。

✅ 你必须提供：改动文件清单、运行方式、以及确认没有越界修改。

如果你觉得必须改 core，请先写“变更提案”，不要直接改。

（你会发现 AI 一旦被画圈，就突然变乖了🙂）

—

结果 🚀

落地之后最爽的变化是：

并行开发真的变成“并行”了：大家各写各的插件目录，互不干扰

合并从“修冲突半小时”变成“新增文件夹合进来就行”

新功能探索成本变低：AI 可以随便试，试烂了删插件就完事

一句话：我们把冲突从“全项目到处炸”缩小成“几乎不炸”。

—

但它有局限吗？有的 🧱（提前说清）

插件化能解决的是：多人并行写新功能时的文件冲突。

它不太能直接解决的是：大家都要改同一份“数据结构/数据库”的时候。

也就是你问的这个：问卷要改 database 怎么办？

—

问卷/数据库要变更怎么办？🗂️（我们用“只新增不破坏”的办法）

核心思路还是同一个：别在原地改，尽量新增版本。

1）问卷题库（配置数据）改动：用“版本文件”

不要改旧题库文件，直接新增一个版本：

questionnaire_v1.xlsx

questionnaire_v2.xlsx

插件在 manifest.json 里声明自己用哪个版本。

这样 v1 插件还能跑，v2 插件也能并行开发，互不拖累。

2）数据库表结构（schema）改动：用“迁移脚本 migrations”

如果你们真改到表结构（加字段、改表），建议用最朴素的迁移：

每次变更新增一个文件：migrations/003_add_xxx.sql

绝对不要回头改旧迁移文件

新增文件合并起来几乎不会冲突，而且还能追溯“这次改了啥”。

—