Vibe Coding 評測實錄:功能說明書讓 AI 更穩,也更自信

作者:產品AI力學
日期:2026年5月12日 下午7:31
來源:WeChat 原文

整理版優先睇

速讀 5 個重點 高亮

功能說明書令Vibe Coding更穩更快,但欠挖掘深層需求

整理版摘要

呢篇文章係作者Vibe Coding評測系列嘅第二部分,專注測試功能說明書口吻嘅輸入方式。作者直接將功能點、邊界同非功能要求寫成類似工程任務單嘅文本,觀察AI(Codex)如何反應。整體結論係:功能說明書口吻令AI更快進入工程邊界,直接追問持久化方案、公網部署等硬約束,輸出好快變成可執行規格。但呢種方式嘅風險係AI會顯得過於自信,侷限於當前文本,缺少用戶故事模式嗰種「將人冇講出口嘅需求挖出來」嘅能力。作者俾咗6分(滿分10分),認為佢更穩更快,但深度不足。

測試過程中,AI首先抓住「不接受僅前端localStorage方案」呢句硬約束,提出三種後端方案。作者補充公網部署需求後,AI馬上問賬號體系,補齊註冊登錄、跨端恢復同多端共享狀態。界面討論亦更收斂,直接推薦B Workbench呢種高信息密度介面。最終規格包括產品形態、技術方案、狀態規則、數據規則同體驗規則,清晰得像一份可執行文檔。

比較之下,用戶故事模式更擅長引導AI思考用戶場景同長期擴展,而功能說明書模式就適合將已經諗清楚嘅需求快速推向編碼。作者話下期會進行復盤分析,對比兩組過程同結果,懇請讀者畀意見。

  • 功能說明書口吻令AI更快抓住硬工程約束,直接追問持久化方案,而唔係先討論用戶場景。
  • AI默認推薦SQLite,但作者點出呢個選擇對PM嚟講冇價值,因為PM關心嘅係部署同擴展。
  • 公網部署呢個需求觸發AI討論賬號體系,補齊咗註冊登錄、跨端恢復同多端共享狀態。
  • 功能說明書輸出似可執行規格,但缺少用戶故事模式嗰種挖掘隱含需求嘅能力,會有局部最優解嘅風險。
  • 作者建議:功能說明書適合將已諗清楚嘅需求快速推向編碼,整體評分6分,下期會同用戶故事模式做復盤對比。
整理重點

測試設定:功能說明書口吻

今次測試係Vibe Coding評測嘅B組,輸入方式係

功能說明書口吻

——將功能點、邊界同非功能要求寫成類似工程任務單嘅文本。作者想觀察呢種寫法會唔會令AI更少跑偏,更快進入可編碼狀態。

過程實錄顯示,AI第一問就落到

持久化方案

,抓住咗

硬約束

不接受僅前端localStorage方案」。AI提出

三個選擇

Node/Express + SQLitePostgres、已有指定後端/數據庫棧。作者補充話未來會部署到公網,AI即刻推進。

整理重點

階段2過程實錄

一旦提到

公網部署

Codex馬上將問題推進到

賬號體系

,同A組(用戶故事模式)嘅問題重複,但呢個係功能說明書下自然嘅反應。

界面討論方面,Codex用visual-companion給出三種界面方向,推薦

B Workbench

,因為信息密度更高,能同時展示任務名、階段、輪次同今日完成數,移動端再摺疊成單列。確認後的方向迅速成型:

  1. 1 產品形態:公網可訪問嘅多用戶番茄計時器
  2. 2 技術方案Next.js + Postgres + Prisma + Cookie Session
  3. 3 狀態規則:同賬號共享一個當前計時器
  4. 4 數據規則:今日完成數按用戶同日期保存
  5. 5 體驗規則:登錄後第一屏就係計時器,唔做營銷首頁

呢份輸出唔似上一篇咁反覆解釋「用戶點解需要佢」,而係更像一份

可執行規格

,範圍、賬號、計時規則、接口、錯誤處理、測試策略、部署假設都齊曬。

