前言

你有開過SPEC嗎？

當使用者跟你說：「我這邊想要看到一個卡片顯示上次資訊」，你能不能冷靜的將對方模糊的需求方向，畫成一張詳盡的地圖？

作為工程師，總是會遇到一些很模糊的需求，常常有人覺得只要跟你講個故事，你就能把功能生出來

昨天剛好想到一個功能，只是一個想法，今天就來把這個想法實作，然後講一下自己與 AI 溝通的心得

這個想法是：

「我想馬上知道上次活動紀錄，我做了多久」

需求討論 → SPEC：從一條模糊的需求開始

「使用者想要在畫面上加一塊區域 顯示上次活動紀錄的資訊」 如果PM劈頭看見你就這樣跟你說，你要怎麼跟對方接著溝通？

常常一個不注意就出現下面兩種狀況：

1. 工程師腦補細節⇒做出來跟使用者想的不一樣。
2. 花很多時間開會對齊 ⇒ 就算順利還是會有時間浪費。

這就是為什麼 SPEC（規格文件）重要。因為可以濃縮到一句話的需求，肯定需要收斂成一本明確的指南。

在AI時代，我們可以依賴AI來做這件事，但是有沒有什麼要注意的呢？

以下搭配我開發的例子來說明幾條，自己摸索出的心得

不論是開SPEC還是開發，不追求一次到位

首先，我們要把模糊的需求慢慢的明確，為此我們可以透過對話的方式，以AI為鏡釐清需求

不是請AI直接開SPEC，而是確保雙方都了解，這次的需求要做什麼

否則不管你討論的人、或是 AI 模型再怎麼厲害都是空談。

使用 AI 開發的工程師 = 裁判 + 守門員

在討論的過程中，工程師必須作為裁判(SA的角色)，去為功能的方向拍板定案

同時也要針對得到的答案做守門(CodeReview的角色)，當出現資料不正確、或是不符合業務邏輯等狀況時，必須及時為AI做補充/更正

AI 也可以講故事、講動機

工程師聽完使用者講的故事後，對於該怎麼實作都會有一些自己的判斷，AI也是

讓AI理解這個需求背後的目的，也許能夠為你將產出的功能、SPEC 提供一些你沒想到的解方

比如這裡，我就得到了「激勵使用者紀錄」的這一回饋。

把 AI 當作同事，而不是 Google 搜尋

其實這點跟「講故事、講動機」有點類似，如果你直接劈頭就跟 AI 說 「如何顯示上次活動紀錄 spec」，高機率你只會得到一些模板或是跟你專案背景無關的答案，浪費時間。

但如果你把它當作同事，在對話時增加更多上下文、保持耐心對話直到有共識，最終產出的結果肯定會比較好。

有句話是這樣說的「慢慢來，比較快」

還好 AI 也沒有女朋友

錯誤與 Bug 是過程的一部分

寫到這邊，我發現跟 AI 討論需求的這些心法，完全可以套用在其他任何開發工作上，總之

要接受就算是 AI 也會出很多錯，尤其是你忘記提醒它一些事情的時候

像是我在開發過程中，Repository 層老是拋 SQL 查詢錯誤（例如 PostgreSQL 不支援 date = varchar 的直接比較），就算 AI 寫的很合理，看起來沒問題，不代表不會出錯。

總結

• 不論是開 SPEC 還是開發，不追求一次到位
• 使用 AI 開發的工程師 = 裁判 + 守門員
• AI 也可以講故事、講動機
• 把 AI 當作同事，而不是 Google 搜尋
• 錯誤與 Bug 是過程的一部分

我自己根據上面心法下去開發，流程大概會長這樣：

1. 提出需求（有人拋出一個想法 / 問題）
2. 提問釐清（對方問問題，幫助把需求講清楚）
3. 補充與選擇（補充細節、比較不同做法）
4. 收斂決策（選定一個方案）
5. 產出

（中間會有一堆 Bug 或錯誤要解決，但這就是開發的一部分）