自定义 MCP 工具加速软件开发

AI 编程工具已经不只是补全代码。它们可以读仓库、跑命令、调用外部服务，也可以参与调试、测试、部署和文档整理。问题随之变成：团队反复执行、已经积累了经验的工程操作，怎样才能封装成可控、可复用、适合 AI 调用的工具？

这篇文章整理自我在 Cursor Meetup 上的一次分享，主题是“自定义 MCP 工具加速软件开发”。文章保留分享中的主要结构和图示，并补充 MCP 工具设计、AI 协作方法，以及 Excel 文件批量验证案例中的实践细节。

分享信息

• 主题：自定义 MCP 工具加速软件开发
• 分享人：张华枫
• 时间：2025-08-09
• 场合：Cursor Meetup

第一部分：MCP 简介和设计理念

什么是 MCP

Model Context Protocol（MCP）是一套连接人工智能应用与外部工具、数据源的开放协议。它提供统一的能力描述和调用方式，让模型所在的应用能够发现并使用外部能力。MCP 本身并不自动解决权限、安全和审计问题，这些边界仍需要由客户端、服务端和具体工具共同实现。

如果只把大语言模型当作文本生成器，工具协议看起来并不必要。但一旦模型开始读文件、查数据库、调用 API、执行命令或操作开发环境，问题就不再只是“让模型生成什么”，而是“怎样让模型可靠地使用外部能力”。此时，工具的输入输出、权限边界、执行状态和错误语义都需要被明确表达。

为什么选择 MCP

选择 MCP 主要有四个原因：

• 统一接口：用相对一致的方式描述和调用不同工具，减少每个客户端单独适配的成本。
• 解耦实现：模型应用不必了解每个内部工具的具体实现，只依赖稳定的能力描述和参数约定。
• 便于扩展：新的内部能力可以通过 MCP 接入现有工作流，而不必重新设计一套调用协议。
• 便于治理：统一的工具边界让权限控制、日志、审计和错误处理更容易放在明确的位置实现。

选择 MCP 的实际动机很直接：开发团队已经拥有大量内部工具、脚本、流程和平台能力，但它们通常散落在命令行、网页后台、CI、数据库、日志系统和文档里。MCP 提供的是一个标准通道，让模型能够在上下文中了解这些能力，并稳定地调用它们。

现有方案的局限性

现成的 MCP Server 很有价值，但到了团队内部场景，经常会遇到几个问题：

• 抽象过于通用：很难直接承载内部流程中的特殊约束和领域判断。
• 接入成本不低：通用工具仍需要配置、权限和流程适配，未必能直接进入现有工作流。
• 维护边界在外部：版本变化、行为变化和兼容性不完全由团队控制。

传统开发流程也有自己的痛点：

• 重复性工作：相似的调试、测试、部署流程需要反复执行。
• 上下文切换成本：开发者在 IDE、终端、日志、网页后台、文档和聊天窗口之间频繁切换。
• 反馈周期长：从问题发现到修复验证之间有太多手工步骤。

开发自定义 MCP 工具是为了把团队熟悉且已经验证过的工程经验封装成 AI 可以稳定调用的能力，而不只是追逐新工具。

第二部分：自定义 MCP 工具的设计理念

业务场景导向

自定义 MCP 工具首先应从业务场景出发：

• 深度定制：针对特定业务流程优化，而非通用方案。
• 流程整合：将多个相关步骤封装为单一工具调用。
• 领域专业化：集成业务专家的经验和最佳实践。

不要一开始就做“万能工具”。万能工具听起来强大，实际往往很难稳定使用。更实际的路径，是找到团队最常见、最耗时、最容易出错的一段流程，把它封装成一个职责集中、能完整处理这段流程的工具。

减少认知负担

第二个原则是减少认知负担：

• 抽象清楚：隐藏调用者不需要关心的技术细节，让接口直接表达业务动作。
• 状态边界明确：需要跨步骤保存的状态应显式管理，避免依赖调用者反复重建上下文。
• 错误可恢复：返回可分类的错误和恢复信息；只有在操作满足安全重试条件时，才自动重试。

对模型而言，接口越清楚，越容易选择正确工具并生成稳定参数；对人而言，工具越贴近业务语言，也越容易被理解和维护。好的 MCP 工具不只是“把命令行包一层 JSON”，还应该把必要的约束、错误语义和恢复路径一起表达出来。

反馈驱动改进

