過去幾個月來，我透過自己的網路觀察到一件事，而且這個感受越來越強烈：

隨著 AI 工具愈來愈強大，來自非技術背景的人，正在更多地投入軟體開發。

• 設計師正在做產品原型。
• 產品經理正在測試工作流程。
• 創業者正在打造 MVP。
• 營運人員正在建立內部工具。
• 一年前還不會把自己稱作「技術人員」的人，現在正在用 AI 把想法變得具體可見。

我真心覺得這非常令人興奮。

現在，創作從未如此容易。

我甚至參加過一場 hackathon，參賽者只有 20 分鐘就要做出一個可以展示的產品！

這也引出了一個問題：

當 AI 讓打造產品變得更容易時，我們要如何確保「理解」不會消失？

我最近發表了 Thinking in the Age of AI，這是一份給軟體工程師的指南（你可以看看我之前的文章 這裡）。

那份指南聚焦在工程師的個人反思：在使用 AI 工具的同時，如何持續培養技術直覺、推理能力與判斷力。

但情勢變化得非常快。

AI 協助開發已經不再只是工程團隊的工作流程。

它正逐漸成為所有人都能使用的「builder」工作流程。

這裡的 builder，我指的是任何使用 AI 把想法轉成類軟體產物的人：

• vibe coder
• 設計師
• 產品經理
• 創業者
• 營運人員
• 行銷人員
• 學生
• 非工程背景的團隊成員

所以我想為更廣泛的 builder 受眾，打造這套系統的新版本。

Thinking in the Age of AI: Builder Edition

這個機會是真實存在的

我不認為我們應該忽視這個轉變。

我和各種背景的人聊過，他們現在都在積極打造產品。

那些以前必須等工程資源的人，現在可以自己做出具體成果。

這改變了對話方式。

與其描述一個抽象概念，你可以直接展示一個流程。

與其寫一大篇產品規格書，你可以直接做出互動原型。

與其問「這樣可不可行？」，你可以先測試一個粗略版本。

這很有力量。

但也有陷阱。

一個原型看起來，可能比實際完成度高得多。

• 介面可能看起來很精緻。
• 按鈕可能可以互動。
• Demo 可能讓人覺得很可信。
• 生成出來的 app 可能可以在本機執行。

但軟體不只是螢幕上看到的東西。

軟體還包含：

• 資料
• 部署
• 行為
• 權限
• 邊界情況
• 安全性
• 可靠性
• 錯誤處理
• 維護
• 擁有權
• 使用者信任

AI 讓看得見的那一層更容易被做出來。

但看不見的那一層，仍然需要判斷力。

這裡有個機會，能讓工程師與非技術 builder 更好地合作。

身為工程師，我以前曾因為產品或設計決策和技術限制不一致而感到挫折。我相信不只我有這種感受。

而我也聽過非工程背景的人相反的挫折：工程師有時候看起來過度保守、動作太慢，或對一些從產品或設計角度看來很直觀的想法顯得抗拒。

很多時候，雙方其實都是在回應不完整的資訊。

隨著打造產品這件事變得越來越容易讓更多人參與，也許這正是減少這種落差的機會。

如果有正確的心態與共同語言，這個流程可以變得更有效率。

原型幻覺

我在這份指南中探討的一個概念，叫做「原型幻覺」。

當一個原型看起來比實際完成度更高時，就會發生這種情況。

原型本來就可以不完整。

它本來就可以很粗糙。

它本來就可以是假的。

問題出在：打造的人不知道哪些是真、哪些是假。

這時候，和工程師的合作就可能開始出現裂痕。

設計師可能會展示一個 AI 生成的原型，然後覺得：

「這差不多完成了。」

工程師看到同一個原型，可能會想：

「這得從頭重做。」

兩個人從各自的角度來看，都可能是對的。

問題不在原型本身。

問題在於缺少共同理解。

2 個實用練習，幫助建立共同理解

以下是 Builder Edition 指南中的兩個練習，你可以立刻開始使用。

我挑這兩個，是因為它們正好處理最常見的摩擦來源：一個原型對某個人來說很清楚，但對另一個人來說卻代表完全不同的意思。

