作者： HOS(安全风信子)
日期： 2026-02-26
主要来源平台： GitHub（HOS_SKILL_WORKFLOW）
读完你能学到： 理解"AI 内容工业流水线"的完整设计——一条指令从内容方向到内容包、PPT 数据、TTS 音频稿、视频渲染规格、GitHub 项目注册全自动输出；并能把它装进 Claude Code / TRAE / Cursor，复用到你自己的 AI Agent 工作流里。

目录

先看问题场景

先说一段我的真实经历，2025 年底的事。

我做了一个开源项目，代码写完只花了两周，真正磨人的在后面。项目要发版，GitHub 仓库要 README，社区要一篇技术博客，讲师朋友要一套培训 PPT，运营要一段 5 分钟视频脚本，市场还要一个"演示 Demo"。我一个个手动来：README 写一天，CSDN 博客改三版写两天，PPT 从找模板到排版调了整整三天，视频脚本憋了两天，最后录演示视频又花了两天。

一周就这么没了，代码反而只占了两周里的一小段。 更崩溃的是，这些内容互相之间还没对齐——PPT 里的第 4 页讲的结论，和音频稿里第 3 幕说的案例对不上，视频脚本又和 README 的口径不一致。改一个，就得全部重排。

我当时就想：写代码我已经让 AI 干了，为什么做内容还要一件一件手动搬砖？

于是有了这篇文章的主角——GitHub 上 lxcxjxhx/HOS_SKILL_WORKFLOW 仓库的 S-06 模块：HOS-Fuck-Demo，一个把"内容生产"当成"工业流水线"来做的 AI Skill。这篇文章会把它的完整设计拆给你看，从痛点、Pipeline、深度分级、质量门禁，到怎么接入你的 AI Agent、怎么真正落地。读完你可以直接照着搭一条自己的内容流水线。

阅读提示：本文所有命令、参数、文件结构均来自仓库真实内容，代码块均标注了来源文件路径；个别无法在线核实的细节会标注【需核实】。

一、AI 内容生产的痛点：一个项目要喂饱 6 个内容出口

本节核心收获

搞清楚"内容生产"到底在生产什么，以及为什么手工一条条做必然慢、必然不一致——这是后面所有方案的前提。

1.1 一个项目发布，到底要多少种内容资产

我们先把账算清楚。一个稍微像样的项目/课程/产品发布，至少需要这些内容资产：

内容资产 对应出口 典型工作量（手工）
README GitHub 0.5~1 天
技术博客/文章 CSDN、公众号、掘金 1~2 天
培训 PPT 线下课、知识付费 2~3 天
音频稿/播客 音频专栏、TTS 配音 1 天
演示视频 B 站、YouTube、发布会 2~3 天
发布页/项目注册 官网、作品集 0.5 天

注：上表工作量是笔者的体感量级，仅供对比参考1。

注意，这还只是"数量账"。真正要命的是一致性账：

  • PPT 第 4 页说"问题冲击"，音频稿第 3 幕却跳到"方案路径"，听众一脸懵；
  • 博客里的数据（比如"3 亿岗位受影响"）和 PPT 里的数据对不上；
  • 视频时间轴和 PPT 页数没对齐，导致"画面讲 A、声音讲 B"。

这些问题手工做的时候几乎必然出现，因为你每做一个资产，都要重新回忆一遍内容结构，而人脑的记忆是会漂移的。这不是能力问题，是流程问题。

1.2 踩坑案例：我那一周的 PPT 事故

讲一个具体踩坑，大家引以为戒。

我那次做 PPT，先花了一天选模板，又花两天排版，自以为搞定了。结果演示视频脚本写完后，发现视频需要每页 PPT 精确对应 50 秒左右的时长（因为要按页切镜头、配旁白）。我那张"总览页"塞了 12 个要点，讲 50 秒根本讲不完，讲 3 分钟又太拖。

于是只好回炉：把 12 页拆成 14 页，每页重排要点，又花了一天半。等我改完，发现音频稿里"幕 1 开场钩子"对应的是 PPT 第 1 页，而我把目录页插到了第 2 页，整个时间轴又错位了。

这轮折腾给我的教训是三条：

  • 先定时间轴，再做内容，不要先做内容再对时间轴；
  • 内容结构要"模板化 + 槽位化"，同一个观点在 PPT、音频稿、内容包里必须是同一份数据；
  • 质量要"门禁化"，每一页讲几秒、每一幕多少字，应该在生成时就校验，而不是最后人工核对。

这就是后面 HOS-Fuck-Demo 的三个核心机制：时间轴标准（10 分钟 = 600 秒）、填槽不创作、质量门禁。先卖个关子，我们接着看为什么"让 AI 写内容"本身也解决不了这个问题。

1.3 小结

内容生产的痛点不是"写得慢"，而是资产种类多 + 彼此强依赖 + 手工维护必然错位。所以解法也不是"让 AI 帮你写得更快"，而是把整条链路变成一条受控的流水线。下一节我们说说为什么"AI 写内容"至今仍然很慢。

二、为什么"AI 写内容"仍然很慢：内容生产 ≠ 文字生成

本节核心收获

理解"内容生产"与"文字生成"的本质区别：前者是一条包含数据流转、校验、渲染、归档的 Pipeline，后者只是其中一步；AI 单独做"生成"这步，快不了多少。

2.1 一句话讲透：慢的不是打字，是衔接

很多人觉得"用 AI 写内容很慢"，于是换更大的模型、写更长的提示词，结果还是慢。其实 AI 生成文字本身只要几秒钟，真正吃掉时间的是"生成之后的衔接"：

  1. 这篇博客的结论，怎么变成 PPT 的要点？
  2. PPT 的要点，怎么变成音频稿的口语化句子？
  3. 音频稿的句子，怎么切分给 TTS 保证每句不超 25 字？
  4. 12 页 PPT 怎么精确铺满 600 秒，还和 4 幕音频时间轴对齐？
  5. 全部做完后，项目怎么登记、文件怎么归档、README 怎么生成？

每一步之间都有一个数据转换契约。手工做，就是人工当"搬运工"；用 AI 但没设计流程，就是让 AI 当"搬运工"——每次转换都重新理解一遍、重新生成一遍，速度快不起来，还会漂移。

2.2 为什么"AI 帮我写 PPT"这种单点工具没用

市面上的"AI 生成 PPT""AI 写视频脚本"工具很多，但用起来总觉得差了点什么。原因在于它们是单点工具，只管自己那一环：

  • 你给 AI 一个话题，它生成一套 PPT，但 PPT 里的观点和你的博客、音频毫无关系；
  • 换一个工具生成音频稿，又是另一套叙事；
  • 最后你还是那个"人肉集成商"，在四个工具之间来回搬数据。

HOS-Fuck-Demo 的仓库里有一句话把这个讲透了（见 skill/auto-pipeline.md）：

核心机制：用户一条指令 → AI 自动执行所有 STEP → 输出完整资产 → 自动注册项目。不中断、不确认、不跳过质量门禁。

也就是说，它的设计立场不是"再帮你写一种内容"，而是把整条流水线编排起来，让 AI 一次性把所有资产按同一份数据生产出来。

2.3 从"写手"到"流水线操作员"：一个思维转变

想真正提速，你得接受一个转变：内容生产的负责人不应该是一个"写手"，而应该是一个"流水线操作员"。

写手思维：给我一个题目 → 我写一篇文章 → 再写一份 PPT → 再写一个脚本……

