HumanifyMe

HumanifyMe

让 AI 听起来像你。 · humanifyme.com

在浏览器中试用 → 无需安装，也无需密钥：粘贴几条你自己写的消息和一份 AI 草稿，即可获得一份保留你个人语气的草稿。

HumanifyMe 会学习某个特定的人的写作方式，然后在任何人看到 AI Agent 的输出之前，将其改写成那个人的语气。只需安装一次，你机器上的每个 Agent——Claude Code、Cowork、Cursor——都会用相同的语气改写内容。它不是“写得更好”，而是“不再听起来像 AI”。

它在本地运行。唯一会通过网络传输的内容，是发送给你所选大模型提供商的、经过脱敏的草稿。

快速开始

先运行安全的一次性设置程序。它会说明隐私边界，在你输入时隐藏提供商密钥，验证提供商，收集 3 份写作样本，构建你的个人资料，并提供首次改写：

npx -y [email protected] setup

想在安装前看看它的效果？设置和改写流程的在线演示见 humanifyme.com。

切勿将提供商密钥粘贴到 AI 聊天中，也不要将其作为命令行参数传递。然后从内置市场安装插件——无需克隆或构建：

claude plugin marketplace add JoshMcQ/HumanifyMe   # register the marketplace
claude plugin install humanifyme@humanifyme        # installs 3 skills + the MCP server

接着，对任何草稿使用 /humanifyme:humanify，或者让内置技能在 Agent 起草电子邮件、PR 或消息后触发它。CLI 和所有已安装的 Agent 共用存储在 ~/.humanifyme/ 中的个人资料。之后可使用 /humanifyme:build-voice-profile 添加样本或重建个人资料。

试过了吗？ 为改写评分：只需选择两个下拉选项，这类反馈最能提升语气匹配效果。

如果你在会话中途安装了插件，请运行 /reload-plugins。使用其他 Agent（Cursor、Continue、Cline、Windsurf、Zed、ChatGPT 桌面版）或 CLI？请参阅安装。

想在设置个人资料前检查草稿？分析器在本地运行，结果确定，无需 API 密钥：

echo "At its core, this robust approach paves the way." | npx -y humanifyme analyze

它会报告与公开的 90 条 AI 写作特征清单相匹配的确切短语和标点。它是编辑辅助工具，而非 AI 检测器；主观特征会继续标记为供人工审核，不会被转换成虚假的概率。

存在的意义

人们每天都把更多文字交给 AI 来写——提交信息、PR 描述、Slack 帖子、电子邮件草稿——而每个 Agent 产出的文字都带着相同的鲜明腔调：流畅、面面俱到，隐约透着企业风格。收件人已经学会识别这种腔调。常见的解决办法（Grammarly、Wordtune、“AI 人性化工具”）会把文本推向千篇一律的专业语气，这与我们的目标恰恰相反。

仅靠少样本提示无法弥合这一差距。一项大型 2025 年研究在前沿模型和数百位真实作者身上进行了数万次生成测试，发现把几段样例放进提示词，再要求模型“像我一样写”，在随意语气上会遇到瓶颈（Wang et al., 2025）。HumanifyMe 的解决方案不是写更长的提示词，而是建立一个可持久保存、可检索的你的写作语料库，再通过先改写后调整风格来重写文本。

MCP 与插件。 MCP（Model Context Protocol）是 HumanifyMe 使用的协议，因此任何兼容 MCP 的 Agent 都可以调用它的 humanify_text 工具。插件是一种打包格式（Claude Code 和 Cowork 使用），可将 MCP 服务和技能打包成一个可安装单元。你可以安装插件，也可以直接注册 MCP 服务。

工作原理

Agent 调用一个工具：humanify_text。其余操作都在你的机器上完成。

