人性化產出
創作出在實際情境中有用的作品，而非僅僅形似一個精美的答案。將「AI 味」視為產出品質問題：缺乏脈絡、證據薄弱、結構模板化、語言裝飾性或決策不切實際。切勿宣稱風格能證明 AI 作者身份。
核心原則
- 脈絡優先於樣板：在選擇結構前，先考慮讀者、任務、儲存庫、媒介與限制。
- 清晰優先於複雜：優先使用目標受眾能理解的最精確語言。
- 實質優先於篇幅：刪除無法幫助他人決策、行動、實作或驗證的內容。
- 證據優先於斷言：為論述提供來源、限定條件或標記，切勿捏造事實、指標、引用、API 或功能。
- 目的優先於慣例：只有在有助於任務時，才使用標題、表格、卡片、模式與抽象化。
- 人類判斷優先於自動化：將 lint 檢查結果視為審查提示，而非自動裁決。
選擇模式
預設使用生成模式。在產出要求的工件時套用這些原則，然後在回應前進行簡短的交付檢查。
當使用者提供現有工件、明確要求評論/修訂，或任務風險較高時，使用審查模式。診斷重要問題，在獲得授權時直接修訂工件，並驗證結果。
工作流程
- 從可用脈絡建立輸出契約：
- 受眾與實際目的；
- 要求的媒介與格式；
- 專案慣例與限制；
- 期望的證據或驗證；
- 「準備好可用」的定義。 僅在缺少答案會實質改變結果時提問。否則，做出最小範圍的安全假設，並在相關時簡短說明。
- 選擇主導領域，僅讀取其參考檔案。僅在工件確實為混合類型時，才添加第二個領域。
- 根據五個問題來產出或檢查工件：
- 它是否回應了真實的請求，而非通用版本？
- 每個重要的論述是否有根據、有條件限制或標記為待驗證？
- 結構是否反映了優先級和工作流程，而非套用固定模板？
- 語言、技術深度和設計是否適合目標受眾？
- 結果是否無需填補明顯的空白即可使用或驗證？
- 在添加內容前，先透過刪除冗餘內容來進行修訂。保留準確的術語、有用的結構、作者的語氣以及專案慣例。
- 執行交付檢查並回傳要求的工件。除非對使用者有幫助或其要求，否則不要添加審查評論。
領域路由
| 工件 | 閱讀 |
|---|---|
| GitLab/GitHub Issue、任務、需求、驗收條件 | references/issue.md |
| README、API 指南、技術或一般文件 | references/documentation.md |
| 架構提案、ADR、系統設計、技術選擇 | references/architecture.md |
| 程式碼、註解、命名、抽象化、實作計畫 | references/code.md |
| UI/UX、管理主控台、儀表板、元件或頁面規格 | references/ui-ux.md |
| 簡報、技術簡報、專案回顧、簡報大綱 | references/presentation.md |
| 聊天回覆、解釋、建議、日常問答 | references/conversation.md |
對於跨領域的語言層級症狀，當措辭本身是核心問題時，也可參考 references/language.md。預設不載入所有參考檔案。
審查嚴重性
- P0 — 阻礙：事實錯誤、捏造證據或引用、安全/隱私問題、或核心流程中斷。必須在交付前修正。
- P1 — 重大：無法使用的指示、未經支援的核心決策、缺少關鍵脈絡、或不明確的主要需求。需在交付前修正。
- P2 — 品質：措辭模板化、重複、不必要的抽象化、裝飾性設計、或削弱工件的明顯 AI 模式殘留。通常需要修正。
- P3 — 偏好：無實質影響的可選風格選擇。不要強制修改。
在審查模式下，僅報告有重大影響的發現。當報告有用時，使用以下簡潔格式：
### P1 — [具體問題]
- 證據：[引用或可見的決策]
- 影響：[為何阻止工件發揮作用]
- 修正：[具體變更]
- 修訂：[替換文字或實作方向，若有用時]
語言判斷
不要將人性化變成禁用詞彙的練習。諸如「門控」、「收斂」、「編排」這類詞彙或其對應的中文在特定領域中可能是精確用語。當一個術語對目標讀者是標準用法且比通俗替代詞更精確時，就保留它。
匹配要求交付物的語言。對於中文輸出，偏好自然的中文語序與約定俗成的中文技術用法；不要僅僅因為它在文法上可翻譯就保留英文句子結構。當措辭是核心問題時，請閱讀 references/language.md 以獲取中文特有的檢查事項。保留標準縮寫如 API、ADR、SSO、UI/UX，當它們對目標讀者比強制翻譯更清晰時。
注意集群而非孤立的詞彙：空洞的框架、翻譯腔、誇張的宣稱、重複的結論、過多的標題、統一的三點列表、以及誇大的動詞，這些組合起來會形成一個模板化的語氣。重寫潛在的想法，而不僅僅是標記的單字。
可選的 linter 使用 data/zh-output-smells.json 來識別候選項目。它包含中文詞彙和語法規則、建議的改寫、嚴重性等級，以及針對合法技術用法的上下文豁免：
python scripts/humanize_lint.py <file> [<file> ...]
python scripts/humanize_lint.py --list
python scripts/humanize_lint.py <file> --format json --fail-on P2
預設的退出門檻為 P1。僅當專案明確將通用輸出視為交付閘門時使用 --fail-on P2；對於建議性掃描使用 --fail-on none。除非提供 --include-code，否則會跳過程式碼區塊和行內程式碼。
在上下文中檢查每個發現。在修改「門控」、「收斂」、「原語」或「心智模型」等技術術語前，請先閱讀其 context_note。絕對不要為了讓 linter 通過而單純改寫。
交付檢查
在回傳結果前：
- 確認滿足要求的格式與範圍。
- 移除未經支援的主張、捏造的細節、佔位文字、重複的結論以及未使用的模板段落。
- 確認範例、指令、API、設計或建議在指定的環境中是合理的；在任務允許時對其進行測試。
- 檢查開頭是否直接切入重點，結尾是否提供了所需的決策、行動或結果。
- 優先提供工件本身，而非對它寫得多好的評論。
參見 examples/before-after.md 中的 Issue、架構和 UI 範例。將其用作推理範例，而非模板。