先分清两种“用得多”

消息提到，Cursor 发布 Projects，不再让人直接盯着一个 Agent 写代码：中间放了一个协调 Agent，用户告诉它项目要做什么，研究、拆解、开发和测试由它分给不同 Subagents，这些 Agent 共享同一套项目上下文。

对求职者的启发是：面试时“我们 AI 工具用得很深”这句话，可能指两种完全不同的团队。一种是每个人各自开一个 Agent，写自己的模块，提效发生在个人层面；另一种是任务被拆给多个 Agent，上下文在它们之间传递，协作方式本身被重新设计。前者你只要会用工具就能融入，后者你要适应“交接”比“手写”更重要的节奏。

三个问题问出协作方式

第一问任务分配。可以问：一个中等规模的功能，从需求到合并，中间会拆成几段？谁决定怎么拆？如果对方回答“每人认领一块”，那更接近各自提效；如果回答“先由一个协调角色拆解，再分给不同执行单元”，就更接近多 Agent 协作。

第二问上下文共享。素材里说，前面的 Agent 研究明白代码架构、测试方法和团队习惯后，后面的 Agent 可以直接接着干。你可以顺着问：新加入的人或新开的 Agent，怎么拿到项目约定？是读文档、读规则文件，还是靠口头同步？答案越具体，说明协作越成型。

第三问结果验收。多 Agent 协作最容易出问题的地方不是生成，而是验收。可以问：多个执行单元产出的改动，谁负责合并前的检查？测试失败时，是退回给原执行单元，还是由协调者重新分派？

把数字当提问线索，不当预期

原文称主要使用 Projects 的工程师，合并 PR 的数量达到了原来的 6 倍。这个说法可以成为面试里的提问线索，但不宜直接当作自己入职后的产出预期。你可以问：这个数字对应的统计口径是什么？是个人对比还是团队对比？样本多大？验收标准有没有同步变化？

如果对方答不上来，也不必当场质疑，可以把它理解为“团队还在摸索度量方式”。这本身就是一个信号：协作方式可能尚未稳定，你进去后要承担一部分流程定义的工作。

准备案例时，优先准备跨角色交接的例子：你怎么把上下文交给下一个人，怎么定义“做完”的标准，怎么处理交接后的返工。模拟面试里可以这样练：假设一个需求被拆成研究、实现、测试三段，你只负责中间一段，你会向上一段要什么信息，向下一段留什么信息？

最后给一个可做的小建议：面试前，把目标团队近期的公开技术分享或招聘描述里关于协作流程的表述抄下来，面试时逐条对照提问，看它说的是个人提效还是流程协作。