面试时怎么问清团队集成走MCP还是CLI？

有开发者公开表示，MCP在多数集成场景中优于CLI，并建议构建自定义harness时使用MCP工具，称自己的meta harness所有外部工具都走MCP。消息提到，这是他的个人偏好，不是行业统一结论，也没有说明哪些团队正在采用。对求职者的价值在于：面试时别只问“你们用不用MCP”，而要问清当前集成方式、是否有迁移计划、工具调用由谁维护。

同一件“让模型调用外部工具”的任务，两种做法的工作内容差别很大。CLI路线通常围绕脚本封装、进程调用和日志排查；MCP路线则更多涉及工具注册、参数定义和连接维护。你可以这样问：“目前外部工具接入主要走哪条路？是历史遗留还是主动选型？”如果对方回答“正在从脚本迁到MCP”，说明入职后可能同时维护两套，学习成本要提前算进去。

我的CLI经验还算数吗，转MCP要补什么？

算数，但要看目标团队的重心。CLI经验在脚本、调试、运维场景仍有价值，尤其是排查超时、权限和输出解析问题时，这些手感不会白费。但如果团队以MCP为主，你需要提前了解工具注册、参数过滤等基本概念，避免入职后被动。

面试时可以追问：“工具调用出错时，谁负责定位？是平台组还是业务开发？”这个问题能帮你判断岗位边界。如果对方说“工具由平台统一维护，你只写业务逻辑”，那你的学习重点在接口约定；如果说“每个开发自己接工具”，那你要准备好承担连接层的调试工作。两种都合理，但匹配度不同。

选offer时，技术选型该占多大权重？

技术选型是判断团队工程成熟度和学习机会的信号之一，但不应只看这一点。素材中的偏好属于个人观点，不能推导出“所有团队都会转向MCP”或“CLI岗位会消失”。更实际的做法是：把技术选型、岗位职责、团队规模和自身长期方向放在一起看。

假设你拿到两个offer：A团队用CLI脚本，职责清晰、迭代稳定；B团队正在试点MCP，职责模糊但接触面广。如果你更看重确定性，A可能更合适；如果你愿意承担探索成本，B的学习曲线更陡。没有标准答案，只有你能否接受入职后前几个月的实际工作内容。

一个可做的小建议：面试结束前，请对方用一句话描述“这个岗位日常最花时间的三件事”。如果其中两件都和你没做过的东西有关，就要认真评估学习成本，而不是只看技术名词是否热门。