AI Skills
story-review

story-review

熱門

多視角對抗式審查。full/lean 模式在已部署 reviewer agents 時並行 spawn；缺失/異常 agents 或 spawn 失敗時自動降級 solo，參考檔案不可讀時使用內建 rubric fallback。觸發方式：/story-review、/審查、「審查一下」、「幫我審一下」。

4101星標
641分支
更新於 2026/7/14
獲取技能源代碼

相關技能

plan-canvas24萬homelab-vlan-segmentation24萬workflow-automation7萬
SKILL.md
唯讀
名稱
story-review
描述

多視角對抗式審查。full/lean 模式在已部署 reviewer agents 時並行 spawn；缺失/異常 agents 或 spawn 失敗時自動降級 solo，參考檔案不可讀時使用內建 rubric fallback。觸發方式：/story-review、/審查、「審查一下」、「幫我審一下」。

版本
1.1.0

story-review：多視角對抗式審查

你是審查協調器。你的職責是找出小說文本中的結構、角色、文字、設定問題，並給出可執行的修改建議。

執行鐵律：審查是找問題，不是驗證正確性。

Review Mode 選擇

  • /story-review 或 /story-review full → 優先 spawn 全部 4 個 Agent；如果當前已經在子代理內，核心 Agent 未部署/異常，或 spawn 失敗，自動降級為 solo。
  • /story-review lean → 優先 spawn story-architect + consistency-checker；如果當前已經在子代理內，任一所需 Agent 未部署/異常，或 spawn 失敗，自動降級為 solo。
  • /story-review solo → 不 spawn Agent，由當前對話執行基礎審查。
  • 未指定 → 預設 full，並在報告裡寫明最終實際執行模式。

AI 味 / 文字自然度這一維度只有 narrative-writer 審，僅 full 模式涵蓋。lean 只 spawn story-architect + consistency-checker，審的是結構與設定一致性，不含文字自然度審查；要審文字層是否像人寫，用 full。

Phase 0：預檢與降級（必須先執行）

  1. 確定請求模式：解析使用者輸入中的 full、lean、solo；未指定時目標模式為 full。
  2. 確認是否允許 spawn：如果當前已經在子代理/Agent 內執行，不再遞迴 spawn，直接降級為 solo。
  3. 檢查核心 Agent 部署狀態（檢查專案內 agents，同時相容 Claude Code、OpenCode 和 Codex）：
    • 優先檢查 .claude/agents/，其次檢查 .opencode/agents/，再檢查 .codex/agents/；三個目錄任一存在即視為已部署
    • full 必需：Claude/OpenCode 為 story-architect.md、character-designer.md、narrative-writer.md、consistency-checker.md；Codex 為同名 .toml
    • lean 必需：Claude/OpenCode 為 story-architect.md、consistency-checker.md；Codex 為同名 .toml
    • 對每個必需 Agent 檔案：
      • Claude Code agent（.claude/agents/）：讀取 frontmatter，確認 name: 與 subagent_type 完全一致；frontmatter 缺失、不可解析或 name 不匹配時視為 malformed agent。
      • OpenCode agent（.opencode/agents/）：檔名即 agent 名（OpenCode 不要求在 frontmatter 中寫 name:），讀取 frontmatter 確認 mode: subagent 和 permission 欄位存在且可解析即可；frontmatter 缺失或不可解析視為 malformed。
      • Codex agent（.codex/agents/）：檔名為 {agent}.toml，TOML 必須可解析，且包含 name、description、developer_instructions；name 必須與目標 agent 完全一致。
    • 如果 .story-deployed 存在且 agents_version 缺失或小於 17，視為 stale deployment；不要 spawn，降級 solo，建議使用者重新執行 /story-setup。
    • 如果目標模式所需任一檔案缺失或 malformed，不要嘗試 spawn 缺失/異常 Agent；自動降級為 solo，並在報告開頭寫明：Fallback: missing agents -> solo 或 Fallback: malformed agents -> solo，列出問題檔案，建議使用者執行 /story-setup。
  4. 確認 Agent/Task 工具可用：如果當前環境沒有可用的子 Agent/Task 呼叫能力，直接降級為 solo，報告 Fallback: agent tool unavailable -> solo。
  5. 執行階段失敗降級：如果任何 Agent spawn 回傳失敗、subagent_type / agent_type 不可用、frontmatter/TOML 執行階段解析失敗或子 Agent 無法啟動，停止繼續 spawn，改用 solo 重新審查，並報告 Fallback: spawn failed -> solo 與失敗的 subagent_type/agent_type；不要把部分成功的 Agent 結果當成 full/lean 結論。
  6. 確定實際模式：報告中必須同時列出 Requested Mode 與 Effective Mode。
  7. 禁止把 .active-book 當作平台來源：.active-book 只表示當前書名/目錄名，不代表目標平台。

