# Information Content Engineering

> 信息与内容工程系统，覆盖选题系统、素材库、认知表达、文章、口播、分镜、归档与方法论沉淀。当用户说”帮我写文章””写一篇关于X的文章””写口播稿””把文章改成视频脚本””生成标题/大纲/分镜””一起打磨选题或结构”，或使用 /共创、/口播生成、/分镜生成、/文章改口播、/拆条、/去AI化、/爆款检查、/沉淀 等命令时触发。提供渐进式共创 workflow：先定选题与承诺，再定钩子与结构，再分段成稿，最后做去AI化、分发改写和方法论沉淀。

- Skill: `yeadon8888/information-content-engineering` (Agent Skill, multi-file: 5 files)
- Install (CLI): `npx skillmds@latest add yeadon8888/information-content-engineering`
- Raw SKILL.md: https://api.skillmd.com/api/skills/yeadon8888/information-content-engineering/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Productivity
- Author: yeadon8888 (https://skillmd.com/u/yeadon8888)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/yeadon8888/information-content-engineering

---


# 信息与内容工程系统

这不是单点“代写文章”工具，也不只是一个公众号写作器，而是一套给作者本人增幅的**信息与内容工程系统**。默认目标不是一次性吐出整篇文稿，而是和作者一起把一个选题逐步开发成可发布、可复用、可复盘、可持续积累的方法资产。

文章、口播、分镜、选题规划和素材沉淀，本质上共用同一套骨架：`选题判断 -> 核心承诺 -> 开头钩子 -> 结构推进 -> 观点/案例/证据 -> 收尾行动`。但它们不是同一条生产链。共享的是选题、案例、金句、认知表达、标题方向、素材包与方法资产；分开的是结构组织、语言节奏、交付格式和终审标准。

整体架构固定为三层：`共享预处理层 -> 文章链路 / 口播链路 -> 审校与沉淀层`。

## 默认协作原则

### 1. 默认走渐进式共创

除非用户明确要求“一次给我整篇成稿”，否则按 `references/共创工作流.md` 分阶段推进：

1. 先明确题目、人群、平台、核心承诺
2. 再给 2-3 个切入角度或开头钩子
3. 再搭结构，确认节奏
4. 再写局部样稿或完整初稿
5. 最后统一润色、去AI化、改写成多平台版本

不要一上来就抛完整长文。先帮作者把方向和骨架做对，后面的成稿会更稳。

### 2. 先检索旧资产，再新写

每次创作前，先查：

- `content-system/01-选题库/`
- `content-system/03-素材库/_索引.md`
- 命中后只读相关文件，不全量扫库

优先复用的高价值资产：

- `开头钩子.md`
- `结构框架.md`
- `口播脚本框架.md`
- `标题钩子.md`
- `认知表达.md`
- `金句表达.md`
- `案例素材.md`
- `AI工具评测模板.md`

### 3. 共享资产可以复用，生产链路必须分开

素材、观点、案例、金句、标题方向可以跨链路复用。但文章的展开方式、口播的推进节奏、各自的交付格式和终审标准必须分开。不要用文章的段落展开方式直接生成口播，也不要把口播的短句堆叠当成文章正文。共享与专属资产的完整清单见 `references/路由矩阵.md`。

### 4. 先判断任务与路由

每次开始前先读取 `references/路由矩阵.md`，判断三件事：

- 输入源是什么
- 任务类型是什么
- 主链路是文章还是口播

先选主链路，再开始生产。除非用户明确要求双份产物，否则一次只走一条主链路。

### 5. 始终服务“作者感”

每次正式创作前读取 `references/作者配置.md`。保持作者的人设特征和表达习惯。无论写文章还是口播，都要先像本人，再像模板。首次使用时需要先填写作者配置。

### 6. 口播不要写成文章腔

当产物是口播稿、分镜脚本、直播拆条、视频解说时，必须额外读取 `references/口播脚本.md`。句子更短，开头更猛，节奏更快，说明更少，画面感更强。能“先让人看到”的内容，不要先解释。

### 7. 短段落、适当留白、视觉友好

无论写文章还是口播稿，默认优先可读性。不要堆成大段墙。段落尽量短，一般控制在 1-3 行；关键判断、金句、反转句、问题句可以单独成段；段落之间留出呼吸感。用户一眼扫过去，应该能很快抓到结构、重点和情绪变化。

### 8. 图片链接 / 文章链接默认自动入库

当用户发来文章链接、推文链接、图片链接等素材时，默认入库而不是用完就丢。具体入库规则见 `references/内容系统.md` 的”链接入库规则”章节。

## 创作主流程

### 第零步：路由任务

读取 `references/路由矩阵.md`，先确认：

- 输入源：链接 / 文本 / 图片 / 草稿 / 录音转写 / 会议记录 / 播客笔记 / 已发布文章
- 任务类型：新创作 / 改写转化 / 诊断精修 / 系统沉淀
- 主链路：文章链路 / 口播链路

如果用户同时要文章和口播，先走一次共享预处理层，再分别进入两条链路独立产出。

如果输入源里包含 **文章链接 / 图片链接 / 推文链接 / 公开图片素材链接**，额外多做一步：

- 判断这是“待开发线索”还是“可复用素材”
- 待开发线索记进 `content-system/01-选题库/_待处理.md`
- 可复用素材整理成独立 `素材包` 文件，放进 `content-system/03-素材库/`
- 两者都必须保留原始链接、来源说明、日期和一句话主题判断

### 第一步：共享预处理层

用最少的问题确认四件事：

- 这条内容发在哪里
- 希望读者/观众看完得到什么
- 本轮是想快速成稿，还是一起打磨
- 有没有可复用素材或现成原稿

如果用户没有说全，就做合理假设并继续，不要卡住。

### 第二步：检索共享资产，提炼共用骨架

先检索选题库和素材库，再提炼共享层中间件：

- 一句话主题判断
- 目标受众与使用场景
- 核心承诺
- 2-3 个开头钩子
- 2-3 个标题或封面方向
- 可复用案例、金句、认知表达

如果是改写任务，不要直接逐句改。先提炼原稿的核心承诺、论据、节奏断点，再重组。

### 第三步A：进入文章链路

只有当主链路被判断为文章时才执行：

- 读取 `references/写作方法.md`，先判断文章类型（工具评测/方法教程/深度思考/调研体验/产品体验），按对应类型的写作优先级展开
- 注意 AI 协作边界：核心角度和第一手体验必须由人提供，AI 负责背景知识、论据、结构和段落展开（详见写作方法.md”AI 协作边界”章节）
- 深度认知类额外读取 `references/深度写作.md`
- 默认交付按 `references/交付规范.md` 中的文章包执行

文章链路的目标是”读完清楚、记住观点、愿意继续看”，不是”说出来顺”。

### 第三步B：进入口播链路

只有当主链路被判断为口播时才执行。先判断口播类型：

**工具演示 / 产品体验 / 教程类口播**：
- 读取 `references/口播脚本.md`
- 从素材库优先调用 `口播脚本框架.md`
- 按口播逻辑推进：前 3 秒 -> 中段推进 -> 结果/案例 -> CTA

**深度认知 / 观点表达 / 趋势判断类口播**：
- 读取 `references/深度认知口播.md`
- 按”先问后写”协议补齐六项信息后再开始
- 按七步结构推进：困惑切入 -> 拆框架 -> 核心洞察 -> 例子推进 -> 个人判断 -> 升维 -> 收束

如果需要分镜，在口播稿基础上展开成画面、字幕、音效。默认交付按 `references/交付规范.md` 中的口播包执行。

口播链路的目标是”停留、听懂、能拍、能剪”，不是”讲得很完整”。

### 第三步C：转化链路

当任务是文章改口播或口播改文章时：

- 先保留原稿核心判断和案例
- 在共享层提炼承诺、支撑点、传播句
- 再切换到目标链路重写
- 不允许停留在“原稿句子改短 / 原稿句子改长”这种浅层改写

### 第四步：交付物打包

读取 `references/交付规范.md`，按主链路补齐交付包。默认原则：

- 用户要文章，就交文章包
- 用户要口播，就交口播包
- 用户要分镜，就在口播包基础上追加分镜层
- 用户明确要双份产物，才同时交文章包和口播包

不要默认把文章和口播混成一个交付。

### 第五步：质量检查

按主链路选择对应的质检流程：

**文章链路**：读取 `references/文章质检系统.md`，按 L1→L2→L3→L4 四层逐级检查，输出结构化质检报告。某一层不通过时，按该层的”失败修复路径”打回重做，修复后从该层重新检查。

**口播链路**：读取 `references/审校清单.md` + `references/去AI化.md`，先过共享审校，再过口播专属审校。

**两条链路共用**：读取 `content-system/04-方法论/成稿前七问-文章与口播共用审稿框架.md`，用七问过一遍。答不上来的地方，默认打回重做。

### 第六步：沉淀成系统资产

发布后或确认可复用后，按 `references/内容系统.md` 处理：

- 文稿或脚本归档到 `content-system/02-已发布/`
- 把共享层资产沉淀回素材库
- 把链路专属结构沉淀回各自专属素材
- 把表现规律写进 `content-system/04-方法论/`

一篇内容的价值不只在发布，更在能否反哺下一篇。

**自动提醒**：每次完成交付包后，在末尾追加一句提醒："这篇内容发布后，建议运行 `/发布复盘` 归档并沉淀可复用资产。" 不依赖用户记忆来触发沉淀动作。

## 仓库工作规则

skill 根目录对应 GitHub 仓库。修改系统文件前先同步远端；如果工作树里有用户未提交内容，不覆盖、不回滚，只在本轮相关文件上增量编辑。涉及 `SKILL.md`、`references/`、`content-system/` 的更新，尽量保持一次改一个主题，提交信息清楚可追溯。

## References 加载指南

| 文件 | 何时读取 |
|---|---|
| `references/作者配置.md` | 每次正式创作前必读 |
| `references/共创工作流.md` | 用户要一起打磨选题、结构、开头、系列策划时 |
| `references/路由矩阵.md` | 每次任务开始时；判断输入源、任务类型、主链路 |
| `references/交付规范.md` | 产出交付包前；确定文章包、口播包、分镜包 |
| `references/写作方法.md` | 文章链路主参考 |
| `references/口播脚本.md` | 口播链路主参考（工具演示、产品体验、教程类） |
| `references/深度认知口播.md` | 深度认知/观点表达/趋势判断类口播；含先问后写协议和七步结构 |
| `references/去AI化.md` | 润色阶段；短段落、留白、低AI痕迹系统化审校 |
| `references/文章质检系统.md` | 文章链路终审；4层质检（L1硬规则→L2风格→L3内容→L4人味） |
| `references/审校清单.md` | 口播链路终审；共享审校 + 链路专属审校 |
| `references/深度写作.md` | 深度思考、认知升级、经验复盘 |
| `references/内容系统.md` | 选题检索、素材沉淀、发布复盘、方法论归档 |
| `content-system/03-素材库/开头钩子.md` | 需要强开头、前3句改写、提高停留 |
| `content-system/03-素材库/结构框架.md` | 文章链路需要搭正文结构时 |
| `content-system/03-素材库/口播脚本框架.md` | 口播链路需要镜头脚本、A-roll/B-roll、节奏模板时 |
| `content-system/03-素材库/标题钩子.md` | 需要起标题、封面文案、视频开场句 |
| `content-system/03-素材库/认知表达.md` | 需要观点判断、认知翻转、结论句 |
| `content-system/03-素材库/金句表达.md` | 需要高密度表达、金句、结尾升华 |
| `content-system/03-素材库/案例素材.md` | 需要案例、类比、论据、平台参考 |
| `content-system/03-素材库/AI工具评测模板.md` | AI 工具评测、功能实测、部署教程、工作流演示 |
## 常用命令

| 命令 | 功能 |
|---|---|
| `/共创 [主题]` | 按渐进式共创流程推进选题、钩子、结构、样稿 |
| `/热点 [关键词]` | 搜索最新热点和切入角度 |
| `/标题生成 [主题]` | 给出标题/封面文案方向 |
| `/结构生成 [类型] [主题]` | 输出文章或口播结构骨架 |
| `/口播生成 [主题]` | 生成纯口播稿或口播提纲 |
| `/分镜生成 [主题]` | 生成 A-roll/B-roll 分镜脚本 |
| `/文章改口播 [文章或主题]` | 把长文改成视频可说的稿子 |
| `/口播改文章 [脚本或主题]` | 把口播骨架扩成文章 |
| `/拆条 [主题或原稿]` | 从一篇主内容拆出多个短内容方向 |
| `/审校 [文本]` | 按共享审校 + 链路专属审校检查文本 |
| `/去AI化 [文本]` | 去除 AI 味，压实作者感 |
| `/爆款检查 [文章或脚本]` | 检查钩子、结构、节奏、传播点 |
| `/金句生成 [观点]` | 生成可传播金句 |
| `/话题推荐 [领域]` | 推荐选题和切入角度 |
| `/初始化内容系统` | 初始化内容资产目录 |
| `/记录选题 [想法]` | 快速记录碎片选题 |
| `/检索 [主题]` | 创作前检索旧资产 |
| `/发布复盘 [文件名]` | 归档文稿并追加复盘模板 |
| `/沉淀 [观察]` | 把规律写回素材库和方法论 |

## Content System Source of Truth

This skill now operates as **information-content-engineering** and uses a **single source of truth** for all content assets:

`content-system/`

Inside it:
- `01-选题库/` → topic backlog and topic planning
- `02-已发布/` → published articles and key cover assets
- `03-素材库/` → material packs, hooks, quotes, cases, expression assets
- `04-方法论/` → templates, framework notes, iteration records

### Obsidian Relationship

Obsidian is the **viewing and editing surface**, not a second independent content database.
The Obsidian workspace should point to this same content system instead of maintaining another parallel copy.

Rule:
- Write content into `content-system/` first
- Let Obsidian reflect this same directory
- Do not create a second diverging version of topic/material libraries elsewhere

### Writing Rules

When adding new content:
- New topic ideas should go into `content-system/01-选题库/`
- Published articles should go into `content-system/02-已发布/`
- New material packs, hooks, quotes, cases, and structured references should go into `content-system/03-素材库/`
- Templates, frameworks, and reusable process notes should go into `content-system/04-方法论/`

Prefer adding to the existing content system rather than creating ad hoc markdown files outside it.

### Git Workflow

Default Git policy:
- Do **not** auto-commit every tiny note immediately
- Use **batch commits** after a coherent content update is complete
- Commit when one of these is true:
  - a batch of topics has been organized
  - a material pack has been added or updated
  - a published article has been archived
  - a framework/template/methodology has been updated
  - the directory structure or indexing has been changed

Recommended commit style:
- `Add new material packs for <topic>`
- `Update topic backlog and content indexes`
- `Archive published article: <title>`
- `Refine content system structure`

### Operational Intent

The purpose of this skill is not only to produce articles.
It is to maintain a long-lived, reusable information and content operating system where:
- ideas become topics
- topics connect to materials
- materials support drafts, scripts, and reusable assets
- drafts become published work
- published work feeds future materials and methods

In short:
- `content-system/` is the main library
- Obsidian is the working surface
- GitHub is the versioned backup and sync layer
- this system should be understood as `information-content-engineering`, even before the physical directory rename happens