Codex 不知道怎麼問？非工程師的零起點提問框架與工作流

多數人卡在 Codex 面前的時刻，不是安裝，而是安裝完成後打開輸入框的那幾秒。游標閃著，你想不出第一句話要打什麼，於是關掉視窗，回頭繼續用手做原本的工作。這個情境有一個名字：不知道怎麼問。它不是技術問題，是起手式的問題，而市面上多數教學預設你已經寫得出一段完整的任務描述，直接跳去講參數與進階操作，零起點的人就這樣被留在門外。

這篇是站上 Codex 系列裡門檻最低的一篇，服務兩種人：完全不寫程式的非工程師，以及想用 AI 代理處理日常文書、卻每次都覺得「我不會下指令」的人。整篇只處理四件事：不知道怎麼問的時候用什麼框架開口、一份非技術的會議紀錄如何走完三輪對話、結果不滿意時如何用對話修正、以及哪些操作屬於對外不可逆、必須畫出風險邊界。Codex 的概念與介面分類，Codex 入門解析談過；四條安裝路線的逐步教學，Codex 安裝指南已經整理好，這篇不重複那些內容，直接從你打開它之後的第一句話開始。

先卸下兩個心防：提示詞不完美，也有產值

第一個心防是「我要先學會寫提示詞才敢開始」。官方最佳實踐指南對此講得很直白：即使你的提示詞不完美，Codex 也已經足夠強到能產出有用的結果，清楚的提示詞不是獲得價值的前提，它只是讓結果更穩定，尤其在大型或高風險的任務上。官方的使用方式文件也重複同一個立場：你不需要完美的第一句提示詞，也不需要特殊指令。換句話說，「寫不出漂亮任務描述」從來不是延期開始的理由，它只是結果會多繞一兩圈的訊號。

第二個心防是「這類工具大概有一堆指令要背」。沒有。提示詞可以是一個問題、一條指示，或一個目標，官方提問指南的建議是用自己的話開始，看完回應，再用後續訊息把結果修成你要的形狀。整個工具的操作核心是對話，不是指令表。你已經會的技能：跟一位新同事交代事情、看他交來的初稿、告訴他哪裡要改，在這裡全部用得上。

官方使用方式文件把「從想法到有用結果」畫成四步：帶著一個問題、點子、粗糙筆記、檔案或待辦走進來；請它解釋、發展、草擬、查證、分析或創作；補上它需要的素材與工具，例如檔案、網路搜尋或專案；審查結果、導正方向、要求修改。這四步值得零起點的人抄在便利貼上，因為它同時回答了兩個問題：我現在該做什麼，以及下一步是什麼。你的注意力只在「給素材」與「審結果」之間擺盪，中間的苦工是它的事。

動手前只剩一個選擇題：從哪個入口工作。官方文件把三個入口的分工講得很清楚：

非工程師的日常任務多數落在 Chat 與 Work，連檔案分析與文件起草 Work 都做得來；在支援的環境裡，Work 也能處理本機檔案與指令，兩個入口的能力有重疊。差別在工作流的形狀：Codex 以專案工作區為中心，為來回讀寫多個檔案、批次操作、留下可審查的變更紀錄這類任務而設計。當任務是在一個資料夾裡反覆操作並驗收變更，Codex 的介面就是為它準備的。三個入口共用同一套對話邏輯，這篇講的框架在每一個上都成立。

成本心態也順便建立。文書任務的單次用量通常不大，但別把它當保證：相似任務的額度消耗可能隨範圍與做法而異。方案內的用量是滾動計算的，工作階段裡想看剩餘狀況，CLI 裡輸入 /status 就會顯示，網頁端則看帳號的用量頁。真正的成本紀律只有一條：任務範圍別開太大，一次讓它做一件可審查的事，比一次讓它翻整座檔案櫃便宜也更安全。

零起點框架：四個欄位把說不出口變成問得出來

