4.1 AI 编程平台 · 波仔的 AI 编程实战课

📄 一句话概括

五个工具：Cursor、Trae、Claude Code、Cline、Continue。 它们最先进 MCP，原因很实际：写代码的人最缺的就是「让 AI 碰到真东西」。 配置三份文件长得几乎一样，差的是放在哪、谁有权改。

📝 本章和前面几章的关系

前三章讲的是协议本身。从这一章开始讲「谁已经实现了它」。这一节只看编程工具这一类，因为它们出现最早、配置最统一。下一节看平台类，那一类的形态完全不同——你填的不是文件，是网页上的表单。

一、为什么是编程工具先吃下它

MCP 最早是给编辑器写的内部约定，所以编程工具接得最早、也最彻底。更实际的原因是需求最痛：写代码的时候，AI 最需要的是「看一眼真实的仓库、真实的日志、真实的报错」，而不是多背几段 API 文档。而这些动作全都要碰本地——读文件、跑命令、查 git 历史。只能在本地跑的东西，天然适合 stdio。

所以这一类的形态高度一致：一个配置文件，里面写清起哪个进程、传什么参数。剩下的事由工具自己办。 这类工具的门槛最低：会写一段 JSON 就能接上，不用申请、不用审核、不用付费。

二、五个工具，一句话一个

Cursor：把 MCP 做进设置面板，点加号填命令即可，项目级配置放在项目目录里。 Trae：形态跟 Cursor 接近，配置入口在自己的设置里，国内可直连，第 6 章要在它里面配一次自己写的 Server。 Claude Code：命令行工具，用一条命令加一个 Server，配置文件放在用户目录，第 53 课整本都在讲它。

Cline：编辑器插件形态，配置里多两个字段 disabled 和 autoApprove，后者决定哪些工具不用逐次确认。 Continue：也是插件，主打多模型切换，MCP 支持相对晚一些。这五家的差别不在协议，在配置放哪和谁能改。协议那层是完全一样的四步。

三、三份配置，长得几乎一样

演示里摆了三份：桌面助手放在用户目录下的一份 json，编程插件放在插件自己的设置文件里，编辑器项目级放在项目里的 .cursor 目录。三份的顶层键都是 mcpServers，结构、字段含义完全相同。差别只有两处：放哪个文件，以及谁有权改它。这个「谁有权改」很关键。用户目录那份是你自己的；项目目录那份会跟着仓库走，别人克隆下来就带上了。

所以项目级配置要当代码看待：进版本库、走评审。它能让一个仓库在别人机器上起一个进程——这可不是小事。

四、一份配置只有三样东西

command、args、env。这三样就是进程启动的三要素，MCP 的配置层没有别的东西。 command 写错，报「找不到命令」，连接直接失败，日志里只有一个超时。 args 写错，进程能起来但立刻退出，日志里一行报错。这种最好查，因为错误是显式的。

env 写错最隐蔽：能跑，但中文变乱码，或者找不到某个路径。看着像「模型不听话」。演示里真按一份配置起了一次：实际执行的命令、环境变量、握手结果、工具数，四样全对才算配置写对了。 【配置写对了，指的是能起来、能握手、能列工具】。 这三步任何一步不过，先怀疑配置，别怀疑协议。

五、Windows 上三个坑

第一条：command 写 python，但 PATH 里没有。表现是连接超时、日志空白。办法是写解释器的绝对路径。第二条：能连上但中文乱码。默认编码不是 utf-8，办法是在 env 里加 PYTHONIOENCODING。第三条最难查：偶发半行 JSON。原因是没加 -u，输出被缓冲了，【输出攒够了才吐】，看着像卡住。

三条都跟用什么宿主无关，是 Windows 上的通用问题。记住一条就够：args 第一个写 -u，env 里加编码，command 写绝对路径。第 6 章会在 Trae 里真配一次，到时候这三条会原样再出现一遍。

六、动手 Demo：同一台 Server，三份配置

同一个 Server，按三种宿主的写法各配一份，看它们差在哪。然后真按其中一份起一次进程，验证「配置写对了」到底指什么。进程是真起的，握手是真做的，工具数是从 Server 那儿列出来的。

# 桌面助手 / 编程插件：都放在用户目录那一层
CFG = {'mcpServers': {'mini': {'command': 'python',
                                'args': ['-u', '.../srv/mini.py'],
                                'env': {'PYTHONIOENCODING': 'utf-8'}}}}

# 起一次，验证三件事：能起来、能握手、能列工具
proc = subprocess.Popen([CFG['mcpServers']['mini']['command']]
                         + CFG['mcpServers']['mini']['args'],
                         stdin=subprocess.PIPE, stdout=subprocess.PIPE,
                         env=dict(os.environ, **CFG['mcpServers']['mini']['env']),
                         text=True, encoding='utf-8')

