同一個 Prompt 為什麼差這麼多？——從踩坑到 Harness Engineering

TL;DR 摘要

同一個 Prompt 為什麼會得到天差地遠的結果？AWS Solutions Architect 許舜雯（Olivia Shiu）從自己的產圖踩坑經驗出發，將問題拆成三層：Prompt Engineering 把任務交代清楚，Context Engineering 在適當時機提供必要資訊，Harness Engineering 則建立代理運作所需的控制系統。改善 AI，不只是換模型或改問法，也要檢查模型能力、資料供給、任務分工，以及出錯後能否追查與恢復。

• 三種工程是逐層包覆的關係，不是新名詞淘汰舊方法；指令、上下文與控制制度都不可少。
• 上下文不是越多越好：動態載入必要資料，才能兼顧準確度、回應速度與 token 成本。
• 代理控制要涵蓋工具權限、流程編排、記憶與狀態、可觀測性，以及驗證與恢復。
• 從產圖、旅平險比較到 legacy code 分析，案例共同指向一件事：先定位失敗原因，再決定改 Prompt、補資料、拆任務或換模型。

三種工程的演進：從交辦任務到建立制度

同一個 Prompt，為什麼 AI 的表現會差這麼多？Olivia Shiu 從自身踩坑經驗出發，把問題從「怎麼問」逐步擴展到「提供什麼資訊」，以及「如何建立控制系統」。她現任 AWS Solutions Architect，過去做過工程開發、部署 K8s，也參與過專案管理；如今服務的產業涵蓋電信、串流媒體、製造與機器人。跨產業的架構工作，讓她經常面對客戶對 AI 回答品質、表現不穩定與使用成本的疑問。

這些疑問不必然只靠修改一句指令就能解決。當 AI 從回答問題走向自行執行任務，工程設計的範圍也必須擴大：不只讓它理解要求，還要讓它取得合適資訊，並為行動設下界線。Olivia 用 Prompt Engineering、Context Engineering 與 Harness Engineering，整理這三個彼此相依的層次。

• Prompt Engineering 處理如何交代任務：把希望 AI 做的事說清楚，讓它理解要求與預期的交付。
• Context Engineering 處理提供哪些資訊：在對的時間給 AI 對的資料，讓它有回答與執行任務所需的依據。
• Harness Engineering 處理如何控制行動與處理失敗：當 AI 開始自主執行，就需要監控、流程與限制，決定它能做什麼，以及做錯時該怎麼辦。

帶新人是理解這三層設計的直覺類比。交辦工作時，先要說明任務怎麼做，這是 Prompt；接著提供參考資料與必要的系統權限，這是 Context。但新人即使聽懂任務、拿到資料，也不代表公司就能不設制度地讓他自由行動。工作要走哪些流程、有哪些 dashboard 可以查看狀況，以及出錯後如何處理，都屬於 Harness 所對應的管理機制。

因此，三種工程不是新名詞取代舊名詞，而是逐層包覆的工程範圍：Prompt Engineering 是內層基礎，Context Engineering 在外圍補上資訊供給，Harness Engineering 再把控制系統納入。任務說不清楚，外圍制度無法代替清楚交辦；資料不足，也不能只期待模型自行補齊。Olivia 也提到 loop engineering 與 graph engineering，並強調這些概念同樣具有相依性。

「prompt就是叫AI怎麼說 context 叫 AI 看什麼 harness是決定AI能做什麼 那做錯了該怎麼辦」
— Olivia

Harness 原意是馬具。這個比喻的重點，不是讓模型變得更聰明，而是為強大、卻不完全可預期的能力建立控制方式。以模型為中心來看，周圍支援它運作的系統就是 harness：模型供應方會提供一部分，使用模型打造應用的人，也有自己必須設計的部分。

這個心智模型把兩種責任分開：模型提供能力，應用端則不能把流程控制與錯誤處理全交給模型自行決定。明確指令、適時提供的資訊，以及可約束行動的制度，需要一起成立，才能讓 AI 不只是產生回答，而是在有控制的條件下執行任務。

Prompt 的基本功：把要求變成可驗證的交付

Prompt Engineering 是 AI engineering 的基本功：用自然語言交代任務，引導 AI 產出預期結果。簡單問題往往一句話就能說清楚，但當任務涉及文件分析、比較或程式處理，只說「幫我看一下」，就像把文件交給同事卻沒說要看哪裡、交付什麼。模型仍然可能給出一大段回答，卻未必是你需要的成果。

