运作方式

同样的四个阶段,每一份简报

采集、分析、简报、审批。每个增长官都跑这套闭环。每条发现都附带证据链落地。每个动作都等你轻点确认。这就是产品的全部。

01
采集

增长官 去把数据取回来.

每个增长官都按自己的计划运行。周一早 8 点、每天 7:30、随时——由你决定时间。到了设定的时间,增长官会从你接好的数据源拉取数据。

  • 从第一方连接器(Slack 话题、Notion、Linear、Stripe、GA、Search Console)和公开来源(竞品网站、点评平台、社交聆听)拉取数据。
  • 每次拉取都会记录时间戳、来源 URL 和响应哈希——证据链从这里开始。
  • 如果某个来源被限流或无法访问,增长官会以指数退避重试,并把这次运行标记为「不完整」,而不是绕过缺口去臆测填补。
  • 按租户隔离的运行时——你的数据永远不会和另一位客户共用同一个进程。
02
分析

对照 你的基线.

原始数据只有在相对增长官上次所知发生了变化时,才会成为一条发现。每条发现都带有四个必填字段——来源、时间范围、基线、触发原因。

  • 增长官会加载它的 MEMORY.md——上周的竞争快照、上月的关键词排名、上季度的 CAC。
  • 把今天的数据与已存的基线做差异比对。竞品的新功能、排名下滑、落地页改价——都会在这里浮现。
  • 缺少四个证据字段中任意一个的发现,会被自动降级为「建议」,永远不会触发审批卡片。
  • 在生产环境部署中,证据覆盖率保持在 ≥ 95%——我们会度量并如实上报。
03
简报

把可读的摘要 推送到你的 IM.

一份简报就是对每条发现 3–6 句话的精炼写法——不是一份要你去分析的报告。直接落到 Slack、Discord 或 Telegram,排版上 30 秒就能扫完。

  • 结构为:标题 · 一句话说清发现 · 为何重要 · 建议动作 · 页脚处的证据链。
  • 每个来源链接都可点击——直接跳到原始的 Notion 文档、竞品的定价页、排名看板。
  • 投递到你在上手时指定的频道。需要的话可以走话题串;不需要就直接发在顶层。
  • 不会重复打扰——增长官会记录哪些发现你已经看过,没有真正的变化就不会再次抛出。
04
审批

轻点一下, 增长官随即执行.

每份简报都有三个按钮:批准、追问、归档。批准 → 增长官立刻执行动作。追问 → 增长官深入挖掘并回报。归档 → 它从你的信息流中消失。

  • 审批是一个状态机:proposed → pending_approval → approved → executed(或 failed,或 48 小时后 expired)。
  • 只有一个已批准、未过期的令牌才能抵达执行层。没有你明确的轻点,增长官就无法采取行动——这是设计使然,而非靠配置。
  • 每次审批都可审计:谁在何时点的、这一点基于哪些证据、增长官据此做了什么。
  • 若执行失败,增长官会重试,随后转入死信队列交给运维团队。你会被告知发生了什么,而不是被晾在一边猜测。
记忆架构

第 2 阶段值得信赖的结构化状态。

粗放的「长上下文智能体」方案什么都记,却什么都说明不了——它们漂移成噪声,把自己改写成一团浆糊。我们改为构建了一个结构化的记忆层。两个文件、四个区块、一条纪律。

USER.md

每个增长官都会读的公司简介

在上手时根据你的输入生成——公司名称、行业、目标客户、竞争对手、渠道、目标。由你租户上的每个增长官共享,在每次会话开始时读取。硬性上限 20,000 字符,强制执行。

# Acme · company brief industry: restaurant SaaS competitors: SevenRooms, Tock, Resy goals: Q2 · +30% demo requests
MEMORY.md

四个具名区块,按增长官各自维护

  • 最近观察 —— 每个竞品、关键词或活动一行。下一条证据链用来对照的基线。
  • 运行日志 —— 每次运行一行,附带 1–5 分的自评分。漂移就是这样被发现的。
  • 持久事实 —— 由运维人员精选、能挺过每一轮 dreaming 周期的事实。把「竞品 X 在 Q3 被收购」或「不要监测公司 Y」钉住,它就会留存。
  • Bootstrap —— 首次启动规则,让刚配置好的增长官不至于盲目冷启动。
