Making Content 是一个内容生产技能，按需提供三种用法，并共用同一套写作风格规则。
一、改写（默认模式） 用户提供一份草稿，技能按下方风格规则进行改写。该规则由某位作者对 AI 草稿的实际修改提炼而来；如果 test-cases/ 中有用户自己的样本，或用户就自己的文风作出说明，则以样本和用户说明为准。
二、从零制作小红书图文 先阅读 references/xhs-post.md（流程、标题、封面、卡片、正文、表明立场）。卡片和正文文字同样遵循风格规则；但“不要重构、不要添加草稿中没有的事实”这类仅适用于改写的条目，在此不适用。
三、短视频 先阅读 references/video-pipeline.md（流程、script.json、配音、渲染、lint）。写 script.json 时阅读 references/layouts.md；克隆音色或遇到 TTS 报错时阅读 references/voice-and-music.md；lint 失败时阅读 references/text-density-lint.md。旁白和文案仍遵循风格规则；视频结尾邀请评论的提问是视频格式的刻意组成部分，按 video-pipeline.md 处理。
从零做图文或视频前：先判断选题能否胜出 在任何大纲之前执行，并在有新数据时重复（已发布版本的数值、用户发来的搜索结果）。改写模式跳过此步。
- 用一句话说明目标：是追求触达（陌生人的点赞、收藏、播放），还是触达指定人群。不清楚就问。
- 从原始搜索结果判断热度与饱和度，而不是凭记忆。在目标平台搜索选题；平台无法读取时在网页搜索；只有最后才请用户提供截图。对前 10 条结果记录发布时间、点赞与收藏、角度、作者是否露脸；记录新闻爆出后过了多少天，以及计划角度是否已在前列。
- 与该账号对比：作者这类内容的中位数与最好成绩。项目有账号数据就读取，否则询问。
- 给出该内容超过作者中位数的概率，附理由，以及什么核查会改变这一判断。
- 如果结果由编辑无法改变的条件决定（新闻已过峰值、所有角度已被更大账号占据、选题超出作者受众关注范围、作者不愿做的形式），就判定为死局：列出这些条件，说明需要什么变化才可行，然后停止。不要在死局里打磨钩子、节奏或视觉，也不要在其上轮换新角度；由用户选择下一个选题。
句子级参考（同级技能） 在改写或图文模式写作前，阅读安装在本技能同级目录（~/.claude/skills/ 或 ~/.agents/skills/）下的第三方技能：
- lieflat-less-ai-tone/SKILL.md：11 条去除中文 AI 腔的规则，每条都有语料测量支撑，如顿号并列的拥挤列表、相邻句同构、过度使用冒号、套话开头、五类翻译腔、段首无指代评论等。覆盖本文件未涉及的句子层面。改写后按其末尾“最终验收”清单检查。
- chinese-writing-style/SKILL.md：平实中文写作通用规则（长句、名词化、数字写法、面向 agent 的文字），主要面向文档与报告。
- humanizer/SKILL.md：仅用于英文草稿（X 上的英文帖与回复）；写英文前阅读。它列出 26 类英文 AI 腔，如 Not X but Y、强行三段式、破折号、单行收尾、套话词。逐条检查结果。中文草稿不要读。 冲突时以本文件为准；lieflat 本身也说风格文档优先于其规则。重叠规则（对比结构、破折号、拟人比喻）按本文件版本执行。正文中的反问不算 AI 痕迹（有测量显示人比 AI 用得多得多），不要顺手删掉。 若某个技能缺失，询问用户是否安装，同意后只安装缺失项，例如：skills add adao-max/agent-skills -g -y -a claude-code -a codex -s chinese-writing-style；skills add larashero3-dotcom/lieflat-less-ai-tone -g -y -a claude-code -a codex -s lieflat-less-ai-tone；skills add blader/humanizer -g -y -a claude-code -a codex -s humanizer。用户拒绝或安装失败时，仅按本文件规则改写，并在末尾说明缺少句子级参考。
先读测试用例（如有） test-cases/ 下每个文件夹是一对前后样本：ai-draft.md（典型 AI 初稿）、final.md（作者终稿）、README.md（可选场景说明）。改写前随机读一两个，看 AI 在哪里过度修饰、作者删减到什么程度，这比规则更能校准。若用户草稿接近某个测试场景，优先读同类。
没有测试用例或场景未覆盖 test-cases/ 是让该技能个性化的关键：规则只是抽象总结，真实文风校准来自具体样本。若 test-cases/ 不存在，或草稿属于尚未覆盖的场景（如首篇英文邮件通讯、长技术博客、短评、中英混合），改写后用用户的语言邀请其保存为新样本。test-cases/ 在 .gitignore 中，样本只留在本地，不会提交。
风格规则（按重要性）
- 极少表情：全篇默认 0–2 个；标题、段首、列表项前不用装饰性表情，唯一允许用法是在对比之后作为情绪反应；用“装饰还是反应”来测试，删装饰留反应。
- 不用情绪词：避免“打脸/神话破灭/翻车/颠覆认知”等，改用“背书/共识/反对/质疑/边界”等中性表述，让事实说话。
- 用限定表述，避免绝对：避免“直接跑赢/必然更好/100%/一定”，改用“经常好过/往往更优/有时/不少情况下”；与来源措辞强度一致；类比也不夸大。例外：一篇可有一个明确判断，平实陈述并带时间范围，需作者认可，标注为“我的判断”并放在靠前位置。
- 标题是陈述，不是机械分层：避免“第一层：业界共识”式，标题本身应是观点，扫读标题即可得到核心论点。
- 段落紧凑，多为 1–3 句：把长段拆成 2–3 个短段，每段一个具体观点加一句解释；删掉只起过渡、重复或缓冲作用的句子。
- 少而准地引用：每个权威来源 2–3 句，引一行关键原话即止，不长篇解读。
- 英文术语用空格不用连字符：multi agent / sub agent / single agent 等；固定专名（KV-cache）保留连字符。
- 删除过渡句：删“接下来我们看/综上所述/值得注意的是/更重要的是”等空过渡；带实质指向的短语（如“具体到 eval”）保留。测试：删掉后下句仍能直接读下去，就是空过渡。
- 删除夸张修辞与漂浮抽象：让数据自己说话；抽象总结词不得单独出现，同句必须带具体数据或具名实体，否则删除重写。
- 以第一人称立场收尾：不以连串提问结尾，而是先承认不完美、给出自己的偏好、自然邀请；有明确判断的文章不靠提问拉互动，而是先给对行业的态度，再落到读者熟悉的具体做法，可加 [doge] 缓和。不要文学化收尾、回扣标题、戏剧化措辞或反问结尾。最后一句具体陈述就是结尾。
- 默认不加话题标签，也不建议标签，除非用户明确要求。
- 作品标题用《》，如《Don't Build Multi-Agents》。
- 列表项朴素，不用数字表情或加粗；重要数据另起一句。
- 准确标注引用：区分原创博客还是二手转述、博客还是访谈/直播/推文；不确定就保守写“在某次分享中提到”。
- 标题：一个“为什么”式问题或陈述，避免标题党；小红书标题还需不超过 20 字、能独立理解、使用读者会搜的词、不用“大厂”泛化、给反直觉说法加限定、可用趋势式标题。
- 不用 AI 式对比或强调结构：避免“不是 X 而是 Y”“真正的 X”“不仅 X 更是 Y”“与其说 X 不如说 Y”“看起来像 Y，其实是 Z”；直接陈述 Y，需要对比时并列事实。
- 不评论自己的写作：删“这个比喻很爽，但”“很少人注意到”“有个细节值得注意”以及对读者反应的叙述。
- 开门见山，不做元定位：避免先花两句说别人怎么说再给己见；第一句就是论点。可用一句并行句预览结构。小红书开头不带版本号或精确日期；产品首次用全名，之后用社区简称（Claude Code → cc）。罗列各公司做法（事实）不算元定位，可作为开头证据。