构建软件即服务交付体系

# 如何构建软件即服务交付栈

我现在终端里同时打开着 15 个客户文件夹。打开第 15 个的成本和打开第 2 个差不多，这一个事实，正是软件即服务公司与一家花钱订阅 Claude 的代理机构之间的全部区别。

这套模式的前半段人人都听过：你按结果定价而非按小时收费，声称软件承担工作，客户签约。这部分很简单，这也是为什么这一模式传播得如此之快。

后半段才是问题所在，而且它从不会大张旗鼓地崩塌。

它的表现是：一位 GTM 工程师在启动四个月后才在 Slack 里问某个客户的 ICP 是什么。或者一个评分模型因为好版本存在另一个账户、没人记得是哪个，只能凭记忆重建。到第 3 个客户时，你已经在手工重建为第 1 个客户手工搭建过的东西，以软件的价格收费，同时又在招人——重新回到了你本想离开的那种业务模式。

所以，检验标准如下：打开第 15 个客户文件夹和打开第 2 个，成本大致相同，就意味着软件真的在承担交付工作。成本更高，你就是在经营一家代理机构，只是故事更难讲。

在 Frontal，我们服务过 275 家公司，每次都是同样的结论：公司买了工具，却无法让工具运转起来。下面这 6 套系统，正是让第 15 个文件夹保持低成本的关键。从第 2 个客户开始就值得搭建，到第 15 个客户时，没有它们就没有这门生意。

读完本文，你将了解：

1. 那 1 个文件，能让人在几分钟内接管一个客户账户，而不必问 3 个人 ICP 是什么

1. 哪些内容需要按客户隔离，哪些可以跨客户共享，以及为什么跨客户污染是最难发现的 bug

1. 值得一次性写好的流程，包括那个能减少约 80% 手工筛选量的评分模型

1. 仍然需要人工介入的 4 项工作，以及 1 个永远不应该放进文件夹的工作流

这一切都不需要开发者。但确实需要你自己的 API 密钥，而且每次新构建的第一次运行都会出问题。这是诚实的边界，其余内容均可照原样复制使用。

关于顺序的说明：每个系统都标有一个客户编号，大致表示没有它开始让你付出真实工时的节点。按顺序搭建，你就能在恰好需要之前为每个系统付出代价。

# 1. 文件夹边界

从第 2 个客户开始产生成本。

每个客户一个文件夹。独立的上下文、独立的 API 密钥、独立的历史记录。除非我主动迁移，否则任何内容都不会跨文件夹流动。

这是最无聊的一点，没人愿意从这里开始。从其他任何地方开始，你就会花一个月时间在错误的层上排查问题。

每个文件夹内我使用 WAT 结构：Workflows（工作流）是 Markdown 指令，Agent（智能体）是 Claude Code，Tools（工具）是执行操作的脚本。3 个子文件夹，每个新文件都有一个显而易见的归属位置。

根目录放置 CLAUDE.md，这是项目的系统提示词。没有它，Claude 是通用的；有了它，Claude 就成了熟悉该客户工作流、工具和数据的专家。（http://claude.md/）

保持在 200 行以内。我在 Claude Code 里花了 600 多个小时，这个上限是我唯一一条从未后悔设定的规则。超过 200 行，它就不再作为系统提示词发挥作用，而重新变成一份文档——没有人会认真阅读文档，包括模型本身。

在我着手构建文件夹内的其他内容之前，我会先决定哪些内容值得占据那200行的位置。凡是不符合要求的内容，都必须有目的地安置在别处——这正是接下来这2个系统所要解决的问题。

**若缺少它会出现什么问题：** 客户2的定位出现在客户1的文案中，而没有人在一周内发现。这种情况不会触发任何报错信息。输出内容看起来完全正常，只是结果是错的。

# 2. 针对每位客户的上下文文件

**从什么时候开始产生成本：** 账户中出现第2个人的时候。

每位客户都有一个 context.md 文件，其中包含：理想客户画像（ICP）、产品/服务方案、用户角色、哪些方法有效、哪些方法无效。（http://context.md/）

在 Frontal 建立这套体系之前，我们经历的是典型的代理商混乱状态。好想法散落在 Slack 里。文案成果被随手扔进 #random 频道，真的就是这样。调研成果留存在某一个人的脑子里。新员工不断地重新学习前人踩过的坑。

有了针对每位客户的上下文文件之后，GTM 工程师可以在几分钟内接手任何一个账户。再也不需要为了获取基本背景信息而去"问一下销售"了。

有一条规则比文件本身更重要：对你的信息来源排定优先级。ICP 文档、情报库与上季度的营销活动记录，最终必然会出现相互矛盾的情况。在代理商运行之前就决定好以哪个来源为准，而不是等它已经基于错误的来源写完40封邮件之后再来处理。

