1. 為什麼「獨自開發五款應用」不再是天方夜譚？

你是否曾經想過，一個人到底要如何同時開發五款應用程式，而且還不是那種「Hello World」等級的玩具，而是真正能上線、有使用者、甚至能賺錢的產品？

當全世界都在高喊「AI 會取代你的工作」時，有一位名為 Josh Pigford 的獨自創業者，卻把 AI 當成了他的終極加速器。他不是什麼科技巨頭的工程副總裁，也不是擁有幾十人團隊的 startup 創辦人。他就是一個人，一台電腦，加上一套他反覆打磨的 AI 工作流，正在用前所未有的速度把點子變成產品。

這不是一篇教你如何「提示工程」的技術手冊，而是一場關於生產力哲學的深度拆解。我們要從 Josh Pigford 的實戰經驗中，提煉出那些能讓一個普通人擁有「十倍工程師」效率的具體技能與心法。準備好顛覆你對「軟體開發」的所有認知了嗎？

1. 為什麼「獨自開發五款應用」不再是天方夜譚？

傳統觀念裡，一個人要開發一款像樣的 SaaS 產品，光是要搞定後端架構、前端介面、資料庫設計、部署維運、客戶支援……這串清單就足夠讓人頭皮發麻。通常你需要一個至少 3-5 人的團隊，每個人各司其職，才能勉強把產品推到市場上。

但 Josh Pigford 的案例告訴我們，這個規則已經被改寫了。他不是在「開發」五款應用，而是在用 AI 工具「組裝」和「加速」五款應用的誕生與迭代。他提到一個關鍵數字：過去需要花費數週甚至數月的功能開發，現在可以在幾小時內完成。

這不是因為 Josh 突然學會了某種失傳的武功秘笈，而是因為他掌握了「如何與 AI 高效協作」這項全新技能。他把 AI 當作一個隨傳隨到、永遠不會累、且擁有幾乎無限知識的超級實習生。差別在於，多數人還在跟這個實習生雞同鴨講，而 Josh 已經學會了如何精準下達指令，讓實習生產出他想要的成果。

這背後的核心轉變是：開發的瓶頸，已經從「寫程式的能力」轉變為「定義問題與拆解任務的能力」。你不需要會寫每一行程式碼，但你必須清楚知道你想要什麼，以及如何把一個模糊的概念，拆解成 AI 能夠理解和執行的一連串步驟。

2. 核心技能一：精準的「任務定義」與「上下文餵養」

Josh Pigford 反覆強調一個觀念：AI 不是你腦中的蛔蟲，它需要極其具體的上下文。

很多人使用 AI 寫程式時，會丟出像是「幫我做一個待辦事項應用」這種過於模糊的指令。結果 AI 產出的程式碼要嘛漏洞百出，要嘛風格完全不是你要的。Josh 的做法是，他會先花時間「餵養」AI 大量的上下文資訊。

這包含了什麼？

• 專案背景： 這個應用是給誰用的？解決什麼問題？
• 技術棧： 明確指定使用哪個框架（例如 Next.js、Tailwind CSS）、哪個資料庫（例如 Supabase、PlanetScale）。
• 程式碼風格： 他甚至會把現有專案的程式碼片段貼給 AI，讓它學習你的 coding style。
• 具體的錯誤訊息： 當遇到 bug 時，他不會只說「這個功能壞了」，而是直接把錯誤訊息、相關的程式碼區塊、以及他已經嘗試過的方法，全部餵給 AI。

為什麼這很重要？ 因為 AI 模型的上下文視窗（Context Window）是有限的，而且它對你的專案一無所知。你給的資訊越模糊，它產出的垃圾就越多。Josh 的做法就像是給一個新來的工程師一份完整的 onboarding 文件，讓他能立刻上手，而不是讓他自己去翻遍整個 codebase。

他提到一個驚人的數字：他花在「設定上下文」上的時間，可能比實際「寫程式」的時間還要多。 但這正是效率的關鍵。因為一旦上下文設定正確，AI 產出的程式碼品質會高到幾乎不需要修改，可以直接 deploy 到 production。

3. 核心技能二：將「大問題」分解成「AI 可消化的小任務」

