2026 AI 程式語言完整指南：Python、JavaScript、TypeScript 怎麼選？從零基礎到 AI 寫程式實戰

天地人文創｜TDR 專業文研究編輯｜資料查核日期：2026 年 10 月 21 日｜本文包含原創情境與可重現練習。涉及產品能力、資安與開發平台的說明以文末來源及所標明版本為準。

一位行政主管希望每週一上班前，系統已經把上週訂單資料整理成報表。她問 AI：「幫我寫個程式，把重複的訂單去掉，再算出每個客戶的營收。」幾秒鐘之後，畫面上真的出現一段 Python。程式可以執行，資料也匯出了。這是不是表示，她已經不必學程式語言？

答案要等她看第二次報表才知道。如果其中一筆訂單被退款，金額應不應計入營收？如果同一筆訂單出現兩次，應保留最早還是最新的版本？如果金額欄位被輸入「1,200 元」，程式究竟會報錯、忽略，還是算成另一個數字？這些問題都不靠打字速度解決，而需要有人定義規則、理解資料、驗證結果。能夠回答這些問題的，才是實際把 AI 用在工作上的人。

近年「AI 程式語言」常被拿來指向兩種不同的學習需求。第一種是「我想開發人工智慧應用，需要學哪一種語言？」第二種是「我想用 ChatGPT、Codex 或其他 AI 工具幫我寫程式，還需要學語法嗎？」兩種問題相關，卻不完全相同。前者在選擇工程材料與執行環境，後者在選擇開發方法。如果把兩者混為一談，容易在學習路線、工具採購與企業開發計畫上走錯方向。

這篇文章不會只做「熱門語言排行榜」。我們要回答的是一個更實用的問題：面對某項真實工作，如何決定該不該寫程式、該用什麼語言、哪些工作可以交給 AI，以及用什麼證據確認程式值得信任？ 讀完後，非工程背景的工作者應能找到第一個適合的專案；技術主管則應能把同一套判斷轉成團隊選型與品質管理的依據。

一、先說清楚：AI 程式語言不是一種新的通用語言

程式語言是把指令、資料結構與演算法表達給電腦的形式系統。Python、JavaScript、TypeScript、Java、C++ 都是程式語言；SQL 則是專門查詢與操作關聯式資料的語言。AI 是一個應用領域與技術方法集合；大型語言模型是其中一類模型；ChatGPT 或 GitHub Copilot 等則是以模型為基礎提供功能的產品。這些詞分別指向不同層級，不能互相取代。

想像蓋一間餐廳：程式語言像設備的規格與操作方式，框架或函式庫像可直接採用的廚房模組，AI 模型像一套具有特定能力的服務，而 AI 寫程式工具比較像協助完成設計與施工的助手。你可以請助手提出圖面，甚至讓它完成部分施工，但仍要決定餐廳是否符合需求、有沒有消防風險、誰負責維修。語言選擇也一樣，重點從來不只是「誰最紅」。

本文將「AI 程式語言」區分為三層。第一層是用來建立 AI 系統的語言，包括 Python 資料處理、模型訓練與後端、JavaScript 或 TypeScript 的網頁應用與服務介接。第二層是用來整合已存在的 AI 能力的語言，例如用 Python 呼叫模型 API，把分類結果寫回資料檔；或用 TypeScript 建立客服管理介面。第三層是用自然語言描述需求，讓 AI 輔助產生程式碼的工作方式。第三層是方法而非取代既有語言的新標準，產物最後仍要在某個執行環境中運作。

這個區分也說明了為什麼「不會寫程式也能做出應用」與「不需要任何程式知識」不能畫上等號。前者可能在低風險、需求簡單、有方便預覽與撤銷機制的原型中成立；後者若擴展到金流、權限、客戶資料或營運決策，就缺乏必要的安全邊界。即使 AI 能產生一份看起來合理的答案，軟體的正確性仍由執行結果決定，而不是文字敘述決定。[S15][S20]

二、真實的市場證據：Python 很強，但「最熱門」不是同一件事

討論應該學哪個語言，常會看到互相矛盾的排名。有人說 Python 第一，有人說 JavaScript 才是通用選擇，也有人發現 TypeScript 已經超車。衝突往往來自研究問題不同，而不是其中一份資料必然錯誤。有的數據計算活躍開發者，有的計算程式庫下載量，有的統計求職需求，有的只看標記為 AI 的專案。未先確認分母，就直接把不同排行併排比較，會製造錯誤結論。

GitHub 在《Octoverse 2025》以平台上的貢獻者資料觀察到，TypeScript 在 2025 年 8 月首度超越 Python 與 JavaScript，成為該統計口徑下使用最廣泛的語言；同一份報告仍指出 Python 在 AI 與資料科學專案維持突出地位。兩句話可以同時成立，因為「GitHub 平台整體的貢獻者」與「AI 專案的主要語言」是不同的集合。[S01]

圖 1｜GitHub Octoverse 2025 所揭露的 AI 標記專案主要語言數量。資料為 GitHub 特定分類、期間與口徑，不代表全球所有 AI 工程、職缺或總使用量；原始資料與數字見 [S01]。

同一份 Octoverse 資料中，AI 標記專案以 Python 為主要語言的數量約 582,196 個，JavaScript 約 88,000 個，TypeScript 約 86,000 個。圖上的差距並不表示使用 TypeScript 做 AI 就比較差，更不表示每個人都該轉向 Python。它指出的是，模型訓練、資料處理、實驗流程所需的套件生態，仍明顯集中在 Python；但當 AI 功能嵌入網站、產品與企業內部系統時，Web 技術的重要性不會消失。[S01]

另一個角度來自 Stack Overflow 的《2026 Developer Survey》。在回答相關題目的 17,464 位受訪者中，65.9％ 表示工作使用 AI 程式助理或 Coding Agent，62.5％ 表示使用通用 AI 對話工具。因為這是複選題，不能把兩者相加，也不能說「全球 65.9％ 工程師都使用」。這是特定調查受訪者的行為，而不是全體人口普查。[S02]

圖 2｜天地人原創 AI 協作開發的六道品質關卡，為程序設計建議，而非市場統計。

這兩組資料合在一起，得到一個比語言排名有用的判斷：程式語言決定你能在哪裡動工，AI 助理影響你怎麼動工，驗收能力決定產物能不能留在企業流程中。 學習的終點不應是「能叫 AI 寫出 100 行程式」，而是「能把需求與例外變成可檢驗的成果」。

三、學 AI 程式設計前，先辨認自己要解決哪一種工作

同樣一句「我要學 AI」，背後可能是完全不同的任務。想在 Excel 裡自動清理資料，與想訓練影像辨識模型，兩者都涉及 AI，卻沒有理由使用同一套工具。選錯工具常不是技術不夠進階，而是尚未把成果形式說清楚。

第一類是資料工作。你有 CSV、Excel、庫存、採購或客戶清單，想做清洗、比對、彙總、預測前的資料準備。此時輸入和輸出通常是表格、檔案或資料庫，主要限制來自資料品質、欄位規則與可追溯性。Python 常是適合的起點，因為它能直接處理檔案，也有成熟的資料分析生態；如果資料量大到需要資料庫查詢，SQL 往往必須一起學。這不是因為 Python「最先進」，而是因為這個工作在 Python 生態中通常有現成且容易驗證的工具。[S04][S06]

第二類是工作流程自動化。例如 Google 表單收到資料後，自動在 Sheets 建立紀錄並通知負責人。若公司本來就大量使用 Google Workspace，Google Apps Script 的 JavaScript 執行環境具有直接整合的優勢，不必為了顯得更像 AI 專案而先設一台伺服器。Google 官方文件明確說明 Apps Script 使用現代 JavaScript，並提供對 Gmail、Sheets、Calendar 與 Drive 等服務的整合。[S10] 但這類程式要考慮帳號授權、執行配額、擁有者離職與觸發器失敗，不能因為程式短就把治理省掉。

第三類是網站或互動產品。想讓員工在瀏覽器中查詢 FAQ、讓業務在手機上看儀表板，或者讓客戶上傳資料後取得 AI 摘要，介面品質與存取權限就和模型同樣重要。JavaScript 是瀏覽器互動的重要基礎，而 TypeScript 在 JavaScript 之上提供型別系統，可幫助大型專案較早發現部分資料結構的不一致。開發規模一大，前端與後端的介面契約會越來越重要。[S08][S09]

第四類是AI 模型、資料科學或深度學習。此時需求可能包含模型訓練、特徵工程、評估資料集、運算資源與實驗管理。Python 不只是教學上的慣例。scikit-learn 官方提供機器學習模型、資料前處理、模型選擇與評估工具；PyTorch 官方教學涵蓋資料載入、訓練與模型儲存。這些能力對嚴肅模型工程有實際幫助。不過會使用函式庫，不代表已經理解資料洩漏、訓練與測試切分、過度擬合或偏差，數學與實驗設計不能省略。[S11][S12]

