深度复盘：六大模块，一次建成。我用 Obsidian × Claude 落地了 Loop Engineering 创作流，打造IP自动化引擎

——从零到运转，一次建成，终身受益

开篇：你需要的不是更多教程，你需要一次完整的安装

打开 YouTube，搜索"Obsidian AI 工作流"，你会得到几百个视频，每一个都讲了一个不同的插件、一个不同的技巧、一个不同的"最佳实践"。

看完三个视频，你会有三套相互矛盾的建议，以及零个已经运转的系统。

这篇文章不是这样的。

它的目标只有一个：读完这篇文章，你的系统已经跑起来了。

我们按照严格的顺序来——先地基，再墙体，再屋顶。跳过任何一步，后面的都会变得困难。

我们要完成的，是一个有六个模块的完整系统：

text

模块 1：Vault 架构搭建（文件夹 + 文件结构）
模块 2：CLAUDE.md 创作（IP 世界的宪法）
模块 3：obsidian-skills 安装与配置（Agent 的驱动程序）
模块 4：Skills 技能库定制（IP 专属工作流）
模块 5：第一个 Loop 从零到跑通（真实自动化）
模块 6：多平台发布流水线（一次创作，全面分发）

每个模块结束，系统都有一个可验证的状态。你不需要猜"是否成功"——你可以直接看到。

开始。

模块一：Vault 架构搭建

1.1 为什么架构是第一步，而不是工具

很多人从安装插件开始。这是错误的顺序。

插件是功能扩展，它们服务于架构。但如果架构本身是混乱的，再多的插件也只会制造更多的混乱。

知识管理系统失败最常见的原因，是它们依赖云同步和专有格式。Obsidian 绕开了这两个问题——你的 Vault 是一个文本文件的文件夹。如果 Obsidian 明天消失了，你的笔记在 VS Code、Vim 或任何文本编辑器里都能正常工作。

这种"文件夹里的文件"的本质，也意味着：你的 Vault 架构，就是你的知识系统架构。 文件夹名称、层级关系、文件命名规范——这些不是整理习惯，是系统设计决策。

1.2 设计原则：为 Agent 而设计，而不是为人而设计

传统的笔记软件，文件夹结构是为人的记忆和浏览习惯设计的。

但我们的系统，主要的"用户"是 AI Agent——Claude Code 或 Codex CLI。它们扫描文件、解析 frontmatter、沿着 wikilink 遍历知识图谱。

CLAUDE.md 在项目的每次会话中都会被加载。Skills 则根据描述条件性地加载。对于所有工作都适用的规则，CLAUDE.md 是正确的归宿；对于只适用于特定任务的规则（测试、提交、安全审查），Skills 更干净，因为它们保持上下文的聚焦。

这意味着文件夹结构需要满足：

• Agent 能从文件名和位置推断文件类型
• frontmatter 字段一致，Agent 可以查询和过滤
• 文件夹边界清晰，Agent 知道"可以修改什么，不可以修改什么"

1.3 IP 创作知识库完整文件夹结构

按照以下结构创建你的 Vault：

text

📁 [你的IP名称]-Vault/        ← Vault 根目录（命名用英文）
│
├── 📄 CLAUDE.md               ← 必须在根目录，Agent 每次读取
├── 📄 agents.md               ← 各 Agent 角色定义
├── 📄 index.md                ← 全局索引（Agent 自动维护）
├── 📄 log.md                  ← 操作日志（Agent 写入）
│
├── 📁 _raw/                   ← 原始素材（_前缀=不自动处理）
│   ├── 📁 clippings/          ← Web Clipper 抓取的网页
│   ├── 📁 voice/              ← 语音转录文本
│   ├── 📁 images/             ← 参考图片（附说明.md）
│   ├── 📁 research/           ← 参考资料、论文
│   └── 📁 processed/          ← Agent 处理完毕后移入
│
├── 📁 wiki/                   ← IP 百科（Agent 编译，权威信息源）
│   ├── 📁 world/              ← 世界观设定
│   │   ├── 📄 geography.md    ← 地理/空间设定
│   │   ├── 📄 history.md      ← 世界历史
│   │   ├── 📄 rules.md        ← 宇宙法则（不可违背）
│   │   └── 📄 culture.md      ← 文化/风俗/语言
│   ├── 📁 characters/         ← 人物卡（每人一文件）
│   ├── 📁 storylines/         ← 故事线追踪
│   ├── 📁 lore/               ← 传说/历史事件/神话
│   └── 📁 concepts/           ← IP 核心概念解释
│
├── 📁 skills/                 ← 创作方法论技能库
│   ├── 📄 SKILL.md            ← 技能总清单（入口文件）
│   ├── 📁 world-builder/      ← 世界观构建技能
│   ├── 📁 character-tracker/  ← 人物追踪技能
│   ├── 📁 content-pipeline/   ← 内容生产流水线技能
│   └── 📁 audience-crm/       ← 受众管理技能
│
├── 📁 projects/               ← 进行中的创作项目
│   └── 📁 [项目名]/
│       ├── 📄 brief.md        ← 项目简报（目标/受众/风格）
│       ├── 📄 outline.md      ← 内容大纲
│       ├── 📁 drafts/         ← 草稿（v1, v2...）
│       └── 📁 assets/         ← 项目资产（图片/数据）
│
├── 📁 publish/                ← 已发布内容存档
│   ├── 📁 articles/           ← 文章
│   ├── 📁 videos/             ← 视频脚本/分镜
│   └── 📁 social/             ← 各平台适配版本
│
├── 📁 crm/                    ← 受众与合作者关系管理
│   ├── 📁 audience/           ← 受众画像文件
│   ├── 📁 partners/           ← 合作者笔记
│   └── 📄 insights.md         ← Agent 生成的受众洞察报告
│
└── 📁 journal/                ← 创作日志
    └── 📁 [年份]/             ← 按年分组

1.4 每个文件夹的"合同"——Agent 行为边界

架构不只是文件夹，更重要的是每个文件夹对应的"合同"——什么可以进，什么可以出，Agent 有什么权限。

根目录文件的权限：

• CLAUDE.md：人工维护，Agent 只读
• index.md：Agent 自动维护，人工可编辑
• log.md：Agent 只写（追加），人工只读
• agents.md：人工维护，Agent 只读

1.5 标准 frontmatter：让 Agent 能读懂每一个文件

在这个系统里，你的 Markdown 文件——带有 [[wikilinks]]、别名、frontmatter 标签和修改时间——是真相的来源。

