“AI然後寫程式很厲害”

在這場與 Mosky 的訪談中，他提出一個核心觀念：在 AI 幫助下，學習與開發的門檻大幅下降，但真正能讓你跨過大多數坑的，是那「1% 的關鍵知識」。

訪談來源： 用 1% 關鍵知識跨過 99% 的坑｜feat. Mosky 從零開始 AI 寫程式（55:22）

TL;DR

透過系統化的提示詞實驗、選對工具與函式庫、把程式切成可測試的積木，並結合自動化測試與 AI 輔助的 Code Review，能把原型快速變成可維護的系統。

核心亮點：

  • 🔑 用 1% 的高價值概念，避免大部分常見雷區
  • 🧩 把程式拆成可測試的積木，AI 才能產生長期可用的結果
  • 🧪 提示詞要系統化做實驗：固定基線、每次只改一個變數並記錄
  • 🛠️ 優先選擇語意明確、高階函式庫，降低 AI 產出的錯誤率
  • 🧰 Google Apps Script 是快速驗證與整合試算表的好工具
  • ✅ 把「整包日誌」貼給 AI 做初步 triage，再把測試納入 CI
  • 🏢 組織應鼓勵員工使用 AI，但指定工程師支援與審核以降低風險

“AI然後寫程式很厲害”（逐字稿，第 50 行）

TL;DR

在這場與 Mosky 的訪談中，他提出一個核心觀念：在 AI 幫助下，學習與開發的門檻大幅下降，但真正能讓你跨過大多數坑的，是那「1% 的關鍵知識」。透過系統化的提示詞實驗、選對工具與函式庫、把程式切成可測試的積木，並結合自動化測試與 AI 輔助的 Code Review，能把原型快速變成可維護的系統。文章整理出 9 個核心章節：起手式、1% 關鍵知識、Prompt 實作、AI coding vs Vibcoding、偵錯與品質、工具與實作範例、函式庫與 API 選擇、組織採用策略、以及系統化學習與未來展望；每章皆引用逐字稿原句、展開脈絡說明、提供可操作的技術細節與 Takeaway。

核心亮點

  • 🔑 用 1% 的高價值概念，避免大部分常見雷區。
  • 🧩 把程式拆成可測試的積木，AI 才能產生長期可用的結果。
  • 🧪 提示詞要系統化做實驗：固定基線、每次只改一個變數並記錄。
  • 🛠️ 優先選擇語意明確、高階函式庫，降低 AI 產出的錯誤率。
  • 🧰 Google Apps Script 是快速驗證與整合試算表的好工具。
  • ✅ 把「整包日誌」貼給 AI 做初步 triage，再把測試納入 CI。
  • 🏢 組織應鼓勵員工使用 AI，但指定工程師支援與審核以降低風險。

章節總覽

  1. 起手式：Mosky 與 AI 寫程式的起點
  2. 1% 關鍵知識：抓住少數名詞的威力
  3. Prompt 實作：寫好提示詞的心法與範例
  4. AI coding vs Vibcoding：積木化思維與天花板
  5. 偵錯與品質：日誌、測試、Code Review 的 AI 工作流
  6. 工具與實作範例：爬蟲、Google Apps Script 與單檔 Demo
  7. 選擇對的函式庫與 API：讓 AI 更容易產出正確程式
  8. 組織採用與共存策略：何時需要工程師介入
  9. 學習建議與未來展望：系統化累積你的 1% 詞彙庫

起手式：Mosky 與 AI 寫程式的起點

