🔧 阿川の電商水電行
AI能夠寫程式碼，但產品為何始終無法「完成」的唯一原因
AI能夠寫程式碼。
對於這個命題，已經很少有人提出異議了。
那麼，為什麼至今仍然難以僅靠AI編碼來讓產品「完成」呢？
「因為AI有幻覺」
「因為它只能表面性地解釋我們的語言意圖」
「歸根究底，複雜的規格要傳達過來的提示工程實在太困難」
我相信會有各種各樣的答案。
然而，這些問題可能僅僅是表面而已。
真正的問題不在於AI的「輸出」，而在於我們人類的「輸入」。
說到底，我們自己是否不知道應該完成的產品的「靈魂」以及應該將其提供給AI的「輸入」格式呢？
本文旨在探討與AI協作的真正瓶頸，同時提出產品開發的新方法，這是以往討論的集大成者。
作為幻想的「Vibe Coding」
「Vibe Coding」是什麼？
Vibe coding（ヴァイブ・コーディング）是一種新的程式設計方法，人類以自然語言（如日語或英語）發出指示，AI主導生成和修改源代碼。
該概念由AI研究員安德烈·卡爾帕希於2025年2月提出，受到了極大的關注，因為它有潛力改變軟體開發的方式。
其最大的特點在於，開發者不是深入閱讀和編寫代碼的細節，而是向AI發出「我想要這種東西」或「把側邊欄的寬度減半」等以「Vibe（ヴァイブ）」、即「氛圍」或「感覺」指令的方式。
人類基本上成為指出產品目的和大致方向的監督者，而繁瑣的實際代碼創建工作則交由AI來負責。
Vibe Coding的主要特點
- 自然語言指示: 開發者並非寫具體的代碼，而是像在聊天一樣，向AI傳達想要實現的功能或修正內容。有時也會使用語音輸入。
- AI自主生成代碼: AI能夠生成和修改代碼，理解跨文件結構的文脈，主動進行大規模的修改。
- 最小化代碼審查: 傳統開發中必須進行的嚴格代碼審查被故意省略或簡化。重點是生成的程序是否按預期運行，以「能運行就好」的姿態展開開發。
- 快速原型製作: 能夠立即將創意轉變為具體形象，因此在開發原型（樣品）或啟動新項目（PoC）中發揮出強大的效用。
與傳統方法的不同
| Vibe Coding | 傳統的AI輔助編碼 | |
|---|---|---|
| AI的角色 | 開發的主體，合作夥伴 | 開發的輔助，助手 |
| 人類的角色 | 指示、反饋、動作確認 | 設計、編碼、調試 |
| 主要工作 | 與AI對話（自然語言） | 編寫和編輯代碼 |
| 重視的點 | 開發速度、理念的具現化 | 代碼的質量、可維護性、準確性 |
以往的AI編碼輔助工具（例如早期的GitHub Copilot）主要擔任的是代碼補全或自動化常規編寫的「輔助」角色，而Vibe Coding則讓AI更主動地承擔開發的主要部分，成為真正的「夥伴」，這是兩者之間的顯著差異。
Vibe Coding的光與影
這種方法具有無法忽視的魅力。
- 優勢（光）: 令人驚歎的快速原型製作速度，讓編程經驗淺薄的人也能輕鬆上手的可接近性，並且使開發者能更加專注於創造性的工作。
然而，其光華背後隱藏著深深的陰影。
- 劣勢（影）: AI生成的代碼的質量和可維護性無法得到保證。而且更重要的是，反覆的即興指示會導致產品整體一致性的喪失。
Vibe Coding像是將理念的火星擴大的一種「引火器」。
但它無法成為持續燃燒的產品之火的「燃料」。
因為在這裡，缺乏將產品引導朝向一致方向的堅定「意志」。
從「翻譯家」轉變為「建築家」
瓶頸究竟在哪裡？
在以往的產品開發中，成功的關鍵人物是誰？
那就是在不同語言的利益相關者之間架起橋樑，將他們的需求轉化為規格的優秀翻譯者=PM和PdM。
在AI時代角色的變化
然而現在，AI已經開始以遠超人類的速度承擔這一「翻譯」的角色。
這迫使我們人類的角色必須上升到更高的層次。
不再需要單純的「翻譯家」。
所需的是能夠定義翻譯故事原作的建築家，即產品設計思想本身。
問題不在於翻譯的準確性。
而是呈遞給AI這台超高速翻譯機的「原作」的質量，也就是構成產品根基的設計思想本身，將決定成敗。
實現「Drive（欲動）」，而非「Vibe（雰囲氣）」
那麼，這個構成「設計思想」的核心是什麼呢？
在本文中，我稱之為「Drive（欲動）」。
在心理學中特別是在精神分析的文脈中，「欲動」是佛洛伊德提出的 "Trieb" 概念，這在英語中一般翻譯為 "Drive"。
它意指「衝動」「（內心湧現的）強大力量」，並與"Vibe"（雰圍）形成對比，準確表達了它內在的強大特性。
兩種力量的對比
- Vibe（雰囲気）: 容易因外部影響而搖擺不定，含糊而表面的「感覺」。隨意且缺乏一貫性，隨著當前情境不斷變化。
- Drive（欲動）: 源自於精神分析中的 "Trieb"，是深層的、穩定的內部力量。它即產品的「靈魂」，也是所有判斷的堅定標準。
產品所需「一致性」的本質
在產品開發中，個別功能或設計的「正確答案」並不存在。
始終只會有根據情況而產生的「最佳方案」。
並且，這「最佳方案」會隨著市場或用戶的變化而不斷改變。
在這不斷變化的過程中，唯一不變的應該是「Drive」。
「我們為何要創造這個產品？」
「有哪些價值是犧牲其他東西也要堅守的？」
對這些根本性問題的回答，恰恰是將無數的決策串起來，賦予產品美麗的「一致性」。
我們應該提供給AI的，並不是模糊的「Vibe」。
而是產品核心的、明確而強大的「Drive」。
【實踐】實現マニフェスト
那麼，如何將「Drive」實現於AI呢？
答案就是制定產品的マニフェスト=憲法。
在這裡，我們以一個虛構的產品為例，詳細體驗其制定過程。
示例產品定義
- 產品名稱:
CogniShelf(Cognition + Bookshelf) - 概念: 「如同寫程式碼般，記錄、培養、連結思考的地方」
- 目標: 針對文件經常散佈在本地、Notion及Google Docs的個人開發者或小型團隊。
- 解決的問題: 代碼與文檔的脫節、知識搜索性降低、團隊內部的信息碎片化共享。
第一步: 在【認知設計】中定義「Drive」
首先，將產品的靈魂語言化，並與AI共享思考的視角（世界觀）。
這將成為即將開始的漫長旅程中的羅盤。
- 動機: 我們根本的願望是，讓開發者的智力生產能從信息的「搜索」和「整理」等雜務中解放出來，更專注於純粹的「創造」活動。實現讓思考的片段不再是死信息，而是能夠成為未來靈感的資產的世界。
- 前提:
- 簡約是終極的精緻: 雖然添加功能很簡單，但真正的設計在於識別本質價值，去除多餘的部分。
- 信息不能孤立: 知識在連結中才會生成價值。工具應該促進信息的連接，而非分斷。
- 開發者的工作流程是神聖的: 新工具不應破壞現有的舒適工作流程（編輯器、Git等）。
- 目的: 開發一個具備AI自動標記和關聯功能的以Markdown為基礎的文檔管理工具
CogniShelf的原型。 - 情況: 隨著遠端工作的普及，基於文本的非同步溝通增多。結果，團隊的隱性知識有更多機會被文檔化，但它們卻分散在多個服務中，無法獲得有效利用。
- 約束:
- 用戶數據不得在未得到用戶許可的情況下發送至外部伺服器。隱私與數據所有權至上。
- 應以不依賴特定企業或平台的開放技術（Markdown, Git）為基礎。
第二步: 在【辯證框架】中提煉「原則」
接下來，通過與AI的對話，找出產品面臨的根本對立結構（反論），並從中提煉出CogniShelf應遵守的指導方針（原則）。
你（人類）: 在開發
CogniShelf時，「多功能且強大」和「終極簡單」常常對立。針對這對矛盾，請使用歷史上的思想或其他產品案例作為比喻，進行結構性分析。AI: 這是一個有趣的主題。這種對立可從哲學上的「斯多卡（克制追求精神自由）」與「伊比鳩斯（追求快樂）」的對比，或作業系統中的「Windows（多功能）」與「早期的macOS（直觀簡單）」的設計思想的差異看出，結構上是類似的。
- Windows式方法: 為了滿足所有用戶而不斷添加功能。結果，雖然多功能，但複雜化，多數用戶甚至無法充分利用10%的功能。
- macOS式方法: 持續詢問「用戶真實想要的是什麼？」刪除非本質功能。最終，為部分強力用戶提供不滿意的體驗，但能夠給大多數用戶提供直觀且舒適的體驗。那麼
CogniShelf應該選擇哪種哲學？
經過這次對話，我們找到了CogniShelf應走的道路。
- 導出的原則:
- 原則A：避免選擇的悖論。 如果感到困惑，優先選擇簡化現有體驗，而不是增加功能。追求「單一功能的美學」，即專注於做一件事的極致。
- 原則B：透過「建議」與「自動化」促進標準化。 在團隊使用中，應設計出不會強迫的優秀模板或AI自動整理，以自然產生秩序的狀態。
第三步: 以【公理系方法】記述「憲法」
最後，將導出的原則以AI無法誤解的嚴謹「公理」形式記述。
這將成為CogniShelf開發中的「憲法」，為AI自動編碼提供絕對的指導。
CogniShelf開發マニフェスト
【UI/UX的公理】
- 公理1.1: 所有功能必須設計到新用戶能在不閱讀手冊的情況下，在3次點擊內完成主要任務 (
UI.isIntuitive() -> true)。 - 公理1.2: 應用程序的響應速度不得超過人類的知覺上限100毫秒。性能優先於功能。
【數據哲學的公理】
- 公理2.1: 用戶所創建的內容的所有權完全歸用戶所有。數據必須以本地的純文本（Markdown）格式保存，並且保證用戶隨時可以自由訪問和轉移。
- 公理2.2: 用戶數據（內容、使用狀況）不得在未經用戶明確許可的情況下傳送到任何外部伺服器。
【技術與協作的公理】
- 公理3.1: 優先考慮避免與現有的開發工作流程（基於Git的版本管理、VSCode等外部編輯器的編輯）斷開，實現無縫連接。
- 公理3.2: 核心功能不應依賴於特定的AI模型或專利技術。必須保留未來用戶可選擇和更改AI模型的開放架構。
通過將這一マニフェスト提供給AI，AI將不僅僅是代碼生成機，而是理解產品的「Drive」，根據該價值觀自律地做出判斷並持續編寫一致的代碼的夥伴。
為何選擇マニフェスト？
「需求定義書、樣式指南、編碼規範以及術語表等不是更具體且重要嗎？」
「制定這樣抽象的理念有何意義呢？」
這裡，我們可能會首先提出上述疑問。
選擇將「マニフェスト」放在最高層次的原因在於兩者的角色層次與AI作為夥伴的特性。
「憲法」和「法律」的區別
借用文中提到的比喻，マニフェスト是憲法，而樣式指南、規則和術語表則是法律。
-
法律（樣式指南和規則）
規定了「在這種情況下應該這樣做」的具體行為。對於已知情況非常有效，是抑制質量變異的必需。然而，在面對法律中並未涵蓋的全新情況或意外問題的時候，這會失去判斷的依據。 -
憲法（マニフェスト）
不關乎個別行為，而是規定所有「法律」應遵循的根本價值觀或原則。在面對未知情況時，能夠回到「我們的根本目標是什麼？」「應該優先考慮什麼？」的問題上，從而成為做出一致性判斷的指導。
為何AI需要「憲法」？
這一區別對於AI這一夥伴至關重要。
如果是人類，則可以隱含地理解規則背後的「思想」和「上下文」。但AI無法做到這一點。
僅僅向AI提供具體的「法律（規則）」無法理解這些規則後面的「為什麼」。因此，在規則範圍以外的情況下，它將變得非常脆弱。
AI可以執行所要求的工作，但對於未被告知的事情，可能會提供不一致或完全錯誤的輸出。
而且，給予AI「憲法（マニフェスト）」後，面對未知問題時，它能夠回到根本原則上，自主推論出最一致且「最佳的解決方案」。
例如，如果有「公理1.1：所有功能必須設計到新用戶能在不閱讀手冊的情況下～」的憲法，當AI被指派新功能的UI設計時，就能自動選擇避免複雜的選擇，而進行直觀的設計。
這種方式遠比一個個教AI具體UI設計的「法律」要強大且靈活得多。
順序的重要性
總之，無論是樣式指南還是術語表，在保持產品質量方面都是極其重要的。
然而，它們應該是源自於確定產品「靈魂（Drive）」的マニフェスト即「憲法」的法律。
首先制定憲法，然後基於其精神制定法律（或讓AI來製訂）。
這一順序正是與這一強大夥伴AI共同完成、一致性強且能抵抗變化的產品的關鍵所在。
結論：轉變為Drive Architect
AI是我們賦予的「Drive」的忠實執行者。
設計產品的「靈魂」以マニフェスト的形式並安裝於AI，這正是AI時代產品開發的新方法。
從Vibe Coding到Drive Coding。
我們的角色將從單純的指示者=Prompter，轉變為定義產品根本價值觀並將這一思想實現於AI的靈魂設計者=Drive Architect。
在AI寫程式碼的時代，你將寫什麼，設計什麼？
這一答案正是人類所帶來的真正價值。
原文出處：https://qiita.com/makotosaekit/items/eba767a0a95bbc7b25b3
1) --- 會變成分隔線（上一行必須是空白）
2) # 會變成一級標題
3) ## 會變成二級標題
4) ### 會變成三級標題
5) **粗體文字**會顯示粗體文字
6) ```當第一行與最後一行會顯示程式碼
7) 請搜尋 Markdown 語法，了解各種格式
