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, styletech-blog, strength0.5, protectNone): 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是最关键的一个参数它决定了改写的激进程度。调这个参数别一步到位从低往高走。取值主要动作适用场景风险0.2只删连接词和套话公文、说明文档几乎无0.4加句长打散技术博客、产品文档低0.6加口语化表达、第一人称个人分享、社区帖中需人工抽检0.8大幅调整结构与语序社交媒体短文案高易失真1.0近乎重写不建议用术语和事实易丢除了强度还有两个参数值得单独说。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”。改法上多用缩写形式its、dont、多用破折号和短句、允许句子以 And 或 But 开头。这些在正式写作里可能被扣分但在分享类文本里恰恰是自然的标志。我的做法是规则词表按语言分开存检测逻辑共用词表各自维护。这样加一门语言只要补一份词表不用动代码。6. 常见问题与排查速查表6.1 症状、原因、处理一张表看完跑了一段时间问题基本集中在下面这几类我整理成了表遇到直接对号入座。症状大概率原因处理办法术语被改掉保护清单没覆盖把术语补进 protect重跑数字变了改写层没做数字锁定检测层加数字提取比对失败即回滚该段代码块被改乱分段时没识别块结构按块切分代码块整体跳过通篇变成网络腔strength 给太高降到 0.5 以下限制口语词出现次数前后风格不一致整篇一次性改写分批改写后统一做一次风格对齐改完更啰嗦只加不减开启“删减优先”模式先砍再加引用块被污染没识别引用语法引用行整行跳过改完事实变了改写层越界补内容收紧提示词明确禁止新增信息表里最危险的是最后一条。术语被改掉、代码被改乱你还能一眼看出来事实被悄悄改动可能要到很久以后才被发现。所以保真校验这一步我现在是强制开启的不管多短的文本都跑。6.2 几条踩过坑之后才明白的经验别整篇改写一定分段。我最早图省事整篇丢进去让模型一次改完结果前三分之一改得挺好到后面模型开始“疲劳”越改越敷衍最后一段基本原样返回。分段之后这个问题就没了而且出问题也只影响一段。保护清单要往宽了设。一开始我按“必要”来设结果漏了一堆东西。后来改成“宁可多保护”凡是拿不准的一律保护。代价是有些该改的没改但比改错强太多。口语词是有配额的。“说白了”“讲真”“实测下来”这类词一篇里出现两三次是调味出现十次就是新的模板。我在配置里给每个词设了出现上限超了就自动替换成普通表达。校验一定要留原始版本。改写是破坏性操作出了问题必须能回滚。我的做法是每次改写前存一份原文改写后存一份 diff出问题时按 diff 定位到具体段落重来而不是整篇重跑。检测分数只是参考别当 KPI。有段时间我盯着指标调把分数压得很低结果文章读起来磕磕巴巴。后来想明白了指标是用来找问题的不是用来追求最优的。真正的标准还是那句读起来像不像一个人在说话。最后一点也是最重要的Humanizer 治不了空内容。如果原文本来就没有具体信息、没有真实细节、没有个人判断那不管怎么改读者还是能感觉到空。这个技能能做的是把已有的东西擦干净擦不出本来没有的东西。我在实际项目里的做法是先确认内容层过关再上这一道工序顺序反了纯属浪费时间。