斜槓時刻・9：首先，你要有一個無條件相信你能的人
文科寫程式，先找一個無條件相信你能的人・怎麼指揮 AI 幫你寫程式・SASS, AI Agents or Both？
做人要能瞎矇，就瞎矇，生活儘量放輕鬆。
——《鹿鼎記》
文科寫程式，先有無條件相信你能的人
在 Appworks AI Founder L&L 閒聊，負責校友的 Natasha 問，寫程式的第一步是去上課嗎？另一位也在用 AI 寫 Code，但是是行銷背景的校友認為，是先去上課，學會變數、迴圈等概念。但身為一個資深工程師的我說，「不是，是先有一個無條件相信你能的人」。
為什麼這麼說？因為學程式最重要的不是知識，而是信念和支持。對初學者來說，錯誤訊息、卡住不動的 Bug 是常態，這很容易讓人懷疑自己不適合。如果這時有一個人不斷鼓勵你，或者你自己相信「我一定可以」，那股力量就會帶你撐過困難，讓你持續學習。
然而，許多人在一開始就被自己的心態限制住了，覺得「我數學不好，肯定學不會程式」、「我邏輯不夠好，寫程式太難了」、「我年紀大了，學新東西太慢」，這些自我設限的想法就像一堵無形的牆，把你和成長的機會隔開了。其實，學程式從來不是天才的專利，而是一種透過反覆試錯、逐步累積的過程。
如果你願意打破這些思維框架，把每一次失敗都當成學習的機會，把每一個 Bug 當成挑戰自己耐心的遊戲，那麼你會發現自己其實比想像中更有潛力。學程式不在於「天生適合」或「完美邏輯」，而在於相信自己有能力解決問題，並在一次次嘗試中找到方法。
朋友 Pei-Chi Lo，最近在聯發科基金會辦了一場專給老師參加的 AI 工作坊。結果短短一天內，70 位老師就做出了他們教學現場能用得上的小工具！這些老師原本都沒什麼寫程式或資訊背景，可是透過 ChatGPT、windsurf、cursor、websim 等 AI 工具，他們很快就上手了。
其中有位在中途學校教書的老師，一直得處理一大堆學生的個案照片，結果他竟然自己寫出一套能批量打馬賽克的工具，既省時間又能好好保護學生的隱私。
甚至有人說：
「我知道我能諮商 我能生小孩 #但我不知道我能寫程式。」
「用AI Coding寫出了人生第一個程式 當下的喜悅比生小孩還開心」
好奇的人可以點擊這邊看有哪些成果。
怎麼遇到無條件相信你能的人呢？
你可以去 Generative AI 社群讀書會 - Code With AI / 用 AI 寫程式找我，我很擅長當誇誇鼓勵師，當然也可以跟我線上預約時間聊聊。
Always surround yourself with people who believe you can succeed.
怎麼指揮 AI 幫你寫程式
最近把 Cursor 退訂閱了，因為 Windsurf 比較接近我想想中的與 AI 開發協作，方式類同文學編程。文學編程（Literate Programming）是一種程式設計典範，由著名的電腦科學家 Donald Knuth 在 1980 年代提出。這種方法融合了程式碼和敘述性文本，以提高軟體的可讀性和可維護性。(延伸：AI 時代的文學程式設計)
在文學編程的框架下，程式設計師以人的思維模式來寫程式，而非依據電腦的運行邏輯。程式碼和註解的組織方式以敘述性的文本為主，故名「文學編程」。這種方式讓開發者可以將程式設計的思維過程詳細記錄下來，讓後來的讀者更容易理解並維護程式。
不過現在看起來，會更像嘴砲工程師，95% AI，5 %自己修 Bug，還有生氣 AI 怎麼講過的錯誤還一直犯⋯⋯
一位女工程師看到我怎麼用 Windsurf 做 git commit, 修 bug 的結果非常羨慕，但是她 Github Copilot 買了一年份，要等 Copilot 用完再買比較不浪費。
買 AI 工具，千萬不要買一年份。
朋友 HLB 下週揪了一場聚會「AI Coding Tools + SDLC (Software Development Life Cycle) Meetup」，歡迎參加。
參加條件是下面的工具用過 20 小時以上：
Aider
Amazon Q Developer
Cline
Cursor AI
Codeium / Windsurf
Devin
GitHub Copilot
GitHub Workspace
Replit AI
Zed AI
SASS, AI Agents or Both？
上週在 Appworks Founder L&L 聊天時，我們就討論到一個很有趣的問題：未來的市場究竟是由「大 SaaS」繼續主導，還是會出現一大堆 AI Agent 把不同的 SaaS 串在一起，提供更有彈性的整合體驗？下面是我的觀點。
雖然現在市面上各種 AI 新創如雨後春筍，從各式 Agent 到 LLM 技術都有，但要真正讓這些能力落地到企業日常運作其實沒那麼簡單。高昂的訓練成本、從試驗到上線的巨大落差，加上企業對新科技接受速度不算快，這些因素都拖慢了 AI 實際發揮的腳步。
不過，技術遲早會成熟，成本也會降下來。到那時，AI 就像水電一樣自然融入生活，我們不會再特別強調「這是 AI 技術」。問題是，屆時會是大 SaaS 一家獨大，還是各路專精領域的 AI Agent 串接多個 SaaS 工具，為大家提供客製化的「生活風格公司」體驗？我認為答案是兩者並存。
在程式設計、行銷、內容創作、遊戲開發這類已經被 AI 深度滲透的領域，未來只會有更多 AI Agent 跳出來，靈活整合各式工具，滿足不同使用者的多元需求。正如 Greg Isenberg 所說的：「if I was betting my career on one thing right now, it would be AI agents. literally a trillion dollar market up for grabs.」
未來市場空間確實相當巨大。
此外，No Code Platform 可能在這種趨勢下逐漸消失，因為隨著 AI 發展，人們能用自然語言生成程式碼，甚至不再需要中間工具。非技術人員也能自行撰寫程式來自動化流程，讓過去仰賴 No Code 工具的用戶有了更直接、靈活的途徑。
我們不必非選邊站。大 SaaS 與 AI Agent 可以並存，AI 成為基礎設施，讓一般人自然使用這些智慧工具，最終也不必在意背後有多少 AI 技術。
近況
在 Code with AI 與 In2 閒聊，她認為未來每個專案的 README.md 都不會是寫給人看的，甚至是教學文件也會是 prompt。因此受她啟發，我就想說想「文件先行」的方式去開發看看，採用一套以「規範文件」為核心的開發流程，成效相當不錯。
首先，我先在 SPEC.md (link)裡面明確定義所有功能需求、型別安全的要求，以及錯誤處理的原則，以此作為整個專案的基礎標準。有了這份文件，我在開發時能始終維持清晰的方向，也能隨時對照規範，檢視自己是否偏離初衷。
接著，我再準備一份 CODINGSTYLE.AI.md (link)，這份文件是特別給 AI 看的，裡頭有程式碼風格和架構的細節指引。這麼做是為了讓 AI 在產出程式碼時，更容易符合我們既定的風格、錯誤處理流程和型別安全標準。
在開始實作新功能時，我會請 AI 先參考 SPEC.md，確保新功能的行為與已定義的規範一致，再引導它照著 CODINGSTYLE.AI.md 的規定產出程式碼。接著，我會仔細檢視程式碼，若發現與原訂標準有落差，就回頭調整相關文件或要求，確保成果不會偏離初衷。這種先訂規範、再生成程式碼，最後再驗證與回饋的循環，讓整個開發過程更順暢有效率，也確保程式碼品質與可維護性都能達到理想狀態。
然而這方式的問題是，Windsurf 的 credits 一下就用完了，雖然可以在刷 10 美金買 Flex crets ，但很明顯能感受到模型變笨。
朋友 Ly 說：
沒錢還想要聰明
只好說，我錯⋯⋯
記得幫我按讚加分享，也記得請我喝杯咖啡，如果有需要，歡迎雇用我當你的暫時技術共同創辦人。有需要可先跟我預約公益時數聊聊。謝謝大家，我們下週見!