极简交互：构建全平台浏览器的音视频入口

今天我正式发布了我的第一款产品：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 的辅助，我们可以更高效地调用这些底层能力，构建出更多功能强大且低成本的工具。