1. 真實功能 vs 假功能地圖

這是 AI 輔助開發時，最重要的習慣之一，用來對抗原型幻覺。

在你做完原型、Demo 或 AI 生成的 app 之後使用這份表單。

所需時間：5–10 分鐘。

步驟 1 — 列出主要功能

這個原型看起來能做什麼？

1. ___________________________________________
2. ___________________________________________
3. ___________________________________________

步驟 2 — 為每個功能分類

對每個功能標示它是「真實」、「模擬」、「部分完成」或「未知」。

功能 1：___________________________________________
☐ 真實
☐ 模擬
☐ 部分完成
☐ 未知

備註：
_____________________________________________________________________
_____________________________________________________________________

功能 2：___________________________________________

☐ 真實
☐ 模擬
☐ 部分完成
☐ 未知

備註：
_____________________________________________________________________
_____________________________________________________________________

功能 3：___________________________________________

☐ 真實
☐ 模擬
☐ 部分完成
☐ 未知

備註：
_____________________________________________________________________
_____________________________________________________________________

步驟 3 — 辨識幻覺

哪一部分看起來比實際完成度更高？
_____________________________________________________________________
_____________________________________________________________________

如果有人看了這個 Demo，可能會誤解什麼？
_____________________________________________________________________
_____________________________________________________________________

在展示之前，我應該明確說明什麼？
_____________________________________________________________________
_____________________________________________________________________

步驟 4 — 釐清下一步

在這個東西變成真正的軟體之前，還需要做什麼？
☐ 產品驗證
☐ 設計調整
☐ 工程審查
☐ 資料庫設計
☐ 身分驗證
☐ 權限處理
☐ API 整合
☐ 測試
☐ 安全性審查
☐ 效能審查
☐ 部署設定
☐ 其他：
_______________________________

最重要的下一步：
_____________________________________________________________________
_____________________________________________________________________

2. 工程交接模板

這可能是團隊中最實用的練習。

最好的交接，不是完美的程式碼。

最好的交接，是清楚的脈絡。

當你要請工程師根據 AI 生成的原型進行審查、重做、擴充或估工時時，使用這份模板。

所需時間：10–15 分鐘。

交接摘要

功能或原型名稱：
_____________________________________________________________________
_____________________________________________________________________

一句話摘要：
_____________________________________________________________________
_____________________________________________________________________

目標使用者是誰？
_____________________________________________________________________
_____________________________________________________________________

這個功能解決了什麼問題？
_____________________________________________________________________
_____________________________________________________________________

原型狀態

使用以下工具打造：
_____________________________________________________________________
_____________________________________________________________________

使用的 AI 工具：
_____________________________________________________________________
_____________________________________________________________________

目前哪些部分可用？
_____________________________________________________________________
_____________________________________________________________________

哪些部分是模擬的？
_____________________________________________________________________
_____________________________________________________________________

哪些部分還不完整？
_____________________________________________________________________
_____________________________________________________________________

已知哪些部分脆弱？
_____________________________________________________________________
_____________________________________________________________________

產品意圖

核心使用流程：
1. __________________________________________________________________
2. __________________________________________________________________
3. __________________________________________________________________
4. __________________________________________________________________

必要行為：
_____________________________________________________________________
_____________________________________________________________________

加分但非必要的行為：
_____________________________________________________________________
_____________________________________________________________________

成功判準：
_____________________________________________________________________
_____________________________________________________________________

技術上的未知

我需要協助理解：
☐ 資料庫結構
☐ 身分驗證
☐ 權限
☐ API
☐ 部署
☐ 安全性
☐ 效能
☐ 測試
☐ 可維護性
☐ 與既有系統整合
☐ 其他： ______________________________

具體問題：
1. __________________________________________________________________
2. __________________________________________________________________
3. __________________________________________________________________

審查需求

