如何建立多元新聞來源清單？追查原始出處、分工與每週維護
從需要回答的問題出發，追查新聞署名、引用與原始文件，將重複報導歸組，再建立互補且能維護的來源清單。附假設產品案例、紀錄欄位與每週更新流程。
- 建立多元新聞來源清單，先決定要回答的問題，再保留能提供互補材料的來源；網站、App 或訂閱數量不是目標。
- 從署名、供稿標示、原文連結、日期與引述追查上游出處，分清轉載、新聞稿與新增採訪；找不到出處時保留未知，不直接算作獨立查證。
- 讓原始文件、原創報導、在地專業與受影響者各有用途，再按證據範圍判斷主張；官方材料不必然獨立，觀點多元也不等於強制平衡。
- 每週檢查更新、更正與重複角色，精簡而不任意清除重要脈絡；需要追蹤缺口時，可用 FoneClaw 自訂新聞建立經確認的主題任務，再回到實際來源核對。
先列問題與缺口，不急著增加訂閱
想建立多元新聞來源清單，先寫下自己需要持續回答的一個問題，而不是先收藏一大串媒體首頁。清單的價值在於提供不同材料，讓你知道消息從哪裡來、哪些部分已核實，以及還需要補查什麼。
假設你想了解無線耳機新功能與使用限制，可以先列三個問題：廠商正式公布了什麼？功能需要哪些裝置或設定？實際使用是否有可檢查的測試材料？接著才找能回答這些問題的來源。這樣建立的清單，通常比單純累積科技新聞網站更容易維護。
先分清「在哪裡看到」與「資訊最初從哪裡來」。出版者是刊登內容的媒體；上游出處可能是記者的原創採訪、通訊社稿件、企業新聞稿，或技術文件。不同出版者可以共用相同材料，同一出版者也可能同時刊登原創與轉述內容。
不用先找出一個公認完美的來源數量。先替每個問題保留可用入口，缺的角色暫時留白，之後按需要補上。若你還不確定興趣相關、來源數量與證據多樣性有什麼差別，可先閱讀個人化新聞能打破同溫層嗎？先分清相關性、來源與證據多樣性，再開始整理。
沿著署名、引用與日期，找回上游出處
挑一篇與問題有關的文章，先處理其中一項重要主張，不必一次追查全文所有內容。目標是確認作者取得了什麼材料，而不是只判斷文風是否可信。
- 看署名與供稿標示：有沒有記者、通訊社、合作媒體或轉載來源？
- 找原文連結：文章是否指向公告、研究、文件或最初報導？開啟後核對內容是否真的支持主張。
- 對照日期：分清原始發布、媒體刊登與後續更新，避免把較晚轉載當成新發現。
- 檢查引述：不同文章是否使用相同發言、數字與段落？它們可能來自共同材料。
- 找新增工作：作者是否另行訪問、取得文件、觀察現場或交代測試方法？記下具體新增內容。
- 追不到時標示未知：不要因為沒有寫轉載，就推定是獨立採訪。
AP 的編採實務規範要求原創撰寫，並將可爭議資訊歸屬到原始來源；處理新聞稿時，須評估可信度、補充其他材料並標明出處，不能原樣發布。這是 AP 的規範，不代表所有媒體都如此執行，也不表示新聞稿內容必然為假。
改寫與查證也要分開。文字變了，不代表取得新證據；保留原稿措辭，也不必然表示事實錯誤。清單應記錄可見的材料關係，無法確認的部分就保留不確定性。
按互補角色建立一份短清單
把候選來源放進清單時，替它寫一句用途。不是每家媒體都要包辦所有角色，也不必讓每個角色只能對應一個網站。以下是可自行調整的分工表，不是經驗證的多樣性量表。
| 來源角色 | 適合取得的材料 | 需要保留的限制 |
|---|---|---|
| 原始文件 | 正式公告、規格、公開資料與適用條件 | 發布者可能有自身利益，文件不自動證明實際成效 |
| 原創報導 | 直接採訪、新取得文件與現場資訊 | 核對取材範圍、引用方式及後續更正 |
| 在地或領域專業 | 當地條件、技術背景與執行細節 | 專業意見仍須交代依據，不能只靠身分推定正確 |
| 相關受影響者 | 實際需求、經驗與被忽略的問題 | 個人經驗不一定代表所有人 |
| 更新與更正入口 | 原文修正、補充說明與文件新版 | 可能就在原有來源內，不必另找一家媒體湊數 |
所有權、資助或商業關係可作為背景註記，但不能僅憑同一股東就判定每篇內容相同，也不能因所有者不同就推定採訪互相獨立。最後仍要回到文章的材料與工作過程。
安排不同角色，是為了補資訊，不是強制安排支持與反對各半。技術文件、透明方法的測試與未具依據的評論，不能因為「觀點不同」就取得相同證據分量。
可先用書籤或簡單表格整理。每個入口至少記下：名稱與連結、服務的問題、角色、常見上游出處、已知限制、最後檢查日期，以及更正或更新位置。不要只保存首頁，卻忘記當初為什麼選它。
假設產品案例：把重複報導歸到共同來源
以下整個案例都是假設，不指涉真實產品、媒體或已進行的測試。某廠商發布一款無線耳機，新聞稿介紹新功能與續航主張。網站甲整理公告；網站乙刊登通訊社報導；網站丙轉載同一份通訊社稿件。
檢查後，如果通訊社稿件也只轉述廠商資料，這三篇對續航的說法仍共同依賴廠商。它們可以提供方便的閱讀入口，但不能直接算成三次獨立驗證。若其中一篇另有採訪，則應把新增部分另外記錄，而不是整篇一概歸為重複。
再假設找到一篇原創測試文，交代樣本、音量、連線模式、功能開關、停止條件，以及產品是否由廠商提供。這些資訊讓讀者判斷方法與適用範圍；本例不提供任何測試結果，也不代表方法公開就必然沒有誤差。
最後，官方技術文件可能補充功能相容性與續航條件。它是更詳細的原始材料，但仍來自廠商，不應另算成一個獨立機構對效能背書。
| 假設材料 | 如何歸組 | 清單中的用途 |
|---|---|---|
| 公告整理、通訊社轉述與轉載 | 共同主張連回廠商新聞稿；有新增採訪才另記 | 保留方便閱讀的入口，合併重複提醒 |
| 官方技術文件 | 廠商原始文件，與新聞稿同屬官方出處 | 查規格條件、相容性與文件更新 |
| 交代方法的原創測試 | 單獨記錄測試者、方法及利益關係 | 檢查實際觀察能否支持特定主張 |
去重不是把使用相同事實的文章判成假新聞，也不一定要全部刪除。更實用的做法，是讓同一組材料只占一個主要閱讀位置，把時間留給真正新增的證據與限制。
每週維護：更新、更正與替換重複角色
清單建好後，可以每週留一段有上限的時間維護，例如十五分鐘。這只是可調整的安排，不是理想時長的研究結論。先處理最近使用過的來源，不必每次重查整份清單。
以下欄位可以直接拿來建立自己的紀錄表；每列放一個常用入口，相關文章則附在該入口下面。
| 欄位 | 填寫內容 |
|---|---|
| 需要回答的問題 | 這個來源具體補上哪一項資訊？ |
| 入口與角色 | 連結、發布者，以及文件、採訪、專業或經驗等用途 |
| 上游出處 | 常引用誰？與其他入口是否共用稿件或公告？未知也要註明 |
| 新增價值與限制 | 新增什麼材料？哪些範圍尚無法支持？ |
| 檢查與更正 | 最後查看日期、原文更新日期、更正位置與待辦問題 |
| 維護決定 | 保留、降低查看頻率、合併重複入口或尋找替代來源 |
- 先開啟近期重要原文，查看是否更新、更正或連結到新版文件；保留變更日期與內容。
- 抽查一篇報導的上游關係。找不到出處時，記為待查；對依賴它的重要主張，另找材料支持。
- 檢查角色重疊。若長期只增加相同轉述，降低其中一個入口的查看頻率。
- 再看缺口。替代來源應補上原創採訪、文件或相關經驗，而不是只換網域。
- 確認清單仍讀得完。議題已不再需要持續追蹤時，改成需要時查閱，不必維持每日訂閱。
未知出處不必直接刪除，但不宜用它充當多份獨立驗證；來源發布更正，也不應只因出現錯誤就忽略其修正方式。記下錯誤、處理與後續表現，比一個永久的好壞標籤更有用。
如果想把選定來源放進閱讀工具，可另看Android RSS 閱讀器與 AI 摘要推薦：Inoreader、Readwise Reader、Feeder 怎麼選。先完成來源分工，再選承載工具，不必為了工具容量擴張清單。
用主題簡報提醒後續缺口，再核對原文
若清單留下某項待追蹤問題，可以另外安排主題簡報。以假設耳機案例為例，可提出：「追蹤這類產品的公開技術文件與方法透明的使用報告，說明哪些主張仍只來自公告，附原始來源與更新日期。」這是提問範例，不是保證會找到指定來源，也不是已設定的 RSS 訂閱或來源白名單。
我們的 FoneClaw 自訂新聞支援主題與目前可用的時間、重複選項，需要相容且支援外掛的 Agent。可手動建立，或先取得 AI 建議，審閱後確認，不合適時取消；預設任務未啟用前不會運作。後續可編輯、暫停、啟用或刪除，查看執行紀錄，並在新聞對話追問出處。
排程可能受網路與 Android 背景限制延遲。產出後仍應開啟實際來源，核對署名、原文與新增材料，再決定是否加入自己的清單；不能把簡報回覆直接當成已完成獨立查證。
可從FoneClaw 自訂新聞功能介紹確認適用方式。今天先挑一個常讀議題，為現有入口補上上游出處與用途，再找出一個尚未被任何來源回答的問題。能維持這條線索，才是新聞來源多樣性比網站數量更有價值的地方。