Humanizer Agent Skill：检测、改写、校验去除AI味

1. 先弄明白 Humanizer 到底在治什么毛病

1.1 “AI 味”不是玄学，它有几个非常具体的特征

很多人第一次接触 Humanizer 这个 Agent Skill，都是被同一件事逼的：文字内容没错、逻辑也通，可读者一眼就说“这是 AI 写的”。问题不在于“AI”两个字，而在于一大类高度可识别的文本模式，我把它拆成几层来看。

最外层是句式机械。通篇句长差不多，二十来个字一句，像用尺子量过；主语永远是“我们”“它”“这”，缺省和倒装几乎不出现。往里一层是连接词泛滥，“首先、其次、此外、值得注意的是、不仅如此”这类显式逻辑标记堆满全文，读起来像一份会议纪要而不是一个人在说话。再往里是抽象词占比过高，“提升效率”“优化体验”“赋能业务”这类词可以套在任何项目上，读者拿不到任何具体信息。

最隐蔽的一层是过分完整。真人写东西会犹豫、会插一句“这里我可能记错了”、会写到一半回头补个限定条件；而模板化的输出永远结论前置、每段等长、结尾必总结，干净得像被擦过一遍。这层最难改，因为它不在词上，在节奏和留白上。

Humanizer 这个技能要做的事情，不是把文章改得“差一点”“随便一点”，而是把上面这四层里不自然的部分还原掉，同时把原文的事实、术语、数字原样保住。这个边界如果一开始划不清，后面调参就会一路跑偏：要么改了个寂寞，要么把一篇技术文档改成了朋友圈段子。

1.2 它和“直接在提示词里写一句去 AI 味”有什么区别

我见过不少人说，这事不就是提示词里加一句“请用口语化、拟人化的风格输出”吗，何必单独做成一个 Skill。区别其实挺大，主要在三点。

第一是可复用。命令式的提示词散落在几十个业务模板里，改一次风格要把所有模板翻一遍；做成 Skill，就是一份带检测规则、改写规则、参数配置的独立资产，所有 Agent 调用同一份。

第二是可分步。提示词是“一把梭”，模型要在一次生成里同时干“想内容”和“调语气”两件事，结果常常是内容被语气带跑。Humanizer 做成 Skill 后可以拆成检测、改写、校验三段，每段只干一件事，可控性高出一截。

第三是可度量。提示词改完，你只能说“我感觉好点了”；Skill 可以输出一份打分明细：句长方差多少、连接词密度多少、高频套话命中几处。有没有改善，数字说了算。这一点在我后来做批量内容处理时特别关键，因为你要处理的是几百篇稿子，靠肉眼抽查根本不够。

提示：Humanizer 的定位是“文风后处理”，不是“内容生成”。它不应该替你想论点、编事实。一旦发现它开始补内容，说明参数给太松了。

1.3 谁适合用，谁其实用不上

适合的人其实很集中。一类是内容批量化生产的团队，比如同一套产品说明要出几十个版本，人工润色成本顶不住。一类是Agent 产品开发者，模型直接面向终端用户输出，文风本身就是产品体验的一部分。还有一类是自己写东西的人，用它做初稿到定稿之间的那道工序，把机械感先刮掉，再人工补细节。

用不上的场景也很明确。如果你要的是严谨的公文、法律条款、标准操作规程，那些文体本来就要求句式和用词高度统一，humanize 反而会引入歧义。另外，如果原文本身就没什么信息量，改写只是在包装空话，那不管怎么调，读者还是能看出来——这类问题得回到内容层解决，工具救不了。

2. 拆开看：Humanizer 技能内部是怎么分层的

2.1 三层结构：检测、改写、校验

一个能用的 Humanizer 技能，我建议按三层来搭，缺一层就会出问题。

