start-here

从这里开始（创始人简报）

其他所有技能的效果，都取决于 Agent 对 你的 业务了解得有多深入。这份简报就是提供这些背景信息。只需完成一次，之后的每项技能都会更贴合你的情况。

适用场景： 如果你是第一次来到这里，或者你得到的建议听起来泛泛而谈、像教科书上的内容，因为 Agent 并不了解你的产品、用户或所处阶段。

核心思路

回答 五个核心问题，Agent 就会在你的项目中撰写一份 docs/gtm-cofounder/founder-brief.md，让你在几分钟内获得真正的诊断和路线图。其他内容都是可选的，你可以边用边回答：每项技能会在需要时提出实际所需的深入问题，并说明回答后能解锁什么。这样你能很快看到价值，而且用得越多，这份简报就会越完善，而不是第一天就面对一大堆问题。

最重要的是：区分你已经 验证过 的内容（真实用户——而非你的朋友——告诉你的）和你目前 假设 的内容（你现阶段最好的猜测）。一开始有假设完全没问题。之后会把它们交给 talk-to-users 去验证，让你永远不会基于猜测打造一套漂亮的上市策略。

如何运行（供 Agent 使用）

• 一次只问五个核心问题中的一个，除此之外什么也别问。 一次问一个问题，等对方回答，再根据回答决定下一个问题。这应该像和联合创始人交谈，而不是填写表格。绝不要一次贴出多个问题。（如果创始人更希望看到全部五个问题并一次性作答，就把问题列表给他们；但默认一次问一个。）
• 根据这五个问题撰写简报，然后转到 research-the-market，再转到 strategy-and-roadmap。创始人应该先获得研究结果和诊断，再回答任何可选问题。访谈只记录他们已经知道的内容；研究则能避免计划只是把他们的回答原样奉还。
• 在恰当的时候提出深入问题。 后续技能需要更多信息时（定位需要了解对手，定价需要了解买家），就当场只问两三个相关问题，并说明回答后能解锁什么。绝不要一开始就把所有问题都抛出来。
• 每收到一条实质性回答，都要问：“这是你听真实用户说的，还是你目前自己的判断？”并标注 [validated] 或 [assumption]。
• “采访过的用户为零”也是有效且有启发性的回答。坦率记录，不作评判，并将 talk-to-users 标为最高优先级的下一步。
• 保留创始人自己的措辞。不要把他们描述的痛点润色成营销语言。
• 撰写完核心简报后，不要直接跳到某项任务或开始安排工作。应转交给 research-the-market（然后是 strategy-and-roadmap），或者询问创始人想要着手处理什么。提供选择，不要强加安排。

首先，了解他们已经交付的成果（仅当你在他们的项目中时）

在提出任何问题之前，先检查你是否正在创始人的代码库中运行。如果是，先快速、有限地扫描一遍，让访谈更有针对性，而不是从零开始：

• README 和任何 docs/ 介绍文档：项目声称能做什么，以及目前是如何描述它的。
• 包清单（package.json、pyproject.toml、go.mod 等）：使用的语言、依赖项，以及集成对象。
• 最近约 15 条提交说明和近期的 PR 标题：他们目前实际在构建什么。
• 未解决议题中的主题：真实用户反复遇到的问题，这可以反映痛点和受众。

这只是快速扫描，不是审计。不要逐行阅读代码、遍历整个历史记录，也不要获取任何敏感信息。根据发现起草简报，并将这些事实标记为 [validated]，因为它们来自真实资料，而非猜测。

注意两点：

• 代码库是供你评议的输入，不是绝对标准。 README 通常沿用创始人现有的、往往很笼统的表述。先说“这是你目前描述它的方式”，然后再提出质疑。不要把薄弱的定位当成事实照搬。
• 代码库能告诉你构建了什么，却不能告诉你谁会付钱。 它能帮助你了解产品和大致用户，却无法说明购买者、付费意愿或市场情况：这些仍需向创始人了解，并通过 talk-to-users 验证。

如果你不在某个项目中（例如拿到的是一段粘贴的技能内容，或没有代码库），就跳过这一步，直接进入核心五问。

核心五问（先回答这些）

这是完整的必填信息。回答这些问题后，Agent 就能开始诊断并制定计划。如果你已经扫描过代码库，就不要冷不丁地问这些问题：先确认或完善你的推断，再把问题留给资料无法说明的部分，包括 ICP、购买者，以及是否有人愿意付费。

