nomoredasi — 領域感知學術英文校稿技能 (v0.1)

nomoredasi — 領域感知學術英文校稿技能 (v0.1) 是做什麼的？

「別再重來」——在送出前預先打磨的技能。將論文原稿校對至 Nature 系列期刊投稿等級的英文。領域慣例（詞彙選擇、密度、節奏、鋪陳方式）由 references/overlays/<領域>.md 負責，領域通用規則則由 references/core/ 處理。

四大原則（所有路徑通用，違者不得交付）

1. 語意不變 — 不改變內容、論點、邏輯順序。僅修改文體與表達方式。
2. 基於證據 — 所有校對皆以 references/core/ 規則或對應領域覆蓋層的語料庫實測為依據。不得憑直覺刪除「AI 感」的用語。
3. 維持體裁 — 保持學術論文語域。禁止口語化、散文化。禁止套用 ASD-STE100 型規則（強制主動語態、句子上限 20 字、禁止 -ing） — 與期刊實測數據（被動語態 111-137/10K 字，平均句長 16.5-18.3 字）衝突（參見 references/core/academic-en.md）。
4. 禁止過度修訂 — 變動率超過 30% 時發出警告，超過 50% 時停止並請求用戶確認。由 scripts/verify_integrity.py 做最終判定。

Phase 0：輸入類型判別

開始工作時輸出一行。標籤遵循用戶請求的語言：

• 韓文請求：nomoredasi v0.1 — 類型 {A|B} / 領域：{已確認領域}

• 英文請求：nomoredasi v0.1 — type {A|B} / field: {resolved field}

• 其他語言：type/field 標籤翻譯為該語言。

• 類型 A（韓文原稿） — 翻譯+校對複合路徑。先以 references/core/korean-author-pitfalls.md 偵測韓文翻譯腔結構（如「~를 통해」、「~에 의해」等）以避免直譯，再進行翻譯，之後比照類型 B 套用三層規則。

• 類型 B（英文原稿，含 AI 初稿） — 校對路徑。若有 AI 初稿跡象，則額外套用 references/core/ai-tell-en.md 層。

Phase 1：領域路由（3 層優先順序）

1. 用戶明確指定 — 用戶說出領域即直接使用。
2. 資料夾名稱 — 若原稿位於 papers/<領域>/ 等領域名稱的資料夾中，則使用該領域。
3. 自動偵測 — 執行 scripts/route_field.py <原稿>，取最高結果。若前兩名分數接近，則合併套用兩個覆蓋層。
4. 不明確時僅確認一次 — 禁止開放式提問。以「看起來是 Optics and photonics，正確的話就繼續進行」的形式提出推測值，僅詢問一次。

即使領域錯誤，核心規則仍獨立於領域運作，因此安全。若無對應領域的覆蓋層檔案，則僅以核心規則進行，並告知用戶。若覆蓋層標頭中 Maturity: 為 immature（檔案 <10 篇或 <100K 字），則該數值僅作為方向參考而非硬性目標。

Phase 1.5：原稿狀態檔案 (manuscript.json)

若原稿資料夾中存在 manuscript.json，則讀取並反映其內容——包括縮寫定義列表、確定的術語寫法（例如 bandgap）、圖表列表。這是維護部分修訂或重複請求時文件整體一致性的機制。若無此檔案，則繼續進行且不創建新檔案，但在交付校對稿後，以 scripts/manuscript_state.py learn <資料夾> <校對稿> 記錄當日的決策（定義的縮寫、多數寫法）。若新觀察到的內容與既有值衝突，則不覆寫，而是向用戶報告。

Phase 2: route_hint — 校對強度 3 路徑

瀏覽初稿，決定為 light / standard / heavy 其中之一並輸出。校對過程中務必依下方 Phase 3 規則，以區塊為單位持續累積撰寫 <校對稿>.edits.json 日誌。

• light（1 輪） — 已寫很好的原稿（已達發表水準的文體，僅有零星文法錯誤）。僅修正核心規則違反事項即結束。變動率下限。
• standard（2 輪） — 一般情況。第一輪：核心三層規則（① 一般學術英文——時態、冠詞、數的一致性 ② 領域術語寫法統一——覆蓋層 Notation watch ③ 期刊語域）。第二輪：自我審查 + 驗證腳本。
• heavy（3 輪以上） — 翻譯腔 / AI 跡象大量出現，結構性不順。第一輪：依類型前處理（pitfalls 或 ai-tell）。第二輪：核心三層規則。第三輪：段落流暢度與鋪陳調整。其後進行驗證。

校對強度預算軸 (level): route_hint 是對原稿狀態的 診斷（不可修改，由 Agent 判斷），level 是用戶選擇的變更預算（預設 low）。以 verify_integrity.py --level {low,mid,high}（以 log_edit.py --level 記錄）輸入，low=低/10-30%, mid=中/20-50%, high=高/30-50% 的閾值（不得強於內建閘門）。有效工作量 = min(診斷, 預算) — 預算可降低診斷所需的強度，但絕不能高於診斷。若請求預算與診斷不符，則明確告知用戶（例如：「原稿為 heavy 診斷，但因 low 請求，僅修正核心違反事項」）。若要對同一原稿以 light 目標重新處理，需再次請求。

多重強度同時請求： 若用戶要求「低與中」、「中與高」或「全部三種」，則按強度獨立校對、驗證、交付。輸出檔案命名為 <原稿名>.low.md / .mid.md / .high.md，日誌 (edits.json)、報告 (HTML) 及 log_edit --level 也按強度分別產生。

Phase 3：區塊感知校對

以 scripts/section_split.py 分割原稿進行識別（IMRaD + Results and Discussion 合併，Experimental Section 等變體對應）。