整理重點

風險與侷限:AI太自信,唔識追問長期方向

功能說明書口吻有一個重要風險:AI會過於自信,只基於當前文本畀出

局部最優解

,而唔識追問長期產品方向。

作者總結:呢種模式適合將已諗清楚嘅需求快速推向編碼,穩定性同速度都比用戶故事模式高,但缺乏「將人冇講出口嘅需求挖出來」嘅能力。作者俾咗

6分

(滿分10分),認為佢更穩更快,更像工程輸入,但深度不足。前情回顧:目前投票係5:5平局,讀者可以去作者嘅產品集網站體驗用戶故事模式下做出嚟嘅產品原型。下期會對兩輪進行復盤分析。

呢篇記錄咗今次 Vibe Coding 評測入面,B組:功能說明書嘅語氣進入階段2嘅過程。

同上一篇用戶故事唔同,今次嘅輸入一開始就更加似‘俾工程師睇嘅任務單’:功能點、邊界、非功能要求都寫得比較硬。我想觀察嘅係:呢種寫法會唔會令AI冇咁易走偏,亦更快進入可以編碼嘅狀態。

圖片

過程實錄

1. 第一條問題直接落到持久化

Codex 冇先傾‘用戶係邊個’,而係捉住咗功能說明書入面最硬性嘅一句話:唔接受淨係前端 localStorage 方案

佢俾咗三個選擇:Node/Express + SQLite、Postgres、或者已經指定咗後端/數據庫棧。

呢個問題好典型。功能說明書會將AI嘅注意力先拉去約束條件,而唔係場景。

我補咗一句:將來會部署到公網,需要極簡單嘅註冊同登入,方便多端訪問,亦方便朋友試用。

2. 公網部署觸發咗賬號同狀態邊界

一旦我話‘部署到公網’,Codex 即刻將問題推進到賬號體系,呢個同A組係重複問題,唔再重複。

3. 介面討論明顯更收斂

隨後 Codex 用 visual-companion 俾出三種介面方向,並推薦 B Workbench:資訊密度更高,可以同時顯示任務名、階段、輪次同今日完成數,移動端再摺疊成單列。

呢個同A組實驗嘅效果都類似,唔再重複喇。

圖片

4. 最終規格更加似工程輸入

確認咗之後嘅方向好快成型:

  • • 產品形態:公網可以訪問嘅多用戶番茄計時器;
  • • 技術方案:Next.js + Postgres + Prisma + Cookie Session;
  • • 狀態規則:同一個賬號共享一個當前計時器;
  • • 數據規則:今日完成數按用戶同日期保存;
  • • 體驗規則:登入之後第一版就係計時器,唔做營銷首頁。

呢份輸出唔似上一篇咁反覆解釋‘用戶點解需要佢’,而係更加似一份可執行規格:範圍、賬號、計時規則、接口、錯誤處理、測試策略、部署假設都齊曬。

階段2過程觀察

觀察點
評價
直接追問持久化方案
有價值。硬性約束俾AI好快捉住。
默認推薦 SQLite
對PM冇價值
公網部署觸發賬號體系
關鍵提升。註冊登入、跨端恢復、多端共享狀態都俾佢補返出嚟。

總體評價

1. 功能說明書語氣確實令AI更快進入工程邊界。

佢見到約束就拆約束,見到持久化就問技術方案,見到公網就補賬號體系。對 Vibe Coding 嚟講,呢個好有幫助,因為AI後面寫程式碼最怕嘅唔係文案唔優美,而係狀態、數據、邊界冇講清楚。

2. 佢嘅風險在於:AI會顯得太過自信。

如果PM原文漏咗長期產品方向,AI唔一定會好似用戶故事模式咁主動追問‘將來係咪仲要擴展’。佢更加可能基於當前文本俾出一個局部最優解。

所以呢一輪我嘅結論係:

功能說明書適合將已經諗清楚嘅需求快速推向編碼。

滿分10分,呢份階段2輸出我俾6分。

佢更穩、更快、更加似工程輸入;但係少咗啲‘將人冇講出口嘅需求挖出嚟’嘅能力。