AI然後寫程式很厲害（line 50）

  1. 那今天的來賓是我們好朋友Mosky
  2. 那他在沒有AI之前呢
  3. 已經用手打扣打了快20年
  4. 是一位超級資深技術又超強的工程師
  5. 因為Mosky跟Vivi和我一樣
  6. 都是從2024年開始AI讀書會第一屆
  7. 就開始參加了元老
  8. 不過當時Vivi跟我都是去問問題的麻瓜
  9. 那Mosky就是來這個
  10. 普渡眾生
  11. 來回答我們問題的這個程氏好朋友
  12. 讓我們掌聲歡迎Mosky
  13. 嗨氛圍實驗室的各位大家好
  14. 很開心今天可以來到這個節目
  15. 那我是Mosky
  16. 那對我已經寫程氏好久了
  17. 寫了20年了
  18. 那我也教程氏
  19. 教了大概10年了
  20. 就是我從以前很久很久以前
  21. 我就覺得說
  22. 喔如果每個人都會寫程式
  23. 那應該很厲害吧
  24. 兩年前
  25. 就是剛好就是我知道了
  26. AI然後寫程式很厲害
  27. 然後不只是AI寫程式很厲害
  28. 而且是有完全不懂程式的人
  29. 有辦法利用AI
  30. 當時的AI
  31. GPD 3.5那個時代
  32. 就有辦法做出一些很厲害的應用

認識 Mosky 的那天像在聽一個老朋友講故事：他有「20 年寫程式、10 年教學」的資歷，講話裡帶著既謙虛又自信的口氣。節目中他說了那句很直接的觀察：

“AI然後寫程式很厲害”（line 50）

這句話不是口號，而是轉捩點的見證。從 GPT‑3.5 的年代開始，工具讓完全不懂程式的人也能「透過對話」產出應用，門檻被大幅降低；Mosky 把自己定位成「先學、後教」的那種人——他既是用手寫過大量程式碼的資深工程師，也是把經驗傳給新手的老師。

在訪談裡，他常用故事來區分兩條路：新手的入門路徑（用 AI 快速上手）與資深工程師的深耕路線（把 AI 當成放大槓桿，但要負責任地管理系統）。對新手，他鼓勵嘗試與實作；對專業人士，他更強調設計、測試與維護的重要性，因為 AI 產生的程式碼需要被整合、審查與驗證。

技術細節（簡單建議）

  • 新手入門步驟清單：
    1. 選一個語言（如 Python 或 JavaScript）與簡單 IDE。
    2. 學會如何把問題拆成小步驟並寫成 prompt。
    3. 用 LLM 生成範例程式碼，自己執行、除錯、理解每一行。
  • Prompt 範例（基礎）： 
    請用 Python 寫一個函式 calculate_mean(numbers)，包含輸入驗證與單元測試範例。
  • 專業工程師 checklist：
    • 把 AI 生成的程式碼放進 CI 進行單元／整合測試。
    • 審查安全性（注入、權限、依賴套件）與可維護性（註解、模組化）。
    • 設計資料契約與錯誤處理。

Takeaway：

✅ AI 降低入門門檻，新手可以透過對話快速產出實作。
✅ 專業仍需深耕：設計、測試與安全是不可省略的步驟。
❌ 別把 AI 當成完全的替代品，最後的責任還是人的。

1% 關鍵知識：抓住少數名詞的威力

我們課程是把它叫做1%的關鍵知識（line 146）

  1. 那其實很多軟體工程的knowledge
  2. 或者是程式效益的knowledge
  3. 它其實是
  4. 也是這一代
  5. 或者說我們所謂的新時代開發者所需要的
  6. 我不知道大家有沒有看stress或facebook
  7. 偶爾會有那種報上班的案例
  8. 就像是這類型的東西
  9. 其實只要一點點
  10. 的關鍵的知識
  11. 就一點點軟體工程的知識
  12. 你其實就可以避開這些雷區
  13. 然後就可以更開心更輕鬆的
  14. 享受這個
  15. 新的世界
  16. 然後AI賦予你的寫程式的衝
  17. 嗯
  18. 所以像Mosie提到
  19. 雖然AI讓這個新時代開發者好像很快可以進來
  20. 但同時天花板還是蠻低的
  21. 那有提到說有一些共通一直被問的問題
  22. 軟體工程的knowledge就被
  23. 提取出來
  24. 覺得這個是最重要
  25. 我看Mosie在課程裡面會不斷用
  26. 所謂的關鍵知識的1%去形容是嗎