第五類是串接 AI 模型與既有軟體。例如公司已經有 ERP、CRM 或 Java 後端，只想加上文件分類與摘要功能。決策重點未必是重新學一種語言，而是選擇能跟既有系統安全整合的 SDK、API 與架構。OpenAI 官方目前提供 Python、TypeScript／JavaScript、.NET、Java、Go 等開發選項，表示呼叫模型的需求本身不強迫所有企業改用 Python；多代理或工具協作才有進一步評估 Agents SDK 的必要。[S13][S14]

所以，請先把你的需求寫成一句可驗收的句子，而不是一份工具名單。例如「每天下午 5 點，整理前一日已付款訂單，遇到金額不合法的紀錄要另外列出，產生可以人工核對的 CSV」。這句話雖然還不完整，卻已經告訴我們：資料來源是什麼、何時執行、哪些資料被計算、異常如何處理、成果由誰檢查。它比「我要做一個最強 AI 自動化 Agent」有用得多。

四、Python、JavaScript、TypeScript、SQL、R、Java、C++，究竟差在哪裡？

如果要給初學者一個簡短回答，會是「做資料與 AI 實驗，先看 Python；做網站介面，先看 JavaScript，再視專案規模考慮 TypeScript；企業高度依賴 Google Workspace，可考慮 Apps Script；資料儲存在資料庫，就不要忽略 SQL」。但短句只是決策起點，不能直接當成採購結論。以下逐一說明語言的優勢、限制與容易誤選的場景。

Python：資料與 AI 實作的順手工具，但不是所有應用都該重寫成 Python

Python 的主要吸引力不只在語法較簡潔，而是龐大的套件與社群。做資料清洗，可以從內建的 csv、json 開始；處理表格，常見選擇是 pandas；做機器學習，有 scikit-learn；進一步研究神經網路，可接觸 PyTorch。官方教學也將 Python 定位為適合腳本與快速應用開發的語言。[S04] 初學者可以先看懂資料如何被讀進來、轉成結構，再產生結果，不必一開始就理解大型應用的所有框架。

但 Python 並不是免費的通用捷徑。當你要做精細的瀏覽器互動介面，JavaScript 生態通常更自然；當你必須維護既有 Java 或 C# 服務，改用 Python 可能增加部署與人才成本；當大量資料已在資料庫中，直接把所有資料搬到 Python 記憶體中反而可能變慢。好工程不是把每個問題都改造成自己最喜歡的語言，而是在既有環境中減少總維護負擔。

Python 的另一個常被忽略的學習障礙，是套件與環境管理。同一段程式在某人的電腦上執行成功，換一台卻找不到套件，通常不是 AI「理解錯誤」，而是環境版本不一致。Python 官方建議使用虛擬環境，讓專案使用的第三方套件有相對獨立的安裝位置。[S05] 因此，真正的 Python 入門至少應涵蓋變數與資料型別、條件、迴圈、函式、例外處理、檔案讀寫，以及如何安裝與隔離套件；不應只記住幾句提示詞。

JavaScript：瀏覽器世界的核心能力，也是許多職場自動化的橋樑

很多人在問「AI 需要學 JavaScript 嗎」，其實是在問「我想做出別人看得到、用得到的東西，需要學什麼」。若成果是一個網頁、一個表單、一個互動查詢工具，JavaScript 的位置就很清楚。MDN 的官方導覽說明了 JavaScript 的控制流程、函式、物件、非同步處理與模組等基本概念。[S09] 它的價值不是讓你和 Python 比誰更像 AI，而是讓模型產出的結果能被放進使用者真正操作的界面。

值得注意的是，瀏覽器中的 JavaScript 與伺服器端執行環境不是同一件事。瀏覽器程式碼可能被使用者檢視，不能把機密 API 金鑰直接寫在前端檔案中。正式應用通常需要後端、認證機制或安全的代理服務來處理敏感操作。AI 助理可以很快做出按鈕與畫面，但它不會因為畫面漂亮就自動解決身分驗證或授權漏洞。這也是為什麼「做出 Demo」與「可以交給客戶」中間，仍有一段不可省略的工程工作。

TypeScript：當協作與維護成本提高，型別成為溝通工具

TypeScript 並不是跟 JavaScript 完全不同的語言生態。官方手冊指出，它在 JavaScript 基礎上加入型別系統，能提早提示部分可能出現的資料型別問題。[S08] 例如 API 回傳的是金額字串，程式卻把它當數字相加，若資料介面定義清楚，型別檢查有機會較早發現不符合預期的寫法。但型別系統無法保證金額的商業定義正確，也不能驗證遠端 API 在執行時一定符合宣告。因此，TypeScript 有助於縮小某些錯誤範圍，不能替代執行期驗證與測試。

AI 輔助寫程式使這一點更值得注意。當工程師可以在短時間內得到大量程式碼，讀懂每個欄位及函式的成本也會跟著上升。型別、測試與清楚的介面契約，就像把每個協作環節的規格寫在明處，有助於人與工具共同檢查。這是採用 TypeScript 的重要理由，但不是「AI 最喜歡 TypeScript」這類不可查證的擬人化說法。

SQL、R、Java、C++：它們不是輸家，而是處理不同問題的工具

SQL 的強項在資料庫。企業訂單、物流與財務資料若本來就在關聯式資料庫，先透過 SQL 做精準篩選、彙總與關聯，通常比匯出全部資料再讓模型解釋更有治理價值。SQL 的學習重點不是背完所有語法，而是理解資料表關係、主鍵、重複紀錄、NULL 值、聚合以及查詢權限。即使最終由 Python 產出報表，也不能忽略這一層。

R 適合某些統計研究、資料分析與既有研究團隊的工作流程。選 R 不必先問「是否比 Python 流行」，而應看團隊既有程式、特定統計方法、報告再現性與交接需要。對統計研究人員來說，維護多年可信賴的 R 程式可能比全面遷移到 Python 更合理。本文不以未查證的使用率來給 R 排名。

Java、C# 等語言在大型企業資訊系統常有實際位置。若現有系統已完成資安審查、監控、權限與服務部署，加入 AI 能力時應優先研究如何以既有語言安全串接，而不是重新開一個無人維護的新技術棧。OpenAI 官方 SDK 清單包含 Java、.NET 等，就是「AI 服務可以嵌入多種現有開發環境」的具體例子。[S13] C++ 與其他偏低階的技術則可能在高效能運算、推論底層或特殊硬體整合上扮演角色；但大部分想整理行政資料的學習者，不必從這裡起步。

可以用一句話整理：Python 常用來處理與思考資料，JavaScript／TypeScript 常用來建立可互動的軟體介面，SQL 常用來向資料庫提出準確的問題；其他語言應由既有系統與專業需求決定。 這不是世界語言排行榜，而是以工作任務為中心的選型法。

圖 3｜天地人原創語言選型流程。這是一套決策建議，不是經統計驗證的市場排行；實際選型仍應考量既有系統與團隊能力。

五、真正該比較的不是語法長短，而是七個選型條件

語言選擇最容易犯的錯，是把「會不會寫」放在第一位。當 AI 可以產生範例程式碼，語法起手式當然變得比較容易；但程式開發的困難並沒有消失，而是轉移到界面、資料、部署、維護與責任分工。與其把七種語言做成簡化分數表，不如先檢查下列七個影響總成本的條件。

第一個條件是輸入與輸出的形狀。 如果輸入是 CSV、JSON 或大量結構化文字，輸出是清理後檔案，Python 的檔案處理優勢明顯。如果輸入是使用者在瀏覽器的點擊，輸出是畫面即時更新，JavaScript 或 TypeScript 更貼近問題。如果輸入來自關聯式資料庫，先釐清 SQL 層可處理哪些事情。不要因為 AI 會產生 Python，就把資料庫所有責任搬到 Python。

第二個條件是使用者在哪裡操作。 個人筆電上的一次性腳本，與 200 位同仁透過公司帳號登入的內部服務，安全與維運成本完全不同。前者重點是可重現、可檢查、低設定成本；後者還要權限、使用紀錄、部署流程、故障通知、服務可用性與備份。選語言前要知道系統要在哪裡活下去。

第三個條件是依賴誰的資料。 同一份資料可能在 Excel、Google Sheets、ERP、雲端資料庫或第三方 API。資料不能任意搬動，也不是模型產生一段程式就能合法取得。要確認來源擁有者、資料授權、欄位定義、個資與商業敏感等條件。特別是 AI 助理需要讀取檔案才能協助除錯時，必須以測試資料或經批准的最小化資料進行，不應把完整客戶名單直接貼進任意對話。

第四個條件是團隊能否維護。 如果現場只有一位會 Python 的同仁，卻將關鍵流程做成沒有文件、沒有測試的腳本，他一離職就可能失去維修能力。反過來，如果團隊長期使用 TypeScript，為單一 AI 功能增加 Python 服務也許會導入不必要的部署複雜度。工具選擇必須看「現在能做」之外的「六個月後由誰修改」。

第五個條件是失敗代價。 做一個私人旅遊規劃工具，出錯也許只是重新整理；做付款金額計算、薪資匯出、會員權限或合約文件，錯誤後果可能很嚴重。風險越高，就越需要資料驗證、審核紀錄、雙人覆核、回復機制與資訊安全測試。這些工作不是某個語言獨有，不能因為換語言而省去。[S15][S17]

