今天想用一個場景，把前三天講的東西串起來。這個場景不是我特別挑出來的，是我這幾天真的在做的事，寫這系列文章本身。與其講一堆抽象原則，不如直接把這幾天實際的流程攤開來看，裡面剛好帶到好幾個我每天都在用的功能，順便連今天寫這篇之前踩到的一個小狀況也一起講。這篇會比前三篇長一點，因為場景要講清楚，牽涉到的功能一個一個拆開來看，內容自然就多了，這也是這系列接下來會常出現的長度。
老實說我自己跟 Claude Code 對話寫出來的初稿，內容通常沒錯，但語氣一聽就是 AI 在講話。句子太工整，每段長度都差不多，轉折詞用得很官方，動不動就「值得一提的是」「總結來說」，結尾還喜歡加一句「歡迎留言分享你的想法」這種邀請式收尾。這種東西直接貼出去，明眼人一秒就看出來不是真人寫的。
我自己第一個用到的功能，是一個專門處理這件事的技能，讀進去的是一整套規則，列出常見的機器人味特徵，空泛的拔高詞、假裝深度的鋪陳、三段式的老套結構、過度工整的列表跟標點、還有那種聽起來很有道理但其實什麼都沒講的收尾句。套用一輪之後，句子才會開始有變化，長短不一，用詞也比較像我自己平常會講的話。
這裡有個細節我自己覺得蠻重要的，去掉機器人味跟套上我自己的語氣，是兩件分開的事，不能一次做完。先把結構上的問題清乾淨，確保沒有新增任何原文沒有的事實或數字，再處理用詞習慣跟語氣節奏。如果兩件事混在一起做，很容易在調語氣的時候，順手就多加了一句聽起來合理但其實是編出來的細節，那就變成造假了，這條線我自己抓得很緊，寧可讓句子平淡一點，也不要為了讀起來更像真人而多塞一個沒發生過的細節。
連這系列用的標點習慣，都是我自己盯出來的細節。AI 寫東西很愛用破折號斷句，一句話裡塞兩三個破折號，讀起來有一種特別工整的節奏感，但那不是我平常講話的樣子，我自己說話比較常是句子講到一半直接換個說法接下去，不會特地用符號斷開。所以這系列從第一篇開始，只要看到破折號一律拿掉，改成拆成兩句話講，這種小地方乍看不重要，但整篇看下來，有沒有破折號，感覺差很多。
舉個例子，原本比較生硬的寫法可能是「這個方法論相當實用，我在使用之後，於一週內完成了原先預估兩週的工作量」，套完規則之後會變成「我之前接到一個需求，正常抓兩週，後來換了個做法，四天就做完了」。差別不是內容變了，是把資訊包裝成人真的會講話的樣子。再舉一個更常見的例子，很多草稿結尾都會出現「這不只是一個工具，更是一種思維方式」這種句型，聽起來很有份量，其實拆開來看什麼都沒講，這種句子我現在看到一律直接刪掉，不會換個說法留著，因為留著就是留一句空話。開頭也一樣有慣性，很多草稿第一句喜歡先鋪一句「隨著人工智慧的快速發展」這種大範圍背景交代，讀者根本不需要這句話才能看懂接下來要講什麼，我現在會直接從真正想講的那句話開始，把這種暖場的句子整段刪掉。
寫這系列的時候，我常常需要去翻自己另外一個資料夾，裡面東西很多，想從裡面挖出真的在用的東西當素材，不是憑空掰一套判斷方式出來。這種時候我自己不會一個個檔案打開看，會直接丟給另一個角色去挖，我自己則專心想接下來要問的問題。
這件事聽起來簡單，但我自己踩過的心得是，交代得不清楚，對方會亂做，你還要花時間重新交代一次，反而更慢。比較差的講法通常是「幫我看一下那個資料夾裡有什麼可以用」，這種講法對方完全不知道要挖什麼、挖到什麼程度算夠、挖回來要用什麼形式給我，結果不是挖太少就是挖太多，兩種都要重做。
我自己現在固定會講清楚三件事。第一是要什麼結果，還有為什麼要，把動機講出來，對方遇到邊界情況才知道怎麼選，只給結果不給動機，它容易挑錯重點。第二是怎樣算做完，這條要講到可以檢查的程度，不能只說「幫我看一下」，要講清楚要拿到幾個候選、每個要附什麼證據、格式長什麼樣子。第三是要它怎麼回報，我會明講不要把整份資料原封不動貼回來，只要結論跟出處，長的東西自己存成檔案，回報只給路徑跟一句摘要。同樣一件事，講清楚這三件跟沒講清楚，出來的結果差很多，我自己現在寫這種交代，花的時間比以前多一點，但省下來的重做時間划算很多。
舉個實際一點的對比，比較差的講法是「幫我查一下這個功能怎麼用」，這種講法沒講清楚查到什麼程度算夠、要不要附來源、查不到怎麼辦，對方只能自己猜。我自己現在會講成類似這樣，「我要查清楚這個功能的用法，因為我接下來要拿它處理一件比較急的事，查到的每個結論都要附出處，查不到就明講查不到，不要用常識腦補一個聽起來合理的答案，最後幫我整理成三到五點，每點附一句可以直接用的說法」。同樣一件事，講法不同，回來的品質差很多，前者常常要來回問兩三輪才問到重點，後者第一次就八九不離十。
不講清楚這三件事，對方要嘛做過頭把整包資料倒回來塞爆我這邊的對話，要嘛做不到位隨便交差。我自己抓的判準很簡單，一件事要翻三個以上的檔案才回答得出來，我就不自己動手，直接外包，這個判準比我想像中好用，因為自己去翻檔案很花腦力，還會把腦子塞滿，留不下空間做真正需要判斷的事。我把自己定位成負責下決定的人，不是負責把資料讀一遍的人，這兩件事分開之後，工作效率差很多。
還有一個我自己很在意的地方，交代它去挖敏感資料夾的時候，一定會先講清楚哪些東西不能公開，客戶資訊、書名、帳密這類的，讓它先篩過一輪，我這邊看到的已經是篩過的版本，不是我自己事後再檢查一遍有沒有洩漏，這樣風險比較低。就算篩過一輪，我自己收到結果的時候還是會再看一眼有沒有漏網之魚，不會因為前面交代過就完全放心，這種涉及公開不公開的判斷，我自己還是會多一道眼睛看過去。
另一件我自己現在很在意的事，是不會每件事都丟給最聰明的模型做。我自己大概分成三層來想。最底層是機械性的事，格式轉換、抓資料、跑一個已經寫好的腳本、單純的關鍵字搜尋，這種事用便宜一點的模型就夠，重點是不要占用我這邊的時間跟資源，聰明不聰明根本不是重點，快跟省才是。中間一層是標準產出，寫一段內容、改一批已經想清楚怎麼改的檔案、跑一輪一般的研究，用中等等級的模型正常仔細做就好，這是我大部分工作實際落在的地方。最上面一層是真正需要判斷的事，架構決策、對抗式審查、當第二意見、決定一件事到底要不要做，這種才丟給最強的那個，這種事才是真正花錢也該花錢的地方。同一件事情，我會先想清楚它屬於哪一層，再決定要用什麼等級處理，而不是每次都憑感覺全部丟給最強的模型，那樣既貴又慢，也沒必要，反而是那種真正需要判斷的事，如果為了省錢用了太便宜的等級，出的問題往往比省下來的錢貴更多。
這裡有個習慣是同一件事如果連錯兩次，我不會再用同樣的講法求它重試第三次，我會換一個更強的模型，或者直接換一種完全不同的做法。反過來，如果只是換了層級但講法沒改，錯的原因可能根本不是模型不夠聰明，是我自己交代得不夠清楚，這種時候換模型也沒用，要先把交代的內容講清楚，用同一個等級再跑一次。方法不對，多試幾次只是把同一道牆撞出更深的凹痕，不會突然通。這聽起來簡單，但我自己也是撞了不少次牆才把它變成習慣，一開始並不覺得這件事有多重要，總覺得再試一次應該就會過。
反過來說，如果某個問題已經被想清楚該怎麼解，我會把解法寫成很明確的步驟，接下來同樣的事就交給便宜的模型批次去做，不用每次都動用最貴的資源想一遍。想清楚怎麼做的過程用最貴的資源，照著做的過程用便宜的資源，這種分工方式，省下來的不是一點點。
還有一個小習慣，如果有好幾件事彼此不相關，不需要前一件的結果才能做下一件，我會一次全部交出去，而不是做完一件再交下一件。以前我會習慣性地一件一件來，後來發現這樣等於把三倍的等待時間都花掉了，其實這幾件事本來就可以同時進行，只是我自己的習慣還停留在一次只能盯一件事。像是今天要準備這篇文章的時候，我需要去外部資料夾挖素材，同時也想確認前幾天的進度狀態對不對，這兩件事互不相干，一個是找內容、一個是查狀態，完全可以同時交出去，不用先等一個做完才開始另一個。這個調整很小，但只要工作裡有好幾條彼此獨立的線，換成一次交出去，整體花的時間差很多。
還有一件事貫穿今天講的所有功能，我自己的判斷方式，盡量都寫成文件，不放在腦子裡。像是要外包一件事該講清楚哪三點、什麼情況該換模型、什麼情況該停下來問，這些東西我都會寫下來，不是每次臨場再想一遍。
這樣做的好處是，就算今天狀態特別不好，或者換了一個完全沒經驗的人來接手，照著寫下來的東西走，產出的品質不會因此掉下去。判斷這件事如果只放在腦子裡，會變成只有我自己在的時候才做得好，別人接手就走樣，寫成文件之後，判斷本身變成可以重複使用的東西，這對一個人要撐起原本一整個團隊的工作量來說，我自己覺得是最關鍵的一步，沒有這一步，前面講的那些功能各自單獨拿出來看都沒問題，但湊不起來變成一套可以每天穩定使用的流程。
外包出去的事，回來的時候我也會要求固定格式，結論講一到三句、有沒有產出檔案、關鍵的地方在哪裡、有沒有需要我自己拍板的地方，四塊缺一不可。以前沒有這個習慣的時候，常常收到的是一大段文字，把整個過程從頭講到尾，我還要自己從裡面撈重點，等於外包出去的事，最後還是要我自己花時間整理一遍，等於沒有真的省到。
現在固定要求這四塊之後，我掃一眼就知道這件事做得怎麼樣，需不需要我自己接手判斷哪個地方。這個格式看起來只是排版問題，其實背後的邏輯是，外包這件事的重點是省下我的時間，如果回報方式讓我還要花時間消化，那外包這個動作本身就白做了一半。這四塊裡我自己最常看的其實是最後一塊，有沒有需要我拍板的地方，沒有就直接收下結果繼續往下走，有的話我就知道這裡不能自己往下推，得先停下來決定，這一塊等於幫我先把「這裡要不要我自己接手」這個問題先篩過一輪。
寫這系列的時候，我自己也常常卡在一個判斷上，這件事要繼續往下做，還是先停下來問清楚。我自己現在抓的標準大概是這樣，如果一個決定做錯了很難收回，或者做這個決定得靠我自己編一個不確定的事實才能繼續，我會停下來問，不會自己先猜一個看起來合理的答案往下走。反過來，如果這件事可逆、風險低，或者已經有明顯的慣例可以照著做，我會自己先決定，做完再說一聲，不用每個小細節都停下來確認，不然對方也會覺得很煩，什麼都要問。
這條標準聽起來簡單，但真的卡住的時候，很容易被「反正先做做看，錯了再改」的念頭說服自己往下走。我自己現在會多問自己一句，如果這步做錯了，代價是我自己重寫一段文字，還是變成一個公開發出去、收不回來的東西。如果是後者，就算只是一個小地方拿不準，我也會先停下來問，這幾天寫這系列的過程裡，好幾次都是靠這條標準才沒有直接把還沒確認的東西當成定論寫出去。
還有一種情況也算在該停下來問的範圍裡，就是需要編一個不確定的細節才能把內容補完整。比如寫到一半發現少一個具體的數字或時間點，順手編一個聽起來合理的補上去，內容看起來會順很多，但那就是編故事了。我自己遇到這種情況，寧可把這段寫得模糊一點，或者直接留白，也不會為了讓文章讀起來更完整而生出一個不存在的細節，這條界線我自己看得比進度重要。
這條之前提過，這裡想講得更具體一點，為什麼一定要換人驗。我自己寫東西的時候，腦子裡會有一整套當下覺得理所當然的假設，檢查的時候很自然會延用同一套假設去看，結果就是看不出問題，因為問題正好長在那套假設的死角裡。這不是不夠細心，是自己寫的東西，自己永遠有一個角度看不到。
我現在的做法是，誰產出的，就換一個完全沒看過整個過程的人或另一個全新的對話去核對，對方沒有那套先入為主的假設，才有機會看出真正的問題。這件事在寫這系列的時候也用得上，每篇定稿前，如果拿不準語氣或內容有沒有問題，我會換一個角度重新檢查一次，而不是自己讀過一遍覺得順就算了。
還有一件事我自己特別提醒自己，換人核對的時候，就算對方講得很篤定，還附了具體的位置或依據，我也不會照單全收，會先確認那個依據真的對得上現在要處理的情況，不是聽起來相關就直接採信。核對這件事本身，也要用同樣的標準再核對一次，不然等於換了個人幫自己背書而已，沒有真正解決問題。
這段是最不起眼的，但我自己覺得很值得提一下。定稿前我會跑幾個很簡單的檢查，數一下這篇字數夠不夠，抓一下裡面有沒有不小心留下不該出現的符號。這種檢查自己盯著螢幕看很容易漏，尤其寫到後面已經看到眼花，但寫成一行指令，幾秒鐘就有答案，準確度比自己肉眼掃高很多。
這種機械檢查有它的極限，我自己很清楚，它只能抓格式對不對，抓不出語意對不對，抓不出這句話講得好不好，抓不出這個論點站不站得住腳。格式檢查過了，不代表內容就沒問題，這兩件事不能混為一談。真正的內容判斷，還是得靠前面那幾道換人核對的關卡，機械檢查只是把最基本、最不用大腦的部分先擋掉，讓後面的判斷可以專心在真正重要的地方。
這種檢查我自己會盡量往前挪，越早跑越好，不要等到整篇都寫完才做。如果字數還差一大截，早點知道就能趁還在寫的時候慢慢補進去，等到寫完才發現差很多，臨時硬塞內容進去，讀起來就會很勉強，跟整篇的節奏對不上。
寫今天這篇之前，我自己有個習慣，接著寫下一篇之前，會先確認前幾天的進度到底是什麼狀態，不會假設一切都照原本想的在走。今天就真的抓到一個落差，本來以為前幾篇的內容已經在某個地方正式記錄下來，實際去確認才發現，那邊留著的其實還是最初的空白範本，真正的內容一直放在另一個暫存的地方，兩邊沒有對上。
這件事讓我多花了一點時間去把狀況搞清楚，才敢繼續往下寫。老實說一開始有點想直接跳過這個檢查，畢竟前幾篇看起來明明都寫得好好的，應該沒問題。後來還是決定先停下來確認一次，因為連續好幾天的東西疊在一起，一旦中間有一天狀態對不上，後面每一天都會建立在錯誤的假設上，越晚發現，要回頭清的東西越多。
確認的方式也很簡單，不是憑印象覺得應該沒事，是直接去看真正的檔案內容長什麼樣子，而不是看那個標記狀態的欄位寫了什麼。標記欄位這種東西很容易對不上實際狀況，可能是因為中途換了做法、也可能是單純沒有同步更新，不管原因是什麼，只要牽涉到接下來還要繼續往上疊的東西，我都會養成習慣，先看真正的內容，不看標籤怎麼寫。這個習慣看起來麻煩，但比起後面發現整個方向建立在錯誤假設上，多花這幾分鐘完全划算。
這件事也呼應了前面講的那條，寫的人不能驗自己寫的東西。我自己以為狀態沒問題，正是因為我自己就是那個一路寫下來的人，帶著自己的假設在看，才會覺得一切正常。真的去對照當下的實際狀態，才發現跟腦子裡想的不一樣。
講了這麼多交出去的部分，也該老實講清楚，哪些事我到現在都還是自己做。這系列每一篇最後定稿要不要發、發出去的內容站不站得住腳，這件事我不會交給任何角色決定，永遠是我自己看過、自己點頭才算數。還有整個系列要往哪個方向走、哪天該講什麼題目，這種偏方向感、偏品味的判斷，我目前也還是自己來，頂多請它列幾個選項給我參考，最後選哪個還是我自己決定。
這幾件事有個共同點，都是沒有客觀對錯、只能靠經驗跟直覺判斷的事。前面講的那些功能，外包研究、分級模型、換人驗證，多少都還有一套可以檢查對不對的標準，這幾件事沒有，錯了也很難用一個檢查表去發現，只能靠自己多年累積的判斷力去接住，這塊我暫時不打算讓出去。也不是說以後永遠不會變，只是現在的我還沒找到一個可以信任的方式，把這種純粹靠直覺的判斷交出去，找到之前，寧可自己多花點時間，也不要交出去之後出了問題還要自己收拾。
Day 3 說過這系列會從小指令講到大工具，今天這篇剛好兩種都用上了。小的那端，像是定稿前跑的那幾個字數跟符號檢查，還有破折號要不要留這種標點習慣，這些都是幾秒鐘就跑完、平常根本不會特別注意到它存在的小動作，但天天用，累積下來省的時間不少。大的那端，像是把整包資料外包給另一個角色去挖、還有那個專門處理語氣的功能，這種要讀進一整套規則、跑起來要花一點時間的，通常是每天固定會用到一兩次，但每次用起來份量都不輕，少了它，前面講的整套流程幾乎轉不起來。
中間那塊，模型分級跟平行處理，比較像是習慣跟心態上的調整，不是單一個功能，而是我自己怎麼安排要用什麼工具、什麼順序做事情，這塊其實才是把小工具跟大工具串起來變成一套流程的關鍵，少了這塊，前面那些功能就只是散落的招式，湊不成一套用得順手的方法。就像今天這篇裡，如果我只會用那個去腔調的功能，卻不知道什麼時候該外包、什麼時候該自己來，寫出來的東西一樣會卡在某個環節動不了，工具本身很好用，但擺錯順序、用錯時機，一樣發揮不出效果，這也是我自己這幾天實際體會到的事。
回頭看今天講的這幾個功能，去腔調、外包研究、分級用模型、平行處理、換人驗證、跑小檢查，再加上今天多抓到的進度對不上，表面上是七件不同的事，但拆開來看，其實都是同一個問題的不同面向，這件事該不該我自己下場做，還有我自己以為對的事，是不是真的對。
草稿的語氣，我自己盯著改比較準，但機械式套規則的部分可以交出去。翻資料這件事，我自己判斷要不要用、要用在哪，但把資料翻出來這件事可以交出去。要用哪個模型，是我自己在分配資源，不是每次都憑感覺。彼此獨立的事情，能一次交出去就不要排隊做。要不要相信一個產出，我自己下最後的判斷，但核對這個動作本身，一定要換人做，連核對的結果都不能照單全收。連定稿前的檢查，我都清楚知道機械檢查能做到哪裡，不能做到哪裡，不會誤以為跑完檢查就等於內容沒問題。今天多學到的一課是，連自己以為理所當然的進度狀態，也值得花時間去對一次，不能因為前面看起來都順利就跳過。
這系列一開始講的那句話，我把自己定位成負責下決定的人，今天這篇算是把這句話拆開來，一項一項給大家看實際上長什麼樣子，也順便老實承認一次，就算是這樣在做，還是會漏東西，只是漏了之後有沒有機制讓自己發現。
老實說這套東西不是沒有代價。一開始要把交代講清楚、把判斷寫成文件，比隨口交代一句話還累，前面幾次甚至覺得寫這些說明的時間，都快追上自己直接動手做的時間了。這種投入要花一陣子才會回本，不是裝上去馬上就變快。我自己會覺得值得，是因為這些東西寫一次可以重複用很多次，第一次比較慢，之後每一次都在吃前面那次的紅利，時間拉長來看才划算，短期看反而會覺得怎麼比自己做還麻煩。如果只打算用一兩次就丟掉，其實不太值得花這個力氣，這套東西比較適合天天在用、會一直重複做的事，偶爾做一次的事，直接自己動手可能還比較快。
寫完今天這篇，我自己重新算了一下，光是今天用到的功能，就橫跨了語氣調整、資料外包、模型分級、平行處理、換人驗證、進度確認這幾個完全不同的層面，全部湊在一起，才撐起一篇看起來只是隨手寫寫的文章。這件事本身也在回答 Day 2 那句話，一個人要撐起原本一整個團隊的流程，具體長什麼樣子，今天這篇就是一個活生生的例子，不是說給大家聽的比喻。
下面講另一個場景，換一個更技術一點的情境，會講到怎麼把一件比較大的工作，拆給好幾個角色分頭去做。
iThome鐵人賽
看影片追技術