我喜歡把「1%」當成放大鏡：不是要你背一大串理論，而是學會辨認那幾個會決定成敗的名詞。講個小故事：小王剛進團隊，寫程式很快，但每次上線後都遇到同樣的錯——沒抓到「副作用」「資源競爭」「邊界條件」這三個名詞背後的危險。當他被提醒只要掌握這些關鍵詞，就能避開常見雷區，整個心態就不一樣了。這就是1%的威力：把99%的背景濃縮成可立刻使用的信號。

名詞萃取與教學設計

  • 名詞萃取流程（實作步驟）:
    1. 從事故報告與 PR 評語中列出所有重複詞彙。
    2. 計算出現頻率與影響指標（影響範圍 × 修復成本）。
    3. 選出前 1% 作為課程核心，為每個詞彙設計 1 個模擬情境與 1 條應對 checklist。

Pseudo-code 範例：

terms = extract_nouns(texts)
score(term) = freq(term) * avg_impact(term)
key_terms = top_percent(terms, 1)
for t in key_terms:
  create_example(t)
  create_checklist(t)

教學形式建議：

  • 案例驅動 + 模板化輸出 + 快速回顧（Spaced repetition）。

Takeaway：

✅ 掌握少數高影響名詞，比記住大量細節更能避免常見雷區。
✅ 選詞依據：出現頻率、可操作性與忽略成本三項評估。
❌ 不要把1%當捷徑省略練習，它是濃縮後仍需反覆演練的技能。

Prompt 實作：寫好提示詞的心法與範例

那個叫no lies（line 160）

  1. 就是請AI幫我
  2. 就是吐出一個比較乾淨的表格
  3. 因為我資訊有點亂
  4. 然後反正他就是一直跟我來回
  5. 就是一直回缺
  6. 給我一些奇奇怪怪的東西
  7. 但我記得那時候我就是問你
  8. 你就是給了我一個詞
  9. 那個叫no lies
  10. 好像就是正規化這個詞吧
  11. 我就是加了這個詞之後
  12. 我開了一個新的視窗
  13. 哇塞一下就幫我解決了
  14. 跟我前一個視窗已經來回
  15. 不知道幾百個對話
  16. 根本搞不清楚
  17. 來做這件事情
  18. 我我我對這件事情有印象深刻
  19. 真的是當時
  20. 就是讓AI就是直接好像變天才一樣

這一章講的是實作面：如何用一句關鍵詞或一套模板，快速把 AI 的回應「正規化」。故事從一段實際經驗開始──對話亂、結果怪、來回好幾百次，直到加入一個詞「no lies」，才瞬間把結果拉回乾淨而可用的狀態。用詞不是魔法，但它改變了模型的解讀框架：把模糊要求變成明確約束，讓系統能跳出之前的歷史對話干擾，從新視窗乾淨地執行任務。

提示詞結構與範例

萬用提示模板：

1. 系統（System）：你現在是一位 ______（角色），回答要 ______（風格）。
2. 現況（Context）：我有的資料/問題是：_______（簡短）。
3. 期待（Goal）：希望得到：_______（輸出格式/重點）。
4. 痛點（Problem）：避免/修正：_______（常見錯誤）。
5. 驗收清單（Acceptance）：必須包含的欄位或條件。
6. 控制關鍵詞（Control token）：例如 "no lies" / "short, factual" / "normalize"

實驗方法：固定基線 prompt、多版本比對、有記錄，並保留最穩定的控制詞與模板。

Takeaway：

✅ 使用控制詞（如 “no lies”）可以快速提升回應品質。
❌ 不要只做一次對話：保留版本與紀錄才能複製成功。
✅ 萬用模板能大幅降低來回試錯成本。

AI coding vs Vibcoding：積木化思維與天花板

