1. 项目缘起：当大模型需要“亲手”操作文件时

最近在折腾一些本地大模型应用时，我遇到了一个挺有意思的瓶颈。我尝试让模型帮我整理电脑里散乱的项目文档，或者根据我口述的草稿生成一份格式规整的Markdown报告。模型的理解和生成能力都没问题，但到了“落地”这一步就卡住了——它无法直接读取我指定的文件夹内容，也无法将生成的文本保存到我指定的硬盘位置。所有的交互都被困在聊天窗口里，模型就像一个被关在玻璃房里的天才，能看到外面的世界，却无法伸手触碰。

这让我开始思考，如何打破这层“玻璃”？答案指向了 MCP（Model Context Protocol） 。简单来说，MCP 可以看作是大模型的“手”和“眼睛”。它定义了一套标准协议，允许大模型（客户端）安全、可控地调用外部工具（服务器）的能力。而我要做的，就是亲手打造一个最基础、也最核心的 MCP Server：一个能让大模型安全地读写我本地文件的“文件管家”。

这个项目的价值在于，它不是一个简单的 API 封装，而是一个 权限与能力的边界定义者 。通过它，我可以精确控制大模型能访问哪些目录、能执行哪些操作（读、写、列表），从而将大模型强大的逻辑处理能力与本地文件系统的持久化存储无缝衔接。无论是自动化文档归类、代码仓库分析，还是个人知识库的构建与维护，这个自研的 MCP Server 都将成为关键的桥梁。

2. MCP Server 核心原理：协议、工具与安全边界

在动手写代码之前，我们必须先吃透 MCP 这套协议的核心思想。你可以把它想象成给大模型设计一套“标准化工具插座”。

2.1 MCP 的三层架构：客户端、服务器与工具

MCP 协议清晰地划分了三个角色：

1. 客户端 (Client) ：通常就是我们使用的大模型应用本身，比如 Claude Desktop、Cursor 或者任何集成了 MCP 客户端库的应用。它的职责是理解用户指令，决定在何时调用哪个工具，并处理工具的返回结果。
2. 服务器 (Server) ：这就是我们要实现的部分。它是一个独立的进程，负责管理一组具体的“工具”（Tools），并响应客户端的调用请求。服务器是能力的提供方和安全的守护者。
3. 工具 (Tools) ：服务器向外暴露的能力单元。每个工具都有明确的名称、描述、输入参数（JSON Schema定义）和输出格式。例如，我们的文件读写服务器就会提供 list_directory 、 read_file 、 write_file 这样的工具。

协议的核心通信是通过 JSON-RPC over stdio（标准输入输出）或 SSE（服务器发送事件） 进行的。这意味着我们的服务器程序启动后，会通过 stdin 接收 JSON-RPC 请求，并通过 stdout 输出 JSON-RPC 响应。这种设计使得服务器可以用任何语言编写，只要遵循协议格式即可。

2.2 为什么是“Server”而不是“Library”？

这是理解 MCP 价值的关键。如果只是给大模型一个函数库调用，那意味着模型代码（或托管平台）需要直接获得你系统的完整权限，这存在巨大的安全风险。而 Server 模式带来了根本性的好处：

• 权限隔离 ：Server 运行在独立的进程，甚至可以是独立的用户权限下。我们可以严格限定这个进程能访问的文件系统范围（例如，仅限 ~/Documents/ai_workspace 目录）。
• 生命周期管理 ：Server 的启动、停止独立于客户端。一个设计良好的 Server 可以长期运行，管理连接池、缓存等资源。
• 协议化与标准化 ：任何遵循 MCP 协议的客户端都能连接任何遵循协议的服务器，实现了生态的互通。你写的这个文件 Server，既可以被 Claude 使用，未来也可以被其他任何支持 MCP 的应用使用。

2.3 定义我们的工具集：能力与约束

基于“文件读写”的核心需求，我们需要设计三个基础工具，并为它们划定清晰的安全边界：

1. list_directory (列出目录)

   • 输入 ： path (字符串，目录路径)。
   • 输出 ：一个包含文件和子目录名称、类型（文件/目录）、大小等基本信息的列表。
   • 安全边界 ：服务器应解析传入的路径，并检查其是否在预设的允许访问的根目录（如 BASE_DIR ）之下。防止类似 ../../../etc/passwd 这样的路径遍历攻击。

