AI论文写作Skills完全指南：从润色到降重的一站式技能包

最近在学术群里经常看到有人问：为什么别人用 AI 写论文，能直接给出可用的文献综述框架、能按期刊口味改句式，自己却每次都要从“帮我润色这段话”开始？其实差别往往不在模型，而在一个叫 Skills 的东西。如果你最近也在刷“codex 写论文的 skills”“paper 润色 skills 推荐”，那这篇就是给你整理的完全指南：Skills 到底是什么、论文写作需要哪几个、怎么把别人写好的装进自己的编辑器，以及如何从零写一个完全适合自己的论文润色 Skill。

先说结论：Skills 不是某个模型的独占功能，而是一套可复用、可共享、可版本管理的“技能包”。它把一段固定的高质量工作流（怎么分析题目、按什么结构输出、用什么标准检查）封装成一个文件夹，让 AI 在遇到对应场景时自动调用。论文写作恰恰是最适合用 Skills 的场景，因为学术写作有大量规范是稳定且重复的——引用格式、段落结构、学术用词、降重逻辑，这些都值得固化成技能。下面我把从理论到实操的全过程一步步拆开。

1. Skills 到底是个什么东西，为什么论文写作偏偏需要它

1.1 一个 Skill 的文件结构，比你想的简单

我第一次接触 Skills 时以为是什么高深框架，打开一看，本质上就是一个带规范命名的文件夹。核心结构大概长这样：

academic-rewriter/ ├── SKILL.md # 技能主文件：描述、指令、示例都在这 ├── scripts/ │ └── ai_phrase_check.py # 可选：处理文本的脚本 ├── assets/ │ └── before_after.png # 可选：展示效果的图片 └── references/ └── academic_phrase_bank.md # 可选：专业词库/参考文献

真正起决定作用的是SKILL.md，它是模型读取这个技能时的“说明书”。文件最上方通常是 YAML 格式的元信息，包含 name（技能名）和 description（技能描述），下面则是具体的指令正文。模型会先扫描所有可用技能的 description，判断当前用户请求是否匹配，匹配时才加载对应的正文指令。

这有点像电脑里的快捷键：不是把整个功能常驻内存，而是你先定义好“按哪个键、执行什么动作”，用到时再触发。理解了这一点，后面所有排查问题都有方向了。

1.2 它和普通 Prompt 的真正区别，以及为什么适合论文

很多人觉得“我不学 Skills，直接把指令复制进对话框不也一样？”短期看确实能用，但用过几个来回你就会发现痛点：普通 Prompt 是一次性的，模型聊完就忘，第二天你要么重新复制一大段，要么忍受它跑偏；而 Skills 是持久化的技能封装。

论文写作对“一致性”的要求极高。举个例子，导师要求所有小标题都用动宾结构、所有文献引用都用 GB/T 7714 格式、所有段落先观点后解释——这些规范靠每次重新输入，漏一次就错一次。把规范固化进 Skill 之后，模型每次触发都会自动遵守，你不需要反复强调。更进一步，Skills 是可以用 Git 管理的，你改了词库、加了规则，整个团队拉下来就是同一套标准。

还有一个容易忽略的好处：Skills 可以把专业知识“外置”。比如你完全可以把常用的学术词库、某个具体期刊的作者指南放进去，模型不需要记住所有细节，用到时按需读取即可。这对论文这种长文本场景特别值钱，因为上下文窗口是有限的，与其让它硬记一万条规范，不如全部塞进 Skill 按需检索。

2. 论文写作的 Skills 清单：按场景匹配，别贪多

2.1 选题与文献综述类：从“一个方向”到“一个问题”

论文写作第一步卡住最多人的，是把一个模糊方向变成可研究的学术问题。这类 Skill 通常叫topic-analyzer或literature-review-assistant，作用是接收你输入的研究领域，输出研究现状梳理、主流方法对比、研究空白（research gap），以及可继续追问的文献线索。

