Proximity 部署首 30 日會發生甚麼

Proximity 部署的首 30 日，應該感覺很務實。

不是做場面。不是一啟動就變成全公司的 AI transformation programme。正確的起點，是揀一個營運範圍：在那裏，如果準備工夫更好、來源更清楚、審閱更容易，實際工作就會有分別。

第一個月的目標，是圍繞真實工作建立一個可重複的審閱節奏。

這一點在香港的專業服務環境尤其重要。很多團隊不是沒有工具，而是工作散落在 email、WhatsApp 跟進、共享 drive、case file、會議紀錄和個人記憶之間。部署初期如果直接追求宏大的 automation，通常只會把這些不清楚的地方放大。較好的做法，是先讓一個重要但受控的工作區域變得可見、可檢查、可改進。

起始原則

由一個 workflow 開始。

這個 workflow 應該是重複發生、依賴大量來源、可以審閱、有痛點，而且邊界清楚的工作。每週 matter review、續約檢視、項目交接、客戶跟進檢視，或者 research packet，通常都比「全面自動化」更適合作為起點。

這類 workflow 有一個共同特點：它不是單次輸出，而是一個會反覆回來的營運節點。正因為它會重複，團隊才可以比較新舊流程，看到哪些資料準備得更好、哪些 review 更快、哪些 follow-up 不再遺漏。

第一個部署要回答：

• 我們正在建模的是甚麼工作對象？
• 哪些來源重要？
• 誰擁有決定權？
• 系統應該準備甚麼？
• 哪些事情必須留在人手批准之後？
• 我們怎樣知道這份 review packet 有用？

第 1 週：梳理營運範圍

第一週的重點，是理解工作本身。

如果是 matter review，工作對象可能是一宗 matter。如果是財務，可能是一項續約。如果是重視關係的團隊，可能是一個客戶承諾。如果是項目團隊，可能是一個 site question 或項目決定。

梳理工作應該識別：

• 重複出現的審閱節奏；
• 參與的人；
• 今天已經使用的來源；
• 現時準備工作的負擔；
• 審閱期間會作出的決定；
• 審閱之後產生的跟進；
• 需要批准才可執行的行動。

這個階段不是要求同事描述一個理想系統。它是觀察已經存在的 workflow，弄清楚工作實際怎樣流動。

很多部署會在這裏犯錯：一開始就問「你想 AI 做甚麼？」但用戶往往只能用現有痛點回答。更有用的是觀察：誰在會前整理材料、誰在會中解釋背景、誰在會後追 action、哪些資料每次都要重新找、哪些決定其實靠某個人記得。這些細節才是系統需要建模的 operating area。

第 2 週：審視來源與邊界

第二週聚焦在來源存取、權限和授權。

團隊應該決定：

• 哪些系統和資料夾在範圍內；
• 哪些來源類型具權威性；
• 哪些材料敏感或受限制；
• 哪些角色可以看見甚麼；
• 系統可以準備哪些行動；
• 系統絕對不應該採取哪些行動。

很多 AI pilot 都是在這裏才變得真實。模型可以總結任何它看見的東西，但專業工作需要邊界。系統需要知道哪些來源可以用、哪些已經過時、哪些只是草稿、哪些需要特別小心處理。

如果這一步做得不清楚，後面所有 output 都會有疑問。Reviewer 不知道摘要是否用了正確 file，不知道某份 draft 是否被當成 final，不知道某個 restricted folder 是否不應進入模型 context。Week 2 的價值，是在模型產生內容之前，先把「可讀」和「可做」分開。

第 3 週：準備第一份審閱包

第一份 review packet 即使未完美，也應該有用。

它應該展示：

• 目前狀態；
• 有變動的項目；
• 來源證據；
• 缺失資料；
• 未決事項；
• 負責人；
• 建議下一步；
• 批准邊界。

團隊應該在實際 workflow 裏審閱這份 packet，而不是把它當成獨立 demo。如果 workflow 是每週 review，就在每週 review 使用它。如果是 renewal review，就用真實續約來試。

問題不是「AI 是否令人驚艷？」問題是「這有沒有令 review 更好？」

好的 first packet 不一定長，也不一定像 sales demo。它應該讓 reviewer 更快看見狀態、證據、缺口和下一步。即使它有錯，只要錯誤清楚、可修正，團隊就能把它變成下一輪改進，而不是把 AI output 當成黑盒。

第 4 週：把回饋變成節奏

第四週是迭代。

審閱者應該標記：

• 缺少的來源；
• 錯誤假設；
• 有用的部分；
• 令人混淆的部分；
• 需要升級處理的決定；
• 應該變成 task 的跟進；
• 可以變成重複模式的 workflow 部分。

這些修正會成為系統下一個版本。workflow 之所以會改善，是因為團隊看得見系統準備了甚麼、人修改了甚麼，以及下一次應該怎樣做。

這也是部署開始變成營運習慣的地方。Feedback 不應只停留在「這段寫得好不好」。它應該回到 workflow：是否少了一個 source、是否多了一個 approval boundary、是否某個 section 永遠沒人用、是否某個 missing fact 每次都出現。這些信號會告訴團隊系統下一步應該加強哪裏。

30 日後，成功應該是甚麼樣子

成功不是全面自動化。

成功是一個有效的營運節奏：

• 一個 workflow 已經被清楚建模；
• 系統可以準備一份可審閱的 packet；
• 來源和邊界清楚可見；
• 審閱者知道要檢查甚麼；
• 跟進更清楚；
• 團隊可以比較新流程和舊流程；
• 下一步改善方向明顯。

這已經足夠讓團隊對是否擴展作出真正判斷。

不應該做甚麼

不要一開始就連接所有系統。

不要一開始就自動化對外行動。

不要一開始就要求模型取代專業判斷。

不要只用一個 polished demo 去評估 pilot。

首 30 日應該令工作更清楚，而不是更神秘。

之後怎樣擴展

當一個 review rhythm 行得通，擴展就會更有紀律。

團隊可以問：

• 這個 workflow 應否由草稿準備，進一步走向建議？
• 哪些部分穩定到可以進入已批准行動？
• 哪些來源需要更好的結構？
• 哪個相鄰 workflow 使用同一個 operating object？
• 哪個團隊會受惠於同一種 packet pattern？

pilot 就是這樣變成 infrastructure。