检测层负责给文本做体检。它不算“好不好”，只算“像不像模板”。常见的可量化指标有这么几项：句长标准差（太低说明节奏平）、显式连接词密度（每千字出现次数）、高频套话命中数（对照一份词表扫）、段落长度方差、被动句占比、四字格密度。这几项不需要多精确，能横向对比就够了。

改写层是真正动手的地方，按检测结果有选择地下刀，而不是通篇重写。哪一段句式太齐就拆哪一段，哪一段连接词太密就砍哪一段。这种“定点处理”比整篇重写的好处是，原文的信息结构不会被打乱。

校验层负责兜底，做两件事：一是把改写后的文本再跑一遍检测，看指标有没有真的降下来；二是做保真比对，把原文里的数字、专有名词、代码片段、引用块逐个核对，确认没被改掉。第二件事比第一件重要得多，我后面会专门讲踩过的坑。

2.2 改写层的六种常用手法，按风险从低到高排

手法排序很重要，因为低风险的手法可以先上，高风险的要谨慎。

第一种，砍连接词。把“此外”“与此同时”“值得注意的是”直接删掉，让逻辑靠语序和内容本身承接。这一步几乎零风险，收益也明显，是最应该先做的。

第二种，句长打散。检测到连续三句长度接近，就把中间一句拆成两句短的，或者把两句合成一句长的。人写东西本来就有长短起伏，这一步做完，整篇的呼吸感就出来了。

第三种，抽象词具体化。把“显著提升处理效率”换成“原来要跑四十分钟的批次，现在十二分钟出结果”。这一步需要原文里有对应事实，没有就别硬编，宁可保留抽象表述。

第四种，注入第一人称判断。适当加“我个人更倾向”“这里我保留意见”“实测下来不太行”。注意是“适当”，一篇里出现三四次就够，多了就成了刻意。

第五种，语序调整。把结论前置改成过程前置，或者反过来；把长定语从句拆成两个短句。这一步风险中等，改多了会影响可读性。

第六种，语气词和口语填充。“说白了”“讲真”“这事儿”这类词能快速拉近距离，但它是最容易过量的手法，也是最能暴露“假口语”的手法。一段里塞三个，读起来比原文还假。

2.3 该改的和绝对不能碰的，得先划条线

这条线如果一开始不划，后面一定会返工。我的做法是建一份保护清单，写进技能配置里，改写层直接跳过这些内容。

必须保护的有：代码块和命令行、术语表里的专有名词、所有数字和单位、引用块原文、表格里的字段名、链接和文件路径、API 名称和参数名。这些内容一旦被“润色”，轻则失效，重则造成实际故障。

可以放开的有：段落之间的过渡句、举例前的铺垫、总结性表述、形容程度的副词、重复表达同一意思的并列句。

边界模糊的有：作者本人的观点句。这类句子改写时容易把语气改掉，我一般设成“只允许调整语序，不允许替换词汇”，或者干脆标成只读。实际做下来，观点句保持原样反而更好，因为那才是文章里最有“人”的部分。

3. 安装与接入：把技能挂到 Agent 上

3.1 目录结构和一个能跑的技能描述文件

不管底层用哪套 Agent 框架，技能的组织方式大体相似：一个目录，一份描述文件，若干规则和脚本。我习惯用下面这个结构，跑过几个项目都没出问题。

skills/ humanizer/ SKILL.md # 技能描述，Agent 靠它判断何时调用 config.yaml # 参数配置 rules/ tropes_zh.txt # 高频套话词表 connectors_zh.txt # 连接词词表 protect.txt # 保护词表 scripts/ detect.py # 检测打分 rewrite.py # 分段改写调度

SKILL.md是整个技能的门面，Agent 在决定要不要调用它时，读的就是这份文件。写法上有个要点：描述里要写清楚“什么时候用”和“什么时候不用”，只写“用于优化文风”这种话，模型很容易在不该调的时候也调。

