中文表达 Skills 怎么选：Humanizer-zh、去 AI 味与助手对话风格

AI 参与说明（Agent：Codex）：本文根据公开仓库的 README、SKILL.md 和 skills.sh 协助调研、比较与校验，资料核验于 2026-10-10。安装量与 Star 为当天页面快照；初次调研实际执行了 Skills CLI 搜索，当次未安装候选 Skill，也未进行改写效果盲测。文中的改写对照是教学示例。运行记录：模型 gpt-6.1-sol，reasoning effort ultra，执行入口 Codex Desktop，提供方 openai；运行记录中的 CLI 版本 0.162.0-alpha.17.2（不代表桌面 App 版本）。

安装与内容修订（2026-10-10，Agent：Codex）：通过 skill-installer 安装 Humanizer-zh，并读取修订日期为 2026-09-23 的 SKILL.md，按其规则润色本文。补充中文博客的编辑流程和验收方法；保留原有热度快照与来源，未进行多模型效果盲测。运行记录：模型 gpt-6.1-sol，reasoning effort ultra，执行入口 Codex Desktop，提供方 openai；运行记录中的 CLI 版本 0.162.0-alpha.17.2（不代表桌面 App 版本）。

打磨已有中文博客稿件，可以先试 Humanizer-zh。它检查套话、重复和生硬句法，并要求保留原文信息。技术文章尤其需要兼顾阅读流畅度、术语准确性和论证完整性。本文比较几个候选，再给出正文润色的操作与验收方法；针对助手回复的规则单独说明适用范围。

A writing Skill guides the agent’s editing behavior. It does not certify who wrote a text or guarantee a result from an AI detector. Humanizer-zh 的当前说明明确区分了润色和检测。实际效果仍需对照原文检查。Humanizer-zh README

热门程度与用途

下面列出两个热门项目，再补充两个中文场景的候选。GitHub Star 表示仓库关注度，skills.sh 记录通过该目录统计的安装量。选型还需要看规则和实际改写结果。

数字核验于 2026-10-10，安装量来自 Humanizer-zh 目录页 与 Humanizer 目录页，Star 来自各项目的 GitHub 页面。后两项属于补充候选，不能称为同等热门。

Humanizer-zh：中文文章可以先试它

当前 SKILL.md 的修订日期是 2026-09-23，有 31 个检查点，涵盖空泛铺垫、公式化节奏、意义拔高、排版残留和中文句法问题。长定语、“进行＋动词”、被字句堆叠、四字词排比及万能背景句都有专门检查。SKILL.md

它的编辑优先级比较适合事实性内容：先保留信息与确定程度，再遵守文体、匹配作者声音，最后修改具体表达问题。规则要求保护代码、链接目标、front matter 和默认标题锚点；没有问题的句子可以原样保留，通常只交付终稿。SKILL.md

这次修订也值得留意：更新记录说明，旧示例中凭空增加数据、功能与经历的问题已修正，机械禁词与自评分也已取消。网上流传的早期规则和目录自动摘要，可能还保留旧描述；使用时应读当前仓库文件。CHANGELOG

可以先选一段包含事实和限定条件的稿件试用，对照原文检查，再处理整篇。技术文章应保留术语和正式程度；句子自然、关系清楚，就已经达到了润色目的。

Humanizer：热门上游，中文适配程度要另看

blader/humanizer 的当前 SKILL.md 标记为 3.1.0，检查 26 类表达问题，既看词句，也看重复的段落形状、故作重要的铺垫和读者已经知道的背景。它支持提供本人文章样本做 Voice Matching；规则和示例主要使用英语。SKILL.md、使用说明

经常处理英文的人可以考虑上游版。主要写简体中文时，先试 Humanizer-zh，再按具体的改写结果决定是否比较其他方案。

qu-ai-wei：更关注简体中文长文

qu-ai-wei 的工作范围包含句子、段落、标题和长文信息顺序。它要求保留事实、判断、证据强度、正式程度与原文声口；适用边界明确排除了翻译、繁体中文和从零写作。README、SKILL.md

默认输出包含门检、终稿和简短打磨报告，也可以要求“只输出终稿正文”。如果稿件的问题是每段都使用相同节奏、标题组织生硬或信息重复，它值得作为对照方案。需要固定标题锚点的文档，应事先限制标题与章节调整范围。README

stop-slop-cn：日常助手回复更对题

