# 技术创始人的 GTM 实战手册：模板、提示词与检查清单

> 一套面向技术创始人的实用 GTM 方法，包含市场研究、定位、发布准备与日常复盘所需的可复制模板和提示词。

Source: https://tomako.ai/zh/blog/builder-gtm-playbook
Updated: 2026-09-18

可靠的市场进入流程，应从已核实的产品事实出发，把市场信号转成可验证的定位假设，再用发布结果指导下一步决策。这套手册让技术创始人不用复杂的营销工具栈，也能建立一套小而完整的执行系统。

## 快速要点

- 先确认产品事实，再写宣传口号。
- 把评论、定价页、更新日志和社区讨论当作研究输入，而不是整个市场的结论。
- 在用户证据和产品测试足够之前，只提出范围明确的定位主张。
- 引入发布流量前，检查激活路径、计费、遥测和恢复方案。
- 用每日记录和每周复盘决定哪些动作继续、调整或停止。

## 技术创始人的五阶段 GTM 系统

每个阶段都应产出一个可以直接交给下一阶段使用的工件。

| 阶段 | 要回答的问题 | 产出 |
| --- | --- | --- |
| **1. 产品事实** | 产品现在可以被核实地完成什么？ | 产品事实表 |
| **2. 市场研究** | 证据中出现了哪些问题和表达？ | 证据笔记与待验证问题 |
| **3. 定位** | 哪个范围明确的主张值得测试？ | 首屏文案与定位假设 |
| **4. 发布准备** | 用户能否避开可预防的故障并获得价值？ | 发布清单与渠道计划 |
| **5. 学习循环** | 发生了什么，下一步要改变什么？ | 每日记录与每周决策 |

顺序很重要。产品事实让研究保持在真实边界内；研究为定位提供依据；定位决定发布方式；发布结果则为下一轮研究带来更好的问题。

## 复制完整 GTM 执行手册

把下面的模板保存到项目仓库或工作笔记中，文件名可用 `GTM_RUNBOOK.md`。

```markdown
# 技术创始人 GTM 执行手册

## 1. 已核实的产品事实
- 产品名称：
- 目标用户及使用场景：
- 核心输入或触发条件：
- 可验证的功能结果：
- 当前设置或部署方式：
- 已核实的限制：
- 不在范围内 / 明确不做的事情：
- 当前还不能提出的主张：

## 2. 市场研究
- 研究问题：
- 已查看的来源：
- 在本次样本中重复出现的信号：
- 单个观察：
- 重要矛盾：
- 缺失的证据：
- 下一步验证动作：

## 3. 定位假设
- 用户：
- 要完成的任务：
- 当前阻碍：
- 候选标题：
- 补充说明：
- 已核实的证明点：
- 需要测试的主要假设：

## 4. 发布准备
- [ ] 已用真实输入完成主要激活路径。
- [ ] 可以在分析工具中看到激活事件。
- [ ] 已通过一次主动制造的错误测试异常遥测。
- [ ] 计费测试环境覆盖成功、拒付、身份验证和退款路径。
- [ ] Webhook 已完成验证，并采用幂等处理。
- [ ] 已检查遥测工具中的敏感输入遮罩。
- [ ] 已记录并测试恢复或回滚路径。
- [ ] 已检查发布渠道规则和披露要求。

## 5. 学习循环
- 主要渠道：
- 两个已保存的问题搜索：
- 每天 30 分钟执行时段：
- 本周有价值的对话：
- 已激活用户及观察到的障碍：
- 无法确认的来源：
- 继续：
- 调整：
- 停止：
```

## 第一阶段：建立产品事实表

在研究竞品或撰写文案之前，先把产品事实与市场假设分开。

| 事实类型 | 要回答的问题 |
| --- | --- |
| **用户** | 谁现在就能使用这个产品？ |
| **输入** | 用户必须安装、连接、上传或提供什么？ |
| **结果** | 用户能完成并验证什么任务？ |
| **机制** | 产品通过什么方式产生这个结果？ |
| **限制** | 哪些情况不适用，或哪些环节仍需人工处理？ |
| **非目标** | 产品明确不是用来做什么的？ |
| **证明** | 哪些主张已有测试、演示、记录或当前产品行为支持？ |

不要把未经验证的客户痛点写进产品事实表。创始人可能认为用户不喜欢某种手动流程，但在证据出现之前，这仍然只是一个研究问题。

### 一个贯穿全文的例子

假设有一个 CLI 工具，可以在预发布环境日志上传前移除常见密钥。这个例子只假定以下事实已经核实：

- 它以单个二进制文件在本地运行。
- 它从标准输入读取日志，并把脱敏后的数据流写入标准输出。
- 它包含常见 API 密钥和数据库连接字符串的处理规则。
- 它采用 MIT License 发布。

这些事实不能证明它能发现所有密钥、满足某项合规标准、节省固定时长，或替代安全审查。

## 第二阶段：把公开信号转成研究问题

公开资料可以帮助你提出有价值的问题，但不能代表完整市场。

