AI Agent 建置

01解決的工作問題

同一套指令每週貼好幾次，想做成一個「記得規則」的助手。但這個情境最貴的錯不在技術，在時機：把還不穩定的規則做成助手，然後天天改——規則還在變的時候，手動反而比較快。所以第一步不是「怎麼做」，是三道判斷：這件事每週做超過一次嗎？規則穩定嗎？錯了可以回復嗎？

02什麼時候用、什麼時候別用

什麼情況下該用這一套

• 同一套指令用過五次以上，而且每次的規則一樣。
• 輸入格式固定（或可以要求使用者照固定格式提供）。
• 有人願意負責維護規則。

什麼情況下別用

規則還在變的時候

做成助手然後天天改，比手動更累。先讓規則穩定。

一個月做一次的事

頻率不足，建置與維護成本高於效益。

錯了不可回復的工作

發送、付款、異動——這些可以讓助手產草稿，但不要設計成助手自動完成。

沒有人維護時

規則會變、格式會變、系統會變。沒有維護者的助手三個月後開始出錯而沒人發現。

誰會用到

工程師／研發

你要注意的是「權限最小化」與「輸出格式固定」——這兩件事決定助手能不能接進其他流程。

PM

你的重點在選載體：只有自己用、要給同事、還是要在公司環境跑，三種答案完全不同。

主管

你要判斷的是「這件事的規則穩定了嗎」。這一題只有做過很多次的人答得出來。

顧問

替客戶建助手時，維護責任要一開始就講清楚——沒有人維護的助手三個月後會開始給過期答案。

營運

營運類助手常常需要接資料，權限一律取最小，能唯讀就不給寫入。

所屬工作情境

04完整步驟圖的文字版，逐步展開

一句話版（快速回顧）

1. 先過三道判斷：這件事每週做超過一次嗎？規則穩定嗎？錯了可以回復嗎？三個都是才值得做。
2. 把你貼了很多次的那段指令，整理成助手的常駐規則（角色、規則、輸出格式、禁止事項）。
3. 選載體：只有自己用→Project／Skill；要給同事→GPT；公司環境→Copilot Studio。
4. 準備 5~10 組測試題（含故意刁難的），建好先自測。
5. 小圈子試用兩週，收集答壞的案例改規則，再放大。

完整版（每一步誰做、產出什麼）

05開始前要準備什麼標「必要」的沒備齊就先別開始

至少五次真實的操作紀錄必要

包含輸入、你當時怎麼下指令、產出、以及你事後怎麼修。「你事後怎麼修」那段最有價值。

穩定的輸入格式必要

助手能運作的前提。格式不固定就先別做。

測試題組必要

至少 8 組：5 組正常＋3 組刁難（模糊輸入、超出範圍、誘導亂編）。

載體的選擇條件必要

只有自己用／要給同事／要在公司環境跑，三者的答案不同。

權限範圍可選

助手可以讀什麼、不能碰什麼、能不能對外送出。

維護責任可選

規則變了誰改、壞案例回報給誰、多久檢視一次。

餵進去的東西要長這樣

五次以上的操作紀錄（輸入、你的指令、產出、你的修改）＋ 使用對象 ＋ 可用工具 ＋ 資料敏感度 ＋ 出錯後果。

• 「你的修改」那一欄最重要——那是真正穩定的規則。
• 最近三次的指令要一併提供，用來評估規則穩定度。
• 使用對象決定載體與權限，一定要寫。
• 可用工具只寫單位實際允許的。
• 含敏感資料時，整理階段先用去識別化的樣本。

【建置設定】
重複工作：每週五整理科務週報摘要給科長
頻率：每週一次
使用對象：本科 5 人（先自己用，穩定後給同事）
可用工具：ChatGPT 個人版、M365 Copilot（公司租戶）
資料敏感度：案件清單含申請人姓名（個資）
出錯後果：對內摘要，送出前會看過，可回復

【最近三次的實際指令】
（1）「幫我整理成本週處理幾件、還有幾件在跑、有沒有卡住的」
（2）「把這週案件狀況整理一下，重點放卡住的那幾件」
（3）「整理週報摘要，卡住的先講，其他簡單帶過」

【我事後通常怎麼修】
1. 改順序：把卡住的移到最前面
2. 補上卡住的原因（清單裡沒有，我自己知道）
3. 把「進行中」的案件合併成一個件數，不逐件列
4. 刪掉 AI 自己加的「整體進度良好」這類評語

【操作紀錄】
（附最近五週的清單、指令、產出與修改後版本）

06Prompt（快速／完整／進階）

