Vibe Marketing：Solo Founder 如何成为营销工程师

开发工具2026-09-15约 16 分钟Vibe MarketingMarketing EngineerAI AgentAgent HarnessADE营销工作流Solo Founder

很多人都在讨论 Vibe Coding：让 AI 帮你写代码、搭产品、修 Bug。但对于 Solo Founder 和 Vibe Coder 来说，产品做出来只是开始。没有调研、定位、内容、分发、转化和复盘，代码很容易变成一个没人知道、也没人愿意使用的产品。

Shann³ 在 X 发布的《How to Become a Marketing Engineer》提出了一个很值得重视的方向：Vibe Marketing 不是让 Agent 随便生成几篇营销文案，而是把知识、数据、工具、工作流和人工判断连接成一个可以持续运行的营销系统。

本文根据 Su 转发并附带中文全文的 X 帖子整理改写。原帖发布于 2026 年 9 月 14 日，原作者是 Shann³（@shannholmberg）。文中对 Orca、Hermes、Typefully、Paper、Figma、Slack 和其他工具的描述，属于原作者的工作实践；后文的 GPT88 接入方式、验收标准和工程边界，是本文基于原文补充的通用建议。

先看结论：营销也需要 Harness

一个可复用的营销系统，大致应当这样运转：

共享知识 + 外部调研 + 活动数据
          ↓
      活动简报
          ↓
   工作流与专业 Agent
          ↓
       草稿与资产
          ↓
     自动检查 + 人工审核
          ↓
        批准后发布
          ↓
     结果回写与下一轮学习

其中最重要的不是“用了多少 Agent”，而是有没有把以下问题写清楚：

Agent 可以读取哪些知识和数据？
哪些来源值得信任，哪些内容只是待验证的假设？
产出保存在哪里，谁负责审核？
哪些动作可以自动执行，哪些动作必须由人批准？
表现数据如何回到下一次活动的上下文？
当输入缺失、数据过期或检查失败时，系统如何停止并求助？

这也是 Vibe Marketing 与普通 AI 文案生成的区别。前者关注可复用的生产系统，后者通常只关注一次输出。

一、什么是 Marketing Engineer？

营销工程师使用 Agent、相互连接的数据和业务上下文，搭建能够真正完成营销工作的系统。它不是传统营销岗位的简单改名，也不是只会写脚本的工程师，而是把多个能力组合起来：

能力来源	对系统搭建的帮助
产品营销	提供客户、定位、产品方案和价值主张
内容与创意	定义语气、提供案例并审核内容资产
增长与效果营销	围绕营销实验和可衡量结果设计流程
营销运营与自动化	连接工具，定义任务如何在环节之间流转
数据分析	提供可靠数据，并检查 Agent 对数据的解释
工程	连接 API，编写代码并测试工作流

你不必一开始就覆盖所有职能。原文给出的建议是从自己最熟悉的一项工作开始：如果你擅长内容，就先做内容工作流；如果你熟悉 SEO，就先做关键词调研和文章简报；如果你经常投放广告，就先做历史活动复盘和下一轮创意规划。

专业经验在这里不是可有可无的背景，而是系统的判断标准。你越清楚什么叫“相关”“可信”“可发布”和“有效”，Agent 越容易得到可执行的约束。

二、模型、Harness 与 ADE 的职责边界

原文把营销工作放进 Agent Development Environment，简称 ADE。作者提到，大约 70% 的营销工作在智能体开发环境中完成，包括调研、活动规划、制作内容资产、运行子智能体和审核结果。

理解 ADE 之前，先区分三个概念：

概念	含义	主要职责
模型	为任务选择的 AI	理解上下文、提出计划、生成分析和草稿
Harness	包裹在模型外的软件层	提供文件、工具、代码环境、权限和执行控制
ADE	与 Agent 协作的开发环境	运行任务、查看过程、审核动作和保存产出

模型本身并不知道你的产品定位是否已经批准，也不知道某条客户信息是否是最新事实。Harness 负责给它受控的文件、工具和执行环境；ADE 则提供一个可以观察、修改和恢复工作的空间。