2. read_file (读取文件)

   • 输入 ： path (字符串，文件路径)。
   • 输出 ：文件的内容（文本）或表示二进制文件的提示。
   • 安全边界 ：除了路径检查，还应限制读取文件的 最大尺寸 （例如 10MB），防止大模型意外尝试读取一个数GB的视频文件导致服务器内存溢出。同时，可以设置允许读取的文件扩展名白名单（如 .txt , .md , .json , .py ）。

3. write_file (写入文件)

   • 输入 ： path (字符串，文件路径)， content (字符串，文件内容)。
   • 输出 ：操作成功或失败的状态信息。
   • 安全边界 ：这是最需要谨慎的工具。除了路径检查，还应防止覆盖重要系统文件。一种实践是限制写入操作只能在某个特定的“工作区”目录内进行，或者要求路径必须不存在（仅允许创建新文件）。对于覆盖写入，可以要求一个额外的 confirm_overwrite 参数。

一个重要的设计抉择 ：是否支持递归操作？例如， list_directory 是否默认递归列出所有子目录？初期建议 不要 。递归操作可能意外遍历出巨量的文件，导致响应缓慢或数据泄露。保持工具原子化，复杂的操作（如“整理整个项目文档”）应由客户端（大模型）通过多次调用基础工具来组合实现，这反而更能体现模型的规划能力。

3. 从零实现：使用 TypeScript 构建文件读写 MCP Server

理论清晰后，我们进入实战环节。我将选择 TypeScript/Node.js 作为实现语言，因为它有活跃的 MCP 社区和官方 SDK，能让我们更专注于业务逻辑而非协议细节。

3.1 环境准备与项目初始化

首先，确保你的系统已安装 Node.js (>=18 版本) 和 npm。

# 创建一个新的项目目录
mkdir file-mcp-server && cd file-mcp-server
# 初始化项目，生成 package.json
npm init -y
# 安装官方 MCP SDK 和必要的类型定义
npm install @modelcontextprotocol/sdk
# 安装用于开发时自动重启的工具
npm install --save-dev tsx typescript @types/node

接下来，创建 tsconfig.json 文件来配置 TypeScript 编译器：

{
  "compilerOptions": {
    "target": "ES2022",
    "module": "NodeNext",
    "moduleResolution": "NodeNext",
    "outDir": "./dist",
    "rootDir": "./src",
    "strict": true,
    "esModuleInterop": true,
    "skipLibCheck": true,
    "forceConsistentCasingInFileNames": true
  },
  "include": ["src/**/*"],
  "exclude": ["node_modules"]
}

然后，在 package.json 的 scripts 部分添加启动脚本：

{
  "scripts": {
    "build": "tsc",
    "start": "node dist/index.js",
    "dev": "tsx watch src/index.ts"
  }
}

3.2 构建 Server 骨架与工具定义

我们在 src/index.ts 中开始编写主逻辑。首先，导入 SDK 并创建 Server 实例。

import { Server } from '@modelcontextprotocol/sdk/server/index.js';
import { StdioServerTransport } from '@modelcontextprotocol/sdk/server/stdio.js';
import {
  CallToolRequestSchema,
  ListToolsRequestSchema,
  Tool,
} from '@modelcontextprotocol/sdk/types.js';

// 创建 Server 实例
const server = new Server(
  {
    name: 'file-io-server',
    version: '0.1.0',
  },
  {
    capabilities: {
      tools: {}, // 声明本服务器提供工具
    },
  }
);

接下来，定义我们的安全配置和工具列表。这是 安全性的第一道关卡 。

// 安全配置：定义服务器允许访问的根目录
const ALLOWED_BASE_DIR = process.env.ALLOWED_BASE_DIR || 
  (process.platform === 'win32' ? 'C:\\Users\\Public\\Documents\\AI_Workspace' : '/home/user/ai_workspace');
// 最大可读文件大小（字节），防止读取大文件
const MAX_FILE_SIZE = 10 * 1024 * 1024; // 10MB

