企业官网建设流程全解析

最近在几个写论文的朋友群里聊 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，去哪里找

刚起步的人最容易犯的错是“收藏一堆技能包但根本用不上”。我不建议一上来就铺开装几十个，先按自己当前的写作方向挑 3～5 个就够了。下面列一些我实际用过或身边人反馈不错的类别，你可以把它们作为搜索关键词去社区仓库里找。

这些技能包的去处，我主要推荐三个方向。第一是厂商自带的例子仓库，比如 Claude Code 官方示例和 Codex 的示例集合，质量最稳、文档最全，遇到问题也好找原因。第二是社区聚合仓库，比如 awesome-claude-skills、superpower skills 这一类的合集，分类多、更新频繁，但质量参差不齐，下载后一定要自己过一眼。第三是干脆自己写，把最适合自己的流程固化成技能包，这个过程并没有想象中难，下一节我会完整演示。

网站和仓库我会建议收藏，但不要盲目信任。下载任何技能包之前，先打开 SKILL.md 看一眼里面的描述和脚本，凡是要求执行来源不明命令、或者提示需要把 API key 写进技能包文件里的，直接放弃。这不是小题大做，技能包和插件一样，本质上就是代码，安全问题值得警惕。

3. 从零开始安装与调用 Skills：三步跑通全流程

3.1 环境准备：第一步先把工具选对

写论文用 Skills，本质上是“本地工具 + 模型能力 + 技能包”三者配合的结果。你不需要把环境想得太复杂，我建议新手从命令行工具开始，因为可观测性强、报错信息直观，调试技能包时看得清楚。目前几款主流选择里，Codex CLI 胜在轻量、上手快，Claude Code 对长文档的理解和指令遵循能力比较稳，opencode 则更灵活、插件生态丰富。这一步没有绝对答案，我个人的选择是：Windows 上做 LaTeX 相关的活儿优先用 Codex，Linux 服务器上跑批处理任务用 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 排版 Skills

4.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 高频故障与排查思路

我看过很多人在社区里反馈技能包不生效、输出乱改格式、甚至出现安全隐患，其实大多数都可以提前避开。下面这个表格是我自己踩过和帮别人排查过程中整理出来的高频问题，适合直接当工作手册用。

这里面我想单独展开两点。第一点是“技能包会乱改格式”这个问题，它发生的频率比想象中高。很多技能包为了让输出好看，会在说明里写“统一调整图表标题格式”“修正所有章节编号”，但论文是个高度个性化的东西，AI 的自作主张往往适得其反。我现在所有技能包的注意事项里都会加一句：先输出修改计划，等用户确认后再执行；执行时保存原始文件备份。这句话成本极低，但能避免大量返工。

第二点是关于社区里对某些“大神级”流程的讨论，比如有人质疑过 mattpocock 的某套配置流程好不好用。我的看法是，大神流程通常面向通用场景，参数多、抽象度高，适合有一定经验的用户去微调，但如果你只是想快速解决一个具体问题，被它的学习曲线绊住反而得不偿失。技能包玩到后面拼的不是谁装得多，而是谁最会做减法：留下真正高频使用的，删掉一年都用不上一回的。

5.2 几条体会比较深的经验

最后分享几条我实际操作中体会最深的原则。第一条是“技能包不是给别人看的，是给 AI 看的”。很多人写 SKILL.md 时爱写很多鼓励话术，比如“请你一定要仔细核对”，但这些对模型的约束力远不如一条具体的“若 A 则 B”规则。你写“检查缺失引用”不如写“扫描正文中所有 \cite 命令，并与 bib 条目做差集，输出缺失键名列表”，模型对后者的执行要精准得多。

第二条是“不要迷信某一个工具”。我见过有人在 Claude Code 里把技能包调试得无比顺手，就觉得其他工具是异端，但不同工具对技能包的解释器实现其实有差异，同一个技能包在 A 工具上完美运行，换到 B 工具上可能连触发都触发不了。我现在写技能包时会尽量保持标准结构，避免使用只有某个工具才支持的私有语法，这样在多个工具之间切换成本就会很低。

第三条是“持续给技能包喂反馈”。每次技能执行完，如果输出不满意，不要只删掉重新生成，而是把“哪里不满意、期望是什么”记下来，抽空更新进技能包的说明里。我最近就在做一个小调整：把审稿意见回复技能里那些偏“卑微”的句型全部改成克制的学术表达，因为投过几次稿我发现，审稿人更受用逻辑清晰的回应，而不是一味客套。这种细节的打磨，才是 Skills 真正拉开效率差距的地方。