先把两条素材的性质分清楚

消息提到，Dex Horthy 批评一种“表演式 tokenmaxxing”，认为它对软件工程职业的伤害会超过任何编程模型。这是一条个人观点，不能当成行业结论。素材里还有一位从业者说，自己在软件工厂里疯狂 tokenmaxxing，想借此找到杠杆、保持领先，并提到当天用了 32x Opus 5.5。这也是个人选择，不是可复制的团队方法。

两条信息放在一起，对求职者的价值不在“谁对谁错”，而在于提醒你：当面试里出现“我们AI用量很高”这类说法时，你要问的不是数字本身，而是这个团队有没有自己的工程判断。

听到“我们疯狂用AI写代码”，追问什么

面试官说团队重度使用 AI，你可以顺着问：过去半年，有没有哪次线上问题能追溯到 AI 生成的代码？那次是谁先发现的，后来流程改了什么。这个问题不预设答案，只是看对方能不能讲出具体过程。

可以再问：代码评审时，评审人重点看什么——是格式和风格，还是边界条件、错误处理和可维护性？如果回答集中在工具用量、生成速度，却说不太清评审在看什么，这至少说明这个团队还没把工具使用和工程结果分开谈。

事故归因和技术债排期同样是自然的追问方向：线上出问题，复盘时讨论的是谁写的提示词，还是系统哪里缺了防线；技术债有没有固定的偿还时间，还是永远排在需求后面。如果评审只走过场、事故归因于工具、技术债从不排期，那工具用得多，可能只是把风险藏得更深。这些是给读者的分析，不是对素材的补充报道。

比较团队时看边界，而不是看用量

选 offer 时可以这样比较：假设 A 团队把“全员 AI 编程、人均用量领先”写进介绍，B 团队说“我们在测试和文档环节用 AI，核心模块仍然人工评审”。这里 B 未必更好，但它能说清工具在哪些环节用、哪些环节不用。你可以继续问：哪些代码不允许 AI 直接生成？新人上手时，是先学工具还是先学系统？团队最近一次因为引入工具而调整流程，是什么时候、改了什么？

这些问题没有标准答案。对方回答得含糊，不等于团队有问题；回答得具体，也不能保证你进去后体验一样。但它们能帮你判断，这个团队是在用工具支撑判断，还是把工具使用量当成交付的证明。

一个实际可做的小建议：面试前挑一个问题写下来——比如“最近一次线上问题，复盘时讨论了什么”——面试时自然问出口，留意对方是在讲过程，还是在讲用量。

本文中的 offer 对比为假设场景，用于说明比较思路，不代表任何真实团队的情况。