System Design
系統設計
共 12 篇相關文章。
Day 23｜我已經能沿著系統思考，卻還不能沿著程式碼追問題
區分系統層級與程式層級的理解，說明能判斷責任與影響範圍，仍不代表能沿著程式碼追出完整實作。
Day 22｜從理解工程概念，到形成自己的判斷
從聽懂工程概念到能在新需求中主動運用，整理如何判斷一個由 AI 解釋的觀念是否逐漸變成自己的判斷。
Day 21｜我幾乎不讀程式碼，那我是怎麼理解系統的？
整理幾乎不直接讀程式碼的情況下，如何透過工作流程、規格、系統分工與追問理解系統，也釐清這不等於能獨立修改。
Day 20｜從「我要這個功能」到「系統必須保證什麼」
以 QA 情境切換為例，把功能需求拆成身分、權限與一致性等不可破壞的條件，並追問誰負責守住這些保證。
Day 19｜把「為什麼這樣決定」也留下來
說明為什麼工程決策不只要記錄結果，也要保留當時的限制、取捨與理由，讓後續修改仍能理解原本判斷。
Day 18｜系統分工之後，怎麼讓不同部分一起工作
整理前端、後端與文件服務拆成多個 repo 後，如何用共同規格與 Coordination repo 維持完整產品脈絡。
Day 17｜從「這個功能怎麼做」開始看懂系統怎麼分工
從一項功能如何拆進前端、後端、文件服務與資料層，說明使用者看到的功能背後其實包含不同性質的系統責任。
Day 16｜以終為始：思考產品功能
以工作終點反推畫面、資料、操作與完成條件，說明如何用「以終為始」設計真正幫人完成工作的產品功能。
Day 14｜我開始能從工作流程看見系統需要做什麼
從工作流程圖往下推導案件階段、狀態與系統需求，說明如何在實作前提早看見系統需要管理的事情。
Day 11｜看到 n8n 時，我以為找到做預約系統的方法了
以 n8n 預約流程為例，說明當需求從自動化轉為狀態管理時，真正需要改變的是問題框架，而不只是工具設定。
Day 9｜系統知道怎麼做，不代表使用者就該這樣做
從把系統步驟直接變成使用者流程的失敗經驗，說明系統怎麼處理與人要怎麼完成工作是兩個不同問題。
Day 5｜做自己的系統，不代表什麼都要自己做
整理 Google Calendar、Sheets、Drive 與 Gmail 等成熟工具如何補上產品能力，也看見工具串接不等於工作流程順暢。