不知道怎麼問的時候，缺的通常不是文采，是結構。官方提問指南給的預設結構有四個部分：目標（它該做什麼）、背景（哪些資訊或來源有幫助）、產出（你要什麼格式、長度、詳細程度）、界線（什麼必須保持不變、什麼要先問你）。最佳實踐指南的版本大同小異：目標、背景、限制、什麼算完成。兩份官方文件合起來讀，可以收斂成一張四欄卡片，寫提示之前拿它問自己一遍，第一句話自然就長出來。站上另有一篇講提示詞四積木的泛用入門，處理的是任何 AI 工具都適用的提問基礎；這篇把同一套思考搬進 Codex 的任務脈絡，多了工作區、檔案範圍與驗收條件三個只在代理工作流裡才會出現的考量。

四欄有兩個使用原則，都來自官方文件。第一，從結果出發，不是從步驟出發。官方的說法是「先描述你要的結果，而不是詳細的步驟清單」，把怎麼做的空間留給它，你只負責定義什麼叫做好。第二，只寫有用的欄位。官方明講這四個部分不必每項都填，也沒有規定格式，小任務一行目標就夠，重要任務才把四欄補齊。把四欄當成備忘清單而不是表格作業，壓力會小很多。

完成樣貌這一欄值得多花三十秒。官方指南特別提醒：告訴它你打算怎麼使用結果，它才知道該選多長、多詳細、怎麼組織。同一份會議摘要，「給主管開會前掃讀的一頁版」與「給執行團隊逐項追蹤的完整版」是兩種不同的產出，你不說，它只能猜。用途講清楚，能省下一輪輪試錯的修正。

素材欄位也有官方背書的幾個給法。要它摘要、比較、轉換時，直接附上文件、試算表或 PDF；任務依賴畫面時，貼截圖並用一句話指出重點在哪個區域，不要只丟一張圖；答案會隨時間變動時，明說請它用網路搜尋並附上來源；同一批檔案會被多個對話用到時，把它們放進同一個專案裡。素材給法的心法與完成樣貌相同：講出它該從每份素材裡拿什麼，而不是把整個硬碟倒給它。

四欄看得眼花時，退回最小版本：一句目標加一條界線。「把這份紀錄整理成一頁更新，日期與金額不要動」就是一個完全合格的起始提示詞，它有目標、有完成樣貌的雛形、有一條界線，其餘等看完初稿再補。零起點者最常見的錯誤不是寫太少，是為了寫得多而把還沒想清楚的東西一起塞進去，結果初稿往錯的方向長，修正反而更花時間。這條路比追求完美開場快得多。

界線這一欄的價值在防止真正的麻煩。官方給的範例句型包括：已核准的日期與預算數字保持不變、只使用我提供的資料、缺漏的資訊標示出來不要用猜的、訊息先做成草稿不要寄出。每一條都對應一種真實的出事方式：改錯關鍵數字、虛構來源、擅自對外發送。界線不必多，官方的建議是聚焦在一兩條最重要的，那一兩條通常就是你事後最不希望出錯的地方。

四欄湊起來，一份完整的提示詞長這樣（以會議更新為例，改寫自官方文件的示範）：

幫我準備週一主管會議用的一頁專案狀態更新。
素材：附件是本次會議紀錄，決策與待辦以它為準。

完成樣貌：主管需要決定的事項與後續步驟放最前面，
再依序是進度、風險、負責人與期限。
界線：已確認的日期與預算數字保持不變；
資料有缺漏或互相矛盾就標示出來，不要補猜。
結束前自查：每個後續步驟都有負責人與期限。

這段不到一百字，卻把四欄全數覆蓋，還加了一句結束前自查。官方指南把這個動作稱為 final check：要求它在收尾前自己檢查一次，例如確認每個行動項目都有負責人與期限、標出它無法查證的資訊。自查不會取代你的審查，但它會把明顯的漏項先撿起來。

連要什麼都說不清楚：兩個官方後援

四欄框架解決「說得出口但不知道怎麼組織」的人。更深一層的卡關是：我連自己要什麼都還沒想清楚。官方對這個情境有兩個直接對應的後援，都在最佳實踐指南裡。