// 工具定义
const tools: Tool[] = [
  {
    name: 'list_directory',
    description: 'List files and subdirectories in a given directory.',
    inputSchema: {
      type: 'object',
      properties: {
        path: {
          type: 'string',
          description: 'The path of the directory to list.',
        },
      },
      required: ['path'],
    },
  },
  {
    name: 'read_file',
    description: 'Read the content of a text file.',
    inputSchema: {
      type: 'object',
      properties: {
        path: {
          type: 'string',
          description: 'The path of the file to read.',
        },
      },
      required: ['path'],
    },
  },
  {
    name: 'write_file',
    description: 'Write content to a file. Will create the file if it does not exist.',
    inputSchema: {
      type: 'object',
      properties: {
        path: {
          type: 'string',
          description: 'The path where the file should be written.',
        },
        content: {
          type: 'string',
          description: 'The text content to write into the file.',
        },
        overwrite: {
          type: 'boolean',
          description: 'If true, overwrite the file if it exists. Defaults to false.',
          default: false,
        },
      },
      required: ['path', 'content'],
    },
  },
];

3.3 实现核心安全校验与工具逻辑

在实现工具处理函数前，我们必须编写一个 核心的安全路径解析函数 。这是整个服务器的安全基石。

import * as path from 'path';
import * as fs from 'fs/promises';
import { fileURLToPath } from 'url';

/**
 * 安全地解析和校验用户提供的路径。
 * 1. 解析相对路径为绝对路径。
 * 2. 检查最终路径是否在允许的基目录之下。
 * @param userPath 用户传入的路径
 * @returns 解析后的绝对路径，或在安全校验失败时抛出错误
 */
function resolveAndValidatePath(userPath: string): string {
  // 将用户路径解析为绝对路径（相对于当前工作目录）
  const resolvedPath = path.resolve(userPath);
  // 获取允许的基目录的绝对路径
  const allowedBase = path.resolve(ALLOWED_BASE_DIR);

  // 关键安全校验：检查解析后的路径是否以允许的基目录开头
  if (!resolvedPath.startsWith(allowedBase + path.sep) && resolvedPath !== allowedBase) {
    throw new Error(`Access denied. Path must be within the allowed directory: ${ALLOWED_BASE_DIR}`);
  }

  return resolvedPath;
}

现在，我们可以实现各个工具的处理函数，并绑定到 Server 的请求处理器上。

// 处理 list_tools 请求：简单返回我们定义的工具列表
server.setRequestHandler(ListToolsRequestSchema, async () => {
  return {
    tools,
  };
});

// 处理 call_tool 请求：根据工具名分发到具体的处理函数
server.setRequestHandler(CallToolRequestSchema, async (request) => {
  const { name, arguments: args } = request.params;

  try {
    switch (name) {
      case 'list_directory':
        return await handleListDirectory(args as { path: string });
      case 'read_file':
        return await handleReadFile(args as { path: string });
      case 'write_file':
        return await handleWriteFile(args as { path: string; content: string; overwrite?: boolean });
      default:
        throw new Error(`Unknown tool: ${name}`);
    }
  } catch (error: any) {
    // 统一错误处理，返回给客户端
    return {
      content: [
        {
          type: 'text',
          text: `Error: ${error.message}`,
        },
      ],
      isError: true,
    };
  }
});

下面是三个核心工具函数的实现，每个都包含了详细的边界检查和错误处理。

async function handleListDirectory(args: { path: string }) {
  const safePath = resolveAndValidatePath(args.path);
  
  // 检查路径是否存在且为目录
  const stats = await fs.stat(safePath).catch(() => {
    throw new Error(`Path does not exist or is not accessible: ${args.path}`);
  });
  if (!stats.isDirectory()) {
    throw new Error(`Path is not a directory: ${args.path}`);
  }

  const items = await fs.readdir(safePath, { withFileTypes: true });
  const listResult = items.map((item) => ({
    name: item.name,
    type: item.isDirectory() ? 'directory' : 'file',
    // 可以添加更多信息，如文件大小（需要额外stat，注意性能）
  }));

  return {
    content: [
      {
        type: 'text',
        text: JSON.stringify(listResult, null, 2),
      },
    ],
  };
}

async function handleReadFile(args: { path: string }) {
  const safePath = resolveAndValidatePath(args.path);

  // 检查文件是否存在且为文件
  const stats = await fs.stat(safePath).catch(() => {
    throw new Error(`File does not exist or is not accessible: ${args.path}`);
  });
  if (!stats.isFile()) {
    throw new Error(`Path is not a file: ${args.path}`);
  }

  // 安全限制：检查文件大小
  if (stats.size > MAX_FILE_SIZE) {
    throw new Error(`File is too large to read (${stats.size} bytes > ${MAX_FILE_SIZE} bytes limit).`);
  }

  // 读取文件内容
  const content = await fs.readFile(safePath, 'utf-8');

  return {
    content: [
      {
        type: 'text',
        text: content,
      },
    ],
  };
}