前情回顧

1. 呢個投票可以繼續,目前係5:5平手

2. 可以去我嘅呢個產品集網站體驗一下用戶故事模式下做出嚟嘅產品原型:https://stemlearn.cloud/

功能說明書嗰個我就唔放出嚟喇,分別係缺少咗用戶故事模式提醒出嚟嘅點。

下一期我會對呢兩輪嘅過程同結果進行復盤分析,懇請各位俾啲批評指正。


這篇記錄的是本次 Vibe Coding 評測中,B 組:功能說明書口吻進入階段 2 的過程。

和上一篇用戶故事不同,這次輸入一開始就更像“給工程師看的任務單”:功能點、邊界、非功能要求都寫得比較硬。我要觀察的是:這種寫法會不會讓 AI 更少跑偏,也更快進入可編碼狀態。

圖片

過程實錄

1. 第一問直接落到持久化

Codex 沒有先聊“用戶是誰”,而是抓住了功能說明書裏最硬的一句話:不接受僅前端 localStorage 方案

它給了三個選擇:Node/Express + SQLite、Postgres、已有指定後端/數據庫棧。

這個問題很典型。功能說明書會把 AI 的注意力先拉到約束,而不是場景。

我補了一句:未來會部署到公網,需要極簡註冊登錄,方便多端訪問,也方便朋友試用。

2. 公網部署觸發了賬號和狀態邊界

一旦我說“部署到公網”,Codex 馬上把問題推進到賬號體系,這和A組是重複問題,不做贅述。

3. 界面討論明顯更收斂

隨後 Codex 用 visual-companion 給出三種界面方向,並推薦 B Workbench:信息密度更高,能同時展示任務名、階段、輪次和今日完成數,移動端再摺疊成單列。

這跟A組實驗的效果也類似,不再贅述了。

圖片

4. 最終規格更像工程輸入

確認後的方向很快成型:

  • • 產品形態:公網可訪問的多用戶番茄計時器;
  • • 技術方案:Next.js + Postgres + Prisma + Cookie Session;
  • • 狀態規則:同賬號共享一個當前計時器;
  • • 數據規則:今日完成數按用戶和日期保存;
  • • 體驗規則:登錄後第一屏就是計時器,不做營銷首頁。

這份輸出不像上一篇那樣反覆解釋“用戶為什麼需要它”,而是更像一份可執行規格:範圍、賬號、計時規則、接口、錯誤處理、測試策略、部署假設都齊了。

階段 2 過程觀察

觀察點
評價
直接追問持久化方案
有價值。硬約束被 AI 很快抓住。
默認推薦 SQLite
對PM沒有價值
公網部署觸發賬號體系
關鍵提升。註冊登錄、跨端恢復、多端共享狀態都被補出來。

總體評價

1. 功能說明書口吻確實讓 AI 更快進入工程邊界。

它看到約束就拆約束,看到持久化就問技術方案,看到公網就補賬號體系。對 Vibe Coding 來說,這很有幫助,因為 AI 後面寫代碼最怕的不是文案不優美,而是狀態、數據、邊界沒說清。

2. 它的風險在於:AI 會顯得過於自信。

如果 PM 原文漏掉長期產品方向,AI 不一定會像用戶故事模式那樣主動追問“以後是不是還要擴展”。它更可能基於當前文本給出一個局部最優解。

所以這一輪我的結論是:

功能說明書適合把已想清楚的需求快速推向編碼。

滿分 10 分,這份階段 2 輸出我給6分。

它更穩、更快、更像工程輸入;但少了一點“把人沒說出口的需求挖出來”的能力。

前情回顧

1. 這個投票可以繼續,目前是5:5平局

2. 可以去我的這個產品集網站體驗一下用戶故事模式下做出來的產品原型:https://stemlearn.cloud/

功能說明書的我就不放出來了,區別主要是缺少了用戶故事模式提醒出來點。

下期我會對這兩輪的過程和結果進行復盤分析,懇請各位給予批評指正。