第三个原则是反馈驱动改进：

• 实时监控：集成监控和日志收集。
• 性能指标：提供可量化的效果评估。
• 持续优化：支持基于使用数据的迭代改进。

AI 参与开发之后，很多工作流会从“一次性执行”变成“执行、观察、修正、再验证”。如果工具只返回成功或失败，调用者就很难判断下一步应该重试、修改输入还是停止。更有用的返回结果应包含必要的结构化状态，例如当前阶段、失败原因、是否可重试，以及能够继续诊断的最小证据或日志入口。

典型应用场景

可以从三个典型场景来看。

开发环境管理工具：

功能：一键环境准备和验证
输入：项目配置文件
执行：依赖安装 -> 服务启动 -> 健康检查 -> 测试运行
输出：环境状态报告 + 问题修复建议

代码质量检查工具：

功能：全方位代码质量评估
输入：代码仓库路径
执行：静态分析 -> 安全扫描 -> 测试覆盖率 -> 性能基准
输出：质量评分 + 详细改进方案

部署流水线工具：

功能：自动化部署和回滚
输入：部署配置 + 目标环境
执行：构建镜像 -> 部署服务 -> 烟雾测试 -> 流量切换
输出：部署结果 + 监控链接

这些工具的共同点是：每个工具都负责一段完整流程，而不只是执行一条孤立命令。MCP 的价值就在于把这些流程变成模型可以调用、团队可以复用的工具。

第三部分：MCP 工具开发实践

开发实践步骤

开发自定义 MCP 工具，可以从三个步骤开始：

1. 识别重复性任务：统计团队在哪些环节花费时间最多，找到自动化的切入点。
2. 分析现有缺陷：找出当前手动或半自动方案的具体问题，明确优化目标。
3. 评估自动化价值：比较自动化工具的开发成本与长期能节省的时间和精力，判断投入是否值得。

以部署流程为例：

• 痛点：一次部署需要跨越多个手工步骤，重复操作多，也容易遗漏。
• 解决：把稳定的步骤和验证条件封装进部署工具，减少重复操作和人为失误。

关键不是把所有事都自动化，而是先找到“重复、高频、容易错、反馈慢”的工作。这类工作最适合封装成 MCP 工具。

从开发实践中形成的 MCP 工具

这次分享里提到三个工具：

1. Command Line Tools MCP Server
2. MCP-SSE-Proxy
3. VSCode-Copy-for-LLM

Command Line Tools MCP Server

Command Line Tools MCP Server 是一个基于 FastMCP 的命令行工具动态封装方案。

它的核心价值是通过 JSON 配置，把已有的命令行能力快速封装为 MCP 工具。

关键特性包括：

• 配置驱动：无需修改代码，仅用 JSON 配置就能定义工具行为。
• 多执行模式：支持 oneshot、foreground、background 等多种执行方式。
• 进程管理：提供后台进程的监控和管理能力。
• 执行保障：内置工作目录设置、环境变量配置和超时控制。

这类工具的意义在于复用团队已有的脚本和命令行能力，而不是重新实现它们。原有程序继续负责执行，MCP 封装则补上能力描述、参数校验、执行控制和结构化结果。

Command Line Tools 调试流程

这张图表达的是一个调试闭环：从问题输入开始，工具负责执行检查、收集结果、暴露中间状态，AI 根据结果继续定位问题。调试不再是一串临时命令，而是一个可观察、可重复的流程。

工具选择

实际效果（1）

实际效果（2）

这三张截图展示了工具在真实开发过程中的调用效果。相比抽象描述，“工具选择、工具输出、工具反馈”这些界面细节更能说明 AI 工具如何进入开发流程。

MCP-SSE-Proxy

MCP-SSE-Proxy 是一个基于 Next.js 14 的全栈 Web 应用，使用 Docker 进行容器化管理。

它的核心价值是：作为 MCP 协议网关和管理仪表盘，解决不同传输协议之间的通信障碍。

关键特性包括：

• 协议桥接：将 stdio、HTTP、SSE 等协议统一为 SSE 流。
• 多服务器聚合：将多个 MCP 服务器工具集成到单一端点。
• 可视化管理：提供 Web 界面进行配置、监控和控制。
• 工具级权限控制：精细化管理每个工具的访问权限。
• 实时日志系统：通过 SSE 提供实时日志监控。