GitHub 成了我们所有内容的唯一可信来源。这听起来像是日常维护工作，但当某个账户的输出结果发生变化时，你可以通过 diff 上下文文件来精确定位原因。

**若缺少它会出现什么问题：** 引导一个新成员上手，所耗费的成本约等于引导一个新客户入职。而这恰恰是你最初想要消除的那部分成本。

# 3. 技能库

**从什么时候开始产生成本：** 第5个客户的时候。

大约到了第5个文件夹，你会发现自己已经把同一套流程写了5遍，每个版本略有差异，而你根本想不起来哪个版本才是最好的。这就是该停下来、认真构建技能库的信号。

所谓"技能"，是一个指令文件，用于教会 Claude 如何完成某一项特定的 GTM 任务。Claude 只会加载与当前任务相关的内容。

我开源了我们在70多个客户中实际运行的15项技能，涵盖5大支柱，共约4200行方法论内容。

内部技能集是复利效应真正发生的地方：

- **文案写作。** 我们整理成文档的高转化率冷邮件框架。
- **TAM 评分。** 80至100分的评分模型。
- **联系人信息丰富化。** 三层瀑布式处理流程。
- **营销活动执行。** 9阶段检查清单。
- **信号检测。** 跨4个层级的30个意图信号。
- **Clay、数据库查询，以及我们所接触的每一套 CRM 的 RevOps 技能。**

技能由1名工程师编写一次，所有文件夹调用的都是同一份副本。这是本文列表中第一个能让第15个文件夹的成本低于第5个文件夹的系统——而不仅仅是把成本维持在同一水平。

以下是其中一项技能的实际内容。ICP 技能通过6个步骤，从客户已成交的赢单客户中克隆出客户的 ICP：

1. **拉取已成交订单的域名。** 从其 CRM 中获取最近30至50笔交易，仅保留域名。这些公司完成了转化、完成了付款、且没有流失，这比任何用户角色文档都更具参考价值。

1. **寻找相似公司。** 将种子域名导入 CompanyEnrich 的相似公司 API。向量搜索在3000万以上的公司数据中进行匹配，每个种子域名返回50个匹配结果。输入10个已成交域名，输出500个以上经过排序的相似公司。

1. **叠加信号进行丰富化。** 使用同一工具，分层叠加。融资轮次意味着新的预算。领导层变动意味着购买席位出现了新的决策者。目标岗位的招聘数量激增意味着团队正在扩张。技术栈变更意味着对相邻工具存在意图信号。这些内容将成为第6步中的相关性切入点。

1. 评分与分级。通过 Claude 中的分类提示对每个账户进行处理，以赢单数据和信号数据作为评判标准。Tier 1 是具有活跃信号的强匹配。Tier 2 是强匹配但尚无信号。Tier 3 是邻近匹配，列入观察名单。大约 80% 的人工筛选工作在这一步消失了。

2. 丰富联系人信息。使用 CompanyEnrich、Prospeo 和 FullEnrich。在 1.7 亿以上的档案中按职位搜索合适人选，然后通过多个供应商瀑布式验证邮箱地址。

3. 按层级个性化。每个 Tier 1 账户使用 1 条提示，结合其信号上下文。Tier 2 使用模板化钩子，只需替换单一变量。Tier 3 使用大批量序列。触达强度与层级匹配：Tier 1 通过 Nooks、lemlist 和 Instantly 进行电话＋LinkedIn＋邮件的组合；Tier 2 使用 LinkedIn＋邮件；Tier 3 仅用邮件。

这是 1 个技能，写一次，被每个文件夹调用，一旦发现有误，在 1 个地方统一修复。

# 4. 连接层

开始让你付出代价的时刻：第一次代理向你描述上个月的管道情况时。

MCP 服务器。1 个连接，Claude 控制整个工具，包括端点和参数。

我会为任何 GTM 团队接入的 10 个工具：Notion、Slack、n8n、HubSpot、Apollo、Instantly、Firecrawl、Fireflies、GitHub 和 ClickUp。在 Frontal，跨账户的常用工作集是 Instantly、Fireflies、Notion、Clay、Apollo 和 Attio。

配置每个工具只需 1 行。

每个大约 5 分钟。这就是让 Claude Code 从聊天机器人变成操作系统的那一层的全部安装成本。

其中几个在第一天就能证明自身价值。接入 Fireflies 后，Claude 可以搜索你曾经开过的每一场会议，无需任何人打开录音，即可提取转录内容、待办事项和摘要。接入 Instantly 意味着可以直接从终端发起活动并查看分析数据。接入 n8n 则让 Claude 无需打开 UI 就能构建、测试和调试自动化流程。

