96.3%的通过率，63%的token消耗下降——这组数字来自Google最新放出的Gemini API编程工具套件。但比数字更耐人寻味的是，Google选择用两套独立系统解决同一个老问题：AI写代码时，训练数据的截止日期让它像个拿着过期地图的导航员。
过期地图与实时路况
大模型写代码有个隐形bug。它的知识停在训练数据截止日期，而API文档每周都在变。Gemini API去年更新了47个版本，模型家族从Pro扩展到Flash、Flash-Lite、Pro Experimental——开发者昨天写的最佳实践，今天可能就过时了。
Google的解法分两条腿走路。第一条腿叫Gemini API Docs MCP，通过模型上下文协议（Model Context Protocol，MCP）把编程代理实时接入官方文档库。不是下载静态快照，是直接读当前版本的SDK、模型参数、配置示例。第二条腿叫Gemini API Developer Skills，一套预置的指令模板，把"用最新版SDK""检查模型兼容性"这类规则写进代理的prompt里。
单独用MCP，代理能查到最新API但可能用错模式。单独用Skills，代理知道模式但可能引用已废弃的参数。Google的测试显示，两者联用时代理在代码生成评测集上的通过率达到96.3%，比裸prompt提升了近40个百分点。更意外的是token效率——正确答案的平均生成长度砍掉63%，相当于同样的API调用次数，你能多处理2.7倍的请求。
MCP：给代理装了个实时浏览器
模型上下文协议（MCP）今年成了AI infra的热门词。简单说，它让代理像人类开发者一样打开浏览器查文档，而不是靠记忆里的残片拼凑答案。
Gemini API Docs MCP的具体实现很直白：代理发起调用→MCP服务器返回当前文档的结构化片段→代理基于实时信息生成代码。对比传统RAG（检索增强生成，Retrieval-Augmented Generation）方案，MCP的优势在于协议标准化——同一套接口可以对接文档、数据库、甚至内部API，不需要为每个数据源写定制爬虫。
Google放出的评测数据里有个细节：MCP单独使用时通过率约78%，但错误集中在"知道有新功能但用错语法"。这暴露了纯文档查询的局限——知道有什么，不等于知道怎么用。
Skills：把经验写成肌肉记忆
Developer Skills解决的是"怎么用"的问题。它不是让代理去查，而是直接把最佳实践写进系统提示里。
Google提供的Skills模板包含三类内容：版本兼容性检查清单（比如"确认目标模型支持json_schema模式"）、常见陷阱规避（比如"不要混用v1beta和v1的端点"）、以及性能优化建议（比如"批量请求优先用batch_embed_content而非循环调用"）。这些规则来自Google内部支持团队过去一年处理的12000+开发者工单。
Skills单独使用的通过率约82%，但错误类型翻转——代理能写出语法正确的代码，却可能调用两周前刚废弃的参数。这解释了为什么Google坚持两套系统并行：MCP补信息 freshness，Skills补决策质量。
联用背后的产品算盘
96.3%这个数字本身有语境。Google的评测集覆盖的是Gemini API常见任务：文本生成、嵌入、函数调用、结构化输出。不涉及多模态理解或复杂agent编排——那些场景的错误率曲线会更陡峭。
但token效率的提升是真实的。63%的降幅来自两个因素的叠加：MCP减少了代理"猜测"参数所需的试错轮次，Skills减少了生成后修正所需的迭代次数。对于按token计价的API调用，这直接换算成成本优势。
Google把两个工具都开源在ai.google.dev，但配置门槛不低。MCP需要本地运行Node服务，Skills需要手动编辑YAML文件。社区里已经有开发者抱怨："解决AI写代码的问题，需要先写一堆代码来配置工具。"
开发者社区的撕裂反应
Hacker News上的讨论分成了两派。一派认为MCP+Skills是"终于有人把RAG做成了协议层"，另一派质疑"为什么不让模型自己学会查文档，而要人类写Skills模板"。
前者的代表观点是：「MCP的价值不在Gemini这一个API，而在于它证明了上下文协议可以标准化。今天接Google Docs，明天就能接Stripe、AWS、任何有文档的服务。」后者的反驳更尖锐：「Skills本质上是把人类工程师的经验翻译成prompt工程，如果模型足够强，这些规则应该被内化而不是外挂。」
Google自己的工程师在回复中承认，Skills是"当前模型能力的妥协"。Gemini 1.5 Pro的上下文窗口够大，但长上下文不等于有效利用。把关键规则前置到system prompt，比指望模型在128K token里自己发现模式更可靠。
一个被反复提及的对比是OpenAI的函数调用方案。OpenAI选择把工具定义结构化地交给模型解析，Google则把工具使用模式预写成指令。两种路线没有绝对优劣，但反映了不同的产品哲学：OpenAI赌模型能力持续爬坡，Google赌开发者需要更多可控性。
96.3%之后的问题
通过率数字漂亮，但生产环境的考验才刚开始。评测集里的任务是单轮代码生成，真实开发涉及多轮调试、跨文件引用、与现有代码库的兼容。Google的文档里埋了一句免责声明：「高通过率不代表零幻觉，关键业务逻辑仍需人工审查。」
更现实的瓶颈在生态。MCP协议需要服务端支持，目前Google Docs MCP是官方维护，第三方API的MCP适配器质量参差不齐。有开发者反馈，接了一个社区版的Slack MCP，结果返回的文档片段是2023年的旧版，比模型训练数据还老。
Skills的扩展性也是个问号。Google提供的模板针对Gemini API优化，迁移到其他云服务需要重写规则集。社区里有人在尝试用LLM自动生成Skills模板，但这又引入了"用AI解决AI工具配置"的套娃问题。
Google的下一步动作值得关注。内部消息显示，团队正在实验把Skills的生成过程也自动化——让代理基于MCP返回的文档，自动提炼出最佳实践规则。如果跑通，人工写YAML的阶段可能跳过，但这也意味着把更多控制权交给模型自己。
当96.3%的通过率成为基准线，开发者会开始追问：剩下的3.7%错误分布在哪些场景？是边缘case还是核心路径？Google的评测报告里没有细分数据，但社区已经有人开始自建测试集验证。一位独立开发者在Twitter上晒了他的初步结果：函数调用场景通过率91%，结构化输出场景通过率88%——均低于官方数字，但样本量有限，结论仅供参考。
工具链的成熟总是滞后于模型能力的跃迁。MCP+Skills组合解决的是2024年的痛点，而Gemini 2.5 Pro的代码能力已经在部分评测中追平Claude 3.5 Sonnet。当模型本身更少犯错，外挂的文档查询和规则模板会不会变成技术债？
或者换个角度问：如果AI编程的终极形态是"说出需求就拿到可运行代码"，中间需要经过多少个"先配置MCP再调优Skills"的过渡阶段？
热门跟贴