第六個條件是能否取得可重現環境。 個人試作可在瀏覽器或 Notebook 先完成；企業正式程式則應記錄依賴套件、執行版本、必要環境變數與部署條件。Python 官方虛擬環境就是一個基本例子。[S05] 如果連明天能否重跑都不確定，就還不適合把結果連到自動寄信、更新 CRM 或修改正式資料庫。

第七個條件是成果如何證明正確。 這是 AI 協作開發最容易被低估的一點。由 AI 產生的程式看起來完整，不等於符合需求；測試通過一個案例，也不等於所有情境安全。至少要先寫出「正常輸入」、「邊界輸入」、「錯誤輸入」與「不得發生的副作用」，再讓程式接受驗證。稍後的訂單 CSV 範例，會示範如何把這些要求落到實際檔案與測試。

六、零基礎能不能直接用 AI 寫程式？先分清楚「學會要求」與「學會判斷」

很多人的第一個成功經驗，是輸入一句中文，幾分鐘後得到一個能按的按鈕。這種經驗確實重要，因為它讓原本害怕程式的人開始理解：工作中反覆出現的操作，有可能被轉換成具體的流程。問題不在於使用 AI 是否「偷懶」，而在於把哪一種能力視為學習終點。如果終點是生成畫面，學員很容易滿足；如果終點是讓程式正確處理工作，就必須往下走。

AI 寫程式最先替人省下的是「記得每個語法細節」和「快速組出常見的樣板」。這對非工程師很有價值。初學者不必等到把一本語法書背完，才有資格嘗試檔案轉換、互動頁面或日常提醒工具。但人仍然要知道程式讀了什麼、改了什麼、輸出在哪裡、何時會失敗。把這幾個問題講清楚，本身就已經是初步的程式設計能力。

因此，本文主張採用「雙軌學習」。一條軌道是做事，選一個低風險的真實任務，讓 AI 協助產生原型，藉此理解整個工作流程；另一條軌道是補基礎，每遇到程式中看不懂的概念，就回頭學資料型別、函式、條件與例外，並且親手修改。前者維持動機，後者建立掌控感。只學前者，容易形成無法除錯的依賴；只學後者，有些學習者則可能遲遲不知道程式和工作有什麼關係。

以 Python 初學者來說，不需要第一天就學會物件導向設計的全部細節，但一定要能回答「為什麼這筆金額是文字而不是數字」、「為什麼函式應該回傳值而不是直接改整份資料」、「例外發生時程式應該停止還是跳過」。以 JavaScript 初學者來說，應先了解使用者事件、表單資料與非同步請求，而不是先下載一堆框架。如果每一次都先問 AI「請解釋這段函式接受哪些輸入、在哪些條件會報錯」，便能把程式碼變成學習素材，而不是看不懂的黑箱。

把自然語言拿來要求 AI 寫程式，真正重要的不是提示詞變得更長，而是需求足夠可判定。例如「做一個好用的報表工具」就很難驗收，「讀取 orders.csv，只接受 order_id、amount、status 三欄，將金額轉為非負整數，拒絕重複編號並輸出異常原因」就能寫出測試。下指令的品質決定了 AI 有沒有機會知道什麼叫做成功。GitHub 的提示與最佳實務文件同樣重視明確任務、輸入輸出、測試與人工覆核。[S24]

這裡要修正一個常見宣傳誤解：使用 AI 協助開發，不代表不用除錯。 程式即使沒有語法錯誤，也可能在業務規則上完全錯誤。今天算錯一次訂單是一筆資料問題，下週自動把錯誤數字送給 50 個業務就是系統性問題。能看懂錯誤訊息、縮小問題範圍、重現錯誤，仍是使用 AI 時不可或缺的能力。

七、第一次與 AI 協作：不要只說「幫我做」，要先寫規格

想像你請了一位第一次合作的外包工程師。你不會只給他一張便利貼寫「幫公司做一個訂單系統」，就期待隔天直接上線。你會提供需求、資料格式、權限、例外規則、測試條件與交付方式。AI 工具也是同樣邏輯：它可能可以很快執行，但你必須清楚告訴它要執行什麼，還要建立方式確認它沒有越界。

一份對 AI 有用的需求規格，至少包含六個部分。第一是目的，說明業務為何需要這個工具；第二是輸入，列出資料來源、欄位、型態與代表範例；第三是輸出，說明成果檔、使用者操作方式與欄位順序；第四是規則，明訂正常與異常情境；第五是限制，例如不得連正式客戶資料、不得自動寄信、不得安裝未知套件；第六是驗收，包括測試案例與如何復原。把這六個部分整理完，AI 生成的程式才有一個穩定的參考標準。

以下是一段可直接修改使用的示範需求，對象為不含個資的測試訂單清理工具：

請用 Python 標準函式庫完成一個可在本機執行的 orders.csv 清理程式。CSV 僅有 order_id、amount、status 三欄。order_id 是不超過 40 字元的英數字與底線、連字號組合，且必須唯一；amount 必須是不小於 0 的整數；status 僅接受 paid、pending、refunded。合法資料輸出到 clean_orders.csv，不合法的每列輸出到 rejected_orders.csv，包含列號與原因。請保留原始檔，不呼叫外部網路，不讀取其他目錄，不使用第三方套件。先列出假設與測試案例，確認程式的主要函式可獨立測試，再提供執行步驟。最後請指出仍需要人工決策的商業規則，不要自行假設退款如何計入營收。

這段提示詞刻意做了兩件事：一是把資料格式寫成可測的約束，二是留下一個尚未解決的業務問題。「退款要不要算營收」不是程式庫能自行決定的事。即使 AI 主動提出一個看起來合理的做法，也必須由資料擁有者或財務負責人批准，不能把模型建議當成正式會計政策。

要求 AI「先列出假設與測試案例」，也能降低一開始就產生巨大程式檔的風險。你可以先檢查它有沒有處理空值、重複訂單、錯誤狀態、CSV 標頭變更與檔案不存在等問題。若 AI 的假設與實務不符，這時修改規格的成本很低；等它已經建立介面、部署服務、加入排程之後才改，返工就可能連帶影響更多組件。

值得注意的是，規格越完整，並不表示要在一開始設計所有將來的功能。應先選出可以獨立驗收的最小任務。例如第一階段只讀取測試 CSV、辨識錯誤、輸出結果；第二階段才加入統計；第三階段確認資料權限後才接正式來源。這種從可驗證的最小單位開始的方法，適合非工程師，也適合使用 Coding Agent 的團隊。它的核心精神不是慢，而是讓每一步的失敗範圍可控。

八、示範專案：用 Python 做一個可以拒絕錯誤資料的訂單清理器

為避免把文章停在抽象討論，下面以一個可重現的案例走完從需求到驗收的過程。這是作者設計的示意情境與合成測試資料，不是天地人實際客戶案例，也不代表已處理任何企業真實訂單。範例只使用 Python 標準函式庫，不呼叫 AI API、不傳送檔案到外部服務，也不包含任何客戶個人資料。

第一步：先設計測試資料，不要先設計好看的介面

建立 orders.csv，內容如下：

order_id,amount,status
A001,1200,paid
A002,0,pending
A003,350,refunded
A001,1200,paid
A004,minus30,paid
A005,850,paid

第 2 至第 4 列是合法格式，雖然第 4 列是退款，但本階段只進行格式驗證，不計算營收。第 5 列重複使用 A001，第 6 列的金額 minus30 不是整數，因此要放進拒絕清單。最後一列 A005 合法。做完後，預期 clean_orders.csv 有 4 筆資料，rejected_orders.csv 有 2 筆，且原始檔不被修改。這幾個數字來自本文刻意建立的 6 筆樣本，不是任何外部調查統計。

為什麼需要先列出預期結果？因為若只是交代 AI「把資料清乾淨」，它可能自行刪掉退款、忽略零元訂單，或直接在輸出中移除重複列，卻不留下紀錄。表面上看似有完成清理，實際上可能讓稽核人員無法知道哪些資料被排除。對企業來說，異常清單和乾淨資料往往同樣重要，因為未被正確分類的紀錄就是後續報表不確定性的來源。

第二步：把規則寫成容易檢查的函式

範例專案包含 clean_orders.py、test_clean_orders.py 與 sample_orders.csv，下載完整範例與測試 ZIP，檔案位於 examples/ 目錄。程式刻意將單筆資料驗證與檔案輸出分開，讓每條規則可以單獨測試。設計重點不是程式行數最少，而是同仁半年後打開檔案，仍能找到欄位、錯誤原因和輸出路徑。

以下節錄主要驗證觀念：

VALID_STATUS = {"paid", "pending", "refunded"}

def validate_amount(raw: str) -> int:
    if not raw.isascii() or not raw.isdecimal():
        raise ValueError("金額必須是非負整數")
    return int(raw)

真正的範例還會限制金額長度、訂單編號格式、CSV 欄位與重複編號。validate_amount 代表將驗證集中在一個可明確呼叫的地方，而不是讓每個報表欄位各自嘗試轉換。Python 的 csv.DictReader 會依據標頭把每列資料映射為字典，因此我們可以明確檢查必要欄位是否存在。[S06] 這種設計也方便將來把「拒絕過長金額」或「只允許特定狀態」等新規則加入，而不必搜尋整個程式找出所有轉換位置。

