用Claude自動產生新人IT開通清單

簡而言之： Claude能在幾秒內把一份職務定義、一張權限清單和一組市場特定要求，變成一份完整的新人IT開通清單，並在任何一項改變時重新產生。它做不到的是建立帳號、核准權限、註冊裝置——那是身分系統、簽核流程，以及Intune或Apple Business Manager的事。把清單當成規格說明，而不是自動化本身。

任何招過二十人以上的公司，某處都躺著一份新人IT清單。它通常是兩年前離職的某個人寫的，上面列著一個郵箱帳號、一台筆電、一個去年春天就被換掉的VPN用戶端，以及靠近末尾的一行字：「加入相關群組」。沒人負責它，沒人替它做版本管理，而它被翻出來的第一次，往往是某個週一早上——新人已經站在櫃台了。

有意思的地方在於，清單本身並不是真正的問題。多數公司大致知道一個新人需要什麼。他們缺的是一種辦法：讓這份知識在十幾個職務、三個國家、以及一份每季都在變的應用清單之間保持最新，並且能在需要時，為特定的人產生正確的那一版。這是一個「產生」問題，而這恰好是語言模型擅長的事。

為什麼入職清單永遠是過期的

它們描述工具，而不是職務。 一份寫著「安裝CRM」的清單，是在只有一套CRM、所有人用法相同的年代寫的。一旦業務、支援和財務需要對同一個系統擁有不同權限，以工具為形狀的清單就不再回答真正要緊的那個問題：這個具體的人，應該被允許做什麼。

它們只被寫過一次，從不做版本管理。 單一登入上線、費用系統換代、端點防護代理被新的取代——每一件事都改變了「正確答案」，但沒有一件觸發過對這份文件的編輯。直到某個新人第三天還拿不到一個顯而易見的權限，才有人注意到。

它們預設只有一個市場。 圍繞新加坡辦公室搭起來的清單，到了上海會悄無聲息地失效：採購週期不同、網路可達性不同、適用的隱私法規也不同。團隊通常是在第一次替本土市場之外的人辦入職時，以最糟糕的方式發現這一點。

它們止步於交接。 多數清單在筆電交付時就結束了。它們對九十天後試用期結束、權限應當覆核這件事隻字不提，對反向流程更是完全空白。

沒有人擁有它們。 入職這件事夾在HR、IT和用人主管之間，實際上意味著它落在最沒辦法說「不」的那個人身上。文件會腐化，因為維護它不在任何人的考核目標裡。

建一個「認職務」的清單產生器

讓這件事成立的轉變很小但很實在：不要再維護清單，改為維護「清單是從什麼推導出來的」那些輸入。清單本身變成一次性的輸出，需要時重新產生即可。

餵給Claude真正要緊的那幾項輸入

一個有用的產生器需要六樣東西，而輸出的品質，幾乎完全取決於你把它們寫得有多誠實。

職務，用「它做什麼」來描述。 不是職稱，而是它接觸哪些系統、做哪些決定。「會處理客戶付款資料」這一句告訴模型的東西，是職稱永遠給不了的。

法律實體與市場。 誰僱用這個人、他坐在哪個辦公室、他的資料和裝置適用哪個國家的規則。就是這一個欄位，把一份通用清單變成了一組真正不同的清單。

裝置標準。 這個職務配什麼硬體、由誰供貨、當地採購要多久，以及它是公司自有裝置還是納管的個人裝置。最後這個區分，幾乎會改變後面每一步。

權限對照表。 哪些群組、授權和應用角色對應哪種職能。這份東西如果存在，通常存在某個人腦子裡或某張試算表裡——把它寫下來，是整件事裡價值最高的一個小時。

簽核規則。 什麼可以自動授予、什麼需要主管、什麼需要資料負責人。模型應該標出這些，而絕不應該替你裁定。

時間線。 第一天之前必須成立的事、第一天當天發生的事，以及第三十天和第九十天的節點。

