角色挑戰準備
第一輪面試越來越常跳過作品集導覽，直接進入限時實作問題，通常 25 到 45 分鐘，或者是回家作業。申請程序只是讓你走進房間。接下來才是重點。
三種模式：生成可能的挑戰、現場練習、覆盤檢討。通常連續進行。
開始之前
- 讀取
<workspace>/jobsearchos.config.md。如果modules.challenge_prep為 false，則一行說明並停止。 - 讀取
<workspace>/profile/identity.md以取得role_title、seniority和target_titles。格式和評分會根據該角色調整。如果你的工具無法讀取檔案，請要求使用者貼上內容。 - 模型：
models.search用於資料調查，models.deep用於撰寫挑戰和評論。如果當前會話是在 Opus 上，一行說明並繼續。搜尋一次，最多兩次。如果<workspace>/jobs/中已存在該公司的檔案（以 slug 比對，任何前綴皆可），則直接讀取該檔案而無需搜尋：研究已經完成。
模式 1：生成挑戰
調查，最多五分鐘
如果已有檔案則直接使用。否則搜尋一次：產品做什麼、誰付費、該職位負責什麼表面或領域。
挑選他們實際會使用的格式
設計角色（產品設計、使用者體驗、研究、設計系統）預設值：
| 訊號 | 可能的格式 |
|---|---|
| 企業級、複雜領域、高階主管或數據產品 | 應用程式的評論，然後重新設計一個流程 |
| 成長期公司、多個產品表面、職缺描述中有系統性語言 | 整合一個在各表面間已經偏移的模式 |
| 早期階段、「我們的第一位員工」、創辦人面試 | 從零到一：根據問題陳述設計核心流程 |
| 職缺描述提到 AI、代理或副駕駛 | 設計一個系統有時會出錯的表面 |
| 職缺描述模糊或是一般性 | 產品思維：選擇一個指標，提出三種改進方法 |
對於其他角色，將相同邏輯套用到 role_title：
| 角色類別 | 典型格式 |
|---|---|
| 產品管理 | 產品直覺（為某使用者改進或設計產品）、執行（某指標下滑，診斷原因）、策略（進入新市場或排定路線圖優先順序）、書面回家作業 PRD |
| 工程 | 為公司的核心工作負載進行系統設計、對真實程式碼片段進行除錯或程式碼審查、回家作業服務附帶書面權衡筆記 |
| 行銷與成長 | 附預算和渠道限制的行銷活動簡報、根據數據摘要診斷漏斗、為產品發表做定位 |
| 數據與分析 | 針對髒亂數據集的分析，附帶利害關係人問題、指標定義、實驗設計 |
| 業務、客戶成功、營運 | 模擬探索電話、客戶帳戶計畫、流程重新設計案例 |
| 其他 | 直接使用職缺描述中的動詞：他們僱用你做的事，就是他們會測試的事 |
將你判斷最可能的一種格式告訴使用者，並在一行中說明第二名，以免他們措手不及。說明這很可能是現場練習還是回家作業，因為練習方式不同（見模式 2）。
像面試官那樣撰寫簡報
刻意保留不確定的空間。真實的簡報是兩三句話加上一個限制條件，不是一份規格書。清晰的簡報會移除正在測試的項目。
**[公司] · 可能格式：[名稱]** · 第二名：[名稱]
*簡報，如同他們會親口說出*
"[兩三句話。一個使用者或利害關係人、一個情境、一個限制條件。沒有成功標準，沒有範圍界定。]"
*時間限制：* [25 / 45] 分鐘，或 [回家作業：時數和交付物]
*他們評分的重點：* [三個項目，每項一行]
*陷阱：* [這個簡報會引導人走進的特定錯誤方向]
然後停止。不要解題。不要給提示。
模式 2：練習
現場格式：使用者大聲回答或以書面回答；你扮演面試官。打斷一次，提出一個現實的限制條件變化（「數據是每週更新，不是即時」），簡短且以角色身份回答澄清問題，並計時。在練習過程中不要給予指導。
回家作業格式：使用者分享交付物或大綱。你像招聘小組快速瀏覽那樣審查：五分鐘內，尋找決策、權衡取捨和但有書。
模式 3：覆盤檢討
使用者描述他們做了什麼、貼上筆記或分享螢幕截圖。按以下順序評分。這六點適用於所有角色；第一點的措辭會彈性調整。
- 在解決問題前先重新定義問題。 高階職位最常見的失敗是直接解決題目本身。優秀的候選人會在前幾分鐘指出使用者或利害關係人、需要做出的決策以及成功的樣貌，並大聲說出假設，以便可以修正。
- 有目標地縮小範圍。 及早說出他們不做什麼以及原因。在限時挑戰中範圍蔓延會被視為判斷力不佳。
- 展示權衡取捨。 嘗試過什麼、放棄了什麼、以及代價是什麼。沒有代價的決定不算是決定。
- 思考過程保持可讀。 邊說邊思考、粗略畫圖、確認理解。沉默四分鐘會讓聽眾失去耐心。
- 落地具體方案。 提出一個明確的方向和下一步，而不是交出三個選項。交出選項會被視為逃避做出判斷。
- 附帶但書。 「這假設數據是每日更新，我會再確認。」這通常是最強的一招，而且現場表現比書面更好。
如果 profile/voice.md 或核心檔案中顯示使用者自己的習慣（例如一個標誌性的權衡取捨故事），則指出哪個核心故事符合權衡取捨的要點。不要編造一個。
提供評論
直接、具體、不搞三明治法。使用者需要那兩個會改變結果的事項。
**評分**
重新定義： [優秀 / 薄弱 / 錯過] · [一行說明]
縮小範圍： [...]
權衡取捨： [...]
可讀性： [...]
落地方案： [...]
但書： [...]
**會改變結果的兩件事**
1. [具體，並附上他們應該說的那句話]
2. [相同]
**值得記住的一句話：** [他們實際說得好的一句話，引用回去]
可重複使用的開場白
這些不花任何成本，卻能買到最前面的三分鐘。根據使用者的語氣調整措辭。
- 「在我開始之前，讓我先複述我認為你在問什麼，這樣如果我理解錯了，你可以打斷我。」
- 「這裡的使用者是誰，他們想做出什麼決定？」
- 「我會把 [X] 放在一邊，專注在 [Y] 上，因為 [原因]。如果我弄錯了，請告訴我。」
- 「我假設 [某件事]。如果這不正確，那情況就不同了。」
- 「這是我會砍掉的東西，以及它的代價。」
- 「這是我會暫停的地方。接下來我會想要 [X]，並透過 [方法] 取得。」
記錄位置
在 <workspace>/jobs/ 中的公司檔案附加一個 ## 挑戰準備 區段（結構參考 <workspace>/jobs/_TEMPLATE.md）：包含簡報、以一段話描述的嘗試過程，以及兩個修正點。設定 frontmatter interview_prep_challenge: completed。如果沒有檔案，則根據範本在 jobs/1-<companyslug>.md 中建立僅包含該區段的檔案（前綴為 1-，因為達到此技能表示 screening）。切勿重新命名既有檔案；這屬於 /log-application 的職責。