Case Writing Skills Research Plan · 2026-05-24

長個案與短個案雙 Skill 設計研究計畫

把近期四個個案與 DBA 圖文講義的製作經驗，整理成可重複執行、可驗收、修正成本較低的多 Agent 工作流程。

閱讀 Markdown 版返回 SONIC 首頁

長個案與短個案雙 Skill 設計研究計畫與規格

日期：2026-05-24 對象：Codex Skill 設計、個案寫作協作流程、圖文式 HTML 講義製作 狀態：研究計畫與規格草案，待人類確認後再建立 Skill 資料夾

一、研究目標

這份研究計畫的目的，是把近期四個 HBR Taiwan 個案與 DBA 圖文講義的製作經驗，整理成一套可重複執行、修正成本較低的工作流程。過去的問題不在於缺少產出，而在於產出常常太早進入版面與圖片階段，導致後續修改必須同時重修文字、圖片、HTML、PDF、PNG 與索引。這一次要把流程拆開，讓長個案與短個案各自成為獨立 Skill。

擬拆成兩個 Skill：

  1. case-longform-builder：負責正式長個案。核心工作是研究、證據整理、產業分析、公司側寫、角色觀點、長篇敘事、圖表與長文 HTML 發布。
  2. case-short-scenario-builder：負責短個案與情境個案。核心工作是場景設計、人物壓力、決策困境、虛構化規則、短篇敘事節奏、圖文式展示頁與討論入口。

這兩個 Skill 必須分開，因為長個案與短個案的寫法、驗收標準、視覺策略與人類介入時機都不同。長個案需要像 Harvard Business School case 一樣把產業、公司與決策放在同一個脈絡裡；短個案則需要用場景、人物與轉場，把同一個管理議題濃縮成讀者能立即進入的情境。

二、已閱讀的交接檔與歷史教訓

本計畫回頭檢視以下交接檔與流程紀錄：

  1. handoff_20260523_four_case_cleanup_and_publish.md

    2. 記錄四個個案在 Commit 前必須修正草稿語、內部註解、未驗證敘述、圖片與 GitHub Pages 同步路徑。重要教訓是，產出一旦被同步到 SONIC Repo，就不能只看本機資料夾；索引與公開路徑也要一起更新。

  1. handoff_20260524_short_scenario_rewrite.md

    2. 記錄短個案重寫的角色分工。花王、Royal POP、Stationery 都曾因短個案仍像長個案摘要，而不是 HBR Case Study 式的場景文本，被要求重寫。重要教訓是，短個案不是短版長個案，它需要獨立的情節、人物視角與決策張力。

  1. HANDOFF_20260524_GEORGIALATTE_REWRITE_STAGE1.md

    2. 整理 Advantech IoT、Borusan Cat、Netflix 2011 與 Gina Vega 個案寫作指南。重要教訓是，長個案需要三條支柱：角色觀點、產業脈絡、公司策略演進。缺任何一條，讀起來都會像雜誌文章或資料摘要。

  1. STAGE4B_GEMINI_EXPANSION_QA_AND_HANDOFF_20260524.md

    2. 記錄 Gemini API 進行段落擴寫與臺灣商管文體修整的過程。重要教訓是，生成模型可能把長文壓縮成摘要，因此必須用字數比例、段落完整度、證據密度與情境完整度作為退件條件。

  1. STAGE5_FINAL_OUTPUT_QA_HANDOFF_20260524.md

    2. 記錄最後一輪內容層查核與 HTML、PDF、PNG 輸出。重要教訓是，最後輸出前必須做雙軌 QA：一軌檢查內容是否仍有 AI 直譯腔、開發者註解、教師指引殘留；另一軌檢查 HTML、PDF、PNG 是否實際可讀、可列印、可發布。

這些交接檔共同指出一個核心問題：過去的流程太容易把「產出」誤認成「完成」。新的 Skill 必須把完成定義成：內容可教、語言可讀、版面可發布、圖片可承擔主視覺、索引可被找到，且過程檔案足以讓下一臺裝置接手。

三、截至目前為止的工作整理