这对 Solo Founder 很重要：不要把一个聊天窗口当成完整的营销系统。聊天里的上下文容易丢失，临时指令无法复用，历史反馈也很难进入下一次运行。营销工作需要留下简报、调研、草稿、审核意见、发布记录和结果数据。

三、先搭知识层，再让 Agent 生成内容

一条营销工作流至少需要两类上下文：内部知识和外部知识。

内部知识	外部知识
产品细节、产品方案和定位	竞品、竞品方案和营销活动
客户访谈、CRM 记录和客服对话	公开讨论、评价和客户问题
你的专业经验、案例和规划输入	行业研究、市场动态和搜索需求
历史活动、数据仓库记录和结果	关键词、内容趋势和渠道变化

内部知识告诉 Agent“我们是谁、服务谁、能承诺什么”；外部知识告诉 Agent“市场正在发生什么、用户如何表达问题、竞品怎么回应”。只有把两者连接起来，Agent 才能提出与业务有关的营销角度。

一个最小的目录可以从这里开始：

marketing/
├── shared-knowledge/
│   ├── audience.md
│   ├── product-and-offer.md
│   └── positioning.md
└── content/
    ├── knowledge/
    ├── work/
    ├── workflows/
    ├── skills/
    ├── agents/
    ├── outputs/
    └── results-and-learnings/

不要因为目录看起来完整，就先把所有文件都填满。第一条工作流只需要建立它真正依赖的上下文。例如，付费广告简报可能只需要 audience.md、approved-claims.md、活动简报和历史测试结果。

目录名也不等于工作规则。还要添加一份简短的 Markdown 说明：资料在哪里、哪些来源优先、发现保存到哪里、哪些主张需要标记为假设、在什么情况下必须停下来询问。

知识必须有来源和状态

营销知识不能只有一句“我们发现用户喜欢快速部署”。更好的记录方式是：

结论：目标用户重视快速部署。
来源：2026-09-10 客户访谈，访谈记录链接。
适用范围：早期 SaaS 团队，尚未验证企业客户。
状态：已审核，可用于内容简报；不可作为广告绝对承诺。

这能帮助 Agent 区分已批准的定位、一次会议中的临时意见、外部调研中的推断和仍然需要验证的假设。

四、营销数据层：不要让 Agent 凭感觉复盘

当 Agent 需要规划下一轮广告或内容时，它应该知道上一轮发生了什么：哪些素材带来访客，哪些访客完成转化，哪些线索最终变成客户。

这些数据通常分散在不同系统里：

来源	可以提供什么
广告平台	活动、广告、花费、展示和点击
网站分析	访问、落地页行为和被追踪的转化
CRM	线索质量、销售结果和营收
实验记录	测试过的受众、产品方案和创意角度

数据仓库不必一开始就很复杂。一个小型数据库或结构化 CSV 也可以作为起点，前提是记录之间存在稳定的关联：

Campaign ID 标识具体营销活动；
Ad ID 或内容 ID 标识具体资产；
追踪参数帮助连接网站访问和渠道；
CRM 中保留来源与活动字段；
实验记录写清楚本次测试的受众、主张和结果。

只有 API 连接，并不会让数据自动保持更新。脚本或集成需要定期抓取新记录、刷新已有记录，并在失败时明确报错。报告工作流不能在数据更新失败后悄悄使用上周的数据，再写出语气确定的结论。

还要保留归因不完整的状态。如果追踪参数缺失、跨设备行为无法连接，或者销售结果没有回传，就应标记为“无法确认”，不能自信地把每一笔收入归因给某条广告。

五、第一条工作流：从一个具体任务开始

原文建议先选择一项你经常做、足够熟悉、也能够判断结果好坏的任务。一个好的起点不是“自动化整个营销部门”，而是：

把客户研究、产品方案和历史活动结果整理成下一轮付费广告的创意简报。

它有明确的输入、输出和审核点，但还没有直接修改预算或发布广告，风险相对可控。

1. 先规划，再运行

