Claude Code 負責人 Boris Cherny 最近在 Lenny's Podcast 說：「Coding is largely solved.」
的確，在 AI 生成程式碼的能力爆炸性成長的現在，寫程式這件事越來越不是瓶頸。人人都可以是十倍工程師。
但產出十倍的程式碼，不代表解決了十倍的問題。
AI 能把功能做出來，但它不知道這個功能應不應該存在、範圍要多大、跟其他功能的邊界在哪裡。這些判斷需要對業務、對使用者、對整個系統的理解——這些東西牽扯範圍更廣，沒辦法外包給（現在的）任何模型。
所以，當產能不再是瓶頸，什麼才是？是動手之前把問題跟解法想清楚的能力。對應到工程實務，這就是技術規劃。
這篇文章會拆解技術規劃的思考框架，讓你不管是自己寫、帶人寫、還是帶 AI 寫，都能更穩當地掌握開發方向。
要解決問題之前，得先釐清問題是什麼
成為工程師的前幾年，只要接到新功能開發的任務，就是一股腦的開始寫。
然後，工程師日常：PM「順便加一個小功能」、設計師「我想改成這樣 UX 比較好」、做到一半發現有個情境沒想到，需要多一張資料庫 table、API 接不上、測試的時候才發現權限邏輯有漏洞。完成時間一延再延。
好不容易做完，交出去之後才是惡夢的開始。Bug 一個接一個。每次以為快結束了，又有新的問題。任務就是沒辦法好好完成。
那時候我以為問題是自己寫 code 不夠有效率。後來跟前輩聊，他問我：「你開始寫之前，有先想清楚要怎麼做嗎？」
我愣住了。
我沒有。就只是接到需求就開始寫。而且，說真的，我也不知道該怎麼「先想清楚」。
在一開始用 AI 工具的時候也是一樣的狀況，直接下 prompt 處理想處理的任務，通常給出的效果都不太好。
事實上，我們缺的是足夠的規劃內容。
什麼是技術規劃？
技術規劃這件事，在不同公司、不同方法論中有不同名稱：Technical Specification、Design Doc、技術方案⋯⋯我習慣叫它「技術規劃」。
它發生在「需求明確」之後、「開始實作」之前。當 PM 完成 PRD、使用流程大致確定後，就是技術規劃介入的時機。
它要回答的核心問題是：我們要怎麼實現這些需求？
具體來說，包括：釐清需求的邊界（做什麼、不做什麼）、設計系統架構、定義資料模型、確立模組之間的介面。目的是透過前期的分析與規劃，讓後續的實作變得明確——理想狀態是，規劃完就能直接依據規劃實作，就像蓋房子時按照藍圖施工。
如果你有在用 Claude Code 或 GitHub Copilot 的 plan mode 或是 SDD 相關工具如 spec kit, openspec 等，那你對這件事應該不陌生。這些工具做的事情本質上與技術規劃一樣：分析需求、拆解步驟、決定怎麼改哪些檔案。但這裡有個關鍵——產出的品質，取決於你輸入與審查的品質。如果你自己不知道技術規劃該思考哪些面向，你也很難判斷 AI 的規劃是不是漏了什麼。就像你把一份模糊的需求丟給 junior 工程師，拿回來的東西高機率是有問題的。
所以，理解技術規劃的思考框架，不只是為了自己寫規劃文件，也是為了能夠有效地駕馭 AI 工具——知道該問什麼問題、該檢查什麼面向、該在哪裡補充 AI 看不到的上下文。
什麼時候需要技術規劃？
不是每個任務都需要完整的技術規劃。
判斷標準很簡單：需求能不能直接對應到實作？
如果接到任務，腦中馬上浮現該怎麼做、要改哪些檔案、資料怎麼流動——那可能不需要特別寫文件。Bug 修復、單純的 UI 調整、已有明確模式可循的 CRUD，通常都屬於這類。
但如果任務涉及多個模組、有複雜的狀態轉換或業務邏輯、需要設計新的資料模型、或預估開發時間超過一週——那就需要先停下來想清楚。
RADIO 框架：技術規劃的五個要素
這裡分享自己習慣的技術規劃架構，後來發現跟 The RADIO Framework 非常相似，所以直接用 RADIO 來拆解：
-
R — Requirement：我們到底要做什麼？
-
A — Architecture：系統概觀長什麼樣子？
-
D — Data：資料長什麼樣子？
-
I — Interface：模組之間怎麼溝通？
-
O — Optimization：其他——邊界情況、效能、權限、風險
五個步驟有先後順序。知道需求才有辦法設計架構，有了架構才知道需要哪些資料，資料清楚了才能定義介面，最後才處理其他需要考量的事。
說穿了，就是在系統完成之前，先把資訊的處理流程在腦中走過一遍。這能幫你找出那些「原本不知道自己不知道」的地雷（Unknown Unknowns）——那些在開發中期才冒出來的問題，在規劃階段就能提早發現。
到這裡，你已經掌握了 RADIO 的核心概念。接下來用一個虛構的專案 TaskFlow（一個輕量級的團隊任務管理工具）當範例，走一遍完整的規劃流程，讓你看到每個步驟實際產出的樣子。
R — Requirement：我們到底要做什麼？
第一步要回答的問題是：我們要解決什麼問題？要做到什麼程度？
聽起來很基本，這裡是一切問題的源頭。很多專案的問題不是技術不行，是一開始就沒搞清楚狀況，後面只能 Garbage In, Garbage Out。
需求階段要釐清：這個功能要解決什麼問題？給誰用？時程多長？具體的使用情境是什麼？進而判斷哪些要做、哪些不做。有的人會覺得這不是 PM 的工作嗎？是也不是，因為 PM 的需求不可能 100% 準確，工程端如果沒有好好對齊這塊，就算需求滿足了，仍然很容易產出無法解決問題的實作。
TaskFlow 的例子：
一個輕量級的團隊任務管理工具，讓團隊透過看板追蹤任務進度。MVP 目標是提供基本的任務建立、指派與狀態追蹤功能，預計四週完成。
目標：讓團隊透過看板追蹤任務進度
要做的事情：建立、編輯、刪除任務；任務指派給成員；拖曳變更狀態；設定截止日；截止日到期時發通知。
不做的事情：子任務、多看板切換、標籤分類、檔案附件、行動裝置 App。
使用情境也要寫到具體的流程，不是「使用者可以建立任務」這種抽象描述，而是：
使用者在看板上點擊「新增任務」，輸入標題、描述、截止日，從成員清單選擇負責人，任務建立於「待處理」欄位，被指派者收到通知。
透過目標、使用流程、要做的、不做的，把需求範圍框下來。
A — Architecture：系統長什麼樣子？
需求清楚之後，下一步是決定那些基礎且難以更改的決策：模組怎麼切、資料怎麼流動、主要流程長什麼樣子。
這個階段不用把每個細節都定義好，但要讓所有人對系統的輪廓有共識。
TaskFlow 的架構：
┌─────────────┐ ┌─────────────┐ ┌─────────────┐
│ Frontend │────▶│ Backend │────▶│ Database │
│ (React) │◀────│ (Django) │◀────│ (PostgreSQL)│
└─────────────┘ └──────┬──────┘ └─────────────┘
│
┌──────V──────┐
│ Redis │
└─────────────┘
然後是狀態圖。任務有三個狀態：待處理、進行中、已完成。可以往前推進，也可以往回退。
┌──────────┐ ┌──────────┐ ┌──────────┐
│ 待處理 │───▶│ 進行中 │───▶│ 已完成 │
│ (TODO) │◀───│ (DOING) │ │ (DONE) │
└──────────┘ └──────────┘ └──────────┘
▲ │
└────────────────────────────────┘
（可從已完成退回待處理）
這看起來很簡單，但如果沒事先畫出來，很容易漏掉「已完成可以退回待處理嗎？」這類問題。
前端的元件結構也值得先想過：主頁面是 BoardPageComponent，裡面有三個 ColumnComponent 代表三個狀態欄位，每個欄位裡有多個 TaskCardComponent，點擊卡片會打開 TaskDetailDialogComponent。
架構圖不需要畫得漂亮，邏輯清楚最重要。手繪、白板或 Mermaid 都可以。
D — Data：資料長什麼樣子？
有了架構，接下來要決定資料的型態：需要哪些實體、每個實體有什麼屬性、它們之間的關係。
TaskFlow 的核心實體：
-
Task：id、標題、描述、狀態、負責人、建立者、截止日、排序位置、建立時間、更新時間
-
User：id、信箱、顯示名稱、頭像網址
-
Notification：id、接收者、通知類型（被指派/狀態變更/即將到期）、關聯任務、是否已讀、建立時間
命名很重要。好的命名能幫助團隊建立共同語言——如果統一叫 assignee，全團隊就都用 assignee，不會有人寫 owner、有人寫 responsible_person。
還有一件常被忽略的事：資料的生命週期。Task 刪除時是真的刪掉，還是 soft delete？Notification 要保留多久？這些是資料層面的問題，也有可能會影響到架構層面。
TaskFlow 的決定：Task 用 soft delete，保留 30 天後才真正清理；Notification 直接硬刪除，30 天後批次清理舊資料。
I — Interface：模組之間怎麼溝通？
有了架構與實體，就能定義接合點。這裡的「介面」不只是 API，也包含元件之間的 interface。
API 端點：
TaskFlow 需要：取得任務列表、建立任務、更新任務、刪除任務、變更狀態、取得通知。每個端點要定義清楚 request 和 response 的格式。
建立任務的 request：title（必填，最多 200 字）、description（選填）、assignee_id（選填）、due_date（選填，ISO 8601 格式）。Response 則是完整的 Task 物件。
元件介面：
TaskCardComponent 接收一個 task 作為 input，當狀態改變時 emit statusChange 事件，當被點擊時 emit click 事件。這些 input/output 定義清楚，元件才能獨立開發和測試。
錯誤處理也是介面的一部分：
-
任務不存在 → 404，前端顯示提示並導回列表
-
沒有編輯權限 → 403，前端顯示「權限不足」
-
標題為空 → 400，前端顯示欄位錯誤
這些如果沒有事先約定，前後端整合的時候會出問題。
說到整合——一定要預留時間。TaskFlow 的規劃是前兩週前後端各自開發用 mock 資料，第三週整合，第四週 QA 測試。整合通常比想像中的需要多點時間，很多問題會在完成了整個流程才會發現。
O — Optimization：功能以外的那些事
最後一個步驟是功能以外的事：邊界情況、效能、權限、風險。這些東西可大可小，甚至可能另外變成一個重要任務。但為了維持開發的順暢度，主要目標應該放在先把當前任務的功能完成，這些則是另外需要考量的點。
TaskFlow 的邊界情況：
- 兩個人同時拖曳同一個任務？→ 以最後一次操作為準，樂觀更新加衝突提示
- 任務被刪除了但使用者還開著詳情頁？→ 關閉彈窗，顯示「任務已被刪除」
- 指派對象離開團隊了？→ 任務保留，顯示「已離開」但不自動取消指派
效能目標： 任務列表載入在 500ms 以內（做分頁）；拖曳更新要有即時感（樂觀更新，失敗再 rollback）；通知目前用 30 秒輪詢，未來可以改 WebSocket。
已知風險： 拖曳在行動裝置體驗差，MVP 先標注「建議使用桌面版」；大量通知可能造成效能問題，同任務五分鐘內的變更合併成一則。
有了技術規劃之後
技術規劃完成之後，最重要的是還要找人 review。找有相關經驗的人——feature owner、資深工程師、或做過類似功能的同事。
Review 的好處有很多，消除盲點、知識交流，最重要的是確保大家對「怎麼做」有共識。
這裡要提醒一件事：技術規劃的目的是降低不確定性，不是預測所有細節。實作過程中發現需要調整是正常的。重點是記錄變化的原因，讓下次規劃可以參考。
個人經驗，需求 (R) 一定是一個輸入資訊，而好的需求內容也會產生比較好的架構 (A)，repo 本身架構是否清楚或是有足夠的文件也會影響 plan mode 的正確性。而有了 R 與 A 之後，通常資料 (D) 與介面 (I) 就不用太擔心。
至於 Optimization 則是浮動性比較大，這是因為這裡的項目通常跟主要開發目標沒有直接相關，所以會需要在需求端先給一些評判標準。
給還在摸索的你
如果你已經在用 plan mode / SDD，恭喜，你其實已經在做技術規劃了——只是可能還沒意識到它有結構。
下次看到 AI 規劃產出結果的時候，試著用 RADIO 的五個角度去檢視它：
- Requirement - 它有沒有釐清需求的邊界？做什麼、不做什麼，有沒有寫清楚？還是把所有東西都當作要做？
- Architecture - 它規劃的模組拆分合理嗎？資料流動的方向對嗎？還是只是把功能一股腦塞進現有結構？
- Data - 它有沒有想過資料模型？實體之間的關係、命名、生命週期，有沒有定義？
- Interface - 模組之間的接合點清楚嗎？API 格式、元件的 Input/Output、錯誤處理，有沒有交代？
- Optimization - 邊界情況想了嗎？效能、權限、已知風險，有沒有被提到？
這就是理解技術規劃框架的價值：不是要你每次都寫一份完整的規劃文件，而是讓你有能力判斷—不管是自己的思考還是 AI 的產出—哪裡還有問題。或者換句話說，透過更完整的規劃文件讓你的產出更接近需求。