我自己常用的流程是：把标题或摘要丢给它，让它严格按“领域背景—已有研究—方法脉络—空白点—可行方向”五段结构输出。注意，好的综述类 Skill 不会直接给你写综述，而是先输出一个“文献地图”，告诉你哪些子问题已经饱和、哪些方向还有空间。这个前置动作非常省时间，能避免你对着一个被研究透了的题目死磕。

这里还涉及一个热词里高频出现的场景：数学建模和人工智能方向的论文。这两个领域的特点是：方法部分占比大、公式和实验描述多、需要对比基线。适合的 Skills 组合是“问题重述 + 模型假设 + 算法伪代码生成 + 实验结果描述”，后面在搭配部分我会展开。

2.2 结构与大纲类：让摘要和结论不再难产

结构类是论文写作里最容易出效果的 Skills。好的outline-builder不会只给你一个“引言—方法—实验—结论”的空架子，而是会针对你的论文类型生成带论据提示的详细大纲。比如实证类论文，它会提醒你在文献综述末尾加入“假设提出”小节；工程类论文，它会要求你在方法部分写明“复杂度分析”。

摘要生成器也很实用。学术摘要最大的难点是“把 8000 字压缩成 250 词还不能丢信息”。好的摘要 Skill 一般会先提取全文关键句，再按“背景—方法—结果—结论”重组，最后把生硬的连接词替换成学术表达。再进阶一点的 Skill 还能针对目标期刊的摘要风格调整侧重点，比如偏重应用价值的期刊要多写意义，偏重理论的期刊要多写贡献。

2.3 润色与降重类：把 AI 味和口语化压下去

这一块是“codex 写论文的 skills”“论文润色 skills”热搜词背后真正的需求。很多人用 AI 润色，出来的句子一看就是机器写的：动词过于正式、被动语态泛滥、连接词千篇一律。润色类 Skill 的价值，就是把“学术化改写规则”显式写进指令，而不是让模型自由发挥。

一个合格的学术润色 Skill 至少应该做到：识别并替换口语化表达、控制被动语态比例、拆分超长句、统一术语、保持论证逻辑连贯。更重要的是降重能力——好的润色 Skill 不是简单换同义词，而是调整句式结构、改变信息呈现顺序、拆分合并句子，这需要一套明确规则，我在第 3 部分会给出一个可复现的实例。

降重和润色千万不要混在一个步骤里。降重注重“和原文不同”，润色注重“更符合学术规范”，二者评价标准相反，混在一起模型会不知所措。建议拆成两个独立 Skill 或同一 Skill 的两种模式。

2.4 图表与排版类：论文里最琐碎却最拉分的环节

图表描述是很多中文论文的硬伤，常见问题是“从图中可以看出，曲线先升后降”这种废话式说明。一个好的figure-describerSkill 会要求你先明确图表要支撑哪个论点，再描述数据特征，最后落到结论。输出结构通常是：总体趋势 + 关键数据点 + 与论证的关联，三句话缺一不可。

排版类 Skill 则覆盖参考文献格式整理、公式编号检查、术语表生成这些机械重复又必须零误差的事。特别是参考文献，人工整理经常出标点、顺序、大小写问题。把 GB/T 7714 或 APA 的格式规则写进 Skill，让 AI 按条检查，效率和准确率都远高于肉眼校对。

下面把我推荐的论文写作 Skills 做一个场景速查表，方便你对号入座。

3. 实战：从零写一个“学术论文润色”Skill

3.1 先写元信息：description 决定了它何时被触发

动手写 Skill 前，先想清楚触发场景。很多人写的 Skill 不生效，八成是 description 写得太宽泛。比如“用于润色论文”这种描述，模型在每次写作时都可能想起它，反而导致误触发或不被触发。一个好的 description 应该是：说明功能 + 说明输入输出格式 + 说明适用边界。

下面是一个可以直接用academic-rewriter技能示例的SKILL.md前段：

