企业官网建设流程全解析

开发者布道师（Developer Advocate）这个职位，这两年正处在一个很微妙的转折点上。说它要消亡有点夸张，但如果你长期关注 DevRel 领域，会发现一个无法忽视的变化：过去靠博客、演讲、线下活动去影响开发者的那一套，正在被 AI 工程（AI Engineer）用更安静、更直接的方式替代。

我自己观察到的现象是：很多团队的布道内容还在正常发布，阅读量也没有崩盘，但真正影响开发者决策的路径已经变了。开发者遇到一个新 API，第一反应不再是搜博客、参加会议，而是打开一个 AI 编程助手，让它帮忙解释、写样例、排错。于是产品的“嘴”，从写文章的人，变成了能被 AI 正确理解和调用的那套工程接口。

这里不打算下一个耸人听闻的结论，而是想把这轮变化拆开看：布道师在传统技术生态里到底承担了什么，AI 改掉了哪一环，哪些能力会被替代，哪些能力反而更值钱，以及现在还站在这个位置上的人，下一步可以往哪里走。

适合读这篇文章的人有三类：正在做开发者关系、技术内容、开发者社区的人；负责产品技术推广的技术负责人；以及还在观望要不要进入 DevRel 这个方向的工程师。前两类可以重点看转型路径，第三类可以先看判断标准。

1. 先给“消亡”这个说法做个校准

1.1 布道师的本质，是技术组织和外部开发者之间的翻译层

开发者布道师并不是一个纯粹的营销岗位。它的核心职责，是把一个技术产品翻译成外部开发者能快速理解、快速上手、愿意持续使用的东西。翻译的方式很多样：官方文档、示例代码、技术博客、大会演讲、线上直播、Meetup、Hackathon，以及在各种社区和群里回答开发者的具体问题。

这个岗位的价值，本质上建立在两件事上。

第一，信息不对称。产品团队自己写的技术文档，经常默认读者已经了解背景。外部开发者缺少这些上下文，会遇到大量“文档里没写清楚”的细节问题。布道师要补上这层上下文。

第二，信任传递。开发者不会因为厂商一句“很好用”就接入一个 SDK。他们更愿意相信一个看得见、能对话、敢在现场接住问题的真实的人。布道师实际上是厂商建立技术信任的前哨。

所以，布道师看似在写内容、办活动，实际在做的是两件事：降低开发者的理解成本，以及降低开发者的信任成本。一旦把岗位拆到这个层面，再去看 AI 带来的变化，思路就会清楚很多：AI 能不能降低理解成本？能，而且做得很快。AI 能不能建立信任？暂时不能，这仍然需要真实的人长期投入。

1.2 真正被重构的，是“内容-活动-反馈”这个传统三角

传统布道师的工作可以压缩成三个动作：生产内容、组织活动、收集反馈。内容解决理解和传播，活动解决信任和关系，反馈解决产品迭代方向。

这三个动作并不是同时失效的，这正是很多团队现在感到迷茫的原因。

内容这一环，最先被 AI 冲击。开发者获取知识的方式，从“人写文章给人看”，逐步变成“人问 AI，AI 读文档后给答案”。如果一篇博客写的知识，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 如果想真正做好“开发者体验”这层工作，仍然需要大量来自真实社区、真实故障现场、真实使用痛点的输入。而这些输入，过去主要靠布道师长期泡在社区里才能获得。问题在于：谁能把这些输入转化为工程方案，谁就能在下一轮里占据主导。

这就是我理解的真正变化：布道的“表达”仍然重要，但“构建”越来越重要；能够同时掌握表达能力和工程能力的人，会非常稀缺。

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 回答不了、必须依赖真实经验和代码验证的资产。这才是这轮变化里，最值得提前做的一件事。