---
author: Peter Pang
date: '2026-02-25'
guest: ''
layout: post.njk
source: https://www.youtube.com/watch?v=M1bifAQSVcY
speaker: Peter Pang
tags:
  - webrtc
  - ai-assisted-coding
  - p2p-communication
  - browser-apis
  - state-machine
title: AI 驱动的 WebRTC 实践：零成本构建全平台 P2P 视频通话系统
summary: 作者分享了利用 AI 开发基于浏览器的 P2P 视频通话平台 o2o 的全过程。文章深入探讨了 WebRTC 的技术架构、STUN 与 TURN 服务器的成本权衡，以及在大语言模型超长上下文支持下解决复杂状态机 Bug 的工程实践经验。
insight: ''
draft: true
series: ''
category: software-development
area: tech-engineering
project: []
people: []
companies_orgs: []
products_models:
  - o2o
media_books: []
status: evergreen
---
### 极简交互：构建全平台浏览器的音视频入口

今天我正式发布了我的第一款产品：**o2o**（One-to-One: 独一无二的一对一视频通话平台）。这个平台完全基于浏览器运行，无需安装任何客户端或插件。用户只需点击发起通话，将生成的网址发送给对方，两人即可在浏览器中直接进行无时间限制的视频聊天。该平台实现了真正意义上的全平台覆盖，无论是电脑还是手机，只要能打开浏览器就能使用。

这一体验的实现依赖于**浏览器原生功能**（Browser Native APIs: 现代浏览器内置的标准接口），特别是最核心的 **WebRTC** 和 **Web Socket**。开发这个平台的初衷是为了照顾我的“社恐”粉丝。在直播连麦时，许多观众因为心理压力或隐私顾虑不敢在公开场合发言，且我也未添加任何粉丝的私人联系方式。孔子曾说“求人不如求己”，于是我决定自己动手，打造一个私密、便捷的一对一沟通渠道。

### 架构决策：WebRTC 与 P2P 的零成本方案

虽然我自称“造”了这个平台，但实际过程更像是一位**产品经理**在与 AI 协作。我负责准备工作环境、定义需求并进行验收，而具体的代码编写全由 AI 完成。在部署方面，我利用了现有的云服务资源，包括 **Kubernetes**（生产级别的容器编排系统）、**Redis**（高性能 Key-Value 数据库）以及 **PostgreSQL**（开源关系型数据库）实例。

为了实现零成本运营，我选择了特定的技术路径。**WebRTC**（Web Real-Time Communications: 二零一一年成为 W3C 标准的网页即时通讯 API）是系统的核心，它允许两个浏览器进行端对端的音视频传输，而服务器仅需负责同步双方的信令信息。这意味着后端仅需提供基础业务接口和 **Web Socket**（用于实时双向通信的网络协议）支持，单次通话的服务器流量消耗仅为几十 KB。

在技术细节上，我明确要求 AI 仅提供 **STUN 服务器**（Session Traversal Utilities for NAT: 用于获取内网设备公网 IP 的服务），而不提供 **TURN 服务器**（Traversal Using Relays around NAT: 在 P2P 失败时中转流量的服务器）。因为 TURN 服务器需要转发所有视频流，会产生高昂的带宽成本。考虑到 **o2o** 的使用场景，我决定不支持企业和校园等限制 P2P 的复杂网络环境。这种决策确保了用户可以无限时长地免费通话，因为带宽消耗完全发生在用户端的对等网络中。

### 工程迭代：AI 在复杂状态机中的深度 Debug

整个平台的开发周期约为十个小时，其中大部分时间由 AI 运行，我仅负责测试与 Bug 反馈。整个开发过程跨越了 6 个对话 Session，累计消耗了约 **120 万个 Token**。随着任务进入深水区，AI 在超长任务窗口中持续进行 **Debug**（程序除错：发现并修复软件错误的过程）的能力显得尤为关键。

在第五个 Session 中，我遇到了最核心的工程挑战：视频通话过程中的断开重连问题。由于 **WebRTC** 原理上支持多人视频，为了严格实现“一对一”逻辑，必须在业务层精确限制连接人数，并实时记录参与者的进入、通话及断开状态。

这类问题本质上是**状态机问题**（State Machine: 系统状态及其转换逻辑的数学模型）。当状态信息分散在 **Web Socket**、服务器内存和 **Redis** 缓存中时，状态同步的微小瑕疵就会导致“一人断线全员下线”或“虚假满员”的错误。AI 在这一阶段通过反复翻看自己写的代码，不断增加中间状态、修正读写顺序并及时清理过期数据，最终通过消耗约 20 万个 Token 修复了这个复杂 Bug。这印证了一个趋势：AI 编程若要进入复杂软件工程领域，最重要的不是一键生成简单页面，而是在长上下文窗口中持续处理复杂业务逻辑的能力。

### 未来展望：挖掘浏览器原生 API 的功能宝库

目前完成的只是 **o2o** 的核心版本，未来还有大量基于浏览器原生 API 的扩展空间。例如：

*   通过 **RTC Data Channel**（WebRTC 数据通道）实现端对端的文件传输；
*   利用 **Media Devices API** 实现屏幕共享功能；
*   通过 **Media Stream API** 进行视频录制；
*   应用 **Web Audio API** 进行环境降噪；
*   使用 **WebCodecs API** 为视频画面添加实时水印。

现代浏览器本身就是一个无穷无尽的技术宝库，通过 AI 的辅助，我们可以更高效地调用这些底层能力，构建出更多功能强大且低成本的工具。