提示詞

把下面的文字翻譯成繁體中文。保留術語、程式碼和專名。先給譯文，再列你改動的三處，並說明為什麼改。不確定的地方標出來，不要編。 {原文}

你來做面試官，職位是{職位}。一次只問一個問題。等我回答後，指出漏掉的要點，再問下一題。問滿 8 題後，按這個職位給一份簡短評價：過、待定或不過，並寫出依據。

審查下面的改動。只列會讓它出錯、變慢或難維護的問題。每條寫清檔案、嚴重程度（高、中、低）和改法。不要重寫整個檔案。沒有問題就寫沒有。

把下面的流水帳收成一份週報。分成：本週完成、未完成及原因、下週三件事。每條一句話，保留數字。不要寫成自我評價。

根據下面的欄名寫一個 Excel 公式，完成：{任務}。先寫公式，再用兩列範例算出結果。如果要動到別的欄，先說明。不要用我沒給出的欄。

用標準 SQL 回答：{問題}。資料表結構在下面。先寫查詢，再說明它依賴哪幾張資料表。不要發明不存在的欄。如果問題含糊，先問我一個問題。

寫一個 JavaScript 正規表示式，匹配：{要匹配的}。不要匹配：{不要匹配的}。給出表達式，再各舉兩個通過和兩個失敗的例子。

向剛接手儲存庫的人解釋下面的程式碼。先用三句話說明它做什麼，再按執行順序講。標出輸入、輸出和會失敗的情況。不要改程式碼。

根據下面的 diff 寫一條提交說明。第一行不超過 72 個字元，說明改了什麼。空一行後寫為什麼。不要寫「update」或「fix bug」這種空話。

完成這個修改：{任務}。只動完成它所必需的行。不要順手格式化、改名或重寫旁邊的程式碼。改完指出你動過的檔案，並說明怎樣驗證行為沒變。

這個缺陷是：{現象}。先寫出會重現它的步驟或測試。重現之前不要改產品程式碼。重現之後再做最小修改，並說明為什麼這就是原因。

為{行為}先寫一個會失敗的測試。展示失敗輸出，再寫讓它通過的實作。不要先寫實作。通過之後不要順手加沒要求的功能。

先閱讀與{任務}相關的檔案，列出你看到的事實和還不確定的地方。這一步不要改檔案。我確認之後你再改。

先不要寫程式碼。針對{目標}給出一個短計畫：要改的檔案、不做的事、怎樣算做完。計畫裡如果有兩個同樣合理的做法，停下來問我選哪一個。

看下面的 diff，只找安全問題：注入、越權、金鑰進了儲存庫、不安全的反序列化。每條給出檔案和觸發方式。沒有就寫沒有。不要做無關的風格評論。

為這個頁面寫 5 個 title 和 5 個 meta description。頁面講的是：{主題}。title 不超過 60 個字元，description 不超過 160 個字元。每個都要包含使用者會搜的詞，不要堆關鍵詞。

為{產品}寫首屏：一個結果、一段不超過 40 字的說明、一個按鈕。按鈕要寫出點擊後打開什麼。不要口號，不要三個賣點並排。

改寫下面的文字，讓它像在跟一個具體的人說話。刪掉空話和排比。保留所有事實、數字和檔案路徑。改完列出你刪掉的套話。

為下面的文章起 10 個標題。5 個直說結果，5 個帶一個具體細節。不要用「震驚」「終極」「賦能」。每個標題不超過 22 個字。

為{產品}寫 3 則短廣告，每則對準一個買家和一件事。寫出買家是誰、他現在的麻煩、以及點擊後得到什麼。不要堆形容詞。

寫一篇小紅書筆記，主題是{主題}。第一行是標題，正文不超過 300 字，包含你用過的具體細節，結尾一個問題。不要「家人們」「絕絕子」。標出適合配的 3 個畫面。

回覆下面的郵件。先用一句話回答對方的請求，再寫需要對方做什麼，最後給出時間。語氣直接。不要「希望這封郵件找到你好」。

把下面的會議記錄整理成會議紀錄。只留決定、負責人、截止日期和未決問題。討論過程刪掉。沒有負責人的事項單獨標出來。

目標職位是{職位}。把下面的經歷改成 5 條履歷要點。每條以動詞開頭，帶一個數字或產出。刪掉與職位無關的內容。不要編造我沒寫過的經歷。

職位要求在上面，應徵者資料在下面。列出符合的要求、不符合的要求、資料裡沒寫的要求。不要推測性格。最後給一個是否約面試的建議，並寫出依據。

為{城市}排 3 天行程。每天上午、下午、晚上各一件事，並寫兩地之間怎麼走。標出需要預約的地方。不要排我沒提的購物點。預算是{預算}。

用下面的設定寫一個 800 字以內的短篇：{設定}。一個主角，一件要完成的事，結尾要有變化。不要分章，不要說教。

把下面的情節寫成一場戲：{情節}。只寫場景標題、動作和對白。對白要能念出來。不要寫鏡頭術語，不要寫角色內心。

