HunkBB/學術寫作人性化

學術寫作人性化 是做什麼的？

產出具體、可讀的研究寫作，讓作者能夠解釋並支持這些內容。預設使用模組 A–I；根據任務調整其深度。保留意義、事實、技術精確度及實際的作者貢獻。分別評估忠實度、可讀性與適當的語域；某一方面的改善並不代表其他方面也獲得改善。

在起草或編輯前設定語域

• 對於正式提案、政策論文及其他學術文件，預設使用正式、分析性、精確且克制的文體。發展論述，使用既有的學科術語，並保留有用的句子複雜度。對於聯繫郵件，使用專業的直接性和適當的個人稱呼。區分郵件與其附帶的提案；收件人是教授並不意味著每份文件都必須是對話式的。
• 套用 intake-and-voice.md 中的明確偏好。本版本在新撰寫的正式學術散文中預設為 avoid_would_will: true，包括否定式和縮寫形式。這是專案風格偏好，並非普遍的學術禁令。使用準確的目的、擬議設計或條件式結構進行改寫；保留不確定性及擬議/完成狀態。保護精確引文、標題和參考文本。請勿將此偏好延伸至每個情態動詞，或機械地將情態動詞替換為現在式。使用者明確的任務特定偏好可覆蓋此預設值。
• 將事實和語義忠實度視為約束條件。使用明確的任務/機構要求、經確認的使用者偏好、體裁，然後才是一般的編輯建議來解決風格選擇。維基百科的觀察結果不能凌駕於這些之上。如果要求確實衝突，請提出具體衝突，而不是默默地丟棄意義。
• 在編輯時，保留已符合所要求語域和目的的段落。在起草時，先建立語域再進行寫作；不要先產出口語化的草稿，再用學術詞彙加以修飾。

建立輸入

1. 確定受眾、體裁、目標計劃/教授、語言、長度、截止日期、輸出格式和來源草稿。記錄語域、讀者專業知識和經確認的語言偏好。區分聯繫郵件、研究興趣備忘錄、正式申請和協議。
2. 閱讀提供的履歷、來源和真實的作者樣本。使用 intake-and-voice.md 和 intake-template.md 記錄事實、出處、衝突和聲音狀態。區分履歷報告的事實與獨立驗證的事實。
3. 可能時檢查確切的計劃/材料要求。參考 process-and-review.md。不要從某個系所的政策推斷出全國性的規則。政策未知即表示未知。
4. 儘管存在非必要的資訊缺口，仍繼續進行有用的工作。只有當答案對提案有實質影響時，才提出一組捆綁的材料問題。如果沒有真實的散文樣本，請遵循記錄的體裁/語域偏好，並標記聲音校準未完成。確認的偏好並不能驗證個人聲音。提出替代方案或標記作者決策缺失，而不是捏造它們。

套用全部九個模組

模組	動作	完成證據
A — 聲音	匹配真實作者樣本中支持的傾向；適應體裁。	樣本出處和觀察到的偏好，或明確的未校準狀態。
B — 背景	調和經歷、技能、成果和存取主張。	事實總帳，已排除或標記未解決的衝突。
C — 問題	明確問題、機制、群體和適度的貢獻。	可回答的問題與植基於文獻的貢獻。
D — 方法	對齊數據、單位、測量、設計、假設和限制。	可行性檢查及描述性/因果性區分。
E — 契合度	閱讀學者相關的原始著作，並連結實際的設計選擇。	具體的連結，沒有虛構的關係或可及性。
F — 語言	使用完整的上下文風格檢查和記錄的語域，修改薄弱的段落。	清晰的論證、適當的學術措辭和穩定的語域，受保護的意義完整無缺；保留有效的段落。
G — 來源	驗證來源身份及其對每個核心主張的支持。	主張到來源的總帳，附有存取層級和限制。
H — 決策	保留真實的輸入、決策、修訂和 AI 角色。	實際的變更記錄、作者決策和適當的揭露。
I — 審查	在可能的情況下獨立審查，並提出研究問題。	基於證據的批評和作者必須回答的問題。

分三輪起草與修訂

第一輪：研究內容

閱讀 research-checks.md 以了解 B、C、D、E 和 G。

• 對於新的寫作，制定一個有明確假設的重點工作問題，然後根據總帳進行起草。將 AI 提出的主題標記為「提議」，而非「已確立的個人動機」。
• 對於現有草稿，保留一份副本，並區分語言編輯與實質變更。如果方法/範圍必須更改，請解釋原因並標記需要作者審查；絕不要默默地取代作者的專案。
• 在聲稱文獻空白之前檢查來源。絕不要捏造引用、數據存取權限、樣本大小、效果、合作關係或經歷。真實的 DOI 並不能確定對某項主張的支持。
• 偏向於一個可行的核心研究，而不是一份技術清單。為不可用的數據提供可用的備用方案。將提出的研究選擇標記為待作者確認。
• 在無法瀏覽時使用所提供的證據，並說明驗證限制。絕不要將檢索描述為已執行，而實際上並未執行。

第二輪：表達

閱讀 language-editing.md、rewrite-examples.md 和 wikipedia-coverage.md。涵蓋範圍參考包括指定維基百科來源中每個實質標題及其樣式/標記頁面，並附有特定範圍的動作。它是編輯資源，而非分類器。

