团队知识库进 ChatGPT，不用再先搭一台 MCP 服务器

团队里总有一类问题，问起来一点都不高深。

「这次上线的验收标准放哪了？」

「这个客户的例外规则，到底谁能改？」

「项目看板上那条风险，已经有人处理了吗？」

资料明明都在，答案却还得找一个最熟的人翻文档、翻表格、翻聊天记录。更麻烦的是，大家很快会冒出下一个念头，能不能直接让 ChatGPT 查它，顺手更新它？

以前这件事往往会拐进一条很长的工程路。要找地方部署服务，要把知识库或业务接口包装成 MCP，还要处理登录、权限、连接和后续更新。好家伙，原本只是想让项目看板能回答一句「本周卡在哪」，转眼先开了半个基础设施项目。

OpenAI 刚更新的官方说明，给了一个更短的入口。ChatGPT Sites 现在可以托管 MCP 服务器，并在发布 Site 后生成可安装的插件。你可以把已有的团队手册、项目看板或内部页面放在 Site 里，要求 ChatGPT 或 Codex 为它加上可读、可写的操作，再把它作为插件装回聊天里用。

这里有个容易混淆的地方。MCP 不是另一种聊天窗口，它更像一份能力清单，告诉 ChatGPT「这个地方能查什么、能改什么、每次要传什么参数」。Site 则承接内容和托管。插件负责让这份能力在 ChatGPT 或 Codex 里被发现、安装和调用。

上图是官方给的团队手册例子。看起来像是聊天更聪明了，真正有价值的地方却在后面，答案能回到一个可管理的 Site，工具也能被审查、重新发布和回查。

先别急着加工具，先把边界缩到一件事

最适合拿来试的，不是「让它管理公司所有系统」，而是一件每周都会发生、又总要靠人转发链接的小事。

例如，项目负责人每天会查里程碑、负责人和阻塞项。那第一个版本的工具可以只有两个，读取项目状态，和提交一条待确认的更新。不要一上来就给它删除事项、改预算、通知所有人的权限。后面这些动作当然也能设计，但把它们塞进第一版，只会让测试时不知道问题出在数据、权限，还是提示词。

我比较建议把每个工具先写成一句人话，再决定参数。比如「按项目名查询未完成里程碑」，或「为指定里程碑新增一条风险说明」。如果一句话里已经出现了「顺便」「所有」「自动」，先把它拆开。能被人一句话说清的能力，才比较容易被模型正确调用，也比较容易被团队审查。

再多补一个小约束，给每个查询写好「找不到时怎么回答」。项目名不存在、资料已经过期、调用者没有权限，这三种情况都不该由模型自己猜一个看似合理的答案。让工具明确返回「未找到」「无权访问」或「请到 Site 核对最新记录」，读者不会觉得它更笨，负责维护的人却能少掉一轮真假难辨的排查。

写入操作也一样。不要只看它能不能成功，还要看失败时留下什么。字段缺失时能否指出缺哪一项，重复提交时能否拒绝或提示，提交后能否给回一条可以回到 Site 核验的记录。很多自动化事故不是模型做错了一大步，而是它做错半步以后，没有给人留下一条能追回去的路。

官方给的四步，重点不在第四步发布

官方流程很短。

1. 新建一个 Site，或打开一个自己拥有的 Site。
2. 请 ChatGPT 或 Codex 为它添加 MCP 服务器，说明哪些信息可读、哪些操作可写。
3. 用样例审查工具行为。
4. 由 Site 所有者发布 Site，创建或更新关联插件。

第二步可以从一段很克制的说明开始。别把权限交代给模型猜。

为这个项目看板添加 MCP 工具。
只允许读取项目、里程碑和阻塞项。
新增风险说明时，必须要求项目名、风险描述和负责人。
不要提供删除、批量修改或发送通知的操作。

这段话没有什么神秘技巧，它只是把人本来会写在接口说明里的边界，用更早、更容易讨论的方式摆出来。等工具真的生成后，再看它列出的名称、输入参数和返回内容。看不懂的工具就不要发布，能读懂却范围太大的工具也先缩回去。

审查时可以故意问几个不那么顺手的问题。让它查询一个不存在的项目，让它尝试少传一个负责人字段，再让它请求一个明明不该有写入权的动作。三个结果都应该清楚而克制。出现失败并不丢人，反而说明工具没有把「模型会补全」误当成「系统可以放行」。

有点子牛逼的是，发布在这里不是一次性的收尾动作。官方文档明确提到，改了 Site 上的工具后，需要再次发布，插件里才会出现新动作。这个小细节特别值得记住。很多团队最怕的不是没做出第一版，而是页面已经改了，聊天里还在调用旧能力，大家排查半天以为模型抽风。

安装成功，不等于同事已经有权限

这也是最容易把演示做得很漂亮、上线后马上卡住的一段。

在 Business 和 Enterprise 工作区里，创建、使用、上传、分享以及发布带 MCP 的插件，可能分别由管理员控制。收到插件的同事也不只是点一下安装，他们还需要同时拥有插件和对应 Site 的访问权限，并完成自己的连接流程。

所以测试不要只用创建者的账号。找一位普通协作者，走一遍安装、连接、提问、回查的完整路径。让他问一个应该能回答的问题，再试一个本来不该被写入的问题。前者验证内容和连接，后者验证边界没有被悄悄放大。

如果工具允许写入，回查不能省。官方示例里就要求，做一次样例更新后打开 Site 核对结果。这个动作有点朴素，却比让模型在对话里说一句「已经完成」可靠得多。聊天里的文字是结果提示，Site 里的真实状态才是事实来源。

可以把第一版的验收压成一张很小的清单。

• 工具是否只覆盖一个明确任务，而不是泛泛地「管理知识库」。
• 每个写入操作是否都有必填字段和可理解的结果。
• Site 所有者是否完成了发布，更新后是否重新发布。
• 普通协作者是否同时拿到了插件、Site 和连接权限。
• 每个样例写入是否都在 Site 里重新核对过。

哪些场景先别把它当成万能入口

如果你的数据还没有稳定来源，或者权限模型本身说不清楚，先别急着把对话接进去。聊天只是把入口变短，不会替你补上数据治理。一个连人类都说不清「谁能改、改完谁负责」的系统，交给 MCP 以后只会更快地暴露问题。

同样，涉及高风险写入的流程也别因为「能托管」就默认放开。付款、账号权限、不可逆删除、面向外部的批量通知，至少应该保留明确确认、可追溯记录和人工复核。官方也提醒，安装插件不替代既有授权和工作区访问控制。能连接，不等于应该拥有全部权限。

这次更新真正省掉的，是把已有内容做成可调用入口时的托管和分发摩擦。它没有替团队做数据建模，没有替你决定工具权限，也没有替你验收每次写入。把这三件事留在人手里，反而能让聊天入口变得更敢用。

如果你手头已经有一个团队手册或项目看板，不妨只挑一个高频问题做第一版。你更愿意先让 ChatGPT 查规范，还是先让它更新项目状态？