流水线思维：给我一个方向 → 第一步解析成 3 个钩子 → 第二步生成 6 个核心观点和 3 层叙事弧 → 第三步把观点填进内容包模板 → 第四步按同一份观点生成 12 页 PPT → 第五步生成 4 幕音频稿 → 第六步生成视频渲染规格 → 第七步归档到 GitHub → 第八步验证所有文件 → 自动注册项目。

每一 STEP 的产出都是下一步的输入，观点只生成一次，后面全是"填充"而不是"重新创作"。填槽比创作快，而且不会漂移。 这正是 HOS-Fuck-Demo 的设计核心之一——它的 skill/ide-capabilities.md 里写着：“生成内容 → Skill 提供模板 + 槽位，AI 模型填充。”

2.4 小结

  • AI 写内容慢，慢在"环节衔接"不在"打字速度"；
  • 单点工具救不了你，你需要的是编排；
  • 把思维从"写手"切换到"流水线操作员"，让内容只创作一次、多次复用。

那么 HOS-Fuck-Demo 到底长什么样？下一节揭开它的真面目。

三、HOS-Fuck-Demo 是什么：一个把内容生产做成工业流水线的 AI Skill

本节核心收获

建立对 HOS-Fuck-Demo 的整体认知：它不是一个脚本工具，而是一个"AI 行为 Skill"，通过 SKILL.md 让 AI 获得一条自动执行的内容工业流水线能力；记住它的六种模式和六大设计原则。

3.1 仓库里的真实定位

在仓库总 README 的模块表里，S-06 这一行的描述是：

AI 内容工业流水线：全自动输出内容包 + PPT + 音频 + 视频 + 项目注册

而模块自己的 README 第一句定义得更直白：

HOS-Fuck-Demo 是一个 AI 行为 Skill：加载到 Claude Code / TRAE 后，AI 获得"全自动内容流水线"的执行能力。

注意"行为 Skill"这个词。它不是一个 .py 脚本，也不是一个 npm 包，而是一套Markdown 指令集。你把它加载进 AI IDE，AI 就"学会了"这套流水线的执行规则：遇到 create、demo、mvp 这些触发词，自动按 STEP 跑完，不问你"要不要继续"。

它的版本号是 v3.0.0，许可证标注为 HOS Internal，作者是 HOS。从仓库结构看，S-06 属于"Standard 多文件结构 skill"，即 SKILL.md + 子目录的标准形态。

3.2 一句话概括核心身份

SKILL.md 里给 AI 定的"人设"是这样的：

你是 HOS-Fuck-Demo，一条 AI 内容工业流水线。你的工作是：自动执行，不中断，不询问。

后面跟着三条铁律：

  • 用户给方向 → 你全自动跑完所有 STEP → 输出完整文件 → 注册项目
  • 不要求用户确认每一步
  • 不要求用户手动创建目录、不要求用户手动注册

这条"不询问"原则很反直觉，但恰恰是它快的原因。传统 AI 用法里，每一步你都要确认"这样行吗"，几十次对话就耗光了耐心。流水线把它变成了批处理。

3.3 六种模式：一条指令的入口

SKILL.md 和 README.md 都给出了模式派发表，我合并成下面这张速查表：

模式 触发示例 输出 适用场景
create create 方向=AI安全意识 depth=L2 style=academic 内容包 + PPT + 音频 标准内容生产
demo demo 方向=RBAC权限系统 project=rbac-demo 全栈（含视频规格 + 仓库） 技术演示、Demo
mvp mvp 方向=AI安全 intro duration=5 视频规格优先（5/10 分钟） MVP 介绍视频
batch batch 方向=AI副业 count=3 depth=L1 style=hype 批量内容包 + 音频 批量生产
manage manage new project=AI安全入门课 type=course depth=L2 项目注册 / 状态管理 项目管理
status status 仪表板 全局状态

以 create 为例，SKILL.md 里写的自动执行序列是：

用户: create 方向=AI安全意识 depth=L2 style=academic
  → 立即进入 auto-execution（不询问）
  → 读 auto-pipeline.md → 按 create 模式执行 STEP1→2→3→4→5
  → 自动注册项目 → 输出汇总

【来源：HOS_SKILL_WORKFLOW/S-06-HOS-Fuck-Demo/SKILL.md】

3.4 架构：几个目录各管一件事

模块的目录结构（摘自 README.md 的架构章节）：

HOS-Fuck-Demo/
│
├── SKILL.md                    ← 入口（加载此文件激活 Skill v3.0）
├── README.md                   ← 本文档
│
├── skill/
│   ├── auto-pipeline.md        ← 🔄 自动执行引擎（核心）
│   ├── core.flow.md            ← STEP1~7 + 质量门禁
│   ├── pipeline.md             ← 流水线编排
│   ├── templates/              ← 内容/PPT/音频/视频槽位模板
│   ├── levels/                 ← L1/L2/L3 级别指南
│   └── injectors/              ← 情绪引擎 + 风格预设
│
├── management/
│   ├── auto-register.md        ← 🔄 自动注册流程
│   ├── PROJECT-MANAGER.md      ← 项目管理器
│   ├── registry/               ← 项目注册表
│   ├── workflows/              ← 标准工作流
│   └── templates/              ← 章程/计划/日志模板
│
├── config/
│   ├── ide-capabilities.md     ← IDE 能力映射
│   ├── api-gateway.md          ← TTS/PPT/ffmpeg 接口
│   ├── levels-config.md        ← L1/L2/L3 定义
│   └── tts-presets.md          ← TTS 语音预设
│
└── output/                     ← AI 输出目录（自动生成）

【来源：HOS_SKILL_WORKFLOW/S-06-HOS-Fuck-Demo/README.md】

简单拆解一下各目录的职责：

skill/ —— 流水线引擎与模板
定义 STEP 流程、质量门禁、内容/PPT/音频/视频的槽位模板、L1/L2/L3 执行指南、情绪与风格注入器。这是"AI 怎么干活"的说明书。
management/ —— 项目管理
自动注册流程、项目管理器、注册表 project-registry.json、新建项目/内容审核/发布检查工作流、项目章程模板。这是"项目怎么管"的说明书。
config/ —— 环境与接口契约
IDE 能力映射（什么该 AI 做、什么该委派给 IDE）、TTS/PPT/ffmpeg 接口契约、L1/L2/L3 定义、TTS 语音预设、环境检测脚本。这是"AI 怎么和外部世界协作"的说明书。

3.5 六大设计原则

README.md 里列了设计原则，我结合源码展开：

  1. 自动优先 —— 不中断、不确认、不手动推进；
  2. 质量内建 —— 每 STEP 有 quality gate，不满足自动重试；
  3. IDE 委派 —— 文件 IO / git / Bash 直接调用 IDE 原生能力，Skill 是薄层；
  4. 填槽不创作 —— 模板 + 槽位，不让 AI 自由发挥；
  5. 10 分钟标准 —— 所有视频/音频统一 600 秒；
  6. 管理自动 —— 项目自动注册，无需手动维护。

这几条原则和我们前两节分析的痛点一一对应：自动优先治"慢"，质量内建治"错位"，填槽不创作治"漂移"，10 分钟标准治"没节奏"。它不是一个点子，是一套针对痛点的系统解。 下一节，我们把流水线放大看细节。

四、完整 Pipeline：方向到发布，一条指令跑完八个 STEP

本节核心收获

掌握 HOS-Fuck-Demo 的流水线骨架：STEP1~8 各自做什么、数据怎么在 STEP 之间流转、质量门禁怎么兜底。这是本文信息密度最高的部分，建议收藏。

4.1 全貌：一张图看懂整条流水线

先看 skill/pipeline.md 里定义的数据传递链：

