前言:
一直以來都用SendAnywhere，但它現在Linux版好像有點問題，WebRTC一直不太會寫，正好拿AI練習，一方便讓AI幫忙寫WebRTC，另一方面嘗試用AI寫個包括前端、後端、應用程式的完整專案，看看實際運作會遇到哪些狀況。
程式取名為Anywhere Sender，希望能跟SendAnywhere一樣方便好用。😀
對了～除了手機版本與應用程式版本之外，還有CLI版本喔。
實做的時間比預期長，我本來還以為一週就能打完收工，沒想到修修改改修修改改弄了快3週，就算是現在我認為都還算是Beta版，WebRTC的部份看來還是得下去看過順過流程，看來AI開發這事，在除錯階段還是會花費很長時間。
成果:
整份專案在
https://gitlab.com/ycfunet/anywheresender
實做過程:
實做過程遇到不少問題，就算是目前Release，我認為都還需要優化，但已經玩了3週了，就先Release一個Beta版。
這邊會列出2種在開發和測試階段遇到的狀況，一種是純粹開發遇到的，一種是AI開發時會遇到的。
開發問題：
1. AvaloniaUI System Tray問題
System Tray在Windows和MacOS應該沒什麼問題，AvaloniaUI在Windows和MacOS的行為描述都還完整，但在Linux下面，我用的MATE Desktop就無法顯示，一查發現xembed和SNI的問題，光這個就花了些時間，AI在這時候帶來的好處是，寫測試程式很快，以往大概都要先花半天一天survey，survey包括測試程式要用的Library、SDK、原理，寫一個測試可能需要半天一天，然後第二個測試程式、第三個測試程式，這功能可能最快需要3天，AI寫測試，給它參考網站和技術文件，它就能寫，幾個小時就能寫出3~4個測試程式，整個問題排除只需要半天~一天，時間大幅壓縮。
測試時，問AI它會說可能是A, B, C, D什麼的，但其實都不對 😂
直接問它，那為何Electron正常，但AvaloniaUI不正常，AI就也沒答案，還是得survey，不過好處是，AI看程式碼很快，直接丟Electron程式碼和Qt程式碼給它，它就能從中給出它們寫了2種模式 😂
2. Web QR-Code掃描器元件
AI建議用Web的QR-Code掃描器Library，但用了之後，AI寫出遞迴地獄，造成QR-Code掃描器時好時壞，無法正常運作，而且怎麼改都改不正常，後來下去看QR-Code掃描器Library，自己先個Sample，讓AI看Sample改進去，遇到React還是改不成功，最後讓AI把Sample包成function，React直接呼叫function才改成功。
看來，AI在遇到複雜的程式碼狀態時，跟人一樣會混搖，老方法依然適用，讓AI寫Sample Code或人寫，然後包成API讓複雜程式碼呼叫。
3. Web的WebRTC與SIPSorcery的WebRTC相容問題
同樣是WebRTC，但SIPSorcery傳遞的預設參數和Web版的WebRTC不太一致，這應該正常，只要不同的SDK，很容易遇到通訊協定有些差異要調整的，這個顯然AI也會遇到，跟人Debug一樣，時間同樣無法變快，最後一樣是老方法，把SIPSorcery程式碼下載之後讓AI看，讓他自己分析裡面的參數缺少了什麼，才改出。優點是，AI看程式碼很快，給出明確方向，這種問題它能透過分析SIPSorcery、Send、Recv、Web WebRTC給出點和修改，這個人看的話，又要花好幾天，區別是，AI一開始會鬼打牆一直亂說找到問題點，一直亂改，直到你讓它停止，給它分析SIPSorcery和Web的WebRTC差異，它才找出問題點。
AI遇到的問題：
1. Web Framework框架不熟悉
一開始選用Konsta UI Svelte開發，結果寫超破，界面改不出，顯然AI還是要用React或Vue才能寫得好。
2. 檔案傳輸的緩存
AI寫檔案傳輸，預設就用個Web blob直接灌入整個檔案傳送和接收，這當然會造成大檔案傳輸會Memory不足或瀏覽器限制，但這個AI不會特別說，測試時被瀏覽器卡住了，才會說這是OOM(記憶體不足)，顯然這不是正確方向，但它會給出建議縮小傳輸檔案大小。
我給AI要求解法，Web用Indexddb，Mobile用capacitor呼叫原生的FileSystem API，Desktop用檔案存取。
3. 兩端WebRTC檔案傳輸的訊息交換與非同步處理問題
這個其實還沒有完全解完，簡單的說，AI從Server、WebRTC傳送、接收的程式碼中，有可能還無法準確的把時序流程弄清楚，因此陸續改了一堆傳送端、接收端時序問題，像是傳送端丟完WebRTC斷線(接收端還沒收完)、Server信令交換在不同平台實做偏差(導致不同平台互傳漏流程，連線無法建立)、Web非同步動作造成時序的先後順序有問題。
目前我還沒下去完整看過WebRTC程式碼細節，但我認為目前Release 1.0.0版本，應該在Web UI Event(傳輸的狀態回傳)與WebRTC傳送、接收檔案的位置應該還有非同步或Event的問題，這可能是目前傳輸有時候會卡住或無法傳送的原因。
結論:
這次用AI實做了一個完整的專案，包括前、後端、手機、應用程式，速度快了不少，以往我不熟悉的知識領域(WebRTC、React、AvaloniaUI)，透過AI能夠直接開發。
此外，以往工程師可能需要前端、後端、應用程式、手機，透過AI協作，可能真的減少為1~2位資深工程師就能處理。
這次開發的經驗，證實了網路流傳的說法，AI是資深工程師的開發加速器，但老實說對於新手工程師或中階工程師未必友好，因為它遇到問題時會鬼打牆，就算是Claude-Code這種等級，它不會在同一個點鬼打牆，卻會在沒答案的錯誤邏輯中鬼打牆出不來，此時需要經驗引導正確方向或作法，它才能改出，甚至在QR-Code掃描器的開發過程，程式碼複雜時，就算給出Sample Code，它還是會套用失敗，需要包成API用引用的方式才能改出，這表示工程師的經驗依然重要。
