Ronacher炮轰MCP：LLM编程死胡同，代码生成才是出路

知名开源Web框架作者Ronacher发表博客，尖锐批判Model Context Protocol (MCP) 是“死胡同”，认为其缺乏真正可组合性且过度依赖推理，导致可扩展性差，不适合自动化场景。他力推“代码生成 + 评审 + 批量运行”的模式，强调其在可靠性、效率和可审查性方面远胜MCP，并指出当前LLM在复杂编程任务中存在的深层局限。

对MCP（Model Context Protocol）的批判

• 核心观点: Ronacher不是MCP的忠实拥趸，认为其宣传言过其实，是“死胡同”，尤其不适合无推理自动化。
• 主要问题:
  • 不具备真正的可组合性，大部分“组合”依赖模型推理完成。
  • 对上下文依赖过重，消耗大量推理上下文，不如直接写代码高效。
  • 可扩展性差，难以自动化重复性任务，调试困难。

代码生成：可扩展自动化的可行方案

• 核心理念: 提出“代码生成 + 评审 + 批量运行”的Agentic Coding场景下可扩展方式。
• 优势:
  • 可靠性与确定性: 可审查代码逻辑，确保计算结果正确，避免“幻觉”。
  • 成本与效率: 推理成本不随任务量成倍增长，脚本可复用，一次生成可运行上百次。
  • 自动化价值: 适合反复出现的任务，实现大规模、高效、正确的自动化。

实际应用案例与对比

• 博客格式转换: 作者使用LLM生成代码，将reStructuredText转换为Markdown，通过AST转换、HTML差异比较等方式，实现了可审查、可信赖的自动化过程。
• Playwright工具: 批评MCP工具如Playwright在远程控制浏览器时，每一步都需要推理，难以消除不确定性；而通过LLM生成Playwright Python脚本，可实现无推理的顺序执行，运行更快、出错更少。

LLM在编程场景中的局限性

• 上下文不足: 对于大型代码库，LLM难以理解整个项目的全貌，上下文窗口太小，无法处理模块间连接关系或复杂执行流程（如多进程、并发）。
• 缺乏“品味”: LLM生成的代码是统计意义上的平均值，可能难以维护、理解，缺乏资深工程师追求的优雅、简洁和高可维护性。
• 推理依赖问题: 当前大模型在Coding工程场景下通过推理和工具调用完成，但推理过程中的上下文消耗和不确定性，导致MCP等方式无法完美解决生产环境问题。