Copilot 將能讀取本機脈絡：整理工作檔案前，該怎麼設定任務範圍？
Copilot 將朝本機脈絡與動作發展。本文以工作檔案整理為例，說明資料範圍、版本依據、只讀試作與結果檢查，並標明尚未推出的能力。
電腦裡累積了企劃、會議紀錄與不同版本的簡報，最麻煩的往往是找出哪一份才是最新。
Microsoft 十月七日介紹 Copilot 在 Windows 的本機脈絡、本機動作與模型方向，預計在未來幾個月逐步推出。
這讓檔案整理多了一種可能，也提出一個實際問題：你應該讓代理讀哪些檔案、改哪些位置，又在什麼地方停下來等人決定？
目前不能把公告中的所有能力當成每臺電腦都已可用。本文整理的是可立即準備的任務規格與試用流程，沒有宣稱已操作尚未開放的功能。等帳號與裝置確實支援後，可以用同一份規格驗證結果。
本機脈絡讓任務更貼近工作，也需要明確來源
官方描述的方向，是在使用者允許下理解相關檔案與活動，協助完成電腦上的工作。本機脈絡需要指定資料來源與適用範圍，舊檔案也應依最新確認資料核對。你仍需要指定資料範圍，並讓結果能追溯到來源。
以產品發表企劃為例，最近修改的簡報可能只是視覺版本，真正的上線日期在另一份確認紀錄中。若只讓代理猜哪個檔案最新，結果就可能錯誤。
更好的需求是：「以指定的確認紀錄作為日期依據，其他檔案只用來補充背景。」
這也能避免把私人或無關資料混入工作。專案整理不需要整個檔案目錄，先限定一個工作資料夾即可。當來源不足時，讓代理指出缺什麼，比自動擴大搜尋到所有檔案更容易控制。
先分開整理、修改與對外操作
整理是讀取與分類，修改則會改變檔案，對外操作可能包括寄送、分享或發布。三者應有不同完成條件。你可以先讓代理整理清單與建議，再檢查後批准具體修改。不要用一句「全部處理好」同時包含所有行為。
例如要整理企劃版本，第一輪只列出檔案名稱、日期、內容差異與疑似最新版。第二輪才把檔案複製到新的整理目錄。原始檔保留，避免錯誤判斷直接造成資料損失。最後是否分享給同事，也應另外指定物件與內容。
一份好的任務規格會寫清楚輸出形式。是一個檔案表、一個新的資料夾，還是一份摘要？如果你只想知道差異，根本不需要讓代理改檔名。把可寫入操作留到有明確用途時，能減少不必要的變更。
用測試資料建立第一份工作資料夾
等功能可用後，第一次試用可以準備幾份自己寫的測試檔案。包括一份舊企劃、一份修訂版、一份日期確認紀錄與一份無關檔案。它們應有明顯差異，方便你判斷代理是否採用正確來源。
不要一開始就把正式客戶資料或個人資料交給新流程。測試的目的是瞭解工具如何讀取、引用與修改，一組無害檔案已足夠。若測試結果不穩定，先改善規格與設定，再決定是否擴大。
在資料夾旁邊保留一份正確答案。比如最新版的費用、確認的日期，以及哪些檔案不能當作決策依據。這會讓你知道結果是正確，還是隻是措辭流暢。沒有答案的試用，很容易被漂亮摘要說服。
第一輪提示詞只要求來源清單
可以先寫：「只讀取這個測試資料夾，列出四份檔案的用途與相互關係。以日期確認紀錄為時間依據。先不要改名、搬移或刪除檔案，也不要分享。每一項結論附來源檔名與對應段落。」
這輪的成果應是一份可檢視的清單。如果工具找不到來源，就說明限制。若它使用資料夾外的檔案，應先查清楚是設定範圍不夠明確，還是產品的來源選取方式需要調整。不要直接把錯誤結果帶入下一步。
檔案名稱也可能誤導。最新日期的檔案，不一定包含已確認內容。「final」可能只是某次輸出的名字。要求代理同時比較內容與指定依據，可以減少只按檔名判斷的情況。最終決策仍由你確認。
第二輪再整理差異與需要人決定的地方
確認來源後，請代理列出有衝突的資訊。例如兩份檔案日期不同，或費用欄位缺少稅費。它應呈現差異，不能自行挑一個看起來合理的版本。你可以把已拍板事項標成確定，其他專案列為待決策。
摘要也應保留語氣與狀態。原文寫「可能延期」，不能變成「已延期」。寫「提出方案」，不能變成「已決定」。這些差異對工作檔案很重要。要求摘要保留原本的確定程度，會比單純要求短而有力更適合內部使用。
如果來源中有舊資訊，可以要求它指出被哪一份新紀錄取代。這樣同事看摘要時，就知道為何採用某個版本。資料脈絡的價值，是減少查詢與比較工作，不是把來源全部藏進一段結論。
第三輪才做可回復的檔案整理
確認清單後，可以指示：「建立新的整理目錄，把確認過的檔案複製進去。保留原始檔，使用一致的檔名格式，另存一份對照表。遇到同名檔案先停止，不自行覆蓋。」
實際產品能否執行這些動作，仍需依開放功能確認。
命名規則應直接寫出，例如專案名稱、用途、日期與版本。不要只說「整理成好看一點」，否則模型可能替換你們已使用的制度。若團隊已有規範，就讓它沿用，避免某位同事看不懂新名稱。
完成後逐一核對檔案是否存在、是否為正確版本，以及原始資料是否保留。不要只看代理回報的數量。可以開啟幾份關鍵檔案，確認內容與格式都正常。這是一條小型驗收路徑，不需要把整臺電腦重新檢查一遍。
本機模型不等於所有資料都不離開電腦
官方的混合 AI 方向可能包含本機與雲端搭配。實際資料流應依產品版本、功能與組織設定確認。你需要區分模型在哪裡執行、檔案如何被引用，以及工具是否連線外部服務。
單純選擇本機處理，不能自動證明整個任務完全離線。
對有資料限制的團隊，應先詢問管理者當下允許哪些來源與功能。這不是讓使用者猜測，而是讓任務規格符合真實設定。若某類資料不能進入該流程，就先使用其他工作方式，無須為了追求自動化放寬限制。
也應看結果儲存在哪裡。新檔案、聊天歷史與執行紀錄可能各有不同儲存方式。先確認誰能讀取與如何刪除，再開始正式使用。資料留在本機與只有特定人可讀，是不同問題。
失敗時怎麼回復，比成功展示更重要
常見情況包括檔案沒有許可權、內容讀取不完整、檔案格式不支援，以及執行中途停止。你可以在無害資料中模擬幾個情境，觀察工具是否把限制說清楚。未完成的工作應有明確狀態，不應和已完成專案混在一起。
如果整理中途失敗，原始檔保留與對照表就會派上用場。你可以檢視哪些操作已執行，再決定從哪一步重新開始。不要讓代理反覆從頭搬移所有檔案，否則可能產生重複副本或新的命名衝突。
對外分享更需要明確停止點。摘要與檔案整理完成，並不表示可以自動寄給客戶。先讓人檢查收件者、附件與內容，再完成實際傳送。把這個流程寫進任務規格，會比每次到最後才臨時提醒可靠。
團隊可以保留三份簡短檔案
第一份是來源規則：哪些檔案是確認依據，哪些只是背景。第二份是操作規則：哪些位置可讀、可寫與不可修改。第三份是結果紀錄：執行時間、產物與未完成項。它們不需要很長，但應讓另一位同事看懂。
當新增一個工作時，只需補上它的來源與完成條件。當工具版本更新時，重測受影響的讀取或修改功能。無關的資料夾不必重複檢查，也不需要每次寫一份龐大報告。規則應服務工作，而不是增加額外負擔。
這三份紀錄還能幫助你衡量效益。手動查詢原本花多久、代理整理後還需要哪些修正，以及是否減少版本錯誤。若只是省下複製貼上，卻增加了更長的查核，應調整任務範圍，而不是隻因產品新就堅持使用。
範例：把每週專案更新整理成會議資料
可以指定一份確認過的進度表、三份工作紀錄與一份會議模板。先讓代理找出本週已完成、未完成與需要決策的項，不改原始資料。每個條目附來源，讓參與者可以回頭檢視。
接著才請它依模板整理成會議草稿。需求應限制頁數或段落，並保留關鍵日期與負責角色。若某項資料缺少，就直接列出缺口，不能為了排版完整補造進度。生成後，人只需核對重要結論，而非重新追查所有來源。
最後把草稿存到指定資料夾，等待會議負責人確認。這個例子中的整理與輸出即使能被工具完成，對外分享與正式決策仍需另外授權。新功能若能穩定走完這條流程，就已提供具體價值。
用一次交接檢查任務規格是否完整
整理完成後，可以請另一位同事只看來源清單、輸出與對照表，試著回答「哪份是最新版」「哪些事項已確認」。如果仍需要原操作者口頭解釋，就先補充資料關係，不急著擴大自動化。
結果應能被別人使用，才算減少了查找工作。
這項檢查也能發現命名問題。有些檔案看似整齊，名稱卻沒有用途。有些摘要很短，卻刪掉了重要條件。請同事指出最先卡住的位置，再只修改相關規則。比起重新整理所有文件，這種修正更容易確認效果。
若團隊本來就有固定模板，先把它當成輸出標準。新功能應沿用大家熟悉的欄位與狀態，不必重新創造一套文件制度。當來源、格式與操作範圍都清楚，日後換工具也能保留同樣的工作方法。
最後保存一組測試資料與結果，作為功能開放後的比較基準。新版本若加入更多能力，可以只增加對應檢查。把準備工作留下來，才不會每次更新都從頭猜測工具怎麼用。
常見問題：沒有 Copilot+ PC 可以先做什麼？
你仍然可以整理來源、命名規則與完成條件。這些準備不依賴尚未推出的本機能力，也能用在現有工具或人工流程。等裝置與帳號支援後，再以同一組測試資料比較，會更容易判斷新功能到底改善了哪一部分。
對這項公告，合理的期待是更貼近工作資料的協助。真正可用的成果，應讓你知道來源、掌握修改範圍，並能在失敗時回復。先把一個小工作定義清楚，才有基礎逐步交給代理處理更多事情。
