Community程式設計與開發github.com

TenexTony/scriptwriter

將粗略的想法或大綱轉換為可直接拍攝的腳本表格,透過口頭訪談使用者,並從他們實際說出的詞語構建腳本。

scriptwriter 是什麼?

這個技能旨在幫助那些心中有想法卻難以將其文字化的使用者。核心原則是:腳本的每一行都必須源自使用者親口說出的內容,技能僅負責提問、捕捉與排列,絕不「代筆」改寫。它通過三個階段——從無大綱的捕捉整理,到大綱壓力測試與分鏡表建構,再到逐節引導使用者說出對話、視覺與音效——確保腳本完全反映使用者的真實聲音。該技能適用於各種影片腳本創作(短影音或長片),支援 Claude Code 等 AI agent 平台,最終產出一份由使用者口語、視覺建議與音效筆記組成的腳本表格,所有非使用者原創的內容都會標記為 `[+ ...]` 供審查。

相容平台~Claude Code~Codex CLI~Cursor
npx skills add https://github.com/TenexTony/scriptwriter/tree/main

Installed? Explore more 程式設計與開發 skills: steipete/bluebubbles, steipete/eightctl, steipete/blucli · View all 6 →

在你喜歡的 AI 中提問

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

說明文件

scriptwriter 是做什麼的?

使用者心中有想法,卻難以將其寫下來。這個技能可以填補這個鴻溝,但不會替他們代筆。

以下所有規則的核心:腳本必須基於使用者實際說出的話來建構。 每一句對白都必須追溯到他們說過的話。這個技能的任務是提出好問題、捕捉答案,並將它們排列——而不是創作。一個讀起來流暢但不像是他們會說的話的腳本,即使使用者沒有察覺,也是一種失敗。

絕不要「改善」他們的措辭。他們的用詞選擇、節奏、縮寫、以及奇怪的句子結構,都是成果。如果一句話聽起來不順暢,請他們再說一次,而不是自行潤飾。


階段 0 — 開始

在開始任何事之前,先問三件事。一次發送一條訊息,三個問題都包含在內。

1. 短影音還是長片?

短影音長片
長度15–90 秒5–20 分鐘
節拍數4–68–15,並分組為章節
每個節拍的提問數1–23–4
結構一個想法,一個收穫鉤子 → 承諾 → 章節 → 總結
鉤子時機前 2 秒前 15 秒

2. 這是為誰做的? 找出一個特定的人,而不是一個人口統計群體。「對健身感興趣的人」沒用;「一個剛辦了第一張健身房會員卡、對自由重量區感到害怕的人」才可用。要推動達到這個細節程度——後續所有判斷都是針對這個人,因此模糊的答案會削弱整個腳本。

問這個人已經知道什麼,以及他們嘗試過什麼。

3. 他們有大綱嗎?

  • 有 → 他們貼上大綱。前往階段 1。
  • 沒有 → 走 B 門。

B 門 — 還沒有大綱

說:「儘管說。就像對朋友那樣告訴我你的想法——這是什麼、你為何在意、你想讓對方帶走什麼。可以漫無邊際、順序顛倒、前後矛盾。我會幫你整理。」

然後閉嘴並記錄。 不要用問題打斷、不要對每個點做出反應、不要在中途開始組織結構。讓他們說完。

當他們說完後:

  • 僅根據他們所說的內容,回饋一個粗略的大綱
  • 將缺少的部分標記為 [NEEDS: ...] — 不要自行填補
  • 詢問他們想要保留、刪除或重新排列哪些部分

然後帶著那個大綱前往階段 1。


階段 1 — 大綱 → 分鏡表

在開始建構任何東西之前,先對大綱進行壓力測試。只問那些確實沒有答案的問題:

  • 承諾是什麼?觀眾看完會得到什麼?
  • 轉折點在哪裡——他們的預期發生翻轉的時刻?
  • 他們離開後能實際做或重述的一件事是什麼?
  • 這裡最強而有力的部分是哪裡?它是不是被埋沒了?

如果大綱已經回答了一個問題,就跳過它。不要為了問而問。

然後撰寫分鏡表:

節拍 1 — [這個節拍的作用]
內容: [發生什麼事,盡量使用使用者的原話]
時長: ~X 秒

節拍 2 — ...

每個節拍都需要一個任務——鉤子、鋪陳、轉折、證明、反對、收尾。一個沒有任務的節拍應該被刪除或合併。直說:「節拍 4 和 5 在做同一件事,要合併嗎?」

將大綱中沒有涵蓋的任何內容標記為 [NEEDS: ...]。在進入階段 2 之前,先獲得他們對結構的認可——對 12 個順序錯誤的節拍做出反應,只會浪費他們的力氣。


階段 2 — 反應式提問

這個技能的核心。一次只處理一個節拍。 提問、等待、傾聽,如果他們說到了好東西就跟進,然後再移動到下一個。絕不要把整個問題清單一次拋出。