这个仓库很小，但用途贴近“LLM 说得不像人话”：它直接润色助手自己的发言，默认处理上一段回复。规则针对讨好开场、多余的后续提议、行业黑话、无关的二元对比、英文句法直译，以及过度列表化；还明确说，用户没有要求总结时，不要为了去味自动删短内容。SKILL.md

文件对单字词和部分中文用法的判断过于笼统，对免责声明与不确定性表达也有较强的禁止倾向。自然中文可以使用“查”“改”“跑”，真实的条件和不确定性同样需要保留。选用其中的规则时，应判断它能否改善具体句子。对博客正文，优先使用 Humanizer-zh 的文体与信息保护规则。

仓库名是 stop-slop-cn，文件中的 Skill 名称实际是 stop-slop。它适合作为中文对话规则的参考，不宜仅凭名称就当成通用文章润色器。SKILL.md

怎样试用并判断效果

先选一个 Skill，试用后再决定是否增加其他规则。下面的命令需要 Node.js 与 npm，安装目标是 Codex。搜索命令已实际执行；安装采用 Codex 的 skill-installer 完成，此处保留 Skills CLI 的安装示例。参数已通过 Context7 核对当前官方文档。Skills CLI README

# 搜索，不安装；本次实际执行了这条命令
npx skills find humanizer

# 安装示例：将 Humanizer-zh 安装到 Codex 的用户级目录
npx skills add op7418/Humanizer-zh --skill humanizer-zh --agent codex --global

搜索结果应包含 op7418/humanizer-zh@humanizer-zh。安装后，按所用 Agent 的要求重新加载 Skills 或开始新会话；确认它识别到 humanizer-zh，再提交待编辑文字。Skills CLI README

可以使用下面的任务模板。它是本文建议的调用约束，不是某个项目的固定接口：

使用 humanizer-zh 润色下面的中文，只输出最终正文。

读者是开发者，保持技术文章的正式程度。
保留所有事实、数字、术语、条件、否定、归因和确定程度。
不补充数据、经历或结论，不把正文改成摘要。
已有标题、代码、链接目标和 front matter 保持原样。

下面是作者自己写的两段样本，只参考表达方式，不移入其中的事实：
[文风样本]

待编辑正文：
[待编辑文本]

验收重点是“读得顺，意思也保住了”。可以用一段短文先检查，再扩展到整篇。以下是本文编写的教学例，不是候选 Skill 的实测输出：

原文：接下来，我们将深入介绍导出功能的最新进展。团队昨天增加了 CSV 导出；PDF 导出仍在开发，预计下周进入测试。

改写：团队昨天增加了 CSV 导出。PDF 导出仍在开发，预计下周进入测试。

这里删掉的是只预告下文的开场。改写仍须保留“昨天”“仍在开发”“预计下周进入测试”；若写成“现在支持 CSV 和 PDF 导出”，句子虽然更短，却把计划变成了已完成功能。

实际试用时，至少核对这四项：

1. 数字、对象、条件、否定、时间与完成状态是否一致。
2. 是否保留作者判断与必要的不确定性，有没有把“可能”改为“必然”。
3. 正文是否更清楚，段落之间仍连贯，文体与读者是否合适。
4. 代码、链接、front matter、标题锚点是否完整。

把润色放进博客写作流程

对于需要调研的技术文章，先完成事实稿：回答主题问题，核对来源、示例和适用条件，再用 Humanizer-zh 编辑表达。润色时发现资料缺口，应回到调研阶段补齐，不能靠改句子补出事实。这是本文建议的写作顺序。

在本站的 Markdown / MDX 内容中，表达润色默认保护 front matter、标题锚点、英文 slug、链接目标、代码、Mermaid 语法和 MDX 组件。修改这些内容需要另做相应核验。已有草稿状态也应保留；文章读起来更顺，不能单独作为发布既有草稿的依据。

如果有作者自己的文章样本，可以借鉴句长、用词和叙述节奏。样本中的经历、数据和立场属于另一篇文章，应留在原处。没有样本时，就保留目标稿件已有的文体，不强行增加口头禅、网络梗或第一人称经历。

最终交付应是一篇能独立阅读的文章。修改过程、自评分和模式命中清单留在编辑记录中；正文保留读者需要的结论、解释和证据。

关联阅读

• 技术文档改写规范：固定英文术语、中文解释与 Mermaid 一致性：润色中文时怎样保护术语、代码和链接。
• 本地 Agent Skills 安装清单：区分已经安装、当前可用与本次实际加载的 Skills。
• Agents Overview：浏览相关工具与工作流。