有了故事清單與萃取好的細節，接著要寫出完整故事。做法是由內而外：先攻 Actions，再整理目錄、為每個主題寫 mini-CARL，最後補上精簡的 Context 與收尾的 Results / Learnings。
🧠 Intuition
TIP
你不會對著面試官逐字念稿，但事先想過段落轉場與關鍵元素，會讓你在壓力下表現好得多。除非你有演說或辯論經驗，否則要臨場即興組出一個涵蓋所有目標訊號的故事並不容易；完整故事也能分享給他人（含 LLM）取得回饋並迭代。
核心故事（尤其資深以上）往往很長，直接從頭到尾寫容易失焦。由內而外的順序讓你先鎖定最有訊號的行動，再往外包裹剛好夠用的背景與結果，避免「情境講太久、行動被稀釋」。
⛏️ 由內而外的搭建法 (Scaffolding)
四步驟：先 Actions，最後才 Context / Results
- 整理一份目錄（Table of Contents）：資深以上的核心故事很長，先決定如何組織你的講述。
- 為目錄中每個主題寫 mini-CARL：把每個主題當一個小故事。
- 寫整體專案的精簡背景：務必把賭注拉得夠高。
- 收尾寫 Results 與 Learnings。
作者建議講完目錄後停頓，在對話中留白給追問——故事寫得比實際會講的更長是正常的。
組織目錄的兩種方式：時間順序 vs. 主題
- 依時間順序（Chronologically）：多數專案有明確階段，從頭講到尾易於理解。例：「這專案有幾個階段——我如何蒐集研究數據後發起它、如何用簡報巡迴爭取領導層資金、如何與 TL 在複雜限制下設計、如何解決實作階段的技術問題、如何協調多團隊謹慎上線……」
- 依主題（Thematically）：時間順序有兩個風險——(1) 最亮眼的訊號可能在專案尾端，還沒講到就被打斷；(2) 你想傳達關於「你是誰」的明確訊息時，把相關行動歸在一起更好，即使時間上不相鄰。例：「這專案有幾個轉折點——確保點子貼近使用者的產品貢獻；化解與領導層、工程、設計的關鍵衝突；為確保速度所做的優先取捨……」
關鍵技巧：在主題裡帶進「結論」
TIP
別只列出「要講什麼」，還要提供你希望聽者對你形成的結論。單純列主題雖有助組織對話，卻錯失了給人「該錄用你」理由的機會。
❌「這專案有幾個階段：發起、對齊巡迴、技術設計、實作、上線……」（只有主題、沒有結論）
✔️「這專案裡，我做了真實使用者研究、與工程密切合作處理技術限制、並基於數據而非假設為設計決策辯護。」（每個主題都帶著你想被下的結論）
故事品質檢查
完成一個故事後跑幾個檢查：
- 讀一遍，看你能否對照訊號領域辨識出關鍵結論——更好的做法是請人幫你讀並辨識。這些是否對應到你想傳達的？
- 檢視 Context：包含專案的業務動機、但別太長。裡面每個細節是否都與故事相關？
- 目錄是否告訴面試官，他該從每一段對你下什麼結論？
🗣️ Discussion Log
（尚無紀錄。用 /note-enrich story-mining/scaffolding 或 note 討論深化。）
🔑 Takeaways
- 由內而外：先 Actions → 整理目錄 → 每主題寫 mini-CARL → 精簡 Context（拉高賭注）→ 收尾 Results / Learnings。
- 目錄兩種組織法：時間順序（易懂）vs.主題（亮點不會被延後、能傳達「你是誰」）。
- 關鍵技巧是在主題裡帶進結論——給面試官該錄用你的理由，而非只列標題。
- 寫完用品質檢查對照訊號領域，確認每個細節都有作用。