Wb Xhs Humanize Compliance

小红书初稿去 AI 味与发布检查

Runtime bootstrap and update gate

Before using any external program, browser automation, package, API client, or local script, apply ../RUNTIME_UPDATE_POLICY.md. Check the current version, automatically install or update a missing or outdated dependency to the latest stable supported version, run its diagnostic, and only then continue. Text-only work needs no installation. Never use sudo or claim success without verification.

R — 原文

> "去 AI 味，这步不能省。"

>

> — 文子, X Article, 2026-07-06

> "爆款不是信息密度，而是：清晰 + 易吸收。"

>

> — yanliudreamer, X Article, 2026-07-04

I — 方法论骨架

AI 初稿的问题通常不是结构不完整，而是太整齐、太概括、太像正确答案。小红书内容需要个人经历、具体场景、口语节奏和可感知细节。

这个 skill 把改稿分成两步：先人格化，再做平台规则检查。人格化是加入“我怎么知道、我踩过什么、我具体怎么做”；规则检查是减少绝对化表达、收益承诺、过度导向外部私聊等风险表达。

yanliudreamer 系列补充了发布前的内容质量检查：开头要给用户入场理由，正文要少废话、有结构、易吸收，结尾要引导评论或收藏。真人感不等于流水账，必须同时服务点击率、停留时长和互动率。

目标不是把文案变花，而是让它更像账号本人能说出口的话，同时更容易被点开、看完、收藏或评论。

dbskill 的内容诊断模块补充了三条硬规则：先诊断再改写；一篇笔记只能有一个核心机制；开头 5 秒必须独立成立，包含话题、继续看的理由和可信证据。所谓 AI 味，常常来自“太顺、太满、太正确”，要用个人语言、真实意图和具体证据把它拉回人。

xhs-visual-director-skill 补充了“图文可读性检查”：改稿时要判断这篇内容适合单图、长文、还是 6-8 页图文；如果要做图文，必须拆成封面、痛点、认知、方法、案例、操作、总结、引导等页面任务，并保证每页只讲一个主要信息。

发布前审融合了 yuwen-cool/yuwen-publish-precheck 的可迁移方法（来源仓库为 CC BY-NC 4.0）：先做词面候选扫描，再做上下文与意图判断；命中候选不等于违规，零命中也不等于安全。这里只转译为小红书的可执行检查与保意修复，不复制来源规则库，也不提供绕审技巧。

A1 — 文章中的应用

案例 1: 把空泛感受改成真实场景

• 问题: AI 常写出抽象而正确的句子。
• 方法论的使用: 作者建议替换成具体经历和可视化场景。
• 结论: 细节比形容词更能建立真实感。
• 结果: 内容更像真人表达，也更贴近账号人设。

A2 — 触发场景

用户会在什么情境下需要这个 skill?

• 用户有一篇 AI 初稿，觉得不像自己。
• 用户要发布小红书前做最后检查。
• 用户想把过于书面、过于整齐的文案改成口播感。
• 用户担心表达过度承诺或过度导流。
• 用户觉得开头不抓人、正文太散、没有收藏点或评论点。

语言信号

• "帮我去 AI 味"
• "这个文案不像真人"
• "发布前检查一下"
• "开头不抓人"
• "帮我提升停留和互动"
• "humanize this draft"
• "make it sound like me"

与相邻 skill 的区分

• 与 wb-xhs-topic-bank 的区别: 选题库产出标题和方向，本 skill 处理已有正文。
• 与 wb-xhs-account-profile 的区别: 账号档案定义语气，本 skill 按语气改稿。

E — 可执行步骤

• 标出 AI 味来源
• 检查抽象词、整齐排比、泛泛建议、缺少个人证据、书面连接词。
• 完成标准: 列出 3-10 个具体问题点。

• 做内容四维诊断
• 检查文字干净度、封面标题承诺、表达效率、认知差或新鲜感。
• 完成标准: 先判断问题在“看不进去、看不懂、没新意、没证据”中的哪一类。

• 做单一核心机制审计
• 列出正文里所有观点、方法、故事和结论，只保留一个主机制，其余作为证据或删减。
• 完成标准: 用户看完能复述“这篇到底讲一件什么事”。

• 检查 5 秒开头
• 第一屏必须同时回答: 讲什么、为什么现在要看、凭什么相信你。
• 完成标准: 开头离开正文也能成立，不靠后文补解释。