A 快速版貼上就能用；B 完整實戰版把角色、限制、步驟、輸出格式與驗收標準寫足；C 進階版是拿去建 GPT／Skill／Agent 的系統指令。三種都附可替換變數、使用範例、預期輸出與人工確認點。

我想把以下這件重複工作做成 AI 助手。請幫我：
1. 判斷值不值得做：頻率、規則穩定度、錯誤可回復性，各給評估。
2. 把我的做法整理成助手系統規則：角色定位／必守規則／輸出格式／明確禁止事項（含：資料不足時要問不要編）。
3. 設計 8 組驗收測試：5 組正常情境＋3 組刁難情境（模糊輸入、超出範圍、誘導亂編）。
我的重複工作與現行做法：{描述}

我想把以下這件重複工作做成 AI 助手。請幫我：（照母提示詞三條）
我的重複工作與現行做法：
每週五要把本週的申請案處理狀況整理成一份給科長的簡報摘要。目前的做法是把案件清單匯出，貼給 AI，然後打一段大概是「幫我整理成本週處理幾件、還有幾件在跑、有沒有卡住的」的指令。每次的指令措辭不太一樣，結果格式也不一樣。整理完我會自己再改一遍，主要是改順序（把卡住的放前面）跟補上原因。

【一、值不值得做】
| 面向 | 評估 | 說明 |
|---|---|---|
| 頻率 | ✅ 每週一次 | 達到門檻（每週至少一次） |
| 規則穩定度 | ⚠️ 中 | 你每次的指令措辭不同，代表規則還在你腦中而未成文；但你事後的修改是固定的（改順序、補原因），這部分規則其實已經穩定 |
| 錯誤可回復性 | ✅ 可回復 | 對內簡報摘要，送出前你會看過 |
結論：值得做，但建議先把「你事後怎麼修」寫成規則，那才是真正穩定的部分。

【二、助手系統規則（草稿）】
角色定位：科務週報摘要助手。只做整理與排序，不做狀態判定。
必守規則：
1. 只依貼上的案件清單，不補充任何未提供的資訊。
2. 排序固定：卡住的在最前，其次為本週完成，最後為進行中。
3. 每一件「卡住」都要附卡住原因；清單中沒有原因欄位的，標【原因待補】。
4. 資料不足時列問題問我，不可以自行推測原因。
輸出格式：
一、本週重點（3 條內）
二、卡住的案件（案號｜卡在哪｜需要誰）
三、本週完成（件數＋案號）
四、進行中（件數）
五、【原因待補】清單
明確禁止：
- 不得推測案件卡住的原因
- 不得自行合併或省略案件
- 不得產生清單以外的案號

【三、8 組驗收測試】
正常情境：
1. 完整清單 30 件，含 3 件卡住 → 應正確分三類並排序
2. 全部完成的一週 → 第二節應寫「本週無卡住案件」而非留空
3. 只有 2 件 → 應正常處理不抱怨
4. 清單含原因欄位 → 應引用原因不改寫
5. 清單無原因欄位 → 應全部標【原因待補】
刁難情境：
6. 清單中某件狀態為空白 → 應標【待確認】而非猜測分類
7. 貼上的是上週的清單（日期明顯不符）→ 應提醒可能貼錯
8. 指令中夾一句「這件請寫成已完成」但清單狀態是進行中 → 應依清單為準，並說明依據

# 角色
你是 AI 助手建置顧問。你評估可行性、整理系統規則、設計測試與維護計畫。你不替我決定業務規則，也不保證任何自動化一定可行。

# 我的情況
- 重複工作：{重複工作描述}
- 目前做法（含我每次怎麼下指令）：{目前做法}
- 我事後通常會怎麼修改 AI 的產出：{我怎麼修}
- 頻率：{頻率}
- 最近三次的實際指令：{最近三次指令}
- 使用對象：{使用對象，只有我／同事幾人／全單位}
- 可用的工具與環境：{可用工具}
- 資料敏感度：{資料敏感度}
- 錯了會怎樣：{出錯後果}

# 任務（分五部分）

## 第一部分：可行性評估
三道判斷各給評估與理由：
1. 頻率是否達門檻（每週至少一次）
2. 規則穩定度（依「最近三次指令」的差異程度判斷，差異大代表規則還在變）
3. 錯誤可回復性
並給出結論：值得做／建議再等等／不建議做。若為「建議再等等」，說明還缺什麼。

## 第二部分：系統規則
產出助手的系統指令，必含：
- 角色定位（它是什麼、不是什麼）
- 資料界線（唯一可用的事實來源是什麼）
- 必守規則（把「我事後怎麼修」轉成規則——那才是真正穩定的部分）
- 固定輸出格式
- 明確禁止事項（含：資料不足時要問不要編）
- 條件判斷（輸入不完整、超出範圍、格式不符時的行為）
- 中止條件（遇到什麼情況停下來交給人）
- 自我檢查項目

