在与AI协作编码时，命令行工具（CLI）通常优于为AI定制的接口（MCP）。因为CLI是AI模型的“母语”，它提供了更高的可靠性、可预测性和控制力。MCP作为一层抽象，虽在某些场景下有用，但往往带来不必要的复杂性和故障点。
原帖作者最近把开发工作流里所有的MCP都换成了CLI，感觉再也回不去了。
他曾以为MCP是“正确答案”，但实际用起来却尽是挫败感：参数错误、授权随机失效、执行超时。感觉每一步都隔着一层毛玻璃，既缓慢又不稳定。
切换到CLI后，一切豁然开朗。Claude处理它们时，就像在说母语。毕竟它的训练数据里塞满了无数的shell脚本、文档和GitHub议题。它天生就懂`gh`的参数和`vercel`的边界，能组合出他得花20分钟才想明白的指令。使用MCP时他感觉在限制它，换成CLI后，只需要让开路。
有观点认为，CLI的胜利在于其可预测性。`gh pr list --json`返回的就是此刻GitHub的真实状态，童叟无欺。而MCP调用失败时，你面对的是一个状态不明的黑盒。CLI的组合也是可审计的，`ripgrep | jq | gh`的数据流一目了然。当自动化任务在深夜静默失败，CLI会留下明确的错误日志，而MCP的故障则可能是个谜。
当然，这不是说MCP一无是处。在企业环境中，它为非技术人员提供了方便的入口，也更利于统一的权限和凭证管理。
更有意思的是，讨论中出现了一个元认知：如果某个服务没有CLI怎么办？让Claude自己写一个。有网友分享了用一个下午让Claude为Google Docs构建复杂CLI的完整思路。这或许才是真正的终局，工具本身也成了生成对象。
说到底，这是个控制权与信任度的选择。
