LuluSkill
中文
語言
English

語言與主題僅儲存在此瀏覽器。

從目標開始

LuluSkill 文章

從社團的一個請求,寫成提示詞、第一版計畫與驗收表

一個攝影社要辦三場初學者工作坊,每場 24 個名額。跟著同一個請求走完全程:關鍵決定、實際貼上的提示詞、一頁計畫,以及別人也能照著跑的驗收表。

這篇文章是什麼,不是什麼

這是 LuluSkill 自己寫的內容。它不引用、不鏡像、也不摘要任何第三方 Skill,也不推薦任何一個。閱讀它不會建置、發布或執行任何東西:AI 工具會拿你的文字做什麼,要由你自己檢查。

社團開口要的是什麼,真正需要的又是什麼

這個請求是從群組裡的一行訊息開始的:「可以幫初學者工作坊做一個報名頁嗎?」下面所有內容都是為這篇文章虛構的——社團、人物、數字,以及最後發生的事——目的是讓一個請求能從第一句話一路被追到那張有人實際去跑的驗收表。這是教學示例,不是真實活動的紀錄。

這個社團在同一個月裡辦三場兩小時的初學者工作坊,每場 24 個名額,由一位志工協調人包辦所有事情。成員是學生和上班族,通常會在走路時用手機打開這個頁面。社團沒有這方面的預算,也不希望為了一個為期兩週的需求而開始付月費。

如果只照字面看,這句話足以開始動工,卻不足以把東西做完。「一個報名頁」很合理地可以變成會員名冊、行事曆、三個獨立頁面、一套帳號系統,或是一份放在共用文件裡的列印清單。這些都是不同的產品,而協調人只有在東西交回來之後,才會知道自己拿到的是哪一種。

形塑每一個答案的四項限制

白話解釋

完全沒有預算
沒有任何東西可以付費,也不能訂閱新服務。這在任何人開始爭論之前,就先刪掉了一整類的設計。
一位兼職的協調人
整條路徑必須由一個人跑得完,而這個人同時還要教課,所以沒有任何一步可以需要兩個人同時在場。
手機、單手操作
每一步都在小螢幕上單手完成,這首先是版面上的限制,其次才是功能的問題。
只要名字,其他都不要
不收電話號碼、地址、付款資料,也不收任何人的照片。沒有收集的東西,日後就不必保護、更正或刪除。

五個決定,以及每一個的理由

下面每一項都是真正的岔路:相反的選擇也站得住腳,而且真的可能有人那樣選。把理由寫在決定旁邊,是為了日後能只改其中一項,而不必把五項全部重談。

先寫決定,再寫理由

白話解釋

一個頁面,不是三個
成員在這裡只做一件事:取一個名額。三個頁面各自需要空白、等待、失敗與完成狀態,卻換不到任何額外好處,而且出錯時協調人得看三個地方。
輸入名字,而不是註冊帳號
帳號代表要保存密碼、協助重設,還要向 72 位只會用這個頁面兩次的人解釋。在一個為期一個月的活動裡,把名字打在框裡就回答了同一個問題,而且收集到的資料更少。
三場活動放在同一頁
成員要一次看到三場,才有辦法判斷哪一場適合自己。把它們拆開,等於逼人在能比較之前就先選定。
看得到剩餘名額
協調人最常被問的是「第二場還有位子嗎」。頁面上放一個數字,就不需要任何人寫信來問。
不做提醒、不做匯出、不做報表
這三項在第一次對話裡都被提過。它們被寫進「先不做」清單,因為三者加起來會讓工作量變成三倍,而第一場工作坊要辦成,一項都不需要。

提示詞全文

這就是協調人最後寫出來的文字,為這篇文章虛構,並完整呈現,方便和上面的決定互相對照。它刻意寫得短:五個短段落,每一段回答五個問題中的一個,最後一句請對方提問,而不是自己猜。

實際貼上的提示詞

範例

