让协作先受约束，再谈效率

多个 AI 模型一起参与开发，听起来像是把算力叠在一起。真正的难点却不在算力，而在约束：谁能改、能改什么、改完凭什么算数。缺了这层约束，越强的模型越容易在无人复核的情况下扩大改动范围，把一次小修变成难以回滚的大改。

FengVoice 的做法是把纪律写在流程里，而不是依赖每个模型自觉。下面是几条已经在用的原则，它们只描述方法，不涉及具体凭据或运维细节。

一次只允许一个写入者

同一任务在同一时间只允许一个具备写入权限的执行者。开始动手前先确认没有其他执行者正在写入，并检查工作区状态。并发写入带来的冲突，往往比单个模型犯的错更难排查，所以宁可串行，也不让两个执行者同时改同一片代码。

任务先定范围，再动手

每一轮改动都先落成一份明确的任务书：允许修改哪些文件、验收标准是什么、哪些事情本轮明确不做。执行者不得擅自扩大范围，也不创建任务书之外的文件。范围写清楚之后，"跑偏"就从一种主观判断变成了可以机械检查的事实。

三道门：入场、过程、封存

改动要穿过三道机械门禁，任一不过就停下。

第一道在提交前检查：暂存的文件是否都落在本轮任务书允许的范围内，有没有触碰被硬性保护的敏感路径。第二道是一条固定顺序的检查链——内容校验、类型检查、单元测试、静态检查、构建产物，按顺序跑，第一处失败即停止。第三道在检查通过后核对产物：除了预期内的文件，工作区不应再有其他改动，否则视为异常，需要人工介入。

这三道门的意义在于：判断"这次改动是否合格"不依赖某个模型说合格，而依赖一组每次都一样、可以被人复现的检查。

外向动作留给人

有些动作是外向且难以撤销的：推送到远程、合并主干、部署生产。这类动作不进入自动流程，必须由人逐次授权。模型可以把一切准备到"只差一步"，但那一步由谁按下，是刻意留给人的判断。

门禁不是为了限制，而是为了信任

把这些门禁摆出来，不是不信任模型，而是让协作产出可以被信任。约束越清晰，越能放心让不同模型接力：因为无论是谁写的，都要穿过同一组门，接受同一套复核。对一个长期维护的项目来说，这种可复现的确定性，比任何单次的高效都更值得积累。