async function handleWriteFile(args: { path: string; content: string; overwrite?: boolean }) {
  const safePath = resolveAndValidatePath(args.path);
  const overwrite = args.overwrite || false;

  // 检查目标路径是否已存在
  const fileExists = await fs.access(safePath).then(() => true).catch(() => false);
  
  if (fileExists && !overwrite) {
    throw new Error(`File already exists at ${args.path}. Use 'overwrite: true' to replace it.`);
  }

  // 确保目标目录存在
  const dir = path.dirname(safePath);
  await fs.mkdir(dir, { recursive: true });

  // 写入文件
  await fs.writeFile(safePath, args.content, 'utf-8');

  return {
    content: [
      {
        type: 'text',
        text: `File successfully written to: ${safePath}`,
      },
    ],
  };
}

3.4 启动服务器与协议传输

最后，我们需要启动服务器并建立传输层。对于 MCP，最常用的是 stdio（标准输入输出）传输，这允许客户端（如 Claude Desktop）通过命令行启动我们的服务器并与之通信。

async function main() {
  // 创建 stdio 传输层
  const transport = new StdioServerTransport();
  
  // 将服务器连接到传输层
  await server.connect(transport);
  
  console.error(`File IO MCP Server started. Allowed base directory: ${ALLOWED_BASE_DIR}`);
  // 注意：日志输出到 stderr，避免干扰与客户端的 JSON-RPC 通信（通过 stdout）
}

main().catch((error) => {
  console.error('Server fatal error:', error);
  process.exit(1);
});

至此，一个具备基础安全能力的文件读写 MCP Server 就完成了。你可以通过 npm run dev 启动开发模式，但更重要的测试是与真正的 MCP 客户端集成。

4. 集成与测试：让 Claude Desktop 成为你的文件助手

编写完 Server 只是第一步，让它真正发挥作用需要与客户端集成。这里以 Claude Desktop 为例，它是目前对 MCP 支持最友好、最易用的客户端之一。

4.1 配置 Claude Desktop 加载自定义 Server

Claude Desktop 允许通过配置文件添加自定义的 MCP Server。配置文件通常位于：

• macOS : ~/Library/Application Support/Claude/claude_desktop_config.json
• Windows : %APPDATA%\Claude\claude_desktop_config.json
• Linux : ~/.config/Claude/claude_desktop_config.json

如果文件不存在，就创建一个。我们需要在其中添加我们的 Server 配置。

{
  "mcpServers": {
    "file-io": {
      "command": "node",
      "args": [
        "/absolute/path/to/your/file-mcp-server/dist/index.js"
      ],
      "env": {
        "ALLOWED_BASE_DIR": "/home/yourusername/ai_workspace"
      }
    }
  }
}

关键配置解析 ：

• command : 启动服务器的命令，这里是 node 。
• args : 传递给命令的参数，即我们编译后的 JS 文件路径。 务必使用绝对路径 。
• env : 传递给服务器进程的环境变量。这里我们设置了 ALLOWED_BASE_DIR ，覆盖了代码中的默认值，将其指向你希望大模型访问的特定工作目录。

重要提示 ：修改配置后，必须 完全重启 Claude Desktop 应用 （不是关闭窗口，而是从任务管理器或活动监视器中彻底退出再重新启动），配置才会生效。

4.2 在对话中验证与使用工具

重启 Claude Desktop 后，新建一个对话。如果配置成功，Claude 通常会在回复中提示可用的工具，或者你可以直接询问：“你现在可以使用哪些工具？”

你应该能看到 list_directory , read_file , write_file 这三个工具。现在可以进行测试：

1. 测试列表功能 ：你可以说“请列出 /home/yourusername/ai_workspace 目录下的内容”。Claude 会调用 list_directory 工具并返回结果。
2. 测试读取功能 ：指定一个该目录下的文本文件（如 notes.md ），让 Claude 读取其内容。
3. 测试写入功能 ：让 Claude 根据你们的对话，生成一份总结并保存。例如：“将我们刚才讨论的关于 MCP 的要点，整理成一份 Markdown 文档，保存为 mcp_summary.md ”。

