從零開始
先學會把想要的東西說清楚,再開始做。
六段簡短說明,給從來沒寫過提示詞、沒選過軟體型態、沒讀過授權條款的人。這裡沒有任何 Skill,也沒有任何東西在販售。
全部讀完大約十分鐘。每一段都可以單獨閱讀。
LuluSkill 已正式發布 17 個經過審查的 Skill:每一個都固定在作者儲存庫的某個版本,並記錄了授權、作者與掃描結果。LuluSkill 只連結到它們的指示,不代管也不執行。其他第三方專案以目錄條目出現,以下內容由 LuluSkill 撰寫。
查看已發布的 Skill提示詞是什麼,以及為什麼同一句話會得到兩種答案
提示詞(prompt)就是你給 AI 工具的指令。定義就這麼多。它是你輸入或貼上的一段文字,另一端的工具決定要拿它做什麼。
兩個人同樣說「幫我做一個社團網站」,卻可能拿到完全不同的結果,差別幾乎從來不在工具,而在指令沒有說出口的部分:給誰用、網站訪客應該能做什麼、現在先不要做什麼、以及你們要怎麼認定它已經可用。
AI 工具看不見你的處境,它只看到文字。因此,對站在你旁邊的同事來說不言自明的事,寫成文字往往並不完整——把那個落差補起來,就是這份指南要教的全部。
這一頁會一直用到的三個詞
白話解釋
- 提示詞
- 你交給 AI 工具的那段指令文字。在本產品裡它是一份寫給助理的簡短委託,你在使用之前隨時可以修改。
- 助理
- 任何接受貼上訊息並回覆的工具。這一頁不指定任何產品,因為你手上有哪一個,是關於你的事實,不是關於提示詞的事實。
- 型態
- 你正在做的東西屬於哪一類:網站、網頁應用程式、小程式,或是在你自己電腦上執行的工具。它決定第一版需要什麼。
可用的提示詞會說明的事
- 用你自己的話,一句話說出目標;說你要的結果,而不是你聽過的技術名詞。
- 給誰用。寫出一個明確的對象。「所有人」只會得到一個誰都不合身的設計決定。
- 現在已經有什麼——什麼都沒有、有一些筆記,或一個你已經有的資料夾。這一句可以阻止助理虛構你根本沒有的素材。
- 限制:現在先不要做什麼、不要蒐集什麼,以及有哪些事你不願意改。
- 你要怎麼知道它完成了,而且要用「你自己操作一次就能確認」的方式寫。
- 要求它先說出自己的假設、並在繼續往下做之前提出問題。這一行能擋掉的虛構需求,比其他任何一句都多。
同一個請求,寫兩次
範例
為什麼其中一個才會產出你能用的東西
- 第一次:「幫我做一個社團活動網站」。
- 拿回來的東西:一個放著範例文字的通用頁面、一個沒人要求的註冊表單,以及一堆關於顏色的問題。
- 第二次:「我經營一個小型社團。我想要一個頁面,列出接下來三場活動的日期、地點和簡短說明,讓社員用手機就能讀。我現在什麼都沒有。第一版不要做註冊、付款或登入。當我只要改一個檔案就能新增活動、而且頁面會顯示出來,就算完成。」
- 拿回來的東西:一個手機上讀得順的頁面、一個要改的地方,以及一份它做過的假設清單,讓你可以更正。
第二次寫得比較長,不是因為比較客氣,而是因為它回答了工具無法自行回答的那五個問題。
重點版:怎麼寫出第一個提示詞
你不需要範本才能開始,也不需要任何特殊用語。你只需要用平常的話,回答幾個關於自己處境的問題,然後把答案放在同一個地方。
下面的順序比用字更重要。每一步都會讓下一步更容易;而如果你答不出某一步,那本身就是有用的資訊——那通常是你還沒決定的事。
七個步驟,照這個順序
- 把目標寫成一句關於結果的話:「我想要一個頁面,讓社員看到接下來三場活動。」關於技術的一句話(「用資料庫」)是一個決定,那要晚一點再寫。
- 先寫出它首先是給哪一個人用的。用手機閱讀的社員,和用筆電編輯的幹部,是兩種不同的產品。
- 說明你現在有什麼:什麼都沒有、一些筆記,或一個現成的資料夾。然後說明你沒有什麼,以免它替你虛構出來。
- 描述那一條一定要從頭到尾跑完的路。不是所有功能,就是那一條路。以社團頁面來說:打開頁面、讀到最近的活動、知道在哪裡。
- 寫下現在一定不要包含什麼。第一版就加上登入、付款表單和電子報訂閱,等於一個永遠做不完的第一版。
- 說明你要怎麼檢查。「當我新增一場活動、並在手機上看到它,就算完成」是一個檢查;「看起來不錯」不是。
- 加上一行,要求它列出自己的假設,以及在繼續往下之前會問的問題。然後在同一段對話裡回答那些問題。
四個讓提示詞在第二次閱讀時還站得住的習慣
- 把它當成寫給一個剛加入、還沒看過你筆記的人。工具實際上就處在那個情況。
- 寧可寫出還沒決定的地方,也不要猜。「顏色我還沒決定」比一個看來合理、之後要推翻的猜測有用。
- 保留你自己的用詞。你對某個東西的說法(「社員」、「場次」、「理事會」)本身就是需求的一部分;換成你沒選過的同義詞,結果會微妙地不對。
- 絕對不要把密碼、API 金鑰、權杖或私密金鑰放進提示詞。指令是會流動的文字,機密不是指令。
從一句話到第一版
範例
同一個想法,先照讀者原本的說法,再寫成提示詞
- 你說的:「我想要記錄誰報名了社團活動。」
- 合適的型態:網頁應用程式,因為紀錄必須按人保存,而且只有幹部能修改。
- 目標那句話:「我想要一份只有幹部看得到的報名名單,讓我在活動前一天核對名字。」
- 最硬的那條限制:「第一版只有一場活動和一份名單。不做付款、不做自動寄信、不做會員帳號。」
- 檢查方式:「當我能手動新增一個名字、並在正確的活動底下看到它,而且社員完全打不開那份名單,就算完成。」
這裡沒有任何技術。只是同一個想法,把你腦中早就有的決定寫下來而已。
閱讀完整文章:從模糊的想法,寫成一段可以用的提示詞
重點版:四種型態中,第一版先做哪一種
這四種型態不是難度等級,也沒有哪一種才是「正式」的。它們只是對三個問題的不同回答:東西放在哪裡、誰能用到、資料留在哪裡。
依情境選型態,不要依野心選。選太大的代價是第一版永遠做不完;選太小的代價是一次你可以預先規劃的重做。這個不對稱,就是為什麼下面每一列的決定因素都在講你的使用者,而不是技術。
| 型態 | 什麼時候選它 | 典型的第一版 | 你要接受的取捨 |
|---|---|---|---|
| 網站 | 任何人都應該讀得到的資訊:公告、時間表、小型公共服務、一份表單。沒有人需要登入。 | 幾個在手機上也讀得順的頁面,加上一個真的能用的動作。 | 分享的阻力最低:一個連結所有人都能用,不必安裝也不必登入。代價是它記不住任何訪客的事。 |
| 網頁應用程式 | 需要有人登入、需要保存紀錄,或需要一面儀表板。重點是反覆進行的工作,而不是讀一次就結束。 | 角色、一種要保存的紀錄、一條能走完的路,以及那條路需要的錯誤狀態。 | 按人分開的資料與權限適合反覆的工作,但立刻帶來帳號問題:誰能看到什麼、以及他要怎麼進去。 |
| 小程式 | 你的使用者本來就活在某一套通訊平台裡,而且這個東西真的需要那個平台自己的分享、付款或定位行為。 | 一條在該平台上原生運作的核心流程,而不是把整個產品搬過去。 | 對那群使用者很方便,對你很貴:平台審核、平台規則與平台改版都會變成你維護工作的一部分。 |
| 本機工具/腳本 | 一個人或一個團隊需要在電腦上既有的檔案上做可重複的工作,而且這些工作不應該離開那台機器。 | 一個輸入、一個檢查步驟、一個輸出,而且要先有辦法看到它「將會做什麼」,才真的動手。 | 存取範圍維持在最小,也不會生出一個沒人要求的公開系統。代價是它只幫得到擁有那台電腦的人,其他人都幫不到。 |
範例
一分鐘選出型態
- 如果沒有人需要登入,也沒有任何事需要按人記住,就先做網站。
- 如果價值在於紀錄本身——誰報名了、付了多少、哪一件東西在哪裡——就先做網頁應用程式,並在第一版就面對帳號問題,不要拖到後面。
- 如果使用者都在同一個平台,而且那個平台功能就是重點,小程式可能是對的。如果那個平台功能只是方便,就不是。
- 如果素材不能離開某台機器,或工作本身就是磁碟上的檔案,就選本機工具,並把第一版限制在一個輸入和一個輸出。
- 如果兩種型態都說得通,第一版先選比較小的那個,並寫下你要看到什麼才會把它長大。
閱讀完整文章:網站、網頁應用程式、小程式還是本機工具:該怎麼選
重點版:第一版的頁面、資料、權限與一條流程
第一版不是完成品的縮小版。它是最小的東西,只要能回答一個問題:「這對我想的那個人真的有幫助嗎?」下面每一項都只是為了把那個問題回答一次。
四個答案就夠了:有哪些頁面、保存什麼資料、誰可以做什麼、以及那一條一定要能從頭走到尾的流程。如果這四個答不出來,第一版就還沒被定義清楚——而寫提示詞不會替你定義。
第一版需要的頁面
先做最少數量的畫面,只要能讓主要動作發生就好。你多加一個畫面,就多一個必須一直維持能用的畫面。
- 網站:一個閱讀頁,加上每個訪客真的需要讀的獨立主題各一頁,以及能從第一頁走到那些頁面的方式。
- 網頁應用程式:登入畫面、紀錄清單、單筆紀錄的詳細頁,以及新增或修改紀錄的表單。
- 小程式:一個入口畫面與那一條原生流程;平台要求的權限畫面只在流程真的需要時才出現。
- 本機工具:選擇輸入、檢查它將要做什麼、以及結果。通常一個畫面的三種狀態就夠了。
- 不論哪一種型態:都要為「目前還沒有東西可顯示」寫一句話,也為「他們要的東西失敗了」寫一句話。
必須保存的資料
只保存主要動作需要的東西,而且要能說出每個欄位為什麼存在。你無法交代理由的欄位,將來都要額外保護、搬遷與解釋。
- 公開閱讀頁不需要保存訪客的任何資料。那正是選擇它的理由。
- 屬於某個人的紀錄需要一個擁有者;在第一版裡,這個擁有者就是整個權限模型。
- 本機工具除了使用者本來就有的檔案以外,可以什麼都不保存。如果它做不到這一點,第一版就蒐集了超出需要的東西。
- 寫下如果有需要,你會刪掉的那一筆資料是什麼、以及怎麼刪。第一版如果答不出這題,就等於帶著一項沒規劃的負債。
權限與存取
在動手之前就決定誰可以做什麼,因為現在很便宜,之後會變成結構問題。
- 網站:所有人都可以閱讀,沒有人可以改動任何東西。管理工作發生在公開頁面之外。
- 網頁應用程式:至少兩種角色——紀錄屬於他的人,以及能看到全部紀錄的人。即使第一版只有一個使用者,兩種都要寫下來。
- 任何在機器上執行的東西:說明它可以讀什麼、可以寫什麼、以及絕對不能碰什麼。預設是什麼都不能,一次只開放一件事。
- 不要讓第一版持有任何屬於別人的密碼、金鑰或權杖。在提示詞裡直接寫明機密不在範圍內。
一定要能跑完的那一條流程
一條路徑,寫成有人可以用手指在螢幕上照著走的步驟。如果你講不出來,它就還沒被定義清楚。
- 寫成:這個人做了什麼、他看到什麼、以及什麼告訴他成功了。
- 為每一步寫出失敗時的樣子,以及這個人應該改做什麼。「它顯示錯誤」是一種沒有人能從中恢復的狀態。
- 說明第一次使用、還沒有任何內容與紀錄時會看到什麼。那是每個人真正最先遇到的狀態。
- 如果這條流程需要一個你還沒做的決定,就把它寫成待答問題,不要在提示詞裡默默替自己決定。
第一版應該先不要做的事
- 在還沒有任何事需要按人記住之前,先不要做帳號。
- 付款會帶來法律、退款與詐欺問題,規模遠大於原本的功能。
- 通知與自動寄信需要有寄送身分,也需要能停掉它們的方法。
- 搜尋、排序與篩選,等內容多到真的需要時再做。
- 在你讀過它做什麼、以及它用什麼授權之前,先不要匯入或複製別人的素材——包括第三方 Skill。
閱讀完整文章:從提示詞到第一版:頁面、資料、權限與關鍵流程
重點版:什麼時候不該使用、也不該發布第三方 Skill
第三方 Skill 是別人把指令(有時還包括程式)打包起來,讓你去執行或照著做。它可以省下一週,也可能一併帶進你沒讀過的授權、你沒打算給的權限,以及一個明年就沒人維護的相依套件。
以下原則都不是針對任何特定 Skill 的評論,這份指南也不會替你檢查任何一個——這也正是為什麼規則必須來自你自己,而不是來自一個評分。
在這些情況下,根本不要找 Skill
- 工作涉及機密、憑證,或那些沒有同意參與你實驗的人的個人資料。
- 這個東西執行時會取得你監督不了的權限——寫檔、執行命令、發出網路請求或刪除——而你又無法先檢查它要做什麼。
- 你說不出它的授權條款,或那個授權禁止你想做的事。「免費使用」不是授權條款,而一個沒有授權檔的專案也不等於允許。
- 你指不出你依賴的確切版本。會在你腳下改變的東西不是相依套件,是意外。
- 你必須交出自己的使用者資料,或那個 Skill 會把資料送到你說不出來的地方。
- 這個任務小到你用一段話就能自己描述清楚。自己描述,比評估別人針對略微不同問題的答案更快。
- 沒有別人在維護它,而你也不打算自己維護。一個沒人維護的相依套件,等於你之後某天被迫接手,而且不能選時間。
在這些情況下,不要把 Skill 發布到共用空間
- 它含有不是你寫的、而且你無法授權的素材——複製來的提示詞、抓取下來的頁面、別人的範例資料。
- 你還沒有用它宣稱能處理的情境實際跑過一次——而且是在你說得出是哪一版的情況下。
- 它的權限比它宣稱的用途更廣,而你沒有說明為什麼。
- 它會處理機密、憑證或個人資料,而你沒有寫下它拿這些東西做什麼。
- 你要發布它,卻沒有附上讀者判斷它所需的事實:它做什麼、會碰什麼、哪個版本、什麼授權、以及它不做什麼。
那可以怎麼做
- 自己描述這個任務,並從合適的型態開始,就像本指南前面示範的。大多數第一版都不需要別人的 Skill。
- 在判斷它「很小」之前先讀原始碼。它的大小是可以查證的事實,而你讀的第一個檔案通常就會告訴你答案。
- 直接看授權條款本身。如果沒有授權,就當成「沒有授權」,而不是「應該還好吧」。
- 把你評估過什麼、以及為什麼決定不用記錄下來。下一個人(常常是半年後的你自己)會需要它。
閱讀完整文章:使用別人的 AI Skill 之前:授權、權限與來源
廣告可以出現在本站的哪裡,以及絕對不會出現的地方
這一頁要說明廣告的界線,而不只是介紹產品,因為一條等到廣告出現之後才寫下來的界線,是一條被廣告調整過的界線。
公開探索與閱讀頁可在主要任務入口之後或內容自然分段處,放置清楚標示的廣告。AdSense 維持這份總覽最多一個,長篇文章最多兩個。Adcash 手動 Display 版位的試驗上限可設定為手機每頁一至兩個、桌面兩至三個;短頁面減少數量。缺少 Zone 設定、空結果與讀取失敗時不投放。基線使用的單一 Zone 在同一份文件中最多請求一次。
任何狀態下都不會有廣告的頁面
- 引導式開始與它產出的每一個結果:問題、提示詞與計畫。
- 專案、已保存的成果、媒合與選擇。
- 任何與執行、核准或審查工作流及其權限有關的頁面。
- 登入、登出、存取閘門、帳號與偏好設定畫面。
- 錯誤狀態、空結果、載入狀態、法律說明與帶有 URL 參數的文件。
- 安全審查與管理、技術文件、檔案預覽,以及私人輸入工具。已登入的瀏覽也不載入第三方廣告。
在本站,廣告必須滿足的規則
- 它必須同時標示為廣告與贊助版位——看得見的兩個詞是「贊助」與「廣告」——使用讀者的語言,標示在單元上方、且在單元之外。
- 它絕不長得像產品動作:不用按鈕樣式、不用 Skill 卡片樣式,也不做任何像本站控制項的行動呼籲。
- 它先保留自己的空間,這樣它出現時下面的內容不會位移。
- 它永遠不是推薦,也永遠不影響建議哪一個 Skill,更不會出現在讀者正在進行的任務旁邊。
- 它不會用本產品自己的資料來追蹤。你的目標、提示詞、計畫與身分都不是廣告資料,也不會為了廣告被送到任何地方。
真正的廣告在這裡還必須滿足什麼
- 啟用 Google AdSense 廣告前必須取得 Google 的核准。本站尚未啟用 Google AdSense 廣告;ads.txt 已授權不代表網站已取得 AdSense 核准。
- AdSense 需要一筆指名這個部署、寫在程式碼裡並可在差異中審查的允許清單項目;這筆項目尚未加入。Adcash 使用獨立且經審查的執行期設定與投放開關;選用 Adcash 時,同頁的 AdSense 會被停用。
- 網站擁有者已授權公開頁面的 Adcash Display 上線,仍須取得訪客明確同意。這項上線決定不代表平台已核准或已有收益。
- 廣告帳號識別碼必須經驗證並由部署的伺服器環境提供。公開 Zone 識別碼僅在同意後隨官方廣告請求傳送;供應商密鑰留在伺服器端,不進入原始碼、瀏覽器儲存、紀錄或下載檔案。
- 一套同意機制——為歐洲經濟區、英國與瑞士的訪客提供 Google 自己的同意訊息,包含拒絕與撤回的方法——而且在任何廣告指令碼載入之前,必須先得到它的回應。這套機制還沒有上線。
- 在真正公開網域的根目錄發布一個檔案,內容正好是廣告帳號提供的那一行。這個檔案現在已由伺服器設定發布;絕不可以發布猜測出來的識別碼。
- 本站不自己寫任何對外連結。廣告單元會自帶它的目的地,本產品既不包裝它,也不讓它經過本站的任何轉址。
符合條件的公開閱讀頁面可在你明確同意後顯示 Adcash Display。同意前不載入 Adcash 廣告指令碼;你可隨時在「廣告隱私設定」拒絕或撤回。Google AdSense 仍停用。若未來啟用 Google AdSense,這一頁最多只會在內容之後顯示一則清楚標示的 Google 廣告;長篇文章最多兩則,一則在文章中段的兩個小節之間,一則在內容之後。它絕不會出現在 Studio、專案、你的帳戶或登入頁面。
接下來去哪裡
挑選合適的 Skill
依固定版本分析適用情境與限制:是 LuluSkill 自己的判斷,而不是該專案的文件。
開發
- 從使用端角度審查介面改動已閱讀的介面設計入口重視契約與可觀察行為。伺服器實作更清楚的前提,是呼叫端仍能理解回應。
- 採用流程套件前,先選一項專長廣泛的工程集合,縮小到實際框架與任務才最有用。專案管理整合是獨立相依項目,不是自動具備的能力。
- 選擇下一個工程決策,而非啟動所有流程已閱讀的入口在問題釐清、設計、規劃與實作之間分流。它是決策輔助,不是工作已完成的證據。
- 決策複雜度足夠時,再採用分階段開發設計討論、規劃、實作與審查能避免過早寫程式,但仍需要真實成果與支援所選流程的環境。
- 依照實際交付的應用程式審查 SwiftUI現代介面建議要先核對部署目標。用有優先次序的審查改善既有畫面,避免不知情地改變裝置支援範圍。
研究
寫作
- 讓行銷建議對準一個使用者動作共用產品背景能連接文案、轉換與量測工作。動作、證據與限制清楚,推薦才有用。
- 改善文字,同時保留事實與作者聲音樣式修改應保留主張、不確定性與有意義的個性。文字自然,不能證明事實正確或內容原創。
- 採用前必讀:一套獨立實作的受控語言改寫流程這個寫作技能強制執行什麼、為什麼它不是名稱所指的那套航太標準、它的硬性限制在哪裡有幫助、在哪裡會破壞好文字,以及如何檢查改寫後事實有沒有少。
- 先選技術文件類型,再決定措辭操作手冊、決策紀錄與介面契約有不同要求。結構只有在結論依據所提供證據時才有用。
- 決定擴大投放前,先定義活動證據活動分析與轉換審查,需要單位可比較的真實輸入。行銷流程不代表允許花費、刊登或修改正式活動。
資料
設計
- 先判斷圖解是否增加資訊圖解應揭示關係,而不是裝飾清單。先區分語意結構、視覺樣式與匯出格式。
- 採用前必讀:附上具體數字的介面文案標準這個技能能修好什麼、不能修好什麼、哪些部分是引用研究、哪些只是內部主張,以及如何拿它檢查既有產品,而不是從零開始。
- 採用前必讀:一套設計變數方法,以及兩個需要連上線網站的技能配色技能如何從一個品牌色推導出整套系統、為什麼規則本身的態度才是真正的產品、哪兩個技能會連網,以及如何檢查推導出的配色對比是否合格。
- 把產生的設計系統當成提案符合題目的樣式推薦只是起始假設。實際內容、既有元件與互動檢查,才決定它是否適合產品。
- 修改介面前先選擇設計模式審查、重新設計與參考研究,需要不同權限與產出。先作區分,才能讓視覺改動符合任務範圍。
- 把實際元件文件整理成助理入口已閱讀的檔案是設計系統入口範例。價值在於資料分流方式;範例匯入不代表你的專案真的有那些元件。
生產力
- 整合全部工具前,先連接一個個人流程會議筆記、語音輸入與知識庫跨越不同隱私邊界。先用不敏感資料建立可復原的小流程。
- 相信測驗前,先建立連結來源的學習庫設定與教學解決不同問題。正確擷取及來源連結,比說明有說服力或產生的測驗分數高更重要。
- 採用前必讀:為還沒動工的專案產生規劃文件這份導讀談這個規劃技能:動手寫之前它會問什麼、產出哪四份文件、哪些步驟只在互動式環境可用,以及如何分辨真正可用的計畫與看起來很合理的計畫。
- 區分知識庫檔案編輯與操作 Obsidian標記文件、資料庫檢視與畫布檔是不同產物。檔案指引不會自動提供應用程式存取或網頁擷取能力。
- 保留持續任務狀態,不把它當成完成成果檔案能跨會話保存計畫與發現,但前提是準確記錄觀察、決策與未完成任務,並釐清負責者。
- 把產品假設轉成可驗證決策產品管理框架能整理不確定性,不能補上缺少的顧客證據、已驗證需求或可靠預測。