haxzie/prequel

部落格研究

研究簡報是區分「陳述事實的文章」與「可供查證的文章」的關鍵。部落格中的每一個價格、每一句用戶抱怨、以及每一句「大多數工具在 60 fps 就停止」的陳述，都是對他人產品的宣稱。一個錯誤的宣稱會讓頁面上所有正確的宣稱都失去可信度。此技能負責產出寫作者據以工作的查證清單，除此以外不做任何事：它不負責撰寫文章。

Prequel 的事實並非來自網路。它們來自專案的程式碼庫，下文中第一個章節會說明來源。搜尋「Prequel screen recorder」可能會找到過時的評論，或是另一個同名但完全不同的產品。

資料存放位置

路徑	內容說明
.context/research/<slug>.md	研究簡報。已加入 .gitignore；它只是搭建框架，不會被發布。
apps/web/src/content/competitors.ts	六個已建立頁面的競爭對手的驗證價格與功能。
.claude/skills/comparison-posts/assets/quotes.json	所有已擷取的 Reddit 引用。
apps/web/src/content/posts.ts	部落格已涵蓋的主題。

研究簡報不會被提交到版本控制，因為文章本身會攜帶自己的證據：表格中的價格會附上查證日期、引用資料會附上 Reddit 討論串的連結，而任何需要在文章發布後仍然有效的資訊，都會被移入 competitors.ts 或 quotes.json。一個被提交的研究簡報，只要價格一變動且無人更新，就會立即過時，接著它就會變成一個與實際頁面衝突的第二手資訊來源。

階段 1：主題地圖

在開始搜尋任何東西之前，先寫下這篇文章的定義並確認它。在回覆中寫出三行文字：

• 這篇文章要解答的搜尋問題。 例如：「screen recorder mac no watermark」、「how to record system audio on mac」。文章是為這個搜尋查詢而寫的，它決定了文章的路徑、定義性問題以及 FAQ。

• 文章類型。 評比文交給 [[comparison-posts]]；「最佳 <競爭者> 替代方案」文章交給 [[alternatives-posts]]；教學文、說明文或支柱文章交給 [[guide-posts]]。它們需要不同的研究：評比文需要十種工具的價格，教學文則需要 macOS 的事實和用戶抱怨。