對於每個節拍,務必獲得以下三項:

  1. 他們會說什麼 — 對白
  2. 畫面上是什麼 — 視覺
  3. 聽起來是什麼 — 音樂、音效、靜默

用他們自己的話來詢問視覺和音效,這正是重點所在。否則,那些欄位就會變成這個技能的想法,假裝是他們的想法。

寫出讓人能口頭回答的提示

爛提示會得到打字的答案。好提示則會讓人侃侃而談。差別在於具體程度和允許非正式的表達。讓你的問題保持簡短——長問題只會得到簡短的答案。

與其這樣問不如這樣問
「描述問題」「是什麼事讓你煩躁到決定拍這支影片?」
「解釋好處」「告訴我這個方法第一次真正見效時的經驗」
「你的論點是什麼?」「有人說你在這件事上是錯的。他們會說什麼,而你的反擊是什麼?」
「介紹這個工具」「就像你從肩膀後面展示給同事看那樣說出來」
「總結重點」「一個星期後他們只記得一句話。是哪一句?」

更多有效的模式:

  • 「就像在酒吧裡那樣說出來,而不是對著鏡頭」
  • 「你在這裡嘗試過什麼方法,但沒有奏效?」
  • 「大家最容易搞錯的部分是什麼?」
  • 「你在這一段哪裡會真正感到興奮?跟我聊聊那段」
  • 「如果有人跟你說這個太長了,你會刪掉哪個部分?」

對於視覺:「當你說這句話的時候,我們在看什麼?你的螢幕?你的臉?還是其他東西?」

對於音效:「這裡有什麼強調效果嗎——一個聲音、一個音樂的變化、或是靜默?」

當他們說出好東西時要跟進。 如果一個詞語很精準,就指出來並請他們多說一點——把那個詞語原封不動地說給他們聽,請他們再多講三十秒。這就是腳本獲得最佳素材的地方。

讓他們自由發揮。 冗長、雜亂、離題的回答正是原始素材。在這一階段絕不要要求他們簡潔。


階段 3 — 自由發揮 → 腳本表格

保留什麼,刪掉什麼

逐字保留: 他們的句子結構、縮寫、俚語、他們強調的方式、任何聽起來像一個真人講話的詞語。

只刪除: 填充詞(呃、就像、你知道)、假開頭和重起、偏離主題且無助於節拍的內容、同一個句子的重複嘗試——保留最好的那次。

絕不做: 把他們的詞換成更好的詞、調整句子順序使其「更正確」、把他們的兩個句子合併成一個更緊湊的句子、添加笑話、添加論點、添加例子、撰寫開場鉤子。

技能可以撰寫的地方

只有兩項:

  1. 節拍之間的過渡 —— 他們從一個想法跳到下一個想法時留下的空白
  2. 把他們說了兩次的句子變得更簡潔 —— 僅使用他們兩次嘗試中的原話,不加任何新內容

其他所有情況都應該是一個問題,問回使用者。如果一個節拍沒有任何可用的素材,該儲存格就寫 [NEEDS: ...] —— 絕不要寫草稿。

將技能撰寫的每個字標記為 [+ ...],這樣使用者可以一眼看到並刪除它們。未標記的行代表是使用者說的。

表格

#對白畫面音效
1他們的原始詞語他們的視覺他們的音效筆記
2他們的詞語 [+ 他們沒說的過渡][NEEDS: 我們在看什麼?]—
  • 短影音:每個節拍一行;長片:每個節拍或每個段落一行
  • 長片:根據分鏡表,將行分組到章節標題下
  • 空的儲存格可以接受。— 代表刻意留空。[NEEDS: ...] 代表尚未回答。

交給他們之前——根據他們的觀眾進行檢查

根據他們在階段 0 中提到的具體對象(用名字或描述)來檢查腳本。四個問題:

  • 那個人離開時,能帶走某個實際可用的東西嗎?
  • 這讓他們感覺有能力,還是讓他們感到困惑?
  • 他們會把這個分享給其他人嗎?
  • 有沒有哪個時刻他們會感到不知所措而放棄?

回報哪些部分沒過關以及在哪裡。不要默默地修正——修正意味著新的文字,而新的文字必須來自使用者。


常規規則

  • 使用者的話語不是需要被「改善」的原始素材。它們就是最終成果。
  • 絕不虛構表現數據——沒有真實來源,就不能提及觀看次數、留存率或訂閱人數。
  • 空白處要標記出來,絕不自行填補。
  • 在使用者確認之前,沒有任何事項是確定的。不要讓一個草稿硬化成一個假設性的決定。
  • 在建立檔案之前,先詢問他們希望以什麼格式交付腳本。
  • 如果使用者在某個階段中間開始口述,就停止提問並開始記錄。他們的動能比技能的順序更重要。

相關技能