当需要明确开发者受众是谁、优先服务哪一类开发者时…

把泛泛的"开发者"拆成3-5个有命名、有规模、有排序、并明确拒绝一类受众的细分市场，用于指导SDK、文档、活动等下游决策。

适用场景

解决思路

1. 先做访谈，一次只问一个问题，能提供选项就给选项；一旦能确定产品形态、出资驱动因素和现有证据就停止提问，其余信息在起草时确认。访谈问题包括：产品是什么、开发者具体用它做什么（调API、装库、跑基础设施、扩展平台、采纳方法）；公司为何出资做开发者工作（开发者采用、销售赋能、开发者赋能、产品输入、生态与伙伴、贡献者社区、雇主品牌），出资方会最先说哪个；今天谁在用，用支持人员的大白话怎么说；是否存在购买行为，若有，开发者是决策、影响还是都不参与，谁签字；现有证据是什么（注册或遥测数据、支持工单、社区帖子、销售通话记录、用户访谈、问卷，还是什么都没有）；当前用户实际用什么语言、运行时、云或框架，你希望他们用什么；要成功使用产品必须满足什么条件（特定技术栈、规模阈值、合规要求、团队规模）；团队一直在争论哪个受众，争论点是什么；这个周期现实地能为一个细分市场构建什么（新SDK、文档线、合规包、活动出席）；未来两个季度会有什么变化（发布、定价调整、新语言目标、开源）；地图必须在何时决定，什么在等它（路线图锁定、招聘计划、发布，还是无固定期限）；你需要本周期一个决策，还是需要一张可反复运行并自我对比多年的地图；决策前的研究上限是多少（数小时阅读已有数据，还是数周访谈和工单编码），以及当前切分上已构建了什么，以了解改变切分的成本。
2. 在提出任何切分前先问上述最后三个问题，它们决定第2步的排序：临近的截止日期会删除任何你尚未持有证据的切分；复合型任务会提升工作负载切分的优先级，因为它在多个周期内回本；低研究上限会直接删除工作负载切分，只留下生态切分和购买模式切分；当前切分上已有大量制品会提高改变切分的门槛，而不是在备选方案之间选择。
3. 如果运行环境有持久记忆，存储所选维度、细分市场集合、每个细分市场的规模和置信度，以及反细分市场。地图的价值在于能与其上一版本对比重跑；下季度从空白页开始会丢失显示押注是否奏效的对比。
4. 第1步——选择两个维度：选一个改变你构建什么的维度，和一个改变你如何触达他们的维度。其余一切成为细分市场内的描述性字段，而不是切分的轴。两个维度给出团队能记住的网格；三个维度给出没人会执行的电子表格。"恰好两个"是本技能自己的基线，不是标准：已发表的分段实践通常只选一个基础，所以两个已是刻意的中间立场。可选维度族及其开发者特定取值和每个必须通过的测试见 references/segment-dimensions.md，在提出切分前先读它。本技能刻意不对六个维度族排序，这是它对其他一切排序方式的例外。哪个族最改变制品完全由问题1的产品形态决定：技术栈维度对必须活在生态内的产品占主导；工作负载维度对每个领域解决不同问题的产品占主导。任何固定顺序都是虚假精确，一半读者应忽略，所以参考文件为每个族给出"何时使用"条件。第2步中的完整候选切分确实会被排序，因为在那里建立每个切分的努力是可比的。
5. 用细分市场有效性标准检验每个候选切分——可衡量、可触达、足够大、可区分、可行动。这些来自Kotler和Armstrong的通用市场细分教科书，它切分任何受众而非专门针对开发者受众（见 references/published-findings.md）。开发者领域从业者Caroline Lewko（DevRel.Agency联合创始人，2022）用一句话表述同样的纪律："细分关乎聚焦和一致"，她对任何候选切分提出的问题与本步测试的相同——什么类型的开发者会真正在产品上获得成功。
6. 明确说明丢弃项："我们不按资历切分，因为该细分市场中的初级和资深工程师需要同样的制品。"记录一次被拒绝的维度能阻止团队每季度重新争论它。
7. 第2步——在选定前头脑风暴候选切分：声明你处于头脑风暴模式，先不写地图。构建同一受众的两到三个完整候选切分——不是同一个的变体。同一产品的工作负载切分、生态切分和购买模式切分会产生真正不同的项目。对每个候选给出：它产生的细分市场，用受众自己的话而非营销标签；在这个切分下变得明显而在其他切分下不可见的东西；每个细分市场需要的制品；它使谁不可触达；建立该切分需要什么代价——在任何人能被放到线的一侧之前需要的证据，以及你已持有多少；该切分在什么条件下是错误选择。
8. 然后大声排序候选。这里的努力是研究工作量和可逆性——绝不是预算数字——可逆性权重很高，因为切分是每个SDK、文档线和活动选择在一个周期内建立的基础。努力：工作负载切分 > 生态切分 > 购买模式切分。价值：工作负载切分 > 生态切分 > 购买模式切分。效率：生态切分 > 购买模式切分 > 工作负载切分。按数量级：购买模式切分是阅读销售记录和现有账户的一到两小时，因为每笔交易都已记录谁签字。生态切分在注册或遥测已带语言和运行时时是一小时，在需要埋点或询问时是一周——并且它改变你最昂贵的制品，SDK和文档线。工作负载切分是一周到一季度的访谈和工单编码，因为今天存储的任何东西都不记录用户处于哪个工作负载；它在价值上领先，在比率上仍然输。
9. 该顺序会饿死工作负载切分，而这恰恰是制品杠杆最高的切分。在以下情况仍要提升它：来自两个工作负载的支持工单没有共同词汇；同一产品明显为不同人解决不同问题；生态切分返回一个主导单元格——单一语言占据大部分使用量使生态切分无区分度，此时为工作负载研究付费是获得真实切分的唯一途径。
10. 删除而非降级访谈排除的内容，并说明你删除了什么：问题4中完全没有购买行为会把购买模式切分从候选集中移除。数小时的研究上限会移除工作负载切分。被搁置在列表底部的切分下季度会被当作仍然可用而重新提出。
11. 排序是默认值而非法律，且随执行者变化。根据你已持有的东西重新排序：现有问卷或聚类数据集会把工作负载切分的努力压缩到接近零并使其排第一；只在单一生态内运行的产品使生态切分无区分度并使其排最后；有销售记录语料而无遥测的团队会把购买模式切分提升到两者之上。推荐一个并说明原因。让负责人在你给任何东西定规模之前选择——给错误的切分定规模既昂贵又有说服力。
12. 让细分市场从观察到的行为中涌现，然后再贴标签。这是SlashData商业细分服务运行的顺序：1. 为下游用途选择属性；2. "无预设假设"地聚类；3. 画像和命名。其服务页面公布顺序，不公布样本量或属性列表。先发明的标签（"企业架构师"）通常是背后没有成员的刻板印象，后续每一步都继承这个错误。没有问卷时，用同样的方式在支持工单、销售通话记录和社区帖子上聚类。
13. 第3步——给每个细分市场定规模，带置信度层级：把每个规模写成范围加方法加日期加置信度，绝不是一个光秃秃的整数：~20万–40万Go开发者构建内部基础设施工具——公开语言社区规模过滤到200名工程师以上的公司，与我们3.1%的Go注册份额交叉核对；截至<日期>；置信度：估计。置信度层级是本技能自己的标签方案，不是外部标准：已测量——你自己的遥测。估计——公开研究应用于你的过滤条件。推断——类比或判断，无数据。地图可以包含推断的细分市场；但不能把它们呈现为已测量。
14. 如果能浏览网页，从独立开发者人口调查、从业者调查、语言活跃度排名、forge报告和注册表中组装估计。每个测量不同的东西：人口调查给出每个生态或部门的数量级；从业者调查给出自选池内的比例；排名给出层级而非计数；forge报告统计账户而非人数。每个能支持什么不能支持什么，以及当前波次及其样本量，见 references/sizing-sources.md 和 references/published-findings.md。如果不能浏览，只用第一方数据定规模，把每个外部数字标为推断，并说明哪个查询能升级它。
15. 用不同类别的来源交叉核对每个估计，加上从你自己漏斗的自下而上构建。两个同类来源通常共享上游数据集，所以它们一致什么也证明不了：一个调查估计被来自同一受访者池的第二个调查"确认"，等于零次检查；同一估计与你自己注册份额对账，等于一次检查。拒绝三种做法：把语言排名当作人口计数来读；从你自己的用户基础给未服务的细分市场定规模（它总会返回"小"）；引用一个你无法说明来源、日期和方法的数字。
16. 第4步——命名每个细分市场内的决策单元：对每个细分市场，记录谁评估、谁批准、谁签字。这是开发者细分与通用受众工作的区别：你赢得的人常常不是付钱的人。先确定公司形态——它决定这种情况发生的频率：开发者优先——销售为开发者构建的产品，所以评估者常在购买组内。开发者加——销售给更广市场，作为多个渠道之一向开发者暴露某些东西，所以开发者很少靠近签字。只有这两个标签有文档记录（见 references/published-findings.md）；两侧的操作机制没有，所以把标签之后的一切当作你自己的判断。
17. 个人采用——用户就是买家，或不存在购买（爱好者、独立开发者、小团队、学生、OSS维护者）。按动机、生态和工作负载细分。成功表现为收入之前的用量。公司采用——开发者评估；架构师、平台负责人、安全审查者或预算所有者决定。按公司特征以及这些角色中哪些存在来细分。成功表现为通过审查的评估。大多数产品两条路径都有。给它们排序；绝不要平均。角色表——每个角色被什么说服以及为什么说不——见 references/decision-unit.md。
18. 对两个后果采取行动：当一个名义细分市场内决策单元不同时，拆分该细分市场。当一个细分市场完全不含购买时，用非收入驱动因素（人才品牌、贡献者供给、未来买家）为其辩护，或将其移到反细分市场——一个无理由的免费受众会悄悄消耗整个内容预算。
19. 第5步——评分和排序：1. 评分前先加权。根据访谈问题2的出资驱动因素给七个标准加权——雇主品牌资助的项目和收入资助的项目对相同细分市场的排序不同，两者都对。2. 粗略评分。在规模、可触达性、契合度、价值、努力、竞争位置和复利上给每个候选细分市场打分，用1-3或高/中/低量表。虚假精确会招致争论6还是7，而不是争论细分市场。定义和每个标准的失败条件见 references/segment-dimensions.md。3. 按单位努力的价值排序，而不是按总分。把其他六个标准读作一个价值判断，然后除以努力，而不是把它加进去。努力是问题9中的前置制品清单，以构建周数和团队外是否有人必须同意来衡量。用一行说明结果顺序并展示除法，让读者能看到哪个细分市场输在分母而非价值上。4. 在任何人据此行动前，说明该比率饿死了什么。大、高价值、高努力的细分市场——通常是需要合规包和你尚未构建的SDK的企业平台团队——在它被排序的每一轮都输，只计算效率的团队永远不会资助它。在以下情况仍要提升它：它的制品已由其他东西资助；它内部一个参考解锁该细分市场其余部分；问题2的出资驱动因素是销售赋能，且没有更便宜的细分市场承载收入。5. 承诺形态：本周期一个主要细分市场。一个次要细分市场，只由主要细分市场已付费的制品服务。一个反细分市场，命名并给出原因（不可触达、无法变现、需要你无法构建的制品，或会压垮团队的支持负载）。6. 应用证据下限。由来自一致群体的少于5-10个独立数据点（访谈、工单、社区帖子、遥测队列）支持的细分市场是假设细分市场。保留在地图中，说明能确认它的最便宜测试，并在通过前不资助。
20. 知道这些规则从何而来。七个标准是本集合自己的复合。Moore的滩头测试（《跨越鸿沟》）覆盖其中四个，每个映射到一个评分标准：燃烧的痛苦（契合度）、支付意愿（价值）、可赢份额（竞争位置）、推荐潜力（复利）。用它作为完整性交叉检查，并保留其一条持久规则：证明只在细分市场内传播，所以集中参考胜过分散。5-10下限是客户研究实践惯例而非测量阈值，主要/次要/反细分形态是本技能自己的基线。有意移动任何一个并在地图中说明。
21. 第6步——写地图并逐节验证：在进入下一节前提交每一节供批准。逐节批准的地图能在有人最喜欢的受众被降级的会议上存活。地图模板：# Developer segment map - <product>, <horizon> ## Cut 两个维度，以及刻意拒绝的维度 ## Segments 3-5行：名称、定义、规模+置信度、决策单元、他们需要什么、他们在哪里聚集、该行背后的证据 ## Primary 所选细分市场、其得分、为何击败亚军 ## Secondary 只由主要细分市场已资助的制品服务 ## Anti-segment 本周期不服务谁，以及为什么 ## Hypotheses 低于证据下限的细分市场，以及解决每个的测试 ## Implications 现在改变什么：制品、渠道、证明，以及什么停止 ## Review 重新决策日期，以及强制提前重读的事件。完整工作示例地图、每节的弱版和强版，以及未通过门槛的被拒地图见 references/segment-map-example.md。
22. 调用示例：用户说"我们应该用API瞄准谁？"→完整运行第1-6步→返回分段地图，一次批准一节。用户说"我们应该追企业还是独立开发者？"→第1-2步然后停止——该问题预设了一个没人选择的切分→返回两到三个完整候选切分及推荐。用户说"有多少Rust开发者？"→仅第3步→返回带方法、日期和置信度层级的范围，以及该数字不能支持什么。用户说"我们的内容触达所有人却转化不了任何人"→从已发布内容重建隐含细分，然后第1、5、6步→返回带反细分市场的排序地图。用户说"谁真正签字购买我们？"→仅第4步→返回每个现有细分市场的决策单元及其强制拆分。"重跑我们的分段地图，是去年的"意味着针对存储的地图运行第3-6步，返回差异：什么移动了、哪些预测成立、哪些细分市场应退役。没有存储的上一版地图时，从第1步重建并说明对比已丢失。
23. 把地图作为用户可粘贴到自己文档的markdown返回。只在需要说明时用散文；其余一切是表格行。
24. 质量门槛：把地图保持在此阈值并迭代直到通过。最后明确报告检查。以下每个计数是本技能自己的基线，不是行业标准——每个背后的理由见 references/published-findings.md；团队可以移动一个，但地图必须说明原因。三到五个细分市场。两个通常意味着受众没被真正切分；六个意味着团队一个都服务不了。每个细分市场命名一个与至少一个兄弟不同的制品、渠道和证明点。相同的行意味着维度错了——回到第1步。每个规模带范围、方法、日期和置信度层级。每个细分市场命名其决策单元，或明确说明不存在购买。至少一半受资助的细分市场通过证据下限；其余标为带测试的假设。反细分市场非空，且包含至少一个团队想保留的受众。每个细分市场用其成员会认出的语言描述，而非内部类别名。整个地图适合两页并命名审查日期。
25. 如何知道细分奏效：细分是关于努力去向的押注，所以衡量押注而非文档。在地图发布前基线这些并在审查日期重读：集中度——主要细分市场在新注册、激活或贡献者中的份额上升，且团队能看到它上升。制品契合度——新制品服务一个命名细分市场；任何为泛泛"开发者"构建的东西计为失误。争论频率——团队重新打开受众问题的频率。有效的地图在一个周期内结束争论。预测准确性——审查时检查哪些定规模的细分市场实际按地图预测表现，并纠正定规模方法而非结论。在以下任何情况强制提前重读：定价或打包变化；新语言或运行时目标；出资驱动因素变化；竞争对手占据主要细分市场的默认位置；主要细分市场达到目标。
26. 常见失败模式："我们的受众是开发者。"一个人口，不是一个细分市场。然后每个制品都瞄准没有共同点的人的平均值。仅按资历细分。同一技术栈中的初级和资深开发者通常需要同样的东西；资历只在映射到权威或学习需求时才重要。没人据此行动的维度。如果两个细分市场会收到相同的工作，它们是一个细分市场加一个人口统计脚注。把人物角色当作散文画像或平均值。一天生活的段落读起来好但决定不了任何事，跨细分市场平均的人物角色代表不了任何人。带规模、决策单元、制品和证据的行才能决定。从你自己的漏斗定规模。第一方数据描述谁已经通过。未服务的细分市场在其中总显得小。没有反细分市场。没有书面排除，每个受众理论上都在范围内，努力在一个季度内重新分散。没有过期时间的地图。生态会变；没有审查日期的分段地图会悄悄变成去年的计划。
27. 参考文件：references/segment-dimensions.md——六个维度族及开发者特定取值、每个必须通过的测试，以及七个评分标准。references/sizing-sources.md——每个公开数据源测量什么、不能支持什么、估计形态，以及假设细分市场的廉价测试。references/decision-unit.md——用户/拥护者/批准者/买家角色、每个被什么说服，以及个人和公司采用如何改变细分市场定义。references/segment-map-example.md——完整工作分段地图、每节的弱版与强版，以及被拒地图。references/published-findings.md——每个有来源的声明及其来源和局限，以及本技能自己的基线。相关技能：samber/developer-relations-skills@developer-journey-map、@devrel-strategy、@developer-first-gtm、@devrel-metrics、@devrel-content-calendar、@developer-event-sponsorship。

适用边界 · 注意事项

• 当问题预设了一个尚未选择的切分时（如"该追企业还是独立开发者"），不要直接产出地图，只做第1-2步并返回候选切分与推荐。
• 当只需要一个数字（如"有多少Rust开发者"）时，不要跑完整流程，只做第3步并返回带方法、日期和置信度层级的范围。
• 当没有存储的上一版地图时，不要声称能做年度对比重跑，需从第1步重建并说明对比已丢失。