--- name: academic-rewriter description: > Academic paper rewriting skill. Use when the user asks to polish, rewrite, refine, or reduce repetition of academic paragraphs. Input must be a paragraph of academic text in Chinese or English. Output will be an academically rewritten version with a brief list of changes. Do not use for creative writing or casual email. ---

这里最关键的是“Use when ...”句式，它明确告诉模型什么时候用；而“Do not use for ...”则划清了边界。实际测试里，加了边界约束后误触发率下降非常明显，模型不会在让你写朋友圈文案时突然调用论文润色逻辑。

3.2 把润色标准拆成可执行规则，而不是一句“请润色”

光有元信息还不行，正文指令才是 core。很多人的润色 Skill 失败，是因为正文里只有“请把这段话变得更学术”这种空话。你需要把“什么才算润色成功”定义清楚。我经过反复测试，整理了一套适合中英文学术写作的规则模板，你也可以直接抄：

• 替换口语词汇和情绪化表达，比如“很棒的结果”改为“结果具有显著意义”
• 控制被动语态占比不超过四分之一，过度被动会让行文显得拖沓
• 拆分超过 35 个词的英文长句或超过 50 字的中文长句，每句只保留一个核心论点
• 统一术语表达，同一概念全文只能使用同一种译法
• 明确指示代词，避免“该”“其”这类词导致指代不明
• 删除重复信息，特别是相邻两句表达同一意思的情况
• 保留引用标记和参考文献编号，不允许修改引用位置
• 输出时必须附上修改说明，按“原句 → 改后 → 原因”逐条列出

把规则写清楚还有一个附带好处：模型会“解释自己的修改理由”。对于写论文的人来说，这简直是免费的写作教学，你能从修改说明里反向理解自己原稿的问题。

3.3 加一个可选脚本：用 Python 检测“AI 味高频词”

润色 Skill 除了文本指令，还可以带上一个辅助脚本，专门扫描文本里的“AI 高频词”。英文里像“delve”“leverage”“moreover”“in conclusion”这类词，中文里像“值得注意的是”“综上所述”“首先……其次……最后”这类套路化表达，都容易让论文一眼看去像机器写的。

下面这个 Python 脚本可以放到scripts/ai_phrase_check.py：

import re import sys AI_PHRASES = { "en": ["delve", "leverage", "moreover", "furthermore", "in conclusion", "it is important to note", "plays a crucial role", "a wide range of"], "zh": ["值得注意的是", "综上所述", "显而易见", "不言而喻", "首先", "其次", "最后", "总的来说", "随着", "为了"], } def load_text(path): with open(path, "r", encoding="utf-8") as f: return f.read() def check(text, lang="zh"): phrases = AI_PHRASES.get(lang, []) found = [] for phrase in phrases: count = len(re.findall(re.escape(phrase), text, re.IGNORECASE)) if count: found.append((phrase, count)) return found if __name__ == "__main__": text = load_text(sys.argv[1]) lang = sys.argv[2] if len(sys.argv) > 2 else "zh" result = check(text, lang) if not result: print("No AI-style phrases found.") else: for phrase, count in result: print(f"{phrase}: {count}")

在 SKILL.md 的正文指令里，可以这样引导模型使用脚本：

如果用户提供的是完整论文或较长段落，先用 scripts/ai_phrase_check.py 扫描高频 AI 表达，将命中结果作为润色重点，并在修改说明中单独列出替换情况。

这样 Skill 就不只是“凭感觉润色”，而是有了一个客观的检查维度。实测下来，以“值得注意的是”这类词为例，脚本扫描后强制模型逐一处理，比单纯要求“少用套话”效果稳定得多。

3.4 安装并实际用起来：Claude 和 Codex 的放置路径

写完 Skill 文件夹后，接下来的问题是怎么让 AI 认到它。不同工具路径不同，但逻辑一致：要么放用户级目录全局生效，要么放项目级目录只对当前项目生效。