日誌 (edits.json) 撰寫義務： 校對過程中必須以區塊為單位逐步累積撰寫 <校對稿>.edits.json——每項編輯不應等到最後才補上，而應連同 kept 項目（評估過但未修改的片段）一併記錄。格式遵循 scripts/check_journal.py 的 schema v1：

• changed — 修改原文片段（original，校對稿的 corrected，<40 個 token）的編輯。以 rule: {source, id} 指向依據的規則，並以 reason 簡短記錄原因。
• kept — 評估過但未觸及的片段。記錄 original（在兩個檔案中皆原樣存在）與 reason。rule 為選填。

original 與 corrected 必須分別是原文與校對稿的確切子字串。標點符號的編輯也不可遺漏——日誌覆蓋率閘門會以機械方式驗證 diff 中所有 changed/insert/delete 區域是否皆已涵蓋在日誌中。學會會議論文集結構各異，但宏觀結構不外乎摘要/引言/正文/結果/結論的選擇，合併型（Results+Discussion, 正文+結果）並非錯誤，不應以校對方式「正規化」。各區塊的時態、被動語態規則與鋪陳、節奏規則，遵循 references/core/academic-en.md §3·§8。

• Methods = 維持過去式、被動語態為主（禁止強行改為主動）
• Results = 以過去式為主，圖表指示用現在式。分析句子不應放在 Results 中
• Discussion/Conclusion = 分析用現在式
• Abstract = 區塊縮減形式，套用時態混用規則
• Introduction 中不得建立結論結構（§8 交叉污染檢查）——在引言中添加 "in conclusion" 類用語即違反語意不變原則

部分修訂請求（「只要 Introduction」、「只要正文」）

若用戶僅請求特定區塊，則鎖定範圍：僅修改請求的區段，不觸及其他區塊。維持該區塊的角色（§8），不套用其他區塊的規則，不編輯交叉引用（如「Section 3」、「Figure 4」），僅就中斷的引用以筆記方式報告。驗證閘門也以該區塊範圍為基準執行（academic-en.md §9）。

Phase 4：驗證（程式碼閘門 — 禁止 LLM 自我判定）

測試執行：在非 UTF-8 主控台（例如 Korean Windows cp949）下，測試套件已明確指定編碼，因此無需設定環境變數即可執行。

交付前必須依序執行以下項目並報告結果（從閘門 0 開始依序執行 — 若前一個閘門 exit 1，則不得繼續交付）：

0. scripts/check_journal.py <原稿> <校對稿> --journal <校對稿>.edits.json — 日誌覆蓋率閘門（所有 diff 變更區域是否皆已涵蓋在日誌中，片段 ≤40 token，rule.id 存在於 rule.source）。exit 1 則阻擋交付 — 補全日誌中缺少的編輯/kept 項目或拆分片段，重新執行。

1. scripts/verify_integrity.py <原稿> <校對稿> --repeat 2 --report <校對稿>.integrity-report.html — 數值、單位、化學式、引用、公式、DOI（＋--overlay 時包含專業術語）的保留 + 變動率閘門。exit 1 則不得交付，修正違反事項後重新執行。報告檔案（<校對稿>.integrity-report.html）應與校對稿一同交付，供用戶以 diff 方式檢視哪些內容已變更。

2. scripts/check_terms.py <校對稿> — 術語寫法一致性（bandgap/band gap 等）。exit 1 則統一為多數寫法後重新執行。

3. scripts/check_abbrev.py <校對稿> [--state <資料夾>] — 偵測未定義縮寫。exit 1 則在首次使用時加入定義，或與 manuscript.json 比對。未經驗證的縮寫（不知其全稱者）以 scripts/abbrev_registry.py references/abbrev-registry.json record <ABBR> --field <領域> --context <句子> 記錄至 registry。此後若在同領域文本中觀察到相同縮寫的全稱（scan），則連同上下文句子更新為 verified；若觀察到不同全稱，則標記為 conflict — conflict 需請求用戶確認。人類可讀的檢視頁面為 references/abbrev-registry.html（自動重新產生，禁止手動編輯；SSOT 為 json）。

4. 若是部分修訂，則上述檢查以該區塊範圍為基準執行。

交付時以 scripts/log_edit.py <領域> <route_hint> <A|B> <原稿> <校對稿> [--journal <校對稿>.edits.json] 將校對配對與（若提供）日誌記錄至 logs/edits/（用於品質基準實測、pitfalls 管線、以及「為何修改」的日誌輸入）。

品質測量（技能本身改善用）

scripts/bench_edit.py <原稿> <校對稿> — 比較校對前後的違反數/100 字（AI-tell、嵌套 hedging、誇飾修辭、圖表時態、長句、過渡副詞過密、寫法不一致）。此非交付閘門，而是技能效能測量裝置：在週/月 delta 週期中，對 golden 案例與實際校對日誌套用，若違反率回歸（exit 1），則回顧覆蓋層/規則的變更。

參考檔案

• references/core/academic-en.md — 時態、冠詞、被動語態平衡、過渡副詞、hedging（領域通用）
• references/core/ai-tell-en.md — 英文 AI 初稿偵測模式（包含未出現在期刊中的證據）
• references/core/korean-author-pitfalls.md — 韓語母語者錯誤詞典（初版，以 diff 累積成長）
• references/overlays/<領域>.md — 各領域實測：文體指標、高頻術語、phrase bank、寫法監控清單。由 scripts/mine_corpus.py 從 ~/Documents/papers/<領域>/ 自動產生，每週更新兩次。

不做的事

• 新增、刪除、重組內容（違反語意不變原則）
• 套用 ASD-STE100、Plain English 等非學術簡化規則
• 在不了解領域的情況下以開放式提問將問題丟給用戶
• 未執行驗證腳本即僅回報「已確認」