为不同类型的文件设计一致的 frontmatter，是系统可查询的基础：

世界观设定文件（wiki/world/）：

YAML

---
type: world-setting
category: geography | history | rules | culture
status: draft | active | archived
tags: [世界观, 地理, ...]
created: 2026-06-15
updated: 2026-06-15
linked_characters: ["[[角色A]]", "[[角色B]]"]
timeline: 第一纪元 | 第二纪元 | 当代
---

人物卡文件（wiki/characters/）：

YAML

---
type: character
name: 角色名
aliases: [别名1, 别名2]
status: active | deceased | unknown
role: protagonist | antagonist | supporting
affiliation: ["[[势力A]]"]
first_appearance: "[[故事线-第一章]]"
tags: [人物, 主角, ...]
created: 2026-06-15
updated: 2026-06-15
---

项目文件（projects/）：

YAML

---
type: project
title: 项目名称
status: ideation | drafting | review | ready | published
platform: 公众号 | 小红书 | X | 视频
audience: core | casual | new
deadline: 2026-06-30
related_wiki: ["[[相关设定1]]", "[[相关设定2]]"]
created: 2026-06-15
---

原始素材文件（_raw/）：

YAML

---
type: raw
source: web | voice | manual | image
source_url: https://...
status: unprocessed | processing | processed
tags: [待分类]
captured: 2026-06-15
---

模块二：CLAUDE.md 创作——IP 世界的宪法

2.1 什么是 CLAUDE.md，为什么它如此关键

3 Claude Code 会在项目根目录寻找 CLAUDE.md 文件。这是你的 Agent 的常驻指令——它在每次会话中都会读取这个文件。把它想成你第二大脑的宪法。

这个定义里，有两个关键词值得深挖：

"常驻"：不是你每次手动粘贴，不是某些对话有某些没有。只要 Agent 在你的 Vault 目录里运行，它就会读取这个文件。这意味着你在 CLAUDE.md 里写的每一个规则，都对每一次 AI 交互生效。

"宪法"：宪法不是操作手册，不是任务清单。它定义的是框架、边界和原则。细节由具体的 Skills 处理，根本规则由 CLAUDE.md 守护。

2.2 CLAUDE.md 的七个核心板块

一个完整的 IP 创作者 CLAUDE.md，应该包含七个板块，按照 Agent 需要理解的优先级排列：

板块一：IP 宇宙身份（最先读取，最重要）

这是 AI 进入你的系统前读到的第一段文字。它决定了 AI 的"宇宙坐标"——知道自己在什么世界里工作。

Markdown

# [IP 名称] 创作知识库 · Agent 宪法
> 版本: 2.0 | 创建: 2026-06-15 | 状态: active
## § 1. 宇宙身份
你正在协助创作的 IP 叫做 **[IP 名称]**。
### 世界类型
[奇幻/科幻/现实主义/混合类型，一句话描述]
### 核心主题
这个 IP 探索的根本问题是：[你的 IP 的哲学命题]
### 不可违背的宇宙法则
以下规则在任何情况下不能被违反：
1. [法则一]——违反此法则将导致世界观崩溃
2. [法则二]
3. [法则三]
### 时代背景
故事发生在：[具体时间描述]
世界的当前状态：[简要描述世界现状]

板块二：核心角色速查

Markdown

## § 2. 核心角色（速查表）
| 角色名 | 身份 | 核心特质 | 当前状态 | 详细档案 |
|---|---|---|---|---|
| [角色A] | [身份] | [2个核心词] | [active/arc完成] | [[wiki/characters/角色A]] |
| [角色B] | [身份] | [2个核心词] | [active] | [[wiki/characters/角色B]] |
> ⚠️ 重要：所有角色的权威信息在 wiki/characters/ 目录。
> 此表仅供快速定向，细节以 wiki 为准。

板块三：Vault 导航地图

Markdown

## § 3. Vault 导航地图
### 目录结构与权限
| 目录 | 内容 | 你的权限 |
|---|---|---|
| `_raw/` | 未处理原始素材 | 只读，处理完移到 _raw/processed/ |
| `wiki/` | IP 百科（权威信息源） | 可读写，更新后必须注明来源 |
| `projects/` | 进行中草稿 | 可读写，重大修改需在 log.md 记录 |
| `publish/` | 已发布内容 | 只读，不得修改已发布内容 |
| `skills/` | 技能定义 | 只读 |
| `crm/` | 受众数据 | 可读写 insights.md |
| `journal/` | 每日日志 | 只写（追加新日志，不修改历史） |
### 关键文件
- `index.md` → 全局索引（你负责维护，每次操作后更新）
- `log.md` → 操作日志（每次重要操作后追加记录）
- `agents.md` → 子 Agent 角色定义（只读）

板块四：创作声音指南

这是最容易被忽略但影响最大的板块——它决定了 AI 生成内容的"腔调"是否符合你的 IP。

Markdown