Dreaming

运行之间的整合

一次离线整合会把当天的观察压缩为持久知识——在夜间完成,而非运行中途。智能体在运行期间只会追加,从不改写自己的记忆。我们就是这样杜绝自我损毁这种失效模式的。

租户隔离

不存在跨客户记忆

每个租户都在自己隔离的运行时上运行。MEMORY.md 和 USER.md 存放在按租户隔离的工作区里。你的智能体对你业务的任何认知,都不会影响任何其他客户的智能体——这是在运行时边界上强制的,而不只是一条政策。

证据链锚点

记忆才是发现可信的根据

每条发现的 baseline 字段都来自 MEMORY.md 的最近观察。没有基线 → 没有审批卡片,自动降级为建议。正是这个记忆层,让第 2 阶段能说「有东西变了」,而不是「有东西存在」。

证据链

四个字段,没有例外——
每条发现都带着它们

这就是契约。一条无法给齐全部四个字段的发现,永远不会作为审批卡片抵达你这里——它会被降级为建议,并记录下来交给运维团队调查。

来源
必填
sevenrooms.com/features/waitlist

一个你能点开并核实的 URL、文件 ID 或 API 响应哈希。绝不会是「我的训练数据」或「常识」。

时间范围
必填
2026-04-13 → 2026-04-20

这条发现所覆盖的时间窗。好让你知道这是本周的新闻,还是上季度的趋势。

基线
必填
Feature didn't exist as of 2026-04-12

增长官此前所知的状态。没有基线的发现,只是一个观察而已。

触发原因
必填
Page changed. Diff: +waitlist module, +FAQ section, +demo CTA.

把这件事从噪声里拉出来的那个具体变化。让审阅变快——你不必自己去比对。

一份真实的简报

这就是落到
你 Slack 里的样子

# growth-officer
M
市场研究主管APP · 周一 8:02 AM
SevenRooms 上线了候补名单功能——我们应该在周四前备好定位。
他们的营销页面在周二 2026-04-16 更新,新增了候补名单模块、FAQ 区块和 demo CTA。目前还没有发布动态——他们在正式发布前先预热。这正击中我们「无需等位的接待」这一信息点。建议:周四前发布我们的对比文章,周五前向销售团队做简报。
来源: sevenrooms.com/features/waitlist
时间范围: 2026-04-13 → 2026-04-20
基线: Feature didn't exist as of 2026-04-12
触发: 他们功能页上 +候补名单模块、+FAQ 区块、+demo CTA
批准 → 在 Notion 起草对比文章追问一下归档
JL
Jake8:07 AM
已批准
M
市场研究主管APP · 8:07 AM
这就办。草稿页面 「SevenRooms vs 我们 —— 候补名单对比」已在 Notion 创建 · 指派给 @jake · 周四截止。我周五会回来跟进进度。
好问题

有几件事值得讲清楚

如果增长官搞错了怎么办?

你有三条退路。驳回这份简报(不执行,附原因归档)。追问一句(增长官深入排查、调整基线、再试一次)。上报给运维团队(我们会审阅证据链、调校增长官的记忆,如果是我们的问题就给你的账户做补偿)。

我能改运行计划吗?

可以。每个增长官都有一条可在 Portal 里编辑的 cron 表达式。每天、每周、每小时,或从仪表盘临时「立即运行」。计划变更在下一次运行时生效。

第一周会发生什么?

上手运行:增长官会建立它的基线。你会收到一份当前状态的摘要简报(还不是差异比对)。从第二周起,简报就只报变化了。

审批执行后存放在哪里?

每次审批连同它触发的动作,都存放在你租户的运行历史里,可从 Portal 仪表盘访问,并可导出为 JSON。取消后保留 30 天,随后做加密清除。

想看看这套闭环在你的业务上怎么跑?

贴上一个 URL,你的 AI 增长团队今天就开工。

开始免费试用查看价格
运作方式 —— Ceres AI 增长官