好的 Prompt 通常不是一次寫成，而是經過 Draft、測試、評估、refine 的迭代循環：先寫一版，實際執行，再檢查回答是否符合預期，依結果修改要求並重新測試。這和寫 code 一樣，需要試錯與實驗，而不是找到一句神奇指令就永遠有效。

判斷 Prompt 好不好，重點不只是語句是否流暢，而是要求是否清晰、有結構，以及結果能否重現、能否驗證。模糊交辦會留下大量空白，讓模型自行補齊比較對象、分析範圍或輸出欄位；每次補得不同，就很難比較結果，也更難分辨哪些內容有依據、哪些只是編造。結構化要求能減少這些不確定性，但不代表幻覺就此消失。

「你沒有講，那AI就會自己補細節」
— Olivia Shiu

一個實用的寫法，是把交辦拆成 input、process、output。它不只是排版方式，而是把「給什麼資料、依什麼規則處理、最後交什麼」分開說清楚，讓測試時有具體的檢查依據。

• input：交代資料背景、角色與任務界線，例如要讀哪些資料、不可揭露哪些資訊，必要時提供範例。
• process：把處理工作拆成可驗證的步驟，說明每一步的規則，以及遇到分岔時如何判斷，而不只要求模型籠統地「分析一下」。
• output：明確指定交付格式，例如 JSON 或 Markdown，以及欄位、長度與風格，讓成果能被檢查或交給後續程式使用。

旅平險比較就是很直觀的例子。「幫我比較一下旅平險」看似合理，卻沒有指定業者、旅行情境或比較項目。在講者的示範中，這類模糊要求可能第一次列三家、第二次列五家，甚至偏離題目，輸出欄位也不固定。即使每一份回答看起來都很完整，也不容易放在同一個標準下比較。

改成結構化要求後，input 固定為 A、B、C 三家業者，以及十天歐洲行的情境；process 指定逐條比較保額、給付額與除外條款；output 則要求 Markdown 表格，並附上 100 字的推薦理由。如此一來，測試者便能直接檢查：是否比較指定三家、是否涵蓋指定項目、是否交付表格與推薦理由。

講者展示的三次測試中，結構化 Prompt 的結果維持一致，都有表格與結論。這是該次示範觀察到的穩定性，不代表任何模型在相同要求下都會逐字產生相同答案，更不代表保險內容已自動通過正確性驗證。它的價值，是先讓交付範圍與形式固定下來，讓差異更容易辨識。

另一個 legacy code 分析案例，則顯示模糊要求可能不只造成格式變動，還會讓錯誤內容混進答案。當要求僅是「幫我看一下」程式，模型的回應出現推測與假設，甚至提到原始碼中不存在的段落。若讀者沒有及時發現，就可能沿著錯誤線索繼續查找，耗費時間與 token。

改善方式是把分析工作具體化：明確告知輸入包含 COBOL 檔與可參考的 job 設定，指定列出 PMragraph、找出未使用的變數，並要求依指定結構輸出 JSON。在講者的測試中，這樣的要求讓多次執行的結構與答案維持一致，也更適合由下游程式接手處理，而不是每次重新解讀一篇自由發揮的說明文字。

這類程式分析仍須回到原始碼核對：列出的 PMragraph 是否存在、變數是否真的未使用，以及 JSON 欄位是否符合要求，都是不同的檢查項目。格式一致能讓驗證與重用更容易，卻不能取代對內容正確性的確認。

上下文管理：資料給得多，不等於答得好

Prompt 寫得清楚，仍然無法補上模型沒看過的知識。當任務需要公司內部文件、即時資訊、模型訓練後才發布的 API，或個人化資料時，問題就不只是「怎麼交代任務」，而是「還要提供哪些資訊」。指令可以指定分析方法，卻不能憑空變出今天的匯率、未提供的訂單，或模型不知道的 API 規格。

• 公司內部文件：模型未曾讀過的規範與文件，需要額外提供。
• 即時資訊：今天的股價、最新匯率，不能只靠模型既有知識回答。
• 新版 API：若在模型訓練後才發布，就需要補上相關資料。
• 個人化資料：行事曆、購買紀錄與訂單等，必須讓模型取得，才能據以回答。

