去AI味写作工作流：Humanizer-zh诊断与dbskill选题组合

文字改写失败时，问题可能来自选题、结构、事实、语气或过度模板化，而不是简单的“AI 味”。本文把 Humanizer-zh 与 dbskill 放在一个可比较的工作流里，先诊断文章问题，再选择改写范围，最后用原意保留、事实核验和人工复读确认结果。文中只讨论可复现的步骤，不把单次结果扩展成产品承诺；每个结论都标注前提、证据和无法覆盖的边界。读者可以先完成最小验证，再按自己的版本、权限和数据补充实验。

你有没有发现，很多 AI 文章不是写得差，而是写得太像一类东西了。

开头先说“在这个快速变化的时代”，中间来一段“首先、其次、最后”，结尾再把一个普通功能拔高成“重新定义行业”。

看起来很完整，读完却没有一个具体的人、一个真实的场景，或者一个值得记住的判断。

更麻烦的是，很多人发现文章没劲之后，第一反应是让 AI 再润色一次。结果只是把“此外”换成“同时”，把“重要”换成“关键”，机器味换了件外套，还是机器味。

这一篇介绍两个开源项目。Humanizer-zh 负责检查和改写常见的 AI 写作模式，dbskill 负责在写作前判断生意、选题、Hook 和标题。一个处理表达层，一个处理决策层。

先判断这件事值不值得写，再让文字像一个具体的人说出来。

一、先弄清楚什么是 Agent Skill

这两个项目都不是新的大模型，也不是独立的在线编辑器。它们更像写给 Agent 的工作说明书。

一个 Skill 通常由说明文件、参考资料、脚本和示例组成。Claude Code、Codex 或其他支持 Agent Skills 标准的工具加载后，会按照里面的规则处理任务。

所以它和普通 Prompt 有一个区别：

普通 Prompt：这一次告诉模型怎么做
Agent Skill：把一套方法、边界和检查流程保存下来，之后反复调用

这也意味着，Skill 能不能工作，取决于几个前提：

• 当前 Agent 是否支持 Skills。
• Skill 是否安装到了它能读取的目录。
• 当前对话是否真的触发了对应能力。
• 任务的输入是否足够具体。
• 生成之后有没有人工核验。

装完一个 Skill，不等于模型立刻拥有作者全部经验。它只是多了一套可重复执行的工作规则。

二、Humanizer-zh 到底做什么

项目地址：op7418/Humanizer-zh

Humanizer-zh 是一个中文化的 Claude Code Skill。仓库说明它的核心文件翻译自 blader/humanizer，实用检查部分参考了 stop-slop 和维基百科关于 AI 写作特征的整理。

它的目标不是“骗过 AI 检测器”，而是找出文本里那些过于模板化、抽象化、宣传化的表达，然后在不改变核心含义的前提下重写。

仓库 README 把检查范围分成四组，一共 24 类模式。

1. 内容模式

内容层主要检查这些问题：

• 反复拔高意义、遗产和宏大趋势。
• 过度强调知名度、媒体报道和影响力。
• 只有表面分析，没有具体证据。
• 把产品介绍写成广告宣传。
• 用模糊来源支撑一个很确定的结论。
• 用“挑战与未来展望”这样的结构收尾，却没有真正的内容。

2. 语言和语法模式

这组问题更接近日常所谓的“AI 词汇”：

• 过度使用“此外、至关重要、深入探讨、强调、格局”等词。
• 用复杂句式回避最普通的“是”。
• 反复使用“不是……而是……”。
• 三个形容词连在一起，制造一种虚假的完整感。
• 为了避免重复而机械地循环同义词。
• 给一个没有边界的观点硬套上“从 A 到 B”的范围。

3. 风格模式

例如：

• 破折号和粗体使用过量。
• 每段都用小标题和列表切开。
• 英文标题大小写习惯直接移植到中文。
• 表情符号到处出现。
• 引号和标点格式不统一。

4. 交流模式和填充词

这组痕迹经常藏在“态度”里：

• 一上来就说“很高兴为你服务”。
• 用过度谄媚的方式赞美读者或用户。
• 加一段知识截止日期免责声明，但和文章本身无关。
• 用“总的来说”“值得注意的是”拖延真正的表达。
• 用一个泛泛的积极结论代替明确判断。