第三步：將結果分成「通過」與「拒絕」，保留可追溯性

一個經常被忽略的設計決策是：遇到壞資料該直接停止，還是繼續處理其他列？沒有單一答案。在財務匯款或正式批次寫入交易系統時，遇到異常可能應中止整批；在用測試資料做初步清洗時，保留拒絕列並讓其餘資料繼續處理可能比較實用。本文示範後者，但在導入真實營運時必須重新評估是否適合。

程式會同時產生兩份輸出，並在終端機列出讀取列數、通過列數與拒絕列數。拒絕清單保留原始欄位與列號，再加入理由。這樣使用者可以逐筆回到原始檔核對，而不會只得到「有兩筆資料出錯」這種無法處理的提示。若採用排程自動執行，下一步還需要增加執行時間、檔案雜湊、處理版本與失敗通知；這些不在入門版的操作範圍內。

第四步：預先處理 CSV 公式注入與極端輸入

看似單純的 CSV，也可能成為安全風險。若某個欄位可以任意輸入以 = 等符號開頭的內容，當檔案被試算表程式打開時，可能被當作公式。本文不需要開發一套完整的試算表安全產品，但可以透過限制訂單編號只允許英數字、底線與連字號，排除不符合欄位定義的符號。這項限制是本文示範的安全設計選擇，並不表示所有 CSV 注入風險都已消除。若未來增加自由文字欄位，必須重新評估匯出、開啟程式及公式防護。

另一個邊界是過長輸入。使用 int() 轉換任意長度的字串、讀取巨大檔案或接受含特殊格式的欄位，都可能產生非預期的錯誤或資源負擔。入門程式可以設定合理的欄位長度與檔案大小上限，在超出時明確拒絕，而不是讓程式無限制執行。輸入長度的上限應由業務資料規則決定，不宜為了「兼容所有狀況」而完全放棄約束。

第五步：先在本機用合成資料驗證，不要立刻連到正式帳號

把程式放進獨立資料夾，只用本文附的 sample_orders.csv 執行。因為不使用第三方套件，確認本機 Python 執行器即可，無須先建立 API Key。正式專案若使用第三方套件，仍應建立 .venv 並保存相依資訊，避免和其他專案互相干擾。[S05] 成功執行後，打開輸出檔並手工核對前述六筆資料；再故意修改一筆金額為空值、一筆狀態為 completed、一筆訂單編號為不合規字元，看拒絕原因是否符合規格。

這整個練習最重要的成果不是寫出一個「AI」按鈕，而是建立能被其他同仁檢查的產物。當讀者真正做到這一步，便會發現 Python 是表達規則的工具，AI 是協助產生或解釋程式的工作夥伴，而業務定義與驗收責任仍然屬於人。這個結論，才是學習 AI 程式語言真正要帶走的能力。

九、會跑的程式不等於對的程式：測試是 AI Coding 最值得先學的一課

假設 AI 把上述訂單清理器完成得很漂亮，你執行後畫面也顯示成功。現在有人把 A001 的第二筆金額改成 1,500，應該以哪一筆為準？如果沒有業務規則，任何選擇都可能錯。AI 可以協助產生多種處理方案，但不可能透過語法得知公司內部究竟使用最後更新、人工指定、還是整批拒絕。程式輸出「看起來合理」只是一種印象，測試才提供受控的證據。

測試第一層是函式層級的單元測試。例如「輸入 1200 應得到整數 1200」、「輸入 -5 應被拒絕」、「輸入 A001 的第二筆訂單應被標記重複」。這類測試針對小範圍規則，因此錯誤容易定位。Python 的標準函式庫提供 unittest，可撰寫獨立測試案例並以斷言確認結果。[S07] 團隊不一定要一開始就導入複雜的測試平台，但應讓每一個關鍵規則有至少一個正例與一個反例。

第二層是資料流程測試。把 6 筆事先標註答案的資料交給程式，檢查清理檔是否有 4 筆、拒絕檔是否有 2 筆、列號是否正確、輸出欄位是否一致。這能驗證讀取、驗證、寫出幾個步驟共同運作。第三層是人工覆核，例如用試算表開啟檔案，檢查前導零、中文編碼、日期格式及檔名是否符合工作交接需要。自動測試能降低錯誤，但不能直接取代對資料語義與業務結果的審查。

第三個常被忽略的問題是：測試自己也可能寫錯。若 AI 同時產生程式和測試，而且兩者都採用同一個錯誤假設，測試可能全部通過，業務結果卻仍錯誤。例如 AI 誤把退款直接算成正向營收，又依這個規則產生「預期 350 元」，程式與測試就可能互相證明錯誤。因此，至少在關鍵案例上，應由需求負責人事先寫下正確答案，再讓 AI 協助把答案轉成程式測試。

把錯誤處理變成可讀的結果，也是測試的一部分。只印出 ValueError，對非工程師幫助有限；記錄「第 6 列，金額 minus30 不是非負整數」，才能讓行政或財務同仁知道如何回到原始檔修正。良好的工具不只是成功時快，還要在失敗時清楚說明原因。若程序涉及客戶個資，錯誤訊息也不應任意把敏感欄位全文寫進日誌，必須在可查核與最小化揭露之間取得平衡。

GitHub 對 Copilot 的官方最佳實務同樣提醒，應理解 AI 提出的程式碼、審查功能與安全性，並利用自動化測試與掃描工具補充檢查。[S15] 這不是某家工具的缺點，而是任何以生成結果協助工程決策的工具都必須面對的基本限制。當程式的錯誤成本提高，人類覆核、測試設計與運行監控的重要性只會更高。

十、ChatGPT、Coding Assistant、Coding Agent 與 Vibe Coding，角色不能混在一起

使用者常把所有能「幫忙寫程式」的 AI 工具放進同一類，但實際的控制範圍差異很大。一般對話式 AI 可以根據貼上的錯誤訊息給建議、解釋程式概念或產生片段；整合在程式編輯器中的程式助理可在既有檔案與部分程式上下文中提供補全或修改；具工具執行能力的 Coding Agent 則可能讀取專案、修改多個檔案、執行測試，甚至在授權範圍內使用終端機。這些能力改變的是「AI 可以接觸與操作什麼」，也直接改變風險。

如果只是學習 for 迴圈，用一般對話式 AI 解釋並提出練習題就很合適；如果你正在處理數十個檔案的網站程式，整合式助理或代理工具可能更有效率；如果專案需要呼叫外部 API、部署服務與操作正式資料，則必須在權限設定上更保守。工具的價值取決於所授權的環境與任務，而不是它能不能自稱自主執行。

「Vibe Coding」通常用來描述以自然語言與反覆試作驅動開發的方式。它降低了產生原型的門檻，也容易讓非工程背景者快速建立信心。問題在於，原型一旦被拿來承擔正式營運工作，原先可以接受的試錯方式就需要改變。畫面不對可以重新描述，訂單金額不對則不能只靠反覆請 AI「再修一次」而不留下證據。這是從個人實驗走向可交付工程的分界。

我們可以用三個問題判斷該讓 AI 走多遠。它會接觸什麼資料？它能修改什麼東西？失敗後誰能撤銷？ 如果只是讀取合成 CSV 並輸出暫存結果，適度放手通常有助於學習。如果它能直接更改正式訂單、刪除雲端資料或寄送客戶郵件，就應縮小權限、加入人工核准與交易紀錄。能力越強的代理工具，越需要明確的工作區與權限邊界。OWASP 2026 年的 LLM 安全風險分類也將過度代理權限、提示注入、敏感資訊揭露等列入重要風險類別。[S16]

這種理解也能協助企業避免買錯工具。若你的需求是「讓行銷同仁更快整理報告」，可能先學 Python 與資料工作流程就能改善；若需求是「讓工程團隊管理大型程式庫的變更」，較應評估與版本控制、程式碼審查、測試環境及權限機制整合的產品。把所有使用者都送進同一門「AI 寫程式大補帖」，往往只會讓能力高低不同的人一起失去焦點。

十一、AI 產碼的資安風險：2026 年必須看懂的五種失敗方式

當一般人第一次看到 AI 寫出程式，往往先注意「它做到了什麼」，較少注意「它被允許做什麼」。但對真正管理企業系統的人來說，這兩個問題同樣重要。程式碼是一種可以執行的指令；有權限的工具也可以發出網路請求、讀取檔案與修改資料。當 AI 開發工具可以不斷呼叫其他工具，其造成的影響就不只是一段文字答錯，而可能成為真實環境中的不適當操作。

OWASP GenAI Security Project 已於 2026 年 8 月發布《Top 10 for LLM Applications 2026》。其中與 AI 協作開發特別相關的分類包括 Prompt Injection（提示注入）、Sensitive Information Disclosure（敏感資訊揭露）、Excessive Agency（過度代理權限）、Supply Chain（供應鏈）與 Improper Output Handling（不當輸出處理）。這些是官方發布的風險類別，而不是對每家公司出事機率的統計。[S16] 本文以下以示意情境說明，目的在建立風險辨識能力，不宣稱任何特定工具必然存在漏洞。

