开发者布道师Developer Advocate这个职位这两年正处在一个很微妙的转折点上。说它要消亡有点夸张但如果你长期关注 DevRel 领域会发现一个无法忽视的变化过去靠博客、演讲、线下活动去影响开发者的那一套正在被 AI 工程AI Engineer用更安静、更直接的方式替代。我自己观察到的现象是很多团队的布道内容还在正常发布阅读量也没有崩盘但真正影响开发者决策的路径已经变了。开发者遇到一个新 API第一反应不再是搜博客、参加会议而是打开一个 AI 编程助手让它帮忙解释、写样例、排错。于是产品的“嘴”从写文章的人变成了能被 AI 正确理解和调用的那套工程接口。这里不打算下一个耸人听闻的结论而是想把这轮变化拆开看布道师在传统技术生态里到底承担了什么AI 改掉了哪一环哪些能力会被替代哪些能力反而更值钱以及现在还站在这个位置上的人下一步可以往哪里走。适合读这篇文章的人有三类正在做开发者关系、技术内容、开发者社区的人负责产品技术推广的技术负责人以及还在观望要不要进入 DevRel 这个方向的工程师。前两类可以重点看转型路径第三类可以先看判断标准。1. 先给“消亡”这个说法做个校准1.1 布道师的本质是技术组织和外部开发者之间的翻译层开发者布道师并不是一个纯粹的营销岗位。它的核心职责是把一个技术产品翻译成外部开发者能快速理解、快速上手、愿意持续使用的东西。翻译的方式很多样官方文档、示例代码、技术博客、大会演讲、线上直播、Meetup、Hackathon以及在各种社区和群里回答开发者的具体问题。这个岗位的价值本质上建立在两件事上。第一信息不对称。产品团队自己写的技术文档经常默认读者已经了解背景。外部开发者缺少这些上下文会遇到大量“文档里没写清楚”的细节问题。布道师要补上这层上下文。第二信任传递。开发者不会因为厂商一句“很好用”就接入一个 SDK。他们更愿意相信一个看得见、能对话、敢在现场接住问题的真实的人。布道师实际上是厂商建立技术信任的前哨。所以布道师看似在写内容、办活动实际在做的是两件事降低开发者的理解成本以及降低开发者的信任成本。一旦把岗位拆到这个层面再去看 AI 带来的变化思路就会清楚很多AI 能不能降低理解成本能而且做得很快。AI 能不能建立信任暂时不能这仍然需要真实的人长期投入。1.2 真正被重构的是“内容-活动-反馈”这个传统三角传统布道师的工作可以压缩成三个动作生产内容、组织活动、收集反馈。内容解决理解和传播活动解决信任和关系反馈解决产品迭代方向。这三个动作并不是同时失效的这正是很多团队现在感到迷茫的原因。内容这一环最先被 AI 冲击。开发者获取知识的方式从“人写文章给人看”逐步变成“人问 AIAI 读文档后给答案”。如果一篇博客写的知识AI 用几秒钟就能总结出来那这篇博客作为传播载体的边际价值就大大下降。活动这一环影响稍微滞后但线下活动最核心的产出其实是“交流现场和真实反馈”。如果现场只是单向宣讲它的价值就会快速缩水。反馈这一环反而没有减弱只是在改变渠道。开发者现在更多在 AI 工具的对话里表达困惑在错误日志里暴露问题。这些信息不再通过布道师的表格收集而是通过可观测的接入日志、模型评测、任务成功率等工程指标直接出现。换句话说布道师传统三角里“内容”正在被机器替代“活动”正在被两极分化“反馈”正在从数据化走向工程化。整个岗位的底座变了。2. 开发者获取信息的方式变了布道逻辑才跟着变2.1 开发者现在更习惯“先问 AI再查文档”前几年一个开发者要接入某个云服务或开源 SDK常规路径是打开搜索引擎、找到官方文档、翻到一个示例、复制到本地跑一遍、遇到报错再回来查。这条路径里搜索引擎和文档是主要入口。现在这条路径正在被压缩。越来越多的开发者尤其是年轻工程师遇到技术问题后的第一反应是问 AI 编程助手。它可以直接根据当前项目的代码上下文给你一段能用的示例甚至直接告诉你报错原因和修复方式。这个转变看起来只是入口变了实际上影响很深。因为开发者问 AI 时AI 的答案质量取决于它所依赖的上下文有哪些官方文档、示例是否完整、API 命名是否语义清晰、错误信息是否可读。换句话说文档团队的产出不再只是给人浏览的网页而是 AI 用来生成答案的原材料。如果你在一个技术内容平台工作看到后台阅读量下降第一反应可能是内容质量不行。但实际上很可能是读者已经不需要通过你的文章来获取这些知识了。这不是说内容没有价值而是内容的存在形式已经不适合新的消费方式。2.2 文档和示例从“给人读”变成“给 AI 读”“给 AI 读”这一点很多团队还没真正转过来。一个典型的情况是官方文档写得非常详尽有大量完整段落和背景说明但缺少结构化信息。LLM 在回答问题时会优先从上下文里抽取与问题直接相关的片段。如果一个 API 的参数说明、输入输出示例、错误码含义分布在好几页文档里没有被清晰地组织起来AI 给出的答案大概率是含糊的甚至是错的。反过来如果把同样的信息整理成结构化、带明确输入输出的示例再加上少量高质量的问题模板AI 基于这些材料回答准确率会高很多。这个差异不是玄学而是检索增强RAG和上下文工程里非常实际的问题。所以现在有一个概念逐渐被接受文档不仅要给人写好还要给 AI 消费好。什么意思呢就是你写完文档后要拿一个 AI 助手来“读”一下看它能不能准确回答关于产品的常见问题。如果你的文档能被 AI 正确消费你的产品就等于多了一个 24 小时在线的“布道师”。这一点上传统的布道师如果愿意把技能重心从“写漂亮的文章”转到“写结构清晰、AI 能消费的资料”反而是有机会的。因为这里面最难的不是会写文档而是知道开发者关心什么、什么问题最常被问、什么样的示例最有代表性。这些判断力恰恰是布道师多年积累的优势。2.3 为什么这个变化比想象中更彻底很多人会觉得AI 生成的内容质量一般开发者最终还是会回来看文档、看博客。这个判断在部分场景下是对的但用来指导职业选择就很危险。关键在于AI 的能力正在快速迭代。一年前还只能写简单代码片段的模型现在已经可以在真实工作流里处理多文件修改、执行命令、读取日志、调用 API。作为从业者不能拿“当前 AI 生成的文档质量不行”来安慰自己。更稳妥的判断方式是假设 12 到 18 个月之后AI 能产出 80% 质量的内容我的工作内容里有多少还是不可替代的这个变化更彻底的地方在于它改变了技术传播的“带宽”。过去一个布道师写一篇文章即使写得很好也只能影响几千个读者而且这些读者还要主动找到这篇文章。现在一个结构良好、能被 AI 正确引用的 API 文档和示例会被大量地嵌入到 AI 的回答里。信息的传播不再依赖“人的注意力”而是依赖“机器能否正确提取”。谁的资料能被 AI 正确消费谁就拥有了更高的传播带宽。这种转变不是把文章写得更长、更详细就能应对的。它要求你换一种方式思考产出物一篇文档不是终点而是一个可以被反复检索、拼接、复用的知识单元。3. AI Engineer 凭什么接住“桥梁”这个位置3.1 AI Engineer 的产物是“让 Agent 自主跑通”的工程AI Engineer 这个词在 2023 到 2024 年逐渐成为一个清晰的岗位方向但它不是简单的“会调 API、会写 prompt”。它的核心工作是构建以 LLM 为主体的系统包括上下文管理、工具调用Function Calling、外部接口接入、结构化输出、评测与回归以及整个流程上的稳定性设计。这里和布道师有一个非常有意思的交集。布道师过去做的事情是让“人”这个终端能顺利使用产品AI Engineer 做的事情是让“AI 代理Agent”这个新终端能顺利使用产品。区别在于Agent 调用产品的方式更加机械化、严格化。它可以理解自然语言但一旦涉及 API 调用、参数格式、返回结构就要求产品接口极其明确、容错处理极其完善。换句话说AI Engineer 正在成为一个新的“翻译层”只不过它翻译的对象不再是内容和情感而是接口、协议和工具描述。在 AI 应用爆发的背景下越来越多产品的“使用者”从人变成了 Agent。谁来告诉 Agent 该怎么正确使用产品就是这个新的工程角色。3.2 从单向宣讲到双向构建桥梁角色的工程化传统布道师的桥梁是单向的把产品的信息传递给开发者再把开发者的反馈带回产品团队。这个循环是异步的周期长而且中间容易失真。开发者说“这不直观”产品团队听到的可能是“文档要改”实际可能是 API 命名不清晰也可能是示例代码没有覆盖关键场景。AI Engineer 做桥梁的方式完全不同。它不满足于“告诉别人怎么做”而是直接把“能跑通”变成产品的一部分。比如给模型定义工具描述让 Agent 可以自己调用产品的 API比如把官方示例压缩成几个高质量的场景化用例让 AI 在学习之后可以直接复用再比如建立一个评测集每次产品迭代后自动跑一遍看 Agent 完成任务的成功率有没有波动。这个变化的意义在于原来布道产生的效果是软性的、难以衡量的现在被转换成了一套可量化的工程指标。单次任务成功率、平均接入耗时、Agent 首次调用成功率、长尾报错数量每一个都像代码质量指标一样清晰。当产品的“可被使用性”可以被这样度量时谁来掌握这个度量和优化谁就掌握了下游开发者的真实体验。3.3 传统布道与 AI Engineer 的能力对照表我整理了一个简化对照帮助判断这两个角色的差异。它不是严格的岗位定义更多是观察行业现状后的一个坐标。维度传统布道师AI Engineer核心产出文章、演讲、活动、社区内容工具接入、Agent 示例、自动化链路、评测集主力媒介人的注意力LLM 上下文和工具接口服务对象开发者本人开发者以及开发者身边的 AI 助手衡量指标阅读量、到场率、注册数任务成功率、接入耗时、首次调用成功率反馈链路收集意见再转给产品直接在代码和评测中改进体验技能重心表达、传播、关系维护系统设计、上下文工程、评测、调试这张表不是要说明布道师毫无价值。恰恰相反AI Engineer 如果想真正做好“开发者体验”这层工作仍然需要大量来自真实社区、真实故障现场、真实使用痛点的输入。而这些输入过去主要靠布道师长期泡在社区里才能获得。问题在于谁能把这些输入转化为工程方案谁就能在下一轮里占据主导。这就是我理解的真正变化布道的“表达”仍然重要但“构建”越来越重要能够同时掌握表达能力和工程能力的人会非常稀缺。4. 哪些布道能力会被替代哪些反而更值钱4.1 会被 LLM 快速覆盖的通常是模板化产出先说容易被替代的部分。第一类是通用教程和模板化 Demo。比如“如何调用某某 API 实现某某功能”这类文章LLM 已经能根据公开文档生成不错的版本。读者如果想要一个能跑的示例AI 给他的速度比看博主文章更快而且还能根据他的代码环境做适配。第二类是常规报错汇总和 FAQ。这些内容是纯信息搬运AI 在学习了文档和社区帖子之后可以给出足够好的答案。布道师反复回答“为什么这个接口返回某个状态码”这类问题价值会越来越低。第三类是形式大于内容的宣讲型演讲。如果一场分享的核心内容是把文档里的知识点换一种方式复述一遍听众自己用 AI 花十分钟就能获得同样信息。这类演讲的长期价值很有限除非现场有真实的互动、案例演示和即兴问题处理。我接触过一些团队布道师每周花大量时间维护博客、制作 PPT、整理会议资料。这些工作并不是没有用但它们的替代成本正在迅速下降。如果一个人 80% 的时间都在做可以被 LLM 快速复现的事情这个岗位的风险就很高。4.2 不容易被覆盖的是真实场景判断和信任积累再说不容易被替代的部分。首先是真实故障现场的经验。开发者在使用产品时遇到的问题很多不是文档表面上能看出来的。比如某个参数在特定环境下会触发奇怪的兼容性问题某个接口在高并发下有行为差异某个 SDK 在不同操作系统上的表现不一致。这些经验只有在真实支持场景里摸爬滚打才能积累。AI 可以读懂文档但要准确识别这些隐含的问题需要高质量的真实案例作为输入而布道师是最早接触这些案例的人。其次是判断力。什么样的功能值得重点宣传什么样的接口设计会让新用户三天之内放弃什么样的反馈应该上升到产品决策层面而不是停留在文档修改层面这些判断需要同时理解技术原理、用户心理和产品战略。LLM 可以提供信息和选项但最后拍板的人仍然要有足够的判断依据。第三是社区信任。技术社区本质上还是人的网络。一些布道师在开发者社区里积累了多年口碑大家信任他的代码示例、技术判断和承诺。这种信任无法通过批量生成内容获得必须在长期互动中一点点积累。在新市场、新项目、新产品冷启动阶段这种信任尤其值钱。这里有个很关键的判断容易被替代的是“信息搬运”不容易被替代的是“经验判断”和“信任关系”。布道师真正要维护的应该侧重于后者。4.3 给自己的三个判断问题如果你现在正在做布道、DevRel、技术内容相关的工作可以拿下面三个问题快速自查。第一把我最常回答的 20 个开发者问题整理成一份提示词交给一个 AI 助手它能给出多少正确答案如果它能答对大部分说明你的工作里有很大一部分是“可机械化”的那些它答不出来的才是你该投入的方向。第二我最近一个月产出的东西有多少是只有我能做、别人和 AI 都做不出来的注意这里不看数量看独特性。如果答案接近零你的位置很容易被替代。第三如果明天公司砍掉这个岗位产品的开发者使用体验会不会立刻变差如果答案是“不会”原因通常不是公司不缺布道师而是布道工作并没有真正和产品形成有效的反馈链路。这是需要警惕的情况。这三个问题不是拿来制造焦虑的它们的真正价值是帮你判断下一步时间应该花在哪里。5. 布道师转向 AI Engineer 的实操路径5.1 先做一轮“自我替代测试”转型的第一步不是先去学一堆 AI 课程而是先看清楚自己的日常产出里哪些会被 AI 替代。这一步非常重要因为只有知道了自己的“能力洼地”转型才有针对性。具体做法不复杂。第一步收集你过去一个月在社区、工作群、私人提问里回答过的 20 个高频问题去重后整理出来。第二步给每个问题写清楚背景、输入信息和期望输出整理成一份带上下文的提示词。第三步把这些问题交给一个当前主流的 AI 助手逐个看它的回答质量。然后做两个判断它回答得好的问题属于你工作中“信息搬运”的部分这部分以后不需要你投入大量时间它回答得差的问题才是你的真正价值所在。它为什么回答得差是缺乏案例是产品文档不完整是问题本身需要现场调试这些问题就是你转型 AI Engineer 时最应该第一时间投入解决的方向。注意这个测试的目标不是证明“AI 能替代我”而是找出“AI 做不好的那部分”。之后的所有转型动作都要围绕这部分展开。这个测试本身也是很好的学习过程。你会发现很多“做了很久的事情”其实可以自动化和半自动化也会发现真正的壁垒往往不在内容本身而在上下文和经验判断。5.2 把内容生产流程改成“AI 起草人判断”很多布道师转型时有一个误区为了跟上潮流强迫自己学 prompt、学大模型 API但日常产出还是一堆静态文章。这样转型是表面的因为你没有改变工作的底层结构。更实际的做法是先把内容生产流程重构成“AI 起草、人验证、人来判断”的模式。举个例子你接到一个任务要写一篇关于产品新功能的教程。以前你会从零开始写现在可以这样拆第一步把新功能的所有接口文档、示例代码、变更日志喂给 AI让它生成一份教程初稿。第二步你按初稿里的步骤在真实环境里跑一遍验证每一步是否真的能跑通。第三步找出 AI 生成的输出里不符合实际的地方逐个修正。第四步把最终版本整理成带结构化输入输出的形式再做一次“AI 消费测试”也就是让另一个 AI 根据这份教程回答相关问题看回答是否准确。这套流程看起来只是多了一步“让 AI 参与”实际上角色的变化非常大。你从内容的“生产者”变成了内容的“编辑、验证者和质量负责人”。这个转变恰恰是 AI Engineer 日常工作的核心状态模型产出、人来验证、人来兜底。5.3 用一个最小 AI 工程项目完成身份切换当你对 AI 的日常协作已经熟练下一步就是真正动手做一个小项目让别人认可你是 AI Engineer而不只是“会聊 AI 的内容运营”。不用贪大一个最小项目就够了。我建议这样设计选一个你最熟悉的 API 或开源项目这个项目你平时已经写过大量示例、知道很多常见问题接下来把它改造成一个“Agent 能自主调用”的形态。具体包含三个部分。第一写清楚这个 API 的功能描述、参数说明、输入输出格式整理成工具定义或结构化描述。第二给 LLM 设计一个能调用这个 API 完成真实任务的流程。第三准备一个 5 到 10 条任务的评测集每条任务有明确输入和期望输出跑一遍记录成功率。比如把自己最熟悉的那个接口包装成一个工具定义简化后的结构大概是这样的{ tool_name: create_async_task, description: 创建一个异步任务并返回任务 ID, parameters: { type: object, properties: { task_id: { type: string, description: 调用方生成的唯一任务编号 }, callback_url: { type: string, description: 任务完成后回调的地址 } }, required: [task_id, callback_url] } }这个示例的重点不是 JSON 语法而是你开始用“机器可读”的方式描述产品能力。写完工具定义后再让 LLM 根据这个描述实际调用一次看结果对不对。项目规模不大但它覆盖了 AI Engineer 的核心工作上下文设计、工具接入、评测与验证。做好这一个项目比报名十门课程都更有说服力。面试时你可以说“我不仅读过 AI 的东西还真的把一个产品改造成了 Agent 可用、可评测、可验证的形态。”这比任何证书都值钱。5.4 转型后的三个长期动作项目做完只是开始。长期来看我认为有三件事值得持续做。第一持续更新评测集。随着产品功能的迭代原来的评测任务可能不再适用。你要养成一个习惯每次产品版本更新都顺手把评测集里的任务过一遍看成功率有没有变化。这个动作听起来简单却是 Agent 时代最核心的质量保障手段。第二把布道资产转化成 AI 可消费的资产。过去写的博客、录的课程、做的分享可以逐步重新整理成结构化格式带准确参数的 API 说明、可复现的代码示例、分场景的故障排查清单。这些资产不仅对人有价值对 AI 也有价值。第三保留并强化自己的“社区感知力”。当你已经具备工程能力后原来的沟通、表达、判断能力反而会成为差异化优势。很多 AI Engineer 会写代码但不一定懂开发者真正卡在哪里。你如果能同时做好这两件事在团队里的位置会非常稳固。6. 真正该盯住的不是职位名称而是你是否还在“单向输出”6.1 出现危险信号时就应该调整方向话题回到开头。开发者布道师会不会真的消亡我更愿意换一种表达被淘汰的不是“布道师”这个名称而是“只会单向输出、无法参与构建”的工作方式。如果你发现自己出现下面这些情况就要开始调整了。第一个信号团队的核心指标还是阅读量、播放量、到场人数而你的产出和产品实际使用数据之间没有任何可验证的关联。这通常意味着你只是内容的搬运者没有进入产品反馈和迭代的链路。第二个信号你已经很久没有写过真实代码或者你的工作不需要接触产品仓库只需要面向市场和公关部门汇报。当一个布道师失去工程触角他的所有判断都会逐渐浮于表面。这不是个人能力问题而是岗位设计问题。第三个信号你今天写的文章和两年前写的同类文章在结构和深度上没有明显变化而开发者获取信息的路径已经完全改变。如果生产方式没有进化而 AI 能力继续提升被替代只是时间问题。判断岗位是否危险不要只看职位名称要看工作内容里有多少是“只有我才能完成的事情”。出现任意两个信号都值得认真考虑一次转型而不是继续靠调整内容选题来续命。6.2 三条比“继续开大会”更稳的路线如果判断自己确实需要转型路线其实很清楚。我观察下来目前至少有三种比较稳的方向。路线 A转 Developer Experience Engineer 或 AI Experience Engineer。直接负责“Agent 能否顺利使用产品”这件事包括工具描述、示例工程、自动化评测和接入日志分析。这条路线最适合有强烈工程倾向的人因为你不需要自己设计大模型只需要把产品的“AI 友好度”做到可量化。路线 B转 AI 应用开发的 Solution Engineer 或 Sample Engineer。做模板、脚手架、参考应用帮外部开发者更快把 AI 应用搭起来。这条路线适合仍然喜欢面对开发者、喜欢做示例的人只是产出物从“讲给你听”变成“写给你抄”。路线 C转内部 AI 工程布道。帮自己公司的研发团队落地 AI 工具和流程比如建立内部的 AI 编程助手使用规范、做工具评测、沉淀内部最佳实践。这条路线适合大厂里熟悉组织运作的人本质上是用布道能力服务内部工程效率。三条路线的共同点是都要求你具备一定工程能力都能保留你原有的一部分优势要么是开发者同理心要么是组织协作能力要么是长期积累的技术判断力。6.3 把“布道”重新定义为一个可验证的产品能力最后说点更个人的观察。我见过一些团队把“开发者布道”这件事做得非常古典出内容、办会议、请人站台、晒数据。也有团队开始尝试另一种做法把产品的文档、示例、工具描述整合成一个完整的“AI 体验包”让任何人的 AI 编程助手第一次使用产品时都能在合理时间内完成一个真实任务同时把“任务成功率”作为正式的产品指标每次发布都跑一遍回归。这两种做法我不认为哪个就是错的。它们阶段不同、团队条件不同。但长期来看第二种做法的抗风险能力明显更强。因为它的结果可度量、可回归、可优化并且它把注意力从“让多少人知道”转移到了“让多少人和多少 Agent 能真正用起来”。所以如果你问开发者布道师是不是真的要消亡我的回答是作为“单向地宣讲产品”的岗位它的黄金时代确实在收尾作为“构建可验证的开发者体验”的能力它反而正走进被工程化的阶段。名字可以改汇报线可以变但只要你掌握的那个能力本身是稀缺的、可度量的、能解决问题的就不怕它换一个载体。我更建议的做法是在别人还在讨论“布道会不会死”的时候你已经把自己手头最常被问的那 20 个问题整理成一份 AI 回答不了、必须依赖真实经验和代码验证的资产。这才是这轮变化里最值得提前做的一件事。