四個個案目前已進入 Stage 5 最終輸出階段：

  1. Stationery：校門口之外：晨光、得力與中國文具市場的 Arena 轉換
  2. Kao：花王的下一輪成長：品牌、材料，還是生態圈？
  3. Royal POP：Royal Pop：當高級鐘錶符碼被大眾品牌重新打開
  4. New Arena：新競技場：HYROX 與 RAF 的新興賽事經營模式

Stage 5 已完成的交付物類型包括：

  1. 正式長個案 Markdown
  2. 短個案 Markdown
  3. HTML 入口頁
  4. 長個案 HTML
  5. 短個案 HTML
  6. PDF
  7. PNG 預覽圖
  8. 過程 Prompt、Gemini 輸入與輸出紀錄
  9. QA 與交接檔

這些成果已形成一條可整理成 Skill 的流程。不過，這條流程仍是在專案中邊做邊修出來的。若要變成穩定技能，必須把它拆成「長個案製作」與「短個案製作」兩條管線，再由主控 Agent 進行整合。

四、接手後已完成與正在收斂的工作

接手後的工作重點，不是再一次從頭生成內容，而是把已有成果整理成可查核、可發布、可交接的狀態。主要工作如下：

  1. 依照交接檔重新確認四個個案的 Stage 5 產出位置與內容狀態。
  2. 確認長個案與短個案的輸出已分流，而不是混在同一份 HTML 中。
  3. 檢查 Stage 5 的 QA 紀錄，確認曾處理 AI 語感、開發者註解、教師指引殘留、未驗證敘述、圖片與版面問題。
  4. 檢查 SONIC Repo 的發布路徑，確認四個個案對應到 hbr/stationery-arena/、hbr/royal-pop/、hbr/kao-growth-strategy/、hbr/new-arena/。
  5. 檢查 works/supplemental-items.csv 中四個個案的索引紀錄，準備同步更新公開頁面與索引。
  6. 撰寫本研究計畫，作為後續建立兩個 Skill 的設計基礎。

接下來的 Commit 會把四個 Stage 5 HTML 成品同步到 SONIC Repo 的公開路徑，並新增本研究計畫的展示頁與索引紀錄。

五、以 New Arena 作為完整個案範例

以下以 新競技場：HYROX 與 RAF 的新興賽事經營模式 作為完整個案範例。這個個案適合作為流程模板，因為它同時包含真實產業資料、兩個賽事組織、商業模式比較、信任治理、參與規模與觀看注意力等議題。

1. 最精準流程

第一步是定義個案不是「HYROX 與 RAF 誰比較有前途」，而是「新興賽事如何成為可經營的賽事資產」。主問題確定後，所有資料蒐集、產業分析、公司側寫、圖片設計與 HTML 展示都回到這個問題。這一步若沒有完成，後面很容易變成資料堆疊。

第二步是建立證據邊界。HYROX 的公開資訊、創辦人訪談、賽事規模、合作夥伴、參與者社群、健身競賽產業資料，都要與 RAF 的創辦團隊、摔角文化、媒體敘事、投資人期待、賽事規則和受眾輪廓分開整理。未驗證的傳聞不能進入本文。若引用原話，必須保留來源與日期。

第三步是把長個案分成四個骨架：產業如何變、公司如何做、角色如何看、讀者要如何判斷。這四個骨架先完成，不急著排 HTML。

第四步是短個案另外處理。短個案可以借用同一個議題，但不能只是長個案摘要。它要有明確場景，例如賽事前夕、贊助商會議、媒體權利談判、運動員與主辦方之間的張力。讀者必須在幾頁之內感覺到壓力。

第五步才是視覺與 HTML。長個案 HTML 應以閱讀效率為主，採用穩定目錄、段落層級、資料表與側欄摘要；短個案 HTML 應以情境進入為主，讓主視覺、場景段落與討論問題形成節奏。

第六步是輸出與查核。Markdown、HTML、PDF、PNG、Prompt 與交接檔都要保留。只要有一種輸出不一致，就回到內容主檔修正，再重建所有輸出。

2. 最少修改成本的關鍵

最少修改成本的做法，是在前三個關卡就讓人類介入判斷：

  1. 主問題是否正確。
  2. 真實個案與情境個案的界線是否清楚。
  3. 哪些資料可以引用，哪些只能作為背景理解。

