过去几年开发者布道师Developer Advocate还是各大云厂商、数据库公司、开源项目争相招聘的“明星岗位”。但最近无论是海外还是国内技术圈关于“开发者布道师正在消亡”的讨论越来越多。与此同时AI Engineer 这一全新岗位正在快速崛起。两者之间有什么关联布道师这个工种是真的要消失了还是正在换一种形态这篇文章想结合行业变化、岗位职责和技术演进聊聊我对这个问题的理解也会聊聊 AI 时代下技术从业者应该如何调整自己的技能结构。1. 开发者布道师到底是个什么岗位1.1 布道师不是“搞关系的”是“技术翻译官”很多人对 Developer Advocate简称 DA的第一印象是“到处参加大会、认识很多人、发发礼品”。这种理解并不准确。布道师的本质是连接技术与开发者之间的桥梁。具体来说布道师做的事情通常包括把复杂的技术产品能力转化成开发者能直接理解的文档、示例代码和最佳实践。收集开发者在实际使用中的反馈反向推动产品团队改进 API、SDK 和文档。通过技术文章、演讲、直播、开源示例项目等方式降低新技术的上手门槛。在社区中帮开发者排错沉淀常见问题库。也正因为这个岗位需要“既能写代码又能写文章还要能登台演讲”它对人的综合能力要求很高。刚兴起那几年优秀布道师确实能给技术产品带来很强的增长杠杆。比如一个开源项目如果在技术社区里口碑好很大程度上依赖于布道师持续的内容输出和用户沟通。1.2 为什么会有人提出“布道师消亡”提出“消亡论”并不是说这个岗位立刻就没有了而是大家在思考一个问题当技术内容生产的效率被 AI 大幅提升之后传统布道师的核心价值还剩下多少过去布道师最耗时的工作是什么写教程文章一篇完整的入门教程可能要写 3 到 5 天。准备示例代码要为不同版本、不同平台维护多份示例。整理 FAQ把社区里出现的高频问题整理成体系化文档。录制视频内容剪辑、字幕、发布每一步都很耗时。现在这些工作的很大一部分已经可以用 AI 工具完成。写一篇基础 API 的使用教程把官方文档喂给大模型几分钟就能生成初稿。整理社区问题AI 也能自动聚类和归纳。如果布道师的工作重心只是“内容生产”那确实会被 AI 大量替代。但布道师的价值从来不只是“写东西”而是“建立信任”和“驱动采用”。这一部分很难被自动化。1.3 布道师与 AI Engineer 的边界AI Engineer 是最近两年最火的岗位之一。与传统的机器学习工程师ML Engineer不同AI Engineer 更多关注的是如何把大模型、RAG 架构、Agent 应用落地到真实业务中。他们不一定要从零训练模型但要非常擅长设计 Prompt 工程方案。搭建基于大模型的应用架构。做模型选型和效果评测。处理上下文管理、工具调用、Agent 工作流等工程问题。把 AI 能力和现有业务系统集成。表面上看AI Engineer 和开发者布道师是两个完全不同的职业。但从更宏观的视角来看AI Engineer 的崛起恰恰是在重新定义“技术传播”的方式过去我们通过文章和演讲传播技术现在越来越多的人通过 AI 应用、自动化工作流、开源 Agent 项目来展示技术价值。换句话说AI Engineer 正在成为“新形式的布道者”——用可运行的智能应用代替 PPT用 API 调用链代替架构图。2. 布道师工作重心的历史演变2.1 文档驱动时代写得多就是王道在早期云计算和开源生态刚起步的时候开发者接触新技术的路径相对单一。官方文档质量不高、社区资料少布道师如果能写出一篇结构清晰的博客就能迅速积累大量读者。那时候的布道师更像是“超级用户 技术作家”。核心考核指标是文章数量。演讲场次。社区活跃度。通过内容带来的注册量。这个阶段的布道师更像是“超级用户 技术作家”。核心考核指标是文章数量、演讲场次、社区活跃度和内容带来的注册量。2.2 开发者体验DX驱动时代不能只看输出量随着云厂商越来越多单纯靠内容量已经很难做出差异化。于是行业开始重视 Developer Experience开发者体验。布道师开始参与产品设计关注 API 是否好调、文档是否好查、报错信息是否友好、示例代码是否能直接跑通。这时的布道师角色从“内容生产者”变成了“开发者体验的产品经理”。除了写文章他们还会做 API 可用性测试。维护示例代码仓库。参与产品需求评审。建立开发者反馈闭环。到了这个阶段布道师的技术门槛其实变高了。一个完全不会写代码的人已经无法胜任这个岗位。2.3 AI 驱动时代个体产能被十倍放大到了 ChatGPT 出现之后的这两年内容生产的边际成本骤降。一个布道师可以在 AI 辅助下一天完成过去一周的内容产出。但问题也随之而来当所有布道师都能高效产出内容之后“内容数量”就不再是竞争壁垒。真正拉开差距的是谁能定位更真实的用户场景。谁能做出直接可用的示例应用。谁能在技术变化极快的时候给出准确判断。谁能建立开发者真正信任的“技术品牌”。这也是为什么很多布道师开始转型做 AI Engineer只有自己深度参与 AI 应用开发才能真正理解技术栈的痛点才能做出有说服力的内容。3. AI 时代布道师职能的变化方向3.1 从“写教程”到“写代码示例”我观察到一个很明显的变化过去技术大会上布道师的演示通常以 PPT 为主配一些代码截图。但现在越来越多的布道师选择直接在大会上写代码现场搭一个 Agent调用真实 API让应用跑起来。这背后反映的是一种信任逻辑的变化开发者在 AI 时代见过太多“看起来很厉害”的技术宣传他们更相信能当场跑通的 Demo。因此布道师不再只是一个“会讲故事的人”而是要像一个 AI Engineer 一样能熟练处理 API 鉴权、模型参数调优、上下文工程、异常恢复等实际问题。简单说未来的布道师如果不懂 AI 工程化就很难做好布道。3.2 从“面向大众”到“面向场景”过去布道师写文章往往追求“覆盖面广”希望一篇文章能面向所有开发者。但在 AI 时代技术更新的速度太快泛泛而谈的教程很快就会被新的模型能力淘汰。相反聚焦具体业务场景的内容生命周期会更长也更受欢迎。例如“如何用 RAG 搭建一个企业知识库问答机器人”“如何用 Agent 自动处理工单分类与流转”“如何给大模型应用设计高质量评测集”“如何解决长文档处理中的上下文丢失问题”这些内容本质上是在构建一个“场景化解决方案库”对开发者的实际帮助远大于泛泛的 API 介绍。3.3 布道师 AI Engineer 的复合角色在我看来未来的开发者布道师最理想的画像就是一个具备布道能力的 AI Engineer。也就是说他要能独立完成一个 AI 应用的从 0 到 1。他能把开发过程中的关键决策、踩坑经验、技术选型逻辑表达清楚。他能把复杂的 AI 概念翻译给不同背景的开发者听。他能把社区反馈转化为产品改进建议。这种复合角色远比一个只会写文章的布道师或一个只会写代码的工程师更有价值。4. AI Engineer 的核心技能栈拆解这一节来重点拆解 AI Engineer 需要掌握的核心能力。不管你是布道师想转型还是普通后端工程师想切入 AI 领域下面的内容都可以作为参考。4.1 大模型应用的基本架构能力AI Engineer 首先是工程师架构能力是基础。一个典型的 AI 应用架构通常包含以下模块模型接入层负责与大模型 API 通信包括鉴权、重试、超时处理、流式输出等。数据准备层负责准备模型的输入数据包括文档解析、清洗、分块、向量化。检索增强层RAG负责把用户问题与知识库中的相关内容进行匹配通常是向量检索 关键词检索的混合方式。上下文管理层负责管理多轮对话中的历史消息、Token 数量控制、摘要压缩。工具调用层负责让模型调用外部工具或 API比如查询数据库、创建一个工单、发送通知。应用服务层负责把 AI 能力封装成业务 API供前端或其他系统调用。如果你能快速把这个架构在项目中落地就已经具备了 AI Engineer 最核心的工程能力。4.2 Prompt 工程与上下文工程很多人以为 Prompt 工程就是“写一段神奇的话术让模型按照要求回答”。这个理解过于浅了。在实际项目中Prompt 工程更像是一种“结构化编码”。举个例子一个可靠的系统提示词System Prompt通常需要包含角色定义你是一个客服工单分类助手。任务目标根据用户描述输出工单优先级。输入格式用户描述是 JSON 格式。输出格式只输出 JSON包含 priority 和 reason 两个字段。约束条件不允许主观臆测缺失信息。少数示例给出 2 到 3 个输入输出示例帮助模型理解任务。下面是一个简化的示例system_prompt 你是一个 IT 工单分类助手。你的任务是根据用户提交的问题描述输出工单的优先级。 输出格式要求必须严格遵守 { priority: high|medium|low, reason: 简要说明判断依据 } 约束条件 1. 如果问题导致业务系统不可用优先级为 high。 2. 如果是使用咨询类问题优先级为 low。 3. 如果介于两者之间优先级为 medium。 4. 不要输出除了 JSON 之外的任何内容。 示例 用户描述生产环境支付接口持续报错用户无法完成付款。 输出{priority: high, reason: 支付接口故障直接影响业务收入} 用户描述请问这个按钮是做什么用的 输出{priority: low, reason: 属于功能咨询问题} 在实际调用时再通过 Messages 结构把用户输入拼进去from openai import OpenAI client OpenAI( api_keyyour-api-key, base_urlyour-base-url ) user_input ERP系统登录页面打开很慢有时候直接超时已经影响办公了 resp client.chat.completions.create( modelyour-model, messages[ {role: system, content: system_prompt}, {role: user, content: f用户描述{user_input}} ], temperature0.2, response_format{type: json_object} ) print(resp.choices[0].message.content)这里有几个实际开发中容易踩的坑temperature不要设太高分类任务建议 0.2 以下。要求模型输出 JSON 时最好同时开启response_format并给出 JSON 示例否则容易出现多余文字。系统提示词里的约束条件越明确输出越稳定。4.3 检索增强生成RAG的落地要点RAG 是大模型应用落地最常用的方案。它解决的核心问题是让模型在回答时能引用私域知识库中的内容减少幻觉提高可信度。一个完整的 RAG 流程可以拆成以下步骤文档加载读取 PDF、Word、Markdown、HTML 等格式的文件。文本切分按标题结构或固定字符数切块保持语义完整。向量化用 Embedding 模型把文本块转成向量。存储索引把向量写入向量数据库。检索召回根据用户问题从向量库召回 Top-K 相关内容。重排序对召回结果做精细排序过滤不相关内容。生成回答将检索到的内容拼接进 Prompt让模型生成回答。这里有一个开发中很容易忽略的点文本切分策略对召回效果影响巨大。如果切块太小语义可能不完整如果切块太大向量检索的精度会下降上下文占用也会飙升。一个相对实用的切分策略是优先按 Markdown 标题或段落结构切分。每块控制在 300 到 800 字之间。相邻块可以保留少量重叠避免信息被切断。对代码文档尽量按代码块边界切分。下面是一个简单的文档加载与切分示例使用 LangChain 作为示例框架from langchain_community.document_loaders import TextLoader from langchain_text_splitters import RecursiveCharacterTextSplitter loader TextLoader(release_notes.md, encodingutf-8) documents loader.load() text_splitter RecursiveCharacterTextSplitter( chunk_size600, chunk_overlap100, separators[\n## , \n### , \n, 。, , , ., !] ) chunks text_splitter.split_documents(documents) print(f切分完成共得到 {len(chunks)} 个文本块)切分完之后就是向量化和检索。生产环境建议加上重排序环节不然检索结果中可能混入无关内容直接影响回答质量。4.4 Agent 工作流的设计思路Agent 是大模型应用的重要发展方向。所谓 Agent就是让大模型不只是“回答问题”而是能根据目标自主决策调用工具完成一系列操作。以“工单自动处理 Agent”为例它的工作流可以是接收用户描述。判断工单类型。如果是故障类自动查询知识库并给出排查建议。如果需要重启服务调用运维 API 执行操作。如果需要人工介入自动创建企业微信/钉钉任务并通知管理员。写 Agent 和写普通 CRUD 最大的区别在于你要处理“不确定性”。模型可能给出错误的工具参数可能陷入循环可能调用一个不存在的工具。因此生产级 Agent 必须有工具路径白名单。调用次数的最大限制。超时与熔断机制。人工审批节点。全链路日志追踪。下面是一个简化版的工具调用循环示例帮助你理解 Agent 的核心思路import json from openai import OpenAI client OpenAI(api_keyyour-api-key, base_urlyour-base-url) def get_server_status(server_name: str) - str: 查询服务器状态 status_map {web-01: 正常, db-01: CPU 80%, cache-01: 正常} return json.dumps({server: server_name, status: status_map.get(server_name, 未知)}) tools [ { type: function, function: { name: get_server_status, description: 查询服务器的实时运行状态, parameters: { type: object, properties: { server_name: {type: string, description: 服务器名称} }, required: [server_name] } } } ] messages [ {role: user, content: 请帮我查一下 db-01 服务器的状态} ] resp client.chat.completions.create( modelyour-model, messagesmessages, toolstools, tool_choiceauto ) msg resp.choices[0].message if msg.tool_calls: for tool_call in msg.tool_calls: fn_name tool_call.function.name fn_args json.loads(tool_call.function.arguments) if fn_name get_server_status: result get_server_status(fn_args[server_name]) messages.append(msg) messages.append({ role: tool, tool_call_id: tool_call.id, content: result }) final_resp client.chat.completions.create( modelyour-model, messagesmessages, toolstools ) print(final_resp.choices[0].message.content)这个例子虽然简化了很多但已经覆盖了 Agent 的核心闭环模型决定调用哪个函数、函数返回结果、再把结果交回模型生成最终回答。5. 布道师如何向 AI 方向转型5.1 先选一个垂直场景深入下去布道师转型 AI Engineer最容易犯的错误是“什么都想学结果什么都没学透”。今天看 LangChain明天学向量数据库后天又去搞模型微调最后反而没有形成核心竞争力。我的建议是先挑一个你所在行业或团队最需要的场景扎进去做一个小项目。比如如果你是做运维的就做一个日志异常分析助手。如果你是做测试的就做一个测试用例自动生成工具。如果你是做前端开发的就做一个 UI 设计稿转代码的辅助工具。如果你是做电商业务的就做一个商品评论情感分析 自动回复系统。选一个小的、能闭环的场景把它做深远比做十个半成品要好。5.2 用内容输出倒逼技术深度布道师有一个其他工程师很少具备的优势就是内容表达能力。在转型 AI Engineer 的过程中这个能力不应该丢掉反而应该充分利用。你可以在学习每个新知识点时强制自己写一篇技术笔记或做一个小分享。这样做有几个好处写清楚的过程就是真正理解的过程。内容发布后别人会帮你发现理解偏差。持续输出会积累影响力为后续职业发展铺路。这些内容本身就是你的作品集。很多转型成功的布道师都是通过“边学边写边分享”的方式快速建立了自己在 AI 领域的话语权。5.3 构建自己的示例项目库过去布道师维护示例项目大多是“为了演示而演示”。AI 时代我建议你换一种思路把每个示例项目都做成一键可运行的完整应用配有清晰的 README、部署脚本和演示视频。哪怕项目规模不大但只要它具备以下特征价值就会很高有真实的业务场景不是简单的 Demo。有清晰的架构说明和技术选型理由。有可复用的代码其他开发者能直接改造使用。有常见的坑点记录。这样的项目库会比十篇纯理论文章更有说服力。6. 常见问题与讨论6.1 布道师岗位真的会消失吗短期内不会大规模消失但岗位要求一定会变化。只会写文章、做 PPT、搞活动的布道师会被边缘化。懂技术、能写代码、能独立完成 AI 应用的布道师反而会因为 AI 的普及更加吃香。6.2 AI Engineer 会不会也很快过时技术岗位的更替是常态但 AI 工程化能力具有长期价值。无论底层模型怎么换工程化能力——架构设计、数据处理、效果评测、系统集成、成本优化——都是通用的。这也是为什么我不建议只学某个具体框架而要注重底层能力的沉淀。6.3 布道师转型 AI Engineer 最大的难点是什么根据我观察到的案例最大的难点是“思维模式的切换”。布道师长期以来习惯了“快速理解新东西并把它讲给别人听”这导致很多人停留在“知道概念”的层级而没有深入到“真正实现”的层级。AI Engineer 需要的是把项目跑通、把性能调优、把线上问题排查解决。这两者之间的差距只能通过大量写代码来弥补。6.4 不会做算法能做 AI Engineer 吗能。AI Engineer 不是算法研究员不需要从零发明模型。核心是把已有的模型能力工程化落地。这就像后端工程师不需要自己写数据库引擎但需要精通 SQL 和索引优化一样。需要掌握的是如何调用模型 API、如何设计好的 Prompt、如何搭建 RAG 流程、如何让应用运行稳定、如何控制成本、如何做效果评测。7. 推荐的技能学习清单如果你正在规划从布道师或普通开发转向 AI Engineer可以参考下面的学习主线Python 基础重点掌握 requests、json、pydantic、异步编程。大模型 API 使用掌握 Chat Completions、流式输出、函数调用。Prompt 工程学习任务拆解、约束表达、少样本示例设计。文档处理PDF 解析、Markdown 切分、常见格式清洗。向量数据库掌握一个主流产品的增删改查和相似度检索。RAG 应用开发理解和实现完整检索问答链路。Agent 开发掌握工具定义、工具调用、多轮上下文管理。效果评测建立自己的测试集能够量化回答质量。部署运维学会用 Docker 部署 AI 应用掌握基本监控。同时建议养成三个习惯每天至少写 30 分钟代码不做纯概念学习者。每次实践都做记录形成自己的排错手册。定期把实践经验整理成文章或视频持续输出。8. 写在最后开发者布道师的“消亡”并不是这个职业的价值消失了而是旧的工作方式正在被淘汰。AI 并不会让“布道”这件事消失反而会让真正懂技术、能落地、会表达的复合型人才变得更加稀缺。今天一个优秀的布道师完全可以也是一名优秀的 AI Engineer。你可以把对技术的热情、对开发者的理解、对内容的表达能力全部投入到 AI 应用的实践中。用真实可运行的作品代替漂亮的宣传语用工程能力赢得开发者的尊重。如果你现在正处在这个转型路口我的建议很简单选一个你真正感兴趣的 AI 场景静下心来把一个项目从零做到上线。过程中遇到的问题就是你最好的学习材料做完后的项目就是你最强的作品集。技术圈永远不缺概念缺的是能把概念变成现实的人。