一、背景：团队在 AI 辅助开发中的痛点 随着 Claude Code / CodeBuddy 等 AI 编程助手的普及，腾讯体育团队在日常开发中逐渐积累了大量与 AI 协作的经验。但在推广过程中，我们发现了几个反复出现的问题： 1. 重复解释团队上下文 每位同学使用 AI 时，都需要反复告诉它：“我们的路由怎么跳转”、“我们的架构层级是什么”、“Commit 格式应该怎么写”。这些团队共有的知识，每次都要重新解释。 2. 有效方案无法沉淀复用 某位同学花了一下午和 Claude 反复沟通，终于摸索出某类问题的可靠解决方案。但下一位同学面对同样的问题时，却不得不从头再来——AI 不会记住上一位同学的探索成果。 3. 规范依赖自觉，缺乏确定性保障 可以把规范写进 Prompt，但 Agent 是否遵守取决于模型"自律"。关键的验证步骤（如编译检查、commit 格式）需要确定性的工具触发，而不是靠模型"记得做"。 4. 社区能力与企业场景之间存在鸿沟 Claude Code 社区（如 OMC/oh-my-claudecode）提供了优秀的多 Agent 编排、自动规划等能力，但它不了解我们团队的 tRPC/DDD 架构约定、日志规范、代码评审流程等企业特定知识。 二、核心思路：“AI 时代的业务组件” OSC（oh-sports-claudecode）的核心设计理念是： 一个同学与大模型反复沟通，最终沉淀出某类问题的解决方案（知识库 + Skill）；下一个同学直接复用，无需再次摸索，AI 开箱即用地理解我们的业务上下文。 这与"业务组件"的思想完全一致——只是这里的"组件"不是 UI 组件或函数库，而是 AI 可消费的知识与工作流。 传统组件： 团队共享代码 → 减少重复实现 AI 业务组件：团队共享知识 → 减少重复沟通 基于这个思路，OSC 在 oh-my-claudecode (OMC) 开源框架之上，构建了一套适合腾讯体育团队的 AI 工作流体系。 三、架构设计：三层体系 OSC 采用 知识层 → Workflow 层 → 工具层 的三层架构，每一层职责清晰、可独立演进。 ...

Function Calling 2.1 要解决的问题 传统聊天大模型只会说话，没有工具调用能力，这使得大模型： 无法感知环境：无法与外部数据源交互，如通过 API 查询网页、查看用户本地文件、访问远程数据库等等 无法改变环境：无法帮用户实际执行任务，如跑代码、发邮件、上传作业等 2.2 如何解决问题 后端 + LLM 传统方案 工作流程 存在的问题 是否调用工具、调用什么工具由后端负责判断，逻辑复杂且容易误判。 AI 这么智能，为什么不让它来帮我判断？ 调用工具的参数由后端负责构建，难度很大。 AI 这么智能，为什么不让它来帮我生成参数？ 广义的 Function Calling 是指让大模型能够调用外部工具的一种技术实现：先向大模型提供可用函数的列表及说明，由大模型在对话过程中智能判断是否需要调用函数，并自动生成调用所需的参数，最终用文字返回符合约定格式的函数调用请求。 狭义的 Function Calling 特指大模型提供商在模型内部与 API 层面做了支持的一种能力，它最早由 OpenAI 引入： 在模型层面：模型提供商需对大模型进行特别优化，使其具备根据上下文正确选择合适函数、生成有效参数的能力（比如有监督微调、强化学习）。 在 API 层面：模型提供商需额外开放对 Function Calling 的支持（比如 GPT API 中提供了一个 functions 参数）。 Function Calling 方案 基于提示词的 Function Calling 工作流程 System Prompt 示例 System Prompt 示例 # 你的角色 你是一个函数调用助手，我将提供多个函数的定义信息，包括函数名称、作用、参数及参数类型。 # 你的任务 - 根据用户的输入，判断是否需要调用某个函数 - 如果需要，请**严格按照以下格式**输出函数调用指令： json { "name": "函数名", "arguments": { "参数名": "参数值" } } # 函数定义信息 1. **get_weather** - 作用：查询指定城市的天气情况 - 参数： -`city`（string）：城市名称 2. **get_time** - 作用：查询指定城市的当前时间 - 参数： - `city`（string）：城市名称 存在的问题 输出格式不稳定。如调用指令中存在多余自然语言。 容易出现幻觉。模型可能编造并不存在的函数名或参数。 大模型提供商能否对模型进行微调、强化学习，提升大模型在这一方面的能力？ 对开发者依赖度高。函数描述、调用指令格式、提示词逻辑完全由开发者设计。 函数描述、调用指令格式能否由大模型提供商来指定？系统提示词中的"说明与规则"逻辑能否由大模型提供商来兜底？ 上下文冗长，Token 消耗大。为确保调用逻辑正确，往往需要在 system prompt 中加入大量说明与规则。 基于 API 的 Function Calling 工作流程 ...