可以先用语音转写或普通文字写下 5 到 10 分钟的背景：目标是什么、已经试过什么、哪里不确定、谁是目标客户、哪些结果不满意。规划阶段的价值，就是把这些零散信息整理成可执行的 Brief。

2. 把目标写成可验收的指令

例如：

/goal 准备下一轮付费广告的创意简报。

使用 audience.md、approved-claims.md、campaign-book/
和 previous-test-results.md 作为上下文。

调研并提出 3 个创意角度。说明每个角度面向谁、依据是什么，
以及它与历史测试有什么不同。链接支撑来源，并标记假设。

根据受众与 approved-claims.md 检查每个角度。
把简报保存到当前活动文件夹的 creative-brief.md。

当简报可以交给我审核时停止。不要制作或发布广告。
缺少必要上下文时先询问。

这段指令明确了输入、交付物、检查方法和停止条件。它没有要求 Agent 自己决定预算，也没有把“生成广告”与“发布广告”混为一个动作。

3. 在人的参与下运行第一版

第一轮不要追求完全自治。重点是观察 Agent 在哪里需要你的输入：

现象	应排查什么
调研覆盖了不相关的公司	筛选标准和调研指令是否过宽
建议漏掉重要客户异议	当前可用的客户上下文是否缺失
报告使用旧数据	数据更新和新鲜度检查是否可靠
产出看起来正确但没有用途	Brief 和“好结果”的定义是否清楚

修复这些问题后，再把工作流用于下一场活动。只有当它脱离上一轮对话里的临时提示也能工作，才算真正可复用。

六、让营销活动成为一个可追踪的系统

一场完整的产品发布可能同时需要落地页、付费创意、社交内容、邮件序列和外联。每个职能可以有自己的工作流，但必须共享同一套产品方案、受众和发布计划。

campaign/
├── brief.md              # 受众、产品方案和目标
├── campaign-book/        # 已批准的视觉方向
├── research/             # 跨渠道共享调研
├── tickets/              # 任务与依赖关系
├── landing-page/
├── paid/
├── email/
└── results/              # 为下一次活动提供依据

把工作拆成工单，可以让协调 Agent 识别哪些任务已经就绪、哪些任务在等待输入、哪些资产需要重新检查。例如：

工单	依赖	状态
批准活动产品方案	客户与竞品调研	需要我的输入
搭建落地页	已批准的产品方案与 campaign book	等待中
制作付费创意	已批准的产品方案与 campaign book	等待中
检查广告与页面一致性	落地页与付费创意	等待中

工单还应该写清楚负责人、交付物、检查项和产出链接。这样 Agent 不是在一个巨大上下文里“继续努力”，而是在一项有边界的任务上推进。

七、循环、审核与人工批准

当工作流已有明确步骤和检查标准，就可以让 Agent 在有限预算内循环执行：制作、检查、修复、再次检查。

领取就绪工单
      ↓
制作或修改
      ↓
运行检查
  ├── 未通过 → 写明修改项 → 在重试额度内继续
  ├── 受阻或达到额度 → 请求人工输入
  └── 通过 → 标记为可以审核

检查可以分为两类：

适合自动化的检查：文件是否缺失、尺寸是否正确、链接是否有效、日期是否冲突、主张是否出现在批准清单中。
需要人工判断的检查：创意方向是否合适、是否真的理解客户、承诺是否过强、品牌语气是否准确、多个渠道是否互相矛盾。

“通过检查”不等于“可以自动发布”。广告可能在格式上完全正确，却把落地页无法提供的结果写成了承诺。落地页、广告和邮件也可能各自通过检查，却使用了不同的产品方案。

因此，高风险动作应拆成不同权限：

准备报告       → 可以自动执行
创建内容草稿   → 可以自动执行或低风险审批
修改广告预算   → 需要明确批准
公开发布内容   → 必须人工批准

这条边界同样适用于 GPT88 接入的 Agent。API 能调用工具，不代表工具就应该拥有发布权限；模型能生成 JSON，也不代表 JSON 可以直接写入外部系统。

八、定时任务和自治机器人应该最后接入

有些任务适合定期运行：每日刷新活动数据、每周复盘竞品、准备效果报告、检查排期内容的日期和链接。但定时任务不能拯救一条尚未跑通的工作流。

