分享嘉宾 | 黄闻欣
审校 | Kitty
策划 | QCon 全球软件开发大会
在 10 月 18-19 日举办的 QCon 全球软件开发大会上，腾讯技术总监黄闻欣为我们带来了精彩的专题演讲“AI 重塑技术流程：下半场的破局之道”，演讲揭示了 AI 如何重塑技术流程的“下半场”，从技术知识管理的痛点出发，展示团队如何运用 AI 技术从简单的知识检索到知识飞轮，让性能分析变得高效。通过实际案例，您将看到 AI 如何协助研发解决棘手性能问题，以及在降本增效的大背景下， AI 如何帮助研发聚焦有价值的性能问题。让我们一起探讨，在 AI 时代，如何让工程师们的工作更智能、更有价值。
内容亮点：
● 揭示 AI 如何协助研发团队在降本增效背景下识别和聚焦核心问题。
● 展示利用 AI 驱动的知识飞轮提升团队整体效能，包括 RAG 资料的自动更新机制。
● 通过实际案例，展示 AI 与企业已经存在的内部技术平台无缝结合。
● 探讨如何借助 AI 打造适配自身企业研发的独特核心竞争力。
以下是演讲分享实录（经 InfoQ 进行不改变原意的编辑整理）。
为什么“下半场”？
在过去一年中，我作为一名深耕性能工程多年的技术人，亲身经历了大家从“不理解”、“不接受”到把 AI 融入到技术工作、性能工程和产品中的全过程。
作为腾讯负责性能工程方向的专家工程师，我同时也是团队管理人员。在当前经济环境不佳的背景下，我想分享如何应对压力，并探讨如何保持、提升和打造团队的战斗力。我的分享将分为四个部分，首先解释为何称之为“下半场”，然后讨论如何保持团队的战斗力，接着是如何提升战斗力，最后是如何打造战斗力。
在“上半场”，我们主要关注成本削减和效率提升，通过产品聚焦和人员精简来实现。许多大型互联网公司，包括腾讯，在西安、武汉、长沙等城市部署新的研发节点，这导致了一系列问题，比如新人经验不足，老人承受压力增大，异地沟通困难。这些问题导致了一个恶性循环：有经验的人变少，新人无法替代他们，而有经验的人也没有精力去建设文档。
在“下半场”，简单的成本削减已经行不通，自动化和 DevOps 等普通招数已经用尽，我们陷入了人力的死循环。我一直在思考，AI 技术如此强大，我们的老板也在谈论 AI，但同时，他也参与一些其他会议，那里充满了各种大难题，讨论的都是运维问题、工单、故障问题等，似乎与 AI 无关。我困惑于 AI 是否能够解决这些大难题。在一次重大故障发生后，我分析发现，代码审查的能力本可以发现这个问题的，但 AI 未承担起这个责任，故障依然发生，AI 只是 AI，我们依旧痛苦不安。同时，这也让我思考，下半场中，我相信 AI 是一个重要的切入点，我们如何利用 AI 确保和提升我们的战斗力，这便是我今天分享的专题。
保持战⼒：沉淀 ->⻜轮
⽤知识传承来保持战⼒
在腾讯，大家很早就意识到了知识沉淀和文档整理的重要性，并为此出台了一系列奖励政策。这些政策鼓励员工沉淀知识、梳理 wiki，并且提供的奖金相当可观。我们的解决方案似乎很明确：利用公司内部的知识库产品—— wiki，结合 RAG 技术和人工智能，来解决知识管理和检索的问题。理论上，这样的组合应该能够解决问题，我们也对此充满期待。
然而，在实际操作中，我们遇到了挑战。我带领团队开发了一个名为“性能大师”的小机器人，它被集成在企业微信中，旨在回答各种性能问题。但在向团队推广时，我们发现它提供的答案并不总是令人满意。这引出了我们遇到的第一个难点：如何将 RAG 技术从最初的兴奋状态转变为实际可用的工具。我们经历了从几乎无法使用到最终使其变得可用的过程。第二个难点是关于全局性问题的解决效果不佳。尽管我们尝试了多种方法，但在处理一些全局性问题时，效果仍然不尽如人意。
知识检索：RAG 从
完全不靠谱到还 OK
我们可以看到下图列了许多 RAG 补丁。我不会详细介绍每一个补丁，因为它们中的许多作用是相似的。例如，Small2big 这个概念我在上一次 AICon 就已经听到别人提及。它的目标与父子文档的目标非常接近，都是为向量检索 512 tokens 的匹配准确率最高，但是实际推理又需要更多相关内容而设计的。
Re-rank 是另一个向量检索的补丁。如果普通的检索效果不佳，我们就采用混合检索，多路召回等尝试各种检索方式，然后再用 Re-rank 进行精细排序。虽然听起来很高级，但实际上也是一个打补丁的过程。
后面的两个技术，更多就是我们针对我们使用场景建设的。
知识库加工
关于知识库，在 RAG 技术出现之前，我们的内部知识库是否已经很好？实际上并不好，它本身就很混乱。以一个性能优化专家写的文档为例，文档中提到某个服务的 CPU 使用率特别高，所以存在问题。但当我询问专家为什么 CPU 使用率高就有问题时，我发现文档中并没有解释清楚。因为网络服务应该是内核态的 CPU 使用率高才对，而不是用户态。所以，我们使用生成式AI 对知识库进行了加工，全量的知识库都会经过这个自定义的加工过程，然后再将其纳入知识库。在我们场景中，我们的加工提示词的重点就放在格式整理和逻辑补全。
RAG Fusion
是论文中提到的一个概念，现在我们也看到很多 AI 搜索使用了类似的方法，即将用户输入的问题生成多个问题再去检索，生成结果。
经过这些步骤后，我们的工具基本上可以使用了。我们有一个名为 Fibona 的内部工具，它提供了一个问题和答案的示例，我们认为这是一个接近正确答案的答案。但这里还有一个隐藏的问题：答案中完全没有提到我们工具最强大的部分，即提供了许多技能。为什么没有提到呢？因为这些技能不一定能在 Fibona Flow 的工作流模式中使用，它们在普通的提示词模式中也是可用的。但是在文档检索时，很多技能并没有被关联在一起。
更进⼀步的知识检索：
拍扁的神经⽹络 = 知识图谱
这观点是我坚信 GraphRAG 有价值的原因，并与团队分享了这个观点：知识图谱可以被视为扁平化的神经网络。如果你 RAG 的智慧尚未达到一定的水平，那么请使用知识图谱。基于这个理念，我们构建了知识图谱，并据此生成了下图中的内容。这个内容清晰地展示了我们的技能，也就是我们所说的 Function call 工具部分，已经被整合到了文档中。
这是我们结合 RAG 技术后的效果，它帮助我们解决了一些全局性的问题。我们使用的是微软开源 GraphRAG，它的作用是将图检索的加权权值附加到我们的向量化检索中。通过这种方式，我们能够将知识图谱与向量检索技术相结合，从而提升了全局性问题的解决能力。
【案例】腾讯云可观测平台 RUM ⼯单处理⻜轮
对于 ToB 业务的人来说，B 端的每次工单处理对于产品改进、引导客户实践都非常重要。因此，当 RAG 技术出现时，我们都非常兴奋，认为它能够解决许多运维问题。我们设想，用户提交工单后，是否可以让机器人直接回答。于是我们将一系列文档输入到 RAG 系统中，并让它对接我们的内部工单系统。但对接完成后，我问团队这是否对他们处理日常工单有很大帮助。他们犹豫了一下，不想让我失望，因为我一直在大力推广 AI。但实际上，帮助并不大。我询问原因，发现很多内容我们的文档里并没有提供。
为了解决这个问题，我们需要进行知识沉淀。老板们都知道需要做知识沉淀，但这个过程也有它的难点。首先，工单流程穿透到我们作为原厂的三线支持，如果缺乏文档和知识沉淀，无论是否使用 AI，问题都无法解决。老板会问为什么不写文档，但问题在于，那些有经验的人已经不多了，剩下的没有经验的人也写不出文档。另一个难点是，专家投入时间解决了工单，已经身心俱疲了，也不愿意去总结。
为了解决这个问题，我和团队梳理了一个大图谱，这是图谱的一部分，展示了 AI 在哪些地方发挥作用。目前，AI 主要在工单问题回答和初步定论时介入，以及在咨询问题时提供答案。但这只是全景的一小部分。我之前一直强调，AI 的实施必须以流程为先，于是我带着团队梳理流程，发现许多节点都可以使用 AI，但实际上并没有使用。其中一个非常重要的节点就是 AI 知识提炼。正如前面说的专家已经很忙了，他们哪有时间提炼知识？我们注意到在流程中，有那么一个地方的内容不敷衍，最终里面也有解决问题的方案产出，那就是与客户的聊天群。因此，我们决定从聊天记录中提取知识并沉淀。我们就是这样做的。
下图是我们从聊天记录中沉淀出来的安全工单内容，内容相对靠谱。从大量的聊天记录中提取出这些信息，实际上是经过了一个相当长的 workflow 过程，不过这里并没有展示出来。尽管提取过程复杂且耗时，但最终我们得到了可靠的结果。
下图是关于 Nginx 的一个安全工单。我们会将这个安全工单的内容沉淀到我们的 wiki 中，具体来说，就是将这些信息转换成 Markdown 格式进行存储。当有新的工单到来时，我们可以看到，尤其是那些之前未出现过的新安全工单，这意味着它们可能是新出现的问题，之前在我们的记录中并不存在。这样的工单非常适合我们的知识沉淀场景。
我们通过 RAG 检索找到了之前沉淀的知识，然后我们会着手处理它，快速给出相应的解决方案，告诉用户应该如何解决这个问题。随着时间的推移，我们通过这种数据飞轮的方式积累了越来越多的数据，我们的工单响应时间和处理速度都有了显著的提升。
依旧有挑战
挑战 1 和 2 是 CoT 带来的。CoT 这种方法非常受欢迎，甚至结合强化学习应用到 OpenAI O1 中。然而，CoT 的效果本身收到 Context 长度的限制。但是假设限制不存在了，你可能会认为上下文越长越好，但实际上又并非如此。过长的上下文会导致模型的注意力分散，稳定性差，从而产生大量噪声。这一点在代码领域的 CR（Code Review）中尤为明显，同样在聊天记录工单场景中也非常明显。
挑战 2，在之前提到的场景中，输出答案后，我们还需要手动将其粘贴到 wiki 中。如何将这个过程自动化，是一个挑战。
对于上面的两个这个挑战，我们想到的第一个解决方案就是利用工作流的方式来整合工具，这样既可以让工具自动化起来，还可以通过控制传递的上下文来解决 Context 的限制和模型不稳定的问题。下面我们来看看具体的案例。
【案例】⼯单可以，
POC 是不是也可以
既然工单可以用于知识沉淀，那么 POC（Proof of Concept）场景是否也可以呢？POC 是指在云计算领域，客户准备购买我们的产品时，我们会参与他们的 POC 过程，其中涉及到与众多竞品的对比。这时，我们性能优化的专家和 IaaS 专家会参与讨论，提供专业意见。这些讨论非常专业且精彩，但是否有人将这些内容沉淀下来呢？通常，一旦 POC 完成，大家都松了一口气，没有人愿意回头去整理这些宝贵的信息。这无疑是“坐在金矿上讨饭吃”，因为有很多资深的研发人员和专家提出了非常好的技术建议，但却没有人去沉淀这些知识。
刚才说，我们要用 workflow，但我们并没有采用传统的方式，因为我自己尝试过，包括拖拽式的 workflow 工具，我发现我并不喜欢这种方式。我认为，既然我可以自然语言描述了步骤，为什么还要用拖拽的方式呢？AI 应该能够理解自然语言的步骤描述。因此，我们稍微进化了一下，开发了一种根据步骤描述生成 workflow 的工具。
下图展示了整个 POC 产出内容的步骤，这些步骤涉及到了很多工具，这些工具可以通过我们称之为“技能”的功能来调用。这个“技能”非常多样，包括提示词本身也可以是一个工具，有点像套娃，提示词套提示词。最终，我们的提示词做得有点像编程中的方法或类，给人一种编程的感觉。
Workflow 听起来似乎很简单，但实际上它涉及许多复杂问题。
批处理
我们希望针对每个点调用 AI 来生成 5 个技术点，这就需要我们分别调用 GitHub Search、大语言模型或谷歌搜索来获取答案。这时，我们需要批量或便捷的操作，但原生的 workflow 并不支持这一点，因此我们开发了智能批量处理功能，它可以并发地调用模型或工具。
中断补充
除了批量处理，我们还进行了中断补充。我经常强调与 AI 的协作关系。很多时候，答案不是一次性对话就能得出的，而是需要在生成答案后进行确认，必要时进行中断和补充。
易用性
也是一个问题，因为描述 workflow 本身就很费劲，尽管我认为它比拖拽方式要好一些。我们收到很多用户反馈，他们写的 workflow 提示词在我们系统中无法生效，我们会告诉他们 workflow 写得不够好。最后，我们提供了一键转 workflow 的方式，通过一个提示词帮助用户一键转换成步骤描述。
变量传递
workflow 与普通提示词的一个重要区别在于，我们在 workflow 中传递的变量是自己控制的，这样才能控制上下文。在其他系统中，用户需要选择哪个变量往后传，而我们这里则需要在步骤描述中明确，尽管这有些反人性。
代码调试
另外，由于我们的工具支持 JavaScript 和 Python，调试也是一个问题。我们的工具提供了一个入口，允许用户修改代码，并且我们还提供了轻量的 AI 生成代码的能力。
可靠性
也是一个大问题，我们曾经经历过内部模型突然迭代带来的灾难，因此对此非常敏感。我们编写了一系列测试用例，并用 AI 进行评分。这些评分不是基于固定标准，而是类似于政治题中的主观题，我们会给最佳答案和评分标准，非常具体。例如，如果是关于 FibonaFlow 工具使用的问题，我们会告诉评分者必须提到技能、Python 工具和 JS 工具，提到这些就能得到分数，否则就会扣分。这个 workflow 每天都会执行，以监测我们的总体情况。
【案例】腾讯云可观测平台 RUM
性能微解决⽅案
我们这么好的工具，是否能够让我们云计算的客户也能使用到。这让我想起了阿里云的王坚所说的“从独善其身到兼济天下”。我们曾经帮助两大头部银行解决 App 的性能问题，让他们在银行 App 评测中获得了第一名和第二名。那时，我们让团队中资深的性能专家不断帮助客户优化 App 性能。但现在，我们明显没有足够的资源去支持这些客户成功的工作，那我们能否将我们沉淀知识和 Fibona 带来的工作流的能力贡献给我们的客户呢？
我们将这些的能力整合到了腾讯云可观测平台 RUM中，但现实并不像理想那么丰满。比如说，端的问题非常复杂，千奇百怪。很多时候就是头脑一热就想要乘上 AI 的风。所以，即使不行，大家也要硬做。我看了很多竞品，发现一个问题，比如最简单的空指针异常，当你没有上下文时，它只能告诉你加保护，但这个回答对研发没有任何帮助。
那什么才能有帮助呢？
我们团队有多年钻研移动端性能的专家，我们的智慧应该能真正改变这个问题。第一步就是，让我们的专家来拆解 Crash 问题。我亲自参与了问题的分类工作，确保问题被正确地划分，然后通过 FibonaFlow 自定义工作流的赋能，让我们通过知识飞轮不断地沉淀腾讯独家的终端性能问题知识库。
在专家介入之前，我看到的分类如下图所示，我认为这样的分类没有实际用处。有用处的分类，应该是腾讯云可观测平台 RUM 监控到问题的下一步来思考，下一步是“分析定位“。因此，我们就从分析问题的角度去拆解。
最终，我们得到了下图这样的分类，包括兼容性、资源时序和非法操作等问题。
之所以这样分类，是因为它与我们的问题定位手段相对应。例如，对于兼容性问题，我们可以利用腾讯云可观测平台 RUM 的聚类统计数据来确定设备、系统等特征。对于资源问题，如 FD 泄露和内存分析，我们可以使用 Hprof 和 FD 快照让 AI 进行进一步分析。空指针和线程安全问题很可能与时序有关。空指针问题应该在发布前的众多测试中已经被发现，如果没能发现很可能是时序问题，我们可以基于日志分析来解决。接下来，我们就逐个击破，使用工作流 WORKFLOW 和 RAG、混元 AI 来构建我们的“AI 微解决方案”到腾讯云可观测平台 RUM 中。
我们也利用了知识沉淀能力，沉淀了大量的 Crash 分析 & 解决方案。这些文章是通过人工审核的，以确保内容的绝对正确性。到目前为止，我们已经有了 80 多篇经过审核的 Crash 分析 & 解决方案，并且这个数字还在持续增长，每天都有新的内容增加。我们利用 AI 技术将腾讯的经验进行脱敏处理，然后将其放入知识库中。同时利用 Fibona AI 不断地更新这些知识库内容。例如，对于某个问题，我们的输出结果有两条正确答案，而某个竞品只有一条。另一个 AI 搜索工具也只有一条，最牛的 PHIND 列出了三条，基本上都正确。我们自己列出的两条主要原因是因为我们确实调研了使用这种方法时最常见的情况。实际上，最多的情况是两种，尤其是第二种。
腾讯云可观测平台 RUM - AI 微解决方案 DEMO
这个功能已经上线到了我们的腾讯云可观测平台 RUM 的崩溃分析，大家可以在平台上看到 Fibona AI Beta 的选项。我们设定了一定的使用限制，通过工作流来分析内容，并将分析结果输出给研发人员，以帮助他们解决那些复杂的崩溃问题。很多互联网公司其实并没有很好地解决这个问题，因为他们没有足够的资源去招聘专门解决安卓或 iOS 上复杂崩溃问题的人才。这些问题的解决往往需要深入的技术知识和经验。因此，我们将腾讯内部在多个端上的丰富经验传递到这个平台中，以帮助解决这些问题。
小结：从简单的沉淀到构建⻜轮，再到让⻜轮转起来
大家可以看到下图中的循环：我们的知识检索出的知识应用之后，还会进行沉淀，沉淀后又反馈回来，形成一个闭环。我们希望这样的循环最终能让新人更快地成长，同时让有经验的人有更多的时间去创造新的价值。这样，无论是新人还是有经验者，都能从中受益，从而提升整体的效率和效能。这就是我们降本增效的下半场——提高效率，创造新价值。
我的之前写文章中提到了总结助手和代码助手，这些我们已经实现了，但复盘助手还没有。未来，我认为复盘助手也是有可能实现的，因为我们的研发同学在复盘时总不能面面俱到还带着浓厚的主观情绪。一提到复盘，大家可能会觉得要承担责任，如果有 AI 这样一个没有感情的中间角色，可能会减少这种情绪化的甩锅。此外，我们还可以利用这些沉淀的知识，结合类似 NotebookLM 的技术，来进行教育工作，帮助新人快速学习。这些都是我们可以想象并实现的未来应用。
提升战⼒：提建议 ->给代码
与⼯蜂 AI 联动，打造“下⼀步”的开发体验
在提升战斗力的方面，我专注于性能这个垂直领域，也就是当代码出现问题时该如何处理，以及如何进行性能优化。我们内部有两个工具：腾讯云可观测平台 RUM 负责客户端性能分析，而 DROP 负责后台性能分析。这两个工具确实能够进行性能分析，但对于研发人员来说，解决这些性能问题仍然是一件头疼的事情。即使我们引入了 AI，它也仅限于给出建议，同时，代码上下文中存在很多噪声，这也增加了解决问题的难度。
案例：DROP 的内存泄露修复代码
DROP 工具负责进行内存采集，包括内存的申请和释放，以及多维度的日志采集，以此来检查是否存在内存泄露。我们会将当前版本与上一个版本进行对比分析。例如，我们发现在一个版本中内存申请了 3000 次，释放了 3000 次，而在另一个版本中申请了 3000 次，却只释放了 100 次，这就让我们严重怀疑存在内存泄露。在这种情况下，我们会使用 AI 来诊断，得到一个初步的答案或指引。
得到这个指引后，如何具体修改代码。因此，我们联动了刚才提到的代码平台，去出修改方案。这里有一个重要的原因是，我们没有代码的读权限。因此，我们做了这样一件事情：我们定位到可能存在内存泄露的地方，然后 Fibona AI 会提出相应的修改建议，并告诉你泄露代码的具体位置和行数，但不会提供具体的代码内容。接下来，我们会将这个建议关联到我们的代码系统中，让大家选择是哪个项目、哪个分支，以及哪个 commit，如果没有的话就以最新的为标准。点击确认后，它会跳转到我们的工蜂平台，生成修改前后的代码对比，依据我们的性能分析建议，生成对应的性能优化代码。
⼩结：⽤ Fibona AI 来打破数据孤岛的次元壁
很多公司内部有很多平台，但这些平台之间往往是不打通的。我的这个案例的关键可能不在于 AI 本身，而在于 AI 可能给研发流程带来的重大价值。AI 作为一个桥梁，连接了两个完全不相关的平台。我们作为性能分析工具，采集了动态分析的数据，比如函数调用、内存申请释放、日志、火焰图、IO、以及 Hprof 这样的内存快照数据。在以前，像工蜂这样的 AI 工具是没有获取到这些数据的。
现在，我们通过 AI 作为一个第三方角色介入进来，在进行 AI 诊断时，我们可以关联到内部的系统。我形容这是一个打破次元壁的过程。这意味着我们可以更方便地利用 AI 来分析和解决问题，而不是让数据如孤岛般存在。同时我们也期望在未来，这个通过 AI 来联动孤立工具的方式能通过我们在腾讯云上的产品分享给大家。
打造战⼒：核⼼竞争⼒
如何打造我们团队的独特竞争力呢？我们提供云服务，提供 AI 能力，你用了我们的服务，你的竞争对手也用了，这个竞争力从何而来呢？大家可能听说过一个关于核心竞争力的思维模型：VRIO 模型。而 AI 在这个过程中可以发挥巨大的价值。这有几个关键点我稍微说明一下。
●Value：我们定义了知识库。一旦我们定义了知识库，我们就可以产生很多领域的专业话术和专业的解决方案。若能精准解决问题、引导客户、节省成本，都是价值。
●Organization：知识飞轮的概念，即我们检索知识、应用知识、沉淀知识的过程。一旦这个飞轮运转起来，它就会与你的组织完全贴合，不断地产生新的数据和知识。这部分我们称之为组织的自我增强。
●Rareness：每个团队都会面对独特的项目、场景和对应的难题。各种知识都沉淀到了专属的知识库中，使得你的知识库具备了稀缺性。这不是从谷歌或外网上搜来的内容，而是你独有的。
●Inimitability：我们将 AI 融合到我们的工作流程中，这本身就是难以模仿的。因为每个团队的工作流程都是不同的，我们称之为自定义。AI 在现阶段提供的最重要的能力，我认为其实是自定义的能力。以前要实现自定义，需要找研发团队。但现在，研发团队只需要提供一个自然语言的自定义入口给我们的客户，他们就具备了自定义的能力。
每个⼈和组织 + AI
与 AI 带来的⾃定义
通过我们提供的 FibonaFlow，我们可以自定义 workflow，还可以自定义提醒，甚至是自定义知识库。此外，我们可以自定义绑定的平台，并定义各种各样的工具，因为它是一个浏览器插件。这意味着用户可以根据团队的需求和流程定制在浏览器中的内部平台工具之间的联动方式，从而构建独特的竞争力。
我们还有知识库市场，这是一个平台，用户可以在这里分享和获取各种知识库。同时，我们提供了预加工的功能，因为很多知识内容可能比较杂乱，我们可以通过编写 Prompt 来对新加入的知识进行预加工，使其更加有序和有用。
此外，我们还可以自定义一些与平台配合的场景。刚才我提到了打破次元壁的概念，我们可以在这里将自定义的提示词复制并粘贴到 wiki 中。在插件的作用下，界面上会多出一个按钮。用户点击这个按钮后，就可以直接使用这些提示词，并立刻执行以产生相应的结果。
每个平台 + AI
与 AI 带来的⾃定义
我们也为 B 端平台提供了 Fibona AI 的接入服务，就像我们自己的 DROP 和腾讯云可观测平台 RUM 工具一样。未来，腾讯内部将有更多的平台接入这一服务。接入这些平台将提供以下能力：
模型接入与管理：虽然我们不直接开发模型，但你可以在上面管理模型和集成模型。
提示词管理：可以管理提示词，以便在需要时快速调用。
SDK 接入：可以使用 SDK，并通过浮窗、侧边栏或浏览器插件的方式在你的产品中展示这些功能。
如何打造未来的团队呢？我一直在强调自定义的重要性，因为每个团队在使用 AI 的过程中，我发现 AI 的私有化属性非常强。与不同的人沟通时，总感觉需要为他们定制一份特别的解决方案。因此，我认为 AI 的核心竞争力在于通过自定义，探索最适合自己团队价值观、专业领域管理方式的 AI 协同方式。
大家在我们的腾讯云可观测平台 RUM 上体验到 Fibona AI。在这个平台上，我们未来将提供自定义的提示词和知识库，这是我向产品经理提出的要求。因为在 AI 时代，自定义的能力才是站在 AI 肩膀上的团队和企业的核心竞争力。
未来，联动平台的能力也应该是自定义的。每家公司都有自己的代码平台，可能不是工蜂，也可能是自己的 GitHub、GitLab 等，他们不可能都购买我们的产品来使用。但可以使用 Fibona AI 进行联动，从而解决平台联动问题。
Fibona 为什么叫 Fibona？为什么是浏览器插件？
大家可能好奇 Fibona 是什么。实际上，它是从斐波那契数列（Fibonacci）演变而来的。我个人对数学有着浓厚的兴趣，因此我将“cci”去掉，形成了 Fibona 这个名字，寓意着希望这个 AI 能够与员工、平台、公司和谐共存。
我们将执行、发现 & 分析、解决、沉淀的整个流程在不同平台之间打通，从而更有效地解决问题。这也是为什么 Fibona 是一个浏览器插件的原因。在浏览器插件中，我们可以携带用户权限和每个平台生成的数据，访问公司内已经存在的平台，而不需要对方开放 API。这种方式为我们提供了解决数据孤岛、平台孤岛的能力。
我觉得现在很多公司可能也有类似的问题。如果未来有可能的话，我也希望能够帮助大家通过 AI 的方式解决工具孤岛的问题，从而跨越不同工具和平台之间的界限，实现数据和功能的互通，提高工作效率和协同能力。
嘉宾简介：
黄闻欣，腾讯技术总监。自 2009 年加入腾讯以来，参与多个项目的性能测试和优化，如腾讯微博、MAC QQ 等。目前专注于腾讯云产品的性能工程体系建设，致力于结合生成式 AI 技术和工具将性能工程经验普惠更多工程师，帮助他们优化产品性能体验，降低硬件资源成本。同时，作为生成式 AI 的深度实践者，负责产品腾讯云可观测平台 RUM 和 Fibona AI，努力把 AI 融合到研发工作流程中，共享“腾讯经验”，武装技术团队。
会议推荐