把小红书内容生产做成一个可复用 Skill：句子级切分、违禁词自检与卡片渲染

一、为什么把内容生产做成 Skill

做小红书图文号的团队通常有三个高频动作：把长文拆成多张卡片、检查文案有没有踩违禁词、把文案渲染成统一风格的图片。这三件事单独看都很简单，但串起来就会暴露问题：拆页靠肉眼、检查靠记忆、排版靠复制粘贴。一轮改稿要来回切四五个工具，人一多风格就散。

把这三件事收敛成一个 Skill，好处是流程被固化下来：输入一段长文案，输出一组可直接发布的卡片和一份合规报告。Skill 的价值不在算法多复杂，而在于把「每次都靠人判断」的环节变成「每次都一样」的确定性步骤。

二、三个脚本，各管一段

整个 Skill 拆成三个独立脚本，互不依赖，可以单独跑，也可以串成一条流水线。

1. split_cards.py —— 决定「哪里断开」

最粗糙的做法是按固定字数切，结果经常把一句话从中间劈开，读者在卡片底部看到半句话，体验直接崩。这里改成句子级切分：先按中文句末标点（。！？；）和换行把长文切成句子数组，再按目标页长把句子往卡片里装。装不下就把当前卡片收口，另起一张。这样任何一张卡片的结尾都落在完整句子上。

页长本身也不是拍脑袋定的。给一个目标字符数区间，用二分搜索找「既不频繁溢出、又不留大片空白」的取值：先在区间中点试切，统计每张卡片的填充率，填充率低就往小调，溢出多就往大调，迭代几轮就收敛。实测下来比手工试参数快得多，换个字体或版式也能自动适配。

2. lint_note.py —— 决定「能不能发」

合规检查做成两层。第一层是词表匹配，把绝对化用语、医疗功效宣称、金融收益承诺这类高风险词收进 banned-words.json，命中即报错并给出替换建议；第二层是正则，负责词表覆盖不到的模式，比如「最」加形容词的极限表达、带数字的收益承诺、联系方式引流。两层都过才放行。

关键是错误信息要能直接改：每条命中都带位置、命中的词和建议替换值，而不是只丢一句「检测到敏感词」。这样人不用回头通读全文找问题。

3. render_cards.py —— 决定「长什么样」

渲染走模板路线：一个 HTML 模板加一套 CSS 变量（字号、行高、主色、留白），脚本把每张卡片的文案填进模板，再用无头浏览器截图导出。好处是换风格只改变量，不动结构；坏处是要处理中文字体在无头环境下的缺字问题，需要在容器里预装中文字体，否则导出的图会变成方块。

三、串起来跑

典型调用顺序是：

python scripts/split_cards.py --input note.md --out build/cards.json
python scripts/lint_note.py --input build/cards.json --dict references/banned-words.json
python scripts/render_cards.py --input build/cards.json --template assets/card-template.html --out build/images

第一步产出结构化卡片，第二步只读不写，第三步消费第一步的结果。任何一步失败都可以单独重跑，不用从头再来。

四、几个真实的坑

• 句子切分不能只看句号。中文里「…」和括号里的句号容易误判，需要先把成对的括号内容整体当作一个单元，再切外层。
• 违禁词表要分层。硬禁（法律风险）和软禁（平台限流）混在一张表里，会导致误报太多，人就开始无视告警。分开维护，软禁只给提示不阻断。
• 无头浏览器截图一定要显式等待字体加载完成，用 document.fonts.ready 之后再截，否则第一张图经常是回退字体。
• 卡片数量不要硬编码。一句很长的话可能一张都装不下，切分逻辑要保证「单句超长时按逗号降级」，而不是直接溢出。

五、小结

这套东西没有用到任何模型推理，全部是确定性代码，所以结果可复现、可回归。真正花时间的不是写脚本，而是把「什么样的内容算合格」翻译成可执行的判断条件——句子在哪断、哪些词不能出现、卡片长什么样。这三条定下来，剩下的都是工程。

如果你也在做内容生产工具，建议先把判断条件写清楚再动手，脚本反而是最快的那部分。