實務上，把這些做成一小組參考文件，而不是每次對話都貼一遍。Claude的Projects功能正是為此設計的——一個該專案內所有對話都看得到的持久脈絡——這樣職務矩陣和權限對照表就只住在一個地方，也只需更新一次。具體功能請以Anthropic目前的文件為準，因為消費級產品、團隊版和API之間可用的能力並不相同。

一種人們真的會照著做的輸出格式

讓清單按「負責人」而不是按「系統」分組。HR做HR的部分，IT做IT的部分，用人主管做自己的部分，每一組都能原樣交給不同的人，不需要再編輯。每一組內部按截止時間排序，而不是按重要性——真正要執行的人需要知道的是「什麼卡住了第一天」，而不是「什麼在概念上最重要」。

每一行都要求四個欄位：負責人、系統、必須先完成的前置條件，以及一個可觀察的完成判準。「開通郵箱」不是一個清單項目。「新加坡租戶內已建立信箱、已指派授權、已收到測試郵件——IT負責，前置條件為HR檔案完成」才是，因為你看一眼就知道它有沒有發生。

當你希望輸出流向別處時，明確要求一種機器可讀的格式。Markdown能乾淨地貼進多數知識庫；CSV能匯入工單系統或專案工具。真正的紀律在於：在提示詞裡把格式固定下來並保持穩定，這樣輸出就能和上個月那一版做差異比對，變化一目了然。

最後，明確要求模型對不確定的地方做標註，而不是自行填補。它拿不準的項目，應該以一個「提給指定負責人的開放問題」的形式出現。一份悄悄編造出簽核環節的產生清單，比一份坦承「我不知道」的清單更糟。

一個真實範例：新加坡的業務 vs 上海的工程師

兩個人，同一家公司，同一個到職日，過了前三行就幾乎沒有任何共同點。

新加坡的業務需要一台公司配發的Windows筆電，當地有現貨，可以預先註冊後再寄出，讓它在首次登入時自行完成設定。身分這塊很直接：企業租戶內的一個帳號、授予標準生產力套件的群組成員身分，以及一個按其負責區域而非全域唯讀來限定的CRM角色。因為他會接觸客戶聯絡資料，清單上應當有一條真正帶完成紀錄的《個人資料保護法》訓練項目，而不是歡迎信裡的一句話。行動門號掛在當地實體下。第一天就能開通，是因為這條鏈路上沒有長週期環節。

上海工程師的清單幾乎立刻就分岔了。裝置採購是一個有自己週期的當地流程，所以觸發日期要往前挪好幾週。網路存取是一個設計問題而不是一個勾選方塊，因為境內辦公室對境外協作服務的可達性確實是變數，需要驗證而不是假設。適用的隱私法規是《個人信息保護法》，這改變了需要做哪些訓練、公司必須能拿出什麼證據。內部溝通可能跑在與公司其他部分不同的平台上，這意味著多一個帳號，也多一步離職清理。而這位工程師需要正式環境權限——那是兩份清單上都絕不該自動授予的那一項。

這個練習的重點不是「模型知道這些差異」——它之所以知道，只是因為你把它們寫進了實體與市場這兩項輸入裡。重點是：一旦這些輸入存在，替其中任何一個人產生正確的清單就幾乎不花成本，而且隨著底層事實變化，兩份清單都會跟著保持正確。

AI產生清單 vs 靜態範本 vs 自動化開通

