← Grok Bot 实战案例总览 · 成果库

官方 guide《Grok Bot for Marketing》专题(Josh Kim):六个营销 Bot 从调研到广告、网页 PR 的完整闭环

六个各有职位描述的 Bot,在 Google Docs、Google Ads、网站仓库和浏览器里接力,营销负责人只留下判断。没有可复制的提示词。

说明:本专题于 2026-10-17 根据公开资料整理,没有编造内容:提示词、步骤和数字都来自下方列出的来源;整理者的推断用“推”标签标出,没能访问或没法核实的放在最后一节。数字多为作者自述,未经验证。
引逐字引用或忠实转述原文 推整理者推断
19

官方 guide《Grok Bot for Marketing》专题(Josh Kim):六个营销 Bot 从调研到广告、网页 PR 的完整闭环

来源类型:x.ai 官方 guide(作者 Josh Kim,2026-09-24);页面为静态文本,已完整读取

引作者说他过去把营销 AI 当成“永远没离开聊天窗口的聪明实习生”,现在是在编排一小队 Grok Bot:“它们起草、交接、开 PR、搭广告壳,我保留判断。”他认为营销启动很少活在一个人脑子里:研究、定位、网页、付费、分析通常是不同的人,最难的是跨岗位推进而不丢上下文。

须知:这篇 guide 没有任何可复制的提示词,也没有真实效果数字——它用的是一个虚构航空公司 “X-Air” 的示例(原文明说 fictional)。

本专题目录

19.1

六个 Bot 和各自的职位描述

“每个都有职位描述,这就是重点”

Bot职责(原文转述)
Market Researcher研究产品页和竞品,指出空白,写策略性解读
Product Marketer把研究变成定位简报、落地页大纲和搜索广告变体,写在 Google Docs 里
Performance Marketer搭 Google Ads 广告系列“壳”,把批准的文案铺进去
Website Ops拿着落地页大纲,在后台用 Cursor 写页面,并在营销网站仓库开 PR
Marketing Analyst拉 Google Ads 数据,写成记分板,建议扩大、砍掉还是继续测试;不修改线上广告、出价或预算
Project Manager研究其他 Bot,跑交接,是作者唯一的对话线程,免得他自己去调度五个专职 Bot 的聊天

引作者的理由:一个通才聊天要在同一线程里做研究、广告和代码,会膨胀并忘记当初雇它做什么。

来源

19.2

X-Air 示例:从调研到定位简报

虚构航空公司,作者用它演示完整闭环

  • 引Market Researcher:指向 X-Air 网站和一组竞品,它自己开浏览器读页面,回来给出具体的空白:“强调空中的有用时间,而不是为奢华而奢华”。
  • 引Product Marketer:被提出下一个要求后,它在后台给 Market Researcher 发消息要上下文,然后在 Google Docs 里写定位简报:一句话定位、价值陈述、以及这个想法如何出现在几个触点上。
  • 引作者像审同事草稿一样审这份 Doc:在一行有效的话上留评论,让 Bot 顺着这个方向走;下一轮 Bot 更新简报、列出落地页大纲,并起草用于信息测试的 Google 搜索广告变体。
  • 引作者说:在 Docs 里留反馈,Bot 修改,他仍然掌握判断层;起初要明确让一个 Bot 去和另一个 Bot 说话,“它告诉我在做什么,然后去做”。

来源

19.3

网页 PR、广告壳、记分板

Bot 在作者用的同一批工具里干活

  • 引Performance Marketer:拿批准的文案,在已接入的 Ads 账户里搭以点击为目标的信息测试广告壳——“是真实的结构,不是我以后还得重建的模拟表格”。
  • 引Website Ops:拿落地页大纲,用 Cursor 写页面,通过 GitHub 在营销网站开 PR;过程中他收到截图;合并后他直接打开线上页面。
  • 引Marketing Analyst:之后拉最近的信息实验数据,按概念给出记分板:花费、CTR、CVR、CPA、ROAS,外加一段简短建议。扩大、砍掉、测试还是再看,决定权在他;“Bot 建议,我批准花钱的事”。
  • 引这些 Bot 用的是同一批工具:Google Docs、Google Ads、网站仓库,以及需要读线上网站时的浏览器;它们互相发消息要上下文,所以作者不用把研究从一个聊天粘到另一个。

来源

19.4

“交接税”、Project Manager、模板、权限与记忆

作者的做法与时机判断

  • 引交接税:手动跑闭环可行,但在专职 Bot 间搬上下文、查看五个线程要付出代价;Project Manager 就是吃掉这笔税的。它学习各专职席位、推动交接,把截图和阻塞点呈现给作者。只有一个专职 Bot 时他不会急着加 Project Manager,交接真多了才要一个“前门”。
  • 引Share as Template:席位稳定后,用它做快照,是“一份食谱,不是一顿饭”——不带电脑、登录和聊天历史;别人得到的是你注入的操作风格,其余需要自己连接。
  • 引权限从小开始:先给文档改写和 Slack 草稿回复,再谈广告写权限或生产权限;“信任来自交付的工作,而不是第一天就把公司信用卡交出去”。
  • 引固定角色让记忆累积;短期项目就把合适的 Bot 拉进一个群聊,而不是每次活动都发明新人设——“席位不变,活动在变”。

总结与建议

引作者说最大的变化是“心理负担”:Bot 在 Docs、Ads、Slack 和网站仓库里把活干完;离开大楼的东西和进入线上账户的东西仍由他批准。他的建议:为一件事建一个专职 Bot;只连这件事需要的工具;席位稳定后做模板;等交接开始痛了再加 Project Manager。

来源

其他专题

↑