iT邦幫忙

2026 iThome 鐵人賽

DAY 5
0
Vibe Coding

透過 vibe coding 製作一套基於社群打造的互動式遊戲系列 第 9

[#009]收到一個好點子之後,先把它變成可以判斷的計畫

  • 分享至 

  • xImage
  •  

上一篇文章,我談到自己想聽見什麼樣的回饋。

比起只有「很好用」或「不喜歡」,我更想知道朋友在哪裡產生興趣,又在哪裡卡住。這些具體經驗,能幫助我理解自己的設計到了別人手上,實際是什麼樣子。

但聽完之後,還有下一個問題:這些意見要怎麼處理?

有些是既有系統的問題,有些是新的使用方式,也有些會讓我覺得:「這個想法滿有趣的,好像可以做。」

如果每個點子都立刻開始做,很容易同時開了很多事情。可是假如只在聊天當下覺得不錯,之後沒有留下來,也可能過一陣子就找不到了。

所以,我想在收到建議和開始開發之間,留一個整理與判斷的步驟。

先分清楚,是卡住了,還是想多做一點
微光是一個建立在 Discord 上,結合交流、學習與奇幻世界觀的社群。隨著裡面的系統逐漸被使用,成員提出的意見,也可能來自不同情況。

有人原本正在用一個功能,卻因為問題無法繼續。也有人用得很順利,只是想到:「如果再多一個功能,會不會更方便?」

兩種意見都值得聽,但對我來說,需要分開處理。

目前我認同的方向,是先處理讓既有使用者卡住的問題,再替新點子留空間。原本已經在用的東西出了狀況,應該先讓它恢復到能正常使用的狀態,而不是只顧著往裡面增加內容。

至於新功能,則需要多想一步。它適不適合微光目前的方向?是在改善一個實際困難,還是另一件可以獨立嘗試的事情?

有趣,可以成為留下這個想法的理由,但不一定是立刻開發的理由。

用 /todo 把建議接住
目前微光裡有一個 /todo 指令。

當我看到成員提出值得留下的建議或意見,可以直接指定收錄。接著,LLM 會根據目前微光的現況,以及成員提供的內容進行綜合評估,整理成一份簡易計畫書,存到我的待辦事項裡。

這個流程讓建議有了一個之後能回頭查看的位置,不必只靠我記得某次聊天大概說過什麼。

而且,它不只是把一句「可以做這個」複製進清單。透過整理,我希望之後重新打開時,能比較容易理解這個建議在處理什麼事情,以及它和微光現有設計有什麼關係。

這裡也有一個範圍:由我指定要收錄的內容,不是把成員每一句討論都自動變成工作。

聊天裡可以有隨口的想法,也可以有還沒想清楚的意見。先留下哪些,是需要做的選擇。

計畫書先幫助理解,不急著給出結論
把建議整理成簡易計畫書,對我來說,是讓它變得比較容易判斷。

例如,成員說某個操作很麻煩,也提出了一個解法。我會想知道,麻煩主要發生在哪個地方,以及他建議的方式,和目前的系統能不能接得起來。

有時候,成員提出的方法很值得採用。有時候,真正值得處理的是他遇到的困難,但解法可以再想。

如果沒有先把這些事情分開,很容易一看到具體建議,就直接照著做,反而忘了確認原本的問題。

我希望計畫书能把這些脈絡整理出來。即使最後還有資訊不足、需要再確認的部分,也可以留在裡面,不必為了讓文件看起來完整,就先替未知的事情下結論。

等到我要決定下一步時,至少有一份具體內容可以看,而不是只剩「好像有人提過一個不錯的點子」。

LLM 協助評估,決定仍然由我來做
在這個流程裡,LLM 的工作是協助整理與綜合評估。

它可以把成員的意見和微光的現況放在一起看,幫我減少重新整理脈絡的負擔。但一份計畫書寫得清楚,不代表裡面的判斷就一定正確。

它仍然可能漏掉背景,也可能把尚未確認的需求理解得太確定。因此,最後要不要做、什麼時候做,還是由我決定。

我想保留這個分工:整理可以借助 LLM,取捨則要回到我對微光的方向、現有問題與可投入心力的判斷。

這也不是一個收到建議之後,就會自動開始施工的流程。

放進待辦,不等於答應一定會做
這是我覺得需要說清楚的地方。

當我把成員的建議收進待辦,代表它值得留下來評估,不表示我已經答應開發,也不代表有了完成時間。

有些想法很好,但目前不適合。有些可能要等其他事情先處理好,才有辦法往下走。也有些在整理之後,會發現它和微光想做的事情距離比較遠。

這些情況,都可以先不做。

我不希望為了表達重視,就在當下給出自己還沒想清楚的承諾。認真看待一個建議,可以是把它留下、理解原因,再作出決定,而不是立即答應。

反過來,成員也不需要因為建議暫時沒有被採用,就覺得分享沒有意義。有些意見即使沒有直接變成功能,仍然能讓我看見原本沒注意到的使用情況。

替建議留位置,也替開發留空間
我喜歡做新東西,也喜歡聽朋友提出自己的想法。但如果每個有趣的建議都立刻變成必須完成的工作,很快就會分不清楚,哪些事情是真的需要先處理。

所以,我想採取的做法是:先照顧已經在使用系統的人,把阻礙使用的問題處理好。新的想法則透過 /todo 留下來,整理成能夠判斷的計畫,再決定適合什麼時候往前走。

這樣,我不必在聊天當下就給出所有答案,也不需要因為怕忘記,就急著開一項新的開發。

對微光來說,我希望這能讓回饋有地方可去,也讓每一次開始做的決定,多一點依據。

當下一次看到一個好點子,我可以先把它接住。等到真正要投入時間時,再回頭看清楚:它想改善什麼、和現在的微光有什麼關係,以及我是不是準備好做這件事了。


上一篇
[#008]當有人真的用了我的設計,我想聽見什麼?
下一篇
[#010]功能越來越多,怎麼讓微光不變得越來越難懂?
系列文
透過 vibe coding 製作一套基於社群打造的互動式遊戲11
圖片
  熱門推薦
圖片
{{ item.channelVendor }} | {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

尚未有邦友留言

立即登入留言