Prompt to Product：AI 時代開發者的範式轉移

raiven.kao@gmail.com (Raiven Kao) — Sun, 10 Aug 2025 00:00:00 +0000

那些年我們追逐的開發效率

還記得第一次聽到「十倍工程師」這個詞的時候，心中總是充滿憧憬。想像著有一天也能寫出十倍的程式碼、處理十倍的任務、創造十倍的價值。每當看到某個同事在短時間內完成複雜的功能，總是會想：他們是不是真的擁有某種神秘的超能力？

隨著經驗的累積，漸漸發現這更像是一個美麗的神話。真正的效率並不在於敲擊鍵盤的速度，也不在於記住多少語法細節。那些看似神奇的十倍效率，往往來自於對問題本質的深刻理解，以及選擇正確工具的智慧。

直到 ChatGPT 橫空出世，Agentic AI 開始進入我們的開發流程，我開始思考：AI 能為我們帶來什麼？又有什麼是它永遠無法取代的？

從懷疑到接受的心路歷程

最初的抗拒與恐懼

坦白說，剛開始接觸這些 AI 工具時，我的內心是抗拒的。作為一個有著多年開發經驗的工程師，看著這些「會寫程式的機器」，心中五味雜陳。那種感覺就像是突然有人告訴你，你引以為傲的專業技能可能會被一個沒有情感的演算法取代。

第一次使用 AI code assistant 時，我提出一個簡單的需求：「幫我寫一個排序函數」。當它瞬間給出了完整且正確的程式碼時，我的第一反應不是驚喜，而是擔憂。這些工具真的實用嗎？會不會最終取代我們這些工程師？依賴 AI 是否會讓我們的技能退化？

這些疑慮很真實，也很合理。畢竟，我們這個行業向來對「銀彈」保持謹慎態度。太多次，我們看到某個新技術被吹捧為「革命性的」，最終卻發現它只是解決了某個特定問題，而創造了十個新問題。

重新定義效率的數學陷阱

然而，在實際使用 Zed AI、GitHub Copilot Agent 等工具幾個月後，我發現自己的思維框架需要調整。「十倍工程師」的概念確實存在一個隱藏的數學陷阱，而理解這個陷阱是擁抱 AI 輔助開發的第一步。

我開始仔細觀察 AI 在哪些環節能夠提供幫助。當我需要寫一個複雜的正則表達式時，AI 能在幾秒鐘內給出準確的答案，而我可能需要查資料和測試十幾分鐘。當我需要重構一個大型函數時，AI 能夠快速理解程式碼邏輯並提供多種重構方案。當我需要撰寫技術文件時，AI 能夠幫我整理思路，甚至提供不同角度的表達方式。

但同時，我也清楚地感受到 AI 的局限。當系統編譯時，AI 無法讓 CPU 運算得更快。當測試套件在 CI 環境中執行時，AI 無法讓網路延遲消失。當我需要與產品經理討論需求細節時，AI 無法代替我進行那些微妙的人際溝通。當面對複雜的架構選擇時，AI 可以提供選項，但最終的決策仍需要結合業務上下文和長期策略考量。

有一天，一位同事興奮地告訴我：「用了 AI 工具後，我覺得自己的開發速度提升了十倍！」我問他：「你的專案交付時間真的縮短了十倍嗎？」他想了想，搖搖頭說：「沒有，可能只快了兩三倍。」這就是數學陷阱的本質：AI 能夠大幅加速某些特定環節，但整個開發流程的速度受限於最慢的那個環節。

從工具使用者到架構思考者

這種認知的轉變讓我重新審視自己作為開發者的角色定位。AI 的出現並沒有降低我們的價值，反而讓我們從機械性的程式碼編寫中解放出來，有更多時間專注於真正重要的事情：理解業務需求的本質、設計優雅的系統架構、做出明智的技術選型決策。

我開始意識到，真正的「十倍效率」不是來自於打字速度的提升，而是來自於思維方式的轉變。當 AI 幫我們處理了大量重複性工作後，我們有機會成為更好的架構師、更好的問題解決者、更好的技術領導者。

機器可讀設計的哲學革命

經過這段時間的實踐，我得出了一個看似簡單但意義深遠的核心理念：「只有機器可讀的設計，才能被 LLM 加速」。

重新審視我們的設計習慣

這個理念讓我開始重新審視過去的工作習慣。回想一下我們是如何管理專案的：每次設計評審，我們會花費大量時間製作精美的 PowerPoint，其中包含各種流程圖、架構圖、時序圖。這些圖表在投影幕上看起來很專業，但會議結束後，它們就被儲存為 PNG 或 PDF 格式，靜靜地躺在某個共享資料夾中，再也沒有人會去更新或維護。

Never Install Locally？試試 Dev Container

raiven.kao@gmail.com (Raiven Kao) — Sat, 01 Mar 2025 00:00:00 +0000

最近換了新工作，到了一間資訊安全公司，讓我更加重視開發環境的安全。

還記得之前分享過透過 Distrobox 解決 Linux 環境依賴問題，用他來解決不同 Linux distribution 的依賴關係，背後即是讓程式跑在 container 內。

既然能夠將應用程式一來透過 container，與 Host OS 本身做出區隔，那麼我們也能透過 container 來對開發的依賴做出隔離。於是，開始擁抱 Dev Container，一個能讓我更安心、更有效率（？）的開發環境。

什麼是 Dev Container？

簡單來說，Dev Container 就是把開發環境「容器化」。我們可以把所有需要的工具、函式庫、設定檔都放在一個 Docker Image 裡，然後用這個 Image 啟動一個 Container 作為你的開發環境。

Consistency (一致性)：不管是在哪台機器上開發，只要有 Docker，就能保證開發環境完全一致。再也不用擔心「在我這台電腦上可以跑啊！」這種崩潰的狀況發生。
Isolation (隔離性)： Dev Container 與本機系統完全隔離，可以避免各種依賴衝突，也能保護系統安全。
Reproducibility (可重現性)：透過 Dockerfile，你可以完整記錄你的開發環境設定，方便團隊協作和版本控制。

為什麼需要 Dev Container？

身為一個資安從業人員，Dev Container 解決了以下痛點：

不同版本的 Node 環境，告別 nvm！需要 node14, node16, node18 或是 stable 版本，隨時產生開發環境。
需要下載 malware 到本地進行 e2e 測試，透過 container 進行蛤蜊（🦪意象），盡可能避免破壞系統安全性。
在 macOS 上解決一些只支援 linux 的 binary，或是在 arm64 host 上透過 rosetta2 模擬 x86_64 環境，進而執行 amd64 執行檔。
使用 rootless 模式，在危機四伏的 npm 環境中，確保開發環境的安全性。

我的 Dev Container 工作流

我將 dev-container 放在 github omegaatt36/lab/dev-container 中，以下 demo 僅「目前版本」，會依據使用情境進行迭代。

Development_experience on omegaatt