為一個攝影社的三場初學者工作坊做一個頁面。裡面每一個數字、名稱與規則都是虛構的。

  1. 目標:做一個頁面,讓我們攝影社的成員可以用手機、在一分鐘內,在三場初學者工作坊的其中一場取一個名額。
  2. 給誰用:我們的成員,大多數用手機。負責辦工作坊的協調人不是主要使用者——她只需要看到每一場還剩多少名額。
  3. 成員要做的事:打開頁面,看到三場活動的日期、時間與剩餘名額,輸入自己的名字,選其中一場,然後看到自己的名字出現在那一場底下。不需要密碼,也不需要電子郵件地址。
  4. 完成的樣子:成員馬上看到自己的名字出現在那一場底下;協調人看到每一場有幾個名字,以及還剩幾個名額。
  5. 這一版先不做:需要密碼的帳號、任何形式的提醒、匯出清單、出席報表、付款,以及任何會索取電話號碼或地址的東西。
  6. 我們會這樣檢查:兩位成員用兩支手機打開頁面,一位選走某一場最後一個名額,另一位隔一下選同一場。第一位名字必須在那一場上,第二位必須被告知這一場已滿,而剩餘名額永遠不能低於零。如果上面有任何地方不清楚,請先問再開始。

讓這段文字真的能用、而不只是很詳細的,是兩件事:最後一段是一項別人也能跑的檢查;第四段則寫明了刻意不做的東西,於是「沒有它」是一個決定,而不是疏漏。

接著寫成的一頁第一版計畫

提示詞說的是這個頁面為了什麼而存在;計畫說的則是「要讓它真的能用,必須有哪些東西」:哪些畫面、哪些資料、誰可以做什麼,以及出錯時會怎樣。它仍然只有一頁,而每一行仍然是協調人可能被說服改掉的決定。

六行寫完的計畫

範例

在動手做任何東西之前寫成,對象是虛構的攝影社。

  1. 畫面:一個頁面。它有四種狀態——還沒有名字、加入名字時正在等待、名額沒取到時失敗,以及名字已經在那一場上時的完成。
  2. 資料:每一場的日期、時間與名額數;每一筆報名的名字,以及它屬於哪一場。工作坊結束一週後,報名紀錄會隨著那一場一起刪除。其他資訊一律不保留。
  3. 權限:不是成員的人看得到三場活動與剩餘名額,也可以報名。協調人看到同一個頁面,另外還看得到每一場的完整名單。沒有人可以刪除別人的報名。
  4. 關鍵流程:成員打開頁面,看過三場活動,輸入名字,選一場,然後看到自己的名字出現在那一場上,而剩餘名額少了一個。
  5. 犯錯路徑:名字留空時顯示一句請你填寫名字的訊息,而且什麼都不會被加入。同一個名字在同一場重複輸入時,顯示它已經在哪一行,而不是再加一次。
  6. 失敗路徑:如果最後一個名額在前一刻被取走,成員會被告知這一場已滿,剩餘名額會重新整理,而且不會儲存任何東西。先不做:帳號、提醒、匯出、報表、付款。

注意失敗路徑事先決定了什麼:搶最後一個名額,是這個頁面唯一真正困難的地方;事先決定「沒搶到的人會看到哪一句話」,比日後才發現沒有人決定過它要便宜得多。

畫面、資料、權限與關鍵流程,是每個第一版都必須回答的四個問題;逐一完整說明在這篇文章裡:從提示詞到第一版:頁面、資料、權限與關鍵流程

寫給別人去跑的驗收表

提示詞裡的檢查只有一句話。下面這張表把那一句話展開成有編號的步驟,每一步都寫明預期結果,讓一位從沒看過計畫的社員也能照著跑,並寫下自己看到什麼。每一行都使用虛構資料:三個社團自己編出來的名字,表上不會出現任何真實成員。

實際交出去的驗收表

範例

為虛構攝影社寫的六個步驟。第三步就是整份提示詞圍繞的那一項檢查。

  1. 準備:兩支手機,都重新打開這個頁面。測試用的名字:小文、阿德、小林。每一場有 24 個名額。
  2. 第 1 步:用手機 A 打開頁面,什麼都不要碰。預期:看到三場活動,每一場都有日期、時間,以及數字 24。
  3. 第 2 步:輸入「小文」,在第一場取一個名額。預期:「小文」出現在那一場底下,而那一場的數字變成 23。
  4. 第 3 步(驗收方式本身):用手機 B 讓「阿德」取走第二場最後一個名額,然後在頁面重新整理之前,讓「小林」試著取同一個名額。預期:「阿德」在那一場上,「小林」被告知已滿,而數字不會讀到低於零。
  5. 第 4 步:名字欄位空白時按下確認。預期:出現一句請你填寫名字的訊息,而且任何一場都沒有多出新的名字。
  6. 第 5 步:兩支手機都完全關掉,再重新打開手機 A。預期:「小文」和「阿德」都還在原本的那兩場上。
  7. 第 6 步:逐一寫下每一步有沒有對上。一步一行,不要寫成摘要。

