設計書寫作每次都要花好幾小時，沒辦法專心做本來的開發工作……你有過這種經驗嗎？
需求規格書、API 設計書、資料庫設計書、類別設計書——工程師的工作中有大量「必須撰寫的文件」。但實際上，我們常常花在文件撰寫上的時間，跟寫程式碼一樣多，甚至更多。
本文整理了「利用 ChatGPT、Claude 等 AI，將設計書撰寫加速 10 倍的具體 prompt 與步驟」。讀完之後，你會得到「從明天就能立刻使用」的實作方法。
結論：只要改變給 AI 的「傳達方式」，設計書撰寫就會劇烈變快
你是否在為撰寫設計書而苦惱？
- 「知道要寫什麼，但把它寫成文字很麻煩」
- 「每次都從零開始寫很痛苦」
- 「每次被審查指出問題就要重寫」
我認為這些問題的根本，是「在還沒弄清楚怎麼用 AI 的情況下就直接使用」。AI 即便只是「隨便用」也能發揮一定效果，但若能掌握「針對設計書的 prompt 範式」，輸出品質與速度會一口氣改善。
結論：想用 AI 把設計書寫快 10 倍，重點有三件事：
- 明確指定設計書的種類：要準確告訴 AI 這是什麼類型的設計書
- 一併提供背景與限制：一同傳達系統概要與技術棧
- 指定輸出格式：事先指示表格、Markdown、章節架構等輸出形式
為什麼「把事情全部交給 AI」反而產出無法使用的設計書？
你可能以為用 AI 就能瞬間生成設計書，但實際得到的常是「總覺得哪裡不對」或「沒辦法用」的內容。
原因很簡單：AI 沒有足夠的上下文時，只會產出通用且表層的設計書。
例如如果只跟 AI 說「請幫我做 API 設計書」，它並不知道系統是什麼、團隊如何運作、技術棧為何，結果很可能是一本教科書式的通用設計書。反過來說，只要把適切的資訊給 AI，就能在數分鐘內產出可直接在實務上使用的設計書。我自己改用這套方法後，撰寫設計書的時間感覺縮短到不到五分之一。
要點在於：不是去讓 AI 變得更聰明，而是把資訊整理好，讓 AI 能夠聰明地運作。設計書撰寫中，AI 是一個優秀的寫作助理；真正做判斷與設計的主體仍是工程師自己。只要意識到這樣的角色分工，你對 AI 的使用方式就會大為不同。
設計書種類別：AI Prompt 實作集
以下進入重點。針對不同種類的設計書，提供「可直接使用的 prompt 範本」。
① 功能設計書（規格說明）
示範 Prompt：
以下資訊為基礎，請以 Markdown 格式產出功能設計書。
【功能名稱】使用者登入功能
【概要】以電子郵件與密碼進行認證
【系統】Web 應用（React + Node.js + PostgreSQL）
【注意事項】Session 管理、錯誤處理、鎖定機制（密碼錯誤 5 次鎖定）
輸出格式：
- 功能概要
- 流程（帶流程編號的清單）
- 輸入/輸出定義（表格）
- 錯誤案例一覽（表格）
- 注意事項／備註
要點：明確指定「輸出格式」能一次性產出接近審查者期望架構的設計書。
② API 設計書
示範 Prompt：
請根據下列規格，以 Markdown 格式撰寫 REST API 設計書。
【端點】POST /api/v1/users/login
【用途】使用者驗證
【請求】email（string, 必填）、password（string, 必填）
【回應】成功時：JWT 令牌 / 失敗時：錯誤代碼與訊息
【驗證】不需（登入前）
輸出格式：
- 端點資訊（表格）
- 請求規格（表格：參數名／型別／是否必填／說明）
- 回應規格（表格：狀態碼／說明）
- 錯誤一覽（表格）
- 範例請求與回應（JSON 格式）
要點：讓 AI 輸出範例 JSON，可以大幅降低與前端工程師的認知差異。
③ 資料庫設計書（資料表定義書）
示範 Prompt：
請根據下列需求，以 Markdown 格式產出使用者資料表的 DB 設計書。
【系統】電商網站（EC）
【欄位資料】使用者 ID、電子郵件、密碼（雜湊）、姓名、加入日期、最後登入時間、註冊狀態（active/inactive）
【DB】PostgreSQL
【注意事項】考慮刪除處理、時間戳（timestamp）管理
輸出格式：
- 資料表概要
- 欄位定義（表格：欄位名稱／資料型別／是否允許 NULL／預設值／說明）
- 索引定義
- 備註／說明
④ 類別設計書
示範 Prompt：
請依下列需求，以 Markdown 格式撰寫 TypeScript 使用者類別的設計書。
【職責】管理使用者實體
【語言】TypeScript
【主要處理】保存使用者資訊、驗證、密碼雜湊
輸出格式：
- 類別概要
- 屬性列表（表格：名稱／型別／存取修飾子／說明）
- 方法列表（表格：方法名／參數／回傳值／說明）
- 相依性
工程師應該閱讀的書籍推薦
→ 文章閱讀
AI 撰寫設計書時常見的失敗與對策
常見失敗與對策（示例）：
-
失敗：內容太薄、沒用
- 原因：缺乏上下文
- 對策：務必附上系統概要與技術棧
-
失敗：格式雜亂、每次都不一樣
- 原因：未指定輸出格式
- 對策：在模板中明確指定輸出格式
-
失敗：需要多次修正
- 原因：需求描述含糊
- 對策：事前整理好「考量事項」與「限制」
-
失敗：審查被大量退回
- 原因：與團隊的設計書格式不符
- 對策：將既有設計書樣本提供給 AI 以學習格式。把「請依此格式撰寫」交代清楚，通常能直接輸出符合團隊規範的設計書——這個方法特別有效。
將既有設計書提供給 AI，往往是最直接也最有效的方式。
利用 AI 撰寫設計書的整體工作流程
我實際使用的流程如下：
- 將需求先以要點式列出（5–10 分鐘）
- 決定要產出的設計書種類
- 將要點填入範本 prompt（3–5 分鐘）
- 讓 AI 輸出（30 秒–1 分鐘）
- 檢查輸出並補足或修正不足的部分（10–20 分鐘）
- 提出審查
整體約需 30–40 分鐘，即可完成過去可能要半天才能做完的設計書。關鍵在於第 1 步「要點式列出」要做得紮實：你在這步投入越多時間，AI 輸出的準確度就越高。
總結
- 想用 AI 快速撰寫設計書，關鍵是將「設計書種類、背景、輸出格式」這三項資訊一併放入 prompt
- 不要用通用 prompt，而要有「針對設計書種類的專用範本」才能實用化
- 使用 AI 的思維不是「讓 AI 變聰明」，而是「建立能讓 AI 智慧運作的環境」
- 將既有的設計書作為範例交給 AI，能產生符合團隊格式的輸出
很多工程師覺得撰寫設計書「不是本職」，但在團隊開發中，文件品質會直接影響產品品質。善用 AI，朝「減少撰寫時間同時留存高品質設計書」的工程師邁進吧。
推薦書籍介紹
我在下列文章中整理了有助於提升工程師基礎能力的推薦技術書籍。
→ 文章閱讀
原文出處：https://qiita.com/kamome_susume/items/ce71acf0aa0b80631c35
1) --- 會變成分隔線（上一行必須是空白）
2) # 會變成一級標題
3) ## 會變成二級標題
4) ### 會變成三級標題
5) **粗體文字**會顯示粗體文字
6) ```當第一行與最後一行會顯示程式碼
7) 請搜尋 Markdown 語法，了解各種格式