在 Claude 类应用里，一般有两个位置：~/.claude/skills/是用户级，放这里后所有对话都能调用；.claude/skills/放在当前项目根目录下，只对该项目生效。在 Codex 这类编程代理工具里，通常会读取项目的AGENTS.md或类似配置文件中的技能声明，也可以在配置里指定额外 skills 目录。具体路径以对应工具的官方文档为准，但记住：装完必须重启会话，模型不会在对话中途重新扫描技能列表，这一点很多人踩坑。

放好后，你可以用一句话测试：“请用 academic-rewriter 润色下面这段话，并说明修改理由。”如果能给出结构化改写结果，说明加载成功；如果模型只是随便改了一通，说明元信息或路径可能有问题，直接跳到第 5 章排查。

4. 怎么引入别人写好的 Skills：四种途径与搭配思路

4.1 按项目引入还是全局引入，取决于使用频率

引入现成 Skill 时，第一个选择是放哪级目录。判断标准很简单：如果你不管写什么方向的论文都用得上，比如润色和降重，放全局；如果只在这一个课题里用，比如某个特定数据集的实验描述模板，放项目级。

全局目录的好处是省心，坏处是技能列表越堆越长，模型扫描 description 的开销变大，误触发概率也会升高。我见过有人全局塞了 50 多个 Skill，结果每个都不灵。建议全局只放最重要的 3-5 个，其余一律项目级按需加载。

4.2 从官方市场和社区仓库找 Skill 的四条途径

很多人问“skills 下载平台有哪些”，目前主流途径基本是这几种。官方市场：部分 AI 工具提供了内置的 Skills 市场或插件广场，直接在应用内启用最简单，作者会维护版本兼容性。社区仓库：GitHub 上有大量用户维护的 skills 合集，搜索关键词比如awesome-claude-skills就能找到列表，下载后按目录放置即可。单文件分发：有些作者只分享一个SKILL.md或压缩包，这种要注意检查是否有外部依赖、引用路径是否完整。自建组合：把两三个现有 Skill 的 references 或 scripts 合并成新 Skill，这是进阶玩法，适合有同一课题重复写作需求的人。

无论从哪个途径下载，安全检查不能省。重点看两点：一是 scripts 里的代码是否只是文本处理，会不会请求外部网络、上传你的论文内容；二是 references 里有没有可疑的提示词注入，有些恶意 Skill 会在参考文档里夹带“忽略之前所有指令”之类的文本。论文内容通常涉及未发表成果，隐私风险尤其需要注意。

4.3 多 Skills 搭配：按写作阶段串联，而不是一锅炖

Skills 之间不是越多越好，而是讲究流程编排。以一篇 AI 方向论文为例，我实际用下来比较顺的搭配是：

阶段一：选题分析 Skill 产出研究空白和候选问题；阶段二：文献综述 Skill 产出相关工作和对比表格；阶段三：大纲 Skill 生成章节结构，每个章节附带预期论据；阶段四：写作阶段调用段落生成 Skill，按大纲逐节产出；阶段五：润色、降重、格式检查三个 Skill 按顺序过一遍全文。

这里要特别提醒：不要在同一个对话里同时启用五六个技能，让模型“看着办”。模型在判断调用哪个 Skill 时也会困惑，导致张冠李戴。我的做法是一次只聚焦一个阶段，或者用明确的阶段切换指令，比如“接下来进入润色阶段，只允许调用润色相关技能”。这样上下文也更干净，不会被大量技能描述占据。

5. 常见问题与排查技巧实录

5.1 技能装了但从不触发，问题八成出在 description

这是群里被问烂的问题：“为什么我装了 Skills 没反应？”排查顺序如下：第一步确认路径正确且文件名是SKILL.md而不是skill.md或SKILL.MD，大小写在多数环境下不能错；第二步重启会话，让模型重新索引技能目录；第三步也是最容易忽略的，检查 description 命中率。

