方法论：我的内容资料库项目结构复盘

日期：2026-05-19 状态：已发布 VSC 方法区

开头

这套结构不是标准答案，只是我自己在长期整理 AI 视觉提示词、样张、方法论、发布稿和跨对话记忆时，慢慢长出来的一种内容资料库骨架。

它的目标很简单：不要让“灵感”“成品”“图片”“方法论”“记忆”和“发布记录”混在一起。越是高频生产，越需要让每个文件夹只回答一个问题。

根目录

当前根目录结构如下：

E:\yun\OneDrive\shenmeiv
├─ AGENTS.md
├─ README.md
├─ 工作流中枢.md
├─ 记忆中枢.md
├─ 工作记录.md
├─ NBP/
├─ x推文整理/
├─ image/
├─ others_prompts/
├─ _memory/
├─ _archive/
├─ .agent/
├─ scripts/
└─ .codex_tmp/

根目录只放入口和中枢，不放具体内容。真正的内容都下沉到几个主目录里：

• NBP/：共享视觉核心和方法底座。
• x推文整理/：完整提示词、文章、发布稿和案例层。
• image/：图片资源归档。
• others_prompts/：外部提示词原始收藏。
• _memory/：跨对话接续记忆。
• _archive/：历史记录和旧文件归档。
• .agent/：本地技能与自动化规则。
• scripts/：本地工具脚本，比如 Eagle 上传 CLI。
• 工作记录.md：当天实际文件改动审计。

NBP：共享视觉核心库

NBP/ 是底座，不是某一个模型专属。

NBP/
├─ 指南/
├─ 字典/
│  ├─ 00_模型与官方资料/
│  ├─ 01_核心维度/
│  ├─ 02_扩展规则/
│  ├─ 03_人物系统/
│  └─ 04_风格资产/
└─ 方法路由/
   ├─ 基础/
   ├─ 构图/
   ├─ 人像/
   ├─ 风格/
   └─ 叙事/

我把它当作“视觉语义操作系统”。构图、光影、材质、风格、主体、叙事这些东西，只要能跨模型复用，就应该沉到这里。

这里不存某一次生成的完整案例，不存某一个模型的脾气，也不存“今天这个 prompt 很好用”的短期经验。它只保留更稳定的视觉规则。

x推文整理：成品与发布层

x推文整理/ 是完整内容区，负责保存可直接发布、复盘或再次调用的完整材料。

x推文整理/
├─ 00_指南与规范/
├─ 01_人像篇/
├─ 02_构图篇/
├─ 03_风格篇/
├─ 04_妆容篇/
├─ 05_技巧篇/
├─ 06_场景篇/
├─ 07_实验篇/
├─ 08_文章篇/
├─ 09_方法论篇/
├─ 10_捏脸篇/
├─ 11_image2探索/
└─ 已发推文整理/

这里最重要的原则是：内容按用途分，不按一时灵感分。

例如人像、构图、风格、妆容、场景和方法论各自成区。这样以后想找“人像可复用模板”和“构图方法”时，不需要从一堆混合文件里翻。

image2 专区

x推文整理/11_image2探索/ 是 image2 / gpt-image-2 的专属探索库。

x推文整理/11_image2探索/
├─ INDEX.md
├─ README.md
├─ 00_image2_风格词多轴分类调用版.md
├─ 01-87_image2_*.md
├─ 合格提示词样本/
├─ 半成品提示词样本/
├─ 探索画风样本/
├─ 欧洲画风探索/
└─ 老画风探索/

我单独切出 image2，是因为不同模型的写法和反馈机制不一样。image2 更适合保留自然语言画风实验、模型行为观察和样张复盘；这些经验不能直接混进 Nano Banana 或其他模型的方法论里。

每个 image2 条目通常会包含：

• 原始提示词
• 分类判断
• 样张路径
• Eagle ID
• 视觉机制
• 适用方向
• 可复用母版
• VSC 发布记录

这样一条记录同时解决“当时怎么写”“图放哪了”“Eagle 里怎么找”“能不能复用”这几个问题。

image：图片资源区

图片不跟 Markdown 混放，而是集中进 image/。

