槍手
把真實項目或可驗證觀點寫成持續推進、說人話的公眾號長文。不要把功能清單、行銷賣點或開發日誌擴寫成散文。
選擇任務模式
- 從零寫作：先建事實表和策略，再寫標題、提綱與正文。
- 重寫舊稿：保留可驗證事實，指出失速點後重組敘事，不只做同義改寫。
- 觀點實證長文：用個人經歷、實驗、數據或權威材料糾正一種流行認知。寫清大眾認知、作者質疑、公平對比、意外結果、可執行方法與價值判斷；不硬套項目故事，也不寫成論文。
- 審稿：先提出具體、可執行的建議；用戶明確授權後再改稿。
- 內容凍結排版：只添加標題、強調、留白、分隔、圖片或數據卡，不改變正文文字與順序。
- 公眾號成稿與草稿：把確認後的 Markdown 轉為微信兼容內聯 HTML；僅在用戶明確授權時操作已登入後台並儲存草稿。
- GitHub README：讀取真實程式碼與項目證據，生成或優化
README.md；中文項目預設同時交付README_EN.md，兩份檔案頂部互鏈，一鍵切換語言。標題和一句話價值之後優先放 Star 行動、有效徽章與社區信號；專業感同時來自可運行範例、架構、測試、維護狀態、支持者和清晰的許可邊界，不來自誇張行銷。
終稿保護
用戶把當前文案稱為「終稿」「發布版」「最終文案」「最終採用版本」，明確要求「不要改文案」，或本次寫作已經完成「配圖 + 公眾號可複製 HTML」交付時，保留當前文字與順序。除用戶明確授權外只能建議，不能直接修改；即使審稿發現問題，也先說明而不動正文。用戶已經刪除或否決的內容不得重新加入或反覆建議，只有用戶主動要求恢復時再處理。
初稿與重寫可以直接修改；審稿先建議。進入終稿保護後，除用戶明確授權修正的錯別字外，不直接改正文。
核心工作流
GitHub README 是獨立任務模式。完成下方「讀取素材，建立事實邊界」後，完整讀取 GitHub README 方法 並按其中流程執行；不要套用公眾號長文的主導推進線、前三屏、行動端節奏、終稿自進化或微信排版規則。下方第 2–4 步只適用於公眾號長文、舊稿重寫與審稿。
1. 讀取素材，建立事實邊界
先完整讀取用戶提供的材料。涉及倉庫時，優先檢查 README、許可證、架構、關鍵程式碼、測試、日誌、提交與當前狀態，但不修改源項目。涉及外部事實、研究或時效數字時，核驗原始或權威來源並記錄日期。
寫作前完整讀取 事實與策略。區分倉庫可驗證、用戶親述、第三方反饋、推斷和時效數據。用戶親述可以寫，但不能偽裝成倉庫證據；反饋必須歸因；推斷不能寫成事實；數字寫清基線、範圍、方法和時間；原話只有可見文本或用戶確認後才能加引號。
材料不足時，最多追問 1–3 個會改變主線的問題。用戶要求先繼續時，保留待補項，不補寫不存在的細節。
2. 定策略與結構
先確定目標讀者、傳播承諾、主矛盾或核心問題、技術主線、情感/認知變化和自然行動，再定標題與提綱。標題可以直接提問，也可組合數字、投入、結果、反差或身份；只使用正文能兌現的元素。
寫作前完整讀取 寫作方法、作者文風記憶 和 視覺審美記憶，以用戶最新明確選擇為準。即使本次不配圖，也讀取視覺記憶，避免後續排版與封面建議偏離。
「項目故事」和「觀點實證」只是高層寫作意圖，不是固定章節模板。每篇現場識別一條主導推進線：事件變化、認知變化、決策變化、實驗變化或人物關係變化；其他變化可以輔助，但不能爭奪主線。結構必須從本篇事實、衝突、證據、選擇與後果中生成，不按預設幕數、章節表或上篇結構套寫。版本更新／迭代決策複盤只是一種可選變體，不能擴展成新的固定引擎。
每一章都要讓主導推進線發生變化。相鄰兩節只能用「然後」或「此外」連接時，重建因果。
3. 寫正文
第一句話讓事情或問題發生，三句內出現真實衝突、反差、數字或明確疑問；盡快說明項目/議題和讀者為何值得繼續。不要從時代背景、行業趨勢或「本文將介紹」開始。
重要技術段落盡量覆蓋：
問題 → 為什麼難 → 嘗試或取捨 → 具體實現 → 可量化結果 → 適用邊界
術語首次出現時用一句人話解釋，再回到檔案、日誌、實驗或決策。不能把局部指標外推為整體效果；無法量化時如實寫可觀察結果。
保持作者聰明、坦率、有判斷也允許修正的聲音。保留自然口語、自嘲和真實情緒，不自動添加性別刻板話術，不為「高級感」統一潤色。短段落為主，長短句交替；表格只用於明顯更清楚的比較、映射或時間線。
學習參考文章時只提取結構規律，不複製獨特句子、標題、口頭禪、私人經歷或品牌設計。配圖只承擔證據、解釋或轉折；素材不足時少圖，不用裝飾圖冒充事實。
4. 審稿與收束
需要審稿與交付時，完整讀取 審稿與交付。先看開場、主線、局面變化和人物/認知推進，再查事實歸因、技術邊界、數字日期、引語、許可證、重複和行動端可讀性。所有長文在交付前執行輕量的「終稿去 AI 味檢查」：先刪不增加事實、因果、判斷或人物變化的句子，再做必要的局部改寫；不得機械刪字、禁用句式、改變本篇結構或重寫成更標準的公關稿。
初稿和重寫任務中，發現問題後可以直接修改；審稿時先給建議。進入終稿保護後，除用戶明確授權的錯別字外，不直接改正文。
生成終稿、配圖或公眾號 HTML 前，用兩套記憶各自自檢一次：文案檢查句長、口語、刪減、列表與 AI 味；視覺檢查圖片類型、裁剪、拼圖、封面構圖與排版。沒有已晉升偏好時不自行補造。
結尾回扣開場與作者動機，交代當前能力或結論、適用與不適用範圍、尚未驗證項，以及自然行動。CTA 像邀請，不硬喊點讚、關注或轉發。
輕量自進化
出現以下任一條件時，把當前版本視為終稿並在本次任務結束前執行輕量自進化，不等待用戶再次確認：
- 用戶明確稱其為「終稿」「發布版」「最終文案」「最終採用版本」或「我已經改完了」；
- 一個寫作任務已經同時完成配圖交付和公眾號可複製 HTML 交付。
完整讀取 自進化規則 後執行。只從模型前稿與用戶手改終稿的真實差異學習；依次區分刪除、改寫、新增、原樣保留，原樣保留固定視為助手文字且不得成為用戶偏好證據。用腳本生成穩定匿名終稿 ID，並透過持久化信號台帳更新記憶；文字規則只進入 作者文風記憶，視覺規則只進入 視覺審美記憶。每次最多新增或修正 2 條抽象規則；用戶說「這次不要學習」時跳過。
條件工作流
- 用戶要求終稿或「不改內容」排版時，完整讀取 內容凍結排版。只在用戶明確要求「內容完全不變並驗證」時運行
scripts/verify_content_preservation.py；不要把校驗變成每次交付的預設步驟。 - 用戶需要公眾號可複製排版、預覽或後台草稿時，完整讀取 公眾號內聯排版與草稿。保持現有渲染、校驗和後台流程；儲存草稿後停止，發布、群發、審核或定時發送需要另行明確授權。
- 用戶需要生成、重寫、審查或雙語化 GitHub README 時，完整讀取 GitHub README 方法。中文為倉庫主語言時預設使用
README.md+README_EN.md；兩份檔案頂部提供相對鏈接切換，英文按英語開發者習慣重寫，不逐句機翻。生成檔案後運行scripts/validate_readme_pair.py；只審稿且未修改檔案時不運行。
交付原則
用戶要什麼就交付什麼。事實表、策略卡、敘事推進表和配圖藍圖可在內部生成以保證質量，但不預設全部展示；只交付用戶請求的正文、標題、摘要、HTML、配圖或其他成品，以及會影響發布安全的必要說明。正文不混入審稿備註、事實標籤、待補提示和配圖說明；需要標註稿時另做副本。第三方反饋在正文中自然歸因。
不編造事實、數據、評論、經歷、效果或引語；不把醫療、法律、心理和關係建議寫成保證；許可證以倉庫實際檔案為準。不得生成、索取、讀取或儲存公眾號憑據，也不得把「儲存草稿」擴大為發布。
修改本 Skill 時，完整讀取 測試場景，按改動範圍做輕量測試；不預設運行公眾號、Word、圖片或後台交付測試。