Josh 的工作流中，最反直覺的一點是：他並沒有讓 AI 一次完成一個巨大的功能。相反地，他會把一個看似複雜的功能，拆解成數十個甚至上百個極度微小的任務。

舉例來說，如果他想做一個「使用者可以上傳頭像」的功能。傳統開發者可能會直接開始寫程式碼。但 Josh 的做法是，他會先跟 AI 對話，把這個功能拆解成：

1. 建立一個上傳檔案的 API 端點。
2. 寫一個前端的上傳按鈕元件。
3. 設計資料庫中儲存頭像 URL 的欄位。
4. 寫一個圖片縮放與裁剪的函式。
5. 處理上傳失敗的錯誤情況。
6. 寫一個測試案例來驗證上傳功能。

他不會要求 AI 一次完成以上所有步驟。他會一個一個來，確保每一步的輸出都是正確且穩定的，再進行下一步。這個過程，他稱之為「逐步驗證」。

這種方法的優點在於：

• 降低風險： 如果 AI 在某個步驟出錯，你很容易就能定位問題，而不需要從一大段程式碼中大海撈針。
• 提高品質： 每一步都經過驗證，最終的產品品質會遠高於一次生成的結果。
• 易於調試： 你可以針對某個步驟反覆調整提示詞，直到 AI 產出滿意的結果。

這其實就是軟體工程中「單元測試」和「迭代開發」的精神，只是現在執行者從人類變成了 AI。Josh 把這種方法稱為「AI 驅動的微迭代開發」。

4. 核心技能三：掌握「版本控制」與「回滾」的藝術

使用 AI 寫程式碼，最可怕的事情是什麼？就是 AI 突然發瘋，給你產出一堆亂七八糟的程式碼，然後把你的整個專案搞壞。Josh 提到，這種情況每天都在發生。

因此，他極度依賴版本控制系統，尤其是 Git。但他不只是「使用 Git」，而是建立了一套與 AI 協作時的專屬 Git 工作流：

• 每次與 AI 對話前，先 commit 一次。 確保你當前的狀態是乾淨的。
• 每次 AI 修改程式碼後，立即 review 並 commit。 如果 AI 的修改有問題，你可以輕鬆地 revert 回上一個 commit。
• 為每個功能建立獨立的 branch。 這樣即使某個 branch 被 AI 搞爛了，也不會影響到主線程式碼。

Josh 甚至會把 Git log 當作與 AI 溝通的工具。他會說：「請看最近三次的 commit，我在那個版本中做了什麼修改，然後根據那個修改，幫我實現下一個功能。」這又回到了「上下文餵養」的概念。

這項技能為何關鍵？ 因為 AI 模型是無狀態的。每次對話都是一個全新的開始。它不會記得你五分鐘前跟它說了什麼。透過頻繁的 commit 和清晰的 Git log，你實際上是在為 AI 建立一個「外部記憶體」，讓它能更好地理解專案的演進過程。

5. 核心技能四：成為「提示詞的雕塑家」

Josh 不喜歡「提示工程」（Prompt Engineering）這個詞，他覺得這聽起來太學術、太像在操作一台機器。他更喜歡把自己比喻成一個「雕塑家」，而提示詞就是他的工具。

他認為，寫出一個好的提示詞，不是一蹴可幾的。它是一個反覆雕塑的過程：

1. 初稿： 寫下一個粗略的想法。
2. 實驗： 丟給 AI，看看它會產出什麼。
3. 反饋： 指出 AI 的輸出哪裡不對，哪裡需要改進。
4. 修改： 根據反饋，調整你的提示詞，讓它更精確。
5. 迭代： 重複步驟 2-4，直到 AI 產出你滿意的結果。

他提到一個非常具體的技巧：不要害怕對 AI 說「不」。很多使用者會因為 AI 產出了一段看似合理的程式碼就欣然接受。但 Josh 會仔細審查每一行程式碼，如果發現風格不對、邏輯有瑕疵，或者只是他不喜歡某個變數名稱，他都會要求 AI 修改。

他會說：「這個函式的命名不夠直觀，改成 fetchUserPreferences。」或者「這段程式碼的效能可能有問題，請用更有效率的寫法重寫。」