辯題是：{辯題}。先給正方最強的三點，再給反方最強的三點。每點一句話，並寫出它依賴的事實。最後不要宣布哪邊贏。

教我{主題}。先用一個具體例子講核心，然後出兩道題考我。我答完之前不要講下一節。答錯了就只指出錯在哪一步。

我想搞懂{問題}。你不要直接給答案。每次只問一個能縮小範圍的問題。等我答完再問下一個。我明確說「給答案」時你再講。

讀下面的論文。用 8 句話摘要：問題、方法、資料、結果、作者自己寫出的限制。每一句後面用括號標出它來自哪一節。論文沒寫的不要補。

比較{方案A}和{方案B}，用來做{目標}。列一張表：成本、要改的地方、失敗時會怎樣。每個儲存格都寫依據。依據不足就寫未知，不要猜。

看下面的介面。只評論層級、間距、可點區域和焦點狀態。列出要改的三處，每處說現在的問題和改完的樣子。不要換一套視覺風格。

為{主體}寫一條圖片提示。寫清鏡頭裡有什麼、光線、構圖和不要出現的東西。用一段話，不要關鍵詞堆砌。出 2 個版本：一個方圖，一個橫圖。

為{產品}起 12 個名字。每個名字要能當網域：短、能念、不要連字號。避開已經用濫的通用詞。每個名字後面寫一句話說明它指什麼。

我要說的是：{句子}。先給一個更自然的說法，再標出我原來的問題（用詞、語序或語氣）。然後給一個我可以跟讀的更短版本。

我要在{系統}上完成：{任務}。列出要執行的命令，每條一行，並說明它會改什麼。不要假裝你就是終端機。有破壞性的命令先停下來問我。

閱讀下面的 JavaScript。按執行順序列出每個 console 會印出什麼。如果會拋出錯誤，寫出錯誤類型和出在哪一行。不要改程式碼，除非我接著要求你修。

為{系統}劃模組。每個模組寫：它負責什麼、它不負責什麼、對外的一個介面。模組不超過 6 個。不要寫實作程式碼。

閱讀下面的材料。用不超過 40 字寫摘要。然後列出文中確實說過的想法，最多 8 條；只有原文出現過的句子才引用，最多 5 條；最後給一個收穫。某一欄沒有內容就寫「無」。不要編造引語。 {材料}

閱讀下面的 git diff，用 Markdown 寫一份合併請求說明，分這幾節：摘要、改動的檔案、原因、影響、測試計畫。每個檔案寫出改了什麼。diff 裡看不出測試，就寫測試計畫缺失。不要重寫程式碼。

閱讀下面的日誌。列出異常和反覆出現的問題，每條給出支撐它的那一行或時間。然後只寫日誌本身能支持的改法。原因不在日誌裡，就直接寫出來。不要用檔案以外的猜測來修。

把這段產品說明寫成 Markdown 需求文件，分這幾節：概述、目標、受眾、功能、功能需求、非功能需求、成功指標。每條需求都要能驗收。缺的事實寫「未知」。不要加說明裡沒有的功能。 {說明}

為{功能}寫一條使用者故事。用三行：作為{角色} / 我希望 / 以便。然後用普通條目列出測試時能核對的驗收標準。不要再寫第二條。說明裡沒有依據的標準不要寫。 {說明}

為{系統}寫一份設計說明。分這幾節：業務目標、上下文、容器、部署、風險、問題和假設。上下文、容器、部署各給一張 mermaid 圖和一張表，表裡寫名稱、類型、職責。安全部分只寫描述裡已經寫明的控制；沒寫就寫未說明。不要寫如何攻擊這個系統。 {描述}

閱讀下面的 Terraform 計畫。用一句話寫出將要改變什麼。然後列出關鍵的新建、更新和銷毀。費用和存取變化只有計畫正文寫了才列出。沒有費用就寫「未顯示費用」。不要編造價格，也不要寫攻擊步驟。

閱讀下面的 diff。第一行不超過 100 個字元，用現在式，並加上其中一個前綴：feat、fix、docs、refactor、test、chore。然後最多 6 條，每條用一句現在式的短話寫出行為上的變化。只動空白的檔案跳過。

閱讀下面的論證。每個站不住的步驟，用白話寫出它屬於哪一種謬誤，引用那一句，並說明這一步為什麼證明不了結論。步驟站不住，並不等於結論為假。論證成立就寫成立。不要列出文中沒有的謬誤。

重寫下面這條提示詞，讓模型能照著做。任務保持不變。補上輸出樣子、長度、不要寫什麼，以及輸入的佔位。把輸入放進一塊標清楚的區域。不要加角色。只返回改寫後的提示詞。 {提示詞}

為{現象}寫一份缺陷報告。欄位：標題、環境、步驟、預期、實際、嚴重程度。標題要寫出元件、動作和現象。步驟編號，並且盡量短。嚴重程度用嚴重、高、中、低，並寫出對使用者的影響。我沒給的欄位寫「未知」。不要提出程式碼修法。