Context 指的是模型產生回應那一刻，實際納入計算的所有 Token。它不只包含使用者剛輸入的問題，也包含 System Prompt、User Prompt、文件、knowledge base、工具或 MCP 讀取的資料，以及納入當次請求的對話紀錄。換句話說，判斷模型有沒有足夠資訊，應看它這次真正讀到了什麼，而不只是資料是否存在某個地方。

Context Engineering 因此更像工作記憶體管理：設計一套系統，從文件、DB、API、歷史對話與工具資料中，動態挑選任務需要的內容，在需要的時候交給模型。它不是一份固定格式，也不是把資料庫搬進對話框；關鍵在於每次任務需要的資訊可能不同，供給方式也必須跟著調整。

「不是把所有的資料都丟給它」
— Olivia Shiu

即使 context window 容量很大，裝得下也不等於能有效利用。講者引用 Lost in the Middle 研究，以 20 份文件、其中一份含有正確資訊的實驗說明：將關鍵文件放在不同位置，回答準確率會出現明顯差異。這也是理解長上下文限制時值得留意的現象：資訊存在於輸入裡，不代表模型一定能同樣有效地取用。

• 正確資訊放在開頭：講者引述的準確率為 75.7%。
• 正確資訊放在結尾：準確率約為 76%。
• 正確資訊放在中間：準確率降至 52.9%。
• 不提供這些文件的對照情境：準確率為 56.1%，甚至高於關鍵資訊放在中間的情境。

這些數字描述的是分享中引用的實驗，不能當成所有模型的固定表現。講者將 Lost in the Middle 解釋為與 Transformer 的 attention 結構有關的問題，提醒單純擴大 context window，並不代表資訊利用問題就會消失。實務上需要關心的不只是容量，還包括資訊是否相關，以及關鍵內容放在哪裡。

為了讓容量更有感，講者以哈利波特第 1 到第 7 集類比約 1M Token 的文字量，再反問：如果塞入整套書，只為了問佛地魔的頭髮是什麼顏色，真的有必要嗎？這是容量與浪費的直覺比喻，而非精確的換算標準；它凸顯的是，能輸入大量文字，不代表每次都值得這麼做。

• 費用與延遲：大量 Token 會增加每次請求的成本，也讓回應變慢。
• 重要資訊被忽略：即使答案已經放進上下文，模型仍可能未能有效取用，尤其要留意關鍵資訊埋在中間的情況。
• 無關資訊干擾：與任務無關的內容可能干擾推理，稀釋真正需要的資訊。

講者使用 Kiro 的經驗，也呈現了長對話的管理難題。她原本會看著 context usage 持續增加，等工具自動 comPMct；後來卻發現，接近滿載時，回答容易發散、偏離需求。她因此改成在使用量約 30% 到 40% 時，就主動壓縮上下文，而不是等到快滿才處理。

30% 到 40% 是講者依自身使用經驗採取的操作方式，不是所有模型或工具都適用的門檻，也不能直接由 Lost in the Middle 的實驗推導出來。這個案例的價值在於：當回答開始偏離需求時，除了修改 Prompt，也應檢查工作記憶體是否已累積過多內容，以及當前任務真正需要的資訊是否仍然清楚。

從貼文件到動態供給：MCP 與 SKILL 的分工

把文件直接貼給 AI，是很直覺的 poc 起點。Olivia Shiu 示範的 HR Policy Assistant，就是先指定 AI 根據提供的文件回答問題，再放入一本 200 頁的員工手冊。詢問「育嬰假要怎麼申請」時，這種做法已能得到正確答案；但能回答一次，不等於適合開放給所有員工持續使用。

當問題變成整年度的休假規劃，資料需求也隨之複雜：一位到職一年三個月的員工，接下來有結婚、太太生產、帶父母出國，以及父親可能住院等安排，希望一次知道可用假別、薪資計算、應備文件、申請期限與扣薪金額。在講者的示範裡，AI 雖然仍能回答，卻又需要讀取約 40k tokens 的文件。若更多員工、更多政策文件都沿用這種方式，重複讀取與人工維護的負擔就會浮現。

• 找資料仍靠人工：每遇到不同需求，就要手動找到正確檔案，再把整份內容貼進去。
• 文件越多，越難擴展：公司的政策不只有請假守則，持續堆疊文件會增加 context 的負擔。
• 更新需要重新操作：文件過期後，已貼入的內容不會自行更新，仍須人工替換。
• 資料有放進去，卻沒有經過設計：系統缺少的是依任務選擇與供給資訊的機制，而不只是更多文件。

