上一篇讲了 MCP 是什么。

这一篇专门解决判断问题：

``

我这个需求到底要不要 MCP？

`

> 前置教程：MCP 是什么，为什么 Codex 需要它

> 如果你还不清楚 MCP 的定位，先看前置教程。

核心判断原则

只有当 Codex 需要访问“当前项目和当前对话之外”的东西时，才优先考虑 MCP。

如果信息已经在项目里，或者你已经贴到对话里，通常不需要 MCP。

决策矩阵

| 需求 | 应该用什么 |

| :--- | :--- |

| 这次只改某个页面 | 当前对话提示词 |

| 以后每次都要按项目规则检查 | AGENTS.md |

| 默认使用哪个模型 | config.toml |

| 让 Codex 查公司内部文档 | MCP |

| 让 Codex 查 GitHub issue 或 PR | MCP |

| 让 Codex 查设计稿 | MCP |

| 让 Codex 按固定流程修 Bug | Skills |

| 让 Codex 在调用危险工具前自动拦截 | Hooks |

5 个推荐使用 MCP 的场景

场景 1：需求或文档在外部系统

比如：

  • OpenAI 官方文档。
  • 框架官方文档。
  • 公司内部接口文档。
  • 产品需求文档。

如果文档经常变化，不适合每次靠记忆或复制粘贴。

你可以让 Codex：

`

请先通过文档 MCP 查询当前最新说明。

只总结结论，不要修改文件。

`

场景 2：需求来自 issue 或任务系统

比如：

  • GitHub issue。
  • Linear issue。
  • Jira 工单。
  • 飞书/Notion 需求页。

适合 MCP 的原因是：

  • 需求可能很长。
  • 评论可能有补充。
  • 状态可能变化。
  • 复制粘贴容易漏。

但第一次要限制只读：

`

请通过 MCP 读取这个 issue 的标题、正文和评论。

先总结需求、验收标准和风险点，不要修改代码。

`

场景 3：需要看设计稿或浏览器状态

比如：

  • Figma 设计稿。
  • 浏览器当前页面结构。
  • DevTools 里的控制台错误。
  • 页面 DOM、网络请求、性能信息。

这类信息不在代码文件里，MCP 可以把它们变成 Codex 可读取的上下文。

场景 4：访问受控的内部工具

比如公司有一个内部平台：

  • 查询接口定义。
  • 查询错误码。
  • 查询测试环境地址。
  • 查询发布记录。

如果内部平台有 MCP，就可以让 Codex 通过受控工具读取，而不是把账号、Cookie、截图到处复制。

场景 5：多个项目共享同一套知识库

比如你有很多项目都依赖同一套：

  • 组件库文档。
  • 接口规范。
  • 业务词典。
  • 设计规范。

这种适合通过 MCP 统一读取。

不要每个项目都复制一份文档。

MCP 在高级流程中的作用

后面讲 Skills、Hooks、Subagents 时，MCP 会更重要。

比如：

`

修 Bug 流程：

  1. 通过 issue MCP 读需求。

    2. 2. 通过 docs MCP 查接口规范。

    3. 读本地代码。

    4. 修改代码。

    5. 运行检查。

    6. 汇报结果。

    `

    这里 MCP 负责“外部信息”，Skill 负责“流程”。

    5 个不推荐使用 MCP 的场景

    场景 1：只是想让 Codex 改一个小页面

    比如：

    `

    把首页按钮文案改成“开始学习”。

    `

    不需要 MCP。当前对话就够。

    场景 2：你连 AGENTS.md 都还没有

    如果你连 AGENTS.md 都还没有，先不要上 MCP。

    先让 Codex 在项目内稳定工作，再连接外部系统。

    场景 3：你不知道这个 MCP 能做什么

    如果一个 MCP server 的能力说明你看不懂，不要先装。

    先问 Codex：

    `

    请只根据这个 MCP server 的公开说明，帮我判断它会暴露哪些工具、是否可能写入外部系统、是否需要登录授权。不要安装。

    `

    场景 4：它需要高权限但你只想做低风险任务

    比如你只是查文档，却装了一个可以写入、删除、发布的工具。

    权限过大。

    场景 5：它会接触敏感数据，但没有审批边界

    比如：

    • 客户资料。
    • 生产日志。
    • 支付数据。
    • 内部密钥。

    这些不适合新手第一波配置。

    其他容易混淆的场景

    配置模型

    配置模型用 config.toml 的 model/provider。不需要 MCP。

    固定工作流

    固定流程更适合 Skills。

    比如“每次修 Bug 都按 6 步走”，这不是 MCP 的主要职责。

    新手进阶建议

    建议按这个顺序：

    1. 先理解 MCP 是外部工具连接。

      2. 2. 先学会判断需不需要 MCP。

      3. 先配置一个只读文档 MCP。

      4. 用 /mcp 或 MCP 状态页确认连接成功。

      5. 做一次只读查询任务。

      6. 再考虑带 OAuth 的 MCP。

      7. 最后才考虑能写入外部系统的 MCP。

      不要一开始就配置十几个 MCP。

      总结清单

      每次准备配置 MCP 前，先问自己：

      1. Codex 是否真的需要访问项目外部信息？

        2. 2. 这个信息能不能直接从项目文件里读到？

        3. 我能不能临时复制一小段给 Codex？

        4. 这个 MCP 是只读还是可写？

        5. 它需要什么账号权限？

        6. 它会不会接触敏感信息？

        7. 它是否来自可信来源？

        8. 失败后我知道怎么关闭它吗？

        9. 是否应该放用户级配置，还是项目级配置？

        10. 是否需要在 AGENTS.md 里写一条“使用 MCP 前先汇报资料来源”？

        如果你答不上来，就先不要配。

        推荐提示词：判断需求

        可以复制：

        `

        请帮我判断这个需求是否需要 MCP。

        需求：

        【这里写你的任务】

        要求：

        1. 先判断任务所需信息是否在当前项目或当前对话里。

          2. 2. 如果不需要 MCP，请说明用提示词、AGENTS.md、config.toml 或 Skills 哪个更合适。

          3. 如果需要 MCP，请说明需要哪类 MCP：文档、issue、设计稿、浏览器、内部工具还是其他。

          4. 判断这个 MCP 应该先只读使用，还是可以允许写入。

          5. 不要直接安装或修改配置。

          `

          推荐提示词：评估风险

          `

          我准备给 Codex 配置一个 MCP server。

          MCP 名称或说明：

          【这里粘贴 MCP 的名称、地址或说明】

          请先做安装前风险评估：

          1. 它可能提供哪些能力？

            2. 2. 是否可能读取私有数据？

            3. 是否可能写入、删除或发布内容？

            4. 是否需要 OAuth 或 API Key？

            5. 更适合用户级配置还是项目级配置？

            6. 第一次验证应该怎么做成只读任务？

            7. 不要执行安装。

            `

            读完后你应该能判断：

            1. 什么时候提示词就够。

              2. 2. 什么时候写 AGENTS.md。

              3. 什么时候改 config.toml`。

              4. 什么时候才需要 MCP。

              5. 为什么第一次要从只读 MCP 开始。

              下一篇看：第一次配置只读文档 MCP。