当需要绘制开发者旅程地图、诊断开发者采用漏斗在哪一阶段流失…

为一个开发者受众细分绘制从发现到倡导的逐阶段旅程地图，并诊断下一个最值得修复的单一流失点。

适用场景

解决思路

1. 先访谈，一次问一个问题并尽量给出选项，直到能说出细分受众、期望终态和可用证据为止；其余信息在起草时确认。访谈需覆盖：产品是什么及开发者实际动作（调用 API、安装库、部署基础设施、扩展平台、贡献仓库）；单一受众细分（每个细分一张地图）；本阶段关心的终态（生产使用、付费转化、合并贡献、公开倡导、组织内标准化）；开发者是买家、影响者还是都不是，谁签字、何时出现；产品是自助、销售辅助、免费开源还是混合；已有证据（分析、注册来源问题、支持工单、社区帖子、用户访谈、既有摩擦日志）；今天能观测到路径的哪些部分、可见性从哪里开始；每个开发者接触面的负责人（网站、文档、quickstart、SDK、仪表盘、支持、社区、仓库）；团队已有的流失假设及其依据；这是首张地图还是刷新；截止时间及谁在等它；要一次性诊断还是每季度重跑并对比；投入上限（只读已有数据，还是招募受访者并请其他团队加埋点），以及当前阶段命名已被哪些仪表盘、目标、其他团队漏斗依赖。
2. 若运行环境有持久记忆，把选定的细分、阶段模型、退出事件和当前信号值存进去，以便下季度重跑并与上一版对比。
3. 第 1 步：选择阶段模型，不要自创。先声明处于头脑风暴模式，暂不写行。两轮：先删除，再排序。
4. 删除：按访谈问题 3 的终态挑模型尾部，凡终态不匹配的模型全部移出菜单，并在 Scope 部分记录删了哪些及原因（标准化、收入、生产使用、贡献、倡导是不同终态，带三个尾部的图没有优先级）。刷新时除上一版模型外全部删除，除非该模型确实失效——与自身历史的可比性优先于更贴切的词汇。
5. 排序：对幸存模型排序并说出排序理由。这里的投入指在能计数某阶段边界前必须收集的证据，加上协调成本和可逆性。给出两到三个候选阶段模型（按效率排序），每个说明它让什么可见、隐藏什么、边界观测成本多少，推荐一个并说明原因，让用户在任何行被写下前做选择。
6. 效率排序参考：API 五阶段弧 > OSS 贡献者漏斗 > AAARRRP > Revell 六阶段 > 无来源默认。投入排序参考：Revell 六阶段 > AAARRRP > OSS 贡献者漏斗 > API 五阶段弧 > 无来源默认。刻意不设价值线——模型价值完全取决于其终态与受资助终态的匹配度。
7. 成本量级：API 五阶段弧的边界（首次调用、集成、生产）通常已在产品遥测中，约一小时到一周；OSS 贡献者漏斗约一周（仓库有首次 PR、评审延迟、回访，但招募放弃者慢）；AAARRRP 约一周到一季度（主要是与其他团队拥有的公司级漏斗协调）；Revell 六阶段约一季度（标准化边界需要账户汇总和买方访谈）。
8. 当受资助的问题正是“为什么团队采用但组织从不标准化”，或续约取决于成为组织级默认时，即使效率排序靠后也要提升 Revell 六阶段——它强制的账户汇总是重点而非成本。把两条排序线当默认而非定律，按团队已有埋点重排：已有公司级 AARRR 漏斗会降低 AAARRRP 协调成本并提升其到第一；已为销售建好账户汇总会移除 Revell 大部分成本；注册前无遥测的产品会降低 API 弧，因其早期边界正是不可观测的。
9. 其余指导：优先五到七阶段（本技能默认区间，非标准）；更少会隐藏阶段内流失，更多会产生没人能说出退出事件的阶段。仅当某阶段有两个不同退出事件且负责人不同时才拆分（如“评估”在阅读文档和本地试用由不同团队负责时可干净拆分）。使用已发布模型时保留其阶段名，以保持与领域词汇和项目策略的可比性。
10. 第 2 步：先收集证据再填任何行。按最便宜来源优先，每条发现标注所属阶段。
11. 亲自走一遍路径并保留摩擦日志（Google DevRel 实践）：一个真实场景，记录搜索、点击、粘贴和感受，用绿/黄/红标记；这是唯一能捕捉没人上报的流失的来源。
12. 挖掘开发者已写的内容——支持工单、issue、社区提问、无结果的文档搜索；按阶段聚类，最大簇是摩擦候选而非结论。
13. 访谈五到八位完成旅程的开发者，以及（更难招募但更有价值）三位放弃者；两个数字都是本技能默认值。
14. 在要求新埋点前，先读已有漏斗数据。
15. 在承诺信号前检查每个接触面实际能报告什么，三个修正影响最大：分析拦截——Plausible 2021 年 8 月在一个带 Hacker News 和 Reddit 流量的站点测得 58% 技术受众拦截第三方分析脚本（Linux 82.3%、Firefox 88.3%），这是有利益相关厂商的单站点测量但也是唯一公开数据，因此开发者接触面的绝对流量数字按页面不同有不同倍数的错误，只有同一来源内的比率可用；留存窗口——仓库流量端点保留 14 天、npm 下载 18 个月、PyPI 序列 180 天，从定义信号当天起就要快照，过期数据无法回填；引荐来源丢失——聚合器、聊天客户端、隐私浏览器和 AI 助手会剥离引荐来源，约 70% 的 AI 助手流量到达时无引荐来源（newsletter 估计，非研究），大量“直接”流量是常态而非埋点 bug。
16. 第 3 步：每阶段填一行，每行八个字段，其中三个加粗字段是区别于通用旅程地图的关键，缺任一则未完成：Stage（所选模型中的名称）；Developer's job（此人想完成什么，用他们的话而非厂商漏斗语言）；Entry trigger（启动该阶段的可观测事件）；Exit event（证明他们前进的单一可观测事件——首次成功 API 调用、首次部署到生产、首次合并 PR、首次演讲）；Touchpoints（涉及的接触面：文档页、仓库、CLI 输出、仪表盘、社区帖子、支持工单）；Owner（对该阶段退出率负责的一个人或团队）；Friction evidence（带来源的引用观察，绝不写假设，没有就写“no evidence yet”）；Signal（一个指标及其数据源和当前值，或 not instrumented）。
17. 不要通用旅程地图的两个列：情绪评分在开发者量级下会被编造并挤占可问责列；同一次写的机会清单会在知道哪个阶段流失前把地图变成待办列表。
18. 标记所有数字为推断而非测量的阶段——结合第 2 步的拦截和引荐丢失，早期阶段几乎总是如此；诚实的 inferred 标签保护后续结论，自信的假数字会摧毁它们。
19. 第 4 步：加入买方车道，或明确说没有。B2B 且开发者不是买家时，为经济买家加一条更短的车道——安全审查、法律与许可、采购、预算审批——在承诺或标准化处汇入；它有自己的退出事件（安全问卷通过、合同签署）和自己的负责人（通常在 DevRel 之外）。开发者车道并行继续：无法武装审批者的拥护者会卡在开发者车道显示不出的阶段。
20. 读买方车道前先把使用量汇总到账户：开发者车道数人，买方车道数组织；先按邮箱域名、工作区或许可证分组注册——同一家公司四十个注册在汇总前看起来像四十个线索。
21. 按购买意图递增读三个信号族：深度（生产使用、持续量、接入 CI）；扩散（同一账户内第二、第三位开发者）；边界接触（有人打开 SSO 或 RBAC 页面、问合规问题、触及席位上限、请求安全问卷）。边界接触最稀有、最强，是该车道最干净的退出事件——优先埋点。
22. 个人采用或 B2C 式自助：两条车道合并，开发者决定并付费或根本不付费；在地图上明确说明，而非留空买方车道，让后来的读者知道这是决定而非遗忘。
23. 无购买的开源：没有买方车道，但用户公司内部常有采用审批步骤（许可证兼容性、依赖政策）；把它建模为采用阶段的摩擦，而非一条车道。
24. 第 5 步：从行中抽出并单独陈述三个关键时刻：首次成功（开发者从产品获得真实结果的时刻，具体命名并注明今天耗时多久）；关键时刻（承诺或离开的点：决定放入真实项目、推荐、开 PR）；放弃点（证据显示大多数人实际停下的地方，通常比团队假设更早更平淡）。
25. 第 6 步：诊断流失。只在两个退出事件都被计数处计算阶段间转化率，其余标 inferred。
26. 只选一个阶段来修：既转化差又有能改变它的负责人的最早阶段。最早优先因为下游修复会被上方损失稀释；有主优先因为无主的建议只是愿望。先按每单位修复投入挽回的开发者数排序候选（文档修复和重新设计 onboarding 的一周成本不同），再以最早且有主作为平局决胜。
27. 说明该排序饿死了什么：后期高回报重修复阶段（标准化、倡导、贡献）永远赢不过早期便宜阶段，每季度重跑此图的团队可能多年不碰它。当最早流失阶段无主、其修复已在进行、或访谈终态正是该后期阶段时，提升它。
28. 低于约 30 个事件/周期时，发布带日期的原始列表而非比率——这是统计惯例而非 DevRel 发现，后期旅程阶段经常触及此下限。
29. 只与本地图上一版对比；其他公司发布的漏斗受众、产品成熟度和各阶段定义都不同。
30. 若多数行的负责人是 DevRel，把这作为关于组织的发现上报：意味着接触面没有可问责负责人，这比流失本身更严重。
31. 选定阶段后才说为什么流失，用 BJ Fogg 行为模型（B = MAP：行为在动机、能力、提示汇聚时发生）。B=MAP 解释一个阶段，不能给阶段排序；在选阶段前用它，会为一个从不是约束的阶段写出流畅的动机故事。流失阶段是未发生的行为，模型把原因分三类，各落到不同负责人：能力太低——步骤太长、需要未声明的前置条件、要求不熟悉的流程；由文档、开发者体验或产品修复。这是开发者受众的默认答案，Fogg 自己的方向性建议适用：提升能力而非鼓动动机，因为“动机不可靠，幸运的是能力可靠”。动机太低——该阶段没有展示值得付出努力的理由；由定位和产品营销修复。在开发者阶段做动机优先的修复通常意味着团队更愿意写文案而非移除步骤。提示缺失——他们能也愿意继续，但没人告诉他们；由应用内引导、生命周期内容或社区修复。
32. 第 7 步：写地图并逐节验证。交付物始终是含七个标题的单一 markdown 文档：Scope（细分、终态、所用阶段模型及原因）；Journey（阶段表，每阶段一行八字段）；Buyer lane（买方阶段，或明确写 none - self-serve）；Moments（首次成功、关键时刻、放弃点）；Leak（所选阶段、证据、为何胜过其他）；Handoff（谁负责修复、要看的信号、重读日期）；Gaps（标为 inferred 的阶段，以及什么能让它们可测量）。
33. 一次呈现一节并在写下一节前取得同意：在第一个标题处发现阶段模型错误只花一段，在流失诊断处发现则花整个文档。
34. 质量门：每阶段恰好一个退出事件，措辞为可观测事件而非心态；每阶段一个负责人，且至少一位在 DevRel 团队之外；至少 60% 阶段带有真实当前值的信号，其余写 not instrumented 并出现在 Gaps；每条摩擦声明引用来源，没有行混合证据与假设；恰好提名一个流失点，有指定负责人和重读日期；推断阶段在所有出现处标注；地图在一页可读尺寸内——否则阶段列表太长或单元格在承载散文。信号线不达标不阻塞：带着已命名的缺口发布，诚实的带洞地图胜过编造数字的完整地图，缺口成为埋点请求。
35. 避免常见失败模式：映射公司希望拥有的漏斗（阶段名取自销售管道描述内部流程而非开发者行为，用“开发者会认出这是他们做过的事吗”检验每个阶段名）；所有开发者一张图（业余爱好者、平台工程师和企业架构师几乎没有共同摩擦，选一个细分否则什么都别产出）；退出事件不是事件（“理解价值主张”无法观测、计数或拥有，“完整跑完 quickstart”可以）；全用分析填图（分析从注册后开始，已是旅程中段，之前一切需要定性证据或诚实的 inferred）；假设沉默即满意（设置失败的开发者很少提交任何东西，他们直接离开；某阶段没有抱怨不是该阶段有效的证据）；提名三个流失点（三个优先级等于没有，排序并修最早的有主那个）；B2B 跳过买方车道（地图会显示健康的开发者旅程旁边是停滞的管道，且两者都解释不了）；把地图当永久（发布、定价变化、文档重写或新 SDK 移动接触面时重读；超过两个季度的地图描述的是已不存在的产品）；借用其他公司的转化率（流传的数字是阶段定义不兼容的单公司轶事，引用会给地图虚假信心并掩盖唯一有意义的对比——与自身上一版对比）；把绝对流量数字写进早期阶段（第 2 步的拦截率使任何会话计数都是按页面变化的分数，保持同一来源内的比率并标注阶段为 inferred）。

适用边界 · 注意事项

• 不要用它来重写 quickstart 以提升转化——单阶段修复不需要七阶段产物，应路由到 developer-quickstart-guide 技能。
• 不要用它来构建开发者指标框架或决定目标细分——这些是地图的上游或下游，应路由到 devrel-metrics 和 developer-segmentation 技能。
• 不要用它来修复阶段——本技能只产出地图和流失诊断，不修复阶段。