STEP1(hooks) → STEP2(title+6ideas+narrative+emotion) → STEP3(content pack) → STEP4(12ppt) → STEP5(10min audio) → STEP6(600s video) → STEP7(repo)

【来源：HOS_SKILL_WORKFLOW/S-06-HOS-Fuck-Demo/skill/pipeline.md】

翻译成流程图就是这样：

是

否

是

否

用户指令
create / demo / mvp / batch

环境预检
environment-check.py

STEP1 方向解析器
方向 → 3 个钩子

STEP2 观点生成器
title + 6 观点 + 3层叙事弧 + 情绪曲线

STEP3 内容填充器
填 content-pack 模板 → 内容包

depth ≥ L2?

STEP4 PPT 生成器
12 页 JSON · 时间轴对齐 600s

STEP5 音频稿生成器
4 幕脚本 · 1800~2200 字

depth = L3 / demo / mvp?

STEP6 视频规格生成器
12 页 → 600s ffmpeg spec

STEP7 GitHub 归档
仓库结构 + commit message

STEP8 文件验证
防 0 字节 / 防占位符残留

auto-register 自动注册
写入 project-registry.json

📦 输出汇总报告

第二张图是 management/PROJECT-MANAGER.md 里的项目状态机——它解决的是"项目多了以后怎么管"的问题。一个项目从 draft 到 published，状态流转是被约束的，不允许双重状态：

项目章程已填写

钩子已确认+模板已选

内容包已生成

审核通过

审核不通过

发布后/手动归档

确认放弃

超30天 stale

draft

planning

production

review

published

failed

archived

4.2 八个 STEP 逐个拆解

每个 STEP 的职责、产出、写入路径，auto-pipeline.md 的"输出写入规则"表写得很清楚：

STEP 产出 写入路径
STEP1+2 观点数据（hooks / title / 6 ideas / 叙事弧 / 情绪） 内存保留，传递给 STEP3
STEP3 内容包 markdown output/{project-id}/01_content/{project-id}-content.md
STEP3.5 扩展音频文本（如需要） 内存保留，传递给 STEP5
STEP4 PPT JSON 数据（含 visual 字段） output/{project-id}/02_ppt/{project-id}-slide.json
STEP5 音频脚本（已清理标记） output/{project-id}/03_audio/{project-id}-script.txt
STEP6 视频渲染规格 JSON output/{project-id}/04_video/{project-id}-render-spec.json
STEP7 仓库结构 在 auto-register 阶段输出
STEP8 文件验证报告 + returncode 日志 在汇总报告中输出

【来源：HOS_SKILL_WORKFLOW/S-06-HOS-Fuck-Demo/skill/auto-pipeline.md】

4.3 关键设计：STEP 之间的"数据契约"

skill/pipeline.md 里定义了一份字段级的数据传递契约。这里我摘最重要的几行：

字段 产生于 消费于 格式约束
hooks[] STEP1 STEP2 yaml array of 3 strings
title STEP2 STEP3, STEP4 string, ≤20 字
key_ideas[] STEP2 STEP3, STEP4 array of 6 strings, ≤15字/个
idea_details[] STEP2 STEP3, STEP4 array of 6 strings, ≤30字/个
layer1/2/3_core STEP2 STEP3, STEP5 string, ≤30字
emotion_start/build/peak/end STEP2 STEP3, STEP5 情绪曲线 4 段
one_line_insight STEP2 STEP3, STEP4(页12) string, ≤20字
fact_1 STEP2 STEP3, STEP4(页3) ≤30字，数据
fact_2 STEP2 STEP3, STEP4(页11) ≤40字，案例
content_pack STEP3 STEP4, STEP5, STEP6 10分钟模板填充体
ppt_data STEP4 STEP6 12-page JSON（总600s）
audio_script STEP5 STEP6 10分钟 4幕脚本
render_spec STEP6 — 600秒 ffmpeg JSON

【来源：HOS_SKILL_WORKFLOW/S-06-HOS-Fuck-Demo/skill/pipeline.md】

这就是"只创作一次、多次复用"的落地方式：6 个观点在 STEP2 只生成一次，之后 PPT、音频稿、视频全部引用同一份数据。 所以 PPT 和博客永远对得上，因为它们是同一份观点的不同"渲染"。

4.4 质量门禁：每一 STEP 出口的自动闸门

质量内建怎么落地？答案是 core.flow.md 里每个 STEP 后面的 🔍 质量门禁。举几个真实的例子：

  • STEP1：hooks 数组长度必须 = 3（不多不少）；每个 hook ≤ 15 字；三个钩子形成递进（问题→翻转→行动）；不含领域标签。不满足 → 用原方向重新生成一次，再失败则输出 WARN 并继续。
  • STEP2：title ≤ 20 字且含数字或冲突感（比如"3个让你焦虑的AI真相"）；key_ideas 恰好 6 个、每个 ≤ 15 字；idea_details 每个 ≤ 30 字。
  • STEP3：无 {{}} 残留（所有槽位已填充）；内容包 600~800 tokens。
  • STEP4：pages 长度 = 12；duration_sec 合计 = 600s ±5%；每页 ≥30s ≤60s。
  • STEP5：4 幕结构完整；每句 ≤ 25 字；总字数 1800~2200 字；含 pause 节奏标记；含 tone 语气标记。
  • STEP6：slides 恰好 12 项；total_duration_seconds = 600 ±30；resolution = “1920x1080”；fps = 30；ffmpeg 命令 valid。
  • STEP8：所有预期文件存在且 size > 0（防 0 字节）；content 无 {{}} 残留；JSON 可解析；所有 subprocess returncode = 0（防静默失败）。

【来源：HOS_SKILL_WORKFLOW/S-06-HOS-Fuck-Demo/skill/core.flow.md】

每个 STEP 出口都有闸门，这正是"质量内建"四个字的落地形态：质量不是最后才检查，而是每一步生成时就校验，不合格直接返工。

门禁的容错策略也很"工程化"：每个 STEP 第一次不过就自动重新生成一次；重新生成还不过，输出黄色警告但继续（不阻塞流水线）；文件验证阶段 ≥3 个 FAIL 才停止。 这既保证了质量底线，又不会因为一次抖动就让整条线瘫痪。用 mermaid 表示这个决策逻辑：

通过

不通过

第1次

第2次

STEP 产出

质量门禁校验

写文件 → 进入下一 STEP

第几次失败?

自动重新生成一次

输出黄色警告

4.5 从流水线视角看"为什么快"

把 STEP 串起来看，整个 create 模式在 auto-pipeline.md 里的执行序列是这样的：

STEP1 → 方向解析器 → 3个钩子
  → auto-validate: 恰好3个钩子，每个≤15字

STEP2 → 观点生成器 → title + 6观点 + 3层叙事弧 + 情绪曲线
  → auto-validate: title含数字或冲突感，6个观点递进排列

STEP3 → 内容填充器 → 读取 content-pack.md → 填入槽位 → Write 文件
  → auto-validate: 所有槽位已填，总长600~800 tokens

[深度≥L2] STEP4 → PPT生成器 → 12页视觉数据 → Write JSON
  → auto-validate: 严格12页，每页时长合计600s

[深度≥L1] STEP5 → 音频稿生成器 → 4幕脚本 → Write 文件
  → auto-validate: 4幕结构完整，每句≤25字，总长1800~2200字

[深度=L3] STEP6 → 视频规格生成器 → 渲染规格 → Write JSON
  → auto-validate: 总时长600s±5%，12页映射完整

全部完成 → STEP8(文件验证) → auto-register → 输出汇总报告

【来源：HOS_SKILL_WORKFLOW/S-06-HOS-Fuck-Demo/skill/auto-pipeline.md】