这类工具解决的是 MCP 工具数量变多之后的管理问题。当团队内部工具越来越多，仅靠逐个配置客户端，很快就难以管理。网关和仪表盘可以把协议、权限、状态、日志集中起来。

VSCode-Copy-for-LLM

VSCode-Copy-for-LLM 解决的是代码上下文传递问题：怎样把一组文件更清楚、更稳定地交给大语言模型。

核心功能包括：

• 智能忽略：遵守 .gitignore 规则，能够正确解析嵌套规则。
• 可定制格式：自定义文件头、分隔符、输出格式。
• 大文件处理：文件大小限制、二进制文件自动检测。
• 用户体验：进度提示、清晰反馈、批量处理。

这个工具看似简单，却对应 AI 编程中一个很实际的问题：怎样把相关代码交给模型，同时保留文件边界并减少无关内容。直接把大量文件贴进聊天窗口，容易产生噪声、遗漏和格式混乱；更稳定的做法是让工具负责选择、过滤和组织上下文。

第四部分：AI 协作中的关键技巧

项目生成

项目生成时，最重要的约束之一是 KISS 原则，也就是 Keep It Simple, Stupid。

工程系统的设计应保持简洁，不引入非必要的复杂性。

我在项目生成场景中常用的提示是：

始终遵循 KISS 原则，优先选择最简单可行的方案。
如果方案复杂度超过 3 层抽象，请重新设计。

AI 很容易在没有约束时生成“看起来完整”的复杂系统：过早抽象、过度分层、引入不必要的框架和配置。KISS 原则的作用是把模型拉回到当前任务真正需要的最小实现。

上下文窗口优化

上下文窗口优化可以从三点入手：

• 渐进式重构：将大型变更分解为多个独立步骤。
• 关键信息提取：只保留当前任务最相关的上下文。
• 长上下文模型利用：确实需要大量上下文时，再选择适合长上下文任务的模型，而不是默认把全部内容塞进窗口。

上下文窗口不是越大越好。真正重要的是上下文中有效信息的比例，以及这些信息如何组织。一个高质量的上下文包应该让模型知道当前目标、相关文件、约束、已有设计、失败历史和验证方式，而不是把整个仓库塞进去。

质量控制

质量控制需要多层机制：

1. 模型自检：让模型重新检查自己生成的代码，用于发现明显遗漏，但不把它当作独立验证。
2. 自动化测试：让可重复执行的测试验证行为和回归风险。
3. 人工审查：对高风险、难以自动验证或涉及重要设计判断的变更进行人工确认。

检查清单包括：

• 逻辑正确性和边界条件。
• 性能和安全性考虑。
• 代码风格和规范一致性。
• 测试覆盖率和文档完整性。

AI 生成代码之后，质量控制不应该只依赖“看起来合理”。更可靠的方式，是明确列出检查步骤，让 AI 自检、自动化测试和人工审查各自承担一层检查职责。

从个人实践到团队标准

个人实践要在团队里持续产生收益，需要沉淀成共享标准：

1. 工具库建设：建立团队共享的 MCP 工具集。
2. 最佳实践沉淀：将成功经验文档化和模板化。
3. 培训体系建立：帮助团队成员快速上手 AI 协作。
4. 从工具使用者到工具创造者：主动构建适合业务场景的专用工具。
5. 知识共享：通过工具封装传递领域专业知识。

AI 协作的价值并不限于提高个人效率。要在团队中持续产生收益，还需要把个人实践沉淀为共享工具、共享流程和共享标准。

第五部分：实战案例

这一部分的主题是构建反馈循环，利用大模型辅助算法优化。

场景背景：Excel 文件批量验证

场景是 Excel 文件批量验证：给定一组验证规则，让一个智能体工作流（agentic workflow）判断每个 Excel 文件是否满足规则，并保留判断依据。

规则举例：

• 标注为“数量”的列不为空。
• 表格中“完成”需要打勾。

这个任务看起来像普通的 Excel 读取和规则判断，但真实文件会让问题复杂很多。我们可以使用正则表达式提取、大模型判断，或者结合多种方法给出最终结论。

例如：

• 正则匹配“完成”，然后在前后匹配勾选符号或类似字符。
• 将 Excel 转成文本，加上提示词，让大模型判断。

Excel 文件处理的现实挑战

现实问题包括：

