Cursor把4个AI塞进同个项目，开发者发现1个隐藏功能：它们会互相拆台

4个AI同时审同一份代码，结果没一个结论相同。这不是bug，是Cursor去年悄悄上线的Background Agents功能——大多数人只当并行工具用，作者发现它更适合当「压力测试仪」。

本文作者正在做一个Angular自动化技能系统，让AI帮开发者搞定繁琐的项目初始化。写到第二部分时，他突发奇想：如果让多个大模型同时审查这套系统，会发生什么？

答案出乎意料：单个AI发现不了的问题，在群体评审中无所遁形。

01 | 把AI当顾问团用，而非打字机

Cursor的Background Agents允许同时运行多个AI代理，各自独立处理同一任务，互不干扰。作者的操作很直接——把同一套审查指令丢给4个不同模型，让它们分别「交作业」。

这个设计像极了管理咨询的标准打法：同一份brief发给四家事务所，对比报告找盲区。单个顾问可能遗漏的角落，在交叉比对中会被强制曝光。

但有个前提条件：项目必须已推送到Git且保持最新。代理直接操作仓库，审的是代码的实际状态，不是你本地没提交的草稿。

作者最初的动机很务实。他的技能系统要处理Angular项目的全套初始化——从linter、formatter到第三方库集成，规则复杂且相互勾连。他担心某些指令表面通用，实则是为过去某次失败打的补丁，这种「过拟合」会让系统越用越僵。

单个AI审查时，这类问题很难被标记。但当4个模型用不同「脑回路」扫描同一套规则时，有人觉得某条指令「过于具体」，有人质疑「这里为什么硬编码」，矛盾点自然浮现。

02 | 一份专门制造「分歧」的提示词

并行评审的价值不在数量，而在结构化冲突。作者设计了一套审查框架，强制每个AI从特定维度切入：

过拟合检查——专门猎杀那些伪装成系统方案的临时补丁。这是技能系统慢性死亡的主因，但常规审查几乎从不触碰。

系统完整性检查——不看单个技能，看技能之间的契约关系、执行顺序、新增子技能是否会破坏现有流程。

失败模式分析——假设用户完全不看文档，会怎么搞砸？系统能否优雅降级？

可维护性审计——半年后的作者自己，还能看懂这些规则吗？

四个维度，四种视角。当AI A在过拟合检查里标记某条规则「像是为特定项目定制」，AI B可能在系统完整性检查里追问「这条规则和前面的冲突检测如何协作」。两个独立发现指向同一处代码，问题坐实。

作者提到一个细节：他故意没在提示词里要求「达成共识」。相反，他鼓励每个模型坚持自己的判断——分歧本身就是信号。

03 | 实战中的意外收获

在Angular技能系统的审查中，4个AI的反馈呈现明显的「能力分野」。某个模型对TypeScript配置细节极其敏感，揪出了eslint规则与prettier的潜在冲突；另一个则擅长识别用户流程中的断点，指出「如果用户中途取消，临时文件不会被清理」。

没有一个模型覆盖全部问题。但把四份报告叠在一起，作者得到了一张完整的「风险地图」。

更意外的是「假阳性」的价值。两个AI同时误判某处代码「有问题」，促使作者重新审视——结果发现注释写得确实模糊，容易让人误解。这属于「没有bug，但有债务」的灰色地带，单模型审查很难触及。

作者把这个方法命名为「Multi-Agent Task Force」。核心洞察是：LLM的幻觉和盲区具有「个性」，不同模型的错误模式不重叠。当它们被强制就同一对象发表独立意见时，共识区域可信度极高，分歧区域则需要人工介入。

这与传统的「多轮自我修正」有本质区别。让同一个AI反复检查，它容易陷入确认偏误，用更复杂的逻辑强化初始判断。换四个不同的「大脑」，才能打破这种回声室。

04 | 这套方法的边界在哪

作者没有回避限制。首先，成本线性增长——4个并行代理意味着4倍token消耗。对于大型代码库，这需要精打细算。

其次，提示词工程变得关键。如果审查框架设计粗糙，AI们会集体跑偏，产出四份相似的平庸报告。作者花了相当篇幅迭代提示词，特别是「过拟合检查」的表述——如何让AI识别「看似通用、实则特化」的代码气味，本身就是一门手艺。

最后，人工整合不可替代。4份报告需要有人阅读、比对、判断冲突优先级。这不是「自动驾驶」，是「副驾驶军团」——帮你把地图画全，但方向盘还在你手里。

作者正在把这套方法扩展到其他场景：prompt系统验证、技术方案评审、甚至文档准确性检查。核心逻辑不变——用结构化的多视角冲突，暴露单点审查的盲区。

他在文末留了一个未完成的实验：如果让AI们不仅独立审查，还能互相质疑对方的结论，会发生什么？Cursor目前的架构不支持代理间直接通信，但作者暗示，这可能成为下一个探索方向。

你的项目里，有没有哪段代码「看起来没问题，但总觉得哪里不对」？或许缺的不是更多时间，而是第四个AI的视角。