四个大模型，三条业务线，四个标准化任务，整整七十二小时。最后的系统能跑通，52个测试用例全过。但过程，用四个字形容：一地鸡毛。

过去三天，我干了一件挺疯狂的事。

我把一个完整的企业级PLM BOM管理系统，拆成了三条业务线，分配给四个不同的大模型，让它们按照统一的任务分工矩阵接力开发。从代码阅读分析开始，到方案设计，再到代码落地，最后到自动化测试验证，每个模型走完完整的四步流程。

四个模型，三条业务线，四个标准化任务，整整七十二小时。

结果怎么样呢？最后的系统是能用的。变更管理、供应商管理、库存管理，三个模块都跑通了，52个自动化测试用例全部通过，甚至还做了回归测试。

但过程，用四个字形容就是，一地鸡毛。

如果只是测试模型能力，那其实没什么好说的。但如果你也想试试用多个模型接力来完成一个稍微复杂点的开发任务，那我踩过的这六个坑，你最好记下来。

真的，我当时每踩一个坑，都想抽自己一巴掌。这些坑没有一个是模型能力不行导致的，全是任务管理和基础设施的问题。整整耽误了将近一天的时间，模型的实际能力都被环境问题给掩盖了。

第一个坑：任务说明书，最初交代不清

最开始我只写了笼统的「完成供应商管理模块开发」，没有明确每个模型具体负责哪个新增模块，没有明确四个任务的交付标准和验收条件，甚至连代码修改范围和边界都没说。

你猜结果怎么样？

第一个上场的Mizu，上来就跑偏了。它本来应该负责做完整的ECR/ECO变更管理生命周期，结果它理解成了做基础功能优化，吭哧吭哧把加载通知、权限控制、审计日志这四个企业级功能给做完了。等到我发现任务描述不够明确的时候，已经完成了两个任务。

模棱两可的描述，等于模型各自理解，等于跑偏。

任务说明书必须在一开始就写清每个模型的分工、交付物清单、验收标准。不要让模型去「猜」你的意图。你说什么，它就做什么。你没说清楚，就不要怪它做错。

第二个坑：缺乏进度跟踪，中断后全靠记忆

前两个模型执行的过程中，我没有强制要求维护进度文件。然后问题就来了：模型被超时掐断后重启，根本不知道自己做到哪了，只能从头再来或者凭「记忆」猜测。

Mizu做完四个P0优化点后，不知道该从哪继续，浪费了一轮对话确认进度。Yama的进度文件里有多处占位符和重复章节，明显就是中断后恢复时逻辑混乱。后来虽然强制建立了进度文件和分工矩阵，但已经浪费了好几轮对话。

进度跟踪不是可选项，是强制项。

每个模型必须在启动时读进度文件，每完成一步更新进度文件。没有进度文件，等于每次重启都是失忆。

第三个坑：分工矩阵没有及时更新

发现第一个问题之后，我跟第二个模型Yama口头沟通了「每个模型开发不同的新增模块」的要求。但是，我没有同步更新任务说明书和分工矩阵。

然后就炸了。

Yama先是按自己的理解做了变更管理的ECR/ECO，然后又做了供应商管理，实际上做了两条业务线。等到Kaze上场的时候，看到的分工矩阵还是旧的，以为供应商管理还没人做，结果发现Yama已经写了一版，但还有bug。导致供应商管理被两个模型重叠开发，代码混合，评分完全失真。

分工变了就必须立刻更新文档并通知所有相关方。

口头说了不算，文档更新了才算。不要相信任何形式的口头交接，在AI协作里，写下来的才作数。

第四个坑：环境不稳定加上超时设置不当，浪费近一天

这是耽误时间最多的一个坑。

测试过程中遇到了严重的环境问题。首先是配置了太多不需要的Skill，什么公众号发布、天气、视频生成之类的，模型启动时读取这些Skill报错、加载失败、甚至触发异常流程。

然后是超时设置过短，默认超时300秒，而代码开发任务需要读6700多行前端代码，写API，写前端，写测试，根本不够用。结果就是超时，重启，再超时，再重启，死循环。

Kaze被300秒超时掐断，任务三前端代码写到一半被杀，后续还得由Yuki代完成。一直等到我清理了无用Skill，把超时改成了3分钟，问题才彻底解决。但从发现问题到彻底解决，耽误了将近一天的时间。