实测中的技巧与观察 ：

• Claude 在调用工具前，有时会向你 请求确认 ，尤其是进行写入操作时。这是客户端层面的另一道安全保险。
• 工具调用的结果会清晰地显示在对话流中，通常以一个特殊格式的区块呈现，里面包含了工具名、参数和返回内容。
• 如果工具调用失败（如路径错误、权限不足），错误信息也会直接返回给 Claude，它会尝试理解错误并提示你修正。

4.3 基础功能之外的扩展思考

当基础的文件读写跑通后，我们可以思考一些更实用的增强功能，这些可以作为你后续迭代的方向：

• 文件搜索工具 ( search_files ) : 输入关键词，在允许的目录内进行文件内容或文件名的模糊搜索。这需要结合 list_directory 递归和文件读取，但要注意性能，可以限制搜索深度和并发数。
• 文件信息工具 ( get_file_info ) : 返回文件的详细元数据，如大小、创建修改时间、MIME 类型等，而不读取内容。
• 操作历史与撤销 : 为 write_file 和 delete_file （如果未来添加）工具添加简单的操作日志，甚至支持一次撤销。这可以通过在服务器内存中维护一个有限长度的操作栈来实现。
• 更细粒度的权限控制 : 不仅仅是目录白名单，可以设计基于用户、基于文件类型的读写控制列表（ACL）。

5. 深入排查：开发与集成中的常见问题与解决方案

在实际开发和集成过程中，你几乎一定会遇到一些问题。下面是我在搭建过程中踩过的坑和解决方案。

5.1 服务器启动失败与连接错误

问题现象 ：Claude Desktop 启动后，侧边栏的“工具”图标显示感叹号，或对话中完全不提工具。

• 排查步骤 1：检查配置文件语法
  • 使用 JSON 验证器检查你的 claude_desktop_config.json 文件，一个多余的逗号或缺失的引号都会导致整个配置被忽略。
• 排查步骤 2：检查命令路径
  • args 中的 Node.js 脚本路径必须是 绝对路径 。相对路径在 Claude Desktop 的上下文中无法解析。在 macOS/Linux 可以使用 pwd 命令获取绝对路径，在 Windows 可以使用完整路径如 C:\Users\... 。
  • 确保 dist/index.js 文件已通过 npm run build 成功生成。
• 排查步骤 3：查看客户端日志
  • Claude Desktop 会输出运行日志。在 macOS 上，可以通过命令行运行 /Applications/Claude.app/Contents/MacOS/Claude 来在终端中查看实时日志。在日志中搜索 “mcp”、“server” 或你的服务器名 “file-io”，通常能找到加载失败的错误信息，如 “command not found” 或 “Cannot find module”。
• 排查步骤 4：手动测试服务器
  • 在终端中，用配置文件中相同的 command 和 args 手动启动你的服务器进程。例如： node /path/to/dist/index.js 。如果服务器本身有语法错误或依赖问题，此时会在终端直接报错。

5.2 工具调用无响应或返回意外错误

问题现象 ：Claude 显示调用了工具，但长时间无结果，或返回一个笼统的错误。

• 排查步骤 1：服务器端日志
  • 我们的服务器将日志输出到 stderr （通过 console.error ）。在手动测试时可以看到。但在集成环境下，需要让 Claude Desktop 捕获这些日志比较麻烦。一个调试技巧是，在开发时，可以临时将错误信息也通过 stdout 以特定的非 JSON 格式输出（但正式版不要这么做），或者写入一个本地日志文件。
• 排查步骤 2：路径权限问题
  • 这是最常见的问题。确保 ALLOWED_BASE_DIR 环境变量指向的目录 真实存在 ，并且运行 Claude Desktop 的用户进程有该目录的 读取和执行（对于目录）权限 。在 Linux/macOS 上，可能需要检查 ls -la 查看权限。
  • 我们的 resolveAndValidatePath 函数会进行路径遍历检查。如果用户请求的路径看似在基目录下但校验失败，请检查路径字符串处理逻辑，特别是 Windows 和 Unix 路径分隔符（ \ vs / ）的兼容性。使用 path.resolve() 和 path.sep 是正确做法。
