Solar Human Proofreader

这是一个由人类编辑用红笔修缮过的原稿返回给你的 MCP 服务器。 把韩语原稿打磨得更容易阅读。Upstage Solar Pro 4 负责润色句子， 而事实、引用、文体是否保持不变，由代码来判定。内容不做任何增删。

这是部署在 Vercel 上使用的服务端 MCP。每天最多免费 100 次调用，超出部分 使用自己的密钥（BYOK）即可。

有什么不同

这不是一台抹去“AI 味”的工具，而是消除读者需要读两遍的地方的工具。 所以工作顺序也不是探测、代换，而是跟吃人类编辑一样。

我们不会去问模型“你到底改了多少”。 因为自己刚写的东西自己评分，从来都会偏高。修改率、数字保留、引用比对、文体判断，全部由代码来算。输入一致，结果永远一致。

编辑原则

• 红笔原则 —— 如果不能一句话说清楚为什么改，就不动笔。

• 以删减为方向 —— 意正的好编辑不做追加。如果字数增加，就会报警告。

• 语气属于作者的 —— 把书面体调成礼貌态，这也算改写。反转会被判定阻无法采用。

• 事实不可动 —— 只要原文中没有的任何一个数字或句子出现，那这份修改稿就不予采用。

工具

proofread 参数

连接方式

支持 Stream HTTP 的客户端（Claude Code、Cursor 等），直接将 URL 放入即可。

{
  "mcpServers": {
    "human-proofreader": {
      "url": "https://<your-deployment>.vercel.app/api/mcp"
    }
  }
}

Claude Code 只需一行命令即可。

claude mcp add --transport http human-proofreader https://<your-deployment>.vercel.app/api/mcp

只支持 stdio 的客户端可以加上 npx -y mcp-remote <url>。

直接让 AI 去读

为了让部署 URL 直接交给 AI 完成安装，我们同时提供了机器读取的说明。两条路径都会读取某个请求头中的部署实际地址——占位符不会被原样复制。

免费 100 次，之后用自己密钥

免费额度是以 Solar 调用 1 为单位来计算的。比如 proofread 一次等于通读 1 次 + 修改 1 次，那就扣 2 次。不以工具调用次数来计，是因为如果按工具调用次数算，同样的额度对不同人可能在量级上差十倍，上报、评估都会乱套。 readability 和 compare 不调用 Solar，不会扣减额度。 每天重置时间：KST 午夜。

想超额使用，就把自己的密钥放进 Header。不用工具参数而是放 header，是因为参数会以明文留在客户端对话记录中。

{
  "mcpServers": {
    "human-proofreader": {
      "url": "https://<your-deployment>.vercel.app/api/mcp",
      "headers": {
        "X-Upstage-Api-Key": "up_..."
      }
    }
  }
}

用自己的 Key 接入后，不再有每日上限，费用从对应提供方的账户中结算。

自行部署

git clone https://github.com/SolarLLM/human-proofreader-mcp
cd human-proofreader-mcp && npm install
cp .env.example .env.local   # OPENROUTER_API_KEY 또는 UPSTAGE_API_KEY 를 채운다
npm run dev                  # http://localhost:3000/api/mcp

vercel deploy --prod

规模变量

没有 Redis 也能工作，但 Serverless 是多实例状态，用户总数会变松。如果想要实际卡到 100 次，就去掉 Upstash Redis。

Vercel 配额及 depth：Hobby 计划函数执行时间 60 秒中断。deep（3 次）在长稿中可能超过它，所以 Hobby 上建议使用 standard 及以下，或升至 Pro（最长 300 秒）。

开发

npm test        # 결정적 계층(가독성·대조·변경률) 회귀 테스트
npm run typecheck

LLM 那层不做测试。但所有判定代码都一一测试——因为“门没有响”才是这个服务器最危险的故障。

如何计算修改率

修改率是判断“是否过度修改”的标准。如果用人单位一次，光一个助词变化也会把整个词粗算为“已修改”，大约会变成双倍数值（实际：字符 22.8% → 词元 46.9%）。所以这里按字符为单位。

用句块、段块单位去 1:1 对位的方法全部放弃了。好的修改本来就是拆长句、并短句、纳段——无论选什么单位，1:1 对应都会把“拆/并”当成“对不上”，从而把正常的修改判定为重写。通过项目“フル”（把一段拆成四段的紧急公告 8 成会被判 75%，实际只有 27%）。

整篇文字直接跑 LCS（最长公共子序列）是准确且可负担的：两屏 2 万字符对 2 万字符，只要 1.1 秒。在一轮 Solar 调用超过 20 秒的背景下，这已完全可承受。结果与 Python difflib 的字符级判断完全一致（实测 0.228 = 0.228；0.680 = 0.68）。

阈值设为 警告 30% · 中止 50%。韩语因为助词、尾词音节高度重，内容完全不同的两篇文章相似度底也有 0.65~0.70。中止线 0.50 取这个底之下、正常重改（0.25~0.45）之上，因此能够区分“认真修改”与“已被重写”。

对照门禁抓的问题

整句的添加一定会被抓到。但句中几个词的替换，不会用“给门禁”挡掉，而以 new_terms 列表显示出来——校订本来就会替换词，如果也拦截会造成大量误报。实测中，这一列表抓到过“与原始对比” → “与同规模基线对比”这一类的隐性修饰追加。

感谢

韩语中的“AI 味”问题的敏感度、文体分类体系，来自 epoko77-ai/im-not-ai。 代码没有直接复用，全部重写。本服务器的设计，也不是“去除 AI 味”，而是以“写好读的韩语”为出发点的独立项目。

许可证

MIT