消息提到，Spotify公开了自家Claude Code内部架构，并称把大文件读取的Token消耗降低约90%。做法包括：超过350行的读取请求在执行前被拦截，大文件分流给廉价小模型；编辑文件和复杂推理则不分流，测试中小模型漏掉线程安全漏洞。是否已开源、90%口径、能否复用到其他团队，素材未说明。

同一任务两种做法，差别在哪里？

假设你手头有一个重复测试生成任务（模拟场景）。做法A：把相关文件全部塞给旗舰模型，让它生成测试；做法B：先让廉价小模型提取接口签名和边界条件，再让旗舰模型只处理复杂断言。两者成本、上下文占用、错误风险不同。B更省，但前提是摘要没丢关键信息。Spotify案例里，超过350行就拦截，本质是给调用加硬门槛；复杂推理不分流，则是承认有些错误代价高。求职者可以准备这样的表述：你不仅会用工具，还能说清在什么条件下选择降级、什么条件下必须保留旗舰模型，以及怎么验证降级结果。但别把“懂成本控制”直接等同于目标岗位的招聘要求，面试时要核实。

面试时怎么问清团队的实际做法？

与其只问“你们用不用AI编程工具”，不如问具体机制：团队是否对工具调用做成本或权限控制？规则是写在提示词里，还是在执行前强制拦截？规则由谁维护、多久复核一次？被分流给廉价模型的结果，由谁验证、验证标准是什么？如果团队目前只靠自然语言提示，没有强制拦截，可以继续问：有没有遇到过规则被绕过、上下文被大文件占满的情况？这些问题不保证有标准答案，但能帮你了解团队对成本、权限和结果质量的实际处理方式。注意，350行拦截只是消息提到的一种做法，不是通用标准。

复杂任务不分流，对能力准备意味着什么？

素材里有个关键边界：编辑文件和复杂推理不分流。测试中小模型漏掉线程安全漏洞，旗舰模型很快抓出。这说明成本控制不能只追求便宜，关键逻辑仍需人工或高成本模型把关。对准备进入这个方向的读者，不要只展示“我用AI写了多少代码”，而要能讲清：你如何把任务分成体力活和推理活，分流后用什么方法验证。如果你有实际记录，例如[实际记录]中把某段重复性代码生成交给小模型，就要说明你如何检查生成结果，而不是只说“效率提升”。如果还没有实际经历，可以用假设场景练习，但不要包装成真实项目。

一个实际可做的小建议：下次读岗位描述时，把“AI工具使用”和“工程效率/成本控制”分开标注，再选一个你真正做过的任务，写下它的降级条件和验证步骤，面试时用来向团队核实做法，而不是背标准答案。