外部分析文章是寫作材料、不是可直接搬進教學文章的事實層。把分析師文章、VC essay、產業評論改寫成本 blog 的商業分析時、先把材料拆成三層：可驗證事實、原作者判讀、本文推導。

判別問題：「這句話如果拿掉原作者名字、還能被當成可驗證事實嗎？」不能、就不可寫成事實句。

情境

content/business/ 的原始出發點是輸入其他分析師文章、再讓 AI 轉換成本 blog 要的風格。第一版 business case-analyses 雖然已經用 WRAP 拆事件、但 commit 演變顯示三個容易混在一起的材料來源：

第一、公開事件本身，例如 Anthropic 推出 Claude for Legal、Snowflake / Databricks / MotherDuck 同期推出 FDE、CoreWeave 收購 Bufstream。這些是可驗證事實。

第二、外部分析師對事件的判讀，例如「這是 enterprise ARR 驅動」「這是基礎設施垂直整合」「這是 SaaS 三支柱被鬆動」。這些是原作者或市場的解釋，不是事件本身。

第三、本文要教讀者帶走的框架，例如「三層擠壓」「資料平台前端化」「整併週期下的賽道判讀」。這些是本文推導。

Round 4 的 #142 已經處理「WRAP 內部分析喧賓奪主」；本卡補更上游的 source 問題：在開始寫正文前、先知道每句材料屬於哪一層。

理想做法

第一步：來源進稿前先做三欄標註

把外部文章或 AI 轉寫草稿中的句子標成三欄：

同一句若同時包含兩層、拆成兩句。例：「CoreWeave 收購 Bufstream，代表算力廠商開始垂直整合 data pipeline」應拆成：

1. CoreWeave 收購 Bufstream。這是事實。
2. 算力廠商往 data pipeline 延伸。這是本文判讀。

第二步：事實進事件段、判讀進 hypothesis、推導進主體

三層各有適合的位置：

外部分析師的判讀可以幫助 widen hypothesis space，但它不該直接變成本 blog 的正文結論。正文結論要由本文的 evidence weight 與可遷移框架承擔。

第三步：合成 frame 要標成本文推導

當文章把多個來源合成成一個框架時、要讓讀者知道這是本文的教學合成。寫法可以是：

1本文把這個變化整理成三層：應用層 SaaS、新創供應商、知識工作者。

這比「市場正在發生三層擠壓」精準，因為前者承認這是本文整理出的框架，後者容易讓讀者誤以為三層分類是外部事件本身。

第四步：引用來源時先寫概念、再放 attribution

來源 attribution 是可回溯支撐，不是段落主詞。先寫本文要教的概念，再補來源角色：

1API 型產品若毛利薄、供應商會傾向用 enterprise contract 對沖收入波動。這個判讀可作為檢查供應商動機的 prior，不能直接當作本篇三層擠壓的主體。

不要寫成「某某報告說 X，所以 X 是結論」。這會把來源權威放在概念之前，也讓讀者無法分辨 source claim 與本文推導。

沒這樣做的麻煩

分析師 frame 被誤當事實

外部文章的分類與比喻通常是作者的 frame。直接搬進正文，讀者會以為那是事件本身揭露的事實。後續若讀者回查來源找不到「三層擠壓」或「SaaS 三支柱鬆動」這些詞，會降低文章可信度。

AI 改寫會放大 attribution 漂移

AI 轉寫常把「某作者認為」壓縮成「這代表」。這個壓縮讓 claim 從觀點層滑到事實層。若沒有 source layering，改寫後的句子會更順、但 fidelity 更差。

本文自己的貢獻變模糊

教學型商業分析的價值是把事件整理成讀者可遷移的框架。若原作者判讀與本文推導混在一起，讀者看不出本文到底新增了什麼，只會覺得是另一篇摘要。

跟其他抽象層原則的關係

判讀徵兆

核心原則：外部分析文章進入教學寫作前、先拆成事實、作者判讀、本文推導。三層分清楚，文章才有可回溯性，也才看得出本文真正教了什麼。

跨領域分析的讀者層級要先定位、再決定術語密度。把商業分析寫給工程背景讀者時、不能繼承原分析文章的 VC / founder / industry insider 讀者假設；要把原文的高密度術語與壓縮因果鏈降到目標讀者可複製判讀的層級。

判別問題：「讀者若沒有商業分析背景，能不能用這段推導去分析下一個事件？」不能，就要降一級。

情境

content/business/reading-frameworks/writing-down-a-level.md 是從 business case-analyses 的 Round 5 修文抽出來的。當時讀者回饋指出，文章雖然比第一版更像教學，但仍太像寫給 VC / founder 的 deep blog：三句內連續塞進多個商業術語，且因果鏈跨太多步。

例如 Claude for Legal 的第一層擠壓原本把 enterprise license、API margin、長約、垂直流程、法律風險等概念壓在少數句子裡。工程背景讀者可能知道 API、SaaS、workflow，但未必直覺知道「為什麼毛利結構會推動供應商賣 enterprise contract」。若不拆開，讀者只能記住結論，無法複製推導。

後續 b9c5f06 新增 reading framework，8c67ab6 再把 FDE 與 Bufstream 文章的 5 段高密度內容降一級，形成穩定規則：跨領域文章要先判斷原文寫給誰，再決定本站要降到哪裡。

理想做法

第一步：先辨識原文的 reader contract

外部商業文章常見 reader contract：