第一個後援是反向面試。官方原文的場景描述是：如果你對想要的東西有模糊概念、但不確定怎麼描述，先請它反過來問你問題，並且告訴它要挑戰你的假設，把模糊的想法變成具體的東西，再開始動手。換成可以直接貼上的腳本：

我想把部門的週報流程改快，但我不確定該怎麼描述需求。
請你先面試我：一次問一個問題，問我現行流程、痛點與期待，
問完之後把你理解的任務描述寫給我確認。
我說開始才開始做事。

這個腳本有三個值得留意的地方。它把發問權暫時交給對方，一次一題避免你被十個問題淹沒；它要求把理解複述給你確認，確認之前不動工；它示範了界線欄位的用法，用一句「我說開始才開始」擋住搶跑。它的價值在於把「想清楚」這件最難的事外包出去，而你只需要回答問題，回答問題比憑空寫出需求容易得多。

第二個後援是計畫模式。任務複雜、模糊、難以描述時，官方建議先讓它調查與規劃再動手：在輸入框打 /plan（或按 Shift+Tab 切換），它會先蒐集脈絡、向你提出釐清問題、建立一份計畫。官方長任務文件把兩個後援串成一條路：結果還不清楚時先用計畫模式，讓它面試你、找出限制條件，把結果變成帶有可衡量完成條件的目標，再用 /goal 啟動。對零起點的人，這條路等於把「想清楚要做什麼」變成工具的內建流程，而不是你的前置作業。

打字慢或講不清楚的人還有第三條路：語音聽寫。桌面 App 裡按 Ctrl+Shift+D 對著麥克風說，說完它轉成文字讓你編修後再送出。口語描述往往比打字更自然，官方指南自己也建議用聽寫來快速交代上下文。說話本來就是你最熟悉的表達方式。

走例：一份會議紀錄的三輪對話

框架講完了，用一份非技術任務從頭走一遍。情境是虛構的示範：你是專案助理，剛開完一場四十分鐘的產品會議，手上有一份零散的會議紀錄，主管要在週一晨會前知道結論與待辦。目標是把爛攤子變成一頁更新，外加一封給缺席同事的後續信。

開始前的準備只有兩件事。把紀錄貼進對話或附成檔案，別讓它靠你的轉述猜內容；把任務用不到的個資先拿掉，人名換職稱、客戶換代號。這一步在送出之前做：本機檔案雖然可以留在裝置上，但送進對話的節錄、提示與工具結果會送往服務端處理，貼出去的內容拿不回來。素材的品質是它表現的天花板，爛素材它救得回來一部分，好素材它根本不需要救。

原始紀錄的長相大概是這樣（以下節錄同樣是虛構示範，且已經做過送出前的去識別化，客戶 A 是代號）：

09:42 業務窗口說 Q4 贈品活動要延後，理由是物流端還沒確認倉位
有人提到客戶 A 上週抱怨出貨單把公司名稱打錯字
（中間兩段討論採購流程，與結論無關）
預算好像動了行銷那邊一筆錢？要再跟財務確認實際數字
10:05 散會前有人提議下週先跑一輪贈品活動的內部測試，沒有結論

第一輪，只交代目標、素材與完成樣貌，界線放一條就好：

把附件這份會議紀錄整理成給專案團隊的簡短更新。
決策與後續步驟放最前面，再來是風險與討論未完的事項。
用詞平實，不要出現「革命性」「重大突破」這類字眼。
日期、人名、金額以附件為準，不要更動。

這一輪示範的重點是：不需要把四欄寫滿才能開始。素材用附件給，完成樣貌用兩句話講清楚排序，界線只有一條資料不動、一條語氣要求。第一輪回來的初稿已經分成「決策」「後續步驟」「風險」「討論未完」四段，決策只有贈品活動延後一條，會中提議但沒有結論的內部測試被如實放進討論未完，預算數字標了「待與財務確認」而不是擅自補一個。三個後續步驟全部缺負責人與期限，因為原始紀錄裡本來就沒有人認領；開頭則先鋪了兩段會議背景。初稿的骨架對了，要修的就是這些看得到的位置。如果你貼上的紀錄本身很亂，它通常會先自行整理出結構，這正是它的強項：你給爛素材，它還你結構。

