打开网易新闻 查看精彩图片

上周,GPT在Claude写的代码里找到一个安全漏洞。不是测试题,是生产环境里的真实漏洞——用户A发起的对话,用户B能直接读取。Claude写的代码,Claude自己审了两遍,没发现。GPT几秒钟就揪出来了。

这件事让我重新理解了一件事:AI辅助开发的上限,不取决于你用的模型多强,而取决于你敢不敢承认它有多瞎。

单模型依赖症:我们都在交"盲税"

单模型依赖症:我们都在交"盲税"

大多数人有个"本命模型"。有人死磕Claude的推理能力,有人迷信GPT的广度,有人追新追最快发布的那个。但问题是——每个模型都有盲视区,而且盲得很有规律。

如果你只用一款模型,它的盲视区就是你的盲视区。这不是比喻,是上周刚发生的生产事故。

我建了一套叫TAT(Tiny AI Team,微型AI团队)的工作流。思路很简单:把AI模型当成真人工程师来管,不是招一个全栈天才包办一切,而是组一个各有所长的团队,我当产品经理拍板。

每个模型有明确分工,没人包揽全部。结果不只是效果更好——成本直接砍到脚踝。

以前我每天用Claude Opus做所有事,很快就把额度烧光。现在Opus只干它擅长的:系统规划和任务编排。常规编码扔给Sonnet,头脑风暴扔给GPT-mini。贵的那款只在关键时刻启动。输出质量没变,账单变了。

Supabase事件:当两个AI共享同一个错误假设

Supabase事件:当两个AI共享同一个错误假设

我在做一款AI管家应用,数据库层用了Supabase。看到服务角色密钥时,我下意识觉得必须是eyJ开头的JWT——以前见过的都这样。新格式是sb_secret_...,我愣是盯着这个有效密钥怀疑了半天。

Claude没纠正我。它跟我犯了同一个假设错误。

GPT在完全独立的上下文里看了同样的代码,回复很干脆:"别猜密钥格式,直接测连接。"

训练数据不同,盲视区不同。这就是多模型协作的核心逻辑。

同一个迭代周期里,Codex(OpenAI的代码专用模型)在代码评审阶段抓到了那个对话所有权漏洞。接口允许任何用户读取任何对话,没有归属校验。Claude的自我评审直接走过场,Codex标为阻塞性问题。

但当我试着用gpt-4o-mini做代码评审时,它开始报假警——把没问题的代码标成漏洞。便宜模型在这个任务上不只是弱,是帮倒忙。

任务和模型的匹配度,比模型本身的排名更重要。

三轮回合制:怎么让AI互相"拆台"

三轮回合制:怎么让AI互相"拆台"

TAT的头脑风暴技能设计成三轮对抗。

第一轮,GPT独立思考,不受Claude已有结论的污染,从零生成方案。第二轮,Opus批判GPT的输出——哪些同意、哪些反对、哪些被遗漏。第三轮,我拍板定夺。

独立性是关键。如果你让同一个模型先想再自我批判,得到的是确认偏误。两个不同模型分开想,才能逼出盲区。

这种设计借鉴了红队测试(Red Teaming,对抗性安全测试)的思路,但成本是真人红队的零头。

打开网易新闻 查看精彩图片

我的TAT配置目前四模型一真人:

Claude Opus:系统架构师。负责高层规划、复杂决策、最终整合。只在关键路径启动。

GPT-4o:创意发散者。头脑风暴、替代方案、挑战假设。便宜到可以随便用。

Codex:代码审计员。专门抓安全漏洞、逻辑缺陷、边界情况。Claude的自检盲区由它补位。

GPT-4o-mini:快速草稿机。生成初版代码、格式化输出、低精度任务。成本是Opus的1/50。

我:产品经理。定优先级、做最终决策、为结果负责。

这套配置的月度成本,比我之前单用Opus还低40%。

成本结构:为什么多模型反而更便宜

成本结构:为什么多模型反而更便宜

直觉上,调用四个模型应该比用一个贵。实际账单恰恰相反。

Opus处理完整编码任务时,我需要连续多轮对话才能拿到可用结果。现在它只参与架构决策,上下文长度和调用次数都骤减。省下来的额度,够我跑几十轮GPT-mini的头脑风暴。

更隐蔽的节省在纠错成本上。单模型 workflow 里,一个安全漏洞漏到生产环境,修复代价是开发时的100倍起跳。Codex提前拦截的那个对话所有权漏洞,如果上线后被利用,用户数据泄露的善后成本远超模型调用费。

我把这种策略叫"模型套利"——用便宜模型处理容错率高的任务,把昂贵模型的算力集中在容错率为零的环节。

具体数字:我现在的AI辅助开发月度支出约$127,之前单用Opus时约$210。输出质量用内部评分卡衡量,从3.2/5提升到4.1/5。评分维度包括代码可维护性、安全漏洞数、架构合理性。

人机回环:为什么"一个真人"不能省

人机回环:为什么"一个真人"不能省

四模型配置里,我的角色不是可选配件,是系统设计的核心约束。