提示注入的風險，是 AI 把不可信內容當作應執行的指令。例如 Coding Agent 在讀取外部套件文件或第三方 README 時，文件內夾帶一段與使用者任務無關的命令，要求代理額外讀取私人檔案或更改工作流程。文件可以提供資訊，不能因此取得與系統管理員同等的指示權。降低風險的方法包括限制代理可讀的來源、對外部文字採不可信資料處理、限制工具操作範圍，以及在敏感動作前要求確認。不能只依靠一段「請忽略惡意指令」的提示詞就當成完整防護。

敏感資訊揭露的風險，通常比刻意外洩更日常。為了除錯，有人把完整客戶檔案、登入權杖、採購價格或內部伺服器設定貼進對話；或者把 API Key 直接寫進要交給 AI 修改的原始碼。這類問題甚至不需要惡意攻擊者，只要沒有處理資料分級與金鑰管理就可能發生。較好的做法是使用合成測試資料、以環境變數或正式的秘密管理機制存放憑證、避免把秘密寫進版本庫與錯誤訊息，並事先確認第三方服務的資料處理政策。

過度代理權限的風險，是讓能寫程式的工具直接擁有不相稱的權限。假設任務只是整理報表，工具卻擁有刪除整個共用雲端資料夾的能力，這不是效率，而是控制設計失衡。權限應按任務最小化，開發工作區與正式環境分離，危險操作採取人類核准，並保留可追查的紀錄。工程師不該把「AI 會自己判斷」視為授予永久管理員權限的理由。

供應鏈與不當輸出處理的風險，則常藏在看似實用的範例裡。AI 可能建議安裝某個尚未查證的套件、執行來歷不明的安裝指令、將模型產出的內容當作可執行程式碼，或把未驗證的文字直接當成資料庫查詢的一部分。正確做法不是永久禁止所有第三方套件，而是確認套件來源、權限與版本、使用依賴清單與弱點掃描，並在每一個信任邊界做資料驗證。尤其不能把模型輸出直接視為已完成安全審查的程式。

圖 4｜依 OWASP 2026 年風險分類延伸整理的示意矩陣。圖中防護是編輯建議，不代表實施後能消除所有風險；分類原始來源見 [S16]。

還有一項容易被忽視的風險：業務正確性。若 AI 寫出的排程程式誤認假日規則，可能造成通知漏寄；若日期格式處理錯誤，可能使同一筆資料重複計算。這些錯誤不一定落入典型資安漏洞分類，卻會直接傷害企業對自動化的信任。因此，安全必須包含機密性、完整性、可用性與業務結果可驗證，而不只是「有沒有被駭客入侵」。

十二、企業導入 AI Coding：真正需要管理的是工作流，不是員工用了哪個工具

假設某家公司宣布「每個部門都要會 AI 寫程式」。這句話看似積極，但實際上缺少對成果的定義。人資部門可能只需要自動匯整問卷；財務部門可能需要合規的報表流程；資訊部門需要的是可審查的程式碼與部署治理。如果用同一套工具、同一套課程、同一個 KPI 衡量，很可能讓培訓變成成果不明的活動。

Stack Overflow 的 2026 年調查提供了一個觀察角度：在回答組織採用方式題目的 13,167 位受訪者中，24.0％ 表示其組織提供核准的 AI 工具與使用指引，29.7％ 表示 AI 使用主要交由個人自行決定。這反映受訪者經驗中的管理落差，但不應推論為台灣所有企業的實際比例。[S23] 更重要的是，它提醒決策者：員工已經在使用工具，不表示組織已經建立共同的驗收與權限規則。

企業要讓 AI Coding 真正產生價值，第一步不是決定全部採用 Python 或 TypeScript，而是整理工作候選清單。每個候選任務應記錄目前流程、資料來源、執行頻率、容易出錯的地方、預期輸出與負責人。接著按資料敏感程度、規則清晰程度、失敗代價與可否人工覆核分級。那些輸入明確、容易測試、可以在不碰正式資料的情況下示範的工作，通常較適合第一批實驗。

第二步是建立可運作但不越權的沙盒。對試驗中的 Python 腳本，只允許處理合成資料與非正式檔案；對 JavaScript 網頁，只使用測試帳號與虛構內容；對 Google Apps Script，先在測試試算表與指定帳號中運作，不要讓學員以個人帳號長期持有關鍵流程的唯一擁有權。對 Coding Agent，則在工作區、外部連線、套件安裝與終端機命令上設定邊界。這種環境控制，比事後要求「小心使用」更具體。

第三步是規定交付必有證據。每一個被保留的程式至少應有需求摘要、輸入輸出規格、正常與異常測試、執行說明、版本與負責人。若涉及正式資料，還應增加存取權限、日誌、回復策略與資安審查。NIST 的 Secure Software Development Framework（SSDF）提供將安全活動納入軟體生命週期的共同語彙。截至本篇資料查核日，SP 800-218 1.1 是已發布的正式版本，1.2 為公開草案，不能誤稱草案已正式生效；它也不是一項自動適用於台灣所有公司的法律義務。[S17][S22]

第四步是設定擴大使用的門檻。不是「原型好像可用」就交給所有人，而是先確認業務規則獲得負責人簽核，測試能被其他同仁重跑，權限已審查，故障有通知方式，且有指定的維護者。再逐步擴充使用人數與資料範圍，過程中保留問題記錄。如果新增需求使系統高度複雜，就應重新評估是否需要資訊部門接手、使用既有企業軟體或採購正式產品。

這樣規劃還有一個好處：企業可以把培訓內容和可用成果連起來。學員不只是完成課程問卷，而是拿到一份已定義、已測試、可交接的工具。主管也能根據「測試通過比例、可重現程度、例外處理、擁有者是否清楚」來檢查，而不是以「生成了多少行程式碼」當作績效。

十三、成本怎麼算？AI 寫程式降低的是某些工時，不是所有軟體成本

假如一套工具能在幾分鐘內生成 1,000 行程式，是否意味開發成本就趨近於零？這是企業在評估 AI Coding 時容易出現的錯覺。產生程式碼只是開發總流程的一部分；需求溝通、資料整理、測試、部署、權限、維護與例外處理仍然要付出成本。有時候，快速產生不必要的複雜性，甚至會提高後續維修負擔。

可以把總成本想成幾個項目：總成本＝需求與資料準備＋開發與模型使用＋測試與修正＋部署與管理＋後續維護＋失敗或錯誤處理。這不是會計準則或市場平均公式，而是供企業估算的管理架構。使用 AI 後，「開發」可能下降，但如果沒有規格與測試，「修正」和「錯誤處理」也可能上升。因此，不能只比較工具訂閱費，忽略人員時間與企業風險。

例如某部門想做每日報表。方案 A 是沿用 Google Sheets，用 Apps Script 設定少量邏輯；方案 B 是用 Python 排程，把輸出寫入指定儲存位置；方案 C 是建立完整網頁管理平台。哪一個划算，取決於使用者數量、權限要求、原始資料來源、是否需要即時操作與既有維護能力。若只有一位同仁每天查看一次 CSV，方案 C 可能是過度設計；若跨部門需要權限、稽核與版本，方案 A 的個人帳號腳本也可能逐漸不適合。

在正式估算前，建議做一張簡單的決策表，每個方案都填入同一組問題：目前每次工作需要多久？一年大致重複幾次？資料是否涉及敏感性？一次錯誤會影響哪些人？誰能修復？系統停止運作時能否退回手動流程？這些欄位未必能立刻換算成精確金額，但可以防止決策只盯著授權費或 AI 模型名稱。

此外，模型 API 的費用通常與使用方式、模型、請求次數及輸入輸出量相關；工具訂閱、雲端主機、儲存、日誌與資料傳輸也可能另計。若程式會自動呼叫模型，應設置預算上限、用量監控與異常停止條件，避免錯誤重試造成不預期的帳單。本文不引用易變動的即時訂價，也不提供沒有使用量資料支持的 ROI 百分比。採購時應以供應商當期正式計費文件及自身流量測試為準。

真正值得比較的指標，也應從「AI 幫我節省多少打字時間」往下一步。對報表工具，可能是每月人工整理時間、錯誤列的辨識率、使用者修正所需時間與重跑成功率；對網站產品，可能是缺陷數、平均修復時間與使用者任務完成情況；對客服機器人，可能是轉人工比例、錯誤回覆率與未授權資訊暴露情境。不同任務用不同的成果指標，才有可能知道是否真的改善營運。

十四、四個職場情境：選錯語言與選對語言的差別

情境 A：行銷人員每天要整理不同來源的成效表

某位行銷主管每天收下多個 CSV，欄位名稱不一致，還要把廣告活動名稱、日期與成效指標整理成共同格式。直覺上他可能問「我要不要學 Vibe Coding 做網站」，但真正的痛點是資料一致性，而不是缺少一個網頁。較合理的第一步，是列出來源檔名、欄位對照與缺值規則，使用 Python 或既有資料工具完成轉換。若資料最終要進入資料庫，再決定是否加入 SQL 與正式資料流程。等清理規則穩定後，才需要考慮加上圖形介面。

