北京
分享至
多AI协作写代码，最常见的翻车方式几乎一模一样：讨论在一个聊天窗口里，动手写代码在另一个工具里，下一次改需求时，只能把上一轮的结论冷冰冰地重新粘一遍。
上下文一断，评审就变成了猜谜。谁定的方案、为什么这么拆、哪条约束不能碰，全散落在几个互不相通的会话里。工具越多，这种断裂越明显。
有一种更靠谱的做法，看上去平淡无奇：把任务说明放在工作旁边，围绕这份说明讨论取舍，从同一个目标出发去构建，发布前再做一次独立评审。
这套流程可以拆成几条要点：
- 任务说明紧贴工作本身，不另存他处
- 所有取舍讨论都对着这份说明展开
- 构建阶段只认一个共享目标
- 发布前独立评审，与草稿分开进行
其中两条边界值得单独拎出来。独立验证和草稿是两件事，不能混在一起做；发布必须经过明确的人工批准，不能由流程自动放行。
Brainstorm 就是围绕这套流程搭起来的：多AI讨论，拆任务，产出可评审的源码，再从已有的项目候选继续往下做。讨论、拆分、评审、续接，每一步都落在同一份上下文里。
模型使用仍然走你自己的合规账号。许可证不卖模型额度，这一点需要说清楚，免得把它当成某种打包转售的通道。
回到开头那个问题：多个AI并不会自动让代码变好。它们共享同一份任务说明时，分歧才有讨论的价值；说明一旦丢失，每个模型都在各自补全缺失的前提，产出越丰富，拼接成本越高。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