这些不是绝对禁用词表。真实作者也会说“此外”，也会使用列表。问题在于连续、密集、无意识地使用，最后让所有文章都长成一个模样。

三、安装和验证 Humanizer-zh

仓库 README 给出的推荐安装方式是：

npx skills add https://github.com/op7418/Humanizer-zh.git

如果你的环境不支持这个安装器，也可以克隆后手动放到 Claude Code 的 Skills 目录。Windows 常见位置是：

%USERPROFILE%/.claude/skills/humanizer-zh/

安装后重启 Claude Code 或重新加载 Skills，在对话中输入：

/humanizer-zh

也可以直接指定任务：

/humanizer-zh 请帮我人性化以下文本，保留事实、数字、链接和原有观点，不要补充没有来源的新信息：

这里放文章草稿。

验证不要只看 Agent 说“已安装”。应该检查：

1. 当前 Agent 能否找到 Humanizer-zh。
2. 输入一段故意充满空话的测试文本。
3. 输出是否指出具体问题，而不是只说“已经优化”。
4. 改写后事实、数字、链接和标题有没有被偷偷改变。
5. 如果输入的是文件，原文件有没有被覆盖。

更稳妥的方式是先让它生成一个新文件，例如：

/humanizer-zh 请读取 article-draft.md，先输出问题清单，再把修改稿保存为 article-humanized-draft.md。

只允许创建新文件。不要覆盖、删除、移动或重命名原始草稿。不要添加原文没有的事实、案例、数字和引用。完成后报告读取了什么、创建了什么，以及哪些段落仍然需要作者确认。

四、Humanizer-zh 的正确用法

它最适合放在写作流程的后半段，而不是一开始就让它代替你写。

推荐顺序是：

先写出明确观点
  -> 补充具体事实和案例
  -> 人工加入经历、判断和限制
  -> Humanizer-zh 扫描模板化表达
  -> 作者重新确认语气和事实

你可以让它执行四步检查：

请检查这篇文章的 AI 写作痕迹，但先不要直接改全文。

请按四组输出：
1. 内容模式：哪些地方拔高、宣传化、模糊归因或缺少证据。
2. 语言模式：哪些词语或句式重复得过于明显。
3. 风格模式：列表、粗体、破折号、标题和段落是否过度模板化。
4. 交流模式：哪些地方像客服话术、填充句或泛泛总结。

每个问题给出原句、问题原因和两个改法。
不要为了“更像人”编造个人经历。原文没有真实细节的地方，标记为“需要作者补充”，不要代写。

这段要求里最重要的一句是“不要编造个人经历”。

因为真正的人味不是增加几个口语词，而是让文章里出现作者确实见过、做过、犹豫过的东西。AI 可以把“这个方案效果很好”改得更顺，但它不知道你到底在哪一步卡过。

五、dbskill 不是一个选题 Prompt

项目地址：dontbesilent2025/dbskill

用户介绍里把 dbskill 叫作“内容选题诊断器”，这个说法不算错，但不完整。

根据仓库当前 README，dbskill 是面向创业者和内容创作者的中文 AI Skills 工具箱。它不是只负责想标题，而是把商业诊断、对标研究、选题、Hook、短视频、决策记录和本地知识库都放进了一个动态路由入口。

README 当前描述为 28 个正式 Skills。版本会变化，所以这里不把数量写成永久不变的产品承诺。

它的核心用法是：

真实任务
  -> /dbs 读取当前上下文
  -> 选择合适的 Skill
  -> 完成一轮诊断或产出
  -> 你补充事实和反馈
  -> 再决定下一步

你不必先判断“我现在应该用哪个方法”。直接把眼前的业务、选题或卡点交给 /dbs，它会根据上下文选择入口。

六、dbskill 里和内容最相关的几个入口

/dbs-diagnosis，先诊断商业问题

当你说“客户总觉得贵”“转化率很低”“我是不是找错了人”，它不应该直接给你一句营销文案，而是先拆产品、定价、客群和验证动作。

这一步对写内容也很重要。很多内容写不出来，不是文笔问题，而是作者还没有判断清楚自己到底要解决谁的什么问题。