--- name: humanizer description: 文本文风后处理技能。当需要把模板化、机械感的文本改写为更自然的表达时使用； 当文本为法律条款、标准操作规程、代码注释、API 文档字段说明时不要使用。 version: 0.3.1 inputs: text: 待处理文本，必填 style: 目标文体，可选，默认 tech-blog strength: 改写强度 0.0-1.0，可选，默认 0.5 protect: 保护词列表，可选 outputs: text: 改写后文本 report: 检测与改写明细 ---

配置文件和词表是分开的，好处是改词表不用动逻辑。词表本身不用追求大而全，我第一版只放了六十来条，后面按实际命中的情况往里加，比一次性堆几百条管用。

humanizer: strength: 0.5 locale: zh style: tech-blog protect: - "```" - "TODO" limits: max_rewrite_ratio: 0.35 # 单段被改动字符占比上限 max_rounds: 2 # 最多迭代轮次

3.2 三种接入形态，各自的适用面不一样

第一种是技能自动加载。Agent 在运行时读SKILL.md的描述，判断当前任务要不要用这个技能。好处是零改造，坏处是触发不稳定，模型有时候觉得“这段已经挺自然了”就不调。我的经验是在技能描述里补几个典型触发语句，命中率会明显提高。

第二种是显式工具调用。把 humanize 包成一个函数，Agent 自己决定调不调、传什么参数。这种方式最可控，代价是你要在系统提示里教会模型什么时候该调。

# 伪代码，示意接口形态 def humanize(text, style="tech-blog", strength=0.5, protect=None): report = detect(text) if report.score < 0.3: # 本身就不机械，直接返回 return text, report chunks = split_by_paragraph(text) out = [] for c in chunks: if is_protected(c, protect): out.append(c) continue out.append(rewrite(c, style, strength, report)) return "\n\n".join(out), report

第三种是后处理中间件。模型先正常输出，输出的内容再统一过一遍 humanizer。这种方式适合已经上线的产品，改造量最小，缺点是会多一次调用开销，而且原始输出里的问题已经被固定下来了，改写空间变小。

我一般推荐前两种搭配用：创作类任务走工具调用，客服、邮件这类模板化输出走中间件。混着用的项目也不是没有，但配置会变得很乱。

3.3 参数怎么调：一份实测过的取值参考

strength是最关键的一个参数，它决定了改写的激进程度。调这个参数别一步到位，从低往高走。

除了强度，还有两个参数值得单独说。max_rewrite_ratio控制单段被改动的字符比例，设成 0.35 的意思是每段最多改三分之一，剩下的保持原样，这样能防止整段被“洗”一遍导致信息丢失。max_rounds控制迭代轮次，我一般设 2，因为第三轮之后收益就非常小了，反而容易把句子改得别扭。

提示：调参时一定固定一组测试样本，每次只改一个参数，对比报告里的指标变化。凭感觉调，调到后面会发现自己在原地打转。

4. 使用方法：一次完整调用是怎么跑起来的

4.1 最小可用流程，四步走完

第一次上手，建议不要整篇丢进去，按下面这个流程走一遍，能快速建立手感。

第一步，先跑检测。把原文丢给检测层，看报告里哪几项超标。如果只有“连接词密度”超标，那就只砍连接词，别动句式，这时候 strength 给 0.2 就够。

第二步，分段。按段落切，别按句子切。句子级别改写容易破坏上下文的指代关系，出现“它”指代不明的情况。切的时候把代码块、引用块、表格整体作为一个块处理，不拆。

第三步，改写并保留报告。每一段改写后记录改了什么、改了多少字符。这份明细在后续人工抽检时非常有用，可以直接定位到改动最大的段落重点看。

第四步，回读校验。校验层跑一遍，然后人工抽三段读。我一般抽开头段、中间最长的一段、结尾段，这三段最容易暴露问题。

整个流程跑下来，一篇两千字的稿子大概两三分钟，比手工润色快得多，但不能省掉人工抽检。这是我现在最坚持的一条。