flowchart LR
    Agent["AI agent (Claude Code / Cowork / Cursor)"] -->|"calls humanify_text"| Tool["humanify_text (MCP tool)"]
    Tool --> Engine["rewrite engine"]
    Engine --> Redact["redaction"]
    Engine --> Memory["voice memory (retrieval)"]
    Engine --> Provider["LLM provider"]
    Engine --> Verify["deterministic verify gate"]
    Redact -. "masked draft only" .-> Provider
    Memory --> DB[("local store: ~/.humanifyme/data.db")]
    DB --> S["samples"]
    DB --> P["profile"]
    DB --> E["embeddings"]

重写采用先改写后调整风格的方式：去除源文本的风格，再按学习到的语气重新生成，最后通过无法被任何提示词绕过的确定性检查关卡。以下三个部分体现了这一设计：

• 确定性验证——质量护城河。 大多数“用我的语气重写”工具止步于提示词，寄希望于模型能做好。每次生成后，src/engine/verify.ts 都会针对已脱敏的草稿运行五项机械检查：模型从你的禁用词列表中引入的词语、遗漏的数字（日期、价格、版本号）、失效的 URL、消失的脱敏占位符，以及你习惯使用的大小写格式。首次尝试未通过的项目会成为一次重试的指令；仍未解决的问题会作为面向用户的“发送前请检查”提示显示。验证失败绝不会阻止输出。
• 可编辑的语气指纹。 你的语气是一个易读且带标签的 JSON 对象，包含句子长度、正式程度、直接程度、标点习惯、你会避免使用的词语、你常用的称呼语和落款，而不是不透明的向量。每个维度都可以针对不同情境（随意、专业、电子邮件、恼火等）进行专门设置，并在重写时深度合并。你可以查看并修正它。
• 检索你自己的写作。 你过去消息的嵌入向量会保存在本地，并在重写时作为少样本范例提取；结构化语气指纹则作为结构规范，并在冷启动时提供回退方案。所有 Agent 和项目共用一个持久化语气记忆，位于 ~/.humanifyme/data.db。默认嵌入器可离线运行且无需额外依赖；MiniLM 和 Ollama 是可选的纯本地升级方案。

深入了解：架构与重写流程 · 语气记忆与检索 · 数据模型。

安装

作为插件安装（从这里开始）

HumanifyMe 已打包为 humanifyme.plugin/ 中的插件：包含 .claude-plugin/plugin.json 清单、用于注册 MCP 服务的 .mcp.json，以及三个技能（humanify、build-voice-profile、humanify-pr）。仓库根目录提供了一个 marketplace 目录，位于 .claude-plugin/marketplace.json。只需两行即可完成安装，详见快速入门。

打包的 .mcp.json 通过 npx -y --package [email protected] humanifyme-mcp 从已发布的 npm 包启动服务，并固定到一个已知构建版本，因此即使是在没有检出任何代码的全新机器上，插件也能正常工作。其他 Agent 的复制粘贴式安装说明见 docs/install/。

命令行

通过 npm，只需一条命令即可完成隐私设置、提供商选择、三个示例、配置文件创建和首次改写。输入 API 密钥时会隐藏；如果中断，设置会从上次完成的步骤继续。

npx -y humanifyme setup
npx -y humanifyme rewrite draft.txt

从代码检出版本进行贡献需要 Node 22.5 或更高版本：

npm ci
npm run build
node dist/humanifyme.mjs setup

原始 MCP 注册

如果你的 Agent 不使用插件格式，请直接注册服务：

claude mcp add humanifyme -- node /path/to/repo/dist/humanifyme-mcp.mjs

该服务在一个注册表中提供 16 个 humanify_* 工具：核心工具 humanify_text，以及反馈和指标、示例添加／列出／删除、配置文件获取／构建／更新／删除、提供商设置、密钥测试、审计列表、全部清除和两个导入器。同一引擎也可脱离 MCP 通过 humanifyme CLI 运行。

它真的有效吗？

一项包含四种语域的评估：四位各有鲜明风格的写作者（随意的小写风格、正式的句首大写风格、简洁的技术风格、热情温暖的风格），每人五篇通用 AI 草稿，在开启和关闭检索的情况下进行改写，共 20 对改写结果。完整方法、原始数据和复现步骤见 docs/proof/README.md。运行日期：2026-06-24。

