agentleFS
chengkj99chengkj99/kj-skills/skills/content-creator/SKILL.md

content-creator

Skill14 starsChanged 5 months agoMITView on GitHub

自动化内容创作工作流系统。通过特定的人设和风格,将已经明确的素材、角度或旧文章转化为高质量、有深度的输出(公众号长文、短视频脚本含深度口播档、小红书笔记)。短视频工作流支持「短平快 / 深度口播」双档与 Video Depth QA(机制、阈值理由、边界反例)。适用于正文生产、文章改编、深度拆解和多平台改写;若请求还包含用户问题调研、外部证据与时效核验、研究配图、知识沉淀决策和下一篇连载的一条龙流程,改用 research-backed-content-loop。

21 other projects use a version of this.

Adopted by

Most recently taken up by

The file

Files
SKILL.md

内容创作者 (Content Creator)

概述

本 Skill 提供一套标准化工作流,基于「AI 编程实战」方法论,从人设、结构、深度拆解到最终封装,全链路支持高质量内容生产。

三条铁律,缺一不可:

  1. 真实性铁律:不得为了人设、情绪、戏剧性或说服力补造第一人称经历、故事、对话、耗时、次数、数据、用户反馈或结果。只有用户素材或可追溯来源支持时才能当作真事写;否则改为客观表述、条件句或明确标注的假设示例。
  2. 洞见铁律:每篇文章必须有一个让人「哦,原来如此」的核心洞见。不是整合大众观点,是穿透本质的那一刀。文章没有洞见,写再多也只是热闹。
  3. 人味铁律:真实 > 完美。所有内容必须经过「去AI味」检查,但“人味”只能来自真实立场、具体判断、自然节奏和有证据的亲历,不能靠假故事伪装。

与完整内容闭环的边界

本 Skill 是正文生产引擎:接收已经明确的角度、素材或初稿,完成洞见深化、结构、成稿和封装。

如果用户要求同时完成用户问题调研、已有内容查重、外部证据与时效核验、研究配图、双视角评审、知识沉淀决策和下一篇连载,使用 research-backed-content-loop 作为总控,再由它在正文阶段调用本 Skill。不要把完整内容项目压缩成一次直接起草。


清晰表达:所有生成与改写工作流共用

起草前读取 十条表达原则与执行边界,明确读者已有经验、陌生术语和本篇要交付的理解或行动;润色时按该参考逐项检查。完成标准是关键段落能被读者准确复述,教程行动有前提与验证点,改稿没有丢失事实和条件。无需修改的段落保留原句,不把十条检查表复制到读者正文。

传播设计服务于意思传达:洞见、反转、金句和钩子只有在材料支持且帮助理解时才使用。普通但有依据的解释同样可以交付价值。

工作流决策树

分析输入类型,选择对应工作流:

  • 录音/转录稿 → 工作流 A(录音转文章)
  • 想法/热点/一句话 → 工作流 B(灵感孵化)
  • 已有文章/初稿 → 工作流 C(文章改编/润色)
  • 文章转视频 → 工作流 D(视频脚本)
  • 文章转小红书 → 工作流 F(小红书矩阵)
  • 竞品文章拆解 → 工作流 E(深度拆解)

所有生成类工作流(A/B/C)结束后,必须执行 Package Phase(封装)。


工作流 A:录音转文章

目标:将口语素材转化为2000字左右、有核心洞见、逻辑严密的专业文章。

阶段一:清洗(Clean)

去除口语冗余、重复、语气词。提炼出原始素材中的核心观点句(每个观点用一句话写下来,为下一阶段准备)。

输出:流畅版.md + 一份「核心观点提炼清单」。

阶段二:深度重构(Deep Structure)

这是文章质量的决定性阶段。

  1. 洞见挖掘(必须先做):
    • 从「核心观点提炼清单」中找到最反常识、最有价值的那一个。
    • 问自己:「如果读者没看这篇文章,他们能想到这个结论吗?」如果答案是「能」,说明洞见不够,需要继续挖掘。
    • 参考 references/深度论证框架.md 的「5层深度论证法」,确认洞见深度。
  2. 结构选型:引用 references/文章结构.md,选择最能承载这个洞见的结构模式。
  3. 饱和式论证:
    • 每个核心观点必须用「论点 → 案例 → 原理 → 反例 → 结论」五步完整论证。
    • 若素材不足,可以补充逻辑连接、概念解释和明确标注的作者分析;不得补造事实、案例、亲历、引语、数据或结果。需要事实支撑时,先补充可追溯来源或明确标记待核实。
    • 解释至少一处读者容易误解或原材料未讲透的问题;材料支持时可用反直觉分析,不为惊讶效果制造对立。
  4. 文章节奏设计:按照「开场高能 → 中段转折 → 收尾升华」安排能量起伏,避免平铺直叙。

