information-content-engineering

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

信息与内容工程系统

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

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

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

默认协作原则

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