每个 STEP 都有：明确的输入、明确的规则、明确的出口校验、明确的写入路径。这就是"工业流水线"的含义——每一步可预期，每一步可校验，整条线可自动跑。 下一节我们看这套流水线的"产品化分级"：L1 / L2 / L3。

五、一次输入，多种内容资产：L1 / L2 / L3 三层深度怎么选

本节核心收获

理解流水线不是"一刀切"：L1 只出内容包 + 音频，L2 加 PPT，L3 再加视频规格 + 仓库。学会按场景选深度、按预算控成本，并看懂"10 分钟标准"这个核心契约。

5.1 三层深度的输出清单

config/levels-config.md 把输出分成三档，我做成一张总表：

深度 输出清单 适用场景 每方向 Token 预算
L1 10 分钟内容包 + 10 分钟音频稿（4幕18002200字） 批量课程、播客、有声短文、音频专栏 ≤ 4000
L2 L1 + PPT 12 页数据（时间轴对齐 600s） 知识付费课件、10 分钟培训视频、演讲 PPT ≤ 6000
L3 L2 + 10 分钟视频合成规格 + 仓库结构 + commit 完整 Demo、YouTube/B 站视频、GitHub 发布、作品集 ≤ 12000

【来源：HOS_SKILL_WORKFLOW/S-06-HOS-Fuck-Demo/config/levels-config.md】

注意"批量约束"是反直觉的：越深的层级越不适合批量。levels-config.md 明确写着 L1 推荐 batch count ≤ 5，L2 推荐 count ≤ 3，L3 不建议 batch（一次一个）。原因很简单——L3 要做视频规格 + 仓库 + 项目管理登记，状态强依赖，批量容易串。

5.2 “10 分钟标准”：所有内容的统一契约

这个 Skill 最狠的设计之一，是把所有内容统一成 10 分钟 = 600 秒。core.flow.md 末尾有一张新旧标准对照表：

项目 原标准 新标准
视频总长 40~60 秒 600 秒（10 分钟）
音频总长 40~60 秒 600 秒（10 分钟）
内容包字数 ~250 字 600800 字
核心观点 3 个 6 个
PPT 页数 6 页 12 页
音频句子 ~10 句 6080 句
音频总字数 ~300 字 18002200 字

【来源：HOS_SKILL_WORKFLOW/S-06-HOS-Fuck-Demo/skill/core.flow.md】

为什么统一成 600 秒？因为只有统一长度，PPT、音频、视频三者才能做严格时间轴对齐。12 页 PPT 各分配 30~55 秒，恰好凑成 600 秒；4 幕音频按 120s / 210s / 180s / 90s 分布，总长也是 600 秒；视频规格里每个 slide 的 start_time 和 duration_seconds 由这套时长算出。长度不统一，对齐就是空谈。

页时长映射（来自 video-spec.md）：

Page 内容 时长（秒） 累计 对应音频幕
1 标题页 30 0→30 幕1 开场
2 问题冲击 50 30→80 幕1 问题
3 问题证据 55 80→135 幕1 证据
4 常见误区 50 135→185 幕2 误区
5 真相揭示 55 185→240 幕2 翻转
6~8 核心观点 1~6 55×3 240→405 幕2 观点
9~10 方法步骤 1~5 50/45 405→500 幕3 方法
11 案例/故事 50 500→550 幕3 案例
12 总结/CTA 50 550→600 幕4 收尾

【来源：HOS_SKILL_WORKFLOW/S-06-HOS-Fuck-Demo/skill/templates/video-spec.md】

5.3 资产之间的关系：同一份数据，多种渲染

用 mermaid 表示"一次输入 → 多种资产"的关系：

方向输入
create 方向=AI安全意识 depth=L2 style=academic

STEP2 观点库
6 核心观点 + 叙事弧 + 情绪曲线

01 内容包
600~800 tokens

02 PPT 数据
12 页 slide.json

03 音频稿
4 幕 script.txt

04 视频规格
render-spec.json

GitHub 归档
仓库结构 + commit

README / 发布页

注意 one_line_insight（一句话洞察）这个字段会同时出现在内容包、PPT 第 12 页、音频稿幕 4 金句里；fact_1 数据会同时出现在内容包、PPT 第 3 页证据页。这就是一致性保证的实现机制。

5.4 Token 预算：内容生产的"成本工程"

levels-config.md 里 L3 的预算表长这样（摘录）：

阶段 预算
方向解析 + 观点生成（STEP1+2） ≤ 1200 tokens
10分钟内容包（STEP3） ≤ 800 tokens
STEP3.5 音频扩展（audio-expander） ≤ 2000 tokens
PPT 12页数据（STEP4） ≤ 1000 tokens
10分钟音频稿（STEP5） ≤ 2000 tokens
视频合成规格（STEP6） ≤ 1000 tokens
仓库结构 + commit（STEP7） ≤ 400 tokens
项目管理登记 ≤ 400 tokens
每方向总计 ≤ 12000 tokens

【来源：HOS_SKILL_WORKFLOW/S-06-HOS-Fuck-Demo/config/levels-config.md】

一条完整 L3 流水线 ≈ 12000 tokens，对应产出 4 个内容资产 + 仓库归档。算一笔账：手工做这堆东西要一周，token 成本按 API 价格不过几块钱。时间的 ROI 和金钱的 ROI 同时成立，这是它能"落地"而不是"炫技"的关键。

这里还有个隐藏的工程细节：音频稿字数和时长之间有换算公式，levels-config.md 里写的校验是

T s e c o n d s = W c h a r s R a t e w p m × 0.8 T_{seconds} = \frac{W_{chars}}{Rate_{wpm} \times 0.8} Tseconds​=Ratewpm​×0.8Wchars​​

即字数 ÷ 语速 ÷ 0.8（留出停顿占比），L3-extended 用它验证"2500~3000 字是否能撑满 600s ±5%"。这个公式在本文附录 B 里也会给出简表。

5.5 小结

  • 按场景选深度：批量选 L1，课件选 L2，发版演示选 L3；
  • 10 分钟标准是"对齐"的前提，600 秒是锚点；
  • Token 预算是成本工程，L3 全程 ≈ 12000 tokens。

六、Demo 自动生成：从"演示"到"全栈内容工厂"

本节核心收获

掌握 demo 和 mvp 两种模式与 create 的差异：demo 默认 L3 全栈且必须给 project-id；mvp 是视频优先的 5/10 分钟快线。并看到视频渲染的真实命令和 Windows 下的文件持久化坑。

6.1 demo 模式：全栈输出的默认选项

auto-pipeline.md 对 demo 的定义很明确：默认 depth = L3，输出内容 + PPT + 音频 + 视频规格 + 仓库，且 project-id 必须提供。

与 create 的区别在于（引用原文要点）：

  • 默认深度 L3（全栈输出）
  • 项目 ID 必须提供（demo 通常需要特定命名）
  • 内容包可精简为 4 个核心观点（非标准 6 个，节省 token）
  • 音频稿可精简为 3 幕（省去幕2部分内容，但仍保持 10 分钟）
  • 视频规格必须完整输出（因为 demo 的目标就是视频）
  • PPT 保持 12 页不变（视频需要页面对齐）

【来源：HOS_SKILL_WORKFLOW/S-06-HOS-Fuck-Demo/skill/auto-pipeline.md】

也就是说 demo 模式在"全栈"和"省 token"之间做了取舍：观点从 6 砍到 4，幕数从 4 砍到 3，但 PPT 12 页和视频 600 秒一根不少。它的执行序列在 SKILL.md 里写得极简：