阶段三:洞见质检(Insight QA)⭐️

这是新增的质量关卡,防止「结构正确但内容平庸」。

对文章进行以下逐项检查:

  • 洞见唯一性:文章是否有一个让人「哦!」的核心洞见?这个洞见是否贯穿全文?
  • 论证完整性:每个核心论点是否都有案例+原理+反例的支撑?还是只有结论?
  • 理解增量:是否解释了读者容易误解或未理解的问题?若使用反转,材料是否支持,是否确实帮助理解?
  • 深度检验:把文章的核心观点提炼成一句话,这句话是「描述现象」还是「解释机制」?后者才是真深度。
  • 读者收获感:读完这篇文章,读者能得到一个「以前不知道、现在知道了」的认知升级吗?

如果任何一项回答是「否」,必须回到阶段二继续深化,不能跳过。

阶段四:润色(Refine)

  • 引用 references/人设.md 和 references/金句.md 确认风格调性。
  • 应用「反爹味」原则,加入类比和口语化表达。
  • 执行完整去AI味检查:引用 references/remove-ai-tone-guide.md,检查全部 14 个核心检查项(含新增的洞见真实性和论证完整性检查)。
  • 发现问题,立即修复,修复后再输出。

输出:公众号文章_final.md。


工作流 B:灵感孵化

目标:从一个点子扩展为一篇2000字左右的深度长文,让读者看完直呼「牛」。

步骤一:破局点挖掘(Insight Mining)

这是决定文章天花板的一步,不能跳过。

对输入的想法,连续追问以下问题:

  1. 「这件事大家普遍的认知是什么?」(定位共识)
  2. 「这个共识哪里错了,或者不完整?」(找到裂缝)
  3. 「裂缝背后,更本质的问题是什么?」(挖到底层矛盾)
  4. 「这个底层矛盾,用什么框架可以解释清楚?」(建立分析模型)
  5. 「这个框架让读者多理解了什么?什么条件下成立?」(形成有依据的判断)

每一层都要写出来。第5层的答案,就是文章的核心洞见。

还可以尝试以下切入角度,选最能制造惊喜的那个:

  • 「反常识」角度:大家觉得是A,其实是B
  • 「根因」角度:大家在解决症状,真正的病根在这里
  • 「第一性原理」角度:从最基础的事实推导,推翻所有中间假设
  • 「长期视角」角度:短期看X,长期看Y,绝大多数人只看到了X

步骤二:论证骨架(Argument Framework)

洞见确定后,搭建完整论证骨架:

  • 核心论点(一句话)
  • 支撑论点 1 → 证据 → 反例
  • 支撑论点 2 → 证据 → 反例
  • 支撑论点 3 → 证据 → 反例
  • 边界条件(这个结论在什么情况下不成立)
  • 结论升华

参考 references/深度论证框架.md 确保论证质量。

步骤三:深度起草(Deep Draft)

引用 references/文章结构.md 进行饱和式扩写:

  • 每个论点必须有可追溯案例、数据或可验证的推理支撑(不能只有结论)。找不到证据时收窄结论,不用虚构案例填空。
  • 解释读者的关键困惑;反直觉分析仅在有依据且帮助理解时使用。
  • 字数目标:2000字左右(靠逻辑撑起来,不靠堆列表)。
  • 文章节奏:开场要抓人,中段要有转折,结尾要有余味。

步骤四:洞见质检 + 润色

同工作流 A 的阶段三 + 阶段四,执行完整的质检和去AI味检查。


工作流 C:文章改编

目标:旧文新写,让深度和专业度有质的飞跃,不是改几个词,是重新「立骨」。

分析阶段

  • 提取旧文的核心价值点(有什么是值得保留的?)
  • 升维思考:从更本质的角度(工程化思维、长期主义、第一性原理)重新解读这个话题,能得出比原文更深的结论吗?
  • 找到原文「点到为止、没有说透」的地方,这些是改编的重点。

重写阶段

  • 引用 references/文章结构.md 调整结构,增加论证密度。
  • 执行洞见质检:改编后的文章是否有真正的洞见?比原文的认知密度高了吗?
  • 执行去AI味检查:引用 references/remove-ai-tone-guide.md,检查全部 14 个核心检查项。

工作流 D:短视频脚本

目标:将文章转化为高完播率的口播脚本;若用户要求「深度」「讲透」「原理向」,必须同时产出可执行的口播密度,避免「短但空」。

两档产出(默认问清或双轨输出)

档位时长参考字数参考(中文口播)用途
短平快45–75 秒约 180–350 字信息流、强 Hook、收藏向清单
深度口播90–150 秒约 450–800 字视频号、关注后观看、建立专业信任

口播语速按约 200–240 字/分钟(清晰、有停顿)估算;含数字、英文缩写处自动放慢半拍。