• 检查爆款结构
• 检查是否有钩子、真实背景、3 点以内核心信息、总结和评论/收藏引导。
• 完成标准: 能指出内容卡在点击、停留还是互动。

• 加入真人材料
• 要求用户提供或根据已有信息提取真实经历、具体场景、踩坑、数据、对话、前后对比。
• 完成标准: 每个关键观点至少有一个具体细节支撑。

• 提升清晰度与易吸收度
• 删除铺垫废话，把核心信息压到 1 个方法、1 个坑、1 个对比或 3 点以内。
• 完成标准: 用户在前 3 秒/第一行就知道为什么要继续看。

• 改成账号口吻
• 按账号档案调整句长、语气、词汇和节奏。
• 完成标准: 用户能判断“这像我会说的话”。

• 做发布前审与保意修复
• 先确认内容身份：目标平台是否为小红书、是否商业内容、是否涉及健康/医美/金融/投资/教育等高风险行业，以及封面、图片、截图和案例是否属于正文的一部分。
• 先做词面候选扫描，再做语义复核：检查绝对化、收益/效果保证、夸张标题、外部联系方式或站外导向、虚假身份/虚构案例、未授权截图、版权风险、标题—封面—正文承诺不一致等；候选命中只是复核入口，不直接判违规，零命中也不能直接判安全。
• 对小红书特别检查：把评论区/私信导流写成平台内动作；不使用谐音、拼音、拆字、表情或图片藏字来规避审核；商业内容按实际关系和平台要求做清楚披露；医疗、投资、收入、教育结果等只保留有证据且边界清楚的表达。
• 按保意修复梯度处理：①补披露或必要声明；②补可核验来源/证据；③收窄断言与适用范围；④最小改写，尽量保留原钩子和账号口吻；⑤仍无法支持时删除或暂缓发布。禁止把规避审核当作修复方案。
• 改写后重新复核全文、标题、封面文字、图片文字和行动引导，并记录仍待用户确认的事实、授权或平台规则问题。
• 完成标准: 输出“可发 / 需修改 / 暂不建议发”，并按“必须改 / 建议改 / 待确认”列出证据、风险、具体替换文本和复检结果；不承诺绝对不违规或一定不被限流。

10. 转成图文页面结构

• 如果用户要发图文，按 3:4 手机端阅读拆成 6-8 页: 封面、痛点、认知、方法、案例、操作、总结、引导。
• 完成标准: 每页有页面任务、标题、副标题、核心文案、视觉重点和互动目标，正文不被硬塞进单页。

11. 做视觉可读性检查

• 检查标题是否够大、文字是否过多、封面是否只有一个钩子、内页是否有收藏价值、是否像普通 PPT。
• 完成标准: 输出需要视觉导演继续处理的字段，而不是只给纯文本文案。

B — 边界

不要在以下情况使用

• 用户还没有正文，只需要想选题。
• 用户要求改变核心观点或重做定位，应转到对应 skill。

失败模式

• 只把句子改口语，不补真实材料。
• 为了更像真人而牺牲信息密度。
• 只依赖自动检查，不做人工过目。
• 一味堆干货，用户没有情绪、收藏或评论理由。
• 开头绕太久，用户还没看到价值就划走。
• 一篇里同时塞多个主机制，导致用户不知道该记住什么。
• 只做润色，不先说明问题来自标题承诺、表达效率、证据还是结构。
• 把长文硬塞成图文，导致每页文字过多、手机端不可读。
• 只改正文，不判断封面、内页和结尾页各自承担什么任务。
• 把关键词命中当成最终判定，或把没有命中关键词当成安全证明。
• 用谐音、拼音、拆字、表情、图片藏字等方式规避平台审核。
• 把没有来源的数字、收益、案例或效果写成事实；把平台经验当成当前官方规则。

作者盲点

• 平台规则会变化，本 skill 只能做通用发布检查，不能替代最新平台规则确认。
• 过度追求“真人感”可能变成流水账，需要保留结构和价值密度。

相关 skills

• depends-on: [wb-xhs-account-profile, wb-xhs-topic-bank]
• contrasts-with: []
• composes-with: [wb-xhs-schedule-review]

审计信息

• 验证通过: V1 ✓ / V2 ✓ / V3 ✓
• 测试通过率: prompts prepared
• 蒸馏时间: 2026-07-07
• 发布前审融合: 2026-08-01，参考 yuwen-cool/yuwen-publish-precheck 的两层预审、保意修复与复检方法；来源为 CC BY-NC 4.0，未复制其规则库。