返回博客

从 SDR 到独立 GTM 工程师

·1 分钟阅读·methodology

四周前,我开始认真使用 Claude Code。

不是大多数人用 AI 的方式 - 让它写封邮件、修个函数、解释一段代码。我说的是每天在一台 Mac Mini 上同时跑 4 到 6 个终端会话,从一个一个月前还不存在的 monorepo 里构建全栈系统。

在这段时间里,我交付了四个网站,构建了一整套可复用的技能文件,创造了一个能用我真实语气生成内容的语音系统,搭建了一个追踪 AI 智能体进化过程中经验值的成长引擎,并把整套方法论开源了。

全部在一个 monorepo 里。一台机器。一个没有 API 限制的 Claude Code Max 订阅。

我以前是 SDR。每天从主域名发 200 多封冷邮件,没有预热,用的是 SalesLoft。在 Salesforce 里手动搭建采购委员会。从最基层的实战中学习 GTM。工具不同了,但直觉是一样的 - 找到系统,持续运转直到产出复利。

正是这种直觉让过去四周的一切得以成立。

这个方法不是计划出来的

大概第二周的时候,有什么东西变了。我不再只是用 AI 来加速构建。我在摸索人类和智能体协作的模式。什么时候让 Claude 在完整上下文下自主运行。什么时候停下来质疑它刚才构建的东西。什么时候并行规划,什么时候顺序构建。

我开始把这些模式写下来。不是因为我想创造一套方法论。是因为我一直记不住哪些方法有效,需要笔记来指导下一次会话。

然后我发现笔记本身正在变成系统。文档在记录自身。关于我如何构建的内容正在反馈到我的构建方式中。一篇关于内容工作流的文章变成了自动化内容工作流的技能文件。一篇关于上下文交接的记录变成了每个会话都在使用的上下文交接协议。

那时我意识到这是一种方法。我把它叫做递归漂移(Recursive Drift)。

六个状态,没有固定顺序

递归漂移有六种模式,你在它们之间切换。工作本身决定顺序,而不是某个剧本。

自由落体(Freefall)。 无结构地探索。让不同领域的想法碰撞。GTM 方案挨着像素精灵,旁边是新闻稿草稿。这种混乱产生原始素材,其他所有状态来提炼它。我最好的技能文件大多源于自由落体中的随手记录。

规划(Plan)。 把混乱结晶为并行轨道。不是一个计划。是多个计划并行运行,标记好依赖关系。关键点 - 计划在执行过程中自我改写。我最初把三个网站的发布规划成独立仓库。构建到一半我意识到需要用 Turborepo 做 monorepo。目标不变,架构重组。计划的失败就是计划下一版本的输入。

构建(Build)。 带着完整上下文去委派,然后让开。上下文是关键差异。在写一行代码之前,技能文件、语音手册、之前会话的产出、合作伙伴调研全部加载就绪。我有 42 个可调用的技能。/playdraft 截一张图就能生成 LinkedIn 和 X 的草稿。/substackpost 给一个主题就能产出一篇 newsletter。构建能跑起来,是因为上下文已经准备好了。

暂停(Break)。 在流程中停下来。质疑假设。调转方向。暂停是大多数人跳过的状态,但它防止了最多的无用功。当一个本该一小时完成的构建做了三小时还感觉不对,那就是暂停在告诉你计划已经过时了。我在暂停中推翻过整个方案,回来后用一半的时间做出了更干净的东西。

追问(Ask)。 审视系统。让 AI 审视自身。让计划审视计划。当我在网站上构建 /arc 页面时,我直接让 Claude 通过检查自己的技能文件和会话模式来描述这套方法论。这个页面通过审视递归漂移来解释递归漂移。

播种(Seed)。 为未来的循环埋下线索。在当前内容中留下一两句话,指向未来的工作。它们产生牵引力。当完整的内容后来上线时,那些种子让它感觉像是水到渠成而不是突然冒出来的。

并发会话问题

有人问我如何在 4 到 6 个并发的 Claude Code 会话之间管理记忆和护栏,而不让它们互相踩踏。

答案在这四周里逐步进化。

最初我只有一个上下文交接文件。每个会话写入自己的状态,下一个会话接着读。当我开始跑并行会话时,这立刻崩了。会话 3 会覆盖会话 2 的交接。

于是我构建了一个并行安全的交接系统。每个会话写入交接目录中的一个带时间戳的文件。2026-03-08_143022_voice-system-refactor.md。没有共享文件。没有覆盖。当新会话启动时,它读取所有未消费的交接,吸收上下文,然后标记为已完成。

听起来简单,因为它确实简单。最好的模式通常都是这样。但如果没有先把朴素方案搞崩,我不会找到它。

护栏也来自同样的迭代过程。lessons.md 记录每一个错误。CLAUDE.md 设定编排规则。技能文件编码特定领域的上下文。到第四周,新会话启动时就比我第一周结束时的会话更聪明了,因为积累的上下文已经预加载了。

真正在复利的是什么

第 42 个技能文件比第 1 个更容易写。不是因为我写技能文件的能力提升了。是因为 41 个技能文件积累的模式、语音规则和工作流模板已经作为上下文存在了。系统变得更密集,但没有变得更沉重。

内容也一样。语音系统起初只是一个偏好文件。现在它有三个层级 - 核心语音 DNA、平台专属手册和运营规则。当我生成一篇 LinkedIn 帖子时,它加载我的语音,对照 29 条反套话模式检查,验证实质性要求,并执行平台专属格式化。产出听起来像我,因为系统研究过我听起来是什么样的。

网站也一样。四个网站通过 monorepo 共享组件。对共享 UI 库的一次修改同时更新四个网站。一篇新博客文章构建到所有承载该内容类型的网站。基础设施是我的,跑在我的机器上,每次提交都在复利。

为什么我把它开源了

这个仓库没有精心打磨。方法文档直接来自我的工作笔记。模板有些粗糙的边角。

我还是推了上去,因为能从中获益的人是那些已经深入 AI 工具并且想要模式而不是精致包装的构建者。是试图以小博大的独立运营者或小团队。是那些从实战中学会了苦功、现在想构建替代它的系统的前 SDR。

方法论层不花一分钱。读六页关于状态和递归属性的内容。花 20 分钟。可能会改变你用 AI 构建的思维方式。

模板层花 5 分钟。把 CLAUDE.md 复制到你的项目根目录,添加 tasks/todo.md 和 tasks/lessons.md,你就有了编排规则和自我改进循环。

深度玩法是构建你自己的智能体,带个性、进化层级和自我阅读反馈循环。那需要一个下午和一个 Claude Code Max 订阅。

一切都运行在 CLI 上。核心功能不需要 API 密钥。你用来写代码的工具就是驱动智能体的工具。

核心原则

如果一个系统无法描述自身,它就不够通用。

这篇文章就是用它所描述的方法写成的。语音系统加载了我的模式。技能文件构建了工作流。反套话规则过滤了 AI 生成的废话。关于系统的内容变成了系统的一部分。

循环明天继续。

Recursive Drift on GitHub

ShawnOS.ai|theGTMOS.ai|theContentOS.ai
built with Next.js · Tailwind · Claude · Remotion