正确顺序是：

手动运行
  → 在参与下运行
  → 保存为可复用工作流
  → 加入失败和新鲜度检查
  → 设置定时任务
  → 再考虑交给团队机器人

自治机器人可以拥有自己的指令、工具和上下文权限，也可以响应 Slack 消息或按时间表运行。但它仍然应该返回：

保存后的报告或简报链接；
使用了哪些来源和数据日期；
哪些结论是事实，哪些是推断；
哪些任务已经完成，哪些被阻塞；
哪些问题需要人做决定。

机器人越自治，越需要清晰的停止条件和权限边界。不要把“每周自动完成营销”当成目标；应当把它拆成一组可验证的任务，例如“每周一收集指定竞品页面变化，生成带来源链接的摘要，数据抓取失败时报告错误，不修改公开内容”。

九、适合搭建的 Vibe Marketing 工作流

可以从以下任务中选择一项开始：

工作流	基本流程
竞品网站监控	定时收集页面 → 检测变化 → 解释变化 → 生成带来源简报
竞品创意素材库	收集广告 → 转写或分析 → 保存参考资料 → 服务下一轮创意规划
播客转团队内容	收集转写 → 提取洞察 → 结合团队经验 → 起草内容供审核
SEO 内容生产	调研关键词与竞品 → 确定角度 → 生成文章 → 运行文字和视觉检查
付费广告创意测试	复盘历史结果 → 提出角度 → 制作素材 → 批准上线 → 回写结果
内容再利用	获取已批准文章或访谈 → 选择观点 → 制作多渠道版本 → 审核排期
邮件活动制作	整合产品与受众 → 规划序列 → 起草文案 → 检查链接和规则
落地页制作与测试	整合活动简报和客户异议 → 搭建页面 → 检查表单与追踪

选择标准很简单：你已经在做、结果可以判断、输入能够拿到、失败后不会直接造成不可逆损失。

十、GPT88 落地时的工程检查清单

如果把这套方法接到 GPT88 或其他兼容 API，建议按下面的顺序验收：

输入和来源

是否明确列出 Agent 可以读取的文件、数据和外部来源？
是否记录来源链接、抓取时间和数据新鲜度？
是否把内部批准知识与外部未验证内容分开？
是否明确要求 Agent 区分事实、推断和建议？

工作流和产出

是否有明确的输入、输出、保存位置和停止条件？
是否保留简报、调研、草稿、检查报告和最终反馈？
是否可以从上一轮结果中恢复，而不是依赖一段聊天历史？
是否为缺失上下文、旧数据和工具失败定义了阻塞状态？

权限和副作用

读取调研、创建草稿和公开发布是否使用不同权限？
Agent 是否只能操作当前活动或当前用户授权的对象？
写操作是否有参数校验、幂等保护和人工批准？
API Key 是否只放在环境变量或服务端密钥管理中，而不是 Prompt、Brief 或知识文件中？

结果和学习

是否能把活动 ID、内容 ID、网站行为和 CRM 结果关联起来？
归因缺失时是否明确标记，而不是编造完整结论？
是否保存你的审核理由，而不仅是“改好了”？
哪些经过审核的发现可以进入共享知识，哪些只能留在当前活动？

结语：从一个真实任务开始

Vibe Marketing 的核心不是让 Agent 替你完成所有营销工作，而是把你已经知道如何判断的一项任务，整理成一条可以反复运行、检查和改进的工作流。

最短路径通常只有六步：

选择一个真实任务
  → 写清输入和完成标准
  → 补齐最小上下文
  → 在你的参与下运行
  → 保存问题、反馈和结果
  → 再连接下一条工作流

当调研能进入简报，简报能进入制作，制作结果能经过检查，活动数据又能回到下一次规划时，你搭建的就不再是一次性的 Prompt，而是一套营销工程系统。

原文最后的提醒值得保留：不需要先把整篇文章中的所有环节都搭好。先从手头的一项工作开始，打开一个你和 Agent 都能使用的工作区，留下第一条真正有用的工作流。