• 定義性問題。 每篇文章都從一個 ## What is <thing>? 章節開頭，而且這個問題必須在整個部落格中是唯一的。在提出新問題前，請先用以下指令搜尋現有文章：

  grep -h "^## What is\|^## How do you" apps/web/src/content/blog/*.mdx
  

然後從 posts.ts 中找出它所屬的支柱。目前有三個支柱：screen-recording-on-mac、product-demo-videos、screen-recording-for-youtube。如果一篇文章不屬於任何現有支柱，那它本身就是一個新的支柱，而這個決定應該由使用者來做，而不是由研究簡報決定。

展示以上資訊並等待確認。若在錯誤的文章類型上進行研究，等於浪費一小時。

階段 2：從程式碼庫取得 Prequel 自身的事實

在開始查閱網路資料之前，先閱讀以下資料，這樣研究簡報才能將競爭對手與 Prequel 實際推出的功能進行對比，而不是與搜尋引擎記得的內容對比：

事實	來源檔案
解析度、fps、編解碼器、輸出格式	apps/web/src/components/landing/LandingBody.tsx 中的 SPECS
自動化初剪功能的內容	同一檔案中的 ALREADY_DONE。除此之外沒有任何功能是自動化的。
價格、試用期長度	apps/web/src/lib/pricing.ts，絕不依賴記憶中的數字
產品常見問題解答	apps/web/src/lib/faq.ts
功能列表及我們的宣稱	competitors.ts 中的 FEATURE_ROWS
系統需求	Apple Silicon、macOS 14 或更新版本、螢幕錄製權限

來自 [[no-dead-air-claim]] 和 [[site-copy]] 的兩條規則同樣適用於研究簡報和最終文章。Prequel 不會剪裁、修剪或移除靜音段落；剪輯是需要在時間軸上手動進行的動作。此外，研究簡報中不得將任何內容寫成 Prequel 的缺點：如果某個競爭對手確實在某方面勝出，研究簡報應記錄此事實，以便寫作者知道不該提出這個主題，並標記為 請勿撰寫。

階段 3：搜尋串流

Firecrawl 是搜尋工具。firecrawl_search 會回傳標題、摘要和網址；firecrawl_scrape 會以 Markdown 格式擷取頁面內容；firecrawl_map 會在廠商將定價資訊藏在三層點擊之下時，列出該網站的頁面。根據文章類型的需求，執行對應的搜尋串流。當需要涵蓋超過三個工具時，以子代理人的形式平行執行；否則直接依序執行。

串流 1，供應商事實。 針對文章中提到的每個工具：擷取並讀取該廠商自己的定價頁面。記錄每個方案及其計費週期，因為未提到年繳方案的月繳報價，是比較文中最具殺傷力的錯誤，而且只要點一下滑鼠就能驗證。記錄下查證日期。如果頁面是由 JavaScript 渲染，而 firecrawl_scrape 只回傳一個空殼，請說明這個情況，並使用無頭 Chrome 來擷取（參閱記憶中的 [[headless-chrome-screenshots]]）。對於 competitors.ts 中已有的六個競爭者，需將取得的資訊與檔案內容進行比對，並標記任何偏差；修正方式是編輯該檔案，而不是在研究簡報中寫入一個不同的數字。

對這個部落格而言，每個工具的重要事實如下，因為這些正是 Prequel 能勝出的領域：每個方案的最高解析度和幀率、免費版或試用版上的浮水印、錄製時長上限、渲染是在本地端還是上傳到雲端、是一次性授權還是訂閱制、以及攝影機是否為可以在錄製後重新構圖的獨立音軌。

串流 2，用戶抱怨。 透過 firecrawl_search 並設定 includeDomains: ["reddit.com"] 搜尋 Reddit，另外也搜尋 Hacker News、G2（特別是兩星和三星評論，其中包含具體的投訴內容）以及 X（推特）。對於替代方案文章，需記錄足夠的資訊以便繪製一張卡片：精確的標題、子版塊或使用者名稱、作者、時間、分數、留言數、第一段。[[alternatives-posts]] 會渲染這些內容。firecrawl_scrape 會直接拒絕 reddit.com，因此只會回傳討論串的標題、摘要和網址，但這對於引用已經足夠。有效的搜尋查詢包括："<tool> pricing" reddit、"<tool> alternatives"、"<tool> watermark"、"<tool> slow"、record system audio mac reddit。

優先選用真正的抱怨，而不是產品發布文。搜尋結果中的許多 Loom 討論串，其實是創辦人以看似抱怨的標題來宣布自己的替代方案。請先檢查 quotes.json：如果某個討論串已經被收錄，其螢幕截圖會存放在 public/blog/quotes/ 中，不需要重新處理。

串流 3，部落格既有的內容。 閱讀 posts.ts 以及任何與該主題相關的現有 MDX 檔案。研究簡報應列出新文章需要連結的既有文章（五篇或更多，包含連結錨點文字）、所屬支柱，以及任何現有文章中的句子可能與新文章產生矛盾的地方。兩篇文章在 Loom 的免費方案上說法不一致，比其中一篇單獨寫錯還要糟糕。

串流 4，macOS 的事實。 對於教學文，需了解在目前版本的 macOS 上，QuickTime 和 Cmd+Shift+5 能做些什麼、不能做些什麼。資訊必須來自 Apple 官方的支援頁面，並附上網址。這些資訊會因 macOS 版本更新而改變，而部落格會將它們視為事實來陳述。

串流 5，統計數字。 任何文章可能引用的統計數據（例如關閉聲音時的觀看時長、Demo 影片的完成率），都必須追溯到其主要來源、標註日期，並且如果超過三年或追蹤來源最終只導向另一個部落格，就必須捨棄。寫作者無法提供連結的數字，就是不能使用的數字。

有效來源的判斷標準

• 來源必須是活著的，並且能載入研究簡報中描述的內容。使用 firecrawl_scrape 驗證；一個回傳 200 狀態碼但內容顯示「暫時限制存取」的頁面，並不是一個有效的來源。G2、Capterra 和 Trustpilot 在使用無頭擷取時，都會有這種回應，因此此處無法使用這些網站。
• 供應商頁面優先於評論網站。詳細頁面優先於摘要頁面。它們之間不一致的頻率遠高於你的預期。
• 必須標註日期。價格、統計數據和 macOS 的行為都必須記錄查證日期。
• Reddit 或 HN 的引用格式是討論串網址加上子版塊或使用者名稱。沒有連結的改寫不是引用，螢幕截圖也不是。
• 文章不得直接連結供應商頁面。 部落格只會連結特定的引用主機：reddit.com、news.ycombinator.com、x.com、g2.com，以及用於數據規模的 github.com 或 producthunt.com。供應商網址僅會出現在研究簡報中用於驗證，不會出現在其他地方。

階段 4：研究簡報

# Research brief: <暫定標題>

Search query: <搜尋查詢>
Genre: guide | roundup | comparison | pillar
Definitional question: ## What is <thing>?     (已確認唯一性)
Pillar: <slug> | none (此文章為一個新的支柱)

## Prequel facts used
<條列式，每個項目都要標註來源檔案>

## Do not write
<任何競爭對手勝過 Prequel 的點，以便寫作者避免提及此主題>

## Tools
### <工具名稱>
Price: <每個方案及其計費週期>. Checked <日期>. <供應商網址>
Facts: <解析度, 幀率, 浮水印, 錄製時長上限, 本地或雲端, 授權方式>
Prequel wins on: <此區塊應傳達的關鍵對比點>
Complaints: <討論串標題> (r/<子版塊>) <網址>    <- 存在於 quotes.json？是/否

## macOS facts
<條列式，每個項目都附上 Apple 的網址和查證日期>

## Numbers
<統計數據> <主要來源網址> <發布日期>

## Existing posts to link
/blog/<slug>  "<錨點文字>"  (適合的原因)

## Contradictions
<任何現有文章可能與此篇文章矛盾的內容>

## FAQ candidates
<問題，如同使用者會在搜尋框中輸入的那樣> (來源：討論串網址或 PAA)

## Angles
<三到五個切入點，來自於用戶提問與現有內容之間的落差>

將以上內容寫入 .context/research/<slug>.md，並在結尾提出一個寫作者需要回答的問題：接下來該使用哪個技能，[[guide-posts]] 或 [[comparison-posts]]，以及是否需要先修剪切入點清單。