前言
我在 2026 年 5 月 2 日出版了一本單著《Agentic Coding：生成式 AI 時代的系統開發入門》。這本書是寫給那些為生成式 AI × 系統開發的資訊在網路上零散又即興而苦惱的人、那些不知道該從哪裡學習怎麼使用代理的人，以及即使自己沒問題、但找不到能交給團隊成員的書的人。
本文並不是在宣傳那本書……而是想談談我在撰寫過程中如何使用 AI 代理，以及捨棄了什麼。先說結論：我沒辦法立刻寫出來。以下內容是我在演講資料基礎上補充整理而成。
寫了「把開發交給 AI」的書，卻不讓 AI 來寫，這種矛盾
在撰寫期間，作者一直抱著一個兩難。
一本寫著「把系統開發交給 AI 吧」的書，其原稿卻不交給 AI。這種態度不合邏輯。站在讀者角度，大概只會想：「你自己先用啊。」
另一方面，我也有種感覺：讓 LLM 產生的文章充滿 AI 味，根本沒法用。這接近個人的信念，但又不能就這樣直接寫進書裡。
那麼，究竟可以交給 AI 到什麼程度？帶著這個矛盾，我開始摸索那條界線。
到底什麼是 AI 味
海外版的流行語大獎之一，最後頒給了「slop（垃圾內容）」。像「AI slop」這樣使用，指的是量很驚人、但內容很空洞的內容，帶有揶揄意味。
那麼，文章裡所謂的 AI Slop 具體是什麼？我認為大致可以分成三層。
第一層是用詞。像「結構」「支架」「很打到」「有效」「放入」這類高頻詞，以及 em dash（—）都是代表例子。第二層是句法。Markdown 強調、帶冒號的條列（- hogehoge: fugafuga）很常見。
第三層是架構，這是最棘手的。章與節裡過度使用小標題、讓人想知道後續但又故意中斷的結尾（cliffhanger）、對作者的極端表述或傾向過度修正的缺乏偏差，以及 LLM 預測性太高、總會漂亮落在前文可預想的位置，這些都屬於這一層。
用詞和句法看得見，所以還能修。但架構就沒那麼容易了。
去味，到底是為了誰？
這裡必須先停一下。把那股 AI 味去掉，到底是為了誰？
是為了「提升品質」，還是為了「洗白」？當我自問為什麼想消除 AI 味時，腦中同時浮現兩個答案：一個是「為了承擔責任」，另一個是「為了抹去外包的痕跡」。
如果是後者，那對讀者就不誠實了。這條界線，作者到最後都還沒想通。不過，至少我已經確認一件事：它不是「只要去掉就會變成好文章」。
嘗試自動去味，最後放棄
市面上其實有不少用來去味的 Skills。
blader/humanizer 會根據 Wikipedia:Signs of AI writing，從 33 個面向偵測 AI 輸出常見的模式，並修正成較自然的文章。k16shikano/japanese-tech-writing 則是用來生成或潤飾日文技術文件的日文寫作規範 Skill。
撰寫期間，我也試過自己做的 Skill 與 Command，也試過 Linter。也就是 textlint-rule-preset-ai-writing。
結論是：Linter 不能採用。
如果只是機械式地刪掉「AI 文章常見表現」，結果不會變成人味更濃的文章，只會變成帶有另一種偏差的文體。比如漢字使用的統一、以及消滅「もの」「こと」。把反模式機械式修掉之後，文章反而變得單調。
再說，LLM 本來就會以某種對人類可讀、或更精確地說、類似機器翻譯的方式來輸出。也就是說，如果把 AI Slop 的特徵全刪光，反而可能讓違和感增加。就像太在意俚語，反而講話變得彆扭一樣。
改造成「harness」
接著我嘗試的是，把它映射到 user harness 的概念。harness 指的是為了讓代理產生良好輸出，而整備出來的一整套輸入與評估機制。
如果把生成所需的資訊稱為 feedforward，把評估所需的資訊稱為 feedback，那前者相當於「讓它模仿我自己」，後者則是「用 Skills 進行審稿與修正」。
先說 feedforward，很簡單。
請理解並參考 @watany 的公開文章與演講投影片，依其文風與結構進行撰寫Qiita 在內，我公開的資料大約有 200 篇，所以我交給 Claude Code 之類的 Web search tool。至於要怎麼模仿，交給 LLM 自己決定即可。如果擔心 context，理解之後把調查結果輸出成檔案，再 /clear 就好了。
接著作為 feedback，我把審稿用的提示語拆成幾項。
有沒有錯字、別字、標記錯誤、文法錯誤？
請考慮這段＜文章＞＜表現＞的簡化替代方案
請指出與前後章節不一致的地方把這些提示語整理成一個 Skill，我反而覺得很容易漏掉什麼。這是比較憑感覺的說法，請半信半疑。
那結果如何？結果是：文風會變得相似，但不會變成好文章。
這個結果最打擊我。文體模仿是成功了，但重讀時卻不好看。
把技術書文章拆成三層
為什麼看起來像，卻不好？我後來認為，技術書的文章其實在實務上有三層（這只是我的看法）。
第一層是用詞。高頻詞彙，或者不容易用到的詞彙，都屬於這裡。第二層是句子的節奏，包括一句的長度、標點位置、語句的緩急。第三層是文章骨架，也就是要寫什麼、不寫什麼，以及用什麼順序來說。
harness 能模仿到的主要是用詞，節奏只模仿到一部分，至於骨架幾乎沒辦法模仿。
如何面對用詞
先讓 LLM 原樣寫出來。讀過 GPT 5.6 或 Claude Fable 5 的 prompt guide 之後，會發現最佳實務是盡量減少要它遵守的步驟，所以一開始就別綁太多比較好。
想禁止的用詞再透過 review 來檢出。不過，機械式刪除會讓文章也變得機械，所以只指出問題也不失為一種方法。另外，像「找出 AI 味的文章」這種指令其實沒用，太抽象，什麼也不會出來。
如何面對節奏
節奏也是先讓它原樣寫出來，然後大聲朗讀。
默讀也可以，但小聲唸出來更有效。因為如果只是沒出聲地反覆讀，違和感會被磨平。邊讀邊問自己：「我會這樣表達嗎？」「這個敘述流程有不自然嗎？」「用詞合適嗎？」
朗讀不只對 LLM 有效，卡住時也常常很好用。雖然也有改善節奏的 Skill，但目前我打算先不用，因為它雖然能減少 LLM 味，卻還是無法徹底消除違和感。
如何面對骨架
針對骨架，大致有兩種做法。
一種是先傳達概念給 LLM，讓它寫出來，然後我立刻反駁：「這怎麼可能是我的文章！」；在這股反彈下重寫，再讓 LLM 修，然後又反駁：「這怎麼可能是我的文章！」（以下略）。這種方法很耗精神。
另一種是先用手寫草稿、筆記等層級把素材列出來，再讓 LLM 起初稿，之後由人和 LLM 反覆輪流調整順序與增減內容。因為骨架一直握在自己手上，這種方式消耗比較少。
能不能從畫面截圖直接生成文章
這本書有一段是在附圖的實況形式中，介紹代理（Cline）的操作過程，分別是 PART3 的 Vibe Coding（只靠自然語言指示一路做完的開發風格），以及 PART5 到 PART7 的 Agentic Coding（把代理納入開發流程的做法）。
我在這裡試著從截圖生成文章，結果相當嚴格。因為不是每個操作都截圖，所以在缺少中間步驟的部分，它會自行捏造不該有的故事。不過，能像 OCR 一樣把截圖中的文字讀出來，這點還是挺方便的。
讓它寫圖片說明文字，結果算是中上。雖然同樣會捏造不該有的故事，但把說明壓成一行其實不容易，所以即使命中率不高，還是值得一試。
總結
單純大量產生文字，和達到書籍品質之間，還是有一段落差。我沒有找到能補上這段差距的銀彈。
另一方面，LLM 產出的表達有時候確實比較好。這種時候就老實採用吧。雖然很不甘心。
另外，手上若有能用來修正文句的詞彙，就更容易對 LLM 下指令。像是指單字與單字、或其他詞性之間自然搭配關係的「搭配詞（collocation）」，以及用來檢查像「因為……所以……」這類對應表達是否正確組合的「呼應」。這能提高指正的解析度。
而最大的教訓是：與其執著於技巧，不如動手寫，或是更早從 LLM 輸出中知道失敗案例。比起鑽研 prompt 或 Skills，使用像 Opus 4.6 或 Fable 這類寫作能力較強的模型更有效。審稿則要細分成多個 prompt 適時執行，結果則記錄到 issue 等地方。
結論就是：即使有 AI 代理，技術書也沒辦法一下子就寫出來。
回顧
順帶一提，這篇文章是我用蒸餾了我文風的 Skills 讓 Opus5 寫出來，再用蒸餾了我那本書文風的 Skills 透過 Fable 修正的。很有 AI 味，對吧？所謂不能把執筆交給代理，意思就是這樣。
1) --- 會變成分隔線（上一行必須是空白）
2) # 會變成一級標題
3) ## 會變成二級標題
4) ### 會變成三級標題
5) **粗體文字**會顯示粗體文字
6) ```當第一行與最後一行會顯示程式碼
7) 請搜尋 Markdown 語法，了解各種格式
