这次我把 Humanizer-zh 这个面向中文场景的“降 AI 味”skill 完整跑了一遍从加载、单条测试、多文体测试到失败排查都过了一遍。先说结论它的核心价值不是把机器痕迹变成零而是把 AI 初稿里最常见的三种毛病——句式重复、连接词堆砌、表述缺乏具体细节——改写成更像人写的自然中文。适合还在用 AI 生成初稿、又希望成稿读起来不像机器口吻的内容创作者、产品文案和技术博主。最值得关注的不是它能不能“消灭”AI 味而是在不同文体、不同长度、不同输入质量下改写效果是否稳定。下面按我的实测流程拆开讲。1. 先搞清楚降AI 到底降的是什么skill 到底加载了什么很多人一看到“降AI”三个字以为是把文字里的机器成分完全抹掉最好能做到让任何人都看不出来。这个预期本身就有问题。文本只要经过大模型生成总会保留一些统计特征不可能绝对“去干净”。更合理的理解是把读者一读就觉得别扭的那层“AI 腔”去掉让文字回到人类写作的正常状态。1.1 降AI 不是消除机器痕迹而是消除“AI腔”什么是“AI腔”我自己的判断标准很简单读一段话如果三句话能猜出它是模型写的那就有明显的机器口吻。常见特征包括句式和长度太均匀每句都差不多长读起来没有节奏感。连接词密度过高“首先”“其次”“再次”“综上所述”轮番出场。喜欢用抽象表达比如“具有重要意义”“为……赋能”“助力发展”但整段没有具体事实。每段结构都工整得像填表格观点、解释、举例、总结。Humanizer-zh 这类 skill 要处理的就是这些可识别、可修正的表层规律而不是去做所谓的“痕迹清洗”。它更像一个风格编辑器把一篇合格的机器文本改写成一篇合格的人工文本。1.2 skill 的本质是一份结构化改写规范不是模型本身这里要先把“skill”这个概念讲清楚。在支持自定义 skill 的 AI 工具里skill 通常是一个包含说明文件的目录里面用 Markdown 写清楚角色、规则、工作流程、约束条件和示例。用户可以在对话中调用它也可以让它自动附加到每次请求上。它和普通提示词的区别在于两点一是可复用一个 skill 文件可以反复在不同对话里加载不需要每次重写二是结构化它会明确告诉模型“按什么顺序做、哪些不能做、输出长什么样”而不是只说一句“请写得更像人话”。所以 Humanizer-zh 本质上是一份针对中文的「降AI 味改写规范」。它的效果取决于三层因素叠加底层模型本身的写作能力。skill 文件里规则设计得是否合理。输入文本是否还有可挽救的语义信息。这也是很多新手最容易误解的地方以为加载了 skill 就能把一篇完全空泛的 AI 废话变成有血有肉的好文章。如果输入文本全是空话任何 skill 都救不回来因为改写的上限取决于原文的信息量。注意我这里没有给出 Humanizer-zh 的具体版本和作者信息因为原始资料里没有。实测时先确认你拿到的是哪个版本评分和效果可能存在差异。2. 实测前的准备环境、测试文本和评判尺子测试这类 skill最忌讳一上来就扔一大段文字看完输出就凭感觉下结论。我的做法是先固定环境、固定样本、固定评判标准再开始跑。没有尺子的测试结论永远是“感觉还行”或者“感觉不行”没什么参考价值。2.1 环境准备skill 放在哪里、怎么确认生效不同的客户端加载 skill 的方式不一样。常见的有三类支持 Agent Skills 的客户端通常需要把包含SKILL.md的目录放到指定路径比如~/.claude/skills/或项目目录下的.claude/skills/。支持规则文件的编辑器工具比如在.cursor/rules/里放一个.mdc文件相当于全局或项目级规则。不支持自定义 skill 的普通对话工具只能手动把 skill 里的规范复制到提示词里。我不确定你手上的 Humanizer-zh 是哪一种封装形式所以第一个步骤是确认加载方式。装完之后先不要在正式文本上测试而是直接问模型一句“你当前加载了哪些 skill”如果它能准确说出 Humanizer-zh 的名字和作用说明加载成功如果答不上来后面所有测试都没有意义。2.2 测试文本怎么选四种样本覆盖不同场景建议准备四种不同类型的样本文本每类至少两段短段落100 到 300 字模拟朋友圈文案、产品简介、工作通知。长文章1000 字以上模拟技术博客、行业分析、活动总结。列表型内容带项目符号或序号模拟汇报材料、指南文档。口语对话型模拟客服回复、聊天消息、评论回复。为什么要分开测因为同一套改写规则在长文和短文上的表现可能完全不同。短文缺乏上下文模型容易误判风格长文信息量大模型可能在改写过程中丢掉细节列表型内容如果被改写成大段散文反而算失败口语对话则要看它能不能把正式腔调压下来。2.3 提前定好评判维度别凭感觉打分我在测试前会先定四个评判维度每个维度按 1 到 5 分打分句式重复度句子结构是否单调。连接词密度“首先”“其次”“总之”等词是否过多。信息具体度原文有没有被改写得更具体或者反过来丢了细节。语气自然度读起来像不像真人有没有明显的正式腔。把维度写下来之后每次测试都按同一套标准评分。这样后面即使换了文本也能横向比较效果而不是这次觉得好、下次觉得差却说不出差在哪。3. 单条文本实测流程从加载到输出比对准备工作做完进入最核心的单条实测环节。这个环节的目的不是判断 skill 好不好而是先确认它能不能按照预期工作。我用一段非常典型的 AI 味文本做基线示例内容如下随着人工智能技术的快速发展越来越多的行业开始应用这一技术。首先人工智能可以提高工作效率。其次人工智能可以降低人工成本。综上所述人工智能的发展具有重要意义我们应该积极拥抱这一趋势。这段文字信息量极低结构极度模板化非常适合用来观察改写效果。如果 skill 连这种最明显的 AI 腔都处理不好那它对复杂文本的表现也很难让人放心。3.1 第一步先确认 skill 被正确加载在正式改写前我会先调用一次 skill。如果客户端支持/humanizer-zh这类斜杠命令就直接用命令如果不支持就把 skill 名称写在提示词里比如“请使用 Humanizer-zh 改写下面的文本”。这一步很关键因为它能暴露一个很常见的问题模型嘴上说“好的我按 Humanizer-zh 的规则处理”但实际上并没有真正触发 skill 的完整规则只是按自己的理解随便改了改。所以我会接着追问一句“请用一句话说明你这次改写遵循了哪几条规则。”能明确说出规则才说明 skill 真的被调用。3.2 用一段“典型 AI 味”文本做基线把上面那段示例文本发给模型改写时明确给出要求“保持原意不要扩写不要添加原文没有的信息输出中文。”为什么要强调不扩写因为很多模型在改写时有一种“补充解释”的冲动会把一段话越改越长。降 AI 味的目标是调整表达方式不是增加内容量。一旦开始扩写原文信息结构就被破坏了后面很难判断是改得好还是补得好。3.3 执行改写并做前后比对我实测中遇到的一段改写结果大致是这样的这一两年AI 落地的地方越来越多很多团队开始把重复性工作交给它。效率确实提上来一些人工成本也降了。但工具归工具怎么用、用在哪才是真正决定效果的地方。这个结果就比原始文本自然很多。你可以看到三个典型变化第一删掉了“首先”“其次”“综上所述”第二句子长度有了变化不再均匀排列第三加入了“很多团队”“重复性工作”这类有画面感的表述。但这里要提醒一句具体输出效果会因底层模型不同而不同。同一个 skill在写作能力强的模型上效果明显在能力弱的模型上可能只是简单删几个连接词。3.4 检查它是否遵守改写边界输出出来之后不要只看“顺不顺”还要核对三个边界有没有添加原文本不存在的事实或数据。有没有改变原文本的语气比如把中立的表述改成情绪化。有没有错误删除关键信息比如把“降低人工成本”这个信息点漏掉。我这次测试里没有发现信息丢失但发现了另一个问题模型在改写短段落时偶尔会把“AI”直接写成“人工智能”导致长度变化。这本身不是大事但如果你在批量处理多段文本这种不统一就会比较明显。4. 输出质量怎么看四维打分表单条文本跑通之后下一步是把“感觉”变成“分数”。我会对每一条改写结果按四个维度评分最后取平均。这个平均分就是我判断 skill 在某个场景下是否可用的依据。4.1 四个核心维度句式重复度看相邻句子是否频繁使用同一结构。比如连续三句都是“XXX 是 YYY 的重要保障”这就是明显重复。合格标准是相邻句子的长度和结构有明显变化但又不刻意。连接词密度统计“首先”“其次”“然后”“总之”“综上所述”这类词的出现频率。降 AI 味之后这些词应该大幅减少但不等于完全消失。人类写作里适当使用连接词没有问题关键是不能每段都靠它们推进。信息具体度比较改写前后的信息量。好的改写会把抽象表达替换成有画面感的表达比如把“提高效率”改成“以前要三个人做一周的事现在一个人半天能跑完”。但要注意如果没有原文支撑模型不能自己编造细节。这里我用的是示例文本如果你实际操作时有你的真实业务信息可以让模型基于这些信息做具体化但不能让它无中生有。语气自然度这是最主观的一项。我的判断方法是假装这段文字是同事发给我的如果不出戏就可以给 4 分以上如果一看就知道是从模板里改出来的只给 2 到 3 分。4.2 打分表与合格线下面是我用的评分表你可以直接复制使用维度怎么看扣分现象合格标准句式重复度相邻句子结构对比连续两句以上同构相邻句子长短、结构有明显变化连接词密度统计逻辑连接词数量每段超过 2 个套话连接词连接词出现自然不靠它们撑结构信息具体度对比改写前后信息量信息丢失、无中生有核心信息完整表达更具体语气自然度模拟真实沟通场景读起来像汇报模板像真人说话但不失准确我之前给这条测试结果的打分大概是句式重复度 4、连接词密度 5、信息具体度 4、语气自然度 4平均 4.25。按我的经验平均分达到 4 以上就可以用于正式场景3 到 4 之间需要人工润色低于 3 基本就是 skill 没生效或者输入文本太差。4.3 警惕“改过头”的失败类型降 AI 味不一定都是“降不下来”还有一种失败叫“改过头”。我测试时遇到过三种口语化过度原文是技术说明文档改写后变成了聊天语气专业性全丢。添加不存在的内容模型为了让文字更自然凭空加了一个案例或数据。破坏原有结构一份带序号的工作计划被改成了流水账散文。这三种失败比“降不下来”更隐蔽因为它们看起来“很自然”但实际已经偏离了任务目标。判断标准很简单改写后的文本必须服务于原来的使用场景。写技术文档自然但要有专业感写产品文案自然但要有卖点写工作汇报自然但要有结构。注意降 AI 的终极目的不是骗过某个检测器而是让文字更可读、更像正常交流。如果改写结果需要靠编造信息来换取自然感那这个方向就错了。5. 多文体和批量测试不同场景表现完全不同单条文本测试只能说明 skill 具备基本能力真正决定它值不值得长期用的是多文体表现和批量稳定性。我这次选了技术说明、产品文案、工作汇报、口语回复四类文本分别测试结果差异很明显。5.1 不同文体的改写表现差异技术说明类表现最好。原始文本通常是条款式、结构清晰的模型只需要把僵硬的连接词替换掉保留术语和专业语气。这类文本的改写风险最低。产品文案类表现不稳定。好的时候能产出“有点人味”的卖点描述差的时候会过度口语化把产品文案改成朋友圈带货风格。如果原文本身是高度营销化的 AI 文本比如“极致体验”“焕新升级”满天飞skill 也不一定能处理干净因为那些词本身就是行业套话不完全是模型腔。工作汇报类中等偏上。模型能去掉“围绕”“深入开展”这类汇报腔但会损失一些公文该有的正式感。如果你要交的是正式方案改写之后最好人工再补一轮。口语回复类最容易“改过头”。因为原文本来就短模型一旦调整句子很容易把答复改成敷衍的客套话。比如“好的收到我们会尽快处理”被改成“行我看到了马上弄”语气是自然了但专业性下降了。我建议做多文体测试时每种文体至少跑三条样本然后分别打分。不要用一条成功案例代表所有文体。5.2 批量化测试时要注意稳定性和输出命名如果你打算把 Humanizer-zh 用在批量任务里比如一次处理 20 篇产品简介就不能只看单条效果了。批量环境会暴露三个额外问题输出是否一致同样输入结构的文本第一次和第二次的改写风格可能不同。这不是 bug模型生成的随机性决定的。但如果风格漂移太严重整个批次的输出会显得很乱。失败如何处理某一条输出因为超长被截断或者因为格式异常返回了空内容会不会影响后面的任务批量处理前要先把失败策略想好是重试还是跳过是记录日志还是直接报警。输出命名是否可追踪每条输出都要能对应回原始输入。我一般会在文件命名里带序号比如input_001.md - output_001_humanized.md这样出了问题能直接定位。5.3 文本长度对效果的影响我还专门对比了短文本和长文本。短文本100 到 300 字改写后容易丢失语气层次因为信息太少模型只能在用词上做文章长文本1000 字以上改写后整体一致性更差因为模型是按上下文窗口分段处理的前段和后段的风格可能不一致。如果你主要处理长文建议按段落改写不要整篇一次喂进去。每次只改 300 到 500 字最后再整体看一遍衔接。这样能减少语气的跳变。6. 效果不好时先查这六个位置如果测试结果不理想先别急着下“这个 skill 不行”的结论。我在排查这类问题时会按照下面这个顺序逐层检查能省掉很多冤枉路。6.1 加载与调用层面第一件事确认 skill 真的被加载了。很多“没效果”的案例本质是模型根本没有读取 skill 文件。你可以在对话里问它“请复述 Humanizer-zh 的核心规则。”如果它复述不出来说明 skill 文件路径不对、客户端没扫描到、或者调用方式错了。第二件事确认调用语句没有歧义。如果你只说“帮我改得更自然”模型可能不会自动调用这个 skill而是凭默认能力随意改写。要明确说出 skill 名称。6.2 输入与参数层面第三件事检查输入文本本身。原文如果是“为了提升用户体验我们不断优化产品功能为用户创造更大价值”这种话信息量为零任何 skill 改出来都是空壳。先把原文的问题解决掉再加入具体事实再谈降 AI 味。第四件事检查改写要求是否相互冲突。如果既要求“保持正式语气”又要求“口语自然”模型会在两个目标之间摇摆最后输出两头不靠。一次只提一个核心目标。6.3 模型与任务层面第五件事确认底层模型是不是太老。skill 是一套规则真正执行规则的是模型。如果模型本身的语义理解能力不足它只会做表面替换比如把“首先”改成“第一”那效果自然很差。换一个能力更强的模型往往立竿见影。第六件事判断任务类型是否超出 skill 能力范围。如果要求它把 AI 生成的“高并发架构对比报告”改写成“带着个人判断的技术博客”这已经不是降 AI 味而是重新创作。这种任务要拆成两步先让人或模型补充观点和案例再做降 AI 味处理。还有一个经常被忽略的点如果输入文本里包含特殊格式比如表格、代码、层级标题skill 可能优先处理文字风格而破坏结构。这类内容在改写后要单独检查一遍结构完整性。7. 这类 skill 的真实边界和适合怎么用测试全部跑完之后我对 Humanizer-zh 这类中文降 AI 味 skill 的判断是它是一个值得放进工作流的辅助工具但不是万能改写器。7.1 它不能做什么首先它不能给原文添加真实经历。AI 生成的文本往往缺少“我上周遇到的一个问题”“我们团队踩过的坑”这类真实细节skill 只能调整表达方式编不出真实经历。想要文章有人味还是得自己补充素材。其次它不能保证所有输出都稳定可用。模型生成的随机性决定了同样的输入每次输出都可能有差异。生产环境里必须有人工抽检。最后它不适合用来包装低质量内容。如果原文逻辑混乱、事实错误、表述空洞改写只是让它看起来更通顺问题本身还在。先解决内容和事实最后再考虑降 AI 味。7.2 适合谁、不适合谁适合的用法有几种内容创作者先用 AI 生成初稿再用 skill 做风格调整减少机械感。产品和技术团队把功能说明、周报、文档从“模板腔”改成“正常沟通腔”。需要在正式场合使用 AI 辅助写作的人把 AI 输出作为底稿通过 skill 快速压缩到更接近人工表达的状态再人工补充个人判断。不适合的用法也有几种不要把它用在需要严格格式规范的合同、法律文件等场景风格改写可能引入表达歧义。不要用它在考试或学术作业里规避规则那不是技术问题是诚信问题。不要用它给虚假信息做包装自然表达不等于内容真实。7.3 我的最终建议如果你刚接触这类 skill我的建议是把使用流程固定成三步先跑单条文本确认加载和基本效果再跑四种不同文体分别打分最后才考虑批量接入。不要跳过前面两步直接上批量任务。测试过程中最好保留一份记录表把每次的输入文本、skill 版本、底层模型、输出结果、评分都记下来。这样等 skill 版本更新或者换了别的底层模型你就能快速对比出变化而不是每次靠运气。最后说一句降 AI 味这件事问题的根源不在“AI 味”本身而在我们是否愿意在 AI 生成的内容上再花一轮人工打磨的功夫。skill 能帮你把初稿推到 70 分剩下那 30 分还是得靠真实的经验、真实的数据和真实的判断来补。这也是大多数人写完 AI 初稿之后最该花时间的地方。