別只叫 AI 扮演專家：Felix Rieseberg 的目標、方法與驗收工作流
Felix Rieseberg 建議使用 AI 時提高目標、深入方法並跨領域協作。本文區分個人經驗與官方功能，提供原創任務範本，把「扮演專家」改成資料、工具、成果與外部驗收。
請 AI「扮演資深分析師」，回答可能立刻多出專業用詞，但你拿到的還是原本那張摘要表。工作方法沒有改變，口氣卻先變得很有把握。
Felix Rieseberg 在 2026 年 10 月 13 日的個人文章談到這個落差：要求專業身分，有時只改變了模型的用語，沒有讓它使用專業人士的方法。
作者首頁自述，他在 Anthropic 工作，曾帶領 Claude.ai、Cowork 與 Code Desktop 的工程團隊。這篇是他的工作經驗與建議，並非 Anthropic 宣布的新功能或效果保證。
對已經會讓 AI 摘要、做簡報的人，我認為最值得先改的是驗收：先寫出結果要能支持什麼決定，再要求交出能核對的資料。這能讓「做得更專業」變成具體工作。
三個方向，可以怎麼用在日常任務？
原作者把提升分成速度、拉高、挖深與拉寬四類，文章略過已相對常見的速度，著重另外三種。以下用白話整理其重點，再配上本文的工作建議。
拉高，是從單一步驟回到最後想得到的結果。例如你原本只要一份客戶流失簡報，可以先改問「哪些問題值得處理、需要做什麼決定」，再決定報告形式。
挖深，是要求使用適合問題的原始資料、方法與工具。當問題是數字對不上，單靠角色扮演不會替你找出漏掉的訂單，還是要讓代理核對來源與計算。
拉寬，則是讓其他領域提供有用的方法。一份面向客戶的數據報告，除了計算，也需要資訊編排與閱讀理解。可以請 AI 分別檢查這些工作，但每一項都要留下可觀察的成果。
把專家角色，改寫成可交付的任務
下面是本文設計的起始範本，方便你套用在既有工作。它不是原文翻譯，也沒有宣稱已經在每個模型或任務驗證。
目標是幫我決定是否調整這個流程。請先列出需要的原始資料、採用的方法及理由，再產出能支持決定的結果。引用資料要能追溯，計算要能重做。最後列出會推翻結論的證據，以及需要由我決定的事項。
假設你要比較兩個月份的客服回覆時間，可以再補上：「使用我提供的去識別化紀錄，依同一個計算定義比較，列出缺漏資料。不要先替差異找原因，先確認時間單位、排除條件與樣本是否一致。」
這個例子把工作分成可以檢查的部分：資料是否齊全、計算是否一致、原因是否有證據。AI 即使提出不同的分析方法，你也有標準判斷它是否回答了問題。
等到資料和定義確認，再問哪些變化值得追查。這樣比較不會把一張完成得很快的圖表，誤當成已經找到問題原因。
資料、權限與驗收，要一起提供
給代理更高的目標，也需要讓它取得完成工作的條件。原作者舉自己處理應用程式當機的例子時，先接好了當機報告與版本對應，並提供 Windows、macOS 和 Linux 電腦以重現問題。
一般工作也能用同樣邏輯，但範圍可以小很多。先給一份測試資料與唯讀來源，確認它能解釋輸出，再決定是否允許修改正式檔案。目標提高，不等於每種權限都要一起開放。
驗收也要放到模型之外。例如用原始訂單重算總額、實際打開匯出的檔案，或交給能確認業務定義的人閱讀。讓 AI 自己說「已通過」，不足以完成這些檢查。
對創作工作，則應保留你要控制的風格與限制。原作者也指出，拉高目標的做法較不適用於某些創作需求。想要特定鏡頭，就應把鏡頭條件寫出來，不必硬改成抽象的大目標。
常見問題
所以不能再叫 AI 扮演專家嗎？
可以交代角色背景，但還要寫它要採取的工作方法與交付證據。角色名稱不會自動補齊資料和工具。
一定要同時開很多代理嗎？
先確認工作能否拆成不同檢查。小任務用一個代理也能逐項完成，代理數量不是品質的判準。
沒有資料庫或專業軟體，也能開始嗎？
可以從一份可核對的資料和清楚定義開始。需要新工具時，先讓 AI 說明用途與成本，再決定是否採用。
先改一個每週都會重做的任務
選一項你熟悉的工作，把提示改成「目的、資料、方法、結果、驗收」五個部分。做完後比較自己是否更容易核對輸出，再決定要不要把這個方式固定下來。
