從 BASIC 到 AI 的程式民主化

假設你想做一個自己用的小工具：記帳、整理一份報名表、把每天的運動紀錄加總成一張週報。你用自然語言描述需求，AI 給了你第一版程式，畫面看起來也動了。接下來要學什麼，才能知道它是不是真的照你的意思運作？

動手之後，程式跑出來的結果要怎麼核對，仍然需要學習。關鍵在於學習的重心該放在哪裡：描述需求之後既然已經有了能跑的程式，就可以把注意力轉移到結果上——這份程式產出的成果，和你原本預期的到底是不是同一件事？如果在核對時仍需要理解底層邏輯，也能帶著具體問題回頭補學語法。

動手嘗試本身值得肯定，不需要任何人的資格審查。我的建議是，把「能動手」接到「能核對結果」，用執行結果繼續學習。這個建議對剛開始嘗試的人成立，對已經在工作中用 AI 寫程式的人也一樣成立；差別只在於核對的範圍必須隨著用途擴大而調整。

1964 年 BASIC 與分時系統降低了語法與存取門檻，但學習的關鍵在於能否核對結果

Thomas Kurtz 於 2024 年過世。1964 年，他和 John Kemeny 及學生在達特茅斯學院共同開發 BASIC 語言與達特茅斯分時系統（DTSS），希望讓不打算從事技術工作的學生也能使用電腦。

這兩件事要放在一起看：BASIC 降低語法學習門檻，DTSS 改善電腦存取與互動，讓使用者能即時輸入程式並看到回應。語法與存取是不同的入門條件：學習者需要理解怎麼表達，也需要有機會把表達交給電腦執行。今天的入門者也可以據此反思：自己目前究竟卡在描述需求、理解程式，還是取得並判讀執行結果？簡化其中一個環節，不等於能自動解決其他環節的困難。

動手之後能不能核對執行結果，是這段歷史留給我們更重要的啟示。取得系統回應後，學習者應該比較「我以為會發生什麼」和「實際發生了什麼」，再回頭修正自己的理解。工具能幫你拿到回應，但真正的理解建立在對照預期與結果的過程中。

BASIC 與 AI 的相似之處，在於大幅增加「開始嘗試的機會」：BASIC 與 DTSS 降低了語法和存取門檻，AI 則能把自然語言轉成可執行的程式碼。但嘗試之後能不能知道自己做對了，不取決於工具的名字，而在於你有沒有一個能拿來核對的預期結果。

光看畫面分不出程式對錯：先用手算資料比對輸出，再逐步測試邊界條件

回到開場那個小工具：你要用它把每天的運動紀錄加總成一張週報。AI 給了第一版程式，畫面上也跳出了總數。但這個總數對不對，光看畫面根本看不出來。它可能剛好正確，也可能少算了一天、或是把單位搞混了；只要數字看起來合理，肉眼很難直接抓出破綻。

比較踏實的做法，是先給它一組你自己能手算的資料。比如每天固定輸入同一個數字、加總固定天數，看程式跑出來的結果和手算是否一致。手算能涵蓋的範圍很小，但它能提供一個不可動搖的基準線。確認這一步沒錯，再換一組更接近真實情況的資料：天數不固定、中間缺漏一天、或者混入格式錯誤的數字。

每換一次測試條件，就比對一次結果與預期。當結果不一致時，往往能逼出兩類問題：要嘛是程式邏輯寫錯，要嘛是你一開始沒定義清楚「缺漏的一天該算零還是直接跳過」這類需求細節。

即使還不熟悉語法，也能先從自己能判斷對錯的資料開始，再逐步放寬條件。判斷驗證難度時，我會先看三件事：任務規模多大、結果能不能被獨立核對、算錯了會造成什麼影響。BASIC 或 AI 生成的程式，都該依這三個條件決定檢查力道；驗證的深度取決於任務風險，不取決於工具名稱。

從個人工具走向團隊共用：當成果開始影響他人，必須補齊規格、異常處理與維護責任

同一個運動紀錄小工具，如果只有你自己用，核對標準由你說了算：你知道資料從哪裡來、哪一天該是空白、缺漏該怎麼解讀。但只要你把它分享給朋友，或者放進團隊共用的試算表，情況就徹底變了。使用的人不只你一個，你腦中的默會假設，別人既不知道、也不一定會主動問你。

用途一旦擴大，就必須把隱性假設變成具體規格：工具預期接收什麼輸入、遇到格式錯誤如何處理、算錯了會引發什麼誤判、未來格式異動由誰修改、壞掉時由誰接收通知。這些問題分別對應需求定義、系統設計、驗證與長期維護。只要別人需要依賴這份結果做決策，就不能再用「我自己知道就好」含混帶過。

程式生成完成，不代表需求已經被滿足。畫面能動只是核對的起點；當成果影響到別人，核對範圍就必須同步放大。驗證難度取決於任務本質與出錯代價，無關乎程式是用 BASIC 還是 AI 寫成。兩者都能做出容易驗證的小工具，也都能堆出難以排查的複雜系統。你可以請 AI 協助草擬測試案例或整理邊界條件，但最終仍必須由人來確認：這些檢查有沒有真正涵蓋實際用途與預期結果。

結論：先挑可逆且能獨立核對的小問題起步，用手算資料建立驗證能力

如果你正要開始，我的建議很具體：先挑一個可逆、影響範圍只有自己的小問題。先寫下你要它做什麼、給定什麼輸入該得到什麼結果，再讓 AI 幫你生成第一版。跑起來之後，先別急著擴大題目，務必先用自己能手算的資料核對一次。這個動作是最好的起點，能幫你扎實練好兩件事：怎麼把需求講清楚，以及怎麼判斷輸出是否真的符合預期。

程式民主化帶來了珍貴的參與機會，但真正的能力成長，來自每一次核對執行結果與修正理解的過程——這是 BASIC 與分時系統留給今天入門者最重要的資產。當你準備把小工具交付給別人時，請務必確認需求規格、異常處理與維護責任是否已經補齊。如果你發現產出變快了但交付依然卡住，可以參考AI 生產力悖論是什麼？為什麼 AI 做得更快，事情卻沒有更快交出去？（2026 完整解析）；若想進一步建立嚴密的自動化防線，推薦延伸閱讀〈AI 寫的測試全過，為什麼功能還是錯的？驗證閉環完整懶人包（2026）〉。

延伸閱讀

• AI 生產力悖論是什麼？為什麼 AI 做得更快，事情卻沒有更快交出去？（2026 完整解析）
• AI 寫的測試全過，為什麼功能還是錯的？驗證閉環完整懶人包（2026）
• Plan、Build、Verify、Ship 是什麼？AI 寫程式變快後，進度要怎麼算？（2026 完整懶人包）

參考資料

• Dartmouth Faculty of Arts and Sciences, Remembering Computing Legend Thomas Kurtz
  https://fas.dartmouth.edu/news/2024/11/remembering-computing-legend-thomas-kurtz
• Dartmouth, BASIC Begins at Dartmouth
  https://www.dartmouth.edu/basicfifty/basic.html
• Dartmouth Library, The People Behind the Computer
  https://exhibits.library.dartmouth.edu/s/dtss/page/people