Update nexus wiki content
This commit is contained in:
@@ -1,58 +1,54 @@
|
||||
---
|
||||
title: "Specialized Developer Advocate"
|
||||
title: "Developer Advocate"
|
||||
type: source
|
||||
tags: [agent, specialized, developer-relations, community, developer-experience]
|
||||
date: 2026-04-20
|
||||
tags: [developer-experience, community-building, technical-content, the-agency, specialized]
|
||||
date: 2026-04-30
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Agent/agency-agents/specialized/specialized-developer-advocate.md]]
|
||||
- [[Agent/agency-agents/specialized/specialized-developer-advocate]]
|
||||
|
||||
## Summary(用中文描述)
|
||||
- 核心主题:Developer Advocate Agent——The Agency Specialized 部门的开发者关系工程师,通过提升开发者体验(DX)、创建高质量技术内容、建立真实社区联系,将产品与外部开发者紧密连接,最终推动平台采用和商业价值增长。
|
||||
- 问题域:开发者关系(DevRel)、开发者体验优化、技术内容营销(区别于传统营销)、社区运营、产品反馈闭环。
|
||||
- 方法/机制:DX 工程审计(Time-to-First-Success)→ 技术内容创作(教程/演示/演讲提案)→ 社区运营(GitHub/Discord/Slack 响应、Hackathon、大使计划)→ 产品反馈闭环(月度 Voice of Developer 报告)。
|
||||
- 结论/价值:Authenticity(不 astroturf)是开发者关系唯一可持续的资产;DX 改善(错误信息/SDK)比内容创作影响更深远、更持久;开发者成功(Developer Success)≠ 营销。
|
||||
- 核心主题:The Agency 的 Developer Advocate(开发者倡导者)专业智能体——定位于产品团队与开发者社区之间的桥梁,通过真实的技术参与提升开发者体验(DX)、驱动平台采用率、建立开发者信任。
|
||||
- 问题域:开发者社区参与度低、文档质量差、SDK 体验不佳、产品反馈闭环缺失、技术内容供给不足。
|
||||
- 方法/机制:DX 工程审计 → 技术内容创作 → 社区运营 → 产品反馈闭环四步工作流;内置 DX Audit Framework、Viral Tutorial Structure、Conference Talk Proposal Template、GitHub Issue Response Templates 等标准化交付物。
|
||||
- 结论/价值:开发者倡导者的核心资产是社区信任(AstroTurf 会永久摧毁);DX 改进(错误消息/TypeScript 类型/SDK 修复)的价值随时间复利增长,优于单纯的内容产出。
|
||||
|
||||
## Key Claims(用中文描述)
|
||||
- **开发者体验优先**:DX 改善(更好的错误信息、TypeScript 类型、SDK 修复)复合效应永远优于新内容发布;修复前 3 大 DX 问题再发布任何新教程。
|
||||
- **真实性是核心资产**:虚假社区参与(AstroTurf)会永久性摧毁开发者信任;保持技术准确性比发布空内容更重要。
|
||||
- **时间度量价值**:新开发者"首次成功调用 API"时间 ≤ 15 分钟;GitHub 问题工作日首响 ≤ 24 小时;教程完成率 ≥ 50%;开发者 NPS ≥ 8/10。
|
||||
- **内容先听后创**:先读过去 30 天所有 GitHub Issue(发现高频痛点)、搜索 Stack Overflow 最新提问(识别理解障碍)、审查社交媒体情绪(获取无过滤反馈),再创作有针对性的内容。
|
||||
- **产品反馈闭环**:将开发者声音量化(17 个 GitHub Issue + 4 个 Stack Overflow 问题 + 2 场大会 Q&A = 同一功能缺失的证据)带入产品规划会议。
|
||||
- **开发者体验优先原则**:在发布任何新教程之前,必须先修复排名前 3 的 DX 问题;DX 改进长期复利,内容有半衰期。
|
||||
- **真实性伦理约束**:绝不做 AstroTurf(虚假社区参与);社区信任是开发者倡导者唯一的资产,一旦损坏永久不可逆。
|
||||
- **社区→产品的代理角色**:开发者倡导者首先对开发者负责,其次才对公司负责——必须将开发者痛点转化为有证据支撑的产品需求。
|
||||
- **可量化成功指标**:新开发者首次成功 API 调用时间 ≤15 分钟、GitHub issue 首响时间 ≤24 小时、教程完成率 ≥50%、开发者 NPS ≥8/10。
|
||||
- **技术内容质量标准**:所有代码示例必须无需修改即可运行;不为非 GA 功能发布教程(除非明确标注 Preview/Beta)。
|
||||
|
||||
## Key Quotes
|
||||
> "You don't do marketing — you do developer success." — 开发者关系工程师的身份定位:Authentic 技术参与,而非商业推销
|
||||
> "DX improvements compound forever; a tutorial has a half-life." — DX 改善的持久价值 vs. 内容创作的时间衰减
|
||||
> "A tutorial with an active author gets 3x the trust." — 作者持续维护对内容可信度的放大效应
|
||||
> "Five people at KubeCon ask the same question — that means thousands more hit it silently." — 大会 Q&A 模式的大规模推断价值
|
||||
> "You don't do marketing — you do developer success." — Developer Advocate Agent 核心定位
|
||||
|
||||
> "Authentic community trust is your entire asset; fake engagement destroys it permanently." — Advocacy Ethics 核心原则
|
||||
|
||||
> "Fix the top 3 DX issues before publishing any new tutorials." — DX-first 工作流原则
|
||||
|
||||
> "Conference Q&A patterns — 5 people ask the same question = 500 have the same confusion." — 社区反馈信号放大原理
|
||||
|
||||
## Key Concepts
|
||||
- [[DeveloperExperienceEngineering]]:审计并改善"首次 API 调用时间",构建示例应用、启动工具包和代码模板,量化 DX 质量。
|
||||
- [[TechnicalContentCreation]]:教程/博客/视频脚本/交互式演示(CodePen/CodeSandbox/Jupyter),内容先以最终效果开头而非"本教程将……"。
|
||||
- [[CommunityBuilding]]:GitHub/Stack Overflow/Discord/Slack 真诚技术响应;大使计划(Ambassador Program);Hackathon/Office Hours。
|
||||
- [[ProductFeedbackLoop]]:将开发者痛点转化为可操作的产品需求(用户故事);月度 Voice of Developer 报告。
|
||||
- [[DeveloperOnboardingAudit]]:DX 审计框架,分阶段(Discovery/Account Setup/First API Call)计时评分:🟢 <5min | 🟡 5-15min | 🔴 >15min。
|
||||
- [[AmbassadorProgram]]:分层次贡献者认可机制,与社区价值观一致的真实激励。
|
||||
- [[ContentStrategyAtScale]]:发现层(SEO 教程)→ 激活层(Quick Start)→ 留存层(高级指南)→ 倡导层(案例研究)的漏斗模型。
|
||||
- [[DeveloperNPS]]:开发者净推荐值,季度调查,目标 ≥ 8/10。
|
||||
- [[Developer Experience Engineering]]:审计并改善"首次 API 调用时间"或"首次成功时间",消除 onboarding、SDK、文档和错误消息中的摩擦点。
|
||||
- [[Technical Content Creation]]:编写教程、博客、视频脚本、会议演讲,核心理念是"先展示最终结果,再解释如何实现";代码示例必须零修改运行。
|
||||
- [[Community Building & Engagement]]:通过 GitHub Issues、Stack Overflow、Discord/Slack 提供真实技术支持,建立大使/冠军计划,组织 hackathons 和 office hours。
|
||||
- [[Product Feedback Loop]]:将开发者痛点转化为可操作的产品需求,用证据而非轶事在产品规划会议中代表开发者声音。
|
||||
- [[Advocacy Ethics]]:绝不 AstroTurf、技术准确优先、为开发者代理、公开关系披露、不过度承诺路线图。
|
||||
|
||||
## Key Entities
|
||||
- [[GitHub]]:开源社区核心阵地;Issue 响应质量是开发者信任的关键指标;响应时效目标:工作日 ≤ 24 小时。
|
||||
- [[StackOverflow]]:开发者问题解答平台;搜索平台名称按最新排序可发现理解障碍点;回答率目标:≥ 90%。
|
||||
- [[DiscordSlashSlack]]:实时社区沟通渠道;无过滤情绪分析来源;Office Hours 和 Hackathon 活动平台。
|
||||
- [[OpenTelemetry]]:社区健康指标监控(错误率、文档搜索成功率等)框架。
|
||||
- [[KubeCon]]:顶级开发者大会;5 人问同一问题 → 数千人无声遇到同样障碍的推断方法论。
|
||||
- [[The Agency]]:该 Agent 所属的 The Agency 项目,提供 12 个业务部门的专业智能体。
|
||||
- Developer Community(开发者社区):Developer Advocate 的首要服务对象和反馈来源。
|
||||
|
||||
## Connections
|
||||
- [[automation-governance-architect]] ← informs ← [[ProductFeedbackLoop]](产品反馈与治理评审互补)
|
||||
- [[specialized-mcp-builder]] ← depends_on ← [[DeveloperExperienceEngineering]](MCP Builder 的 DX 改善依赖开发者体验工程原则)
|
||||
- [[design-ux-researcher]] ← informs ← [[DeveloperOnboardingAudit]](UX 研究方法论应用于 DX 审计)
|
||||
- [[ContentStrategyAtScale]] ← supports ← [[ProductFeedbackLoop]](内容策略放大产品反馈影响力)
|
||||
- [[CommunityBuilding]] ← depends_on ← [[DeveloperExperienceEngineering]](社区健康依赖底层 DX 质量)
|
||||
- [[specialized-mcp-builder]] ← extends ← [[specialized-developer-advocate]](MCP Builder 扩展了开发者工具能力,Developer Advocate 负责传播和推广)
|
||||
- [[backend-architect-with-memory]] ← depends_on ← [[specialized-developer-advocate]](后端架构师产出的 SDK 和示例应用依赖 Developer Advocate 的 DX 反馈优化)
|
||||
- [[specialized-workflow-architect]] ← shares_workflow ← [[specialized-developer-advocate]](两者都使用结构化模板驱动工作流)
|
||||
|
||||
## Contradictions
|
||||
- 与 [[specialized-workflow-architect]] 存在设计哲学张力:
|
||||
- 冲突点:快速交付 vs. 质量保障。Developer Advocate 优先修复 DX 问题再发布内容("修复前 3 大 DX 问题再发布任何新教程");Workflow Architect 优先快速交付功能。
|
||||
- 当前观点:DX 改善复合效应优于快速内容发布,内容发布前必须有可运行的代码样本。
|
||||
- 对方观点:快速迭代需要尽早发布并通过真实用户反馈迭代,内容质量可随时间改进。
|
||||
- 与 [[engineering-technical-writer]] 潜在冲突:
|
||||
- 冲突点:技术写作与开发者倡导者都产出手册和教程,但目标受众和交付标准不同。
|
||||
- 当前观点(Developer Advocate):教程必须先展示最终结果,必须包含失败模式和调试方法,代码必须零修改运行,不为非 GA 功能发布教程。
|
||||
- 对方观点(Technical Writer):文档以参考完整性优先,覆盖所有 API 端点和参数,面向不同熟练度的开发者分层提供内容。
|
||||
- 协调方案:Developer Advocate 负责"教程/快速入门/演示"等引导式内容;Technical Writer 负责"API 参考/规范文档/操作指南"等查阅式内容;两者共享 DX 反馈回路。
|
||||
|
||||
Reference in New Issue
Block a user