第二輪，看初稿之後，指名要改的地方：

開頭兩段太鋪陳，直接從決策講起。
每個後續步驟都要標負責人與期限，
負責人紀錄裡沒有的寫「待指派」、期限沒有的寫「待確認」，
不要自己填人名或日期。
第二段的風險描述加一句對時程的具體影響。

這一輪示範對話式修正的三個手勢。指出位置（開頭兩段、第二段），說明方向（直接從決策講起），畫出資料界線（沒有的寫待指派或待確認，不要編人名日期）。修正訊息的品質決定往返次數，含糊的「再精簡一點」會得到它猜的版本，具體的「開頭兩段合併，從決策講起」一次就到位。官方指南的示範句也是這個結構：開頭更直接、保留證據、把建議移到背景說明前面，三個動作都指名道姓。第二輪回來的骨架長這樣，每一行都對得回原始節錄：

決策
一、Q4 贈品活動延後（業務窗口宣布，理由：物流端尚未確認倉位）。
風險：倉位未確認前，活動上線時程無法承諾。
後續步驟
一、與財務確認行銷預算實際數字（待指派／期限待確認）
二、（建議）修正客戶 A 出貨單的公司名稱錯字（待指派／期限待確認）
三、（建議）追蹤物流倉位確認進度（待指派／期限待確認）
討論未完
一、下週是否先跑贈品活動內部測試（會中提議，未結論）

開頭直接從決策講起，待辦如實標了待指派與待確認，會中沒有結論的內部測試留在討論未完，風險那句「倉位未確認前，時程無法承諾」也看得出處。值得留意的是後兩個待辦：原始紀錄只記了客訴與倉位未確認，是它推導出「修正錯字」「追蹤倉位」這兩個動作，因此標上了（建議）與待確認，而不是偽裝成會議的既定結論。紀錄所載與它的建議分得開，這是你要的眼睛。

第三輪，收尾時轉成另一種產出：

很好。用這份更新改寫成一封給缺席同事的後續信，
信裡包含決策、負責人與期限，語氣親切但不囉嗦，
一百二十字以內。
寄出前先給我看草稿，不要直接寄。

它交回來的信長這樣：

哈囉，補一下這場產品會議的重點：
Q4 贈品活動確定延後（物流倉位尚未確認）；
行銷預算實際數字待財務確認。
後續三件事的負責人與期限都待指派：
預算確認、客戶 A 出貨單錯字修正（建議）、倉位追蹤（建議）。
需要細節再跟我拿，週一我會有整理好的版本。

第三輪示範兩件事。同一個對話裡的上下文是連續的，你不必重貼會議紀錄，它看得到這個對話裡先前的內容；以及對外不可逆的動作在這裡畫線：先給草稿，不要直接寄。草稿也把缺漏如實帶進信裡，待指派與建議標記都保留著，你讀一遍、改順語氣，才貼進信箱送出。三輪走完，四十分鐘會議的爛攤子變成一頁更新加一封信，你的角色從產出者變成審查者。

對話式修正的技術：不用重來，只要說清楚哪裡不對

把三輪走例裡的修正動作抽出來單獨講，因為這是零起點者進步最快的一項技能。官方提問指南的定位句值得背下來：你的第一個提示詞不需要完美，看結果，然後要求你想要的特定改變。後續訊息能做的事比多數人想像的多：補上漏掉的素材、導正方向、要求另一個版本、調整詳細程度，全部不用重新開始。開新對話是最貴的選項，它把累積的上下文全部丟掉。