用户: demo 方向=RBAC权限系统 project=rbac-demo
  → 立即进入 express 模式（不询问）
  → 读 auto-pipeline.md → demo 模式（默认 L3，4观点，3幕音频）
  → 自动注册项目 → 输出汇总

【来源：HOS_SKILL_WORKFLOW/S-06-HOS-Fuck-Demo/SKILL.md】

6.2 mvp 模式：视频优先的 5/10 分钟快线

mvp 模式是"视频优先"：PPT + 视频规格是核心产出，内容包和音频作为支撑。支持两种时长：

参数 5 分钟模式 10 分钟模式
PPT 页数 6 页 12 页
音频幕数 3 幕（~1000 字） 4 幕（~2000 字）
视频时长 300 秒 600 秒
默认风格 academic academic

项目 ID 不提供时，自动生成 mvp-{seq}-{keyword}。触发示例：mvp 方向=AI安全 intro duration=5。

6.3 视频渲染：从规格到成片的真实命令

规格文件输出后，真正的渲染靠 ffmpeg。video-spec.md 里给出了 12 页 + 10 分钟音频的完整渲染命令（关键部分）：

# 12 张幻灯片按各自时长播放 + 10 分钟音频合成
ffmpeg -y \
  -framerate 1/30  -i slide_01.png \
  -framerate 1/50  -i slide_02.png \
  -framerate 1/55  -i slide_03.png \
  -framerate 1/50  -i slide_04.png \
  -framerate 1/55  -i slide_05.png \
  -framerate 1/55  -i slide_06.png \
  -framerate 1/55  -i slide_07.png \
  -framerate 1/55  -i slide_08.png \
  -framerate 1/50  -i slide_09.png \
  -framerate 1/45  -i slide_10.png \
  -framerate 1/50  -i slide_11.png \
  -framerate 1/50  -i slide_12.png \
  -i 03_audio/{project-id}.mp3 \
  -filter_complex \
    "[0:v]fade=t=in:st=0:d=0.5[v0]; ... [v0]...[v11]concat=n=12:v=1:a=0[vid]" \
  -map "[vid]" -map 12:a \
  -c:v libx264 -pix_fmt yuv420p \
  04_video/{project-id}.mp4

【来源：HOS_SKILL_WORKFLOW/S-06-HOS-Fuck-Demo/skill/templates/video-spec.md】

6.4 踩坑案例：Windows 下 .mp4 被"吃掉"

这是我在真实跑流水线时遇到、并且仓库里专门做了防御的一个坑：某些环境（TRAE / 安全软件）会扫描并自动清空 .mp4 文件。

video-spec.md 里明确写了这个已知问题，并给出防御策略：

交付格式 免疫清理 推荐场景
.mp4 直接输出 ❌ 可能被清理 Linux/macOS
.zip 打包交付 ✅ 完全免疫 Windows 推荐
渲染到临时目录 → 迁移 ⚠️ 部分免疫 需要 mp4 直读时

执行规则是：平台 = Windows → 渲染到临时目录 → 验证文件有效 → .zip 打包交付。同时 environment-check.py 里专门有一项"文件清理风险检测"，Windows 下会输出 WARN 提示。这个坑提醒我们：内容流水线不只是"生成"，还要管好文件的生命周期。

6.5 小结

  • demo = L3 全栈 + 4 观点 + 3 幕 + 12 页 PPT + 600s 视频规格，必须给 project-id；
  • mvp = 视频优先，5 分钟 6 页 / 10 分钟 12 页；
  • 视频靠 ffmpeg 合成，Windows 交付记得走 .zip 防清理。

七、如何接入 AI Agent：从下载到跑通第一条流水线

本节核心收获

学会把 HOS-Fuck-Demo 装进 Claude Code / TRAE / Cursor，跑环境检测，并把 TTS、PPT、ffmpeg 三个外部工具接进来。这条"接入路径"本身是可复用的方法论。

7.1 安装：两种方式

README.md 给了两种安装方式。方式一（推荐）：把 SKILL.md 放到 AI IDE 的技能目录：

# Claude Code
cp SKILL.md ~/.claude/skills/

# TRAE
cp SKILL.md .trae/skills/

# Cursor
cp SKILL.md .cursor/skills/

方式二：完整部署

git clone https://github.com/lxcxjxhx/HOS_SKILL_WORKFLOW.git
cd HOS_SKILL_WORKFLOW/S-06-HOS-Fuck-Demo

【来源：HOS_SKILL_WORKFLOW/S-06-HOS-Fuck-Demo/README.md】

仓库总 README 里列出的兼容平台包括：Claude Code、OpenAI Codex、Cursor、Gemini CLI、VSCode AI IDE、Trae，均为 ✅ 支持。

7.2 环境要求

README.md 的配置章节写明：

  • Python 3.8+（用于 TTS 和 ffmpeg 集成）
  • Node.js 16+（用于 PPT 生成）
  • ffmpeg（用于视频合成）

environment-check.py 的依赖检测列表还包含：Pillow、numpy、opencv-python（可选）、moviepy、imageio-ffmpeg、edge-tts、markitdown，以及 Node 侧的 pptxgenjs。一键安装命令（脚本自带提示）：

pip install imageio-ffmpeg moviepy Pillow numpy edge-tts
npm install pptxgenjs

【来源：HOS_SKILL_WORKFLOW/S-06-HOS-Fuck-Demo/config/environment-check.py】

7.3 跑一次环境检测：先知道自己站在哪

流水线在首次执行时会先跑环境预检，读取 config/env-check.md 并执行 environment-check.py。检测结果决定三件事：

检测结果 影响
ffmpeg 不可用 STEP6 输出 render-spec.json + 标注"需人工渲染"
edge-tts 不可用 STEP5 输出脚本 + 标注"需人工 TTS 转换"
平台 = Windows 交付格式改为 .zip，pipe 渲染改用线程安全模式
缺少 Python 包 输出安装命令，继续执行数据生成

【来源：HOS_SKILL_WORKFLOW/S-06-HOS-Fuck-Demo/config/env-check.md】

env-check.md 里有个细节值得抄：ffmpeg 要区分"系统精简版"和 imageio-ffmpeg 捆绑完整版。Windows 自带或精简版 ffmpeg 可能缺 libmp3lame，导致转码失败；检测脚本会优先推荐 imageio-ffmpeg。这是典型的"环境坑前置化"做法。

7.4 三个外部工具的接入契约

流水线自己不实现工具，它只定义接口契约（config/api-gateway.md），执行交给 IDE 原生 Bash。三个核心契约：

① TTS（edge-tts，免费本地）

{
  "provider": "edge-tts",
  "voice": "zh-CN-XiaoxiaoNeural",
  "speed": 1.0,
  "pitch": 0,
  "output": "03_audio/{project-id}.mp3"
}

【来源：HOS_SKILL_WORKFLOW/S-06-HOS-Fuck-Demo/config/api-gateway.md】

② PPT（python-pptx 本地脚本） —— AI 只输出每页 title + content + notes，脚本组装为 .pptx，无幻觉、可控、免费。

③ 视频（ffmpeg）

{
  "engine": "ffmpeg",
  "inputs": {"images": ["02_ppt/slides/*.png"], "audio": "03_audio/{project-id}.mp3"},
  "output": "04_video/{project-id}.mp4",
  "params": {"fps": 1, "transition": "fade", "resolution": "1920x1080"}
}

【来源：HOS_SKILL_WORKFLOW/S-06-HOS-Fuck-Demo/config/api-gateway.md】