我需要哪種回饋？
☐ 這在技術上可行嗎？
☐ 哪些部分需要重做？
☐ 你看到了哪些風險？
☐ 最簡單且可靠的實作方式是什麼？
☐ 哪些東西不應該直接上線？
☐ 哪些假設是錯的？
☐ 大概的複雜度如何？
☐ 在它成為工程工作之前，我還需要釐清什麼？

最重要的工程問題：
_____________________________________________________________________
_____________________________________________________________________

工程師希望非技術 builder 知道的事

指南中有一個章節叫做「工程師希望你知道的事」。

工程師通常不是想拖慢你。

當他們詢問邊界情況、權限、資料、安全性或失敗狀態時，他們不是在否定你的想法。

他們是在思考：當這個想法真的變成產品時，會發生什麼事。

能運作的 Demo，不等於可正式上線的軟體。

看起來很簡單的功能，背後可能隱藏著複雜的系統。

AI 生成的原型可以大幅改善合作。

但前提是，它們必須被誠實地呈現。

這種誠實會建立信任。

那軟體工程師會變成什麼樣子？

這是我還在持續思考的部分。

如果更多人都能做出類軟體原型，那世界是否還需要更少的軟體工程師？

在某些領域，或許是。

但我懷疑的是，這個角色更可能是轉變，而不是消失。

軟體工程師的價值，可能會更進一步轉向：

• 系統設計
• 技術判斷
• 可靠性
• 安全性
• 整合
• 可維護性
• 審查 AI 生成的作品
• 協助團隊理解取捨
• 把原型轉成可長期運作的系統

換句話說，工程師可能會花更少時間成為「唯一能做出第一版的人」。

但會花更多時間成為那些能讓軟體真正落地、夠安全、夠可靠、可維護的人。

這是一種不同的槓桿效應。

這也意味著，非技術 builder 與工程師都需要更好的合作模式。

未來也許不是「工程師對上 vibe coder」。

它可能會是：

builder 更早產出更具體的想法，而工程師則協助把正確的那些想法變成真正的系統。

但要做到這件事，雙方都需要共同理解。

我整體上是樂觀的，但不是因為我認為這個轉變會很容易。

工具改變時，工作也會跟著改變。

MIT 2024 年的一項研究估計，今天人們從事的工作中，大約有 60% 在 1940 年根本不存在。這並不代表 AI 會自動帶來更好的結果，但它提醒我們：當技術改變時，職位也會跟著演化。

我身為工程師的策略，是成為一個更廣泛的通才：一個能理解產品、系統、AI 工作流程，以及跨領域合作的人。

為什麼我寫這份指南

我寫 Thinking in the Age of AI: Builder Edition，是因為我認為這個轉變太重要了，不能忽視。

AI 輔助開發已經來了。

非技術 builder 已經在打造軟體。

這不會消失。

問題在於，我們要不要為此建立更好的習慣。

這份指南包含工作表、檢查清單、提示詞與反思卡，幫助 builder：

• 理解 AI 產出了什麼
• 分辨真實功能與模擬行為
• 找出隱藏的技術風險
• 避開常見的 vibe coding 陷阱
• 更早發現邊界情況
• 準備更好的工程交接
• 知道什麼時候需要審查

目的不是讓人害怕用 AI 開發。

目的是幫助大家更清楚地打造產品。

AI 可以生成原型。

builder 必須生成清晰度。

討論

我很好奇其他人是怎麼看待這個轉變的。

對非技術 builder：

• 你在用 AI 開發時，最不確定的是哪一部分？
• 是程式碼品質、資料、安全性、部署、邊界情況，還是不知道什麼時候該找工程師？

對工程師：

• 你如何看待設計師、PM、創業者或其他非技術 builder 提供的 AI 生成原型？
• 什麼樣的交接會讓你覺得有幫助，什麼樣的交接會讓你覺得困擾？

對所有人：

你認為未來世界會需要更多軟體工程師、更少軟體工程師，還是只需要不同類型的軟體工程師？

如果你想探索完整的練習、提示詞與工作表，可以在 這裡 免費取得這份指南。

原文出處：https://dev.to/javz/from-vibe-coding-to-clear-thinking-what-non-technical-builders-need-in-the-age-of-ai-4nbd