一、引言：自动化团队，也被大量手工操作困住
来源：Claude Blog / Anthropic · 分享者：Ian Chan、Annabel Custer · 发布时间：2026 年 7 月 8 日
营销运营（Marketing Operations）本来就是负责自动化的团队，但现实往往很讽刺：他们自己仍被大量手工操作包围。
原因不难理解。营销技术栈通常不是一个系统，而是一串彼此勉强连接的系统：CRM 管客户和商机，营销自动化平台跑邮件与名单，活动平台承载报名页，数据仓库存历史指标，Slack 和会议记录里又不断冒出尚未结构化的新口径。平台之间的集成很少完整，最后只能靠人来做“胶水”。
Anthropic 官方文章给了两个很具体的样本：
- 负责营销指标的 Ian Chan，每周要花一到两天追数据、核口径、拼周报；
- 负责 Campaign Operations 的 Annabel Custer，每接一个活动请求，都要依次点开 Salesforce、HubSpot、Swoogo 和邮件工具完成搭建。
两人把这些流程搬进 Claude Cowork 后，原本按“天”计算的工作被压缩到按“小时”计算。Ian 的周报流程从最多两天缩短到最多两小时。
但如果只把这个案例理解成“AI 帮人点得更快”，就错过了最重要的部分。Anthropic 团队真正做的，是把散落在人脑、聊天记录和点击路径里的隐性流程，重构成一套由连接器、定时任务、专用技能、独立验证和人工决策共同组成的运营系统。
换句话说，效率提升只是表象，底层变化是：
营销运营人员不再亲自搬运每一份数据、点击每一个页面，而是开始设计、验证和持续改进一条可重复运行的生产线。
二、案例一：把周度营销报告从“找数”改造成“审稿”
2.1 真正费时间的不是写结论，而是追数据
理想的周报流程应该很简单：所有指标都在仪表盘里，分析师只需要解释“发生了什么、为什么发生、接下来做什么”。
现实却分成四层：
- 一部分指标已经在仪表盘；
- 一部分还停留在数据仓库，尚未进入仪表盘；
- 一部分甚至还没有进入仓库；
- 最新的业务信号可能只存在于 Slack 消息或会议转录里。
业务变化速度超过了传统数据管道的建设速度。于是 Ian 每周最耗时的工作不是分析，而是追踪、拼接和验证这些处在不同成熟度上的信息。
Claude Cowork 接管的正是这段“数据搜寻”工作。
2.2 周日自动准备，周一由人决定叙事
每周日晚上，一个定时任务自动启动。Claude 会读取上一周的业务回顾和最新会议转录，查看 Slack 中销售团队正在关注什么，查询数据仓库，然后留下一份包含指标与建议关注点的文件夹。
周一早上，Ian 打开 Cowork，先拿到一版初始报告：其中既有指标表格，也有候选标题和建议重点。他不会让 Claude 直接定稿，而是先确认数字，再决定本周叙事应该围绕销售优先级、产品发布，还是季度计划展开。方向确定后，Claude 才补充支撑细节和案例。
同一组数据与叙事还会继续生成面向管理层的幻灯片，回答三个问题：什么变了、为什么变、团队准备怎么办。后续事项则被转成 Asana 任务。
这个流程有两个值得注意的边界。
第一，Claude 负责扩大信息搜索面，人负责确定叙事焦点。搜索和汇总可以自动化，但“这一周组织最该关注什么”仍然是业务判断。
第二，数字冲突时不允许猜测。销售团队重组后，营销侧与销售侧的报表曾经对不上。Claude 没有偷偷选一个口径，而是标出差异并询问 Ian 应该如何处理。对报告系统而言，“知道何时停下来”与“知道如何继续”同样重要。
2.3 三个技能，把流程拆成可维护模块
Ian 没有写一个包办一切的超级提示词，而是维护三个职责清晰的技能：
| 技能 | 职责 | 主要风险控制 |
|---|---|---|
| Prep Skill | 组装报告、提出焦点与标题、按选定方向扩写 | 避免遗漏关键上下文 |
| Proofreading Skill | 将草稿中的每个数字追溯到已验证来源 | 防止数字幻觉与口径漂移 |
| Action-items Skill | 把报告中的后续动作转成 Asana 任务 | 防止洞察停留在文档里 |
模块化的价值不只是“好维护”。它把内容生成、事实核验和行动落地分成了三个不同的质量关口：报告可以写得不够精彩，但数字不能失去来源；数字都正确，也不能让后续动作无人认领。
每周流程结束时，Ian 还会让 Claude 总结：这次运行中有哪些内容应该写回技能？销售重组后的新结构、Ian 做过的纠正、标题需要采用的新表达方式，都会成为下一轮运行的显式规则。
于是技能不再是一份静态 SOP，而是一套被真实运行持续校准的操作系统。
三、案例二：把跨平台活动搭建变成“调度—执行—审计”流水线
3.1 活动搭建为什么适合 Agent 化
一次活动、网络研讨会或整合营销 Campaign，通常需要同时完成：
- 在 CRM 创建 Campaign；
- 在营销自动化平台配置工作流和名单；
- 在活动平台建立报名页与落地页；
- 起草邮件；
- 接通平台之间的数据流；
- 提交测试报名，检查确认邮件和任务状态。
这些工作规则明确、重复度高，却横跨多个供应商系统。过去 Annabel 从专用 Slack 频道接单，再逐个平台完成操作。现在，请求者先通过表单说明需求类型，例如活动搭建、数据导入、申请制报名或审批支持，后续流程几乎都由 Claude 处理。
3.2 调度器不干活，只决定谁来干
每小时，一个 Dispatcher Skill 读取请求频道，挑出最紧急的任务，为工单加上已领取标记以避免重复执行，再交给相应的专用技能。
这里最好的设计决定，是让调度器保持“无业务能力”。它不创建活动，不写邮件，也不改落地页，只负责优先级、去重和路由。这样，Annabel 可以单独改进某个专用技能，而不必同时触碰整条分发逻辑。
对于最复杂的 Event Build，请求会依次完成 CRM Campaign、营销自动化 Campaign、工作流、名单、活动平台、邮件、落地页和集成配置。完成后，执行者不会自己给自己判分，而是把结果交给一个全新的审计 Agent。
这个 Audit Agent 没有前序会话上下文。它从外部观察成品：在真实落地页提交测试报名，到 Gmail 检查确认邮件，确认无误后才把 Asana 任务标记为完成。最后，Annabel 仍会在正式发布前审阅结果。
“新实例 + 无前序上下文”很关键。如果仍由执行 Agent 自检，它很容易沿用自己在构建阶段的假设，重复忽略同一个问题。换一个没有历史包袱的验证者，相当于把软件工程里的独立测试思想搬进营销运营。
3.3 专业化技能，而不是一个万能 Agent
原文列出的技能体系覆盖多种请求：
- Dispatcher Skill：读取渠道、判断优先级、路由任务；
- Event-build Skill：跨平台完成活动端到端搭建；
- Webinar Landing Page Skill：生成网络研讨会落地页；
- Audit Skill：由独立 Claude 实例验证活动结果；
- Apply-to-attend Skill：处理报名流程中的变更；
- Approval-support Skill：按计划处理审批并发送邮件；
- Data-import Skill：清理名单并处理参会者数据。
Annabel 还保持一个独立的 Manager Agent。当某次运行出错时，她让 Manager 回看过程并提出调整建议，值得保留的经验再写回相应技能。
这形成了两条互不混淆的链：
- 生产链：调度 → 专业技能执行 → 独立审计 → 人工发布；
- 改进链：运行失败 → Manager 复盘 → 人确认调整 → 更新技能。
一个负责交付，一个负责学习。把二者分开，系统才不会在生产过程中随意修改自己的规则。
四、两个案例背后，是同一套 Agent 运营架构
周报和活动搭建看起来差异很大：前者偏分析，后者偏执行。但把业务名称拿掉，它们其实共享同一套结构。
4.1 Connectors：让 Agent 在工作发生的地方取数与行动
Claude 不是靠人把所有材料复制进聊天框，而是通过连接器访问团队正在使用的营销平台、数据仓库、Slack、Gmail、Asana 等系统。
这解决的是“能不能做”的问题，但也引出安全与治理要求：连接器应遵循最小权限，读与写的权限边界要分开，生产环境的高影响动作要保留审批，所有关键写操作都应留下可追踪记录。原文没有展开权限模型，但任何团队复制这套方法时都不能跳过这一层。
4.2 Skills：把隐性经验变成可复用资产
技能承载的是业务规则、执行顺序、质量标准和异常处理方式。它比一次性 Prompt 更稳定，也比写死在传统自动化脚本里更容易被运营人员理解和迭代。
最重要的维护原则来自原文：同一个纠正出现第二次，就不该继续停留在聊天里，而应该进入技能。
4.3 Scheduled Tasks：把“记得做”变成“自动发生”
周日晚上自动准备报告、每小时自动读取活动请求，这些任务的价值不只是节省点击，而是消除了“谁来记得启动流程”这一脆弱环节。
适合定时运行的工作通常有三个特点：触发条件稳定、输入位置明确、即使暂时无人查看也不会立即造成不可逆影响。
4.4 Independent Verification：让生成和验收相互独立
报告由 Proofreading Skill 逐项核对数字，活动由全新 Audit Agent 从真实用户路径测试。两个案例都没有采用“生成完成即视为成功”的乐观假设。
这是 Agent 工作流从 Demo 走向生产的分水岭：
不要只定义 Agent 要做什么，还要定义什么证据能够证明它做对了。
4.5 Human Validation：人的位置从执行路径移到决策关口
Ian 决定报告叙事，Annabel 审阅活动结果；数字冲突、边界案例和正式发布都要回到人类。
Human-in-the-loop 并未消失，只是从“人完成每一步”变成“人在关键关口做判断”。这既释放了时间，也要求运营人员具备更强的提问、验证、数据口径和系统设计能力。
五、岗位没有消失，但工作的重心已经迁移
Ian 省下的时间没有变成更多报表。他开始帮助营销人员更好地描述问题、改进提示词、理解自行查询的数据，也能深入数据层，确保 Claude 对指标定义、区域结构和仓库口径的理解一致。
Annabel 也不再把主要精力放在复制活动页面和逐项配置，而是转向 Enablement、流程优化和 Campaign Architecture。
这揭示了一个比“节省多少小时”更重要的变化：
| 过去的重心 | 迁移后的重心 |
|---|---|
| 手工汇总数据 | 定义数据口径并验证来源 |
| 逐个平台执行 | 设计跨系统流程与边界 |
| 修正单次错误 | 把重复纠正沉淀为技能 |
| 自己处理全部请求 | 让业务方自助，并提供 Enablement |
| 依赖个人经验保质量 | 用审计步骤与标准化模板保质量 |
原文还指出，Annabel 建设这些流程的首要动机其实是质量，而不只是省时。团队扩张后，营销人员从手边任意模板克隆活动页，很容易留下错误城市名、失效链接或错误确认邮件。统一技能与审计路径可以让构建质量在规模扩大时仍保持一致。
所以，这套实践的核心 ROI 至少有三层：时间压缩、错误减少、组织经验复用。原文只量化了 Ian 从最多两天到最多两小时的变化，没有给出活动吞吐量、错误率或总体成本数据。复制案例时，应该把这些指标纳入自己的试点，而不是只凭“看起来自动化了”判断成功。
六、营销运营团队如何从第一个工作流开始
Anthropic 团队给出的建议，可以整理成一条更稳妥的落地顺序。
第一步：选高频、重复、可验证的流程
不要从“自动化整个营销部门”开始。优先选择每周重复、输入位置明确、输出有客观验收标准的任务，例如周报准备、名单清洗或落地页 QA。
第二步：先写验证标准，再写执行技能
原文明确建议先做 Proofreading Skill。原因很简单：如果团队还不能回答“怎样证明结果是对的”，就不应该急着扩大 Agent 的执行范围。
报告要定义每个数字的可信来源；活动要定义测试报名、确认邮件、字段同步和状态更新等验收项。
第三步：把角色拆开
至少区分调度、执行和审计。调度器只负责去重、排序和路由；专用技能只负责一种任务；审计者使用独立上下文验证成品。职责越清晰，失败时越容易定位和迭代。
第四步：把重复纠正写回技能
发现 Claude 第二次犯同类错误，就停止在对话里临时提醒。让 Claude 总结困难点，运营人员确认后，将规则写进对应技能。技能的质量来自持续运行，不来自第一次编写时追求完美。
第五步：让适合的任务定时运行
把“每周日晚上”“每小时一次”这种稳定节奏交给 Scheduled Tasks。先从只读、可回滚、低影响的动作开始，再逐步扩大到写操作。
第六步：保留明确的人类关口
叙事选择、口径冲突、生产发布、权限变更和异常处理，不应被模糊地交给 Agent。团队要明确：哪些情况可以自动继续，哪些必须标记差异并等待人类决定。
七、结语：真正可复制的不是 Prompt，而是闭环
Anthropic 营销运营团队的案例，最容易被模仿的是几个技能名称，最不该被忽略的却是它们之间的关系：
- 用连接器把 Agent 放进真实工作环境；
- 用技能封装稳定职责；
- 用定时任务消除人工启动；
- 用独立审计证明结果正确；
- 用人工决策处理叙事、冲突和发布；
- 用复盘把新经验写回技能。
这六步连起来，才是一条会工作的自动化流水线。只拿其中一个环节——比如写一个很长的 Prompt——很难得到同样结果。
Ian 从“每周追数据的人”变成了指标口径、验证机制和团队自助能力的建设者；Annabel 从“逐个平台搭活动的人”变成了 Campaign 流程、质量标准和技能体系的设计者。Claude Cowork 接管的不是岗位，而是岗位里最机械、最容易标准化的部分。
因此，这个案例最值得带走的结论不是“AI 能把两天变两小时”，而是：
当执行、验证和学习都被写进系统，自动化才不再是一次演示，而会成为组织能力。
「真诚赞赏，手留余香」
爱折腾的工程师
真诚赞赏，手留余香
使用微信扫描二维码完成支付
