為甚麼 ChatGPT 有用，但對專業工作仍然未夠

ChatGPT 有用。

這應該是起點，而不是要反駁的說法。人們使用 ChatGPT 或其他聊天式 AI，因為它們幫到草擬、摘要、brainstorm、重寫、解釋和探索。對個人工作來說，這可以是真實改善。

但專業工作很少只是一個人的 prompt。

它依賴即時工作狀態、來源證據、權限、ownership、審閱、時間和問責。這正是單靠 chat 經常不夠的地方。對香港團隊而言，還要加上一層實務考慮：不能假設每個人都可直接使用同一個海外聊天工具；很多機構會以地區可用性、客戶保密、內部 IT 政策和已批准工具清單作為前提。

Chat 幫到哪裏

當人可以把背景帶入對話，並能判斷輸出時，聊天式 AI 很強。

它可以幫助：

• 草擬第一版；
• 摘要文件；
• 把筆記變成結構；
• 探索選項；
• 改寫得更清楚；
• 準備問題；
• 解釋陌生材料；
• 建立 checklist。

這些都是有用任務。很多專業人士都應該使用聊天工具，或使用機構批准的同類工具來處理這類工作。

限制在於，使用者每次都要在 prompt 裏重建機構。

Prompt 變成營運層

如果系統不知道工作，使用者就要提供。

使用者要解釋：

• 涉及哪個客戶、matter、供應商、項目或承諾；
• 哪些來源是當前版本；
• 哪個來源具權威；
• 上星期發生過甚麼；
• 下一步由誰負責；
• 批准邊界在哪裏；
• 甚麼語氣或風險取向重要；
• 系統被允許做甚麼。

小任務可以這樣做。當工作重複、來源繁重，或者由整個團隊共享時，這方法會崩潰。

Prompt 變成一個臨時營運層。使用者人手重建背景，取得答案，然後當工作回到電郵、文件、任務、會議或紀錄時，大部分背景又散失。

這亦令團隊協作變難。同一位使用者可能知道自己在 prompt 裏提供過甚麼，但其他同事未必知道答案基於哪些材料、哪些假設或哪個版本。當輸出要進入正式流程，這種不可見背景會成為審閱和交接的弱點。

專業工作需要狀態

專業工作流需要系統理解當前工作狀態。

Matter review 不只是文件摘要。Renewal review 不只是合約摘要。Project handover 不只是重寫筆記。Client follow-up 不只是電郵草稿。

每個工作流都會問：

• 甚麼改變了？
• 欠缺甚麼？
• 哪些來源支持這一點？
• 下一步由誰負責？
• 甚麼需要批准？
• 甚麼暫時不應該發生？

這就是 operating intelligence。系統需要一個關於工作、證據、人、節奏和邊界的活模型。

專業工作需要 Source Grounding

流暢答案不夠。

如果系統說續約快到期、某條條款適用、客戶承諾過某件事，或項目決定已改變，審閱者需要看到來源。

來源可以是合約、發票、會議筆記、電郵、DMS record、project register、site photo、政策或過往決定。專業人士需要檢查說法的基礎。

這就是 helpful draft 和 reviewable workflow 之間的分別。Source grounding 令輸出向模型文字以外的證據負責。

專業工作需要權限和邊界

專業團隊也需要控制 AI 可以看到甚麼和做甚麼。

不是每個使用者都應該看到每個 matter、客戶、供應商、員工紀錄、財務細節或敏感筆記。不是每個工作流都應該可以寫回系統。不是每個行動都應該自動化。

受治理的工作流應該知道：

• read permissions；
• write permissions；
• approval requirements；
• action boundaries；
• escalation paths；
• audit records。

沒有這些控制，AI 仍然只是個人助理，而不是專業營運層。香港機構在這裏尤其要實際：可使用的聊天工具、資料可否輸入、跨境處理、客戶保密和內部批准流程，都會影響系統可以被放在哪一層工作。

Chat 和 Proximity 是不同層

這不是「chat 不好、platform 才好」的論點。

分別在於層次。

Chat 是靈活的思考和草擬介面。Proximity 圍繞專業工作流需要的營運背景設計：work objects、sources、review packets、approvals、owners 和 handoffs。

兩者可以共存。一個人可以用聊天工具探索想法。Proximity workflow 可以從已批准來源準備 review packet。重要問題不是哪個介面流行，而是系統是否有足夠 context 和 control 來支援這份工作。

實用測試

在依賴 chat 做專業工作流之前，先問：

• 系統是否不用我重建，也知道當前狀態？
• 它能否顯示每個重要說法背後的來源？
• 它是否尊重團隊權限？
• 它是否知道誰擁有決定？
• 它能否分辨草稿、建議、批准和行動？
• 它是否留下用了甚麼和產生了甚麼的紀錄？
• 另一位團隊成員能否由輸出接手繼續？

如果答案是否，chat 仍然可以幫忙。但它還不是該工作流的營運系統。

這不是要減低聊天式 AI 的價值，而是要把它放在合適位置。對個人思考、初稿和探索，它可以非常有效；對需要共同記憶、審批、權限和審計的工作，它通常需要連接一個更完整的營運層。香港團隊尤其應把「哪個工具可用」和「哪個流程可問責」分開處理：前者是供應和政策問題，後者是工作設計問題。

換句話說，chat 可以是入口，但不應被誤認為整個工作系統。當輸出要交給同事接手、放入客戶紀錄、觸發審批、影響預算或代表機構立場時，團隊需要比一段對話更多的東西：可追蹤來源、共享狀態、權限模型、版本歷史和清楚 handoff。這些不是聊天介面的弱點，而是專業工作本身的要求。

實務上，最好的安排通常是讓聊天式 AI 處理探索和草擬，讓營運平台處理受控工作流。個人可以在已批准工具內思考、改寫和準備問題；當工作進入正式流程，系統就要使用批准來源、保留紀錄、尊重權限，並把需要審閱的地方送到負責人面前。

這個分工能保留 chat 的速度，同時避免把整個機構背景反覆塞進 prompt。當工作從個人草稿走向團隊承諾，這個分界就特別重要：chat 可以幫忙，但共享狀態、來源、權限和審閱路徑，才令專業工作可問責。

因此，問題不是 chat versus platform，而是系統是否有足夠 operating context。若沒有當前狀態、來源、owner、approval boundary 和 audit record，聊天式 AI 仍然適合輔助個人工作，但不應被當成整個專業 workflow 的營運層。