科研人每天面对的最大痛点其实不是想不出idea而是信息处理量远超个人脑力上限。读文献、追arxiv、整理实验记录、写代码、跑数据、改论文这一整套流程里真正需要人类创造力的部分可能只占20%剩下80%都是重复性的信息搬运和格式转换。GPT-6 出来之后很多人第一反应是它比上一代强多少但真正拉开效率差距的其实是你给它配了哪些 Skill。这篇内容面向的是每天跟论文、代码、数据打交道的科研工作者也包括正在读研读博、需要大量处理文献和实验记录的人。我会把科研场景下最值得装的5个 Skill 拆开讲清楚每个 Skill 解决什么问题、为什么这样设计、具体怎么配置、实际用起来会遇到哪些坑。不是泛泛而谈的推荐清单而是可以直接照着搭的操作记录。1. 先搞清楚 Skill 到底是什么以及科研人为什么需要它1.1 Skill 和普通 Prompt 的本质区别很多人第一次接触 Skill 这个概念会把它理解成高级一点的提示词模板。这个理解不算错但漏掉了最关键的一层Prompt 是一次性的Skill 是可复用、可组合、可版本管理的能力单元。打个比方Prompt 像是你每次做实验前临时写的一张便签告诉助手今天帮我做Western blot注意别把抗体搞混了。而 Skill 更像是实验室里那本标准操作手册SOP里面写清楚了每一步的操作、注意事项、常见问题和预期结果。你不需要每次重新交代助手拿到手册就能按流程执行。从技术实现上看一个 Skill 通常包含这几个部分SKILL.md 文件核心描述文件定义这个 Skill 的用途、触发条件、输入输出格式脚本或工具调用Skill 可以绑定具体的执行逻辑比如调用 arxiv API、解析 PDF、生成图表上下文约束告诉模型在什么场景下应该激活这个 Skill什么场景下不应该这就解释了为什么热词里频繁出现SKILL.md、skill脚本、skill插件这些词。Skill 不是一段对话它是一个有结构的工程产物。1.2 科研场景对 Skill 的特殊要求科研工作和一般的文案写作、客服问答有本质区别它对 Skill 提出了几个额外要求第一可追溯性。你让模型帮你总结一篇论文它给出的结论必须能对应到原文的具体段落。这不是最好有而是必须有。科研容错率极低一个错误的引用可能导致整个综述方向跑偏。第二领域精度。通用模型对专业术语的理解经常停留在看起来对的层面。比如你让它处理冷冻电镜的数据它可能会把分辨率单位和放大倍数搞混。Skill 需要把领域知识固化进去。第三批量处理能力。科研人不是读一篇论文是读一百篇。不是跑一次数据是跑几十组参数。Skill 必须能支撑批量化、流程化的操作。第四与现有工具链的衔接。科研人的工作流里已经有 Zotero、Jupyter、LaTeX、Git 这些工具Skill 不能是孤岛得能嵌进去。理解了这些要求再看下面5个 Skill 的设计逻辑就会清晰很多。2. arxiv 追踪 Skill把文献订阅从手动刷变成自动推2.1 为什么 arxiv 追踪是科研人的第一刚需热词里arxiv和arxiv 怎样订阅同时出现说明大量科研人卡在同一个问题上知道 arxiv 重要但不知道怎么高效地追踪自己领域的新论文。传统做法是每天手动刷 arxiv 的列表页或者依赖 Google Scholar 的邮件提醒。前者费时间后者有延迟而且两者都无法做精细化的筛选。一个做强化学习的人可能只关心特定几个子方向但 arxiv 每天推送的 cs.LG 分类下有上百篇新论文大部分跟你的方向无关。arxiv 追踪 Skill 的核心价值就是把这套人找论文的流程反过来变成论文找人。2.2 这个 Skill 的实际配置方式一个可用的 arxiv 追踪 Skill通常需要配置这几个部分# skill_config.yaml 示例结构 skill_name: arxiv_tracker trigger: 每日定时 / 手动触发 sources: - arxiv_categories: [cs.LG, cs.CL, stat.ML] - keywords: [reinforcement learning, sample efficiency, offline RL] - authors: [关注的具体作者列表] filters: - exclude_keywords: [survey, position paper] - min_relevance_score: 0.7 output: format: markdown_digest destination: 本地笔记 / 邮件 / 即时通讯工具这里有几个设计决策值得展开说。为什么用关键词加作者双通道纯关键词会漏掉一些标题不包含关键词但内容相关的好论文纯作者追踪又会错过新崛起的研究者。两个通道并行召回率明显更高。为什么要有 exclude_keywords因为 survey 类论文和 position paper 的信息密度跟原创研究完全不同。如果你每天收到10篇 digest其中5篇是综述实际可读性会大打折扣。排除掉这些digest 的信噪比会高很多。min_relevance_score 怎么定这个阈值需要根据你的领域宽度调整。方向窄的人可以设到0.8方向宽的人设0.6比较合适。设太高会漏设太低会烦。2.3 实测中容易踩的坑第一个坑是分类选择过宽。很多人一上来就把 cs.AI、cs.LG、cs.CL 全勾上结果每天收到几十篇。建议先用一周时间观察逐步收窄到真正相关的2-3个分类。第二个坑是关键词太泛。比如你写 deep learning那基本等于没筛选。好的关键词应该是 contrastive learning for graph representation 这种具体到方法层面的。第三个坑是digest 格式没设计好。如果 Skill 只是把论文标题和摘要堆在一起你还是要自己一篇篇点开看。好的 digest 应该包含标题、作者、一句话核心贡献由模型提炼、与你研究的相关性判断、原文链接。这样你扫一眼就能决定哪几篇值得精读。提示arxiv 的 API 有请求频率限制批量拉取时记得加延时。一般建议每次请求间隔至少3秒否则容易被限流。3. 论文精读 Skill从读完就忘到结构化沉淀3.1 精读 Skill 要解决的核心问题arxiv 追踪解决的是找到论文精读 Skill 解决的是消化论文。这两个环节之间的落差是很多科研人效率低下的根源论文下载了一堆真正读进去的没几篇读进去的过两周又忘了。精读 Skill 的设计目标不是帮你读论文而是帮你把论文拆解成可复用的知识单元。3.2 结构化拆解的维度设计一个成熟的论文精读 Skill会从这几个维度拆解一篇论文拆解维度具体内容科研价值研究问题这篇论文试图解决什么判断是否与你的方向相关核心方法用了什么技术路线可迁移到自己的研究实验设计数据集、baseline、评价指标参考实验设计思路关键结论主要发现和数值结果直接引用的素材局限性作者自己承认的不足寻找后续研究切入点可复现性代码/数据是否公开决定是否值得深入这个表格不是随便列的。局限性这一栏尤其重要因为很多创新点就藏在别人论文的 limitation 里。你读一篇论文如果只记住它的贡献那只是消费如果你能看出它没解决的问题那才是生产。3.3 SKILL.md 里应该写什么精读 Skill 的核心在于 SKILL.md 的指令设计。以下是一个实际可用的结构# 论文精读 Skill ## 触发条件 当用户提供一篇论文的 PDF 或 arxiv 链接时激活。 ## 执行流程 1. 提取论文的标题、作者、发表信息 2. 按以下结构输出分析 - 研究问题2-3句话 - 核心方法技术路线概述 - 实验设置数据集、baseline、指标 - 主要结果关键数值 - 局限性作者声明 你的判断 - 与用户研究方向的相关性 3. 生成3-5个可延伸的研究问题 ## 约束 - 所有结论必须标注原文出处章节或页码 - 不确定的内容标注需人工确认 - 不臆造论文中未提及的信息这里最关键的是最后两条约束。科研场景下模型编造比不知道危险得多。明确要求标注出处和不确定标记能大幅降低误用风险。3.4 批量精读时的处理策略单篇精读和批量精读的策略完全不同。批量处理时建议分两轮第一轮快速筛选。只提取标题、摘要、核心贡献生成一个对比表格。这一轮的目标是决定哪些论文值得进入第二轮。第二轮深度拆解。对筛选出的论文做完整的结构化分析。这样做的原因是如果你对每篇论文都做深度拆解时间成本会高到不可接受。先用低成本的方式过滤再对高价值目标投入深度处理这才是合理的资源分配。4. 实验记录 Skill让实验日志自动变成可检索的知识库4.1 科研人记实验记录的普遍困境实验记录这件事几乎每个科研人都知道重要但几乎每个人做得都不够好。原因很简单做实验的时候忙着调参数、跑代码哪有时间详细记录等实验做完了再补记录细节已经忘得差不多了。结果就是三个月后你想复现自己之前的某个结果翻遍笔记本和代码注释还是搞不清楚当时到底改了什么参数。实验记录 Skill 要解决的就是记录成本和记录价值之间的矛盾。核心思路是让记录这件事尽可能自动化同时保证记录的结构化程度足够高方便后续检索。4.2 自动记录的触发点和内容一个实用的实验记录 Skill应该在这些节点自动触发记录代码运行时自动捕获 git commit hash、运行命令、环境配置、随机种子参数变更时记录改了哪些超参数、从什么值改到什么值结果产出时记录关键指标、输出文件路径、运行时长异常发生时记录报错信息、当时的上下文这些信息如果靠人工记录几乎不可能做到完整。但通过 Skill 绑定到代码执行流程上就可以自动完成。4.3 记录格式的设计记录格式直接决定了后续能不能检索。推荐使用结构化格式比如{ experiment_id: exp_20250115_001, timestamp: 2025-01-15T14:30:00, git_commit: a3f8c2d, command: python train.py --lr 0.001 --batch_size 64, hyperparameters: { learning_rate: 0.001, batch_size: 64, epochs: 100 }, metrics: { train_loss: 0.0234, val_accuracy: 0.8912 }, notes: 尝试降低学习率观察是否改善收敛稳定性, artifacts: [checkpoints/model_epoch100.pt, logs/train.log] }这个格式的好处是后续可以用脚本批量分析。比如你想找出所有 val_accuracy 超过0.9的实验它们的 learning_rate 分布是什么直接写个查询就行。4.4 和现有工具链的衔接实验记录 Skill 不应该另起炉灶而是要嵌入你已有的工作流。常见的衔接方式与 Git 集成每次 commit 自动关联最近的实验记录与 Jupyter 集成notebook 执行时自动捕获 cell 输出与实验管理平台集成如果你们组用 Weights Biases 或 MLflowSkill 可以把记录同步过去这里有个经验不要追求一步到位。先把最基础的自动记录跑通用一段时间发现哪些信息经常需要但没记到再逐步补充。一上来就设计一个完美的记录系统大概率会因为太复杂而放弃。5. 代码辅助 Skill科研编程和工程编程是两回事5.1 科研代码的特殊性热词里codex、codex skill、codex使用教程出现频率很高说明很多人在用 Codex 类工具辅助编程。但科研编程和工程编程有本质区别直接套用工程领域的代码辅助方案效果往往不好。科研代码的特点一次性 vs 可维护很多科研代码只跑一次不需要考虑长期维护正确性优先于性能先跑通再优化过早优化是科研大忌探索性强经常需要快速试错代码结构随时可能推翻重来可复现性要求高实验代码必须能被自己和他人复现这些特点决定了科研代码辅助 Skill 的设计方向快速生成可运行的实验代码而不是优雅的生产级代码。5.2 代码辅助 Skill 的核心能力一个面向科研的代码辅助 Skill应该具备这些能力第一从论文到代码的转换。给一篇论文的方法部分生成可运行的 PyTorch 或 JAX 实现。这个能力极大加速了复现过程。第二实验脚手架生成。给定数据集和模型结构自动生成训练循环、验证逻辑、日志记录、checkpoint 保存这些模板代码。第三调试辅助。当实验报错时能结合报错信息和代码上下文给出可能的原因和修复建议。第四可视化代码生成。科研论文里的图表有固定套路Skill 可以根据数据格式自动生成符合论文规范的绘图代码。5.3 实际使用中的注意事项不要盲信生成的代码。模型生成的代码经常在边界条件上出问题比如空张量处理、维度不匹配、数值溢出。跑之前一定要小规模测试。保留人工审查环节。尤其是涉及数据处理和评价指标计算的部分一个 subtle 的 bug 可能让你的实验结果完全错误而且很难发现。版本管理要跟上。用 Skill 生成代码的速度很快如果不做好 git 管理很容易出现不知道哪个版本对应哪个实验的情况。注意涉及codex相关配置时如果遇到codex is ignoring 1 unrecognized configuration setting这类提示通常是配置文件里有拼写错误或版本不兼容的字段。建议对照官方文档逐项检查不要直接忽略。6. 论文写作 Skill从实验完成到投稿的最后一公里6.1 写作 Skill 能帮什么不能帮什么先说清楚边界写作 Skill 不能帮你产生核心 idea不能替你判断实验结果的意义也不能保证论文被接收。它能做的是把你已经完成的工作用符合学术规范的方式组织成论文。具体来说它能帮的环节包括结构组织根据你的实验内容建议合理的章节安排文献综述辅助把之前精读 Skill 沉淀的知识单元组织成综述段落图表描述根据图表数据生成准确的文字描述语言润色改善表达的清晰度和学术性格式检查检查引用格式、图表编号、公式编号的一致性6.2 写作 Skill 的配置要点写作 Skill 的配置里最重要的是风格约束。不同期刊、不同领域的写作风格差异很大。你需要把目标期刊的写作规范固化到 Skill 里。# 论文写作 Skill 配置 ## 目标期刊风格 - 领域机器学习 / 计算机视觉 - 引用格式NeurIPS 风格 - 时态规范方法用现在时实验用过去时 - 人称避免第一人称单数使用 we ## 输出约束 - 每个段落不超过5句话 - 避免使用 novel、significant 等主观形容词 - 所有数值结果必须标注来源哪个表/图 - 不生成未经用户确认的实验结论这里 不生成未经用户确认的实验结论 是一条硬约束。模型很容易根据上下文推测出一个看起来合理的结论但科研论文里的每一句话都必须有实验支撑。6.3 和精读 Skill 的联动写作 Skill 和精读 Skill 之间有一个很自然的联动精读时沉淀的结构化笔记可以直接作为写作时的素材库。比如你写 related work 部分不需要重新去翻论文而是从精读笔记里检索相关的方法和结论组织成段落。这个流程的前提是精读 Skill 的输出格式和写作 Skill 的输入格式要匹配。所以在设计这两个 Skill 的时候最好统一数据格式。7. 五个 Skill 怎么组合成一套完整工作流单独看每个 Skill 都有价值但真正的效率提升来自于把它们串起来。7.1 完整工作流的串联方式一个典型的科研工作流是这样的arxiv 追踪 Skill每天推送相关新论文你从 digest 里挑选值得读的论文交给精读 Skill做结构化拆解精读笔记沉淀到知识库成为后续写作的素材你基于文献调研确定研究方向用代码辅助 Skill快速实现和迭代实验实验记录 Skill自动记录每次实验的配置和结果实验完成后写作 Skill帮你把结果组织成论文这六个环节追踪、精读、沉淀、实现、记录、写作构成了一个闭环。每个 Skill 负责一个环节环节之间的数据格式统一就能实现无缝衔接。7.2 组合使用时的注意事项数据格式统一是前提。如果精读 Skill 输出的笔记格式和写作 Skill 期望的输入格式不一致你就需要手动转换效率提升会大打折扣。建议在搭建初期就定义好统一的数据 schema。不要一次性全上。五个 Skill 同时配置调试成本很高。建议先从最痛的那个环节开始跑通了再加下一个。一般来说arxiv 追踪和精读是最容易见效的切入点。定期回顾和调整。Skill 的配置不是一劳永逸的。你的研究方向会变关注的期刊会变工作流的瓶颈也会变。建议每个月花半小时回顾一下哪些 Skill 用得多、哪些用得少、哪些需要调整参数。7.3 关于 Skill 生态的一些观察从热词里能看到Skill 生态正在快速演化。skill插件、agent skill、skill脚本这些词的高频出现说明越来越多人在把 Skill 当作一种可分享、可复用的资产。对科研人来说这意味着你不需要从零搭建所有 Skill。社区里已经有人分享了各种领域的 Skill 配置你可以基于这些做二次开发。但要注意直接拿来用的 Skill 往往需要根据你的具体场景调整尤其是涉及领域知识的约束条件。另外去ai味的skill这个热词也值得注意。它反映了一个真实需求科研写作里AI 生成的痕迹太明显会被审稿人注意到。好的写作 Skill 应该能生成自然、符合学术惯例的表达而不是那种一眼就能看出是模型写的文字。8. 一些实际使用中的经验教训8.1 关于 Skill 的调试Skill 调试最有效的方法是用已知答案的案例做测试。比如你配置了一个精读 Skill就拿一篇你已经很熟悉的论文让它分析看输出是否准确、是否有遗漏、是否有编造。这比随便找一篇新论文测试有效得多。另一个经验是把 Skill 的失败案例收集起来。每次 Skill 输出不符合预期就记录下当时的输入和输出。积累一段时间后你会发现失败模式是有规律的针对这些规律调整 SKILL.md 的约束条件效果比盲目修改好得多。8.2 关于时间投入的预期搭建这套 Skill 体系需要时间。第一个 Skill 从零到可用可能需要几个小时。但随着你对 Skill 机制的理解加深后续的搭建速度会明显加快。从投入产出比来看arxiv 追踪和精读 Skill 的回报最快基本当天配置当天见效。代码辅助和实验记录 Skill 需要跟你的代码库磨合可能需要一两周才能跑顺。写作 Skill 的回报周期最长但一旦跑通在论文产出阶段的效率提升非常明显。8.3 一个容易被忽略的点很多人配置 Skill 的时候只关注能不能用忽略了好不好维护。一个 Skill 如果配置过于复杂过两个月你自己都看不懂了那它的实际价值会大打折扣。建议在 SKILL.md 里写清楚每个配置项的理由就像写代码注释一样。这样当你需要调整的时候能快速理解当初为什么这么设计。我在实际使用中体会最深的一点是Skill 的价值不在于它有多智能而在于它有多稳定。一个能稳定完成80%任务的简单 Skill比一个偶尔能完成100%但经常出错的复杂 Skill 有用得多。科研工作最怕的就是不确定性Skill 应该成为你工作流里最可靠的那一环。
科研人必装的5个GPT-6 Skill：从arxiv追踪到论文写作的完整工作流
科研人每天面对的最大痛点其实不是想不出idea而是信息处理量远超个人脑力上限。读文献、追arxiv、整理实验记录、写代码、跑数据、改论文这一整套流程里真正需要人类创造力的部分可能只占20%剩下80%都是重复性的信息搬运和格式转换。GPT-6 出来之后很多人第一反应是它比上一代强多少但真正拉开效率差距的其实是你给它配了哪些 Skill。这篇内容面向的是每天跟论文、代码、数据打交道的科研工作者也包括正在读研读博、需要大量处理文献和实验记录的人。我会把科研场景下最值得装的5个 Skill 拆开讲清楚每个 Skill 解决什么问题、为什么这样设计、具体怎么配置、实际用起来会遇到哪些坑。不是泛泛而谈的推荐清单而是可以直接照着搭的操作记录。1. 先搞清楚 Skill 到底是什么以及科研人为什么需要它1.1 Skill 和普通 Prompt 的本质区别很多人第一次接触 Skill 这个概念会把它理解成高级一点的提示词模板。这个理解不算错但漏掉了最关键的一层Prompt 是一次性的Skill 是可复用、可组合、可版本管理的能力单元。打个比方Prompt 像是你每次做实验前临时写的一张便签告诉助手今天帮我做Western blot注意别把抗体搞混了。而 Skill 更像是实验室里那本标准操作手册SOP里面写清楚了每一步的操作、注意事项、常见问题和预期结果。你不需要每次重新交代助手拿到手册就能按流程执行。从技术实现上看一个 Skill 通常包含这几个部分SKILL.md 文件核心描述文件定义这个 Skill 的用途、触发条件、输入输出格式脚本或工具调用Skill 可以绑定具体的执行逻辑比如调用 arxiv API、解析 PDF、生成图表上下文约束告诉模型在什么场景下应该激活这个 Skill什么场景下不应该这就解释了为什么热词里频繁出现SKILL.md、skill脚本、skill插件这些词。Skill 不是一段对话它是一个有结构的工程产物。1.2 科研场景对 Skill 的特殊要求科研工作和一般的文案写作、客服问答有本质区别它对 Skill 提出了几个额外要求第一可追溯性。你让模型帮你总结一篇论文它给出的结论必须能对应到原文的具体段落。这不是最好有而是必须有。科研容错率极低一个错误的引用可能导致整个综述方向跑偏。第二领域精度。通用模型对专业术语的理解经常停留在看起来对的层面。比如你让它处理冷冻电镜的数据它可能会把分辨率单位和放大倍数搞混。Skill 需要把领域知识固化进去。第三批量处理能力。科研人不是读一篇论文是读一百篇。不是跑一次数据是跑几十组参数。Skill 必须能支撑批量化、流程化的操作。第四与现有工具链的衔接。科研人的工作流里已经有 Zotero、Jupyter、LaTeX、Git 这些工具Skill 不能是孤岛得能嵌进去。理解了这些要求再看下面5个 Skill 的设计逻辑就会清晰很多。2. arxiv 追踪 Skill把文献订阅从手动刷变成自动推2.1 为什么 arxiv 追踪是科研人的第一刚需热词里arxiv和arxiv 怎样订阅同时出现说明大量科研人卡在同一个问题上知道 arxiv 重要但不知道怎么高效地追踪自己领域的新论文。传统做法是每天手动刷 arxiv 的列表页或者依赖 Google Scholar 的邮件提醒。前者费时间后者有延迟而且两者都无法做精细化的筛选。一个做强化学习的人可能只关心特定几个子方向但 arxiv 每天推送的 cs.LG 分类下有上百篇新论文大部分跟你的方向无关。arxiv 追踪 Skill 的核心价值就是把这套人找论文的流程反过来变成论文找人。2.2 这个 Skill 的实际配置方式一个可用的 arxiv 追踪 Skill通常需要配置这几个部分# skill_config.yaml 示例结构 skill_name: arxiv_tracker trigger: 每日定时 / 手动触发 sources: - arxiv_categories: [cs.LG, cs.CL, stat.ML] - keywords: [reinforcement learning, sample efficiency, offline RL] - authors: [关注的具体作者列表] filters: - exclude_keywords: [survey, position paper] - min_relevance_score: 0.7 output: format: markdown_digest destination: 本地笔记 / 邮件 / 即时通讯工具这里有几个设计决策值得展开说。为什么用关键词加作者双通道纯关键词会漏掉一些标题不包含关键词但内容相关的好论文纯作者追踪又会错过新崛起的研究者。两个通道并行召回率明显更高。为什么要有 exclude_keywords因为 survey 类论文和 position paper 的信息密度跟原创研究完全不同。如果你每天收到10篇 digest其中5篇是综述实际可读性会大打折扣。排除掉这些digest 的信噪比会高很多。min_relevance_score 怎么定这个阈值需要根据你的领域宽度调整。方向窄的人可以设到0.8方向宽的人设0.6比较合适。设太高会漏设太低会烦。2.3 实测中容易踩的坑第一个坑是分类选择过宽。很多人一上来就把 cs.AI、cs.LG、cs.CL 全勾上结果每天收到几十篇。建议先用一周时间观察逐步收窄到真正相关的2-3个分类。第二个坑是关键词太泛。比如你写 deep learning那基本等于没筛选。好的关键词应该是 contrastive learning for graph representation 这种具体到方法层面的。第三个坑是digest 格式没设计好。如果 Skill 只是把论文标题和摘要堆在一起你还是要自己一篇篇点开看。好的 digest 应该包含标题、作者、一句话核心贡献由模型提炼、与你研究的相关性判断、原文链接。这样你扫一眼就能决定哪几篇值得精读。提示arxiv 的 API 有请求频率限制批量拉取时记得加延时。一般建议每次请求间隔至少3秒否则容易被限流。3. 论文精读 Skill从读完就忘到结构化沉淀3.1 精读 Skill 要解决的核心问题arxiv 追踪解决的是找到论文精读 Skill 解决的是消化论文。这两个环节之间的落差是很多科研人效率低下的根源论文下载了一堆真正读进去的没几篇读进去的过两周又忘了。精读 Skill 的设计目标不是帮你读论文而是帮你把论文拆解成可复用的知识单元。3.2 结构化拆解的维度设计一个成熟的论文精读 Skill会从这几个维度拆解一篇论文拆解维度具体内容科研价值研究问题这篇论文试图解决什么判断是否与你的方向相关核心方法用了什么技术路线可迁移到自己的研究实验设计数据集、baseline、评价指标参考实验设计思路关键结论主要发现和数值结果直接引用的素材局限性作者自己承认的不足寻找后续研究切入点可复现性代码/数据是否公开决定是否值得深入这个表格不是随便列的。局限性这一栏尤其重要因为很多创新点就藏在别人论文的 limitation 里。你读一篇论文如果只记住它的贡献那只是消费如果你能看出它没解决的问题那才是生产。3.3 SKILL.md 里应该写什么精读 Skill 的核心在于 SKILL.md 的指令设计。以下是一个实际可用的结构# 论文精读 Skill ## 触发条件 当用户提供一篇论文的 PDF 或 arxiv 链接时激活。 ## 执行流程 1. 提取论文的标题、作者、发表信息 2. 按以下结构输出分析 - 研究问题2-3句话 - 核心方法技术路线概述 - 实验设置数据集、baseline、指标 - 主要结果关键数值 - 局限性作者声明 你的判断 - 与用户研究方向的相关性 3. 生成3-5个可延伸的研究问题 ## 约束 - 所有结论必须标注原文出处章节或页码 - 不确定的内容标注需人工确认 - 不臆造论文中未提及的信息这里最关键的是最后两条约束。科研场景下模型编造比不知道危险得多。明确要求标注出处和不确定标记能大幅降低误用风险。3.4 批量精读时的处理策略单篇精读和批量精读的策略完全不同。批量处理时建议分两轮第一轮快速筛选。只提取标题、摘要、核心贡献生成一个对比表格。这一轮的目标是决定哪些论文值得进入第二轮。第二轮深度拆解。对筛选出的论文做完整的结构化分析。这样做的原因是如果你对每篇论文都做深度拆解时间成本会高到不可接受。先用低成本的方式过滤再对高价值目标投入深度处理这才是合理的资源分配。4. 实验记录 Skill让实验日志自动变成可检索的知识库4.1 科研人记实验记录的普遍困境实验记录这件事几乎每个科研人都知道重要但几乎每个人做得都不够好。原因很简单做实验的时候忙着调参数、跑代码哪有时间详细记录等实验做完了再补记录细节已经忘得差不多了。结果就是三个月后你想复现自己之前的某个结果翻遍笔记本和代码注释还是搞不清楚当时到底改了什么参数。实验记录 Skill 要解决的就是记录成本和记录价值之间的矛盾。核心思路是让记录这件事尽可能自动化同时保证记录的结构化程度足够高方便后续检索。4.2 自动记录的触发点和内容一个实用的实验记录 Skill应该在这些节点自动触发记录代码运行时自动捕获 git commit hash、运行命令、环境配置、随机种子参数变更时记录改了哪些超参数、从什么值改到什么值结果产出时记录关键指标、输出文件路径、运行时长异常发生时记录报错信息、当时的上下文这些信息如果靠人工记录几乎不可能做到完整。但通过 Skill 绑定到代码执行流程上就可以自动完成。4.3 记录格式的设计记录格式直接决定了后续能不能检索。推荐使用结构化格式比如{ experiment_id: exp_20250115_001, timestamp: 2025-01-15T14:30:00, git_commit: a3f8c2d, command: python train.py --lr 0.001 --batch_size 64, hyperparameters: { learning_rate: 0.001, batch_size: 64, epochs: 100 }, metrics: { train_loss: 0.0234, val_accuracy: 0.8912 }, notes: 尝试降低学习率观察是否改善收敛稳定性, artifacts: [checkpoints/model_epoch100.pt, logs/train.log] }这个格式的好处是后续可以用脚本批量分析。比如你想找出所有 val_accuracy 超过0.9的实验它们的 learning_rate 分布是什么直接写个查询就行。4.4 和现有工具链的衔接实验记录 Skill 不应该另起炉灶而是要嵌入你已有的工作流。常见的衔接方式与 Git 集成每次 commit 自动关联最近的实验记录与 Jupyter 集成notebook 执行时自动捕获 cell 输出与实验管理平台集成如果你们组用 Weights Biases 或 MLflowSkill 可以把记录同步过去这里有个经验不要追求一步到位。先把最基础的自动记录跑通用一段时间发现哪些信息经常需要但没记到再逐步补充。一上来就设计一个完美的记录系统大概率会因为太复杂而放弃。5. 代码辅助 Skill科研编程和工程编程是两回事5.1 科研代码的特殊性热词里codex、codex skill、codex使用教程出现频率很高说明很多人在用 Codex 类工具辅助编程。但科研编程和工程编程有本质区别直接套用工程领域的代码辅助方案效果往往不好。科研代码的特点一次性 vs 可维护很多科研代码只跑一次不需要考虑长期维护正确性优先于性能先跑通再优化过早优化是科研大忌探索性强经常需要快速试错代码结构随时可能推翻重来可复现性要求高实验代码必须能被自己和他人复现这些特点决定了科研代码辅助 Skill 的设计方向快速生成可运行的实验代码而不是优雅的生产级代码。5.2 代码辅助 Skill 的核心能力一个面向科研的代码辅助 Skill应该具备这些能力第一从论文到代码的转换。给一篇论文的方法部分生成可运行的 PyTorch 或 JAX 实现。这个能力极大加速了复现过程。第二实验脚手架生成。给定数据集和模型结构自动生成训练循环、验证逻辑、日志记录、checkpoint 保存这些模板代码。第三调试辅助。当实验报错时能结合报错信息和代码上下文给出可能的原因和修复建议。第四可视化代码生成。科研论文里的图表有固定套路Skill 可以根据数据格式自动生成符合论文规范的绘图代码。5.3 实际使用中的注意事项不要盲信生成的代码。模型生成的代码经常在边界条件上出问题比如空张量处理、维度不匹配、数值溢出。跑之前一定要小规模测试。保留人工审查环节。尤其是涉及数据处理和评价指标计算的部分一个 subtle 的 bug 可能让你的实验结果完全错误而且很难发现。版本管理要跟上。用 Skill 生成代码的速度很快如果不做好 git 管理很容易出现不知道哪个版本对应哪个实验的情况。注意涉及codex相关配置时如果遇到codex is ignoring 1 unrecognized configuration setting这类提示通常是配置文件里有拼写错误或版本不兼容的字段。建议对照官方文档逐项检查不要直接忽略。6. 论文写作 Skill从实验完成到投稿的最后一公里6.1 写作 Skill 能帮什么不能帮什么先说清楚边界写作 Skill 不能帮你产生核心 idea不能替你判断实验结果的意义也不能保证论文被接收。它能做的是把你已经完成的工作用符合学术规范的方式组织成论文。具体来说它能帮的环节包括结构组织根据你的实验内容建议合理的章节安排文献综述辅助把之前精读 Skill 沉淀的知识单元组织成综述段落图表描述根据图表数据生成准确的文字描述语言润色改善表达的清晰度和学术性格式检查检查引用格式、图表编号、公式编号的一致性6.2 写作 Skill 的配置要点写作 Skill 的配置里最重要的是风格约束。不同期刊、不同领域的写作风格差异很大。你需要把目标期刊的写作规范固化到 Skill 里。# 论文写作 Skill 配置 ## 目标期刊风格 - 领域机器学习 / 计算机视觉 - 引用格式NeurIPS 风格 - 时态规范方法用现在时实验用过去时 - 人称避免第一人称单数使用 we ## 输出约束 - 每个段落不超过5句话 - 避免使用 novel、significant 等主观形容词 - 所有数值结果必须标注来源哪个表/图 - 不生成未经用户确认的实验结论这里 不生成未经用户确认的实验结论 是一条硬约束。模型很容易根据上下文推测出一个看起来合理的结论但科研论文里的每一句话都必须有实验支撑。6.3 和精读 Skill 的联动写作 Skill 和精读 Skill 之间有一个很自然的联动精读时沉淀的结构化笔记可以直接作为写作时的素材库。比如你写 related work 部分不需要重新去翻论文而是从精读笔记里检索相关的方法和结论组织成段落。这个流程的前提是精读 Skill 的输出格式和写作 Skill 的输入格式要匹配。所以在设计这两个 Skill 的时候最好统一数据格式。7. 五个 Skill 怎么组合成一套完整工作流单独看每个 Skill 都有价值但真正的效率提升来自于把它们串起来。7.1 完整工作流的串联方式一个典型的科研工作流是这样的arxiv 追踪 Skill每天推送相关新论文你从 digest 里挑选值得读的论文交给精读 Skill做结构化拆解精读笔记沉淀到知识库成为后续写作的素材你基于文献调研确定研究方向用代码辅助 Skill快速实现和迭代实验实验记录 Skill自动记录每次实验的配置和结果实验完成后写作 Skill帮你把结果组织成论文这六个环节追踪、精读、沉淀、实现、记录、写作构成了一个闭环。每个 Skill 负责一个环节环节之间的数据格式统一就能实现无缝衔接。7.2 组合使用时的注意事项数据格式统一是前提。如果精读 Skill 输出的笔记格式和写作 Skill 期望的输入格式不一致你就需要手动转换效率提升会大打折扣。建议在搭建初期就定义好统一的数据 schema。不要一次性全上。五个 Skill 同时配置调试成本很高。建议先从最痛的那个环节开始跑通了再加下一个。一般来说arxiv 追踪和精读是最容易见效的切入点。定期回顾和调整。Skill 的配置不是一劳永逸的。你的研究方向会变关注的期刊会变工作流的瓶颈也会变。建议每个月花半小时回顾一下哪些 Skill 用得多、哪些用得少、哪些需要调整参数。7.3 关于 Skill 生态的一些观察从热词里能看到Skill 生态正在快速演化。skill插件、agent skill、skill脚本这些词的高频出现说明越来越多人在把 Skill 当作一种可分享、可复用的资产。对科研人来说这意味着你不需要从零搭建所有 Skill。社区里已经有人分享了各种领域的 Skill 配置你可以基于这些做二次开发。但要注意直接拿来用的 Skill 往往需要根据你的具体场景调整尤其是涉及领域知识的约束条件。另外去ai味的skill这个热词也值得注意。它反映了一个真实需求科研写作里AI 生成的痕迹太明显会被审稿人注意到。好的写作 Skill 应该能生成自然、符合学术惯例的表达而不是那种一眼就能看出是模型写的文字。8. 一些实际使用中的经验教训8.1 关于 Skill 的调试Skill 调试最有效的方法是用已知答案的案例做测试。比如你配置了一个精读 Skill就拿一篇你已经很熟悉的论文让它分析看输出是否准确、是否有遗漏、是否有编造。这比随便找一篇新论文测试有效得多。另一个经验是把 Skill 的失败案例收集起来。每次 Skill 输出不符合预期就记录下当时的输入和输出。积累一段时间后你会发现失败模式是有规律的针对这些规律调整 SKILL.md 的约束条件效果比盲目修改好得多。8.2 关于时间投入的预期搭建这套 Skill 体系需要时间。第一个 Skill 从零到可用可能需要几个小时。但随着你对 Skill 机制的理解加深后续的搭建速度会明显加快。从投入产出比来看arxiv 追踪和精读 Skill 的回报最快基本当天配置当天见效。代码辅助和实验记录 Skill 需要跟你的代码库磨合可能需要一两周才能跑顺。写作 Skill 的回报周期最长但一旦跑通在论文产出阶段的效率提升非常明显。8.3 一个容易被忽略的点很多人配置 Skill 的时候只关注能不能用忽略了好不好维护。一个 Skill 如果配置过于复杂过两个月你自己都看不懂了那它的实际价值会大打折扣。建议在 SKILL.md 里写清楚每个配置项的理由就像写代码注释一样。这样当你需要调整的时候能快速理解当初为什么这么设计。我在实际使用中体会最深的一点是Skill 的价值不在于它有多智能而在于它有多稳定。一个能稳定完成80%任务的简单 Skill比一个偶尔能完成100%但经常出错的复杂 Skill 有用得多。科研工作最怕的就是不确定性Skill 应该成为你工作流里最可靠的那一环。