| 来源 | 适合了解什么 | 单独使用时不能证明什么 |
| --- | --- | --- |
| **客户评论** | 工作流程中的阻碍，以及用户描述问题时使用的语言 | 这个问题在所有用户中有多普遍 |
| **定价页** | 当前限制、计费单位和功能门槛 | 某项限制是否不合理，或是否会为另一款产品创造需求 |
| **更新日志** | 某家公司在一段时间内选择公开了什么 | 完整的研发投入、维护程度或路线图优先级 |
| **社区讨论** | 问题出现的场景、常用术语和已尝试的替代方法 | 市场规模，或你的产品能否解决这个问题 |

只有在你查看的样本范围内，才能把一个问题称为“重复出现”。两条相似评论足以支持继续追问，但不足以代表大多数客户。

### 可复制的竞品研究提示词

```markdown
你正在协助一位技术创始人分析市场证据。

只使用下方提供的来源文本。不要使用关于公司、产品、市场或用户的外部知识。

研究问题：
[问题]

来源类型与采集日期：
[评论、定价页、更新日志或社区讨论]
[日期]

来源文本：
"""
[粘贴简短且相关的来源材料]
"""

先从 10–15 条简短且相关的摘录开始。更大的来源集合应拆成多次分析，
不要把彼此无关的材料混在一次处理中。

规则：
1. 把直接观察与解释分开。
2. 只有至少两个独立条目支持同一个底层问题时，才标记为“在本次样本中重复出现”。
3. 只有一个条目支持的发现，标记为“单个观察”。
4. 每项发现附上一段简短原文或一个准确的文档字段。
5. 不要推断市场规模、用户意图、产品质量或付费意愿。
6. 用户抱怨可以支持某个痛点存在，但不能证明我们的产品能解决它。
7. 如果材料不足以支持结论，写明“证据不足”。

输出：
- 有证据支持的观察
- 在本次样本中重复出现的信号
- 单个观察
- 矛盾或缺失的背景
- 这些证据不能支持的主张
- 接下来最小的三个验证问题
```

对于这个日志脱敏 CLI，一个有用的研究问题是：“开发者是否反复提到维护自定义脱敏规则是一项运维负担？”研究应验证这个问题，而不是一开始就认定产品已经发现了市场需求。

## 第三阶段：写出定位假设

定位应连接一个用户、一项任务、一个阻碍，以及一个已有事实支持的相信理由。

可以用下面的模型起草：

```text
定位假设 = 用户 + 要完成的任务 + 当前阻碍 + 已核实的证明
```

标题不必塞入全部信息。主标题、副标题和证明点可以共同完成表达。

| 模式 | 公式 | 示例 |
| --- | --- | --- |
| **移除已知阻碍** | `[完成任务]，无需[替代做法]` | 验证数据库恢复，无需维护自定义恢复脚本。 |
| **转换输入** | `把[输入]转成[输出]` | 把 Webhook 事件转成可对账的账本记录。 |
| **明确服务对象** | `面向[用户或环境]的专用[产品类别]` | 面向单容器家庭服务器的运行状态监控工具。 |
| **替代脆弱流程** | `停止[脆弱流程]。[获得结果]。` | 不再手动清理生产日志。导出前先移除常见密钥。 |
| **划分工作** | `你负责[高价值工作]，我们处理[系统工作]。` | 你负责写查询，我们处理连接池、缓存和故障转移。 |

对于贯穿全文的例子，一个谨慎的初始假设可以是：

- **H1：** 上传预发布环境日志前，先移除常见密钥。
- **副标题：** 让日志先经过一个本地 CLI，遮罩它支持的 API 密钥和数据库连接字符串，再把清理后的数据流交给上传脚本。
- **CTA：** 查看安装命令。
- **证明点：** 本地运行，采用标准输入/输出工作流，并使用 MIT License。

每句话都来自产品事实表。文案没有声称它能完整检测所有风险、满足合规要求或节省经过测量的时间。

### 可复制的定位提示词

```markdown
你正在协助一位技术创始人起草定位假设。

只使用下方已核实的产品事实和有证据支持的研究观察。
不要编造性能、隐私、合规、客户、价格、集成或设置方面的主张。

已核实的产品事实：
[粘贴产品事实表]

有证据支持的研究观察：
[粘贴带有证据边界的发现]

要求：
1. 起草三个明显不同的首屏方案。
2. 每个方案提供 H1、副标题、CTA 和证明点。
3. 写明每个方案背后的受众假设。
4. 指出一个不够谨慎的写作者最可能加入的、最严重的无依据主张。
5. 缺少证明的地方写“缺少证据”。
6. 最后给出一个最小用户测试，用来判断目标读者最容易理解哪个方案。
```

提示词只能生成候选方案，不能验证定位。应把完整首屏展示给相关用户，再询问他们理解到的任务、受众和差异点是什么。

## 第四阶段：检查发布准备度

发布是一段连续过程，不是一条公告。

