CubeLV:AI團隊、藍圖與交件卡的產品查核,點數、插件及資料流先看清
核對創作者求收購貼文、官網、雙商店與公開條款,區分可確認的產品存在和未驗證的三萬用戶/千人付費;整理點數、Max MCP、工作區插件權限及Gmail自動化邊界。
CubeLV值得研究的是「先核准藍圖,再建立AI部門、工具與可批閱成果」的產品流程;「比Grok Bot強、3萬用戶、約千人付費」仍是作者自述,沒有同條件比較或公開營運憑證。本篇核對公開官網、商店、定價、隱私與條款,不把宣傳動畫、App上架或有CTA的卡片當成安全與交付驗收。
社群來源:公開求收購不是已發生交易
作者idontwantthreehigh在Threads介紹打造AI團隊的CubeLV,自述六月上線、累積三萬多用戶與約千位付費者,並公開表示希望被收購。貼文是對Grok Bot討論的回覆,畫面中的上游Grok相關貼文不等於對CubeLV的推薦、比較結論或收購意向。[1]
作者主張包含前後端插件、可改UI乃至App架構、錄影加時間戳逐字稿回報AI修正、先確認藍圖、可操作架構圖,以及集中待批閱的交件卡。被引用的2026-06-18舊帖談雙商店上架與一人AI團隊;本次可見新增留言主要是求收購的玩笑,coverage為partial。未取得完整產品操作影片、內部架構或營運帳表。[1]
能確認的產品定位與商店存在
官網將CubeLV定位為可組建AI投資團隊的雲端工作區,描述先諮詢與核准施工藍圖,再建立部門、AI員工、資料夾、待辦、交棒與排程;插件元件還可嵌入報告,AI CEO定期提出改善建議。這些是官方功能宣告,官網展示的「100%」「運作中」不是本次建立團隊後的實際結果。[2]
Apple台灣lookup查得對應App、版本5.43、最初releaseDate為2026-06-06,目前版本日期為2026-10-21;六月十八日是作者的公告日期,不能直接當最初商店上架日。Google Play也有com.cubelv.app條目與2026-10-21更新記錄。Apple的賣家欄是個人名稱,Google及官網標示Runvo LLC;本篇只記錄各平台公開欄位,沒有驗證背後契約關係。[6][7]
Google Play當時顯示5,000+下載,不等於全平台註冊、月活或付費戶數,不能拿它推算或否定作者的三萬用戶。反過來,商店有下載與評分也無法驗證約千名付費者、MRR、留存或單位經濟;這些仍待可核對報表。[1][7]
免費下載不等AI團隊無限運作
官網定價明列:Free是一次性500點AI credits與2GB儲存;Pro每月US$10.99、每月5,000點與100GB;Max每月US$29.99、每月20,000點與100GB,另可加購credits。外部MCP是Max專屬,Free與Pro不含;所有方案看得到教學,不代表有同樣連線權限。[3]
頁面說AI員工讀資料、寫報告及重建工具會消耗點數,模型越重消耗越多;用完後AI會停,等待重置或加購,既有工具與資料仍在。沒有足夠公開資訊把點數精確換成任意部門每天可完成幾項工作,因此不以方案月費當完整營運成本保證。[3]
有價值的設計:把規劃與審核變成具體介面
依作者與官網描述,可借鏡的流程是:先把需求翻成可修改藍圖,核准後建立實體任務與工具,再以文件、待辦與成果卡交棒,重大變更送回待批閱。相較只讓多個Agent在背景對話,這更強調人看得見的工作物件;但是否確實比Grok Bot好,要看同任務、同工具權限、同模型與成本的對照,不是比較介面名詞。[1][2]
以下是編輯建議,不是已驗證功能:每張交件卡應有task id、owner、輸入來源、成品連結、驗收紀錄與失敗狀態;CTA應清楚顯示將改哪個系統、使用哪個身分。按「批准」不宜只是外觀,需驗證後端是否把批准綁到精確版本與動作,舊卡能否重播、是否可撤銷,以及通知與實際執行是否分離。
重要資料流:雲端同步,不是local-only
2026-10-22更新的隱私政策寫明,筆記、卡片、任務、檔案、附件、AI對話、插件及設定存放AWS、主要在日本東京,傳輸採TLS。內容預設不公開與資料完全不出機是兩回事;跨平台同步不能當端對端加密或供應商無法讀取的保證。[4]
AI輸入依選擇的模型送往第三方供應商;政策列出Anthropic、OpenAI、Google、Moonshot、DeepSeek及Z.AI,Auto則由系統決定。供應商地區與不訓練的說明是CubeLV政策宣告,本次沒有逐家驗證實際API帳號、跨區處理及保留安排。不訓練也不等零保留。匯入客戶文件、交易資料或個人信件前,須先明確核對允許的模型與資料範圍。[4]
Google Play的「不與第三方分享資料」是開發者提供的資料安全標籤,不應解讀成完全沒有第三方處理;產品隱私政策已列外部AI處理路徑。這不在此直接判定違反商店規定,而是提醒要讀標籤定義與完整政策。[4][7]
插件與錄影回饋:能力越大,越需要權限界線
政策寫明安裝或執行插件即同意其存取所在工作區資料;條款則說使用者插件不由平台開發、審查或背書,不承諾主動審查。這是工作區範圍的授權說明,不能假設每個插件已有細粒度scope或安全沙箱。作者提到monkey patch更是應另驗證的能力,不是安全性證據。[1][4][5]
錄影操作+錄音轉文字再交AI修正的概念很實用,但也可能把畫面上的帳號、客戶內容與環境資料帶入回饋。公開政策說明附件與對話會儲存,不足以確認這個錄影路徑的遮罩、同意、保存期限與所有處理商。本次未開啟錄影或麥克風,也未輸入私人資料。[1][4]
Gmail與自動批准:整合存在不代表每封都等人按確認
政策描述Gmail只索取gmail.send,不透過Gmail API讀取信箱;來信若要由Agent處理,需使用者自行設轉寄,轉寄內容會成為工作區項目。政策另說寄信僅限回覆、固定原寄件人及頻率上限,token加密儲存。這些是公開設計宣告,尚未實測API scope、限制強制與失敗情況。[4]
條款5.2允許排程、收信或其他事件觸發自動化操作,並明說不保證阻止所有非預期行為;政策也允許已設定的Agent依指示決定回信。所以「藍圖先核准」與「每個動作都要人工批閱」不是同一件事,不能用官網重大變更送審的描述概括全部行為。[2][4][5]