從聊天框到本機執行：非工程師的 AI 飛輪

大多數人與 AI 的關係，仍停在同一個介面：打開瀏覽器，打一段話，複製答案，自己去落地。這不是沒用，而是把 AI 鎖在「顧問」模式——它給建議，執行鏈仍全部壓在你身上。

真正拉開差距的，往往不是誰背了更多 prompt 技巧，而是誰開始讓 AI 採訪自己的真實處境、建議該打造什麼、並在本機能經你允許地動手做。創作者與經營者圈子裡流傳的 Claude Code 入門路徑，核心其實不是終端機崇拜，而是一套可遷移的學習與生產系統。我把它稱為 AI 飛輪。

飛輪長什麼樣

飛輪很簡單，四步循環：

1. 讓 AI 採訪你——事業、工作、生活裡，什麼重複、什麼痛、什麼值得自動化。
2. 讓它建議可打造什麼——優先能省時間、創造客戶價值、或直接帶來收入的東西。
3. 讓它幫你打造，同時解釋在做什麼——你不是盲目貼指令，而是邊做邊更新自己的心智模型。
4. 可能性變多 → 靈感變多 → 再進入下一圈——像替大腦做一次韌體更新。

重點在順序：先釐清「在你的脈絡裡該做什麼」，再碰工具。
很多人卡關，是因為先打開教學清單，跟著做一個與自己無關的 todo app，做完既沒省時、也學不到「下一步該問什麼」。飛輪反過來：從不確定開始，用訪談把模糊痛點收成可執行的小專案。

一個好的第一題，最好同時滿足三件事：

• 真的痛：每週已在燒時間（抄表、彙整、重複回覆、手動追蹤）。
• 做得到：涉及真實 API 或資料處理也沒關係，但不要複雜到卡關好幾天。
• 學得到：做完之後，你多認識一種介面（API、本機檔案、權限、部署），而不是只多一個一次性玩具。

有用性護欄：飛輪最容易翻車的地方

AI 相關工作有一種高雅的陷阱：你開始做「能跟其他代理對話的代理」「協調代理的代理」，架構圖很漂亮，客戶與自己的日曆卻毫無感覺。那很像花一週調 Notion 儀表板，理論上更有效率，實際上沒有。

我建議用很粗暴的三問當護欄：

• 這能為客戶創造可感知的價值嗎？
• 這能為我或團隊每週省下可計算的時間嗎？
• 這能帶來收入或可驗證的決策品質嗎？

三個都偏「否」，就先不要開第二層抽象。飛輪的燃料是好奇心；飛輪的剎車是有用性。兩者缺一，要嘛學不起來，要嘛學成空轉。

Chat 與 Code：同一個腦，不同工地

理解 Claude Code（以及同類「本機可執行」工具）時，最有用的不是功能表，而是一張對照：

網頁版像建築師把圖攤在桌上給你看；本機執行版像建築師帶工具進工地——施工權仍在你手上，但牆真的會被砌起來。

終端機也不必神祕化。圖形介面像自排：系統幫你擋掉很多細節。終端機像手排：同一台車、同一條路，你用鍵盤直接下指令。對「建資料夾、跑腳本、看錯誤訊息」這類事，手排常常更快；可怕的不是黑畫面，而是在看不懂的情況下按了允許。

安全不是嚇自己，是養成核准習慣

讓模型碰檔案系統，確實是大事。健康的預設不是恐懼到不敢用，而是建立可重複的習慣：

1. 專案資料夾隔離：先 mkdir 一個專用目錄，在裡面啟動工具，預設工作區邊界清楚。
2. 權限從嚴：不要一開始就「本工作階段全部允許」；看清楚再准。
3. 讀懂破壞性指令：尤其刪除類操作——刪的是單一測試檔，還是整個目錄？影響範圍寫在指令裡，養成先讀再點。
4. 不懂就另開一窗問：把即將核准的指令貼到另一個聊天視窗，問「這安全嗎、會動到什麼」。必要時用第二個模型交叉檢查。
5. 小步驗證：先建一個測試檔、讀回來、再清掉；用一次完整權限流程建立肌肉記憶。

能力越強，你核准的每一下越像在簽名。系統可以設計成「先問再做」；要不要承擔後果，永遠是人的決定。 這點與「它會執行，但不會替你做價值判斷」是同一條紅線。

技術阻力：非工程師真正要練的肌力

開發者日常就在撞牆：過時文件、失敗的 API、難懂的錯誤碼。以前靠會搜尋、會逛論壇；現在多半是把錯誤貼給模型，換回可執行的下一步。

多數非技術職缺比較少遇到技術阻力，卻常遇到人際與流程阻力。一進入「去 Google Cloud 拿 API 金鑰」「本機起一個 server」這類步驟，介面企業感過重，很容易覺得自己不夠格而放棄——即使目標只是一把讀 YouTube 公開資料的鑰匙。

飛輪能轉起來的人，通常不是比較天才，而是比較願意做這件事：

把看不懂的整頁畫面或完整錯誤訊息複製起來，貼回去問「我現在在哪、該點什麼、哪些可以忽略」。

阻力不是系統在拒絕你；阻力是學習的入場券。躲阻力，飛輪停在聊天；扛過一輪，你多的不是一行指令，而是以後會問的新問題——「這個軟體有 API 嗎？有沒有 MCP？我能不能自己接？」詞彙一擴張，可自動化的版圖才會跟著擴張。

最小可行的第一圈（明天就能做）

不必先成為 Labs，也不必一次上多代理編制。第一圈可以小到這樣：

1. 裝好桌面端與（若需要）語音輸入——用說的描述需求，比乾打字更接近真實思考。
2. 對 AI 說：請訪談我；目標是找出一件每週很煩、做成後能省時或創造價值的小事。
3. 為該事開一個專用資料夾，在裡面啟動可執行工具。
4. 用白話寫清輸入、輸出、成功標準；先做「三筆資料／單一來源」版本，不要一開始就全公司儀表板。
5. 每一步核准前讀懂；做完立刻用那三問檢查有用性。
6. 再請它訪談你：下一步哪個功能會改變你的決策或省下下一小時？

你會發現，最難的常常不是寫程式，而是把「我隱約很煩」說成「我要這三個欄位、每週看一次、用來決定什麼」。飛輪逼你把意圖講清楚——而講清楚，本身就是一種專業能力。

結語

只會在網頁上聊天的人，與會在本機上安全地讓 AI 施工的人，差距不會靠再多看幾篇「十大 prompt」自動縮小。縮小差距的方式很朴素：選一件真的痛的事，讓 AI 訪談你，帶著核准習慣做完最小版本，再問下一件。

飛輪轉起來之後，工具名單會變——Cowork、Code、代理框架、MCP——但底層不變：意圖與有用性由你定義，執行可以被放大，後果由你簽名。

從聊天框走到本機執行，不是為了看起來像工程師，而是為了把「知道該做什麼」和「真的做完」接回同一條路上。

延伸閱讀

• 「你會不會寫代碼」已失重：當構建不再等於編程
• 當實作不再是瓶頸：把「選擇與驗證」工程化
• 掌控思想，而非代碼：Redis 作者 antirez 為何認為工程師不該再死盯程式碼

我是江中喬，專注於 AI Agent Architecture、Memory Governance 與 Cognitive Diversity，持續研究如何打造能夠長期協作、可信任且可治理的 AI 系統。