這三件事若拖到 HTML 或圖片完成後才修，成本會變高。圖片會重做，HTML 會重排，PDF 與 PNG 也要重輸出。新的 Skill 必須把這三個人類判斷點放在流程前段。

六、多 Agent 架構

新的流程採取「多 Agent 蒐集與寫作，Georgialatte 統合」的架構。各 Agent 不直接覆蓋最終稿，而是輸出可審查的中間檔，最後由主控 Agent 組裝。

1. 主控 Agent：Georgialatte

Georgialatte 是資深個案撰寫統合者。它的任務不是產生最多文字，而是維持個案的教學問題、證據邊界、敘事重心與發布標準。它先讀使用者指令、交接檔、既有輸出、參考個案與 Gina Vega 寫作指南，再建立工作包給其他 Agent。所有 Agent 回傳資料後，Georgialatte 只採用可被查證、可進入個案本文、語氣符合臺灣商管環境的內容。若某段文字看起來像作者說明、開發註解、教師指引或模型提示，Georgialatte 必須退件。驗收方式是檢查長個案是否具備決策情境、產業脈絡、公司側寫、角色觀點、證據支撐與討論空間；短個案是否具備場景、人物、情緒壓力與決策難題。校正時先改結構，再改語氣，最後才改字句。

2. 證據與來源 Agent

證據 Agent 負責建立可引用資料庫。它閱讀原始資料夾、PDF、DOCX、HTML、新聞、年報、公開訪談、公司公告、產業資料與過去 Prompt 紀錄，並把資料分成「可引用」「可改寫引用」「只能作為背景」「不可使用」四類。它必須記錄來源、日期、作者、原始連結與使用限制。若資料夾中已有逐字稿或訪談摘要，它要先確認是否完整，不能留下「找不到字幕」這類已被後續資料推翻的說法。驗收方式是交出來源表、引用候選句、風險備註與資料缺口清單。校正時重點在事實一致性、時間順序、公司名稱、金額、比率、人物職稱與是否存在未驗證推論。

3. 產業分析 Agent

產業 Agent 負責把個案放進市場演進中，而不是列出零散資訊。它採用 Borusan Cat 的寫法，從總體環境、產業歷史、需求結構、價值鏈、競爭者、政策制度、技術變化與顧客行為逐步收斂到個案主題。Stationery 要說明中國文具市場、校園通路、辦公採購、外資品牌、得力與晨光的定位變化；Kao 要說明日本經濟、日化與化工、保養品與材料平台；Royal POP 要說明高級鐘錶、奢侈品符碼、大眾聯名與智慧錶衝擊；New Arena 要說明健身競賽、賽事 IP、媒體注意力與參與型運動。驗收方式是每個產業段落都有時間點、資料、競爭含義與個案連結。校正時刪掉像產業報告摘要的段落，改成能服務決策問題的敘事。

4. 公司側寫 Agent

公司 Agent 負責企業沿革、創辦人、經理人、商業模式、能力形成、資源配置與策略轉折。它採用 Netflix 2011 的深度寫法，不把公司寫成介紹文，而是寫成一連串選擇與代價。晨光與得力要呈現創辦團隊、渠道、產品線、品牌升級與供應鏈；花王要呈現歷任 CEO、K27、品牌與材料平台的張力；Royal POP 要呈現 AP、Swatch、集團關係、符碼管理與品牌邊界；HYROX 與 RAF 要呈現參與規模、觀看注意力、組織信任與賽事資產化。驗收方式是企業段落必須能回答「它靠什麼長大」「它如何面對轉折」「它的優勢與限制從哪裡來」。校正時避免公司簡介式語氣，也不能把策略術語塞進人物對話。

5. 角色觀點 Agent

角色觀點 Agent 負責找出個案中重要人物的立場、矛盾與語氣。它參照 Advantech IoT 的寫法，讓經理人、創辦人、投資人、監管者、愛用者或產業觀察者的觀點自然出現在合適場合。若是真實個案，公開人物只能依公開資料與可引用訪談來側寫，不得創造未發生的對話。若是短個案或情境個案，角色可以虛構，但要先標記虛構化規則。驗收方式是每個角色觀點都有出現理由，不只是替作者說理。校正時刪掉不自然對話，例如把策略口號直接塞進角色嘴裡，或讓角色說出正常會議中不會出現的句子。

