如何比較 LinkedIn 帖文的主張與支持證據

收集公開帖文資料

把最多三個已知公開帖文 URL 直接複製到託管於 LinkedIn Post Actor 的 LinkedIn Post Text and Engagement Metrics Data Task 內的 `startUrls`。手動替換整份現有示例清單。Task 接受已複製的帖文連結。它不支援關鍵字探索、完整帳戶存檔、瀏覽器擴充功能或 Google Docs 整合。

儲存未經改動的來源副本，並把數據集結果與你的分析表分開追蹤。任何未能取得的帖文文字，在你檢查之前保持待處理。一次成功的執行並不能證明所有媒體或影片文字稿均可取得。Actor 收集帖文資料；它不核實所連結的研究、不檢查圖像證據、不驗證口述內容，也不撰寫新內容。

每個數據集列都包含以下確切輸出欄位：`inputUrl`、`url`、`postUrn`、`activityId`、`ugcPostId`、`authorUrl`、`authorName`、`text`、`headline`、`publishedAt`、`observedAt`、`captionUrl`、`transcript`、`status` 和 `statusReason`。缺失值仍然未知。`publishedAt` 欄位可能源自公開來源元資料，或源自 `activityId`。它不保證是作者最初發佈的確切時間。把 `publishedAt` 與 `observedAt` 分開，後者記錄確切的收集時間。

八個方法步驟

1. 界定內容決定：選擇讀者的問題，並為該問題挑選已知的公開參考帖文，而不是收集整個帳戶。
2. 把每則帖文的確切 URL 複製到 Task。儲存來源列與結果。在檢查之前，不要把未能取得的文字放入比較。保留一份未經改動的來源副本，以及一份獨立的分析表。
3. 閱讀每則帖文。用你自己的話說出其主要主張。把該主張的來源段落儲存在你的私人筆記中。識別受眾、所述條件，以及所承諾的行動。不要把互動次數當作該主張的證明。
4. 為其支持分類：逐步說明示例、已連結的第一手來源、個人經歷、示範、僅有斷言，或未經覆核的支持。個人故事可以說明一種可能；單靠它不能證明普遍結果。在你檢視相關來源段落之前，連結並不是已檢查的證據。
5. 覆核條件與反例。該主張是否只適用於特定工具、樣本、組織或時間？關鍵條件是在帖文裡，還是只在所連結的來源裡？任何視覺證據在實際檢查之前都保持待處理。
6. 製作跨帖文矩陣：帖文鍵、主要主張、支持類型、條件、缺失的支持、你可以回答的原創問題。比較推理模式，而不只比較措辭或版面。多次重複的斷言仍然是斷言；不要把它們計算為獨立確認。
7. 從一個你可以用自己已檢查的示例或來源解決的實際證據缺口中，選擇原創角度。撰寫簡短的論證大綱：擬議主張、已知條件、你已有的支持、要處理的反例、讀者行動。不要複製參考帖文未經支持的承諾，也不要自動產出衍生帖文。
8. 儲存已完成的矩陣，以及選擇該大綱的理由。撰寫內容是另一項讀者行動。參考樣本可以教你結構，但它不是對所有 LinkedIn 內容的代表性調查。

主張與支持的逐步說明示例

所有帖文身份與文字都是編造的虛構示例。一名讀者想向一個小團隊說明更安全的試算表匯入。

主張與支持矩陣

虛構的原創證據列

考慮以下四列虛構證據：

• 第一列：O10、第一行、項目 A
• 第二列：O10、第一行、項目 A 複製匯入
• 第三列：O11、第一行、項目 A
• 第四列：missing-order、第一行、項目 A

四列包含一對已確認的複製鍵，位於第一列與第二列之間。第三列雖然是同一項目，但仍然不同。最後一列有一個尚未解決的鍵。只有在完成來源鍵與值檢查之後，才移除一個已確認的匯入副本。保留 O10 原件、O11，以及尚未解決的一列，作為三項保留觀察。不要把尚未解決的一列稱為一筆獨立訂單，也不要稱為重複項。重點是已檢查論證的條件，而不是另一篇完整的去重教學。

五部分原創論證大綱

1. 擬議主張：使用已檢查的鍵自動處理重複項，並把缺失鍵的列留作人手覆核。
2. 已知條件：鍵必須識別預期的訂單行。
3. 可用支持：讀者自己的虛構逐步說明示例列。
4. 要處理的反例：兩個看起來相同的項目，可以是兩筆分開的訂單。
5. 讀者行動：保留一份獨立的未解決分類帳。

支持類型會改變你的寫作選擇。P2 提供一個有用的明確條件。P1 提出一條需要修訂的寬泛規則。P3 不能支持量化承諾。