我用AI打造了一个内容工厂

内容的好坏，完全取决于背后的人和系统。投入在筛选想法和写作上的精力少，输出的内容质量就低。

这篇文章将帮助你开始构建自己的内容护城河。

我构建了一个系统，它只优化一件事：

值得收藏的内容

这是一种能让读者觉得“极具价值”、忍不住点击书签按钮、加入自己第二大脑以备日后参考的帖子。

这是我那篇获得100万印象的帖子的例子：

1、从这篇文章你将获得什么

这里的每个部分，你都可以直接复制、调整，并在本周就应用到自己的账号上：

完整的 Content OS 框架，并映射到你今天就能建立的实际文件夹结构
四个生产级提示词，你可以直接复制到 Claude 或任何前沿模型中使用并开始产出
V1 入门版，只需1-2小时的前期投入，就能让你之后每周都节省这些时间
作家上下文数据包模板，能把模糊的简报变成具体的草稿

2、先说结果，再说理论

我运营着自己的个人 X 账号。在此系统运行前，账号虽然有名字和几千粉丝，但我基本没怎么打理。

当时根本谈不上有什么系统，只是偶尔发帖，数据也时好时坏。

然后我坐下来，搭建了这篇文章中描述的系统。

从一个近乎沉默的账号，在2周内获得500万印象。此后每周迭代。到第二个月，同一个账号累计超过1100万浏览量和10万书签。

我还联合创立了 @LunarStrategy，我们为客户部署了类似的 Content OS。

3、不可妥协的原则

在讲任何具体机制之前，整个系统运行的核心规则是：

绝不发布未经编辑的内容，每篇草稿都要手动完成最终打磨。 系统是加速器，不是自动驾驶仪。如果当成全自动，它就会衰退。

目标不是用提示词伪造一个声音，而是从你真实的写作中构建一个可重复使用的运营资产。一次投入做好，后续持续更新，这样模型每次生成的草稿都会更接近你的风格，你的时间就可以专注在打磨想法上。

4、“值得收藏”到底是什么意思

收藏是读者对未来自己的一个小承诺，它意味着“我以后还会需要这个”。这比点赞的要求高得多，在算法中的表现也不同。

我不会夸大排名算法，但我作为一个每周都在跑这个系统的营销者，发现规律非常一致：书签是对未来实用性的投票，获得书签的帖子即使过了很久，也会持续出现在 feed 中。

在我发布任何内容之前，我会问自己这篇帖子是否像以下任意一种：

检查清单
蓝图
文件夹结构
模板
框架
逐步工作流
带截图的证明 + 关键 takeaways
前后对比
可重复使用的心智模型

如果草稿不符合以上任何一种，通常就不应该发布。

5、系统一图概览

我不是跑一个超级大提示词，也不是用一堆通用文件夹。我的系统围绕一个核心理念构建：每一条内容都是一个携带自身状态的对象，从想法到发布。


   ┌──────────────────────────┐   ┌──────────────────────────┐
   │ EXTERNAL: SIGNAL LAYER   │   │ INTERNAL: KNOWLEDGE GRAPH│
   │                          │   │                          │
   │ X bookmarks, articles,   │   │ personal OS, notes,      │
   │ transcripts, DMs,        │   │ journals, voice memos,   │
   │ replies, competitor      │   │ owned content archive    │
   │ posts                    │   │                          │
   │                          │   │                          │
   │ feeds: rewrite,          │   │ feeds: original,         │
   │ research + ideate        │   │ repurpose                │
   └─────────────┬────────────┘   └─────────────┬────────────┘
                 │                              │
                 └──────────────┬───────────────┘
                                ▼
              ┌────────────────────────────────────┐
              │ STRATEGY + VOICE + STORES          │
              │ positioning, voice profile,        │
              │ master avoid-slop, ideas, hooks,   │
              │ proof bank, feedback log           │
              └────────────────┬───────────────────┘
                               │ feed into
                               ▼
              ┌────────────────────────────────────┐
              │ PRODUCTION LEADER                  │
              │ opens run folder, routes via       │
              │ idea gate, enforces gates          │
              └────────────────┬───────────────────┘
                               │ creates
                               ▼
              ┌────────────────────────────────────┐
              │ RUN FOLDER (one per content object)│
              │                                    │
              │  idea ─► brief ─► draft ─► verify  │
              │  ─► shann review ─► scheduler      │
              │  ─► feedback                       │
              └────────────────┬───────────────────┘
                               │ updates on the way out
                               ▼
              ┌────────────────────────────────────┐
              │ STORES                             │
              │ winners, losers, voice rules,      │
              │ banned patterns, hooks, proof      │
              └────────────────────────────────────┘