• 排查步骤 3：文件大小与编码
  • 如果 read_file 失败，检查目标文件是否超过 MAX_FILE_SIZE 限制。
  • 确保读取的是文本文件。我们的实现使用 utf-8 编码读取。如果尝试读取二进制文件（如图片），会得到乱码。更健壮的实现可以先用 file-type 等库检测文件类型，如果是非文本文件，返回一个提示而非内容。

5.3 性能与可靠性考量

当工具被频繁调用时，一些潜在问题会浮现。

• 问题：频繁的 list_directory 导致服务器压力大
  • 解决方案 ：可以考虑为目录列表添加简单的内存缓存，设置一个短暂的过期时间（如5秒）。但要注意，缓存可能带来一致性问题。对于文件系统操作，更常见的优化是提供分页或过滤参数，例如 list_directory 工具可以增加 limit 和 offset 参数，或者 filter 参数（如只列出 .md 文件）。
• 问题： write_file 并发写入可能导致内容错乱
  • 解决方案 ：Node.js 的 fs.writeFile 在单个进程内是异步但非原子性的。如果多个写请求同时指向同一个文件，可能会互相覆盖。对于简单的 Server，这可以靠客户端（大模型）的“单线程”思维来避免。如果要求更高，可以在服务器端对文件路径加锁（例如使用一个 Map 存储正在写入的文件路径的 Promise），实现简单的互斥。
• 问题：服务器进程意外退出
  • 解决方案 ：使用 process.on('uncaughtException', ...) 和 process.on('unhandledRejection', ...) 全局捕获未处理的异常，至少记录日志后再优雅退出。更好的做法是使用像 pm2 这样的进程管理工具来守护服务器进程，配置崩溃后自动重启。

6. 超越文件读写：MCP Server 的生态想象与进阶方向

实现一个文件 Server 只是打开了 MCP 世界的大门。这个协议的真正威力在于其 标准化带来的生态可能性 。你的模型助手，通过不同的 MCP Server，可以拥有几乎无限延伸的能力。

• 数据库操作 Server ：暴露安全的查询接口，让大模型可以直接查询你的项目数据库（如 SQLite、PostgreSQL），获取结构化数据来辅助决策，甚至生成报表。
• 版本控制 Server ：封装 Git 命令，让模型可以查看提交历史、比较代码差异、甚至根据你的要求创建特性分支和提交。这需要极其谨慎的权限设计，可能只允许在特定分支上进行操作。
• 系统信息 Server ：安全地获取 CPU、内存、磁盘使用情况，或者监控特定进程的状态，让模型助手能帮你诊断“电脑为什么这么卡”。
• 外部 API 聚合 Server ：将多个你常用的外部 API（如天气、日历、邮件、项目管理工具）封装起来，提供一个统一的工具集给大模型。模型可以帮你规划日程、汇总未读邮件、创建待办事项。

设计一个“好”的 MCP Server 的进阶原则 ：

1. 工具设计的原子性与复合性 ：工具应该足够原子化（如“发送一封邮件”），但也要考虑常见的复合操作。有时提供一个复合工具（如“创建日历事件并发送邮件邀请”）可能更符合用户心智，但这需要在易用性和灵活性间权衡。
2. 上下文与状态管理 ：MCP 协议本身是无状态的。但有些工具可能需要上下文。例如，一个“代码解释器” Server 可能需要维护一个会话，在其中可以定义变量、多次执行代码。这可以通过让工具返回一个“会话ID”作为后续工具的输入来实现。
3. 流式响应与长时操作 ：对于可能耗时的操作（如处理大量数据），MCP 支持服务器发送事件（SSE），可以逐步返回结果，提升用户体验。
4. 配置化与可扩展性 ：我们的文件 Server 通过环境变量配置基目录。一个成熟的 Server 应该支持配置文件，允许用户动态添加新的工具或修改现有工具的行为，而无需修改代码。

手写一个 MCP Server 的过程，与其说是在编写一个工具，不如说是在为 AI 规划一套安全、可控的“行为准则”。它迫使你从 AI 的视角去思考如何与真实世界交互，如何将模糊的指令分解为精确、安全的操作步骤。当你看到 Claude 自如地浏览你指定的文件夹，并把你口述的想法整理成井井有条的文档时，那种感觉就像是亲手为它解开了一道枷锁。这个项目最深的体会是， AI 应用的最后一公里，往往不是算法问题，而是工程与设计问题 。MCP 提供了一条优雅的路径，而我们作为开发者，正是这条路径的铺设者。