此情境最重要的測試不會是按鈕顏色，而是日期是否被正確解析、同一個活動的名稱能否一致、缺值是否被清楚標記、不同幣別或不同歸因口徑有沒有錯誤合併。AI 可以幫忙生出欄位映射的程式，但它無法僅憑欄名推論公司在 GA4 與廣告平台之間如何定義轉換。資料負責人必須事先定義指標語義。沒有這一步，再漂亮的圖表也可能是誤導。

情境 B：人資希望 Google 表單填完後能自動提醒主管

某間公司只想在員工填完內部申請表後，自動在 Google Sheets 留下紀錄，並依條件寄送通知。若資料、帳號與授權都在 Google Workspace 裡，Apps Script 可作為候選方案，因為它直接整合相關服務，並使用 JavaScript。[S10] 這時學習的重點應是事件觸發、欄位驗證、寄送失敗處理、使用者權限與通知紀錄。若未來擴大為需要多人協作、正式審核歷程、整合 HR 系統的服務，再評估是否適合轉成獨立的 Web 應用。

真正風險不是「能不能自動寄出 Email」，而是「誰有權看到申請資料、何時應通知、重複送出該怎麼辦」。若申請涉及個資或其他敏感內容，學習範例必須先用匿名資料。也應考慮腳本擁有者調職後的維護與授權問題。這種需求即使完全沒有訓練 AI 模型，也屬於 AI 輔助程式開發值得處理的職場案例。

情境 C：創業者想做一個能回答產品問題的 AI 網站

這個需求包含至少四層：網站介面、內容資料、模型呼叫與使用者安全。JavaScript 或 TypeScript 可以處理網頁與伺服器端邏輯，模型能力則透過正式 API 引入；若需要建立資料清洗或批次索引流程，也可能搭配 Python。選擇全 TypeScript 或採混合架構，應由團隊維護能力與實際流程決定。模型本身並不強迫你把整個網站重寫成 Python。[S08][S13]

更關鍵的是，網站是否只回答公開 FAQ，還是會查詢會員訂單、退款狀態與付款資訊。如果涉及後者，必須區分使用者驗證、資料授權、模型可存取的資料範圍與操作權限。能正確回答「運費怎麼算」的 Demo，不能直接當作可操作客戶資料的正式服務。當應用需要在回答之外執行動作時，應為工具呼叫建立權限與確認流程，不能把模型的文字同意當作使用者的合法授權。

情境 D：工程團隊想讓 Coding Agent 協助既有系統維護

一家已經有 Java 或 C# 後端、TypeScript 前端的公司，想讓 AI 協助修正程式、整理測試與提出程式碼審查意見。最差的做法之一，是直接要求所有人轉去學 Python，彷彿只有使用 Python 才稱得上 AI 導入。更合理的方法，是先保留原有程式語言與程式庫，測試 AI 對既有技術棧的理解能力，建立分支、Pull Request、測試與人工審查的作業規則，再逐步放大代理工具的任務範圍。

在這種情境，績效指標不應只有 AI 產生的程式碼行數，而應評估缺陷是否減少、審查是否有效、測試覆蓋是否改善及修復時間是否縮短。由 AI 提出修改建議可以是效率來源，但程式碼進入正式主分支前仍應遵守組織的審查規則。即便使用 AI 程式碼審查工具，也不應把「另一個 AI 覺得沒問題」當作足夠的人類核准。[S15][S25]

這四個示意情境有一個共同點：需求不是從工具產生，而是由工作問題產生。 若有人原本就已經能用試算表公式處理，沒必要為了增加 AI 標籤而建立新的後端；若需求已涉及跨系統權限、多人操作與持續維護，也不應停在一次性指令碼。選對語言的價值，是讓任務以最低可接受的總成本、最低可接受的風險完成。

十五、學習路線怎麼安排？一份以成果為單位的 4 週起點

對沒有程式背景的人，最需要的通常不是 200 個語法名詞，而是一條不會在中途失去意義的練習路線。以下提出 4 週的教學安排範例，不是經實驗證實人人能在 4 週成為工程師，也不是對工作成效的承諾。每週的目標是交出一個可檢查的產物，並且在遇到不懂的地方補充必要語法。實際進度可依工作時間與先備知識調整。

第一週先練習問題拆解與環境操作。選一個低風險的日常任務，列出輸入、輸出、成功條件、例外與使用者。接著熟悉檔案位置、文字編輯器、終端機與一個小範例程式的執行方式。學 Python 的人，先了解資料型別、print()、簡單運算、字串與串列；學 JavaScript 的人，則可先建立一個不連網的互動頁面，觀察按鈕事件如何改變畫面。這週的成果不是完成大專案，而是能親手啟動、修改、關閉一個最小程式。

第二週建立資料與邏輯能力。針對 Python，學習如何讀取 CSV、使用字典、寫函式及處理無效資料；針對 JavaScript，學習陣列、物件、條件判斷與簡單的資料驗證。可以請 AI 先解釋範例程式，再要求它給出兩個錯誤版本，讓自己練習找出問題。這種反向練習比被動觀看 20 段生成過程更接近真實工作，因為未來遇到故障時，先要知道從哪裡檢查。

第三週加入測試與錯誤處理。對每個功能列出正常、邊界與錯誤輸入，使用 unittest 或同等方式寫幾個小測試；再刻意使檔案不存在、欄位被改名或資料型別錯誤，觀察程式如何回應。這週的重要成果是一份「失敗時該怎麼辦」的說明，而不只是成功畫面截圖。若需要第三方套件，開始學虛擬環境、依賴紀錄與版本管理，避免同一個專案在不同裝置出現難以追查的差異。[S05][S07]

第四週完成一份可交接的小作品。整理 README、輸入輸出範例、執行條件、測試結果、限制與未完成事項，請另一位同事依文件重跑。這一步會讓學習者清楚看到：自己是不是只有靠 AI 才能操作？如果接手者不知道檔案在哪裡、不知道程式可能改變什麼，就表示作品還不能稱為可交接。此時再考慮是否把它延伸成自動排程、正式資料連線或簡單介面，而不是一開始就讓小工具長成難以維護的平台。

圖 5｜天地人原創學習地圖。週次與能力順序為教學編排範例，非保證完成時間。

對本來會程式的工程師，路線則不同。他們不必重頭花時間背基礎語法，而應練習將既有需求與測試交給 AI 協作，評估生成品質、辨認模型容易誤解的界面、建立代理工具權限，並將變更整合到現有 CI 與程式碼審查。對管理者，重點更不是親自學所有語言，而是學會辨別 POC 與正式系統的界線、設定品質關卡，以及評估跨部門維護與人才風險。

最重要的是，學習成果必須和原本的工作產出連起來。「這週學了資料型別」是一項活動；「可以把一份有空值的訂單資料清理後輸出拒絕原因」才是成果。當課程以成果為主軸，語法、AI 工具與安全觀念便有了清楚的角色，不會淪為互不相干的知識碎片。

十六、開發 AI 應用與使用 AI 服務，其實是兩種不同工程決策

另一個常見的混淆是：只要把 AI 加入軟體，是否就必須懂模型訓練？答案通常取決於你要控制到哪一層。想要一個可以將客服問題分類的系統，有可能只需要把文字交給已存在的模型服務；想研究自有影像資料中的特殊瑕疵，才可能評估資料集、模型訓練、推論硬體與評估流程。兩者都叫 AI 應用，但學習成本與治理重點差距很大。

使用既有 AI API 時，程式一般需要完成幾件事：接收資料、驗證輸入、決定哪些內容可送出、呼叫服務、確認回傳結構、處理失敗與逾時，最後把結果放入工作流程。這些步驟可用 Python，也可用 JavaScript 或 TypeScript 完成。OpenAI 官方 SDK 文件提供多種語言的開發方式，說明模型服務的介接並未綁定單一語言。[S13] 對已有成熟網站的企業來說，讓現有後端呼叫模型，可能比另建一整套 Python 服務更簡潔。

需要注意的是，模型回答不等於資料庫中的既定事實。假設模型替客服建議退款處理，是否真的可以退款，仍應由正式訂單系統依據已驗證的客戶身分與規則決定。AI 的文字結果應視為待處理資料，而不是繞過權限的指令。當輸出會影響金流、個資或其他高風險事項時，應設計結構化欄位、驗證規則、人工確認或其他適當控制，不能單靠一句「你必須回傳正確 JSON」就認定結果可靠。

至於模型訓練，除了程式語言還會多出資料標註、樣本分布、訓練成本、評估指標、模型版本、監控與公平性等議題。scikit-learn 官方入門就包含模型擬合、預測與模型評估概念；PyTorch 則提供深度學習完整工作流程的教學。[S11][S12] 如果你只想把文件摘要功能放進內部網站，無須因此先安排團隊研究深度學習訓練。反過來，如果團隊要建立能區分不同產品瑕疵的自有模型，只有學會呼叫 API 也不足以完成工作。