這就像帶新人：不會在報到第一天，把公司二十年來的文件全部堆上桌，就期待對方立刻完成工作。比較合理的做法，是先給當前必讀的幾份文件、需要的系統帳號，以及部門 SOP。AI 也需要這樣的資訊供給方式：參考資料、取得資料的管道，以及完成工作的操作方法，應各有安排。

「MCP就是管AI可以拿到什麼資料，那SKILL就是AI可以怎麼用這些資料」
— Olivia Shiu

MCP，也就是 model context protocol，是一套開放標準，讓 AI 以統一方式連接資料庫、API、內部檔案系統與工具。講者把它比喻成「AI 的萬用轉接頭」：重點在於統一連接介面，減少為不同資料來源各自客製化 connector 的工作，讓資料與工具能透過 MCP server 提供給模型使用。

SKILL 則像給 AI 閱讀的操作手冊，把一項任務的做法封裝成可重複使用的模板。它不只提供背景知識，也交代什麼情境下該啟用、要按什麼步驟執行、需要哪些工具，以及最後應交付什麼格式。依情境載入這份操作手冊，就不必每次從頭描述同一套工作規則。

• 觸發情境：什麼時候應該使用這個 SKILL。
• 執行步驟：完成任務需要依循哪些操作。
• 所需工具：過程中應使用哪些工具。
• 輸出格式：結果應如何組織與呈現。

兩者並不是二選一。講者常用 RDS 的 MCP，讓 AI 工具取得 RDS 資料來做分析；製作 PowerPoint 時，則會使用自己封裝的 SKILL，把公司模板的配色、字體與排版方式交給 AI 遵循。前者解決資料怎麼取得，後者解決任務怎麼完成：接上資料來源，不代表模型已經知道交付規範；有了操作模板，也不代表所需資料已經備齊。

載入時機則關係到 context 的使用效率。在講者描述的使用方式中，MCP 啟用時就會載入，SKILL 則按情境動態載入；例如提出製作 PowerPoint 的需求後，才呼叫對應的 SKILL。這是她所使用工具的行為描述，不宜直接視為所有實作都相同的規則。

按需載入的價值，是避免把暫時用不到的操作說明與工具資訊全都預先塞入 context。講者提到，Kiro 會顯示 SKILL、Chat 的 History 與 Tool 等內容的占用情況，可用來觀察工作記憶體花在哪裡。把「全部先放進去」改成「需要時再提供」，有助於減少不必要的 context 占用與 token 消耗，也降低上下文長期滿載的壓力；但這不代表只要採用 MCP 或 SKILL，就能保證回答正確或不再出現幻覺。

代理分工：拆小任務，也分配模型成本

Agent 不只是接收問題、產生回答的介面，而是一個能與環境互動、自動收集資料，並自主完成任務的程式。它的核心運作方式是「觀察、思考、行動、再觀察」：取得資訊後決定下一步，執行動作，再根據結果繼續處理。就像已經能獨立作業的新人，不必每一步都有人帶著做，而是能運用手上的資訊與工具推進工作。

但能自主執行，不代表適合包辦所有工作。當任務同時包含 coding、測試與部署，還需要長時間持續執行，單一 Agent 就得承擔不同專業的要求，並在 context 中保留大量資訊與中間結果。講者指出，這類任務容易讓 context 不堪負荷，因此不宜只把整包工作交給一個 Agent，期待它一路完成。

當產出不符合預期，先別急著歸咎於模型。講者從自己的踩坑經驗提出兩個檢查方向：

• 模型是否具備任務所需的能力？如果能力本身不符合需求，再怎麼交辦，也無法憑空得到理想成果。
• 是否把太多事情集中在同一個 Agent？跨專業、長時間的任務需要拆成更細的步驟，讓每個角色能專注完成自己的工作。

這與帶新人很相似：工作做不好，未必只是執行者的問題，也可能是主管沒有交代清楚，或沒有合理劃分責任。任務拆解的目的，不只是把一份工作切成幾段，而是讓各段工作都有清楚的負責角色。

Multi-Agent 就是把這種分工帶進代理系統。透過 orchestration 編排與指派任務，由 orchestrator 協調不同 Agent，而不是讓所有工作都擠在同一個執行者身上。講者舉出的角色分工包括：

