前幾天討論到會寫程式的真開發者，他們有能力從技術選型、工作手法、程式碼等方面跟 AI 合作。

但我也想知道，真正的開發者到底怎麼用 AI 開發？於是我請 CC 做了研究，分成「開發觀察」「開發框架」「開發方針」三部分。

一、AI 開發觀察：專業開發者不 vibe，他們控制

第一份是康乃爾大學跟加州大學聖地牙哥分校的研究，標題直接就是結論：專業開發者不 vibe，他們控制。

這份研究有美國國家科學基金會的經費，過了倫理審查，資料是 2025 年 8 到 10 月收的，結果在2026年8月發表。算得上是新鮮且具有代表性的資料。

方法分成觀察與問卷：現場觀察 13 位，每人 45 分鐘看他們實際做自己的工作，再加 30 分鐘訪談；另外問卷 99 位，都是三年以上的專業開發者，平均 12.8 年經驗。

為什麼用

本來我以為不會有人研究，結果整整一節在講。

排前面的理由是加速開發（問卷 35 次提到）、能好好執行使用者的請求（36 次）。這些不意外。

意外的是另一個也排在前面的理由：99 個人裡有 36 個說，他們是因為同事跟網紅在講，好奇才去試的。

這跟我這次開始Vibe Coding的理由一模一樣：Day 3 我寫過，Fable5 放出來，所有人都在炫耀，我沒有東西可以炫耀，只有焦慮。

還有幾句情緒體感面的：

有人說寫程式又變好玩了，像第一次重新發現電腦一樣。

有人說跟手動寫程式比，AI 降低了壓力，因為焦點轉移到「怎麼組織我的提示」。

還有一位說，他在領身障給付，但 AI 讓他可以再寫程式，而且是他 25 年職涯裡最有生產力的時候。

整體享受度平均 5.11 分，滿分 6。

我最感到欣慰的事情是，無論真正的開發者或者我這種Vibe Coder，大家其實都很享受這種『控制與快』

我們可以控制自己要什麼，也可以更快看到從需求到作品的過程，於是完成作品成為一件更享受而不再是照表操課的任務了。

怎麼用

我本來猜，會寫程式的人應該是放手讓 AI 跑更遠；就像很多都會傳說寫的：某某大神只用了一兩句話，就開發好了以前要一整隊人工作好幾個月才能完成的產品。

結果相反。

他們每個提示中位數只交代 1.8 步。有兩位受訪者的計畫超過 70 步，但從不讓 AI 同時執行超過 6 步。

為什麼交代得這麼碎？因為他們要能審。

驗收方法有五種：讀 diff、命令列跑測試、用 debugger、手動操作畫面、瀏覽器開發者工具。 13 個人裡有 9 位在自己專長領域內逐一審查每一次變更，有人說接受之前讀過每一行。

我只有第四種，手動操作畫面

另外，沒有任何一位受訪者認為 AI 適合完全自主運作。 有一位的原話是：我什麼都用「輔助」的方式做，但從不讓它完全自主，我一直在讀輸出、一直在掌舵。

其實我上班時候寫分析報告也是這樣，我會用輔助寫SQL工具，會用Copilot做Excel分析，但我還是會讓它說明分析計劃，要仔細說明看了哪幾個table，怎樣做join，怎樣做驗證，每步驟管得像控制狂。我有能力用幾句話就做出複雜的分析，但不代表我不看中間過程。

用來做什麼

論文問了 99 個人哪些任務適合交給 AI。

最適合的是加速生產力、小而明確的任務、照著已經寫清楚的計畫做、重複無聊的事、樣板、寫文件、寫測試。這幾項幾乎沒有人說不適合。

最不適合的第一名是取代人在決策上的專業，12 個人說不適合，零個人說適合，是整張表裡最一面倒的一條。

看到這裡我才想明白一件事。他們把 AI 用在自己會做但不想做的事，我把 AI 用在自己不會做的事。 同一個工具，兩個相反的方向。

不想做的 vs 不會做的，很有趣的對比。

更有趣的是，當我們能夠聚焦在需求與作品，而不只是想不想與會不會。

至於速度到底有沒有變快，我本來想找一個乾脆的答案，找不到。

有隨機對照試驗發現開源維護者在可以用 AI 的情況下反而慢了 19%，而他們自己估計快了 20%；也有產業資料說 24 家公司採用之後 PR 合併率提高 39%。

這篇康乃爾的論文自己的說法是「量化證據混雜」。

這也跟我在企業裡的觀測類似：總之是不一樣，一部分造成變快，但是也因為變快我們需要更多檢驗流程，然後也想做更多事情。所以總工作時間很難說是變短還是變長。