测试环境要提前清理干净，超时设置要根据任务复杂度调整。

不要等模型跑挂了才发现环境有问题。模型的超时时间，跟人类的开会时间是一个道理。你给它五分钟，它只能产出五分钟的东西。

第五个坑：没有随时提交Git，成果丢失白干活

模型写完代码后没有自动提交Git的习惯。当超时被杀或环境重启时，未提交的工作全部丢失。

Yama写了一版供应商管理代码，超时被杀后重启，发现代码没保存，只能重写。Kaze修了Yama的路由bug和死代码bug，但这些修复在超时被杀时丢失，又得重新来。多个模型的代码改动因为没及时commit，在环境重启后丢失，等于白干。

每完成一个子任务就必须git add + commit + push。

不要等「全部做完再提交」，因为可能永远等不到那个时刻。写代码不提交，跟写文章没保存是一个感觉。前功尽弃的那种绝望，我不想再体验第二次。

第六个坑：边界场景考虑不足，降级逻辑缺失

模型开发功能时，只考虑了正常路径，完全没考虑第三方依赖异常的边界场景。结果这次测试就发现了一个P0级Bug：ECR/ECO详情接口在ARAS连接断开时直接返回500，没有模拟数据降级能力。ARAS服务一异常，整个变更管理模块完全不可用。

企业级应用核心模块的容错能力不足，根本达不到生产环境的可用性要求。

企业级系统开发必须强制要求依赖异常场景的处理，降级逻辑是核心功能的一部分，不是可选优化项。

写在最后：管理大于能力

说真的，这六个坑踩下来，我最大的感受不是哪个模型强哪个模型弱，而是现在大家聊大模型工程，都在聊模型能力、聊Prompt技巧、聊Agent架构，但很少有人聊最基础的东西。

任务管理。进度跟踪。环境配置。版本控制。边界场景。

这些软件工程里最基础、最朴素的道理，放到AI开发里依然适用，甚至更重要。因为人忘带东西了还能想起来，AI忘了就是真忘了。人超时了还能说一声“我再做会”，AI超时了就是直接被杀，什么都不剩。人知道改了分工要告诉所有人，AI只看文档，文档没更新它就不知道。

现在很多人对多模型协作有一个巨大的误解：觉得多模型就是选一堆最牛逼的模型，让它们各展所长，1+1>2。

但真实情况是，多模型协作，首先要解决的不是怎么发挥每个模型的长处，而是怎么避免基础设施的问题把所有模型的能力都废掉。

一个管理混乱的多项目，十个顶级模型也干不过一个管理规范的单模型。

这就像一家公司，招了十个行业顶尖的专家，但不给他们定清楚分工，不给他们写清楚任务目标，不让他们写日报记录进度，不给他们配好用的电脑，还每隔五分钟就把他们电脑强制重启。你说这十个专家能干出什么活来？

专家也会被傻逼管理干废。大模型也一样。

所以如果你也想试试用多模型来做开发，我的建议是：先不要去纠结选哪个模型，先把基础设施搭好。

写清楚每个模型的分工和验收标准，强制要求每一步更新进度文件，每做完一件事就提交Git，给够足够的超时时间，清理干净不需要的插件和Skill。

这些基础工作做好了，哪怕用的是普通模型，最后出来的结果也不会差。这些基础工作没做好，哪怕用的是世界上最好的模型，最后也是一地鸡毛。

管理大于能力。这个在人类组织里被验证了一万遍的道理，在AI组织里同样适用。

说真的，这次测试做下来，我对未来反而更乐观了。

现在模型的能力已经足够强了。四个不同的模型，按照同一个分工矩阵，各自独立开发，最后写出来的代码居然能拼到一起跑通，还能通过回归测试。这放在一年前，谁敢想？

但我们这些用模型的人，管理水平还没跟上。还在用原始的、粗放的方式来管理模型协作。想到哪说到哪，没有文档，没有进度，没有版本控制，全靠模型自己领悟。

这就是现在最大的信息差。

模型的能力已经跑到了90分，但我们的管理水平还在30分。大部分人用不好模型，不是模型不行，是管理不行。

而这，恰恰就是机会。

当所有人都在卷模型、卷Prompt、卷Agent架构的时候，你只要老老实实把最基础的项目管理做好，就能超过90%的人。

就这么简单。