• researcher：負責蒐集資料。
• builder：負責寫 code 與 tool，進行建置工作。
• reviewer：負責驗證產出。

分工之後，仍然需要協作。依講者描述，這些 subagent 會共用整個過程的 context、memory 與 output，讓各角色的工作能銜接起來。因此，Multi-Agent 並不是多開幾個 Agent 就自然變好；角色越多，需要協調的資訊與成果也越多。

「multiagent就是很像一個大團隊，就是你人一多其實溝通的成本上升」
— Olivia Shiu

orchestrator 的價值，正是在這個團隊裡負責編排與分派，讓不同角色各司其職。不過，多代理也帶來溝通負擔，不能把它視為所有任務的必然答案；仍要先判斷問題究竟出在模型能力，還是工作過度集中，再決定如何拆分。

角色分工也提供了配置模型成本的機會。講者的實務做法，是用 Haiku 擔任主要負責分派任務的 orchestrator；到了需要撰寫大量文件或 code 的 builder，才使用 opus。這是依工作需求配置模型的經驗，而不是所有編排工作都只需要較輕量模型的通則。重點在於，不必讓每個步驟都使用同等成本的模型，而是把模型能力配置到真正需要它的角色上。

代理控制系統：工具、流程與狀態都要設計

把模型放進能自主執行任務的系統，不能只決定它要讀什麼，還要設計它能用什麼工具、依什麼順序行動，以及中斷後如何接續。Olivia 以 planner、generator、evaluator 三個視角，串起 harness 的六大核心：planner 涵蓋上下文工程與工具系統；generator 涵蓋執行編排，以及記憶與狀態；evaluator 則對應 observAPIlity，以及驗證與恢復。上下文工程是提供正確資訊的基礎，工具、流程與狀態則把這些資訊轉成受控制的行動。

Agent 通常不會單靠模型就完成所有工作，而是需要呼叫 API、tools、MCP，或使用 websearch 取得資料、與外部系統互動。工具系統的設計，因此不只是把功能接上去，也要交代清楚哪些工具可用、如何呼叫，以及使用者是否具有呼叫權限。

Olivia 建議在呼叫外部系統的路徑中加入 gateway。它像工具入口的管理窗口，集中設定背後有哪些工具、呼叫方式是什麼，以及誰可以使用。這讓「有這個工具」與「有權使用這個工具」成為兩個需要分別確認的問題，而不是工具一接上，Agent 就能任意操作。

有了工具，仍需要 Flow Control 決定任務如何推進。自主執行不等於放任模型持續嘗試，而是在事先規劃的流程與界線內行動。執行編排至少要回答以下問題：

• 執行順序：哪些步驟先做，哪些步驟接著做。
• 分支條件：遇到不同情況時，應走哪一條處理路徑。
• retry：失敗後是否重試，以及最多重試幾次；例如講者提到的失敗後再 retry 三次，是可事先設定的流程規則，而非固定標準。
• 中斷條件：什麼情況下必須停止，不能繼續執行。
• 人工核准：高風險動作必須由人核准，不能只因 Agent 能呼叫工具，就直接放行。

「高風險的動作一定需要人去核准」
— Olivia Shiu

流程之外，系統還需要知道自己記得什麼、工作做到哪裡。Memory 與 Status 看似都是保存資料，實際上各自回答不同問題：對話談過什麼、過去有哪些資訊可取回，以及眼前這個任務執行到哪一步。

• 短期記憶：保存當前 session 的對話紀錄，提供這次互動的脈絡。
• Long-Term Memory：將過去對話的相關資訊存入長期記憶區，需要時再取回，而不是每次都把所有歷史紀錄放進當前對話。
• Execution Status：記錄任務目前的執行進度與資料，讓系統能辨認工作停在哪裡。

這三類資料共同支援中斷後的接續：短期記憶保留當前討論，長期記憶提供可按需取回的過往資訊，Execution Status 則留下任務進度。就像交接工作時，除了知道先前談過什麼，也要知道實際做到哪裡；若缺少這些紀錄，任務一旦中斷，就容易每次都得重新來過。

可觀測、可驗收、可恢復，才能定位失敗

同樣的 context，不一定帶來同樣的執行結果。Olivia 示範的案例中，一次執行成功，另一次部分成功卻遇到 timeout，第三次則抓到錯的檔案，交付了錯誤內容。真正棘手的不只是失敗，而是沒有留下 trace：只看到最後結果，就無法判斷問題來自 Prompt、context、工具，還是模型。