這種「挑剔」的態度，正是他能維持高品質輸出的關鍵。他不會被 AI 牽著鼻子走，而是反過來駕馭 AI。

6. 核心技能五：建立「個人化的程式碼知識庫」

Josh 提到一個非常聰明的做法：他把自己過去寫過的所有好的程式碼片段、常用的函式庫、以及專案的最佳實踐，都整理成一個「個人化知識庫」。當他要開始一個新專案時，他不會從零開始，而是直接把這個知識庫餵給 AI。

這就像是給 AI 一本「你的專屬程式碼聖經」。AI 會學習你的 coding style、你偏好的設計模式、以及你過去踩過的坑。這樣一來，AI 產出的程式碼就會非常貼近你個人的風格，減少了後續大量的修改工作。

他使用的工具是 Cursor（一款 AI-first 的程式碼編輯器），它允許你將特定檔案或整個資料夾設定為 AI 的上下文。透過這個功能，Josh 可以輕鬆地讓 AI 參考他過去專案中的程式碼。

為什麼這是一個超級武器？ 因為這解決了 AI 模型的一個根本問題：通用性。通用模型學過世界上所有程式碼，但它不知道「你」喜歡怎麼寫程式。透過建立個人化的知識庫，你實際上是在 fine-tune 一個專屬於你的 AI 助手，讓它從一個「萬能實習生」變成一個「了解你喜好的資深工程師」。

7. 核心技能六：從「寫程式」到「審查程式碼」的角色轉變

這可能是 Josh Pigford 觀點中最具顛覆性的一點：他認為，在 AI 時代，一個優秀的開發者，其核心技能不再是「寫出正確的程式碼」，而是「審查 AI 寫出的程式碼」。

他把自己的角色從「生產者」轉變為「編輯」或「審查者」。他的日常工作流程變成了：

1. 向 AI 描述需求。
2. 等待 AI 產出程式碼。
3. 仔細審查 AI 的程式碼，找出潛在的 bug、安全漏洞、效能問題、以及風格不一致的地方。
4. 給出修改意見，讓 AI 修正。
5. 重複步驟 3-4，直到程式碼達到 production 等級。

他強調，這種審查能力比過去任何時候都重要。因為 AI 會犯錯，而且它犯的錯往往很「愚蠢」但又很「隱蔽」。例如，它可能會使用一個已經被棄用的 API，或者忘記處理邊界情況，或者在安全性上留下一個巨大的漏洞。

一個不懂得審查程式碼的開發者，用 AI 寫出來的程式碼只會是一顆定時炸彈。而一個擅長審查的開發者，則能把 AI 的產能放大十倍、百倍。

8. 核心技能七：保持「人類在迴路中」的決策權

Josh 反覆提醒，AI 是一個強大的工具，但它不是神。它缺乏對商業邏輯、使用者體驗、以及長期產品策略的深入理解。

因此，他堅持所有重要的決策，都必須由「人類」來做。AI 可以幫他生成十種不同的登入頁面設計，但最終選擇哪一種，必須由他根據對目標使用者的理解來決定。AI 可以幫他分析使用者數據，但數據背後的商業意涵，必須由他來解讀。

他提到一個有趣的案例：AI 曾經建議他為某個應用增加一個很酷的功能，但 Josh 拒絕了，因為他清楚地知道，那個功能會讓產品變得過於複雜，背離了產品「簡單易用」的核心價值。

這項技能的本質是：批判性思維。 在 AI 時代，能夠不被 AI 的輸出迷惑，保持清醒的頭腦，做出符合長期目標的判斷，將是頂尖人才與普通人才之間最大的差距。

9. 一個人的軍隊：具體的應用案例與數據

Josh Pigford 到底同時開發了哪五款應用？雖然影片中沒有完全揭露，但他提到了其中幾款，並給出了一些令人震驚的數據：

• 一款名為「Maybe」的個人理財應用： 這是他最早期的作品之一。他提到，在傳統開發模式下，要實現一個連接銀行帳戶、自動分類交易、並生成圖表的功能，可能需要一個團隊花費數月時間。但在 AI 的幫助下，他一個人，在幾週內就完成了 MVP（最小可行產品）的開發。
• 一款用於管理社交媒體排程的工具： 他展示了如何使用 AI 來生成貼文文案、設計圖片、以及分析貼文成效。他聲稱，AI 讓他把這個工具的開發時間縮短了 80%。
• 一款 AI 驅動的日記應用： 這個應用的核心功能是，使用者可以語音輸入日記，然後 AI 會自動幫你摘要、分析情緒、並生成回顧。Josh 表示，這個應用的後端邏輯幾乎完全由 AI 生成。