info = rpc('initialize', {'protocolVersion': '2024-11-05',
                         'capabilities': {}}, 1)
print(info['result']['serverInfo'])
print(len(rpc('tools/list', {}, 2)['result']['tools']))

实跑输出：

--------------------------------------------------------------------
同一台 Server，三份配置
--------------------------------------------------------------------


  ① 三份配置，长得几乎一样
  --------------------------------------------------------------------

| 宿主类型 | 配置文件放哪 | 顶层键 | 多出来的字段 |
|---|---|---|---|
| 桌面助手 | 用户目录下的一份 json | mcpServers | — |
| 编程插件 | 插件自己的设置文件 | mcpServers | disabled、autoApprove |
| 编辑器（项目级） | 项目里的 .cursor 目录 | mcpServers | — |

  三份配置的【键名、结构、字段含义完全相同】。差别只有两处：
  放在哪个文件里，以及谁有权改它。

  ② 一份配置就三样东西
  --------------------------------------------------------------------
（路径省略了前面的目录，实际要写全）
    {
      "command": "python",
      "args": [
        "-u",
        ".../srv/mini.py"
      ],
      "env": {
        "PYTHONIOENCODING": "utf-8"
      }
    }

| 字段 | 意思 | 写错会怎样 |
|---|---|---|
| command | 起哪个可执行文件 | 报「找不到命令」，连接直接失败 |
| args | 传什么参数 | 进程起来但立刻退出，日志里一行报错 |
| env | 给它什么环境变量 | 能跑，但中文变乱码或路径找不到 |

  这三样就是【进程启动的三要素】。MCP 的配置层没有别的东西。

  ③ 真按这份配置起一次
  --------------------------------------------------------------------
  实际执行的命令：python .../srv/mini.py
  环境变量：{"PYTHONIOENCODING": "utf-8"}
  握手结果：serverInfo = {"name": "mini", "version": "0.1.0"}
  工具数：1（add）
  到这里就验证完了：【配置写对了，指的是能起来、能握手、能列工具】。
  起不来的时候，先看 command 和 args，再看 env，最后才怀疑协议。

  ④ 两个 Windows 上的坑
  --------------------------------------------------------------------

| 现象 | 原因 | 怎么办 |
|---|---|---|
| 连接超时，日志空 | command 写 python 但 PATH 里没有 | 写解释器的绝对路径 |
| 能连上，中文乱码 | 默认编码不是 utf-8 | env 里加 PYTHONIOENCODING |
| 偶发半行 JSON | 没加 -u，输出被缓冲 | args 第一个写 -u |

  第三条最难查：不是每次都错，是【输出攒够了才吐】，看着像卡住。
  ! 这三条在 Windows 上几乎每个新手都会踩一遍，跟用什么宿主无关。

①第一张表三行，最后一列是重点：编程插件多两个字段，一个能整条禁用，一个能免确认。后者是安全开关，第 3 章那三道闸里的第二道就管这个。 ②第二段那份配置只有三样东西。看着简陋，但这三样足够描述「怎么把一个进程拉起来」，而 MCP 的配置层确实只需要这些。 ③第三段的验证只有四行输出，但它是最有用的四行：命令、环境变量、serverInfo、工具数。少一样没对，就说明这条路没通。 ④第四段三个坑里，第三个最值得记。没加 -u 的时候，写进去的 JSON 待在缓冲区里，宿主那边读到的就是空。看着像 Server 死了，其实它只是想攒够再吐。 ⑤这一节没有一行需要平台界面。配置对了，任何宿主都能连；配置错了，再贵的客户端也连不上。

30 秒实验

打开你正在用的编辑器或插件，找到它的 MCP 配置项在哪。能找到就说明你已经在用了。
把演示里的 command 改成写死的一个不存在路径，想想日志里会出现什么。
如果你的项目要提交一份项目级 MCP 配置，里面该写什么、不该写什么。

常见误区

「编程工具的 MCP 配置各家不一样，要分别学。」顶层键、结构、字段含义完全相同，差的只是文件放哪。
「项目级配置就是方便，随手加。」它能让别人克隆仓库后自动起一个进程。当代码看待，走评审。
「中文乱码是模型的问题。」多半是编码，env 里加一行就好。模型看不见你的控制台编码。

自测三问（点开对答案）

1. 一份 stdio 配置要写哪三样？ —— command、args、env。就是进程启动的三要素，配置层没有别的东西。 2. 「配置写对了」的判据是什么？ —— 能起来、能握手、能列工具。三步都过才算通，之后才是协议层的事。 3. 为什么说项目级配置要当代码看待？ —— 它会跟着仓库走，别人克隆下来就带上了，能让别人机器起一个进程。所以进版本库、走评审。

编程工具这一类看完了，下一节看平台类——同样的协议，形态完全不同：你填的不是文件，是网页上的表单。

☐ （本篇完，下一篇 4.2 支持 MCP 的智能体开发平台）