opencode是典型的AI coding工具，無論是「幫我改 bug」「幫我補一個功能」這類日常開發工作，都是典型的用法。但如果把它看成一個能讀檔案、寫程式、也能呼叫外部工具的 AI 助手，它其實可以拿去做很多事，包括寫書。
過去幾個月，我陸續用 opencode 完成了幾本英文自我成長書籍。它參與的不只是「生成文字」，還包括整理寫作企劃、安排不同模型互相審稿、寫處理內容的小工具，以及最後把 Markdown 轉成 EPUB 上架。這篇文章不打算討論「AI 能不能取代作者」，而是想記錄一件比較實際的事：在這整個流程裡，opencode 到底負責了什麼、哪些工作交給模型比較好、哪些反而應該交給固定的程式碼(當然這個所謂固定程式碼 也是AI生成 只是固定執行而已)。
以下的例子來自完成的5本書。對我來說這5本書最大的收穫，不是產出了5本書，而是讓一套流程慢慢變成可以重複使用的工具鏈。
整體流程大概長這樣
(1) 主題發想 ... 只有這個階段是純人類完成
人類(就是我)必須先想好書的主題跟概觀，模型主要負責生成和評論；程式負責批次執行、保存結果和驗證格式；opencode 則是串起兩邊的那個角色，有時候它自己動手寫文章，有時候它去寫一支工具讓模型去跑，有時候它像編輯一樣讀完一堆審稿意見後，幫我整理重點。
先審企劃，再動筆
每本書一開始我會有個粗略的概念：想談什麼主題、寫給誰看、希望讀者讀完帶走什麼。我(人類)先把這粗糙的計劃撰寫成概念文件，然後讓opencode把這些想法整理成一份詳細的寫作企劃，它不只是章節目錄，更像是這本書的規格文件，哪些概念可以在書裡反覆使用、每一章大致要走什麼結構、遇到敏感主題時哪些話不能講得太武斷，都會先寫清楚。
最省時間的做法不是急著開始寫正文，而是先讓幾個模型讀企劃書挑毛病。opencode 會把企劃分別交給不同家的模型，請它們獨立找問題。像是某個主題定位太接近醫療建議、或是兩個章節其實在講同一件事。這類問題如果等寫完三萬字才發現，修改成本會高很多。軟體工程裡常把「越早發現問題越便宜」叫做 shift left，放到寫書上，就是先審閱企劃，再寫正文。到第三、第四本書的時候，企劃審查已經變成固定的第一關，先修骨架、再寫肉，通常比寫完之後大改划算得多。
逐章生成不是聊天，是一支可以重跑的程式
企劃定案後，opencode 不會只在對話框裡一章一章地跟模型聊，而是先幫我寫一支可以重複執行的小工具。每一章的主題、故事、要教的技巧和大概的字數，都會變成那一章的寫作指令；模型產生內容後，結果就存回書稿裡。這樣做的好處是流程不依賴某一次對話，如果中途斷掉，下次可以接著沒寫完的章節繼續，也留得下每次執行的紀錄。
到後面幾本書，每一章大概都會經過四個來回：第一個模型先寫初稿；第二個模型不急著改字句，而是用幾個預先設定好的讀者視角去讀它，例如只想快速找到方法、沒耐心的年輕讀者，或是特別反感說教口吻的主管；接著再由模型把這些反應整理成具體的修改任務；最後才重寫這一章。這些讀者視角當然不能取代真人試讀，但至少比每次臨時請模型「幫我看看讀者會怎麼想」要穩定一些。
這個過程都是在opencode的commandline(命令列)完成，所以如果有軟體工程背景，在使用AI上有很大的優勢。
許多新聞都提到資工資管資科的前景因為AI而變得晦暗不明，但我倒是覺得如果你是個能善用工具的人，有軟體工程背景在AI時代反而更能發揮。
這套流程裡最特別的地方：讓不同模型互相審稿
如果只看到「用 AI 生成文字」，這件事其實沒什麼特別。這個做法中，最能運用opencode先天優勢的是，我讓opencode角色更像是「多模型審稿流程的設計者和執行者」，而不是自己一個模型從頭寫到尾。
第一，不讓同一個模型同時寫稿又替自己打分。生成模型的任務是把內容寫出來，評論模型專門負責找問題、模擬讀者反應。這不代表換一個模型審查就一定比較客觀，但至少能減少「自己寫完、自己說沒問題」的情況。
第二，同一份稿子、同一個審稿指令，我會分別交給兩三家不同的模型，讓它們獨立作答，而且刻意不讓程式自動把幾份意見合併成一份「平均意見」。（實際做法等一下會說明）實作上就是一支小工具，把同一份稿子分別送給不同家的 API，並把每家的原始回覆各自保存下來。這些腳本背後的共同原則是：先分開保存各家的意見，再由人去比較它們，而不是一開始就把答案混在一起。真正的取捨，是我自己讀完幾份報告之後，判斷哪些是大家都同意的高信心問題、哪些只是單一模型的個人偏好，再決定要不要動手改稿。模型負責提出建議，工具負責整理和保存，最後裁決永遠是我自己做的。
第三，審稿腳本原則上只產生報告，不會直接改動書稿本身。真正要改稿，會是另一個明確標示用途的步驟去執行，而且會記得它是根據哪一輪審稿結果修的。這樣至少能把「模型提出問題」跟「有人採納建議」分成兩個獨立步驟，事後比較容易回頭檢查一段文字是怎麼被改掉的。
從第三本書開始，我還把幾個固定的讀者角色寫成檔案，之後每一輪審稿都用同一批角色去讀稿子。這有點像軟體測試裡固定的測試案例。每次改完稿，都可以用同一套視角再跑一次，確保前後兩輪的反應是可以互相比較的，而不是每次都臨時生一組隨機讀者出來。當然，這些角色終究是模擬出來的，不是真人讀者，它的價值主要在於讓不同版本之間能用同一套問題來比較。
審稿也不是把同一個指令重複跑七次那麼粗暴。第一輪先看結構、內容和語氣有沒有大問題；後面幾輪則只驗證前一輪修過的地方有沒有真的修好，不再重新檢討已經處理過的風格問題。等大問題都處理完，模型也就不再反覆挑戰整本書的風格，而是集中檢查指定的範圍。不然的話，模型永遠能再挑出一點新毛病，永遠改不完。有一本書甚至還多跑了一輪，專門請模型找出可以刪減的段落，再由我決定哪些建議值得採用。
封面和電子書，反而是刻意不讓 AI 立刻執行
第一次做封面的時候，我讓圖片生成模型直接畫「有文字」的完整封面，結果書名拼錯了字。圖片模型很會畫風格、畫氛圍，卻常常把文字畫成看起來很像字但其實是亂碼的東西。後來就改成分兩步做：圖片模型，只負責生成沒有文字的背景，書名和作者名另外用程式排版疊上去，保證每一個字都是對的。
電子書組裝也是同樣的道理。書稿最後會由一支純程式的小工具轉成 EPUB 需要的網頁和目錄結構，再打包成電子書檔案，整個過程完全不呼叫任何模型。EPUB 的檔案格式有規範，但沒那麼嚴格，就像網頁一樣，有點小錯誤乍看之下不會影響，但是任何一個小地方寫錯，就有可能不會通過kindle或讀墨上架平台檢閱，這種需要「絕對正確」的工作，讓程式處理反而比較安心。這幾次做下來，不能把所有事情都塞給模型。需要發想、需要判斷語氣、需要比較不同可能性的工作，模型很好用；但遇到格式、結構這類要求精準的事，還是讓程式來比較可靠。最後一關，程式還會先檢查電子書能不能正常解壓、內部連結是否完整，再把這些檢查結果整理成一份報告交給模型，讓它負責把已經算出來的事實講成人看得懂的話，而不是要它自己去猜檔案對不對。當然，強調一下其實「程式」也是AI寫的，這個程式會一直留著，之後的AI會去執行它，有必要的時候會修正他，但他始終是一個獨立完整的小程式。
opencode中如何讓多個LLM合作
這地方值得特別說明：你打開一個 opencode session、跟它聊天，不管切到 `/models` 選了哪一家，這個 session 本身在同一時間就是被一個模型驅動。它沒辦法自己一邊用 GPT、一邊用 Claude 回你話。所以「多模型互審」這件事，並不是靠我在對話裡不斷切換 opencode 用的模型做到的，而是靠另一層做法：把每一家的API 金鑰放進 `.env`，然後直接請 opencode 讀這個檔案、寫一支小工具去呼叫不同家的 API。
實際做的時候，我對 opencode 下的指令大概會長這樣：「讀一下 `.env`，裡面有 `OPENAI_API_KEY` 跟 `CLAUDE_API_KEY`，幫我寫一段程式，先用 OpenAI 審這份稿子，抓出結構跟語氣上的問題，然後把審稿結果連同原稿一起丟給 Claude，請它照著審稿意見重寫一遍。」opencode 當下自己是哪一個模型在跑不重要，重要的是它會照著指令，去讀金鑰、組出程式、呼叫兩家完全不同的 API，把整個「A 模型審、B 模型改」的來回跑完，再把結果放回書稿裡。從我的角度看，就是坐在同一個 session 裡打字，實際發生的事卻是好幾家 LLM 輪流上場。opencode 在這裡的角色比較像是一個知道去哪裡拿鑰匙、會自己開門的助理，而不是那個真的在審稿或重寫的人。
這個做法唯一要小心的地方，是 `.env` 裡放的是好幾家廠商的真實金鑰，絕對不能跟著程式碼一起進版控。實際操作上我會先確認專案的 `.gitignore` 裡有 `.env`，再讓 opencode 去讀取、使用它。這樣不管後續請它做多少事、寫多少支腳本，金鑰都只留在本機，不會不小心被 commit 上去。
回到「怎麼換模型」這件事本身，其實可以分兩個層次看。如果只是想換掉目前對話裡在用的模型，opencode 本身就有內建的方式：輸入 `/models` 就能挑選要用哪一家、哪一個模型；也可以在設定檔裡指定預設模型，或是替不同的 agent 分配不同的模型。例如負責規劃的 agent 用一個較快、較便宜的模型，負責寫程式或做深度分析的 agent 換成能力更強的模型。這些都是點一點設定就能做到的事，不需要另外寫程式，也是大多數人平常換模型的方式。
我並不是找到了一個很會寫文章的模型，而是我開始把寫書當成一件可以設計的事。模型可以幫忙產生內容，也可以扮演編輯、讀者或審稿人的角色；但流程怎麼拆、哪些結果要留底、哪些建議不能照單全收，終究還是要人來決定。封面文字、電子書結構這類要求精準的工作，交給傳統程式碼處理(當然傳統程式碼也是AI產生)反而更放心。從一本書到下一本書，速度變快的原因從來不是「讓 AI 自己多做一點」，而是把每一種工作交給適合的工具，並且可以根據犯過的錯修正。
AI 時代，有經驗的工程師反而更吃香
這陣子常看到新聞說，AI 讓工程師的工作變得岌岌可危，資工、資管相關科系的前景一片看衰。我自己倒是有不太一樣的體會：如果你本來就有軟體工程的底子，AI 普及之後，你能做到的事情反而變多了，不是變少。
單純打開 ChatGPT 網頁請它幫忙寫書，跟用 opencode 走一遍前面講的這整套流程，表面上都是「叫 AI 寫東西」，實際做起來完全是兩回事。在對話框裡，你每次只能一問一答，模型寫完一段，你得自己複製貼上、自己記得上一輪講到哪、自己去湊下一個 prompt；想要同時比較兩家模型的意見，就得開兩個分頁，自己把結果拼在一起看。這些事情不是做不到，只是每一步都要人親自動手，很難放大規模，也很難重複執行第二次。當然你也可以用openclaw，但他的設定繁瑣也得有工程背景的人才
而工程背景真正值錢的地方，是能把這些零散的步驟，寫成一套會自己讀檔案、自己呼叫好幾家 API、自己把結果存下來、下次還能接著跑的流程。企劃要不要重審一次、審稿意見要不要留底比對、電子書格式對不對，這些原本要靠人一步一步盯著做的事，都可以變成可以重複執行、也可以事後追查的工具。AI 本身很強，但強的模型加上散亂的操作方式，還是只能做出一次性的成果；懂得把 AI 放進一套系統裡的人，才能讓同樣的模型，一次又一次穩定地產出東西。
換句話說，這波 AI 浪潮真正淘汰的，可能不是「會寫程式的人」，而是「只會手動一步步操作、沒辦法把工作系統化的人」。對一個原本就習慣拆解問題、寫腳本、做自動化的工程師來說，AI 比較像是多了一批隨時待命、又便宜又能幹的隊友，而不是搶飯碗的對手。