4.2 提示词模板和分文体配置

技能内部改写用的提示词，和用户直接对话用的提示词不是一回事。它需要更强的约束，因为改写层不看全文，只看一段，很容易改跑。我用的模板大致长这样：

你在做文风修订，不是重写。 任务：让下面这段文字读起来更像真人写的，同时严格保留所有事实。 必须保留：数字、专有名词、代码片段、引用原文、专有术语。 可以做：删除显式连接词、长短句交替、把抽象表述换成同义但更具体的说法（仅当原文有依据）。 不要做：添加新信息、删减论点、改变语气强度、使用网络流行语超过一处。 强度：{strength} 文体：{style} 原文： {chunk}

分文体配置这块，差别比想象中大。技术博客允许第一人称和口语，产品文档要求克制，社交媒体可以短句连发、允许省略主语，邮件介于中间，需要保持礼貌但去掉套话。我一般给每类文体单独存一份配置，切换时整体替换，而不是在一个配置里用一堆 if。

4.3 怎么判断“人味”够了：三个验收标准

改完之后，我一般用三个标准过一遍，比看分数直观。

第一，读出来顺不顺。默读一遍，如果某句读着要喘口气，说明太长了；如果连着四五句都是短句，说明节奏太碎。这一条最主观，但也最准。

第二，遮住开头看结尾。把第一段遮住，只看结尾。如果结尾像一句总结陈词，而且是那种放之四海皆准的总结，那基本没改到位。真人写东西结尾往往是一个细节、一句感慨，或者干脆直接停。

第三，找人读一段。随便找个没看过原文的人，读一段问他“这是人写的还是机器写的”。判断不一定准，但如果对方犹豫了，说明改得还行；如果对方秒答“AI”，那还得再来一轮。

分数可以看，但别唯分数。我遇到过指标全绿、读起来依然假的情况，因为指标只能抓显性特征，抓不到语气里那种“过分周全”的感觉。

5. 案例应用：四个场景的实际处理过程

5.1 场景一：技术文档改成可读的分享稿

这是最典型的用法。原文往往长这样：

本项目通过引入缓存机制，显著提升了数据查询效率，为系统的高并发场景提供了有力支撑。

改完的目标不是“更好听”，而是“有具体信息”。按流程走：检测发现连接词密度正常，但句长方差极低、抽象词占比高。strength 给 0.5，改写时把“显著提升”落到实处。如果原文里有数据，就换成数据；如果原文没有，就改成“具体提升多少我没测，但原来要等三秒的查询现在基本秒回”这种带限定的表述，而不是编一个数字。

这一步的关键是允许不确定。真人写东西经常带不确定表达，“大概”“可能”“我没细测”。这种表达在模板化文本里几乎绝迹，但它恰恰是“人味”的重要来源。当然前提是真的不确定，不能拿它当挡箭牌掩盖没做的工作。

改完对比一下：连接词没动，句式长短混开了，抽象表述换成了一个具体现象，结尾从总结句改成了“这块后面还得再看看并发下的表现”。整段读下来，像是一个人在讲自己做过的事。

5.2 场景二：短文本的语感调整，比长文难

短文案是最难改的。长篇有足够的上下文可以铺，短文案就一两句话，每个字都在放大镜下。这类文本我一般把 strength 直接给到 0.7，但保护清单要拉满，因为短文案里往往有产品名、活动名这些不能动的东西。

常见的问题是开头太工整。模板化的短文案喜欢用对仗、喜欢用“在……的今天”起手。改的时候我一般直接砍掉铺垫，从具体动作或具体场景切入。比如把“随着用户需求的不断变化，我们推出了全新版本”改成“新版上线了，主要改了三处”，信息量更大，也更快进入正题。

