> ## Content Index > Fetch the complete content index at: https://www.hubwiz.com/blog/llms.txt > Use this file to discover other available public pages before exploring further. # 我用AI打造了一个内容工厂 - URL: https://www.hubwiz.com/blog/i-built-a-content-engine-with-ai/ - Published: 2026-05-09T15:35:22.000Z - Updated: 2026-05-09T22:13:37.000Z - Description: 一个系统，它能帮你找到想法，用你的声音起草内容、发布它们，并从有效的内容中学习。它让我的账号在2周内获得500万曝光，2个月内获得10万书签。 - Author: admin - Tags: APPLICATION, #Import 2026-10-14 14:41 内容的好坏，完全取决于背后的人和系统。投入在筛选想法和写作上的精力少，输出的内容质量就低。 这篇文章将帮助你开始构建自己的**内容护城河**。 我构建了一个系统，它只优化一件事： > **值得收藏的内容** 这是一种能让读者觉得“极具价值”、忍不住点击书签按钮、加入自己第二大脑以备日后参考的帖子。 这是我那篇获得100万印象的帖子的例子： ![](https://www.hubwiz.com/blog/content/images/2026/05/image-108.png) ## 1、从这篇文章你将获得什么 这里的每个部分，你都可以直接复制、调整，并在本周就应用到自己的账号上： - 完整的 **Content OS 框架**，并映射到你今天就能建立的实际文件夹结构 - 四个生产级提示词，你可以直接复制到 Claude 或任何前沿模型中使用并开始产出 - V1 入门版，只需1-2小时的前期投入，就能让你之后每周都节省这些时间 - 作家上下文数据包模板，能把模糊的简报变成具体的草稿 ![](https://www.hubwiz.com/blog/content/images/2026/05/image-110.png) ## 2、先说结果，再说理论 我运营着自己的个人 X 账号。在此系统运行前，账号虽然有名字和几千粉丝，但我基本没怎么打理。 当时根本谈不上有什么系统，只是偶尔发帖，数据也时好时坏。 然后我坐下来，搭建了这篇文章中描述的系统。 ![](https://www.hubwiz.com/blog/content/images/2026/05/image-111.png) 从一个近乎沉默的账号，在2周内获得500万印象。此后每周迭代。到第二个月，同一个账号累计超过1100万浏览量和10万书签。 我还联合创立了 @LunarStrategy，我们为客户部署了类似的 Content OS。 ## 3、不可妥协的原则 在讲任何具体机制之前，整个系统运行的核心规则是： **绝不发布未经编辑的内容，每篇草稿都要手动完成最终打磨。** 系统是加速器，不是自动驾驶仪。如果当成全自动，它就会衰退。 目标不是用提示词伪造一个声音，而是从你真实的写作中构建一个可重复使用的运营资产。一次投入做好，后续持续更新，这样模型每次生成的草稿都会更接近你的风格，你的时间就可以专注在打磨想法上。 ## 4、“值得收藏”到底是什么意思 收藏是读者对未来自己的一个小承诺，它意味着“我以后还会需要这个”。这比点赞的要求高得多，在算法中的表现也不同。 我不会夸大排名算法，但我作为一个每周都在跑这个系统的营销者，发现规律非常一致：书签是对未来实用性的投票，获得书签的帖子即使过了很久，也会持续出现在 feed 中。 在我发布任何内容之前，我会问自己这篇帖子是否像以下任意一种： - 检查清单 - 蓝图 - 文件夹结构 - 模板 - 框架 - 逐步工作流 - 带截图的证明 + 关键 takeaways - 前后对比 - 可重复使用的心智模型 如果草稿不符合以上任何一种，通常就不应该发布。 ![](https://www.hubwiz.com/blog/content/images/2026/05/image-112.png) ## 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，包括验证检查表、调度移交、反馈循环等。 ![](https://www.hubwiz.com/blog/content/images/2026/05/image-113.png) ## 6、四种路由 在内容对象进入起草阶段前，想法关卡会做一个决定：这是哪种类型的内容？ 共有四种路由，每种都有自己的简报、参考资料和关卡： 1. **原创（ORIGINAL）**：直接从你自己或你的第二大脑中创造（个人 OS、笔记、日记、语音备忘录、你已经思考几周的想法）。简报依赖你的基础：定位、证明库、支柱话题。不使用外部来源。需要高品味投入。 2. **repurposing（REPURPOSE）**：拿已有的内容进行扩展。内容系列衍生品、从文章中拆出的线程、对自己爆款帖子的自 QRT，或从已发布内容中抽一行来发帖。核心是你的，形式可以变化。 3. **改写（REWRITE）**：从信号层拿外部素材（值得回复的推文、值得拆解的文章、有用框架的转录稿），用你的观点和声音进行翻译。简报会明确说明要保留什么、如何致谢、以及适用哪些声音规则（参考 avoid-slop 主文档）。 4. **研究 + 发想（RESEARCH + IDEATE）**：探索一个话题、研究模式，在开始起草前生成候选角度。输出不是帖子，而是一个打磨好的想法或角度列表，反馈到存储/想法库供后续使用。 ![](https://www.hubwiz.com/blog/content/images/2026/05/image-114.png) 每种路由最终还是会生成一个运行文件夹，并在 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 工具全部搭建完成。 ![](https://www.hubwiz.com/blog/content/images/2026/05/image-115.png) 它有效，但过于复杂。四个代理其实只对应三个生产步骤加一个反馈循环。运行它让我学到大多数关于代理集群的博客文章忽略的东西： > 代理数量不是关键杠杆，喂给作家的知识层才是。 现在的版本更精简：更少的代理、更多工作流、同样的循环、更锐利的输出。 ## 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 并归档文件夹。 ![](https://www.hubwiz.com/blog/content/images/2026/05/image-116.png) ## 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）：负责层级路由、为作家打包正确上下文、决定传入内容、运行验证器、移交到发布层 ![](https://www.hubwiz.com/blog/content/images/2026/05/image-117.png) ## 13、在哪里运行这个系统 这样的系统只有当协调者能真正干活时才有效。它需要读写文件、调用工具、运行检查，并按计划把批准的草稿交给发布层。所以关键问题不是用哪个 App，而是系统在哪里运行。 我见过两种有效方案： 1. VPS + Claude Code。你租一个小服务器，把 /content-os 文件夹放进 Git 仓库，让 Claude Code 在上面跑工作流。完全可控、自己拥有的机器、可定时任务等。 2. Hermes Agent（我现在用的）。它专为这种工作设计：代理、技能、工具访问、文件和 Git 操作、浏览器搜索、定时任务、跨整个工作流的持久上下文。 ## 14、Postiz 作为发布层 草稿批准后进入 Postiz 并排期。它支持 X、LinkedIn、Instagram、Threads、TikTok、YouTube、Bluesky、Reddit 等多个平台。 开源且可自托管，仓库：gitroomhq/postiz-app，由 @wickedguro 构建。 ![](https://www.hubwiz.com/blog/content/images/2026/05/image-118.png) ## 15、反馈循环才是护城河 大多数人做到发布就停了，而系统从这里才开始赚钱。 我每周会看：浏览量、书签数、书签率、回复、DM 跟进。 > 书签率是我最关注的指标。它告诉我哪些帖子真正被保存，而不仅仅是被刷过。 赢家会被复制到输入库作为带数据的范例，输家会更新声音规则、禁止模式或想法过滤器。 下一次的数据包会因为本周学到的东西而变得更锐利。 ## 16、蓝图 我正在把完整系统打包成蓝图，放在我正在搭建的新站点 bookmarkable 上。 包括实际文件夹结构、我正在运行的提示词、作家上下文数据包模板、验证检查表、评分表、avoid-slop 主文档，以及我自己账号使用的文件。 想最早知道这个系统蓝图发布消息：[https://bookmarkable.io/](https://bookmarkable.io/?ref=hubwiz.com) 如果你已经有满意的草稿，缺的只是发布层，别等我了。现在就可以开始用 Postiz。它就是我接在这个系统后面的工具，能帮你把批准的帖子排期到所有重要渠道。 --- 原文链接：[How to build your content system with AI (and get to 5M impressions)](https://x.com/shannholmberg/status/2052780393326092407?ref=hubwiz.com) 汇智网翻译整理，转载请标明出处