> ## 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.

# 用智能体自动化妻子的内容营销
- URL: https://www.hubwiz.com/blog/automating-my-wife-s-content-marketing-with-agents/
- Published: 2026-05-13T13:07:25.000Z
- Updated: 2026-10-13T15:53:48.000Z
- Description: 我的妻子需要持续的内容营销来保持在行业中的可见度。如果你几周不发声，客户就找不到你。但她经营着一家企业——客户是第一位的。
- Author: admin
- Tags: AGENT, MARKETING, #Import 2026-10-14 14:41

我妻子去年辞去了公司工作，成为了一名个体创业者。她没有时间做内容营销。所以我在Claude Code上为她构建了一个15个Agent的自主系统。

上周的构建日志向你展示了[AI Chief of Staff](https://doneyli.substack.com/p/i-built-an-ai-chief-of-staff-that)（43,000行Python代码，7个Agent管理我的生活）。今天我将深入探讨构建的另一半：我为她的企业构建的内容系统，在她睡觉时每周跨四个平台产出10-12篇内容。

这不是演示或副项目。这是一个为真实业务运行的生产系统。3,000个文件，24个自定义技能，4个对话内子Agent，以及一个处理从信号发现到分析收集所有环节的双波批量流水线。

我完全用Claude Code构建了它，就是那个大多数人只把它当作花哨自动补全的CLI工具。

以下是架构、有效的模式、构建过程中让我浪费数周的错误，以及（针对付费订阅者）让你可以自己构建的精确设置。

## **1、没人谈论的问题**

**约束条件：** 她需要持续的内容营销来保持在行业中的可见度。如果你几周不发声，客户就找不到你。但她经营着一家企业——客户是第一位的。

**真正的约束：** 预算内无法聘请营销团队或专门的内容人员。AI工具有助于写作，但谁来每天运行它们？仍然需要有人提示它们、审查输出并点击发布。这是一份工作。

**她首先尝试了：**

- **有时间就发布：** 不稳定。好的几周很棒。忙碌的几周意味着沉寂；而沉寂在行业中会扼杀可见度。
- **雇佣自由职业者：** 昂贵，而且他们不了解她的声音。内容听起来专业但千篇一律。可以是任何人写的。
- **通用AI工具：** 更糟。精致但听起来和其他人一样。没有针对性，没有可信度，没有"她"。

三者失败的原因相同。它们将内容视为孤立的输出，而不是一个具有依赖关系、共享资源和随时间累积的质量标准的系统。

**她实际需要的：** 一个了解她声音、遵循她标准、在她专注于客户时处理重复性工作的系统。

## **2、在她睡觉时运行的架构**

内容系统遵循一个循环：

```
信号发现 → 周计划 → 双波生产 → 审查 → 发布 → 分析 → 循环

```

三个层次使其工作。我称之为**三层自主栈**，这是区分"AI工具"和"AI基础设施"的模式。

### **第1层：配置（大脑）**

Claude Code在每次对话前读取项目根目录的`CLAUDE.md`文件。大多数人会在里面放几行指令。我把它变成了整个内容运营的路由表。

我为她构建了三个配置层级：

- **全局**（`~/.claude/CLAUDE.md`）：我的个人偏好、代码质量规则、工作流模式。这跟随我构建的每个项目。
- **项目**（`content-system/CLAUDE.md`）：她的内容运营。技能触发器、她的内容模型、质量门、平台层级、编辑日历。目前约200行，指向更深层的资源。
- **记忆**（`~/.claude/projects/.../MEMORY.md`）：跨会话持久化的上下文。她的指标、策略决策、已发布内容、对受众有效的内容。Claude在每次对话前读取这个，已经了解她的品牌、受众和内容模型。

当Claude启动一个会话时，它已经知道她的声音、受众、内容模型、活跃策略和编辑日历。不需要提示。上下文是结构性的，而非对话式的。

**路由表模式至关重要。** 我的第一个CLAUDE.md有2,000行。Claude花了太多token处理指令，用于实际工作的容量就少了。现在它约200行，指向`.claude/`中的134个文件。主文件路由。技能文件指导。

![](https://www.hubwiz.com/blog/content/images/2026/05/https-3A-2F-2Fsubstack-post-media.s3.amazonaws.com-2Fpublic-2Fimages-2F940658a1-cc1a-4e11-8d9a-abfe13e382f0_1024x572.png)

### **第2层：技能（战术手册）**

为她的业务内容需求构建了24个自定义技能，每个都是基于触发短语自动激活的结构化行为。当系统收到"起草一篇LinkedIn帖子"时，Claude加载LinkedIn起草技能。当收到"规划下周"时，它加载周计划技能。无需手动切换上下文。

- **起草（7个技能）：** LinkedIn、newsletter、Twitter、Substack Notes、视频、YouTube、演讲
- **生产（2个）：** 周计划 + 批量起草编排
- **分析（3个）：** LinkedIn指标、Substack统计、帖子级导出
- **互动（1个）：** 四种模式的评论起草
- **研究（2个）：** 信号扫描、CFP分析
- **发布（2个）：** 发布工作流、内容再利用
- **外部（3+）：** 演示文稿（Gamma API）、图片（Gemini）、性能审查

每个技能有四个组成部分：

1. **清单工作流**，包含Claude跟踪的明确步骤（步骤1、步骤2等）
2. **质量门**，带有复选框（什么使输出好或坏）
3. **模板**，用于结构骨架（同一平台内的不同格式）
4. **共享资源**，从`_shared/`目录引用

**共享资源模式改变了一切。** `_shared/`中的五个文件（声音基础、质量门、内容模型参考、平台格式、积压集成）被每个起草技能引用。我更新一次她的声音指南，所有7个起草技能立即继承更改。

在我构建`_shared/`之前，每个技能都有自己的声音规则副本。当我在分析她表现最好的帖子后优化语气时，我不得不在7个地方更新。我遗漏了一个。那个技能产生了脱离声音的内容长达两周，在我发现之前——她的品牌声音在各个Agent间不一致，帖子听起来像来自两个不同的人。

### **第3层：自主Agent（舰队）**

15个shell脚本，每个在macOS的launchd调度上以无头模式启动Claude Code（`claude -p`）：

**市场情报（每日）**

- signal-scan（早上6点）：扫描HN、Reddit、arXiv寻找趋势
- deep-signal-scan（早上7点）：深入挖掘检测到的信号
- afternoon-pulse（下午2点）：午间信号刷新
- cross-field-scan（每周）：跨行业模式检测
- weekly-intelligence（每周）：汇总情报简报

**内容运营（每周周期）**

- content-planner（周日晚）：生成下周日历
- content-producer（周一凌晨1点）：起草所有内容（双波流水线）
- content-prep（周一早上6点）：发布前准备

**分析（每周）**

- analytics-collector：收集平台指标
- linkedin-post-export：每篇帖子的详细LinkedIn统计
- performance-review：分析哪些有效哪些无效

**互动（每日）**

- commenting-curation：评分和排队评论目标
- midday-engagement：监控和回应互动
- lead-scan：识别收入线索
- lead-pipeline-updater：更新线索评分

它们在她睡觉时运行。每个Agent将健康状态推送到Gatus（正常运行监控），并通过ntfy（自托管推送通知）发送失败通知。如果Agent在凌晨3点失败，我会收到通知。如果成功，监控仪表板保持绿色。

## **3、改变一切的模式：双波生产**

这是使批量内容生产真正有效的突破。

**朴素并行的问题：** 如果你同时起草所有内容，你的Substack Notes无法引用你的LinkedIn帖子，因为它们还不存在。你的Twitter线程无法提炼你的newsletter，因为它还没写好。内容有依赖关系。

**解决方案：带特定模型委派的顺序波。**

```
波1（周一凌晨1点）
├── LinkedIn帖子（5-7篇原创）          ← Opus
└── Newsletter（1篇深度文章）           ← Opus
        │
        ▼  波1输出成为波2输入

波2（周一，波1完成后）
├── Substack Notes（从LinkedIn改编）    ← Sonnet
└── Twitter（挖掘GitHub活动，而非LinkedIn）← Sonnet

```

**为什么每波使用不同模型？**

- **Opus**用于波1：原创内容创作需要深度。声音一致性、钩子选择、结构决策是创造性的任务，受益于最强大的模型。
- **Sonnet**用于波2：改编是公式化的。"把这篇LinkedIn帖子改成适合Substack的对话风格"是一个结构化转换。Sonnet便宜3-4倍且足够快。

**为什么Twitter不同：** Twitter不是从LinkedIn改编的。它挖掘实际的GitHub活动和Langfuse跟踪，获取原始构建观察。这是一个"公开构建"的游乐场，有自己的声音。LinkedIn听起来专业。Twitter听起来像构建者的笔记本。这是刻意的设计选择，而非捷径。

**对于企业领导者：** 这是你会在任何多阶段AI流水线中使用的相同模式。将创作与转换分离。将模型能力与认知负荷匹配。让昂贵的模型做思考。让高效的模型做格式化。

## **4、安全架构：什么防止它出错**

### **4.1 人在回路中的门控**

我的内容生产者Agent在起草任何内容之前检查她是否已审查周历：

```
# 检查日历在规划器创建后是否被修改
PLANNER_COMMIT=$(git log --grep="content plan W$WEEK" | head -1)
EDITS_AFTER=$(git log "$PLANNER_COMMIT"..HEAD -- "$CALENDAR" | head -1)

if [ -z "$EDITS_AFTER" ]; then
  echo "跳过：日历未更改。等待人工审查。"
  exit 0
fi

```

**模式：** 规划器创建。她审查。生产者执行。如果她没有碰日历，生产者什么都不做。这防止系统基于未审查的计划生成内容。

任何程度的自动化都不应绕过对发布内容的编辑判断。

### **4.2 带指数退避的重试**

Claude Code会话可能失败（API速率限制、网络故障、上下文窗口耗尽）。每个Agent在报告失败前最多重试3次，使用指数退避（60秒、120秒、240秒）。这听起来基本，但在第一个月为我省去了30多次误报通知。

### **4.3 监控即基础设施**

```
push_gatus() {
  curl -s -X POST \
    "${GATUS_URL}/api/v1/endpoints/content-system_${AGENT}/external?success=$1" \
    -H "Authorization: Bearer ${GATUS_TOKEN}"
}

notify() {
  curl -s -H "Title: $1" -H "Priority: $3" -d "$2" \
    "${NTFY_URL}/content-system-alerts"
}

```

每个Agent在每次运行后报告成功或失败。监控仪表板让我一目了然地看到整个舰队的状态。早期有一个Agent悄无声息地失败了一周。直到我的分析数据过时了我才发现。现在每个Agent从一开始就有健康检查和通知。

![](https://www.hubwiz.com/blog/content/images/2026/05/https-3A-2F-2Fsubstack-post-media.s3.amazonaws.com-2Fpublic-2Fimages-2F35a83b51-f687-4ae0-8d57-b392394a779f_2488x1694.png)

## **5、框架：三层自主栈**

以下是这个模型。无论你构建的是内容系统、数据流水线还是内部运营Agent，各层都是一样的：

**第1层：配置。** 持久化的上下文，使每个会话了解你的标准、声音、约束和当前状态。没有这个，每次交互都从零开始。

**第2层：技能。** 结构化、可重用的行为，带有质量门和共享资源。没有这些，你会得到不一致的输出，需要大量的人工编辑。

**第3层：Agent。** 按计划运行、受监控、自主的执行者，使用技能和配置独立运行。没有监控，你会得到无声的失败和陈旧的数据。

**关键洞察：** 每一层依赖于它下面的层。没有技能的Agent产生不一致的输出。没有配置的技能产生脱离声音的内容。你应该自下而上构建，而非自上而下。

```
第3层：AGENT（自主、按计划、受监控）
    ↓ 使用
第2层：技能（结构化行为、质量门、共享资源）
    ↓ 使用
第1层：配置（持久化上下文、声音、标准、记忆）

```

**如果你是一位评估自主AI的CTO：** 问题不是"我们应该使用AI Agent吗？"而是"我们有详细到足以让Agent遵循的文档化流程吗？"如果你最好的工程师不能用20个要点解释工作流，Agent也无法执行。配置和技能先于Agent。

![](https://www.hubwiz.com/blog/content/images/2026/05/https-3A-2F-2Fsubstack-post-media.s3.amazonaws.com-2Fpublic-2Fimages-2F8d99aa00-7506-4709-a3b0-507f1f278ee7_1376x768.png)

## **6、浪费我数周时间的五个错误**

### **错误1：从Agent而不是配置开始**

我在拥有技能和配置之前就尝试构建自主舰队。Agent没有战术手册可遵循，因此输出不一致。一个Agent起草的LinkedIn帖子与另一个的声音完全不同——她的品牌声音在各Agent间不一致，因为两者都没有读取共享的声音规则。

**修复：** 自下而上构建。先配置，再技能，然后Agent。每层需要它下面的那一层。

### **错误2：一个巨大的CLAUDE.md（2,000行）**

我的第一个CLAUDE.md试图包含所有内容。Claude花了太多token处理指令，用于实际工作的上下文窗口就少了。草稿变得更短、更不详细，因为模型在开始写作之前就已经"满了"。

**修复：** CLAUDE.md是路由表，不是长篇小说。保持在300行以下。指向技能、共享文件和文档中的详细资源。主文件路由。技能文件指导。

### **错误3：没有共享资源**

每个技能都有自己的声音规则和质量门副本。我更新了一个技能中的声音指南，忘了另外三个。那些技能在数周内产生了脱离声音的内容。

**修复：** 从第一天起创建`_shared/`目录。声音、质量门、格式化规则、内容模型。更新一次，处处传播。

### **错误4：所有事情都用Opus运行**

我第一个月的API账单是应有费用的4倍。Opus在分类分析数据、将LinkedIn帖子改编为Substack Notes、以及格式化日历条目。这些都是Sonnet能以极低成本完美处理的任务。

**修复：** 将模型与认知负荷匹配。Opus用于创作和推理。Sonnet用于提取、改编和结构化任务。Haiku用于分类和路由。

### **错误5：Agent没有监控**

一个Agent悄无声息地失败了一周。我的分析数据变得陈旧。直到我试图审查每周表现时才发现，数字已经是一周前的了。

**修复：** 每个Agent从第一天起就有健康检查、失败通知和结构化日志。而不是"最终"那天。

## **7、数据**

以下是我为她构建的系统的产出：

- 系统中的**3,000+个文件**
- **24个自定义技能**，**15个自主Agent**，**4个对话内子Agent**
- 服务于**4个平台**（LinkedIn、Substack、Twitter、Substack Notes）
- 每周**10-12篇内容**
- 她每周约**2-3小时的审查时间**（人工投入）
- 构建耗时约**6个月**（迭代式，同时有全职工作）
- `.claude/`目录中有**134个文件**
- 所有7个起草技能引用的**5个共享资源文件**

她专注于客户。系统处理可见度。

**大家都会问的成本问题：** Claude Max订阅（100美元/月）覆盖所有15个Agent通宵运行，每项工作零边际成本。双波模型策略（Opus用于创作，Sonnet用于改编）保持交互使用的效率。对于一个需要兼职内容协调员的系统，每月总成本：100美元。

---

原文链接: [How I Automated My Wife's Content Marketing with AI Agents on Claude Code](https://doneyli.substack.com/p/how-i-automated-my-wifes-content)

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

> **这是「Agent / MCP」专题的一部分。**完整地图见：[Agent / MCP / 自动化完全指南](https://www.hubwiz.com/blog/agent-stack/)