小編精選 - 技術文章翻譯 · 06月22日

用 Codex 讓商業書籍出版加速到飛起來的實戰訣竅

我至今很幸運地有機會出版了多本商業技術書。
雖然我並不是長年寫作的作者，而是本業做工程師，這兩年半是半帶著興趣、在工作之餘進行執筆。

原本我就很習慣寫 Qiita，手速也算快；尤其是最近半年，Claude Code、Codex 等寫程式 AI Agent 的進化非常驚人，已經能用來大幅加速各種工作。

這次我想聚焦在「商業書籍的出版（特別是 IT 技術書）」上，介紹用 AI 來爆速化的技巧。

這篇文章全都是手打的，請安心閱讀。

基本的考慮方式

大家可能會以為：「咦，要讓 AI 生成書籍正文嗎？」但並不是這樣。

核心概念是：把除寫作之外的周邊工作全部用 AI 半自動化，讓作者能專注寫作、編輯能專注審閱，建立這樣的工作環境。

另外，不限於出版工作，凡是想用 AI Agent 加速非開發類工作的做法，請參考以下文章。

企劃階段

我想很多企劃都是從出版社編輯向作者提出「能不能寫一本關於 xx 的書」這樣的委託開始。

建立資料夾並從語音輸入開始

首先先建立執筆用的 repository，AI 化就是從這裡開始的。
建立一個空資料夾，在 VS Code 裡打開 Codex（或 Claude Code），然後用語音輸入把第一段 prompt 大量灌進去。以下是範例：

SB Creative 的編輯邀請我撰寫一本關於 AWS AgentCore 的書，接下來我會用這個目錄來進行從企劃、撰寫、架構設計，到出版、行銷等所有活動。這會以 GitHub 私人儲存庫的方式推進，之後會視需要加入共同作者或編輯等成員。請先幫我把之後會更好作業所需的 Codex 初始設定、agents.md、skills、rules、sub-agent 等都整理好，把目錄結構調整成未來方便工作的形式。必要時請建立 markdown 檔並整理資訊，讓它更容易使用，並先完成初始化作業。以下是共享的企劃書，請先把原始檔複製整理，並讀取內容後另外整理成 md。/Users/minorun365/Desktop/企劃書.pptx

以上只是範例，實際上我會講大概 5 分鐘，塞進去的上下文會是這個 10 倍左右。

寫程式 AI Agent 只要是像 Codex、Claude Code 這類目前較熱門、較新的工具都可以。
我自己是在執筆過程中，因為 Claude Code 的效能劣化得很嚴重，所以改用 Codex。
如果使用 Claude Code，目前用 Opus 4.6 會比較好一些。
以下就統一以「Codex」來稱呼。

架構討論

如果是體貼的編輯，應該也會幫忙提出目錄草案，但技術書終究還是應由身為該領域專家的作者主導架構討論。
要寫什麼方向的主題、鎖定哪些讀者、章節怎麼安排、是否已有競品書籍、相近主題的書人氣大概如何等等，都可以讓 Codex 進行調查並整理成報告，再一起反覆討論、磨出企劃案。

這裡最重要的是，作者本身要透過語音輸入，把腦中的想法完整倒出來，並把作為骨架的故事線交給 Codex。內容型作品如果交給對該主題缺乏實戰經驗的人再丟給 AI 全權生成，很容易變成「看起來像樣，但內容空洞」的作品。

專案推進

如果和編輯或共同作者開過會，就把會議紀錄讀進 Codex 讓它整理，並一起參與討論。
例如在離線會議中，iPhone 內建錄音 App 錄下來的音檔可以直接轉成文字複製，把它貼到 Slack，讓 Codex 快速整理成 markdown，並在大家持續討論的同時，再讓 Codex 持續優化，這樣也能進行很互動式的會議推進。

工作目錄請同步成 GitHub 私人儲存庫，並一開始就讓編輯和共同作者一起加入。

原稿撰寫

原稿建議用 markdown 撰寫。即使有人前半段是用 Google 文件之類工具寫的，只要交給 Codex，也可以透過 MCP（或 Apps）讀取並漂亮地轉成 GitHub 與 md，搬移也很簡單。

如果在標題層級、撰寫規範等 DTP 上有任何限制，就先寫進 rules 裡。（當然也可以讓 Codex 自己建立）
我自己的做法是，用 iPhone 拍幾頁自己過去作品的頁面，再把圖片讀給 Codex 看，告訴它「請幫我做出能用同樣格式寫作的 rules」。

人類唯一要努力的部分「寫作」

正文撰寫就交給人類努力吧。若是像商業雜誌這樣要求高品質的作品，目前仍然是 100% 手寫最有優勢。
不過，即使先隨手寫得有點潦草，細部修正之後還是可以交給 Codex 依 rules 來處理。