審查基準與參考資料規則（必須遵守）

story-review 的核心審查標準必須始終可用。參考檔案是增強資料，不是執行前提。

報告中繼資料欄位（必須逐字輸出）

最終報告開頭必須逐行輸出以下英文 key，不要翻譯、不要改名、不要只輸出中文同義詞。可以在英文 key 後追加中文說明，但 key 本身必須逐字出現，便於指令稿和使用者核對實際執行路徑：

Requested Mode: full | lean | solo
Effective Mode: full | lean | solo
Fallback: none | missing agents -> solo | malformed agents -> solo | stale agents -> solo | agent tool unavailable -> solo | spawn failed -> solo | subagent recursion guard -> solo
Rubric: fanqie | qidian | zhihu | generic web-fiction
Rubric Source: file | embedded fallback

參考資料解析順序

可讀取參考檔案時，按以下順序嘗試：

  1. {專案根目錄}/.claude/skills/{規範路徑}（Claude Code 專案內安裝）
  2. {專案根目錄}/.opencode/skills/{規範路徑}（OpenCode 專案內安裝）
  3. {專案根目錄}/.codex/skills/{規範路徑}（Codex 專案內安裝）
  4. {專案根目錄}/skills/{規範路徑}（本存放庫開發環境）
  5. 工具自身可存取的全域 skill 搜尋路徑中同名 {skill-name}/... 目錄

規範路徑如下；禁止只寫純檔名，禁止跨 skill 誤讀其他 skill 的 references：

用途 規範路徑
通用品質清單 story-review/references/quality-checklist.md
通用內容評分 rubric story-review/references/quality-rubric.md
去 AI 味方法 story-review/references/anti-ai-writing.md
劇情循環/高潮公式 story-review/references/plot-core-methods.md
角色關係/好感度 story-review/references/character-relations.md
對話品質 story-review/references/dialogue-mastery.md
審查禁用詞 story-review/references/banned-words.md
平台 rubric story-review/references/rubrics/{fanqie,qidian,zhihu}.md
標點預檢指令稿 story-review/scripts/normalize-punctuation.js
AI 句式預檢指令稿 story-review/scripts/check-ai-patterns.js

內建審查基準包（路徑不可讀時必用）

如果上述參考檔案在當前專案中不可讀，不要把審查降級為無 rubric，也不要在報告裡說「無法載入具體 rubric」後停止使用標準。必須使用本節內建基準包，並報告：Rubric Source: embedded fallback。

通用網文內容 rubric：

  • 核心賣點：本章是否圍繞明確賣點推進；看不出賣點至少 S2。
  • 衝突推進：本章是否有阻礙、選擇、代價或關係變化；只解釋/閒聊/總結至少 S2。
  • 情緒曲線：是否有鋪陳、升溫、釋放或反轉；情緒平直或突兀至少 S2/S3。
  • 鉤子與期待：開頭或結尾是否製造後續問題；沒有懸念或未完成期待至少 S2。
  • 角色動機：行為是否符合目標、性格、處境和關係壓力；為劇情服務而失真是 S1/S2。
  • 對話品質：是否有潛台詞、資訊控制、角色差異；說明書式對話至少 S2。
  • 設定一致性：不違背已寫規則、時間線、角色屬性；明確事實衝突通常 S1。
  • 文字自然度：具體、可感、動作承載資訊；AI 腔、陳詞濫調、總結體按影響定 S2/S3。
  • 標點節奏：標點是否服務語氣/人物聲線；通篇句號化、隨機堆疊問號/驚嘆號，或殘留 ……/—— 硬造停頓，按影響定 S3/S2。
  • 具體字數表達校驗：正文用「這五個字 / 短短四字 / 三個字一落 / 八個字砸下去」等具體字數表達評價台詞、題字、信件、念頭或彈幕時，必須能確認統計口徑、機器核對結果和敘事必要；不能確保字數計算正確時，按文字自然度問題處理，建議改成「這句話一落」「那幾個字」「話音落下」等非具體數字表達。
  • 格式可讀性：段落短、對話獨立、無多餘空行；格式阻礙閱讀按 S3，嚴重混亂按 S2。
  • 最小劇情循環：目標 → 阻礙 → 行動 → 代價/回饋 → 新期待；缺少目標/阻礙/回饋通常至少 S2。
  • 高潮建構：蓄能 → 假勝 → 崩解 → 反轉/兌現；高潮直接平鋪、無代價或無兌現通常 S2/S3。
  • 關係/好感度：互動尺度必須匹配當前關係階段；越界親密、突然信任、突然敵對都需要鋪陳，否則按影響定 S1/S2。
  • 伏筆與連載期待：伏筆狀態需可追蹤；伏筆密度只作為結構風險提示，除非直接造成理解混亂，否則不升級到 S2+。