6. 長個案寫作 Agent

長個案寫作 Agent 使用 case-longform-builder 的規格。它先接收主問題、來源包、產業分析、公司側寫與角色觀點，再組成正式長個案。長個案不可留下「本案要說明」「可作為討論」這類作者提示，也不可出現教師指引用語。開場要把讀者帶到決策時點，正文要讓產業與公司彼此扣合，結尾要留下可辯論的管理難題。驗收方式是篇幅、段落密度、證據密度、角色觀點、產業層次與討論張力達標。校正時先查是否像雜誌文章，再查是否像 AI 摘要，最後才修字詞。

7. 短個案寫作 Agent

短個案寫作 Agent 使用 case-short-scenario-builder 的規格。它不改寫長個案，也不壓縮長個案，而是重新設計一個可在短時間內閱讀的情境。它負責人物、場景、轉場、情緒壓力、決策難題與討論問題。短個案可使用虛構公司或虛構角色，但要保留真實議題的管理張力。驗收方式是讀者能在第一頁進入情境，第二頁理解利害關係，最後一頁面對需要選擇的問題。校正時刪除會議紀錄感、策略簡報腔與過度理性的對話，讓人物說話像臺灣商管現場會出現的語氣。

8. 視覺與 Image Gen Agent

視覺 Agent 負責主視覺、封面圖、關鍵插圖與 HTML 視覺規格。它先讀個案主問題，再決定圖片要承擔的概念，而不是替每段文字找裝飾。長個案圖片以產業、公司、決策場景與資料感為主；短個案圖片以人物、場景與壓力感為主。Image Gen 產生的圖片 Prompt 要保留在過程檔，不直接放在學生頁面。若涉及 Logo 或正式識別，應使用可查證、高品質、透明背景素材，再用程式疊加，避免白底污染版面。驗收方式是圖片沒有文字錯誤、沒有左上角殘影、沒有品牌誤用、沒有干擾標題。校正時先看縮圖，再看實際 HTML 與 PNG。

9. HTML 發布 Agent

HTML Agent 負責把長個案、短個案、入口頁與輸出檔組成可閱讀網站。長個案展示樣式應像正式閱讀頁，有清楚目錄、章節層級、資料表、參考附錄與 PDF 下載；短個案展示樣式應更像情境閱讀頁，讓場景段落、討論問題與主視覺形成節奏。HTML 不放開發者 Prompt，不放 ImageGen Prompt，也不放不必要的素材來源區塊。若要放 Prompt，必須是 DBA 學生可直接複製使用的生成式 AI 工作提示。驗收方式是桌機與手機都可讀，PDF 連結正常，PNG 可作預覽，所有頁面標題、導覽與輸出檔一致。校正時檢查右欄內容是否服務讀者，而不是服務製作者。

10. QA 與 Repo Agent

QA Agent 負責最後兩輪查核。第一輪看內容：是否有 AI 腔、翻譯腔、中國用語、開發者註解、教師指引殘留、未驗證敘述、錯誤職稱、錯誤日期。第二輪看交付：Markdown、HTML、PDF、PNG、Prompt、交接檔、SONIC Repo 路徑與 Works 索引是否一致。Repo Agent 只在 QA 通過後同步檔案、更新索引、檢查 Git 狀態、避開無關檔案、Commit 並 Push 到 main。驗收方式是 Git diff 只包含本次任務檔案，公開索引能找到新成品，且交接檔足以讓下一臺裝置接手。

七、長個案 Skill 規格草案

Skill 名稱：case-longform-builder

觸發時機

使用者要求撰寫、改寫或出版正式長個案，並期待接近 Harvard Business School case 的深度。常見訊號包括：長個案、正式個案、產業背景、公司策略、商業模式、競爭者分析、教學個案、20 頁、15 頁、Harvard Case、HBR Case。

核心輸入

  1. 個案主題與暫定標題。
  2. 原始資料夾。
  3. 可使用的 PDF、DOCX、HTML、MD、逐字稿、新聞、年報。
  4. 使用者指定的參考個案或寫作風格。
  5. 是否使用真實公司、真實人物、匿名公司或虛構化角色。
  6. 預期輸出：Markdown、HTML、PDF、PNG、Prompt、交接檔、Repo 同步。

