最近在几个写论文的朋友群里聊 AI 工具我发现一个很有意思的现象很多人还在用“新建对话 一段提示词”的方式让大模型帮忙做文献综述、润色英文、调 LaTeX 格式但另一拨人已经在用 Skills 把这套流程整个固化下来了效率完全不在一个量级。Skills 这个词最近在 Codex、Claude Code、opencode 这些工具里刷屏说直白点它是给 AI 插上的“专业技能包”让模型按你预设的流程和规范干活而不是每次看心情发挥。这篇东西我打算完全围绕论文写作这个场景从 Skills 是什么、怎么装、怎么用到手写一个 LaTeX 排版技能包一次讲清楚。适合刚开始接触 Skills、想在论文写作里少走弯路的朋友也适合那些已经积累了一堆提示词、想进一步把自己经验沉淀成技能库的熟手。1. Skills 机制到底是什么它和普通提示词差在哪1.1 一句话理解 Skills给 AI 装上一套“操作手册”很多人在第一次接触 Skills 时第一反应是“这不就是 preset prompt 吗”。我一开始也这么想但真正用起来后发现两者完全不是一回事。普通提示词是你在每次对话里临时告诉 AI“你要做什么、按什么标准做”它本质上是上下文的一部分模型这次记住了下次又忘干净。而 Skills 是一个独立的技能包通常包含一个类似说明书的 Markdown 文件外加上可执行的脚本、模板文件、参考资料存放在固定的目录结构里。AI 工具在启动后会自动扫描这些技能包根据你当前对话的内容去匹配“该技能是否可用”匹配到之后才把技能包里的说明完整加载进上下文。我习惯用一个类比来理解普通提示词是你在路边找个实习生口头交代两句让他去干活而 Skills 像是你给团队里的老员工发了一本厚厚的项目操作手册里面有流程图、有检查清单、有模板还有一整套配套工具。你只需要说一句“按手册去办”他就能以稳定的质量把事情推进下去而且不会因为当天心情不好就随意发挥。正是这种“可复用、可沉淀、带工具”的特性让 Skills 和提示词在一开始就走上了不同的进化路线。现在主流的几个命令行 AI 工具比如 Codex CLI、Claude Code、opencode包括一些编辑器插件都已经把 Skills 当成一等公民来支持社区里甚至出现了像 superpower skills、awesome-claude-skills 这样的聚合仓库把别人打磨好的技能包直接拉下来用。热度这么高不是没原因的它解决的是一个大模型应用里非常头疼的问题如何把复杂的工作流稳定地重复执行。1.2 为什么论文写作比写代码更需要 Skills你可能想Skills 不是从编程助手火起来的吗怎么论文写作反而更需要它我的体会是写代码的场景里模型即使跑偏了编译器和测试用例会立刻告诉你错了纠错成本其实是低的。但论文写作不一样它的周期极长从文献调研、大纲设计、实验描述到 LaTeX 排版、语言润色、参考文献整理横跨好几个完全不同的任务类型而且每一步的“标准答案”都藏在各种作者指南和审稿人偏好里。普通提示词在这种长流程任务里最大的问题是风格漂移和遗忘第一次对话让你把摘要写得紧凑写到第三节方法部分时它已经忘了开头的风格要求这篇论文要求参考文献用 GB/T 7714下一篇换成 IEEE 格式每次都要重新交代一遍。Skills 解决的是“把隐性知识显性化”的问题。比如我自己写英文论文时最烦的就是把中文思路翻译成英文后总被审稿人指出“语言表达不够 native”。后来我把一段写好的润色规则沉淀成一个翻译润色 Skill里面明确规定了术语一致性检查、句式扁平化、被动语态的使用边界还有我自己的高频易错词表。每次执行时AI 不只是机械翻译而是先读我的规则再按规则处理最后还会把改了哪些地方、为什么这么改列成清单给我看。这个体验是普通提示词给不了的。还有一点对论文党特别重要Skills 是可以在不同工具之间迁移的。我在 Claude Code 里写好的一个“数学建模论文生成”技能包放到 Codex 或者 opencode 里只要目录结构对就能直接用。这意味着你整理的写作规范、排版模板、审稿意见回复套路会慢慢积累成一套属于自己的学术 AI 知识库换工具、换电脑都不会丢。对于要长期产出论文的人来说这个沉淀价值可能比省几个小时更重要。2. 论文写作高频场景与值得优先配置的 Skills 清单2.1 先把论文写作拆成五个能“自动化”的环节我在日常工作中会把论文写作拆成几个相对独立的环节并不是每个环节都适合交给 AI 全权处理但很多环节确实可以用 Skills 把重复劳动砍掉一大半。第一个是文献调研与综述整理。这个场景最累的不是读文献而是把几十篇文章的贡献、方法、局限按主题归类最后形成一段有逻辑脉络的综述。一个好的综述 Skill 会要求 AI 先提取每篇文献的属性字段再按你指定的维度做对比表格最后才动笔写文字。它逼着模型“先整理再输出”比直接问“帮我写一段综述”要靠谱得多。第二个是实验与方法描述。理工科论文的实验部分最忌讳的就是描述含糊、参数缺失但每次写起来又非常繁琐。一个实验描述 Skill 可以内置一套 checklist数据集名称、评估指标、基线方法、超参数设置、实验环境、重复次数逐项核对缺哪个就向你提问直到信息完整才输出文字。这个方法表面上看起来多花了时间但实际它避免了你写完一段后发现少了关键实验细节又回头补查的折腾。第三个是 LaTeX 排版与图表处理。这是我认为最适合用 Skills 的环节之一因为排版规则高度标准化工具链也稳定。一个排版本地技能包能帮你自动生成符合期刊模板的 LaTeX 骨架、统一字体和图表尺寸、检查参考文献引用是否缺失、甚至能写出辅助脚本去检测表格是否超宽。这类技能包的目标不是让你完全不碰 LaTeX而是把最琐碎的查错工作接管过去。第四个是语言润色与中英互译。中文论文翻译成英文时最怕的就是逐字对译带来的冗长和生硬感。优秀的中译英 Skill 会定义详细的处理步骤先分层理解中文原意再按英文思维重写句子同时保证专业术语的准确性不被牺牲。反向操作也类似英文论文投中文期刊时需要把长难句拆开、把被动语态改得符合中文阅读习惯。第五个是审稿意见回复与论文结构检查。回复审稿人有一套固定的沟通礼仪和逻辑结构逐条回复、说明修改位置、标注新旧变化这些用一个专门的回复 Skill 就能规范化。论文结构检查 Skill 则相当于一个自动化的逻辑自检助理按“摘要—引言—方法—结果—讨论”的完整性检查每个部分的要素是否齐全转折是否突兀。把论文写作拆成这五个环节之后每个环节用什么 Skill 就清晰多了。2.2 具体有哪些好用的 Skills去哪里找刚起步的人最容易犯的错是“收藏一堆技能包但根本用不上”。我不建议一上来就铺开装几十个先按自己当前的写作方向挑 35 个就够了。下面列一些我实际用过或身边人反馈不错的类别你可以把它们作为搜索关键词去社区仓库里找。场景技能包类型主要作用备注文献综述综述生成与证据表格整理文献字段并输出对比表格需要自己维护文献列表实验描述实验方法完整性检查逐项核对参数与指标内置常见会议期刊规范LaTeX 排版中文论文 LaTeX 技能包生成模板、检查引用与超宽表格需要本地 TeX 环境支持中英翻译学术英语润色术语一致性、句式扁平化、易错词表可自定义自己的词表审稿回复point-to-point 回复生成按审稿意见逐条生成回复强调克制礼貌的语气结构自查论文结构调整检查 IMRaD 结构要素完整度适合投稿前最后过一遍图表生成结构图、流程图脚本生成论文逻辑结构图或流程图源码需要配合绘图工具这些技能包的去处我主要推荐三个方向。第一是厂商自带的例子仓库比如 Claude Code 官方示例和 Codex 的示例集合质量最稳、文档最全遇到问题也好找原因。第二是社区聚合仓库比如 awesome-claude-skills、superpower skills 这一类的合集分类多、更新频繁但质量参差不齐下载后一定要自己过一眼。第三是干脆自己写把最适合自己的流程固化成技能包这个过程并没有想象中难下一节我会完整演示。网站和仓库我会建议收藏但不要盲目信任。下载任何技能包之前先打开 SKILL.md 看一眼里面的描述和脚本凡是要求执行来源不明命令、或者提示需要把 API key 写进技能包文件里的直接放弃。这不是小题大做技能包和插件一样本质上就是代码安全问题值得警惕。3. 从零开始安装与调用 Skills三步跑通全流程3.1 环境准备第一步先把工具选对写论文用 Skills本质上是“本地工具 模型能力 技能包”三者配合的结果。你不需要把环境想得太复杂我建议新手从命令行工具开始因为可观测性强、报错信息直观调试技能包时看得清楚。目前几款主流选择里Codex CLI 胜在轻量、上手快Claude Code 对长文档的理解和指令遵循能力比较稳opencode 则更灵活、插件生态丰富。这一步没有绝对答案我个人的选择是Windows 上做 LaTeX 相关的活儿优先用 CodexLinux 服务器上跑批处理任务用 opencode其他情况 Claude Code 居多。你可以都装上试用一下反正这些工具本身基本都是免费开源的模型调用按量付费。安装过程这里不展开每个工具的细节但思路是一致的通过系统的包管理器或者厂商提供的安装脚本把命令行工具装好然后登录你的模型 API 账号最后确认工具版本支持 Skills 功能。需要注意旧版本对 Skills 的支持可能不完整如果你发现某个技能包的行为和教程里不一致优先检查版本号是不是太旧。还有一个容易忽略的点就是模型本身也会影响 Skills 的上限。技能包里的指令写得再好配一个能力太弱的模型输出质量也会打折反过来模型很好但技能包写得很乱照样翻车。我实际测试下来的感受是当前几款主流模型跑 Skills 都没问题但复杂多步骤的技能包还是选推理能力强的模型更稳妥。3.2 手动放置与一键拉取两种安装方式安装 Skills 的方式大体分两种。手动放置是最通用也最容易理解的方式找到工具指定的全局 skills 目录把技能包文件夹整个放进去。不同工具的全局目录不一样但一般都会有一个类似~/.codex/skills、~/.claude/skills或~/.opencode/skills的默认路径。不知道在哪的话在命令行里搜索一下工具文档中的“skills directory”或者“全局安装管理地址”就能找到。我自己习惯在用户目录下建一个skills主目录然后按工具建子目录再把公用的技能包软链接进去这样多个工具之间可以共享我维护的技能库改一个地方全部生效。一键拉取是更省事的做法。现在很多工具提供了命令行的技能管理入口比如在对话里输入/skills就能看到已安装的技能列表部分工具支持从仓库地址直接把技能包拉进全局目录类似skills install 作者/仓库名这种形式。我列一个典型的命令流程不同工具略有差异但思路可以借鉴# 查看技能列表 skills list # 从 GitHub 仓库安装一个技能包 skills install some-user/awesome-latex-skill # 查看全局技能目录位置 skills path安装完并不是终点你还要看一眼它装到了哪里、目录结构是否完整。一个标准的技能包至少应该有一个SKILL.md文件这是 AI 读取的核心其他的脚本、模板视情况而定。如果拉下来后发现没有 SKILL.md那基本可以断定这个仓库不是按标准组织的AI 也认不出来。3.3 如何验证一个 Skills 是否真正生效装完之后不要急着开始写论文先做一次验证。最简单的方法是在对话里直接说出来比如“使用 LaTeX 中文排版技能帮我检查这段文档的格式问题”然后观察模型的反应。如果技能生效它通常会在回复里体现出读取了技能包中的规则比如说“根据技能包中的模板规范我发现你的章标题缺少编号格式”甚至会把技能包里的检查清单列出来给你看。如果模型只是泛泛地回答没有任何读取技能包的痕迹那就是没命中或者没触发。另一种验证方式是通过工具自带的技能管理指令直接看当前会话加载了哪些技能。很多工具在对话中输入斜杠命令就能列出可用 Skills。我工作中经常用的检查方法是故意提一个边界问题比如对翻译润色技能说“把这段中文翻译成英文但是保留非常中式的长句”看模型会不会坚持按技能包里的“句式扁平化”原则来纠正我。如果能坚持原则甚至反过来提醒我说明技能真的在起作用如果顺从了我的错误要求那说明技能包可能写得不够强势或者根本没有被加载。验证通过之后还有一件重要的事把技能包的 description 字段和你的触发词对齐。模型判断是否使用某个技能主要依据就是 SKILL.md 里的 description 描述和当前对话内容的相似度。如果你的技能包描述写得太泛比如“帮助论文写作”那你每次提到任何和论文相关的内容都可能触发它反而干扰如果写得太窄又会在需要时找不到。这一步调好之后日常使用的体验会有质的飞跃。3.4 调用 Smart 细节触发词、参数传入与长文档稳定性说几个我踩过的坑。第一个是触发词的问题。中文环境下如果你的技能包说明是用英文写的那么你用中文说“帮我排版”时模型可能匹配不上。解决方案是在技能包的 description 里同时写上中英文触发词比如“LaTeX typesetting/论文排版/参考文献格式检查”。第二个问题是参数传入。技能包不是魔法它也需要输入信息。以翻译润色为例你最好一次性告诉它“目标期刊是 IEEE 会议、语言风格希望偏英式、术语参照某某标准”这些参数越明确输出越贴合需求。我会在技能包的配置区域里预留变量位然后在调用时把具体值填进去这样同一个技能可以适配不同的期刊要求。第三个也是最头疼的问题是长文档场景下的稳定性。论文动辄几十页模型在长时间、多轮对话中可能会逐渐“遗忘”技能包里的规则尤其在讨论到第 30 轮时经常会出现格式漂移。我的应对办法是把技能包拆得更细一个总控技能负责全局规范几个子技能分别管摘要、方法、图表、参考文献。每完成一个部分就让模型回到总控技能那里做一次一致性校验。虽然多了一步操作但比最后统一返工省心太多。4. 实战手把手做一个 LaTeX 排版 Skills4.1 Skills 的文件结构与命名规范先强调一个原则技能包不等于一个 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 是最关键的部分相当于触发的“钩子”写得好不好直接决定技能是不是会被正确激活。我在命名时都会带着场景词比如“论文 LaTeX 排版与参考文献检查”避免和别的小技能混淆。正文字部分的组织很讲究我不会写一堆空泛的原则而是按执行步骤来写让 AI 能看到“先做什么、后做什么、什么情况下做例外处理”。比如第一步永远是“读取用户提供的 TeX 文件并确认编译引擎”而不是上来就开始改格式。frontmatter 的写法和 metadata 的 tag 也别浪费可以写清楚这个技能包适用的期刊类型、编译工具链版本、支持的中文字库范围。AI 读取这些信息后能够在适当的时机作出工具链选择而不是遇到 ctex 宏包时报错半天还不知道哪里的问题。4.2 写一个面向中文论文的 LaTeX 技能包完整示例我直接分享一个我修复过多次的 SKILL.md 示例这是面向中文论文场景的精简版你想用的话可以在这个基础上继续丰富。它的核心思路不是替你把全文写出来而是先判断文档类型再执行一套稳定的检查流程。--- name: latex-chinese-paper description: 中文论文 LaTeX 排版与格式检查。当用户提到论文排版、LaTeX 格式、参考文献引用、表格超宽、编译错误、中文支持时使用。 tags: [latex, ctex, bibtex, 中文论文, 排版] --- # 中文论文 LaTeX 排版技能 ## 目标 帮助用户完成中文论文的 LaTeX 排版与格式一致性检查减少低级格式错误。 ## 执行步骤 1. 读取用户提供的 TeX 文件确认 preamble 区域使用的文档类和宏包。 2. 检查是否引入 ctex 宏包或使用 ctexart 文档类若缺少中文支持给出添加方案。 3. 检查编译引擎 - 推荐使用 xelatex 或 latexmk确认字体配置适配当前操作系统。 - 在 Windows 中建议使用中易字体集合在 macOS 中建议检查系统中文字体名。 4. 检查参考文献系统 - 确认使用 bibtex 还是 biblatex并保证 .bib 文件条目完整。 - 扫描正文中的 \cite 命令列出引用过但 bib 中缺失的键名。 5. 检查表格与图片 - 表格宽度超过文本宽度的项建议使用 tabularx 或调整列宽。 - 图片建议统一使用矢量图格式并确认图片路径存在。 6. 输出格式检查清单按“已通过/待修改/需确认”三类列出。 ## 注意事项 - 不擅自改变用户原有命令所有修改都先给 diff。 - 涉及编译时不要假设所有环境都有完整 TeX Live 发行版。配套的check_refs.py脚本可以做一个最基础的事扫描正文里的\cite键和 bib 文件里的条目做差集找出缺失引用。这个小脚本非常简单也许只有十几行但它把排版里最机械、最费眼的那部分检查自动化了。脚本放好后在技能说明里注明“运行 scripts/check_refs.py 检查引用完整性”AI 到那一步就会自动调用它。写完技能包后我的习惯是把常见的修改记录追加到 SKILL.md 里“注意事项”区域。比如有一次我发现某个期刊模板要求图表标题必须位于表格上方但另一个期刊要求在下边这属于模板级差异不能写死进主流程里我就把它们作为备注字段让用户在调用时传入参数。通过这种方式不断给技能包“喂”新需求它才逐渐变成真正贴合自己业务的工具。4.3 调试和迭代让技能包越用越聪明新写的技能包第一次运行时很少能完美工作这太正常了。调试时我会让 AI 先输出“技能执行计划”让它把每一步要干什么列出来而不是直接埋头改文件。这样一旦出错我能很快定位是哪一步出了问题。第二个调试技巧是故意用一个小样本来测试。比如只给它一个 3 行的最小 TeX 文件看它能不能走通整个流程跑通了再拿完整论文去试。这个过程有点像一个检查流水线先跑通空转再加载负载效率反而最高。迭代时最忌讳的是把技能包当成一次性产品。我会维护一个独立的经验笔记文件记录每次论文写作中遇到的格式问题和解决方案定期把它合并进 SKILL.md 和 scripts 脚本中。久而久之这个技能包就成了我自己专属的“AI 知识库”——不只是 LaTeX 的技能连“哪些期刊要求突出贡献点”“哪些审稿人喜欢看到对比实验”这些经验都能沉淀进去。这才是 Skills 玩法里最有价值的部分它不是工具喂给你的而是你在使用中长出来的。5. 常见问题与避坑经验速查5.1 高频故障与排查思路我看过很多人在社区里反馈技能包不生效、输出乱改格式、甚至出现安全隐患其实大多数都可以提前避开。下面这个表格是我自己踩过和帮别人排查过程中整理出来的高频问题适合直接当工作手册用。高频问题可能原因排查与解决思路技能完全没触发description 和用户意图匹配不上给 description 增加中英文触发词做一次最小触发测试技能触发了但结果乱改格式SKILL.md 里没有限制修改范围在注意事项里明确“先给 diff 再修改”或要求“不允许改动原有命令”LaTeX 中文编译失败缺少 ctex 宏包或字体配置不对推荐用 xelatex 引擎检查系统中文字体名并写入技能包参考文献引用缺失检测不到脚本没有在正确时机调用在 SKILL.md 执行步骤里明确标注脚本调用节点长文档后期规则失效模型上下文被长对话冲淡拆分技能包每完成一个部分让模型回到总控技能做一致性校验安装后技能包不可见目录结构不对或不在全局 skills 路径检查 SKILL.md 是否存在确认安装到了工具的全局安装管理地址来源不明的技能包行为异常可能包含恶意脚本安装前先查看 SKILL.md拒绝执行来源不明的命令这里面我想单独展开两点。第一点是“技能包会乱改格式”这个问题它发生的频率比想象中高。很多技能包为了让输出好看会在说明里写“统一调整图表标题格式”“修正所有章节编号”但论文是个高度个性化的东西AI 的自作主张往往适得其反。我现在所有技能包的注意事项里都会加一句先输出修改计划等用户确认后再执行执行时保存原始文件备份。这句话成本极低但能避免大量返工。第二点是关于社区里对某些“大神级”流程的讨论比如有人质疑过 mattpocock 的某套配置流程好不好用。我的看法是大神流程通常面向通用场景参数多、抽象度高适合有一定经验的用户去微调但如果你只是想快速解决一个具体问题被它的学习曲线绊住反而得不偿失。技能包玩到后面拼的不是谁装得多而是谁最会做减法留下真正高频使用的删掉一年都用不上一回的。5.2 几条体会比较深的经验最后分享几条我实际操作中体会最深的原则。第一条是“技能包不是给别人看的是给 AI 看的”。很多人写 SKILL.md 时爱写很多鼓励话术比如“请你一定要仔细核对”但这些对模型的约束力远不如一条具体的“若 A 则 B”规则。你写“检查缺失引用”不如写“扫描正文中所有 \cite 命令并与 bib 条目做差集输出缺失键名列表”模型对后者的执行要精准得多。第二条是“不要迷信某一个工具”。我见过有人在 Claude Code 里把技能包调试得无比顺手就觉得其他工具是异端但不同工具对技能包的解释器实现其实有差异同一个技能包在 A 工具上完美运行换到 B 工具上可能连触发都触发不了。我现在写技能包时会尽量保持标准结构避免使用只有某个工具才支持的私有语法这样在多个工具之间切换成本就会很低。第三条是“持续给技能包喂反馈”。每次技能执行完如果输出不满意不要只删掉重新生成而是把“哪里不满意、期望是什么”记下来抽空更新进技能包的说明里。我最近就在做一个小调整把审稿意见回复技能里那些偏“卑微”的句型全部改成克制的学术表达因为投过几次稿我发现审稿人更受用逻辑清晰的回应而不是一味客套。这种细节的打磨才是 Skills 真正拉开效率差距的地方。