修正訊息的好壞有一條清楚的分界。含糊的修正：這樣感覺不太對，你再改一下。具體的修正：開頭直接給結論，證據保留，建議移到背景前面。後者的每一個動詞都對應一個可檢查的改變，它不需要猜你想要什麼。養成一個習慣：送出修正前問自己，這段話拿給一位人類同事看，他知道要改哪裡嗎？如果人類要猜，AI 也要猜。

它正在跑的時候也能插話，而且插話有兩種模式。官方文件把它分成導引與排隊：導引把訊息加進目前正在跑的這輪，用於改方向、補細節；排隊把訊息留到這輪結束後的下一輪，用於不相干的後續要求。CLI 裡的鍵位是 Enter 導引、Tab 排隊，桌面 App 則在設定裡選預設行為。這套機制的細節與更多變化，Codex 進階操作解析有完整整理，這裡記住區別就夠：打斷是為了改方向，排隊是為了不干擾。

對話的管理還有一條官方建議的紀律：一個對話顧一件事。最佳實踐指南把「整個專案擠在同一個對話」列為常見錯誤，上下文會膨脹，結果會變差。同一件事的追問留在同一個對話，換主題就開新的，這條紀律跟人類開會的原則一致：一個會議一個議程。

長一點的任務還有一個觀念值得先認識：把完成條件寫進任務裡。官方長任務文件的建議是給它清楚的結果、限制與完成定義，讓它能自己判斷做到哪裡算完成；結果還在演進時，在同一個對話裡繼續補充與調整，互不相干的任務才開新對話平行跑。桌面 App 與 CLI 都有目標模式可用，一段寫清楚「什麼算做完」的目標文字，既是第一句提示詞，也是它的驗收標準，一份文字兩用。

修正還有兩個防禦性手勢。它改過頭、動了你沒叫它動的東西時，直接說：只改開頭，其他部分維持原樣，並且請它列出這次動了哪些檔案或段落。它連續兩次誤解你的意思時，與其第三次換句話說，不如讓它複述一次它理解的任務，誤解通常在複述裡現形。兩個手勢都只花一句話。

風險邊界：草擬歸它，扣扳機歸你

零起點階段最該建立的觀念，不是任何提示詞技巧，而是一條權責線：草擬歸它，扣扳機歸你。官方文件對這條線的表述足夠清楚。提問指南的界線範例直接寫著：訊息先做成草稿，不要寄出。針對更大的任務，官方的使用建議是：在它寄送、發布或更動他人依賴的資訊之前，必須先取得你的核准。把這兩句放進你的預設界線欄位，對外風險就被擋在了草稿階段。

軟體端對這條線有對應的機制，值得認識名詞。官方權限文件的建議是多數工作從 Ask for approval（要求核准）模式開始：它在目前的工作範圍內自由行動，要越過邊界之前先停下來問你。其餘兩個模式是 Approve for me（代為核准，設定裡叫 Auto-review，由自動審核機制把關）與 Full access（完整權限），實際可見的選項依方案與設定而異。沙盒機制文件把兩層控制講得很明白：沙盒定義它能碰哪些檔案與網路資源，核准政策決定它在哪個動作前暫停。一句關鍵結論來自權限文件原文：改由誰來審核，並不會擴大沙盒的邊界。也就是說，把關可以自動化，能碰的範圍不會因此變大。

新手對 Full access 要有敬意。最佳實踐指南把「在還不了解工作流程之前，就給它整台電腦的完整權限」列為常見錯誤，官方的建議順序是先保持預設的緊權限，等你理解它的行為模式、且在可信任的專案裡，再按需要放寬。

核准彈跳出現時怎麼讀

第一次遇到核准彈跳的人常以為出錯了，其實那是邊界機制在照常運作。彈跳會告訴你它想做什麼，例如執行某個指令、碰某個範圍外的檔案；你的選擇也不只准與拒兩種，視介面而定，可以只准這一次，或核准到本次工作階段結束。讀彈跳的順序：先看它想執行的具體指令、想碰哪些檔案或網域、會不會把資料送往外部或刪改東西、核准有效期到哪裡，再對照你的任務描述，然後決定准不准。判定標準一句話：這個動作在我的任務範圍內、且後果我承受得起嗎？兩者都是再准，核准範圍取能繼續完成工作的最窄選項就好；有一個不是，先拒絕並請它解釋為什麼需要這個動作，看不懂的核准永遠不要點。把範圍用一句界線補進任務描述能減少無謂的彈跳，但別期待它從此消失：沙盒與核准政策的邊界不由提示詞決定。