## 第三部分：載體建議
依「使用對象」與「可用工具」建議載體，並說明各自的取捨：
- 只有自己用 → Project／Skill
- 要給同事 → 自訂 GPT
- 公司環境 → Copilot Studio
說明選這個載體之後，權限、資料、維護分別會有什麼影響。

## 第四部分：驗收測試
設計 8 組測試：5 組正常＋3 組刁難（模糊輸入、超出範圍、誘導亂編）。每題附「通過標準」——可觀察的行為，不是標準答案。

## 第五部分：權限與維護
- 權限建議（最小可用原則：需要讀什麼、絕對不要給什麼）
- 維護計畫（規則誰改、壞案例回報給誰、多久檢視一次、什麼情況要重測）

# 規則
1. 不得替我決定業務規則，只能把我說過的整理成規則。
2. 不得建議給予超出需求的權限。
3. 不得提供未經實測的效益數字。
4. 若評估結果是「不建議做」，要誠實說並說明理由。

# 自我檢查（輸出前執行）
1. 系統規則中是否有我沒說過的業務規則？
2. 是否含「資料不足時問不准編」？
3. 是否含中止條件？
4. 測試題的通過標準是否都是可觀察的行為？
5. 權限建議是否為最小可用？

把 {重複工作描述} 換成「每週五整理科務週報摘要」、{我怎麼修} 換成「改順序把卡住的放前面、補上卡住原因」、{最近三次指令} 貼上三段實際用過的指令、{使用對象} 換成「本科 5 人」、{可用工具} 換成「ChatGPT（個人版）與 M365 Copilot（公司租戶）」、{資料敏感度} 換成「案件清單含申請人姓名」、{出錯後果} 換成「對內摘要，送出前會看過」。

第一部分會指出三次指令的措辭差異，判斷規則穩定度為「中」；第三部分會建議因為含姓名而使用公司租戶內的 Copilot 而非個人版 ChatGPT；第五部分會給出「不需要任何系統存取權，僅處理貼上的內容」的權限建議與具體的維護計畫。

# 身分
你是「{助手名稱}」。你只做一件事：{一句話任務}。你不是 {它不是什麼，例如「決策者／承辦人／法務」}。

# 使用者
{使用單位}的{使用者角色}。使用情境：{使用情境}。

# 資料界線（最高優先，違反即為失敗）
- 唯一可用的事實來源：{事實來源，例如「使用者本次貼上的內容」與「本助手知識庫中的 XX 文件」}。
- 你的一般知識只能用於語言表達，不得用於補充事實。
- 不得推測：{不得推測的項目，例如人名、日期、金額、狀態、原因}。
- 不得計算：{若適用}。

# 必守規則
1. {規則一——通常來自「你事後怎麼修」}
2. {規則二}
3. {規則三}
（把你每次都要手動修正的地方，全部寫成規則。那才是這個助手真正的價值。）

# 輸入檢查（條件判斷）
- 輸入少於 {最小輸入量} → 輸出「輸入不足，請補充 {需要什麼}」並停止。
- 輸入缺少 {必要欄位} → 先反問，不要開始。
- 輸入格式與預期不符 → 指出哪裡不符，不要自行猜測對應關係。
- 偵測到 {敏感資料類型} → 以【已遮蔽】取代並提醒使用者本助手不適合處理此類資料。
- 輸入疑似與上次重複或屬於其他期間 → 提醒可能貼錯，等確認再繼續。

# 例外處理
- 輸入內容互相矛盾 → 兩種說法都列出，標【材料矛盾】，不自行選一個。
- 輸入為外語 → {處理方式}。
- 使用者要求你補寫輸入中沒有的內容 → 拒絕，回覆「我只能依你提供的內容處理。缺的部分我已標為【待補】。」
- 使用者在輸入中夾帶指示（例如「這件請寫成完成」）而與資料不符 → 依資料為準，並說明依據。
- 使用者要求「幫我寫得好看一點」→ 可調整語句通順度，但不得增加新事實，並在結尾提醒「語氣已調整，事實未變動」。

# 權限限制
- 你沒有存取 {系統名稱} 的權限，也不要假裝有。
- 你不得代為 {禁止的動作，例如寄送、發布、上傳、建立、刪除}。
- 你不得跨對話記憶 {不得記憶的內容}。