這些案例說明了，這不是一個理論上的可能性，而是已經被驗證的現實。Josh Pigford 證明了一件事：一個人，只要掌握了正確的技能，其生產力可以超越一個小型團隊。

10. 你現在該怎麼辦？從今天開始培養你的 AI 協作技能

如果你看完以上分析，感到熱血沸騰，迫不及待想開始你的「一個人軍隊」之旅，那麼 Josh 給出了非常具體的行動建議：

1. 選擇一個你真正想解決的問題。 不要為了用 AI 而用 AI，而是找到一個你充滿熱情的點子。
2. 從一個極小的功能開始。 不要試圖一次就做出一個完整的產品。先挑戰一個單一功能，例如「一個可以根據使用者輸入產生圖片的 API 端點」。
3. 強迫自己使用 AI 完成它。 即使你已經知道怎麼手動寫這個功能，也要試著用 AI 來完成。這是你練習「任務定義」和「提示詞雕塑」的最佳機會。
4. 記錄你的工作流。 把你覺得有效的提示詞、上下文設定方式、以及除錯技巧記錄下來。這會逐漸形成你的「個人化 AI 協作手冊」。
5. 加入社群。 與其他正在嘗試同樣方法的人交流。Josh 自己在 Twitter 上非常活躍，經常分享他的 AI 協作心得。

他最後拋出了一個值得所有人深思的問題：

「當每個人都能輕鬆地使用 AI 建立任何東西時，真正的競爭優勢會是什麼？」

他的答案是：獨特的觀點、深刻的領域知識、以及對使用者需求的直覺。 AI 可以幫你寫程式，但它無法替代你對這個世界的理解。未來，最有價值的不是「會寫程式的人」，而是「知道該寫什麼程式的人」。

---

觀點匯總：Josh Pigford 的 AI 協作核心技能

核心技能	具體做法	為什麼重要
精準任務定義	將模糊需求拆解成極小、可執行的步驟，並餵養大量上下文。	降低 AI 產出垃圾的機率，提高 output 品質。
微迭代開發	每次只讓 AI 完成一個小任務，並立即驗證。	降低風險，易於除錯，確保每一步都正確。
版本控制紀律	每次與 AI 互動前後都 commit，善用 branch 隔離風險。	建立 AI 的「外部記憶體」，防止專案被搞爛。
提示詞雕塑	反覆修改提示詞，對 AI 的輸出保持「挑剔」態度。	提升 AI 產出的精準度與個人風格一致性。
個人化知識庫	將過去好的程式碼整理成庫，作為 AI 的上下文。	讓 AI 學習你的 coding style，減少後續修改。
角色轉變為審查者	從寫程式轉變為審查 AI 寫的程式碼。	確保程式碼品質、安全與效能，避免潛在災難。
人類決策權	所有商業與產品策略決策，必須由人類主導。	確保產品方向符合長期目標，不被 AI 牽著走。

總結：AI 時代的「一人軍團」作戰手冊

Josh Pigford 的故事不僅僅是一個關於「如何用 AI 寫程式」的技術分享，它更像是一份關於「未來工作模式」的宣言。他證明了，當一個人願意擁抱變化，並系統性地學習與新工具協作時，過去需要整個團隊才能完成的壯舉，現在可以獨力完成。

這並不意味著團隊協作不再重要，而是代表著「個人創造力的天花板」被大幅提高了。對於科技愛好者來說，現在最需要關注的不是某個特定的 AI 模型，而是如何建立一套屬於你自己的 AI 協作系統。這套系統將決定你在未來十年，是成為被 AI 取代的勞工，還是駕馭 AI 的創造者。

最後，留給你一個值得深思的問題：如果今天你擁有一個全知全能、永不疲倦的實習生，你打算用它來解決什麼問題？

你準備好開始雕塑你的第一個提示詞了嗎？