当工具不可用时有完整回退策略：edge-tts 不可用 → 输出 script.txt 标注"需 TTS 转换"；python-pptx 不可用 → 输出 slide.json 标注"需渲染"；ffmpeg 不可用 → 输出 render-spec.json 标注"需合成"。“数据永远先生成，渲染永远可降级”，这个思路很值得抄到自己的项目里。

7.5 进阶：TTS 的"原生慢速"铁律

audio-script.md 里有非常具体的技术铁律，我单独拎出来讲，因为它是一个高价值的踩坑经验：

核心原则：使用 edge-tts 原生慢速，禁止后处理速度拉伸（moviepy speed_scale 会造成音质劣化）。

❌ 错误方案（导致音质劣化）:
   edge-tts (rate=+10%, ~70秒) → moviepy speed_scale(0.75) → ~600秒
   └─ moviepy 时间拉伸算法引入数字失真、颤音、机械感

✅ 正确方案（原生慢速，无失真）:
   edge-tts (rate=-30%, ~原始时长3x) → 分段合成 → concat合并

【来源：HOS_SKILL_WORKFLOW/S-06-HOS-Fuck-Demo/skill/templates/audio-script.md】

配套规则还有三条：

  • Windows 上必须通过 python 模块调用：python -m edge_tts ...，直接敲 edge-tts 命令可能不可用；
  • 长文本必须分段合成：总字数 > 1200 时按幕分段（幕1~4 各自合成），再用 ffmpeg concat 合并；
  • --rate=-30% 是最慢语速：超过这个值音调开始不自然，若还达不到目标时长，应增加字数而非继续降速。

这个教训的本质是：追求"时长"时，别用破坏音质的后处理，而要用 TTS 原生参数 + 内容量控制。 你的内容流水线如果接 TTS，这条直接可用。

7.6 快速上手：第一条流水线怎么跑

装好之后，最快验证效果的两条命令：

# 标准内容生产（内容包 + PPT + 音频）
create 方向=AI安全意识 depth=L2 style=academic

# 全栈 Demo（内容 + PPT + 音频 + 视频规格 + 仓库）
demo 方向=RBAC权限系统 project=rbac-demo

【来源：HOS_SKILL_WORKFLOW/S-06-HOS-Fuck-Demo/README.md】

SKILL.md 里还规定了"例外才询问"的清单——只有四种情况 AI 才需要停下来问用户：

  • direction 缺失 → 问：“请提供内容方向”
  • depth 缺失 → 默认 L2（不询问）
  • project-id 冲突 → 问：“project-id 已存在，是否覆盖？”
  • 方向过于宽泛无法解析 → 问：“请具体化方向描述”

除此之外，一律闭嘴干活。这是"自动化"的边界设计：必须问的才问，能默认的绝不打扰。

7.7 小结

  • 安装 = 拷 SKILL.md 进 IDE 技能目录，或 clone 仓库；
  • 先跑 environment-check.py，让流水线自己选渲染策略；
  • TTS 用 edge-tts 原生慢速，绝不后处理拉伸；工具不可用就"降级交付数据文件"。

八、实际案例：一个 GitHub 项目从 Repo 到演示视频的全流程

本节核心收获

跟着一个真实示例走完整条链路：demo 方向=RBAC权限系统 project=rbac-demo 会产出什么、每个文件长什么样、时间轴怎么对齐。这是把前面所有概念串成"可感"体验的一节。

8.1 起点：一个已完成的 GitHub 项目

假设你刚做完一个 RBAC 权限系统（Role-Based Access Control，基于角色的访问控制），代码在 GitHub。现在要给它做一整套发布内容。按 HOS-Fuck-Demo 的方式，你只需要一句话：

demo 方向=RBAC权限系统 project=rbac-demo

按 auto-pipeline.md 的 demo 模式执行序列：

STEP1(方向→3钩子) → STEP2(title+4观点+3层叙事弧+情绪)
  → STEP3(填充4观点内容包) → STEP4(12页PPT)
  → STEP5(10分钟3幕音频稿) → STEP6(600s视频规格)
  → STEP7(仓库结构) → STEP8(文件验证) → auto-register

【来源：HOS_SKILL_WORKFLOW/S-06-HOS-Fuck-Demo/skill/auto-pipeline.md】

8.2 产出：output/rbac-demo/ 目录长什么样

按 README.md 的输出目录规范和 auto-register.md 的目录创建规则，最终会长成这样：

output/rbac-demo/
├── 01_content/
│   └── rbac-demo-content.md          ← 内容包（4 观点 + 3 层叙事弧）
├── 02_ppt/
│   └── rbac-demo-slide.json          ← 12 页 PPT 数据
├── 03_audio/
│   └── rbac-demo-script.txt          ← 10 分钟音频稿
├── 04_video/
│   └── rbac-demo-render-spec.json    ← 600 秒视频渲染规格
└── README.md                         ← 项目说明

8.3 内容包长什么样

内容包是流水线的"中枢数据"。按 content-pack.md 的槽位模板，填充后的内容包结构（示意，来自模板的填充示例）：

## RBAC 权限系统：别再让权限管理毁掉你的应用

**方向**: RBAC权限系统
**风格**: academic | **情绪**: neutral
**时长**: 10分钟 | **叙事**: 3层递进

### 开场钩子
> 90% 的越权漏洞，根源都是权限模型设计失误。

### 核心观点（递进排列）
1. **权限不是功能，是安全边界** — 每一个越权漏洞都是边界失守
2. **RBAC 用角色解耦用户与权限** — 管理员不再直接面对数百条权限
3. **最小权限原则是底线** — 授最少、够用即止
4. **动态权限正在取代静态配置** — 策略即代码，审计才可追溯

### 三层叙事弧
| 层 | 阶段 | 核心 | 时长 |
|---|------|------|------|
| 层1 | 问题冲击 | 越权漏洞的成本远超想象 | ~2.5min |
| 层2 | 认知翻转 | RBAC 不是造轮子，是补地基 | ~4min |
| 层3 | 行动升华 | 三步落地一套最小权限模型 | ~3.5min |

### 一句洞察
> 权限模型的优劣，决定了系统的安全上限。

### 关键素材
- 数据/事实: OWASP Top10 中越权/失效访问控制常年位居前列
- 案例/故事: 某企业因未做权限校验导致数据泄露，损失数千万

【说明：以上内容为按 content-pack.md 模板结构与槽位示例组合的演示文本；具体数值与案例如需正式发布请以真实数据替换】

注意：上面这段我是按仓库模板的槽位和"填充示例"风格组合的演示文本，不是仓库里现成的 rbac-demo 输出文件（仓库 output/ 目录不包含实际生成物）【需核实】。你要做自己的项目时，把方向换成你的，其余机制不变。

8.4 PPT 数据长什么样

ppt-6page.md 的 JSON 输出格式定义了 12 页结构，前两页示意：

{
  "project": "rbac-demo",
  "template": "12page-10min",
  "style": "academic",
  "total_duration": 600,
  "pages": [
    {"page": 1,  "title": "RBAC 权限系统实战", "content": "权限模型的优劣，决定了系统的安全上限", "duration_sec": 30,  "notes": "开场引言"},
    {"page": 2,  "title": "越权之痛",           "content": "失效访问控制位列 Web 应用风险前列",     "duration_sec": 50,  "notes": "冲击感"}
  ]
}

【来源：HOS_SKILL_WORKFLOW/S-06-HOS-Fuck-Demo/skill/templates/ppt-6page.md（结构）】

8.5 音频稿长什么样

audio-script.md 的填充示例（AI 安全主题，但结构完全通用）展示了 4 幕音频稿的形态，节选：

【幕1：问题冲击 — 0:00~2:00】