模型判断是否调用某个 Skill，靠的是用户请求和 description 的语义匹配。如果你的 description 写得太窄，比如“Use when user asks about reinforcement learning”，那用户只说“帮我写个方法对比”就不会触发。反过来写得太宽也一样糟糕。解决办法是写两到三个常见触发说法，比如“Use when user asks to polish, rewrite, refine, or reduce repetition of academic paragraphs”，一念之间覆盖用户真实表达。

另外还有一种隐蔽情况：两个 Skill 的 description 描述的是同一场景，模型每次都优先选择其中一个。出现这种竞争时，优先检查并集场景，给核心 Skill 的 description 加上更明确的关键词，或者干脆合并两个技能。

5.2 一执行技能上下文就爆掉，怎么控制阅读量

论文写作场景最容易触发上下文超限。原因往往是 Skill 的 references 里塞了整本书、整份期刊模板或大量例句，模型一执行就全部读入，几轮对话后上下文窗口直接耗尽。解决思路是控制的粒度：把大参考资料拆成按需读取的小文件，并在 SKILL.md 中明确写出“只读取与当前任务相关的部分”，不要一次性把所有参考全部加载。

当你的 Skill 需要处理整篇论文时，另一个降低上下文压力的办法是：让脚本做粗处理，模型做细处理。比如先用 Python 脚本抽取每个章节的第一段和最后一段，提取核心信息，再把压缩后的文本交给模型去润色或总结，而不是 5 万字一次性倒入对话。

5.3 输出格式总是不稳定，需要给 Skill 加“格式锚点”

如果你发现同一个 Skill 每次输出的格式都不一样，比如第一次用列表、第二次用表格、第三次用段落，问题通常出在 SKILL.md 里没有给出格式范本。模型对格式的服从程度，取决于你给出的示例到底有多具体。

我的建议是：在 SKILL.md 中用“输出必须符合以下结构”作为锚点，后面跟上完整的示例输出。下面是一个用于润色输出的结构示例：

输出结构： 1. Rewritten Paragraph：完整改写后的段落 2. Change Log：每条修改按“原文片段 → 改后片段 → 修改原因”列出 3. AI Phrase Check：脚本命中的AI高频词及处理结果

如果模型还是偶尔跑偏，可以在指令末尾加一句自检要求：在输出 Change Log 之前，先对照上述结构检查自己的输出。这个看起来不起眼的“自检提示”，实测比单纯重复强调格式有用得多。

5.4 中文学术写作的特殊坑：不只是模板问题

中文论文和英文论文在润色和格式上的需求差异很大，直接套用英文 Skill 会水土不服。首先是引用格式，中文学位论文常用 GB/T 7714，和 APA 的标点、顺序规则不同，好的做法是在 Skill 里专门放一个 references/gbt7714_rules.md。其次是中式学术词汇的规范，比如“基于”“面向”“采用”这些词在中文论文里使用频率非常高，但经常被滥用，需要 Skill 里给出一组更精准的替代表达。最后是口语化连接词，像“所以说”“这样的话”在口语里没问题，放进论文里就需要替换成“因此”“据此”“基于此”等更正式的表达。

这些都需要你在测试过程中不断积累，把导师和审稿人经常批注的问题逐个加入到 Skill 规则里。这也是我认为自己写 Skill 的价值所在——别人分享的通用技能永远不会比你自己迭代过十几个版本的技能更懂你的写作痛点。

5.5 常见问题速查表

我个人在实际操作中最深的一个体会是：Skills 的价值是随着迭代次数增加的，而不是装好那一刻。第一版润色 Skill 可能只解决了 60% 的问题，但每被导师批注一次，就把这条意见翻译成一条规则加进去，半年后这套 Skill 会变得比任何现成模板都好用。这也解释了为什么同样用 AI，有人写论文越写越顺，有人永远在重复同样的错误——差别不在模型智能，而在你有没有把经验固化成离线的可复用资产。

最后分享一个小技巧：给 Skill 里的 references 建一个CHANGELOG.md，每次修改规则或词库时记一笔原因。时间长了，你能清楚地看到自己的论文写作能力在哪些维度上真正提升了——这本账，比论文本身还值得留。