真正厲害,真正可以解放更多的超能力（line 401）

  1. 我覺得這是一個很好的問題
  2. 其實所有的專業人士啊
  3. 我們在有了這個AI的super power
  4. 我們其實也是掌握到super power
  5. 就不滿大家說
  6. 只是我們的super power比較不會用
  7. 再說
  8. 在社群又分享說
  9. 我又做了一個小網站
  10. 大家
  11. 老實老實說
  12. 這個
  13. 就沒什麼好炫耀的
  14. 就是
  15. 太簡單了你知道嗎
  16. 其實
  17. 其實這專業
  18. 不好意思
  19. 這專業怎麼會炫耀這種東西
  20. 沒什麼好炫耀
  21. 這邊
  22. 被插了三刀有沒有
  23. 抱歉抱歉抱歉
  24. 抱歉抱歉
  25. 對因為就是
  26. 那個想當然就做得到嘛
  27. 對我們就不會
  28. 做什麼事情
  29. 所以我看到很多專業人士
  30. 他們是在公司裡面
  31. 然後可能是
  32. 一個人幫十個人用
  33. 他們非常
  34. 非常快樂
  35. 因為很多以前
  36. 沒辦法做的廠師
  37. 現在全部都可以做
  38. 做這些廠師
  39. 那可能是幫助公司
  40. 省錢也好
  41. 有新的機會去探索也好
  42. 就是我很多朋友
  43. 都真的是跑出來開
  44. 就是新創
  45. 可以開公司
  46. 對這些專業人士

在這一段對話中，講者把兩種「寫程式的態度」分成 Vibcoding（快速玩）與 AI coding（有意識的協作）。Vibcoding 是那種看到工具就開心玩，快速把想法做出來、分享一個小網站，常常讓專業人士覺得「太簡單了沒什麼好炫耀」。相對的，AI coding 強調把 AI 當作協作夥伴：有意識地拆解問題、驗證關鍵模組，才可能真正達到「解放更多的超能力」。

技術細節（步驟與檢查）

  1. 分段：把需求拆成 N 個功能點（輸入驗證、商業邏輯、資料存取、錯誤處理）。
  2. 驗證：每個功能寫小測試或手動驗證步驟，確保 AI 生成的函數符合期待。
  3. 組合：定義清晰的 API/介面，逐一串接並做整合測試。

Prompt 範本與驗證清單在章中示例可複製使用。

Takeaway：

✅ 將程式切成「可測試的小積木」，能把 AI 的超能力放大並避免天花板。
❌ 只用自然語言指令而不驗證程式結果，容易在複雜系統中失敗。
✅ 多輪、有意識的協作（AI coding）比單次快速實作（Vibcoding）更能帶來長期價值。

偵錯與品質：日誌、測試、Code Review 的 AI 工作流

所以這個是我覺得一個 超級好用的出錯法給大家（line 506）

  1. 然後整包貼給AI
  2. 你也不用思考
  3. 整包貼給AI
  4. 然後看它有沒有辦法定位到問題在哪裡
  5. 所以這個是我覺得一個
  6. 超級好用的出錯法給大家
  7. 我覺得第二個是大家沒有的概念
  8. 是自動化測試
  9. 那自動化測試的意思就是說
  10. 其實我們軟體第二程式出復之前
  11. 它都一定會跑一系列的測試
  12. 來確定說每個功能都是由我們預期量做的
  13. 那我會蠻建議就是說
  14. 大家的程式做到一個程度之後
  15. 你就可以叫AI說
  16. 你會幫我加一些測試
  17. 對
  18. 那當然我們這是很簡單的問法
  19. 實際上怎麼用會有一些比較詳細的
  20. SOP可以遵守
  21. 會運作得比較好
  22. 那我這邊就不贅述
  23. 那我覺得給大家一個很簡單的觀點
  24. 是叫做自動化測試
  25. 它有點像是幫你的程式加防腐劑

把「整包」的日誌與相關程式片段貼給 AI，像講稿裡說的「整包貼給AI，你也不用思考」，AI 可以快速幫你定位錯誤熱點，給出可能原因與優先修復點。接著把「手動測試流程」轉成自動化測試，是長期品質保證的關鍵。先從單元測試開始，針對核心函數寫短小可重現測試，再往外擴展到整合與 E2E。