## § 4. 创作声音指南
### 叙事声音特征
- **视角**：[第一人称限知视角/第三人称上帝视角/多视角轮换]
- **时态**：[过去时/现在时]
- **句式偏好**：[短句有力度/长句建画面/混合使用]
- **节奏感**：[紧张快节奏/沉郁慢节奏/动静结合]
### 语言风格描述
[具体描述，如："克制的诗意。不用比喻堆砌，但每一处细节都经过选择。
情绪藏在动作和对话里，不在形容词里。
参考作者：[具体作家/作品]"]
### 绝对禁止清单
以下元素在任何情况下不应出现：
- ❌ [禁止词汇/表达/情节类型1]
- ❌ [禁止词汇/表达/情节类型2]
- ❌ [禁止情节模式：如"神奇能力突然觉醒"]
- ❌ 打破第四堵墙
- ❌ 随意引用现实世界品牌
### 允许的创作边界
这个 IP 可以触碰的敏感主题（需要谨慎处理）：
- ✅ [主题1]——处理原则：[简短说明]
- ✅ [主题2]——处理原则：[简短说明]

板块五：技术规范

Markdown

## § 5. 技术规范
### 文件格式
- 所有笔记使用 Obsidian Flavored Markdown（OFM）
- 内部链接统一使用 wikilink 格式：`[[文件名]]`
- 禁止使用标准 Markdown 链接格式 `[文字](路径.md)`（会破坏图谱）
### Frontmatter 规范
每个新文件必须包含：
```yaml
---
type: [文件类型]
status: [状态]
tags: [相关标签]
created: [日期]
updated: [日期]
---

命名规范

• 人物文件：[角色名].md（如：李明.md）
• 世界观文件：[类别]-[主题].md（如：rules-magic-system.md）
• 项目文件：[YYYYMMDD]-[项目名].md（如：20260615-第三章初稿.md）
• 日志文件：[YYYY-MM-DD].md

text

**板块六：Agent 行为规则**
```markdown
## § 6. Agent 行为规则
### 必须做
1. 每次操作前读取相关 wiki 文件确认设定一致性
2. 新增或修改 wiki 内容后，更新 index.md 对应条目
3. 发现设定矛盾时，在 log.md 记录矛盾详情，不擅自裁决
4. 重要操作（移动文件/修改 wiki）前在 log.md 写入操作意图
5. 生成内容时，明确标注信息来源于哪个 wiki 文件
### 绝对禁止
1. ❌ 修改 publish/ 里的任何已发布文件
2. ❌ 删除任何文件（移动到 _raw/processed/ 可以，删除不行）
3. ❌ 修改 CLAUDE.md 本身
4. ❌ 在没有核查 wiki 的情况下生成世界观相关内容
5. ❌ 创建没有 frontmatter 的文件
### 发现问题时的处理顺序
1. 停止当前任务
2. 在 log.md 写入：[日期] [ISSUE] 问题描述
3. 等待人工确认后继续

板块七：上下文加载指令

Markdown

## § 7. 会话启动时的上下文加载
每次新会话开始，按以下顺序预加载：
**必读（每次）**：
1. 此文件（CLAUDE.md）
2. `index.md`（了解当前知识库状态）
3. `log.md` 最后 20 行（了解最近操作历史）
**按任务按需加载**：
- 写角色相关内容 → 读取对应 `wiki/characters/[角色名].md`
- 写世界观内容 → 读取 `wiki/world/rules.md` + 相关设定文件
- 继续进行中项目 → 读取 `projects/[项目名]/brief.md` + 最新草稿
**不需要主动加载**（按需检索即可）：
- `_raw/`（等待处理的原始素材）
- `publish/`（已发布存档，除非明确需要参考）

2.3 CLAUDE.md 写作的三个原则

原则一：具体胜于抽象

❌ 弱版本："写作风格应该有文学感"

✅ 强版本："避免直接描述情绪（不写'他感到悲伤'），改用外化行为（'他把杯子放在了桌上，没有喝'）"

否定指令至关重要。负面指令是你阻止 Claude 退回到它默认行为的方式。

原则二：边界清晰胜于权限宽泛

不要给 Agent 模糊的权限（"根据情况判断"），要给它清晰的边界（"只修改 projects/ 里的文件，wiki/ 修改必须先在 log.md 记录意图"）。

原则三：随系统演进更新

CLAUDE.md 不是一次性文档。每当你发现 AI 输出了你不想要的内容，检查 CLAUDE.md 里是否缺少了对应的规则——然后加进去。

模块三：obsidian-skills 安装与配置

3.1 为什么需要 obsidian-skills？

先做一个实验。在没有安装 obsidian-skills 的情况下，让 Claude 创建一个 Obsidian 笔记：

你会得到：

Markdown

# 角色：李明
[人物描述链接](characters/liming.md)
*相关内容*: 见[世界观设定](world-setting.md)

你实际需要：

Markdown

---
type: character
name: 李明
status: active
tags: [人物, 主角]
created: 2026-06-15
---
# 李明
相关设定见 [[世界观设定]]
人物关系参考 [[人物关系图]]

obsidian-skills 解决了每个 Obsidian + AI 用户都会遇到的问题：Claude 会写标准 Markdown，但它不了解 [[wikilinks]]、callouts、Bases 或 Canvas。你的 AI 生成的笔记看起来差不多，但每次都需要手动清理。 当你让普通的 Claude 写一个 Obsidian 笔记，它大约有 60% 的概率会出错。这意味着没有 obsidian-skills，你每次都要花时间"修正"AI 的格式，而不是利用 AI 的内容。

3.2 obsidian-skills 的五个技能详解

Obsidian CEO Steph Ango 在 2026 年初发布了 kepano/obsidian-skills，这是第一次有主流生产力工具的创建者正式拥抱 Agent Skills 规范，并为自己的平台发布了生产质量的技能。 这个仓库包含五个技能，每个针对特定的 Obsidian 文件格式或能力。因为它们遵循开放的 Agent Skills 规范，它们不只适用于 Claude Code，也适用于 Codex CLI、Gemini CLI，以及任何兼容的 Agent。

技能一：obsidian-markdown

教 Agent 掌握 Obsidian Flavored Markdown：[[wikilinks]]、callouts（> [!note]）、frontmatter/YAML 属性、标签、嵌入（![[file]]），以及所有与标准 Markdown 不同的语法。

对 IP 创作者的价值：所有人物卡、世界观笔记、故事线文档，都需要正确的 OFM 格式。这个技能是基础中的基础。

技能二：obsidian-bases

教 Agent 创建和管理 Bases——Obsidian 的结构化数据层。这是建立在笔记之上的数据库，有类型属性、过滤器、排序和视图。你的 AI 可以自动生成 CRM 表格、进度追踪器或研究数据库。

对 IP 创作者的价值：把你的受众 CRM、内容发布进度、角色状态追踪，变成可查询的结构化数据库，而不是散乱的笔记。

技能三：json-canvas

JSON Canvas 格式用于可视化白板。Agent 可以创建节点、边、组和空间布局，Obsidian 将其渲染为交互式画布。架构图、思维导图、项目概览。

对 IP 创作者的价值：让 AI 自动生成你的 IP 世界地图、人物关系图、故事线时间轴。

技能四：obsidian-cli

从终端进行 Vault 管理。创建笔记、搜索内容、打开 Vault，以及无需触碰 Obsidian GUI 的自动化工作流。

对 IP 创作者的价值：这是 Loop 自动化的核心工具——Agent 可以在没有你打开 Obsidian 的情况下操作 Vault。

技能五：defuddle

defuddle 可以说是这套技能中最具创新性的一个。它解决了每个在 Obsidian 做研究的人都知道的摩擦点：网页是嘈杂的。导航、广告、cookie 横幅和模板文字会让每个页面变得臃肿。安装 defuddle 技能后，你可以让 Claude：研究这个 URL 的内容，并保存一个干净的摘要到我的 Vault。

对 IP 创作者的价值：原始网页是嘈杂的。不先清理它们，单次研究会话可能会用导航栏和页脚撑爆你的上下文窗口。广告也会堆积。配合 MCP 服务器设置，你就有了从 Web 到 Vault 的完整流水线。

3.3 安装步骤（三条路径，选一条）

有三种不同的集成路径，选哪条取决于你的工作方式。路径一：MCP 服务器（Claude 通过协议层读取你的 Vault）。这是最流行的方式。你安装一个 MCP 服务器，把你的 Vault 文件暴露给 Claude Desktop、Claude Code 或 Cursor。服务器处理搜索、文件读取、写入和 frontmatter 解析。你可以从 Claude 的聊天界面访问 Vault，无需切换应用。

路径选择指南：

推荐：路径 B（Claude Code + obsidian-skills），这是最简单的方式。在终端运行 Claude，切换到你的 Vault 目录。把 obsidian-skills 放入 .claude/ 文件夹，这样 Claude 就理解了 wikilink 和 frontmatter。完成。

完整安装流程（路径 B）：

Bash

# Step 1：安装 Claude Code CLI（如果还没有）
npm install -g @anthropic-ai/claude-code
# Step 2：进入你的 Vault 目录
cd /path/to/你的IP名称-Vault
# Step 3：安装 obsidian-skills（方法一：通过 npx）
npx skills add kepano/obsidian-skills
# 或方法二：手动克隆（更可控）
git clone https://github.com/kepano/obsidian-skills .claude/obsidian-skills
# Step 4：验证安装
ls .claude/
# 应该看到：obsidian-skills/ 文件夹
# Step 5：启动 Claude Code
claude
# Claude 会自动读取 .claude/ 目录里的所有技能

验证技能已加载：

启动 Claude Code 后，输入：

text

列出当前加载的所有技能

如果看到 obsidian-markdown、obsidian-bases、json-canvas、obsidian-cli、defuddle 这五个技能，安装成功。

路径 A（MCP 服务器）安装：

Bash

# 安装 Obsidian MCP 服务器
npm install -g obsidian-mcp-server
# 启动 MCP 服务器（指向你的 Vault）
obsidian-mcp --vault /path/to/你的Vault
# 在 Claude Desktop 的 MCP 配置中添加
# 位置：~/Library/Application Support/Claude/claude_desktop_config.json
{
  "mcpServers": {
    "obsidian": {
      "command": "obsidian-mcp",
      "args": ["--vault", "/path/to/你的Vault"]
    }
  }
}

路径 C（Codex EchoInk 插件）安装：

使用 Codex CLI 或 OpenCode 在 Obsidian 内管理知识，询问 Vault 问题，并在本地审查 Agent 的工作。这使工作流保持在 Obsidian 内部，而不是在应用之间来回切换。

在 Obsidian 的社区插件里搜索 "Codex EchoInk" 并安装即可。

3.4 技能组合的四步工作流

这是一个真实的工作流：第一步，/defuddle [URL] → 把文章抓取到 _raw/；第二步，/obsidian-cli → 总结它并创建一个 wiki 页面；第三步，/obsidian-markdown → 确保所有语法正确；第四步，/json-canvas → 创建一个把它与相关概念链接起来的概念图。关键的架构洞见：技能是可以组合的，你可以链式调用它们。

对 IP 创作者，这套链式流程是这样的：

text

第一步：你发现一篇关于世界观构建的好文章
↓ /defuddle [URL]
第二步：干净的 Markdown 素材进入 _raw/clippings/
第三步：Agent 读取素材，提炼与你 IP 相关的内容
↓ /obsidian-cli 创建 wiki 草稿
第四步：新 wiki 页面进入 wiki/concepts/
第五步：Agent 确保所有语法、frontmatter 正确
↓ /obsidian-markdown 格式校验
第六步：格式合规的笔记进入知识图谱
第七步：Agent 创建与已有概念的视觉关联
↓ /json-canvas 生成概念图
第八步：概念图保存，可视化知识连接

整个流程，你只做了一件事：发现一篇好文章。

模块四：Skills 技能库定制——IP 专属工作流

4.1 什么是 Skill？和 CLAUDE.md 有什么区别？

在最基础的层面上，一个 Skill 是一个包含单个 SKILL.md 文件的目录。这个文件有两个部分：顶部的简短 YAML frontmatter，包含名称和描述；以及下方的 Markdown 正文，包含 Claude 在技能被触发时遵循的指令。这就是完整的规范。 

CLAUDE.md 在每次会话中都会被加载。Skills 则根据描述条件性地加载。对于所有工作都适用的规则，CLAUDE.md 是正确的归宿；对于只适用于特定任务的规则（测试、提交、安全审查），Skills 更干净，因为它们保持上下文的聚焦。

简单类比：

• CLAUDE.md = 公司的文化手册和价值观
• Skills = 各岗位的工作手册和操作 SOP

4.2 Skills 的两种类型

YAML frontmatter（name、description、trigger、tags）告诉 Claude 何时以及如何使用这个技能。Markdown 正文包含实际的指令。

根据触发方式，Skills 分为两类：

类型一：手动触发（Slash Command）

你在对话中输入 /技能名，手动激活。适合需要你主动发起的任务。

YAML

---
name: world-check
description: 检查当前内容与世界观设定的一致性
slash: /world-check
---

类型二：自动触发（Auto-trigger）

Claude 根据任务描述判断是否需要激活。适合通用性规则。

YAML

---
name: character-voice
description: 每当写角色对话时，确保声音符合人物卡定义
trigger: auto
---

4.3 IP 创作者的四个核心 Skills 设计

Skill 1：world-builder（世界观守护者）

文件位置：skills/world-builder/SKILL.md

Markdown

---
name: world-builder
description: |
  当任务涉及创建或修改世界观设定（地理、历史、规则、文化）时激活。
  检查一致性，防止设定冲突，维护世界观完整性。
slash: /world-check
tags: [世界观, 设定, 一致性]
---
# 世界观守护者技能
## 触发场景
- 创建新的世界观设定笔记
- 修改已有世界观设定
- 写涉及世界观细节的内容
- 用户主动调用 /world-check
## 执行步骤
### Step 1：加载权威信息
读取以下文件（按优先级）：
1. `wiki/world/rules.md`（宇宙法则，最高优先级）
2. `wiki/world/history.md`（世界历史时间线）
3. 与当前任务相关的 `wiki/world/` 其他文件
### Step 2：一致性检查清单
对当前内容逐项检查：
- [ ] 是否违反 rules.md 中的任何宇宙法则？
- [ ] 时间线是否与 history.md 一致？
- [ ] 地理描述是否与 geography.md 一致？
- [ ] 是否引入了未在 wiki 中定义的新概念？
### Step 3：矛盾处理
发现矛盾时：
1. 停止生成
2. 在 `log.md` 追加记录：
[日期] [CONFLICT] 描述矛盾内容 矛盾位置：[文件路径] 矛盾类型：[时间线/地理/规则/角色] 建议解决方向：[可选]
3. 向用户报告，等待裁决
### Step 4：新概念注册
如果内容引入了新概念且通过一致性检查：
1. 在 `wiki/concepts/` 创建新页面
2. 更新 `index.md`
3. 在相关已有页面添加 wikilink
## 输出规范
- 所有设定文件必须有完整 frontmatter
- 新地点/势力/概念必须有独立文件
- 使用 `[[]]` 格式引用已有实体

Skill 2：character-tracker（角色一致性守护者）

文件位置：skills/character-tracker/SKILL.md

Markdown

---
name: character-tracker
description: |
  当任务涉及角色对话、行为、心理描写或修改人物卡时激活。
  确保角色行为符合人物卡定义，检测性格/能力前后矛盾。
slash: /char-check
tags: [角色, 人物, 对话, 一致性]
---
# 角色一致性守护者技能
## 触发场景
- 写任何角色的对话
- 写角色的内心独白或情绪反应
- 写角色在特定情境下的行为选择
- 修改人物卡文件
- 用户调用 /char-check
## 执行步骤
### Step 1：加载人物档案
读取涉及角色的 `wiki/characters/[角色名].md`
重点关注：
- 核心性格特质
- 已建立的行为模式
- 价值观边界（什么事不会做）
- 语言习惯（用词偏好/口头禅/禁忌词）
### Step 2：声音一致性检查
对角色对话逐句检查：
- 这句话符合角色的教育背景和语言习惯吗？
- 这个反应符合角色的情绪模式吗？
- 角色在这种情境下真的会做这个选择吗？
### Step 3：能力边界检查
- 角色使用了超出其已建立能力范围的能力？
- 如果是，这是成长弧的设计，还是设定遗漏？
### Step 4：矛盾标记
发现矛盾，在 log.md 记录：
[日期] [CHARACTER-CONFLICT] [角色名] 矛盾描述：[具体描述] 矛盾位置：[文件+行号] 严重程度：[轻微/中等/严重]
## 对话生成规范
- 角色台词不加引导词"他说"等，直接写对话
- 情绪通过动作和环境外化，不直接陈述情绪
- 保留角色的语言特征（句式、用词）
- 每个角色的对话节奏应该可区分

Skill 3：content-pipeline（内容生产流水线）

文件位置：skills/content-pipeline/SKILL.md

Markdown

---
name: content-pipeline
description: |
  当任务涉及从草稿到发布的内容生产流程时激活。
  管理内容状态流转，确保每个阶段有明确的完成标准。
slash: /pipeline
tags: [内容, 发布, 流水线, 草稿]
---
# 内容生产流水线技能
## 内容状态定义
| 状态 | 描述 | 进入条件 | 退出到 |
|---|---|---|---|
| `ideation` | 选题/创意阶段 | 有初步想法 | `drafting` |
| `drafting` | 写作阶段 | 已有大纲 | `review` |
| `review` | 审核阶段 | 初稿完成 | `ready` 或 `drafting` |
| `ready` | 待发布 | 通过审核 | `published` |
| `published` | 已发布 | 人工确认发布 | 归档到 publish/ |
## 触发场景及执行
### 场景一：新建内容项目
触发词：用户描述一个新的内容想法
执行步骤：
1. 在 `projects/` 创建新文件夹 `projects/[YYYYMMDD]-[项目名]/`
2. 创建 `brief.md`（包含：目标/目标受众/核心信息/平台/风格）
3. 创建 `outline.md`（基于 wiki 知识库生成初步大纲）
4. 在 brief.md 设置 `status: ideation`
5. 更新 `index.md`
### 场景二：推进到草稿
触发词：用户说"开始写"/"生成草稿"
执行步骤：
1. 确认 brief.md 和 outline.md 已存在
2. 加载相关 wiki 文件（人物/世界观/受众画像）
3. 在 `projects/[项目名]/drafts/` 创建 `v1.md`
4. 更新 status 为 `drafting`
5. 在 log.md 记录开始时间
### 场景三：内容审核
触发词：用户说"审核"/"检查"
执行步骤（顺序执行）：
1. 一致性检查（触发 world-builder 技能）
2. 角色声音检查（触发 character-tracker 技能）
3. 风格指南检查（对照 CLAUDE.md § 4）
4. 生成审核报告写入 `projects/[项目名]/review-[日期].md`
5. 列出：问题清单 + 修改建议
### 场景四：标记为发布就绪
触发词：用户说"这个可以发了"/"通过审核"
执行步骤：
1. 更新 status 为 `ready`
2. 询问目标平台（公众号/小红书/X/视频）
3. 触发 audience-crm 技能，检查受众匹配度
4. 生成平台适配版本（触发对应平台技能）

Skill 4：audience-crm（受众关系管理）

文件位置：skills/audience-crm/SKILL.md

Markdown

---
name: audience-crm
description: |
  当任务涉及受众分析、内容匹配度评估或生成选题建议时激活。
  基于 crm/audience/ 的受众画像，为创作决策提供数据支撑。
slash: /audience
tags: [受众, CRM, 选题, 分析]
---
# 受众关系管理技能
## 受众画像文件结构
每个受众画像文件（`crm/audience/[画像名].md`）包含：
```yaml
---
type: audience-persona
name: 画像名称
size: 核心/次要/潜在
age_range: 25-35
platforms: [公众号, 小红书]
reading_habits: [深度阅读, 碎片化浏览]
pain_points: [碎片信息太多, 缺乏系统方法]
love_points: [有体系的框架, 真实案例]
content_types: [长文章, 实操教程]
engagement_time: 晚间21-23点
---

触发场景及执行

场景一：内容受众匹配度评估

执行步骤：

1. 读取 crm/audience/ 所有画像文件
2. 对待发布内容进行多维评估：
• 主题与受众痛点的匹配度（1-10分）
• 内容深度与受众习惯的匹配度
• 发布时间与阅读习惯的匹配
3. 生成匹配度报告
4. 建议：目标受众、最佳发布时间、标题优化方向

场景二：选题建议生成

执行步骤：

1. 读取 crm/insights.md（最新受众洞察）
2. 读取 publish/ 最近 10 篇内容的 frontmatter
3. 分析：哪些主题获得了高参与度
4. 结合 wiki 知识库，生成下周选题建议 × 5
5. 每个选题附：目标受众/核心价值/推荐格式
6. 保存到 projects/ideas/[日期]-weekly-ideas.md

场景三：更新受众洞察

触发时机：有新的受众反馈数据（评论/点赞/转发）

执行步骤：

1. 读取新反馈数据
2. 更新 crm/insights.md：
• 新增洞察条目
• 标注日期和数据来源
3. 如果洞察影响创作策略，标注 [ACTION NEEDED]

4.4 Skills 设计的三个黄金原则

最常见的错误是设计"超级技能"——一个 SKILL.md 试图同时处理提交、PR、分支命名和更新日志。

原则一：一个技能，一个职责

world-builder 只管世界观一致性。character-tracker 只管角色一致性。它们各司其职，需要时组合使用。

当你把 Loop 和 Skills 结合使用时，真正的力量才会显现。

原则二：技能调用技能（可组合性）

关键的架构洞见：技能是可组合的。你可以链式调用它们。一个 Obsidian CLI 技能可以调用 Defuddle 技能来抓取网页，然后把结果写入你的 Vault。LLM 负责编排，技能提供工具。

原则三：负面指令与正面指令同等重要

每个技能里，都要明确写"不做什么"。这防止 AI 在没有明确指令时，用它认为"合理"的方式填补空白。

模块五：第一个 Loop 从零到跑通

5.1 Loop 的五个组成部分

所有实用的 Loop 包含五个部分加一个存储：一个进行发现和分类的定时自动化、避免并行 Agent 冲突的机制、捕获项目知识的技能、将 Agent 接入真实工具的连接器、以及将"制造者"和"检查者"分离的架构，加上一个持久化状态的存储。

翻译成 IP 创作者的语言：

触发器（Trigger） → 什么时候运行？（时间/事件） 任务定义（Goal） → 要完成什么目标？ 技能集（Skills） → 需要哪些技能？ 验证门（Validate） → 什么算成功？ 预算（Budget） → 最多花多少时间/金钱？ 状态存储（State） → 结果存在哪里？（你的 Vault）

5.2 Loop 0：手动触发版（最简单，从这里开始）

在学会自动定时运行之前，先让 Loop 的逻辑跑通。这是手动触发版——你在终端输入一个命令，Loop 完整执行一次。

Loop 0：原始素材处理

你要做的：在终端里，切换到你的 Vault 目录，运行：

claude "
任务：处理 _raw/ 文件夹里的所有未处理素材。
对于每一个 status 为 unprocessed 的文件：
1. 读取文件内容
2. 用 obsidian-markdown 技能生成摘要（100-200字）
3. 提取关键概念和实体（人物/地点/概念）
4. 在 wiki/ 对应分类创建或更新相关页面
5. 在原始文件添加 wikilink 指向新创建的 wiki 页面
6. 更新原始文件 frontmatter：status: processed
7. 移动原始文件到 _raw/processed/
全部处理完后：
8. 更新 index.md 的知识库统计
9. 在 log.md 追加：[日期] 批量处理完成，处理 X 个文件
开始执行。如果发现设定矛盾或不确定的内容，先在 log.md 标记，继续处理下一个文件。
"

验证成功的标志：

• _raw/ 里的文件 status 变成了 processed
• _raw/processed/ 里出现了这些文件
• wiki/ 里出现了新的知识页面
• log.md 最后一行有今天的处理记录
• index.md 有更新

如果这个步骤成功了，恭喜：你的 Loop 逻辑是通的。

5.3 Loop 1：每日素材处理（定时自动版）

手动版跑通后，让它变成定时自动运行。

方法：使用 cron（Mac/Linux）

Bash

# 打开 crontab 编辑器
crontab -e
# 添加这一行（每小时的第 0 分钟执行）
0 * * * * cd /path/to/你的Vault && claude "处理 _raw/ 中所有 status:unprocessed 的文件。用 obsidian-markdown 技能生成摘要，创建 wiki 页面，更新 frontmatter 状态为 processed，移动到 _raw/processed/，最后更新 index.md 和 log.md。" >> /path/to/你的Vault/journal/loop-log.txt 2>&1
# 保存并退出

方法：使用 Codex EchoInk（更适合不熟悉终端的人）

在 EchoInk 的聊天界面，输入 /maintain，然后加上你自己的指令。

text

/maintain 每小时处理 _raw/ 里的新素材文件：
读取 unprocessed 文件 → 生成摘要 → 创建/更新 wiki 页面 
→ 标记为 processed → 移动到 processed/ → 更新 log.md

日志和监控让不可见的进程变得可见。健康检查、日志文件和推送通知让我有信心系统在正常运行。

建议：在 journal/ 文件夹里创建一个 loop-log.txt 或 loop-log.md，让所有 Loop 的运行记录都写入这里。每天早上花 2 分钟看一眼，确认系统在正常工作。

5.4 Loop 2：每日创作日志（你醒来就有的日报）

功能：每天晚上 22:00，自动总结今天的创作进展，生成一份日报。

Bash

# crontab 设置
0 22 * * * cd /path/to/你的Vault && claude "
生成今日创作日报，保存到 journal/[YYYY]/[YYYY-MM-DD].md
日报内容：
1. 今日 _raw/ 新增文件数量（检查今日 created 的文件）
2. 今日 wiki/ 更新的页面（检查今日 updated 的文件）
3. 今日 projects/ 进展（哪些项目状态有变化）
4. 今日 log.md 的操作摘要
5. 知识库健康状态：总文件数/总 wiki 页面数/待处理素材数
格式要求：
- 简洁，不超过 300 字
- 使用 wikilink 引用具体文件
- 包含明日建议的优先任务
在 log.md 追加：[日期] 日报生成完成
"

验证成功：明天早上，你的 journal/[年份]/ 文件夹里应该有昨天日期的日报文件。

5.5 Loop 3：每周选题建议（周一上午的创作礼包）

功能：每周一上午 9:00，基于受众数据和知识库，自动生成本周选题建议。

Bash

# crontab 设置
0 9 * * 1 cd /path/to/你的Vault && claude "
生成本周选题建议，保存到 projects/ideas/[YYYY-MM-DD]-weekly-ideas.md
执行步骤：
1. 触发 audience-crm 技能
2. 读取 crm/insights.md（最新受众洞察）
3. 读取 publish/ 最近 10 篇内容的 frontmatter（分析规律）
4. 读取 wiki/ 最近更新的页面（找到新的知识点）
5. 读取 _raw/processed/ 最近 7 天的文件（捕获新灵感）
生成：
- 选题建议 × 5（每个包含：标题/核心价值/目标受众/推荐格式/关联 wiki 页面）
- 本周创作重点（基于项目进度）
- 知识库空白区（哪些重要概念还没有 wiki 页面）
在 log.md 追加：[日期] 周选题生成完成
"

5.6 Loop 4：每周世界观一致性检查（你的 IP 安全审计）

功能：每周日凌晨 3:00（不干扰正常工作），自动扫描所有内容，检测设定矛盾。

Bash

0 3 * * 0 cd /path/to/你的Vault && claude "
执行 IP 世界观一致性审计
检查范围：
1. wiki/characters/ 所有人物卡：
   - 检查角色能力描述前后是否一致
   - 检查角色年龄/时间线是否合理
   - 检查角色关系描述是否相互印证
2. wiki/world/ 所有设定文件：
   - 检查地理描述是否矛盾
   - 检查历史时间线是否自洽
   - 检查宇宙法则是否有被其他设定违反
3. projects/ 所有 active 项目草稿：
   - 检查是否引用了不存在的设定
   - 检查是否违反了宇宙法则
输出格式：
- 发现的所有矛盾，写入 log.md，格式：
  [日期] [WEEKLY-AUDIT] [严重程度] 矛盾描述
- 生成审计报告：wiki/world/audit-report-[日期].md
- 严重程度分级：[轻微] 细节不一致 / [中等] 情节逻辑漏洞 / [严重] 核心设定冲突
在 log.md 追加：[日期] 周审计完成，发现 X 个矛盾
"

5.7 四个 Loop 的协作关系

text

┌─────────────────────────────────────────────────┐
│                四个 Loop 的协作关系               │
│                                                 │
│  你每天的输入：                                  │
│  Web Clipper 抓取 / 语音备忘 / 手动笔记          │
│           ↓                                     │
│  ┌─────────────────────────────────────┐        │
│  │ Loop 1（每小时）：原始素材处理       │        │
│  │ _raw/ → wiki/（知识库持续增长）     │        │
│  └─────────────────────────────────────┘        │
│           ↓ 知识库质量提升                        │
│  ┌─────────────────────────────────────┐        │
│  │ Loop 2（每日）：创作日报生成        │        │
│  │ 你醒来就知道系统昨天做了什么         │        │
│  └─────────────────────────────────────┘        │
│           ↓ 掌握进度，决定优先级                  │
│  ┌─────────────────────────────────────┐        │
│  │ Loop 3（每周一）：选题建议生成       │        │
│  │ 基于受众洞察+知识库的智能选题        │        │
│  └─────────────────────────────────────┘        │
│           ↓ 方向明确，质量保障                    │
│  ┌─────────────────────────────────────┐        │
│  │ Loop 4（每周日）：一致性审计         │        │
│  │ 你的 IP 世界观安全网                │        │
│  └─────────────────────────────────────┘        │
│           ↓ 护城河越来越高                        │
│  你的竞争优势在复合增长                           │
└─────────────────────────────────────────────────┘

5.8 Loop 的安全边界：你必须保留的人工控制点

一旦你把控制权交出去，你真的需要信任这个提示词。

在自动化中，有四件事永远不应该自动化：

不自动化一：发布动作

Loop 可以把内容准备到"ready"状态，但不能替你点击"发布"。发布是你对受众承诺的时刻，这个决定必须是人工的。

不自动化二：删除文件

Loop 只能"移动"文件（移到 processed/ 或 archive/），不能删除任何文件。

不自动化三：修改已发布内容

publish/ 文件夹是只读的。一旦发布，这个版本就是历史记录，不应被 AI 修改。

不自动化四：裁决设定矛盾

当 Loop 4 发现了世界观矛盾，它只标记，不裁决。哪个版本是"正确"的，只有你能决定——因为这个决定涉及 IP 的核心价值取向。

模块六：多平台发布流水线

6.1 一次创作，全面分发的系统设计

IP 创作者最大的时间黑洞之一，是同一个内容在不同平台的手动适配：公众号一个版本，小红书一个版本，X 一个版本，视频脚本又一个版本。

这个过程重复而耗时，而且每次都要手动进行。

现在，这个过程可以变成一个 Skill，一个命令触发，AI 自动生成所有平台版本。

6.2 平台差异分析

在设计适配 Skill 之前，先理解每个平台的本质差异：

6.3 多平台发布 Skill 设计

文件位置：skills/publish-pipeline/SKILL.md

Markdown

---
name: publish-pipeline
description: |
  当用户要发布内容到多个平台时激活。
  基于主内容，自动生成各平台适配版本。
slash: /publish
tags: [发布, 多平台, 公众号, 小红书, X, 视频]
---
# 多平台发布流水线技能
## 触发
用户调用 /publish [项目名] [目标平台]
## 执行步骤
### Step 1：加载主内容
读取 `projects/[项目名]/drafts/` 最新版本
### Step 2：受众适配检查
触发 audience-crm 技能，确认各平台受众画像
### Step 3：按平台生成适配版本
#### 公众号版本
目标：深度阅读体验
- 保留完整论证逻辑
- 添加段落小标题（增加扫描友好度）
- 开头：用一个场景或问题钩住读者（前 100 字决定一切）
- 结尾：明确的价值总结 + 行动召唤
- 图片位置标记：[配图：XXX]
- 保存到：publish/articles/[YYYYMMDD]-[标题]-公众号.md
#### 小红书版本
目标：快速获取价值 + 收藏动力
结构：
① 痛点开头（引发共鸣）
② 核心方法（3-5个要点，每点一行）
③ 具体例子（真实感）
④ 行动指引（立即可做）
配套标题：疑问句或数字型标题
标签：#相关话题标签
保存到：publish/social/[YYYYMMDD]-[标题]-小红书.md
#### X Thread 版本
目标：传播核心观点
格式：
1/ [钩子推文：核心观点，让人想看下文]
2/ [背景说明]
3-6/ [每条推文一个论点，独立成立]
7/ [总结 + 价值提炼]
8/ [关注原因 + 互动问题]
每条推文独立成立，即使只看一条也有价值
保存到：publish/social/[YYYYMMDD]-[标题]-X-thread.md
#### 视频脚本版本
目标：口播自然，节奏感强
结构：
[0-15s] 开场钩子：直接说出最反常识的观点
[15-60s] 建立共鸣：这个问题困扰了多少人
[60-180s] 核心内容：每个论点配一个视觉化例子
[180-240s] 行动指引：最简单的第一步
[240-270s] 结尾：悬念或价值承诺
每句话不超过 20 字（符合口播节奏）
保存到：publish/videos/[YYYYMMDD]-[标题]-脚本.md
### Step 4：生成发布计划
创建 `projects/[项目名]/publish-plan.md`：
- 各平台发布时间建议（基于受众画像的活跃时段）
- 各版本文件链接
- 发布注意事项
### Step 5：更新状态
将项目 brief.md 的 status 更新为 ready
在 log.md 记录：[日期] [项目名] 完成多平台适配

6.4 内容发布后的知识回流

内容发布是起点，不是终点。产品循环是：原始素材 → 编译的 wiki → 有引用的问答 → AI 输出归档 → 审查 → 提升。

发布后的知识回流 SOP：

text

发布后 24-48 小时：
↓ 收集受众反馈（评论/点赞/转发/私信）
↓ 手动记录或截图 → 放入 _raw/clippings/
Loop 1 自动处理：
↓ 提炼受众洞察 → 更新 crm/insights.md
↓ 高频问题 → 创建 wiki/concepts/ 新页面
↓ 受众对某个设定的困惑 → 标记 wiki 需要补充说明
下周 Loop 3 生成选题时：
↓ 读取新的 crm/insights.md
↓ 基于受众真实反应生成更精准的选题
↓ 知识库的复利开始显现

当你积累到 50-100 条相关主题的笔记时，交叉链接会变得非常有用。在 50 条以下，你自己还记得这些连接。而当你的 wiki 超过这个数量，系统的价值就开始指数级增长——你已经不再依靠记忆，而是依靠结构。

全系统验收：六个模块的完成标准

现在，用这张清单验收你的系统：

模块一：Vault 架构 ✅

•  完整文件夹结构已创建（14个文件夹）
•  根目录四个核心文件已创建（CLAUDE.md / agents.md / index.md / log.md）
•  三种 frontmatter 模板已确定（世界观/人物卡/项目）

模块二：CLAUDE.md ✅

•  七个板块全部完成
•  IP 宇宙法则已定义（至少 3 条不可违背的规则）
•  创作声音指南包含具体的"绝对禁止"清单
•  Agent 行为规则有明确的权限边界

模块三：obsidian-skills ✅

•  已选择安装路径（A/B/C 之一）
•  五个技能已验证加载（obsidian-markdown / obsidian-bases / json-canvas / obsidian-cli / defuddle）
•  测试：让 Claude 创建一个带 frontmatter 和 wikilink 的测试笔记，格式正确

模块四：Skills 技能库 ✅

•  四个 IP 专属技能文件已创建（world-builder / character-tracker / content-pipeline / audience-crm）
•  测试：调用 /world-check，Agent 能正确读取 wiki/world/rules.md

模块五：Loop 自动化 ✅

•  Loop 0（手动版）已跑通，_raw/ 里有文件被成功处理
•  Loop 1（每小时定时）已配置
•  Loop 2（每日日报）已配置
•  Loop 3（周选题）已配置
•  log.md 里有 Loop 的运行记录

模块六：发布流水线 ✅

•  publish-pipeline 技能已创建
•  测试：对一篇草稿调用 /publish，生成至少两个平台的适配版本
•  受众 CRM 基础文件已创建（至少一个受众画像文件）

常见问题排查手册

问题一：Claude 写的 wikilink 格式不对（写成了 文字）

原因：obsidian-skills 没有正确加载

解决：

Bash

# 确认 .claude/ 目录存在且结构正确
ls -la .claude/
# 应该看到 obsidian-skills/ 文件夹
# 重启 Claude Code
exit
claude
# 重新启动时会重新扫描 .claude/ 目录

问题二：Loop 跑完了但 wiki/ 里没有新内容

原因：通常是路径问题，或者 _raw/ 里的文件没有正确的 frontmatter

解决：

1. 检查 _raw/ 里的文件是否有 status: unprocessed
2. 在终端手动执行一次 Loop 0，观察报错信息
3. 确认 Claude Code 是否在 Vault 根目录运行

问题三：AI 生成的内容忽略了世界观设定

原因：CLAUDE.md 里的设定太抽象，或者相关 wiki 文件不存在

解决：

1. 检查 CLAUDE.md §7 的"上下文加载指令"是否包含相关 wiki 文件的路径
2. 在 CLAUDE.md 里加入更具体的规则
3. 在任务开始时明确指令："先读取 wiki/world/rules.md，然后再执行任务"

问题四：log.md 文件变得越来越大，难以查看

解决：每月归档旧日志

Bash

# 创建月度归档
mkdir -p journal/2026/logs/
mv log.md journal/2026/logs/log-2026-06.md
# 创建新的空 log.md
touch log.md
echo "# 操作日志 - 2026-07 开始" > log.md

问题五：多个 Loop 同时运行，产生了文件冲突

解决：给不同的 Loop 设置不同的运行时间，避免并发：

Bash

# Loop 1：每小时第0分
0 * * * * [命令]
# Loop 2：每天22:00
0 22 * * * [命令]
# Loop 3：周一9:00
0 9 * * 1 [命令]
# Loop 4：周日3:00
0 3 * * 0 [命令]

结语：你的系统刚刚拥有了自己的生命

如果你按照这六个模块完成了所有步骤，此刻你拥有的不只是"一个更好的笔记系统"。

你拥有的是：

• 一个每小时自动处理新素材的知识引擎
• 一个知道你 IP 世界观的 AI 协作者
• 一个每天晚上自动总结进展的日志系统
• 一个每周一帮你想选题的策划助手
• 一个每周检查世界观安全的"守门人"

这个系统的最大特点，是它会随着时间变得越来越聪明。

交叉链接在你积累到 50-100 条相关主题的笔记后会变得非常有用。在 50 条以下，你自己还记得这些连接。

三个月后，你的 wiki 会有几百条相互关联的知识条目。AI 基于这个知识库生成的内容，质量将远超今天。

六个月后，你会发现自己的创作决策越来越快——不是因为你变聪明了，而是因为你有了一个越来越精准的"思考环境"。

一年后，这个系统积累的 IP 世界知识、受众洞察、创作方法论，将成为你最难以被复制的竞争优势。

现在，已经足够信任这个流水线了——你知道当你去倒咖啡时，你的笔记已经在自动变得更加整洁有序。

这就是 Loop Engineering 给 IP 创作者的真正礼物：你的系统在工作，而你在创作。

📌 完整操作手册 · 速查索引

每一个真实运转的系统，都是下一个想搭建系统的人最好的说服。