上下文存在于两个地方：

信号层：你本周保存的书签、你关注的创作者的内容、你喜欢的文章等外部输入。
知识图谱：你已经拥有的内部资产——你的个人 OS、笔记、日记、语音备忘录，以及你已经发布的内容存档。

路由决定使用哪种来源来生成简报，而策略 + 声音 + 存储则位于两者与作家之间，确保上下文经过精心筛选。

每篇帖子、文章、线程或 campaign 都会作为一个新的“运行文件夹”打开，这个文件夹就是内容对象。它会从系统的共享部分拉取信息，经过一系列生命周期关卡，当它发布后会把学到的东西写回去。

一个内容对象的生命周期：

captured
  → idea_review (route: original / repurpose / rewrite / research+ideate)
  → brief_ready
  → drafting
  → verification
  → shann_draft_review
  → approved
  → scheduler_ready
  → scheduled
  → published
  → feedback_24h
  → feedback_72h
  → learned

运行文件夹周围有什么：

策略：定位、受众、支柱话题、来源监控列表。这是唯一我手动编辑的层。如果你让 AI 写你的定位，那你就不是有定位，而是有平均值。
声音：声音档案和“避免低质”（avoid-slop）主文档。每个代理在起草前都会读取它。
存储：原始输入收件箱、待处理工作板、想法 backlog、钩子库、证明库、反馈日志。这是运行文件夹读写共享记忆的地方。
模块：作家技能（SKILL.md、参考资料、模板）。生产代码。你给系统的每个角色对应一个模块。
工作流：把内容对象从想法推到发布的 playbook，包括验证检查表、调度移交、反馈循环等。

6、四种路由

在内容对象进入起草阶段前，想法关卡会做一个决定：这是哪种类型的内容？

共有四种路由，每种都有自己的简报、参考资料和关卡：

原创（ORIGINAL）：直接从你自己或你的第二大脑中创造（个人 OS、笔记、日记、语音备忘录、你已经思考几周的想法）。简报依赖你的基础：定位、证明库、支柱话题。不使用外部来源。需要高品味投入。
repurposing（REPURPOSE）：拿已有的内容进行扩展。内容系列衍生品、从文章中拆出的线程、对自己爆款帖子的自 QRT，或从已发布内容中抽一行来发帖。核心是你的，形式可以变化。
改写（REWRITE）：从信号层拿外部素材（值得回复的推文、值得拆解的文章、有用框架的转录稿），用你的观点和声音进行翻译。简报会明确说明要保留什么、如何致谢、以及适用哪些声音规则（参考 avoid-slop 主文档）。
研究 + 发想（RESEARCH + IDEATE）：探索一个话题、研究模式，在开始起草前生成候选角度。输出不是帖子，而是一个打磨好的想法或角度列表，反馈到存储/想法库供后续使用。

每种路由最终还是会生成一个运行文件夹，并在 content-object.md 中声明路由类型。


runs/active/2026-05-bookmark-flywheel/
  content-object.md   # route, current state, next action
  idea.md             # the idea gate decision
  brief.md            # writer handoff (for original, repurpose, rewrite)
  draft-package.md    # rendered draft, verifier output, review notes
  feedback.md         # 24h / 72h learnings

5、这个系统之前的版本

在当前的 Content OS 之前，我曾构建过一个4代理系统，运行类似的循环：研究员、想法生成器、作家，以及一个在它们之间路由的协调者。每个代理都有跨会话持久的记忆。

我用 Claude Code + Markdown 提示词 + 数据库 + CLI 工具全部搭建完成。

它有效，但过于复杂。四个代理其实只对应三个生产步骤加一个反馈循环。运行它让我学到大多数关于代理集群的博客文章忽略的东西：

代理数量不是关键杠杆，喂给作家的知识层才是。

现在的版本更精简：更少的代理、更多工作流、同样的循环、更锐利的输出。

6、你今天就能搭建的文件夹

你不需要花哨的基础设施就能开始。你只需要一个存放共享部分的目录，以及每个内容对象在发布前居住的地方。

我的结构如下：