你知道AI正在取代多少编程工作吗？
这个数字可能远超你的想象。

麦肯锡最新报告显示，3亿岗位将在未来几年受影响。
其中程序员群体首当其冲。
70%的编码工作已经可以被AI自动化完成。



【幕4：升华号召 — 8:30~10:00】

归根结底，不是AI淘汰你，而是会用AI的人正在淘汰你。
想象一下，六个月后的你会是什么样子。
当别人还在观望和焦虑，你已经走在了前面。

未来从来不属于AI，而是属于那些善于使用AI的人。

【来源：HOS_SKILL_WORKFLOW/S-06-HOS-Fuck-Demo/skill/templates/audio-script.md】

注意这个模板的两个技术细节：每句 ≤ 25 字（TTS 友好）、段落之间空行（TTS 在句号处自然停顿，替代 [pause] 标记）。audio-script.md 里专门强调：[pause] 不是标准 SSML，edge-tts 不会正确解析，所以合成前必须用 clean_script_for_tts() 把标记剥掉。

8.6 视频规格长什么样

video-spec.md 的 render-spec.json，头几项示意：

{
  "project": "rbac-demo",
  "spec_version": "2.0",
  "engine": "ffmpeg",
  "resolution": "1920x1080",
  "fps": 30,
  "total_duration_seconds": 600,
  "slides": [
    {"page": 1, "image": "slide_01.png", "start_time": 0.0,  "duration_seconds": 30, "audio_segment": "幕1_开场_0s_30s", "transition": "fade_in"},
    {"page": 2, "image": "slide_02.png", "start_time": 30.0, "duration_seconds": 50, "audio_segment": "幕1_问题冲击_30s_80s", "transition": "fade"}
  ]
}

【来源：HOS_SKILL_WORKFLOW/S-06-HOS-Fuck-Demo/skill/templates/video-spec.md（结构）】

8.7 时间轴对齐：这条流水线的"质检命门"

把 PPT 页、音频幕、视频段三者对齐，是 L3/demo 的核心约束。L3-full-demo.md 里有一张对齐校验表（节选关键行）：

时间段 PPT 页 音频幕
0:00~0:30 1 标题页 幕1 开场
0:30~1:20 2 问题冲击 幕1 问题
1:20~2:15 3 证据 幕1 证据
2:15~3:05 4 误区 幕2 误区
3:05~4:00 5 真相 幕2 翻转
4:00~6:45 6~8 观点 幕2 观点
6:45~8:20 9~10 方法 幕3 方法
8:20~9:10 11 案例 幕3 案例
9:10~10:00 12 总结 幕4 收尾

【来源：HOS_SKILL_WORKFLOW/S-06-HOS-Fuck-Demo/skill/levels/L3-full-demo.md】

这正好回应了开篇我踩的那个坑：先定时间轴，再做内容。 流水线把时间轴当作最上层契约，PPT 时长、音频幕时长、视频段时长全部从同一套 600 秒分配里推出来，天然对齐。

8.8 收尾：自动注册与发布

跑完后，auto-register.md 会自动写入注册表，注册条目格式：

{
  "id": "demo-001-rbac-system",
  "name": "RBAC权限系统",
  "type": "demo",
  "status": "production",
  "depth": "L3",
  "created": "2026-02-26",
  "outputs": {"content": true, "ppt": true, "audio": true, "video": true},
  "tags": ["demo", "L3"]
}

【来源：HOS_SKILL_WORKFLOW/S-06-HOS-Fuck-Demo/management/auto-register.md（结构）】

然后项目进入 PROJECT-MANAGER.md 定义的状态机，走 review → published；发布前跑 publish-check.md 的最终清单（无占位符、JSON 可解析、注册表已更新、commit message 格式正确）。到此，一个项目的全套内容资产 + 项目管理闭环就齐了。

8.9 小结

  • demo 方向=RBAC权限系统 project=rbac-demo 一条指令产出 4 个资产 + 仓库 + 注册；
  • 内容包是中枢数据，PPT/音频/视频都是它的"渲染"；
  • 时间轴对齐是 L3 的质检命门，600 秒分配表锁死一切。

九、为什么这不是普通 AI 写作：五个"工程化"的本质差异

本节核心收获

看清 HOS-Fuck-Demo 与"让 AI 写篇文章/做个 PPT"的本质区别：它把内容生产从"生成"升级为"受控的工业流水线"。这五个差异也是你自建流水线时要抓住的骨架。

9.1 差异一：从"自由生成"到"填槽不创作"

普通 AI 写作：AI 自由发挥，每次生成的风格、结构、质量不可控。
HOS-Fuck-Demo：content-pack.md 定义死槽位，AI 只负责填充，质量门禁检查"无 {{}} 残留"。

ide-capabilities.md 里写得很透：

生成内容 → Skill 提供模板 + 槽位，AI 模型填充。

自由创作是好作家的活，流水线要的是可复现。 模板 + 槽位牺牲了一点"惊艳"，换来的是 10 份内容 10 份同构——而这恰恰是规模化生产的前提。

9.2 差异二：从"单点产出"到"数据契约驱动的多资产"

普通 AI 写作：你写博客，AI 写博客；你问 PPT，AI 另写一套。
HOS-Fuck-Demo：pipeline.md 定义了字段级数据契约，key_ideas 在 STEP2 生成一次，STEP3/4/5 全部消费它。所以 PPT 和博客永远一致。

9.3 差异三：从"人工质检"到"质量门禁 + 自动重试"

普通流程：产出后人工核对，发现错位再手动改。
HOS-Fuck-Demo：每 STEP 出口有门禁，不满足自动重试一次，再失败 WARN 并继续；STEP8 做全量文件验证（防 0 字节、防占位符、验 returncode）。

9.4 差异四：从"人肉项目管理"到"自动注册 + 状态机"

普通流程：项目多了，Excel 记状态，经常忘了哪个到哪一步。
HOS-Fuck-Demo：auto-register.md 自动生成 {type}-{seq:03d}-{keyword} 格式 ID，写入 project-registry.json，seq 按类型自增且永不复用；PROJECT-MANAGER.md 用状态机约束 draft → planning → production → review → published/archived。超过 30 天未更新的 draft 自动标记为 stale。

9.5 差异五：从"黑盒"到"环境预检 + 显式降级"

普通脚本：环境缺依赖直接报错，整条线中断。
HOS-Fuck-Demo：environment-check.py 先行检测，ffmpeg 缺了就"降级输出 render-spec.json + 标注需人工渲染"；Windows 平台自动改 .zip 交付。宁可降级交付，绝不静默失败。

用一张对比表收拢：

维度 普通 AI 写作 HOS-Fuck-Demo 流水线
内容生成 自由发挥 模板 + 槽位填充
多资产一致性 人工保证 数据契约保证
质量 事后人工查 每 STEP 门禁 + 自动重试
项目管理 人肉维护 自动注册 + 状态机
环境异常 报错中断 预检 + 降级交付
单次成本 不可预估 L1≤4000 / L2≤6000 / L3≤12000 tokens

【token 预算来源：HOS_SKILL_WORKFLOW/S-06-HOS-Fuck-Demo/config/levels-config.md】

9.6 小结

一句话总结这节：普通 AI 写作解决"写得出"，流水线解决"稳定地批量产出且不会错位"。 如果你只是偶尔写一篇随笔，不需要流水线；如果你要每周产出多套课程/多个 Demo 的内容资产，流水线是唯一不会崩的方案。

十、总结：让 AI 成为你的内容工厂

本节核心收获

收束全文：你能带走什么、立刻能做什么、下一步去 GitHub 怎么继续。