為{行為}寫測試計畫，分三組：單元、整合、端對端。每條用「給定 / 當 / 則」一句話，只驗一件事。多數放在單元。端對端最多 2 條，而且必須是人會走的路徑。不要寫測試程式碼。不要用固定等待。

把{功能}寫成測試能核對的需求。每一行用其中一種句式：當[事件]時，系統應當[行為]；在[狀態]期間，系統應當[行為]；如果[不想要的情況]，系統應當[回應]。然後列出說明裡還沒寫的邊界，每條標成「提議」。不要寫設計，也不要寫程式碼。

把關於{選擇}的一個決定記下來。分節：決定、背景、選項、理由、影響、何時重看。選項只寫我點過名的。我只給了一個選項，就寫備選未提供。理由要寫出取捨。何時重看要寫出會讓我們重開這個決定的條件。不要編一個指標。

閱讀下面的 diff。只列出讀者需要改的文件：README、變更紀錄、API 說明、設定範例或遷移說明。每條寫出章節，以及 diff 裡哪一個事實讓它過時。diff 沒有使用者能察覺的變化，就寫不需要改文件。不要起草 diff 裡沒有的功能。

下面先是例子，然後是新輸入。答案跟例子用同一種樣子。只用例子裡出現過的標籤。新輸入對不上任何一個，就寫「對不上」，並指出最接近的例子。不要新造標籤。 {例子} 新輸入： {輸入}

用三種不同的方法回答{問題}。每條不超過 80 字，並以「答案：」收尾。然後說明三個答案是否一致。一致就給出那個答案。不一致就列出分歧。不要把它們合成一個新數字。

寫{主題}。只用這些小節，並按這個順序：{小節}。全文不超過{字數}字。某一節需要的事實我沒給，那裡就寫「未知」。不要加小節，不要加口號，也不要補我沒寫的事實。

寫{主題}。下面這些一律不要出現：{排除}。不要點名，也不要用別的說法把它們寫進去。寫完再刪掉仍然碰到這份清單的句子。如果刪完沒有剩下的，就寫排除條件把答案拿掉了。

幫我找一個能把 Markdown 大綱做成 PPT 的技能，並安裝它。

用 Grill Me 追問這份遷移方案。不許跳過回滾、資料量和負責人缺口。

按 Frontend Design 重做這個行銷首頁。不要紫漸層，不要三卡片功能排。

打開預發主控台，用環境變數裡的帳號登入，列出過去一小時失敗的任務。

用 Vercel React 最佳實踐審查 src/app/dashboard/page.tsx，先修影響最大的三項。

用 Web Design Guidelines 檢查這個到達頁，按檔案路徑列出不合格項。

寫一個技能：把 GitHub issue 變成測試先行的實作計畫。

合併這三份 PDF，寫入真正的文件標題，並抽出第 4 頁的表格。

把這一頁說明做成 10 頁投資人材料。每頁只保留一個觀點。

按 sku 合併這三份 CSV，去掉重複列，寫出 inventory.xlsx。

為我們的內部工單 API 設計 MCP 伺服器。最多三個工具。先出示 schema。

結帳總額只在歐元時算錯。先診斷。在能重現之前不要修補。

給這個 billing 資料夾提出模組圖。點名接合處，以及每條接縫需要的測試。

給這個商店建模退款。在寫函式之前先列出非法狀態對。

比較寫程式智能體上的 Agent Skills 與 MCP。引用原始文件。標出仍不清楚的地方。

編輯這份 README。去掉 AI 痕跡。命令和檔案路徑必須原樣保留。

教我 Astro Content Collections。下一課前先測驗。進度存在 ./notes。

記住我們使用 trailingSlash never，預設語言是英文。寫進智能體筆記。

把這個元件改成 Vue 3 組合式 API。對齊本地 vue 版本。不要 Vuex。

審查 /guides/install-agent-skills 的標題長度、canonical，以及是否只有一個 h1。

重寫首屏。只保留一個結果。不要空話。按鈕必須寫出點擊後打開什麼。

把這份大綱做成 Word 簡報：用標題樣式、加封面，並在未決問題上留批註。

啟動開發伺服器，再用 Playwright 測結帳流程：空購物車和已登入使用者各跑一遍。

加一張 orders 資料表，並用 RLS 讓使用者只能看到自己的資料列。給出遷移和政策。

把這個設定頁重構成複合元件。不要再把 theme 和 title 往下傳五層。

用 Expo 做個人資料頁。貼文列表用 FlatList。不要用只適合 Web 的 div 排版。

為一次性購買加上 Checkout。驗證 Webhook 簽章，並用冪等方式儲存付款狀態。

為這個 PR 建一個 Neon 分支，在分支上跑遷移，並把預覽環境指過去。

用 Remotion 做 15 秒產品片頭：標題卡、三個賣點、結尾 Logo。1080p。

這個不穩定測試五次裡失敗一次。用系統化除錯。在能重現之前不要修補。

用 TDD 加速率限制。先展示失敗測試，再寫實作。

重做這個設定頁。修好層級、間距和焦點狀態。不要現成的紫漸層。

給這個 API 加認證。若有任何地方說不清，先問我，再自己發明方案。