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

儲存已知公開 LinkedIn 帖文文字及其來源身份，然後比較每則帖文提出的主張，以及它提供的支持。Actor 是託管的資料收集程式。Task 是已儲存的輸入預設。此方法幫助你為內容研究揀選一個可加以證實的原創角度。Actor 不能檢查所連結的研究是否屬實、不能閱讀圖表，也不能核實口述內容。缺失值仍然未知，觀察時間與發佈時間保持分開。

## 收集公開帖文資料

把最多三個已知公開帖文 URL 直接複製到託管於 [LinkedIn Post Actor](https://apify.com/chronometrica/linkedin-post-scraper) 的 [LinkedIn Post Text and Engagement Metrics Data Task](https://apify.com/chronometrica/linkedin-post-scraper/examples/linkedin-post-text-engagement-data) 內的 `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. 為其支持分類：逐步說明示例、已連結的第一手來源、個人經歷、示範、僅有斷言，或未經覆核的支持。個人故事可以說明一種可能；單靠它不能證明普遍結果。在你[檢視相關來源段落](/zh-Hant/articles/%E5%90%91%E7%B6%B2%E9%A0%81%E6%90%9C%E5%B0%8B%E4%BB%A3%E7%90%86%E6%8F%90%E4%BE%9B%E4%BE%86%E8%87%AA-bing-%E7%9A%84%E5%B7%B2%E6%A0%B8%E5%B0%8D%E7%B6%B2%E9%A0%81%E8%AD%89%E6%93%9A/)之前，連結並不是已檢查的證據。
5. 覆核條件與反例。該主張是否只適用於特定工具、樣本、組織或時間？關鍵條件是在帖文裡，還是只在所連結的來源裡？任何視覺證據在實際檢查之前都保持待處理。
6. 製作跨帖文矩陣：帖文鍵、主要主張、支持類型、條件、缺失的支持、你可以回答的原創問題。比較推理模式，而不只比較措辭或版面。多次重複的斷言仍然是斷言；不要把它們計算為獨立確認。
7. 從一個你可以用自己已檢查的示例或來源解決的實際證據缺口中，選擇原創角度。撰寫簡短的論證大綱：擬議主張、已知條件、你已有的支持、要處理的反例、讀者行動。不要複製參考帖文未經支持的承諾，也不要自動產出衍生帖文。
8. 儲存已完成的矩陣，以及選擇該大綱的理由。撰寫內容是另一項讀者行動。參考樣本可以教你結構，但它不是對所有 LinkedIn 內容的代表性調查。

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

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

### 主張與支持矩陣

| 帖文鍵 | 主要主張 | 支持類型 | 條件 | 缺失的支持 | 你可以回答的原創問題 |
| --- | --- | --- | --- | --- | --- |
| P1 | 刪除看起來相同的列 | 一張裁剪圖像 | 未說明 | 可能把不同訂單合併 | 不要用作一般規則 |
| P2 | 使用訂單 ID 加行號來檢查重複匯入 | 四列逐步說明示例 | 來源具有穩定的訂單與行識別碼 | 未涵蓋缺失 ID 的情況 | 如何在鍵缺失時檢查重複項 |
| P3 | 我們的團隊在清理後節省了數小時 | 個人經歷 | 一個團隊的工作流程 | 沒有基線或時間記錄 | 視為已報告的主張，而非已核實的效益 |

### 虛構的原創證據列

考慮以下四列虛構證據：

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

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

### 五部分原創論證大綱

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

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

## 下一步行動

開啟 [LinkedIn Post Text and Engagement Metrics Data Task](https://apify.com/chronometrica/linkedin-post-scraper/examples/linkedin-post-text-engagement-data)，使用 [LinkedIn Post Actor](https://apify.com/chronometrica/linkedin-post-scraper) 把其示例替換為最多三個已知公開帖文 URL，並在選擇你的原創論證之前完成主張與支持矩陣。

## 來源與延伸閱讀

- [LinkedIn Post Actor](https://apify.com/chronometrica/linkedin-post-scraper)
- [關於 LinkedIn Scraper 的 Reddit 討論](https://www.reddit.com/r/automation/comments/1jcodlw/linkedin_scraper_chrome_extension/)