加、減、乘、除：教 Copilot 的速查表

財務及採購部門工作坊前一晚，凌晨一點，我把剛做完的簡報扔了。團隊花了整個晚上砌出一套 Demo 1 到 Demo 4 的發票加採購單流程。內容紮實，技術上完全正確。但我睡不着，因為我清楚明天的對象是甚麼人。

財務人不需要另一個 Copilot 功能示範。他們早就看過了。他們真正需要的，是一份「用得安心」的許可——不用每次都像在亂猜提示詞那樣心虛。Demo 1 到 Demo 4 那條路徑給了他們工作流程，但沒給他們一套思考方法。

於是我用四則運算重寫了整份教材。加、減、乘、除。到早上六點，簡報換了樣，數據集重新生成，提示詞全部重剪。十點開場，工作坊照跑。我至今還不確定下次會不會用同一套方法，但框架撐過了那次恐慌，通常這代表它有點承重能力。

為甚麼是算術

大部分非技術背景的人用 Copilot 失敗，原因來來去去得兩個。他們不知道該給它甚麼（加），也不知道該拿走甚麼（減）。那些更花巧的東西——Agent、Custom Instructions——要等到基本的「給與收」乾淨之後才談得上意義。

算術之所以有效，是因為它可攜。你可以在腦裡抓住四個運算子，哪怕你已經跟了項目三個星期、剛開完會、有點累。那些五個 C 七個支柱的框架，房間一散就死。加減乘除不會。

加：上載按鈕做的事，比你想像中多

第一個動作極其簡單：給 Copilot 它手上沒有的背景資料。上載按鈕。貼上。截圖。

工作坊裡三道實操任務，對應三種不同形狀的數據。一份港鐵通勤記錄（180 行，日常生活數據，低風險，純粹用來打破「這些資料也可以給它看嗎」的緊張感）。一份按部門劃分的損益表（36 行，正是財務團隊月尾真正會打開來看的那種東西）。一份多倉庫庫存檔案（110 行，有快到期的月餅、庫存告急的酸種包、滯留太久的堅果餅乾）。

同一個運算子，三種來源數據。要教的道理是結構性的：加，不是關於寫出更漂亮的提示詞，而是關於決定 Copilot 需要先看到甚麼，你才好開口問。當房間裡的人發現，一句三行提示詞搭上正確的檔案，可以打贏一份三十行但沒有附檔案的提示詞，他們就不會再花力氣去優化錯的那一端。

減：大部分 Copilot 令人失望的時刻，來自太多，而非太少

另一面更難教，因為它表面上像甚麼都沒做。你要把背景資料拿走。

工作坊裡兩道配對練習，同一條提示詞，同一組數據的兩個版本。完整銷售檔案：5,200 行、44 欄、三年交易記錄。乾淨版本：240 行、6 欄、只有上一季。同一條問題。完整版本回來的答案含糊不清，甚至出錯。乾淨版本直接浮出酸種包是毛利率 58% 的冠軍，而且港島區銷量是九龍的兩倍。

然後是一份預測檔案，數據集裡藏了 580 行已刪除但仍然存在的列（來自混亂的匯出流程的真實狀況）。完整版本出現幻覺。乾淨版本給出酸種包按年增長 12%，以及堅果餅乾第二季下滑。重點不言自明：Copilot 有 context window，你餵太多反而會餓死它。

這一步是多數內部培訓直接跳過的。他們教提示詞，不教修剪。失望率因此居高不下。## 倍乘：一個 agent 不過是一串已儲存的動作鏈

講到倍乘，多數人會僵住，因為「agent」這個詞已經被濫用到失去意義。我的定義很操作型：一個 agent 就是你事先決定好的一套 Plus 和 Minus，加上固定的輸出格式，儲存起來，以後就不用重新交代。

我在現場直接搭建一個「讀收據 agent」給大家看。五張香港虛構收據：一間茶餐廳、一次超市購物、一張被弄污的的士收據、一張順豐快遞單、一疊辦公室用品單據。Agent 的任務：讀取每一張收據，輸出一個 JSON 物件，當中的欄位要符合香港會計師真正需要的東西——日期、商戶名稱、總金額、消費稅、分類、付款方式、建議的 ledger code。每次都同一套 prompt，每次都是同一個輸出格式。

課室裡的人看見，agent 不是機械人，而是刻意選擇不再重複自己。第二個 agent——一個原材料研究 agent，會從過去三十天內抓取餐飲食材價格，必須有三個資料來源——把同一套原理延伸到網上搜尋。倍乘這個操作，能把一個好的 prompt 變成一百次的使用。

除法：custom instructions 是最划算的槓桿

除法是最低調的一步，卻帶來最高回報。你刻劃出一套預設行為，以後就不用次次說明。工作坊裡有五個範本：財務簡報濃縮器、採購談判準備、審計軌跡紀律、風險訊號偏好、報告長度上限。

我即場安裝其中一個給大家看——就是報告長度上限。以後的 prompt 回覆都會自動符合要求的篇幅，沒有人要開口問。整個房間的人看見，一直以來重複交代偏好所花的時間成本，就靠一次貼上徹底消失。

如果一個財務團隊安裝三條 custom instructions，之後什麼都不碰，他們已經拿到大部分的價值。幾乎沒有人教這個，因為它看起來太簡單，難以收費。

下次我會砍掉的東西

坦白說，有兩樣。

開場那個「Excel 耗費 210 億小時」的數據很有衝擊力，但我懷疑對一個本來就活在 Excel 裏的財務團隊來說，這不是最適合的切入點——他們不用人告訴他們問題有多大，他們要看見的是這一步的槓桿有多大。數字本身是厲害的，因為它令人驚訝，但驚訝不等於切身。下次我會改用 Garden 團隊自家的版本（我們估算過他們團隊每天耗用約 1,125 小時），丟掉那個全球統計數字。

中間那段 Magic Moment——在 Minus 和 Multiply 之間安排了一段 Copilot 即場畫圖表的環節——是我為了防止氣氛冷掉而買的保險。它的確有用。但如果現場氣氛本身已經足夠活躍，那三分鐘我會想取回。我為自己定下的應變紀律（口訣：Magic Moment 是進度落後時第一個砍掉的東西，Session 2 的捕捉內容永遠不能砍）經過這次驗證，依然站得住。

沒有崩掉的東西

這套四則運算框架還能站住，因為它沒有假裝自己超越本質。四個動作：兩個在 prompt 層（Plus、Minus），兩個在設定層（Multiply、Divide）。你可以在真實工作流程中，腦袋裡同時抓着這四個概念，就算在三個星期之後，在一個沒有人會看着你的星期二。

這才是我在乎的測試。框架有沒有活得比課室更久？三個星期後我回到 Session 2 時就會知道，那時的參加者要麼用這些詞彙談論自己真正的工作，要麼沒有。如果沒有，就代表我選的操作組合錯了，那時我就會找出應該換成什麼。

凌晨一點那次重寫很可能是對的。但「很可能對」是我暫時能給出的全部答案，直至當天坐在課室裏的人，在沒有我的情況下真正用它。