另外，在開始寫之前，先和 Codex 一起反覆討論，把目錄草案、各章內容結構等打磨好，再看著這些內容開始寫，會順很多。

最近，明顯可以看出是 AI 生成的商業書也越來越多了呢。。
為了讓珍貴的日本出版業不要被讀者拋棄，作者還是要認真努力，不能偷懶。

AgentCore 書一開始設想的目錄案中，AgentCore 那一章變得太重，所以我改成四部構成，並大幅調整了標題配置。
這種工作以前非常辛苦，但用了 Codex 就輕鬆多了。

活用 MCP 和 Skills

技術面上，透過 Web Search 或 MCP 持續參照最新文件是理所當然的。
以 AgentCore 為例，有時甚至文件更新都跟不上，文件本身也偶爾有錯誤，所以我會讓 Codex 同時用 CLI 和 GUI console（透過 MCP 操作瀏覽器）自動驗證，交叉確認內容是否有誤。

編輯最感謝的一項功能是頁數預測 skill。它能在原稿非常初期，就依照既有書籍格式相當準確地估算大概會有幾頁，因此在出版前調整定價之類的事情會更容易處理。

插入原稿的圖片草案，也可以先在 PowerPoint 裡加上投影片，再讓 Codex 轉成圖片並插入 markdown。只要成功一次，就可以把整個流程做成 skill 固定下來。

審稿

以前我也是用 Google Docs 寫原稿，並請編輯以編輯建議或留言的形式進行審稿。
如果和 Codex 一起作業，能集中到 GitHub 會更有效率，所以我先讓 Codex 幫忙整理 GitHub 的使用方式，尤其是 Issue 和 PR 的建立流程，再分享給編輯。

各章的審稿內容，粗略的指示放在 Issue 裡，細到語助詞層級的改寫指示則請對方建立 PR。

一邊去便利商店一邊用手機處理審稿

作者回應審稿會變得非常輕鬆。
你可以對 Codex 說：「幫我確認編輯有沒有新的審稿，讀完審稿內容和該章原稿後，請逐一提出修正方案，並清楚說明 Before/After。」

這樣就能用一問一答的形式推進審稿回覆，就算在移動途中，也能透過手機 App 處理。
如果是需要坐在電腦前慢慢重寫的內容，只要說「那部分我之後再做，先幫我記成 To Do」就可以了。

範例程式

技術書通常也會製作大量範例程式與實作教學。
首先會以最新文件為基礎，讓 Codex 撰寫讀者容易理解的最小範例程式，並完成動作驗證。註解粒度、程式撰寫規範等，也會一邊養成 rules，一邊調整成作者喜歡的風格。

尤其實作教學要特別注意，若不固定執行環境與函式庫版本，初學者很容易卡住，所以我通常會使用 GitHub Codespaces，並將函式庫版本固定在校稿前最後一刻的最新版本。

每天晚上讓 Codex 自動測試

版本清單當然也會讓 Codex 整理，再由作者之間共享，並檢查是否有反映到各章。
撰寫期間函式庫每天都在更新，所以我會每天晚上在睡覺時自動跑 Codex，讓它對所有章節的範例程式與實作內容做 E2E 測試，早上醒來就能看到問題報告。

那些不想一再重做的初始設定、或很難重現的 GUI 操作，總有一些部分會想為自動測試稍作調整，這些都可以慢慢養成 Skills。
另外，範例程式會集中整理，並在出版前另外切出一個提供讀者使用的公開 repository。

校對

原稿審查結束後，把 markdown 送交 DTP，之後就會回來所謂的校樣 PDF，也就是依照版面設計排好的紙面 PDF。
編輯和作者會根據這個 PDF 持續加入所謂的「紅字」修正指示，以往多半是用 Acrobat 等 PDF 的註解功能，透過反白等方式寫入修正要求。

校樣 PDF 的紅字也交給 Codex 處理

使用 Codex 時，會維持原稿 markdown 始終更新的運作方式。
編輯仍然照舊會在 PDF 上加紅字，接著讓 Codex 解析這些內容，並把修正指示反映回原稿 md。之後，作者若看到有在意的地方，也全部反映回原稿，最後再讓系統偵測原稿與 PDF 的差異，並把所有差異以紅字註解的形式加回 PDF。
這件事也能透過 Codex 自動化。（會用到 Python 函式庫）

另外，各章的校樣當然也會反覆讓 Codex 檢查，確認是否有和最新資訊不一致、是否有誤植等問題。它能抓出人類幾乎不可能發現的 99% 錯誤。
雖然麻煩，但分章讓它檢查，精度會更高。

順帶一提，在校對階段中，我用 Claude Code 的 /insights 指令分析我的工作風格，結果如下。