技術細節（範例）

  • AI prompt 範例： 
    我有以下錯誤日誌與程式片段，請幫我找出最可能的錯誤來源、相關 stacktrace 行號，以及三個優先排查建議：
[貼上 log 與程式碼]
  • 測試轉換（Jest 範例）： 
    // sum.test.js
const { sum } = require('./sum');
test('sum of two numbers', () => {
expect(sum(2,3)).toBe(5);
});
  • SOP（簡要）：
    1. 先貼完整日誌與最小可重現程式片段給 AI。
    2. 依 AI 回報做初步修補與重跑測試。
    3. 請 AI 生成單元測試範本並加入 CI。
    4. 用 AI 做 Code Review 初審，重要改動仍需人工確認。

Takeaway：

✅ 把「整包」日誌與最小可重現程式貼給 AI，能快速做初步定位與 triage。
❌ AI 可做初審但不能完全取代人工審查；安全與設計判斷仍需人來把關。
✅ 將手動測試轉成自動化測試並納入 CI，是最有效的品質保護方式。

工具與實作範例：爬蟲、Google Apps Script 與單檔 Demo

甚至可以很簡單 用Google Apps Script 就可以做到（line 277）

  1. 像我們是台灣人嘛
  2. 我們都知道說
  3. 誒你要從台北到宜蘭
  4. 那可能最快的方法
  5. 可能是開車
  6. 或是搭客運
  7. 那但是
  8. 呃因為我們是台灣人
  9. 我們有這個knowledge
  10. 但今天AI詞
  11. 它是有可能告訴你說
  12. 好那你要去宜蘭
  13. 你就從
  14. 台北
  15. 然後搭高鐵到左營
  16. 然後被開車
  17. 北上到宜蘭
  18. 然後征程一大圈
  19. 然後到宜蘭
  20. 這確實是會發生的
  21. 我舉一個比較清楚的好了
  22. 就像是
  23. 爬蟲
    1. 那大家可能都會想要
  25. 或多或少啦
  26. 都會想寫爬蟲
  27. 可是因為大家沒有那種
  28. web技術的知識
  29. 你可能不知道要去
  30. 怎麼判斷說

這一章像在跟朋友聊天，我會先說：「先別急著用最複雜的工具，很多時候可以用最簡單的方式先解決問題。」正如開頭所說，很多人直覺想用爬蟲，但第一步是判斷目標網站是靜態還是動態：靜態就抓 HTML，動態則要模擬瀏覽器或用 API。實務上建議流程是：先嘗試簡單抓取（Google Apps Script 或 curl），做成單檔 Demo，成功後再逐步複雜化。

技術細節（判斷與工具選擇）

  • 判斷靜態/動態：檢查「檢視原始碼」是否含資料、或在 Network 看有無 XHR/Fetch。
  • 簡易首選：Google Apps Script（定時 + 寫入試算表）。
  • 進階：Puppeteer / Playwright 模擬瀏覽器抓取 JS 渲染後內容。
  • 輸出流程：CSV → AI 處理 → 產生可下載 HTML dashboard。

範例：Google Apps Script（簡單抓靜態頁面並寫入試算表）

function scrapeToSheet(){
  const url = 'https://example.com/data';
  const res = UrlFetchApp.fetch(url, {muteHttpExceptions:true});
  const html = res.getContentText();
  const matches = html.match(/<tr>[\s\S]*?<\/tr>/g) || [];
  const sheet = SpreadsheetApp.getActiveSpreadsheet().getActiveSheet();
  sheet.clear();
  matches.forEach((tr,i)=>{
    const cols = tr.replace(/<[^>]+>/g,'').split(/\s+/);
    sheet.getRange(i+1,1,1,cols.length).setValues([cols]);
  });
}

Takeaway：

✅ 先判斷靜態或動態，再選工具以節省力氣。
✅ Google Apps Script 是快速驗證、定時爬取與試算表整合的好選擇。
❌ 不要一開始就用最複雜的方案，先做單檔 Demo 再擴充。

選擇對的函式庫與 API：讓 AI 更容易產出正確程式