/dbs-content，判断选题能不能展开

它适合把一个模糊想法拆成：

• 选题到底在谈什么。
• 对谁有用。
• 读者为什么现在要看。
• 有哪些角度可以展开。
• 哪些角度只是重复已有内容。

/dbs-hook，处理开头

把前 20 秒的逐字稿或文章开头交给它，让它分析：

• 读者是否知道你要讲什么。
• 开头有没有具体场景。
• 第一处信息增量在哪里。
• 哪些句子只是铺垫。

它可以给出多个版本，但不要直接接受其中一个。Hook 的选择取决于你的内容事实，不能靠情绪强度替代证据。

/dbs-xhs-title，生成小红书标题方向

它更适合先给一批标题方向，再解释每个标题承诺了什么。不要只看哪个标题最夸张，还要确认正文是否真的交付了标题承诺的内容。

/dbs-knowledge，把本地资料变成可调用的知识库

dbskill 还提供本地文件夹知识库能力。它可以建立导航、查找、收录和调用资料，并将跨对话的记录默认保存在用户本机的 .dbs 目录。

这并不等于它会自动把你的文件变成可靠知识。重要资料仍然要保留来源、版本和人工确认状态。

七、安装和验证 dbskill

仓库 README 给出的通用安装命令是：

npx -y skills add dontbesilent2025/dbskill -g --all

如果你使用 Claude Code 的插件市场，也可以按仓库 README 提供的方式：

claude plugin marketplace add dontbesilent2025/dbskill
claude plugin install dbs@dontbesilent-skills

首次安装不建议盲目全量加载。仓库虽然提供了完整工具箱，但每个被加载的 Skill 都可能增加 Agent 每次运行时的上下文成本。你可以先选择内容相关能力，确认工作流后再扩展商业诊断、决策记录和知识库。

验证可以分三步：

/dbs 新手入门

/dbs-content 我想做一个关于“AI 工具越来越多，但工作效率没有提高”的内容，请先诊断选题，不要写稿。

/dbs-hook 这是文章开头，请给出问题清单和三种不同方向的改法，不要直接覆盖原文。

如果 /dbs 能根据任务选择不同路径，且每次都说明了下一步需要什么输入，动态路由才算真正工作。

八、把两个 Skill 串起来

一个可复用的内容流程如下：

第一分钟，先判断选题

/dbs-content

我想写：普通人如何用 Agent Skills 改善写作流程。
目标读者：会使用 Claude Code 或 Codex，但没有系统内容工作流的独立创作者。
请先做选题诊断：
- 这个题目具体解决什么问题。
- 哪些表达已经被写烂。
- 最值得展开的三个角度。
- 需要我补充哪些亲身经历或实测结果。
不要写完整文章。

第二步，单独打磨 Hook

当你补充了实际经历，再用：

/dbs-hook

这是我的真实经历和文章开头：

[粘贴真实素材]

请给出：
1. 当前开头为什么抓不住人。
2. 一个具体场景开头。
3. 一个反常识开头。
4. 一个问题驱动开头。

不要增加我没有提供的经历、数字、客户和结果。

第三步，写出初稿

初稿可以让 Claude、Codex 或你习惯的模型完成，但先把事实和观点交进去。不要让模型根据一个标题凭空补齐整篇文章。

第四步，用 Humanizer-zh 做诊断

先请求问题清单，再逐段确认。对于“需要作者补充”的位置，回到真实经历中找细节，而不是让 AI 编。

第五步，人工定稿

最后检查三件事：

• 标题是否过度承诺。
• 文章是否真的回答了开头提出的问题。
• 所谓“人味”是不是来自具体事实，而不是来自随意添加的口头禅。

九、一个完整的组合 Prompt

如果你想一次性把流程交给 Agent，可以复制下面这段。但它仍然应该分阶段执行，不能因为 Prompt 很长就跳过人工确认。

我要写一篇中文文章，主题是：[主题]。
目标读者是：[读者]。
文章目标是：[教育 / 说服 / 记录实测 / 分享方法]。

请按以下顺序工作：

第一阶段，调用 dbskill 相关能力先诊断选题。
- 说明读者痛点和文章承诺。
- 找出三个可行角度和两个不值得写的角度。
- 列出需要我补充的真实经历、数据和来源。
- 不写完整文章。