归属判断（健全性检查，并非证明）。 使用文体评分器，判断每篇基于检索的改写结果最接近四位写作者中的哪一位：20 篇中有 17 篇（85%）最接近其对应的写作者。对此应保持怀疑，因为我们自己也持怀疑态度——写作者之间的差异主要体现在语域上，评分器只使用了八项粗略的表层特征，而且所有误判都出现在两位使用小写风格的写作者之间。这说明整个机制确实发挥了作用，但并不能证明它复现了任何人的个人语言风格。

检索让改写结果更接近真实写作者：本次运行中，四位写作者有三位如此（距离越小越接近）。我们仍报告写作者 B 的结果，尽管检索让它更差——这项指标存在噪声，我们不会把一次退步四舍五入成进步。

写作者	开启距离	关闭距离	检索有帮助吗？
A（随意／小写）	2.35	3.38	是，效果明显
B（正式／句首大写）	3.22	2.32	否，本次更差
C（简洁／技术）	2.92	3.09	是，效果较小
D（温暖／热情）	2.47	2.69	是，效果较小

我们不声称： 让一个大模型评判另一个大模型就能构成证明（我们做过这项测试，但它只是一个较弱的替代指标）；检索对每位写作者都有帮助；MVP 已经实现了纯风格检索；或脱敏召回率能保证隐私。真正可靠的测试需要人工评估，证明文档详细说明了所有局限。

隐私

HumanifyMe 以本地优先为原则，并会在发送前进行脱敏。隐私保障体现在架构中，而非召回率指标上：引擎在你的机器上运行，隐私关键代码（src/privacy/、src/network/ 和 src/engine/verify.ts）采用 Apache-2.0 许可证，因此你可以准确查看哪些内容会被发送出去。

• 本地优先。 所有状态都存储在 ~/.humanifyme/ 下，且只能通过 HUMANIFYME_HOME 更改其位置。原始样本绝不会离开该目录。
• 密钥保存在操作系统凭据存储中。 云 API 密钥存储在 Windows Credential Manager、macOS Keychain 或 Linux Secret Service 中。如果密钥链不可用，HumanifyMe 会安全失败；绝不会退而将配置明文存储。
• 发送前脱敏。 在唯一一次网络调用之前，redact() 会将电子邮件地址、电话号码、美国地址、通过 Luhn 校验的银行卡号、API 密钥、AWS 访问密钥 ID 和 JWT 替换为带编号的占位符；之后由 restore() 还原。检索到的示例会在发送时重新脱敏——绝不信任存储时的脱敏结果。本功能按设计尽力而为，相关限制也有明确说明。
• 出站白名单 + 静态扫描。 src/network/outbound-scan.test.ts 会验证只有 src/providers 和 src/network 可以调用 fetch()，并确保所有硬编码主机都在包含 4 个条目的白名单中。
• 仅收集元数据的遥测。 审计日志和自愿提供的反馈只记录数量、延迟和字节大小，绝不记录内容。匿名分享默认关闭，且每 24 小时最多一次。

在 src/privacy/redact.test.ts 中的黄金测试样本上，脱敏功能会屏蔽全部七类预置机密，并在 20 个普通段落中不产生误报，结果完全确定。完整的方法说明见 specs/privacy-security-spec.md，这是贡献者不可违反的一套规则。

不是绕过检测的工具

HumanifyMe 不会帮助你骗过 AI 检测器，相关规范也明确说明了这一点。研究从实质上支持这一立场：检测并不可靠——检测器的可靠性存在理论上限，递归改写也能绕过大多数检测器（Sadasivan 等人，2024）；而一个擅长愚弄分类器的工具，并不能证明输出听起来像你。我们只将 AI 特征密度作为合理性下限来追踪，从不将其作为目标。

本项目依据的研究