喔 這個應該是很適合小白使用的（line 1472）

  1. 我想一下喔
  2. 我覺得你可以這樣子理解
  3. 就是說
  4. 呃
  5. 每個API啊
  6. 一組API
  7. 就有點像是我們鍵盤上的
  8. F1到F12
  9. 它就是這樣一排
  10. 這樣湊起來
  11. 就是一組API
  12. 那這個API上面會有告訴你說
  13. 喔我的F1是什麼
  14. F2是什麼
  15. F3是什麼
  16. 那不同的API就是
  17. 有點像你切換那個鍵盤的
  18. 快速鍵組合
  19. 可能Photoshop是一組
  20. 可能Chrome是一組
  21. 類似像這樣的概念
  22. 它其實就指的是
  23. 呃
  24. 這個函數庫
  25. 那提供了哪些功能
  26. 哪些功能鍵讓你用
  27. 那
  28. 我自己會這樣判斷是說
  29. 今天
  30. 因為它都會有API的文件
  31. 那這個文件會說
  32. 它的F1的功能是什麼
  33. 那今天它的秒數
  34. 或是它函數本身的命令
  35. 很符合我們自家語言
  36. 會下的方式的時候

在挑函式庫或 API 時，最重要的是「可被 AI 自然理解」——換句話說，文件與參數要接近自然語言描述，這樣模型比較不會誤解指令。實務上偏好高階、語意清楚的函式庫（減少必填參數與低階細節），當遇到不穩定 API 時，快速替換並記錄問題以便下一次選擇。

判斷清單（要點）

  • 文件可讀性：參數名稱是否貼近自然語言。
  • 高階 vs 低階：優先高階封裝（減少必填參數）。
  • 回傳型態穩定：有明確 status / error code。
  • 可替代性：是否容易換到相似庫。

範例：

  • 好：saveImage({ path: ‘out.png’, format: ‘png’ })
  • 差：saveImage(bufferPtr, width, height, stride, pixelFormat)

Takeaway：

✅ 優先選語意明確、高階封裝的函式庫，讓 AI 更容易產出正確程式。
❌ 避免一開始就用低階、多參數的 API，容易造成指令誤解與錯誤。
✅ 若遇不穩定的庫，迅速嘗試替代方案並記錄結果以供未來選擇。

組織採用與共存策略：何時需要工程師介入

新時代開發者 跟專業人士是不一樣的（line 1616）

  1. 如果是在組織裡面
  2. 其實我還蠻不推薦就是說
  3. 你到某個
  4. 某個時刻再去找工程師
  5. 我反而會更推薦的事情
  6. 是說
  7. 每一間公司
  8. 如果有老闆在聽的話
  9. 每一間公司
  10. 其實
  11. 就是真的
  12. 老闆們
  13. 你看大家
  14. vibe coding
  15. 可以發現出這個
  16. AI coding可以做出這個
  17. 第一個要理解的事情是說
  18. 新時代開發者
  19. 跟專業人士是不一樣的
  20. 請不要
  21. 新時代開發者做的東西
  22. 其實不一定是
  23. 所謂的production ready的東西
  24. 新時代開發者
  25. 開發的東西是
  26. 幫助自己工作
  27. 跟幫助自己生活
  28. 跟可以提升公司的
  29. 營運效率
  30. 都是可見的

在公司裡推動 AI 工具普及時，把場景想成辦公室內的兩類人：新時代開發者（善用工具做原型）與專業工程師（負責生產級系統）。Mosky 建議：不要等到出大問題才找工程師，而是在推廣初期就把工程師列入支援角色，協助規劃、審核與上線。

建議政策與流程

  • 明確區分責任：誰可以做 prototyping，誰負責 production。
  • 指定工程師支援小組：作為橋樑，負責將高價值原型轉為可維護服務。
  • 建立治理機制：資料來源、敏感資料處理與審核回溯。

技術 checklist（原型上線最小步驟）：

