prose 是做什麼的？
兩種模式。在執行任何操作前，請先偵測正確的模式。
模式偵測
草稿模式 — 使用者有主題、簡報或大綱，並希望撰寫新內容。 審閱模式 — 使用者有現有文本，並希望改進、人性化或評分。
若有歧義：詢問 — 「您希望我撰寫新內容，還是審閱/改寫您已有的內容？」 如果使用者沒有回應，預設為草稿模式。
聲音校準
在草稿或改寫之前，如果使用者尚未提供聲音範例，請要求提供。 對於短格式目標（即時訊息、200 字以下的電子郵件）：除非使用者已提供範例，否則跳過聲音校準。
「請分享 1–3 段您自己的、最能代表您風格的作品。我會比對您的 句子節奏、詞彙選擇和結構習慣。」
分析範例中的：
- 句子長度傾向（簡潔 / 分析型 / 混合型）
- 開頭方式（主張優先、故事優先、數據優先、脈絡優先）
- 標點習慣（括號、冒號、分號）
- 反覆出現的短語或口頭禪
- 結尾方式（原則、挑戰、開放式問題、行動）
- 從不使用的詞彙
保留個人檔案。 分析範例後，提供儲存結果的選項，以便未來的工作階段跳過重新校準：填入 references/voice-profile-template.md 並將其寫入技能資料夾內的 references/voice-profile.md（如果資料夾為唯讀，則輸出完整的個人檔案供使用者儲存）。如果 references/voice-profile.md 已存在，請在草稿或改寫前完整讀取它——它會覆蓋預設慣例（破折號容忍度、引號風格、慣用語、語域）。對於「也從這段文字學習」：將添加日期記錄附加到現有個人檔案中；衝突以較新的範例為準。個人檔案永遠不能凌駕於事實紀律、可及性或「絕不」規則之上。
如果沒有範例且沒有儲存的個人檔案：使用預設聲音繼續 — 請參閱 references/drafting-core.md 的「預設聲音」章節。對於部落格、散文、評論或個人寫作，另請參閱 references/personality-and-soul.md — 乾淨的預設聲音若缺少它，仍可能顯得沒有靈魂。如果文本將以使用者名義發布，請提及未經校準的輸出帶有通用的預設聲音，並提供校準選項 — 每個對話一次，之後便不再提出。
草稿模式
第零階段 — 先理解再寫作
在草稿前詢問：
- 讀者在閱讀後需要做什麼或感受什麼？（決定媒介和受眾契合度）
- 什麼才能真正讓讀者感到驚訝——他們自認為已經知道但實際上不完整的部分是什麼？
- 這個文本的唯一任務是什麼——告知、說服、指導、娛樂還是轉換？
- 什麼語域符合上下文——正式、隨意、技術、對話性——並且它會保持穩定嗎？
- 主線 — 一個具體的案例、事例或後果，能夠承載真正的分量
如果是任務導向：答案或下一步行動放在最前面。 如果是長篇形式：在草稿前選定主線和一個具體的錨點。
在草稿前，詢問：什麼是能夠承載這篇文章的一個具體事例或後果？如果你無法說出它，表示你還沒有準備好進行草稿。
在起草任何超過 200 字的內容之前，必須閱讀：
→ references/drafting-core.md — 核心規則與媒介特定模式
對於文件或創意目標，在草稿前另請閱讀該渠道的改寫規則——兩者都會暫停在其他地方適用的預設值：
→ references/channel-rules.md 的「文件」章節 /「創意」章節
在草稿期間不要載入 references/ai-patterns-universal.md — 它僅供審閱使用。
第一階段 — 草稿
根據實際上下文來寫作，而不是抽象的「好文章」理想。
主動原則：
- 每個實質段落至少包含一個具體的錨點（專有名詞、特定數字、直接引語、具名決策、可查證的細節）。對於部落格、文章和社群媒體。對於即時訊息和短電子郵件：每則訊息一個錨點就足夠。
- 沒有模糊主張：「許多」、「各種」、「廣泛影響」、「有意義的變革」無法通過錨點測試
- 使用平實的詞語；在正確的詞語出現時重複使用它；優先使用動詞而非名詞化
- 保持語域穩定；格式與媒介相符
第二階段 — 修正
必須：在草稿後執行必要的檢查。
→ references/required-checks.md
如果 Shell 可用，也在草稿上執行確定性掃描器——反機器人套件適用於新的寫作，不僅是審閱：
python3 scripts/slop-scan.py --channel <medium> draft.md
此技能中的所有腳本和參考路徑都是相對於技能目錄，而非工作目錄。以插件形式安裝時，兩者很少相同：請根據載入此 SKILL.md 的目錄來解析 scripts/slop-scan.py。將「找不到檔案」視為需要修復一次的路徑問題，而不是「沒有 Shell」——預設回退到手動層會無聲地跳過整個確定性檢查。
無條件修復垃圾內容。在更改每個短語標記之前，根據誤報規則驗證它（被標記的詞語可能只是正確的詞語）。結構註釋與必要檢查 5 使用相同的判斷標準。
如果在必要檢查後，作品感覺仍然不對勁（僅限較長的作品）：
→ references/long-form-diagnostics.md
當修改範例有幫助時：
→ references/examples.md
審閱/人性化模式
在審閱/人性化模式期間不要載入 references/drafting-core.md — 它僅供草稿使用。
第零步 — 自動偵測內容類型
在執行任何檢查前，先分類渠道。在審閱報告頂部說明偵測結果。
電子郵件 — 具有：主旨行 / 問候語公式（Hi Name, Dear Name）/ 明確請求 + 結尾結構 社群媒體 — 具有：全篇每行一句 / 主題標籤 / 結尾有互動呼籲 / 無標題且少於 3,000 字元 即時訊息 — 具有：@提及 / 頻道引用 / 隨意語氣 / 少於 500 字元 / 無問候或結尾 文件 — 具有：編號程序 / 命令式動詞步驟 / 程式碼區塊、CLI 命令或設定鍵 / API、參數或選項表格 / 無第一人稱敘述 創意 — 具有：帶有引號標點的對話 / 場景、詩節或劇本結構 / 帶有具名角色的敘述 / 使用換行製造節奏而非列表結構 部落格文章 — 具有：標題 / 3,000+ 字元的結構化散文 / 多個發展完整的段落
在檢查部落格之前，先檢查文件和創意。兩者都有標題和發展完整的段落，因此一本手冊或一個場景也會符合部落格的訊號，而部落格對兩者來說都是錯誤的預設值。
如果有一個渠道清楚匹配：說明偵測結果並繼續。 如果有歧義（訊號衝突或無訊號觸發）：詢問 — 「這是什麼格式？部落格文章、社群媒體、電子郵件、即時訊息、文件還是創意？」在得到回答之前不要繼續。
第一步 — AI 模式掃描
先進行確定性檢查。 如果 Shell 可用，將文本儲存到檔案並執行：
python3 scripts/slop-scan.py --channel <detected> file.md
渠道名稱對應到標記值：部落格文章 → blog，社群媒體 → social，電子郵件 → email，即時訊息 → im，文件 → docs，創意 → creative。每個渠道都會抑制其媒介合法違反的規則，因此傳遞錯誤的渠道會同時產生誤報和遺漏。
掃描器報告機械性標記（垃圾內容、公式化短語、排版問題）和結構指標（句子單調性、統一段落、統一自信度、格言預算、類比修辭、編號段落、創造的概念標籤、逐字重複），輸出穩定且可重複。傳遞 --allow <rule-id> 來允許聲音個人檔案或媒介合法允許的任何項目。沒有 Shell：手動套用 references/formula-watchlist.md 作為機械層。
其次進行判斷性檢查。 必須閱讀——先閱讀通用標記：
→ references/ai-patterns-universal.md
然後載入特定渠道的標記：
→ references/ai-patterns-channels.md
將通用標記套用到所有內容。僅針對偵測到的類型套用渠道特定標記。 列出每個標記項目——掃描器命中與判斷標記——附上確切引文及其位置。
第二步 — 對抗驗證
第一步中的每個標記在進入報告之前都必須通過抗辯。針對每個標記，為其是誤報提出最有力的論證，使用 ai-patterns-universal.md 中的「不要標記什麼」規則：
- 這個短語是否在引文、標題、專有名稱，或是正在被討論而非使用的範例中？
- 它是否在這裡是正確的詞語，只出現一次，且周圍沒有其他標記叢集？
- 它是否是媒介慣例（文件中的結構、電子郵件中的問候語）或由聲音個人檔案明確允許？
- 這個「結構性」標記是否實際上符合此類型（規格、操作手冊、參考頁）的正確形狀？
每個標記的裁決：已確認（抗辯失敗）或已駁回（一行原因）。只有已確認的標記會繼續。垃圾內容命中（聊天文物、佔位符、追蹤片段）永遠是已確認的——沒有合法用途。
此步驟的存在是為了保護真正的散文：過度編輯原本沒問題的文本與遺漏標記同樣是失敗。
第三步 — 原創性檢查
如果內容符合以下情況，請標記：
- 任何有搜尋引擎的人都能寫出來（沒有贏得的權威性、沒有特定經驗）
- 沒有任何第一手經驗、客戶故事或具體證據
- 兩次提出相同觀點但沒有增加深度
- 回收業界框架（「X 的未來是 Y」）
- 缺少「只有我能寫出這個」的因素
社群媒體額外規定：標記偽裝成經驗分享的產品推廣；帶有吉祥物式結論的個人故事。
第四步 — 評分
根據渠道閱讀評分維度的必要文件：
→ references/channel-rules.md
為每個分數提供一句話的說明理由。 如果 AI 相似度低但實質維度也低——領域可信度（部落格/社群媒體）、清晰度（電子郵件/即時訊息）、任務完成度（文件）或克制力（創意）——請明確標記。內容乾淨但空洞。
第五步 — 結構化審閱報告
關於報告結構的必要閱讀：
→ references/review-report-template.md
僅報告已確認的標記；用一行說明被駁回標記的數量。
第六步 — 改寫
首先選擇編輯範圍（如果使用者沒有說明，請自行選擇；如果重要的話，說出你選擇了哪個）：
- 自由編輯（「人性化這個」的預設值）——空泛的短語會被刪除，而不是改寫；長度可能明顯縮短。
- 謹慎編輯（文本必須填補某個位置：客戶文件、固定格式）——結構保留；長度維持在原作的 80–110% 之間。
- 最小編輯（僅在明確要求時）——僅觸碰明確的 AI 結構。
通用改寫規則：
- 永遠不要添加原文中沒有的想法；永遠不要刪除實質內容
- 將每個被標記的 AI 短語替換為自然語言
- 變化句子長度：混合簡潔的短句和較長的分析性句子
- 將通用的開頭替換為具體的鉤子（故事、數據點、反主流主張）
- 將總結性的結論替換為挑戰、原則或開放式問題
- 打破統一的段落節奏：有些短，有些長
- 如果缺少具體範例：留下
[從您的經驗中添加具體範例]— 永遠不要虛構 - 編輯不是事實查核：文本不支持的主張不一定是錯誤的——作者可能擁有文本之外的數據。將措辭軟化到文本能承載的程度，或者標記公開版本需要證據。不要將該主張當作未經證實而靜默刪除。
規則 3–6 的渠道例外。 這四條是散文節奏規則，有兩個渠道不希望使用它們：
- 文件 — 不要變化句子長度、打破段落節奏、用鉤子替換開頭，或將結尾摘要變成開放式問題。統一的形狀是讓程序可遵循的關鍵，而以挑釁結尾的規格是失敗的。規則 1、2、7 和 8 仍然適用。
- 創意 — 規則 5 反轉：說明作品含義的結尾句子正是標記，因此直接刪除它，而不是用原則或挑戰替換。規則 3 和 6 由作者決定，而非你。
對於部落格、散文、評論或個人寫作（非百科全書、技術、法律或參考內容）：
必須閱讀 → references/personality-and-soul.md — 移除 AI 模式會產生乾淨的散文；這部分是讓它聽起來像某個人的關鍵。
必須閱讀渠道特定的改寫規則：
→ references/channel-rules.md
消除循環。 單次改寫不是最終狀態。迭代直到文本同時通過確定性檢查和對抗檢查，最多 3 輪：
- 改寫 —— 套用已確認的標記和上述規則。
- 重新掃描 —— 對改寫後的版本執行
scripts/slop-scan.py（相同的--allow集合）。任何垃圾內容 = 立即修復。任何新的短語命中 = 修復或證明其合理性。 - 起訴 —— 轉換立場：為改寫後的版本仍然是 AI 生成提出最有力的論證。特別檢查
references/ai-patterns-universal.md第 5 部分中的二階標記——清理過程往往會產生它們：統一的自信、每個段落都有格言式結尾、「那不是 X。那是 Y。」、沒有鬆弛之處、表演性的脆弱感（對作者來說毫無成本的承認）、以及代替你剛剛刪除的鉤子的製造懸念。每個用一行列出證據。 - 如果起訴成立，則進行修復並從第 2 步重複。如果不成立，或在 3 輪之後，停止。
退出標準：掃描器報告 0 個垃圾內容；其餘掃描器標記每個都有一行理由（媒介慣例或聲音個人檔案）；起訴者無法在文本中建立一個令人信服的 AI 生成假設。
如果在此之後文本仍然感覺不對勁：
→ references/long-form-diagnostics.md
→ references/examples.md