kscz0000 开发者受众画像
使用场景
当用户想要建立或更新其开发者受众画像时使用本技能。亦在任何其他开发者营销技能启动时使用，以确保已加载基础上下文。触发词包括"开发者画像""目标开发者""我们的开发者是谁""开发者……"
本技能帮助你创建并维护 .agents/developer-audience-context.md —— 一份捕捉目标开发者所有信息的基础文档。所有其他开发者营销技能都会首先引用这份文档，因此你只需定义一次受众即可。
开始之前
检查 .agents/developer-audience-context.md 是否存在：
- 若已存在：阅读并提议更新特定章节
- 若不存在：创建目录和文件，然后逐章节进行填写
两种构建方式
方式一：从代码库自动起草（推荐）
分析现有材料以起草初始版本：
- README.md —— 产品说明、功能、快速开始
- 文档 ——
/docs、API 参考、教程 - 落地页 ——
index.html、营销文案 - package.json / pyproject.toml —— 依赖项揭示生态系统
- GitHub Issues —— 常见问题、痛点、使用场景
- 现有博客文章 —— 技术内容、教程
起草完成后，逐节验证并填补空缺。
方式二：从零开始
按节逐个提问。在当前章节完成前不要进入下一节。
需要捕捉的 10 个章节
1. 产品概览
| 字段 | 要捕捉的内容 |
|---|---|
| 产品名称 | 官方名称及任何别名 |
| 一句话介绍 | "我们帮助[开发者][做 X]，无需[面对 Y]" |
| 产品类别 | API、SDK、CLI、SaaS、开源库、基础设施 |
| 核心技术 | 支持的语言、框架、平台 |
| 定价模式 | 免费/开源、Freemium、按用量计费、按席位计费 |
2. 开发者画像
不是泛泛的"开发者"——要具体到角色：
| 字段 | 要捕捉的内容 |
|---|---|
| 主要角色 | 后端、前端、全栈、DevOps、数据、ML、移动端 |
| 资历层级 | 初级、中级、高级、资深、主管、架构师 |
| 公司规模 | 个人、初创公司、成长期企业、大企业 |
| 行业领域 | 金融科技、医疗科技、电商、游戏、B2B SaaS |
| 技术栈 | 使用的语言、框架、云服务商 |
| 决策权 | 个人贡献者、团队主管、采购决策者、有影响力的人 |
提问："用一段话描述从你产品中获得最大价值的那位开发者。他/她的日常工作是什么样的？"
3. 他们常出没的地方
开发者在购买前会先调研。了解他们在哪里：
| 渠道 | 要捕捉的具体内容 |
|---|---|
| 社区 | 具体 subreddit、Discord 服务器、Slack 群组 |
| 社交 | Twitter/X 话题标签、LinkedIn 群组 |
| 内容 | 他们阅读的博客、订阅的 newsletter、收听的播客 |
| 活动 | 开发者大会、本地聚会、黑客马拉松 |
| 代码 | GitHub topics、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 issues、Twitter 提及、Hacker News 评论、支持工单、销售通话、社区 Slack/Discord。
8. 技术可信度信号
开发者看重哪些证据：
| 信号类型 | 示例 |
|---|---|
| 采用度 | GitHub stars、npm 下载量、Docker pulls |
| 质量 | 测试覆盖率、安全审计、正常运行时间 SLA |
| 社区 | 贡献者人数、Discord 成员数、论坛活跃度 |
| 信誉 | X 投资背书、Y 名企使用、Z 名人创建 |
| 透明度 | 开源、公共路线图、变更日志 |
9. 转化动作
每个阶段成功的标志是什么？
| 阶段 | 主要动作 | 次要动作 |
|---|---|---|
| 认知 | Star 仓库、关注 Twitter | 阅读博客文章、分享内容 |
| 考虑 | Clone 仓库、阅读文档 | 观看演示、加入 Discord |
| 试用 | 注册账号、安装 SDK | 完成快速上手、发起首次 API 调用 |
| 激活 | 抵达"Hello World"时刻 | 集成到真实项目 |
| 转化 | 升级付费 | 添加团队成员、扩大用量 |
10. 声音与语调
与这些开发者对话时，你应该呈现什么调性？
| 维度 | 范围 |
|---|---|
| 正式度 | 随意 ← → 严谨专业 |
| 技术深度 | 通俗易懂 ← → 深度技术 |
| 个性 | 中立 ← → 鲜明主张 |
| 幽默 | 严肃 ← → 轻松俏皮 |
示例：
- Stripe → 专业、精准、简洁
- Vercel → 现代、自信、开发者优先
- Supabase → 友好、平易、社区驱动
- Tailwind → 主张鲜明、直接、务实
输出格式
保存到 .agents/developer-audience-context.md，结构如下：
# 开发者受众画像
Last updated: [DATE]
## 产品概览
[章节内容]
## 开发者画像
[章节内容]
## 他们常出没的地方
[章节内容]
## 问题与痛点
[章节内容]
## 当前的替代方案
[章节内容]
## 关键差异化
[章节内容]
## 开发者的原话
[章节内容]
## 技术可信度信号
[章节内容]
## 转化动作
[章节内容]
## 声音与语调
[章节内容]
维护
在以下情况时更新本文件：
- 你从用户研究中获得新洞察
- 你发现了很有价值的原话引用
- 你的定位或差异化发生变化
- 你扩展到新的开发者细分群体
工具
| 工具 | 用途 |
|---|---|
| Octolens | 跨 GitHub、Hacker News、Reddit、Stack Overflow、Twitter 监控开发者对话。是捕捉原话、找出痛点以及了解开发者常出没之处的必备工具。 |
| GitHub 搜索 | 在 issues 中找出开发者描述问题的方式 |
| Twitter 高级搜索 | 找出关于你所在领域的讨论 |
| Google Alerts | 追踪竞品和问题关键词的提及 |
相关技能
在建立上下文后，下列技能会引用它：
devrel-content—— 撰写引起共鸣的内容hacker-news-strategy—— 在 HN 上真实地互动developer-onboarding—— 优化从接触到价值的时间developer-seo—— 瞄准正确的技术查询词competitor-tracking—— 了解你的竞争格局
局限性
- 仅当任务明确匹配其上游来源和本地项目上下文时才使用本技能。
- 在应用更改前，验证命令、生成的代码、依赖、凭证及外部服务的行为。
- 不要把示例当作特定环境测试、安全审查或用户对破坏性/高成本操作的审批的替代。