Google Sheet 不只是表格：SheetRelay 如何把数据变成 MCP 与 REST 后端
很多小型网站、内部工具和自动化流程，并不需要一套复杂的数据库。真正麻烦的是：数据已经在 Google Sheets 里维护，但 AI 助手、网页和脚本都需要稳定地读取、写入这些数据。把表格导出、复制到数据库，再维护同步任务，往往比业务本身更费时间。
SheetRelay 的思路很直接：连接一个 Google Sheet，把工作表暴露成 MCP 服务和 HTTP API。这样，Claude、ChatGPT、Cursor 等能通过 MCP 访问数据，网站和自动化工具则可以使用普通的 REST 请求；原始表格仍然留在自己的 Google Drive 中。
它解决的不是“如何存数据”，而是“如何复用已有数据”
从官网演示看，连接后可以为某个 tab 生成独立地址。例如订单表可以通过类似下面的请求筛选状态：
curl "https://api.sheetrelay.com/acme/orders-2026/orders?status=open"
返回结果是 JSON，而不是整张表。对网站来说，这足以支撑订单列表、菜单页或 RSVP 页面；对 AI 助手来说，表格又可以作为一个受权限控制的数据源。SheetRelay 还展示了 POST、PATCH 等写入场景，因此它并非只读的导出工具。
关键点在于，接口与表格的映射由连接过程生成，不要求使用者先设计数据库 schema。官网给出的流程是：选择 Google Sheet，检查哪些列会被暴露，再上线地址、密钥和连接片段。新 tab 默认只读，读取、添加、修改、删除可以分别控制。
MCP 连接适合什么场景？
如果团队已经在 Claude 或 Cursor 中工作，MCP 比手工复制 CSV 更自然。助手可以回答“哪些订单仍然是 open”，也可以在获得写权限后新增一行。这里的安全边界不能省略：读权限和写权限必须分开，内部备注、利润等列应当隐藏，面向不同应用使用不同的 key。
SheetRelay 官网特别强调了列级和行级限制，以及可撤销的 key。隐藏列不会出现在响应和助手读取到的字段描述中；调用也会记录使用了哪个 key，以及为什么被拒绝。这种设计比把一个拥有完整表格权限的 API key 塞进前端更适合生产环境。
还要注意一个容易忽略的事实：助手看到的工具描述来自列名，而不是单元格内容。这样可以降低“表格某个单元格写了一段指令，助手就把它当命令执行”的提示注入风险。不过，权限配置仍然要由人审查，不能把安全性全部交给产品默认值。
REST API 更适合网站和自动化
对于网站、表单、Zapier、Make 或 n8n，普通 HTTP 接口通常比 MCP 更容易接入。一个菜单页可以直接读取 dishes tab；一个报名页面可以把访客提交的数据写回 RSVP tab；内部运营页面则可以按需更新订单状态。
这种架构的优势是没有第二份数据库：改动在 Google Sheet 中立即可见，原有的筛选、协作和人工编辑习惯也能保留。官网还展示了“函数化”能力：如果表格本身包含报价公式，可以把输入单元格和输出单元格包装成可调用函数，让表格继续负责计算，而不是在代码里重写一套可能已经被团队验证多年的公式。
但它并不适合所有系统。高并发交易、复杂关联查询、严格事务和大量历史数据，仍然应该交给真正的数据库。表格更适合轻量后端、内部工具、原型、个人网站，以及数据量和并发都可控的自动化流程。
上手时建议先做三项检查
第一，按应用拆分 key。网站只给它需要的 tab 和列，AI 助手不要默认拥有删除权限。第二，先用只读模式跑通查询，再逐步开启 add、change 等写操作。第三，检查敏感列是否真的没有出现在响应、工具描述和错误信息中。
如果你的团队已经把业务数据维护在 Google Sheets，SheetRelay 提供了一条比“再建一个后台”更轻的路线：同一份数据同时服务于人、AI 和代码。它的价值不在于把表格包装成炫目的 AI 产品，而在于减少同步层，让权限、接口和现有工作习惯落在同一个可审查的边界里。
发布前最好先把一个低风险 tab 接入，观察查询日志和权限拒绝记录，再逐步扩展到真实业务数据。