摘要：多人同时改一个项目，最怕撞车和误发：你改接口、他改调用，一合并全是冲突；有人图快直接动了客户正在用的版本，线上当场挂掉。马良 Harness 研发协作平台用 worktree 给每个人一条独立工作路径，会话与工程全部隔离；主干 release 谁都不能动，成员提交、管理员合并验收后才发布成新版本。十个人的团队，从此拥有百人团队才有的特性隔离、评审合并与主干保护纪律。
先看一个十人研发小团队最熟悉的周五下午。
五个人同时在一个项目上并行：老张在改设备通信接口，小李在改调用这个接口的上层逻辑，小王在重构数据结构，两个刚入职的工程师跟着 AI 一边问一边改。五点半开始往一起合——冲突一片红。接口对不上，字段被改了名，新人那版里还留着调试时写死的测试参数。更要命的是，周三有人图省事，直接在客户正在跑的版本上动了刀，现场设备当晚报警，技术负责人连夜打车回公司回滚。
这不是谁水平不行。这是没有隔离的协作，迟早要交的学费。马良 Harness 研发协作平台治这种病，靠两样朴素的东西：worktree 隔离，和一个必须过管理员的 release。
一、病根：所有人挤在同一摊代码上
大公司靠什么避免这种事故？靠一整套昂贵的研发纪律：特性分支、代码评审、合并门禁、受保护的主干、专职的配置管理员。任何一个改动在进入正式版本之前，都要先在隔离环境里完成，被人看过、被机器验过，才允许合进主干。
一个十个人的团队请不起这套编制，于是流程退化成"靠吼"：动手前在群里喊一声"这个文件我动了"，合并前靠技术负责人肉眼盯，发布靠某个胆子大、记性好的老员工手动操作。代码散落在各台电脑上，协作全靠打 zip 包传来传去；每个人跟 AI 聊了什么、试到哪一步，别人看不见，项目到底推进到什么程度，全靠人跟人口头沟通。
老板想看一眼进度，只能把人一个个拉来问：你那个分支叫什么名字？最新版在哪台电脑上？上周让 AI 试过的三个方案为什么选了现在这个？会话历史不透明，决策过程不留痕，一个人请假，整条线就断在他的电脑密码后面。项目越大、并行的人越多，这种"靠人传递状态"的成本就越离谱——团队的产出明明已经开上 AI 的快车道，协作方式却还停留在发压缩包的年代。
还有一种乱，是 AI 时代新长出来的：一个工程师在同一个会话里又做策略探索、又做数据准备、又做回测验证，上下文又脏又长，AI 常常把半路的猜想当成正式结论写进代码，他自己都分不清哪句是定论、哪句是草稿。
马良 Harness 研发协作平台做的事，就是把大公司研发流程里最精华的那套纪律——特性隔离、评审合并、主干保护——压缩进一个开箱即用的平台。核心是两样东西：每人一条 worktree，加上一个谁都不能随便动的 release。
二、worktree：每人一条独立工作路径，会话和工程都关在里面
先理解一个概念：在这个平台里，工作区就是服务器上的一个项目路径。代码不在各人的笔记本上，而在团队服务器的项目目录里；所有人打开平台，看到的是同一套三区域界面——左侧是团队与工作区，中间是会话窗口，右上角是批注模式。
成员要开始干活，先在项目下建立自己的 worktree，也就是一条只属于自己的工作路径。接下来他做的所有事都关在这条路径里：他跟 AI 的会话在这里，他改出来的工程也在这里。十个人同时开工，就是十条各自独立的 worktree——你改你的接口，我改我的逻辑，他试他的新方案，物理上互不干预。没有"谁覆盖了谁的代码"，也不会有人一失手就碰掉别人干了一半的活。
放到一个真实的十人团队里，画面是这样的：早会拆完需求，量化团队的三个人各自领走任务，一个在自己的 worktree 里试新因子，一个在另一条路径里改回测引擎，技术负责人同时开第三条路径复核数据口径。三条路径背后是同一份项目底子，但三个人的会话彼此听不见、改动彼此碰不着。中午那个试因子的方向被证伪，他直接放弃整条路径，另外两个人的工作连根头发都没被惊动。
更顺的一种用法，是让策略总控先接住一个模糊想法：负责人把需求丢给总控，总控按预定义好的流程和任务特征，把准备工作拆给多个 session 在后台并行——这个 session 去整理数据，那个 session 去搭回测框架，第三个先做可行性验证。等工程师早上坐下来，面前已经是几份准备好的上下文。项目从此不再卡在老板一个人的时间上：他不必亲自派每一个活，却随时可以进入任何一个 session，看到不对的地方直接接管、当场调整。而这些 session 依旧长在各自的 worktree 里，准备归准备，主线归主线。
不同性质的任务从此也不必挤在一个会话里：探索的归探索，验证的归验证，准备交付的那一份始终干干净净。AI 上下文脏乱导致的"拿着草稿当结论"，被路径隔离从根上挡住了。
三、release：当前能用的版本，谁都不能随便动
每个项目默认有一个 release。它的定义非常朴素：当前可用、能交付给客户、能上线运行的版本，是全队的"根据地"。
普通成员没有 release 权限。他在自己的 worktree 里怎么试都行，哪怕把代码改得天翻地覆，影响的也只是自己那条路径，客户手里正在用的版本毫发无伤。"改坏了"这个让无数小团队做噩梦的词，从此只可能发生在试验场里，发生不到生产版本上。
这正是主干保护最朴素的含义：不是不让人犯错，而是让错误天然够不到主干。新人可以放手试，外包可以放开干，因为他们再怎么折腾，都在自己的沙盒里。
很多团队用熟之后会定下一条规矩：哪怕只是改一行配置想看个效果，也一律在个人 worktree 里试。因为试验零成本、又绝不波及主干，团队终于不再需要"别动我代码"式的互相提防；新人上手反而更快——敢动手，是成长的前提。
四、活干完了：提交管理员，合并验收后才成为新 release
那活干完怎么交出去？流程只有几步：成员在自己的 worktree 里完成开发和自测，提交合并申请，交给管理员 admin。
管理员干的是合并与验收的活：把每个人的工作合到一起，看接口对不对、改动是不是符合这次需求、有没有夹带调试代码和不该动的文件、测试报告过不过关。符合要求，才合并发布成新的 release；不符合，打回去，注明问题，继续在各自的 worktree 里改。急着赶版本也没用，闸门不认嗓门，只认质量。
评审意见也不必另开工具：管理员在右上角的批注模式里直接对着代码和会话写批注，哪一行不达标、为什么打回，落在哪一条 worktree 上清清楚楚；提交人改完重新提交，同一处改动的来龙去脉完整留痕。三个月后回头查"这个接口当初为什么这么设计"，看到的不是谁的记忆，是系统里的记录。
这就是这套机制里最硬的一条原则——最后一层还是人。规则可以全部交给系统：隔离自动完成，路径自动分开，权限自动生效；但"这一版能不能交付"这个判断，最终责任必须落在人身上。AI 可以十倍放大人的产出，却不能替人在交付单上签字。系统把人从反复维护流程的苦役里解放出来，人则守在唯一不可外包的那个点上：拍板。
纪律是硬的，配置是活的：如果某个同事经过长期验证特别可信，或者某个项目本来就由他一个人维护，管理员角色可以直接授予他，让他在自己的项目里一路走完；人多、项目重的组，则把闸门收回到技术负责人手里。
五、项目内不打架，项目间好集成
这套隔离同时理顺了两种协作。
项目内，多人并行不打架，主干永远健康。十个人接再急的需求，也能拆成十条 worktree 同时推进，最后在管理员这里汇成一个经过验收的新版本，而不是周五晚上全员留下来解冲突。以前一个人的 session 卡住，整条线都得等他睡醒；现在管理者可以进入任何一条 worktree 的会话直接接手调整，项目不再卡在某一个人的时间上。
项目间，上下游协作第一次有了清晰边界。上游团队把一个工程化模块在自己的项目里做好、测完，把项目路径直接复制给下游；下游拿到授权，进入会话就能看到测试报告和完整上下文，直接引用、动态集成，不用再收 zip 包，也不用猜"你发我的到底是哪一版"。人与人之间版本不一致这种最耗人的沟通成本，被"服务器上只有一个项目路径"从根上消掉了。合作结束，权限一收，边界立刻恢复。
对做甲方交付的团队，这还顺带改变了验收方式：到了里程碑节点，给甲方开一个受限账号查看当前 release，对方看到的永远是经过管理员发布、可以运行的那一版，而不是某个工程师电脑上不知道改没改完的半成品。演示翻车的经典场面，就此消失。
技术老板一听就懂它的价值：这不是多了一个代码仓库，而是把大公司研发组织最核心的秩序，变成了十个人也用得起的日常工作方式。规则交给系统，把关留给人。
适合谁
它适合十个人左右、有明确上下游研发协作、工作量饱满的小团队：做工业控制和嵌入式软件的、做量化策略的、给甲方做封闭交付项目的外包团队，以及所有"多人同时在一个代码库里干活"的研发组。团队越小，越经不起一次主干事故，这套纪律的回报就越大。
worktree 和 release 管的是工程协作的秩序，分支策略、验收标准、评审颗粒度，仍需要技术负责人按项目的实际情况定清楚。管理员这道闸，必须由一个真懂代码、担得起交付责任的人来守。