把最好的模型放在前面
内容提要
软件开发中，AI模型能力分配应逆向：最强模型用于需求与设计，因早期错误代价高且难验证；中等模型负责编码，弱模型做常规Review。避免让弱模型先设计再强模型审查，因后者易受已有方案限制。建议用两模型独立设计再比较，确保独立思考，将资源投入方向决策。
延伸解读
早期错误代价更高
文章指出，软件开发中越靠前的错误越昂贵。需求和设计阶段的错误会沿着后续的规划、编码和测试被放大，最终形成难以推翻的惯性。因此，将最强模型用于早期决策，比在最后阶段多查出几个bug更有价值。
模型Review的局限性
模型在Review时容易受已有方案限制，倾向于在现有框架内修补，而非推翻重来。这是因为任务本身暗示了当前方案大体成立，且模型缺乏独立判断和最终责任。因此，不能指望最后的Review能纠正方向性错误。
独立设计优于交叉Review
文章建议，若想利用多个模型，应让它们基于同一需求独立设计，再比较整合。这能避免路径依赖，产生真正不同的解法。交叉Review虽能减少盲点，但无法消除已有产物带来的思维限制。
Q&A
在软件开发中，AI模型的能力应该如何分配？
应该逆向分配：最强的模型用于需求和设计阶段，中等模型负责编码，较弱的模型用于常规代码审查。
为什么在AI开发流程中，最强的模型应该用在需求分析和设计阶段？
因为需求和设计阶段的错误代价最高，且难以验证，一旦方向错误，后续开发会沿着错误方向展开，导致成本高昂。
为什么让弱模型先设计再让强模型审查效果不好？
因为强模型在审查时容易受到已有设计的限制，只会在这个范围内查缺补漏，而不会推翻重来，导致得到平庸的设计。
在AI开发中，为什么不能完全依赖最后的代码审查来纠正方向性错误？
因为模型在审查时缺乏独立判断，且不会质疑已有代码的前提，容易沿着已有结构修补，无法从根本上纠正方向性错误。
如何利用两个模型进行设计阶段的对抗，以获得更好的方案？
给两个模型同一份原始需求，让它们在彼此不知道对方答案的情况下独立设计，然后比较两份设计，一致的地方可靠，分歧大的地方值得深入探讨。
为什么在AI开发中，传统软件团队中资深程序员Review的模式不适用？
因为人类Reviewer有独立判断和权力推翻重来，而模型没有长期参与项目的独立判断，也不承担合并后的责任，只会努力扮演Reviewer角色，改进当前方案。
