developer-audience-context

开发者受众背景

此技能可帮助你创建和维护 .agents/developer-audience-context.md，这是一份记录目标开发者相关信息的基础文档。所有其他开发者营销技能都会优先参考此文档，因此你只需定义一次受众。

---

开始之前

检查 .agents/developer-audience-context.md 是否存在：

• 如果存在：阅读文档，并提出更新特定部分
• 如果不存在：创建目录和文件，然后逐一梳理各个部分

---

两种构建背景信息的方式

选项 1：根据代码库自动起草（推荐）

分析现有材料，起草初稿：

1. README.md — 产品描述、功能、入门指南
2. 文档 — /docs、API 参考、教程
3. 落地页 — index.html、营销文案
4. package.json / pyproject.toml — 依赖项可揭示所属生态
5. GitHub Issues — 常见问题、困扰、用例
6. 现有博客文章 — 技术内容、教程

起草后，逐一审阅各部分，验证内容并补齐缺失信息。

选项 2：从头开始

逐部分提问。当前部分完成之前，不要进入下一部分。

---

需要记录的 10 个部分

1. 产品概览

字段	需要记录的内容
产品名称	官方名称及其他别名
一句话介绍	“我们帮助［开发者］在无需［Y］的情况下完成［X］”
类别	API、SDK、CLI、SaaS、开源库、基础设施
核心技术	支持的语言、框架、平台
定价模式	免费／开源、免费增值、按使用量计费、按席位计费

2. 开发者角色画像

不要笼统地写“开发者”——要具体：

字段	需要记录的内容
主要角色	后端、前端、全栈、DevOps、数据、机器学习、移动端
资历	初级、中级、高级、资深、负责人、架构师
公司规模	个人、初创公司、成长期公司、大型企业
行业领域	金融科技、健康科技、电子商务、游戏、B2B SaaS
技术栈	他们使用的语言、框架、云服务提供商
决策权	个人贡献者、团队负责人、采购决策者、影响者

提问：“用一段话描述最能从你的产品中获益的开发者。他们的日常工作是什么样的？”

3. 他们活跃的地方

开发者在购买前会先做调研。了解他们在哪里活跃：

渠道	需要记录的具体信息
社区	具体的 subreddit、Discord 服务器、Slack 群组
社交媒体	Twitter/X 话题标签、LinkedIn 群组
内容	他们阅读的博客、订阅的简报、收听的播客
活动	会议、聚会、黑客马拉松
代码社区	GitHub 主题、Stack Overflow 标签

专业提示：使用社交媒体监听工具，监控 Hacker News、Reddit、Stack Overflow、GitHub 和 Twitter 上的讨论。了解人们通常会在哪里讨论与你的问题领域相关的话题。

4. 问题与痛点

记录实际问题，而非解决方案的功能：

层面	需要记录的内容
功能层面	“我无法完成 X”／“X 耗时太长”／“X 容易出错”
情绪层面	沮丧、焦虑、难堪、恐惧
情境层面	痛点何时出现？什么会触发他们开始寻找解决方案？

提问：“开发者找上你时，最主要的困扰是什么？”

调研：在 Reddit、Hacker News 和 Stack Overflow 上搜索与你的问题领域相关的抱怨，并原样记录引用内容。

5. 当前替代方案

开发者现在用什么来代替你的产品？

替代方案类型	示例
直接竞争产品	解决同一问题的工具
自己动手构建	自定义脚本、内部工具
间接解决方案	权宜之计、手动流程
什么都不做	忍受痛点

针对每种替代方案，记录：

• 开发者选择它的原因
• 它有哪些令人困扰之处
• 什么情况会促使他们转而使用你的产品

6. 关键差异化优势

用开发者的语言说明你有何不同：

差异化优势类型	示例
技术	“快 10 倍”“无依赖”“类型安全”
DX（开发者体验）	“5 分钟即可完成设置”“文档出色”“一流的 CLI”
生态系统	“可与 X 搭配使用”“专为 Y 框架打造”
理念	“开源”“隐私优先”“本地优先”

警告：避免空洞的营销辞藻。开发者一眼就能看穿“同类最佳”和“企业级”之类的说法。请使用具体且可验证的描述。

7. 开发者原话

记录开发者使用的原话，而不是润色过的营销文案：

类别	示例
描述问题	“这真的太麻烦了”“我希望可以直接……”
描述你的产品	他们如何向别人解释它
异议	“但是……怎么办？”“我担心……”
好评	推荐语、推文、GitHub 评论

来源：GitHub 问题、Twitter 提及、Hacker News 评论、支持工单、销售通话、社区 Slack/Discord。

8. 技术信任信号

哪些证明对开发者很重要：

信号类型	示例
采用情况	GitHub 星标数、npm 下载量、Docker 拉取量
质量	测试覆盖率、安全审计、正常运行时间 SLA
社区	贡献者、Discord 成员、论坛活跃度
可信度	由 X 支持、被 Y 使用、由 Z 创建
透明度	开源、公开路线图、变更日志

9. 转化行动

每个阶段的成功表现是什么？

阶段	主要行动	次要行动
认知	为仓库点星标、在 Twitter 上关注	阅读博客文章、分享内容
考虑	克隆仓库、阅读文档	观看演示、加入 Discord
试用	注册、安装 SDK	完成快速入门、发起首次 API 调用
激活	达到“Hello World”时刻	集成到实际项目中
转化	升级为付费用户	添加团队成员、扩大使用范围

10. 风格与语气

与这些开发者交流时应采用怎样的风格和语气？

维度	光谱
正式程度	随意 ← → 专业
技术深度	通俗易懂 ← → 技术深入
个性	中立 ← → 观点鲜明
幽默	严肃 ← → 活泼

示例：

• Stripe → 专业、精准、简洁
• Vercel → 现代、自信、开发者优先
• Supabase → 友好、易懂、由社区驱动
• Tailwind → 观点鲜明、直接、务实

---

输出格式

按以下结构保存到 .agents/developer-audience-context.md：

# Developer Audience Context

Last updated: [DATE]

## Product Overview
[Section content]

## Developer Persona
[Section content]

## Where They Hang Out
[Section content]

## Problems & Pain Points
[Section content]

## Current Alternatives
[Section content]

## Key Differentiators
[Section content]

## Verbatim Developer Language
[Section content]

## Technical Trust Signals
[Section content]

## Conversion Actions
[Section content]

## Voice & Tone
[Section content]

---

维护

在以下情况下更新本文档：

• 从用户研究中获得新发现
• 找到精彩的开发者原话
• 定位或差异化优势发生变化
• 拓展到新的开发者细分群体

---

工具

工具	用途
Octolens	监控 GitHub、Hacker News、Reddit、Stack Overflow、Twitter 上的开发者对话。对于记录开发者原话、发现痛点，以及了解开发者聚集在哪里至关重要。
GitHub Search	查找开发者如何在问题中描述问题
Twitter Advanced Search	查找关于你所在领域的讨论
Google Alerts	跟踪竞争对手和问题关键词的提及

---

相关技能

建立上下文后，以下技能会参考本文档：

• devrel-content — 撰写能引起共鸣的内容
• hacker-news-strategy — 真诚地参与 HN 社区
• developer-onboarding — 优化实现价值所需的时间
• developer-seo — 定位合适的技术搜索词
• competitor-tracking — 了解你的竞争格局