熊二编程 · 技术专栏

MCP 接入前检查

先分清读、写、触发、授权

01

WHY

MCP 改变的是动作边界

不只是“给模型更多上下文”。

02

TABLE

小团队先做四层权限表

别从安装命令开始，从动作分级开始。

1读数据

例子：读 issue、查文档、看监控、查数据库。默认策略：先只读，记录数据范围，敏感数据脱敏后再给 AI。

2写数据

例子：改 issue、写评论、创建文档、修改配置。默认策略：需要确认，写入前显示字段、对象、差异和回滚办法。

3触发动作

例子：发邮件、合并 PR、部署、推送公众号草稿、调用支付。默认策略：人类审批，禁止静默执行。

4账号和钱

例子：生产库、客户资料、支付、云账号、私有仓库 token。默认策略：不用个人主账号，拆最小权限账号，先沙盒后生产。

03

FLOW

真正的接入顺序

先只读，再写入，最后才自动化。

第一步：先列工具清单。不要只写 server 名，要写每个 tool 的动作，例如 read_issue、create_comment、query_db、send_message。

第二步：先只读试跑。让 AI 查询、总结、对照，先不要让它修改、发送、删除、部署。

第三步：写入必须确认。确认页至少展示对象、字段、差异、影响范围和操作者身份。

第四步：日志要能追。工具被谁调用、传了什么参数、返回了什么、最后有没有写入，都应该能查。

第五步：最后才考虑自动化。能人工确认跑通三五次，再把低风险动作交给 AI 自动做。

04

RULE

三个不要碰的红线

这些不是小心一点就行，而是应该直接禁掉。

红线 1：不要把个人主账号 token 直接写进项目共享配置。尤其是会进版本库的 `.mcp.json`、`.vscode/mcp.json` 或团队模板。

红线 2：不要让一个会读外部不可信内容的工具，同时拥有发送消息、导出数据、删除记录或生产写入权限。

红线 3：不要把“安装了官方或知名 server”当成安全证明。工具描述、输入、输出和权限组合，都要按自己的业务场景复核。

05

ASK

判断一个 MCP 值不值得接

用业务问题筛掉炫技。

它能省掉哪种重复劳动？例如每天复制错误日志、查工单、整理客户反馈、更新草稿。

它错了会造成什么损失？是多读了一段无关信息，还是发错消息、删错数据、动了生产环境？

不用 MCP 有没有更简单办法？如果一次性导出 CSV、只读 API、脚本报表就够了，不要为了“Agent 化”增加长期风险。