image/
├─ image2探索/
├─ x推文整理/
├─ 人像篇/
├─ 妆容篇/
└─ 方法论篇/

image/image2探索/ 里会按具体项目建文件夹。图片命名尽量带中文主题、英文主题和编号，例如：

梦核魔法少女公共交通玩偶围观_Dreamcore_Magical_Girl_Transit_Toy_Audience_P05_A01.png

这么做的好处是：即使图片脱离 Markdown，也能从文件名看出主题、组别和编号。

_memory：跨对话记忆

_memory/ 不是资料库正文，它只负责接续。

_memory/
├─ 00_启动协议.md
├─ 01_长期共识.md
├─ 02_当前热点.md
├─ 03_任务状态.md
├─ 04_决策记录.md
├─ 05_可复用知识卡/
├─ 06_人类硬规约.md
└─ _archive/

我把记忆分成几类：

• 长期共识：长期不变的项目偏好。
• 当前热点：最近一段时间要接着做什么。
• 任务状态：项目线推进到哪里。
• 决策记录：为什么当时这么做。
• 可复用知识卡：以后可以反复调用的流程。
• 人类硬规约：不能绕过的规则。

这样做的好处是，新对话不需要全量读取所有历史，只要按路由取相关记忆。

工作记录：当天审计

工作记录.md 只做一件事：记录当天实际改了什么。

它不是长期记忆，也不是文章草稿，更不是灵感池。每次新增、修改、移动文件，都要写进去。

我现在的习惯是每天一个根目录 工作记录.md，旧记录放进：

_archive/工作记录归档/

这看起来有点笨，但非常有用。因为内容库越大，最怕的不是文件多，而是不知道某个文件为什么出现、什么时候被移动、是否已经上传 Eagle 或发过社区。

工具层

工具层主要有两个位置：

.agent/
└─ skills/

scripts/
└─ eagle-archive.ps1

.agent/skills/ 放本地工作技能，比如 image2 图片归档、提示词审计、知识吸收等。

scripts/eagle-archive.ps1 是 Eagle 上传 CLI，用来批量导入图片、写入分类、标签、备注和完整提示词。这样图片不只是“存进去”，而是能在 Eagle 里被检索、被复盘。

我觉得最关键的几条原则

第一，入口少一点，内容深一点。

根目录不要塞内容，根目录只放中枢、说明和主目录。

第二，提示词和图片不要分家。

Markdown 里记录图片路径和 Eagle ID；Eagle 备注里反向写入项目记录和完整提示词。两边互相能找回。

第三，模型经验要分流。

image2 的经验就是 image2，Nano Banana 的经验就是 Nano Banana。能跨模型复用的东西，再抽象到 NBP/。

第四，外部提示词先原样收藏。

不要一看到好 prompt 就吸进主库。先放 others_prompts/，再判断它能复用的是视觉语义、写法结构，还是只是一次性灵感。

第五，工作记录不要省。

真正长期帮忙的，不是“我记得我做过”，而是文件里清楚写着“我在什么时候改了什么，为什么改”。

可以直接借走的骨架

如果你也在做 AI 内容资料库，可以先用这个简化版本：

project/
├─ README.md
├─ 工作记录.md
├─ 工作流中枢.md
├─ core/
│  ├─ 指南/
│  ├─ 字典/
│  └─ 方法/
├─ content/
│  ├─ 人像/
│  ├─ 构图/
│  ├─ 风格/
│  ├─ 场景/
│  ├─ 方法论/
│  └─ image2探索/
├─ image/
├─ others_prompts/
├─ memory/
├─ archive/
└─ scripts/

不用一开始就很复杂。先把“底座、成品、图片、外部参考、记忆、归档、工具”分开，就已经能避免大部分混乱。

结尾

这套结构肯定还会继续变。它不是为了显得专业，而是为了让持续生产不把自己反噬掉。

如果你也在搭 AI 内容库，我觉得最值得先做的不是命名多漂亮，而是先回答六个问题：

方法放哪？
成品放哪？
图片放哪？
外部参考放哪？
记忆放哪？
每次改动怎么追踪？

这六个问题答清楚，项目就已经有骨架了。剩下的，只是在骨架上慢慢长肉。