/content-os
  /strategy
      positioning.md
      audience.md
      pillars.md
      source-watchlist.md

  /voice
      voice-profile.md
      master-avoid-slop.md

  /stores
      inbox.md
      workboard.md
      ideas/
      hooks/
      proof/
      feedback/

  /runs
      /active
          /2026-05-bookmark-flywheel
              content-object.md
              idea.md
              brief.md
              draft-package.md
              feedback.md
      /archive

  /modules
      /writer
          SKILL.md
          references/
          templates/

  /workflows
      idea-to-published-post.md
      verifier-checklist.md
      scheduler-handoff.md
      feedback-loop.md

runs/active/ 是核心。里面的每个文件夹都是一个内容对象。一条内容 = 一个运行文件夹，它会携带自己的状态，直到发布后被归档。

Notion、Obsidian、Git 仓库、共享驱动器……用你已经在用的工具就行。结构比工具更重要。

7、你的 V1 搭建步骤

计划投入1-2小时的前期工作。你不会“完成”，但你会“开始”，这是唯一值得的状态。这里花的时间会在之后每周为你节省更多时间，因为下一次草稿会带着上下文开始，而不是从零开始。

步骤1：搭建结构。创建六个顶级目录：strategy、voice、stores、runs、modules、workflows。在 runs 里再加 active/ 和 archive/。其余暂时留空。

步骤2：填充 strategy。创建 strategy/positioning.md、strategy/audience.md 和 strategy/pillars.md。每份写3-5行。支柱话题是你有资格谈论的3-4个领域。受众要具体到一个人，而不是一个群体。

步骤3：写声音锚点。创建 voice/voice-profile.md（你总是遵循的5条规则、绝不使用的5种模式、2-3篇你状态最好时的参考帖），并开始建立 voice/avoid-slop.md（用下面八种模式作为起始过滤器，每次草稿出现问题就添加）。在 stores/proof/ 放入十个具体证明（数字、名字、你做过的项目、真实案例）。

步骤4：往 stores/inbox.md 放入十个想法。其中一半应该来自你这个月在 DM 或电话里已经说过的话，而不是现场编的。

步骤5：为一个想法打开运行文件夹。创建 runs/active/2026-05-{你的slug}/。在里面写 content-object.md（ID、状态、格式、支柱）和 brief.md（使用下面的作家上下文数据包模板）。把 brief 交给你的写作模型。

步骤6：阅读草稿并闭环。模型会在同一文件夹返回 draft-package.md。对照验证器和 avoid-slop 主文档检查。通过则排期，否则给一个具体修改意见。发布后写 feedback.md 并归档文件夹。

8、作家上下文数据包（最容易出错的部分）

大多数人把整个品牌文档、整个知识库和整个 feed 都扔进一个提示词里。模型就会写出安全的稀泥，因为上下文里没有真正重要的东西。

一个紧凑的数据包几乎总是胜过巨大的上下文窗口。

数据包作为 brief.md 存在于运行文件夹中。每条内容一个数据包，在起草前写好。

可复制的模板：

writer context packet
─────────────────────
thesis:        one sentence the post must prove
reader:        the specific person who should save it
proof:         numbers, screenshots, stories I am allowed to use
angle:         the unexpected framing
constraints:   format, length, tone, banned phrases
voice anchors: 2-3 lines that sound like me
risks:         what would make this read as slop or as cringe
open loops:    what I do not yet know, that the writer should flag

9、可收藏价值评分表

在草稿排期前给它打分。每项0、1或2分：

帮读者省下未来要做的事
包含证明（数字、截图、具名案例）
提供可重复使用的 takeaway（模板、清单、框架）
有特定受众和待完成的工作
我不在场也能直接应用
有强有力的截图或视觉

总分12分。我个人的及格线是8分。低于8分就退回数据包修改，而不是扔掉。大多数“差”草稿其实是跳过了评分表某一行。修复那一行，重新评分，就能发布。

这个评分表也是训练新合作者最便宜的方式。你不用抽象地教品味，直接给他们评分表，指三篇赢家帖，让分数说话就行。

10、避免低质主文档

评分表告诉你帖子值不值得留，avoid-slop 文档告诉你这篇帖子听起来是不是人写的。

我让每个草稿在发布前都过一遍这个文档。它有54种模式，分三个严重等级，并给出具体改写建议。它能捕捉诸如：

- promotional language ("groundbreaking", "game-changing")
- significance inflation ("pivotal moment", "testament to")
- vague attribution ("experts believe", "studies show")
- false agency ("the system compounds", "the data tells us")
- rhetorical setups ("the question is whether you X")
- staccato fragmentation ("no X. no Y. no Z.")
- em dash overuse (zero is the target)
- filler adverbs ("actually", "literally", "quietly")

