外部分析文章要先拆成事實、作者判讀、本文推導
核心原則
外部分析文章是寫作材料、不是可直接搬進教學文章的事實層。把分析師文章、VC essay、產業評論改寫成本 blog 的商業分析時、先把材料拆成三層:可驗證事實、原作者判讀、本文推導。
| 層級 | 內容角色 | 進正文時的寫法 |
|---|---|---|
| 事實 | 事件、交易、產品發布、公開數字 | 放「事件本身」或背景段、可回溯來源 |
| 原作者判讀 | 分析師對事件的解釋、預測、立場 | 標成「某類分析觀點」、只當 hypothesis |
| 本文推導 | 本文從多個來源合成的判斷框架 | 明確寫成「本文判讀」或「可遷移框架」 |
判別問題:「這句話如果拿掉原作者名字、還能被當成可驗證事實嗎?」不能、就不可寫成事實句。
情境
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」應拆成:
- CoreWeave 收購 Bufstream。這是事實。
- 算力廠商往 data pipeline 延伸。這是本文判讀。
第二步:事實進事件段、判讀進 hypothesis、推導進主體
三層各有適合的位置:
| 層級 | 正文位置 |
|---|---|
| 事實 | 開頭與「事件本身」段 |
| 原作者判讀 | Widen Options 的 prior 或背景敘事 |
| 本文推導 | 文章主體、長期影響、預警訊號、框架 |
外部分析師的判讀可以幫助 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 更差。
本文自己的貢獻變模糊
教學型商業分析的價值是把事件整理成讀者可遷移的框架。若原作者判讀與本文推導混在一起,讀者看不出本文到底新增了什麼,只會覺得是另一篇摘要。
跟其他抽象層原則的關係
| 原則 | 跟本卡的關係 |
|---|---|
| #116 引用案例要分觀察層 / 判讀層 | #116 處理 case 引用,本卡把同一條分層原則套到外部分析文章 source |
| #117 跨多個 case 合成的 frame 必須標為章節合成 | 本卡是 #117 在 analyst source 的對應版本:跨來源合成 frame 要標成本文推導 |
| #142 文章主體要對齊標題承諾 | Source layering 是 #142 的前置條件;先知道哪些是背景 prior,才知道哪些不該佔主體 |
| #140 WRAP Widen Options 容易塌成稻草人 framing | 原作者判讀可作為 Widen Options prior,但不能被設成待打倒的稻草人或預設正解 |
| #97 Metadata surface 要納入寫作 review 範圍 | Title / description 若把本文推導寫成事實,也會造成來源層漂移;metadata 也要跑 source layering |
判讀徵兆
| 訊號 | 該做的事 |
|---|---|
| 句子寫「這代表 X」、但 X 其實是分析師解釋 | 改成「一種判讀是 X」或標成本文推導 |
| 外部文章的比喻或分類被直接放進本篇標題 | 確認這是原作者 frame 還是本文 frame |
| AI 改寫後少了「某作者認為」「市場敘事」等 attribution | 回原文補回 source layer |
| 引用來源只寫機構名、沒有具體文章或可驗證出處 | 刪掉具名 source,改成一般 prior 或重新查證 |
| 讀者問「這是事件事實、原文觀點、還是你自己的推導」 | Source layering 失敗,重寫段落主詞與 attribution |
核心原則:外部分析文章進入教學寫作前、先拆成事實、作者判讀、本文推導。三層分清楚,文章才有可回溯性,也才看得出本文真正教了什麼。
#report #事後檢討 #工程方法論 #原則 #writing #source #business-analysis