面试时怎么问出团队在工具集成上的真实路线？

消息提到，有作者认为对大多数集成来说，MCP 比 CLI 更好，理由是模型在工具调用方面已经强了很多，可以延迟加载工具，而且 MCP 现在是无状态的。这是个人观点，不是行业结论，但它给面试提供了一个有用的追问角度。

不要直接问“你们用 MCP 还是 CLI”，这个问题太抽象，对方容易给一个标签就结束。换成问最近一次集成任务：工具是怎么暴露给模型的？参数怎么设计？会话状态放在哪一侧？从具体做法反推路线，比听名词可靠。

如果对方说工具是延迟加载的、服务端不保存会话状态，那大概率更接近 MCP 思路；如果说靠命令行脚本串起来、状态写在本地文件或环境变量里，那更接近 CLI 或混合做法。两种回答都正常，关键是听他们有没有讲清楚为什么这么选。

如果团队走 MCP 路线，我的项目经验该怎么讲？

素材里有一条具体建议：如果需要组合或过滤数据，可以给 MCP 工具加上 query 之类的参数。这句话可以直接变成你讲项目时的落点。

假设场景：你之前做过一个内部数据查询脚本，别人调用时只能拿全量结果。你可以这样表述——后来我把查询条件抽成参数，让调用方按需过滤，减少了无效数据传输。这是思考方法，不是让你编造一段 MCP 开发经历。

讲经验时，重点放在三件事：工具接口的参数怎么设计、数据组合与过滤放在哪一层、怎么让调用方更稳定地拿到结果。只讲“我写过多少脚本”说服力有限，因为脚本数量不等于接口设计能力。

如果团队还在用 CLI 或混合路线，我该怎么判断是否值得去？

素材认为 MCP 比 CLI 更适合大多数集成，但并没有断言 CLI 会被完全取代。所以路线本身不是唯一标准，别把“用 CLI”直接等同于团队落后。

更值得确认的是：团队是否清楚自己的集成痛点在哪，有没有迁移或演进的计划，以及你在这条路线上能积累什么可迁移的能力。如果对方说“一直这么用，没想过为什么”，那要谨慎；如果对方能讲清楚当前约束和下一步打算，即使暂时用 CLI，也值得考虑。

面试前可以准备一个小练习：挑一个你做过的集成任务，用两分钟讲清楚工具怎么暴露、参数怎么设计、状态怎么管理。讲完再对照目标岗位的描述，看哪些点还需要向对方确认。这比背路线名词更能帮你在对话里站稳。