當應用需要多個工具、不同角色的代理與持續運作的工作流程時，可以再評估代理協作框架。OpenAI Agents SDK 官方文件同時提供 Python 與 JavaScript 入門，並包含工具與代理協作的設計概念。[S14] 但能用代理框架不代表一定應使用。若「讀取 CSV、檢查金額、輸出檔案」能以一般程式準確完成，就沒有必要把每一步交給會生成不確定答案的模型。適當的工程架構，應把確定性規則留在可以測試的程式中，把需要理解非結構化資訊的工作放在模型擅長且可受控的部分。

這個分界對非工程師尤其重要。與其一開始追逐最新 Agent 平台，不如先做一張「確定規則與判斷規則」的表。像日期轉換、重複訂單辨識、金額相加，原則上應以一般程式與明確規則處理；像從一段自由文字辨認主題、草擬摘要或提出候選分類，才是可以評估模型協助的部分。即使分類由模型提出，正式行動仍需要使用者、權限與業務規則共同決定。

十七、Excel、Google Sheets、Python 與 SQL，何時該停止使用試算表？

對大量職場讀者來說，真正的選擇不是 Python 對 JavaScript，而是「我已經會用 Excel，為什麼還要學程式？」這個問題完全合理。試算表本來就提供大量計算、篩選、樞紐分析與圖表功能。如果工作只有少量資料、規則簡單、需要人工即時查看，沿用熟悉的試算表可能更容易維持。單純追求 AI 標籤而把一個穩定公式改成腳本，不一定帶來好處。

開始考慮程式化，通常是因為出現了某些具體限制。第一，資料來源多，且每次都要重複搬移或整理。第二，處理步驟很多，靠人工點選容易遺漏。第三，同一套規則需要被不同人重現，不能接受每個人的公式版本不同。第四，資料量與查詢邏輯已讓試算表操作變得不穩定。第五，過程需要異常報告、排程、版本與權限控管。這些訊號比單一「多少列以上應該學 Python」更可靠，因為可接受的資料量會隨環境與操作方法改變。

如果資料都在 Microsoft Excel 的單一活頁簿中，且處理步驟有限，應先評估現有公式、Power Query 或其他已核准工具；若有既有 VBA 腳本，也不必在不了解維護風險前直接全面替換。若工作跨多個 CSV、需要自訂驗證或統一輸出，Python 可能提供更好的可重現性。若工作圍繞 Google Workspace，Apps Script 能利用既有帳號與服務整合，不必每次都建立獨立的部署環境。[S10] 若要跨多張關聯式資料表做查詢與大量彙總，SQL 應成為資料架構與操作能力的一部分。

這裡還有一個管理上容易忽略的考量：工具接手的人是誰。如果整個部門只有一位 Excel 高手，所有流程都藏在他的個人檔案裡，風險可能和只有一位 Python 工程師的腳本一樣高。真正的改善不是語言更現代，而是將規則寫清楚、輸入輸出標準化、異常可追查，並讓其他人能接手。把共用權限、版本和流程說明做好，有時比把工具搬到新技術棧更有價值。

做選型時可以採用「最小足夠架構」原則：先問現有工具能否安全、可重現地完成任務；若不能，再辨認是資料、互動、權限還是運算能力不足，最後才選擇需要增加的程式語言。這不是反對新技術，而是避免為了展示新技術而增加不必要的維運負擔。AI 降低試作成本，更應讓團隊願意快速比較多種方案，而不是對第一個產出的程式形成路徑依賴。

十八、怎麼讀懂 AI 產生的程式？從一個看似正常的錯誤開始

閱讀程式碼不必先像資深工程師一樣理解所有架構。對初學者來說，第一步是辨認一個函式接受什麼、回傳什麼，以及最容易失敗的地方。假設 AI 提出 int(float(amount))，想把輸入的金額轉成整數。它看起來很方便，但 float('1200.9') 再轉成 int 會得到 1200，小數部分被截斷。如果需求規定「金額必須原本就是非負整數」，這樣的程式不會報錯，反而會安靜地把不合規資料轉成另一個數字。

錯誤在這裡不只是語法，而是輸入規則被偷偷放寬。解法不是詢問 AI「這段程式是否正確」，因為若沒有給它原始規格，得到的回答可能只是解釋這段轉換在 Python 中如何運作。較好的問法是：「我們只接受 ASCII 數字組成的非負整數字串，不接受小數、負號、千分位或貨幣符號。請根據這個規格提出測試，指出目前程式會錯誤接受哪些值，並提供修改。」這時 AI 比較有機會協助把規格差異具體化。

JavaScript 也有類似陷阱。例如 parseInt('123abc', 10) 會回傳 123，但如果需求是整個欄位都必須是有效整數，這樣的結果可能不符合預期。TypeScript 即使把資料型別寫成 number，也不代表從網路或 CSV 進來的原始文字已經通過執行期驗證。[S08][S09] 這提醒我們，語言的型別、語法與資料驗證是相關但不同的概念，不能把任何一項當成完整保證。

比較實用的讀碼習慣，是從邊界往內看：程式在哪裡讀資料？是否可能拿到空值、重複欄位、超長文字或錯誤編碼？它如何將資料型別轉換？重要條件是寫在哪裡？錯誤被丟出、記錄，還是被安靜忽略？程式會寫到哪個目錄、覆寫哪些檔案、使用哪些權限？最後，哪些輸出會被人拿去做決策？只要能沿這條路徑檢查，即使沒有逐行理解所有語法，也能比較快抓出高風險區域。

當 AI 回覆一大段程式碼時，建議不要直接接受全部修改。先請它標示最小必要變更、說明哪些函式會受影響、列出預期通過與失敗的案例，然後在乾淨的測試環境執行。如果程式在你還沒看懂的情況下要求新增大量外部依賴、開啟新的網路權限、修改系統設定或刪除原始檔，應暫停執行並請有經驗的人協助檢查。讓程式能夠暫停、比對及撤回，是人機協作的基本控制，而不是對 AI 的不信任表態。

十九、從原型到上線：交付文件、權限與維護者，比演示影片更重要

當一個 AI 協作完成的小工具要交給同事使用，最先要回答的不再是「AI 有沒有寫出來」，而是「使用者如何知道它適合做什麼」。一個好的交付包應包含工作目的、支援的輸入檔、不得放入的資料、輸出格式、執行步驟、常見錯誤、測試範例、版本與負責窗口。如果用途只是個人實驗，這份說明可以簡短；如果是每日都會影響營運的流程，它就成為可靠性的一部分。

版本控管應比正式部署更早開始。當你請 AI 修改程式後，必須可以知道哪一版在什麼時間加入了哪個規則。若新版本誤判重複訂單，至少應能回到上一個已測試版本。Git 等版本控制工具可以協助紀錄修改；但初學者不必一開始就掌握所有進階操作，先學會保存明確版本與比對差異，也比每次把程式貼進同一份檔案覆蓋來得安全。

環境與憑證管理同樣重要。程式在開發者電腦執行成功，不代表可以在公司伺服器、其他同仁裝置或排程環境正常運作。若使用第三方套件，應記錄 Python 或 Node 的版本、依賴清單與必要設定；若呼叫 API，應以環境變數或組織批准的秘密管理方法提供憑證，並確認權限範圍。金鑰不應放在文章範例、前端程式、公開儲存庫或可被其他使用者看到的日誌中。正式部署前還需檢查資料保存位置與失敗時通知責任。

上線後也不能把程式完全忘掉。資料格式會變、原始 API 可能調整、權限可能過期、第三方套件可能出現漏洞。對每日報表工具來說，一個簡單但有效的監控做法，是記錄最近一次成功時間、處理列數、拒絕列數及是否有異常，並設置某種人工檢視機制。如果失敗時程式只是在背景安靜停止，使用者仍可能以為最新報表已完成。可靠的自動化不只需要成功路徑，更需要明確的失敗路徑。

交付的最後一道界線是責任歸屬。若使用者在 AI 建議下修改客戶資料，應由誰核准？若 Coding Agent 修改了付款流程，誰負責審查？若工具被移交給其他部門，誰擁有運作與修復權限？企業若不能回答這些問題，就不應因為演示成功而直接宣稱系統已正式落地。成熟的軟體交付，是技術、管理與使用者責任共同成立的狀態。

二十、AI 程式語言常見問題

Q1：AI 程式語言是一種新發明的程式語言嗎？

不是一般意義上的單一新語言。這個詞在實務搜尋中常指向「用來開發 AI 的程式語言」，例如 Python；也可能指「讓 AI 協助寫程式」的方法，例如透過自然語言向程式助理提出需求。兩種用法應先區分，因為一個是在選擇執行技術，一個是在選擇人與工具的工作方式。如果還不知道自己需要哪一種，先寫下希望完成的工作，再決定搜尋方向。

Q2：學 AI 一定要學 Python 嗎？

不一定。如果目的是機器學習、模型資料處理或快速檔案自動化，Python 通常值得優先評估；若目的是網站、互動工具或既有 JavaScript 系統中的 AI 功能，JavaScript 或 TypeScript 可能更直接；若公司已有穩定的 Java、C# 或其他技術棧，透過正式 SDK 與 API 整合也可能較合理。[S01][S13] 語言應與任務相符，不必為了名詞「AI」而全面重學。

Q3：沒有程式背景，先學 Python 還是 JavaScript？