第 3 步是刻意安排得很麻煩的。它是唯一會測到「最可能出錯的那件事」的步驟;一張悄悄跳過它的驗收表,會每一輪都通過,而頁面每次遇到同時操作時仍然會弄丟一個名字。

社團如何讓這張表保持誠實

  1. 負責跑的人是沒讀過計畫的社員,所以需要口頭解釋的步驟,都是回去改測試單,而不是當場解釋過去。
  2. 測試單是在手機上跑的,因為成員就會在那裡,而社團的筆電從頭到尾沒有進到這個流程裡。
  3. 測試單和計畫放在一起,所以下一輪的修改,是拿同一套六個步驟來檢查,而不是又一次全新的意見。

兩個失敗,以及各自一行字的修正

下面是虛構的第一輪結果,寫法就跟測試當下寫筆記一樣:做了什麼、預期什麼、實際發生什麼。這兩個都是這類頁面很常見的失敗,也都不是放棄計畫的理由——每一個都只是計畫上漏掉的一行。

第一輪發現了什麼

範例

兩則紀錄,加上一行通過的部分,全部出自那場虛構的測試。

  1. 紀錄 1,第 3 步,卡住關鍵流程:「阿德」取走了最後一個名額,「小林」也取到了。兩支手機都顯示「小林」,而那一場的數字還超出了上限一個。試了兩次,兩次都這樣。
  2. 紀錄 2,第 5 步,有錯但能繞過:兩支手機都關掉、再打開手機 A 之後,「小文」的名字從第一場消失了,但那一場的名額數字並沒有加回去。
  3. 通過:第 1、2、4、6 步。第 1 步在社團試過的三支手機上都正確,而名字留空時的那句話,每一次都只出現一次。

紀錄 2 其實更有意思,因為數字和名單互相矛盾。如果頁面只顯示其中一個,它看起來會是正確的,卻在悄悄弄丟一筆報名。

每一個失敗、計畫漏掉的那一行,以及修正方式
失敗漏掉的那一行修正
兩個人取走了最後一個名額失敗路徑寫了第二個人會被告知什麼,卻沒有寫「名額必須先被占住,才能算進去」。加一句話:名額先被占住、再確認;搶輸的那一筆直接丟棄,不列入計算。
名字消失了,數字卻沒變資料那一行寫了報名紀錄何時刪除,卻從來沒說剩餘名額是從什麼算出來的。加一句話:顯示的數字一律由名單即時算出,不另外單獨保存。

比較

這種做法什麼情況適用,什麼情況不適用

適用的情況

  • 有一個人能描述整條路徑,而且判斷成果好不好的也是同一個人。
  • 需求是有結束點的——一場活動、一個檔期、一次性的任務——所以一個刻意做小的臨時頁面就是剛好的大小。
  • 涉及的資料很薄:名字與選擇,而不是金錢、健康或身分文件。
  • 有一位不是作者的人能跑這張驗收表,而且時間只夠做一輪修正。

不適用的情況

  • 這個頁面必須持續運作好幾年,或必須撐過人員更替;那樣一來,計畫就需要一位負責人和一套維護方案,而這一頁沒有空間寫這些。
  • 牽涉到金錢、健康資訊或兒童資料;這些需要關於保存期限、存取與刪除的決定,而四行資料說明承載不了。
  • 必須由兩個團隊對結果達成共識;一位協調人的驗收表,無法代替一份還沒有人談成的共識。
  • 這個任務主要是判斷,而不是一條路徑——例如寫一份政策、決定一個價格;那樣就沒有「從頭到尾走通」的流程可言。

同一套方法也能用在完全不離開一台電腦的任務上,只是那裡的限制是權限,而不是活動預算。那個案例完整寫在:從一團亂的資料夾,寫成一份權限受限的本機工作方案

你的下一步

用你自己的想法依序做三件事。每一件都不需要帳號、工具或 Skill。

  1. 找出你最近一次交給助理的請求,在它旁邊寫下五個答案,之後再送出新東西。
  2. 把你的驗收方式寫成一句別人能照著跑的話,並寫出實際上會去跑它的那個人。
  3. 把提示詞、一頁計畫與驗收表放在同一個地方,這樣下一輪是修改它們,而不是重新開始。