• Excel 文件排版不一致，导致定位特定列的算法并不稳定。
• 一个工作表（sheet）可能有多个“区域”，也就是一个工作表里实际放了多个表格。
• 区域划分可能通过带颜色的合并单元格模拟边界。
• 判断一列在哪里结束，需要理解合并单元格、颜色、空行、区域边界等信息。

这并不是一个简单的“读表格，查单元格”问题。算法需要理解 Excel 文件的结构，而文件并不总是通过标准的表格结构来表达这些信息。

核心思路：构建反馈循环

核心思路是构建一个测试驱动的迭代优化流程：

输入：算法原型 + 验证规则 + 测试文件集 + 预期结果

执行检测算法 -> 获得实际输出
对比预期结果 -> 识别差异点
分析失败原因 -> 生成改进建议
更新算法实现 -> 重新测试验证

大模型并不是一次性写完算法，而是参与一个反馈循环：根据测试结果分析失败模式，再提出改进方案。人类负责提供规则、测试集、预期结果和边界判断，并用可重复的测试决定修改是否真的有效。

LLM 驱动的算法优化实施步骤

具体实施分两步。

第一步，建立测试基础设施：

• 构建包含多种典型场景的 Excel 文件测试集。
• 定义每个文件的标准验证结果。
• 创建可自动化执行的测试脚本。

第二步，启动 AI 驱动的优化循环：

• 使用 GitHub Copilot 执行 <检查算法, 规则描述, 测试文件>，获得初始输出。
• 根据 <算法描述, 预期结果, 实际差异> 生成算法改进方案。
• 应用改进后的算法重新测试，持续迭代直至达标。

这个过程的关键是把失败变成可检查的反馈，而不只是给模型一句“请改好”。没有明确的预期结果和差异信息，模型很容易给出看似合理、却无法判断是否改进的方案。

优化过程中的关键发现

遇到的典型陷阱有三类：

• 过度拟合：算法根据文件名特征进行判断，缺乏泛化能力。
• 关键词堆砌：使用大量硬编码关键词匹配，算法脆弱且不通用。
• 忽视边界情况：只针对理想格式优化，忽视实际文件中的格式变化。

获得的意外收获也很重要：

• Excel 处理组件库：沉淀出高质量的 Excel 文件处理代码片段。
• 结构理解能力：智能提取工作表名称和结构。
• 样式解析能力：理解和处理合并单元格、单元格颜色和样式信息。
• 领域知识积累：把 Excel 文件处理经验整理成有明确结构的知识，为后续类似项目提供参考。

这个案例说明，AI 参与算法优化时，产出不只是最后那段算法代码。更有价值的是调试过程中的中间组件、失败样本、判断规则和领域知识。

优化后的 Excel 处理组件库

经过多轮迭代之后，我们得到了一组可复用的 Excel 处理组件。它们不只服务于当前规则，也可以被后续相似任务复用。

对这类任务而言，把“文件读取、结构识别、区域划分、规则判断、证据生成”拆成可组合组件，比写一个单体脚本更可靠。

用大模型优化算法的成功条件

成功的关键因素包括：

• 领域知识注入：将人类专家对 Excel 文件格式的理解整理成结构化知识，作为上下文提供给 AI，显著提升算法生成质量。
• 渐进式优化：从最简单的规则开始，逐步增加复杂性，确保每一步都有稳定基础。
• 自动化反馈：建立测试、反馈和优化闭环，让每一轮修改都能根据失败样本继续调整，并由测试判断是否改善。

参考资料：Google DeepMind《AlphaEvolve: A Gemini-powered coding agent for designing advanced algorithms》。

总结

核心观点可以概括为四点：

• 对高频、边界相对稳定的内部流程，面向业务场景的工具通常比直接拼装通用能力更容易稳定复用。
• 工具不只要完成动作，还要返回足够的状态和证据，让后续判断能够进入反馈循环。
• 大模型适合参与探索、分析和方案生成，但结果仍需要测试、规则或人工判断来验证。
• 当重复流程已经足够稳定时，把经验沉淀成团队可复用的工具，比反复依赖个人提示和临时操作更有长期价值。

实践建议是：

• 从团队最频繁的重复性任务开始。
• 优先解决现有工具的具体痛点。
• 建立可量化的效果评估体系。
• 将成功经验沉淀为团队标准。

重点不在于“每个团队都要马上写一堆 MCP 工具”。当 AI 已经进入开发流程后，我们需要重新思考工具的形态：工具不只是给人用，也要能被智能体（Agent）安全、稳定、结合上下文调用。