初始投入 — 靜態範本在第一個人身上勝出，此後永遠落敗。產生方案的成本是花一個下午把權限對照表寫下來。自動化開通則是一個有預算的專案，以週計。
半年後的準確度 — 產生方案明顯勝出。範本在寫下來的那天是準的，之後無聲地腐化。產生器的陳舊程度只取決於它的輸入，而輸入小到真的會有人去更新。
應對非典型職務 — 產生方案完勝。一個權限受限的約聘、一個回聘的老員工、一個市場裡只有一名員工的國家經理——這些正是範本涵蓋不了、而規則型開通系統需要提變更申請才能處理的情況。
第一天的速度 — 自動化開通勝出，而且差距不小。清單告訴人要做什麼；零接觸註冊直接把它做了。隨著人數成長，這才是最要緊的那道差距。
可稽核性 — 自動化開通勝出，產生方案次之。開通系統產生日誌。產生的清單產生一份帶日期、可歸檔的產物。一個被九個人編輯過的wiki頁面，產生的是爭論。
出錯的代價 — 三者之中，產生方案錯了最安全，因為在行動之前有人會讀它。一條授權過度的自動化開通規則，是在無人察覺的情況下、成規模地出錯——這也正是下文那些簽核關卡比自動化本身更重要的原因。

誠實的結論是：這三者並不是競爭關係。產生的清單是規格說明，自動化開通是實作。那些跳過權限對照直接上自動化的公司，最後往往自動化了一組從來沒人真正同意過的權限決策。

AI做不了的那部分：簽核、裝置註冊，以及風險更大的那一半

簽核是一道控制措施，不是一個步驟。 如果某個清單項目授予的是客戶資料、財務系統或正式環境基礎設施的權限，就必須有一個具名的人來核准，並且這次核准要有紀錄。模型可以辨識出哪些項目需要簽核、應該由誰來簽。它絕不能成為做出這個決定的東西，而任何產生的清單都不應被直接接進一個會真正授予權限的系統。

真正的自動化在裝置註冊這一層。 Windows Autopilot把裝置登錄到你的租戶，讓首次登入的使用者自動拿到設定、原則和應用程式，IT完全不必碰這台機器。Apple Business Manager的自動裝置註冊為Mac、iPhone和iPad提供等價能力，Android Enterprise則為Android硬體提供零接觸路徑。三者都要求裝置在開箱前就已登錄——通常由經銷商完成，或透過其硬體識別碼——這正是為什麼採購這件事應該在到職日前好幾週就出現在清單上。各平台的具體要求不同且會隨時間變化，在據此做設計之前，請以原廠當前文件為準。

真相來源是身分系統，不是那份文件。 一條寫著「加入業務群組」的清單，描述的是你的目錄服務本來就知道的狀態。你越能把權限決策下沉到「按職務授予的群組」裡，清單需要承載的就越少，權限也就越可能是真的正確，而不只是被記錄過。

離職是風險更大的那一半，得到的關注卻少得多。 漏掉一個入職項目，製造的是第一天的不便。漏掉一個離職項目，製造的是一個屬於已經不在職的人的活帳號，而它可以存活好幾年。用完全相同的輸入、在同一時間產生離職清單，並和入職清單放在一起——模型可以從同一份職務描述裡同時產出兩份，這就消除了「沒有離職清單」最常見的那個藉口。

把這件事做對：身分、裝置註冊，以及何時該讓IT介入

這底下還壓著一個容易被忽略的資料問題，因為這些內容感覺上只是行政事務。一段抽象描述職務的提示詞是無害的。一段包含具名個人、到職日期、薪資級距或私人聯絡方式的提示詞，則是一次涉及個人資料的處理活動，要落到適用的法規之下——香港《個人資料（私隱）條例》、新加坡PDPA，或中國《個人信息保護法》。實務規則很簡單：從職務產生清單，而不是從人。如果確實需要一份帶姓名的版本，就在本地把姓名替換進已經產生好的範本裡，根本不必把這個人的資料送給模型。如果你用的是API而不是消費級產品，請覆核適用於你帳號的資料處理條款，兩者並不相同。

