先说个真实感受我身边很多人拿到新一代 GPT 类模型之后第一反应还是“帮我写一段总结”“帮我润色一下邮件”这当然没错但说实话有点浪费。尤其在科研场景里写论文、做综述、调代码、跑实验、估算力哪一个不是流程长、环节多、重复性高这些恰恰是 Skill 机制最擅长接管的活。最近 Codex Skill、Claude Code Skill、数学建模 Skill 这些词很热我索性把手里在用的 6 个科研 Skill 整理出来从文献蒸馏到建模从代码复现到算力测算一次讲透。这篇文章适合研究生、高校科研人员以及所有想把 GPT-6 这类模型真正用进日常研究的读者。我也会把 Skill 的安装方式、一个最小可用的 Skill 文件模板、链式调用策略以及我踩过的坑都写出来。不是那种“看完全文你会很厉害”的空话而是你照着做今天下午就能跑通一条科研流水线。1. 先搞清楚Skill 到底和普通提示词、Agent 有什么区别1.1 一句话理解 Skill它是给模型的“岗位说明书工具箱”如果你只用过普通提示词那你和 GPT-6 的协作方式基本是“你问一句它答一句”。这在写个邮件、列个提纲的时候够用但科研场景不是这样。科研任务是长链条的先读文献再提炼问题然后设计实验接着写代码最后跑数据、算资源、出报告。你不可能在每一个环节都重新输入一遍背景也不可能忍受模型每次都按自己的理解瞎发挥。Skill 解决的就是这个问题。你可以把它理解成一份“岗位说明书工具箱”的压缩包里面有这个任务的定义、执行步骤、输入输出格式甚至还有配套的脚本和参考文档。当模型检测到当前对话内容命中某个 Skill 的 description 时它就会把整套规则加载进来按照你预设的流程干活。我在实际用下来最直观的感受是没有 Skill 的时候让模型做一个复杂任务它像是在“自由发挥”有了 Skill它像是在“按照 SOP 执行”。自由发挥适合头脑风暴不适合科研产出。1.2 Skill、Prompt、Agent 三者的分工这三个概念经常被混着讲但分工其实很清晰Prompt提示词一次性指令。你跟模型说“帮我翻译这段摘要”这就是一个 Prompt。它没有状态没有流程用完即弃。Skill技能包可复用的任务脚本。它把某一类任务的执行路径固化成标准模板包含步骤、规则、输入输出约定有的还带脚本。简单说它是对 Prompt 的工程化封装。Agent智能体负责调度和决策。Agent 可以判断当前该调用哪个 Skill、要不要读文件、要不要执行代码它是一个“带着工具箱去干活”的执行体。用一个生活化类比Prompt 是你临时让实习生去打印一份文件Skill 是给实习生一份“打印文件操作手册打印机驱动”Agent 是这个实习生本人他看手册、用驱动、把文件打出来还会在你打印机卡纸的时候自己处理。所以热词里“Skill 和 Agent 的区别”其实不是对立关系。一个 Agent 可以挂载十几个 Skill遇到什么场景就调什么 Skill。GPT-6 之所以被很多人看成 Agent 代际跃迁的引爆点是因为新一代模型在多步推理、工具调用上的能力更强了这也让 Skill 机制的收益变得格外明显。1.3 为什么科研场景尤其适合 Skill我自己的经验是科研任务有几个天然适合 Skill 的特点第一科研流程高度标准化。文献综述无非是“收集-筛选-提炼-对比-输出”数学建模无非是“问题分析-假设-建模-求解-验证-报告”。这些流程每年被无数学者重复完全可以固化成模板。第二科研对可复现性要求高。同一个任务今天让模型做一遍、明天再做一遍输出应该大体一致。但普通 Prompt 生成的回答非常不稳定稍有语气变化结果就漂移。Skill 通过固定步骤、固定输出格式、必要时固定脚本来压低这种随机性。第三科研任务链条长。一篇论文从想法到成稿中间跨了好几个工具、好几个知识领域。Skill 可以把链条每一段的上下文都打包好减少信息在传递中的丢失。第四科研领域知识密度高。一个生物信息学方向的 Skill可以在文件里预置常用数据库字段、文件格式、分析管线说明省掉你每次重复解释的大量背景。2. 六大科研 Skill 拆解从文献到算力一次讲透2.1 文献蒸馏 Skill把论文丢进去出来一张对比矩阵先说我最常用的一个把几十篇论文压缩成结构化知识库。以前做文献综述最痛苦的环节不是读而是“读完就忘”。今天读了 5 篇明天再读 5 篇等到写综述的时候脑子里只剩模糊的印象还得回去翻 PDF。后来我把这个流程做成了一个 Skill名字就叫 PaperDistiller。它的核心逻辑是让模型按固定 schema 抽取每篇论文的信息然后汇总成对比矩阵。我预设的抽取字段大致是这样的研究问题论文试图解决什么方法核心用了什么模型/算法/实验范式数据集与实验设置关键结论不依赖作者原话用归纳性表述局限与未来工作与你课题的相关程度标注实操的时候我会先把 PDF 转成文本然后分段丢给模型让它逐篇输出结构化笔记最后再让模型根据这些笔记生成一张对比矩阵。对比矩阵的维度可以是“方法-效果-成本-适用条件”方便横向比较。这里有个非常关键的技巧不要一上来就让它处理 50 篇。我踩过的坑是先跑 50 篇结果输出的格式混乱很多关键信息被吞掉。后来改成先用 3~5 篇代表性论文校准输出格式确认 schema 合理后再批量执行。所谓“校准”就是先手动写出一篇论文的“标准答案”再让模型对照学习这样后续生成质量会稳定非常多。另一个心得是文献蒸馏 Skill 的最终产物不是“摘要汇总”而是“决策依据”。所以我在 schema 里特意加了“与当前课题的相关性判断”和“可借鉴点”这比单纯摘要有用得多。它相当于让模型替你先做了一轮筛选和关联分析。2.2 数学建模 Skill从“题目读不懂”到“模型可计算”数学建模是另一个我个人非常看好的 Skill 方向尤其是国赛、美赛常客还有做运筹优化类课题的研究生。热词里“数学建模 Skill”“数模 Skill”出现频率很高说明这是刚需。我给建模流程设计的 Skill 叫 MathModeler它的执行路径是问题重述把原始题目拆解成目标、约束、已知条件、未知变量。假设建立明确哪些因素忽略、哪些条件理想化每条假设都要给出理由。模型选型根据问题特征推荐模型类别比如线性规划、整数规划、随机过程、图论、机器学习回归等。数学表达把问题用数学语言写出来包括目标函数、约束条件、决策变量。求解与灵敏度分析分析参数变化对结论的影响。报告生成按竞赛格式输出建模论文的骨架。为什么建模这样的任务特别适合 Skill因为它天然具备“流程刚性”。一个合格的建模过程步骤顺序不能乱假设不能漏结论必须对参数变化有回应。普通 Prompt 很容易让模型跳过敏感性分析直接出结论但 Skill 把步骤写死在流程里模型没得跳。我自己在用一个技巧在 Skill 里加一句强制规则——“在给出模型之前必须先用通俗语言解释你将采用什么方法并说明理由”。这一步很有用它能逼着模型先思考再行动输出明显更扎实。对于新手来说这也是一个学习建模思路的极好入口。还有一个细节建模 Skill 里的“假设建立”环节非常重要。很多学生在建模时忽略假设导致模型看着复杂但不可用。我一般会让 Skill 输出一个“假设审查清单”逐条检查每个假设是否被后文用到、是否合理、是否需要灵敏度分析。2.3 科研代码工程化 SkillCodex 类工具的真正用法很多人的科研代码其实是“能跑就行”的水平一个脚本几百行、没有函数封装、没有参数配置、没有测试。这种代码写的时候爽一个星期之后自己都看不懂更别提复现。Codex Skill 的价值就在这里。热词里“codex的skill安装”“codex好用的skill”搜索量很大说明大家已经把 Codex 当成写代码的主力工具了。但仅仅有 Codex 还不够你仍然要给它足够的工程约束否则它生成的代码一样是“玩具代码”。我给代码生成场景配置的 Skill 叫 CodeSmith核心约束包括生成代码前先输出项目文件结构所有函数必须有类型注解和 docstring配置集中放在 config 区禁止把路径和超参散落在代码里必须包含最小可运行的示例入口生成后必须自检导入是否成功、依赖是否完整。最让我觉得值回票价的功能是把“验收标准”写进 Skill。我跟 Codex 说“帮我写一段数据预处理代码”的时候它经常给出一段看似合理但根本跑不动的代码。但我在 Skill 里加上“请先列出 3 个你准备编写的关键函数每个函数的输入输出要给出示例”它在动手前就把逻辑想清楚了代码可用率大大提高。科研场景里另一个很实用的子 Skill 是“论文复现代码整理”把作者公开的代码库按 README 重新梳理把数据集路径统一把依赖版本固定成 requirements.txt最后生成一份复现说明。这个流程以前手动做至少要一上午现在丢给 Skill 处理几分钟出一个初稿我再人工审核修改效率完全不是一个量级。2.4 自动化测试与安全审计 Skill让研究结论不翻车科研工作不只是“写”和“算”测试同样重要。尤其写数据处理工具、隐私计算脚本、爬虫、模型服务接口的时候没有测试意识的人容易把 bug 带进实验数据最后结论全错还找不到原因。热词里“AI 自动挖掘漏洞 Skill”被搜得很多我在这先做个澄清对绝大多数科研场景你不需要一个真的去“挖漏洞”的攻击型 Skill你需要的是一个“生成测试用例并执行自动化审计”的防御型 Skill。我把这个 Skill 叫做 TestPilot。TestPilot 的典型使用方式是这样的你给它一段代码或者一个需求文档它自动生成测试矩阵。比如一个数据清洗函数它会针对空值、边界值、类型错误、超大输入量生成对应测试用例如果是 API 接口它会检查鉴权、参数校验、超时处理、异常返回。这里我想分享一个非常有价值的操作把“需求文档”转换成“测试用例列表”。传统做法是你写完功能代码再补测试但 TestPilot 可以反过来——先让模型根据需求文档写测试用例你验收这些用例然后再让模型照着用例去写实现代码。这种“测试先行”的方式非常契合科研逻辑因为科研本身就需要你先把假设和验证方式想清楚再去收集数据和跑实验。安全审计方面我建议把边界设置得非常明确。Skill 只能做白盒检查和规范审查比如检查日志是否记录敏感信息、接口是否缺少频率限制、代码是否有明显的注入风险。它输出的应该是一份“风险报告修改建议”而不是直接给你一个漏洞利用脚本。不要越界这对你自己也是一种保护。2.5 推理算力测算 Skill报告里那句“需要 N 张 GPU”不再拍脑袋这个 Skill 是最近才补上的但用完后我非常后悔没早做。之前写项目申报书经常被问你打算租几张卡、跑一个 7B 微调要多大的显存我基本都是靠“感觉”给数字。后来看到一个算力测算 Skill 的思路觉得这才是科研场景最实用的工具之一。这个 Skill 的核心是计算模型训练和推理的显存开销。对于训练场景显存占用主要包括模型参数、梯度、优化器状态、激活值这几块对于推理场景则包括模型参数和 KV Cache。Skill 里会内嵌一套估算流程输入模型参数量、精度FP32/FP16/INT8、batch size、序列长度然后一步步估算出显存需求。我拿一个常见例子来演示假设你要部署一个 7B 参数、FP16 精度的模型做推理并且设置了较长的上下文窗口。仅模型参数本身就占约 14GBKV Cache 还会随序列长度显著增长激活值、中间变量和 CUDA context 也得再留出余量。综合算下来想要流畅跑起来单卡至少得准备一块 24GB 以上的 GPU。这个结果跟实测基本吻合。这个 Skill 里面最容易被忽视的是“预留余量”。很多非专业的人会把算出来的理论值当成实际值结果一跑就 OOM。我的建议是Skill 里强制加入一个冗余系数阻碍你自信满满地卡着临界值部署。顺便说一句别被各种榜单上夸张的跑分数字带偏对你写代码做实验来说跑分只是参考能不能稳定跑完你的任务才是关键。我个人体会这个 Skill 特别适合两类人第一类是研究生写开题报告和中期报告的时候需要给导师明确的计算资源说明第二类是创业团队或实验室管理员需要给不同项目分配 GPU。它让你在面对“需要几块卡”这个问题时不再是拍脑袋而是有据可依。2.6 自研 Skill 开发把一个重复十次的流程固化下来最后这个不是某个现成的 Skill而是“开发 Skill 的能力”。热词里“skill开发”“skill recorder”“skill脚本”出现频率非常高说明越来越多人不满足于别人做好的 Skill想自己定制。我自己的经验开发一个 Skill 不必一开始就写得很正式。你只需要做到三件事第一记录流程。下次再做某个重复性任务时刻意记录你引导模型的每一步包括你输入的提示词、你要求输出的结构、你中途纠正它的地方。这一步相当于“Skill Recorder”——先录下来再提炼。第二提炼模板。把流程中的“每一步为什么这么做”想明白然后用平实的语言写进 SKILL.md。不需要用复杂的术语模型读得懂、你读得懂就行。第三测试与迭代。把写好的 Skill 拿到一个全新对话里跑一遍看输出是否符合预期。不要指望一次成功通常要改三四轮 description 和步骤输出质量才会稳定。我做的第一个 Skill 就是为了应对“把一堆会议录音转写成结构化纪要”这个任务。一开始就是普通 Prompt后来发现每次都要重新解释“说话人识别怎么标”“行动项放哪里”太烦了就把它固化成了一个 Skill。再后来写标书、写综述、做预算全都被我陆续 Skill 化了。关于 Skill 开发我再补一个很重要的观点Skill 的本质是把你的专业经验工程化。它不是模型能力的外挂而是你工作方式的沉淀。一个 Skill 写得好不好取决于你对任务本身理解得深不深而不取决于你会不会写多高级的代码。所以哪怕你完全不会写程序也完全可以开发出自己的科研 Skill。3. Skill 安装与实战让 GPT 类模型真正跑起科研流水线3.1 在主流工具里装 SkillCodex / Claude Code / OpenClaw我知道很多人卡在“看了一堆 Skill 介绍但不知道怎么装”这一步。这里说一个通用的思路不针对特定工具因为各家工具的 Skill 机制仍在快速迭代以官方文档为准永远不会错。目前主流工具装载 Skill 的方式基本类似在配置目录下建一个 skills 文件夹把 Skill 的文件夹放进去即可。比如你用的是 OpenAI Codex一般会在~/.codex/skills/下创建目录如果你用的是 Claude Code路径通常类似~/.claude/skills/OpenClaw 这类社区工具可能略有不同但大方向都是“一个 Skill 一个文件夹里面至少有一个 SKILL.md”。如果你装的是别人写好的 Skill安装完之后要重新开一个会话让模型重新扫描一次 Skill 目录否则新装的 Skill 不会被加载。这一点经常会坑到新手装完了结果没生效其实只是没开新会话。还有一个经常被忽略的细节检查该工具当前版本的官方目录约定因为不同版本的目录名或加载机制可能不同。如果你看到“Skill 加载失败”的报错第一时间去看工具更新日志别急着怀疑自己的 Skill 文件写错了。3.2 一个最小科研 Skill 的完整文件模板我给你展示一个真实的“最小可用”Skill 文件结构以“文献蒸馏”为例paper-distiller/ ├── SKILL.md ├── scripts/ │ └── extract_pdf.py └── reference/ └── schema_example.mdSKILL.md 是这个 Skill 的核心文件它的开头必须有 YAML frontmatter里面写清楚 name 和 description。description 非常重要因为模型靠它来判断“什么时候该用这个 Skill”。描述越具体误触发和漏触发的概率越低。--- name: paper-distiller description: 用于对学术论文进行结构化信息抽取和综述对比。当用户提供 PDF 文本、论文原文或一段较长的论文内容并要求总结、提炼、对比或多文献综述时使用。 --- # Paper Distiller ## 目标 从学术论文中抽取结构化信息生成可直接引用的综述素材。 ## 步骤 1. 读取用户提供的论文文本。 2. 按 reference/schema_example.md 中的字段抽取信息。 3. 输出一篇论文的结构化笔记。 4. 当用户提供多篇论文时生成对比矩阵。 ## 输出格式 每条笔记包含 - 研究问题 - 方法核心 - 数据集与实验设置 - 关键结论 - 局限与未来工作 - 与用户课题的相关程度标注 ## 注意事项 - 不要照抄原文句子用归纳性语言。 - 相关程度判断必须给出理由。scripts 目录放辅助脚本比如 PDF 转文本。reference 目录放你需要模型参考的长文档比如 schema 示例、字段说明。这样一个 Skill 的完整写下来不超过 40 行但已经能稳定完成“论文结构化笔记”任务。你先跑通它再在这个骨架上增加各种细节就很容易了。3.3 Skill 链式调用把六件事串成一条流水线单个 Skill 能解决一个问题但这还不够。科研流程是链式的所以我真正日常使用的其实是 Skill 与 Skill 之间的接力。我举一个完整的例子假设我的课题是“基于大模型的某领域文本分类优化”。我拿到一批新文献后先用 PaperDistiller 输出结构化笔记和对比矩阵筛出值得借鉴的方法然后基于筛选结果我用 MathModeler 去梳理问题建模思路建模方向定了之后用 CodeSmith 生成实验代码框架代码写完了用 TestPilot 生成测试用例做健壮性检查准备提交实验之前用 GPU 测算 Skill 评估算力需求。一个流程下来原来需要一周的准备工作现在两天能完成初版。我踩过的最深的一个坑是让一个 Skill 去干另一个 Skill 的活。比如你明明在写代码结果文献蒸馏 Skill 也被触发了开始自动总结你的代码注释。这个问题的根源在于 description 写得太宽泛。后来我把每个 Skill 的 description 都加了非常明确的触发边界比如“仅当用户提供论文文本时使用”“仅当用户要求生成代码时使用”误触发率大幅下降。还有一个实操技巧如果你用的是支持 Agent 机制的客户端可以为整条流水线建一个“科研总管”的 Agent它自己统筹调用各个 Skill。这相当于你招了一个项目助理在你不上心的时候替你把流程往前推。4. 常见问题与排查实录踩过的坑都替你列好了4.1 Skill 加载不上、完全没生效这个是我被问得最多的问题我自己也遇到过。常见原因有三一是目录结构不对很多工具要求技能文件夹名字与 SKILL.md 里的 name 完全一致大小写也算二是 SKILL.md 的 frontmatter 格式写错比如 description 前面少了一个空格或使用了不支持的关键字三是权限问题放在系统目录下的文件没有可读权限也会导致加载失败。排查思路很简单先检查目录命名和文件是否齐全再检查 frontmatter 格式最后以管理员或当前用户权限重新放置目录。最笨也最有效的方法是新建一个空白会话输入一段明显触发该技能描述内容的话看模型是否按你的流程输出。这一步就能判断到底有没有加载成功。4.2 输出质量忽高忽低Skill 只是把流程固定了但生成质量仍然受模型状态和上下文影响。如果你发现输出忽高忽低先看上下文是否太长。模型注意力在超长上下文里会衰减导致后半段指令被“遗忘”。解决办法是把任务切成更小的子任务每个子任务单独开一个会话。另一种常见情况是 description 写得太具体导致模型在边界场景下不知道是不是该用这个 Skill最后用了个折中的方式输出效果四不像。这时候要把触发条件描述得更准确而不是更复杂。描述越简单越明确触发越稳定。4.3 多个 Skill 互相抢活干这个问题在 Skill 数量多了以后特别明显。比如你想让模型“读取一份 PDF写一段 Python 代码分析数据”结果文献 Skill 和代码 Skill 同时被触发输出就乱七八糟。解决方案我前面提过给每个 Skill 的 description 加上“仅当……时使用”的限制。更进一步可以把冲突的 Skill 拆成更小粒度的子 Skill让它们各自只负责一个非常明确的场景。如果还不行就考虑用 Agent 统一调度让模型在调用 Skill 前先判断“当前任务发不发给我”。4.4 数据安全边界Skill 不是保险箱最后提醒一个很多人忽略的问题Skill 会读取你的文件、你的上下文甚至可能执行脚本。不要轻易把实验室内部数据、个人隐私数据、未公开研究内容交给一个你不清楚底细的 Skill尤其是从网上下载的。即使你信任模型服务商也不建议把完整原始数据丢进去可以先脱敏、再分段处理。我在团队里推广 Skill 时候立了一条规矩下载任何外部 Skill先通读 SKILL.md 和 scripts 目录里的脚本确认没有恶意行为再使用。自己开发的 Skill 如果没有特别需求尽量不写“自动执行任意命令”的脚本。让模型生成文本建议、由人来执行关键操作是目前最稳妥的平衡点。根据我的经验科研场景里 80% 的任务并不需要模型“替你做决策”而是需要它“按你的规则高效执行”。Skill 恰好就是这个定位。从文献蒸馏到数学建模从代码工程化到测试审计从算力测算到自研技能每一个 Skill 本质上都是把你过去零散的经验固化成可复用的资产。真正拉开你和别人差距的从来不是模型的跑分而是你用它组织工作的方式。最后分享一个小技巧写 Skill 的时候在它的输出要求里加上一条“执行完必须输出自检清单”。这样模型每次跑完任务都会自己检查一遍格式是否完整、步骤是否遗漏稳定性会显著提升。我试了很多方法这招虽然简单但效果出奇地好。