约束条件(两档共用):

  • 开头:用真实问题、具体场景或有依据的判断吸引目标读者;钩子须与正文兑现一致,不制造焦虑或虚构反常识。
  • 语言:口语化优先;专业词必须带一句人话翻译(例如「token → 按字块计费、代码也算字」)。
  • 禁止只有「怎么做」没有「为什么」:至少回答读者会在评论区追问的 1 个机制问题(见下方「深度三问」)。

生成结构(深度口播必选):

痛点 → 误区揭示 → 机制层(为什么) → 边界与反例(什么时候不灵) → 实操建议 → 行动收口。

分镜:为每一段标注画面/特效建议,增加制作可行性。

深度口播专属:上线前自检(Video Depth QA)

生成或改编短视频稿时,逐项检查;任一项为「否」则补段,不得交短稿充数:

  • 机制:是否说清楚「现象背后的结构原因」(例如窗口竞争、注意力稀释、中间位置弱势),而不止「要清理」?
  • 数字有锚:出现百分比、阈值(如「七成」)时,是否解释为什么是这档、不是更低/更高各会有什么代价?(允许诚实说「经验阈值/产品余量」,禁止编造厂商内部参数。)
  • 反例/边界:是否有一句「什么情况可以不那么早压」「什么必须立刻 clear」?
  • 信息增量:删掉所有形容词,脚本是否仍有一个读者愿意转述给同事的点?
  • 去 AI 味:避免清单腔、避免「一、二、三」标题腔;金句全文 ≤5 句且不单独成段(与 references/remove-ai-tone-guide.md 对齐)。

「读者会追问的三件事」模板(至少覆盖 1 件,深度口播建议 2 件)

在稿内用口语自然嵌入,不必单独立标题:

  1. 为什么是这档阈值?(经验值 / 余量留给工具返回与模型长回复 / 避免贴顶后被动截断)
  2. 和「更早一点做」比,多等什么会吃亏?(信号被稀释、纠错成本、时间浪费)
  3. 不做的最坏情况是什么?(胡编接口名、改错文件、上下文打架)

与长文工作流的对齐

  • 核心洞见引用 洞见铁律:短视频可以短,但不能没有「哦,原来如此」的那一刀;若素材来自长文,不得只缩句,要保留一条论证链(机制或对比)。
  • 论证密度参考 references/深度论证框架.md 的「论点 → 案例 → 原理」压缩版(短视频可合并步骤,但不可只剩结论)。

封装(工作流 D 可选用):3 条 ≤80 字朋友圈文案 + 1 条置顶评论「追问答疑」预埋(回应机制向追问)。


工作流 F:小红书矩阵

目标:将长文章拆解为一系列高传播力的小红书笔记。

  1. 拆解评估:引用 references/小红书指南.md,分析知识点密度,决定拆解数量(通常 3-5 篇)。
  2. 笔记生成:
    • 标题:每篇 5 个备选(含 emoji 和情绪词)。
    • 正文:Hook + 干货 + 互动,emoji 含量高,一屏可读完。
    • 首图建议:详细描述视觉元素。
    • 标签:生成精准 tag。

工作流 E:深度拆解

目标:向优秀竞品文章学习思维模型,提炼可复用的写作策略。

执行分析:引用 references/深度拆解模型.md,输出 TL;DR、文章地图、观点-证据表、写作技巧分析、可复用模型提炼。


通用封装阶段(Package Phase)

适用于 A、B、C 工作流的最后一步。

引用 references/标题与配图指南.md,输出:

  1. 5 个爆款标题(痛点型/反常识型/方法型/清单型/强对比型),优先用「」。
  2. 配图方案(首图 + 内文图建议)。
  3. 3 条朋友圈文案(≤80字,口语化、利他、去爹味)。

核心资源

文件用途重要度
references/clear-expression.md十条原则、具体改稿动作与保真边界,生成与改写必读⭐⭐⭐⭐⭐
references/人设.md康健人设与写作风格⭐⭐⭐
references/深度论证框架.md5层论证法、反直觉挖掘、洞见升级⭐⭐⭐⭐⭐ 新增
references/文章结构.md四种文章结构模式 + 节奏设计⭐⭐⭐⭐
references/remove-ai-tone-guide.md14个检查维度,所有生成内容必读⭐⭐⭐⭐⭐
references/金句.md表达风格与类比库⭐⭐⭐
references/表达风格.md写作技巧与禁忌⭐⭐⭐
references/标题与配图指南.md封装阶段⭐⭐⭐
references/深度拆解模型.md工作流 E 专用⭐⭐
references/小红书指南.md工作流 F 专用⭐⭐

核心原则:交付有依据的理解或行动,用准确、自然的语言让读者看懂;洞见与传播设计服务于这个目标。

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.