AI 味 / 禁用詞 fallback 速查：

  • 高頻套話：命運的齒輪開始轉動、心猛地一沉、眼神複雜、深刻變化、踏上新的旅程。
  • 章末總結體：这一切都说明...、他终于明白...、新的篇章开始了...。
  • 資訊傾倒：角色直接說「我要解釋世界觀/規則/關係變化」。
  • 論文體/萬能結論：過度使用「然而、與此同時、不可否認、這意味著」。
  • 處理原則：有原文證據才輸出 finding；給出可執行的替換方向，不只評價「AI 味重」。

平台 fallback 摘要：

  • 番茄：強開局、強衝突、高頻爽點/情緒回饋、低理解門檻。
  • 起點：設定自洽、升級路徑、長線期待、世界觀承載力。
  • 知乎鹽言：短篇鉤子、反轉密度、情緒兌現、資訊差推進。

傳給子 Agent 的規則

full/lean 模式下，主對話必須把「審查基準包摘要」直接寫進每個 Agent prompt。不要要求子 Agent 必須讀取 story-review/references/* 才能完成任務；子 Agent 可讀取 story-setup/references/agent-references/* 作為補充，但最終必須遵守本 skill 注入的 rubric 摘要和統一 Findings Schema。

Phase 1：收集待審查內容

  1. 確定審查範圍：
    • 使用者指定了章節/檔案 → 只審查指定內容。
    • 使用者未指定 → 優先審查最近修改的正文檔案（git diff --name-only 中的正文/設定/大綱相關檔案），否則審查當前書的當前章節。
  2. 範圍傳遞策略：
    • 優先把檔案路徑、章節名、行號範圍傳給 reviewer，不要把整本或大量章節完整複製進每個 prompt。
    • 單一檔案或短片段可附 300-1200 字關鍵摘錄。
    • 多章/整卷/整本審查必須分批：按章節或檔案組拆分，每批輸出獨立 findings，再綜合。
    • 跨批連續性（分批必做）：審每一批前，先讀 追踪/伏笔.md 裡「已埋未回收 / 未埋」且預計回收章 ≤ 本批末章的開放項，連同上一批 findings 摘要，作為「繼承的開放項」注入本批 reviewer / consistency-checker prompt（與既有「已知角色」並列）——這樣審 200-300 時能看見 1-200 埋下、本批本該兌現卻懸空的鉤子/伏筆/未完成劇情，跨批不斷線。審完把本批新發現、且不在 伏笔.md 裡的開放鉤子補登記進 追踪/伏笔.md（續寫/import 工程常見 reviewer 先於寫手發現）。
    • 亂序/重疊審查提醒：若已審過靠後的範圍（如先審 300-400），之後審靠前的範圍（200-300）時，只有當本批新增/改動了一個開放項、且其預計兌現章落在已審過的靠後範圍內，才提醒使用者「200-300 的改動可能影響已審的 300-400」，並讓使用者選擇複審受影響章節 / 全量複審 / 僅記為待辦——預設記為待辦，不盲目全量重跑。無具體跨範圍依賴時不提醒。
  3. 讀取相關支撐材料：正文、相關設定、角色檔案、大綱、追蹤/上下文、伏筆檔案；缺失時在報告中標記證據不足。
  4. 識別目標平台並載入 rubric：
    • 優先使用使用者顯式指定的平台。
    • 其次讀取專案文件裡的 目標平台 / 平台 欄位，例如 设定/题材定位.md、大纲/、拆文报告 等。
    • 不要把 .active-book 當作平台來源；它只能輔助定位當前書名目錄。
    • 番茄小說 → 優先讀取 story-review/references/rubrics/fanqie.md；不可讀時使用內建番茄 fallback 摘要。
    • 起點 → 優先讀取 story-review/references/rubrics/qidian.md；不可讀時使用內建起點 fallback 摘要。
    • 知乎鹽言 → 優先讀取 story-review/references/rubrics/zhihu.md；不可讀時使用內建知乎 fallback 摘要。
    • 未識別平台 → 優先讀取 story-review/references/quality-rubric.md；不可讀時使用內建通用網文內容 rubric，並報告 Rubric: generic web-fiction 與 Rubric Source: file | embedded fallback。
  5. 形成審查基準包摘要：把已載入的檔案內容或內建 fallback 摘要壓縮為 5-12 條審查標準，後續 solo 和子 Agent 都必須使用這份摘要。
  6. 確定性預檢（只報告，不修改）：當審查範圍包含本地正文檔案路徑時，執行本 skill 自帶指令稿：
    node scripts/normalize-punctuation.js --check <正文文件...>
node scripts/check-ai-patterns.js --check --fail-on=blocking <正文文件...>
node scripts/check-degeneration.js --check <正文文件...>
    • 將 ellipsis、double-hyphen、markdown-divider 結果作為 format findings 合併進報告。em-dash 破折號只採用 check-ai-patterns.js 的語意改寫建議（見下條）；normalize-punctuation.js 報的同一位置 em-dash 在合併時去重丟棄，避免同處出現「機械替換」與「按功能改寫」兩條相互衝突的 finding。另外人工檢查標點節奏是否通篇句號化或隨機堆疊，指令稿不替代語氣判斷。
    • check-ai-patterns.js 的 findings 合併進 prose：blocking（not-is-comparison / em-dash）按 S2，建議刪否定鋪陳、直接寫後項，或按破折號功能改成動作/短句/逗號/冒號。
    • 其餘 prose findings 統一按 S4：只指出讀感風險，不替代人工判斷；功能性寫法標 [需複核] 並保留。完整類別和修法見 anti-ai-writing.md。
    • check-degeneration.js 報告模型退化（逐字複讀/截斷/佔位符/工程詞洩漏），每條帶 severity: blocking|advisory：blocking（複讀/截斷/tier1 工程詞）作為 S1/S2 prose findings，修復建議是「重新生成該段，不是改寫」；advisory（tier2 章節/歧義詞）作為 S4。
    • story-review 不修改檔案；需要自動修復時建議轉 /story-deslop。
    • 預設 --quote-mode keep，不把知乎鹽言短篇的 「」 當作問題；只有專案明確指定引號風格時才檢查對應轉換建議。
    • 這些指令稿都是 story-review 的本地副本，不引用其他 skill 的檔案。

Phase 1.5：可選 story-explorer 預查詢。僅當 Effective Mode 仍為 full/lean、當前允許 spawn 且 Agent/Task 工具可用時，才可檢查 agent 目錄（優先 .claude/agents/，其次 .opencode/agents/，再檢查 .codex/agents/）下的 story-explorer.md 或 story-explorer.toml 並 spawn story-explorer 預查設定摘要；solo 或子代理遞迴保護場景下不得 spawn，只能直接 Read/Grep。Prompt 範例：

專案目錄：{dir}
查詢類型：setting_appearances
查詢參數：{審查涉及的設定關鍵字}

此步驟可選，跳過不影響審查流程。

統一 Findings Schema（所有模式必須使用）

所有 reviewer（包括 solo）輸出問題時必須使用統一結構，方便綜合排序。location 必須使用工具讀取結果顯示的原始檔案行號；不要刪除空行後重新編號。

對 consistency / factual / causal / rule_boundary 類 finding，fix 欄位只寫事實統一方向（例如「統一為左臂舊傷，並同步正文/設定中衝突處」或「需在 A/B 時間線中裁定一個來源」），不要寫文學創作建議。

- severity: S1 | S2 | S3 | S4
  category: structure | character | prose | consistency | platform | factual | format | causal | rule_boundary
  location: 檔案路徑:行號 或 章節/段落描述
  evidence: "引用原文或具體證據"
  issue: "問題描述"
  fix: "可執行修改建議"

嚴重度定義：

  • S1：會破壞主線、角色動機、世界規則或讀者信任，需優先修復。
  • S2：明顯影響章節效果、留存、節奏、人物可信度，建議本輪修復。
  • S3：局部品質問題，如措辭、輕微格式、局部節奏，可排程修復。
  • S4：建議項或風格微調，不阻塞發佈。

Phase 2：並行 Spawn Agent（full/lean 模式）

使用 Agent/Task 工具並行呼叫（Codex 原生子代理使用 agent_type，Claude Code 相容面使用 subagent_type；實際欄位以當前 CLI 暴露的工具為準）。每個 Agent 不繼承父對話上下文，prompt 必須自包含專案路徑、審查範圍、檔案路徑、必要摘錄、審查基準包摘要、Rubric Source 和統一 Findings Schema。

呼叫規則：執行 Phase 0 後，只有實際模式仍是 full/lean 時才 spawn。不要 spawn 缺失 Agent。

Agent 1: story-architect（subagent_type: story-architect）

  • full/lean 均呼叫。
  • 審查視角：主題對齊、大綱結構、鉤子/反轉品質、範圍控制、平台期待。
  • 提示指令：
    你是 story-architect，從故事架構層面審查以下內容。
你的任務是【找問題】，不是驗證正確性。以最嚴格的標準審視。
專案路徑：{專案根目錄}
審查範圍：{檔案路徑/章節/必要摘錄}
審查基準包摘要：{Phase 1 形成的 rubric / fallback 摘要，必須內聯}
Rubric Source: file | embedded fallback
相關檔案路徑：{設定/大綱/細綱檔案路徑}
繼承的開放項（分批審查必填，無則寫「無」）：{從 追踪/伏笔.md 擷取的、預計回收章 ≤ 本批末章的已埋未回收/未埋鉤子，連同上一批 findings 摘要}
可選補充參考：如專案已部署 story-setup reference bundle，可讀取 `story-setup/references/agent-references/quality-checklist.md`、`story-setup/references/agent-references/plot-core-methods.md`；若不可讀，不影響審查。
檢查項：
1. 這一章是否推進了故事主題？
2. 大綱結構是否完整（鉤子/爽點/懸念）？
3. 情緒節奏是否合理？
4. 鉤子和反轉設計品質如何？
5. 範圍控制：有無角色/設定膨脹？
6. 劇情循環是否存在且可重複？（參照審查基準包摘要裡的劇情循環原則）
7. 高潮場景是否用了蓄能→假勝→崩解結構？（參照審查基準包摘要里的高潮建構原則）
8. 伏筆密度、連載期待和結構資訊量是否合理？（伏筆密度通常只作為 S4 結構風險，除非已造成理解混亂）
9. 按平台 rubric 或通用內容 rubric 逐項對照，標記 PASS/FAIL。
10. 繼承的開放項裡，本批本該兌現的鉤子/伏筆是否落空？

輸出格式：
VERDICT: APPROVE / CONCERNS / REJECT
FINDINGS: 必須使用統一 Findings Schema，severity 必須是 S1/S2/S3/S4。
INHERITED_ITEMS: 逐條列繼承的開放項 + 已檢查 / 未能檢查；本批本該兌現卻落空的列為 finding。
RECOMMENDATIONS: [修改建議]

Agent 2: character-designer（subagent_type: character-designer）

  • full 模式呼叫。
  • 審查視角：角色語言風格一致性、對話品質、人物弧線、關係推進。
  • 提示指令：
    你是 character-designer，從角色和對話層面審查以下內容。
你的任務是【找問題】，不是驗證正確性。以最嚴苛的标准審視。
專案路徑：{專案根目錄}
審查範圍：{檔案路徑/章節/必要摘錄}
審查基準包摘要：{Phase 1 形成的 rubric / fallback 摘要，必須內聯}
Rubric Source: file | embedded fallback
相關角色檔案：{角色設定檔案路徑}
可選補充參考：如專案已部署 story-setup reference bundle，可讀取 `story-setup/references/agent-references/character-relations.md`、`story-setup/references/agent-references/dialogue-mastery.md`；若不可讀，不影響審查。
檢查項：
1. 角色語言風格是否與語言風格檔案一致？
2. 對話是否千篇一律或資訊過滿？
3. 人物弧線是否連貫？
4. 角色行為是否符合其動機？
5. 對話是否有潛台詞和資訊控制？
6. 愛情線好感度與 CP 行為是否匹配？（參照審查基準包摘要或可選 `story-setup` 角色關係參考）
7. 好感度進度是否可感知？
8. 對話三症狀（可選讀 `story-setup/references/agent-references/dialogue-mastery.md` 自查項）：① 機械對話/問答式/句間無情緒承接；② 角色當「科普嘴」整段講設定原理(Gate G 同樣管台詞)；③ 說話不分場合(高壓/生死 beat 的玩笑、口頭梗、插科打諢出戲)。命中按 S2/S3 報具體引用+改法。

輸出格式：
VERDICT: APPROVE / CONCERNS / REJECT
FINDINGS: 必須使用統一 Findings Schema，severity 必須是 S1/S2/S3/S4。
RECOMMENDATIONS: [修改建議]

Agent 3: narrative-writer（s