必要流程

  1. 讀交接檔與既有輸出。
  2. 建立主問題與決策時點。
  3. 建立證據邊界與資料缺口。
  4. 指派產業、公司、角色觀點三個 Agent。
  5. 由 Georgialatte 整合成長個案綱要。
  6. 人類確認綱要與主問題。
  7. 撰寫長個案初稿。
  8. 進行內容層查核。
  9. 使用 Gemini API 或指定語言工具修整臺灣商管文體。
  10. 重建 HTML、PDF、PNG。
  11. 寫交接檔。
  12. 更新 SONIC Repo 與索引。

長個案展示樣式

長個案 HTML 以閱讀與引用為主。首頁放主視覺、摘要、閱讀路徑與下載連結。正文頁使用穩定寬度、章節目錄、資料表、註腳或附錄區。圖片數量不求多，但每張都要服務核心概念。PDF 以列印與課前閱讀為標準，PNG 作為預覽圖或封面縮圖。

八、短個案 Skill 規格草案

Skill 名稱：case-short-scenario-builder

觸發時機

使用者要求撰寫或改寫短個案、情境個案、HBR Case Study 式短文、角色模擬、課堂暖身案例、圖文短案例。常見訊號包括：短個案、情境個案、場景、人物、對話、小說語法、HBR Case Study、不要只是摘要。

核心輸入

  1. 長個案主問題或同一主題的資料包。
  2. 是否允許虛構角色、虛構公司、匿名化或改寫自真實事件。
  3. 目標閱讀時間。
  4. 課堂使用情境。
  5. 是否需要討論問題、Prompt 範本或課前作業。

必要流程

  1. 確認短個案不是長個案摘要。
  2. 建立場景、人物、壓力來源與決策時點。
  3. 確認虛構化規則。
  4. 撰寫短個案初稿。
  5. 檢查對話是否自然。
  6. 檢查情緒張力是否支撐管理難題。
  7. 使用臺灣商管文體修整。
  8. 建立短個案 HTML 展示頁。
  9. 輸出 PDF、PNG、Prompt 與交接檔。

短個案展示樣式

短個案 HTML 以情境進入為主。首屏應讓讀者看到主視覺與決策壓力，正文可以使用較短段落、場景分隔、角色視角與討論問題。若頁面中出現 Prompt，必須是給 DBA 學生使用的生成式 AI 工作提示，例如議題確認、資料蒐集、訪談整理、個案主軸修正或教學準備，不放製作圖片或產出 HTML 的內部 Prompt。

九、人類需要介入判斷的時機

  1. 個案主問題確認：判斷這個個案到底要讓學生討論什麼。
  2. 真實與虛構界線確認：判斷可否使用真實公司、真實人物、真實對話，或必須改成情境個案。
  3. 引用邊界確認：判斷哪些訪談、逐字稿、新聞、年報與內部文件可引用。
  4. 長個案綱要確認：判斷篇幅、主線、產業比重、公司比重與決策點是否正確。
  5. 短個案場景確認：判斷人物、壓力、場景與對話是否符合課堂用途。
  6. 視覺方向確認：判斷圖片風格、品牌使用、主視覺概念與頁面色系。
  7. 最終發布確認：判斷 HTML、PDF、PNG、Prompt 與索引是否可公開。

這些節點必須提早設定。若人類判斷延後到最後一輪，修正成本會從文字修正擴大成全套交付物重建。

十、修正與驗收方法

新的 Skill 應建立以下退件條件：

  1. 文字看起來像 AI 摘要，而不是個案敘事。
  2. 角色對話像策略簡報，不像正常商管現場。
  3. 產業段落只有資料，沒有支持讀者判斷的分析。
  4. 公司段落像公司簡介，沒有策略選擇與代價。
  5. 短個案只是長個案縮寫。
  6. HTML 內含開發者 Prompt、ImageGen Prompt、作者備忘或教師指引。
  7. 圖片文字渲染錯誤、Logo 白底污染、左上角殘影、標題被圖像干擾。
  8. PDF 與 HTML 內容不一致。
  9. Prompt 檔沒有保留，導致下一次無法追溯。
  10. Repo 索引未更新，公開入口找不到新成品。

