官方手冊截至 2026 年 9 月 7 日仍將 Project Cloud 標為 Beta，並明確不支援兩台裝置同時編輯同一個專案；因此，ATLAS.ti 26 Project Cloud 課題組協作只適合個人跨裝置續作與非同步分工，不適合多人同時共編。需要即時編碼時，應優先評估 ATLAS.ti Web；需要桌面分析、專案合併或編碼者一致性檢驗時，則應建立唯一主專案。
這篇文章適合三類讀者：
- 課題組負責人：需要建立主專案、權限、交付與回收規則。
- 研究生與編碼員：需要在 Mac 與 Windows 之間安全接續，避免覆蓋新版本。
- 高校技術支援人員：需要評估遠端 Mac、帳號授權、資料儲存與桌面版部署邊界。
最後更新於 2026 年 9 月 7 日。 版本、Project Cloud 狀態、同步限制、Web 互通與合併流程，均以 ATLAS.ti 26 Mac 官方手冊及相關官方文件核實。
[ SECTION_01 ] 先按場景選路線，而不是先開啟同步
Project Cloud 的主要價值，是把專案狀態放在雲端，讓研究者在另一台裝置取得專案副本並繼續工作。這不等於多人進入同一個即時編輯畫面。若 Mac 上的版本尚未上傳，Windows 端又開始修改，後續就可能出現版本基線不清、修改覆蓋或需要人工回退的情況。
目前可先用以下原則分流：
- 個人跨裝置續作：可選 Project Cloud。
- 小型團隊異步分工：可用獨立專案副本，再按規則回收。
- 多人即時編碼：優先評估 ATLAS.ti Web。
- 桌面分析、正式合併與一致性檢驗：使用唯一主專案及桌面版分發、合併流程。
- 實驗室沒有 Mac，但必須驗證 Mac 桌面版：使用脫敏樣例，在遠端 Mac 完成驗收，不要直接遷移正式訪談資料。
官方 Project Cloud 說明已指出，它不供兩台裝置同時編輯同一專案。這是路線判斷的硬限制，不應以「成員彼此錯開幾分鐘」代替正式協作規則。Project Cloud 官方限制與操作說明可作為課題組制定流程時的依據。
[ SECTION_02 ] 個人跨裝置續作：Project Cloud 可以用，但要守住版本基線
這是最適合 Project Cloud 的場景。例如研究者在 Windows 工作站完成初步編碼，之後需要在 Mac 上檢視備忘錄、整理報告或使用桌面版分析功能。
驗收時應逐項確認：
- 開始工作前，先檢查雲端是否存在較新的專案版本。
- 完成目前裝置上的工作後，確認修改已上傳。
- 上傳完成前，不要在另一台裝置開啟並繼續編碼。
- 看到兩台裝置都有未上傳修改時，立即停止編碼。
- 回到最近一次明確可識別的版本，再決定保留哪一份修改。
這裡的「通過」不是兩台裝置都能開啟專案，而是研究者能清楚回答三件事：哪個版本是主版本、上一輪修改是否已上傳、下一位使用者何時可以接手。若回答不了，流程就不應放行。
ATLAS.ti 26 Mac 官方系統要求與授權啟用文件，應在校內部署前一併核對。尤其要確認 Mac 端能正常啟動桌面版、帳號可啟用授權，以及研究團隊使用的專案格式能被目標版本開啟。官方系統要求與授權啟用說明可作為技術支援人員的驗收起點。
[ SECTION_03 ] 小型團隊異步分工：副本可以分發，結果不會自動合併
多人編碼時，Project Cloud 更接近「分發與回收」工具，而不是共同編輯器。每位成員收到的是可獨立工作的專案副本。若沒有清楚命名、回收期限與主專案歸屬，不同副本很容易被誤認為已經自動同步。
課題組可用一輪脫敏材料作為最小驗收樣本：
- 由負責人建立唯一主專案，保留只讀原始副本。
- 以成員姓名、日期與任務標記副本名稱。
- 將同一批脫敏文件分配給不同編碼員。
- 設定工作時段與回收方式，避免同一副本被重複取用。
- 回收後先保留每個原始副本，再進行合併或比較。
- 用一份輸出成果確認文件、代碼、備忘錄與編碼者身份仍可追溯。
官方團隊工作文件強調，團隊協作需要清楚的使用者身份與工作分工。若所有人共用一個帳號，後續即使合併成功，也難以判斷某段編碼由誰建立或修改。ATLAS.ti 使用者帳號說明應與課題組的成員名冊、權限表一同保存。
停止條件： 成員副本沒有命名規則、主專案歸屬不明，或回收後無法區分編碼者身份時，不要直接合併正式研究專案。先用脫敏樣本重做一輪。
[ SECTION_04 ] ATLAS.ti Web 與桌面版：即時協作和分析能力要分開驗收
需要多人在同一時間查看、討論與編碼時，ATLAS.ti Web 是較符合即時協作方向的路線。但不能因此假設 Web 專案和桌面版 Project Cloud 專案可以無縫互見。
截至本文核實日期，官方已說明桌面版 Project Cloud 專案與 ATLAS.ti Web 專案目前相互不可見。換言之，ATLAS.ti Web 專案能否直接在桌面版繼續編輯，不能用「登入同一帳號」推論，必須按官方轉移流程測試匯入、匯出與格式變化。官方專案轉移文件應列入驗收紀錄。
若研究流程依賴桌面版的特定分析能力，建議採用階段性交付：
- Web 階段負責需要即時協作的整理與編碼。
- 在明確節點匯出專案或成果。
- 由指定人員在桌面版建立後續分析基線。
- 匯出前後比較文件、代碼、備忘錄與關聯是否完整。
- 不在同一研究階段混用 Web 即時編輯與桌面版 Project Cloud 同步。
這樣做的代價是流程較慢，但能避免團隊以為 Web 與桌面版共享同一個即時專案，最後才發現兩邊的修改沒有出現在對方環境。
[ SECTION_05 ] 編碼者一致性與正式合併：先固定主專案，再處理衝突
多人編碼後需要計算一致性時，不能讓每位成員從空白專案自行建立文件與代碼體系。正確做法是由共同主專案產生獨立編碼副本，讓成員在相同文件、相同代碼與相同研究範圍內工作。
正式合併前，至少要檢查：
- 每位編碼者是否使用可識別的個人帳號。
- 所有副本是否由同一個主專案建立。
- 文件與代碼的實體識別是否保留。
- 合併報告是否顯示衝突、重複或未匹配項目。
- 是否意外重複匯入同一份文件。
- 一致性分析需要的編碼、文件與身份資訊是否完整。
ATLAS.ti 編碼者一致性說明與專案合併文件可用來建立試合併流程。Mac 使用者還應參考Mac 版合併與一致性分析說明，確認桌面端實際可見的選項與報告內容。
「通過」的標準不是合併按鈕能夠完成，而是合併後文件沒有不應出現的重複、編碼者身份可追溯、衝突能被解釋，而且一致性分析所需材料仍然存在。只要出現無法解釋的重複文件或身份遺失，就應退回試驗專案。
[ SECTION_06 ] 敏感訪談與多媒體資料：先判斷能不能上雲，再談方便性
訪談逐字稿、錄音與影片可能涉及受訪者身份、研究倫理審批、校內資料分級與跨境傳輸要求。文章不替學校或研究者作法律結論。課題組應先向倫理審查單位、資料保護人員或校方資訊部門確認，Project Cloud 是否獲准存放該類資料。
驗收可分成兩層：
- 專案內部文件：確認脫敏後的文件是否能在目標裝置開啟、編碼與匯出。
- 外部連結媒體：確認換裝置、換帳號或換工作環境後，音訊與影片連結仍然可訪問。
若雲端儲存未獲批准，或外部多媒體連結無法穩定恢復，應保留本地桌面專案、只讀原始副本與受控傳輸路線。不要把「可以同步專案」當成「所有關聯媒體都能安全同步」。
[ SECTION_07 ] 實驗室沒有 Mac：用遠端 Mac 驗收桌面流程，不直接搬正式資料
實驗室以 Windows 或 Linux 為主時，遠端 Mac 的用途是驗證桌面版流程，不是替研究團隊繞過資料治理。NOVAKVM 提供按週、月或季使用的遠端 Mac 環境，研究者可透過遠端桌面、SSH 或網頁控制台進行測試；實際部署前仍應先確認校方資料政策與帳號授權。
建議以不含真實受訪者資訊的脫敏樣例執行：
- 建立測試主專案，保留只讀原始檔。
- 在遠端 Mac 安裝或啟動 ATLAS.ti 26，檢查授權狀態。
- 測試專案下載、開啟、文件檢視與桌面分析。
- 將測試編碼或備忘錄帶回現有 Windows 或 Linux 流程。
- 測試匯出成果是否能被課題組現有工具接收。
- 結束後登出帳號、刪除測試資料與暫存檔，再確認遠端環境沒有留下正式資料。
目前沒有本站實測資料可支持特定遠端節點、交付耗時或桌面互動速度，因此不把這些項目寫成普遍性能結論。若需要先確認可用環境，可從 NOVAKVM 的遠端 Mac 方案了解服務形態，再用脫敏專案完成一次端到端驗收。
[ SECTION_08 ] 放行前勾選清單
- [ ] 已確認 Project Cloud 只用於個人跨裝置續作或非同步分發。
- [ ] 已建立唯一主專案，並保存只讀原始副本。
- [ ] 已訂定成員命名、工作時段、回收方式與版本基線。
- [ ] 已驗證開始工作前取得最新版，結束後完成上傳。
- [ ] 發現兩台裝置都有未上傳修改時，已有停止與回退流程。
- [ ] 已用脫敏材料完成成員副本、回收與試合併。
- [ ] 已確認每位編碼者使用可識別的帳號。
- [ ] 已檢查合併後的文件重複、實體識別與衝突報告。
- [ ] 已分清 ATLAS.ti Web 與桌面版 Project Cloud 的專案邊界。
- [ ] 已按學校要求核對敏感資料、跨境儲存與外部媒體連結。
- [ ] 已在遠端 Mac 上完成授權、下載、分析、匯出與退出清理驗收。
[ SECTION_09 ] 四條路線的放行條件
| 路線 | 適合場景 | 主要限制 | 通過標準 |
|---|---|---|---|
| Project Cloud | 個人 Mac、Windows 跨裝置續作；非同步分發 | 不支援兩台裝置同時編輯同一專案；目前標為 Beta | 每次接手前取得最新版，上一台裝置已完成上傳 |
| ATLAS.ti Web | 需要即時協作與共同編碼 | 與桌面版 Project Cloud 專案目前相互不可見 | 已測試 Web 階段、匯出與後續桌面流程 |
| 桌面版專案合併 | 多人獨立編碼、編碼者一致性檢驗 | 需要唯一主專案、身份管理與衝突檢查 | 試合併後無不明重複，編碼者身份與分析材料完整 |
| 遠端 Mac 桌面版 | 實驗室沒有 Mac，需要驗證 Mac 流程 | 需自行核對資料政策、授權與遠端清理 | 脫敏專案可完成下載、分析、匯出與清理 |
如果目前方案是讓成員共用 Windows 或 Linux 工作站、用檔案夾互相覆蓋專案，常見問題是版本不透明、檔案鎖定規則不一致，以及缺少 Mac 桌面版驗證環境；若改用只靠 ATLAS.ti Web 的混合流程，又可能碰到桌面專案不可直接互見和分析能力分段的限制。對需要短期驗收、跨平台交接或臨時使用 Mac 的課題組而言，租用 NOVAKVM 的遠端 Mac，先用脫敏副本完成一次下載、編碼、合併與匯出，通常比立即購置實機更容易控制試驗範圍；若課題組是長期高負載分析、必須接實體硬體，或校方禁止研究資料離開受控環境，則應保留本地 Mac 或校內部署方案。
需要評估週期方案與可用地區時，可再查看 NOVAKVM 的 Mac 遠端租用選項。最終判斷不應只看能否開啟 ATLAS.ti，而要看課題組能否在自己的資料政策下，穩定完成版本交接、身份追蹤、專案合併與成果帶回。