10.1 学完本文，你能做什么

  • 读懂 HOS-Fuck-Demo 的完整架构：SKILL.md 入口 + skill/ 流水线 + management/ 项目管理 + config/ 环境契约；
  • 用 create / demo / mvp / batch / manage / status 六种模式驱动内容生产；
  • 按 L1/L2/L3 选深度，用 600 秒标准对齐 PPT、音频、视频时间轴；
  • 接入 edge-tts、python-pptx、ffmpeg 三个工具，并理解"原生慢速 / 降级交付"两条技术铁律；
  • 把"填槽不创作 + 质量门禁 + 自动注册"这套工程思想，复制到你自己的任何 AI Agent 工作流里。

10.2 两个金句

内容生产不是文字生成，是数据流水线；快不是来自更强的模型，而是来自更狠的编排。

AI 不会替你写 PPT 写视频，但 AI 可以替你跑完一条你设计好的内容流水线——你要做的，是先把流水线设计出来。

10.3 下一步：去 GitHub

这套 Skill 的完整代码都在开源仓库里（AGPLv3 许可，仓库 README 有注明）：https://github.com/lxcxjxhx/HOS_SKILL_WORKFLOW，模块目录 S-06-HOS-Fuck-Demo/。建议你按这个顺序读：

  1. README.md —— 5 分钟建立全局认知；
  2. SKILL.md —— 看模式派发和 10 分钟标准契约；
  3. skill/auto-pipeline.md —— 看自动执行引擎；
  4. skill/core.flow.md —— 看 STEP 定义和质量门禁；
  5. 最后跑一条 create 方向=你自己的项目 depth=L2，亲手验证。

仓库里还有 S-00 安全测试引擎、S-07 IP 写作、S-12 批判式评审等十几个 Skill 模块，风格统一，思路是相通的——把 AI 从"聊天对象"变成"受控的执行流水线"。这套方法论，值得你抄进自己的每一个自动化项目里。

本文核心观点回顾

  1. 内容生产的痛点不是"写得慢"，而是资产种类多 + 彼此强依赖 + 手工维护必然错位；
  2. AI 写内容慢，慢在环节衔接而非打字速度；解法是把思维从"写手"切换到"流水线操作员"；
  3. HOS-Fuck-Demo 是一个"AI 行为 Skill"：一条指令 → 内容包 + PPT + 音频 + 视频规格 + 项目注册，全自动执行；
  4. 流水线的骨架是 STEP1~8 + 数据契约 + 质量门禁：观点只生成一次，PPT/音频/视频全部引用同一份数据；
  5. L1/L2/L3 三层深度按场景选：批量选 L1，课件选 L2，发版演示选 L3；10 分钟 = 600 秒是所有内容统一的对齐锚点；
  6. demo 模式 = L3 全栈 + 4 观点 + 3 幕 + 12 页 PPT + 600s 视频规格；mvp 模式是视频优先的 5/10 分钟快线；
  7. 接入路径可复制：拷 SKILL.md 进 IDE → 跑环境检测 → 接 edge-tts / python-pptx / ffmpeg → 快速验证一条 create；
  8. 它和普通 AI 写作的本质差异是工程化：填槽不创作、质量门禁、自动注册、环境预检、显式降级。

参考链接：

  • 主要来源（GitHub，S-06-HOS-Fuck-Demo 模块，分支 main）：
    • https://github.com/lxcxjxhx/HOS_SKILL_WORKFLOW/tree/main/S-06-HOS-Fuck-Demo
    • README.md：https://raw.githubusercontent.com/lxcxjxhx/HOS_SKILL_WORKFLOW/main/S-06-HOS-Fuck-Demo/README.md
    • SKILL.md：https://raw.githubusercontent.com/lxcxjxhx/HOS_SKILL_WORKFLOW/main/S-06-HOS-Fuck-Demo/SKILL.md
    • skill/auto-pipeline.md、skill/core.flow.md、skill/pipeline.md、skill/templates/*、skill/levels/*、skill/injectors/*
    • management/auto-register.md、management/PROJECT-MANAGER.md、management/workflows/*、management/registry/project-registry.json
    • config/ide-capabilities.md、config/api-gateway.md、config/levels-config.md、config/tts-presets.md、config/env-check.md、config/environment-check.py
  • 辅助来源：仓库总 README：https://github.com/lxcxjxhx/HOS_SKILL_WORKFLOW

附录（Appendix）：

A. 环境依赖速查（来源：config/environment-check.py）

依赖 用途 安装
Python ≥ 3.8 TTS / 渲染脚本运行环境 python.org
Node.js ≥ 16 PPT 生成（pptxgenjs） nodejs.org
ffmpeg（推荐 imageio-ffmpeg） 视频合成 pip install imageio-ffmpeg
edge-tts AI 语音合成 pip install edge-tts
Pillow / numpy / opencv-python 图像与帧渲染 pip install Pillow numpy opencv-python
moviepy 视频合成（可选替代） pip install moviepy

B. 10 分钟标准速查（来源：core.flow.md / SKILL.md）

  • 内容包：600~800 tokens，6 观点（标准）/ 4 观点（demo、mvp）
  • PPT：12 页（标准）/ 6 页（mvp 5min），总时长 600s（或 300s）
  • 音频稿：1800~2200 字（标准）/ 900~1200 字（mvp 5min），4 幕（或 3 幕）
  • 视频：600s ±5%（10min）/ 300s ±5%（5min），1920x1080，fps=30
  • 时长换算： T ( s ) = 字数 语速 ( 字 / 分 ) × 0.8 T(s) = \frac{字数}{语速(字/分) \times 0.8} T(s)=语速(字/分)×0.8字数​（0.8 为停顿占比折减）

C. 常用命令速查（来源：README.md）

create 方向=AI安全意识 depth=L2 style=academic   # 标准内容生产
demo 方向=RBAC权限系统 project=rbac-demo          # 全栈 Demo
mvp 方向=AI安全 intro duration=5                  # MVP 视频
batch 方向=AI副业 count=3 depth=L1 style=hype      # 批量生产
manage new project=AI安全入门课 type=course depth=L2 # 项目管理
status                                           # 状态查询

D. 输出目录规范（来源：README.md / auto-register.md）

output/{project-id}/
├── 01_content/{project-id}-content.md
├── 02_ppt/{project-id}-slide.json
├── 03_audio/{project-id}-script.txt
├── 04_video/{project-id}-render-spec.json
└── README.md

E. 脚注

关键词： AI 内容流水线, AI Agent Skill, 内容包, PPT 自动化, TTS 音频稿, ffmpeg 视频合成, 质量门禁, 项目自动注册, HOS-Fuck-Demo
在这里插入图片描述

  1. 手工工作量因个人经验、模板熟练度与内容复杂度而异，此处为笔者的体感量级，仅供横向对比参考；生产环境建议以自己的历史耗时建立基线。 ↩︎

# 人工智能 # 开源 # github # 生活 # 重构
Logo
AtomGit AI 社区

AtomGit AI 社区提供模型库、数据集、Agent、Token等资源

更多推荐

每日 AI 研究简报 · 2026-08-12

ChatGPT 与 Gemini 同日突破 10 亿月活，AI 应用进入超级应用时代；SpaceXAI、River AI 等 AI 代理赛道融资活跃，企业级 AI Agent 成为新战场。

avatar AtomGit AI 社区
cover

ChatGPT Plus 订阅全攻略， 官方方式说明

avatar AtomGit AI 社区
cover

豆包智能体历史对话批量导出为Word或PDF：先筛选，再整理，最后导出

avatar AtomGit AI 社区