最近在幾個寫論文的朋友群里聊 AI 工具我發(fā)現一個很有意思的現象很多人還在用“新建對話 一段提示詞”的方式讓大模型幫忙做文獻綜述、潤色英文、調 LaTeX 格式但另一撥人已經在用 Skills 把這套流程整個固化下來了效率完全不在一個量級。Skills 這個詞最近在 Codex、Claude Code、opencode 這些工具里刷屏說直白點它是給 AI 插上的“專業(yè)技能包”讓模型按你預設的流程和規(guī)范干活而不是每次看心情發(fā)揮。這篇東西我打算完全圍繞論文寫作這個場景從 Skills 是什么、怎么裝、怎么用到手寫一個 LaTeX 排版技能包一次講清楚。適合剛開始接觸 Skills、想在論文寫作里少走彎路的朋友也適合那些已經積累了一堆提示詞、想進一步把自己經驗沉淀成技能庫的熟手。1. Skills 機制到底是什么它和普通提示詞差在哪1.1 一句話理解 Skills給 AI 裝上一套“操作手冊”很多人在第一次接觸 Skills 時第一反應是“這不就是 preset prompt 嗎”。我一開始也這么想但真正用起來后發(fā)現兩者完全不是一回事。普通提示詞是你在每次對話里臨時告訴 AI“你要做什么、按什么標準做”它本質上是上下文的一部分模型這次記住了下次又忘干凈。而 Skills 是一個獨立的技能包通常包含一個類似說明書的 Markdown 文件外加上可執(zhí)行的腳本、模板文件、參考資料存放在固定的目錄結構里。AI 工具在啟動后會自動掃描這些技能包根據你當前對話的內容去匹配“該技能是否可用”匹配到之后才把技能包里的說明完整加載進上下文。我習慣用一個類比來理解普通提示詞是你在路邊找個實習生口頭交代兩句讓他去干活而 Skills 像是你給團隊里的老員工發(fā)了一本厚厚的項目操作手冊里面有流程圖、有檢查清單、有模板還有一整套配套工具。你只需要說一句“按手冊去辦”他就能以穩(wěn)定的質量把事情推進下去而且不會因為當天心情不好就隨意發(fā)揮。正是這種“可復用、可沉淀、帶工具”的特性讓 Skills 和提示詞在一開始就走上了不同的進化路線?，F在主流的幾個命令行 AI 工具比如 Codex CLI、Claude Code、opencode包括一些編輯器插件都已經把 Skills 當成一等公民來支持社區(qū)里甚至出現了像 superpower skills、awesome-claude-skills 這樣的聚合倉庫把別人打磨好的技能包直接拉下來用。熱度這么高不是沒原因的它解決的是一個大模型應用里非常頭疼的問題如何把復雜的工作流穩(wěn)定地重復執(zhí)行。1.2 為什么論文寫作比寫代碼更需要 Skills你可能想Skills 不是從編程助手火起來的嗎怎么論文寫作反而更需要它我的體會是寫代碼的場景里模型即使跑偏了編譯器和測試用例會立刻告訴你錯了糾錯成本其實是低的。但論文寫作不一樣它的周期極長從文獻調研、大綱設計、實驗描述到 LaTeX 排版、語言潤色、參考文獻整理橫跨好幾個完全不同的任務類型而且每一步的“標準答案”都藏在各種作者指南和審稿人偏好里。普通提示詞在這種長流程任務里最大的問題是風格漂移和遺忘第一次對話讓你把摘要寫得緊湊寫到第三節(jié)方法部分時它已經忘了開頭的風格要求這篇論文要求參考文獻用 GB/T 7714下一篇換成 IEEE 格式每次都要重新交代一遍。Skills 解決的是“把隱性知識顯性化”的問題。比如我自己寫英文論文時最煩的就是把中文思路翻譯成英文后總被審稿人指出“語言表達不夠 native”。后來我把一段寫好的潤色規(guī)則沉淀成一個翻譯潤色 Skill里面明確規(guī)定了術語一致性檢查、句式扁平化、被動語態(tài)的使用邊界還有我自己的高頻易錯詞表。每次執(zhí)行時AI 不只是機械翻譯而是先讀我的規(guī)則再按規(guī)則處理最后還會把改了哪些地方、為什么這么改列成清單給我看。這個體驗是普通提示詞給不了的。還有一點對論文黨特別重要Skills 是可以在不同工具之間遷移的。我在 Claude Code 里寫好的一個“數學建模論文生成”技能包放到 Codex 或者 opencode 里只要目錄結構對就能直接用。這意味著你整理的寫作規(guī)范、排版模板、審稿意見回復套路會慢慢積累成一套屬于自己的學術 AI 知識庫換工具、換電腦都不會丟。對于要長期產出論文的人來說這個沉淀價值可能比省幾個小時更重要。2. 論文寫作高頻場景與值得優(yōu)先配置的 Skills 清單2.1 先把論文寫作拆成五個能“自動化”的環(huán)節(jié)我在日常工作中會把論文寫作拆成幾個相對獨立的環(huán)節(jié)并不是每個環(huán)節(jié)都適合交給 AI 全權處理但很多環(huán)節(jié)確實可以用 Skills 把重復勞動砍掉一大半。第一個是文獻調研與綜述整理。這個場景最累的不是讀文獻而是把幾十篇文章的貢獻、方法、局限按主題歸類最后形成一段有邏輯脈絡的綜述。一個好的綜述 Skill 會要求 AI 先提取每篇文獻的屬性字段再按你指定的維度做對比表格最后才動筆寫文字。它逼著模型“先整理再輸出”比直接問“幫我寫一段綜述”要靠譜得多。第二個是實驗與方法描述。理工科論文的實驗部分最忌諱的就是描述含糊、參數缺失但每次寫起來又非常繁瑣。一個實驗描述 Skill 可以內置一套 checklist數據集名稱、評估指標、基線方法、超參數設置、實驗環(huán)境、重復次數逐項核對缺哪個就向你提問直到信息完整才輸出文字。這個方法表面上看起來多花了時間但實際它避免了你寫完一段后發(fā)現少了關鍵實驗細節(jié)又回頭補查的折騰。第三個是 LaTeX 排版與圖表處理。這是我認為最適合用 Skills 的環(huán)節(jié)之一因為排版規(guī)則高度標準化工具鏈也穩(wěn)定。一個排版本地技能包能幫你自動生成符合期刊模板的 LaTeX 骨架、統(tǒng)一字體和圖表尺寸、檢查參考文獻引用是否缺失、甚至能寫出輔助腳本去檢測表格是否超寬。這類技能包的目標不是讓你完全不碰 LaTeX而是把最瑣碎的查錯工作接管過去。第四個是語言潤色與中英互譯。中文論文翻譯成英文時最怕的就是逐字對譯帶來的冗長和生硬感。優(yōu)秀的中譯英 Skill 會定義詳細的處理步驟先分層理解中文原意再按英文思維重寫句子同時保證專業(yè)術語的準確性不被犧牲。反向操作也類似英文論文投中文期刊時需要把長難句拆開、把被動語態(tài)改得符合中文閱讀習慣。第五個是審稿意見回復與論文結構檢查。回復審稿人有一套固定的溝通禮儀和邏輯結構逐條回復、說明修改位置、標注新舊變化這些用一個專門的回復 Skill 就能規(guī)范化。論文結構檢查 Skill 則相當于一個自動化的邏輯自檢助理按“摘要—引言—方法—結果—討論”的完整性檢查每個部分的要素是否齊全轉折是否突兀。把論文寫作拆成這五個環(huán)節(jié)之后每個環(huán)節(jié)用什么 Skill 就清晰多了。2.2 具體有哪些好用的 Skills去哪里找剛起步的人最容易犯的錯是“收藏一堆技能包但根本用不上”。我不建議一上來就鋪開裝幾十個先按自己當前的寫作方向挑 35 個就夠了。下面列一些我實際用過或身邊人反饋不錯的類別你可以把它們作為搜索關鍵詞去社區(qū)倉庫里找。場景技能包類型主要作用備注文獻綜述綜述生成與證據表格整理文獻字段并輸出對比表格需要自己維護文獻列表實驗描述實驗方法完整性檢查逐項核對參數與指標內置常見會議期刊規(guī)范LaTeX 排版中文論文 LaTeX 技能包生成模板、檢查引用與超寬表格需要本地 TeX 環(huán)境支持中英翻譯學術英語潤色術語一致性、句式扁平化、易錯詞表可自定義自己的詞表審稿回復point-to-point 回復生成按審稿意見逐條生成回復強調克制禮貌的語氣結構自查論文結構調整檢查 IMRaD 結構要素完整度適合投稿前最后過一遍圖表生成結構圖、流程圖腳本生成論文邏輯結構圖或流程圖源碼需要配合繪圖工具這些技能包的去處我主要推薦三個方向。第一是廠商自帶的例子倉庫比如 Claude Code 官方示例和 Codex 的示例集合質量最穩(wěn)、文檔最全遇到問題也好找原因。第二是社區(qū)聚合倉庫比如 awesome-claude-skills、superpower skills 這一類的合集分類多、更新頻繁但質量參差不齊下載后一定要自己過一眼。第三是干脆自己寫把最適合自己的流程固化成技能包這個過程并沒有想象中難下一節(jié)我會完整演示。網站和倉庫我會建議收藏但不要盲目信任。下載任何技能包之前先打開 SKILL.md 看一眼里面的描述和腳本凡是要求執(zhí)行來源不明命令、或者提示需要把 API key 寫進技能包文件里的直接放棄。這不是小題大做技能包和插件一樣本質上就是代碼安全問題值得警惕。3. 從零開始安裝與調用 Skills三步跑通全流程3.1 環(huán)境準備第一步先把工具選對寫論文用 Skills本質上是“本地工具 模型能力 技能包”三者配合的結果。你不需要把環(huán)境想得太復雜我建議新手從命令行工具開始因為可觀測性強、報錯信息直觀調試技能包時看得清楚。目前幾款主流選擇里Codex CLI 勝在輕量、上手快Claude Code 對長文檔的理解和指令遵循能力比較穩(wěn)opencode 則更靈活、插件生態(tài)豐富。這一步沒有絕對答案我個人的選擇是Windows 上做 LaTeX 相關的活兒優(yōu)先用 CodexLinux 服務器上跑批處理任務用 opencode其他情況 Claude Code 居多。你可以都裝上試用一下反正這些工具本身基本都是免費開源的模型調用按量付費。安裝過程這里不展開每個工具的細節(jié)但思路是一致的通過系統(tǒng)的包管理器或者廠商提供的安裝腳本把命令行工具裝好然后登錄你的模型 API 賬號最后確認工具版本支持 Skills 功能。需要注意舊版本對 Skills 的支持可能不完整如果你發(fā)現某個技能包的行為和教程里不一致優(yōu)先檢查版本號是不是太舊。還有一個容易忽略的點就是模型本身也會影響 Skills 的上限。技能包里的指令寫得再好配一個能力太弱的模型輸出質量也會打折反過來模型很好但技能包寫得很亂照樣翻車。我實際測試下來的感受是當前幾款主流模型跑 Skills 都沒問題但復雜多步驟的技能包還是選推理能力強的模型更穩(wěn)妥。3.2 手動放置與一鍵拉取兩種安裝方式安裝 Skills 的方式大體分兩種。手動放置是最通用也最容易理解的方式找到工具指定的全局 skills 目錄把技能包文件夾整個放進去。不同工具的全局目錄不一樣但一般都會有一個類似~/.codex/skills、~/.claude/skills或~/.opencode/skills的默認路徑。不知道在哪的話在命令行里搜索一下工具文檔中的“skills directory”或者“全局安裝管理地址”就能找到。我自己習慣在用戶目錄下建一個skills主目錄然后按工具建子目錄再把公用的技能包軟鏈接進去這樣多個工具之間可以共享我維護的技能庫改一個地方全部生效。一鍵拉取是更省事的做法?，F在很多工具提供了命令行的技能管理入口比如在對話里輸入/skills就能看到已安裝的技能列表部分工具支持從倉庫地址直接把技能包拉進全局目錄類似skills install 作者/倉庫名這種形式。我列一個典型的命令流程不同工具略有差異但思路可以借鑒# 查看技能列表 skills list # 從 GitHub 倉庫安裝一個技能包 skills install some-user/awesome-latex-skill # 查看全局技能目錄位置 skills path安裝完并不是終點你還要看一眼它裝到了哪里、目錄結構是否完整。一個標準的技能包至少應該有一個SKILL.md文件這是 AI 讀取的核心其他的腳本、模板視情況而定。如果拉下來后發(fā)現沒有 SKILL.md那基本可以斷定這個倉庫不是按標準組織的AI 也認不出來。3.3 如何驗證一個 Skills 是否真正生效裝完之后不要急著開始寫論文先做一次驗證。最簡單的方法是在對話里直接說出來比如“使用 LaTeX 中文排版技能幫我檢查這段文檔的格式問題”然后觀察模型的反應。如果技能生效它通常會在回復里體現出讀取了技能包中的規(guī)則比如說“根據技能包中的模板規(guī)范我發(fā)現你的章標題缺少編號格式”甚至會把技能包里的檢查清單列出來給你看。如果模型只是泛泛地回答沒有任何讀取技能包的痕跡那就是沒命中或者沒觸發(fā)。另一種驗證方式是通過工具自帶的技能管理指令直接看當前會話加載了哪些技能。很多工具在對話中輸入斜杠命令就能列出可用 Skills。我工作中經常用的檢查方法是故意提一個邊界問題比如對翻譯潤色技能說“把這段中文翻譯成英文但是保留非常中式的長句”看模型會不會堅持按技能包里的“句式扁平化”原則來糾正我。如果能堅持原則甚至反過來提醒我說明技能真的在起作用如果順從了我的錯誤要求那說明技能包可能寫得不夠強勢或者根本沒有被加載。驗證通過之后還有一件重要的事把技能包的 description 字段和你的觸發(fā)詞對齊。模型判斷是否使用某個技能主要依據就是 SKILL.md 里的 description 描述和當前對話內容的相似度。如果你的技能包描述寫得太泛比如“幫助論文寫作”那你每次提到任何和論文相關的內容都可能觸發(fā)它反而干擾如果寫得太窄又會在需要時找不到。這一步調好之后日常使用的體驗會有質的飛躍。3.4 調用 Smart 細節(jié)觸發(fā)詞、參數傳入與長文檔穩(wěn)定性說幾個我踩過的坑。第一個是觸發(fā)詞的問題。中文環(huán)境下如果你的技能包說明是用英文寫的那么你用中文說“幫我排版”時模型可能匹配不上。解決方案是在技能包的 description 里同時寫上中英文觸發(fā)詞比如“LaTeX typesetting/論文排版/參考文獻格式檢查”。第二個問題是參數傳入。技能包不是魔法它也需要輸入信息。以翻譯潤色為例你最好一次性告訴它“目標期刊是 IEEE 會議、語言風格希望偏英式、術語參照某某標準”這些參數越明確輸出越貼合需求。我會在技能包的配置區(qū)域里預留變量位然后在調用時把具體值填進去這樣同一個技能可以適配不同的期刊要求。第三個也是最頭疼的問題是長文檔場景下的穩(wěn)定性。論文動輒幾十頁模型在長時間、多輪對話中可能會逐漸“遺忘”技能包里的規(guī)則尤其在討論到第 30 輪時經常會出現格式漂移。我的應對辦法是把技能包拆得更細一個總控技能負責全局規(guī)范幾個子技能分別管摘要、方法、圖表、參考文獻。每完成一個部分就讓模型回到總控技能那里做一次一致性校驗。雖然多了一步操作但比最后統(tǒng)一返工省心太多。4. 實戰(zhàn)手把手做一個 LaTeX 排版 Skills4.1 Skills 的文件結構與命名規(guī)范先強調一個原則技能包不等于一個 Markdown 文件就完了它是一個有結構的文件夾。一個標準技能包通常長這樣my-latex-skill/ ├── SKILL.md # 技能說明AI 會先讀這個 ├── templates/ # 可復用的 LaTeX 模板 │ ├── article.tex │ └── reference.bib ├── scripts/ # 輔助腳本比如引用檢查 │ └── check_refs.py └── assets/ # 參考資料、風格指南SKILL.md 是靈魂它采用 Markdown 加 frontmatter 的格式frontmatter 部分至少要有 name 和 description 兩個字段。description 是最關鍵的部分相當于觸發(fā)的“鉤子”寫得好不好直接決定技能是不是會被正確激活。我在命名時都會帶著場景詞比如“論文 LaTeX 排版與參考文獻檢查”避免和別的小技能混淆。正文字部分的組織很講究我不會寫一堆空泛的原則而是按執(zhí)行步驟來寫讓 AI 能看到“先做什么、后做什么、什么情況下做例外處理”。比如第一步永遠是“讀取用戶提供的 TeX 文件并確認編譯引擎”而不是上來就開始改格式。frontmatter 的寫法和 metadata 的 tag 也別浪費可以寫清楚這個技能包適用的期刊類型、編譯工具鏈版本、支持的中文字庫范圍。AI 讀取這些信息后能夠在適當的時機作出工具鏈選擇而不是遇到 ctex 宏包時報錯半天還不知道哪里的問題。4.2 寫一個面向中文論文的 LaTeX 技能包完整示例我直接分享一個我修復過多次的 SKILL.md 示例這是面向中文論文場景的精簡版你想用的話可以在這個基礎上繼續(xù)豐富。它的核心思路不是替你把全文寫出來而是先判斷文檔類型再執(zhí)行一套穩(wěn)定的檢查流程。--- name: latex-chinese-paper description: 中文論文 LaTeX 排版與格式檢查。當用戶提到論文排版、LaTeX 格式、參考文獻引用、表格超寬、編譯錯誤、中文支持時使用。 tags: [latex, ctex, bibtex, 中文論文, 排版] --- # 中文論文 LaTeX 排版技能 ## 目標 幫助用戶完成中文論文的 LaTeX 排版與格式一致性檢查減少低級格式錯誤。 ## 執(zhí)行步驟 1. 讀取用戶提供的 TeX 文件確認 preamble 區(qū)域使用的文檔類和宏包。 2. 檢查是否引入 ctex 宏包或使用 ctexart 文檔類若缺少中文支持給出添加方案。 3. 檢查編譯引擎 - 推薦使用 xelatex 或 latexmk確認字體配置適配當前操作系統(tǒng)。 - 在 Windows 中建議使用中易字體集合在 macOS 中建議檢查系統(tǒng)中文字體名。 4. 檢查參考文獻系統(tǒng) - 確認使用 bibtex 還是 biblatex并保證 .bib 文件條目完整。 - 掃描正文中的 \cite 命令列出引用過但 bib 中缺失的鍵名。 5. 檢查表格與圖片 - 表格寬度超過文本寬度的項建議使用 tabularx 或調整列寬。 - 圖片建議統(tǒng)一使用矢量圖格式并確認圖片路徑存在。 6. 輸出格式檢查清單按“已通過/待修改/需確認”三類列出。 ## 注意事項 - 不擅自改變用戶原有命令所有修改都先給 diff。 - 涉及編譯時不要假設所有環(huán)境都有完整 TeX Live 發(fā)行版。配套的check_refs.py腳本可以做一個最基礎的事掃描正文里的\cite鍵和 bib 文件里的條目做差集找出缺失引用。這個小腳本非常簡單也許只有十幾行但它把排版里最機械、最費眼的那部分檢查自動化了。腳本放好后在技能說明里注明“運行 scripts/check_refs.py 檢查引用完整性”AI 到那一步就會自動調用它。寫完技能包后我的習慣是把常見的修改記錄追加到 SKILL.md 里“注意事項”區(qū)域。比如有一次我發(fā)現某個期刊模板要求圖表標題必須位于表格上方但另一個期刊要求在下邊這屬于模板級差異不能寫死進主流程里我就把它們作為備注字段讓用戶在調用時傳入參數。通過這種方式不斷給技能包“喂”新需求它才逐漸變成真正貼合自己業(yè)務的工具。4.3 調試和迭代讓技能包越用越聰明新寫的技能包第一次運行時很少能完美工作這太正常了。調試時我會讓 AI 先輸出“技能執(zhí)行計劃”讓它把每一步要干什么列出來而不是直接埋頭改文件。這樣一旦出錯我能很快定位是哪一步出了問題。第二個調試技巧是故意用一個小樣本來測試。比如只給它一個 3 行的最小 TeX 文件看它能不能走通整個流程跑通了再拿完整論文去試。這個過程有點像一個檢查流水線先跑通空轉再加載負載效率反而最高。迭代時最忌諱的是把技能包當成一次性產品。我會維護一個獨立的經驗筆記文件記錄每次論文寫作中遇到的格式問題和解決方案定期把它合并進 SKILL.md 和 scripts 腳本中。久而久之這個技能包就成了我自己專屬的“AI 知識庫”——不只是 LaTeX 的技能連“哪些期刊要求突出貢獻點”“哪些審稿人喜歡看到對比實驗”這些經驗都能沉淀進去。這才是 Skills 玩法里最有價值的部分它不是工具喂給你的而是你在使用中長出來的。5. 常見問題與避坑經驗速查5.1 高頻故障與排查思路我看過很多人在社區(qū)里反饋技能包不生效、輸出亂改格式、甚至出現安全隱患其實大多數都可以提前避開。下面這個表格是我自己踩過和幫別人排查過程中整理出來的高頻問題適合直接當工作手冊用。高頻問題可能原因排查與解決思路技能完全沒觸發(fā)description 和用戶意圖匹配不上給 description 增加中英文觸發(fā)詞做一次最小觸發(fā)測試技能觸發(fā)了但結果亂改格式SKILL.md 里沒有限制修改范圍在注意事項里明確“先給 diff 再修改”或要求“不允許改動原有命令”LaTeX 中文編譯失敗缺少 ctex 宏包或字體配置不對推薦用 xelatex 引擎檢查系統(tǒng)中文字體名并寫入技能包參考文獻引用缺失檢測不到腳本沒有在正確時機調用在 SKILL.md 執(zhí)行步驟里明確標注腳本調用節(jié)點長文檔后期規(guī)則失效模型上下文被長對話沖淡拆分技能包每完成一個部分讓模型回到總控技能做一致性校驗安裝后技能包不可見目錄結構不對或不在全局 skills 路徑檢查 SKILL.md 是否存在確認安裝到了工具的全局安裝管理地址來源不明的技能包行為異常可能包含惡意腳本安裝前先查看 SKILL.md拒絕執(zhí)行來源不明的命令這里面我想單獨展開兩點。第一點是“技能包會亂改格式”這個問題它發(fā)生的頻率比想象中高。很多技能包為了讓輸出好看會在說明里寫“統(tǒng)一調整圖表標題格式”“修正所有章節(jié)編號”但論文是個高度個性化的東西AI 的自作主張往往適得其反。我現在所有技能包的注意事項里都會加一句先輸出修改計劃等用戶確認后再執(zhí)行執(zhí)行時保存原始文件備份。這句話成本極低但能避免大量返工。第二點是關于社區(qū)里對某些“大神級”流程的討論比如有人質疑過 mattpocock 的某套配置流程好不好用。我的看法是大神流程通常面向通用場景參數多、抽象度高適合有一定經驗的用戶去微調但如果你只是想快速解決一個具體問題被它的學習曲線絆住反而得不償失。技能包玩到后面拼的不是誰裝得多而是誰最會做減法留下真正高頻使用的刪掉一年都用不上一回的。5.2 幾條體會比較深的經驗最后分享幾條我實際操作中體會最深的原則。第一條是“技能包不是給別人看的是給 AI 看的”。很多人寫 SKILL.md 時愛寫很多鼓勵話術比如“請你一定要仔細核對”但這些對模型的約束力遠不如一條具體的“若 A 則 B”規(guī)則。你寫“檢查缺失引用”不如寫“掃描正文中所有 \cite 命令并與 bib 條目做差集輸出缺失鍵名列表”模型對后者的執(zhí)行要精準得多。第二條是“不要迷信某一個工具”。我見過有人在 Claude Code 里把技能包調試得無比順手就覺得其他工具是異端但不同工具對技能包的解釋器實現其實有差異同一個技能包在 A 工具上完美運行換到 B 工具上可能連觸發(fā)都觸發(fā)不了。我現在寫技能包時會盡量保持標準結構避免使用只有某個工具才支持的私有語法這樣在多個工具之間切換成本就會很低。第三條是“持續(xù)給技能包喂反饋”。每次技能執(zhí)行完如果輸出不滿意不要只刪掉重新生成而是把“哪里不滿意、期望是什么”記下來抽空更新進技能包的說明里。我最近就在做一個小調整把審稿意見回復技能里那些偏“卑微”的句型全部改成克制的學術表達因為投過幾次稿我發(fā)現審稿人更受用邏輯清晰的回應而不是一味客套。這種細節(jié)的打磨才是 Skills 真正拉開效率差距的地方。