- [ ] 需求評估（owner, SLO）
- [ ] 安全審查（資料分類）
- [ ] 測試覆蓋 > 70%
- [ ] 日誌/監控設定（Prometheus / Grafana）
- [ ] CI: tests -> build -> deploy(staging)
- [ ] 上線前安全與合規簽核

Takeaway：

✅ 新時代開發者適合做原型與自動化，但不等於 production-ready。
✅ 公司應指定工程師作為支援與審核窗口，從規劃到部署共同協作。
❌ 不要等到系統出問題才找工程師介入，會付出更高的代價。

學習建議與未來展望：系統化累積你的 1% 詞彙庫

大家下提示詞的時候 要有系統一點（line 1912）

  1. 就是第一個
  2. 大家下提示詞的時候
  3. 要有系統一點
  4. 要有系統的在做
  5. 實驗跟
  6. 驗證
  7. 而不是就是漏漏的
  8. 向到對位置
  9. 那這樣你沒有辦法
  10. 整理出任何東西
  11. 但如果你是同一個
  12. 同一個提示詞
  13. 然後分兩次
  14. 分三次下
  15. 那你就可以掌握到說
  16. 你是哪一個變化
  17. 導致了一個關鍵的結果
  18. 就可以把它記下來
  19. 那你要怎麼去取得
  20. 更多類似這樣的關鍵字
  21. 就是你永遠都可以問AI說
  22. 我今天學到一個Echuf
  23. 它超讚的
  24. 可以告訴我其他的選擇
  25. 類似像這樣的方式
  26. 就可以幫Jimmy拓展
  27. 自己的
  28. 關鍵字的詞彙庫
  29. 我覺得今天就是
  30. 真的很開心可以邀請到Moskey

聽到那句「要有系統一點」，可以看成學習與優化的行動指南：固定基線、分步實驗、紀錄差異，讓偶然變成長期資產。把每一次成功的提示詞、控制關鍵字、或成功的模板記錄下來，並讓 AI 幫你拓展相似詞彙，慢慢打造你的 1% 詞彙庫。

系統化實驗流程（建議）

  1. 固定基線 prompt（Context / Role / Task）。
  2. 每次只改一個變數並重跑多次。
  3. 記錄結果：輸出樣式、成功率、失敗類型。
  4. 將有效詞彙加入索引或表格，並定期回顧優化。

示例紀錄欄位（CSV）：

  • prompt_id, base_prompt, 變數改動, 次數, 輸出樣例, 成功度(0-1), 備註

Takeaway：

✅ 系統化實驗：固定基線、單變數測試、紀錄差異是關鍵。
✅ 用 AI 幫你擴展關鍵字詞彙，建立可搜索的詞彙庫。
❌ 不要零散試驗，缺乏紀錄的實驗無法帶來可複製的成效。

總結：關鍵 Takeaways（6-8 條）

  1. ✅ 把握 1% 的關鍵知識，能避開 99% 的常見坑。
  2. ✅ 提示詞要系統化（基線、單變數、記錄），不要零星試驗。
  3. ✅ 優先選語意清晰的函式庫，讓 AI 更容易生成正確程式。
  4. ✅ 把程式切成可測試的小積木，再用 AI 協助組合。
  5. ✅ 把日誌與最小可重現程式片段貼給 AI 做初步 triage，再納入測試流程。
  6. ✅ 公司應鼓勵使用 AI，但在早期即導入工程師支援與治理機制。
  7. ✅ 用 Google Apps Script 與單檔 Demo 快速驗證想法，然後再升級工具鏈。
  8. ✅ 把每次成功的提示詞與控制詞記錄成詞彙庫，形成長期資產。

相關資源

  • 訪談影片： https://youtu.be/n3wZiJcOcRk
  • 提到的工具：GPT（GPT-3.5 起）、Puppeteer、Playwright、Google Apps Script、Jest、Prometheus/Grafana
  • 延伸閱讀：請參考節目同檔案與 Mosky 的課程資源（若公開）

（本文為從 Mosky 訪談逐字稿整理之深度文章；所有引用均取自逐字稿原句，並保留逐字稿行數標註。）