这是我的作家代理起草前加载、验证器批准前加载的文档。

它是“AI 写的”和“一个人恰好在使用 AI 写的”之间的区别。

11、四个可直接复制的提示词

简短、有边界、可编辑。把它们当作起始形状，而不是魔法咒语。

每个对应系统的一个层级。丢到 Claude、GPT 或任何前沿模型里用。如果你只保留一个，保留最后那个事后分析提示词。

prompt 1: brand foundation extraction
maps to: strategy/ + voice/

ROLE
You are helping me build the foundation layer of a personal-brand
content system. You will turn raw, half-formed notes about my
work, audience, and voice into a tight set of operating documents
my writer agent can use to draft in my voice.

INPUT
I will paste raw notes covering: what I do, who I help, what I
have shipped or built, how I sound when I write, the kinds of
people I want as readers, and anything I refuse to sound like.

PROCESS
1. Read the notes. Note any contradictions or gaps.
2. Ask me up to 5 clarifying questions. Do not skip this step.
3. Once I answer, produce the six artifacts in OUTPUT FORMAT.
4. Flag anything you had to invent or guess. Mark it "assumed".

OUTPUT FORMAT
1. positioning. one sentence. the line a stranger should be able
   to repeat back after one of my posts.
2. audience. one specific person, by role, situation, and stake.
   not a segment.
3. pillars. 3 to 4 topics I have earned the right to talk about,
   each with a one-line reason I am credible on it.
4. voice rules. 5 things I always do.
5. banned patterns. 5 things I never do.
6. proof bank. 10 concrete things I can reference (numbers,
   names, shipped projects, lived examples).

RULES
- If a section is generic, mark it "missing" and tell me what
  you need from me.
- Do not invent numbers, customers, or projects.
- Use my own words wherever possible. Lift phrases from the notes.
- The output should fit on one page. Tight is the point.

12、两个模型，两个角色

当我开始大规模运行这个系统后，我发现一个显而易见的事：写作和运行系统是两份不同的工作，需要不同的模型。所以我不再用同一个模型做所有事。

我现在的分工是：

作家（Opus 4.7）：负责品味、节奏、压缩、声音、实际草稿
协调者（GPT-5.5）：负责层级路由、为作家打包正确上下文、决定传入内容、运行验证器、移交到发布层

13、在哪里运行这个系统

这样的系统只有当协调者能真正干活时才有效。它需要读写文件、调用工具、运行检查，并按计划把批准的草稿交给发布层。所以关键问题不是用哪个 App，而是系统在哪里运行。

我见过两种有效方案：

VPS + Claude Code。你租一个小服务器，把 /content-os 文件夹放进 Git 仓库，让 Claude Code 在上面跑工作流。完全可控、自己拥有的机器、可定时任务等。
Hermes Agent（我现在用的）。它专为这种工作设计：代理、技能、工具访问、文件和 Git 操作、浏览器搜索、定时任务、跨整个工作流的持久上下文。

14、Postiz 作为发布层

草稿批准后进入 Postiz 并排期。它支持 X、LinkedIn、Instagram、Threads、TikTok、YouTube、Bluesky、Reddit 等多个平台。

开源且可自托管，仓库：gitroomhq/postiz-app，由 @wickedguro 构建。

15、反馈循环才是护城河

大多数人做到发布就停了，而系统从这里才开始赚钱。

我每周会看：浏览量、书签数、书签率、回复、DM 跟进。

书签率是我最关注的指标。它告诉我哪些帖子真正被保存，而不仅仅是被刷过。

赢家会被复制到输入库作为带数据的范例，输家会更新声音规则、禁止模式或想法过滤器。

下一次的数据包会因为本周学到的东西而变得更锐利。

16、蓝图

我正在把完整系统打包成蓝图，放在我正在搭建的新站点 bookmarkable 上。

包括实际文件夹结构、我正在运行的提示词、作家上下文数据包模板、验证检查表、评分表、avoid-slop 主文档，以及我自己账号使用的文件。

想最早知道这个系统蓝图发布消息：https://bookmarkable.io/

如果你已经有满意的草稿，缺的只是发布层，别等我了。现在就可以开始用 Postiz。它就是我接在这个系统后面的工具，能帮你把批准的帖子排期到所有重要渠道。

原文链接：How to build your content system with AI (and get to 5M impressions)

汇智网翻译整理，转载请标明出处