這個問題，在各種「科技職涯 QA」裡幾乎每年都會出現一次。
而且不管是在職涯論壇、教學文、還是某個 AI 工具操作影片底下的留言區，你幾乎都會看到這句話：
「PM 要不要學程式？」
如果這是 2015，這篇文章大概會試圖說服你「至少要能看懂程式碼」。
但放到今天，這問題反而有點復古。因為現在的開發環境跟協作方式都改了：
- 不會寫程式的 PM 也能 vibe 出 feature spec
- GPT 可以幫你 mock API、改前端、算 hash
- 工程師之間的抽象語言越來越高階，不懂語法也能對話
但話說回來：這個問題今天依然值得被討論，只是角度該換一下
重點不是會不會寫，而是懂不懂系統
你問一百個 PM 有沒有必要會寫程式，
大多數人都會跟你說類似的話：
「不一定要寫，但要懂邏輯」
「重點是系統理解，不是語法」
聽起來很合理，但也有點模糊
那「系統邏輯」到底是什麼？是 if/else？是 for loop？還是 RESTful API 的結構？
其實都不是
真正該理解的，是「系統架構」而不是程式邏輯
程式邏輯，是 code 裡怎麼跑；
系統架構，是整個產品在高強度情境下怎麼活
舉個例子來說，如果你是個 PM，你做了一個電商網站，正常運作時大家都很開心
但今天辦了一場秒殺活動，立刻爆出這些狀況：
- 有人成功付款但沒下單（→ 超賣）
- 有人卡在結帳畫面半小時（→ 資源爭奪）
- 有人整個網站打不開（→ 前後端撐不住）
這時候你不可能只說：「我們有做完 QA」、「我 spec 沒問題」
你會發現：這不是 feature 的問題，是系統架構撐不撐得住的問題。
系統架構不是平常用來炫的，是在出事時才顯現價值
正常時系統都能跑，沒人會在意你用了什麼架構、怎麼切模組、API 怎麼設計
但高發場景才是系統架構存在的意義：
- 秒殺搶購
- 高併發登入
- 跨境匯率波動導致的價格閃跳
- 多人同步編輯
- 權限變更導致的資源鎖死
你不懂架構，你就無法預測出這些場景會出事
你無法預測，就無法提前設計補償機制
你無法提前設計補償機制，就會在當天被 call 起來背鍋
那不寫程式可以理解系統架構嗎？
理論上可以，你可以：
- 看技術書
- 跟工程師討論 or 參加架構設計會議
- 問 GPT 一輪什麼是 CAP、CDN、rate limit、eventual consistency
但我個人的看法是：
如果你沒把手弄髒過，沒辦法真正理解系統架構
你只有在自己寫過一點東西後，才會對以下東西有真實感：
- 為什麼要加 cache？怎麼清？
- 為什麼這個簡單的操作，在高頻下會爆炸？
- 為什麼你明明有上鎖，Redis 還是會死鎖卡死整個流程？
這最後一個通常最容易發生在「你以為你鎖住就萬無一失」的場景裡。
但等你遇過：
- 多個流程競爭同一個 key，沒處理好 TTL
- 鎖沒釋放，卡住整批交易隊列
- 加鎖加成功，但邏輯出錯直接跳過釋放流程
你就會知道，Redis 本身沒問題，問題在你怎麼設計那段業務流程
這些東西書上會寫、GPT 會講，但你真的遇過、寫過、debug 過，才會知道：
系統設計不是靠對話 vibe 出來的，是靠實作踩出來的
你可以不寫程式，但你不能不了解系統
身為一個 PM，學程式不是為了跟工程師拼邏輯，也不是為了自己造一套產品
而是為了讓你在遇到風暴的時候，知道是哪一塊撐不住
學程式可能是最有效理解系統的方式，但不是唯一
真正重要的是，你能不能在那些高壓場景下，知道風險在哪、限制在哪、瓶頸在哪
因為這時候，懂產品邏輯已經不夠了
你需要的，是系統邏輯