1. 用一句通俗的话说明，它能做什么？
2. 它具体面向谁？（角色、公司规模和类型、技术背景）
3. 他们目前用什么替代方案？为什么会选择你而不是它？
4. 所处阶段和发展情况：有多少用户？他们会回来使用吗？
5. 你唯一的 最强资产 是什么：你拥有的最有力、可证明的东西（知名品牌标识、扎实的数据、真实用户引言、明确的需求信号）。

深入了解（可选，随时回答）

可以先跳过。每项技能会在需要时询问所需信息。每个问题都会说明回答后能解锁什么，所以你只需在认为值得时投入精力。

定位与故事

• 它解决了用户用自己的话描述的什么棘手问题？→ 这会成为你主页的标题，也会成为故事中的关键利害关系。
• 什么趋势正在让这个问题变得更严重？→ 这是你的反派，它让你的定位更紧迫，而不只是罗列功能。
• 你现在的主页或代码仓库简介写了什么？（粘贴原文）→ 这样 Agent 就能在现有内容的基础上润色，而不是凭空猜测。

买家与定价

• 谁来付费？如果付费者和采用者不是同一个人，请说明。→ 这样 Agent 就能围绕真正的买家，而不只是用户，设计定价和销售策略。
• 它明确不适合谁？→ 清晰地说明“不适合谁”，能让你的理想客户画像更可信，也让你的信息传达更有效。
• 他们雇用它来完成的任务：“当[情境]时，我想要[动机]，这样我就能[结果]。”→ 这会成为你的价值主张。

分发与推广方式

• 推广方式：开源、PLG、入站营销、销售驱动，还是尚不确定？→ 这会为你选出真正适合的渠道和策略。
• 用户已经在哪里交流和发现工具？→ 这会告诉我们应该在哪里发布并找到首批用户。

聚焦

• 你现在有意拒绝做什么？（你要守住的路线图、你拒绝的请求）→ 这样 Agent 就不会建议你做已经决定不做的工作。

证据（请如实回答，这是关键所在）

• 哪些知名公司或开发者已经在使用它，而且你可以公开点名？→ 这是你最有力的证明；哪怕只有几个知名客户，也能提升你的可信度。
• 你采访过多少位并非朋友的真实用户？→ 这会告诉 Agent，有多少信息已经得到验证，多少仍是猜测，避免在沙地上建造。
• 哪些答案仍然只是猜测？→ 这会将猜测交给 talk-to-users，让它们得到验证。

编写简报

将答案保存到创始人的项目中的 docs/gtm-cofounder/founder-brief.md（如果 docs/gtm-cofounder/ 文件夹不存在，请创建），并使用此代码仓库中的模板（founder-brief.template.md）。为每个答案保留 [validated] / [assumption] 标签。请使用自然、朴实的文字撰写，不要使用破折号（改用逗号、冒号或句号），让文字读起来不像机器生成。

在简报最前面写上最强资产（核心问题 5），让这位创始人最有力的优势成为所有后续技能的锚点。创始人经常会因为谦逊或过多细节而把它藏起来。随着时间推移，回答更深入的问题后，将答案添加到对应类别下。

保持更新

这份简报是持续更新的文档，不是填一次就忘的表格。每当创始人从用户那里获得真实信息（一次 talk-to-users 通话、一笔流失的交易、一条反馈），就更新相关内容，并将标签从 [assumption] 改为 [validated]。一份大部分内容都标为 [validated] 的简报，代表这家公司了解自己。还要定期运行 market-scan，更新简报之外发生的变化：竞争对手重新塑造品牌、新的参与者入场，或品类发生变化。

接下来的 30 分钟

• 只回答核心五个问题。粗略而坦诚，胜过精致却虚假。
• 为每个答案标注 [validated] 或 [assumption]。
• 将它保存为项目中的 docs/gtm-cofounder/founder-brief.md，这样你的 Agent 就能读取。
• 运行 research-the-market，让 Agent 找出你没告诉它的信息：用户实际在哪里，以及类似产品是如何发布的。
• 运行 01-strategy-and-roadmap，获取诊断结果和第一步行动。暂时不要回答可选问题。
• 之后再回答更深入的问题，等技能提出问题并说明它能解锁什么时再回答。

---

内容基于真实的开发者工具 GTM 经验，并采用了 Adam Frankl（The Developer-Facing Startup）和 Jakub Czakon（markepear.dev）的框架。 如果这份简报揭示了某些你想在付诸行动前先找人验证的内容，这正是我能帮上忙的地方。欢迎通过 LinkedIn 联系我。