第二阶段，等我确认角度后，设计三个 Hook。
- 一个从具体场景切入。
- 一个从反常识事实切入。
- 一个从读者问题切入。
- 不虚构人物、数字和结果。

第三阶段，根据已确认的素材写初稿。
- 保留来源链接和不确定信息。
- 将推测标记为待核实。
- 不把产品宣传语写成事实。

第四阶段，调用 Humanizer-zh 只做 AI 写作模式检查。
- 先输出问题清单。
- 按内容、语言、风格、交流四组归类。
- 给出原句和候选修改。
- 不覆盖原稿，不删除来源，不新增没有依据的经历。

第五阶段，返回：
- 选题诊断
- Hook 备选
- 初稿文件位置
- Humanizer-zh 检查结果
- 仍需我确认的事实和段落

十、许可证、隐私和企业接入

dbskill 的 README 标注 CC BY-NC 4.0。个人学习、研究和非商业项目可以按许可证使用，商业团队在复制其知识库、方法文档或衍生分发前，应先确认授权边界。

Humanizer-zh 的仓库提供开源许可证信息，但它依赖的原始项目、参考资料和你自己加入的内容仍然要分别核对来源。

隐私方面，不要把这些内容直接粘贴给公共 Agent：

• 客户名单和联系方式。
• 企业内部经营数据。
• 未发布产品路线。
• API Key、Token、Cookie 和登录信息。
• 带个人身份信息的聊天记录。

企业使用时，可以把模型调用统一放到企业级 API 网关或合规的多模型 API 入口中，再做 API Key 分组、调用日志、预算和成本治理。调用日志应记录模型、项目、耗时、错误类型和费用，但不要把文章原文和密钥明文写入日志。

如果通过 上游 API 或其他 API 中转服务调用模型，服务地址、模型标识和 Key 以当前服务商文档为准。中转层只解决统一接入、路由或计费问题，不能替代内容事实核验。

十一、谁适合这套组合

适合：

• 经常需要写公众号、Newsletter 或行业文章的人。
• 有很多选题，但不知道哪个值得投入的人。
• 发现 AI 草稿结构完整，却没有个人判断的人。
• 想把内容诊断和润色流程固化成可重复步骤的团队。

不适合：

• 只想按一个按钮自动产出可以直接发布的文章。
• 希望工具替你编造个人经历和一手案例。
• 不愿意保存来源，也不想做事实核验。
• 想用“去 AI 味”躲过平台审核或学术诚信检查。

十二、发布前验收清单

选题和内容

• dbskill 的诊断结论、Hook 和标题都经过人工选择，没有把模型推荐当成市场事实。
• 文章里的经历、数字、案例和引用都能回到来源或作者本人确认。
• Humanizer-zh 只处理模板化表达，没有删除关键限定条件或改掉作者真正的判断。

许可和安全

• 已确认 dbskill 的 CC BY-NC 4.0 边界，商业团队没有直接复制其受限材料。
• 没有把 API Key、Cookie、客户资料和未公开信息放进公共 Agent。
• 通过 上游 API 或其他企业网关接入时，项目 Key、预算、日志和发布权限已经分开。

发布质量

• 标题和开头与目标平台匹配，没有夸大“绝对去 AI 味”的效果。
• 正文保留具体人物、场景和事实，不是只替换同义词。
• 最终全文由作者通读，并确认愿意用自己的名字署名。

总结

Humanizer-zh 解决的是“文字为什么像机器写的”，dbskill 解决的是“这件事到底值不值得写、从哪里写”。

把它们放在一起，顺序应该是：

dbskill 诊断选题
  -> dbskill 打磨 Hook 和标题
  -> 人提供真实事实、经历和判断
  -> 模型完成初稿
  -> Humanizer-zh 检查模板化表达
  -> 人工确认事实、语气和责任边界

AI 最适合加速重复劳动，不适合替你承担作者身份。

结论

本文给出了问题定位、配置或创作流程的可执行路径。实际结果仍取决于当前版本、权限和运行环境，提交前应按官方文档复核可变字段，并保留失败证据和回滚边界。