可觀測性的作用，就是替 Agent 的執行過程留下可追查的證據。這像是替流程裝上行車紀錄器：結果告訴我們有沒有到達目的地，紀錄則幫助我們還原途中發生了什麼。Olivia 將需要保留的資訊分成五個層次，讓除錯不必只靠猜測。

• session：保留任務完整的上下文脈絡，理解這次執行是在什麼背景與要求下進行。
• trace：記錄單一 request 的查詢與執行路徑，追查請求經過哪些環節。
• sPMn：記錄每個 operation 的起訖與狀態，把問題定位到更細的操作步驟。
• metrics：保留執行狀況的指標，作為觀察與除錯的依據。
• logs：留下執行紀錄，與其他層次的資訊一起協助還原問題。

這五個層次需要搭配使用：session 提供任務背景，trace 串起請求路徑，sPMn 細看各步驟，再由 metrics 與 logs 補足執行狀況。當 Agent 出錯時，才有機會沿著紀錄回查，區分是要求交代不清、提供的資料有誤、工具操作失敗，還是模型產出出了問題，而不是每次都先改 Prompt 或換模型。

「就是大家一定要留下記錄去debug」
— Olivia Shiu

不過，能追查過程，不代表產出就已經正確。驗收仍需要獨立設計。Olivia 提到以單元測試與整合測試驗證內容正確性；這與只看回答是否流暢、格式是否一致，是不同層次的檢查。文字看起來合理，不能取代對實際產出的驗證。

另一種評估方式是 LLM-as-a-Judge，由模型評論 Agent 的輸出。Olivia 特別提醒，應避免讓同一個 session、同一個 model 為自己的產出評分，否則容易形成球員兼裁判的情況。她在 POC 測試中的做法，是以 Claude 產出，再用 open AI 的模型進行 evaluation。這提供了另一個評估視角，但不能把跨模型評估當成正確性的保證，也不應因此省略原本的測試。

驗收之後，還需要替失敗預留處理路徑。recovery 不只是「再跑一次」，而是事先定義哪些情況可以自動重試、如何回復，以及何時應該跳脫。把這些機制設計好，Agent 才能在失敗時有明確的處置方式，而不是不受限制地反覆執行。

重看馬鈴薯事件：先查能力，再換模型與驗收

2025 年 5 月，一段能產出韓系照片的 Prompt 在網路上流行，Olivia 也拿自拍照試了一次。當時她手上使用的是 anthropic Claude，沒有先研究模型能不能產圖、適不適合這類任務，就把照片與 Prompt 一起交給它。模型答應幫忙，等待許久後，交付的卻是一張被她形容為「馬鈴薯」的圖。後來請朋友把同樣的需求交給 ChatGPT，才得到她比較喜歡的結果。

這個案例的關鍵，不是再把 Prompt 寫得更長，而是先確認工具是否選對。Olivia 後續指出，當時使用的 Sonnet 3.7 並不具備她期待的照片生成能力；她也提到 Claude Code 能生成 SVG，但能產出這類圖形，不等於能完成預期的韓系照片。這是當時特定模型與任務之間的能力落差，不能延伸成 Claude 所有版本都不適合產圖的結論。

「prompt、context跟 right model，你都是要確認完之後，我們才可以優化我們的準確度跟成本」
— Olivia Shiu

更容易踩坑的是，模型願意接下任務，不代表它真的做得到。在這次經驗裡，Claude 並沒有先拒絕，而是答應產圖，最後交出不符預期的結果。就像把工作交給不具備相關技能的人，交辦內容再清楚、參考資料再完整，也無法補上能力缺口；表面上的配合，反而可能讓使用者繼續等待、投入更多 token。

Olivia 後來用 harness 重新實驗這條流程，改善方向不再只是要求模型「再試一次」，而是把能力檢查、停止條件與模型選擇放進執行流程：

• 先確認能力是否匹配：在開始生成前，檢查所選模型是否適合目標任務，不把模型口頭答應視為能力證明。
• 不適合就提早停止：若能力不符，讓流程在前面結束，避免繼續消耗 token，最後仍交付不符合期待的結果。
• 改用適合任務的模型：與其持續修飾同一份 Prompt，不如更換執行者，讓照片生成交給具備相應能力的模型。
• 把生成與驗收分開：她嘗試由 ChatGPT 產圖，再交給 Claude 驗證，讓產出多經過一道獨立檢查。

