技术 · 入门
MCP 到底该怎么接，才不会把自己接进坑里？
先接一个、只读起步、写操作留人工点头
接 MCP 的门槛比大多数人以为的低 —— 一个能跑的 server 大约 80 行，从零到一个能干真活的 agent 大约一小时。但它有一个反直觉的地方：MCP server 不是「AI 代码」，它是一个普通服务端，只是客户端不寻常 —— 你暴露的每个函数都会被一个语言模型决定何时、以什么参数调用。这一页给两样东西：一张七步接入纪律（挑一个你已在用的应用 → 只接一个连接器 → 优先官方 server → 点允许前读权限 → 凭据可撤销 → 从只读开始 → 写权限刻意地加、邮件 / 发布 / 删除三类动作前留人工批准），以及一条最容易忽略的边界：模型能决定「调什么」，决定不了「该不该」—— 所以每个工具自身必须把边界焊死。最后附一个反例：教程里那个「不该上线的工具」，是怎么从有用变成远程代码执行漏洞的。
方法 · 一图看懂
1
先分清三类能力 — tools 干活 · resources 给上下文 · prompts 给可复用模板，用途混了就出事
2
只从一个连接器开始 — 从你日常已经住在那里的一处接（文件 · 收件箱 · 任务），不要一次开五个
3
从只读开始 — 先问「列出我最近 5 个文件」「总结这份文档」，看几轮它要什么
4
写权限刻意地加 — 放行具体任务；邮件 / 发布 / 删除三类动作前保留人工点头
5
把边界焊在工具里 — 参数不许直接拼进命令与路径；不读请求的调用者，比人更容易踩进洞里
原理 · 为什么有效
MCP 真正改变的不是「模型更聪明」，而是让 AI 够到你真实的东西 —— 文件 · 收件箱 · 项目 · 数据库。它不取代 API / SDK / 数据库，只是把其中一部分能力用一套共同的接法暴露给 AI 应用。为什么必须按顺序放宽权限：接上之后，模型会自己决定何时调用、传什么参数，而这个决定过程没有人读一遍请求 —— 这与「机器可以在没人读请求的情况下触发」的任何 API 是同一套纪律。一次只加一个连接器不是保守，是让「它到底做了什么」这件事一直处在你能看懂的范围里；同时开五个，出问题时你分不清是谁干的。
适用场景
适用：想让 AI 帮你操作真实文件 / 收件箱 / 项目的人 · 已经在用某个支持 MCP 的客户端（Claude · ChatGPT 开发者模式 · Gemini CLI 等）但还没接过东西的人 · 想搞清「连接器到底给了我什么权限」的人。
⛔ 不适用：以为接得越多越好 —— 一次开五个连接器，等于把自己数据的五个入口同时交给一个不读请求的调用者。
⚠️ 前提：愿意先只读、观察几轮，再逐步放宽。
自测 · 5 问
我能不能说出「我现在接了几个连接器，各自能读什么、能写什么」？说不出，说明接得太快。
其中一个连接器，我有没有在点允许之前读过它要的权限清单？
我有没有哪个连接器，是「一接上就给了写权限」的？它是哪几个动作？
删除 / 发布 / 发邮件这三类动作，目前是自动执行还是有我点头？
如果这个连接器明天开始乱写文件，我怎么发现？有没有一条能看出它做了什么的路子？
怎么上手 · 验证步骤
第一次只做一件事：挑一个你每天都会打开的目录或收件箱，把官方的 filesystem server 接上去，指到那一处，然后只用只读方式问三句话 —— 「列出最近改过的 5 个文件」「总结这份文档」「这里面有没有和我上周那份重名的」。观察它要什么、跑到哪一步，再决定要不要给写权限。跑通之后再加第二个（GitHub / Notion 之类），最后才考虑自己写一个 30 行的自定义 server —— 那一步才是「把你自己的工作流接进去」，而这一步的门槛比想象的低。
自检动作：写下这一句 ——「我现在接了 N 个连接器，其中 M 个有写权限，M 个里的哪几个动作需要我点头」。写得出来，说明接得清楚；写不出来，说明你只是把它们打开了。