TechMoon 科技月球
WordPress、SEO 與 AI 工具實測指南
Devin 測折疊 App：把 iPhone Duo 鉸鏈狀態變成可重跑任務
Cognition 開發者示範 Devin 在雲端 macOS 虛擬機器測 iPhone Duo 折疊 App：相機範例走過展開、半折、闔上的鉸鏈狀態，交出操作影片與逐項通過清單兩種證據。對照官方文件，模擬器能驗證的範圍、影片證據的加工方式，以及實機驗證仍然無法取代的部分，邊界一次看清楚。
用 AI 摘要這篇文章：
台北時間 10 月 17 日凌晨 2 點 17 分，在 X 帳號掛著 Cognition 企業標章的開發者 Nader Dabit 發文，寫得很直白：Devin 現在可以在 macOS 雲端虛擬機器上建置並測試 iPhone Duo App，「把手機展開、折起來、闔上，檢查每一個畫面，並取得所有操作的影片驗證」。文中附了一段約 37 秒的螢幕錄影。
錄影裡的東西比配文具體。那是一部叫 Pose Mirror 的相機類範例 App 的驗證紀錄：畫面右側的測試面板寫著「5 passed, 0 failed」，測試項目包括平面擺放時 3 秒與 5 秒倒數拍攝、沿摺痕分割畫面並跨鉸鏈角度取景、半折立在桌面拍照、中途闔上後的照片保留，以及闔上狀態用主鏡頭自拍。被攝者在外螢幕上即時看見自己，倒數同步出現在兩個畫面上，擺姿勢的提示文字跟著取景角度變動。
時間背景讓這段錄影不只是一則貼文。蘋果官網標明 iPhone Duo 10 月 23 日開賣，這是蘋果自己定位的第一款折疊 iPhone，7.6 吋內摺疊螢幕加上 5.4 吋外螢幕，相機是 48MP Dual Fusion 相機系統（兩枚 48MP Fusion 鏡頭）配 12MP Center Stage 前鏡頭，行銷主打之一是「從前拍到後」的新拍法，規格表也列出 Dual Capture。App 要在展開、半折、闔上之間活得下去，是開發團隊本週就要面對的驗收題，Devin 在開賣前六天交出這條工作路徑。把官方文件與這段影片逐格對照後，值得拆開來回答的是三個問題：它到底在什麼東西上測？影片與通過清單能當什麼證據？現在誰能用、代價怎麼算？
這是在 iPhone Duo 上測嗎？嚴格說，測的是它的虛擬替身
答案寫在 Devin 的官方文件裡。macOS support 頁說明，Devin 的 macOS 工作階段跑在雲端虛擬機器上，環境預載最新的 Xcode 26 當預設，旁邊附一套 Xcode 27 預先發布版；每套 Xcode 各配一個 iOS 模擬器 runtime（iOS 26 與 iOS 27），每個 runtime 都預先建好一台 iPhone 模擬裝置，Homebrew、Node、Python 這些也在映像檔裡。代理靠 Computer Use 拿到整個 macOS 桌面的滑鼠鍵盤控制權，可以直接開模擬器、裝 App、點畫面；工作階段裡的「Computer」分頁會串流模擬器畫面，人可以全程盯著。官方把 macOS 與 Linux、Windows 並列為正式支援的平台，開工作階段的方式有好幾種：設定檔裡指定 runs-on: macos、在 Slack 用 !mac 指令、透過 API 帶 platform 參數，或由管理員把 macOS 設成組織預設。
Dabit 的示範影片走的正是這條路。錄影裡的分頁標題是「Build iPhone Duo Apps」，掛著 macOS 標章，另一個工作分頁名稱帶著「real hinge」（真實鉸鏈）字樣。測試把折疊當成可以操作的物理狀態：面板紀錄把取景角度寫成可讀的數列（上仰 29 度、上仰 5 度、下俯 20 度），App 畫面同步跳出「Aimed 29° up」這類取景提示，手機半折立在桌面時觀景窗跨過摺痕，倒數到一半闔上再打開，相簿裡的照片一張不少。錄影裡還能看到測試從乾淨狀態起步：面板記著重新安裝、空相簿、普通啟動的起始條件，避免把上一輪留下的資料誤當成這一輪的保留成果。
邊界也在同一頁文件裡。Limitations 表列得明白：雲端 macOS 環境沒有 USB passthrough，建置與測試都在模擬器裡完成，接不上實體 iPhone 或 iPad；虛擬機器裡的效能量測（Instruments 級的計時與分析）不能代表真實裝置表現。還有一件事容易漏看：官方文件的完整索引裡找不到 iPhone Duo 這個名字，文件範例用的裝置是 iPhone 17，Duo 專屬的內容只存在於員工示範這一層；映像檔預配的模擬裝置，文件也只寫「一台預配的 iPhone 裝置」，沒有指名型號。
所以能確定的是「Devin 可以在雲端模擬器裡驅動折疊狀態並驗證流程」，還不能確定「Duo 模擬裝置已屬於標準環境映像檔」。把這兩句分開寫進驗收單，才不會過度承諾。Cognition 近期也持續把 Devin 往工程流程深處推，九月才把自研模型 SWE-2 與語音操作 Devin Voice一起推上線。
影片加通過清單：證明流程被走過，時間與覆蓋率要另外算
這次示範最值得看的部分，是測試面板使用的語言。每一項測試都用「It should…」（它應該）的規格句寫成，例如「It should take flat 3s and 5s timer shots with countdowns on both views」（平面擺放時應能以 3 秒與 5 秒倒數拍攝，兩個畫面都有倒數）、「It should split at the crease and track aim across several real hinge angles」（畫面應沿摺痕分割，並跨多個真實鉸鏈角度追蹤取景）。通過之後面板記的是可數的結果：「1/1 passed」、「8/8 shots retained」。摘要行甚至寫著「No instant shutter mode exists; two extra timing attempts are disclosed」：這個範例 App 沒有即時快門模式，過程中多做的兩次計時嘗試也一併揭露在紀錄裡。錄影裡的另一行紀錄也值得記下：關閉鏡像功能會藏起子畫面預覽，打開又恢復，七個姿勢提示都對得上文字。
這段摘要值得停下來看。清單裡連不存在的模式與多做的嘗試都寫出來，代理沒有只挑成功的地方講。對要驗收代理產出的團隊來說，這種把測了什麼、邊界在哪都留下的完整紀錄，比一段剪得流暢的影片更接近可核對的交付物。
折疊 App 的測試重點也在這裡現形：驗的從來不是單一畫面排得整不整齊，而是狀態轉移之後，使用者手上的工作還接不接得下去。這段錄影把「接得下去」翻譯成可數的東西：倒數中闔上手機，今天拍的 8 張照片全數保留；取景角度連續變化（上仰 29 度、上仰 5 度、下俯 20 度），觀景窗跟著摺痕分割追蹤。資料保留與畫面呈現是兩件事，分開驗才算真的驗過。
至於影片本身能當什麼證據，官方文件比貼文保守得多。testing-and-recordings 頁寫明：錄影會自動加上文字註解、在點擊處自動放大、在重點時刻放慢速度，並壓縮閒置時間；它的定位是「單一最重要端到端流程」的快速查核，讓審查者看完能確認功能真的動了；需要更完整的覆蓋時，「應使用既有的測試套件與 CI，而不是視覺錄影」。整個流程有三個階段：先準備環境，再寫測試計畫，計畫會先以訊息送出讓人可以中途修正，然後才錄影執行。計畫的寫法文件也有要求：挑一條最能證明功能可用的端到端流程，步驟要具體到「點選右上角標示為儲存的按鈕」這種程度，並從程式碼裡追溯到實際的介面路徑，而不是憑空猜測畫面長相。成拍的影片以附件形式寄達，在網頁介面或 Slack 都能直接看。文件甚至預先寫了錄影失敗的常見原因（App 當掉、影片處理逾時）與重錄方式，原始執行結果會留在機器上可以再要。測完之後代理還會把這次學到的啟動方式與環境設定寫成 skill，以 PR 形式存回 repo，下一輪測試直接沿用，折疊狀態的回歸測試因此可以一輪一輪累積，每輪都從上一輪的筆記出發。
換算成驗收語言：影片證明「這條流程確實走過、到達了預期結果」，它證不了「花了多久」，也證不了「所有邊界都測過」。這則貼文還多壓縮了一層：X 上的 37 秒其實是 Devin 網頁介面的螢幕錄影，介面裡播放的驗證影片標題是「Pose Mirror in depth」，實際長度 1 分 08 秒。把剪輯過的影片拿來算工時或評估速度，帳會完全算錯。
現在誰能用？方案層級與計價要先看清楚
官方 iOS 教學把帳號條件分成兩層：Pro 與 Teams 帳號的 macOS 工作階段預設可用；Enterprise 要先請帳號團隊為組織開啟 macOS VM，再到設定裡打開 Computer Use 開關，Dedicated SaaS 部署同樣要找帳號團隊。Computer Use 的開關由組織管理員控制，桌面模式本身所有方案都有。
計價是另一個該先看清楚的地方。官方文件寫明，macOS 工作階段目前與對等的 Linux 工作階段消耗相同用量，沒有 macOS 附加費，但隨後加了一句但書：這是促銷期定價，可能改變。換句話說，現在用 macOS 跑折疊測試的帳，不適合直接拿去做長期成本規劃。
環境行為也影響怎麼交辦。工作階段睡眠時，磁碟上的東西都會保留：裝好的工具、clone 下來的 repo、建置快取；但執行中的程式不會跟著喚醒續跑，模擬器與開發服務要重新啟動。跨天的長任務在交接前，先把「喚醒後要重開哪些服務」寫進任務說明，才不會把環境沒恢復誤判成 App 壞掉。另外快照重建後的第一個工作階段會明顯變慢，因為建置快取從頭來過；官方的建議是把預熱建置寫進環境設定檔的維護區塊，讓每次新開的工作階段都從暖好的快取出發，反覆迭代折疊測試時這個差異會直接反映在等待時間上。
要碰到實體裝置，路徑是上傳 TestFlight：Devin 可以在虛擬機器裡封存 App、簽署、上傳、加進 beta 群組。但前置不能代辦：App Store Connect 建檔、具有 App Manager 角色的 API 金鑰、Team ID，都要先存成 secrets，而且帳號持有人層級的步驟與雙因素驗證，官方文件明說需要人工完成。雲端模擬器到實機之間，仍有一段要人走的路。
把驗收單拆成兩份再交辦
整理成決策軸會是這樣。
可以交給雲端模擬器的：狀態轉移本身（展開、半折、闔上、角度連續變化）、狀態改變後的資料保留、操作可重跑，以及「影片加通過清單」兩種證據的自動產出。這些恰恰是人力最不耐煩、最容易漏測的部分。折疊機把測試矩陣撐大了：蘋果官網列了五種姿勢，同一個畫面有內外兩套呈現，鉸鏈又是連續量而非五個定點，人工把每種組合走一遍的成本，比截一張圖檢查高出一個量級，而這種重複又機械的路徑，正是代理相對划算的工作。
必須留給實機的：效能、耗電與溫度（官方明言虛擬機器量測不可代表）、相機實拍畫質、真鉸鏈的阻尼與耐用性。iPhone Duo 10 月 23 日才開賣，這一段多數開發團隊現在還做不了，等實機到位再補。
規格的寫法也值得跟著調整。蘋果官網把姿勢命名為 Landscape、Portrait、Closed、Seated、Standing 五種，那是行銷命名；寫進測試任務時應該落到可核對的轉移句：從什麼狀態開始、做什麼動作、該保留什麼、證據是什麼。照著錄影裡的句式，一條交辦可以寫成這樣：從空相簿開始，啟動 App 並開始 5 秒倒數拍攝，倒數中把手機完全闔上再打開，預期這張照片留在相簿裡，繳交操作影片與逐項通過清單。這種寫法每一格都能判讀成成立或不成立，比「折疊狀態要正常」這種交付要求可驗證得多。
另一個極端是把代理塞進手機裡跑，先前介紹過的 Pelican 與 ESP32 iPhone 代理實作都走這條路；Devin 剛好相反，把手機放進雲端給代理操作。兩條路解的問題不同，一個是隨身自動化，一個是工程驗證。
還要把未確認的部分說清楚：Cognition 官方部落格沒有為 macOS VM 或 Duo 測試發過專文，這波資訊的權威來源是官方文件加員工示範；標準映像檔預配的裝置型號未指名；促銷定價隨時會調。等 10 月 23 日實機開賣、第一批實測出爐，這條雲端驗證路徑值多少，可以對著實機再算一次。