若第一個成果想做資料清理、報表、批次檔案與 AI 資料處理，可先學 Python；若第一個成果是可以點擊、輸入、顯示內容的網頁，則可以從 JavaScript 基礎開始。若公司主要在 Google Workspace 工作，Apps Script 是具有情境優勢的 JavaScript 路線。[S10] 不論選哪個，都不要只練習請 AI 生成成品；要同步理解資料型別、條件、函式、除錯與測試。

Q4：ChatGPT、Codex 或 Copilot 都能寫程式，為什麼還要學基礎？

因為 AI 可以產生一種可能的實作，卻不能自動取得你公司正確的業務規則、合法的資料權限與部署責任。程式基本能力讓你能描述問題、辨認錯誤、驗證結果，並在工具失效時維護現有成果。調查也顯示 AI 使用者的信任常取決於是否容易驗證；在 2026 年 Stack Overflow 的相關題目中，48.0％ 受訪者選擇「能輕易驗證輸出時才信任」。這是受訪者態度，不是 AI 正確率。[S03]

Q5：想開發 AI Agent，是否應該先學最熱門的模型？

應先看 Agent 要執行哪種任務、要連接哪些資料與工具、是否需要長期狀態與權限控制。模型選擇很重要，但只有模型而沒有測試、工具權限與錯誤處理，仍無法形成可靠系統。官方代理 SDK 也提供 Python 與 JavaScript 方案，因此沒有「一定要先學某一種模型才有資格做 Agent」的技術必要性。[S14] 初學者更適合先學會一個明確的 API 呼叫，再逐步增加工具與流程。

Q6：企業是不是應該立刻讓所有員工學 AI Coding？

應先分流。資料處理職務可以學 Python 與資料驗證；行政與 Google Workspace 使用者可先評估 Apps Script；產品與前端職務可加強 JavaScript／TypeScript；工程師應把 AI 協作整合到測試、程式碼審查與權限規範。管理者則要了解怎麼判定 POC 是否能交付。培訓的共同目標不必是每人會同一套語言，而是每個角色能處理其範圍內可驗收的工作。

Q7：使用 AI 寫出的程式可以直接放進正式環境嗎？

不應只因程式可以執行就直接上線。至少要確認資料與業務規格、正常與異常測試、安全與權限、依賴套件、部署及回復方式，再依風險程度安排人工審核。GitHub 的官方最佳實務要求驗證 AI 建議，而 OWASP 2026 年風險分類也提醒開發者注意提示注入、資訊揭露、過度代理權限與不當輸出處理等問題。[S15][S16] 高風險系統應另外遵守組織的正式安全流程。

Q8：學 SQL、Excel 或 Google Apps Script，算不算學 AI 程式語言？

它們不全是 AI 專用語言或工具，但都可能成為 AI 工作流程中不可缺少的一層。SQL 讓資料查詢有結構，試算表幫助使用者檢查與使用資料，Apps Script 可以把工作流程與 Google Workspace 連接起來。學習目標應是理解這些工具如何與 AI 模型或 AI 寫程式助手協作，而不是為每項技能貼上一個 AI 標籤。若既有工具能把工作完成且容易維護，就沒有必要額外包裝成複雜的 AI 系統。

Q9：Python 和 TypeScript 哪個比較有前景？

不應用單一排行推論個人職涯。GitHub 2025 數據顯示 TypeScript 在 GitHub 整體貢獻者統計中排名突出，Python 則在 AI 與資料科學的專案中具優勢。[S01] 對工作者而言，更實際的是評估目標職務使用的系統、想建立的成果、可投入的時間，以及能否完成可展示的專案。對企業而言，既有程式庫、人員能力與安全架構通常比追逐年度排行更直接影響成本。

Q10：完全不寫程式，有沒有可能得到 AI 的實務價值？

可以。許多摘要、文字整理、問答、資料探索或流程設計問題，可以先用已核准的工具、試算表、工作流程平台與人工覆核解決。只有在需要自訂規則、跨系統整合、重複執行與可重現處理時，程式能力的價值才會更加明顯。是否學程式，不該由焦慮決定，而應由真正想完成的任務與長期維護需求決定。

二十一、最後的決策：先選工作，再選語言，最後才選 AI 工具

回到開頭那位希望自動整理訂單的主管。她真正要解決的不是「不知道哪一種 AI 最會寫 Python」，而是每週報表依賴重複手工處理、錯誤難以追查、資料規則沒有成為可重現的流程。若這個問題能先用 Python 與清楚規格解決，便沒有必要額外建立複雜網站；若日後需要多人使用、權限審核與持續追蹤，再評估 TypeScript 或其他既有系統技術，也不遲。

你可以在今天就做一個小型驗證：挑出一項每週重複的工作，列出原始資料、必要輸出及三種會讓結果錯誤的狀況，先用合成資料讓 AI 協助產生程式。不要急著接正式帳號，先確認程式可以重跑、輸出能人工核對、壞資料會被明確列出。若這些條件都符合，再決定是否值得把原型交給資訊或營運同仁進一步評估。這個行動不需要先決定所有技術名稱，卻能讓學習直接連到業務價值。

對想學習的人，最有用的問題不是「哪個語言一定不會被淘汰」，而是「哪一種能力能讓我把目前處理不了的工作完成，而且知道結果是否正確」。對企業決策者，最重要的也不是短時間內導入多少 AI 工具，而是能否把需求、資料、驗證、權限與責任變成一套可重複執行的工作方法。當這五件事已經清楚，Python、JavaScript、TypeScript、SQL 或其他技術的選擇就會逐漸變得合理。

本文主張的學習路徑可以濃縮成一句話：先用 AI 幫你開始，再用程式基礎理解它，最後用測試與流程管理決定能否信任它。 這比追求不斷變動的工具排行榜，更接近一套能夠長期累積的職場能力。

進一步學習與企業應用

如果你想從 Python 開始掌握 AI 協作寫程式，天地人的 Python for AI Vibe Coding：人機協作時代的程式基礎能力 可作為進一步了解的方向；若仍想先用自然語言完成簡單原型，可參考 Vibe Coding 零基礎入門課程；若已經有原型，需要學習跨系統開發、規格管理與測試，可閱讀 Agentic Engineering 進階課程。以上為已查到的公開課程資訊頁面，最新授課方式、價格及名額請以頁面當期公告為準。

企業若要評估團隊培訓，建議先整理 3 個最想改善的工作流程，說明目前輸入、輸出、資料限制與主要錯誤，再決定課程要聚焦 Python 資料處理、Google Workspace 自動化、AI Coding 專案，或工程團隊的代理式開發治理。先有待解的問題，才有理由選擇培訓主題。

資料來源、版本及原文摘要

本篇優先採用英文官方第一手資料，保留可核對的原始網址。以下短句僅摘取辨識主張所需的少量原文；分析與操作方法由 TDR 研究編輯另外整理。部分官方技術文件是持續更新的動態頁面，產品版本與文件內容可能在本文日期之後變更。來源 S19 至 S21 及 S26 至 S27 僅供確認天地人現有頁面與延伸學習，不以課程文案作技術事實的獨立證據。

重要英文原始用語核對

• GitHub [S01]：原文關鍵句「Python remains dominant for AI and data science workloads.」解讀：此句有指定 AI 與資料科學範圍，不能改寫成全球所有開發領域都由 Python 排名第一。
• Stack Overflow [S03]：問卷選項「I trust it when I can easily verify the output」。解讀：受訪者描述自己何時信任 AI，不代表 AI 在此情境的統計正確率。
• Python 官方 [S04]：原文「Python is an easy to learn, powerful programming language.」解讀：官方亦提醒其入門教程預設讀者有一定程式概念。
• TypeScript 官方 [S08]：原文「TypeScript offers all of JavaScript’s features」。解讀：TypeScript 是 JavaScript 生態中增強型別的選項，並不等同消除所有執行期錯誤。
• Google Apps Script [S10]：原文「You write code in modern JavaScript」。解讀：它是 Google Workspace 應用開發環境，不是新的 AI 模型。
• OWASP [S16]：2026 年版分類包括「Prompt Injection」「Excessive Agency」。解讀：這是風險類別，不是特定產品的漏洞證明。
• GitHub Copilot [S15]：原文「you should always validate the code it suggests」。解讀：AI 建議需在使用前審查與測試。

可追溯來源清單

資料檢索日期：2026 年 10 月 21 日。本篇未使用付費關鍵字工具的搜尋量資料，沒有自行估算搜尋量、排名、關鍵字難度、採購費用或 ROI。AI 安全與 API 官方文件可能持續修訂，重要企業決策應重新查閱最新文件。

文章編製說明

本文由 TDR 專業文研究編輯依可公開核查的官方資料、原創決策框架與合成程式練習製作。六張圖片中，主視覺由 AI 產生，五張資訊圖以原創 SVG／PNG 繪製。本文不含真實客戶資料，也沒有實際連接任何企業系統。AI 協作編輯並不等於經外部專家人工終審。本次發布已檢查站內重複內容、來源及網站排版；實作以合成資料執行 11 項本機測試，不代表已驗證任何企業正式系統。