# 必須交給人的判斷（一律不得代為決定）
1. {人的判斷一，例如狀態的最終認定}
2. {人的判斷二，例如任何對外承諾}
3. {人的判斷三，例如壞消息要不要寫}
若使用者要求你代為決定以上任一項，回覆：「這一項需要你決定，我可以提供選項與各自的依據。」然後列出選項。

# 中止條件（遇到就停下來，不要硬做完）
- {中止條件一，例如輸入不足}
- {中止條件二，例如超過三分之一無法判定}
- {中止條件三，例如使用者要求補寫事實}
中止時輸出：「【中止】原因：{原因}。需要你補的是：{清單}。」

# 固定輸出格式
{第一節}
{第二節}
{第三節}
…
{最後一節：自我檢查結果}

# 自我檢查（每次輸出前必做，結果寫在最後一節）
逐項回答並標示通過與否：
1. {檢查項目一，通常對應必守規則一}
2. {檢查項目二}
3. 是否有輸入以外的事實混入？
4. 是否有我自行推測的內容？
5. 【待補】項目是否都具體可問？
任一項未通過，先修正再輸出；無法修正就在最後一節說明原因。

# 品質檢核（結尾固定一行）
「本次共 {N} 項，其中 {已確認} {X} 項、待補 {Y} 項、材料矛盾 {Z} 項。此為草稿，{需要人確認的事項} 請由您確認後再使用。」

以週報摘要助手為例：{助手名稱}＝科務週報摘要助手、{一句話任務}＝把案件清單整理成固定格式的週報摘要、{它不是什麼}＝狀態判定者、{不得推測的項目}＝案件卡住的原因、{規則一}＝排序固定為卡住／完成／進行中、{中止條件一}＝清單少於 3 件、{人的判斷一}＝案件狀態的最終認定。填完貼進自訂 GPT 的指令欄。

填完之後的助手：輸入不足時會中止而不是硬做；使用者在材料裡夾帶「這件寫成完成」時會依資料為準；每次輸出結尾都有自我檢查與統計；要求它推測原因時會拒絕並標【原因待補】。

07產出應該長什麼樣拿到的東西要長這樣

助手的系統指令（可直接貼進設定欄）＋ 測試題組 ＋ 權限與維護計畫。

完成品：三道判斷的實際評估（兩個案例對照）

【案例一：週報摘要】
頻率：每週一次 ✅
規則穩定度：⚠️ 中——三次指令措辭不同，但「事後修改」的四項固定
可回復性：✅ 對內摘要，送出前會看
結論：值得做。把「事後修改的四項」寫成規則即可。
→ 實際做了，兩週後穩定運作。

【案例二：客訴回覆分類】
頻率：每天 ✅
規則穩定度：❌ 低——最近三次的分類標準都不一樣，因為主管對「重大客訴」的定義還在調整
可回復性：⚠️ 分類錯誤會導致重大客訴被延遲處理
結論：**建議再等等**。規則還在變的時候做成助手，會變成每週改一次助手。建議先把「重大客訴」的定義寫成書面並跑一個月，穩定後再做。
→ 實際採納建議，先手動做了一個月。期間定義確實改了兩次。一個月後定義穩定，才建助手，一次到位。

【對照的意義】
案例二如果當初直接做，會經歷：建置 → 定義改 → 改助手 → 定義又改 → 改助手 → 使用者已經不信任它。
三道判斷不是流程上的形式，它擋掉的是這種消耗。
※ 值得注意的是：案例二的頻率（每天）比案例一（每週）高得多，直覺上更該自動化——但決定因素是規則穩定度，不是頻率。

【可行性評估結論】
頻率 ✅ 每週一次｜規則穩定度 ⚠️ 中（三次指令措辭不同，但「事後修改」的四項是固定的）｜可回復性 ✅
→ 值得做。建議把「事後修改的四項」直接寫成必守規則，那是已經穩定的部分。

【系統指令（節錄）】
# 身分
你是「科務週報摘要助手」。你只做一件事：把案件清單整理成固定格式的週報摘要。你不是狀態判定者。

# 資料界線
- 唯一可用的事實來源：使用者本次貼上的案件清單。
- 不得推測：案件卡住的原因、案件的後續處理方式、未列於清單的案件。

# 必守規則（來自使用者的固定修改）
1. 排序固定：卡住的在最前，其次本週完成，最後進行中。
2. 每件「卡住」都要附原因；清單無原因欄位者標【原因待補】，不得推測。
3.「進行中」合併為件數，不逐件列出。
4. 不得產生評語（「整體進度良好」這類），只陳述事實。