另一个问题是感叹号密度。模板文本喜欢用感叹号提气，一段里能出现三个。真人在社交平台上写东西，反而很少连着感叹，更多是句号甚至不加标点。这一项在检测层里可以单独统计，超过阈值就整体降下来。

5.3 场景三：邮件和客服话术，礼貌和自然之间要找平衡

这类文本的约束最多：不能太随意、不能有歧义、不能带情绪。但模板化的毛病也最重，“感谢您的支持与理解”“如有任何疑问请随时联系”这类句子几乎每封都有。

处理这类文本，我的策略是只做减法不做加法。删掉重复的客套、删掉不必要的连接词、把长句拆短，但不往里加口语词。原因是客服场景里，过度口语反而会让人觉得不专业，或者觉得在敷衍。

一个具体的处理例子：把“关于您反馈的问题，我们已进行核实，现将相关情况回复如下”改成“您说的问题我们查了，情况是这样”。礼貌度确实降了一点，但可读性上来了。这类改动要不要做，取决于对方是谁——正式商务往来就别动，日常沟通可以动。所以我在配置里加了一个formality字段，专门控制这一档。

5.4 场景四：中英文的 humanize 重点完全不一样

同一套逻辑，换语言就得换规则，这点很多人会忽略。

中文的问题集中在四字格和连接词。“持续优化”“全面提升”“进一步加强”这类词，密度一高就露馅。另外中文模板文本很少省略主语，真人写东西经常省，读起来更轻。改写时适当省略主语、减少“的”字堆叠，效果很明显。

英文的问题在另一头。高频的模板词是“delve into”“leverage”“seamless”“robust”这一类，还有大量的“It is important to note that”。改法上，多用缩写形式（it's、don't）、多用破折号和短句、允许句子以 And 或 But 开头。这些在正式写作里可能被扣分，但在分享类文本里恰恰是自然的标志。

我的做法是规则词表按语言分开存，检测逻辑共用，词表各自维护。这样加一门语言只要补一份词表，不用动代码。

6. 常见问题与排查速查表

6.1 症状、原因、处理，一张表看完

跑了一段时间，问题基本集中在下面这几类，我整理成了表，遇到直接对号入座。

表里最危险的是最后一条。术语被改掉、代码被改乱，你还能一眼看出来；事实被悄悄改动，可能要到很久以后才被发现。所以保真校验这一步，我现在是强制开启的，不管多短的文本都跑。

6.2 几条踩过坑之后才明白的经验

别整篇改写，一定分段。我最早图省事，整篇丢进去让模型一次改完，结果前三分之一改得挺好，到后面模型开始“疲劳”，越改越敷衍，最后一段基本原样返回。分段之后这个问题就没了，而且出问题也只影响一段。

保护清单要往宽了设。一开始我按“必要”来设，结果漏了一堆东西。后来改成“宁可多保护”，凡是拿不准的一律保护。代价是有些该改的没改，但比改错强太多。

口语词是有配额的。“说白了”“讲真”“实测下来”这类词，一篇里出现两三次是调味，出现十次就是新的模板。我在配置里给每个词设了出现上限，超了就自动替换成普通表达。

校验一定要留原始版本。改写是破坏性操作，出了问题必须能回滚。我的做法是每次改写前存一份原文，改写后存一份 diff，出问题时按 diff 定位到具体段落重来，而不是整篇重跑。

检测分数只是参考，别当 KPI。有段时间我盯着指标调，把分数压得很低，结果文章读起来磕磕巴巴。后来想明白了，指标是用来找问题的，不是用来追求最优的。真正的标准还是那句：读起来像不像一个人在说话。

最后一点，也是最重要的：Humanizer 治不了空内容。如果原文本来就没有具体信息、没有真实细节、没有个人判断，那不管怎么改，读者还是能感觉到空。这个技能能做的是把已有的东西擦干净，擦不出本来没有的东西。我在实际项目里的做法是，先确认内容层过关，再上这一道工序，顺序反了纯属浪费时间。