小編精選 - 技術文章翻譯 · 09月10日

從氛圍編碼到驅動編碼

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應走的道路。

導出的原則:
1. 原則A：避免選擇的悖論。 如果感到困惑，優先選擇簡化現有體驗，而不是增加功能。追求「單一功能的美學」，即專注於做一件事的極致。
2. 原則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作為夥伴的特性。

「憲法」和「法律」的區別

借用文中提到的比喻，マニフェスト是憲法，而樣式指南、規則和術語表則是法律。

法律（樣式指南和規則）
規定了「在這種情況下應該這樣做」的具體行為。對於已知情況非常有效，是抑制質量變異的必需。然而，在面對法律中並未涵蓋的全新情況或意外問題的時候，這會失去判斷的依據。
憲法（マニフェスト）
不關乎個別行為，而是規定所有「法律」應遵循的根本價值觀或原則。在面對未知情況時，能夠回到「我們的根本目標是什麼？」「應該優先考慮什麼？」的問題上，從而成為做出一致性判斷的指導。