social-post-review

name

social-post-review

description

校閱、打磨要發到社群（以 Facebook 為主）的短文貼文（約 1k 字）—— 看主軸是否單一貫穿、開場能否扛住『顯示更多』截斷、與母體（演講 / 長文）是否互補不互搶、可貼性與外連策略、引用是否回源查證。Use when reviewing or polishing a Facebook / social short post drafted in Obsidian, a 暴雷文 / 預告文 that companions a talk or long article, or any ~1k-char 社群貼文 / 短文. Triggers on facebook, FB, 社群貼文, 短文, 貼文, 暴雷文, 預告文, po 文, 短文校閱, 貼文校閱. Do NOT use for talks / keynotes / slides (publish-review:talk-structure), long-form blog articles needing formal multi-round review, or the line-level mechanics of marking changes (obsidian-review:obsidian-revision-marks).

社群短文校閱方法論

校閱一篇要貼到社群（Facebook 為主）的短文時，處理的不是「逐字稿潤飾」，而是這篇有沒有在約 1k 字內，用一個清楚的主軸打中讀者、並把該補的事實補對。短文的紀律跟演講、長文都不同，這個 skill 把一套可重複的短文校閱流程固定下來。

短文常見的角色：它往往是某個更大內容（一場演講、一篇長文）的衛星 —— 暴雷文、預告文、延伸補充。校閱時要同時顧「這篇自己站得住」與「它跟母體的關係正確」。

---

短文的形態紀律（跟演講 / 長文的差別）

• 長度：約 1k 字是體感基準、不是硬規定。短文的成敗在「一句話打中」，不是鋪陳論證（那是長文的事）。寧可砍到只剩一個洞見 + 一個證據。
• 單檔迭代、不分 draft / release：短文不像演講要拆「工作稿 / 釋出稿」兩份。一個檔案裡：上面放 meta（主軸、對應的母體、source、待補），下面放「可直接貼出去的本文」，反覆改同一份。
• 可貼性優先：本文是要被複製貼到社群的純文字。社群不吃 markdown —— 不要在本文用 ## 標題、**粗體**、markdown 連結語法（會原樣顯示出來）。結構靠空行、【】、條列符號（・/1.）、箭頭（→）。
• 多圖貼文分區：FB 等平台一次貼多張圖時，每張圖可以個別加說明文字。草稿就把「主貼文內文」與「各圖圖說」分成兩區（### 圖1 / 圖2 / 圖3，圖說緊貼對應圖片），別把圖說塞進內文 —— 否則內文虛胖、貼的時候還要再拆。圖說各自也要能獨立讀懂。外部連結（repo、demo 站）通常放第一則留言而非內文。
• 跨 session 可重跑：短文常常要隔幾天、換個 session 再看一次。每次校閱都重讀本文、重跑下面的檢查清單，不要假設上一輪的判斷還成立。

---

三條鐵則（每篇必查）

這三條是使用者特別在意的硬規矩，每次校閱都要逐條過。

鐵則 1：專有名詞首次中英對照，之後只用英文

• 任何專有名詞 / 概念詞第一次出現時給中英對照，例如「護欄（guardrails）」「依賴反轉（dependency inversion）」；縮寫第一次出現要展開，例如「DX（developer experience）」。
• 之後同一個詞就按使用者習慣只用英文，不再重複對照。
• 拿捏：有對應中文譯名、或會被誤解的概念才需要對照；使用者本來就習慣用英文講的詞（contract、agent、CLI…）英文本身就是那個詞，不必硬塞中文。判不準時，對照了再說、別漏。
• 時機（重要）：這條留到內容定稿後的最後一輪「收尾」才一次做完，不要在內容還在改的每一輪都 enforce —— 內容會動、用詞會變，提早做不但白工，還會造成「有些詞對照了、有些沒有」的半套不一致。內容迭代階段把它列為待收尾項、先略過即可。

鐵則 2：本文避免 #XXX，會變成 hashtag

• Obsidian 編輯 / 預覽，以及社群平台，都會把 # 開頭的字串吃成 hashtag（純數字如 #1 在 Obsidian 不算 tag，但社群與觀感上仍建議避開）。
• 要表達「系列第幾篇 / 編號 / 議題號」時，改用無 # 的寫法：第 1 篇、Vol.1、No.1、（一）、①、或全形 ＃。
• 注意：本文（要貼出去的純文字）裡的 # 才是問題；Obsidian 檔案上方 meta 區用的 markdown 標題 #/## 是檔案結構、不受影響。

鐵則 3：引用的名稱 / 網址 / 術語逐一回源查證

使用者自承可能把引用打錯 —— 大小寫、單複數（有沒有加 s）、記成同義字或相近的名字。校閱時：

• 把本文引用到的專案名、檔名 / 路徑、網址、產品 / 服務名、API / 型號、技術術語全部挑出來。
• 回原始來源比對：repo（用 ls/grep 對實際專案與檔名）、官網 / 官方文件（用 fetch 對拼法）、規格檔（對術語）。
• 把每一處不符列出來（原 → 應為 + 依據），修正後告訴使用者你改了什麼、根據什麼。
• 特別容易錯的：.Extension vs .Extensions、Storefront vs StorefrontUI、產品大小寫（GitHub/Github）、人名 / 公司名同音異字。
• 若引用的東西在母體（演講 / 長文）也出現，順手確認兩邊拼法一致。

