| name | solo-parallel-dev |
| description | 单人多分支并行开发工作流：一个人同时开发多个feature/fix/docs时，如何管理分支、预防冲突、恢复上下文、有序合并。当用户说'同时开发几个功能'、'多分支并行'、'分支管理'、'切来切去忘了进度'、'README冲突'、'一个人怎么并行开发'时触发。核心特点：worktree物理隔离、分支状态看板、冲突预防策略、上下文恢复协议、合并排序算法。 |
来源: 自建（基于 skills-ai 仓库 94 个 skill 的实战经验）
发布时间: 2026-05-25
理念: "一个人开 5 个分支，不等于 5 倍效率——等于 5 倍混乱。"
🌿 Solo Parallel Dev — 单人多分支并行开发工作流
你既是产品经理，也是开发，也是 QA，也是运维。
这个 Skill 教你如何在不把自己逼疯的前提下，一个人并行推进多个 feature。
🎯 核心原则
原则1: 并行 ≠ 同时写代码
真正的并行是"A 在等反馈时做 B"，不是"A 写到一半切去做 B"
原则2: 同时活跃的分支 ≤ 3 个
人脑上下文切换的成本极高，超过 3 个必烂尾
原则3: main 分支永远可部署
你自己就是唯一的 gatekeeper，不要骗自己
原则4: 用 worktree 物理隔离，不用 stash mentally 隔离
stash 会让你忘记，worktree 让你打开文件夹就回到上下文
🏗️ 分支策略
分支命名规范
feat/<skill-name>-<简短描述> # 新功能
fix/<bug-desc> # 修复
docs/<doc-update> # 文档更新
refactor/<scope> # 重构
chore/<maintenance> # 维护性工作
示例：
feat/backend-change-flow-upgrade
feat/ai-collaboration-safety
fix/readme-typo
docs/cross-platform-guide
分支生命周期状态
🌱 新建 → 刚创建，还没写代码
🌿 开发中 → 正在编码，有未提交变更
🍃 暂存中 → 开发中断，已 stash / 已提交但未完
🌳 待合并 → 代码完成，等待合入 main
🍂 已归档 → 已合并到 main，可删除
🛠️ 工作流：worktree 物理隔离法（推荐）
为什么用 worktree 而不是 stash / 反复 checkout？
| 方式 | 切换成本 | 上下文保留 | 同时查看多个分支 |
|---|
git checkout | 中 | 差（靠记忆） | ❌ 不能 |
git stash | 低 | 极差（经常忘） | ❌ 不能 |
| git worktree | 低 | 极好（物理隔离） | ✅ 可以 |
worktree 设置
cd /d/xgq/work/skills-ai
git worktree add ../skills-ai-feat-backend-flow feat/backend-change-flow-upgrade
git worktree add ../skills-ai-feat-ai-safety feat/ai-collaboration-safety
git worktree add ../skills-ai-fix-readme fix/readme-typo
git worktree list
目录结构：
D:\xgq\work\
├── skills-ai/ # main 分支，稳定版本
├── skills-ai-feat-backend-flow/ # feat/backend-change-flow-upgrade
├── skills-ai-feat-ai-safety/ # feat/ai-collaboration-safety
└── skills-ai-fix-readme/ # fix/readme-typo
切换上下文 = 打开另一个 VS Code 窗口，不需要 stash，不需要记 stash 里是什么。
📋 分支状态看板（Branch Kanban）
你自己维护一个看板文件，防止遗忘。
看板位置
skills-ai/
├── .solo-dev/ # 新建这个目录
│ └── BRANCH_KANBAN.md # 分支状态看板
这个文件只在 main 分支维护，每个 feature 分支不修改它。
看板模板
# 🌿 单人并行开发看板
## 当前活跃分支（最多 3 个）
| 分支 | 状态 | 目标 | 进度 | 阻塞点 | 下一步 |
|------|------|------|------|--------|--------|
| feat/backend-change-flow-upgrade | 🌿 开发中 | 升级七阶段闭环 + AI安全机制 | 阶段⑤编码中 | 等用户确认原子输出规则 | 完成编码，提PR |
| feat/ai-collaboration-safety | 🌳 待合并 | 新建防逼疯Skill | 100% | 无 | 提PR → 合并 |
| fix/readme-typo | 🌳 待合并 | 修复README格式错误 | 100% | 无 | 随时可合 |
## 待开始（Backlog）
| 分支 | 优先级 | 预估工作量 | 依赖 |
|------|--------|-----------|------|
| feat/weather-skill-v2 | P1 | 2天 | 无 |
| feat/frontend-code-review-v2 | P2 | 1天 | 等设计稿 |
## 已归档
| 分支 | 合并日期 | 说明 |
|------|---------|------|
| feat/music-recommender | 2026-05-22 | 音乐推荐Skill |
| feat/cardiac-arrest-guide | 2026-05-20 | 心脏骤停急救指南 |
更新时机：
- 每次切换分支前 → 更新当前分支的"进度"和"阻塞点"
- 每次合并后 → 移动到"已归档"
- 每周一 → 审视看板，清理烂尾分支
🔄 上下文恢复协议（Context Recovery）
场景：你三天前在分支 A 写了一半，今天切回来，完全不记得当时在想什么。
恢复三步法
Step 1: 读取分支看板
cat .solo-dev/BRANCH_KANBAN.md
Step 2: 读取分支内的进度笔记
每个 feature 分支根目录下放一个 BRANCH_NOTES.md：
# 分支笔记：feat/backend-change-flow-upgrade
## 当前焦点
- 正在写阶段⑤的"原子输出协议"部分
- M03 修改点已完成，M04 写到一半
## 关键决策记录
- 2026-05-25: 决定原子输出每次只输出一个方法，而非一个文件
- 2026-05-25: 熔断阈值定为"同一修改点错3次"
## 待确认问题
- [ ] 阶段⑦的"AI盲区清单"格式是否合适？
- [ ] 是否需要和 ai-collaboration-safety 交叉引用？
## 上次离开时的状态
- git status: 有 2 个未暂存文件（backend-change-flow/SKILL.md 修改中）
- 未解决：README.md 还没更新
Step 3: 查看代码状态
git status
git diff
git log --oneline -3
如果用了 worktree：
- 打开对应文件夹 → 文件就躺在那里
- VS Code 的未保存标签页还在（如果你没关窗口）
- 终端历史记录还在（
history | tail -20）
⚔️ 冲突预防策略
单人并行最恶心的冲突：自己改 A 分支的 README，同时改 B 分支的 README，合并时自己和自己冲突。
策略 1：公共文件延迟修改
❌ 错误：每个 feature 分支都改 README.md
→ feat/A 改了技能数 93→94
→ feat/B 改了技能数 93→95
→ 合并冲突，自己打自己
✅ 正确：feature 分支里 README.md 要么不改，要么只改目录结构树（不碰统计数字）
→ feat/A 的 README 保持 93 个
→ feat/B 的 README 保持 93 个
→ 合并到 main 后，统一改一次 93→95
具体规则：
| 文件 | feature 分支能否改 | 处理方式 |
|---|
SKILL.md（本分支的） | ✅ 必须改 | 正常开发 |
README.md 目录结构树 | ⚠️ 谨慎改 | 只添加本分支的目录行，不改其他行 |
README.md 技能总数统计 | ❌ 不改 | 留到合并后再改 |
README.md 分类表格 | ⚠️ 谨慎改 | 只添加本分支的行，不改表头 |
README.md 维护记录 | ❌ 不改 | 留到合并后再追加 |
策略 2：合并前统一刷新（Reconciliation）
所有 feature 开发完成后，创建一个 chore/reconcile-readme 分支：
git checkout main
git pull origin main
git checkout -b chore/reconcile-readme
策略 3：先合小的，后合大的
合并顺序影响冲突量：
推荐顺序：
1. fix/* 分支（改动小，先合，减少后续冲突面）
2. docs/* 分支（改动中，无逻辑变更）
3. feat/* 分支（按改动量从小到大）
→ feat/小功能（改 2 个文件）
→ feat/中功能（改 5 个文件）
→ feat/大功能（改 10+ 个文件，重构级）
原因：
- 小分支先合入 main → main 更新 → 大分支 rebase 到最新 main → 大分支解决冲突
- 如果大分支先合 → 小分支 rebase 时要解决大分支引入的冲突，亏死
📦 合并策略
单人推荐：Rebase + Fast-forward（保持线性历史）
git checkout main
git pull origin main
git checkout feat/ai-collaboration-safety
git rebase main
git checkout main
git merge feat/ai-collaboration-safety --ff-only
git push origin main
git branch -d feat/ai-collaboration-safety
git push origin --delete feat/ai-collaboration-safety
如果 feature 分支已经 push 到远程（有 PR）
git checkout main
git merge feat/xxx --squash
git commit -m "feat: xxx
- 功能点1
- 功能点2
Closes #PR编号"
🧹 防烂尾机制
一个人最容易犯的错误：开了 5 个分支，3 个烂尾。
烂尾识别信号
| 信号 | 说明 | 处理 |
|---|
| 分支超过 7 天无提交 | 大概率已忘记上下文 | 要么强制恢复，要么删除 |
| 分支看板状态为"暂存中"超过 3 天 | 阻塞点没解决 | 评估是否值得继续，或降级为 backlog |
| 分支里有大量 WIP 提交 | "save point"式提交 | rebase -i 整理提交历史再合 |
| 分支目标变得不清晰 | 做着做着忘了初衷 | 回看最初的 issue / 需求描述 |
每周清理仪式（Monday Cleanup）
git branch -v
🚀 完整工作流示例
场景：你要同时开发 3 个 feature
Feature A: 升级 backend-change-flow（大，2天）
Feature B: 新建 ai-collaboration-safety（中，1天）
Feature C: 修复 README typo（小，10分钟）
Day 1 上午：
git worktree add ../skills-ai-feat-a feat/backend-change-flow-upgrade
git worktree add ../skills-ai-feat-b feat/ai-collaboration-safety
git worktree add ../skills-ai-feat-c fix/readme-typo
Day 1 上午-下午：在 skills-ai-feat-c 里修 typo
cd /d/xgq/work/skills-ai-feat-c
Day 1 下午：合入 C，开始 B
cd /d/xgq/work/skills-ai
git checkout main && git pull
git merge fix/readme-typo --ff-only && git push
cd /d/xgq/work/skills-ai-feat-b
Day 1 晚上：B 完成，A 开了个头
cd /d/xgq/work/skills-ai-feat-b
git commit → push
cd /d/xgq/work/skills-ai-feat-a
Day 2 上午：合入 B
cd /d/xgq/work/skills-ai
git merge feat/ai-collaboration-safety --ff-only && git push
Day 2 全天：专注 A
cd /d/xgq/work/skills-ai-feat-a
Day 3 上午：合入 A，创建 reconcile 分支刷新 README
cd /d/xgq/work/skills-ai
git merge feat/backend-change-flow-upgrade --ff-only && git push
git checkout -b chore/reconcile-readme
🆚 与现有 Skill 的关系
| Skill | 关系 | 如何使用 |
|---|
| backend-change-flow | 每个 feature 的执行器 | 在每个 worktree 里独立跑七阶段闭环 |
| ai-collaboration-safety | 情绪保险 | 当某个 feature 被 AI 逼疯时，切换到这里恢复 |
| create-pr | 合并前检查 | 每个 feature 合入 main 前，生成规范 PR 描述（即使自己合） |
| quality-gate | 合并前检查 | 每个 feature 分支提交前跑五维检查 |
| multi-agent-orchestration | 进阶并行 | 如果 feature 完全独立，可用多个 Agent 并行工作（worktree 隔离） |
| git-commit | 规范提交 | 每个 commit 用 Conventional Commits 格式 |
最佳实践链：
solo-parallel-dev（分支规划 + worktree 隔离）
↓
backend-change-flow（每个 feature 的开发闭环）
↓
ai-collaboration-safety（被 AI 逼疯时恢复）
↓
quality-gate（提交前检查）
↓
create-pr（生成 PR，留记录）
↓
solo-parallel-dev（合并 + 归档 + 清理）
🚀 快速入口
"我要同时开发几个功能" → 分支规划 + worktree 设置
"分支管理" → 分支状态看板 + 命名规范
"切来切去忘了进度" → 上下文恢复协议
"README冲突" → 冲突预防策略（公共文件延迟修改）
"一个人怎么并行开发" → 完整工作流 + 防烂尾机制
"一个人并行开发的关键不是技术——是自律。worktree 帮你物理隔离，看板帮你对抗遗忘，延迟修改 README 帮你避免自己打自己。"
