2.1 WorkBuddy：知识工作者的 AI 协作平台
本章导读
本 节 目 标
- 能描述 WorkBuddy、CodeBuddy、ADP、Miora 四类核心产品各自解决的核心问题及使用边界。
- 能针对给定场景分析并说明至少 2 种工具组合方案，阐明选型依据与边界条件。
- 能判断系统集成需求对工具选型的影响，说明复杂场景下应如何选择合适的组合路径。
- 能说清 WorkBuddy 的「专家 → 助理 → 团队」三层递进与四类能力资产（专家 · Skill · 连接器 · 资料库）各自解决什么问题，以及客户落地时要跨过的四层门槛。
想象这样一个场景：客户的 IT 负责人坐在你对面，说："我们想引入腾讯云 AI 能力，但我不知道用哪个产品。WorkBuddy？CodeBuddy？听起来差不多，都是 AI 助手吧？"
这个问题，正是 FDE 工程师必须在 30 秒内能清晰回答的。
本章介绍的 WorkBuddy、CodeBuddy、ADP、Miora，是腾讯云 AI 家族中 FDE 最常用的四款重点产品——它们不是腾讯云的全部产品，但覆盖了 FDE 交付中最典型的四类场景。四款产品之间分层、互补、可组合，每款都有明确的核心场景定位和使用边界。选错工具，轻则交付效果打折，重则在客户侧埋下难以维护的技术债。
本章的核心任务就是让你建立这四款重点产品的完整认知地图——不仅知道每个产品"是什么"，更能在真实场景中做出有依据的选型决策。
🖼 图：tool matrix position map
概念
WorkBuddy 解决的核心问题：让普通业务人员（非技术用户）能够通过对话、问答、文档处理等自然语言交互方式，访问企业内部知识并完成日常工作任务。
一个直觉类比：如果把企业 AI 能力比作一座冰山，WorkBuddy 是水面以上的那一层——用户直接看得见、摸得着的界面和交互入口。它面向的是企业中"最多的那群人"：HR、运营、市场、客服、管理层，而不是开发者。
典型能力标签：知识库问答（RAG）、文档摘要与分析、多轮对话助手、企业内容生成、工作流辅助。
产品定位与三层递进
WorkBuddy 是腾讯云推出的企业级 AI 智能体套件。用户以自然语言下达任务，WorkBuddy 自主思考、拆解任务、规划执行步骤，最终交付可直接验收的工作结果——不止于问答，而是能真正把活干完。
提示
产品路径是「专家 → 助理 → 团队」三层递进：从解决个人效率问题，走向解决组织生产力问题。这个路径本身就对应了 FDE 在客户现场的推进节奏。
| 层级 | 解决什么问题 | 产品形态 |
|---|---|---|
| 专家 | 专业能力供给（个人层） | 把岗位所需的应用、技能、指令和标准工作流打包在一起，降低个人使用门槛。100+ 预置领域专家，覆盖招聘、投研、前端、法务、营销等 |
| 助理 | 常驻执行能力（任务层） | 把专家放到云端，成为 7×24 常驻的数字员工。长任务在云端持续推进，关闭客户端也不中断 |
| 团队 | 协作与资产沉淀（组织层） | 把人和助理放进同一个项目空间，多个 Agent 并行处理各自任务，推动上下文共享、过程透明和资产复用 |
提示
一个反复出现的现象：AI 产品即使能显著提高个人效率，如果组织和管理形态没有相应升级，整体效果仍会衰减。产品试用初期使用频次很高，两三个月后如果没有嵌入日常流程就会下降——问题不在功能，在组织没有为 AI 调整工作方式。这正是 FDE 存在的意义。
四类能力资产：专家 · Skill · 连接器 · 资料库
对 FDE 来说，这四类是最常用的杠杆工具。Skill 描述怎么做，连接器决定能接入哪些系统，资料库决定能调用什么专业内容，专家把三者打包成一个可直接调用的角色。
🖼 图：四类能力资产：Skill 描述怎么做 · 连接器决定能接入哪些系统 · 资料库决定能调用什么专业内容 · 专家把三者打包成一个可直接调用的角色。
| 资产 | 解决的核心问题 | WorkBuddy 对应能力 | 主要风险 |
|---|---|---|---|
| 专家 | 把岗位经验封装为可调用的角色 | 预置专家 + 自定义企业专属专家（上传岗位说明书、SOP、知识库即可构建） | 岗位理解不到位会做成「换皮提示词」 |
| Skill | 把任务经验固化为可执行能力单元 | 技能市场，支持自定义封装与团队共享调用 | 需要长期项目经验和场景抽象能力 |
| 连接器 | 把 AI 接入企业真实系统，不替换原有系统 | 基于 MCP 协议与统一身份体系，连接 OA、CRM、项目管理、腾讯会议、邮箱等 | 权限管理、安全合规、系统稳定性 |
| 资料库 | 提供专业内容和业务上下文 | 深度打通腾讯文档、腾讯网盘、腾讯乐享，形成组织记忆底座 | 数据来源质量、行业 know-how 持续更新 |
提示
单个 Skill 不构成护城河。Skill 本质上是自然语言描述的流程和规则——它是明文的，一旦放上平台容易被复制。实践中可行的保护方式，是把 Skill + 连接器 + 专属知识库封装成完整应用，只暴露使用界面或对话接口，不直接暴露底层 Skill 描述。
评价平台能力积累，不应只看 Skill 数量，而要看四个递进问题：
-
Skill 是否被组织成 行业模板 ，而不是零散插件？
-
模板是否能 连接真实业务系统 ？
-
系统连接后是否能在客户现场 持续产生数据反馈 ？
-
反馈能否继续 改进下一版 Skill 和产品功能 ？
提示
如果只把 Skill 当成零散插件，平台会变成素材市场；只有把三者组织成可复用方案，平台才可能成为行业能力的载体。
用法
WorkBuddy 的核心交付模式是**"配置式部署"**：客户不需要写代码，通过平台界面完成知识库接入、Prompt 模板配置、权限管理等操作，即可上线面向员工的 AI 助手。
WorkBuddy 适用边界一览表
| 维度 | 适用（In Scope） | 不适用（❌ Out of Scope） |
|---|---|---|
| 用户类型 | 业务人员、管理层、非技术员工 | 开发者、数据科学家 |
| 交互形式 | 自然语言对话、文档上传问答 | 代码生成、程序调试 |
| 数据接入 | 企业文档、FAQ、知识库（只读为主） | 单独使用时的直接生产写操作——写操作需经企业级连接器 + 最小权限凭据 + 人工门禁（见第 4、5 章） |
| 部署复杂度 | 低代码/零代码配置 | 复杂业务逻辑定制开发 |
| 典型场景 | 员工内部问答、客服知识库、文档助理 | 自动化流水线、代码审查 |
使用边界关键判据：
提示
当客户问"我们的员工能直接用吗？不想让他们学复杂操作"→ 优先考虑 WorkBuddy。 当需求涉及"写代码""调 API""自动触发外部系统"→ WorkBuddy 单独使用已触及边界；其中"接外部系统"经企业级连接器与 WMA 可受控扩展（见第 4、5 章）。
示例
场景：某制造企业希望将 500 份产品手册和内部 SOP 文档变成员工可以随时问答的知识助手。
WorkBuddy 交付路径：
① 收集文档材料（PDF/Word/网页）
↓
② 在 WorkBuddy 平台创建「知识库」，上传文档，触发自动向量化
↓
③ 配置「助手」：设定助手角色、Prompt 模板（如"你是 XX 公司的内部知识助手，只基于文档回答"）
↓
④ 配置权限：哪些部门可以访问哪个助手
↓
⑤ 通过企业微信/Web 入口发布，员工直接对话访问
预期交付周期：1～2 周（含文档清洗与测试）
**⚠️ 风险提示：**WorkBuddy 知识库的回答质量强依赖 文档质量 。上传前需完成文档去重、格式标准化、敏感信息脱敏，否则 RAG 检索质量会显著下降。这是交付中最常见的踩坑点。
关联阅读：WorkBuddy 与 CodeBuddy 作为团队经验沉淀载体的分工与对比，详见第 8 章「沉淀：把经验变成资产」中「沉淀载体怎么选」一节。
随堂测
逐题作答，即时反馈
1. WorkBuddy 的四类能力资产中，「描述怎么做」的是哪一类？
2. 用 WorkBuddy 把 500 份产品手册和 SOP 做成员工问答助手，配置式部署路径的正确顺序是？
3. 用 WorkBuddy 交付知识库问答助手，课文给出的预期交付周期（含文档清洗与测试）约为？