Community寫作與編輯github.com

demandvector/channel-content-review

審查、標記、摘要或改寫通路/合作夥伴行銷內容,依購買階段、意圖權重、讀者角色、交付擁有者以及與合作夥伴自身定位的契合度進行評估。

channel-content-review 是什麼?

這項技能旨在系統化地評估通路行銷內容(無論來自品牌方或合作夥伴),確保每份內容精準對應購買週期中的正確階段。它會分析內容在意圖(問題、解決方案、效益、成果)上的權重分布,判斷其主要服務的購買階段,並檢驗該內容是否針對該階段的核心讀者角色(如決策者、擁護者、執行者)撰寫。技能特別強化了合作夥伴定位檢查,確保合作夥伴交付的內容能讓買家感受到是合作夥伴自身的專業建議,而非單純轉發的品牌素材。支援Cline、Claude Code、Cursor、Codex等主流AI代理平台,並提供詳細的程序步驟、參考網格和標準化報告格式,讓審查流程可重複且客觀。

相容平台~Claude Code~Codex CLI~Cursor
npx skills add https://github.com/demandvector/gtm-automation/tree/HEAD/skills/channel-content-review

Installed? Explore more 寫作與編輯 skills: steipete/notion, langchain-ai/langchain, bytedance/podcast-generation · View all 6 →

在你喜歡的 AI 中提問

開啟一個已預先載入此 Agent Skill 的新對話。

說明文件

通路內容審查

當有人提供一份通路內容(或一批內容)、一份摘要,或要求改寫品牌內容以供合作夥伴使用時,請使用此技能。任務是判斷該內容服務於哪個購買階段,其權重、讀者和交付方式是否適合該階段,以及當合作夥伴交付時,買家是否會將其視為合作夥伴自身的專業知識。

此方法適用於通路的雙方。品牌合作夥伴經理用它來審查要放入合作夥伴資料庫的內容;合作夥伴則用它來審查品牌提供的內容,並將其調整為符合自身定位。

參考網格

四個購買階段。每個階段都有一個主導意圖、一個最活躍的讀者,以及一個常見的交付擁有者。相鄰階段會有所融合;網格標示了權重通常所在的位置,作為一個起點而非硬性規則。

階段買家狀態...意圖(權重)讀者常見交付典型內容
發現首次為問題命名問題執行者品牌以讀者用語描寫問題的指南;結尾處點名解決方案類別
協作找出解決方法,引入專家解決方案擁護者、影響者合作夥伴以買家所在產業為背景的解決方案操作指南,圍繞合作夥伴的服務建立
共識比較選項;委員會形成,否決浮現效益整個委員會(執行者返回進行技術檢查)合作夥伴擁護者轉發的評估資料;包含合作夥伴的證明和技術細節
決策詢問成功的樣貌成果(ROI、商業案例、回本時間)決策者、擁護者共享商業案例,將品牌的數據與合作夥伴的交付計畫相結合

讀者角色採用類似RACI的詞彙:決策者(預算、簽核)、擁護者(內部倡導)、影響者(評估期間被諮詢)、執行者(購買後部署)、被告知者(了解該類別,無購買角色)。

程序

1. 收集輸入

  • 內容(文字、連結或檔案)。若為批次,取得每一份;不要抽樣。
  • 誰將交付此內容(如果已知)。如果未知,請在步驟 5 中推斷。
  • 如果由合作夥伴交付:合作夥伴的定位(參見下方的合作夥伴檔案)。詢問他們的網站、服務頁面、案例研究或一段描述。不要猜測合作夥伴的產業或聲明。

2. 找出主要階段

大略估算內容有多少比例導向每個意圖:問題、解決方案、效益、成果。佔比最大的部分指向主要階段。列出分佈,例如「問題 60 / 解決方案 25 / 效益 10 / 成果 5 → 發現」。

大部分內容會傾向某一方,其他意圖以較低權重存在。發現階段的內容仍會在結尾處提及解決方案類別;決策階段的內容仍會用一兩行重申問題。如果兩個意圖的比例非常接近,請說明並選擇結構上偏重的那個(標題承諾了什麼,結尾要求了什麼)。

3. 比較權重與階段

將比例分佈與網格進行比較。值得檢查的模式:

  • 一份側重解決方案的內容被規劃為認知內容,讀起來像協作內容,而合作夥伴是它可能的載體。
  • 沒有證明佐證的效益部分,讓共識階段的讀者找不到他們想要的東西。
  • 商業案例中過長的問題重申部分,耗費了決策讀者對已知領域的注意力。
  • 在所有四個意圖上的權重均分,使得內容沒有主要階段,因此沒有先服務任何讀者。

4. 檢查讀者

說出在主要階段最活躍的角色,並檢查內容是否為他們而寫:詞彙、深度以及要求他們下一步做什麼。一份只寫給擁護者的共識內容,在轉發給委員會後仍能站得住腳時效果最佳。

