跳到主要內容

部落格

不定期分享最新資訊文章

  • article-當 ChatGPT 可以接上 Pi:AI Agent 正在走向「模型與 Harness 分離」

    2026/9/30

    AI工具 ChatGPT AI Agent
    當 ChatGPT 可以接上 Pi:AI Agent 正在走向「模型與 Harness 分離」

    最近看到 OpenAI 推出 Sign in with ChatGPT,並開始讓符合資格的開源工具串接 ChatGPT 方案用量。官方目前列出的開源工具範例包含 Pi by Earendil。 一開始我也以為,這只是「Pi 現在可以更方便使用 GPT」。但把 OpenAI 的整合說明和 Pi 的登入方式放在一起看,我更在意的其實是另一件事:我們過去常綁在一起看的模型與 Agent Harness,正在變成可以分開選擇的兩層。 這可能改變我們挑選 AI Agent 工具的方式。 為什麼我開始把模型與 Agent 分開看?這兩年挑 AI Coding 或 Agent 工具時,我們很容易先從模型開始想:想用 Claude,就想到 Claude Code;想用 OpenAI,就想到 Codex;想用 Gemini,就去找 Google 生態系裡的工具。 久了容易覺得模型就是 Agent。其實模型比較像負責理解、推理、規劃與生成的大腦。要讓它讀檔、改程式、執行 Shell、呼叫 MCP、操作瀏覽器、載入 Skill,還需要一套把模型接到電腦、工具和工作流程上的系統。 這一層通常稱為 Agent Harness。 Harness 負責把模型接到工作現場假設我們請 Agent 檢查專案、找出 Bug、修改程式碼、執行測試,再整理報告。真正完成任務時,除了模型本身,背後還有許多部分一起運作: 上下文管理與檔案系統 Shell、Terminal 與工具呼叫 MCP、Skills、Browser 或 Computer Use 權限控制、錯誤處理與 Agent Loop 工作狀態保存、模型切換與記憶機制 這些能力如何串接,會影響模型能看見什麼、可以採取哪些行動,以及出錯後能不能修正並繼續。Harness 不只是聊天介面,而是模型的執行環境和工作規則。 同一個 GPT,換一套 Harness 也會有不同體驗假設兩套 Agent 使用能力相近的 GPT 模型。A Harness 可能會先搜尋專案、整理計畫、修改程式碼、自動執行測試,發現錯誤後再回頭修正與驗證;B Harness 可能只讀幾個檔案、修改一次就回報完成。 最後使用者感受到的「AI 好不好用」,不一定全是模型能力的差異,也可能是 Harness 怎麼安排模型工作的結果。 Pi × ChatGPT 值得注意的是什麼?OpenAI 的 Sign in with ChatGPT 把兩種權限分開處理:使用者可以用 ChatGPT 身分登入,也可以另外選擇是否讓符合資格的應用程式使用方案內的 AI 用量。使用 ChatGPT 方案用量需要獨立授權;目前官方說明限定 Plus 與 Pro 等符合資格的方案,而且這不會把 ChatGPT 對話或 API Key 交給應用程式。OpenAI 使用說明 也列出 Pi by Earendil 作為開源工具範例。 這不只是第三方工具自己接上一個模型 API。OpenAI 已提供讓開源工具使用者以 ChatGPT 帳號登入,並在同意後使用方案用量的整合方式;開發者文件也說明,登入身分與使用方案用量是不同能力,後者是可選權限。 不過「列在支援範例」不等於每種登入方式對所有使用者都已順利可用。Pi 既有的文件也列出 ChatGPT Plus/Pro(Codex)訂閱登入;此外,Pi 專案在 2026 年 9 月 29 日有使用者回報,新版 Sign in with ChatGPT 的 Pi 登入出現 invalid_client,而舊的 Codex 訂閱登入仍可用。這是一則使用者回報,不能推論成所有帳號都遇到相同問題;但它提醒我們,整合方式和實際可用狀態可能還在演進。Pi 登入文件 · Pi issue #10184 模型與 Harness 可以分開組合過去模型、帳號、額度和 Agent 工具常被包成一套產品。現在可以想像不同的組合:ChatGPT 方案連上 Pi,Pi 再接 Skills、MCP、CLI 或 Browser,最後串成自己的 Workflow。 我也可能在某些工作使用 Claude Code,在另一些工作使用 Codex;需要自訂流程時,再選 Pi、OpenClaw 或 Hermes 等其他 Harness。這些工具的能力和整合方式會隨版本變動,但「模型與執行環境可以分開思考」是更值得留下的觀念。 因此,選 AI Agent 時只問「要用哪一個 AI?」可能不夠。還可以接著問: 你使用什麼 Model? 你使用什麼 Harness? 你裝了哪些 Skills、接了哪些 Tools? 這些元件最後如何組成 Workflow? Harness 也是一條重要的信任邊界Agent 不只回答問題。依照授權,它可能讀寫檔案、執行指令、連接服務、操作瀏覽器、使用憑證或呼叫 MCP。因此除了問「這顆 LLM 安不安全?」,也要了解「這套 Harness 在我的電腦上能做什麼?」 Harness 決定模型可用的工具和權限,也要負責把操作結果與錯誤交回模型。選擇工具時,可以檢查它會讀取哪些資料、哪些地方會執行 Shell、網路請求送往哪裡、憑證如何保存,以及 MCP 或擴充套件擁有哪些權限。 開源代表多了一個檢查入口,不代表自動安全Pi、OpenClaw、Hermes 這類開源 Harness 有一個優點:原始碼可以檢查。開源不等於安全,專案仍可能有漏洞,第三方 Skill、Plugin 或 MCP 也可能帶來風險。 但我們可以把「完全不知道它在做什麼」往前推一步,改成檢查它的資料流、Token 儲存、Shell 執行點、網路請求、遙測、相依套件與敏感檔案存取。也能請 Codex 或 Claude Code 協助做安全檢視,再由人確認重要結果。這不能保證百分之百安全,卻增加了理解和審查的機會。 Skill Library 比 Prompt 收藏更容易累積工作方法我最近整理 Agent Skill 時,越來越不想只收藏「一百個超強 Prompt」。Prompt 容易散落各處;比較有價值的,是把自己的工作方法整理成可重複使用的能力。 例如簡報、文章、社群內容、研究、影片分鏡、資料整理、Vibe Coding 或課程設計 Skill,都可以說明 Agent 遇到這類工作時,先做什麼、要遵守哪些規則、參考哪些資料、輸出成什麼格式,以及如何驗收成果。 每個 Skill 不只是放一句提示詞,而是逐步累積判斷方式與 SOP。這也延伸了我在整理自己的 AI 工作能力庫時的想法:把工作方法留下來,才能在模型更新時繼續使用。 用五層架構理解 AI Agent剛開始研究 Agent 時,可以先用五層架構來看: Model:GPT、Claude、Gemini 等模型,負責理解與推理。 Harness:Pi、Codex、Claude Code、OpenClaw、Hermes 等工具,負責讓模型在環境中工作。 Skills:把專業知識、規則與 SOP 包成可重複使用的能力。 Tools:MCP、CLI、Browser、Computer Use、API 等,讓 Agent 接觸外部工具和資料。 Workflow:把前面各層組合起來,完成一項真正的工作。 最後產生價值的,通常不是單獨某一顆 LLM,而是 Model、Harness、Skills、Tools 與 Workflow 的組合。 哪些人值得研究 Pi 這類開源 Harness?如果平常只是偶爾問 ChatGPT 問題,不需要因為一則整合消息就立刻更換工具。但如果已經開始做 AI Coding、MCP、Skills、自動化、長時間任務或多工具工作流,Pi 這類開源 Harness 值得研究。 重點不是把所有工作搬到同一個工具,而是理解模型、執行環境與工作方法可以分開評估,再依任務組合。 Agent 下一戰也許是工作系統GPT、Claude、Gemini 都會持續更新,模型排行榜也會一直變。我現在更在意的是:工作流程有沒有留下來?Skill 能不能重複使用?工具能不能替換模型?資料能不能掌握?Harness 能不能檢查?Agent 能不能真正完成工作? 以前我會想「選一個最強的 AI,把工作交給它」。現在更傾向先建立自己的 AI 工作系統,再選合適的模型進來工作。 模型會換,Harness 也會進化;更值得自己留下來的,是 Skills、Tools、Workflow,以及累積下來的工作方法。也許以後大家討論 AI Agent,不只問「你用 GPT 還是 Claude?」,還會問「你現在用哪個 Harness?你的 Skill Library 裡有什麼?」 參考資料 OpenAI:Using your ChatGPT plan in other apps and sites OpenAI:Integrating Sign in with ChatGPT in your Open Source App Pi:Provider Authentication Pi issue #10184:Sign in with ChatGPT 登入回報 常見問答 (FAQ)Q1:Agent Harness 是什麼?Agent Harness 是讓模型在電腦與工具環境中執行任務的系統,通常包含上下文管理、檔案與 Shell 工具、權限控制、Agent Loop、錯誤處理及工作狀態等部分。 Q2:使用 Pi 連接 ChatGPT 方案一定要準備 API Key 嗎?Sign in with ChatGPT 的開源整合可讓符合資格的使用者登入,並在另外授權後使用方案內的 AI 用量,不需要自行建立或提供 OpenAI API Key。是否能使用仍取決於方案資格、工具整合與當下登入狀態。 Q3:Sign in with ChatGPT 會把我的 ChatGPT 對話交給 Pi 嗎?不會因登入或使用方案用量就取得 ChatGPT 對話或 API Key。登入身分與方案用量授權是不同權限;使用者仍應逐項檢查應用程式要求的權限及其資料處理方式。 Q4:開源 Agent Harness 就代表安全嗎?不代表。開源讓人有機會檢查原始碼,但不能保證沒有漏洞,也不能替第三方 Skills、Plugins 或 MCP 背書。使用前仍要檢查程式行為、資料流、工具權限與相依套件。

  • article-從 Prompt 到 Skill Library:我從吳奇老師的 Agent Skill 講座學到什麼?以及如何打造自己的 AI 工作能力庫

    2026/9/30

    AI工具 AI自動化 AI Agent
    從 Prompt 到 Skill Library:我從吳奇老師的 Agent Skill 講座學到什麼?以及如何打造自己的 AI 工作能力庫

    最近我看了「數位敘事力期刊」舉辦的一場直播講座,主講人是吳奇老師,主題是: 《Agent skill:為何需要 skill?與 skill 的極限》 直播原始影片: YouTube|Agent skill:為何需要 skill?與 skill 的極限 看完之後,我最大的感受不是「又多了一個 AI 新名詞」,反而是很多我最近一直在做的事情突然被串起來了。 這一兩年我們從 Prompt、GPTs、Gems、MCP、Agent,一路走到 Skills。 表面上工具一直換,但底層其實是在解決同一件事: 怎麼讓 AI 不只是回答問題,而是學會「我們平常到底怎麼工作」。 尤其我自己最近大量使用 Codex、Claude Code、Agent、MCP 做課程教材、簡報、網站、影片、自動化工作流,更能感受到一件事: 真正有價值的,已經慢慢不是那一句「神 Prompt」。 而是: 你有沒有辦法把自己做事的方法,整理成 AI 可以重複使用的 Skill。 這篇文章就是我從吳奇老師直播中吸收之後,再搭配目前 OpenAI、Anthropic 與 Agent Skills 官方規格,重新整理出來的一套理解。 最後也會實際設計我準備使用的: 「享哥 Skill Library」 一、先用一句話理解什麼是 Agent Skill我目前最喜歡的理解方式是: Tool / MCP 告訴 AI「你可以做什麼」,Skill 告訴 AI「這件事情應該怎麼做」。 例如我今天給 Agent: Gmail Google Drive Calendar Browser Terminal Python ImageGen 這代表它有很多工具。 但是: 有工具,不代表會工作。 就像今天公司請了一位新員工,給他: 電腦 Gmail ERP Excel 公司帳號 不代表他就知道: 收到客戶詢問後,可以依序判斷: 先確認什麼? 哪些資料要查? 哪些狀況要升級處理? 最後要填哪張表、寄什麼格式的信? 這中間缺的就是: SOP、判斷規則、範本與經驗。 而 Skill 就是在做這件事。 OpenAI 現在也把 Skill 定義為可重複使用的工作流程,讓 ChatGPT 或 Agent 不需要每一次都重新被解釋流程。 二、我會把 AI Agent 能力拆成四層從吳奇老師直播裡的 Workspace、Tools / MCP、Skill 架構,我自己重新整理成下面四層。 層級 解決問題 可以怎麼理解 Model AI 會不會思考 大腦 Workspace / Runtime AI 在哪裡工作 辦公室 Tool / MCP AI 可以操作什麼 工具 Skill AI 應該怎麼做 SOP+教師手冊 例如: 1234567GPT / Claude↓Codex / Claude Code / VM↓Google Drive / Gmail / Browser / CLI↓我的課程製作 Skill 這四層要放在一起看。 因為 Skill 並不是魔法。 假設 Skill 裡面寫: 打開瀏覽器登入後台,把資料輸入 ERP。 但是這個 Agent 根本: 沒 Browser 沒 Computer Use 沒帳號 沒權限 那 Skill 寫得再漂亮,也執行不了。 所以 Skill 能力永遠是: 123456789模型能力×執行環境×工具×權限×Skill 三、MCP 跟 Skill 到底差在哪?這是很多人第一次接觸 Skill 最容易混在一起的地方。 假設 MCP 提供三個工具: 123search_customer()check_calendar()send_email() 這代表 AI: 能查客戶、能查行事曆、能寄信。 可是它不知道什麼時候該用哪一個。 Skill 就可以寫: 12345678當使用者要求安排客戶會議時:1. 先搜尋客戶資料。2. 確認上次聯絡紀錄。3. 查詢雙方可用時段。4. 產生 3 個候選時段。5. 使用者確認後才建立行程。6. 建立完成後寄出確認信。 所以: 12MCP = CapabilitySkill = Workflow OpenAI 官方文件也把兩者定位為互補層:MCP Server 提供即時資料、授權與受控動作;Skill 則說明何時呼叫工具、依什麼順序處理,以及如何處理不完整結果與整理輸出。我會把它簡化記成:MCP 提供能力,Skill 描述工作流程。可參考 OpenAI Developers:Skills 與 MCP 的分工。 這個觀念非常重要。 因為我們以前很容易覺得: 「接上 MCP 就完成 Agent 了。」 其實不是。 MCP 比較像把工具箱交給 Agent。 Skill 才是在告訴它: 「我們公司拿這套工具到底怎麼做事情。」 四、Skill 不只是一個比較長的 Prompt第一次看到 Skill 很容易想: 那不就是把 Prompt 存成 Markdown? 某種程度沒錯。 但如果只這樣理解,又會低估 Skill。 一個正式 Skill 通常是一個資料夾。 目前 Agent Skills 開放規格要求每個 Skill 至少包含 SKILL.md;scripts/、references/、assets/ 則依需求加入: 12345my-skill/├── SKILL.md├── scripts/├── references/└── assets/ 其中: SKILL.md核心操作說明。 定義: 這個 Skill 做什麼 什麼時候使用 需要哪些輸入 工作流程 判斷規則 輸出格式 完成前檢查 references/參考知識。 例如: 123456課綱品牌規範公司 SOPAPI 文件報價規則產品規格 assets/可重複使用的素材。 例如: 123456PPTX 模板Word 模板CSV 樣板品牌 LogoJSON Schema範例檔案 scripts/需要確定性執行的程式。 例如: 123456PythonJavaScriptBash資料轉換檔案檢查格式驗證 這些目錄名稱對應 Agent Skills 開放規格列出的常見支援資源;除了 SKILL.md 之外,其餘目錄都是可選。 五、真正重要的設計:Progressive Disclosure吳奇老師直播中,我非常認同的一個關鍵概念叫: Progressive Disclosure中文可以理解成: 漸進式揭露。 以前我們很常幹一件事情: 把所有規則全部塞進 System Prompt。 例如: 123450 頁品牌規範30 頁課綱20 個範例100 條 SOP 然後每一次對話全部讀。 結果就是: Token 增加 Context 變亂 AI 抓不到重點 不相關的規則互相干擾 Skill 的做法不同。 第一層: 12namedescription AI 只先知道: 「有這個 Skill 存在。」 第二層: 只有判斷目前任務需要它時,才載入: 1SKILL.md 第三層: 真的遇到某種工作,才讀: 123references/assets/scripts/ Anthropic 把這套機制明確稱為 Progressive Disclosure;Agent Skills 官方規格也建議 Skill 啟動前先只載入名稱與描述,啟動後才載入完整 SKILL.md,需要時才讀其他資源。 所以好的 Skill Architecture 不是: 1一個 50,000 字 SKILL.md 而是: 12345678910SKILL.md↓需要才讀references/course-design.md需要才讀references/brand-guide.md需要才用assets/template.pptx 這一點對大型工作流非常重要。 六、Skill 真正封裝的是四種知識這是我看完直播之後,自己再整理出來最重要的一個框架。 一個成熟 Skill,其實可能封裝四種東西。 第一層:Declarative Knowledge也就是: 「知道什麼」例如: 1234AI 課程有哪些工具?公司的品牌色是什麼?勞基法規定是什麼?國中課綱有哪些素養指標? 這些比較適合放: 1references/ 第二層:Procedural Knowledge也就是: 「知道怎麼做」例如: 12345678910111213收到課程需求↓確認學員↓確認程度↓確認時數↓設計學習目標↓安排實作↓建立 Slide Manifest 這就是: 1SKILL.md 真正主要封裝的內容。 第三層:Executable Knowledge也就是: 「真的幫我做」例如: 1234scripts/├── export-pptx.py├── validate-csv.py└── generate-index.js 這時 Skill 不只是叫 AI: 「記得檢查。」 而是直接: 「執行檢查程式。」 這會比靠 LLM 自己判斷穩定很多。 第四層:Decision Knowledge這一層我認為最值錢。 也就是: 「專家為什麼這樣判斷?」例如我在規劃 AI 課程時,真正有價值的不只是: 12先做課綱再做簡報 而是: 123456789101112如果學員第一次接觸 Agent→ 不要先講架構→ 先做成功案例如果只有 3 小時→ 不做完整工作流如果行政人員居多→ Gmail / Excel / Drive 優先如果學員超過 50 人→ 降低需要逐一登入帳號的實作 這些東西不一定寫在書裡。 它們來自: 做過很多次之後形成的經驗。 而這也是我認為 Skill 最有價值的一件事: 把 Human Skill 慢慢轉成 Agent Skill。 七、直播裡提到的 5 種 Skill 建立方式吳奇老師整理了幾種 Skill 的建構方式。 我把它們重新整理一下。 方法一:Manual最直接。 自己寫: 1234SKILL.mdreferences/assets/scripts/ 適合: 本來就已經有完整 SOP 的人。 方法二:生成式建構不是自己從空白開始。 直接讓 Agent 幫你建立。 OpenAI 現在也有 Skill Creator。 在 Codex 裡可以呼叫: 1$skill-creator OpenAI 官方文件目前也推薦使用內建的 Skill Creator 開始建立 Skill。 例如: 1234567891011121314151617181920212223$skill-creator幫我建立 course-design skill。用途:將企業提供的課程需求轉換成完整 AI 課程架構。輸入:- 課程時數- 學員職務- AI 程度- 人數- 預期成果輸出:- 課程定位- 學習目標- 單元- 時數- 實作- 使用工具如果資料不足,先列出缺少資訊。 接著 Agent 就可以協助建立基本架構。 方法三:逆向工程/工作流蒸餾這是我自己最推薦的方法。 因為大部分人: 會做工作,但不一定會寫 SOP。 那怎麼辦? 先跟 AI 把工作做一次。 例如: 1234567891011討論需求↓修改課程架構↓調整簡報↓發現問題↓修正↓得到滿意結果 做到最後直接告訴 Agent: 1234567891011分析我們剛才完整的工作流程。找出:1. 固定步驟2. 判斷規則3. 必要輸入4. 常見錯誤5. 成功輸出格式6. 可以重複使用的參考資料把這套成功流程整理成 Agent Skill。 這件事情我會叫: Workflow Distillation工作流蒸餾。 它其實非常符合現在 Vibe Coding 的工作方式。 方法四:Record & Replay這種比較像: 「不要聽我解釋,看我做一次。」 例如: 123456登入網站→ 建立活動→ 填寫表單→ 上傳圖片→ 設定時間→ 發布 Agent 透過: Browser Use Computer Use RPA 學會操作順序。 這類 Skill 未來會跟 GUI Agent 高度整合。 方法五:Decision Distillation這比 Record & Replay 更進階。 不是觀察: 「你按哪個按鈕?」 而是觀察: 「你為什麼做這個決定?」 例如蒐集一位資深講師過去的: 12345650 個課程案例20 次退件30 次修改報價課綱學員反應 再抽出: 1234什麼情況用 A什麼情況不用 B什麼情況必須詢問什麼情況可以直接決定 這就從: 操作自動化 進化到: 決策經驗數位化。 八、其實這 5 種方法可以再濃縮成三類我後來發現,它們本質上就是: 1234567891011第一種我知道怎麼做→ 寫成 Skill第二種我已經做成功→ 把成功流程蒸餾成 Skill第三種觀察專家怎麼做→ 推導成 Skill 也就是: 123WriteDistillObserve 這樣一來 Skill 就不只是 AI 工程師的東西。 任何專業工作者都可以做。 九、Skill 跟 GPTs / Gems 有什麼不同?直播裡用了一個很好懂的方式,把 GPTs / Gems 理解成預設 Prompt,而 Skill 是完整工作流程。 這樣入門非常好懂。 不過如果要更精確,我會稍微補充。 GPT / Gem 比較像: 「一個已經設定好的 AI 助手」裡面可以包含: Instructions Knowledge Tools Persona 對話設定 Skill 比較像: 「這個 AI 助手可以學會的能力模組」例如: 123456789一個 Agent可以同時會:researchpresentationbrand-designcourse-designdata-analysis 所以我自己會用更簡單的方式教: GPT 比較像員工。 Skill 比較像員工會的技能。 而且 Skill 更強調: 模組化、可組合、可攜與按需載入。 目前 OpenAI 已支援 Agent Skills 開放格式,官方也把 SKILL.md 定義成可移植、可分享、可版本管理的工作流程格式。 十、Skill 最大的問題:不是越多越好這也是我最近特別有感的事情。 GitHub 現在 Skill 越來越多。 我前陣子也研究過一次: 146 個免費 Agent Skills。 第一反應很容易是: 全部裝! 但是其實這不一定是好事。 例如你裝: 123456presentation-designpptx-designbeautiful-slidesproduct-designslide-makerpresentation-pro 每一個 Description 都寫: 做簡報時使用。 那 Agent 到底選哪個? 這會產生: Trigger Collision所以一個 Skill 最容易被低估的欄位其實不是 Instructions。 而是: 1description: 因為它其實也是: RouterAgent Skills 官方規格明確要求 description 不只寫 Skill 做什麼,還應寫出「什麼情況使用」。OpenAI 也指出 Agent 主要根據 Skill 的 name 與 description 判斷是否需要呼叫。 例如不要寫: 1description: Helps create presentations. 而是: 1234description: > Converts a completed Slide Manifest into a structured presentation. Use only after the course outline and Slide Manifest have been approved. 這就清楚很多。 十一、Skill 有自己的極限看完直播後,我把 Skill 的極限整理成七個。 1. Model CeilingSkill 不會讓能力差的模型突然變成頂級模型。 它只能讓模型: 更了解怎麼使用既有能力。 2. Tool Ceiling沒有 Browser: 就不能瀏覽網站。 沒有 CLI: 就不能執行 Terminal。 3. Permission Ceiling有 Gmail Tool: 不代表有你的 Gmail 權限。 4. Context CeilingSkill 太長、太多: 還是可能造成 Context 干擾。 5. Knowledge CeilingSkill 不會自動擁有你的專業經驗。 你沒有把經驗整理進去: 它就不知道。 6. Environment Ceiling同一個 Skill 放到: 12345CodexClaude CodeChatGPTCursorComputer Use Agent 可以執行的內容未必完全相同。 因為環境能力不同。 7. Security Ceiling尤其外部 Skill 要非常小心。 因為 scripts/ 可能做: 123456執行 Bash下載程式讀 Environment Variable存取檔案呼叫外部 API刪除資料 OpenAI 現在也特別提醒,使用外部 Skills 前應檢查 Skill 與其支援檔案,尤其具有網路或 Shell 權限時,可能產生提示注入或資料外洩風險。 十二、模型越強,Skill 反而應該越薄這是一個很有趣的現象。 以前模型比較弱,我們寫: 12345第一步做什麼第二步想什麼第三步不要忘記什麼第四步怎麼判斷第五步…… 寫 300 條。 但模型越強之後: 很多事情其實它自己已經知道。 OpenAI 在 2026 年 9 月甚至特別發文提醒,新的模型能力提升後,要重新檢查累積已久的 Skill、AGENTS.md 與 Prompt,因為過度 scaffolding 可能造成 Context 膨脹與不必要限制。 所以未來好的 Skill 可能反而更像: 12345678910111213GoalInputsConstraintsDecision boundariesResourcesOutputQuality checks 而不是: 12345滑鼠往右 10px↓按一下↓等待 這很像管理人。 員工能力越強: 管理者越不應該 Micro Management。 十三、我自己認為真正的 Skill 成熟度,可以分成 8 層整理完直播內容後,我自己建立了一個 Skill 成熟度模型。 123456789101112131415161718192021222324252627282930313233343536373839404142434445Level 0Prompt這一次怎麼做?↓Level 1Template照這個格式做↓Level 2Workflow照這個流程做↓Level 3Skill以後遇到這類工作都這樣做↓Level 4Skill Library有很多能力可以選↓Level 5Agent自己判斷使用什麼 Skill 與 Tool↓Level 6Multi-Agent不同 Agent 分工合作↓Level 7AI Organization形成完整數位組織 我覺得這套分類也很好跟之前談過的: RPA Level 1~5 放在一起。 因為兩者其實描述兩個不同維度。 1234567Automation Level=AI 自己能做多少Skill Level=我們把多少工作知識交給 AI 十四、最終一定會走向 Multi-Agent直播最後談到: 1234校長 Agent教務 Agent學務 Agent總務 Agent 不同 Agent 各自帶著自己的 Skill。 表面是在講 Multi-Agent。 但我反而覺得真正的問題是: Organization Design因為你要回答: 12345678910111213誰負責什麼?誰能讀什麼資料?誰能修改資料?誰可以批准?什麼事情需要升級?工作完成交給誰?出錯誰負責處理? 也就是企業本來就在做的: 123456角色權限SOPRACI流程組織架構 所以未來 Multi-Agent 最大的問題可能根本不是: 「我要用 GPT 還是 Claude?」 而是: 「這份工作到底怎麼拆?」 這才是 Skill 往下一層走真正困難的地方。 十五、看完這場直播,我決定不要再只是收藏 Skill這就是整場直播對我自己最大的啟發。 最近我一直在研究: Codex Claude Code Agent Harness MCP Presentation Skill Product Design Slide Manifest Video Skill GSAP Skill 各種 GitHub Skill 如果一直照現在的方式,很容易變成: 12345收藏 50 個↓收藏 100 個↓收藏 500 個 結果: 真正屬於自己的工作方法沒有留下來。 所以我接下來比較想做的是: 「享哥 Skill Library」把這幾年真正累積的工作流程,一個一個數位化。 十六、享哥 Skill Library 不應該按照工具分類我不打算這樣分: 1234Gemini SkillClaude SkillCodex SkillChatGPT Skill 因為工具會換。 今年 Claude 強。 半年後可能 Codex 強。 再半年又有新東西。 真正不容易過時的是: 工作場景。所以我的 Skill Library 應該按照: 1我要完成什麼工作? 來分類。 十七、第一版「享哥 Skill Library」我目前會先規劃下面這些。 1234567891011121314151617181920212223xiang-skill-library/├── course-intake/│├── course-design/│├── slide-manifest/│├── presentation/│├── student-handout/│├── social-article/│├── social-visual/│├── video-script/│├── course-review/│├── workflow-distiller/│└── skill-security-review/ 01|course-intake用途: 收到邀課需求之後,先判斷資訊是否足夠。 輸入: 12345678910單位對象程度人數時數主題場地裝置AI 帳號預期成果 輸出: 12345已知條件缺少條件限制風險推薦課程方向 02|course-design用途: 123需求↓完整課程架構 包含: 定位 學習目標 單元 時數 工具 實作 成果 前置能力 03|slide-manifest這個是我最近特別重要的一個 Skill。 以前常遇到: 課程大綱跟最後 PPT 不一致。 所以現在增加中間層: 12345Course Outline↓Slide Manifest↓Presentation Slide Manifest 應記錄: 123456789slide_idtitlepurposekey_messagecontentvisualdemoexercisespeaker_notes 讓後續所有教材都吃同一份「簡報真相來源」。 04|presentation輸入: 1Slide Manifest 輸出: 1PPTX 同時加入: 我的簡報 DNA 字體 圖文比例 圖像風格 排版 ImageGen 規則 Speaker Notes 這樣就不需要每次重新解釋: 「我喜歡什麼簡報。」 05|student-handout把: 123課程內容↓Notion / Word 講義 並且保留: 123456提示詞變數實作注意事項摺疊區延伸練習 06|social-article把: 12345研究課程實驗工具心得 轉換成我的部落格與社群文章。 裡面可以慢慢累積: 12345我的語氣文章結構用詞不要使用的 AI 味CTA 07|social-visual輸入: 1文章 判斷: 1234567主視覺概念標題畫面構圖人物場景色彩ImageGen Prompt 08|video-script把文章轉: 1234567891011Hook↓30–90 秒腳本↓分鏡↓旁白↓字幕↓影像提示詞 09|course-review這個我覺得會非常重要。 每次教材完成後: 不要直接交件。 由另一個 Skill 做: 1對抗式 Review 檢查: 時數合理嗎? 新手做得完嗎? 工具有沒有過時? 提示詞太長嗎? 實作真的能執行嗎? Slide Manifest 跟 PPT 一致嗎? 講義跟簡報一致嗎? 10|workflow-distiller我覺得這會變成整套系統裡最重要的一個 Skill。 它的工作不是直接處理業務。 而是: 幫我製造 Skill。流程: 12345678910111213141516171819讀完整對話↓找成功工作流程↓找重複步驟↓找判斷規則↓找 Input / Output↓找 Edge Cases↓建立 SKILL.md↓建立 references↓建立 assets↓建立測試 也就是: Skill Factory。 11|skill-security-review這是我另外會加的。 任何 GitHub 下載下來的 Skill: 先不要直接安裝。 全部先過: 1skill-security-review 檢查: 12345678910SKILL.mdscripts/外部網址ShellNetworkEnvironment Variables檔案讀寫刪除命令依賴套件Prompt Injection 這會是未來 Skill 越來越普及之後,很實際的一個需求。 十八、實際開始:不要一次做 20 個 Skill我反而建議: 從一個最常重複的工作開始。對我而言,第一個很可能就是: 1course-design 十九、第一步:先找一個「已經成功過」的案例不要幻想 SOP。 直接找: 「我上一次做得很好的課程。」 把: 123456邀課需求對話課綱修改紀錄簡報學員實作 全部交給 Agent。 然後問: 123456789101112131415161718分析這個專案。不要只摘要內容。請逆向分析我實際採用的工作方法,包括:1. 任務輸入2. 固定工作步驟3. 決策點4. 我做過哪些修改5. 哪些判斷可以一般化6. 哪些只是這次案例特殊條件7. 最終輸出格式8. 常見錯誤9. 哪些內容適合放 SKILL.md10. 哪些內容應拆到 references / assets / scripts目標是把我的工作方法整理成可重複使用的 Agent Skill。 二十、第二步:請 Skill Creator 建立 Skill在 Codex 可以直接: 1$skill-creator 然後: 12345678910111213141516171819202122Create a skill named course-design.Goal:Turn training requirements into a practical AI course structure.The skill must:- identify missing requirements- classify learner skill level- determine realistic scope from course duration- prioritize hands-on exercises- avoid overloading beginners- generate structured course modules- include tool requirements- include learner outputsUse the attached successful course projects as reference examples.Separate:- workflow into SKILL.md- detailed teaching heuristics into references/- reusable course templates into assets/ 二十一、我會讓 SKILL.md 長這樣1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859---name: course-designdescription: > Designs practical AI training courses from client requirements. Use when planning a new workshop, corporate training session, or revising an existing course structure.---# GoalConvert training requirements into a realistic,hands-on course structure.# Required Inputs- audience- learner level- duration- number of learners- available devices- tool/account restrictions- expected outcome# Workflow1. Parse requirements.2. Identify missing information.3. Classify learner level.4. Define realistic learning outcomes.5. Divide the course into modules.6. Assign duration.7. Design hands-on exercises.8. Verify total duration.9. Produce final course outline.# Decision RulesIf learners are beginners:- reduce tool switching- prioritize one successful workflowIf duration <= 3 hours:- do not design a full multi-agent projectIf learner count > 50:- avoid exercises requiring individual account configuration# OutputReturn:- course positioning- audience- prerequisites- learning outcomes- module table- hands-on exercises- required tools- risks 你會發現: 真正好的 Skill 不一定要很長。 二十二、把詳細經驗拆出去例如: 1234567891011121314151617course-design/├── SKILL.md├── references/│ ├── beginner-course.md│ ├── corporate-training.md│ ├── course-duration-rules.md│ └── exercise-design.md├── assets/│ ├── course-outline-template.md│ └── course-intake-form.md└── examples/ ├── admin-course.md └── marketing-course.md 當課程是行政人員: 才讀: 1corporate-training.md 當課程是新手: 才讀: 1beginner-course.md 這就是 Progressive Disclosure。 二十三、第三步:一定要測試「什麼時候不該啟動」很多人測 Skill 只測: 「它會不會啟動?」 其實還要測: 「它會不會亂啟動?」 例如 course-design: 應該啟動: 1幫我規劃一堂 6 小時 Codex 課程 應該啟動: 1這堂 AI 課只有 3 小時,怎麼調整? 不應啟動: 1幫我查明天天氣 不應啟動: 1幫我修這段 JavaScript 這就是: Skill Routing Test。 二十四、Skill 不是做好就結束,而是要做 Evals這也是我認為下一階段很重要的觀念。 OpenAI 已經專門提出: Testing Agent Skills Systematically with Evals因為只靠感覺: 「好像 V2 比 V1 好。」 是不夠的。 應該建立固定測試題。 例如: 1234510 個應該啟動10 個不應該啟動10 個正常案例5 個極端案例5 個資料不完整案例 測: 1234567Trigger AccuracyWorkflow AccuracyOutput CompletenessError Handling OpenAI 官方現在也建議用 Evals 系統化測試 Skill 是否正確觸發、是否漏步驟,以及不同版本是否發生 Regression。 二十五、Skill 也應該像軟體一樣 Versioning例如: 12course-designv1.0 使用一段時間後發現: 人數超過 50 人的實作常失敗。 加入規則。 變成: 1v1.1 後來又發現: Windows / Mac 混合班不能設計太多 OS-specific 操作。 再加入: 1v1.2 久了之後: Skill 就變成: 我的數位工作經驗。 二十六、這其實才是 AI 時代真正的個人資產模型會換。 Prompt 會過時。 工具會消失。 今天: 1Claude 明天: 1Codex 後天: 又有新的 Agent。 但是: 12345678910111213我怎麼設計課程我怎麼判斷學員程度我怎麼做簡報我怎麼設計實作我怎麼 Review 教材我怎麼寫文章我怎麼做影片 這些東西: 才是真正屬於自己的。 而 Skill 做的事情,就是: 把 Human Skill 變成可以被 AI 使用的 Digital Asset。 二十七、我現在會把整個發展路線理解成這樣123456789101112131415Prompt↓Template↓Workflow↓Skill↓Skill Library↓Agent↓Multi-Agent↓AI Organization 以前大家問: 「Prompt 要怎麼寫?」 接下來可能會開始問: 「你的 Skill Library 裡面有什麼?」 再下一階段可能變成: 「你的 AI Organization 有哪些角色與能力?」 我覺得這才是 Agent 時代真正開始有趣的地方。 二十八、我的下一步:不是再找更多 Skill,而是開始蒸餾自己的工作看完吳奇老師這場直播之後,我最大的改變是: 以前看到: 146 個免費 Skill 我的第一反應可能是: 趕快下載。 現在我的第一個問題會變成: 「這個 Skill 能不能補我的工作流程?」 如果不能: 其實沒有必要裝。 真正值得做的反而是: 每完成一個重要專案,就問一次: 1這次有哪些做法值得留下來? 然後: 1234567891011Project↓Experience↓Workflow↓Distillation↓Skill↓Skill Library 如果一年做 100 個專案: 不需要留下 100 個 Skill。 但也許可以留下: 20 個真正代表自己工作方法的高品質 Skill。 那個東西的價值,很可能遠高於收藏 1,000 個別人的 Skill。 最後如果要我用三句話總結這次學到的內容: 第一句: MCP 給 Agent 工具,Skill 教 Agent 怎麼工作。 第二句: Skill 最有價值的地方,不是把 Prompt 存起來,而是把人的工作流程與判斷經驗保存下來。 第三句: 真正值得建立的,不是全世界最大的 Skill 收藏庫,而是最了解自己工作的 Skill Library。 所以我接下來真正想做的事情,就是: 享哥 Skill Library不是一次做完。 而是一個專案、一個流程、一個判斷慢慢累積。 最終把: 1234567我的課程我的簡報我的文章我的影片我的 Vibe Coding我的自動化我的顧問經驗 逐漸變成一組 AI 可以真正理解、呼叫、組合與執行的能力。 我覺得這才是 Skill 時代真正值得玩的地方。 延伸閱讀與參考資料1. 本文主要學習來源「數位敘事力期刊」直播講座,吳奇老師主講: 《Agent skill:為何需要 skill?與 skill 的極限》 YouTube 直播影片 2. OpenAI Academy|Using Skills適合第一次理解 Skill。 OpenAI 把 Skill 定義成可以重複使用、分享的工作流程。 OpenAI Academy:Using skills 3. OpenAI API|Skills比較技術面的官方規格,包括: SKILL.md references scripts assets Skills API Agent Sandbox Skill Discovery OpenAI Developers:Skills 4. OpenAI|Build Skills想使用 Codex 建立 Skill,這篇非常值得看。 包含: 1$skill-creator 以及 Skill 如何搭配 MCP。 OpenAI Developers:Build skills 5. OpenAI|Testing Agent Skills Systematically with EvalsSkill 做好之後不要只靠感覺測試。 這篇專門講: 123Skill EvalsTrigger TestingRegression Testing OpenAI Developers:Testing Agent Skills Systematically with Evals 6. OpenAI|Rethinking skills and prompts模型能力變強之後,Skill 不一定要越寫越長。 這篇很適合理解為什麼 Skill 也需要定期「瘦身」。 OpenAI Developers:Rethinking skills and prompts for GPT-6 Astra 7. Anthropic|Agent SkillsAnthropic 對 Agent Skills 的完整概念說明。 包含: Skill 架構 Progressive Disclosure VM Scripts References Skill Trigger Anthropic:Agent Skills 官方文件 8. Anthropic Engineering|Equipping agents for the real world with Agent Skills想理解 Progressive Disclosure,非常推薦這篇。 Anthropic Engineering:Equipping agents for the real world with Agent Skills 9. Agent Skills Open Standard如果你要自己開發 Skill,非常建議直接收藏規格。 目前核心格式就是: 12345skill-name/├── SKILL.md├── scripts/├── references/└── assets/ Agent Skills Specification 10. Agent Skills GitHub開放規格、文件與相關開源內容。 Agent Skills GitHub 11. OpenAI Developers|Skills 與 MCPOpenAI 對 Skills 與 MCP Server 分工的說明,可對照本文第三節。 OpenAI Developers:Skills 給自己的提醒以後再看到新的 Skill,不要第一時間問: 「我要不要安裝?」 先問: 「它解決的是我的哪一個工作流程?」 而每一次自己把一件事情做到滿意之後,也不要直接關掉對話。 最後多問 Agent 一句: 「把我們這次成功的流程蒸餾成一個 Skill。」 長期累積下來,那才會真正變成自己的 AI 能力庫。 常見問答 (FAQ)Q1:MCP 和 Agent Skill 的差別是什麼?MCP Server 提供 Agent 可使用的即時資料、工具、授權與受控動作;Skill 則描述完成一類工作的步驟、工具使用順序、判斷點與輸出要求。簡單記法是 MCP 提供能力,Skill 說明如何把能力用在工作流程裡。 Q2:建立自己的 Skill Library,第一步應該做什麼?先挑一個經常重複、而且已有成功案例的工作。整理它的輸入資料、固定步驟、決策規則、常見例外與成功輸出,再把穩定流程寫成一個 Skill;細節資料則視需要拆到 references/、assets/ 或 scripts/。 Q3:Skill 是不是越多越好?不是。從一個常見工作開始,確認它確實能減少重複說明或提升流程一致性,再逐步擴充。Skill 數量增加時,也要檢查描述是否重疊、觸發時機是否清楚,並用代表性案例測試它該啟動與不該啟動的情境。 Q4:使用外部 Skill 前需要檢查什麼?先閱讀 SKILL.md 和支援檔案,特別檢查 scripts/、依賴套件、網路請求、檔案讀寫、環境變數及刪除操作。只有在了解它會執行什麼、存取哪些資料與權限後,才決定是否使用。

  • article-Claude Opus 5.5 做影片到底有多強?一次看懂能力、Token 消耗與 AI 影片工作流

    2026/9/28

    AI工具 AI自動化 影音行銷
    Claude Opus 5.5 做影片到底有多強?一次看懂能力、Token 消耗與 AI 影片工作流

    最近我一直在研究 Claude Opus 5.5 做影片的案例。越看越覺得,這波值得注意的事情,不是「Claude 也會做影片了」,而是 AI 開始能把影片製作當成軟體工程專案來完成。 這和我們熟悉的 Veo、Seedance、MiniMax H3 等生成式影片工具,走的是不同路線。以前常見的流程是: 1提示詞 → 影片生成模型 → MP4 而程式化影片的流程更像: 1提示詞 → AI Agent → 程式碼 → 動畫引擎 → Render → MP4 Anthropic 在 2026 年 9 月 22 日推出 Claude Opus 5.5,官方將它定位為適合長時間 Agentic Coding 與知識工作的模型。這篇文章談的「做影片」,是讓模型在 Agent 工具、動畫框架與 Renderer 的協助下寫程式、反覆檢查並組裝成片;不是把 Opus 5.5 當成直接生成電影鏡頭的影片模型。Anthropic:Claude Opus 5.5 Claude Opus 5.5 做影片,實際上是在做什麼?如果你交代 Agent:「幫我製作一支 90 秒的科普動畫」,它可以先協助拆解主題與旁白,再規劃分鏡、場景、動畫節奏和字幕,接著在有提供適當工具與執行環境的前提下,建立 HTML、Canvas、SVG、Three.js 或 Remotion 專案,執行程式、檢查輸出、修改動畫,最後再串接 TTS、字幕或 FFmpeg。 所以更精確地說,Claude 負責理解需求、產生與修改程式、安排工具;動畫引擎負責呈現畫面;TTS、音效、FFmpeg 或剪輯工具則完成聲音與影片輸出。模型能否直接操作這些工具,要看你使用的 Agent、權限與環境設定。它不會只靠模型本身就自動完成上述每一步。 環節 Agent 可協助的工作 實際執行者 企劃與分鏡 拆解主題、旁白、Scene 與時間軸 Claude 與創作者 Review 動畫實作 建立 SVG、Canvas、Three.js 或 Remotion 程式 Agent 編輯檔案,動畫框架執行 聲音與字幕 整理旁白、字幕和時間標記,呼叫 TTS 外部 TTS、字幕工具或剪輯軟體 輸出與檢查 呼叫 Render、讀取輸出結果並修正問題 Renderer、FFmpeg 與可用的 QA 工具 **影片不是單純的媒體檔案,也可以是一套可重複產生影片的程式專案。**這個差異,是理解 Opus 5.5 影片工作流的起點。 為什麼 Agent 做影片可能會累積數百萬 Token?我看到的個別案例分享中,有人提到用 Opus 5.5 做一支科普動畫,約 30 分鐘完成,整段 Agent 工作階段累積約 500~600 萬 Token。這是單一案例的分享,不是 Anthropic 公布的影片製作平均值;如果沒有 API usage 明細、平台計算方式和完整執行紀錄,也無法單憑總 Token 數推算出精確費用。 Agent 不是只回答一次。它可能反覆讀取需求和程式、執行專案、檢查輸出、修正錯誤,再重跑 Render。程式碼量、工具輸出、Context 長度、修改輪數、QA 次數,都會讓不同專案的用量差很多。 比起只看成片幾分鐘,更有參考價值的問題是:有多少個 Scene?Agent 讀了多少程式和輸出?改了幾輪?重跑幾次?有沒有用 Prompt Caching?是否加入 TTS、音訊分析或自動 QA? Token 總量不等於同價的計費量以 Anthropic API 公布的 Claude Opus 5.5 標準價格為例,每百萬 Token 的一般 Input 為 US$4、Output 為 US$20;5 分鐘 Cache Write 為 US$5、1 小時 Cache Write 為 US$8,Cache Read 為 US$0.20。這些是本文撰寫時的 API 價格;不同產品方案、雲端平台、快速模式或後續調價可能不同,實際估價請以官方價格頁為準。 計費項目 用途概念 Opus 5.5 標準 API 價格(每百萬 Token) Input 送進模型、未命中快取的內容 US$4 Cache Write 首次將可重用內容寫入快取 5 分鐘 US$5;1 小時 US$8 Cache Read 後續讀取已快取的內容 US$0.20 Output 模型產生的文字或程式碼 US$20 假設一份用量報表中,Input 是 100 萬、Cache Read 是 400 萬、Output 是 100 萬,這三類加總是 600 萬 Token;依上述標準 API 價格試算,這三項約為 US$24.80,尚未計入 Cache Write、其他平台費用或可能適用的價格條件。這只是示範算法,不代表前面提到的個案實際帳單。 看帳單或用量頁面時,先確認 Input、Cache Write、Cache Read 與 Output 的定義,以及介面是否已將快取項目包含在總數裡,再分項估價;不要把所有 Token 都乘上 Output 的單價。 影片長度只能當粗略參考下面是原稿提出的工作量區間,只適合當作概念估算,不是官方規格、業界平均或保證值。影片腳本是否既有、場景複雜度、程式碼是否重用、Context 管理、Agent 次數及平台記帳方式,都可能讓結果大幅不同。 製作規模 原稿提出的 Token 概念區間 簡單 10~20 秒 Motion Graphics 數十萬 Token 等級 30~60 秒程式動畫 數十萬到百萬 Token 等級 約 90 秒科普動畫 百萬 Token 等級 複雜 MV 或多場景長時間自主 Agent 數百萬,甚至可能超過千萬 Token 哪些影片適合用程式來做?程式動畫特別適合畫面元素可明確描述、位置與時間能被控制的內容。它不是每種影片的替代方案,但在資訊正確、文字清晰或需要重複修改時,有自己的優勢。 Motion Graphics 與品牌動畫動態文字、Logo Animation、資訊圖表、數字動畫、線條、粒子、UI 動畫、字幕和轉場,都很適合用程式精準控制。若指定顯示「2026 AI Agent」,程式就能照規格排版,不會像影像生成一樣把字形畫錯。真正的品牌標誌仍應使用已核實的素材檔,不能讓模型憑空仿製。 科普與知識型動畫以「疫苗如何作用?」為例,可以將內容拆成免疫系統、抗原、抗體和記憶細胞,再為每個段落建立 Scene,串上旁白、字幕和動畫。這類影片若重點在資訊清楚、流程正確與方便修訂,SVG 或 Canvas 動畫有時比直接生成影像更合適。科學內容仍需專業查核,動畫只負責呈現,不能代替事實驗證。 像素風 MV 與歌詞動畫可將歌詞與音樂段落整理成時間軸,為每段設計 Pixel Art 場景,再用程式控制角色、背景和字幕切換,最後把音樂、畫面與字幕合成。這讓大量重複的時間軸工作更容易自動化,但美術方向、歌詞解讀與節奏感仍值得由人 Review。 Data Visualization Video給 Agent 一份 sales.csv,讓它協助找出重點、建立圖表、編寫旁白,再輸出 60 秒報告影片。這裡最重要的是數字從資料讀取,而不是讓生成模型自行猜測。例如營收 NT$3,582,000,就要由資料欄位帶入畫面,並驗證計算與標示正確。 生成式影片搭配 Motion Graphics實務上不必在「AI 影片」和「程式動畫」之間二選一。可以用生成式影片提供人物、場景或電影感素材,再由程式動畫加上字幕、Logo、圖表、歌詞、轉場與時間軸,最後使用 FFmpeg 或剪輯軟體合成。 工作路線 主要負責內容 常見適用場景 Generative Video 生成角色、場景、鏡頭與氛圍 真人感、電影畫面、場景運鏡 Programmatic Video 以程式控制文字、圖表、UI 和動畫 資訊圖表、教學、品牌字卡、歌詞動畫 混合工作流 生成式素材加上程式化資訊與剪輯 品牌影片、音樂 MV、知識型短片 影片也開始變成軟體專案以前要把片中的「2025」改成「2026」,可能得回剪輯軟體逐段修改。如果影片以程式生成,年份可以是變數;公司名稱、品牌色、業績資料與語言也可以從設定檔或資料表帶入。 同一套模板因此有機會產生 A 公司、B 公司和 C 公司版本,或依照不同資料自動更新圖表。這時,產物不只有 MP4,也包含一套可維護、可重複執行的 Video Generator。 但程式化並不代表沒有 QA。仍要檢查字幕是否正確、圖表是否引用正確資料、音畫是否同步、輸出解析度和影片長度是否符合規格。自動 Render 只是流程的一部分,不能取代成片檢查。 Video Engineering Prompt:把影片需求寫成規格傳統 AI Video Prompt 常描述鏡頭、光線、角色、運鏡與風格。程式化影片還需要把需求寫成 Agent 能執行的製作規格,例如: 解析度、畫面比例與輸出格式 每個 Scene 的內容、順序與 Duration Timeline、轉場、動畫與 easing 字型、Typography、字幕與安全區 旁白、TTS、音效、音樂和音訊時間點 使用的 Renderer、Render 指令和檔案結構 QA 條件:文字、資料、時間長度、解析度與輸出檔案 這已經很接近一份影片 PRD。Prompt 不只是說「做得漂亮一點」,還要交代輸入素材、限制、時間軸、驗收條件和交付格式。規格越清楚,Agent 就越容易在可檢查的範圍內工作。 下一階段:Agentic Video Production我會把這種做法稱為 Agentic Video Production(Agent 化影片製作):人提供主題、音樂、歌詞、素材和輸出要求,Agent 協助規劃、寫程式、呼叫工具、Render,再根據檢查結果修正。 人仍然要負責方向、審美、素材權利與最後 Review。Agent 可以接手很多重複的製作步驟,但工具是否能互相呼叫、影片能否一次做對、素材是否合用,都取決於實際工作流和 QA。 所以我看 Claude Opus 5.5 做影片,真正感興趣的不是「Claude 會生成影片了」,而是:**影片製作也開始能透過自然語言和程式工作流來建構。**這件事和 Vibe Coding 很像,讓不熟悉動畫或剪輯的人,也有機會把自己的影片製作流程做成可重複使用的工具。 如果你也在建立自己的影片流程,可以延伸閱讀用 Codex 打造 AI 影片工廠與AI 影片生成的價值轉移。 常見問答 (FAQ)Q1:Claude Opus 5.5 可以直接輸出 MP4 嗎?Opus 5.5 本身不是專門直接輸出影片畫面的生成模型。它可以在提供 Agent、程式執行環境與相關工具時,協助產生動畫程式、呼叫 Renderer 或 FFmpeg,再把輸出組合成影片;實際能力取決於你配置的工具和工作流。 Q2:Agent 工作階段累積 600 萬 Token,代表影片要花很多錢嗎?不能只看總 Token 數。一般 Input、Cache Write、Cache Read 與 Output 的價格不同,也要確認平台報表如何計算快取用量。最好取得實際用量明細,依模型、平台和當時價格分項估算;沒有明細時,個案總數只能作為工作量參考。 Q3:什麼類型的影片最適合用程式製作?需要精確文字、數據、圖表、UI、字幕、時間軸或多版本重複輸出的影片,通常較適合程式化動畫。真人表演、電影感鏡頭與複雜場景可搭配生成式影片,再用程式處理資訊圖層、字幕和剪輯。

  • article-Codex Skill 與 Plugin 到底差在哪?從個人工作流到團隊交付

    2026/9/27

    AI工具 AI Agent Codex
    Codex Skill 與 Plugin 到底差在哪?從個人工作流到團隊交付

    最近我在研究 Codex Skill,發現 Agent 的擴充方式正逐漸變得清楚。以前看到好用的 Skill,我會想:下載、放進 Codex,自己開始用。但如果做出一套能重複使用的工作流,想交給十位學員、五十位同事,甚至其他公司安裝,接下來就不只是「怎麼寫好一份 SKILL.md」了。 像是 MiniMax H3 影片提示詞整理、Slide Manifest 簡報流程、社群文章產生、課程企劃、AI 影片 Shot Manifest,或企業內部 SOP,都可能先從個人方法開始,最後變成團隊希望共用的能力。理解 Skill、Plugin 與 MCP 各自負責什麼,能幫我們用合適的結構保存這些方法。 先用四個概念拆開來看 元件 負責什麼 可以怎麼理解 Prompt 告訴 AI 這一次要做什麼 單次任務說明 Skill 描述一類工作怎麼完成,包含步驟、判斷、範例與資源 可重複使用的工作流程或 SOP MCP Server 提供 Agent 可呼叫的工具、即時資料或動作 能操作的工具入口 Plugin 把一個或多個 Skill,以及可選的 MCP、資源等組成套件 能安裝與管理的能力包 因此,我平常會把 Skill 記成「工作方法」,把 Plugin 記成「套件包裝」。Skill = Function、Plugin = Package 可以當作方便記憶的比喻,但它不是嚴格的技術等式:Plugin 裡可以只有一個 Skill,也可以加入 MCP Server 等元件。 Skill 是 Agent 能重複遵循的工作方法Skill 通常是一個資料夾,核心是 SKILL.md,必要時再放入參考資料、範本、資產或腳本。它會交代什麼情況適用、要收集哪些輸入、如何做判斷、按什麼順序執行,以及怎樣算完成。 例如 minimax-h3-prompt-standardizer 這類工作流,可以教 Codex 如何分析影片需求、拆分生成單元、處理人物與場景一致性、規劃鏡頭,再整理成適合模型使用的提示詞。Skill 教的是如何做這件事;影片仍由相應的模型或工具生成。 Skill 的價值在於把個人的 Know-how 寫成可以複用、檢查和持續修正的流程。模型可以更換,成熟的工作步驟、範本與品質標準仍能留下來。若你正在整理 Skill 與 Agent 執行環境的關係,也可以參考我之前寫的從 Skill 到 Agent Harness。 Plugin 是組合與交付能力的套件Plugin 的任務是把可重複使用的能力整理成一個有名稱、版本與結構的套件。官方架構允許 Plugin 包含一個 Skill,也可以放入多個相關 Skills;需要連接外部服務時,還能搭配 MCP Server。依套件需求,也可包含資產、生命週期 hooks 或選用介面。 可以想像一個「AI Video Production Plugin」包含故事規劃、Shot Manifest、H3 Prompt、影片檢查等 Skills,再視需求連接素材庫或其他工具。使用者安裝的是一套有關聯的能力,維護者則能一起整理套件版本與分發方式。 Plugin 不等於「把所有能力塞在一起」。官方建議從符合使用情境的最小結構開始;工作流程只需要說明和既有工具時,Skill-only Plugin 已經足夠。 2026 年 9 月的重要更新:官方明確支援 Skill-only Plugin截至 2026 年 9 月,我特別留意到 OpenAI 舊的 openai/skills repository 已標示 deprecated,並把目前的 Codex Skill 與 Plugin 範例導向新的 openai/plugins repository 與 Plugins 文件。官方文件也明確寫出,Plugin 可以只包含 Skills,不需要 MCP Server。 這不代表 Skill 失去獨立價值。Skill 仍是工作流程本身;改變的是,當我們需要依照新的 Plugin 格式整理、安裝或交付 Skills 時,可以直接用 skill-only plugin 作為套件結構。概念從 Skill 開始思考,交付時再判斷是否包成 Plugin,會是實用的路徑。 新版文件中的 portable Plugin 以根目錄 plugin.json 作為 manifest,Skills 放在 skills/,需要時再加入 mcp.json 與資產等內容。.codex-plugin/plugin.json 仍是相容格式;OpenAI 的 Plugin Creator 也能產生相容布局。開始建立套件前,請依目前目標平台與官方文件選擇格式,不要把舊範例路徑當成唯一結構。 一個最小的 Skill-only Plugin 可以概念化為: 12345my-first-plugin/├── plugin.json└── skills/ └── hello/ └── SKILL.md 這份套件可以只有說明、範本和其他工作資源,沒有 MCP、API、資料庫或 Connected App。它仍然是一個 Plugin,因為 Plugin 的核心價值是以可辨識的結構組合與交付能力,而不是一定要連外部服務。 MCP 與 Skill 的分工:一個教流程,一個提供工具如果希望 Agent 讀取 Google Drive、查詢 CRM、建立文件或更新 Notion,Skill 可以說明何時呼叫工具、如何判讀結果,以及怎樣完成後續步驟;MCP Server 則提供 Agent 實際可呼叫的工具與資料連線。 簡單來說: 123Skill = 說明怎麼完成工作MCP = 提供可呼叫的工具與即時資料Plugin = 將 Skill 與需要的工具配置等包在一起 技能文件不會自動帶來外部帳號權限,也不會讓沒有連接的服務突然可用。實際能做什麼,仍取決於已安裝的工具、使用者授權、服務端權限,以及執行環境。 什麼時候用 Skill,什麼時候包成 Plugin? 使用情境 建議起點 判斷方式 個人想固定文章、研究或簡報流程 Skill 流程清楚,現有工具已足夠 想讓一套成熟流程方便安裝與更新 Skill-only Plugin 交付與版本管理比額外工具更重要 多個緊密相關的 Skills 要一起使用 Plugin 使用者需要安裝一組有共同目的的工作流 流程還要讀寫外部服務 Plugin 加 MCP Server Skill 描述判斷步驟,MCP 提供受控工具 不需要等到 Skill 累積到某個固定數量才開始考慮 Plugin。只要一個成熟的 Skill 已經需要被標準化交付,skill-only plugin 就可能有用;反過來說,很多互不相關的 Skills 也未必適合硬包成一個 Plugin。關鍵是安裝、更新與使用情境是否一致。 從個人 Know-how 走到團隊工作流以公司 Sales Plugin 為例,可以先整理會議準備、客戶研究、會議摘要與 Follow-up Email 等工作方法,再確認哪些步驟需要 Gmail、Calendar、CRM 或 Drive 工具支援。Skill 寫清楚流程與判斷,MCP 讓 Agent 呼叫服務,Plugin 則把相關能力整理成團隊可管理的套件。 實際導入時,還要分別處理登入、資料範圍、使用者授權與企業政策。安裝套件不等同於取得 CRM 或公司雲端資料的存取權;這些存取能力必須由服務整合與管理設定明確提供。 這也提供一條較自然的發展路徑:先自己完成一項工作,記錄穩定的 SOP,整理成 Skill 並反覆使用;當流程需要工具時再連接 MCP 或 App;當能力需要成套維護與交付時,再包裝成 Plugin。先把真實工作做好,之後再依重複模式模組化,能避免一開始就替尚未驗證的需求建造太大的架構。 知識產品也可能從「教你做」變成「依方法幫你做」書、課程、影片、PDF 和範本通常傳遞的是知識,使用者還需要自己把它轉成行動。Skill 能把部分 Know-how 寫成 Agent 可遵循的工作流程;Plugin 則能進一步把相關流程、工具配置與資源組成一套交付物。 這讓課程設計也有新的方向:除了教 Prompt、圖像或影片工具,還可以教學員分析工作、建立 Skill、判斷何時需要 MCP,再把成熟且有共同目的的 Skills 包成 Plugin。交付的內容不只是「知道怎麼做」,也可以是讓 Agent 依照方法完成工作的起點。 結語:先設計 Skill,再依交付需求決定 Plugin我目前會這樣記:Prompt 交代這一次的需求;Skill 保存一類工作的 Know-how;MCP 或 App 提供 Agent 可使用的能力;Plugin 將一個或多個 Skills,以及需要的工具與資源整理成套件。 所以,個人工作流可以先從 Skill 開始。當它需要版本化、團隊共用、搭配多個相關工作流或連接工具時,再考慮用 Plugin 交付。OpenAI 在 2026 年 9 月明確提供 skill-only plugin 路徑,也讓「先設計 Skill,交付時採 Plugin 結構」成為值得採用的預設思路。 常見問答 (FAQ)Q1:Codex Skill 和 Plugin 最大的差異是什麼?Skill 描述 Agent 如何完成一類工作,通常包含指示、判斷步驟與支援資源;Plugin 是安裝與交付套件,可以包含一個或多個 Skills,並可選擇加入 MCP Server、資產等元件。 Q2:Skill-only Plugin 需要 MCP Server 嗎?不需要。OpenAI 官方 Plugin 架構支援只包含 Skills 的 Plugin。當工作流程仰賴外部服務資料或動作時,才需要再評估 MCP Server 或其他可用的工具連線。 Q3:要分享 Skill,就一定得包成 Plugin 嗎?不一定。個人使用或簡單分享可以先維持 Skill 的形式;若需要標準化安裝、一起管理版本,或與相關 Skills 和工具配置成套交付,就可以改用 Plugin。選擇應配合使用者與維護方式。 Q4:安裝 Plugin 後,Agent 就能操作我的 Google Drive 或 CRM 嗎?不一定。Plugin 需要包含或連接相應工具,服務端也要有適當的登入、授權與資料權限。Skill 說明工作流程,本身不會授予外部帳號的存取權。 官方參考資料 OpenAI Plugins 官方文件 OpenAI Plugins GitHub OpenAI Skills 說明 舊版 OpenAI Skills repository deprecated 公告 Plugin 架構 Plugin 封裝格式

  • article-MiniMax H3 提示詞怎麼寫?用 Codex Skill 建立 AI 影片工作流

    2026/9/27

    AI工具 Codex 影音行銷
    MiniMax H3 提示詞怎麼寫?用 Codex Skill 建立 AI 影片工作流

    做 AI 影片時,很多人會先研究「提示詞要怎麼寫」。但影片做得越多,越容易發現真正重複消耗時間的,是每次都得重新想:人物怎麼描述、鏡頭如何移動、動作要拆幾段、台詞怎麼保留、參考圖怎麼指定,以及哪些限制值得寫進提示詞。 與其每次從頭整理,不如把這些經驗交給一個可重複使用的 Skill。本文以 MiniMax H3 Prompt Standardizer 為例,介紹如何把一句畫面構想整理成較完整的影片提示詞,並說明如何在前面加上 Shot Manifest、在後面接續生成佇列與檢討紀錄,逐步建立一套自己的 AI 影片工作流。 先說清楚範圍:這個專案是 Codex Skill,負責整理提示詞與分段規劃;它本身不是 MiniMax H3,也不會直接生成或剪輯影片。提示詞是否能達到預期,仍取決於實際使用的模型、參考素材、產品版本與生成設定,不能保證一次成功。 MiniMax H3 Prompt Standardizer 在解決什麼問題?可以把這個 Skill 想成一個「Prompt Compiler」:使用者用自然語言描述想法,它再把人物、場景、動作、運鏡、聲音和限制整理成比較清楚、可複製的提示詞。 沒有固定整理流程時,工作大致是: 1234567畫面想法 ↓自己研究提示詞 ↓反覆修改 ↓交給影片模型 使用 Skill 後,提示詞整理步驟可以變得可重複: 123456789畫面想法或劇本 ↓Codex ↓MiniMax H3 Prompt Standardizer ↓整理後的 H3 提示詞 ↓MiniMax H3 或其他影片工具 專案的 SKILL.md 說明,它可以處理一句話、既有長提示詞、故事、劇本、對白、廣告構想、分鏡清單,以及參考圖片等輸入;依需求擴寫、精簡、修補提示詞,或規劃多段生成。它也把文字生成影片、圖片參考、多張參考圖、首尾幀、對白與聲音等列為提示詞整理情境。這些是 Skill 的提示詞工作範圍,不代表每個 MiniMax H3 介面或帳號都支援相同功能;使用前仍要確認目前產品可用的輸入模式與限制。 比方說,輸入: 1一個女生在雨夜車站等人,8 秒,16:9。 Skill 可以補出一份較清楚的描述,涵蓋人物、場景、主要事件、鏡頭流程、光線、色彩、聲音和必要的防錯條件。重點不在於把一句話變得很長,而是讓每一項資訊都有明確作用。 先決定一段影片要完成什麼,再寫提示詞這個 Skill 的一個實用做法,是在輸出前先判斷需求形狀:要用哪種生成方式、內容是對話還是動作、適合一鏡到底還是多鏡、需要什麼時長、故事是否要拆段,以及每段在哪個畫面節點結束。 它的規則建議在沒有指定時,為單次生成挑選合理時長,並以每段最多約 15 秒作為規劃參考。這是 Skill 的工作流建議,不是 MiniMax H3 的官方時長上限;實際能輸入的秒數要看當下使用的產品與模型設定。 故事很長時,切段也不應只依字數平均分配。每段最好是一個可以完整看見的微事件或情緒節點,避免把尚未完成的動作、姿勢或情緒硬拆在兩次生成之間。可以優先在下列變化處切開: 鏡頭景別或視角改變。 場景、時間或主要人物改變。 一個動作已經完成,下一段開始新的事件。 角色完成一個情緒節點,後面進入新的反應。 例如「跑進咖啡廳、認出前任、停下來對望、哭泣、放下戒指、轉身離開」其實包含場景建立、跑步、視線互動、表情變化、道具互動和情緒轉折。把所有事件都塞進短短幾秒,模型需要同時安排太多變化。可以先找出哪些動作能構成一個完整鏡頭,再決定每段提示詞要負責的內容。 這裡的關鍵是先定義 Generation Unit(單次生成單位),再寫 Prompt。與運鏡、攝影語言有關的延伸閱讀,可參考從 Google Flow 的 /orbit 學 AI 影片運鏡提示詞;更完整的 Skill 製片流程則可看從 Prompt 到專家 Skill 的 AI 影片製片工作流。 如何安裝與第一次使用?這個 GitHub 專案的根目錄包含 SKILL.md,因此可以從該 repo 安裝。若你的 Codex 版本提供內建 $skill-installer,可以在 Codex 輸入: 1$skill-installer install https://github.com/sengseng123/minimax-h3-prompt-standardizer 也可以把 Skill 放進個人技能資料夾。Codex 目前文件列出的個人本機 Skill 位置是 $HOME/.agents/skills: 123mkdir -p "$HOME/.agents/skills"git clone https://github.com/sengseng123/minimax-h3-prompt-standardizer \ "$HOME/.agents/skills/minimax-h3-prompt-standardizer" 安裝前先檢視 repo 裡的 SKILL.md 與其他檔案,確認這份指示適合你的工作方式。這個專案的核心內容集中在 SKILL.md,另有 agents/openai.yaml 供支援該格式的介面顯示名稱或描述。Codex 會自動偵測本機 Skill;若清單沒有出現,再依目前版本文件重新啟動 Codex。安裝目錄可能隨 Codex 版本與安裝方式不同,請以官方技能文件列出的載入位置為準。 第一次使用時,可以在 Codex 輸入: 1234使用 $minimax-h3-prompt-standardizer:一個女孩在雨夜車站等待某人。8 秒,16:9,真人風格,不要字幕。 短構想提供了主角、事件、時間、比例和一項畫面限制,其他細節再由 Skill 依規則補齊。若結果偏離原意,直接指出要改的人物、鏡頭、節奏或風格,不需要先學會專業術語。 什麼情況適合直接交給 Skill?單一情境、短時間、只有一個主要事件時,可以直接請它整理提示詞。例如: 12345使用 $minimax-h3-prompt-standardizer:幫我做一段 10 秒影片。台灣女生坐在深夜便利商店窗邊,窗外下著雨,她低頭讀到一則令人難過的訊息。真人實拍,16:9,不要字幕;情緒壓抑但不要過度戲劇化。 輸入可以口語、簡短,也可以是一段既有提示詞。使用者不必先決定所有鏡頭術語;若某個缺少的資訊真的會改變結果,Skill 才應該提出簡短問題。這符合專案的方向:讓人描述想完成的畫面,而不是要求每個人先學會 Prompt 工程。 長故事先加一層 Shot Manifest如果要做 MV、短劇、品牌影片、多場景廣告或一段較長的連續劇情,我會在提示詞整理前先建立 Shot Manifest(鏡頭規格表): 123456789故事或腳本 ↓Shot Manifest ↓H3 Prompt Standardizer ↓單段生成提示詞 ↓影片生成與檢查 Shot Manifest 是本文建議加在工作流前段的規格,不是這個 GitHub 專案內建的功能。它的用途是把故事邏輯和模型生成條件分開:編劇先決定角色、情節和情緒;分鏡規格再交代每一鏡的人物狀態、具體事件、動作方向和結尾。 我會讓每個 Shot 至少包含: Shot ID 與目的:這個鏡頭在故事裡要完成什麼? 建議時長與場景:預計生成多久、在哪裡、什麼時間? 人物與參考素材:畫面有哪些角色,哪些參考圖要鎖定人物或環境? 核心事件:這一鏡只需要讓觀眾看懂哪件事? 起始狀態與結束狀態:鏡頭開始時是什麼畫面,最後停在哪裡? 動作流程與運鏡:人物朝哪裡移動,鏡頭如何配合? 聲音:有哪些對白、環境聲、動作聲或配樂? 連續性與銜接點:服裝、道具、人物方向與光線如何延續?下一鏡從什麼畫面接起? 例如,故事「女孩走進空蕩的月台,停下來等待」可先拆成: 1234567891011121314SHOT 01目的:建立人物與月台環境建議時長:5 秒場景:夜晚、空蕩的室內月台人物:女孩核心事件:女孩走進月台中央並停下起始狀態:鏡頭看見空月台結束狀態:女孩站定,視線望向月台一側運鏡:中遠景緩慢推近參考素材:角色參考圖、月台場景參考圖聲音:遠處列車聲與室內環境音連續性:下一鏡延續同一服裝、站位與光線方向銜接點:以女孩轉向月台入口作為下一鏡起點 完成後再逐鏡轉成 H3 提示詞: 123使用 $minimax-h3-prompt-standardizer,把 SHOT 01 整理成 MiniMax H3 提示詞。保留人物、場景、起始狀態與結束狀態;不要新增事件。 這多一層整理,能先發現故事分段和素材規劃問題,不必等影片生成後才發現一段裡安排了太多事件。 多張參考圖要先標明各自用途如果會上傳多張圖片,先說清楚每張圖負責什麼,並指定有衝突時以哪張為準。比如: 123456789使用 $minimax-h3-prompt-standardizer。圖片 1 是人物主要參考,鎖定臉部與髮型。圖片 2 補充服裝與體型。圖片 3 是場景參考,鎖定空間與光線方向。圖片 4 是商品外觀參考。請整理一段 10 秒廣告提示詞:人物走進咖啡廳,坐下後拿起圖片 4 的商品。人物與商品外觀以主參考圖為準。 專案的規則建議在正式提示詞前,先以 @圖片1、@圖片2 等標記列出上傳順序、主要參考和鎖定資訊。參考圖可能彼此衝突,也可能帶著不需要的背景、姿勢、浮水印或介面文字;要說明哪些視覺資訊應保留,哪些應忽略。不要指示 Skill 描述它沒有收到的素材。 對白與 Lip Sync 要提供可執行的細節如果畫面裡有人說話,只提供一句台詞通常不夠。可以補充說話者、說話時間、視線、呼吸、停頓、情緒與聲音質地: 1234567說話者:台灣女生,約 25 歲,聲音自然,不要播音腔。情緒:像是忍住眼淚,語速稍慢,中間停頓一次。台詞:「你終於來了。」台詞必須逐字保留,不要改寫。請讓嘴型與說話時間對齊。 這個 Skill 的規則明確要求,除非使用者要求改寫,否則保留原始台詞;也建議交代誰在何時說話、聲音情緒、停頓和嘴型同步。實際對嘴表現仍受生成工具和素材影響,提示詞只能交代目標,不能保證結果。 把抽象形容詞換成看得見的描述「電影感」、「高級感」、「震撼」、「史詩」或「絲滑」,本身很難告訴模型畫面該如何安排。試著把這些詞拆成可以觀察的鏡位、動作、光線、色彩、節奏與材質。 例如: 12345模糊:人物以很有電影感的方式走過來。具體:低機位中景跟拍,人物由畫面左後方走向右前方;鏡頭穩定地緩慢後退,背景保持淺景深,暖色街燈在遠處形成柔和散景,人物臉部保留自然陰影。 如果要描述角色動作,則交代方向、重心、原因、反應、與環境的互動,以及動作結束時的姿勢。例如「男子向左揮拳,女子側身閃避,身體重心轉到左腳;拳頭擦過肩膀,碰倒後方桌上的紙杯,男子收拳後停在她右前方。」比「兩個人激烈打架」更容易讓人看懂要生成的事件。 轉場用畫面元素銜接,而不是只喊「絲滑」要接兩個場景,可以先找一個可見元素作為轉場錨點,也就是 Match Element。例如第一鏡推近一把紅色雨傘,直到傘面填滿畫面;下一鏡從相似的紅色開始,再拉遠揭露那是咖啡廳的紅牆。這樣交代了前後畫面如何匹配,不必只寫「使用絲滑轉場」。 長故事也可以記錄前一鏡的結尾姿勢、人物方向、道具位置和光線,並指定下一鏡從哪裡接續。每段可以獨立生成,但規格表仍保留全片的連續性資訊。 聲音分層,提示詞會更清楚聲音可以分成三層描述: 對白:角色說話或旁白,包括內容、說話者、時機、語氣和停頓。 畫面內聲音(Diegetic Sound):角色也處在其中的雨聲、腳步聲、門鈴、杯子碰撞或遠處車聲。 畫面外配樂(Non-diegetic Sound):觀眾聽得到、但不是場景裡物件發出的背景音樂。 不要把三種聲音混成「加一點有氛圍的音效」。可以指定哪些聲音要突出、哪些只當背景,並只保留這個鏡頭真正需要的聲音設計。 防錯限制要針對場景挑選人物一致性、服裝變化、道具重複、手指異常、口型不符、人物瞬移、軸線反轉、鏡頭跳動、光線不連續、意外文字或風格漂移,都是常見的影片生成問題。不代表每個提示詞都要把整份負面限制貼一遍。 先想清楚當前 Shot 最可能失敗的地方,再補對應限制。例如人物拿著一杯咖啡並轉身時,可能要注意杯子不要複製、人物轉向保持一致;若只有遠景空景,手指或 Lip Sync 就不是需要處理的條件。限制越貼近畫面任務,越容易看懂它要避免哪種錯誤。 把單次生成接成可管理的工作流如果一部影片包含許多鏡頭,我會把它擴充成以下流程。這是本文整理的工作流建議;Generation Queue 與失敗知識庫不是這個 Skill repo 的內建功能: 1234567891011121314151617想法 ↓故事與劇本 ↓Shot Manifest ↓參考素材規劃 ↓H3 Prompt Standardizer ↓Generation Queue ↓影片生成 ↓人工檢查與重生失敗鏡頭 ↓剪輯軟體組片 Queue 可以用 Markdown 或試算表記錄每一鏡的提示詞檔案、參考素材、狀態與失敗原因: 1234567891011121314SHOT 001Status: ReadyReference: character-a.pngPrompt: prompts/shot001.mdSHOT 002Status: WaitingReference: character-a.png, room-a.pngPrompt: prompts/shot002.mdSHOT 003Status: RegenerateReason: 人物臉部在鏡頭中途改變Prompt: prompts/shot003-v2.md 狀態名稱可以依自己的流程調整,例如 Ready、Generated、Approved、Regenerate。記錄可以回答:哪些還沒生成、哪些已通過、哪些要重做,避免只靠記憶管理一長串鏡頭。 每次重生前也可以先寫一筆 Review: 1234567SHOT 07 Review問題:人物臉部一致性下降發生時間:約 4 秒觀察:鏡頭旋轉後臉部特徵開始改變可能原因:鏡頭旋轉幅度過大下一次調整:減少環繞幅度,增加正面停留時間,重新指定人物主參考圖 累積一段時間後,失敗紀錄便能整理成自己的 Failure Knowledge Base:哪些動作容易失敗、哪些運鏡會影響角色一致性、哪些參考圖組合較合適。這些紀錄是團隊自己的經驗,不應直接當成 MiniMax H3 的永久規則。 讓 Skill 符合自己的製作習慣原版 Skill 可以作為起點。若想做個人版本,可以複製後再加入自己的偏好,例如預設使用繁體中文、預設不加字幕、人物一致性優先、長故事先產生 Shot Manifest,或對話鏡頭避免劇烈環繞運鏡。 建議把「普遍有幫助的規則」和「特定專案偏好」分開。工作流規則可以告訴 Skill 如何判斷、如何輸出;專案偏好則描述你的影片風格與製作要求。無論如何擴充,都要清楚標示必要條件與可選建議,避免把過去某次成功的設定說成每個模型都適用。 可以直接保存的短片提示詞指令123456789101112131415使用 $minimax-h3-prompt-standardizer。請把以下內容整理成適合 MiniMax H3 的影片提示詞。若單次生成可以完成,輸出一段提示詞;若事件太多,拆成數段完整的 Generation Unit。每段保留一個主要事件,不要切開尚未完成的動作;優先在場景、視角、時間、人物或完整動作結束處分段。維持人物、服裝、道具、移動方向與光線連續。有參考圖時標明每張圖片用途,對白逐字保留。只加入這一鏡真正需要的防錯限制。不要自行加入字幕、Logo、浮水印或畫面文字。我的構想:{{貼上故事、劇本、既有提示詞或畫面想法}} 長故事先產生規格,再逐鏡產生提示詞若要處理 MV、短劇或多場景廣告,可以先要求 Codex 不要立即輸出影片提示詞: 12345678910111213以下是一個完整故事,請先建立 Shot Manifest,不要直接產生影片 Prompt。每個 Shot 都要是一個可在單次生成內完成的完整微事件,並列出:Shot ID、故事目的、建議時長、人物、場景、核心事件、開始狀態、動作流程、結束狀態、運鏡、光線、聲音、參考素材、與前一鏡的連續性,以及與下一鏡的銜接方式。完成 Shot Manifest 後,逐鏡使用 $minimax-h3-prompt-standardizer產生提示詞,最後另建 Generation Queue,記錄 Ready、Generated、Approved 或 Regenerate 狀態。故事:{{貼上完整故事}} 這個順序先把「故事如何拆鏡」和「每一鏡如何寫成模型提示詞」分成兩個任務。若想從更完整的製片視角延伸,也可以參考AI 影片製片工作流。 五分鐘快速操作1234567891. 安裝並檢視 MiniMax H3 Prompt Standardizer。2. 單一短畫面直接使用 $minimax-h3-prompt-standardizer。3. 長故事、MV 或短劇先建立 Shot Manifest。4. 逐鏡整理 H3 提示詞。5. 標示人物、場景與商品參考圖用途。6. 用 Generation Queue 管理待生成與待重做鏡頭。7. 生成後檢查人物、動作、聲音與連續性。8. 只針對失敗的鏡頭修改提示詞並重生。9. 將通過的鏡頭交給剪輯流程組成成片。 影片模型會更新,某些特定提示詞寫法也可能隨產品調整;但把故事、鏡頭、參考素材、生成與檢查拆成清楚步驟,能讓經驗留在工作流裡。與其每次從頭重寫 Prompt,不如把可重複的判斷整理成 Skill,把影片製作變成可檢視、可修正的流程。 常見問答 (FAQ)Q1:MiniMax H3 Prompt Standardizer 會直接生成影片嗎?不會。它是給 Codex 使用的 Skill,負責把畫面想法、故事或現有提示詞整理成影片提示詞;要生成或剪輯影片,仍需使用支援相應功能的影片工具。 Q2:只輸入一句話也能使用嗎?可以。專案設計上接受一句話構想,會依可合理推定的資訊整理提示詞。若時長、比例或其他缺漏會明顯改變結果,再補充條件即可;不用先掌握專業提示詞術語。 Q3:每段 15 秒是 MiniMax H3 的硬性上限嗎?不是。約 15 秒是這個 Skill 用來規劃單次生成的建議,不是 MiniMax H3 的官方產品限制。實際可用時長、參考素材模式與生成參數,請查看目前使用的 MiniMax 介面說明。 Q4:Shot Manifest 和 Generation Queue 是 Skill 內建功能嗎?不是。MiniMax H3 Prompt Standardizer 的核心是提示詞整理與分段建議;Shot Manifest、Generation Queue 和失敗紀錄是本文建議加上的工作流層,可以用 Markdown 或試算表自行管理。 Q5:安裝後沒有看到這個 Skill 怎麼辦?先確認 SKILL.md 位於 Codex 目前會掃描的本機 Skill 資料夾,並查看 Codex 的 Skill 清單;如果尚未載入,再依官方文件重新啟動 Codex,或更新資料夾位置。個人和專案層級的載入路徑可能不同,安裝前請先檢查目前版本的說明。

  • article-享哥宇宙 EP010|回家的那一聲

    2026/9/27

    享哥宇宙 科幻喜劇 AI故事
    享哥宇宙 EP010|回家的那一聲

    本篇為「享哥宇宙 Sean Verse」EP010《回家的那一聲》的連載試讀版。系列仍在創作整理中,後續文字與設定可能繼續修訂。 閱讀完本集後,可回到享哥宇宙專頁瀏覽已收錄篇章。 第一章 最後一晚不是世界末日年度路線合併在天亮前開始。轉運站的大螢幕列出所有尚未驗證的人工支線,逐條標成「暫停」或「併入主線」。每過一分鐘,就有一條灰色路線從清單上消失。 白手套站在南側入口,正關閉一條曾發生事故的窄道。門邊貼著缺失的維修紀錄,欄杆也沒有重新驗收。享哥沒有要求他重開。 「那條路不安全。」享哥說。 白手套看了他一眼,像是在等他補一句「但是」。 享哥沒有補。 他把這幾集收下的紙本放在桌上:許伯親手簽的操作紀錄、小滿原件的編號、自己付費查到的舊班表、夜市人工排程回條、林技師補過外殼的羅盤,還有被雨水弄裂的中繼線圈。每一樣都能證明一件小事,沒有一樣能單獨證明阿策正在另一端等他。 「你可以放棄測試,先跟人群撤離。」白手套說,「窗口關閉後,要等下一個審核週期。」 「我知道。」 「不是我不想幫你回家。」 「我知道。」 白手套把路線圖轉向他,指著唯一有維修班現場簽到、有可撤退護欄,也有人願意值守的人工線。旁邊另一條支線曾經出過事故,紀錄仍缺欄位。 享哥想回家,也想在走之前完成自己答應的測試。這次不是輝哥的安排,也不是回不了家才留下。他可以現在離開,或者把已經查到的資料交給安全員,自己選擇要不要試。 「只測這一條。」他說,「其他線照你的安全結論走。」 白手套點頭。「現場安全由我負責。你要離開,我也會帶你走安全通道。」 「我留下來測。」 「那是你的決定。」 第二章 舊聲音先到了小頻把接收端接上本地記錄設備。她先確認測試不會儲存任何人的新語音,設備只留時間戳、訊號強度和是否為即時回應。林技師在另一側檢查接地與電源,沒有替受潮線圈通電。 「先看舊紀錄。」小頻說。 三天前的延遲語音還在緩存裡。她比對檔案建立時間和本地收件時間,才讓萬丸播放。 阿策的聲音響起:「稿子先存起來。不要在路上改到忘記吃飯。」 享哥肩膀往前一動,手指差點碰到回覆鍵。 「時間戳。」小頻提醒。 這段聲音比今天早三天。它不是在此刻回答,也沒有因為他們今天的動作而改變。 「我剛才差點又把它當成現在。」享哥說。 「你可以希望它是現在。」小頻說,「但紀錄要寫它實際是什麼。」 「我剛剛就是這麼想。」 白手套沒有催他,只沿著安全區巡了一遍,確認撤退繩、護欄和備用電源都在位置上。林技師把線圈從防水袋取出,展示已經乾燥的接點和裂開的外殼。 「這個只能送出一個低功率短脈衝,接收端不在這裡。」他說,「它送出去後會不會有回覆,要看另一端設備和人工窗口。」 「如果沒有回覆?」享哥問。 「我們只能記錄沒有收到。」 「如果有聲音呢?」 「先看時間戳,確認是不是舊檔。」小頻說。 「這句我已經背起來了。」 「背起來不等於做得到。」 享哥拿出手機,打開那份小說草稿。第十八章的檔名停在最上面:第十八章_最後真的最後版_真的。 「阿策知道這個檔名。」他說。 小頻看了一眼。「問一個對方能回答、而且你有理由相信只有你們知道的問題。別問只有你自己能證實的事情。」 「好。」 林技師先用測試器檢查本地接收設備,沒有啟動發送線圈。設備亮起綠燈,表示接收端可用;這只是本地檢查,沒有訊號離開轉運站。 第三章 只保留一條能驗證的路路線合併倒數開始。站內另一端,一道未完成維修的窄門突然落下,白手套立刻拉開警戒線。 「那一條永久停用。」他說,「上次事故的維修紀錄在這裡,欄杆沒有重新驗收。不能因為今晚要測試,就把它算成可用支線。」 享哥看過那份報告。缺的不是一個簽名,而是整段現場檢查;沒人能證明欄杆修好。 「我不申請重開這條。」他說,「只申請有維修班簽到、現場有退路、也有人守入口的人工線。」 輝哥把已補交的小頻合作條款、收件回條和自己支付延誤費的紀錄放到桌上。這些文件不能替安全方案背書,但能證明他這次確實交過資料,也承認了之前漏交的事。 「我這邊有一筆沒準時送到的文件,延誤費由我付。測試條件、小頻的資料範圍和享哥的回程要求,都在這一份。」 白手套逐項核對。他只在安全方案那格簽下自己的名字,沒有替任何人簽意願,也沒有替另一端保證接通。 「窗口只開到天亮,兩名值守員,每十五分鐘回報一次。測試結束就關閉,這不是長期通行權。」 「知道。」享哥說。 小頻把自己的權限條件再讀一遍:不保存原始語音、不替任何人消除警報、不自動續約。她簽名後,白手套在安全欄補上撤退方式。林技師確認發送線圈只能用一次,收訊由另一端站務設備留存,不把兩種功能寫在同一件器材上。 享哥把線圈放到固定架上。小頻守著記錄台,只看訊號波形;白手套站在通道另一端;輝哥負責電源和接地。站務員站在已驗證的護欄內,等著確認測試是否結束。 「本地迴路檢查不會啟動線圈。」林技師說,「接地、護欄和時間標記都正常後,你再決定要不要用唯一一次低功率脈衝。」 「你們都在。」享哥說。 「我在。」小頻答。 「現場安全我負責。」白手套說。 輝哥拍了拍電源盒。「我也在。電源盒也在。」 享哥笑了一下,把手放在發送鍵上,沒有立刻按。 「如果接收端先出現舊聲音,我就停下來看時間戳。」 「對。」小頻說。 「如果沒有聲音?」 「就記錄沒有回覆。」 「如果真的有人回答?」 白手套說:「先確認線路穩定,再由你決定下一步。」 第四章 那個檔名只有他知道最後一遍本地檢查完成後,小頻開啟即時時間標記。白手套確認撤退線沒有被遮住,輝哥把備用電源固定好。所有人都知道線圈只有一次低功率發送機會。 享哥看著手機上的檔名。「我問這個。」 他把線圈接上已驗證的發送端,再次確認單人、單次、限時的條件。享哥對著麥克風說:「阿策,如果你現在在線,告訴我工作室桌面那份稿子的檔名。」 他按下唯一一次低功率發送脈衝。線圈只響了一聲短促的蜂鳴,指示燈亮起不到一秒便熄了。螢幕先顯示「已送出」,沒有寫收到。 享哥盯著狀態欄,直到小頻提醒他先看時間標記,不要盯著自己想要的答案。 幾秒後,接收端的時間欄開始跳動。小頻先檢查本地快取標記,再看進入時間與發送時間是否一致。狀態燈從待機轉成即時連線。 接收器裡傳出阿策的聲音:「第十八章_最後真的最後版_真的。你到底為什麼把檔名取成這樣?」 那不是三天前的錄音。小頻核對時間戳,確認聲音在脈衝之後抵達;接收端沒有讀取舊緩存。白手套檢查線路,確認沒有播放舊檔。 享哥抓緊欄杆。「你現在聽得到我嗎?」 「聽得到。你人在哪?你消失好幾天了。」 「我還在外面。稿子有存好。」 「我知道,我剛才看到了。鹽酥雞還在冰箱,你回來自己熱。」 享哥吸了一口氣。那不是完整解釋,也不是阿策突然知道一切;只是兩個人終於在同一刻聽見彼此。 「我會回去。」他說。 「先別在路上改稿。回來再說。」 通話斷開。即時窗口進入冷卻,沒有第二次發送機會。小頻記下雙向確認成立,只存時間戳和狀態,不保存兩人的語音。 第五章 工作室真的有味道萬丸顯示:即時雙向確認成立。回程條件:短時窗口、單人、一次;本地責任須先完成交接。 享哥看向白手套。「通道上的人都交接好了嗎?」 「維修班已接手,事故支線保持封閉。窗口值守員在位。」白手套說,「你可以走。這是本地狀態,不是我替你做的選擇。」 享哥看向輝哥。「你還有要我簽的嗎?」 輝哥把本次測試的費用和設備歸還條款交給他。線圈已完成唯一一次脈衝,所有權仍屬夜渡站,享哥要把外殼和測試紀錄交回林技師。 「沒有別的案子要你留下。」輝哥說,「你自己決定。」 「我走。」 回程窗口只剩不到一分鐘。享哥把線圈交還林技師,確認白手套拿到完整測試報告,再把欠路羅盤放進自己的口袋。羅盤沒有指向門,也沒有替他選擇。 他走進那道不是門、卻映著工作室燈光的入口。跨過去時,先聞到微波爐裡鹽酥雞放久的油味。 工作室的椅子歪在桌邊,螢幕停在第十八章。阿策的訊息跳出來,這次沒有延遲標記。 「你現在在哪?」阿策問。 享哥看了看冰箱。「工作室。我回來了。」 「那你先把稿子存好,再去微波。不要一回來又改到凌晨。」 「你這句話很像真的阿策。」 「什麼叫像?」 「沒事。我晚點跟你說。」 通話沒有被系統替他們補上和好、解釋或承諾。阿策仍在等答案,享哥仍欠著稿子。他先把檔案存好,走到冰箱前拿出那盒冷掉的鹽酥雞。 手機彈出輝哥傳來的結算回條:回程窗口已使用,人工支線只獲限期試行,設備已交還。下一次測試須重新申請。 享哥把鹽酥雞放進微波爐,按下開始。 這次沒有任何人替他決定留下或離開。那條路只開了很短一段,足夠他回到工作室,沒有變成任意往返的門。 微波爐開始轉。稿子存在硬碟裡,阿策的聲音留在通話紀錄外,回家的事則先停在今天。 至少今晚,他真的回家了。

  • article-享哥宇宙 EP009|輝哥忘了誰簽過名

    2026/9/27

    享哥宇宙 科幻喜劇 AI故事
    享哥宇宙 EP009|輝哥忘了誰簽過名

    本篇為「享哥宇宙 Sean Verse」EP009《輝哥忘了誰簽過名》的連載試讀版。系列仍在創作整理中,後續文字與設定可能繼續修訂。 閱讀完本集後,可回到享哥宇宙專頁瀏覽已收錄篇章。 第一章 評分只有不適合輝文會的公開評測室裡,小頻面前放著三段聲音:一段是舊廣播,一段是現場警報鈴,最後一段是兩種聲音同時響起。桌旁的白板標著測試範圍,沒有任何人的通話錄音。 「要不要先聽原始音檔?」評測員問。 「不用。」小頻說,「我先看今天授權我測什麼。」 評估表只寫「結果可供外勤適配參考」,沒說原始聲音能不能留存,也沒說交給誰。小頻沒有按開始。 輝哥站在桌邊,翻完上衣口袋和樣品箱,沒找到她簽過的資料條款。 「你不是說文件都送了?」享哥問。 「我記得簽過。」 「我問你送了沒有。」 輝哥沉默了一下。「我沒看到收件回條。」 白手套立刻按下暫停。「資料權限沒確認,小頻不能開始。我不能拿『大家都記得』當成授權。」 享哥先以為評鑑組又在用程序卡住人。小頻從自己的資料夾抽出一份副本,上面有她和輝哥的簽名、日期,還註明原始音訊不提供。她把那張紙推到桌子中央。 「我有簽。」她說,「但沒有授權保存原始聲音。」 輝哥仔細看了看自己簽名的位置。「我以為簽完就送進去了。」 「你是說你不記得送了,還是沒送?」享哥問。 「我沒送。」 小頻把副本收回去。「我的工作條件已經寫清楚。今天要測什麼,可以重新談;資料要怎麼用,不能先做了再說。」 白手套把未開封的設備推回桌角,請所有評測員重新列出可用訊號和保存期限。這不是取消評測,而是先讓每一個人知道正在接受什麼測試。 第二章 測試不用交出全部評測室外的走廊裝有一只固定安全廣播,另一端有手動警報鈴。白手套把撤退線畫在地上,將警報鈴搬到低風險區,測試全程有兩名工作人員在場。 「只測三段聲音來源,不留存原始音訊。」小頻說,「結果先存在我的本機報告裡。交給輝文會以前,我要自己看過。」 評測員皺眉。「沒有原音,第三方沒辦法完全複核。」 「可以在現場重播廣播、重新拉鈴。」小頻說,「我不需要把別人的私人聲音交出去,才能證明自己聽見差別。」 白手套點頭,把測試方式改成現場可重播的廣播和手動鈴,不用任何人的通話錄音。評分表因此少了一項原始資料的驗證,但測試邊界清楚了。 第一段只有廣播聲。小頻在聲音開始前標出固定的電流雜音,又記下句尾那一拍的空白。 第二段,評測員拉了一次手動鈴。小頻沒有立刻回答,只先確認現場沒有另一個喇叭同步播放,再把波形記成「即時振動」。 第三段兩個聲音同時響起。她把它們分開標記,各自寫下開始時間和間隔。萬丸只保留測試結果,不存音檔。 評分系統跳出「資料不完整,外勤適配度不足」。 享哥盯著螢幕。「她三段都分出來了,系統說她不適合。」 「因為資料不能獨立複核。」白手套說,「它算不出完整分數,不等於她答錯。」 「那它就把『不完整』當成『不適合』?」 「目前的表格是這樣設計的。」 享哥本來想把椅子推開,叫大家去看實際測試。他先停下來,問小頻:「妳要不要重做一遍,讓他們現場看?」 「可以。但這次由我決定何時開始,也由我確認結果有沒有寫錯。」 她把廣播關掉,等走廊恢復安靜,再請評測員重新拉鈴。這次她先說出聲音來源,再讓大家回看控制台時間。三次重測,她都分對。評測員能看到警報鈴被拉動的時刻,卻沒有拿到任何人的原始錄音。 「現在有足夠資料嗎?」小頻問。 評測員承認現場測試可核對,但自動評分不會替她加分。「結果仍然是外勤適配度不足。」 享哥忍住沒替她回答。「妳要怎麼處理?」 「把現場紀錄放進我的申訴。原音不交。」 白手套在安全欄簽名,註明測試完整、安全線未被越過;評分欄仍維持未通過。兩件事沒有被混成一個結果。 第三章 簽名不會自己走到收件匣評測結束後,輝哥回到辦公桌前搜尋寄件紀錄。他找過寄件匣、掃描資料夾和樣品箱,最後在夜市排班單後面找到那份已簽名的條款,紙角還沾著一點豆漿糖。 沒有寄件時間,沒有收件回條。 「是我漏交。」他說,「我把簽名當成事情已經完成。」 小頻收起自己的副本。「你答應過我,測試前先確認資料範圍。」 「我沒做到。延誤費我付,今天的出勤照算。我會把漏交寫進事故紀錄,也接受內部核對。你可以不再接我的案。」 他沒有說最近很忙,也沒有怪掃描系統。白手套要他把未送出的文件、發現時間和補救方式寫在同一張表上。輝哥簽名,自己把延誤費轉到小頻的帳上,再請她確認金額。 「我不打算退出。」小頻說,「第一份短期測試已經做完。下一期我願意再做三次,每次開始前先看用途,資料只留結果,不交原始聲音。你漏一次,我就停。」 輝哥問:「可以把這些寫在同一份合作條款嗎?」 「可以。寄出後把收件證明給我,不要只說你寄了。」 享哥看著他。「你要怎麼證明?」 輝哥把條款掃描到小頻指定的收件資料夾。小頻先在自己的裝置上確認檔案與簽名都看得見,才把正本放進資料袋。白手套另外留下評測室的現場紀錄,兩份檔案用途不同,沒有互相取代。 「這次收到。」小頻說。 「我也收到。」輝哥答。 「你收到什麼?」 「收到要留收件證明。」 小頻沒有笑,只把回條收進自己那一層資料夾。 第四章 昨天的聲音先到了雨夜受潮的中繼線圈還封在乾燥袋裡。白手套不允許直接通電,小頻也沒有把線圈接到任何外部頻段。她先打開夜渡站交來的本地接收設備紀錄,查找前幾日留存的回執。 螢幕上有一個未讀語音檔,收件時間比今天早三天。檔案來自阿策的舊聯絡端,狀態是「延遲轉存,待本人讀取」。 享哥看見名字,手已經伸向播放鍵。 「先確認時間戳。」小頻說。 「我知道。」 「你剛才還不知道。」 他把手收回來。小頻先核對檔案大小、來源和建立時間,確認它不是今天剛抵達的訊息,才把揚聲器轉向享哥,沒有匯出副本。 阿策的聲音在測試室響起:「稿子先存起來。不要在路上改到忘記吃飯。」 享哥聽完,幾乎立刻按下回覆鍵。白手套還沒來得及開口,小頻已把他的手腕輕輕擋住。 「這不是即時通道。」她說,「它三天前就進了本地接收設備,今天只是有人把緩存檔找出來。」 享哥鬆開手。「我知道。」 「你剛才不知道。」 「我剛才希望它不是。」 房間裡安靜了幾秒。那是一個很難笑的地方,享哥沒有補笑話。 小頻關掉播放器,將時間戳寫進自己的結果報告,不留存音訊。阿策的聲音仍舊停在昨天,甚至更早;被播放出來,不等於有人正在另一端聽。 白手套把下一次測試申請放到桌面上。只核准一個受監督的即時窗口,時間排在下次路線合併前。要用受損的線圈,先由林技師確認它只作一次低功率發送;接收端則使用獨立的站務記錄設備,不以舊緩存冒充即時回覆。 「這是資格,不是保證。」白手套說。 「我聽過了。」享哥把封存袋放回箱裡,「而且這次我會先看時間戳。」 小頻把合作回條交給他看。「你也要看清楚收件時間。新文件已經到,舊語音沒有。」 享哥將兩個時間寫在同一頁上,中間留了一條空白線。他沒有把阿策的聲音刪掉,也沒有按下回覆。 下一次測試之前,他們得先確保有人值守、接收設備可查,還有一條能安全離開的路。

  • article-享哥宇宙 EP008|陰路全線暫停

    2026/9/27

    享哥宇宙 科幻喜劇 AI故事
    享哥宇宙 EP008|陰路全線暫停

    本篇為「享哥宇宙 Sean Verse」EP008《陰路全線暫停》的連載試讀版。系列仍在創作整理中,後續文字與設定可能繼續修訂。 閱讀完本集後,可回到享哥宇宙專頁瀏覽已收錄篇章。 第一章 全線暫停,請保持冷靜暴雨從轉運站高架道的接縫灌下來。廣播每分鐘播一次「陰路全線暫停」,每播完一次,南側入口的水就又高一截。 站內大部分乘客已被帶到二樓。白手套在入口拉起第二道封鎖帶,手上拿著路線關閉清單。南側工具間還有三名夜班人員,一時無法穿過積水回出口。 「南側維修道不是乘客通道。」他說,「欄杆缺口還沒查,不能放人進去。」 享哥看著工具間的定位燈。「那三個人怎麼出來?」 「工具間後面有一條高架廊道。我先確認電源和撤退點,再決定能不能用。」 輝哥打開器材箱找中繼線圈。裡面有一卷救援繩、兩盞紙燈、一盒餅乾,還有一張被水泡軟的空白交接單。 「線圈呢?」享哥問。 輝哥把器材箱翻過來。「我剛才放在撤離桌上。」 「撤離桌呢?」 「被搬去另一個安全區了。」 「你是不是把線圈一起交走?」 「可能。」 「這種可能在你身上通常不太可能。」 白手套把撤離時刻表按在箱蓋上。「先救人,再找物品。」 他沒有提高聲音,卻讓人都停下手邊動作。享哥想起線圈只剩一次低功率測試機會,還想起夜渡委託後拿到的費用;可工具間裡的人還在等一條能安全走出的路。 「先看現場。」他說。 白手套點頭。「我帶隊,任何人不越過封鎖線,直到我確認。」 許伯從值班室傳來一張南三線舊圖。圖上有手動分流點、維修口和一段繞到南側工具間的高架道。新路線表把那一段標成封閉;紙本舊圖仍留著兩個維修記號,一個是許伯親手註的「03」,另一個是夜市人工排班表上相同格式的現場簽到章。 享哥從資料袋裡取出 EP003 拍下的藍色紙標照片,上頭可辨認「南三線/03」,新路線表卻查無此線;旁邊放著 EP007 的夜市人工簽到回條,紙本有名字,掃描狀態仍顯示無人值守。許伯傳來的舊圖則標出手動分流點和維修口。 「這三樣不能直接接成一條路。」享哥說,「但它們都提醒我們,先查南側的人工維修區。」 「許伯說這條廊道以前給維修班走。」他說。 「以前能走,不等於現在安全。」白手套答。 「我知道。要現場查。」 小頻透過通訊器接進來,只讀取定位燈和排水泵的振動,不接收工具間裡的對話。她確認三個定位點仍在移動,代表裡面的人能走動,卻不確定出口方向。 「工具間有備用水和電池嗎?」享哥問。 「站務清單寫有。」小頻說,「清單最後更新是兩年前。」 「這句話沒有讓人比較安心。」 「它也沒有要讓你安心,只是清單內容。」 第二章 羅盤只找到一個人享哥拿出欠路羅盤。指針在水氣裡打了兩圈,最後停向封鎖線另一側的一名站務維修員。那人提著絕緣桿,正在查看電箱標籤。 「它又指到人。」輝哥說。 「不代表他會讓我們走。」享哥答。 維修員看了看羅盤,又看了看白手套。「我是林技師,負責南側電源檢修。高架廊道能通到工具間外門,但中間有一段漏電警示。」 「你能走嗎?」白手套問。 「我可以先從安全側測外門。裡面那段要關掉總閘,總閘在側門另一邊,手動拉桿可能卡住。」 白手套把一盞紙燈放到積水前。紙燈漂出兩三步,就被急流推向排水口,撞在格柵上,燈芯熄了。 「那段不用走。」他說,「紙燈回不來。」 林技師指出高架道下方的側門。「我可以從工具間外面關總閘,但要有人在另一邊壓住門,否則閘門會彈回。等水退至少一小時,裡面沒有乾糧,也沒有備用電池。」 享哥問:「你願意回去操作嗎?」 「要先確認出口和撤退繩。那三個人也得知道我們會怎麼做。」 白手套沒有替他答應。他先叫林技師在門外畫出接線圖,再讓站內廣播通知工具間的人:救援小隊正在查高架廊道,不會從積水通道進入;任何人都可以選擇留在安全室等水退。 工具間裡傳來兩短一長的敲擊。林技師抬起頭。「那是他們的確認訊號,表示聽到了。」 「你確定?」享哥問。 「我在這裡工作十年,知道他們平常怎麼敲。但我不會把這個當成電源已關閉。」 羅盤的指針仍指著林技師。享哥把它放低,轉到另一側,指針隨即偏開。 「它只告訴你這個人可能提供下一步。」輝哥說,「沒告訴你下一步安全。」 「今天連籤詩都比這個直接。」 白手套把絕緣桿交給林技師,自己固定救援繩的一端。另一端沿高架廊道放到安全區,讓工具間的人即使要退回,也不必摸黑找路。 「我去關總閘。」林技師說,「但你們要留一條能回來的繩。」 「會留。」白手套說,「你到側門後先回報,沒有收到確認就不要拉閘。」 享哥把繩結重新檢查一次,手指摸過固定環,確認繩端沒有滑動。上次夜渡救人時,繩子在護欄上磨出尖聲;他不想再用「大概固定好了」這句話賭別人的重量。 第三章 差一拍的閘門高架廊道離地不高,底下卻全是翻滾的積水。每塊金屬踏板都滑,白手套走在最前面,用絕緣桿逐一碰過欄杆和接縫,再讓其他人跟上。 輝哥突然停下來摸器材箱。「線圈不在這裡。」 「你才發現?」享哥問。 「我以為還在撤離桌那一箱。」 白手套看了看遠處的水位牌。「回頭找要走另一條安全路,至少十二分鐘。現在先完成撤離,器材等水位下降再拿。」 輝哥沒辯解。他在臨時紀錄上寫下「中繼線圈未隨撤離物資點交,造成預定測試延後」,簽上自己的名字,再把筆交給白手套確認。 小隊到達側門時,裡面的手動閘卡在半開位置。林技師從門縫看見三名同事已沿著救援繩退到工具間外室,卻還差一扇閘門才能到高架廊道。 「總電源關掉,照明也會斷。」白手套說,「你們先固定,等我回報。」 他用絕緣桿碰過門框,沒有出現火花。林技師報出總閘位置,表示只要閘門不要彈回來,他就能隔著安全板拉下開關。 「我只需要一拍。」林技師說。 享哥的萬丸亮起警告:若閘門回彈,最近的承擔者會被壓向門框。這一次他沒有把手伸進接縫,也沒有叫林技師冒險。他先問清楚:「你要的是一拍固定,不是替你拉閘,對嗎?」 「對。我自己拉總電源。」 白手套確認他們站在乾燥踏板上,才讓享哥靠近外側橫桿。享哥用道袍袖口包住手,將身體抵在門框外緣,不碰裡面的電線。 「準備好了。」林技師說。 享哥壓住橫桿。肩膀的舊痕立刻發熱,像有人把一條緊繃的線拉過皮膚。這不是替誰做決定,只是替對方留出一拍完成自己選擇的時間。 林技師扳下總閘。電流聲停了,照明也一起熄滅。 「先別放。」白手套在黑暗裡說。他用手電筒檢查指示燈,確認總電源已切斷,才叫享哥慢慢退開。 閘門抖了一下,往回彈。享哥手臂整片發麻,白手套握住外側扶手幫他卸力;林技師從另一端拉動鎖扣,門才緩緩合上。 三名夜班人員沿救援繩走出工具間。他們身上都濕透了,沒有人受傷。白手套逐一點名,再把他們交給二樓的值班組。漏電區被封住,南側維修道仍不開放。 輝哥跟著值班員回到器材區找線圈,卻發現撤離桌已經被搬走。他追到另一側的安全點,才在一只空器材箱底找到線圈。外殼濕了一半,接頭上的封口紙泡成一團。 「你找到它了。」享哥說。 「也錯過了原本的安全渡班。」輝哥把線圈裝進防水袋,「我會把延誤費記在自己名下。」 白手套重新安排了一段有護欄、有照明的接駁,沒讓任何人走回積水通道。行程晚了二十分鐘,工具間的人卻都平安到了高處。 第四章 把羅盤修好,不代表把路修好雨勢稍緩後,林技師把受潮的線圈放進乾燥箱。他先檢查接點,沒有通電,只在外殼上貼了新的狀態標籤:「待檢,可能一次低功率發送」。 「能修嗎?」享哥問。 「要拆開看。現在只能說外殼裂了,接收端原本就不完整。你如果拿它測,最多送一次脈衝,不知道對面有沒有收。」 「這個條件聽起來很熟。」 林技師看著他手上的欠路羅盤。閘門回彈時,羅盤外殼撞上欄杆,半側裂開;裡面的指針短了一截,轉動時偶爾卡住。 「我能補外殼,不能校準裡面的東西。」林技師說,「給我半小時。」 他用工具箱裡的金屬薄片和束圈把裂口固定,沒有碰指針。修好後,羅盤不再一轉就卡住,卻仍會偏向最近那個可能提供下一步的人。 「現在它會指出你已經選定、也可能願意提供幫助的人。」林技師說,「它不替你選人,不知道那個人會不會答應,更不知道哪條路安全。」 「它不會告訴我哪一條路能回家?」 「你問的是羅盤,不是路線表。」 「我問兩個都不行嗎?」 「可以問,答案還是不知道。」 白手套把三名值班者的撤離時間、總閘維修單和路線封閉紀錄裝進同一個資料袋。「南側維修道先維持封閉。確認電源、護欄、退路和現場值守後,再討論局部開放。」 「好。」享哥說,「我也不想每次羅盤指到人,就跟著往水裡走。」 「今天你有先問人。」白手套說。 「今天它也沒指水裡的人。」 桌上有一張舊維護表,兩個欄位緊挨在一起:「靈性回聲偏低」和「全區重新校準」。享哥拍下欄位,沒有把它直接當成因果。 「這兩件事有關嗎?」他問。 林技師檢查那張表的日期。「我不知道。那不是我填的,而且兩欄中間還有一整段被撕掉。」 「那我們只記得它們曾經在同一張表上。」 「對。」 線圈經過乾燥後,仍只能送出一次低功率脈衝;那個脈衝不會確認有沒有人收到。羅盤外殼補好了,也沒有多出新路線。白手套沒有解除南側封鎖。 夜班人員平安撤出,漏電被切斷,輝哥的交接疏漏也記進報告。享哥在資料袋封口處簽了名,才收起自己的那份照片。 外面的雨還沒停。工具間的燈已經熄了,這次不是一段假完成播報,而是有人親手切掉了電源。 這已經是今晚能確定的答案。

  • article-享哥宇宙 EP007|夜市神明排班表被換了

    2026/9/27

    享哥宇宙 科幻喜劇 AI故事
    享哥宇宙 EP007|夜市神明排班表被換了

    本篇為「享哥宇宙 Sean Verse」EP007《夜市神明排班表被換了》的連載試讀版。系列仍在創作整理中,後續文字與設定可能繼續修訂。 閱讀完本集後,可回到享哥宇宙專頁瀏覽已收錄篇章。 第一章 每個人都在同一班夜市臨時排班表貼在廟口柱子上,紙面被油煙燻成淡黃。夜巡志工、送香車和三家攤商的補貨時段,全擠在晚上九點二十分那一格。 享哥抵達時,正好有兩輛手推車從巷子兩頭同時進來。前面那台載著玻璃油瓶,後面跟著送香車,車身比巷口的轉角還寬。白手套站在巷口,手臂一抬,先把入口擋住。 「先停。車不能再進。」 後面的人來不及煞車,車輪在濕地上滑了一段。享哥和輝哥各抓住送香車後面的把手,往側邊帶了半步。油瓶碰撞出一陣脆響,沒有碎,前車的志工卻嚇得把推車推上了路緣。 「這張表誰排的?」享哥問。 夜市主辦人拿著一疊貼紙跑過來。「我排的,但三張時段貼紙被換過。」 「誰換的?」 「大家都看過,沒人說是自己。」 輝哥拍胸口。「第二位引導員是我找的。」 「人呢?」 輝哥翻口袋,拿出一張皺掉的名片、早餐收據和一顆不屬於他的螺絲。 「我沒有找到簽收單。」 「那你找到的是一個想法,不是一個人。」 輝哥看著停住的送香車,沒有笑。他把委託單交給主辦人,確認今晚的分流費和臨時補位費由他負責。主辦人先把「人車安全」列為第一條,才讓他簽字。 享哥低頭看排班表。南側窄巷那格寫著「無人值守」,但一張送貨紙上有三個手寫簽名,時間正好落在同一班。 「像南三線的資料。」他說。 白手套正在指揮大家把油瓶車退回寬路。「像,不代表相同。」 「我知道。今天先把車停好,再開始猜。」 送香車輪子卡在路緣上。白手套沒有讓人硬推,而是叫志工先卸下最外側兩箱香,再由兩個人固定車尾,另外兩人把前輪抬正。貨物暫時放在遮雨棚下,送香車才慢慢退回寬路。 主辦人看了一眼被清空的窄巷。「現在大家都塞在外面了。」 「至少沒人被兩台車夾住。」白手套說。 「那我今天的貨怎麼補?」一名攤商問。 白手套把排班表折起來。「我們會分批放行,但先找到誰在現場負責引導。」 第二章 封路的人先救了貨窄巷裡只容一台手推車通過。兩家攤商的補貨箱堆在轉角,志工的巡查路線從另一頭進來,如果照紙上那張表走,三組人會在最窄處相遇。 享哥從主辦人手上借來三張未使用的色卡,沒有再碰原本的排班貼紙。他讓紅卡代表送香車,藍卡代表攤商,黃卡代表夜巡。每組人站在不同等候點,先用空推車試一次。 白手套在轉角設緩衝區。「只放一台。前一台看見出口的人揮手,下一台才能進。」 攤商抱怨這樣會晚到半小時。主辦人想照舊表讓夜巡隊先過,送香車則在旁邊等;結果志工剛轉進巷子,攤商的補貨車也從另一頭被推進來。 白手套立刻把兩邊攔住。「退回去。現在還沒撞上,不代表可以繼續。」 他先讓送香車往寬路倒退,保住車上那籃玻璃油瓶,再請夜巡隊從外側繞行。這個決定讓兩家攤商短時間無法補貨。有人對他喊:「你每次只會封路!」 「這條路現在不安全。」白手套回答,「我先讓人和貨都停下來,再想怎麼分。」 享哥趁大家等候時,去看排班表旁的柱子。原本貼紙撕過三次,下面留著兩種背膠:新貼紙沾著一點豆漿糖,舊貼紙則帶黑色機油,像送香車常擦到的油漬。 他問搬箱子的攤商:「今天誰拿著豆漿站在這裡?」 對方指向巷尾。一名穿深色雨衣的人正在把最後一箱貨推到遮雨棚下,聽見他們的聲音,停了一下,沒有立刻走近。 「是我換的。」她說。 主辦人朝她走去。「你為什麼改時段?」 「原本那個時段被寫成無人值守。明天就要把小巷封掉。幾家攤子靠夜班補貨,走大路要多搬兩趟。我只是把大家真的在場的時間貼回去。」 「你沒有權限改表。」白手套說。 「我知道。我也知道沒人看那張申請單。」她指向公告柱上的一疊紙,「我送過三次,回覆都是『已完成』。可是排班格還是空的。」 享哥看向她。「你想留下現場紀錄,不是要三組人同時進巷。」 她點頭。「我以為他們看到新表,就會知道錯開。」 「表上有時間,沒有寫誰負責把人分開。」 她沒有反駁,只把手上那張被撕掉一半的申請單遞給享哥。上面有送件日期,右下角蓋著「已完成」。沒有承辦人名字,也沒有實際排班結果。 「你願意留在現場簽到嗎?」享哥問。 「可以。但名字不公開給攤商群組。」 「那就只交給主辦人和安全員。」 白手套確認保管範圍後,她才在臨時簽到表上寫下自己的名字。她沒有要求把自己的貼紙恢復原位,只說明自己改過哪幾格。 第三章 把人分開比把表貼正難享哥把窄巷分成三個時段,不試圖一次塞進所有人。先讓空推車走完整段,確認地面沒有積水和凸起;再讓兩名攤商分別推小車進出;最後才安排送香車走較寬的外側路。 「每一組到出口,現場引導員揮手,下一組才走。」他對主辦人說,「如果沒人揮手,就不算完成。」 「要是人忘了揮呢?」 「那就當作沒收到。重新確認。」 輝哥把補位費的數字寫在委託單上。「我本來答應找第二個引導員,但我只有口頭談妥,沒確認到場,也沒把名單交給主辦人。這筆費用我付。」 「你要不要先找他確認?」享哥問。 「我會補問。但不是等他回覆了才認帳。」 輝哥在費用欄簽下自己的名字,將款項轉給主辦人。那張收據不會讓巷子立刻變寬,卻至少沒有把缺人的成本丟給攤商。 小頻在遠端測試台接上三種車輪的短距離聲響。她沒有錄下攤商或志工的對話,只標記輪軸振動的頻率,提醒大家哪一台車已經進入轉角。 「妳聽得出哪台是哪家的嗎?」享哥問。 「我能分出三種輪軸聲,不知道車主是誰,也不會辨認車上的人。」 「很好,今天沒有人需要被分類成輪胎。」 第一次放空車,輪子在一塊翹起的地磚上抖了一下。白手套叫大家停住,先把地磚旁的積水清掉;第二次才順利通過。攤商的兩台推車分開進場,各自把貨搬到轉角外,沒有人被迫倒車穿過另一組人。 送香車走寬路時,仍然得暫停一次,讓夜巡志工從外側回到集合點。白手套站在轉角親自看視線,等志工揮手後才示意送香車通過。 「這樣貨晚了二十分鐘。」攤商說。 「今天先晚二十分鐘。」享哥說,「明天如果排程有人到場,就不用每一台都停這麼久。」 主辦人拿出新的時段回條,只核准南側一小段巷道,下一晚兩個小時、兩名引導員,必須在現場簽到。這不是永久通行,也不代表所有舊路都該打開。 貼卡者在臨時簽到欄留下名字,並註明「原排程無人回覆,擅自換貼時段」。她同意配合下一晚的現場記錄,不同意把名字放進攤商公開群組。主辦人把保密條件一併寫進回條。 第四章 輝哥把費用寫在自己名下夜市散場後,主辦人清點了三張排班卡。被換掉的時段沒有再貼回去;新的回條則寫清楚兩個小時、兩名引導員、每十五分鐘一次現場點名。貼卡者把原申請單交給安全員,沒有把擅自改表說成別人的錯。 輝哥當著主辦人的面付清補位費。白手套把收據的影本交給他,正本留在委託檔案裡。 「你答應的事終於有一張收據。」享哥說。 「我一直都有答應。」 「我說的是有一個人真的到場。」 輝哥看了一眼空下來的巷口,沒有接話。 白手套拿著排班回條到掃描台登記。紙本上有兩名引導員和一名貼卡者的簽名,螢幕卻跳出「無人值守」。他把紙張翻過來重新掃了一次,結果仍然相同。 「這次我親眼看見簽名。」白手套說,「系統紀錄還是顯示沒有人。」 主辦人急著問:「是誰把資料改掉?」 「我不知道。」白手套回答,「我只知道這張紙上有簽名,系統裡沒有。我會分別保存,不先替其中一邊下結論。」 享哥拍下螢幕、紙本和站在旁邊的人。他沒有說這一定是有人故意改表,也沒把「無人值守」直接當成系統故障。 下一晚的人工窗口只有兩個小時。若沒有人到場簽到,就會失效;若有人到場,主辦人會再交一次紙本和掃描結果,讓安全組比對。 「明晚只有兩小時。」白手套把回條交給享哥,「有人到,才算開窗。」 「收到。」 「不要把它當傳送票。」 「我目前的傳送票都很會把我送去別的地方。」 回程時,輝哥把補位收據放進自己胸前口袋,還用手機拍了一張。享哥把那張兩小時回條收進資料袋,確認名字、日期和負責人都看得清楚。 夜市最後一盞燈熄掉時,排班表上的「無人值守」仍沒被刪除。紙本明明有簽名,系統卻說沒有人。 這一次,他至少知道明晚誰會站在巷口。

  • article-享哥宇宙 EP006|救命渡班不載回頭客

    2026/9/27

    享哥宇宙 科幻喜劇 AI故事
    享哥宇宙 EP006|救命渡班不載回頭客

    本篇為「享哥宇宙 Sean Verse」EP006《救命渡班不載回頭客》的連載試讀版。系列仍在創作整理中,後續文字與設定可能繼續修訂。 閱讀完本集後,可回到享哥宇宙專頁瀏覽已收錄篇章。 第一章 船沒有走,帳單會走河岸夜渡站的渡船正繞著一段短短的纜線打轉。 船每次靠近東岸,船頭的感應燈就亮綠色;船身剛偏過去,又響起一聲「已返航」,整艘船便慢慢退回西岸。船上的兩名乘客抓緊扶手,沒有受傷,臉色卻像剛坐完一圈沒有出口的遊樂設施。 享哥看了一眼站牌。「這就是南三線的舊維修點?」 輝哥把紙條拿出來,對著站牌比了一次。「地址沒寫錯。」 「你確定?」 「這次有兩份備份。」 「那我暫時相信地址。」 雨水把站台沖得發亮。白手套先把兩岸乘客引到安全線後,叫值班員清出救援通道。東岸控制室的燈還亮著,玻璃後有個人影一動不動。 「林技師還在手動控制台旁邊。」值班員說,「他把總閘扳到手動,現在回不來。船的回程感應一直把他那邊當成出發點。」 白手套看了一眼水位標尺。「先封閉兩岸,禁止下水、禁止跳船。水深已經超過救援線。」 「他是為了把乘客送回來才留在那邊。」享哥說。 「我知道。」白手套說,「所以先想辦法讓他安全回來,不是再送一個人過去。」 渡船還在纜線上打轉,雨勢每分鐘都比上一分鐘更大。站方開出一張救援委託:把乘客安置到高處、協助林技師撤回,並取回手動控制紀錄,完成後支付八百元。享哥看過委託範圍,在工作人員欄簽下名字。 「我接。想拿報酬,也想確認舊接收器現在到底怎麼運作。」 白手套看了他一眼。「兩件事不能混在一起。救援成功不等於收到訊號。」 「我會分開記。」 「你知道有可能什麼都收不到?」 「我現在連能不能送出去都不知道。」 他們先把乘客帶到有遮雨棚的平台。那兩人被引導員分別點名、確認沒有受傷,才交給另一艘靠岸的安全渡船。享哥一直想回頭看東岸,白手套提醒他先確認每個人都完成交接。 乘客離開時,其中一人回頭問:「那個技師呢?」 「我們會把他帶回來。」享哥說。 白手套看了他一眼,沒有糾正他,但把委託單上的「救援成功」用筆圈起來,旁邊補上「待確認」。 第二章 一次借殼,送錯岸站務員找出南三線的舊圖,透過值班室的有線電話聯絡許伯。許伯只肯核對自己親眼見過的標記:舊浮標發報器在西岸纜柱旁,東岸有一組手動頻段,控制台的接地開關在玻璃室外側。 「這張圖的路線已停用。」許伯在電話裡說,「我不知道現在的設備還能不能用,也不替以前那次事故作結論。」 「我們只用你確認的位置。」享哥說,「不會把它當成安全證明。」 他們沿著有欄杆的站台走到西岸纜柱。舊浮標發報器的外殼裂了一道縫,手動槓桿還能轉。旁邊的接收器每隔十幾秒就響一聲短促的蜂鳴。每次蜂鳴後,渡船都往西岸退一段。 「它在收到自己的回覆?」享哥問。 「也可能是自動播放上一次的返航碼。」白手套說,「先不要碰。」 輝哥拿出一張設備單,上面只有「發送測試」四個字,沒有方向、頻段或接收端。享哥才把萬丸靠近發報器,白光便沿著金屬外殼爬到手動槓桿上。 「等一下,我還沒說要開——」輝哥伸手去拉他。 萬丸已經讀取了享哥剛才那句「送一個訊號去控制台」。 三秒內,槓桿自己跳了一格。東岸控制室亮起紅燈,渡船立刻轉向,卻不是往東岸靠,而是加速繞回西岸。纜線繃緊,船上兩名引導員扶住乘客,救援艇也被水浪推離岸邊。 「你送錯方向了!」輝哥喊。 「我只說送去控制台。」 「你沒說哪一岸!」 「我現在知道方向也要講。」 白手套按下岸邊急停。救援艇的馬達停了,渡船被纜線拉在中段,船身撞了一下浮標。乘客都已經離船,沒有人落水;舊發報器卻冒出一縷白煙,外殼更裂開一截。 萬丸縮回享哥手心,亮出一行字:「借殼連線:已結束。資料方向:未指定。」 享哥看著熄掉的指示燈。「我拿八百塊來做方向示範。」 「委託費還沒付。」白手套說。 「你提醒得很準時。」 「我也要記錄設備損壞。」 享哥沒有辯解。他在事故欄簽下自己的名字,寫明操作內容沒有指定方向,發報器受損。輝哥站在旁邊,想替他補一句「設備本來就老舊」,最後把那句話吞回去。 「等查完再寫原因。」享哥說。 「好。」 雨打在安全帽上,像有人不停敲一面很大的鐵皮。東岸控制室的紅燈又閃了一次。 第三章 先救人,再問誰收到小頻從夜市的測試台接進一條有線讀取端。她先確認現場沒有人聲資料接入,只看兩個感應器的時間戳和震動強度。 「每次渡船被拉回西岸前,接收器都播同一段短回執。」她說,「間隔固定,波形也固定,應該是舊紀錄重播。」 「那我們剛才送出去的,有沒有人收到?」享哥問。 「這些資料不能回答。它只能說現在這個接收器會重播,不能證明東岸那端收到什麼。」 東岸控制室的手動閘往回滑了一寸。林技師從玻璃後比出十根手指,又指向一旁的接地開關。白手套用探照燈回覆,先叫他別移動,再把岸邊情況說明給他看。 「他能撐多久?」享哥問。 「他比我們清楚。」白手套說,「先讓他選要不要離開控制台。」 有線通話接上後,林技師的聲音斷斷續續傳來。他說手動閘卡在半開位置,若不先鎖住,纜線就會再次收緊;但他一離開,東岸的輔助電源可能重新啟動。 享哥問:「你能先關總閘再走嗎?」 「開關在門外。我得跨過一段積水,不能確定地板下面有沒有漏電。」 「那我們把你拉回來?」 「要先讓纜線鬆一點。你們有救援繩嗎?」 白手套確認繩索額定重量,把一端繫在岸邊固定環,再由值班員用絕緣桿把浮圈送到東岸的低平台。享哥把繩端交給林技師,逐個檢查結和扣環。第一次拉緊時,繩子磨過欄杆,差點從固定環上滑出去。 「那個結要重打。」白手套說。 享哥蹲下來重新繫,讓繩頭多繞一圈,再把尾端反扣。這次白手套親自拉了兩次,才示意可以使用。 林技師看著燈號,報出他需要的時間:「我能把手動閘卡進固定槽,再走到門邊關總電源。大概十秒。」 「水位?」白手套問。 「不超過小腿,但地板可能帶電。」 「你不用現在決定。我們可以等救援艇從南側靠岸。」 林技師看著玻璃外逐漸升高的水線。「那三個乘客已經走了嗎?」 「都到安全平台,有人接手。」享哥答。 「那我去關電源。要是十秒內沒成功,我就退回控制室。」 白手套再次檢查纜線張力。「我們給你十秒和一條撤退繩。你自己喊停。」 林技師把手動閘推進固定槽,等指示燈轉成黃色,才走出控制室。他在門邊停了一下,先用絕緣桿碰地面,再伸手去扳總開關。燈滅的瞬間,渡船的馬達也停了,纜線終於不再繃緊。 「現在。」他說。 享哥和輝哥一同拉繩。雨水浸透手套,繩子在護欄上磨出刺耳的聲音。林技師在最後兩步踩滑,白手套抓住他背後的救援帶,享哥則用肩膀頂住固定環,直到人被拖上岸。 渡船還停在纜線中段。乘客已由另一艘船送走,沒有人受傷。林技師坐進值班室,喝了幾口熱水,手才不再發抖。 第四章 有發出,不代表有回音白手套先問林技師是否要休息,再問他願意交出哪些控制紀錄。林技師只提供手動閘的切換時間和總電源關閉時間,沒有把全部維修資料交給評鑑組。 「其餘資料等我回去核對再給。」他說。 白手套把空白封套放到桌上。「可以。這一份只記錄你現在同意提供的部分。」 站務主管按委託單結算八百元救援費。救援繩與浮標的修理費由夜渡站另行支付,設備操作損壞則記在享哥的事故欄,不從林技師的薪資扣除。 林技師打開一只上鎖的器材櫃,取出一個外殼裂開的中繼線圈。它有一個短脈衝發送端,接收端已斷開,側面貼著待送修的標籤。 「這件列在另外一張物資轉讓單。」他說,「它能發送,不能收訊。你若要帶走測試,修復工時由輝文會付,所有權和歸還日期要寫清楚。」 輝哥拿出兩支筆和合約,逐項填好費用、使用範圍和歸還日期。享哥看完後簽名。 「你這次有帶筆。」 「兩支。」 「人類真的在進步。」 小頻把線圈接上封閉測試架的虛擬負載,只量接點、電阻和限流狀態,沒有啟動發送。記錄上添了一行:「尚未送出;唯一低功率脈衝保留;接收端已斷開。」 享哥看著那行字。「它甚至沒有寫『已送出』。」 「因為我們沒有發送。」小頻說,「等你真的要測時,才能知道另一端有沒有設備、有人收不收得到。」 白手套把救援報告推到他面前。「乘客已交接,林技師已撤回,電源已隔離。那是今天的結案。回家測試另外申請。」 享哥在報告上簽名。「這裡的人真的很會把我的期待寫成但書。」 「這是工作範圍。」白手套說。 雨勢稍歇時,渡船被拖回岸邊。那段纜線有一處被拉白,浮標外殼裂著,修理費已由站方開單。享哥把線圈包進防水布,沒有立刻試著朝主宇宙發送。 阿策的訊息仍停在原處。今天確實有人被救回來,也確實有一段短訊號離開了發送端;至於那條訊號最後去了哪裡,還沒有任何人能回答。