寒暄一下

最近在為團隊編寫一個影片素材管理工具，有別於我一向擅長的App開發，這次的需求就像ProContent一樣，網頁。對，你沒看錯，網頁。這輩子真的沒怎樣碰過寫網頁的部分（畢竟從國中開始就已經去學寫Android Native App開發嘛...），先大概説一下背景吧(心得在最後)

背景資訊

團隊的投影隊在去年從PowerPoint換用ProPreseter後，素材一直都是在ProContent下載。但因爲ProContent年費真的很貴（$199/year + $99 sign up fee）

而且ProContent，嗯，但凡你有用過應該知道，人家的節點只有在美國...一去一回到200多ms，要不是用VPN，可能真的下載到天方地老了，加上後期打算改用Canva製作背景影片（非牟利機構）...

方案1：外置硬碟

不是不行，而是真的麻煩咧，總不可能每次都讓負責的那位拿回家再插拔。這樣一來，不但容易把硬碟弄失/破，而且辛苦存下來的數據也有消失的風險

方案2：Google Drive / Dropbox 雲端

這個嘛...一個字，錢，素材預計也需要幾百GB，而且路由不一定都這麼近...

方案3：團隊内弄一個NAS + Mac Mini

這不就來了嗎，本來有想過讓NAS獨自升級，但跟朋友談了一下，如果未來有FFMPEG轉譯需求（4K -> 1080p）

NAS一來原生沒有適合影片處理需求的Core，二來它的CPU...本來就不是設計來給大型影音處理。試了一下，硬解的話，一段30秒的4K影片轉譯為1080p：

• NAS: 3分鐘
• Mac Mini M4: 6秒（用了Apple的 VideoToolbox)

高下立判，還是乖乖用Mac Mini處理前後端吧...

需求

基本上就是ProContent 優化版本（？

需要寫一個能夠讓團隊成員能夠在手機、電腦、平板都能用的網頁，透過瀏覽網頁内陳列的影片素材，選擇自己想使用的影片。然後下載完整集合/單一影片

不過我還是有加點新東西下去

• UI: 基於類似Material的設計，就邏輯那些的就像你用App一樣
  • ProContent看來沒有打算用戶用手機來看，手機用的時候會很燥
  • NavigationBar、返回按鈕、基本上就是一個 8年前Material 2 的設計風格
  • 在展示影片組別的選項，特意不加下載按鈕，主要是希望你按下去再看看才決定
  • 在詳情頁那邊，也把每一影片大小、組別的標籤標示出來
  • 那個主頁的標籤欄，是真的隨機15個出來的，不是ProContent那樣固定
• 篩選、標籤：不但跟你展示它是甚麼標籤、還有顔色可以用來篩選呢！
• 上載功能：這個是因爲使用者都是團隊成員，系統不公開開放（不想被吉）
  • 成員會獲發一個邀請碼，請自己註冊吧w
  • 所以會有上載功能，減輕我每次手打、匯入的工作量
  • 而且能讓其他成員自行上載，不用每次都等我來做，讚啦！ ## 心得分享 好，廢話説完了 然後就是大概心得。

剛開始時，後端是手寫的 後來因爲對Vue.js前端不熟，加上React.js我只用過一下，對它的 useState 不太喜歡（尤其是你嵌套再嵌套後，天知道你到底那個state是哪個的），Kotlin Multiplatform那個我沒問題，我把它簡化了就相當輕鬆 簡單來説，你需要有點相關知識、説仔細點、避免在同一個你不確定的方向嘗試過多次

TL;DR

就我感覺，現在Vibe Coding的門檻確實下降了不少，AI生成的原始碼相對過去，比較多是可信的。

作為一個上學期修了軟體開發的人，多少還是會習慣刻意注重開發流程的...但這次從接收客戶需求 轉為「我就是那個客戶」，感覺突然輕鬆了很多誒ww基本上説明白、説清楚細節、專有名詞（不知道算不算），AI就會更加準確給到你想要的東西，別太空泛就好。目前AI還未到專業PM水平這麼強，可以理解為一個剛做1-2年的新人就好。

本來只是打算試試讓AI生成一個React.js 的 demo來看看，怎料它真的做到我想要的UI誒...東西都直接幫你弄好了

跑一下，嗯，CSS錯了一個位置，讓它改一下，得咗。

整體來説就是，作爲「客戶」的你，最好有開發相關的經驗，尤其是Fullstack，是真的需要理解多點介面設計的理論部分有想過讀，但好像沒開這個課程了。而且，你需要多引導AI思考，不然它只會在同一方向越嵌越深

舉個栗子，現在我要處理影片上載功能，因爲Cloudflare僅允許最大100MB（檔案大小）上載，所以AI繼續建議我使用CORS（就是從abc.com向upload.abc.com發出請求時，攜帶file過去）。花了一天下去，做了，但依然解決不了HTTP 499的問題，AI亦不會主動建議你去試其他辦法的

後來跟懂網絡的朋友談了一下，決定還是透過上載時把檔案Chunking傳送，每XXMB分作一個請求來規避Cloudflare限制就好了

所以説，Hmm...樹葉有專攻，你還是需要有點相關知識才能事半功倍

大概是這樣，只是你不用自己親手修BUG，還有幫你快速弄好skeleton為主，可能適合用來做MVP更多吧。不要過份期望AI能幫你加速超級多，還是多動腦袋想想，不要甚麼都説好吧。

该渲染由 Shiro API 生成，可能存在排版问题，最佳体验请前往：https://dev.voc2048.com/notes/6

看完了？说点什么呢

该渲染由 Shiro API 生成，可能存在排版问题，最佳体验请前往：https://dev.voc2048.com/notes/4

看完了？说点什么呢

今天做了...

(昨天)

• 推倒整個專案，重新從結構開始寫過，原因如下：

  • 角色列表的加載速度，以及因為Lazy屬性而不斷使圖片會重新加載
  • 為了避免頁面Navigation Back後重新加載，引入ViewModel (MVI) 架構
  • 本來沒有妥當處理好Apdative UI相關需求
  • 減低App大小（Assets）
  • 現有專案結構過於平面化，把所有和該頁面相關的子控件和業務邏輯都放在同一個kt檔案內
  • 避免每次更新都需要等待App商店們的審核... qq

• 觀摩了大大 對於Adaptive UI 和 ViewModel 的寫法，而且都是CMP！

  • 部份結構設計和Kanban都是有曾參考以上專案

• 引入了GitHub Issue Priorities, 嘗試盡力跟照Git Commit Message指引

(今天)

• 處理好HomePage初始化
• 導航系統也做了一點
• 一點點把SG3本來的東西搬過來，然後要按照MVI的方式處理介面相關的東西
• 做好了Kanban 了，以後就可以在這邊看到我們的進度了

今日心情

• 考試已經考了一半，算是不錯的結果
• 很久沒有寫一天代碼了，有點不適應

疲倦指數 ( 🟩 🟨 🟧 🟥 )

• 🟩 🟩 🟨 🟨 🟧

该渲染由 Shiro API 生成，可能存在排版问题，最佳体验请前往：https://dev.voc2048.com/notes/2

看完了？说点什么呢