5. 確定交付方式

誰最有可能將此內容呈現在買家面前:品牌、合作夥伴,或兩者?

  • 通常由品牌主導:大規模觸及市場的發現階段內容。
  • 通常由合作夥伴主導:協作和共識階段,合作夥伴是購買過程的門面。
  • 通常由雙方共享:決策階段,品牌帶來產品數據、ROI研究和客戶成果,合作夥伴帶來交付計畫。

如果一份內容的權重在協作或共識,但卻以品牌的口吻為一般買家撰寫,請標註:買家很可能會以合作夥伴的名義閱讀它,而且為該合作夥伴撰寫會更有效。

6. 如果由合作夥伴交付,檢查合作夥伴契合度

買家會根據他們對該合作夥伴的看法來審視合作夥伴交付的內容,而這個看法是從合作夥伴的定位形成的。根據合作夥伴檔案的每一行檢查內容:

  • 它是否屬於合作夥伴主打服務的範疇?
  • 它是否針對合作夥伴提到的產業?
  • 它是否使用了合作夥伴已經聲稱的價值,並用合作夥伴的用語表達?
  • 證明是否來自合作夥伴(案例研究、資格證明、指名客戶)?這在共識階段最為重要。
  • 它是否符合合作夥伴承諾的服務水準?

當買家會將其視為合作夥伴自身的專業知識,且品牌產品內嵌於合作夥伴服務之中時,該內容即為契合。如果內容讀起來像是合作夥伴轉發的品牌文宣,那麼調整方法就是根據合作夥伴的定位進行改寫。在品牌內容上加上聯合品牌標誌並不會改變契合度。

7. 報告

使用下面的輸出格式。按影響程度對建議進行排序:先處理交付和合作夥伴契合度,然後是權重,再來是讀者,最後是潤飾。

合作夥伴檔案

為每個合作夥伴建立一次並重複使用。它回答了買家在評估未曾合作過的合作夥伴時常會問的問題:

買家的問題由誰回答
他們做什麼?他們主打的服務
他們了解我的領域嗎?他們提到的產業
他們專業嗎?他們發表的專業知識(文章、演講、認證)
他們會出現嗎?服務承諾(回應時間、SLA、交付模式)
我能信任他們嗎?證明:案例研究、獎項、員工資格、客戶標誌
他們說自己值多少?他們聲稱的價值,用他們的用語

盡可能從合作夥伴自己的資料中,將答案記錄為簡短列表。此檔案是步驟 6 的參考,也是任何改寫工作的摘要。

輸出格式

單一內容

內容:<標題>
主要階段:<階段>(問題 X / 解決方案 Y / 效益 Z / 成果 W)
權重:符合 | 部分符合 | 偏離其他階段 — <一行>
讀者:<角色> — 是否為他們而寫?是 | 部分 | 尚未 — <一行>
交付方式:品牌 | 合作夥伴 | 兩者 — <原因>
合作夥伴契合度(若由合作夥伴交付):符合 | 部分符合 | 尚未 | 無法評估 — <需要處理的檔案行>
建議,依優先順序排序:
1. ...
2. ...

批次審查

一個表格,每行一個內容:標題、主要階段、意圖分佈、讀者、交付方式、合作夥伴契合度。然後:

  • 階段覆蓋率:每個階段的數量,以及哪些階段的內容最少。
  • 交付契合度:權重在協作或共識,但以品牌優先撰寫的內容。
  • 機會:尚無內容的階段或讀者,以及哪些合作夥伴交付的內容可以補齊組合。
  • 前三項建議。

摘要或改寫

在撰寫之前,說明階段、讀者、交付方式以及內容應滿足的合作夥伴檔案行。然後以合作夥伴的口吻產出內容,將品牌產品置於合作夥伴服務之中,針對合作夥伴的產業,使用合作夥伴的價值用語。對於共識階段,以合作夥伴自身的證明為主。對於決策階段,將品牌的數據和客戶成果與合作夥伴的交付計畫相結合。

規則

  • 不要強加階段。如果內容是分佈式的,報告分佈和矛盾之處。
  • 不要編造合作夥伴的事實。如果沒有檔案,要求提供一份,或將合作夥伴契合度標記為「無法評估」。
  • 契合度來自為合作夥伴的定位撰寫;僅聯合品牌無法改變它。
  • 一份內容可能寫得很好,但對於其交付者而言卻處於錯誤的階段。審查關乎內容對階段、讀者和交付者的契合度;最後簡短地提及散文要點。
  • 當為合作夥伴而非品牌審查時,請反轉框架:審查品牌提供的內容,找出哪些協作和共識內容會有幫助,並向品牌要求原始素材(技術細節、ROI研究、客戶成果、授權以合作夥伴名義發布)以及完成的文宣。

基於「How to Weight Channel Content Across the Buying Cycle」(DemandVector,2026):https://www.demandvector.com/resources/weighting-channel-content

相關技能