多人协作修改anishort项目需以git+lfs管理二进制资源，按修改类型分设功能分支，pr须注明影响分镜，评审锚定json工程文件具体行，且每人限负责2–3个连续场景以避免语义冲突。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
多人协作修改 AniShort 项目时，意见不同步的根本原因不是沟通意愿不足，而是缺乏可落地的版本控制与变更可见机制。直接靠口头同步、截图发群、手动合并时间线，必然导致覆盖、遗漏、回退困难。
用 Git + LFS 管理 AniShort 工程文件
AniShort 生成的工程目录（如 project.anishort、assets/ 下的 PNG 序列或 MP4）本质是二进制文件，普通 Git 无法有效 diff 和合并。必须启用 Git LFS：
- 在项目根目录执行
git lfs install，再用git lfs track "*.mp4"、git lfs track "assets/**"声明大文件类型 - 确保所有成员都运行过
git lfs install --local，否则 clone 下来的是指针文件而非真实资源 - 每次提交前必须
git add .gitattributes，否则 LFS 规则不生效 - 避免把整个
output/目录纳入 LFS —— 它是产物，应从.gitignore排除
分支策略要匹配修改粒度
AniShort 的修改常分三类：脚本调整（文本）、分镜变动（JSON 或 XML 结构）、素材替换（二进制）。不同修改应走不同分支路径：
- 脚本和分镜逻辑改用
feat/script-refactor这类短生命周期功能分支，合并前需通过anishort validate（如有 CLI）校验结构合法性 - 美术素材更新走
asset/update-bg-forest-v2分支，命名带版本号，便于回溯；禁止在main上直接 push PNG 序列 - 所有 PR 描述里必须写明「本次修改影响哪些分镜编号」，例如「修改了 scene_03 和 scene_07 的台词与镜头时长」
评论必须锚定到具体帧或节点
微信群或文档里说“第12秒太慢”毫无操作性——AniShort 时间轴没有统一帧率标识，不同人导出的 MP4 帧数可能不一致。可行做法是：
- 统一用 AniShort 导出的 JSON 工程文件作评审依据，在 VS Code 中用
jsonc模式打开，直接在"scenes"[2]["duration"行加评论 - 使用 GitHub 提交后的文件差异页（而不是原始 MP4），在
project.json的特定行点击「+」添加 review comment - 禁止出现“我觉得这里不对”这类模糊反馈；必须写成“
scene_05.duration当前为 2.4s，建议调至 1.8s 以匹配配音节奏”
最常被忽略的一点：AniShort 自身不提供协同编辑锁机制。哪怕用了 Git，两个人同时改同一个 scene_05 的 JSON 字段，merge 后仍可能语义冲突——比如一人删了转场效果，另一人改了背景色，Git 能合并文本，但 AniShort 加载时可能因字段缺失而静音或跳帧。解决办法只有一个：拆分场景粒度，让每人只负责连续的 2–3 个 scene，且修改前先 git pull && git checkout -b feat/scene-05-06-yourname。