在後續示範中，Olivia 也展示了背影照的生成結果，並將跨模型驗收納入實驗。這種安排的用途，是讓「已經產出圖片」與「圖片符合要求」成為兩個分開判斷的步驟，而不是由生成端一路自行認定成功。不過，這次示範呈現的是一條可行的改善路徑，並不代表換一個模型驗收，就能自動攔截所有錯誤。

接回開發流程：AI 輔助，不是丟掉工程方法

AI 能參與越來越多開發工作，不代表原本的工程方法就該丟掉。Olivia 將 SDLC（Software Development Life Cycle）與 AWS 推出的 AIDLC 對照：需求、設計、開發、測試、部署與維運仍然存在，改變的是各階段如何加入 AI 協作，而不是省略原有的工程責任。

「其實跟你以前的工作方式其實差不多，只是現在做了AI來輔助你。」
— Olivia Shiu

這種對照讓代理系統的設計不再像一套全新的陌生技術，而是把熟悉的開發問題，轉換成適合 AI 參與的工作形式：

• 需求：過去要寫清楚需求，現在可以透過 AI 協助撰寫 spec，並整理成結構化 Prompt。交辦方式變了，但仍要先釐清希望完成什麼，才能讓後續工作有依據。
• 資料設計：過去需要設計 schema，面對 AI 則要進一步設計 context：提供什麼資訊、什麼時候提供，以及如何供給。資料不只是預先備妥，還必須配合任務進程送到模型面前。
• 開發：除了實作功能，也要設計需要哪些 Agent，以及如何透過 orchestration 編排它們的工作。角色與執行安排，成為開發工作的一部分。
• 測試：AI 可以協助 evaluation、retry 與獨立驗收，但測試責任並沒有消失。產出之後仍需要評估與檢查，而不能把完成生成直接視為完成交付。
• 部署與維運：讓 AI 協助維運，需要提供足夠的執行資訊，並具備 observAPIlity、驗證與恢復機制。可觀測性讓執行狀況有跡可循，驗證與恢復則讓服務不只會啟動，也能在出現問題時有處理依據。

從這個角度看，Prompt、context 與代理控制並不是脫離軟體工程的額外技巧，而是把工程紀律帶進 AI 協作：先把問題問清楚，再於合適的時間提供合適的資訊，並為執行過程建立控制機制。模型能做哪些事，與系統如何安排、檢查及維持這些工作，是必須一起設計的問題。

Olivia 也以 anthropic 的 planner、generator、evaluator 三個階段，作為理解實作路徑的視角：從規劃、生成到評估，把 Agent 的開發與後續服務拓展放進同一條工作流程中。這個視角的用途，是協助辨認每個環節的責任，而不是用一個生成步驟取代整個開發生命週期。既有的需求釐清、設計、測試與維運方法，仍是讓代理服務持續運作的基礎。

「帶AI其實跟帶人一樣，你就是交代清楚，給對他的資料，然後建立好制度。」
— 許舜雯（Olivia Shiu）

重點回顧

• 問法不清，先補任務背景、處理規則與交付格式；結構穩定只是驗證的起點，不等於內容必然正確。
• 資料不足或雜訊太多，改造上下文供給：挑選相關資訊、維持時效、按需載入，並觀察壓縮前後的實際效果。
• 任務過重，先拆分責任與檢查模型能力，再評估是否需要多代理，以及各角色適合的模型成本。
• 結果忽好忽壞，不能只怪模型：留下執行紀錄，搭配測試與獨立評估，才能找到出錯環節。
• 準備讓代理上線時，工具權限、人工核准、中斷條件與恢復路徑，都應是系統設計的一部分。

這場分享的核心，不是再增加一套提示詞技巧，而是把 AI 的品質問題拉回工程設計。Prompt 決定交辦是否清楚，context 決定資訊是否到位，harness 則讓行動有邊界、失敗可追查。與其期待模型每次都剛好答對，不如讓系統能看見問題，並有方法修正。

Prompt EngineeringContext EngineeringHarness Engineeringcontext windowLost in the MiddleMCPSKILLAgentMulti-AgentorchestrationgatewayFlow ControlExecution StatusobservAPIlityLLM-as-a-JudgeverifyrecoverSDLCAIDLC