每次它停下來，你都在看它的工作方式：它打算怎麼拆步驟、想動用什麼工具、對邊界的理解跟你一不一致。看幾次下來，你會知道哪些事它穩、哪些事你要盯，信任有了依據。零起點階段別為了省事急著把核准關掉。

涉及檔案的工作再加一道保險：讓可回退成為預設。它動手改檔案之前，確保那些檔案在某種版本控制或備份的保護下，出事時退得回去。官方文件對多步驟任務的建議裡也包含在任務前後建立檢查點的習慣。最終一關永遠是人：官方指南在自查建議之後補的那句話是，在它檢查完之後，你自己還要再看一遍才使用或分享。自查是它的責任，終審是你的責任，兩層都不能省。

六類起手任務範本：找到你的第一個任務

框架與邊界都齊了，還缺一個「今天下班前就做一件」的入口。以下六類是為非技術工作場景設計的起手任務，每一類附一個可直接改寫的範本，而且每一個範本都內建至少一條界線與一句結束前自查。挑一個貼近你本週工作的，把括號換掉就能用。

一、會議紀錄整理。練的是目標與完成樣貌：

把（附件會議紀錄）整理成一頁更新，決策與待辦在前。
負責人缺的寫「待指派」，期限缺的寫「待確認」。
結束前自查：每個待辦都有負責人與期限，或明確標了缺漏。

二、長文件摘要與問答。練的是素材與界線：

讀（這份報告／合約），用三百字說明它要求什麼、
對我們的影響、三個最需要注意的條款。
只依文件內容回答，文件沒寫的就標「文件未提及」。
結束前自查：三個條款都能指出在文件中的段落出處。

三、資料表清理。練的是界線與自查：

這份 CSV 有姓名格式不一、重複列與缺欄位的問題。
原始檔保持原樣，另輸出整理後的新檔。
疑似重複的列先列表標明判定依據，待我確認後才合併，
缺欄位的列單獨標出，不要逕行刪除。
結束前自查並回報：統一了幾筆、幾組疑似重複待確認、缺欄位幾列。

四、草稿語氣改寫。練的是具體修正：

把這封客訴回覆草稿改得專業但不冰冷，
保留道歉與補償方案，刪掉所有藉口。
語氣對象是被耽誤出貨的長期客戶。
改完自查：道歉與補償方案還在，全文沒有新增藉口句。

五、查證與彙整。練的是來源紀律：

查證（這個說法）目前是否成立，引用可點開的來源，
每個關鍵結論附上資料日期。
查不到可靠來源的結論，明說查不到，不要硬寫。
結束前自查：每個結論都對得上一條可點開的來源。

六、文件產出。練的是完成樣貌的規格化：

把（這份分析）做成一頁報告：結論三點在最前面，
每點附一個風險，以及一個支持數字（附件查得到的才附，
沒有就標「附件無資料」，不要補估）。
先給大綱讓我確認，確認後才寫全文。
寫完自查：附上的每個數字都指向附件的原始位置，
標了無資料的點沒有被補上估計值。

六類的共同設計：每一個範本都內建至少一條界線與一句自查，這是刻意的。範本用久了，界線與自查會內化成你寫任何提示詞的反射，那時你就不需要範本了。要在專案資料夾裡反覆操作的版本，例如把數十份文件批次重整成統一格式並產出變更清單，就是 Codex 以工作區為中心的介面派上用場的時機：把資料夾設成工作區再開對話，它能來回讀寫檔案、執行批次操作，並回報每個動過的位置。

從第一句話到穩定工作流

第一個任務跑完之後，深化路線只有三步，每一步都有官方文件背書。