每项设计决策都有既有研究作为依据，每篇说明也都会明确指出科学结论止于何处、我们的观点始于何处：既有研究综述 · 最先进技术综述 · 评估设计。特别是，确定性的验证关卡是针对一种明确故障模式做出的设计选择，并非经验证的已发表成果。完整的参考文献列表及链接见下文。

我为什么构建它

我希望 AI 能帮我写消息，但它始终做不到恰到好处。我写好一段内容，让它只润色一下措辞，结果它返回的却是一条完全不同、语气也不像我的消息。于是我开始尝试通过编写提示词来解决这个问题，最终就有了这个项目。

大部分代码都是我用 Claude Code（Anthropic 的 Agent 编码工具）编写的，依据的是我撰写并审阅的规范和验收标准。产品和架构决策由我做出：优先采用插件进行分发、确保所有内容都保留在本地、设置验证关卡，以及决定如何评估产品。

仓库布局

/README.md                       <- you are here
/src/                            <- the MCP server + CLI (TypeScript)
/humanifyme.plugin/              <- plugin bundle: manifest, MCP registration, skills
/prompts/                        <- LLM prompt templates for the rewrite engine
/evals/                          <- ablation runner, scorers, results
/docs/                           <- research, proof, architecture, install, data model

贡献

我们欢迎维护者加入。请先阅读 CONTRIBUTING.md，然后阅读 src/engine/rewrite.ts、src/engine/verify.ts 和 src/privacy/——这三者是本方法的核心。不可违反的规则位于 specs/privacy-security-spec.md；更改行为时，必须确保 src/network/outbound-scan.test.ts 和 src/engine/verify.test.ts 全部通过。适合新手的首批议题会标记为 good first issue。

如果 HumanifyMe 帮你摆脱了机器人的语气，请在 GitHub 上给我们一个 ⭐，并帮忙宣传。星标和贡献者能让像这样的开源项目得到更多关注。

许可证

Apache License 2.0。请参阅 LICENSE 和 NOTICE。整个代码仓库都是开源的，包括改写引擎、提示词和隐私关键模块，因此任何人都可以核实究竟有哪些数据会或不会离开设备。“HumanifyMe”是 Joshua McQueary 的商标；该许可证不授予商标权。

参考文献 — 本设计所依据的作品（每个标题均链接到经核实可访问的权威发表版本）

内容摘自项目的既有研究综述。

1. Stamatatos. 现代作者归属方法综述。JASIST，2009。
2. Koppel、Schler 和 Argamon。作者归属的计算方法。JASIST，2009。
3. Abbasi 和 Chen。Writeprints。ACM TOIS，2008。
4. Patel 等人。LISA：学习可解释的风格嵌入。EMNLP 论文集，2023。
5. Stamatatos、Bevendorff 等人。PAN 2023 跨话语作者验证概述。CLEF 2023 工作记录（CEUR-WS）。
6. Salemi 和 Zamani。RAG 与 PEFT：保护隐私的个性化。ICTIR（ACM SIGIR），2025。
7. Li 等人。教会大模型实现个性化，2023。
8. Neelakanteswara 等人。从 RAG 到风格。ACL 的 Personalize，2024。
9. Wegmann、Schraagen 和 Nguyen。同一作者，还是只是同一主题？ ACL 的 RepL4NLP，2022。
10. Wang 等人。作者表征学习能否捕捉风格特征？ TACL，2023。
11. Krishna、Wieting 和 Iyyer。STRAP。EMNLP，2020。
12. Patel、Andrews 和 Callison-Burch。STYLL，2022。
13. Wang 等人。想抓住我？还不行。EMNLP 论文集，2025。
14. Sadasivan 等人。AI 生成文本能否被可靠检测？ TMLR，2024。
15. Rivera-Soto 等人。使用风格表征进行机器生成文本的少样本检测。ICLR，2024。
16. Jangra 等人。评估个性化风格文本生成，2025。
17. Jin 等人。文本风格迁移深度学习综述。Computational Linguistics（MIT Press），2022。