缺少它会发生什么：代理拥有你所有的指令，却没有你的实时状态。输出内容流畅、结构良好，描述的却是 3 周前就已过时的管道情况。这比直接崩溃要难发现得多。

# 5. 数据层

开始让你付出代价的时刻：大约到第 9 个客户时，第一次有人问某个账户的情况，而答案是一份手动报告。

Supabase 作为底层基础。所有 TAM 列表、联系人、活动和绩效快照存储在 1 个数据库中。

活动绩效每天自动跟踪，无需任何人拉取报告，你就可以查看趋势。

对交付成本而言真正重要的一点：每位工程师查询的是同一份数据。一个人的工作成果无需交接会议、Loom 视频或没人看的 Slack 消息，就能被所有人获取。

将定时任务部署到云端运行器，只在运行时付费。按计划或 webhook 触发。它在你睡觉时运行，这是在 15 个账户之间每天获取快照的唯一现实可行的方式。

在这里部署任何东西之前，先进行一次安全审查。1 条提示：检查暴露的 API 密钥和漏洞。大约 30 秒，是这套技术栈中最廉价的保险。

# 6. 智能存储层

开始让你付出代价的时刻：第 10 个客户重新学习第 3 个客户已经证明过的东西的那一刻。

每一条活动洞察都被记录下来。哪些文案角度有效，哪些无效，哪些角色反应最好，哪些细分市场表现最佳。按目标类型、市场、ICP 分类存储。

在撰写新文案之前，Claude 会检查该特定细分领域已经验证过的内容。这就是整个循环。

在整个机构中，该知识库现在存储了 11,000 个营销活动、132,000 个快照以及 30 多个客户的数据。当某位工程师在周二发现一个有效角度时，其他所有账户最快周四就能开始使用它。

其余 5 个系统的作用是防止随着客户增加导致交付成本上升。这是整个体系中唯一一个无需任何人工干预、交付质量就能持续提升的环节。

# 这 6 个系统真正带来了什么

70 多个客户，500 多个 AI 工作流。一家年经常性收入 700 万美元的企业，运行着 37 个 Agent。在这 37 个中，大约 6 个从根本上改变了我们的日常运作方式，其中电话前研究是最典型的一个：生成一份完整简报只需 90 秒，而以前销售代表需要手动挖掘 15 分钟。

在营销活动层面，具体流程如下：Claude Code 直接从项目文件夹中读取 Instantly API 文档，调用 Apollo API，在大约 90 秒内拉取 153 个联系人。然后我将这些数据依次经过 Wiza、FullEnrich、Prospeo 进行瀑布式处理，最终获得 149 个经过验证的邮箱地址。在完整的瀑布流程下，覆盖率可突破 90%。营销活动在 Instantly 中上线。

任何人都可以在某个顺利的日子里，在某个文件夹中完成一次这样的操作。但当这套流程被记录下来一次，让第 15 个文件夹调用的是完全相同的副本时，它才真正成为一门生意。

# 仍然需要人工处理的 4 项任务

1. API 密钥。每次都需要你自己添加，每个文件夹单独配置。这件事没有任何可以自动化的版本，你也不会希望有。

1. 调试环节。每次新构建的第一次运行都会出问题。Claude 会排查错误、修复代码，并更新工作流以避免同样的问题再次发生。但第一次出错时，你仍然需要在场。

1. 裁量判断。分层处理可以消除大约 80% 的手动筛选工作。剩下的 20% 需要判断哪些账户根本不值得发送，而这个判断直接关系到收入。

1. 电话本身。电话前简报会在 90 秒内发送到 Slack。但它无法主持会议。

# 唯一不应该放进文件夹的工作流

这整套体系是为个人层面的工作而构建的，同时也止步于此。

我是这 15 个账户上唯一的操作者，这在很大程度上正是它能够运转的原因。把同样的 15 个文件夹放到 5 台电脑上、由 5 个操作者使用，你得到的就不再是一个系统，而是 5 个人在猜测哪个版本的技能才是当前有效版本。

因此，要将涉及营收关键、团队协作的工作流排除在外。如果你构建了一个从 CRM 拉取数据、检查数据是否最新、再将更新推送回去的 RevOps 流程，这个流程就不能存在于某人的本地机器上。它需要一个在云端受监控的稳定环境，让整个团队都能看到什么在运行、以及凌晨 3 点发生了什么故障。

把文件夹体系用于一个人端到端负责的工作。任何整个营收团队都依赖的内容，都应该放在所有人都能监控的地方。