第一步，手寫四欄幾次，建立語感。這週用兩三個小任務刻意練習：送出前把四欄在心裡過一遍，漏了界線就補一句。練過幾次之後，框架會從檢查表變成直覺，你寫提示詞的速度會回到平常說話的速度。

第二步，把重複的交代變成常駐說明。同一件工作做到第三次，你會發現每個對話都在重複貼同一段背景（我們公司的用語、客戶的稱謂、報表格式）。官方的解法是 AGENTS.md：一份放在專案裡的代理說明文件，代理動工前會自動讀取。AGENTS.md 開放規格把它定位成「給代理看的 README」，超過六萬個開源專案採用，規格由 Linux Foundation 底下的基金會托管；Codex 的對應文件說明它可以分層放置，越靠近工作目錄的指示優先。CLI 裡的 /init 指令能為當前目錄生成起始版本，官方提醒生成後要照團隊實況改寫。內容原則官方只有一句，但那句就是重點：簡短而正確的說明文件，比一長篇空泛規則有用。還有一條進階習慣值得偷學：當它同一個錯誤犯第二次，請它做一次回顧，把學到的規則補進說明文件。你的工作流從此會自己長記性。

官方指南對「第三次以後」的工作還有一條路線：流程穩定之後，把它包成可重複使用的技能；需求再固定一點，就排成排程任務讓它在背景定期跑。官方的原話是技能定義方法、排程定義時間，順序不要顛倒，還需要你一路盯著修的工作先別排程，等它可靠了再自動化。零起點階段知道這條路存在就好，你的第一週目標只是把四欄變成反射。

第三步，按需要往深處走。導引與排隊的完整鍵位、長任務的暫停與導引、手機接手電腦上的對話、跨機器備份，這些操作層的技巧都在進階操作解析裡；想改走終端機路線的人，CLI 命令列入門先打底再回頭看安裝指南的 CLI 段落。順序很重要：框架與邊界站穩之前，不必急著追操作技巧。

常見卡關快查

表裡的第四項值得展開。AI 在資訊不足時傾向補全而不是留白，這不是它壞，是它的預設行為。對應的界線句官方已經寫好：只使用提供的來源，缺漏的資訊標示出來，不要用猜的。凡是要對外使用、要進報告、要給客戶看的產出，這條界線都該在。搭配來源要求（每個關鍵結論附可點開的出處），你可以把它的輸出從「看起來很像真的」推到「每一句都查得到」，後者才是能簽名的版本。

卡關的另一個極端也提一句：它停下來問你問題，不是故障。代理的工作迴圈本來就包含向你要素材這一步，它問的每個問題，都是在替你省下一輪錯方向的產出。把它的問題當成一次需求訪談，答完之後通常會直接到達你要的結果。

收在兩個習慣

這篇講了框架、走例、修正、邊界、範本，全部收斂之後其實只剩兩個習慣。習慣一，具體地說出哪裡不對：位置、方向、界線，三個元素湊齊就是一條高品質的修正。習慣二，草擬與扣扳機分離：它可以寫完一封信、整理完一份報表、排完一份計畫，寄出、發布、刪除、付款這四個動作永遠由你執行。

官方指南裡有一個比喻適合放在結尾：跟這類工具協作，最好的心態不是把它當一次性助理，而是當一位你會持續調教、讓它越來越懂你的隊友。隊友的價值在累積，第一次合作總是最笨拙的；到第十次合作，你的格式、用語、地雷都已經寫進常駐說明，它不必每次重新學。

給一條具體的練習路線收尾。第一天用會議紀錄範本跑一輪真實任務；第三天挑一個需要界線的任務，合約摘要或資料清理都行，刻意練習界線句；第一週結束時，把重複貼過兩次的背景整理成你自己的常駐說明草稿。三個錨點分別對應這篇的三個主題：開口、修正、邊界。今天下班前，挑六類起手任務裡最貼近你工作的一個，把括號換掉，送出你的第一句話。框架很快就會退場，因為它已經變成你說話的方式。