AI模型会达成一种虚假的共识。两个模型都同意的事,可能是它们共享了同一个训练数据偏见。我需要保持对最终决策的垄断,不是为了炫技,是为了在它们集体跑偏时踩刹车。

上周的Supabase事件就是典型案例。如果我当时让Claude和GPT"讨论"密钥格式问题,它们可能互相强化错误假设。我强制要求独立生成结论,才拆穿了共识幻觉。

我的干预点集中在三处:任务分配(哪个模型上)、冲突裁决(模型意见不一致时)、验收标准(什么算"完成")。

任务分配需要理解每个模型的能力边界。Codex擅长找漏洞,但给不出架构建议;Opus能规划系统,却会在简单代码里过度设计。这种判断力来自三个月的试错记录,我建了张"模型-任务匹配度"评分表,每周更新。

冲突裁决更微妙。当Codex和Claude对同一行代码给出相反判断,我不能简单多数决。需要看谁的论证链条更完整、谁引用了更相关的最佳实践、谁的假设更少。这个过程逼我深入理解争议点,比单模型时代学得更快。

验收标准是最容易被外包的环节。模型会告诉你"完成了",但完成的是功能还是需求,是两件事。我坚持手写验收清单,每条对应用户故事而非技术实现。

打开网易新闻 查看精彩图片

从工具到团队:组织设计的隐喻迁移

从工具到团队:组织设计的隐喻迁移

TAT的设计灵感来自敏捷开发里的"两披萨团队"——小到两个披萨能喂饱,大到足够自治。四个模型加我一个,正好在这个规模区间。

传统软件团队有角色分化:架构师出图、开发搬砖、测试挑刺、PM对齐。单模型 workflow 相当于让一个人包揽全部,表面上省掉沟通成本,实际上制造了巨大的隐性债务。

多模型 workflow 把沟通成本显性化了。我需要写更清晰的任务描述,因为模型不像真人同事能追问澄清。但这种摩擦迫使我前期想得更透彻,后期返工更少。

一个意外收获是决策日志。因为每个模型的输出都有记录,我能复盘"当时为什么选A方案"。单模型时代,这个思考过程是黑箱。现在成了可审计的资产。

我还在实验更激进的配置。比如让GPT-4o-mini专门生成"愚蠢问题"——故意用新手视角挑战方案,逼其他模型暴露假设。这个角色的产出90%是噪音,但10%的洞察足够值回票价。

另一个方向是动态路由。根据任务复杂度自动选择模型组合,简单CRUD用mini,涉及权限校验必须过Codex。这个需要我持续标注训练数据,目前准确率约78%,还在迭代。

行业镜像:大厂已经在这么干

行业镜像:大厂已经在这么干

我的TAT是个人项目的土法炼钢,但底层逻辑和大厂实践高度吻合。

Google的Gemini团队内部流传一种"模型议会"机制,多个规模不同的模型对同一查询投票,用置信度加权输出。OpenAI的o1系列在推理时隐式调用了多个内部检查点,只是包装成单模型体验。

更直接的信号来自API定价策略。Claude 3.5 Sonnet和GPT-4o-mini的价格差达到20倍,这不是偶然,是供应商在主动引导用户做任务分层。便宜模型够用的场景,没必要烧贵的那款。

Anthropic的CEO Dario Amodei去年在一次播客里提到,他们内部开发已经"模型化"——不同团队用不同Claude版本,根据任务特性切换。这话的潜台词是:连造模型的人都不迷信最强版本。

我的TAT配置还在进化。最近把DeepSeek-R1加进轮换,专门处理需要长上下文推理的代码重构。它的优势区间和Opus不完全重叠,在某些边界条件下表现更好。

但新增模型也有代价。每加一个成员,任务分配复杂度指数级上升,我需要维护的"模型画像"越来越厚。目前四模型是甜点区,五模型已经开始感到管理负荷。

给同行者的起步建议

给同行者的起步建议

如果你现在单模型重度依赖,迁移不需要推倒重来。

第一步:分离"想"和"做"。让便宜模型生成初版方案,贵模型只负责批判和整合。这个切换能立即降本30%以上。

第二步:引入专门化模型。代码评审用Codex或类似工具,不要指望通用模型做专业任务。专用模型的假阴性率(漏报)显著更低。

第三步:建立冲突解决机制。当模型意见分歧,不要自动采纳"更强"的那个。强制自己写一段分析,说明为什么A比B更适用于当前上下文。这个练习会快速提升你的模型判断力。

第四步:记录决策理由。简单日志就行,"选Opus是因为涉及多步骤状态机"。几个月后回看,你会发现自己的分配策略进化轨迹。

最后一步:保持人的最终否决权。模型可以建议,不能决策。这个边界一旦模糊,系统就开始积累你察觉不到的风险。

我的TAT运行四个月,最意外的发现是"模型疲劳"真实存在。连续几天用同一配置,我会对特定模型的输出风格产生抗体,误判其质量。定期轮换、引入新模型,某种程度上是为了保持我自己的敏感度。

那个被GPT抓出来的安全漏洞,现在写进了我的 onboarding 文档。新成员(人或模型)的第一课:Claude会漏过权限校验,Codex是最后一道防线。这不是对Claude的贬低,是对系统冗余的尊重。