我有12篇未发布的文章一直停留在草稿中。MCP服务器解决了这个问题。
Source: Dev.to
请提供您希望翻译的文章正文内容，我将为您翻译成简体中文。
我是一个通过写作学习的开发者…但我从未完成
硬盘上那堆半成品文章的墓地才是真正的写照：12 份草稿 我真的打算发布。主题是我觉得有趣的、我已经解决的问题、我认为值得分享的东西。每一篇都在 “粗略想法” 与 “足够好可以发布” 之间的某个阶段被抛弃。
这不是写作障碍，而是 摩擦：
- 研究已有的内容覆盖情况
- 在编辑器、Dev.to 和我的笔记之间来回切换
- 格式化、标签、系列选择
这些并不难，但全部加在一起形成了足够的阻力，以至于我的大脑会去寻找更即时的奖励——比如再修复一个 bug 或阅读别人的成品文章。
我每天都在使用 AI 工具。Claude Code 负责繁重的工程工作。我把代码库交给它，它帮我重构、调试并一起规划。但当涉及写作——我一直说想多做的事——我仍然全手工操作。
于是我搭建了一座桥梁：一个 MCP 服务器，直接把 Claude 与 Dev.to 连接起来，把整个发布工作流变成一次对话。
它不仅帮助我更快地发布，还彻底改变了发布的心理过程。
当摩擦消失时会有什么变化
我注意到的最大变化不是速度，而是我不再说服自己放弃。
| 之前 | 之后 |
|---|---|
| 我有一个想法 → 打开空白文档 → 开始输入 → 发现不知道是否已经有人写过 → 在另一个标签页打开 Dev.to → 花约 20 分钟搜索 → 失去思路 → 关闭标签页 → 告诉自己稍后再回来（通常也不回来）。 | 我有一个想法 → 打开 Claude Code 并说 “search Dev.to for articles about X — what’s already covered and what’s missing?” → 30 秒后我得到该主题的全景图，准确知道我的切入点在哪里，空白页的问题消失了，因为我是从对话开始，而不是从无到有。 |
仅仅这一步的研究就让大多数文章在起步前就被扼杀。去掉它，一切都改变了。
起草 也不同了。我不再是向空虚写作并期待它成功。我描述想说的内容，Claude 起草，我再把它塑造成自己的声音，结构已经就位。我在编辑，而不是在开始。编辑很容易，开始很难。这把工作从困难的部分转移到了容易的部分。
一旦起草完成——发布实际上只需要一条信息：
“Looks good, publish it.”
完成。
工作流实践
以下是一段实际会话的示例，从构思到发布：
Me: "I want to write about setting up a local MCP server for Outlook.
Search Dev.to — what's already covered on this topic?"
Claude: [searches Dev.to]
"There are a few articles on MCP setup generally, but nothing
specifically about Outlook or email automation workflows.
Strong gap to write into."
Me: "Good. Check my existing series — does this fit anywhere?"
Claude: [checks my articles and series]
"You have an 'AI‑Powered Developer Workflows' series.
This fits perfectly as the next entry."
Me: "Write it. Focus on the local server setup and the automation
angle. Keep it practical, not theoretical. Draft it on Dev.to."
Claude: [writes article, creates draft]
"Draft created. ID: 3341092. Ready for your review."
Me: "The setup section needs more detail — add the exact config file
path and a sample rule."
Claude: [updates the draft]
Me: "Perfect. Publish it."
Claude: [publishes]
"Live at https://dev.to/themeticulist/..."Start → published: 一次对话完成全部流程。无需切换标签页、复制粘贴，也不会出现上下文丢失。
这篇会话产出的文章已经发布在我的 Dev.to 个人主页上，拥有互动和评论。若没有这次会话，它只会停留在草稿 #13。
如何自行设置
服务器的源码位于 yashaswiyogeshwara/devto-mcp。按照以下步骤运行它。
1. 获取你的 Dev.to API 密钥
- 前往 Dev.to → Settings → Extensions → DEV Community API Keys。
- 生成一个新密钥并妥善保存。
2. 克隆并构建
git clone https://github.com/yashaswiyogeshwara/devto-mcp.git
cd devto-mcp
npm install
npm run build3. 创建你的 .env 文件
# devto-mcp/.env
DEVTO_API_KEY=your_key_here4. 将其添加到 Claude Desktop
打开 %APPDATA%\Claude\claude_desktop_config.json 并添加：
{
"mcpServers": {
"devto": {
"command": "node",
"args": ["C:/path/to/devto-mcp/dist/index.js"],
"env": {
"DEVTO_API_KEY": "your_key_here"
}
}
}
}重启 Claude Desktop。Dev.to 工具会自动出现在 MCP 面板中。
5. 对于 Claude Code 用户
将相同的块添加到 claude_mcp_config.json（通常位于 %APPDATA%\Claude\claude_mcp_config.json）。Claude Code 会在下次启动时读取。
服务器能做什么
八个工具覆盖完整周期：
| Tool | Purpose |
|---|---|
search_articles | 查找已经发布的任何主题。可按标签、作者或热度过滤。写字前先运行此工具。 |
list_my_articles | 显示您已有的内容，Claude 可建议新文章的定位。 |
list_series | 列出您的系列，帮助避免重复条目。 |
create_draft | 直接保存到 Dev.to，published: false。在浏览器中审阅后再上线。 |
update_article | 对草稿进行迭代——“让此段更具体”，“删掉引言”，“添加代码示例”。 |
publish_article | 一键发布草稿。 |
delete_draft | 清理不需要的草稿。 |
add_tags | 为草稿或已发布文章添加标签。 |
这些工具让您研究、计划、写作、编辑和发布，全程无需离开与 Claude 的对话。
TL;DR
摩擦会扼杀写作。 通过将 Claude 直接连接到 Dev.to 并使用 MCP 服务器，研究、起草和发布步骤变成了无缝对话。结果呢？发布更快，草稿被抛弃的情况更少，对你的想法能够顺利面世更有信心。试一试——未来的你会感谢自己的。
Publishing — publish_article 是一个有意的、独立的步骤。一次消息即可发布。分离很重要：你始终清楚何时将要上线。
Tracking — get_article_analytics 返回任意文章的反应计数和评论。
值得了解的一个坑
如果你在此基础上构建或进行自定义：不要在文章正文中放置 YAML front‑matter。Dev.to API 有一个怪癖，body_markdown 中的 front‑matter 会悄悄覆盖你的 JSON 参数——你的标签会被替换，系列会消失。服务器已经对此进行防护，如果检测到 front‑matter 会抛出明确的错误，但了解其原因仍然很有价值。
对我而言实际改变了什么
我在过去一个月里发表的文章数量超过了前一年。这并不是因为我突然有了更多的想法或时间——而是因为“我应该写这个”和“这篇文章已经发布”之间的步骤，从需要多次会话的艰巨过程，缩短到了只需一次对话。
工具并不会替我写文章。我的声音、我的例子、我的视角——仍然必须由我自己提供。但它会处理写作周边的所有事务：研究、结构、格式、发布机制。它把写作从一个项目变成了一场对话。
如果你有一堆未发表的草稿，那就是值得先解决的问题。
本文使用它所描述的 MCP 服务器撰写。