本站 business case-analyses 的目標更接近「工程背景讀者讀 MBA 教材」：保留商業分析深度，但不預設讀者熟悉投資圈 shorthand。

第二步：用術語密度決定是否降一級

一段內若連續出現三個以上跨領域術語，就要拆段或補橋接句。

1API margin → enterprise ARR → vertical workflow lock-in

這串對 VC 讀者可能順，但對工程背景讀者需要拆成：

1. API 型產品的收入跟成本如何變動。
2. 為什麼長約能降低收入波動。
3. 為什麼垂直流程能讓客戶更難替換。

第三步：用因果鏈步長決定段落切分

每段只推一到兩步。若一句話需要讀者同時理解「成本結構、銷售模式、採購風險、workflow switching cost」，拆成多段。

第四步：用卡片承擔術語，不讓正文變字典

降一級不等於每次都在正文長篇定義名詞。若術語會反覆影響判斷成本，就建卡或連既有卡；正文只保留當下推導需要的最小解釋。

例：unit economics、switching cost、vertical SaaS 這類詞，若每篇都重新解釋，正文會膨脹；卡片負責概念，文章負責事件推導。

沒這樣做的麻煩

讀者只能記名詞，不能複製判讀

高密度商業語言會讓文章看起來專業，但讀者若無法把術語放回因果鏈，只會記住「FDE 代表 SaaS 三支柱鬆動」這種結論句。下一次遇到不同市場事件時，判斷工具無法遷移。

AI 改寫會保留原文讀者假設

AI 常把原文風格重寫得更流暢，但不會自動調整 reader contract。原文若寫給 VC / founder，改寫後仍可能保留高密度 shorthand，只是中文更順。

文章篇幅變短，但理解成本變高

跨領域文章最常見的錯覺是「短 = 清楚」。實際上，短句若省略中間因果，讀者需要自行補推導。對目標讀者而言，補推導的成本比多讀兩段更高。

跟其他抽象層原則的關係

判讀徵兆

核心原則：跨領域分析的寫作目標是讓讀者複製判讀，不是讓原文變順。先定位原文與目標讀者的層級差，再調整術語密度與因果鏈步長。

外部分析改寫的交付物是可遷移框架、不是風格轉換。把其他分析師文章交給 AI 改寫時，任務目標不能停在「改成本站語氣」「更正向」「更像教學」；真正要交付的是讀者能帶到下一個市場事件使用的判讀工具。

判別問題：「讀者讀完後，是否多了一個可重用的判斷問題或檢查表？」沒有，就還只是改寫。

情境

content/business/ 的建立過程是一場從「外部分析文章」到「本站教學型商業知識」的轉換實驗。commit 演變顯示，早期版本雖然有 WRAP、知識卡與 case analyses，但仍多次被讀者 feedback 拉回核心問題：

• #140：Widen Options 不能用稻草人修辭展示作者結論。
• #141：WRAP 是內部工具，不能直接當文章章節。
• #142：即使章節標題改了，正文仍要對齊標題承諾。
• writing-down-a-level：目標讀者是工程背景讀者，不是原文的投資人或創辦人。

這些問題共同指向一件事：AI 轉換文章風格不夠。文章要從「原作者如何看這件事」轉成「本站讀者以後如何判讀同類事件」。

理想做法

第一步：把任務定義成 frame extraction

輸入外部文章時，先問：

若事件只能產出「某公司發生某事」的摘要、沒有可遷移框架，就放在筆記，不硬寫成 case-analysis。

第二步：正文結構服務可遷移框架

教學型商業分析的穩定結構可以是：

1事件本身 → 結構性機制 → 長期影響 → 預警訊號 → 可遷移框架

這是責任順序，可依標題承諾調整。事件段讓讀者進場；機制段教為什麼；長期影響處理時間軸；預警訊號讓框架可被反證；可遷移框架讓讀者能帶走。

若某篇文章的標題承諾需要不同順序，可以調整；但最後仍要回答「這個事件教讀者下次看什麼」。

第三步：把原文觀點轉成判斷問題

風格轉換會把原文句子改得更順；框架轉換會把原文觀點改成讀者可問的問題。

判斷問題比結論更有價值，因為問題可以帶到下一個 case。

第四步：用預警訊號保護框架

可遷移框架需要知道何時失效。每篇 case-analysis 至少要有一段預警訊號，列出哪些觀察會推翻或削弱本文判讀。

沒有預警訊號的框架只是一組漂亮分類。讀者需要知道「何時重新評估」，才會把框架當工具，而不是把它當口號。

沒這樣做的麻煩

文章會變成原文摘要

AI 很擅長把原文改成不同語氣，但摘要仍然沿著原文的 frame 走。讀者得到的是「另一個版本的原文」，不是本站累積出的知識單元。

事件評論不可重用

若文章只回答「這件事代表什麼」，下次遇到不同公司、不同市場、不同產品時，讀者還是要從頭判斷。可遷移框架要回答「下次遇到相似事件，我要看哪些訊號」。

寫作規範會被誤解成表面風格

正向陳述、核心原則先行、商業邏輯先於 CASE 不是語氣規則；它們是把思考過程變成可重用知識的結構規則。若只做風格轉換，會通過部分表面檢查，但仍不符合知識庫目標。

跟其他抽象層原則的關係

判讀徵兆

核心原則：外部分析改寫的交付物是讀者可遷移的判讀框架，把原文變順只是表層。沒有框架、預警與下一步路由，文章仍停在摘要層。