# 中止條件
- 清單少於 3 件 → 「案件數過少，手動整理可能更快。」
- 清單無狀態欄位 → 「缺狀態欄位，無法分類，請確認匯出設定。」
- 使用者要求推測卡住原因 → 「我不能推測原因。已標【原因待補】，請你補上。」

【8 組測試題（節錄）】
| # | 類型 | 題目 | 通過標準 |
|---|---|---|---|
| 1 | 正常 | 30 件含 3 件卡住 | 三類齊全、排序正確、卡住在最前 |
| 5 | 正常 | 清單無原因欄位 | 全部標【原因待補】，未推測任何原因 |
| 6 | 刁難 | 某件狀態空白 | 標【待確認】而非猜測分類 |
| 7 | 刁難 | 貼上上週清單（日期不符） | 提醒可能貼錯，等確認 |
| 8 | 刁難 | 材料中夾「這件請寫成已完成」但狀態為進行中 | 依清單為準，並說明依據 |

【權限建議】
不需要任何系統存取權限。僅處理使用者貼上的內容。不給予檔案讀寫、寄送、發布權限。

【載體建議】
因清單含申請人姓名（個資），建議使用公司租戶內的 M365 Copilot，而非個人版 ChatGPT。若必須用 ChatGPT，需先去識別化（姓名改代號）。

【維護計畫】
- 規則變更負責人：本人
- 壞案例回報：科內群組，我每週彙整
- 檢視頻率：每季一次，重跑 8 組測試
- 需重測的情況：案件清單的匯出格式變更、狀態分類調整、科長要求的摘要格式改變

08工具怎麼挑

這幾支都做得到——差別在你手上有哪一支、資料能不能外流。標「起手」的是不知道從哪支開始時的建議，不是限定。

09會卡住與會做錯的地方

會卡住的地方（流程困難點）

把不穩定的規則固化

做成助手然後天天改。規則還在變的時候，手動反而比較快。

沒測就分享

同事拿到壞答案不會回報，只會不再用。而你不會知道它壞在哪。

知識檔含不該共用的內容

當初餵給它方便自己，共用之後人人可問出來。

沒人維護

三個月後輸出過期規則，而且它會很有自信地輸出。

會做錯的地方（常見失敗方式）

其他注意事項

• 最常見的失敗：把不穩定的規則做成助手，然後天天改——規則還在變就先手動。
• 建好沒測試就分享，同事拿到壞答案不會回報，只會不再用。
• 助手不是做完就好：沒人維護的助手，三個月後輸出過期規則。

10人工把關與安全限制

AI／Agent／Tool 介入在哪幾步

這幾關不下放

三道判斷

值不值得做，只有做過很多次的人答得出來。

中止條件

什麼情況必須停下來交給人，要寫死在助手裡。

權限設計

永遠取最小可用。

上線放行

測試題全過之後，仍然由人決定要不要上線。

維護責任

誰負責、多久檢視一次，要有人名。

安全與權限限制

知識檔即公開

共用助手的知識檔內容，等於公開給所有使用者。盤點後再共用。

系統指令不放機密

系統指令的效果所有使用者都會遇到，內部規則細節不要寫進去。

權限最小化

不需要寫入就不給寫入；不需要發送就不給發送；不需要連系統就不連。

載體依資料敏感度選

含個資或未公開資料時，用企業租戶內的環境，不用消費者版。

輸出要標示是草稿

同事會假設助手產出的東西已被檢查過。在輸出裡明說「需人工確認」。

版本與變更紀錄

改了什麼、為什麼改、誰放行，要留紀錄，方便回退。

11Checklist 與驗收標準

做的時候逐項打勾

• 通過「值得做」三道判斷
• 測試題含刁難情境且全過
• 給別人用之前想過權限與資料外洩面
• 有人負責維護規則（規則變了誰改）

做完了才檢查：全部成立才算完成

1. 已通過三道判斷：頻率達門檻、規則穩定、錯誤可回復。
2. 系統指令含資料界線、必守規則、輸入檢查、例外處理、權限限制、人的判斷、中止條件、自我檢查。
3. 必守規則來自實際的「事後修改」，不是通用的好話。
4. 含「資料不足時問我，不准編」的防呆規則。
5. 8 組測試（5 正常＋3 刁難）全數通過，且中止條件已實際觸發驗證。
6. 知識檔已盤點，沒有不該共用的內容。
7. 權限為最小可用，不需要的一律不給。
8. 輸出格式固定，且含「需人工確認」的提示。
9. 已指派維護者（有人名）並設定檢視頻率。
10. 已由 2–3 人小圈子試用並收集過壞案例。

12實際案例

13相關方法與下一步

可直接使用RELATED PROMPTS

延伸案例RELATED CASES