阅读导航（建议先看） 如果你是第一次接触这套 SDK，建议按下面顺序读： 先看 2 章：理解 commonMain 与双端 actual 的职责边界； 再看 5~6 章：把“主流程 + 双端播放器实现”串起来； 最后看 10 章：按需查 Debug 手册，不必一次读完。 如果你只想快速建立整体认知，优先看 0 + 5 + 9 + 12 四节即可。 0. 这篇写什么 这篇不再重复 KMM 概念，而是聚焦一件事：AIRead 这套 KMM SDK 在工程上到底怎么跑起来。 会重点回答四个问题： 工程目录怎么分层； 核心 API 给了什么能力； 从 start(contentId, sentenceId) 到播放/高亮/回调/重连，链路如何闭环； Android（ExoPlayer）和 iOS（AVPlayer）分别承担了什么。 KMM 基础与平台适配背景放在上一篇：KMM 基础篇。 1. 仓库目录总览 AIRead 仓库根目录： AIRead/ ├── androidApp/ # Android 示例应用（Compose + WebView） ├── iosApp/ # iOS 示例应用（SwiftUI + WKWebView） ├── shared/ # KMM SDK 主模块 ├── gradle/ # 版本目录、发布脚本、wrapper ├── build.gradle.kts ├── settings.gradle.kts ├── gradle.properties └── README.md 先按根目录分工看一眼： ...

阅读导航（建议先看） 这篇文章信息量很大，建议按下面顺序读： 先读 0 章：把 KMM、LLVM/IR、KuiklyBase-kotlin 的关系建立起来。 再读 2 章：看 ovCompose 在 iOS 上如何解决混排与性能问题（重点是 2.4）。 最后读 3 章：看 ovCompose 在鸿蒙上的架构补齐与落地结果。 如果你时间有限，可以先看每章的小结段，再回到细节表格和时序图。 0. 什么是 KMM KMM（Kotlin Multiplatform Mobile） 是 JetBrains 推出的跨端代码复用方案：共享业务逻辑，不共享 UI。它的核心价值不是“写一套 UI 到处跑”，而是“用一套业务代码支撑多端原生体验”。 为了避免概念混淆，可以先把 KMM 放到两个对比里看： 对比 RN/Flutter：RN/Flutter 是 UI + 逻辑一起跨端，带独立渲染与运行时；KMM 只共享业务逻辑，UI 仍由 iOS/Android 原生实现。 对比传统混编 SDK：传统方式多是单端产物复用；KMM 是同一套 Kotlin 源码多端编译，天然支持平台差异化实现。 一句话：KMM 更像“跨端业务层统一”，而不是“跨端 UI 统一”。 0.1 给非编译器读者的背景知识（LLVM / IR） 如果你不是编译器方向，可以先记住 4 句话： 编译器做的事，就是把高级语言（Kotlin）翻译成目标平台可执行代码。 **IR（Intermediate Representation，中间表示）**是“中间语言”，用于把“前端语法分析”和“后端机器码生成”解耦。 LLVM不是单一编译器，而是一套编译器基础设施（优化器 + 后端代码生成等）。 KMP 的 Native 路线里，常见链路是：Kotlin 源码 -> Kotlin IR -> LLVM IR -> 机器码/.so。 其中最容易混淆的是两个 IR： ...

背景介绍 腾讯体育的个人直播业务中，主播开启比赛陪看直播一直仅支持移动端开播。然而，移动端开播存在屏幕尺寸过小、摄像头拍摄角度受限等问题，严重影响了主播的解说体验。为了提升主播在比赛解说场景下的使用体验，同时降低使用 OBS 进行运营的人力成本，我们决定在腾讯视频 PC 开播助手的基础上进行迭代开发，新增对腾讯体育比赛陪看功能的支持。 选择陪看比赛界面： 陪看解说画面： 从零开发一款 PC 开播软件的成本较高。幸运的是，腾讯视频已经拥有一款成熟的 PC 开播助手，用于支持主播或艺人在 PC 端进行直播。虽然当时该产品尚不支持陪看直播功能，但我们可以在其基础上进行二次开发：接入腾讯体育的账号体系，并新增比赛陪看能力，从而以最小的开发成本实现业务需求。 整体架构概览 腾讯视频 PC 开播助手基于 Electron 框架开发，推流等核心功能则依赖 OBS Node（obs-studio-node）实现，前端部分采用 Vue.js 技术栈。 OBS Studio 是一款知名的开源直播与录屏工具，其客户端使用 Qt 框架绘制界面。OBS Node 是将 OBS Studio 的核心功能模块进行封装，使其能够被 Node.js 直接调用的扩展库。 OBS 原生支持多种推流协议，但腾讯视频直播中台采用的是 TRTC（Tencent Real-Time Communication）协议。在此基础上，视频 PC 开播助手对 OBS Node 进行了以下扩展： TRTC 协议支持：实现基于 TRTC 的推流和连麦功能； 移动设备开播支持：支持使用手机等移动设备作为视频源进行开播。 整体技术架构如下图所示： 图 1｜整体技术架构 Renderer 进程Vue UI ⇄ IPC ⇄ Main 进程Node + Native → OBS Node + TRTC SDK 腾讯体育后台服务（账号/房间/陪看控制） → Main 进程 虚拟主播（比赛点播转直播） → TRTC SDK 主播推流 → TRTC 云端混流 → 观众端 多房间架构设计（SubRoom） 陪看场景最大的技术约束是：主播需要同时处于主直播间和虚拟陪看房间。为此我们在 TRTC 单房间模型之上封装了 ITRTCSubRoom，并通过 SubRoomService 统一管理子房间生命周期。 ...

AI/LLM 相关面试题

iOS APM 监控面试题

iOS 基础面试题

iOS 进阶面试题