DSH 实际操作（一）：接入 MCP 工具链，让 DeepSeek 读代码、改文件、跑测试

一、这篇做什么

上一篇讲了 DSH（DeepSeek Harness）的安装与排错，装好之后它默认只能"聊天"。真正让它干活的是 MCP（Model Context Protocol）工具：接上文件系统、终端、抓取等工具后，DSH 就能读你的代码库、改文件、跑测试命令。本文记录一次完整的实操：把一个本地小项目交给 DSH，让它定位一个报错并修复。MCP 的完整配置说明与更多 server 清单可以在 https://deepseekdsh.com/ 的 MCP 专页查到。

二、准备：确认 DSH 能正常启动

先按安装篇把 DSH 跑起来（npx @deepseek-ai/dsh web 或桌面端），确认对话界面能打开、API Key 已填、随便问一句有回复。这一步不通先别碰 MCP，九成问题出在基础环境。

三、第一步：接入 filesystem 工具

打开 MCP 配置（设置界面或项目根目录的配置文件），写入 filesystem server：command 为 npx，args 为 ["-y", "@modelcontextprotocol/server-filesystem", "D:/projects/myapp"]。args 最后一个参数是允许访问的目录——只给项目目录，不要给整个磁盘。保存后重启 DSH，在工具列表里确认 filesystem 出现。验证一下：问它"列出项目根目录的文件"，能返回真实文件列表就是通了。

四、第二步：给它一个真实任务

任务描述要具体，这是实操里最容易翻车的地方。反例："帮我看看这个项目有什么问题"——它只能泛泛而谈。正例分三段说清：1. 现象："运行 npm test 时 user.test.js 里有 2 个用例失败"；2. 目标："定位失败原因并修复，不要改动测试文件本身"；3. 边界："只允许修改 src 目录下的文件，改完重新跑一遍测试确认"。DSH 会先读相关文件、给出它的判断，然后请求执行修改和命令。每一步工具调用界面上都会显示，等它跑完再看结果，不要中途连发新指令打断它。

五、第三步：看它改，盯住三件事

实操中重点盯：① 它读的文件对不对（读错文件后面全错）；② 改动是否超出你给的边界（比如顺手"优化"了无关代码，要当场指出回滚）；③ 测试是真跑了还是嘴上说跑了——终端输出里有真实的命令和结果才算数。

六、常见问题

• 工具列表里没有 filesystem：多半是 JSON 格式错误（尾随逗号最常见）或 npx 拉包失败，先在终端单独运行一遍那条 command 验证。
• 调用工具时超时：首次调用要下载 server 包，慢是正常的；反复超时检查网络与 npm 源。
• 它说没有权限访问文件：检查 filesystem 的目录参数是否覆盖了目标文件所在路径。

七、小结

MCP 接入只需一次配置，之后的日常开发就是"描述现象、划定边界、验收结果"三件事。更多 server 的接入写法和组合用法，https://deepseekdsh.com/ 的 MCP 专页有持续更新的清单。下一篇讲插件：把这类配置打包成一键可装的能力扩展。