繁中

微信+ PWA +騰訊TRTC:利用人工智慧輔助開發打造親子視頻通話MVP

最近,我開始嘗試一個非常簡單的想法:

家長用微信開始視頻通話
↓
孩子的平板電腦收到來電
↓
雙方進入視頻對話

乍一看,它聽起來像是一個普通的視頻聊天應用程式。

但當我真正開始構建它時,我意識到這個項目與其說是「製作視頻聊天頁面」,不如說是:

連接微信生態系統,
PWA行為,
實時通信,
和Android平板電腦生命周期管理
變成一個連貫的系統。

最終,整個MVP變成了一個實驗:

SDK編排
+
人工智慧輔助開發
+
架構優先的Vibe編碼

為什麼要建造這個?

最初的動機出奇地簡單。

我注意到許多「家庭陪伴」產品都存在同樣的問題:

對父母來說太複雜了,
對孩子來說太重了。

大多數通訊產品假設:

  • 兩個用戶都安裝應用程式
  • 兩位用戶都註冊了帳戶
  • 兩個用戶都學習界面
  • 兩個用戶都管理權限

但實際上:

大多數家長已經生活在微信里了。

所以問題變成了:

家長只能用微信嗎?
雖然兒童只使用平板電腦,
並且仍然實現流暢的視頻通話體驗?

這成為MVP的核心目標。


最初的架構

第一個系統設計是這樣的:

微信端
↓
後端服務
↓
騰訊雲IM / TRTC
↓
兒童平板電腦

每個層都有不同的責任:

微信:
入口點

即時通訊:
消息收發和信令

TRTC:
實時音頻/視頻

平板電腦:
來電UI和視頻顯示

這很早就導致了一個重要的認識:

IM與視頻通話不同。

一個重要誤解

最初,我假設:

騰訊雲IM SDK
收件箱視頻通訊SDK

但在更仔細地閱讀文檔後,架構變得更加清晰。

騰訊雲實際上將系統分為兩層:

騰訊雲IM

騰訊雲IM

負責:

  • 消息傳遞
  • 在線狀態
  • 信令
  • 會話管理
  • 推送通知

同時,實際的媒體層來自:

TUICallKit / TRTC

騰訊雲TUIKit文檔

負責:

  • WebRTC
  • 音頻/視頻流
  • 室管理
  • 麥克風
  • 相機

此時,心理模型終於點擊了:

IM是「門鈴」
TRTC是「對話」

一旦這種區別變得明確,整體架構就會變得非常簡單。


為什麼我選擇PWA而不是原生應用程式

起初,我考慮:

顫振
React Native
原生Android

但後來我意識到:

MVP開發過程中最大的複雜性
不是UI開發。

困難的部分實際上是:

  • 微信生態整合
  • 信令流
  • Android生命周期行為
  • 推送通知
  • 權限
  • WebREC兼容性

所以最終我選擇了:

PWA + APK包裝

原因很簡單:

疊代速度。

平板電腦方面只需要:

  • 全屏UI
  • 麥克風
  • 相機
  • 通知
  • WebREC支持

現代Android Chromium環境對於MVP來說已經足夠好地支持其中大部分功能。

部署路徑最終變成了:

PWA
↓
TWA / WebView
↓
Android APK

這極大地減少了疊代費用。


系統實際工作原理

最終的MVP流程變成:

家長按下「呼叫孩子」
↓
微信發送請求
↓
後台創造空間
↓
IM發送信號事件
↓
兒童平板電腦接收來電
↓
兩位客戶都加入TRTC房間
↓
視頻通話開始

後台主要處理:

用戶Sig一代
設備綁定
室管理
權限驗證
消息路由

與此同時,平板電腦側面處理:

來電UI
相機
麥克風
視頻渲染

最難的部分不是UI

在開發過程中,有一件事變得非常明顯:

最困難的部分不是繪製界面。

困難的部分是:

Android後台行為
PWA生命周期限制
WebREC兼容性
通知可靠性
許可處理

例如:

PWA能否可靠地喚醒來電?

答案原來是:

部分。

不同的Android供應商的行為不同:

  • 不同的WebView版本
  • 不同的Chromium實現
  • 不同的電池政策
  • 不同的背景限制

最終,事情變得很明顯:

純粹的PWA架構不夠穩定。

於是系統逐漸演變成:

PWA
+
APK包裝
+
本地通知橋

那時,該項目不再讓人感覺像是「Web開發」,而是開始感覺更像是:

跨系統編排。

Codex和架構優先Vibe編碼

該項目的另一個有趣部分是開發工作流程本身。

我沒有從頭開始手動構建所有內容,而是嘗試了我所說的方法:

架構優先的Vibe編碼

工作流程看起來像這樣:

閱讀騰訊雲文檔
↓
向Codex描述系統目標
↓
產生建築創意
↓
分析SDK集成路徑
↓
生成PWA結構
↓
WebREC行為
↓
調整Android生命周期處理
↓
不斷疊代

在這個過程中,我意識到一件重要的事情:

人工智慧的最大價值不是「寫代碼」。

它的最大價值是:

加速建築探索。

大多數真正的問題實際上是關於:

  • 系統設計是否有意義
  • SDK是否可以合作
  • 生命周期假設是否有效
  • 生態系統是否存在限制

- 與語法本身無關。


MVP最終取得了什麼

在現階段,MVP已經可以:

  • 從微信發起電話
  • 通知兒童平板電腦
  • 建立實時視頻通訊
  • 通過IM同步信號
  • 在Android平板電腦上運行
  • 通過簡化的交互流程操作

最重要的是:

它終於開始感覺像一個產品,
而不是SDK演示的集合。

最後的想法

這個項目逐漸改變了我對現代軟體開發的看法。

變得有趣的不再是:

「AI會寫代碼嗎?」

更有趣的問題變成了:

「人工智慧可以加速系統級推理嗎?」

因為越來越多的發展感覺不太像:

輸入單個函數

更像是:

組織生態系統,
SDK,
人工智慧系統,
和人類意圖
變成一個連貫的結構。

也許這正在成為人工智慧時代最重要的技能之一。

返回頂端