另一半是清單所指向的那些東西。零接觸註冊、以群組為基礎的權限授予、以及一條裝置合規基線，才是把一份產生清單變成真實工作流程的東西，而把它們設定對，是一個組態專案，不是一段提示詞。Brocent的行動裝置與BYOD管理服務涵蓋的正是這一層——註冊設定檔、合規原則，以及「公司裝置」和「納管的個人裝置」之間的區別。我們的AI+支援服務幫你設計提示詞、參考文件和覆核環節，讓輸出不只是快，而是可信；託管IT支援則在流程定義好之後，負責跑通入職—異動—離職這整條鏈路。如果底層流程還沒被寫下來，我們那篇用ChatGPT和Notion自動產生SOP的指南是正確的第一步，因為從一個沒有文件的流程產生清單，產出的只是一個聽起來很篤定的猜測。Brocent自2007年在北京創立以來一直在亞洲提供託管IT服務，總部位於新加坡，並自2016年起設有香港辦公室。

常見問題

它會真的去建立帳號嗎？

不會，也不該。模型產出的是一份規格說明——什麼應該存在、每一項歸誰、「完成」長什麼樣。建立帳號、指派授權、授予群組成員身分，發生在你的身分系統裡，理想情況下由以職務為基礎的群組驅動，而不是靠手工。把語言模型直接接到帳號開通API上，技術上做得到，也恰恰因為它誘人而是個壞主意：它移除了那個本來會發現錯誤的人。

怎麼讓每個職務的權限保持正確？

靠維護權限對照表，這是唯一值得真正投入精力的產物。寫下每種職能對應哪些群組、授權和應用角色，在系統新增或替換時覆核它，並把它當作清單據以產生的輸入。如果你的目錄服務已經透過以職務為基礎的群組授權，這份對照表基本上就是對現有群組行為的描述——順帶也是一個很好的機會，去發現其中某些群組的權限比任何人預期的都大。

離職呢——那不是風險更大的一半嗎？

是的，而且通常是被忽略的那一半。在產生入職清單的同時，用同一份職務描述產生離職清單，並把兩者放在一起。它應當涵蓋帳號停用（而非刪除）、工作階段與權杖撤銷、裝置回收與抹除、信箱委派，以及任何只存在於某一個辦公室的市場特定系統。要防的失效模式並不是「忘了停用主帳號」——而是那個沒人記得還連著的第三方工具。

它能處理不同市場的裝置與合規要求嗎？

只能處理到你告訴它的程度。模型對主要法規有通用認知，但它不知道你的法律實體、你當地的採購現實，也不知道你的哪些系統從哪個辦公室能存取。把這些寫進「市場」這項輸入並保持更新，同時要求輸出標註每一條是由哪條市場規則推導出來的，這樣錯誤的假設是可見的，而不是被埋起來的。

一定要用Intune，還是任何MDM都行？

任何能為你的裝置組合提供零接觸註冊的現代MDM都可以。如果你本來就在用Microsoft 365，Intune是自然的選擇，因為身分、裝置和應用三層在同一個平台上。要緊的不是產品，而是能力：裝置在寄出之前就已登錄、設定在首次登入時自動下發，以及一條存取原則真的可以依賴的合規基線。

職務矩陣應該放在哪裡？

放在一個有版本、可讀、且有具名負責人的地方。程式碼儲存庫、一個有真實歷史紀錄的wiki頁面、或一個啟用版本控制的文件庫，都可以。行不通的是共用磁碟上一張沒有歸屬的試算表，因為這套方法的全部價值都建立在「輸入是最新的」之上——而一個沒人維護的輸入，會比它取代掉的那份範本更快地變錯。

從哪裡開始

挑一個你招得最頻繁的職務，把它的六項輸入寫下來——職務、實體、裝置、權限、簽核、時間線。這就是全部投入。產生清單，然後逐行對照你上一次替這個職務辦入職時「實際發生了什麼」，並留意兩個方向上的缺口：模型漏掉了什麼，以及你的真實流程做了哪些從來沒人寫下來的事。第二份清單通常更有意思。輸入理順之後，先別做別的，用同一份描述產生離職清單——那是你日後會慶幸自己有的一份。如果你更希望把清單、裝置註冊和權限模型一起設計好，歡迎與我們聯絡。