| 时间 | 重点 | 准备完成的证据 |
| --- | --- | --- |
| **T-14 至 T-7** | 激活、错误处理、计费、隐私 | 核心路径和失败路径均已测试 |
| **T-6 至 T-1** | 信息、素材、渠道规则、支持责任人 | 发布资料已审查，支持计划已分配 |
| **第 0 天至第 2 天** | 冒烟测试、回复、问题分级 | 产品保持可用，新问题有明确负责人 |
| **第 3 天至第 30 天** | 流失诊断、留存、定性反馈 | 已记录下一步产品与分发决策 |

### 技术发布检查清单

- **激活：** 使用真实输入完成主要价值动作，并确认分析工具中出现预期事件。
- **错误：** 主动触发一次异常，确认负责人能找到足够的上下文进行调查。
- **计费：** 使用 Stripe 的[测试环境](https://docs.stripe.com/testing)模拟产品支持的付款路径。不要在正式环境中使用真实付款信息进行测试。
- **Webhook：** 对 Stripe Webhook，使用端点密钥和未经修改的请求体验证签名。采用幂等处理，并记录已经处理的事件 ID。参见 Stripe 当前的 [Webhook 指南](https://docs.stripe.com/webhooks)。
- **遥测：** 检查会话录屏或日志工具中的实际设置与已采集数据。不要假定所有位置都已经启用遮罩。
- **恢复：** 记录并测试适合当前架构的恢复或回滚路径。数据库迁移、Serverless 函数和桌面应用可能需要不同方案。
- **容量：** 用合适的限制、队列或超时保护高成本端点，并测试触发限制时用户会看到什么。
- **渠道：** 阅读社区当前规则，在需要时准备披露说明，并安排发布后负责回答问题的人。

更完整的执行安排见[七天产品发布指南](/zh/blog/how-to-launch-product-7-days)。选择首个社区时，可以比较 [Product Hunt、Reddit 与 Hacker News](/zh/blog/product-hunt-vs-reddit-vs-hacker-news)各自的优势与限制。

## 第五阶段：建立每日与每周学习循环

日常安排的目标不是在所有平台发帖，而是在不占满工作日的前提下，持续推进有价值的对话、产品学习和后续跟进。

| 时间段 | 动作 | 产出 |
| --- | --- | --- |
| **00–10 分钟** | 查看两个已保存的问题搜索；如果有合适讨论，提供一次有帮助的回复 | 一条有用回复，或一个更准确的搜索词 |
| **10–20 分钟** | 把真实的产品改动、故障修复或经验写成简短更新 | 一条已审查的帖子或草稿 |
| **20–30 分钟** | 跟进一位用户，或调查一个激活障碍 | 一项有负责人的下一步行动 |

计时结束就停止。如果没有合适的对话或跟进对象，就改进搜索、记录一个问题，或回到产品工作。

周五用复盘替代中间十分钟：

- 哪些对话涉及真正的目标受众？
- 哪些用户完成了激活事件？
- 他们在哪里停下来或需要帮助？
- 他们来自哪个来源？无法确认时就标记为未知。
- 下周哪些事情应该继续、调整或停止？

[独立创始人每天 30 分钟的营销安排](/zh/blog/daily-marketing-routine-solo-founders)提供了可复制的每日清单和更完整的每周复盘方法。

## 用一个例子串起五个阶段

这个假设的日志脱敏 CLI 可以这样贯穿整套系统：

| 阶段 | 示例决策 |
| --- | --- |
| **产品事实** | 确认本地运行、支持的密钥类型、标准输入/输出和许可证。 |
| **研究** | 验证开发者是否反复把维护自定义脱敏规则描述为负担。 |
| **定位** | 起草一个关于“导出前遮罩已支持密钥”的窄范围主张，避免完整安全或合规承诺。 |
| **发布准备** | 测试真实日志流、失败行为、文档、遥测和恢复方案。 |
| **学习循环** | 记录谁理解了使用场景、谁完成了第一次脱敏导出，以及设置在哪一步失败。 |

一次发布的结果可能改变定位。如果用户更在意本地处理，而不是脚本维护，下一版标题就应该测试这个发现。当证据能够改变下一次决策时，这个循环才真正起作用。

## Tomako 在其中承担什么角色

开始阶段的人工工作很有价值，因为它能暴露哪些背景、证据和判断真正重要。当流程开始重复时，[Tomako](https://tomako.ai)可以把已经连接的产品与市场背景整理成有优先级、可审核的增长工作。方向、发布、外联、花费及其他重要决定仍由人掌控。

> **检查你的 GTM 准备度**
>
> 使用免费的 [GTM 准备度检查清单](/zh/tools/gtm-readiness-checklist)，在推广产品前找出产品、定位、发布与衡量环节仍需解决的问题。

## 延伸阅读

- [如何在 7 天内发布产品](/zh/blog/how-to-launch-product-7-days)
- [Product Hunt、Reddit 与 Hacker News：独立创始人应该先在哪里发布？](/zh/blog/product-hunt-vs-reddit-vs-hacker-news)
- [独立创始人每天 30 分钟的营销安排](/zh/blog/daily-marketing-routine-solo-founders)

从产品事实表开始，选择一个研究问题，再提出一个能用真实用户验证的、尽可能小而诚实的主张。