---

校閱檢查清單

逐項過，給出「OK / 建議改 / 待你確認」三種結論之一。

1. 主軸是否單一且貫穿 —— 一篇短文只扛一個主軸（標題講的那個）。主軸要在本文裡至少回扣一次，不能只出現在標題。沿用正面肯定句、答案前置（與 talk-structure 原則 2 一致）。
2. 開場扛不扛得住截斷 —— 社群動態通常只露前 2–3 行就「顯示更多」。把最強的洞見 / 鉤子放最前面，行政資訊（活動時間、頭銜、客套）往後挪。被截斷的預覽要賣的是「想法」，不是「行程」。
3. 與母體一致且互補 —— 若這篇是某演講 / 長文的衛星：用詞與框架要跟母體一致（同一個概念別換名字）；內容要互補不互搶（例如演講不講實作細節，短文就補實作細節，而不是把演講重點原樣搬出來）。
4. 有沒有一個落地的具體 —— 再短也要有一個具體的東西撐著（一個細節、一張圖、一個數字、一段對話），不要整篇只有形容詞與大道理。
5. 圖文對應 —— 本文若提到「圖1 / 圖2…」，確認真的有那張圖、且圖的內容對得上文字描述（例：說「decision table」的那張圖真的有 decision table）。
6. CTA 與外連策略 —— 結尾的行動呼籲清楚嗎？外部連結要嘛發文前補齊、要嘛改放第一則留言（多數社群演算法會壓含外連的貼文）。本文裡留 (待補) 提醒，但別帶著 (待補) 發出去。
7. 公開語氣與點名風險 —— 工具 / 廠商 / 產品 / 同業的比較與評價，語氣要中肯、留餘地；點名個人 / 公司前想一下公開講合不合適。自我揭露（用量、訂閱、內部數字）確認願意公開。
8. 三條鐵則 —— 見上，逐條過。
9. 長度落點 —— 報出本文的中文字數 / 總字元數，對照「約 1k 字」基準；過長就指出最該砍的段落（通常是離主軸最遠的背景或比較）。
10. 系列感（若適用） —— 連載要有清楚編號（用鐵則 2 的無 # 寫法）＋ 一句往後勾的預告，讓讀者想追下一篇。

---

校閱流程

1. 重讀本文 —— 只看「要貼出去」的那段純文字，先抓主軸與開場。
2. 跑檢查清單 + 三條鐵則 —— 逐項標 OK / 建議改 / 待你確認。
3. 能直接改的就改 —— 用字、對照、# 改寫、查證後的拼字修正，直接動本文（這是協作中的工作稿，不上修訂標記）。但牽涉主軸或結構的調整、以及「事實層」的修正（改了引用的名稱 / 數字），要在收尾明講你改了什麼、依據什麼，讓使用者複核。
4. 查證回源 —— 鐵則 3 的引用，實際去 repo / 官網比對，別只靠記憶。
5. 收尾報告 —— (a) 本文字數落點；(b) 三條鐵則逐條結果；(c) 我直接改了哪些（含查證依據）；(d) 還要你拍板的項目（待補連結、圖、語氣風險…）。
6. 可多輪 / 跨 session —— 下一輪重跑流程；若使用者給了新觀點，先想清楚它該進開場（當鉤子）還是收尾（當餘韻）。

---

與其他 skill 的關係

• 同屬 publish-review plugin（對外發表內容的 review 家族）：
  • 本 skill 管社群短文（~1k 字，FB 為主）—— 重「一句話打中」、單檔迭代、可貼性。
  • talk-structure 管演講 / 簡報 —— 重主軸骨架、講者註記、工作稿 vs 釋出稿。
  • 長文部落格（~100k 字、需要更正規的多輪往返校閱）是另一條線，不在本 skill 範圍。
  • 三者共用「先在 Obsidian 打草稿 → skill review」的流程，但長度與形態紀律各自不同。
• 搭配 obsidian-review:obsidian-revision-marks：當短文是改在「使用者長期維護的既有檔案」上（而非協作中的工作稿）時，用那個 skill 的 %%...%% / footnote 語法標記每處變動讓使用者複核。本 skill 的直接改，限於協作中的短文工作稿。
• 搭配 obsidian:obsidian-markdown：處理 wikilinks / callouts / 嵌入圖等 Obsidian 語法（注意：要貼出去的本文不要用這些，社群不吃）。

---

何時不適用

• 演講 / 簡報大綱 —— 用 talk-structure。
• 長文部落格 / 需要正規多輪校閱的文章 —— 不在本 skill 範圍，用一般長文校稿流程。
• 只是要標記某份既有檔案的變動語法 —— 那是 obsidian-revision-marks。
• 不是要對外發表的私人筆記 / 草稿 —— 不必套這套發表紀律。