二、AI 開發框架比較：六個框架，六個維度

第二份是巴西一位研究者做的。他從 GitHub 找出六個開發用的框架，篩選門檻寫得很清楚：一千顆星以上、近半年有推送。然後依照官方文件做六個維度的評比。

我一開始沒get這個手法，來回跟CC確認很多次，最後才忽然搞懂：這是另類的工具評比。就像我們評比新的AI模型或是新的手機一樣，拿幾個最受歡迎的工具來，用一致性的維度比拼，看哪個更符合標準。

十萬顆星那個叫 Spec Kit，我完全沒聽過。

六個維度才是我真正想帶走的東西：

他的結論是：沒有任何一個框架六格都強，流程深度跟可攜性互相排擠。

要講清楚，那份分數是作者一個人讀官方文件打的，沒有第二位評分者，論文自己在限制裡承認了。而且他本人就是其中一個框架的作者，論文有揭露。不過他給自己打的分數排中間，沒有灌水。

我請CC拿這六格量我自己，最強的是可攜性，因為我什麼框架都沒用，換一個 AI 照樣跑得完。最弱的是規格，因為我的規格活在對話裡。

三、開發方針：大公司的 Playbook 記錄了什麼

那規格怎樣文件化呢？

CC幫我檢查的第三份不是論文，是兩間公司公開的 Playbook。

我自己也有一份，四個 App 做完後跟 CC 整理的，50 條、六千多字，記的是我的需求規格跟錯誤紀錄。

中間一度我們在討論需要研究的到底是Runbook 還是 Playbook，最終定調在後者，因為我相信開發者最終都需要一個自己的Playbook

• Runbook：低層、戰術、可執行。某件重複的事的操作步驟，寫成別人照著做得出來的樣子，而且寫法要方便被自動化。
• Playbook：高層、策略。定義角色與責任、誰做什麼、怎麼溝通、何時升級、該觸發哪一本 runbook。

兩間公司的差異：thoughtbot像品控手冊、微軟則是開發手冊

thoughtbot 那份，從宗旨與價值觀、招聘、薪酬、多元共融，一路寫到 Logo 怎麼用、字體怎麼選，再到配對編程、測試驅動開發、程式碼審查、持續整合。那是一間公司的完整作業系統，看格式有點像是我以前會去看的得到App的品控手冊，每年出版一本，讓新進人員可以學習理解公司的文化，比Wiki深且實用。

微軟那份涵蓋 14 個工程領域，附檢查清單。它是真的寫給工程師看的，一開場就建議「如果你什麼都不做，至少參考工程基礎檢查清單」。

14 個領域：敏捷開發、自動化測試、CI/CD、程式碼審查、設計、開發者體驗、文件、工程回饋、機器學習與 AI、非功能性需求、可觀測性、安全性、原始碼管理、UI/UX。

是不是真的很像工程師新人訓練手冊？但它顯然就沒有要管PM或是分析師調研者等等。

兩份沒有一個具體的失敗案例。

也合理。公司出版的東西寫到誰哪天做錯了，會暴露客戶也會暴露人，所以能寫的只剩抽象原則。一個人開發沒有這個顧慮，我可以寫到「我眼殘選錯下拉選單」這種程度。

所以差別不在誰寫得好，在寫給誰看。

他們那份是寫給還沒進公司的人看的，我那份是寫給三個月後的我自己看的。

嚴格說，我那份不算 Playbook，比較像踩雷經驗談，至少不要老是踩到相同的雷。

心得

整個開發世界在改變，未來的真正開發者未必跟今天相同。我想要了解落地開發的挑戰，但沒有要讓自己變成寫程式的人，至少現在還沒有。

但我可以學下來的至少有三件事。

第一，更小、更可控制的步驟。 我的批次是功能級的，他們是 1.8 步。我做不到逐行審查，但我可以把一次交代的事情切小，讓每一段都有我看得懂的驗收點。

第二，那六個維度的開發框架。 我不會去裝 Spec Kit，但規格、角色、脈絡、執行、驗證、可攜性這六個維度我每個都答得出來，而且答案會告訴我哪一格最弱。我最弱的是規格。

第三，把自己常用的項目都放到文件裡。 這是第二點的解法。我的規格活在對話裡，而對話會斷、會超出視窗、會需要重新交代一次。那些東西本來就該在檔案裡。

三件事都不需要我會寫程式，只需要把需求想得更清楚，清楚是有形狀的。

這個系列同步寫在我的部落格：yojuhsu.com/blog

前一篇：【Day24】開發的黑盒子沒有消失，只是變成透明的了
下一篇：Day 26，推廣的心累與轉折