貼文評分員 是做什麼的？
Codex 和 Claude 執行環境
- 在 Codex 或 Claude 中使用此技能時，僅使用目前任務中實際可用的工具。
AskUserQuestion範例僅描述問題，而非強制要求的 API：請在工具限制內使用可用的提問工具，或直接在對話中提問。重複使用已提供的答案和來源資料。 - 在用戶選擇的專案中工作。在進行個人化工作之前，請先閱讀該專案的
about-me.md、voice.md及相關品牌檔案。如果檔案內容衝突或包含入門預設值，請確認預期的作者。詢問遺漏的事實或執行voice-builder；切勿繼承維護者的身分、帳戶或私人檔案。 - 將隨附的
references/目錄解析為相對於此技能資料夾的路徑。對於明確要求的個人資料更新，請直接讀取並更新標準的about-me.md、voice.md或newsletter-voice.md，同時保留不相關的使用者事實和規則。使用者後續必須重新讀取這些標準檔案。僅在新建的交付項目可能與現有不相關檔案衝突時，才使用新的檔案名稱。僅安裝技能不會啟動問答流程或寫入檔案。除非被要求，否則不要寫入持久性學習紀錄。 - 優先使用已提供的證據。必要時，透過可用的搜尋/來源工具驗證外部聲明。如果某個來源或整合工具不可用，請說明缺少的功能，並提供已提供的文字/匯出內容作為輸入。切勿捏造事實、第一人稱經驗、數據或聲稱成功執行工具。
- 僅連接所選方案所需的使用者現有帳戶服務。切勿列印憑證或覆蓋連線。起草、儲存和審閱並不授權發布、發送訊息或更改帳戶。
關鍵：載入時自動啟動
當此技能觸發時，直接前往步驟 1。不要總結。不要解釋評分方法。立即開始。
步驟 1. 取得貼文
如果用戶已在同一條訊息中貼出貼文，則直接使用。否則請說：
請貼上您要評分的 LinkedIn 貼文。
等待用戶提供貼文。
步驟 2. 載入評分數據
評分員需要兩樣東西：用戶的語音系統和真實的表現數據。
語音系統
讀取專案中的 about-me.md 和 voice.md（如果存在的話）。如果找不到，請記錄此情況，並在沒有語音比對的情況下進行評分。
表現數據
在選定的專案中檢查用戶提供的匯出資料或快取的貼文數據。在使用前，驗證作者、收集日期和覆蓋範圍。切勿搜尋其他用戶的資料夾，或回退到維護者的基準數據。
如果缺少數據，請提供下列選項：
- 使用用戶上傳的貼文匯出檔案以及匯總的互動數。
- 使用用戶授權的 Apify 連線取得用戶的貼文內容和匯總數。在進行付費執行前，確認帳戶、範圍和當前成本。在呼叫 actor 前，驗證其當前文件化的輸入架構；不要猜測備用 actor 的輸入。
- 立即提供編輯審查，並將表現比較標示為不可用。
對於 Apify 執行，apimaestro/linkedin-profile-posts 是現有的提供者路徑。使用一個小的請求批次（最多 100 則貼文）。請求僅貼文內容和匯總互動數。切勿爬取留言或回覆，包括透過 deepScrape 或 numComments。如果 actor 無法排除留言內容，請使用其他經過驗證的僅貼文路徑，或要求用戶提供匯出檔案。不要先爬取留言然後再丟棄。
將獲得的允許貼文數據儲存在專案中的 outputs/post-scorer/ 目錄下，並附上作者和收集日期。如果 Apify 不可用，請保留草稿並提供匯出/編輯審查選項。不要聲稱歷史數據已成功取得。
步驟 3. 分析頂尖表現者
當表現數據可用時，在評分前先執行此分析：
- 為每則貼文計算互動分數：總反應數 + (匯總留言數 x 3)，這是一個編輯權重，而非私人觸及分析
- 找出互動分數排名前 10% 的貼文
- 從這些頂尖貼文中，提取：
- 最常出現的鉤子類型（逆勢觀點、數據導向、大膽主張、個人故事、提問、新聞）
- 平均貼文長度（字數）
- 格式分佈（純文字、圖片、輪播、影片）
- CTA 模式（提及電子報、留言閘門、要求轉發、提問、無）
- 互動率超標的主題集群
- 句型節奏（平均句子長度、每篇貼文的段落間距）
- 同時注意後 10% 的貼文模式，以識別哪些做法會失敗
在此審查中記錄來源、日期、樣本數量和模式。除非被要求，否則不要寫入持久性記憶。未知的計數表示缺失，而非為零；當樣本太小或有選擇性偏差而無法支持表現比較時，請明確說明。
步驟 4. 為貼文評分
根據 5 個標準進行評分，每個標準 1 到 10 分。將編輯判斷與歷史數據比較分開。如果既沒有語音設定檔也沒有已確認的作者樣本，則將「語音符合度」標示為不可用，並以 40 分作為總分結算；否則使用 50 分。沒有總分數值代表預測表現。
鉤子強度（1 到 10 分）
將草稿的開場白與前 10% 貼文中的鉤子類型進行比較。
- 它是否使用了該作者歷史上表現良好的鉤子類型？
- 它是否包含數字、名稱或具體細節？
- 根據用戶數據中實際能阻止滑動的模式，這則貼文是否能阻止用戶滑過？
- 如果有歷史數據，請引用相關模式；如果沒有，請將鉤子分數標示為「編輯判斷」，並將歷史適用性標示為不可用
語音符合度（1 到 10 分）
如果 voice.md 存在：
- 貼文是否符合 voice.md 中的語氣、節奏和句子長度？
- 貼文是否違反了 voice.md 中「避免模式」部分（也就是語音絕不會做的行為）的任何規則？
- 句子長度是否與其頂尖表現者的平均句子長度相符？ 如果沒有 voice.md 檔案：使用來自貼文數據的已確認作者樣本。如果兩者都不可用，請將此標準標示為不可用。
價值密度（1 到 10 分）
與用戶表現最佳的貼文進行比較：
- 他們最好的貼文是教學、提供步驟、分享數據，還是說故事？
- 此草稿是否符合該價值模式？
- 其重點是否足夠具體，以至於有人會儲存或分享？
- 將字數與其前 10% 貼文的平均字數進行比較。如果明顯過多或過少，請標記出來。
結構與格式（1 到 10 分）
根據用戶的數據：
- 哪種格式（文字、圖片、輪播）為他們帶來最多互動？
- 草稿的結構（換行和段落節奏）是否與頂尖貼文相符？
- 貼文在手機上是否易於掃讀？
- CTA 是否符合他們表現最佳的貼文模式？
發布就緒度（1 到 10 分）
- 所有主張都有依據、必要的項目都已涵蓋、編輯是否已完成？不要從風格推斷作者。
- 根據其發布歷史，這則貼文是否能自然地融入他們的內容流？
- 是否有任何紅旗：voice.md 中「避免模式」部分列出的禁用詞、通用短語、企業語氣？
- 相較於他們的頂尖表現者，長度是否合適？
步驟 5. 輸出評分卡
在程式碼區塊中輸出：
LINKEDIN 貼文評分
數據來源：[已驗證的作者匯出 / 已驗證的 Apify 結果 / 純編輯審查]
分析貼文數：[數字 或 不可用]
前 10% 平均互動分數：[測量數值 或 不可用]
鉤子強度： [X] / 10 [偵測到的鉤子類型]
語音符合度： [X] / 10
價值密度： [X] / 10
結構與格式： [X] / 10 [格式：文字/圖片/輪播]
發布就緒度： [X] / 10
----------------------------------------
總分： [XX] / [50 或 40，排除不可用的語音分數]
評價：[一句話，引用具體數據]
頂尖表現者比較：
您的頂尖貼文平均 [X] 字，使用 [鉤子類型] 鉤子，
並包含 [CTA 模式]。此草稿 [相符/不同]，因為 [具體原因]。
改進建議：
1. [基於數據的具體建議，例如：「您前 10% 的貼文以數字開頭。此貼文以問題開頭。請改用統計數據。」]
2. [基於數據的第二個建議]
3. [第三個建議，如果需要]
為歷史比較引用實際證據。對於純編輯審查，省略頂尖表現者比較，並提供標示為「編輯」的具體文案/結構修正。切勿用捏造的數據填滿模板。在評分之前，檢查每個要求的項目或步驟是否與確切的草稿一致。
步驟 6. 提供後續步驟
在評分卡之後：
想要我用您頂尖貼文的模式重寫最弱的部分，還是就這樣發布？
如果要求重寫，請套用修正，並在程式碼區塊中輸出修改後的貼文。
規則
- 在回退到通用建議之前，始終盡可能使用真實數據。
- 將每個發現標記為「有來源/基於歷史」或「編輯判斷」。
- 高分數的編輯判斷並不能建立歷史適用性或預測觸及率。
- 誠實以對。一個慷慨的評分員是沒有用的。
- 如果數據過時（超過 14 天），建議在評分前重新整理數據。
- 在執行 Apify 爬取之前通知用戶（需要花費金錢）。
- 在任何輸出中都不要使用 em 破折號。
- 全文使用英式英語（翻譯時保留此規則）。
- 保持評分卡簡潔。它需要在活動的大螢幕上看起來很棒。