驗收應至少跑兩輪。第一輪由內容 QA 檢查長個案與短個案是否可讀、可教、可討論。第二輪由發布 QA 檢查所有檔案、連結、索引與 Git diff。

十一、建議資料夾結構

兩個 Skill 若正式建立，建議放在：

C:\Users\sonic\.codex\skills\case-longform-builder\
C:\Users\sonic\.codex\skills\case-short-scenario-builder\

各自結構如下：

case-longform-builder/
  SKILL.md
  agents/openai.yaml
  references/
    evidence-boundary.md
    harvard-case-structure.md
    industry-analysis-patterns.md
    company-profile-patterns.md
    role-viewpoint-patterns.md
    taiwan-business-prose.md
  scripts/
    scan_case_residue.py
    build_case_html.py
    export_case_artifacts.py
  assets/
    html-template/

case-short-scenario-builder/
  SKILL.md
  agents/openai.yaml
  references/
    short-case-scenario-patterns.md
    fictionalization-rules.md
    dialogue-calibration.md
    dba-prompt-blocks.md
    taiwan-business-prose.md
  scripts/
    scan_case_residue.py
    build_short_case_html.py
    export_short_case_artifacts.py
  assets/
    html-template/

SKILL.md 只放核心流程與啟動判斷。大型參考資料放進 references/，避免每次載入 Skill 都把整套指南塞進上下文。HTML 與匯出流程若已穩定，應放入 scripts/，讓下一次製作時少寫臨時程式。

十二、Prompt 與過程檔規則

所有用於生成文字、圖片、HTML、PDF、PNG 的 Prompt 都要保留在過程資料夾。它們屬於製作過程，不直接出現在讀者頁面。

面向 DBA 學生的 Prompt 另行管理。這些 Prompt 的目的，是讓學生能複製、調整並用於自己的個案寫作或教學準備，例如：

  1. 確認個案主軸。
  2. 整理產業資料。
  3. 設計訪談提綱。
  4. 清理逐字稿。
  5. 找出可辯論的管理問題。
  6. 把資料整理成個案段落。
  7. 準備教學討論。

因此，HTML 中若放 Prompt，必須以 DBA 學生的使用情境為準。製作者用來叫模型生成圖片或 HTML 的 Prompt，只能放在過程檔。

十三、後續行動方案

第一階段先完成本研究計畫、同步四個 Stage 5 成品到 SONIC Repo、更新 Works 索引並 Commit 到 main。

第二階段在取得確認後建立兩個 Skill 資料夾。建立時不把所有歷史檔塞進 Skill，而是抽出最穩定、最能降低錯誤的流程：證據邊界、長個案骨架、短個案情境、臺灣商管文體、HTML 輸出與 QA。

第三階段用一個完整個案做回放測試。建議以 New Arena 作為測試案例，因為它同時包含兩個主體、產業新興性、商業模式差異與短個案場景需求。測試時要記錄模型在哪些節點容易偏離，再把退件條件寫回 Skill。

第四階段才把 Skill 用在下一個新個案。正式使用時，每個 Agent 只做自己的工作包，Georgialatte 統合，QA Agent 做兩輪查核，Repo Agent 最後同步。

十四、承諾與工作準則

我後續建立 Skill 時會遵守以下原則：

  1. 不把長個案與短個案混成同一條流程。
  2. 不把短個案寫成長個案摘要。
  3. 不把作者提示、開發者註解、教師指引放進學生頁面。
  4. 不使用未確認來源的訪談或逐字稿。
  5. 不讓圖片先於主問題定稿。
  6. 不在沒有 QA 的狀態下同步 Repo。
  7. 每一輪重要輸出都留下交接檔。
  8. 中文輸出先按臺灣商管語境修整，再做發布。
  9. Commit 前確認 SONIC Repo 更新、Works 索引更新、Git diff 只含本次任務。

這份研究計畫先作為 Skill 設計基礎。待確認後，再把它拆成兩個真正可觸發、可重複使用、可驗收的 Codex Skill。

同步路徑：hbr/case-skill-split-research-plan/index.html。這份文件是研究計畫與規格草案，待確認後再建立實際 Codex Skill。