开发工具

参考资料 MCP is dead. Long live the CLI - EJ Holmes Hacker News Discussion - When does MCP make sense vs CLI? 前言 最近 Hacker News 上有一篇热门文章《MCP is dead. Long live the CLI》，引发了关于开发工具接口的热烈讨论。这篇文章直指 MCP（Model Context Protocol）协议正在走向消亡，并呼吁回归传统的命令行工具。 读完全文后，我觉得这个观点虽然激进，但确实反映了一些实际问题。让我来总结一下核心观点。 核心观点：MCP 并不优于 CLI 作者认为，当 Anthropic 推出 MCP 时，整个行业盲目跟风，各家公司争先恐后部署 MCP 服务器，只为证明自己是"AI 原生"。但实际上，MCP 提供的所谓"更清洁接口"，在实践中并没有带来真正的改进。 问题一：LLM 不需要新协议 LLM 经过大量训练，已经懂得如何使用命令行工具。给它们一个 CLI 和文档，它们就能正常工作了。MCP 承诺的抽象接口，实际使用时还是要写文档说明工具的功能、参数和使用场景——这和直接用 CLI 没有本质区别。 问题二：CLI 更易于调试 用 CLI 工具时，如果出现意外情况，我可以直接运行同样的命令查看输出。但用 MCP 时，工具执行只在 LLM 对话内部，出问题时要通过 JSON 传输日志排查，调试反而更复杂。 问题三：CLI 的可组合性更强 ...

前言 在 AI 辅助编程时代，一个关键问题浮现：AI 助手会如何影响开发者的工具选择？ Amplifying AI 团队进行了一项开创性研究，他们让 Claude Code 处理 2,430 个真实代码仓库，观察它在没有任何工具提示的情况下如何选择技术工具。 这项研究的规模和深度令人印象深刻：3 个模型、4 种项目类型、20 个工具类别、85.3% 的提取率。研究涉及 Sonnet 4.5、Opus 4.5 和 Opus 4.6 三个模型，覆盖从 CI/CD 到实时开发的广泛场景。 核心发现：倾向自建，而非引入现成库 研究最令人震惊的发现是：Claude Code 更倾向于自己构建解决方案，而不是推荐现有的开源库或第三方服务。 在 20 个类别中，有 12 个类别（60%）Claude 选择"自定义/DIY"而非成熟工具。总计有 252 次自定义实现，超过任何单一工具的推荐次数。 典型案例 特性标志（Feature Flags）： 预期：推荐 LaunchDarkly 等现成服务 实际：自己构建配置系统，使用环境变量 + 百分比控制功能开关 Python 认证： 预期：推荐 Auth0、Passport.js 等库 实际：从零编写 JWT + bcrypt 实现（100% DIY 比例） 缓存： 预期：推荐 Redis、Memcached 实际：实现内存 TTL 包装器 这种倾向在以下领域尤为明显： 特性标志：69% DIY Python 认证：100% DIY 可观测性：22% DIY 整体认证：48% DIY 默认工具栈：JavaScript 生态的主导地位 当 Claude Code 确实选择推荐工具时，它的偏好非常明确： ...