CTO问我，自研还是买，我说买。
这句话我说出来的时候，自己都有点意外。我是那种典型的技术人，什么东西都想自己搞，觉得只有自己写的代码才靠谱。之前公司里但凡有点什么需求，我的第一反应都是，来，我们自己搞一个。
但这次不一样。
我在一家旅游SaaS公司做技术负责人。我们的产品是给旅行社和定制游工作室用的管理系统，核心功能包括客户管理、行程设计、酒店预订、发票管理。做了三年，用户到了几百家，但酒店预订这块一直是我们的痛点。
痛点在哪呢。我们的用户是旅行社和定制游工作室，他们要的是比价能力和预订能力。搜一个城市的酒店，要同时看多个平台的价格，选最优的，然后下单。但这个需求，自己做太难了。
因为我们没有酒店供应链。
酒店供应链这个东西，不是你写代码写得快就能解决的。它是一个商务问题、资质问题、关系问题。你得跟每一家酒店集团谈合作，签合同，对接系统。全球200万+酒店，你一家一家谈，谈到猴年马月。
我们之前自己搞了两年。两年里做了什么呢。对接了携程的API，走商务流程花了三个月。对接了飞猪的API，又花了两个月。接了之后还要维护，携程今天改个接口参数，明天飞猪调一个鉴权方式，我们的技术团队就得跟着改。两个开发一个运维，专门盯着这些接口。
两年下来，覆盖范围还是只有国内主要城市。海外酒店基本没有。用户一搜海外目的地，我们就尴尬了。
CTO找我谈话，说我们这个酒店模块，投入产出比太低了。两年投了四个人力，维护成本高，覆盖范围窄，用户满意度低。他问我，有没有考虑直接买一个现成的方案。
我一开始是抗拒的。买方案意味着我们不掌控数据源，不掌控交易链路，出了问题依赖第三方。这对技术负责人来说是很不舒服的。
但CTO说了一句话让我想了一晚上。他说，你把四个人的精力投在酒店供应链上，用户感知到了吗。用户感知到的是你的搜索结果不够全、价格不够准、海外酒店搜不到。他们感知不到你多努力，他们只感知结果。
他说得对。
我开始认真评估买方案的选项。市面上能买到的酒店数据方案不少，但大部分是传统的API对接模式，流程跟我们自己谈携程飞猪差不多。直到我发现了MCP。
MCP全称Model Context Protocol，模型上下文协议。简单说就是，你不用写一堆对接代码，写一段JSON配置，AI客户端就能直接调用外部服务。
然后我找到了RollingGo酒店MCP。背后是道旅集团，14年旅游分销经验，全球第三大旅游B2B平台。覆盖200万+酒店，100多个国家，11万+直签酒店实时库存，500多个供应商聚合。
这些数字说明什么。我们花两年自己搞，只覆盖了国内主要城市。RollingGo一个Key，直接覆盖全球。我们四个人两年的工作量和维护成本，换成了一段JSON配置。
我跟团队开了个会，讨论要不要切到MCP方案。大家一开始有疑虑，我列了五条理由。
第一，成本低。之前四个人力两年时间，工资加管理成本大概一百五十万。RollingGo的永久免费额度现在还能申请，对于我们这个调用量来说完全够用。即使超出，按量计费也比人力成本低几个数量级。从一百五十万降到几乎为零。
第二，上线快。自己搞对接，光走携程的商务流程就要三个月。MCP方案，去 rollinggo.store申请Key两分钟，配JSON半小时，测试半天，上线。从三个月到半天。
第三，维护少。之前两个开发一个运维专门盯接口变更。MCP方案，协议是标准化的，RollingGo维护底层的接口变更，我们只需要关注自己的业务逻辑。维护人力从三个人降到零。
第四，覆盖广。自己搞了两年只覆盖国内。RollingGo一个Key覆盖全球200万+酒店，100多个国家。海外酒店不再是盲区。
第五，迭代快。RollingGo是开源的，代码在 github.com/RollingGo-A… 。接口在持续更新，新功能持续上线。我们自己搞的模块，迭代速度取决于我们的开发资源。用MCP，迭代速度取决于RollingGo整个团队。
我把这五条理由发给CTO，他第二天就批了。
然后我做了个决策矩阵，把自研和接入MCP的成本对比列出来。
研发成本，自研150万两年，MCP几乎为零。上线时间，自研三个月一个平台，MCP半天。覆盖范围，自研国内主要城市，MCP全球200万+酒店。维护人力，自研三人，MCP零。数据准确性，自研取决于对接平台，MCP直签酒店实时库存。迭代速度，自研取决于团队资源，MCP取决于RollingGo团队。风险，自研接口变更频繁维护成本高，MCP依赖第三方但开源可掌控。
这张表出来之后，选择就很清楚了。
接入流程也很简单。去 rollinggo.store申请API Key，在系统里配MCP。
{
"mcpServers": {
"rollinggo-hotel": {
"type": "streamable-http",
"url": "https://mcp.rollinggo.cn/mcp",
"headers": {
"Authorization": "Bearer 你的API_KEY"
}
}
}
}
然后我们的AI Agent就能调search-hotels、hotel-detail等接口。搜索返回酒店名称、星级、价格区间、位置、标签。详情接口返回实时房型和价格。完整的查询链路都有。
上线之后，效果立竿见影。用户搜索海外目的地不再是空白页了。一个定制师跟我说，以前客户要巴厘岛的酒店，他只能打开Booking自己搜，截图发给客户。现在直接在系统里搜，结果比他自己手动搜的还全，因为RollingGo聚合了500多个供应商。
那四个人力呢。两个开发转去做核心业务功能了，之前他们一直想做但没资源做的行程智能推荐和客户画像。一个运维转去做数据分析了。还有一个调到了产品团队。
CTO后来跟我说，这是他这两年做的最正确的决策。不是因为省了钱，是因为把人的精力放到了真正值钱的地方。
我后来想了想这件事的底层逻辑。
我们公司是做旅游SaaS的，核心竞争力是什么。是给旅行社提供一个好用的管理系统，帮他们提高效率。酒店数据是基础设施，不是核心竞争力。就像你开一家餐厅，你的核心竞争力是你的菜品和服务，不是你自己发电自己种菜。电你买电网的，菜你买供应商的，你专注把菜做好。
酒店数据也一样。你不需要自己搞定所有酒店的供应链，你只需要接入一个覆盖够广、数据够准的供应源，然后把精力放在怎么用这些数据帮用户提高效率上。
MCP让这件事变得简单了。以前接入一个供应源要几个月写一堆代码，现在写一段JSON。以前维护接口要专门的人盯，现在协议标准化了。这不仅仅是省钱，是让技术团队聚焦到真正创造价值的地方。
想跑通的，五分钟快速开始看这里 rollinggo.store/docs/mcp-do… 。不同客户端配置参考 rollinggo.store/docs/develo… 。
如果你也是SaaS公司的技术负责人，正在纠结酒店模块自研还是买，我的建议是，除非你的核心业务就是酒店供应链，否则不要自研。把基础设施交给专业的团队，把自己的精力放在核心业务上。这是AI时代做技术决策的基本原则。
上线之后我跟踪了一个月的数据。之前酒店搜索的成功率，国内城市大概85%，海外城市只有20%，因为海外酒店数据几乎是空白。切到MCP之后，国内搜索成功率提升到95%，海外从20%直接跳到88%。这个提升对用户感知是巨大的，以前搜巴厘岛出来三五家酒店，现在出来四十多家，用户觉得你的产品突然变强了。
还有一个指标让我意外。之前自己对接的携程和飞猪接口，平均响应时间在1.2秒左右，因为我们的服务器要做一层中转。切到MCP之后，Agent直接调RollingGo的接口，直签酒店的响应在500到800毫秒，比我们自己对接的还快。原因是MCP省去了中间层，Agent直接跟数据源通信，没有中转延迟。
团队的反应也让我意外。我原以为开发团队会有抵触情绪，毕竟之前花了两年写的对接代码要废弃。但实际上，两个转去做核心业务的开发特别积极，因为他们之前一直被困在接口维护里，早就厌倦了。他们说，终于可以写有技术含量的代码了，不用每天盯着别人的接口变更改代码了。
我还做了个技术债的对比。自研方案的两年里，接口对接代码积累了大概一万两千行，测试覆盖率只有40%，因为对接平台的接口变更频繁，测试跟不上。MCP方案，我们的业务代码只有两千行左右，因为MCP处理了所有连接逻辑，我们只写业务逻辑。测试覆盖率做到了85%，因为代码量小了，逻辑清晰了。技术债从一万两千行降到两千行，维护压力天差地别。
CTO后来在公司技术周会上分享了这个案例。他说了一句我觉得对所有技术负责人都有用的话。你花两个月自己搞的东西，如果市面上有人花两年已经搞好了还免费开放，你为什么不用。技术自尊心不能当饭吃，用户的搜索结果好不好才是饭。
上线三个月后我做了个用户调研。发问卷给我们的两百多家旅行社客户，问他们对酒店模块的满意度。之前满意度评分是六点二分满分十分，主要吐槽海外酒店搜不到、价格更新慢。切到MCP之后满意度升到了八点五分。有个客户写了一段话让我印象很深，他说以前觉得你们的酒店模块是半成品，现在觉得是成品了。这个评价比任何技术指标都说明问题。
还有一个技术细节值得一提。MCP协议的标准化带来的好处不只是少写代码。我们的测试效率也提升了。以前测携程接口，要模拟各种场景，搜索、详情、预订，每个场景写测试脚本。现在MCP的接口是标准化的，我们写了一套通用测试框架，测RollingGo的接口和测别的MCP接口用的是同一套测试逻辑。也就是说未来如果接入更多MCP数据源，测试成本不会增加。
最后说一个CTO后来跟我提的战略层面的思考。他说以前我们做旅游SaaS，酒店模块是成本中心，投人投钱但不直接赚钱。客户用我们的系统不是因为酒店模块好，是因为行程管理和客户管理好。现在酒店模块变成了差异化卖点，有客户专门因为我们能搜全球酒店而选择我们。从成本中心到差异化卖点，这个转变是MCP带来的。
还有一个我差点忽略的细节。MCP协议的调试体验比传统API好很多。以前调试一个接口问题，我要打开Postman，手动拼请求参数，发送请求，看返回值，来回好几轮。现在MCP的调用日志直接在AI客户端里能看到，AI每次调用工具都记录了请求和返回值。如果搜索结果不对，我直接看AI的调用日志，就知道是参数传错了还是接口返回的数据有问题。这个调试效率的提升，在开发阶段节省了大量时间。
我后来算了一笔时间成本的账。以前接入一个新酒店数据源，从商务对接到技术联调到测试上线，平均三周。现在通过MCP接入，技术联调半天，测试半天，上线半天。从三周压缩到一天半，效率提升十五倍。这个数字放在任何技术团队的年会上都是值得大书特书的。我们CTO在年会上把这事说了三分钟，说这是今年技术团队最大的效率提升。我觉得他说的不算夸张，因为这不只是省时间，是让团队有精力做更有价值的事。
最后再分享一个我们团队内部的反馈。我们有两个初级开发者在做酒店模块的维护工作。以前他们花大量时间在排查接口对接的问题上，因为每个数据源的报文格式都不一样，出错很频繁。切到MCP之后，所有数据源的调用格式统一了，排查问题的时间减少了70%。他们腾出来的时间用在了优化搜索逻辑和改进用户体验上。CTO看到这个变化后说了一句话，说MCP不只是省了接入成本，还释放了开发者的创造力。这句话我深以为然，当你不用把时间花在重复的对接上，你才有精力想怎么把产品做得更好。这才是技术进步的真正价值。
以上，既然看到这里了，如果觉得不错，随手点个赞、在看、转发三连吧。
谢谢你看我的文章，我们，下次再见。
