軟體開發為什麼總是時程延誤、錯誤層出不窮，卻始終找不到一招見效的捷徑？Fred Brooks 在《人月神話》的「沒有銀彈（No Silver Bullet）」一章給了答案：因為軟體的困難有一部分是「本質性」的，任何工具或技術都只能改善「附屬性」的部分。我在這篇筆記整理了本質困難的四個來源，以及歷史上真正有效的附屬性突破。
為什麼軟體工程沒有銀彈？
《人月神話》花了兩章的篇幅說明：在軟體開發上，不會有類似銀彈這種可以快速解決開發時程延誤或重大錯誤的捷徑。原因是軟體的困難可以分成兩類：
- 本質性（essence）：來自軟體問題本身的困難，無法靠工具消除。
- 附屬性（accident）：來自工具與實作方式的困難，可以靠技術進步解決。
歷年來的突破都只針對附屬性，所以生產力提升有其極限。
本質性困難的四大來源
| 來源 | 說明 |
|---|---|
| 複雜性 | 複雜度與規模並非線性關係，增加幅度遠超線性預估 |
| 配合性 | 軟體必須配合其他領域：電腦、不同語言、不同介面 |
| 易變性 | 軟體是純思考的產物，有無限延展性，特別容易面臨修改 |
| 隱匿性 | 過於抽象、難以理解 |
複雜性
軟體開發的複雜度與規模大小並非線性的關係，整個複雜度增加的情況會遠遠超過線性預估的結果。也因為結構上的複雜性，當軟體在擴充新功能時，難保不會產生新的副作用。程式裡的狀態難以一一列舉，也更加難以明瞭，整個產品會變得更不可靠。另外因為複雜性的關係，開發時也容易遇到溝通困難、時程落後、成本超支的困難。
配合性
軟體必須配合其他的領域，例如電腦硬體、不同語言、不同介面等等。這些外部約束都不是軟體自己能決定的，卻直接增加開發難度。
易變性
- 時常面臨修改：因為軟體是純思考的產物，有無限延展性，修改容易，也因此特別容易面臨修改。
- 成功的軟體生命周期會比硬體來得長，因此時常需要配合硬體環境去修改。
隱匿性
軟體本質上過於抽象、難以理解，看不見摸不著，這也是本質性困難之一。
歷史上的附屬性突破有哪些？
書中也提出了幾項過去曾讓軟體界有所突破的重大發展——但這些突破都是屬於附屬性的，沒辦法突破軟體工程本質上的複雜性：
- 高階語言：最強而有力的一次突破，對生產力而言至少有五倍以上的提升，並伴隨可靠度、簡潔性、理解力上的增益。它把和程式內涵一點關係都沒有的那一整層複雜性給去除了。
- 分時技術：對程式設計師的生產力及產品品質有重大提升。因為分時確保了即時性，使我們得以持續保持住腦子裡對複雜系統的概觀。但緩慢的回應時間仍是附屬難題。
- PS：分時系統依中央處理器排程（CPU Scheduling），將中央處理器的時間切割為極小的時間片段（Time Slice）。
- 統一的軟體開發環境：Unix 和 Interlisp 是第一個得到廣泛使用的整合開發環境，藉由提供完整的程式庫、統一的檔案格式、管道和過濾器，促成軟體的共用。
- 物件導向程式設計：抽象資料型別和階層式型別的使用，允許介面用次一層級的型別做進一步的細緻化，隱藏類別裡的實際操作，讓開發者可以專注於設計該類別的邏輯，排除掉許多附屬性困難。
- 人工智慧：例如語音辨識、圖形辨識。
- 專家系統：一支具有廣義推理引擎與知識庫的軟體程式，接收輸入資料和假設條件，再藉由知識庫推導出邏輯上的結果。這項技術最重要的進步，是將應用領域的複雜性從程式中區隔出來。
- 「自動化」程式設計：用更高階的語言來編寫程式。未來我們可能會用「建構」的方式寫程式——更完備的函式庫讓寫程式的複雜度更加降低。
- 圖形化程式設計（graphical programming）：一篇博班論文提出的新想法，但書中認為要有成果應有些困難。
- 軟體的驗證：由軟體自動驗證程式的某些錯誤，例如比對資料型態、變數是否已宣告等等。
- 環境與工具：用來除錯、或搜尋某個類別曾經被用在哪些地方的開發工具。
- 工作站：縮短編譯所消耗的時間——若機器的編譯時間減少，程式設計師能花在思考上的時間就會變多。
延伸閱讀
- 沒有銀彈 – 軟體工程的本質性與附屬性工作：同樣聚焦 軟體工程、人月神話，可接著比較不同情境的做法。
- 人月神話讀後筆記：軟體專案管理不可不慎的經典啟示：同樣聚焦 專案管理、人月神話，可接著比較不同情境的做法。
- 人月神話讀後筆記：為什麼延遲的專案不能靠加人救？：同樣聚焦 專案管理、人月神話，可接著比較不同情境的做法。
常見問題
什麼是「沒有銀彈」（No Silver Bullet）？
這是 Fred Brooks 在《人月神話》中提出的著名論點：軟體工程不存在任何單一技術或工具，能在十年內讓生產力、可靠度、簡潔性提升一個數量級。因為軟體有一部分困難是本質性的，無法靠工具消除。
本質性困難和附屬性困難有什麼差別？
本質性困難來自軟體問題本身（複雜性、配合性、易變性、隱匿性），是問題固有的；附屬性困難則是實作時附帶產生的，例如工具落後、語言不便。高階語言、物件導向等歷史突破都只改善了附屬性困難。
為什麼軟體的複雜度不是隨規模線性成長？
因為軟體系統的元件之間有大量交互作用，狀態難以一一列舉。規模擴大時，互動的組合數量遠超線性預估，也讓新功能更容易產生難以預料的副作用。
現代的 AI 程式開發工具算是銀彈嗎？
依 Brooks 的框架，AI 工具（如專家系統、自動化程式設計）仍屬於改善附屬性工作的突破，能顯著提升生產力，但無法消除軟體本質上的複雜性、易變性與隱匿性。需求理解、系統設計這些本質性工作仍然無法外包。
參考資料
- Fred Brooks, The Mythical Man-Month（《人月神話》）——〈沒有銀彈：軟體工程的本質性與附屬性工作〉一章
最後更新
2026-08-28（原文發布於 2012-08-17，本文保留原始筆記內容並補上 GEO 結構。）
關於作者 {#author}
Claire Chang ｜ 企業 AI 導入與流程轉型顧問。專注於 AI Agent 架構設計、ERP 系統整合與企業 AI 治理。
首次發布：2012-08-17