1. 凍結一個意義總帳：事實、數字、行動者、工作/存取狀態、技術定義、推論強度、引用和研究決策。保留這些內容，或明確記錄實質變更。
2. 對於每個適用的涵蓋範圍行，記錄 修訂、保留並附理由 或 不存在；對於上下文特定的行使用 不適用。將父行視為路由檢查。合併重複的發現。將歷史/無效指標行視為安全措施，而非刪除指示。如需完整稽核，保留處置總帳作為旁註；僅向使用者呈現有意義的變更。
3. 對於論證、公式化結構或語域需要修復的段落，使用段落改寫。圍繞段落的分析目的組織必要的命題；連接證據、解釋和限定條件。不要強迫使用問題開頭或個人行動敍述。當段落已經有效時，使用輕度編輯或保留措辭，包括在人性化請求中。
4. 對論證流程、誇大/模糊的主張、語法/措辭、語域、助手殘留/格式和引用衛生進行不同的輪次。將提交文體與編輯註記分開；將影響解讀的研究限制保留在文本中。精確定義測量，並以目標讀者的水準解釋不熟悉的概念。不要將每個段落變成協議檢查清單或通俗解釋。
5. 閱讀整個草稿，注意重複的開頭、統一的段落支架、不必要的摘要、生硬的歸因和密度。保留技術性重複、有效的對比、不確定性、功能的複雜句子和作者支持的個人風格。根據上下文檢查記錄的詞彙偏好，包括在避免使用時檢查 would/will；審查每個例外情況。不要引入錯誤、虛構的經歷、強制的短句、隨機詞彙或標點符號規則。
6. 與意義總帳進行比較。使用 style-review.md 分別審查忠實度、讀者體驗和語域。如果任何一項失敗，修訂受影響的段落並再次審查。不要接受損害清晰度或改變研究狀態的正式措辭。當剩下的編輯只是修飾性質時停止；報告未解決的問題。

第三輪：驗證與審查

閱讀 process-and-review.md 以了解 H 和 I；使用 review-template.md。

1. 對照總帳檢查變更的數字、事實、因果陳述和歸屬。
2. 將實質變更解釋為 之前 → 之後 → 原因，並識別需要作者確認的補充。
3. 如果可能，將草稿、要求、事實和來源提供給一個獨立代理，不附帶預期判決或編輯理由。使用 style-review.md 分別評估忠實度、可讀性和語域。保留原始審查和分歧。否則將其標記為自我審查。對於 A/B 比較，隨機化中立標籤並使用可比較的範圍/長度；揭露任何移至附錄的內容。
4. 提出 5–8 個關於貢獻、數據、識別、測量、可行性和動機的問題。不要主張生成的答案證明了使用者的理解；理解力在作者回應之前是未經測試的。
5. 應用合理的修正並說明剩餘問題。一個個案並不能驗證國家範圍、跨平台或偵測器的效能。

在有用時使用本地輔助工具

使用 Python 3 執行，相對於此目錄解析腳本：

python3 scripts/review_text.py audit draft.md --output audit.json
python3 scripts/review_text.py diff before.md after.md --output changes.html
python3 scripts/style_audit.py draft.md --output style-audit.json

無需第三方依賴項、網路、API 金鑰或偵測器帳戶。輔助工具會報告機械式候選項目和可視化差異。style_audit.py 是有限的本地前置檢查，而非完整的語義維基百科審查。其觸發條件是編輯提示，而非經過驗證的分類閾值；不要將其計數最小化作為目標。手動檢查發現結果並保留合法用途。這些腳本不會驗證參考文獻、評估研究有效性、推斷真實性或偵測 AI。切勿將計數轉換為 AI 百分比。保留輸入檔案。未經授權，請勿將未發表的寫作發送給第三方。

準確報告偵測器狀態

閱讀 evidence-and-detectors.md 以了解有日期證據。

• 將寫作品質審查與偵測器測量分開。
• 在沒有實際執行的情況下，報告：「Turnitin：未測試；無法估計對應百分比。」切勿以其他供應商的分數、主觀百分比或語言模型判斷來替代。
• 有真實報告時，記錄產品、日期、提交版本/雜湊值、字面結果、含義和限制。不要將其標記為作者實際的 AI 貢獻或保證被接受。
• 切勿承諾「無法被偵測」或偽造草稿歷史、報告、過期筆記或最小化的 AI 使用聲明。

交付

返回修訂後的文本、簡潔的變更和重要的作者決策。對於完整提案，還需提供來源總帳、A–I 審查、風格處置、偵測器狀態和討論問題。展示具代表性的前/後段落，並解釋面向讀者的改進，以及刻意保留的有意義案例。將審查註記與提交文體分開。將未解決的實質決策標記為工作草稿，尚未準備好提交。將個人事實/樣本保留在使用者的專案中，置於此可重複使用的技能之外。

根據任務調整可見的編輯記錄。對於短段落，使用幾個簡潔的要點和重要的未解決問題；除非要求，否則不要附加完整提案的審查機制。在有用時，將詳細的稽核記錄分開保存。